Blog – Page 5 – The Roberto Selbach Chronicles

My social anxiety screwed me royally this week

Posted on 2014-10-182018-08-20 by Roberto's Chronicles

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

Posted on 2014-09-252018-08-20 by Roberto's Chronicles

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 Laythe¹.

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 there².

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 anywhere³.

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 journey⁴.

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 control⁵ 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 MET⁶.

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:

It’s almost entirely made of oceans, with some relatively small islands and continents; and also
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.

That would turn out to be a mistake, as we’ll see.↩
Not really, actually, as Kerbals don’t seem to care…↩
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.↩
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.↩
That’s me.↩
Mission Elapsed Time↩

Things I wish I knew one year ago

Posted on 2014-08-282018-08-20 by Roberto's Chronicles

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.

More on validating with Go

Posted on 2014-05-032018-08-20 by Roberto's Chronicles

A few days ago I posted about a new Go package called validator that we initially developed for our own internal use at project7.io 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.

[ANN] Package validator

Posted on 2014-04-292018-08-20 by Roberto's Chronicles

The thing about working in a startup under stealth mode is you can’t often talk about what you’re doing. Thankfully, from time to time, an opportunity appears that lets us at least share something tangential.

A large part of our project at project7.io involves receiving data from a client (generally in JSON) for processing. This involves unmarshaling the JSON into a struct, something that Go does very well. But then comes the boring part: checking that the information sent from the client is correct and complete before doing anything with it.

The boring life of validating stuff

if t.Username != "" && t.Age > 18 && t.Foo != nil && len(t.Bar.Baz) > 8 && ...

We had to do this often and for a large number of different structs and sometimes a struct gained a new field and we had to go back and see that it was being properly validated everywhere. It was so boring that we ended up writing something to make it easier for us. We’ve been using this for a while and now we decided to open source it in the hopes that it might be useful for others.

Package validator implements validation of variables. Initially we had implemented JSONschema but we don’t always deal with JSON, we also get data as XML and sometimes as form-encoded. So we changed our approach and went right to the struct definitions.

A struct definition with some validation rules attached

type T struct {
  A int    `validate:"nonzero"`
  B string `validate:"nonzero,max=10"`
  C struct {
      Ca int    `validate:"min=5,max=10"`
      Cb string `validate:"min=8, regexp:^[a-zA-Z]+"`
  }
}

This allowed us to attach validation rules right to the data structure definitions. Then instead of large, boring list of if statements, we were able to validate in single function call.

Validating an instance of a struct

if valid, _ := validator.Validate(t); !valid {
  // not valid, so return an http.StatusBadRequest of something
}

Multiple rules for different situations

We often use the same struct to deal with different data coming from the client. Sometimes we only care about one or two of the fields in one scenario, so we also supported multiple rules like, say

A struct with two different sets of rules

type T struct {
  A int    `foo:"nonzero" bar:"min=5,max=10"`
  B string `bar:"nonzero"`
}

In scenario foo, we need A to be non-zero, but we don’t care for what is in B. In the bar scenario, however, we need B to be non-zero and the value of A to be between 5 and 10, inclusive. To validate, we then make validator use a different tag name for each case

WithTag() FTW

t := T{A: 3}
validator.WithTag("foo").Validate(t) // valid
validator.WithTag("bar").Validate(t) // invalid

We can also change the tag by using SetTag with will then make the tag name persistent until changed again by another call to SetTag.

Please refer to http://godoc.org/gopkg.in/validator.v1 for a lot more documentation, use cases, and how to access the individual validation errors found for each field.

Easter Eggs in the Apollo Program

Posted on 2014-01-252018-08-20 by Roberto's Chronicles

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.

Exemplo de texto de MBA

Posted on 2013-08-072019-12-20 by Roberto's Chronicles

Um amigo publicou um texto no Facebook hoje que me lembrou do MBA. Vou deixar o texto aqui, como exemplo do tipo de texto comum em escolas de negócio e deixar o julgamento ao leitor:

