Falcon start with Polish satellite

I’ve just watched SpaceX’s Falcon 9 rocket liftoff. It took 64 small satellites (called cube sats) to Earth’s orbit. Among them was one that I witnessed being born over past few years. My two friends (@maciejt_nowak and @mandrek44) were part of a team that wrote the code for one of the first polish satellites (I think it’s the 4th one?). There was also hardware team from Warsaw University of Technology, overseeing this whole PW-Sat2 project.

Falcon went into space, released second stage with payload and then landed safely on the “Just read the instructions” droneship (nice name, right?). All as expected. What a time to be alive!

See you space cowboy!

Leadership and authority building training – overview

At the beginning of the year I was promoted to architect position. Well, it is more lead developer position, but architect sells better to non-developer clients so that’s what company went with. So no ivory towers, thanks God! With it came package of trainings that I have/should do. There will be some technical ones, but there are also dreaded soft skills trainings.

I say dreaded because I don’t think anyone actually likes participating in them. I mean – day or two out of work are cool and all, but usually somewhere in the middle of the first day I was finding myself thinking – I would rather be coding now. Don’t get me wrong – this is useful knowledge. Knowing how to communicate, how people work, how psychological aspects are affecting us – whether we want it or not (even: whether we are aware of it or not!) is a must. I also do part time recruiting at the company, so meeting other people, external to our organisation, is normal and I better communicate appropriately. But those trainings are usually boring, assignments done in groups are too long, to vague. Seems like all the knowledge could be condensed into 1-2 hour block and we would be done with it.

Last training I was at, touching topics like building authority and leadership skills, working with teams and (to some extent) managing teams – it was completely different. It was so good. Two days packed with knowledge, fun, short exercises, that had direct impact on what we do and discuss later on. Touching real problems that participants brought with them and sharing work-life stories by trainer – everything anchored in the topic and logical rules and groups introduced. Not only was this good from soft skills point of view – it was also good from engineering point of view! Trainer presented concrete knowledge, show us for example how teams are developed, how they change, what changes with them and how to approach teams at different level. And I think everyone participating had those moments where they thought: yea, I know that type of team, I’ve been there. I know I did, more than once.

At first I was afraid it’s going to go into manipulating teams, how to make them do stuff they don’t want to. I was wrong. It was all about communicating with teams and individuals. How to pass our knowledge to them, how to be clear and precise in telling them what we need of them. How to setup clear working framework and manage expectations. Most of all – it was about how help teams and people in those teams grow professionally.

It’s been more than 24 hours since the training ended. I gave myself one day to clear my head and let they hype ventilate. But even after that – I’m still in awe of how good this training was. How it clicked with my engineering brain, showed clear instructions – if you see this kind of person, this is what you need to do. Different type of person – approach them this way. Sure, we’re still talking to humans, so there’s some wiggle space and we need to approach everyone individually. But having a framework that prepares you for the direction things can go to and how to steer it for mutual benefit – that’s perfect.

I wish all future soft skills trainings will be done like that. Concrete. Precise. Based on experiences. And giving straightforward advices and rules to follow.

[Book] 4-hour workweek, Tim Ferriss

Recently I’ve read a book by Tim Ferriss “4-hour workweek”. Title is click-baity (and Tim kind-of admits it). But it is pretty honest, says what the book is about. And if it sells – I will not hold it against it.

In general – the book is nicely written, it reads fast, chapters are not too long and the content is of very good quality. Good job there! And I definitely agree with many points presented in the book. Automate stuff – no brainer. If something can be automated (or, even better, completely avoided) to save time – do it. Outsource stuff – to some extent it clicks. Avoid clutter, junk information diet etc. Hell yeah! I try to do that (to some extent) and fail way to often, but I will keep pushing.

