OSCON 2013 Ideas

HTML 5 Canvas

Games account for about half of the apps in the typical app store. They are among the first thing ported to any new platform. Games help drive technology forward.  This year's edition of the popular HTML Canvas Deep Pe will focus specifically on building cross platform games for mobile and desktop. We will cover everything needed to build basic games with animation, scrolling, sound effects and music, image loading, sprites, and even joystick support. Then we will learn how to package them to run on desktop and mobile devices, both in and outside of app stores.

Outline:

• Why make games?
• Why make games in Canvas?
• • it's easy and fun!
  • works everywhere. more places than any other graphics API.
  • keeps getting faster and more powerful.
• Anatomy of a game
• • game engine: it's more than just a run loop
  • images: sprites, models, and more
  • input: keyboard, touch, and joysticks
  • animation and player control
  • scaffolding: menus and splash screens
• picking a game engine
• • 2d engines
  • 3d engines
  • rolling your own
• drawing to the screen with movement
• handling input:
• • regular events: keyboard and mouse
  • multi-touch: utilities to help
  • gamepad / joystick
  • camera
• audio:
• • background music
  • sound effects
  • • latency
    • doubling up the playback
  • considerations for mobile
• resource management
• finishing touches:
• • fullscreen
  • splash screens
  • loading screens
• sharing your game with the world
• • on the web
  • mobile app stores
  • desktop app stores
  • tools to help
  • case study
• performance
• • desktop
  • mobile
  • using 3d for 2d work
• tools to help
• • performance tuning
  • resource editing
  • existing artwork and music you can use

Make both a full three hour workshop and a 1 hour talk with the lessons?

Designing The Internet of Things with the 3 Laws of Robotics

Thanks to cheap sensors and even cheaper computing, we are rapidly approaching the age of the smart home: living spaces filled with smart things. Objects connected to each other and to the internet. Thermostats, door switches, lights, windows, gas sensors and toilets.  However, this vision of things to come brings great challenges as well. How do we design interfaces for these devices? How can someone manage a house full of 200 gadgets each demanding new batteries and an IP address?  What if your networked toaster rats you out to the FBI? The challenges of building a safe and understandable Internet of Things are immense. There is one existing ethical framework that can help: Isaac Asimov's Three Laws of Robotics.

In this session we will explore the complex interactions of the Internet of Things and see how the classic Three Laws of Robotics can be applied in these situations. We will cover physical safety, data privacy, setup and maintenance, and general usability.  No knowledge of programming or interaction design is required, just an open mind and a desire see the future.

outline:

• The Internet of things?
• • Why is it cool?
  • What counts and what doesn't?
  • Inside and outside your home.
• A quick survey of the problems IoT creates:
• • data privacy
  • physical security
  • physical safety
  • data overload
  • management overload
• The Three Laws of Robotics
• • fictional and non-fictional history
  • guidance to solve our IoT problems
• Do Not Harm a Human
• • physical safety
  • emotional safety
  • preserving privacy
• Obey Orders From Humans
• • The principle of Least User Astonishment.
  • manual overrides
  • decision delegation
  • heuristic design
• Protect Own Existence
• • Easing the management burden
  • Escalation of emergencies
  • Safe failure
• Next steps

A survey of visual programming languages

Pure visual programming languages sound like a great idea. Who wouldn't want to create robust and powerful programs using more than just lines of text?  It is one of the holy grails of computer science, yet success has proven elusive. The last fifty years of research are littered with the corpses of failed attempts (along with a few interesting successes in unexpected areas).  Why is it so hard to create a visual programming language that works in the real world? In this session we will explore the history of visual programming, looking at both the failures and successes from the fifties through to modern day, We will look for clues about what works and what doesn't. We will extract concepts that can help us design visual languages in the future, as well as features to bring back into traditional programming environments.

outline

• What is visual programming?
• Why visual programming?
• • a picture is worth a thousand words, so it's more expressive. right?
  • similarity to visual structures we already use (UML, state diagrams, GUI builders)
  • non-programmers can program.
  • for teaching programming.
• what counts and what doesn't.
• • visual studio, no; visual basic yes;
  • visual aids to traditional programming don't count. 
  • some part of the application must be specified in a purely visual manner. VB forms count. same with access forms.
• history
• • early attempts in the 50s and 60s
  • the mother of all demos.
  • 80s era research. 
  • • smalltalk visual environments. didn't quite make it. why? what held them back?
    • soviet visual programming recently uncovered.
    • spreadsheet
  • 90s
  • • visual basic
    • access and other visual databases
    • flash, director, multi-media languages.
    • music composition
  • 2000s
  • • quartz composer
    • educational languages
• educational languages:
• • scratch
  • squeak & etoys
  • lego mindstorms
  • blockly: abandoned?
  • android builder thingy: abandoned?
• conclusions:
• • some tasks work visually. others do not.
  • winners:
  • • UI layout
    • drawing, animation, movies. any media creation.
    • anything where direct manipulation helps
    • where a boxes and lines metaphor already exists: music sequencers. (though it doesn't result in very extensible code)
  • losers:
  • • traditional stream and graph based algorithms
    • anything dealing with strings or non-visual data structures 
    • building libraries. reusability seems to be especially hard to get right.
• crossover ideas:
• • colors and images in a traditional editor
  • rapid/instant feedback. Processing.
  • show/hide overlays for interesting information.
  • use of color, typography, visual layout to display purely text based code.
  • mixing visual with non-visual works very well. assemble components visually. build components in regular code.
  • separate editing from viewing:  greek symbols and other very compact representations of algorithms?
  • hide the filesystem. you don't care how your code is stored on disk. dir structure is irrelevant. Smalltalk had this.

A Few Other Ideas

My 'game editor inside the game as the game' idea.

Hacking Things Up with WebKit-nix:

Nix is a port of WebKit2 based on Posix and OpenGL/ES. It is unique due to it's portabljilty and few dependencies. While it can be run on a traditional desktop environment and GUI toolkit, it's most interesting use is for embedded systems where a full GUI may not be abailalble, and for headless applications where there is no live graphics environment. This session will cover what Nix is, how to compile it,

• list of things people have done with it
•      how to compile it
•      how to integrate it into a server side app
•      how to integrate it into a client side app with direct GL rendering
•      running it on a raspi w/o X running
•      next steps and places to help

Working with the Raspberry Pi as a kiosk: no X, boot right into your app

Intro to Bluetooth Low Energy: iOS, desktop, raspberry pi, arduino.