ASSALTO MUITO INTERESSANTE.
Durante um assalto, em Guangzhou, China, o assaltante de bancos gritou para todos no banco: “Não se mova O dinheiro pertence ao Estado Sua vida pertence a você…”
Todo mundo no banco deitou-se calmamente no chão. Isso é chamado de “Mudando o conceito mental” Mudar a forma convencional de pensar.
Quando uma senhora apresentou-se sobre a mesa provocativamente, em que o ladrão gritou para ela: “Por favor, seja civilizada isto é um assalto e não um estupro!”
Isso é chamado de “ser profissional” Concentre-se apenas no que você está treinado para fazer!
Quando os assaltantes voltaram para casa, o ladrão mais jovem (MBA treinee), disse ao ladrão mais velho (que só completou seis anos na escola primária): “Big brother, vamos contar o quanto nós temos.”
O assaltante mais velho rebateu e disse: “Você é muito estúpido. Há tanto dinheiro que vai nos levar muito tempo para contar. Hoje à noite, o noticiário da TV vai nos dizer o quanto nós roubamos do banco…!”
Isso é chamado de “experiência”. Hoje em dia, a experiência é mais importante do que as qualificações do papel!
Depois que os ladrões saíram, o gerente do banco disse ao supervisor bancário para chamar a polícia rapidamente. Mas o supervisor lhe disse: “Espere, vamos retirar U$ 10 milhões do banco para nós mesmos e adicioná-lo aos 70 milhões dólares que já foram desviados do banco”.
Isso é chamado de “nadar à favor da maré.” Convertendo uma situação desfavorável para a sua vantagem!
O supervisor diz: “Vai ser bom para nós se houver um assalto a cada mês.”
Isso é chamado de “morte do tédio”. Felicidade pessoal é mais importante do que o seu trabalho.
No dia seguinte, o noticiário da TV informou que U$ 100 milhões, foram retirados do banco. Os ladrões contaram e contaram e contaram, mas eles só podiam contar o montante de U$20 milhões. Os ladrões estavam muito irritados e reclamaram: “Nós arriscamos nossas vidas e só levamos 20 milhões de dólares. O gerente do banco levou 80 milhões de dólares com apenas um estalar de seus dedos. Parece que é melhor ser educado do que ser um ladrão..!”
Isso é chamado de “Conhecimento que vale tanto quanto ouro!”
O gerente do banco estava sorrindo feliz porque suas perdas no mercado de ações foram agora cobertas por este roubo.
Isso é chamado de “Aproveitando a oportunidade.” Ousadia para assumir riscos!
Então, quem são os ladrões reais aqui?
Conde de Kakflour

Join us on App.Net

Posted on 2013-05-182018-08-20 by Roberto's Chronicles

I liked the idea behind App.Net (or ADN for the initiated) from the start; I’ve happily signed up during the initial funding effort and before it even existed. It is quite like Twitter, although it does have some pretty interesting API advantages that allow clients to do things that are not possible in Twitter such as creating private chat rooms (with Patter.) I found a text by Matt Gemmell, App.Net for conversations, that sums it up nicely:

The interesting part, though, is what you won’t be used to from Twitter. There are no ads, anywhere. Because it’s a paid service, there’s no spam at all; I’ve certainly never seen any. There’s an active and happy developer community, which ADN actually financially rewards. There’s a rich, modern, relentlessly improved API. And again because it’s a paid service, there’s a commensurately (and vanishingly) low number of Bieber fans, teenagers, illiterates, and sociopaths.

But the real difference I notice is in the conversations. On Twitter, the back-and-forth tends to be relatively brief, not only in terms of the 140-character limit, but also the number of replies. There’s a certain fire-and-forget sensibility to Twitter; it’s a noticeboard rather than a chatroom. Then there’s the keyword-spam (woe betide the person who mentions iPads, or MacBooks, or broadband, or just about anything). Oh, and let’s not forget the fact that any malcontent with internet access can create an account (or two, or ten) in seconds. Not a happy mixture.

