About an year ago, I started a new project in a stealth startup. Aside from the fact that it would provide currency that could then be exchanged for goods and services, including food for me and my family, one of the biggest reasons I took the job was that I was going to get to learn a lot of new things.

Now, over a year later I can say that learn I did. And I caught myself thinking of what I wish I knew back in the beginning. The following list is probably not exaustive but it’s a good example of what I’ve learned. These are mostly things I’ve dealt with on rewrites, redesigns, or are things that I still struggle with.

JavaScript is magical and that’s not good

I already had a general idea of the issues with JavaScript, but I really failed to grasp how magical JavaScript is. And when I say magical, I don’t mean the good kind that conjures fluffy rabbits inside hats. I mean evil dark magic that would make Voldermort cry. I mean magic in the sense of a language that never seems to behave just the way you think it should.

I wish I knew back then how much work I would need to spend to do what seemed at first to be basic, simple stuff. I often caught myself fighting JavaScript instead of working with it.

AngularJS is awesome but the web works on jQuery

I think AngularJS is fantastic. Really I do. I am not at all sorry for having picked it for the project. I think it’s well-designed and logical and yes, it is magical sometimes, but often in a good way.

But…

I wish I knew back then how much work I would have to do making AngularJS and jQuery work together, and you have to make them work together because honestly, unless you want to reinvent the wheel for every little thing, you will end up using jQuery components. We will revisit that later.

So yeah, AngularJS is great but for it to work properly, you have to do things the Angular way and that means turning a lot of jQuery components into AngularJS directives. Once you get the hang of it, it gets much easier and faster but there’s a bit of a learning curve there.

asynchronously have You think undefined

You have to think asynchronously to work with JavaScript. For a while, it was painful and it surely added to my perception of JavaScript being magical. JavaScript is entirely asynchronous and works like a turn-based game. This can be annoying at first and I caught myself working around this in all kinds of wrong ways. I wish I knew back then what I know now so I’d embrace the async’ness from the get-go. Things would be so much easier.

Large single-page web applications rock but…

Picking AngularJS as my framework of choice, I designed the web client for the project to be almost purely implemented inside the browser in JavaScript as a single-page app. This has some very good consequences, chief among them responsiveness. The application feels fast. Sure it has to download a lot of JavaScript up front, but (1) this is not nearly as bad as I expected it to be and (2) with caching this is done once and that’s it. Switching from a “page” to the other is essentially instantaneous as it’s all pre-loaded AJAX parts of the page. The server actually has to do very little.

But now, if I could start all over again, I would not do it like one big single-page app. It’s just too much JavaScript code and I’ve already established how I feel about that. I never have the feel that things are stable, even though there are integration tests passing all the time. I can’t explain it but it all feels like a big house of cards, like it’s all going to come tumbling down all of a sudden. I simply don’t trust the code. I would much rather use JavaScript sparingly, to do some things but surely not all. I have been fixing this slowly by isolating some parts of the application as separate, but to do it for everything would require a rewrite that I don’t have the time for right now.

Trust the Go standard lib

As an alternative title, “don’t go too fancy with Go.” It’s not that I didn’t trust it, but I sure did try things that honestly didn’t make sense. I am looking right at you, Martini, I had to do a lot of work to get rid of you.

As it turns out, the standard library is really good. And for the things that are not in the standard lib, there are packages that are really well done and work with the standard lib, not against it. I love you, Gorilla Toolkit.

Never assume jQuery components will do what you need

The current state of JavaScript is such that there is literally—in the figurative sense—an infinite number of components out there ready for you to use. As far as I can tell, anything I could ever possibly conceive of has already done and hosted on Github. There are time pickers, calendars, and even a business hours widget display ready for you.

And yet.

I am yet to find one single component that is flexible enough to work for my needs without extensive modifications. And it’s not like I have especially unique needs. I am talking about things that are to the best of my knowledge pretty basic. But no, they never do that one tiny thing you need them to and I spend a lot of time implementing features I need.

Bootstrap responsiveness

For a long time I misunderstood how Bootstrap deals with responsive design. Trusting Bootstrap’s system is a must. It works very well. I wish I understood it better back then. It would have saved me a lot of time. And related:

Don’t use an existing Bootstrap theme

It’s just not worth it. Back then, we didn’t have a designer and we wanted to have our minimum viable product as quickly as possible so we went after something ready. We chose a premium theme that is very popular. It was good looking and seemed really nice. Boy do I wish I had a time machine now.

We are now stuck with it. Switching to something else is something we will have to do eventually and let me tell you: it will be painful. These themes change everything and not in a way that we could simply switch themes painlessly. It permeates everything.

Think of touchscreens from the beginning

