- Appeal to a variety of interests by presenting a wide range of computer science applications. Provide lots of answers to the question "Why do I want to learn to program? What can I do with programming that I'm interested in?" Not all students may be motivated to make games. Help them find an application they are passionate about.
- Make the point that computer science isn't just relevant for "computer people". You can be a great programmer and love it without knowing everything about computers. Also, programming skills are applicable to many careers, not just software engineer.
- Provide encouragement. There are a lot of forces pushing girls away from computer science. Help combat this by encouraging students. You may provide the crucial support a vulnerable individual needs to persist.
- Recognize that there can be a tendency to attribute academic shortcomings to lacking intrinsic ability. If a student believes she is "failing" in a class (keep in mind this is in her eyes, which may be a B), she may conclude that she is not smart enough for the subject as a whole. Emphasize that other factors such as study skills (and sleep!) can have a huge impact on performance.
- Don't take lack of interest in a subject at face value. Perceived self-efficacy affects interest. A student may not be interested, in part, because the student does not feel confident.
- When stress is too high, the ability to learn decreases. If a student is feeling insecure, incapable, or otherwise stressed, performance may decrease. Don't assume that low scores indicate lack of potential.
- Feeling "out of place" can be very distracting. Instead of listening to the course material, a student may be focused on her minority status or how uncomfortable she feels (imagine trying to listen to a teacher with loud static in the background). The student may need a different environment, in which she feels comfortable, in order to focus.
- Provide actual programming practice. Show that programming isn't mysterious or too complicated to comprehend. You don't need secret "computer knowledge" to succeed. Demonstrate what to do when you don't know the answer.
- Understand the reasons that the pipeline is leaky. For one, staying in it is exhausting. If a student doesn't know why this is the case, she might be more likely to think it is just her and give up. It might take awareness of the factors involved and the deliberate decision to stay anyway.
- Encourage students not to rule out any careers due to expectations about difficulty achieving acceptable work-life-family balance. There are a lot of options out there.
- Don't try to "weed students out". Instead, encourage students to sign up for another class. Students don't have to commit to a life of programming; just stay in computer science a little bit longer.
- Have female teachers and role models. Show that you don't have to be the stereotype.
Tuesday, December 10, 2013
Preserving Girls' interest in Computer Science
My wife put together a great list of tips recently for educators asking for advice on incorporating computational thinking into their curriculum. I heartily agree with these thoughts:
Tuesday, March 19, 2013
GDC Sessions for HTML5 games on web and mobile
GDC sessions that caught my eye related to building games on web tech:
Native Apps? With HTML5? Yes You Can! (Presented by Google)
Joe Marini | Developer Advocate, Google
... Chrome Packaged Apps platform allows the creation of native app experiences using HTML5 technologies that work offline by default, have access to native platform features, and can run across a variety of operating systems.
Fast and Awesome HTML5 Games (Presented by Mozilla)
Vladimir Vukicevic | Engineering Director, Mozilla Corporation
Alon Zakai | Senior Researcher, Mozilla Corporation
... JavaScript tooling and execution allow near-native-code speeds. Combined with standards such as WebGL, Web Audio, and the rest of the HTML5 stack, the modern web is emerging as a platform for high-quality games ...
Multiplatform C++ on The Web with Emscripten
Chad Austin | Technical Director, IMVU
Emscripten is a compiler of LLVM bitcode into JavaScript. With Emscripten, programs written in C++ can run straight from your web browser, and no plug-ins are required. ... why IMVU has chosen Emscripten as part of its multi-platform engine strategy ...
(Tragically, a time conflict with 'Fast and Awesome HTML5 Games' by Mozilla, which overlaps content wise)!
Nintendo Wii U Application Development with HTML and JavaScript
Ryan Lynd | Senior Software Engineer (NST), Nintendo Software Technology
Kevin McCullough | Software Engineer, Nintendo of America
Takeshi Shimada | Deputy General Manager, Software Environment Development
... HTML and JavaScript have empowered a whole new wave of developers that have previously been excluded from Nintendo console development - until now! This session will introduce a new way of rapidly developing Wii U applications that takes full advantage of unique Wii U features while reducing development times significantly.
Game Development with Google Cloud Platform (Presented by Google)
Yanick Belanger | Server Architecture Lead, Electronic Arts
Ryan Boyd | Developer Advocate, Google
Chris Elliott | Solutions Architect, Google
Dan Holevoet | Developer Programs Engineer, Google
Momchil Kyurkchiev | CEO, Leanplum
Michael Manoochehri | Developer Programs Engineer, Google
Luca Martinetti | Founder and CTO, Staq Inc.
Google Cloud Platform provides everything you need to build, run, and scale social, mobile, and online games. Already, tens of thousands of popular applications like SongPop, Angry Birds, SnapChat, and Legend of Monsters ...
Supercharge Your Game With YouTube (Presented by YouTube)
Satyajeet Salgar | Product Manager, YouTube Live & Sports
Ibrahim Ulukaya | Developer Programs Engineer, YouTube
Jarek Wilkiewicz | Developer Advocate, YouTube
... By integrating your game with YouTube, you can share rich and authentic game experiences that are more likely to convert viewers into gamers than any other medium. In this session, we will highlight integration examples and best practices with special focus on mobile. We will also give you a sneak peek at our latest live streaming platform APIs. ...
HTML5 Cross-Platform Game Development: The Future is Today (Presented by Ludei)
Ibon Tolosana | CTO, Ludei
HTML5 is finally ready for cross-platform game development. We'll explain best practices for HTML5 game development, case studies and how to overcome issues to make HTML5 games work.
Rapid Development of High Performance Games for Mobile and Web
Ricardo Quesada | Software Architect, Zynga
This talk will be about the cocos2d JS, a complete toolchain for developing multi-platform games for both the Web and Mobile, which goes all the way from rapid prototyping to a finished high performing game. There are three main components: a game engine (cocos2d), a physics engine (Chipmunk), and a visual editor (CocosBuilder). For the web, no plugins are required. For mobile, it uses JavaScript bindings for the C/C++ version of cocos2d and Chipmunk, and achieves a performance 10 times faster than other JS engines/JS accelerators. ...
HTML5 Audio: Coming to a Mobile Game Near You!
Jory Prum | Sound Guy, studio.jory.org
... possibilities the new Web Audio API enables audio developers when building games for the web. ... With the adoption of the new W3C's new Web Audio API (available in Chrome, Safari, and iOS 6), tremendous possibilities exist, ranging from simple audio playback to object- and event-triggered audio. There are advanced filtering and reverb capabilities built in, 3D positional panning, and all available with extremely low latency. ...
Have fun at GDC!
Tuesday, March 12, 2013
Chrome's FPS Histogram
Eberhard Gräther has improved the FPS meter in Chrome. I particularly like the histogram added on the right hand side. It allows you to easily see how long your frames are taking, and if your frame rate is bouncing around between different values.
You can check it out by
Or, in about:flags you can enable it always.
It's handy to see, e.g. when you are missing some frames and oscillating between 30 and 60fps:
You can check it out by
- Opening up Chrome's developer tools (3 bar menu in upper right, Tools, Developer Tools)
- Opening up the options (gear menu in bottom right)
- Enabling 'Show FPS Meter' in the rendering section.
Or, in about:flags you can enable it always.
It's handy to see, e.g. when you are missing some frames and oscillating between 30 and 60fps:
Tuesday, October 9, 2012
State charts
Thanks to Bill Budge for pointing me to State Charts.
I've been carefully sussing out the logic of Chrome's Fullscreen controller into a finite state machine, mainly so that we can get a group to agree on exactly what we think it should be doing. Chrome can go fullscreen in numerous ways: users entering and exiting via a menu or button, web pages making the transition (e.g. when you make a video fullscreen by clicking on it in a page), extensions, a special mode on Mac, and Windows 8 Metro Snap. Most of these include asynchronous transitions, and all API initiated transitions must be serviced (even if we're 'in the middle' of another transition).
Initially the diagram resembled a flying spaghetti monster, I've been winnowing it down discarding states we can design out of the naive total possibility space. But, it's also much simpler to notate using clustering and history offered in state charts.
BTW, state charts are also included in UML state machines.
I've been carefully sussing out the logic of Chrome's Fullscreen controller into a finite state machine, mainly so that we can get a group to agree on exactly what we think it should be doing. Chrome can go fullscreen in numerous ways: users entering and exiting via a menu or button, web pages making the transition (e.g. when you make a video fullscreen by clicking on it in a page), extensions, a special mode on Mac, and Windows 8 Metro Snap. Most of these include asynchronous transitions, and all API initiated transitions must be serviced (even if we're 'in the middle' of another transition).
Initially the diagram resembled a flying spaghetti monster, I've been winnowing it down discarding states we can design out of the naive total possibility space. But, it's also much simpler to notate using clustering and history offered in state charts.
BTW, state charts are also included in UML state machines.
Tuesday, September 25, 2012
Pointer Lock (Mouse Lock) shipped in Chrome
Pointer lock has shipped with Chrome 22, it's out of Beta and releasing on time! Fancy demo first, check out Mozilla's First Person Shooter Demo.
Pointer lock offers the ability to hide the mouse cursor and use movement for controlling the camera without bumping into the edge of the screen or moving off the browser window. I've been working on it for some time, including writing the Pointer Lock specification.
It's been a long path. Things started with early prototypes and discussions of mouse lock in standards lists (and more, as it was renamed to pointer lock). Not everyone in the browser community was ready to just jump on board. It took some explaining, and still there were the those who think "Browsers are for looking at static documents, not web applications! This API is too powerful for the web." Also, people who wanted more, to the point of impracticality.
One challenge of specification was that I limited the resolution to be the same as mouse movement events without pointer lock. A direct connection to a high resolution mouse offers higher precision unaltered by an operating systems acceleration, or 'ballistic' algorithms. Sounds great, but how can this be specified, calibrated, and offered across browser vendors and operating systems? I stuck with keeping it simple and producing the exact same mouse movements received today, but without the limits of screen boarders or moving out of an application's focus area. More details in the spec FAQ.
I was pleased when David Humphrey jumped onto the Mozilla Issue. He is a professor at Seneca College and implemented Pointer Lock in Mozilla as a class project. They did great work, and eventually shipped to Firefox 14 a bit before Chrome.
One of the differences is that Firefox only allows pointer lock when pages have made an element full screen. This provides good security shelter, as Fullscreen had already been rigorously designed, implemented, and tested due to a real security threat (tricking a user to enter data into a website pretending to be another application). It was important to me to ship Chrome with non-fullscreen support on day 1, as I believe it to be a real need and wanted to discover security issues up front. The security policy in Chrome is split between the Chromium and WebKit open source projects, adding to that complexity.
On the topic of Fullscreen, there was a significant Pointer Lock API re-write in order to be as consistent as possible with the Fullscreen API. They do have many similarities, and are likely to be used at the same time by developers. However, I do lament using the Fullscreen style pointerlockchange and pointerlockerror events to notify a developer of success or failure. In my original specification I used callbacks. The advantage of callbacks is a guaranteed 1 to 1 correspondence of request and response. The events allow for cross talk between different bits code using the API, and are more fragile. On every event, code must validate if the event was due to a related request it had made (which it must keep track of).
With the help of Yuzhu Shen and others, we shipped an early version of Mouse Lock to Pepper plugins much earlier, including Native Client games. There security concerns were somewhat more relaxed as content using the API had to be published in the Chrome Web Store, as opposed to the open web. Via the store, we could have more control to remove content if it were misbehaving.
I'm looking forward to seeing new classes of applications implemented on the web using this API. ;)
Pointer lock offers the ability to hide the mouse cursor and use movement for controlling the camera without bumping into the edge of the screen or moving off the browser window. I've been working on it for some time, including writing the Pointer Lock specification.
It's been a long path. Things started with early prototypes and discussions of mouse lock in standards lists (and more, as it was renamed to pointer lock). Not everyone in the browser community was ready to just jump on board. It took some explaining, and still there were the those who think "Browsers are for looking at static documents, not web applications! This API is too powerful for the web." Also, people who wanted more, to the point of impracticality.
One challenge of specification was that I limited the resolution to be the same as mouse movement events without pointer lock. A direct connection to a high resolution mouse offers higher precision unaltered by an operating systems acceleration, or 'ballistic' algorithms. Sounds great, but how can this be specified, calibrated, and offered across browser vendors and operating systems? I stuck with keeping it simple and producing the exact same mouse movements received today, but without the limits of screen boarders or moving out of an application's focus area. More details in the spec FAQ.
I was pleased when David Humphrey jumped onto the Mozilla Issue. He is a professor at Seneca College and implemented Pointer Lock in Mozilla as a class project. They did great work, and eventually shipped to Firefox 14 a bit before Chrome.
One of the differences is that Firefox only allows pointer lock when pages have made an element full screen. This provides good security shelter, as Fullscreen had already been rigorously designed, implemented, and tested due to a real security threat (tricking a user to enter data into a website pretending to be another application). It was important to me to ship Chrome with non-fullscreen support on day 1, as I believe it to be a real need and wanted to discover security issues up front. The security policy in Chrome is split between the Chromium and WebKit open source projects, adding to that complexity.
On the topic of Fullscreen, there was a significant Pointer Lock API re-write in order to be as consistent as possible with the Fullscreen API. They do have many similarities, and are likely to be used at the same time by developers. However, I do lament using the Fullscreen style pointerlockchange and pointerlockerror events to notify a developer of success or failure. In my original specification I used callbacks. The advantage of callbacks is a guaranteed 1 to 1 correspondence of request and response. The events allow for cross talk between different bits code using the API, and are more fragile. On every event, code must validate if the event was due to a related request it had made (which it must keep track of).
With the help of Yuzhu Shen and others, we shipped an early version of Mouse Lock to Pepper plugins much earlier, including Native Client games. There security concerns were somewhat more relaxed as content using the API had to be published in the Chrome Web Store, as opposed to the open web. Via the store, we could have more control to remove content if it were misbehaving.
I'm looking forward to seeing new classes of applications implemented on the web using this API. ;)
Sunday, May 6, 2012
What!? I had kids?
I started a new blog, What!? I had kids?, because the world needed another blog. And though I love my job I've had less ideas and/or motivation to write them up on Beautiful Pixels recently. I've been spending more time planning on how to have fun with the kids.
The current article, Strollers on Steps? is proper geekery of a topic at the levels you've come to expect from Beautiful Pixels. If you're more into color, try Colored Rice, or Food Colors in the Bathtub.
Perhaps some day there will be a magical post about both children and pixels.
The current article, Strollers on Steps? is proper geekery of a topic at the levels you've come to expect from Beautiful Pixels. If you're more into color, try Colored Rice, or Food Colors in the Bathtub.
Perhaps some day there will be a magical post about both children and pixels.
Monday, March 12, 2012
Game Developers Conference 2012 presentation: The Bleeding Edge of Open Web Tech
I presented at GDC last week, and it went well. Here is a pre-recorded version of the talk. You can also check out the notes for the presentation.
Subscribe to:
Posts (Atom)




