Tuesday, January 15, 2013

GirlDevelopIt SF: Help us grow in 2013!

In my last post, I talked about how we started up GirlDevelopIt SF just 8 months ago in April, and thanks to the kindness of sponsors and the enthusiasm of volunteers, we had a great 2012. We've already started planning our 2013, with multiple events a week in January and some exciting new topics planned like Salary Negotiations and Data Modeling, and it's looking to be a great year.

Want to make it even better? Here are some ways you can help:

As an individual:

  • Be a TA: We strongly believe in having an interactive component to our classes, so that students get the chance to actually try out what they've learnt and the opportunity to ask questions that inevitably arise. As a TA, you can help them answer their questions and clarify their understanding, and as a bonus, you'll probably learn something yourself! Many of our students go on to TA the classes that they themselves took, as a way of testing and solidifying their knowledge. If you want to TA a particular class, just send a message to the teacher and let them know.

  • Teach a class: We have a vast array of topics that we want to teach our students - web development, version control, command-line, design, user experience, mobile, gaming, etc. If you feel comfortable teaching a particular topic (maybe it's one we already have curriculum, like HTML/CSS, or maybe it's a completely new one that you'd be willing to create curriculum for), please send us a message. We find the best teachers aren't necessarily the "experts", but the ones that have practical experience in the industry with the skillset, and can impart real world learnings and industry best practices to the students.

  • Run a hack night: Our students learn a lot at the workshops (we hope!) but they need to practice what they've learnt for the skills to really stick. Many of them do Codecademy or Treehouse at home, but when they get stuck, it's harder for them to find the help online. So, we like to hold casual hack nights for students to practice around others. Typically, they're at a cafe with free WiFI like Epicenter or Panera, or they can be at the office of whoever is hosting the hack night. If you'd like to host a hack night (or a "code & coffee" if it's in the morning), please send us a message.

As a company:

First, a preface: Yes, we do charge our students a small amount, but it is lower than the other similar classes in SF, and is designed to be just enough to make GDI sustainable, but not necessarily profitable. When companies sponsor us, that means that we can support more students and make sure our teachers are adequately compensated for the vast amount of time they put into teaching. We feature our sponsors on the Meetup page and also thank them in the event descriptions, and of course, at the event itself.

  • Volunteer your space: We've had a lot of great spaces for our workshops, but we can always use more - we don't want to exhaust our current spaces and hosts. We look for spaces that have tables with chairs where students can sit with other students, but also with enough room for TAs to walk around. Usually, we host classes around the SOMA area in SF, but we're starting to explore classes in South Bay and Oakland. Our classes are either on weekday evenings or on weekends, and sometimes stretch over multiple days. If you have a space in your office that you'd like to volunteer for a class or two, please send us a message.

  • Sponsor our snacks: Our classes require a lot of brainpower - students learning programming for the very first time! - so we like to keep our students fueled with food when we have the funds to do it. For evening workshops, that means a light dinner and for weekend workshops, it's usually lunch and snacks. If you'd like to sponsor the food for an upcoming workshop, please send us a message.

  • Donate to our scholarship fund: Many of our students are learning programming because they are in a low-pay position now and trying to transition over to development, so money is tight. We encourage those students to apply for a GDI SF scholarship, where they describe what they want to learn and how it will benefit them, and then we give them a free entrance to the class. Right now, the teachers have been giving up some of their own compensation to make those scholarships possible, but we can't keep doing that forever since our teachers need to support themselves as well. So, we are starting an official scholarship fund for the GirlDevelopIt SF chapter, and we would love for companies to contribute to that fund. When you sponsor a student, we will let them know who the sponsorship came from, and we will thank you on Meetup and at the event. If you're interested in sponsoring, please fill out this form and specify 'San Francisco' as the recipient chapter.

And hey, even if you can't help in any of those ways, you can help us by spreading the word. Let your female friends and family know about GirlDevelopIt SF and encourage them to take a class or two. Who knows, they may turn out to be the next great developer!

Saturday, January 5, 2013

GirlDevelopIt SF: Thanks for a great 2012!

Back in April, I had the good fortune of discovering that the GirlDevelopIt organization was looking to create a San Francisco chapter, and they were happy to let me lead that up. We started slow, with an HTML/CSS workshop, then a JavaScript workshop, and then suddenly, we were holding workshops every week, with new TAs helping out, new topics being explored, and new friendships being formed at each of them. It's been an amazing 7 months, and I want to start this post by thanking everyone who's helped.

First, thank you to the companies (and the great people from them) that lent us their space and sponsored our fuel:

Next, thank you to the teachers that made learning possible and spent hours working on curriculum:

  • Liz Howard, who started off TAing, then teaching, then writing a whole NodeJS 2-day class, and now she's helping to organize workshops for other teachers as well.
  • Carina Zona, who put together an incredibly informative and interactive command-line Git workshop.
  • Gwen Brinsmead and Sheba Najmi, who worked together to create an all-day UI/UX workshop.
  • Michell Wetzler, who started off as a student and went on to create an Analytics overview workshop, complete with real data and data analysis.

And thank you to the TAs- many of whom started off as students - like Sharon Wong, Tripta Gupta, Regina Walton, Eva Zamudio, Sarah Adams, and everyone else who spent their free time helping our students learn.

In putting together those lists, I've realized just how many people have helped us get to where we are today. Here's where we are, in numbers:

  • 796 members
  • 20 workshops
  • 7 hack nights

But, numbers, schnumbers. What really matters is the learning and the community that's forming around learning, and that's best shown in pictures and tweets:

So, there you have it: 2012 was a great year for GDI SF, and it was a group effort. I'm looking forward to an even better 2013, and I'll be writing on my thoughts for that in my next post.

Friday, January 4, 2013

Xtreme Makeover: Legacy Codebase Edition

At Coursera, we have two codebases that power our user-facing experience - the one behind www.coursera.org, where students browse and enroll for courses, and the one behind class.coursera.org, where students actually take classes. The latter is our oldest codebase, and is based on the code that powered the first version of Coursera (before we even had a name or a company), the machine learning class. It's built on PHP/mySQL and a custom routing/templating/ORM framework.

In the beginning, it probably had very little CSS and JavaScript, so the creators understandably didn't put thought into how to write the CSS and JS in a way that would be maintainable and scalable to a large codebase and team. Well, 50 classes and countless features later, it became a hodge-podge of PHP, HTML, CSS, and JS all entangled together with no conventions in sight.

But, it worked — so we didn't want to touch it. When we touch it, we risk introducing bugs or un-introducing "features" that we were unknowingly supporting before, and when students grades and instructors happiness are on the line, we opt for doing the safe thing.

We couldn't leave it unchanged forever, though. We had many usabilty issues (meaningless icons everywhere, hard-to-navigate menus) and we also wanted to improve the university branding. So our designer proposed a redesign of the user-facing interface, and when I set about implementing that redesign in the codebase, I realized that I could not bring myself to do the user-facing improvements without making some developer-facing improvements too.

Why? Well, as a developer myself, I find it frustrating to work in an environment that doesn't use modern tools (like CSS pre-processors) and best practices (like avoiding global variables). And, as I know we will be bringing on more developers soon, I want them to be surrounded by good examples of what our codebase should look like, and not think "Oh, I guess this is just how we do things around here." I also want them to enjoy working in any of our codebases and expect that they can apply the same best practices to all of them.

So, I set about on the behind-the-scenes redesign, and thanks to help from the rest of the frontend team, we were able to make a lot of significant improvements. Here's a round up:

JS Code quality:

  • We moved all of the JavaScript into separate files (much of it was in PHP templates, and some of it was even PHP-generated, ick).
  • We ran JSHint over all of our JavaScript files (not third party libraries) and fixed any issues that came up. (We had to guess with situations like " == 0" vs " === 0" what it was they actually wanted - which is why developers should use JSHint from the beginning!).
  • We stopped using third party JavaScript libraries that were adding unnecessary bloat and were difficult to customize - like fancybox, which we replaced with our own much smaller modal library.

JS Performance:

  • We made sure all of our JavaScript executed after the document ready event.
  • We moved all of the <script> tags into the bottom of the page.
  • We wrote a build task to compress all of the JS files.
  • We wrote a build task to create a single compressed file of all the JS libraries that are used across most of the pages.

CSS Code Quality:

  • We stopped using CSS class names that were short and ambiguous, like "title", and instead moved to prefixed, explicit names, like "css-forum-thread-title". We also only use IDs when needed for accessibility reasons, and instead prefer classes everywhere.
  • We ported all of our CSS to Stylus. That means we can now take advantage of variables (like the URLs for our assets, which we can now serve off CloudFront), automatic vendor prefix generation (which will improve our cross-browser support), and extending (which means I can extend Bootstrap classes and avoid directly using them in our HTML).
  • We started using box-sizing:border-box, which makes our height and padding calculations easier, but did require overriding the CSS for a few third party libraries.

CSS Performance:

  • We created separate Stylus files for each functional area of the site, and we have one file that imports all of them, so that we can work in small files but still only serve one big file.
  • We wrote a build task that compresses the generated CSS, so it's not actually that big.

226 commits later...! Now that we have our codebase in a better state, we can enforce our conventions on any changes that developers make in the future (via code reviews), and maybe future developers won't even realize that it was ever our legacy codebase. Maybe. :-)

Wednesday, January 2, 2013

Getting Kids into Programming

A local father asked for advice on what laptop he should get for his 7 year old daughter, who he wants to get interested in programming. That got me thinking about getting kids interested in programming generally.

Of course, I was a kid once, so I started by thinking about what got me into it. I first got interested in programming because it helped me solve a problem (I needed a mother's day card and we lived too far away from any physical stores, so I learnt to program a digital one) and I got even more excited about it because it helped me be creative in new ways (e.g. I could create digital versions of the games I would play in real life with my friends). So, at least for me, it was less about getting interested in programming itself and more about discovering what programming would enable me to do. Programming was not the goal, it was the way to get there. Now, after many years of programming, I am interested in the meta aspects of programming itself, like what makes for a good language and clean code, but I still value the output of my program more than the program itself.

So, that's the first thing I'd advise for parents who want to get their kids into programming: don't just tell them about programming, also expose them to all the crazy things you can do with programming, and the way that your programs can be used by anyone in the world. Maybe your kid isn't into robots or 3rd printers, but when you tell them they can make a game where their favorite cartoon character is the lead, that's when it clicks for them.

But besides desire, they also need the tools and the skills. I've written before about the different ways that aspiring programmers can learn online and in SF, but I was curious to find out what the most kid-friendly resources are out there. So I turned to everyone on Twitter for their opinions. Here's what they suggested:

Programming Languages & Environments

Computer Science Lessons

Books & Blogs

Robotics & Electronics


Jen Myers asked her Twitter feed for advice on game programming resources for her daughter, so I gathered these links from their answers:

  • MineCraft: No programming, but the building mechanics involve logic.
  • Little Big Planet 2: the authoring environment includes AI programming.
  • Adventure Games Studio: "Minimal programming, lots of graphicky goodness."
  • GameSalad: Aimed for non-coding, but coding is possible for more advanced users.

Now, I'm not a parent myself and haven't had any first-hand experience with exposing kids to programming. If you have, or if you're young enough to remember your own first exposure, let me know in the comments!