Oh boy. You do a lot of nice stuff and then one day you try it on a tablet and nothing works just as your co-founder tells you that your first customer will use the app exclusively on tablets. Then you start panicking and sobbing and crying and running for help. You then find out about the hack that is jQueryUI Touch Punch and although it fixes some of the problems it creates new ones and then there’s jQuery Mobile which is OMG fantastic except lo and behold it doesn’t play well together with AngularJS. And then you find some projects on Github trying to get jQuery Mobile to work alongside with AngularJS but they’re no longer maintained and won’t really work that well and…

Well, it would be best to think about touch support from the get go.

Stop worrying about the size of your JavaScript

Or actually, do worry, but for the right reasons. One of the things I learned is that the web is full of outdated and/or otherwise uninformed advice.

Stop laughing.

Yes, it’s obvious, but still. With little experience with web frontend programming, I used to worry about the size of my JavaScript code. And the web doesn’t really help. Search a bit and you will find people telling you how horrendous it would be to download 100Kb of JavaScript and how the only way to save your customers is to access files from popular CDNs.

It turns out that’s kind of like cargo cult programming. It’s just a bunch of people repeating something they heard somewhere. Things change. We measured them.

Concatenating and minifying our files and serving them gzip’d and with aggressive caching is actually faster. Even concatenation is about to become irrelevant now that SPDY is becoming more common (IE11 now supports SPDY3 and the upcoming versions of Safari for OSX and iOS will as well.)

The first access to our app downloads almost 1MB of JavaScript code and CSS files. It sounds horrible but it’s really fast, even on bad 3G with with defer and async. Speaking of which.

Most of the advice repeated as a mantra on the web is from before browser support for <script defer> and <script async> was widespread.

I think that’s about it. Now all I need is a time machine.

On the way to the Moon, the Apollo crew and ground control needed precise information about the position, speed, and acceleration of the stack. Getting that information was a feat of engineering involving very clever solutions that deserve a post of their own, but the easiest piece of the puzzle was the position.

To figure out where exactly the Apollo was at any given moment, the crew used a guidance computer designed by the MIT along with a sextant, not much unlike the ones used for centuries by sea captains.

The CM pilot would pick a specific star (or planet sometimes) that could be placed within view of the sextant optics, he’d then align the sextant viewport with the chosen star, and then tell the guidance computer to calculate the position by telling it which star he had just pointed the sextant to.

The astronauts had a table of stars they could use, each accompanied by an octal code that could be fed to the computer. In this list, along with well-known stars—such as Sirius (15), Rigel (12), and the Sun (46)—were three oddly named stars.

(Credit: Nasa)

While helping with the development of this system, the crew of Apollo I decided to have a little fun and added references to themselves by changing the names of some stars to parts of their own names spelled backwards:

• Navi (03) for Gus Grisson’s middle name (Ivan)
• Regor (17) for Roger Chaffee
• Dnoces (20) for Edward White II.

In reality, Navi was γ Cassiopeiae, Regor was γ Velorum, and Dnoces was ι Ursae Majoris.

After the crew lost their lives in a tragic fire—the first fallen in the American space manned program—the people at NASA kept those names in all their documentation and literature.

The recently approved C++11 standard brings a lot of welcome changes to C++ that modernize the language a little bit. Among the many changes, we find that containers have received some special love.

Initialization

C++ was long behind modern languages when it came to initializing containers. While you could do

[cpp]int a[] = {1, 2, 3};[/cpp]

for simple arrays, things tended to get more verbose for more complex containers:

[cpp] vector v; v.push_back(“One”); v.push_back(“Two”); v.push_back(“Three”); [/cpp]

C++11 has introduced an easier, simpler way to initialize this:

[cpp] vector v = {“One”, “Two”, “Three”}; [/cpp]

The effects of the changes are even better for things like map s, which could get cumbersome quickly:

[cpp] map<string, vector > m; vector v1; v1.push_back(“A”); v1.push_back(“B”); v1.push_back(“C”);

vector v2; v2.push_back(“A”); v2.push_back(“B”); v2.push_back(“C”);

m[“One”] = v1; m[“Two”] = v2; [/cpp]

This can now be expressed as:

[cpp] map<string, vector> m = One,

                             {"Two", {"Z", "Y", "X"}}};

[/cpp]

Much simpler and in line with most modern languages. As an aside, there’s another change in C++11 that would be easy to miss in the code above. The declaration

[cpp]map<string, vector> m;[/cpp]

was illegal until now due to » always being evaluated to the right-shift operator; a space would always be required, like

[cpp]map<string, vector > m[/cpp]

No longer the case.

Iterating

Iterating through containers was also inconvenient. Iterating the simple vector v above:

[cpp] for (vector::iterator i = v.begin();

 i != v.end(); i++)
cout << i << endl;[/cpp]

Modern languages have long had some foreach equivalent that allowed us easier ways to iterate through these structures without having to explicitly worry about iterators types. C++11 is finally catching up:

[cpp] for (string s : v)

cout << s << endl;

[/cpp]

As well, C++11 brings in a new keyword, auto, that will evaluate to a type in compile-type. So instead of

