Kartones Blog

Be the change you wanna see in this world

Good lessons learned from past jobs

We sometimes are too negative and forget that many times there's also a bright side about most situations. For example, when we don't end nicely a work relationship, we tend to only remember what went wrong (if it did, that is). This post is a small recapitulation of good things I've learned on each and every past job, no matter if it was overall a good experience or not.

At my first job, Eidos (now Alhambra-Eidos, and NOT the videogame publisher) I had the luck of directly learning a good way to build software: 3-layer applications, separation of web templates and code, SQL Server stored procedures instead of SQL in strings, distributed components... They also hosted for free one of my defunct websites for many years.

At the second job, Surfernet, I did some of the coolest projects: A full MSN Messenger client from scratch (fully implemented the protocol), a Winamp-like MP3 player, and other nice applications with fancy graphics using Win32 API. It was physically exhausting (I worked from 8AM to 1PM, + going to university until 9PM) and schedule was always tight (usually projects took 1,2 months max.) but I learned a lot.

At the third job, I mostly developed the sense of teamwork. Development was a tiny fraction of the company and not well cared about, but the four of us took the daily job with tons of humor and smiles up to the day we left.

ilitia was the 4th job, and I lasted there for 4 years. On one side, it was a job where I matured a lot: Long times in a client, dozens of projects built in quite varied languages ranging ANSI C to advanced C# (.NET Remoting, threading in the pre-C# 2.0 era, ...), first time ever doing testing (even TDD!), setting up a .NET continuous integration server, my first usergroup and event talks (giving the first one in front of 200 geeks was really scary), even managing a small team of two people in my last months... On the other side, lots and lots of fond memories, parties, friends made (some of my best ones come from here).

Then came NAVTEQ, an important milestone because I got out of consulting. I learned to fight for what I think it is right, whenever it is the appropiate programming language (instead of a random management decision), pushing for rewriting components, or daring to peek into heavy algorithms-related code (I optimized an A* component). It was also the first time I had to talk in english at work but outside of events/talks.

Nokia shutdown NAVTEQ Madrid offices, and I ended up hired at Tuenti, another place where I've been almost 4 years. Here I got way out of my comfort zone, switching from a full .NET stack to a LAMP one (but hey, at least was object oriented PHP!). By far, Tuenti is the place where I've learned most and quickest, pacing being so fast that we joked about 6 months there being like 2 years at any other company. Lots of high scalability concepts, watching a website grow to millions of users and huge numbers of visits. It was a monolith but it worked nice and we were better than Facebook in Spain for quite some time. The "work hard, party hard" motto was 200% true, but I would repeat the experience without a doubt.

Minijuegos was the seventh job. Wanting to go back down to building big chunks of something from scratch (or almost) I joined. Between three people (CTO, a junior dev and me) we were able to fully build an online games portal, avatar generation system, CMS, APIs, payment gateways... I was able to put into practice theory learned in the past, work with asynchronous jobs... and work for once in something related with videogames! (my childhood dream). Things slowed down and tasks weren't so challenging but I did my "Mr. Wolf" role, got "version 1.0" done and made some good friends there too.

CartoDB (Vizzuality in 2014) was another radical shift, ditching my PHP and MySQL knowledge to start with Ruby (on and off Rails) and PostgreSQL, and this time moving to a full backend engineer role. There I learned a lot about databases, importing big amounts of data, manipulation and transformation of data, heavy DB-related operations, developing and maintaining APIs, and lots of interesting concepts of mapping and GIS (although I only grasped that world). I'm happy because I think I was able to hold up with a big part of the backend, alone for a while and then with some great colleages once we grew.

And now, The Motion marks the 9th job. I have lost sight of my comfort zone: now I'm working with Python, microservices, containers, AWS, managing a small team... And getting for once deep into devops tasks... We'll see how it goes ;)

Book Review: Speccy Nation

Last month I forgot to post anything so here comes one of the books I read some weeks ago, Speccy Nation. Small, cheap and not especially good, but hey, I paid less than 2€ for it so what could I expect...


Speccy Nation book cover

Title: Speccy Nation

Author: Dan Whitehead

A small 124 pages B&W book about 50 ZX Spectrum games chosen from a British perspective. Nothing less, nothing more. Some are terrible games (chosen on purpose), some are really good classic ones, but I really miss international games, as for example Spain had lots of really good titles.

