Random Musings on Technology

Serverless: Google Cloud vs AWS

 • 


Just spent 2 hours trying to make some basic Google Cloud Services examples of Serverless to work, directly from the Serverless page to no avail. GCS was returning all kind of weird errors, including HTTP 500 ...

After that decided to move to use the AWS examples, and the first one I tried worked like a charm! Google has a long way to go to be at the level of AWS, right now the infrastructure seems crappy, if you cannot even run the most simple examples of a simple HTTP serverless function.

TypeScript: Millennials discover Static Typing

 • 

I was reading the book Programming Typescript. Making your Javascript Application Scale when I found this gem:

“So here’s a question: when exactly does JavaScript tell you that you made a mistake?

Right: when you actually run your program. Your program might get run when you test it in a browser, or when a user visits your website, or when you run a unit test. If you’re disciplined and write plenty of unit tests and end-to-end tests, smoke test your code before pushing it, and test it internally for a while before shipping it to users, you will hopefully find out about your error before your users do. But what if you don’t?

That’s where TypeScript comes in. Even cooler than the fact that TypeScript gives you helpful error messages is when it gives them to you: TypeScript gives you error messages in your text editor, as you type. That means you don’t have to rely on unit tests or smoke tests or coworkers to catch these sorts of issues: TypeScript will catch them for you and warn you about them as you write your program.”

Funny how the old becomes new... static typing has been available for ages, but apparently JavaScript is now "old" and statically typed JavaScript is in vogue now.

On Pointers and Software Developer Candidates

 • 

Recently read a good article by Joel Spolsky. The Guerrilla Guide to Interviewing v3.

This paragraph brought me some chuckles first, and later some sadness:

I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude. In first year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4 years old. They are having a good ol’ time learning C or Pascal in college, until one day the professor introduces pointers, and suddenly, they don’t get it. They just don’t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good looking members of the appropriate sex in their CompSci classes, that’s why they switched. For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirected thinking that some people just can’t do, and it’s pretty crucial to good programming. A lot of the “script jocks” who started programming by copying JavaScript snippets into their web pages and went on to learn Perl never learned about pointers, and they can never quite produce code of the quality you need.

Unfortunately, more and more Software Developer candidates are becoming "copy pasters" and do not have the skills to understand what they are doing, understand what is happening.

A Patch for AoE II HD on Linux

 • 

So apparently there is a wine bug that has been open for more than 7 years affecting Age Of Empires II HD. The game keeps scrolling the screen when inside a battle.

Fortunately someone found the specific bytes that can be changed as a workaround for the bug. I am saving the workaround here in case it is lost at some point:

Original link: https://steamcommunity.com/app/221380/discussions/2/622954302095447538/#c154645539343670235

Quote:

Ive been having this issue under wine as well, and finally got annoyed enough to look into it. I have an explanation and fix which seem to have fixed the issue for me so far.

The game is using the GetKeyboardState() function to read the arrow keys (and other keys), and is not checking the result correctly. The MSDN documentation for the function only defines the low bit (0x01, meaning that the key is "toggled" à la Caps Lock) and the high bit (0x80, meaning that the key is pressed). Age of Empires (both 1 and 2) check if the key is pressed by checking if the result is > 1. This works most of the time, as it does not depend on the low bit. However, the undefined "middle" bits are occasionally used by windows/wine internals, and are not guaranteed to be zero. The game should check only the high bit (by ANDing it with 0x80).

I've patched version 5.0 to do this for the arrow keys (replace 80 3C 01 01 at offset 0x4525D4 with 80 24 01 80 and 0F 97 C0 at 0x4525DB with 0F 95 C0 in AoK HD.exe). Note that this doesn't fix the issue across the board — the Tech Tree screen also uses GetKeyboardState() and checks the result in the same way. It'll also need redoing for each version until it's fixed properly by the developers.

I only had to do the first replacement for it to work :); this using any hex editor (like Bless). Afterwards, I can enjoy AoE II HD on Linux.

Evaluating for a Project Manager

 • 

I was asked to describe how to evaluate a Software Project Manager. I remembered this nice challenge I did at some point, and realized that had to dig in memory a lot (and ask someone who actually had taken the challenge). For that reason I decided to write about it here.

At some point in the past I have had to hire a Software Project Manager for a startup. We were looking for someone who had great Project management skills, but that also understood the Engineers.

