Roberto Selbach

About |  Blog |  Archive


Invincible breaks my heart

Spoilers abound. You’ve been warned.

From the very beginning, Robert Kirkman maintained that Invincible was his attempt at doing the whole superhero thing right. There is a running gag in this book that on every cover (at least for a lot time if not since the beginning), they take a little jab at the superhero genre as done by other houses.

As news appeared that there would be a reboot, Kirkman was quick to declare that he was not going to be a dick to his readers and would not erase the whole timeline. By calling the arc “REBOOT?” with a question mark, he could not have made this more clearer. Also, the cover tagline:


And so we reach the end of the arc and Kirkman did keep his promise: the timeline was not erased. But maybe it should? That is the question that he leaves us with.

Mark is taken back to just before he gets his powers. He then deals the best he can with what he knows is coming: Nolan’s attempt at conquering the world for the Viltrumite Empire and the consequent deaths of so many in the process. That’s the “hero stuff” and although it’s well done, none of it will matter.

Mark has also to deal with being young again, living with his parents. His wife of many years now barely knows and definitely doesn’t care for him. And his daughter wasn’t born yet. How do you deal with this?

During the first two issues of the arc, Mark’s personal life was mostly a B plot. But in this final issue, it becomes central.


Mark gets a chance to go back to his original timeline, to his wife, to his daughter. But he’s asked for a sacrife. A hero’s sacrifice.

The beings that brought Mark here explain that by setting himself in another path, he can fix the future, he can fix all the things that happened to Earth in the original timeline. All he has to do is make the choice.


But he says no. Mark wants to go back to his wife and daughter. There is nothing that can make him change his mind.

He doomed his planet and he is a disgrace, they say. I can leave with that, he responds and goes back only to find desolation where the battle against Thragg is apparently finished – and apparently lost — I suppose we’ll learn more about that soon.

And of course, Kirkman had to throw one extra punch at the guy. As a father, the reveal at then end of what Mark has lost is heartbreaking.

Invincible remains the only book that has never once disappointed me in any of its arcs. This is amazing for a story ongoing for over 10 years and 126 issues.

Now excuse me while I go hug my daughter.

The Evolutionary Psychology Nonsense

I have a friend who is all into the whole evolutionary psychology fad. It’s useful when you want to rationalize bad behaviour. I once told him that evolutionary psychology was pseudoscience to which he replied saying that I was just trying to negate the world as-is.

But apparently I’m not alone, as Jonathan Marks writes (emphasis is mine) —

I can’t shake the feeling that the methodologies I have encountered in evolutionary psychology would not meet the standards of any other science.  For a notable example, it is apparently a revelation to evolutionary psychology that one cannot readily generalize about the human condition from a sample of humans that is Western, Educated, Industrialized, Rich, and Democratic. Perhaps this was news in psychology – creationist, evolutionary, or otherwise – but, sad to say, everybody else who works with cultural diversity knew that a really long time ago.

Avoiding Avoidance Behaviour

I am currently trying a new approach to deal with my social phobia. Basically it involves avoiding avoidance behaviours. You see, people with social anxiety tend to avoid problematic situations and run to metaphorical safe places. After a while, the avoidance behaviours become almost automatic, almost imperceptible.

Almost but not quite.

We behave so without thinking but we recognize the behaviour while we’re doing it. And that’s exactly when we have to force ourselves to avoid avoidance. It is very difficult and the temptation of avoidance is almost irresistible. The problem, of course, is the more we avoid things, the harder it is to stop doing it later in life.

Last night I posted something to Facebook —

The voices of social anxiety immediately started working in my head. “FriendA will mock at you,” they shout. “FriendB will think you’re pathetic.” And so they went. I came this close to deleting the post before stopping and forcing myself to ignore the voices.

It is not easy. It is so not easy that I am writing a blog post about it. Social phobia makes my mind work against me: it constantly attacks me, my self-esteem, and my confidence. It would be so much easier to just delete the post.

Dealing with social anxiety involves many counter-intuitive measures: it forces socially anxious people to go against what our own brains tell us is not the safest route.

