I had my first talk! Juhuuu! Very nice. Super. Great feeling. And what’s best, from the feedback I received I’m pretty sure the audience liked it

I presented a 30-minute talk about the architecture of my child of 2017, Nyssetutka.fi. The presentation was part of the now annual Tietotekniikan yö, IT-night, organised by students of the Tietoteekkari guild and our lab, Pervasive Computing. You may find a summary blog posting of the whole event here (also, check out previous Tietotekniikan yö blog postings here and here). The evening was filled with interesting talks from a couple of companies (Futurice, SWD, Solita) and both our own and Signal Processing lab’s staff. IoT, PC++, CI, AI, ML, ethics of programming, ASICs, side-channel attacks, the story of maksalaatikko and so forth.

I went through both the server and client-side architecture of the application and discussed the various optimizations I’ve done in order to make the experience smooth for the user (caching techniques for the server, batching DOM work, splitting computations etc.). I also talked about the MV of the MVC and the usual one-way data flow you find from current modern JS frameworks. Moreover, synchronous vs. asynchronous work was discussed and what needs to be done in order to make the app responsive when you’re dealing with single-threaded JS engines.

In addition to learning some new things, I hope at least a part of the students in the audience got a good grasp of the importance of little (and not-so-little) side projects. I think they’re very important and one should every once in a while hack and tinker with something that’s not given by the teachers or employers. It doesn’t have to be big, just exploring new things will make you better at everything. I always want to learn more.

TB104 was packed!

Me speaking

The diagrams here are from my slides. I used them for high(ish) level architecture illustration. As you can see, they don’t follow any formal spec. But you get the idea.

The post My first talk [Mistä Nyssetutka on tehty] appeared first on Pietari Heino's personal website.

Grafana dashboard showing memory consumption reported by collectd/statsd/graphite

Notice the gap on the graph. That’s the time when my AWS micro instance went completely janky and stopped responding to everything and I had to force-reboot it from the EC2 control panel. What did I do? Very simple: running webpack build pipeline for my project’s static assets and it ate all the RAM. I suspect that it would have finished the build some time in the future (though not sure if this or the next decade) but after 10 minutes rebooting was the only option.

This blog post is just for those who might not notice the problem and try to google for answers as to why their perfectly working deployment tool hangs the whole production server from time to time.

This happened to me once last week and now for the second time. So basically 1 hang for every 40 deployments or something like that. I had no clue. But just when I was about to start googling it struck me: the server runs out of resources. This wasn’t completely obvious to me from the beginning because A the project is in early steps and I hadn’t configured any server monitoring before (if you look at the picture that tad over 16hours is when I actually started collecting the stats, no joking) and B I had made sure that the 1 GB of RAM on the server was completely enough to run the actual services I needed. It didn’t cross my mind that ~500 meg usage would rise so much when building.

The project in question is Nyssetutka which is a Tampere area public transportation web app showing busses and stops and whatnot. It’s still in early(-ish) development stage so I haven’t had the time to build a nice deployment pipeline and put all the usual checks into place and was funnily just setting up the collectD monitoring as I discovered the reason for the hangs. The app consists of a Node backend and static front end. The backend is run by PM2 because it works nicely and comes with customizable deployment “pipeline” (not really a pipeline). I’ve configured it so that the static assets for the front end are not stored in VC and every deployment always builds the front end files, installs all new dependencies for the server and starts the backend. This basically means a 30 second downtime for the app but that’s fine right now. This workflow gives me very fast iteration times and now that I have server monitoring in place (using Grafana) I don’t have to worry so much.

Hopefully this is of help for someone.

The post “node build.js” hangs on production server appeared first on Pietari Heino's personal website.