What I have problem with is the general idea Tim is trying to sell. That you can work 4 hours a week and have a good, fulfilling life. While that may be option for some, it definitely does not sound like something everyone can do. Someone has to do the heavy lifting, baking bread, cleaning up, cooking or coding software. Is all the work we do necessary and valuable? Heck no! Buch of stuff is being done just for the sake of doing it. Consumptionism is full-blown disease of our times. Some people like to present themselves as working 60 or even 80 hours a week. Some people really do work that much! Hell, that’s no way to live your life! But if everyone worked 4 hours a week we would be nowhere. We would achieve nothing. It may be the way to get money for some, if you can create something that can sell well to many people and at the same time not require much work to keep it going. But that’s something only few can do.

I liked the book. It is worth reading, I think. But at the same time I feel like I’ve been conned. I payed for the book and helped Tim make his 4-hour workweek work – even when I don’t agree with him completely. Good play, Tim! ;)

What is origin/master, or how to update to latest changes in git

When using git, there are few concepts that are hard to grasp at first, but are (in my opinion) required to get fluent with it. It does not matter if you are using GitHub, BitBucket, Gitlab – figuring out how it works (at more than basic commit/push/pull level) will be very useful when you will try to set up your workflow or when you find yourself in a corner.

One of those concepts I think is – what is origin/master? How does it differ from master?

Collegue of mine had a problem where he could not reproduce issue with code. We thought it may have been related to latest changes on master branch, that were not included into his branch. But he insisted that he in fact did merged master branch changes. Spoiler: he did not.

What my collegue was doing was: git merge origin/master. Now that’s perfectly fine, I said, but you are not getting latest changes that were made by others in our team. “But I am calling origin/master, so I am getting latest, freshest code, right?”. Nope, you are not. origin/master is not latest code. It is latest code since the last time you contacted origin server.

Here’s how it goes. You contact server sometime, usually when you are doing operations like pull, push, fetch. Then your local copy of repository gets latest code changes, updates your branch pointers etc. But – not all pointers. Just those that are reflection of server state, like origin/master, origin/nasty_bug_solution, origin/new_fancy_feature etc. But your nasty_bug_solution branch will stay unchanged – unless you will merge changes (or you are doing pull which merges changes automatically).

So now you have your latest version of code, you are at the same place where origin server is. But that’s not forever. In a few minutes your collegue may add something to master branch and whoops! you’re out of date. But that’s OK, that’s cool. That’s what makes git – git. You can work offline with your branches, not requiring asking server over and over again what’s going on there. Just keep in mind that when you are doing git merge origin/master – you are checking and merging your local version of branch, last state you have seen on server, not what is there now.

In graphics above you can see how it flows – unless you do git fetch (or git pull which fetches underneath) – you won’t get server status update. You can merge all you want – code will still be in the state it was.

So if you want to update your branch with latest-freshest master copy – do git pull and git merge origin/master afterward. That’s the way to success!

Or, if you are feeling frisky, you can try git pull origin matser – pull changes from server origin, branch master on that server, and then merge those changes into my current branch. But that’s only for the bravest! Will you dare?

Custom TypeScript typings not recognized

For a while we got problem in our project where TypeScript typings (*.d.ts files) were not recognized. This resulted in many failed builds. Solution was rather straightforward – reference those files directly, for example by code like this:

/// <reference path="shared/my_custom_typings.d.ts" />

While this works – it is far from perfect – those typings should be automatically recognized.

Turns out when bumping typescript version at some stage they did introduce a change. While in older version directory structure like this was OK, in newer requirements changed – and so our directory structure had to follow.

We had to move our d.ts files into dedicated directories, one for each typing, following structure something like:

+ shared
    + my_custom_typings
        - index.d.ts
    + my_other_library_typings
        - index.d.ts

And with that we could get rid of all reference directives as they got loaded automatically (of course there still has to be some kind of indication where to look for those common, shared typings – set it up in tsconfig.json!)

Inclusive job interview or fighting for your job

For past year I have been working (partially) as technical recruiter. This lead to some nice and some weird experiences, but mostly has been very interesting – sitting on the other side of the table. While the process of recruitment is not perfect, we are trying to make it more open, inclusive and make sure people are going out with something: either an offer, or at least info about what was missing in them, where they are not lacking – but have some holes in skillset that is required for the position. Some skills, that people do not have at the moment, can be quickly learned. Others are more complex and people just didn’t make it – that’s how life goes sometimes.

