A few years ago I visited San Francisco for the first time. After soaking up the atmosphere and exploring the city, I realized that I wanted to move there permanently. Although by no means easy, six months ago I made that happen. Today as I look back, I realize that moving to this city was one of the best decisions I've ever made.
I used to live in London and, while I did like the city, many things pale in comparison to SF. For example, take my commute. It used to take me an hour each way from home to work on a cramped and stuffy underground train. Contrast that to San Francisco, where I literally walk two blocks in sunshine every morning to work. This sort of commute isn't unusual, as SF is a particularly small and walkable city.
Although the weather in San Francisco seems to get a bad rap by the locals, it's actually extremely good. You can pretty much wear the same clothes the entire year round, and the climate is generally warm and sunny. Certainly better than England.
The opportunities out here in terms of technology are unsurpassed. Some of the most interesting jobs, challenges and possibilities. The streets are alive with talk of startups, tech and investment.
You'll also find some of the best people in the industry out here. People who you've read about, used their libraries or seen present at conferences. These people are now your colleagues, there for you to bounce ideas off and learn from.
I've also found that most startups are quite willing to sponsor H1Bs, as demonstrated by the huge amount of foreign talent in the city. Your background doesn't matter, just your potential.
Last, but not least, is the quality of life. Not only are the salaries good, but the perks are excellent too. Most startups cater breakfast lunch and dinner, have flexible vacation policies (even unlimited) and awesome work places. Airbnb have re-created some of their top ten properties inside their offices, GitHub have air-hockey tables and a war room whilst Monkey Inferno's offices look like an incredible steam-punk lair.
Outside the office you have the whole of San Francisco to explore, whether it's checking out a different restaurent every evening, or lazying away an afternoon in Dolores park. The city is so diverse and cultural there's something for everyone.
So, if you're a developer in Europe (or elsewhere) looking for something new, then I urge you to consider San Francisco. If your experiences are anything like mine, you'll love the place.
Sebastian Thrun, a Stanford Professor, Google X founder (self driving cars, Google Glass, etc), and CEO of Udacity recently did a AMA on Reddit. He had some very interesting things to say about what drives him:
The thing that worked best for me is to be relentlessly driven by the desire to solve problems I really care about, and to be open to changing my mind along the way when I learn new things. A lot of successful entrepreneurs do this. They pick a vision of something that's important, and work as hard as they can to make it happen. Act as if you already know that you won't fail. What would you do if you knew that you wouldn't fail?
On rules:
And have a healthy disregard for rules. There are way too many rules, and they usually have only one effect: to slow down those how are active.
And finally, Sebastian talks about education:
I am a strong believer in learning by doing. I believe you can't lose weight by watching someone else exercise. It's really hard to learn by watching someone else solve problems (and lecture about it).
Currently, color pickers on the web use CSS gradients instead of canvas. The trouble with this approach is that the picker has to be a fixed size. Any change in the size of the color picker means a change in your calculations.
Furthermore, the colors you get from such pickers are approximates. They're based on a calculation involving your mouse coordinates, the size of the picker and HSL.
By using HTML5 Canvas, we can get extract absolute color values, so they're always spot on. Canvas was built for this sort of application, and is the ideal tool for the job.
When I was building Stylo I needed a top notch color picker, such as Photoshop's, but couldn't find one. I ended up writing my own, called ColorCanvas, which I'm happy to announce I'm open sourcing today.
I've split up the CoffeeScript code into separate modules, which is compiled down by Sprockets into two files, colorcanvas.js and colorcanvas.input.js. The latter is a shim for color inputs.
Usage
Include the two scripts, lib/colorcanvas.js and lib/colorcanvas.input.js inside your page.
I learn by setting projects for myself, and so a few months ago I decided to create an app called Stylo. The idea was to let people design basic web apps using a Fireworks-like interface, ultimately exporting the finished design as CSS.
I'd always admired complex apps like 280 Slides, so was excited to be building something with similar problems. I started writing the app with CoffeeScript, Spine and Sprockets, my technologies of choice. A month later, after working in the evenings and weekends, I had a basic prototype which you can see a demo of here(webkit only).
Have a play around with the app. You can draw shapes, apply shadows, background gradients and add a variety of other styles. Double click on an element to add text, and use keyboard shortcuts, such as command z to undo. In the latest versions of Chrome, you can even copy elements and paste their CSS into a text editor.
Now the time has come to open source Stylo, and the code should provide good examples of how to achieve the following:
The part of Stylo I'm most proud of is the encapsulation. I believe that decoupling and abstracting your programs is the secret to good code, and that's what I've tried to achieve with Stylo. Each behavior is split into its own CommonJS module, while each part of the right hand inspector is a different controller.
I've written a custom guard task to compile the CoffeeScript down to one file whenever anything changes. Stylo is also using my CommonJS extension to Sprockets, giving us explicit requires and exports.
One thing I particularly enjoyed learning about was color theory, required for making the canvas color picker. As a self-taught programmer, color theory is one of those things I hadn't had the chance to be immersed in yet, and learning about HSL and HSV was fascinating. I'll be releasing the color picker as a separate library soon.
The other aspect I loved writing was the PEG CSS3 parser. PEG.js is an extraordinarily simple yet powerful tool, allowing you to write complex parsers by combining basic constructs.
So checkout the source code and have a rummage around. The best way to become a writer is to read other books, and programming is no different. I'm hoping Stylo will become a useful resource for programmers creating similar things.
Traditionally browsers haven't been able to make raw socket requests to arbitrary endpoints, mostly due to security concerns. Although the majority of browsers now have WebSockets, the caveat is that the server needs to have specific support for the WebSocket handshake. This has limited the type of protocols and APIs that the browser could communicate with.
However, Chrome's changing all of that. Canary now has support for raw TCP and UDP sockets in its 'experimental' APIs. These features are only available for extensions and, although documented, are hidden for the moment. Having said that, some developers are already creating interesting projects using it, such as this IRC client.
To access this API, you'll need to enable the experimental flag in your extension's manifest. Using sockets is pretty straightforward, for example:
Although the API is still under flux, already I can see some amazing potential for it, especially when it comes to P2P. A few years ago I did a bit of work concerning firewall tunneling with TCP, which should now be possible in Chrome. This API should lead itself to some interesting applications, like P2P games, collaboration and data transfer.
Incidentally the name Canary comes from the canary that coal miners used to take down the mines. Gases like carbon monoxide used to kill the bird before affecting the miners, giving them enough warning to escape.
One weekend a few months ago, I decided to try my hand at creating a Facebook app. The premise was simple: create a game where you could prepare for the inevitable Zombie Apocalypse by choosing a team from your friends, specifying how exactly they'd be useful in the event of certain doom.
Heroku has excellent Facebook integration, and it wasn't long before I had a basic app up and running. Part of the game involves a Facebook friend selector, and after searching around for some existing libraries, I decided to write my own one using Spine.
The picker allows you to toggle the selection of multiple friends, and fires events whenever the selection changes. You can even filter by name. It's a good example of how simply this sort of behavior can be represented with client-side MVC.
When it comes to self-development, programmers can often be illogical.
They spend thousands on conferences, hundreds on books and many hours coding late into the night learning about exciting new technologies. They do all of this to try and improve their brain's ability to program. However, they manage to neglect one of the most significant factors to their brain's performance: exercise.
Our bodies are not just some vehicle to get our brains between meetings and keyboards. Like it or not, our brains are deeply tied to the performance of our bodies. This sedentary lifestyle we've become accustomed to has severe implications on our performance as programmers.
I run for 15 minutes every day, and swim every other day. This isn't much at all, but it works for me, and keeps me in a fit and healthy shape. I feel so good after taking exercise. It lifts my spirits, and I can think much more clearly. It's a crucial part of my life.
So, when you're making that resolution to learn a new language or technology, remember that's only part of the puzzle. By taking time to be healthy and take exercise, I can assure you your brain will reap the rewards.
I've been interviewing engineers for a while now, and it seems the more interviews I do, the more I realize how many my initial assumptions about hiring were wrong.
For example, take resumes. Initially, before every interview I'd carefully review resumes. I'd look at candidate's past experience, at their skills and interests, and I'd take it all into account. However, over time I've come to a conclusion: resumes are dangerous.
Often, when I'm reading a resume I'm thinking: “This guy is great, look at all this experience. He clearly knows Ruby and JavaScript like the back of his hand, and this interview is just going to be a formality”. Then, come the interview, the guy can barely code, much less know the ins and outs of variable scope. It turns out there is very little correlation between how good a resume is, and how the interview actually pans out.
At best resumes give you some ideas on follow up questions to ask during the actual interview. At worst they give you a false sense of security that you actually know something about the candidate's abilities.
Well, you say, what about sourcing? Surely resumes are the only way to deal with the volume of job requests some companies get? I honestly think that, at least for engineers, you can solve this problem with practical coding challenges. These can sort most of the wheat from the chaff and, as well as being reviewed by an engineer, they can serve as a point of discussion during the interview.
The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code. Doing open source is not a be-all and end-all by any means, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly.
As I'm talking to candidates we run through some of their code, and I will ask about the reasons behind the decisions they've made. The interviews are spent discussing code, and writing code. It's what we programmers do day in, day out. It's the one things that matters.
Above all, I try to hire people who I'd want to pair with tomorrow. People who are better than me, and people who I can learn from.
Getting hiring right is the most fundament part to any company. Valve put it well in their handbook:
Hiring well is the most important thing in the universe. Nothing else comes close. It’s more important than breathing. Here are some questions we always ask ourselves when evaluating candidates:
Would I want this person to be my boss?
Would I learn a significant amount from him or her?
What if this person went to work for our competition?
So my message is evaluate the candidate, not their resume. During the interview focus on code that tackles common problems in your organization. Above all, hire people better than you.
The opinions here are mine, and not necessarily those of my employer, or even mine tomorrow
The library allows you to apply basic styles, such as bold and italic to a contenteditable HTML element. You can then read the HTML straight from that element. It's written in CoffeeScript in a MVC 'controller' style and its only dependency is jQuery.
Content editable is a fickle beast, with an archaic API and poorly documented functionality. However in modern browsers, it does produce good HTML and is certainly a viable WYSIWYG solution.
I find the secret to creating WYSIWYGs (or software in general for that matter), is to keep things as simple as possible. That said, this library could certainly improve in a number of areas. For example:
Have a way of overriding the alert() notices
Show selected styles (this may be harder to do than I first anticipated)
Cross-browser keyboard shortcuts
In the spirit of open source fortnight I'm releasing it to the community. I'm excited to see where it goes next.
CommonJS modules are a way of encapsulating and packaging up JavaScript files to ensure they're name-spaced and loosely coupled, a crucial aspect to ensuring JavaScript code quality and maintainability.
Traditional JavaScript module management is very manual, often using a single namespace for the whole app. In my opinion this doesn't go far enough - scripts end up being tightly coupled, there are accidental globals and code quickly descendes into spagetti.
CommonJS modules address all these problems by adding explicit requiring and exporting, allowing you to quickly see inter-dependencies between files.
The module format consists of two things:
Loading in files using require(),
Explicitly exposing properties using module.exports.
However, integrating a JavaScript module workflow into a framework like Rails is not a trivial task. Well, until now…
I've been working with Josh Peek to integrate CommonJS modules into the library behind Rail's asset pipelining, Sprockets. The result is the gem sprockets-commonjs. Simply add the gem to your Gemfile, and you're good to go.
To specify that a script should be using CommonJS, just rename it from myscript.js to myscript.module.js. Any JavaScript or CoffeeScript files with module in the filename will be automatically wrapped up as CommonJS modules, and can subsequently use the require and export API.
It's worth noting that modules won't be evaluated on page load, only when they're first required. Subsequent calls to require() return a cached representation of whatever the module exported.
The gem doesn't do any static analysis of the AST, so you may have to double up require calls. However I think the average use case is using require_tree to concatenate files, so it won't be too much of a problem.
Having some sort of packaging and dependency system is crucial to modern and professional JavaScript development; CommonJS modules are a great solution. Perhaps if this gets traction, we'll see it in Sprockets core.