The writing is good, even in the case of really straightforward and even simple titles, knowing when to simply explain how the game worked and when to expand with what made it really different from others.

Some chapters about the Spectrum itself or its history would have been welcomed, but we get exactly what we're told about. The description of games vary in length, some being a bit small (1 page including a screenshot) others being 2 pages long, sometimes they feel not extense enough and in a few cases you don't even get to know exactly how the game was played, but is the exception, not the norm.

Overall, a really cheap title so if you feel nostalgic is a good quick read to maybe grab ideas of some games to play (if you're able to get them).

Migrating from BlogEngine.NET to Pelican

Last weeked I found some spam at two of my BlogEngine.NET blogs. It is not the first time, and in the past updating to the latest major solved the issue, but this time I had to switch from 2.9.X to 3.2, and I already suffered a migration from 1.9 to 2.0 that gave quite some headaches. One of my main reasons to go far away from Wordpress was to stop this tiring battle between spammers and new versions, that forced you to update way too frequently or face serious security bugs and spam-holes. Combine that with a general feeling of being tired of big, admin-driven blog engines, and I needed a big change.

My premises were:

  • Administration fully optional: even prefered not to have one
  • Static site generation: No more security issues, plus FTPing the changes once or twice per month is more than enough considering my posting frequency
  • As less setup requirements as possible
  • Local testing: Including (for the near future) Windows support without extra effort
  • Favor Python 3 over other languages: I want to improve my Python n00b skills and the best way is to use it as much as possible

Reading some articles and checking some static generators, I found Pelican. I peeked at bit at the source code, documentation and plugins, and it looked quite simple. Did some local tests, wrote some posts using existing content and read the documentation, and decided to keep it.

The setup is so easy I got a blog running locally with some base theme in a few minutes. But I had one issue, all my posts are in XMLs (thankfully I had chosen not to use a DB for storage) and Pelican uses Markdown... so I had to transform the data somehow.

I don't do too complex stuff like <meta> keywords and I set some post tags but not even show them, so in general I just needed a few fields for the pelican post format:

Title: ...
Slug: ...
Date: ...
Tags: ...,...

...CONTENT (which can be directly HTML)...

The XML has a very simple structure, with all the fields and just HTML-encoded the content, some regular expression searches and reverse transformations were enough to port everything. I have plans to migrate another blog, and prefer to be able to reproduce the whole migration any number of times, I built a small script. It only handles basic stuff and doesn't extracts other "basic" fields like authors, and only works with posts (I manually migrated the pages as I had few), but it does what it does well and might be of some use to somebody else.

You can find both my scripts and a small plugin (to limit RSS/Atom syndication feed output to only a certain amount of items, as by default dumps every post ever written) at my GitHub.

I'll probably work on more small plugins in the future, as I have some improvement ideas regarding output content generated, but I can't be happier with the results. A proper example of "the Python way of life", simple yet practical code, easy to setup and use and does it's job without many features.

UPDATE: Added another small script to GitHub to do some post-generation tasks like creating duplicates (as "aliases") and moving or removing certain files from the output folder.

Book Review: Building Microservices

Due to my new job I wanted to learn about microservices, and this book had good reputation and recommendations, so I decided to read it. After finishing the read yesterday, I can only recommend it to anyone starting with this system design principles.


Building Microservices book cover

Title: Building Microservices

Author: Sam Newman

I'm pretty new to microservices, but working in a startup means you usually have to ramp-up from not knowing something to being able to use it on a daily basis, and quickly. While I have an experienced colleage in the subject, I cannot be asking him always, so I grabbed this book based on some recommendations, and have been reading it& on commute time. And spoiling the review, I definetly think it is worth it.

I come from& a background of classic monolithic web-apps, a SOA platform and a mostly shared-codebase set of REST APIs and components, so for me it's a process of true discovery and mindset revolution to think in really small, bounded and clearly defined services. It is too easy to cross those limits and do more things in the same place, or by mistake create dependencies or couplings. One of the first services I built few months ago acts really as a distributed synchronous component, not honouring the microservices "autonomous" principle... So I have a lot to learn, but this book really has taught me how to do things better.

Always including real world scenarios and stories from the author, we're slowly introduced to the basic pillars of a microservices architecture, to the why, what and how to both build from scratch and separate existing systems into pieces, decorated with lots of advices and curiously not so many dogmas, but tips and "usual solutions" (but not mandatory) about approaches you can take. I like the fact that many books speak about "universal truths" where here the tone is more like "decide by yourself and take my advice as guidance".

Moving towards asynchronous processing and communications, how to handle code reuse, libraries and shared components, orchestation (or why is it good to avoid it), metrics, monitoring, cross-functional requirements, testing, deployment, security, scaling... There are so many concepts at first that the last chapter of the book is a "quick" summary that I think we should print and leave at the office as our small "microservices builder manual".

I had been told about some of the concepts, thought about few ones (but as usually happens with design patterns, not exactly in the best way) but the book provides lots of proper namings and topics you then can read more specifically about (like caching for resilience, synthetic transactions, consumer-driven contracts...).

I could go on longer, but I'd summarize it as a must read book if you work with microservices. Highly recommended.


"Keep It Simple, Stupid": A nice design principle, usualy forgotten in the development world.

Over the last years I've switched from the (flawed) mentality that whatever I should do must be perfect from the start to being more pragmatic and getting something build fast to then iterate. In the past, I tried doing all kind of mega-extensible pet projects, TDD-driven map generators, complex videogame attempts... and most of them lie dead in states between "not even working" and "proof of concept". Instead, I've built more "games" using only Javascript (hint: 2 dumb ones) and not caring about perfectionism. In fact, I have built quite a few things with almost or no tests, without complex design patterns or fancy language features, and aiming to have a working version in a few hours to then improve it.

This post is mainly a list of those small pet projects and tools, nothing to be proud of technically nor visually, but that really do help me optimize my time and/or ease some tasks. So, here comes the list:

  • A CSS-less web tools toolkit, using only Javascript
  • A bookmarks manager, first attempted using Javascript, later finding that mere server-side C# Arrays and StringBuilders did the job way faster... plus literally 15 lines of javascript to handle contract/expand groups
    Bookmarks web-app
  • A movies & videogames catalog, using only Javascript and the fantastic CartoDB CSV import and javascript SQL API capabilities . Just a search input and options to search games or movies
  • An internal Google-Analytics like poor-man dashboard, again using only Javascript and CartoDB's SQL API. This one has no security so I haven't even uploaded it, running instead locally (if you don't need it online, don't do it)
    Visits Dashboard web-app
  • A minimalistic Python 3 static site generator (including minimization of HTML) that outputs HTML, which I use to maintain my small portfolio site
  • A shopping lists mobile web-app, so that my girlfriend and I can "sync" what needs to be bought without writing and managing paper post-its. Pure C# in ASP.NET web forms with no code-behind and storage based on text files: files are the lists, lines inside the products, last space acts as delimiter of item state. Thanks to Bootstrap and jQuery works perfectly in mobile without any specific line
    Shopping list web-app
  • Small photos uploader, using PHP. Just some file upload inputs and items listing
  • Social media privacy housekeeping tools, using Ruby. Old tweets eraser, uploaded photos remover and other internal scripts
  • An instagram tag-based searcher that builds a crappy HTML with the results so I can quickly browse from my PC photos by tag
  • A Windows oldie but goldie batch file that performs backups (using 7zip) of local relevant folders and leaves the compressed files on an external drive. Hint: if compression is not worth the time, just store files (zip without compression), moving a few big files is way faster than many small ones.

And probably more small tools that I now don't remember, like snippets to generate base64 URLs for to embed images into HTML, hash calculators,... My goal as a developer is to make my life easier, because work already provides the challenges and hard thinking.

All of those took me between hours and less than two nights of coding to build an initial fully working version, and I sometimes evolve or improve little things, but from day 1 or day 2 I have something working. They usually are ugly as hell (and I overabuse Bootstrap) and some use jQuery while others have vanilla Javascript. Also, each is done in a different language, maybe because I wanted to toy with it, or maybe I was using it at work and wanted to train more, or I just wanted to change the language I code into often. The tool is not as important as the results.

One thing all this examples don't imply is the need to build everything from scratch, that would be dumb, it just means that for certain scenarios, you don't need to strive for perfection. I for example use a blogging platform not made from scratch but existing, but I simplified it a working but really old engine to the simpler, not DB-based BlogEngine.net it currently runs with. It has some tweaks and optimizations but maintenance is easy and a local copy for development required 3 minutes of configuring Internet Information Server at Windows.

In the end, what matters is to have something working and adding value, instead of a fancy 90% code coverage application that doesn't even have a single feature fully implemented. My "home code" won't win any award but it works great.

Previous entries