Sunday, May 22, 2016

Recent Presentation: Understanding JavaScript in the Browser

I recently gave a short presentation to mostly non-Web developers, on what goes into the soup of the browser platform. I began by covering the many parties involved in standards - the W3C, WhatWG, TC39 committee, and others. Then, I introduced some of the other characters, like each browser vendor's rendering engine and JavaScript engine. It's a lot to keep track of, even just to keep a loose eye on things, not to mention the day-to-day effort (and fun discovery) of the many libraries and frameworks available to solve a problem. tldr - there are a lot of cooks in the Web kitchen.

I tried to highlight the great community tools like or, and later demonstrated a few features of the developer tools, and the idea of the browser as the app platform and the IDE. (the JavaScript profiler, logging and analyzing xhr requests, the timeline, ol' trusty console) I also showed the final example from a great talk, What the heck is the event loop anyway?

Finally, we looked at some of the idiosyncrasies of the language. After talking about some of the basic structures in the language (objects, functions, less-than-intuitive rules around 'this'), I posted this example, to a room of very experienced (but mostly non-JavaScript) developers, and there were some pretty confused looks on people's faces. However, when we went through line by line, everyone immediately understood. And shook their heads in disbelief.

The slides can be viewed here.

Friday, September 25, 2015

September in (and out of) iOS

This month my intention was to continue the Udacity Nanodegree program. I think the learn-by-doing approach it takes is great, and usually works well for me. However, in a fit of frustration -- wrestling with NSRegularExpression for something that would be trivial in many other languages and forgetting about the .rangeOfString method -- I began to reflect on the overall experience and my approach to learning at this point. What were really my goals in becoming a better iOS programmer? I'm familiar with enough of the APIs and resources for learning, can wade through the docs if necessary, have built some toy apps, etc. So why the urgency to add more to the never-ending list of things to keep up with (in code, business and law)? What other stuff would get put on the backburner for a while? 

Well, part of the problem is that the other stuff is never really on the backburner. I spend my days in Ruby and the browser, and absolutely love it, and my subway rides reading articles and keeping up with developments in the Rails world. People have their reasons for not using or liking Ruby or Rails, but the joy of coding in Ruby coupled with the productivity boost of Rails still makes it my go-to. If/when I need to deal with millions of concurrent connections and the other performance problems at crazy scale that many see as a drawback to using Rails, or the speed of the language is more important than my productivity with it, I'll reconsider. I've checked out many of those other tools - just enough to know where to start looking when a problem presents itself, and to improve my existing approaches (hopefully).

And so back to iOS, and really any new language, framework or library. Yesterday I quit the Nanodegree program since I didn't feel like it was materially pushing me forward as a programmer generally, or an iOS programmer specifically. Sure, the exercises are good and you need a guide beyond just the docs, Stack Overflow and Google. At the same time, I'd already done a lot of that stuff and know the areas I need to learn or improve. Plus, at $200/month for something they give away for free, it just didn't feel worthwhile to me. (No offense to those doing it and making the most of it, or the company for expecting to get paid for their work.) For those shifting careers or just starting out, go for it. But having an iOS Nanodegree isn't going to make or break my resume at this point.

While much folk wisdom (or PR spin) about online learning suggests that an extra credential and paying a bit gives you some skin in the game, and maybe it works for some people, it really just made it feel like work to me. I've got enough of that (thankfully). This was supposed to be a fun hobby. With Ruby and Javascript, even outside of work, it's still *fun*. Maybe I'm just too hooked on the instant feedback cycle (and not waiting for the iOS Simulator or XCode to catch up) or productive enough to look past the frustrations that occur, or just impatient in getting a fast enough workflow going with iOS. That's not to say I'm completely giving it up. Just not spreading my free time too thin for no good reason or clear personal or professional benefit. I could spend that time on core CS concepts, reading (gasp!) non-tech books, or writing more to avoid awkward sentence constructions like these last two. 

So I'll end with this. Before diving into something new - clearly state your goals, and resist any OCD/stereotypical coder urges to overwhelm yourself and burn out on it. The mental energy of frustration just isn't worth your time. Is it for a job? Is it for fun? Is it for a new perspective? Just to stretch your brain? Learn enough to be dangerous, if the opportunity ever presents itself. For now, I need to refocus on relaxing, reviewing years of Ruby and Rails code and notes, and working with a few new Javascript libraries I'll need at my new job. After a great 2 years of growth at Simon & Schuster, I'll be starting at Bloomberg next month. Onward... 

Monday, August 31, 2015

August in iOS

Last year I began working with iOS right around the time Swift came out. While I'm glad to have some familiarity with Objective C, Swift is much more comfortable (coming from working mostly in Ruby and Javascript). I soon dove in! While this blog's been silent in 2015 so far, I've got tons of draft posts sitting around that need to see the light of day.

One new commitment I've made is to start posting a monthly rundown of tips, tricks and adventures as I get back into iOS development, similar to the TMIL (This Month I Learned) series I posted in 2014. Zooming back to last year when I wanted to start learning another programming ecosystem beyond the web world I know and love, here are a few of the resources that helped me get started (and very much continue to help) with the world of iOS:

Zooming forward to a few months ago, I decided that this summer I'd get back into it. The Brooklyn Swift meetups have been an awesome source of keeping up, and it's exciting to follow the language as it develops. Among other technical tidbits, one exciting note from these meetups is the emerging open source ecosystem around iOS development. As was widely reported after the announcement at WWDC 2015, Swift itself will soon be open-sourced. While the language hasn't moved into the top GitHub languages just yet, there are plenty of repo's gaining popularity and it's on its way up in the TIOBE index (as of August 2015). Notably, more companies are following the lead of groups like Artsy and open sourcing their entire production apps. (e.g. Gilt) As noted at an earlier meetup, hopefully the emerging Swift community can build on the successful lessons of others.

Udacity Nanodegree

With the above in mind, and a million ideas, books and tutorials but never enough time, I thought I should add more to my learning load! So, I've enrolled in Udacity's iOS Developer Nanodegree program to help solidify my understanding and work on more significant apps to showcase. (My first project in the program, a work in progress called Pitch Perfect, can be found on my GitHub here.)

While there's the essential work of design, writing good algorithms and such, in web and backend development I've found that a prerequisite to getting anything done (and often most of the day-to-day work of being efficient) is knowing your environment and tools well. For me, that means keyboard shortcuts. Fortunately, they're laid out in a pretty consistent way in XCode.
  • Navigator - use cmd-1, cmd-2, etc to jump between different the File, Debug, Test and other panels 
  • Utilities - use cmd-option-1, cmd-option-2, etc to jump between the Attributes, Size and other utility inspectors 
  • Jumping to a file - cmd-shift-O (the letter O, i.e. open) to open a file or jump to a symbol 
  • Getting around the menus - this is a must-use item found in most (all?) OS X apps, cmd-shift-? to open an application's Help search index, and using the arrow keys to select the item. In XCode, I've found this particularly helpful when adding constraints, such as 'pin' (rather than the tedium of using the mouse to select items from the Editor->Pin menu)
You can find a much more detailed guide at

So far, the Pitch Perfect app has been a good reminder of the value of adding constraints to UI elements as you go (at least, that works better for me). Also, it's been fun playing around with the audio APIs. The first project fetches a local file and plays it back slow or fast. Though not part of the course, I'd like to next fetch a file from the web and play it back... But that's enough for tonight! See you next month!

Wednesday, December 31, 2014

December #TMIL

This month I learned that this year I learned to keep a New Year's resolution alive, that documenting everything is usually a good idea, and most important, to relax and have fun during the holidays.

Happy 2015!

NovEmber #TMIL

Over the summer, I decided it was time to learn a client-side Javascript framework. I chose to start with Ember, mostly because it felt more like Rails and I kept hearing about the combination of an Ember app with a Rails backend. While I usually jump right in and try to build something, I had enough other coding side projects going on at the time (and it was summer!), so I joined the Ember Weekly mailing list, attended a few of the NYC meetups and kept a loose eye on things... which have been moving along quickly! By November, it was time for another look.