As part of the evaluation process I did an "onsite challenge", which took around 3 hours. For this challenge the candidate had to define a plan (in the form of a type of Gantt Chart) for executing a Software development project, given a set of constraints (in time, resources, and scope of course).

The Challenge

The objective of the challenge was to test how the candidate handled the definition of a real-life project, with its constraints. The constraints came in the form of insufficient resources and time, for the scope

The candidate was recommended to ask questions to the interviewer, who played the roles of a) The Engineering team and b) The Product Team. The points to evaluate were:

  1. How well the candidate interacted with the Engineers and Product "teams" to ask them questions, clarification, etc.
  2. How much "domain knowledge" did the candidate have allowing him to make sound decisions when making compromises.
  3. How did he handled the scope/resources duality and what solutions did he came up with to address them.

Scope

To define the scope of the project, we provided the candidate with a list of stories needed to develop a mobile App. This list was comprised of Frontend stories (to implement standard UI HTML/JS), Backend stories (for the APIs to be used by the app) and Mobile stories (which required specialized mobile knowledge).

The stories were provided in the form of Story Name - Story Points - Skill, where Skill defined which type of Engineer could do it (everyone, Front End only, Backend only, Mobile Only). The stories were real stories (they actually were partially based in another project we had made before).

Resources

We provided a set of theoretical Engineers for the project. Engineers were defined in 2 dimensions: Seniority (Jr., Mid level, Sr, Tech Lead) and Skills (Fronted, Backend, Full Stack, Mobile). Each Engineer had a specific seniority and a combination of Skills they had.

The Seniority factor was modeled as the number of story points that an Engineer could finish per Week.

The idea here is that the Project Manager candidate had to consider the skills and seniority when assigning each story to the different Engineers.

Time

The last of the constraints was modeled as the date when Business had asked us to release the software product. The available time of course was not enough to implement the full list of requirements considering the available resources.

Moreover, as part of the definition of the problem, we asked the candidate to consider people going on vacation and getting sick (I barely remember even adding some vacation days for some of the Engineers, although I am not sure of that).

Evaluation

The desired output of the challenge was a type of Gantt chart. We did not explicitly asked for this, but asked the candidate to use any tool hey could, so that at the end of the challenge, he would be presenting to "Business" (i.e. the CEO, given that this was a small startup) the plan for realizing the project. The best candidates usually made some kind of Gantt chart.

The output was only one aspect of the evaluation, another (more important to me) was the interactions that happened while doing the challenge; these in the form of questions to the Development team, or questions to the Engineering team.

As candidates asked questions, possibilities opened here and there. For example, one story that was 8 points if he asked if it could be split in two, the answer was usually yes (given that those were real stories, I tried to stay true to the story and give a "real world" answer. For example if the 8 point story was a complex frontend screen in the App, divided it in 2 stories of 5 and 3, dividing the screen development in two parts).

At some point some candidates even asked about QA considerations (something I did not consider initially), so we gave them some "advantage" (in the form of time, telling him that say, the stories had some QA in them, which could be split and maybe better accommodated).

The one thing that we were looking for was for candidates that not only filled up the scope until filling the time available in the project, but that went a bit further away.

My experience with startup projects has been that there is always not enough time to do all the required features, but the greatest value (and challenge) comes into prioritizing the tasks so that the team can deliver the mythical MVP on time, and then, perform additional iterations improving the product. This type of reasoning is what we were looking for as part of the output of the challenge.

Results From Applying The Challenge

In general, candidates that asked more questions produced a better result. We interviewed about 30 different people for the position and we had a very diverse set of responses.

Some candidates had a stronger technical background, and thus could leverage more the content of the stories. Other candidates had not so much technical background and leveraged more the business side.

In general, the challenge was a success, and in the end I remember we found the right candidate for the team.

Something important to stress is that, this like many other "technical" (in the sense of, having to implement something, in this case a plan) interviews tends to suffer from a "degradation of context" problem: When we created it, it was very clear for us that the evaluation consisted in not only the end product (gantt chart, or anything else) but the interaction and general process that happened during the 3 hours. If other people start using this challenge, it is important not to lose this context and only consider the end product for the scoring, as it will be misleading.

I've seen this happen in other types of challenges (specially ones that comprise programming something). Where inexperienced interviewers decide to apply the problem for an interview and score it as in a "black and white" given the program provided by the candidate.