Recently we’ve had discussion with fellow technical recruiters. We’ve touched few topics, all opinions were very interesting (mostly because quite different from mine). But one opinion struck me. Colleague said that he is very dissatisfied with job interviews that are nice and easy. What he said is that getting offer after nice interview, where everyone was not only respective but simply goes out of the way to make you feel included, and where there are no trick questions – just does not feel satisfying. That this is too easy. He expects that job has to be obtained through hard talk, complex questions, maybe trap question here and there. He has to sweat to get through it.

This feels totally weird to me. I understand feeling stressed out on job interview, it is hard to avoid. Someone is judging you, your skills, you are sitting in foreign space, unknown people. Hard to not sweat a little bit (use antiperspirant!). I however love it when people are open, happy to talk to me, are going out of their way to make questions clear and well defined. Do not try to trick me and prove me how unworthy I am of taking software engineering position at the company they are recruiting me to. Bleeding through interview is simply wrong to me. Why would I want to work with people that are trying to squeeze me out of my bucks (that’s the whole point of job interviews with tricks etc. – they still want you if you fail to answer some of those, but this will go against you when going to money part of interview).

If you are interviewer – I urge you to be nicer, more inclusive of people. Lack of skills, holes in knowledge – we’ve all been there, none of us have been born with our current skill set. It is OK not to hire someone, but it is not OK to make them feel wrong about it.

We are not hiring coding monkeys. We are not hiring spec-ops soldiers that have to work under top stress conditions. We are not hiring robots.

We are hiring humans.

Idempotent changes

I finished chasing a bug in code few days ago that took me a while to understand. What happened is – system failed because it expected to have one value matching search criteria, but it found multiple. Two, three, up to four in some cases. That should not be possible, violates business logic. It should violate SQL Server constraints as well, but for one reason or another those were not in place.

The source of a problem was the fact that, when importing data from external source, system tried to add default value to some list. In case of failure, it did retry few times. Each time it added default value. In our case, there were three retries due to system setup, so we ended up with four default values in a list.

Why did that happened? Multiple reasons. Retries called code to setup defaults etc. at every retry. The code that inserted those defaults were not made aware that such thing could happen so it assumed default has to be added.

It is, first of all, lack of communication and clear design from the team as a whole. Should defaults be clearly marked as being called every time – team would have avoided this mistake. But this is hard.

One big thing that everyone on a team could do is – whenever possible, write code to be idempotent. Do not introduce side effects when not necessary. If changing value triggers event in system – check if value was not already what you are trying to change it into. If you are adding something to the list – check if it’s not already there. If you need to make call to external service – check if value is not already downloaded.

Not only it may save operation time in some cases, it may help avoiding bugs if someone unaware tries to use method incorrect way.

Dealing with project failure as a team

Sometimes our projects fail. How we, as a team, and our managers and leaders deal with it is very, very important. We can learn from what happened, we can try to figure out what went wrong, what needs to be improved in future projects. It also decides how team will feel and how they will approach future endeavours.

This post is inspired by story of one of my fellow devs. They recently finished a short project for a client. When they were starting few weeks ago, no one was willing to work on this project as everyone thought deadlines are impossible to meet. Requirements were complex, team was not too familiar with the domain etc. And here comes manager, not technical guy, spending his time convincing the team that this is easy, doable, they can achieve it. Complex requirements are not that complicated and everything can be simplified. In the end, one dev said that yea, he can do it. He started working on the project.

Soon, of course, developer realised that this is at least as complex as everyon initially thought, starting putting in more and more hours into project, working 12 hours a day. Others on the team started staying long hours to help collegue.

When final date was close, manager came in, said that everything is cool and they can leave at 4pm, not to worry about anything. And some of the team did. Others decided to stay late and finish up the project.

On Monday there was demo for client. Demo apparently went well, client was happy, however product was mostly smoke and mirros, not fully implemted. It happens, right? Underestimated complexity, short deadline, team with not deep enough knowledge and no domain expert available. But – they pushed, they delivered something so it is not all down the drain. Or so I thought listening to the story.