[cpp] for (map<string, vector >::iterator i = m.begin();

 i != m.end(); i++) {

[/cpp]

we can now write

[cpp] for (auto i = m.begin(); i != m.end(); i++) { [/cpp]

and auto will evaluate to map<string, vector>::iterator.

Combining these changes, we move from the horrendous

[cpp] for (map<string, vector >::iterator i = m.begin();

 i != m.end(); i++)
for (vector<string>::iterator j = i->second.begin();
     j != i->second.end(); j++)
    cout << i->first << ': ' << *j << endl;

[/cpp]

to the much simpler

[cpp] for (auto i : m)

for (auto j : i.second)
    cout << i.first << ': ' << j << endl;

[/cpp]

Not bad.

C++11 support varies a lot from compiler to compiler, but all of the changes above are already supported in the latest versions of GCC, LLVM, and MSVC compilers.

A couple of days ago, I was listening to one of my favourite podcasts, The Frequency, when one of the hosts, Dan Benjamin, thought of a cool domain name, ohitson.com and checked to see if it was available. Turns out it was and he said he was registering right there and then. Now, two things: (a) I was listening to a recorded podcast, not live; and (b) I thought to myself, damn it! it is a cool domain name.

The next day, I launched Hover and checked the domain name and to my surprise it was available. I simply thought either Dan had given up on it or, most likely, I had misunderstood the domain name he was talking about and fortunately that had made me thing of this cool domain name. I even checked Google to make sure “Oh, it’s on” was really written like that :P

Obviously I went ahead and registered the name. After that, I listed to that day’s The Frequency and heard Dan tell Haddie something to the effect of “oh, I forgot to register that domain yesterday!” That’s when I thought, oh-oh, maybe I had heard the correct domain name.

As it turns out, I was just listening to today’s episode and guess what? Dan mentions that someone registered it due to his mention on the show (which is technically true.)

But I am a nice guy. I offered to transfer the domain to Dan for free just a few minutes ago. Not sure he’ll see my posts to app.net or Twitter. If not, I’ll try again a few times. I really don’t have any intention to keep this domain name as long as he still wants it. Sounds unfair.

Update 7 Nov 2012: can you believe he actually accepted my offer? What a douche! Just kidding, it was the Fair Thing to Do™ and I’m happy to say the domain has been transferred to His Benjaminship already.

While I was ranting about the annoyances I found in OS X Lion today, a friend commented he had no issues at all, except for the full-screen mode. I got curious because the new Lion full-screen mode is probably the only new feature I found interesting. What did Apple do so wrong?

The answer: Google Chrome.

Wait, what? My friend was complaining that in Chrome you needed to use a keyboard shortcut in order to leave full-screen mode. That, he continued, was because Apple had given programmers too much freedom to implement the new feature any way they wanted. And he knew that, he assured me, because he had searched Google and confirmed it.

The new full-screen mode in Lion is implemented as a window behaviour not enabled by default, but adding it to a window is remarkably easy*:

[go] NSWindowCollectionBehavior behavior = [window collectionBehavior]; behavior |= NSWindowCollectionBehaviorFullScreenPrimary; [window setCollectionBehavior:behavior]; [/go]

Adding the NSWindowCollectionBehaviorFullScreenPrimary behaviour to a window will enable a small button to its top right corner. When enabled, the mode will allocate a new Desktop for the full-screen app and will also add an icon to the system menu to allow you to quickly leave full-screen mode.

And that’s the little icon my friend complained Chrome wasn’t showing, forcing him to use a keyboard shortcut. Imagine the trepidity! And all because of Apple.

I tried to explain that the problem was that Chrome’s windows still didn’t support the new full-screen behaviour but my friend’s version of reality was unswayable: Chrome supported the new behaviour and the problem was Apple. He had searched Google to confirm it. What could I possibly do?

Search it myself is what. And search I did. And I found this comment on Chromium’s bug tracker:

Comment 39 by rsesek@chromium.org, Jul 15, 2011

We had a conversation with one of our designers, and what we’re going to do right now is remove the fullscreen button so we don’t advertise a behavior that we don’t really implement. That change just landed and will hit Canary/Dev channels soon.

Long-term, we’re going to implement a proper fullscreen interface for Lion. In this interface, we’ll also experiment with having a collapsable toolbar. Until then, fullscreen will operate as it does on Leopard/Snow Leopard.

So there it is, straight from the source. Chromium — same as Chrome — still doesn’t support the new behaviour. Done. Nothing like reality to end a discussion.

Except my friend would not yield. Apple still needs to fix Chrome and anyone who disagrees — presumably that Chromium developer himself — is to be disregarded as an Apple fanboy.

If however you don’t want to wait for Google (or is it Apple?0 to release Chrome with the new full-screen behaviour, you can get by using Maximizer, which adds the behaviour to any application window.

• Yes, I do realize that if you’re supporting multiple OSX versions and, even worse, multiple platforms, things get slightly more complex, but still.

( Image by Anderson Mancini)