Rainbow Log

Inspired by: I thought console.log() needed some more flair and Benargee/rainbowLog.js

console.rainbow = (s) => {
    const [cs, c] = s
        .split("")
        .map((c,i) => ['%c'+c, `color:hsl(${20*i%360}, 100%, 50%)`])
        .reduce((p, c) => [p[0] + c[0], p[1].concat(c[1])], ["", []])
  console.log(cs, ...c)
}
console.rainbow("Hello World!")

Kessler Bomb

Kessler Bomb

Siege Weapon

Deployed in low orbits around hostile planets.

On deployment millions of projectiles are scatters in random orbits around the planet, taking out all satellites after a few hours. The shrapnels will make launches from the attacked planet impossible for several decades.

Primarily used to lock down planets with offensive capabilities.

Prohibited by the New Geneva Convention, due to the high collateral damage

Thoughts on Development Time Estimation

Estimating development time is similar to the coastline paradox. The more detailed your project description gets, the longer you estimation will be.

Graphic by: Acadac

You start with "building a blog will take me 20 hours", then go to "OK actually I will need 10 hours for the data structure, 10 hours for a way to create posts and 10 hours for the actual website". For each of this estimations you will end up with more hours needed the further you break them down.

Breaking tasks down reveals more of the complexity of a task, leading to higher (hopefully more accurate) estimations.

Global Climate Strike

Debugging Web APIs with session based authentication in Postman

• Open the web app in Chrome or Firefox and open the Developer Tools (F12 or Ctrl+Shift+I).
• Login and look for an API call in the Network Tab of the Developer Tools.
• Right click the request and select Copy -> Copy as cURL

• Open Postman and use the Import Button -> Paste Raw Text

• You can now execute the same request as done in the browser.
• Start modifying it and happy hacking.

#debug #web #postman

Lessons learnt: First Hackathon

• Be prepared. In my case the material was sent out a week beforehand. Use the time to setup your machine(s) and code base so you can start directly.
• Do research on the topic. I've not looked into state of the art algorithms for the problem beforehand. This cost me a lot of time in the Hackathon, to understand the algorithm we used.
• Have compute resources ready. I could have used 2 further machines, but forgot to setup ssh, Teamviewer or any other remote control on them.
• Do whatever you know best. Some of my team members had far more experience on the topic than me. I've tried to follow there example, which wasn't successful. I think I would have been more successful using more basic approaches (which I have enough knowledge about) than trying to follow the "state of the art" approach. At the end I've tried to support them as best as I could (mostly doing evaluations).
• Push for more organization. We quickly came to the conclusion that only 1 or 2 approaches (transfer learning on common models) would be feasible in the short time of a hackathon. This led to us being rather unorganized. Everybody tried to get the models running as fast as possible and tweaking them the rest of the time. I think we could have produced more insight on the topic with regular "stand ups".

AutoTexture

I've built a small tool to create tileable, seamless textures.

https://autotexture.libove.org/

Commute to Work

[Helsinki] View on City

[Helsinki] Serenity