I need to keep working on it. I’ll need to continue to force myself into doing more of what I desperately want to avoid. Let’s see how it goes.

Why do Salespeople Believe in Magic?

File this one under techies complaining about non-techies. Over the years, I have noticed a pattern with salespeople, they have a firm belief in wishful thinking. They honestly believe that wishing something to be true will magically make it so.


The specific pattern I noticed many a time goes something like this.

The customer wants something done and goes through their account manager to request that. The account manager — a fancy name for salesperson — commits to a date without talking to the developer first. They then go to the developer and tell her something to the effect of “yeah, I’m going to need that by Friday morning.” The exasperated developer explains that this is not feasible and the account manager responds by simply repeating that they will need it by Friday. They usually leave at this point satisfied that everything is fine.

Come Friday, the account manager is then horrified to discover that the feature is not ready. “But we made a commitment with the customer,” they’ll say, emphasizing the “we” that never was.

This has happened some many times in my career that I should no longer be surprise and yet I still do. Every time.

Of course, what they are really doing is trying to put pressure on the developers so that they will hurry up and deliver on the desired timeframe. And to be fair, it can sometimes work, but if the developer tells them in no uncertain terms that the deadline is not feasible, then the salesperson is taking the risk by herself.

By committing to a date with the customer before talking to the developer, the salesperson has already taken a big risk. They will then try to spread that risk by sharing it with the developer. Since the developer never had a chance to agree with that in the first place, it is only fair that she should be able to refuse to take the risk if she doesn’t believe it is worth it. Why should she?

And yet, we developers often accept the risk by being passive and simply accepting it. This problem can be exacerbated by managers who are also passive. Many years ago I worked at a company where the engineering power that be were submissive to the sales department, which led to some of the worst experiences in my life as a developer, including the Project From Hell.

At the time, I led the engineering services group, so whenever a new project came about that required software development, it had to go through me for analysis. Another group leader analysed the infrastructure projects. Then one day this large project showed up on my desk. I looked over it along with the infrastructure guy and we agreed that it was a monster of a project, including developing a huge distributed nationwide (Brazil) infrastructure, a huge system developed from scratch, and a lot of technology transfer and end-user training.

The project had some timeframes attached to it and although they were tight, they were not what immediately caught out eyes. We saw the pricing they were offering the customer and it was clear to us that it was low. We raised the issue but were told not to worry about it. There are valid business reasons to do projects at a loss sometimes, so it was okay, except the exact wording to us was, “please limit yourselves to your little expertise sphere.” Ok then.

We talked to our teams and we committed to the dates defined in the project documentation. Again, it was a little tight but feasible: we would have many months to get things ready for initial deployment.

About a week after we approved the statement of work, I received a call from the customer. At this point, I had not yet engaged the customer at all, so they had gotten my phone number from their sales rep. The customer was possessed. This person I had never talked to before was shouting at me on the phone that we were late. It took me a while to call him down and understand what the issue was.

As it turns out, the sales team, in an effort to get the customer’s signatures before the end of the quarter, changed the statement of work after we had gone through it, moving the dates to right that very moment. We had not even started working on the project yet and the customer was expecting it to be ready right then. We were late before we even started.

Many stressful meetings later we managed to agree on some new dates, but they were much tighter than the ones originally in the statement of work and would required us to outsource parts of the project to a contractor to help speed up things. Incidentally, what we paid the contractor for only a part of the project was more than what our company made on the project. All because the sales team wanted to make sure they got their commission in that quarter.

The people responsible would eventually be let go of the company, in great part due to this, but that did not prevent the company from losing at least an order of magnitude more than what it made from that project.

And still, I continue to see salespeople ignoring the developers and then trying to share the fallout. Developers need to stand firmly by their professional evaluations of deadlines and technical feasibilities.

Of course, if you turn out to be wrong, all of this is moot.

Goodbye, Mr. Spock.

Leonard Nimoy

I am sad. The New York Times