Next day, manager came in, shouting at everyone, taking away bonuses from people that left on time on Friday (that is, after 8 hours of work). He blamed the whole team for the failure, not taking the blame on himself. This is ugly, I think. Team initially did not want to commit to the project as they thought it was not feasible to deliver it in given time frame. Team warned manager. And they only started work after manager worked hard to convince them that they are wrong and project is easy. Team did not deserve this kind of treatment after finished project, despite its potential failure (client was happy, I remind you, even if not over the moon – at least content). Taking away bonuses, screaming at people only because they left on time, exactly like manager told them too. And not taking into account that they spent a lot of time working overtime trying to deliver the project – that’s ugly, ugly managing of people. Definite red flag if you ask me.

But that was not the end. What came next strikes me as pure sociopathy. Manager told the team, that they need to pick one person who’s most responsible for project’s problems and this person will get fired. Yea, you got that right. Team has to pick someone who will loose their job. Like it’s some kind of big brother or shit.

Isn’t it crazy? I mean – isn’t that, at the very least, manager’s job to manage people and decide who to fire (although in given situation I don’t think anyone, except for maybe manager, deserves to get the boot)? How toxic is the situation with the team now is hard for me to imagine. What will happen when next project will have problems (which eventually will happen). Who will get fired then? Should I bring pizza for everyone next Friday so they will feel bad if I make any mistake and will not fire me?

This manager decided that people on the team are his resources. Cows, giving milk. And if one cow seems to not give enough milk this week, not only will he turn this cow into hamburgers, but he will make other cows look.

This is not how managing people works. This is not how anything should work, not in development teams, not in any other kind of work. Seems like this, so called, manager is not only completely untrained to do his job, he is also basically evil and unfit for any kind of people-contact position.

What he thought he was, is the king, allmighty.

What he should have thought about himself is being a good leader, showing the way and solving problems, not creating ones.

ASP.NET Core –launch-profile and launchSettings.json

How to start application in ASP.NET Core from command line?

dotnet run

How to start application in ASP.NET Core in development mode?

set ASPNETCORE_ENVIRONMENT=Development
dotnet run

How to make it one command? Use launch profile, available in dotnet run command. But to make it work, there needs to be launchSettings.json file with profile definition, i.e. what needs to be done for application to run.

Definition I am using, inspired by web, is this:

{
    "iisSettings": {
        "windowsAuthentication": false,
        "anonymousAuthentication": true,
        "iisExpress": {
        "applicationUrl": "http://localhost:5000/",
        "sslPort": 0
        }
    },
    "profiles": {
        "Dev": {
            "commandName": "Project",
            "launchBrowser": true,
            "launchUrl": "http://localhost:5000",
            "environmentVariables": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            }
        }
    }
}

And to launch it in Dev mode all I have to do is:

dotnet run --launch-profile 'Dev'

And… it fails, saying it cannot find this profile. That is because what I did is place the file next to .csproj file. Seemed obvious. Well, it should not. Where this file needs to be is in Properties directory (\Properties\launchSettings.json). With this layout – it works perfectly fine. fine.

Game graphics scaling

In game I would like every player to have more or less the same game experience. And, most importantly, I want players to have the same chance of winning, and not limiting players’ skills based on their devices etc. One of the things that need to be handled is visible game arena size. Ideally players with ultra HD screens and players with smaller laptop screens with 1600 over 900 for example should all see the same part of game arena, to not make players on bigger screens have it easier to spot enemies. This means there needs to be standard game size defined. But that would mean that some players would have only part of their screen space used for game, while others would have to scroll to see whole content – that makes terrible user experience. Scaling should solve the problem!

OK, first things first. I have to define base game arena size to server as reference. On screen with this resolution scaling factor should be equal to one. This could possibly be any set of two numbers (width and height), not corresponding to any particular screen size, but I’ve decided to base it on my full hd screen, or to be more precise, on my canvas size on Raim page – 1600 over 861 (with some space being taken over by address bar, developer tools, icons etc.).