I’d add that there seems to be less of a popular clique on ADN. Popular users seem to be much more engaging with “regular people” than on Twitter. And there’s the developers… although most of the rush is now behind us, it was fun to follow the developers working on ADN clients. It was a very collaborative effort, with alpha builds floating around and discussions about whether this or that should be done in a certain way.

As for the developers of ADN proper, well, you can try asking ADN CEO and Founder Dalton something to see if he’ll answer you in about 30 seconds. He actually does. 🙂

It all feels like a big community where everyone feels a bit like they own the place as well and want it to thrive. Again I think Matt is on the money on why this is so:

We value what we pay for. We not only pay for things which we deem to be of value, but we also retrospectively assign and justify value based on what we’ve paid. Any consumer is familiar with the simple psychology of cost equating as much to value after the transaction as value does to cost beforehand (likely moreso, from my own experience). At its core, I don’t think that the reason for the noticeably different, warmer, more discursive “feel” of ADN is any more complicated than that.

I personally love the service and I think you should consider it too. There is a free tier account that allows you to follow up to 40 people for free, as long as you’re invited by a current user. If you’re interested, I have a few invites.

Feel free to comment on this post by using this Google+ thread or also by talking to me on, where else, ADN, where I’m @robteix. And of course Twitter isn’t going anywhere and I’m there too.

Why is Change So Difficult?

Posted on 2013-04-302018-08-20 by Roberto's Chronicles

I have long been a bit of a nomad. What is interesting to me is that I don’t really like change too much. I am a creature of habit and yet, here I am.

Four years ago, I moved to Argentina due to professional reasons. At the time, I had my mind set that I was going to give it a try and come back if it didn’t work out. It was a hard decision too, since my wife and I were pregnant of our daughter. But we took the plunge anyway. We knew we could always come back and as Terry Pratchett wrote in one of his Discworld novels —

Why do you go away? So that you can come back. So that you can see the place you came from with new eyes and extra colors. And the people there see you differently, too. Coming back to where you started is not the same as never leaving.

I am now leaving, returning to my old country. It is mostly due to the economic situation in Argentina. I was able to mostly protect myself by keeping my savings in Brazil as well as transferring as much money as I could from Argentina. But still, I need to make a move. Our daughter is growing up and should start school soon so if we’re going, we should go now.

I officially left my job about a week ago. My wife and daughter left soon after as I stayed to put our affairs in order — selling stuff, closing accounts, the whole thing — and now it’s my time. I am leaving in the morning.

Being here alone made me think about — and fear — the future. Why is change always so difficult?

It isn’t that I have doubts about the decision itself. I know it is the best move for us. But I still fear it.

Will I ever find another job again? Am I too old to do these things? Will my daughter learn to speak the language? Rationally and logically I know the answers to these questions. But the fear of change is there.

What I learned — or at least what I tell myself — is that it’s fine to be afraid. Being afraid just means you are about to do something brave. Or stupid. Starting tomorrow, I find out which.

Adiós, Argentina. See you all on the other side.

Goodbye Intel

Posted on 2013-04-222018-08-20 by Roberto's Chronicles

Eight years ago I joined a great company in Intel. It has been a great ride but as of a few minutes ago, I have informed my manager that I quitting my job for personal reasons.

A couple of years ago, I relocated to the software development centre in Cordoba, Argentina. It was always meant to be a temporary assignment but it ended up being longer than my family and I ever thought. And as our daughter grows up, it becomes ever more difficult to engage in international relocations, so my wife—who also works at Intel, by the way—and I decided that we needed to act. We set a hard deadline for the move and stuck to it. This is it.

My wife, daugher, and I at the Intel Minigolf side during the last Kids@work Day

My wife and daughter will be flying to Brazil in two weeks and I should follow some short time later, once I’m done closing everything behind. We’ll be relocating to Curitiba, where my wife and I first met 13 years ago, so it’s fitting.

So this is it. Good bye, Intel, it’s been fun and I wish you all the best.