Leonard Nimoy, the sonorous, gaunt-faced actor who won a worshipful global following as Mr. Spock, the resolutely logical human-alien first officer of the Starship Enterprise in the television and movie juggernaut “Star Trek,” died on Friday morning at his home in the Bel Air section of Los Angeles. He was 83.

I am actually sad. As much as Star Trek was a part of my life, I had not felt this way when other cast members passed away in the past.

I suppose Nimoy was different somehow. My theory is that as Spock, he would (almost) never smile and that made his rare smile that much more important. When I think of Nimoy/Spock, it is his smile that I picture in my mind. When out of character, he was always smiling. This contrast forces an emotional connection or something. I don’t know.

What I do know is I am sad. For whatever’s worth, Nimoy was a part of my life.

You’ll be missed, Mr. Nimoy. I have been, and always shall be, your fan.

My social anxiety screwed me royally this week

By Christopher Walker (Sadness) [CC BY-SA 2.0 (], via Wikimedia Commons

A few years ago I wrote about how social anxiety makes me use fake accounts on the web.

I love coding. I have done it since I was a kid and it’s the best thing I know how to do. And then there is open source. Open source projects should be the perfect venue for me to have f un. Except I am scared stiff by the idea that someone might laugh at the code. It came to a point where it is impossible for me to contribute. Then I’ve come up with a solution: an alias. For the past several years I’ve lived two different lives online: one as myself and another as an alias. I keep them strictly separate.

Actually I today use more than one single separate life. Looking at my Chrome identities menu I count four (including the real me), but I actually have more around that I have abandoned.

It has allowed me to do what I like to do. I don’t have to be afraid because I know all I have to do is abandon one account and start over with another. It’s a good solution but it has some issues.

I have been offered this great job in the past by the manager of someone I’ve worked together. It was one of the Big Tech Companies, a place I really would love to work. All great, right? Except the offer was not addresses to Roberto Teixeira, but to one of my aliases. Tough luck. I’ve soon abandoned that alias for good.

So yes, it sucks. But not as much as it has sucked this week.

I—under an alias—have been working with a developer of a big open source project out there to try to solve a problem we were having at work. And I found a solution that was pretty clever. That developer checked it out and thought it was great and then we both wrote a proposal and submitted it. And it was accepted and our change will be part of their next major release.

I’m not saying it was something revolutionary or anything. Still, it was something I am very proud of. And there will be a name there in the changelog/release notes/whatever but it will not be my name.

This happened the same week I learned that someone I–the real me; real name and everything–interviewed with a few months ago had dismissed me for not having open source contributions.

In short, I am sad and angry. Fuck social anxiety. 🙁

(photo: Christopher Walker (Sadness) / CC BY-SA 2.0 / via Wikimedia Commons)

From Kerbin to Laythe and Back

Even though I’ve been playing Kerbal Space Program for over a year, I have only barely explored the outer kerbolar system. I have been around Jool before and I have even landed on Laythe but never managed to make a round trip until this week.

Traveling all the way to Jool’s moon Laythe and back is not easy[citation needed]. It’s not so much getting there—although that’s not trivial, either—but we want to land on Laythe and we want to get back to orbit later: that takes a lot of fuel.

This is my adventure.

Mission Overview

The Kerbal Air and Space Agency (KASA) will be sending two separate missions: the Laythe Recovery System (LARS) and the Laythe Orbital Landing System (LOLS). The LARS stack is controlled by an automated probe and its function is to carry fuel for the travel back.


Although huge, it is only as heavy as it needs to be to deliver fuel, lacking scientific instrumentation and communication systems other than the Clamp-O-Tron’s acquisition signal.

The second stack is LOLS, which will carry a 3-kerbal crew, the lander itself, and all the scientific instruments: a gravioli detector, a termometer, a barometer, and a Mystery Goo™.

The two stacks will launch a couple of days between them and will meet in orbit around Jool over two years later. LOLS will then rendezvous with LARS, dock, and transfer any remaining fuel from its tanks and then drop its large tank before the LARS will then make the Hoffman transfer to Laythe1.

LARS Launch and Trans-joolian Insertion Burn

The first of the two missions to launch was LARS, the rationale being that if something were to go wrong later that prevented the LOLS launch, LARS could wait in Jool orbit for the several years until a new interplanetary window opened to allow LOLS—or its successor—to go rendezvous with it. It would be harder to keep a Kerbal crew waiting there2.

Also, to minimze the risks, LARS was launched as soon as the window opened, allowing for more time to deal with any issues with LOLS later. This resulted in a night launch.


Showing that LARS was not too heavy, it quickly started accelerating towards terminal velocity and we lower the thrust to about 80% so we don’t waste fuel fighting drag.


At 7300m we start the roll program to begin gaining horizontal speed. A little later, just passing the 10,000m mark our two first boosters run dry and we have a beautiful separation.


At its parking altitude of 240Km, the probe circularizes its orbit and, as Robert Heinlein would have said it, we are halfway to anywhere3.


About 2 hours after settling in its parking orbit, LARS is GO for TJI. This burn adds the 1,907m/s delta-V needed for LARS to reach Jool.


After the burn is done, LARS is on its way. Time to remember to extend our four Gigantor solar panels to ensure the probe will have power in its journey4.


With LARS now on the way, the KSP staff turns its attention to their next mission: LOLS.

LOLS Launch and Trans-joolian Insertion Burn

LOLS presents its own set of challenges. It is considerably heavier than LARS because not only it carries a similar amount of fuel—which it will spend much more quickly due to the extra mass—but it also adds the crew, large capsule, and scientific instrumentation.

With the greater weight, the engines struggle to lift off the launch pad. It takes almost 20 seconds to clear the flag pole by the pad.


It never comes close to terminal velocity while in the atmosphere and the throttle remains at 100% all the way. It begins roll program at 7300m and has barely accelerated past the 200m/s mark at this point.


After another beautiful separation, the speed is mounting a bit faster now…


… but it still takes a while. As well, although LARS managed to reach orbit on its second stage alone–albeit running on fumes at the end—, LOLS had to rely on the third stage to reach orbit, spending half its fuel tank.


About 90 minutes after reaching the parking orbit, LOLS is GO for TJI. Delta-V needed is 1,904m/s.


Over a million kilometers behind LARS, LOLS is now on its way for the long, nearly-two-year-long journey to Jool.

Deep space Transfer

During the long transfer period spend after escaping Kerbin’s sphere of influence and before the encouter with Jool, the crew does some science.


Tonmen Kerman goes EVA for a while and reports back to Kerbin. They also do a crew report and use the gravioli detector for some extra science production.

The original plan was to have LARS arriving first and waiting for LOLS to arrive. That would make sense as LARS is an automated probe while LOLS is carrying actual kerbals. That is why mission control5 naïvely launched LARS first. As it turns out, it was a mistake.


As you can see in this picture, LARS is indeed ahead of LOLS. However, due to their positions in relation to Jool itself, LOLS ends up getting caught by the Jool sphere of influence before LARS. This caught mission control by surprise and almost ended the mission as all its attention was on the LARS approach and only by sheer dumb luck they noticed LOLS encountering Jool SOI.


In retrospect, this makes perfect sense. In the 1-2 days following the launch of LARS, Kerbin and Jool were moving in relation with each other. Kerbin, having a much lower orbit than Jool’s, was moving faster and since it was “behind” Jool, this meant both planets were actually getting closer to each other so LOLS had a slightly shorter trip than LARS. That’s orbital mechanics for you.

LOLS Aerobreaking and Joolian Orbit Insertion Burn

One year, 270 days into the mission, LOLS, already deep inside the joolian SOI, maneuvered to adjust its periapsis to 110Km above Jool. Jool’s atmosphere begins at around 138Km of its sea level, which is not that much considering how big the planet is. But that atmosphere is very dense, which is good for aerobreaking, saving us some precious fuel.


Two days later, LOLS reaches Jool…


… and falls 30Km into its dense atmosphere for some heartstopping aerobreaking.


Mission control found 105Km to be a great aerobreaking altitude as LOLS re-emerged from the atmosphere with an apoapsis of a tad over 500Km, which required very little delta-V during the Joolian Orbit Insertion burn to reach the desired parking orbit of 400Km. The crew adjusted their apoapsis and periapsis and waited for the LARS to arrive. This was the early hours of 1y 273d MET6.

LARS Aerobreaking and Joolian Orbit Insertion Burn

Twenty seven days after the arrival of LOLS in Jool, LARS enters Jool’s SOI. LARS will try for an approach with a periapsis a little lower: 105Km. The 5Km difference doesn’t sound much but considering the density of Jool’s atmosphere, it makes a difference.

Despite mission control’s best efforts to point it retrograde, LARS insisted in going nose first.


LARS leaves the atmosphere with a apoapsis of a little under 400Km, again leaving little delta-V for the JOI burn. It parks at 280Km. This is 1y 386d MET, meaning the intrepid kerbal crew waited in orbit for 113 days for LARS, even though their total mission time so far was a little under 2 days shorter than LARS’.


Rendezvous and Docking

As soon as LARS settled in its parking orbit, the LOLS crew starts working on the rendezvous maneuver. A good encounter happens after 5 orbits around Jool.


Once docked, the crew transfers all the fuel remaining on the LOLS main tank to LARS and ejects it. From now on, LARS will be doing the heavy lifting of the Trans-laythean Injection.

Trans-laythean Injection and Laythean Orbit Injection

(I mentioned early on that rendezvous in Jool orbit proved to be a mistake. The why might become more clear from this picture.)


The two small extra boosters added to LOLS made it a bit too much for the Clamp-O-Tron docking port to hold. When LARS ignited its engine for TLI, the centre of mass shifted slightly but enough to make LOLS wobble and put on too much stress on the docking port, which then broke. (Thankfully I had quicksaved just before the burn and was able to recover.)

The crew slowly pushes on the throttle to ease on the clamp-o-tron stress. Same thing during LOI: easy on the throttle. The crew and mission control also agreed to skip the aerobreaking, the rationale being that Laythe’s atmosphere is low (55Km) and not very dense so it would probably not help them all that much and they did not want to put on more stress on the docking port.


Undocking LOLS and Landing

At this point, the crew transfers fuel from the LARS main tank to the three LOLS tanks and undocked. Time to land.

Laythe is touch to land for two basic reasons:

  1. It’s almost entirely made of oceans, with some relatively small islands and continents; and also
  2. The islands and continents are rough! Lots of mountains and steep slopes.

The crew ultimately picked the continent that looks sort of like a large ‘C’ with an internal sea.


(It took me a few tries and one big scare as just before landing I noticed a deep valley just ahead.)


LMP Donbro Kerman uses the retro rockets plus the parachutes to slow the LOLS down and slowly descend.


He also has to rotate LOLS around to make sure it lands in a way to prevent it from tumbling over the slope.


It all ends well though, as Commander Roley Kerman steps out of LOLS and steps on Laythe.

Laythe Base

The crew has to remain on the surface until the next interplanetary window before they could go back to Kerbin, which means: time for some science! With some gravioli detection, temperature and barometric measurements, EVA reports, crew reports, Mystery Goo™ observation, and some surface samples, the LOLS crew gets well over a thousand science points.

And they had some fun too, like this little night rave or whatever. This is Donbro standing by the lander legs while Tomner jumps by the flag.


Commander Roley was asleep and missed the shenanigans. Probably for the best.

Takeoff and rendezvous

After a couple of years on Laythe, the crew was eager to go back home.


LOLS rendezvous with LARS, which patiently waited all these years in orbit.


The crew now transfers the remaining fuel from the LOLS tank to LARS’ and jettisons it. Time to go home.

The jorney home

The jorney back is largely uneventful, starting with the transfer from Laythe back to Jool. Now that they got rid of the LOLS tanks, the Clamp-O-Tron docking port is more than capable of holding the capsule in place.

Back in orbit around Jool, LARS is GO for Trans-Kerbal Injection.


And the long journey back to Kerbin is now underway.

Two years later, the crew maneuvers to reach Kerbin with a periapsis of 30Km for some heavy aerobreaking.


They reemerge from Kerbal atmosphere with an apoapsis of almost 2,000Km and running of fumes. The remaining fuel is then used to lower the apoapsis a little bit without changing the periapsis too much. This made sure that on the second periapsis pass, the stack will not make it out of the atmosphere again.

At this point, mission control tries for a bonus mission objective. They plan to land both the LOLS capsule and the LARS rockets at the same time and try to recover the LARS hardware costs. After they stop burning in the reentry, the LOLS capsule undocks from LARS and mission control constantly switch between the two to try and land both.

Unfortunately, saving the LARS was a failure. As soon as the parachutes opened, LARS disintegrated, leaving only the RCS tank and docking port to slowly land.


The LOLS capsule on the other hand had a beautiful descent.


After LOLS splashed down, the capsule, its science payload, and its crew were successfuly recovered. Mission accomplished!


The remaining LARS parts were found to not be recoverable.


A few closing remarks

I was pretty pleased to have completed my longest mission yet. Still, a few things I would have changed.

I wasted fuel by not aerobreaking in Laythe. Also, I am sure there is an optimal altitude that I could have reached Jool for a better aerobreaking. I did try several but going even a bit under 105Km seemed to be too much as the ship never came back out of the atmosphere. A little over 110Km and the apoapsis would end up in the millions of kilometers.

Another thing is that I made the hop in Jool orbit between Kerbin and Laythe. I am not sure it is possible but I think I will try in the future to go directly to Laythe. It must be terribly difficult but a scenario would be to arrive in such an angle that you could aerobreak in Jool and come out with a path leading to Laythe directly, hopefully with some extra aerobreaking. This would be optimal but would require a lot of precision. I don’t think I could make it but it sure sounds like it would be fun.

I should also have scheduled the LOLS-LARS rendezvous to happen in orbit around Laythe instead of Jool to avoid the wobbly lander problem. The LOLS was low on fuel by that time though, so I am not really sure I could have pulled it off anyway.

And I could have taken at least one more Mystery Goo™ as I could have observed it in orbit aroud Laythe for some extra points.

And finally, I love this game so much. You learn more every time you play it. This whole thing, including designing both stacks and doing some testing, was done over the course of a few days, mostly last weekend with the return from Laythe to Jool and then Kerbin done over a couple of nights this week.

I thank Squad for this great game.

May your solar panels be always unobstructed.

UPDATE: this whole story was created way before KSP 1.0 came out. The aerobreaking maneuvers here would not have worked due to the lack of heat shields. As well, a scientist kerbal in the crew would solve my issue above with only taking a single Mystery Goo™ as kerbal scientists can reset experiments in flight.

  1. That would turn out to be a mistake, as we’ll see.
  2. Not really, actually, as Kerbals don’t seem to care…
  3. Heinlein’s actual quote was “Once you get to earth orbit, you’re halfway to anywhere in the solar system.” I suppose it can be used for Kerbin and the kerbolar system.
  4. You learn that the hard way in KSP. How many a time I have arrived somewhere after warping time just to find my ship completely dead because there was no electrical power left.
  5. That’s me.
  6. Mission Elapsed Time

Things I wish I knew one year ago

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.


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.

More on validating with Go

A few days ago I posted about a new Go package called validator that we initially developed for our own internal use at but what fun is internal stuff, right? So we opensourced it.

Then Matthew Holt pointed me to an ongoing discussion
on validation happening on martini-contrib’s github. By the way, if you don’t know martini yet, go rectify that right now.

And today I learned about check, which takes a completely different
approach to data validation than the one we took, which by the way is totally fine and you should check it out.

Good to know we were not the only ones with the problem. Although I’m happy with how our package turned out, I kind of wish
I had found these other guys earlier. Could have shared some code or just ideas.