var originalSize = { x: 1600, y: 861 };
var scale = 1;

Then, it is time to scale canvas on page when size of browser changes, so that resizing window will cause scale to change.

var resizeCanvas = function () {
    var arenaElement = document.getElementById(arenaHandler);
    var widthDiff = originalSize.x - arenaElement.offsetWidth;
    var heightDiff = originalSize.y - arenaElement.offsetHeight;

    var aspectRatio = originalSize.x / originalSize.y;
    var w, h;

    if (Math.abs(widthDiff) > Math.abs(heightDiff)) {
        w = arenaElement.offsetWidth;
        h = w / aspectRatio;
    } else {
        h = arenaElement.offsetHeight;
        w = h * aspectRatio;
    }

    canvas.width = w;
    canvas.height = h;

    scale = canvas.width / originalSize.x;
};

(function init() {
    ...

    var arenaElement = document.getElementById(arenaHandler);
    viewport.x = 0;
    viewport.y = arenaElement.offsetHeight;

    canvas = document.createElement("canvas");
    document.getElementById(arenaHandler).appendChild(canvas);
    resizeCanvas();

    window.addEventListener('resize', resizeCanvas);

    gfx = new raimGraphics({
        canvas: function () { return canvas; },
        viewport: function () { return viewport; },
        arena: function () { return arena; },
        scale: function () { return scale; }
    });

    ...
})();

Calculating the scale is not too hard. There is aspect ratio I want to hold (calculated as width divided by height). Given that, if I have new screen width, I can calculate screen height by dividing width by this ascpect ratio. Holding aspect ratio will ensure that graphics don’t get distorted in any axis (e.g. circles do not turn into elipses). The calculation formula is simply taken from proportion:

newWidth / newHeight = originalWidth / originalHeight
newHeight = newWidth / (originalWidth / originalHeight)

With new scale calculated, drawing graphics is as simple as multiplying every coordinate by this scale, for example:

...
x = player.Position.X + args.viewport().x;
y = player.Position.Y + args.viewport().y;
drawingContext.arc(x * scale, -y * scale, player.Size * scale, 0, 2 * Math.PI);

...

var x = points[0].X + args.viewport().x;
var y = -(points[0].Y + args.viewport().y);
drawingContext.moveTo(x * scale, y * scale);
for (var i = 1; i < points.length; i++) {
    x = points[i].X + args.viewport().x;
    y = -(points[i].Y + args.viewport().y);
    drawingContext.lineTo(x * scale, y * scale);
}

x = points[0].X + args.viewport().x;
y = -(points[0].Y + args.viewport().y);
drawingContext.lineTo(x * scale, y * scale);

Easy! Is that it? Well, no. There is also user input to be taken into account – mouse movement and mouse clicks are used in application and game required coordinates to be handled in game world coordinates, not screen coordinates. So what needs to happen is – mouse coordinates have to be scaled accordingly. Does this mean multiplying by game scale?
No. Since I’ve stretched game twice (for player with big screen) and user clicks in coordinate [10, 10] on the screen, it must be [5, 5] coordinate in game world (remember – game world got stretched two times). It makes sense – if I put stuff onto the screen, I multiply it by scale. If I get it from back the screen, I have to devede the value back by reversing the operations.

var inputChange = function (input) {
    var player = getCurrentPlayer();
    if (player == undefined) return;

    input.mouse.x /= scale;
    input.mouse.y /= scale;
    input.mouse.x = input.mouse.x - viewport.x;
    input.mouse.y = -input.mouse.y - viewport.y;
    ...
}

And just one more fix – in my calculations of viewport I was taking canvas size into account. Since canvas account is no longer a real game world size, I cannot take it into account. But thankfully there is game world size already there – originalSize, so that makes viewport calculation really easy:

viewport.x = originalSize.x / 2 - currentPlayer.Position.X;
viewport.y = -originalSize.y / 2 - currentPlayer.Position.Y;

And now game scales on every window sizes!