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.
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.
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:
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.
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.
Around 2005 virtualization already was working nicely, and at work, as we did .NET consulting, we started using virtual machines (with Virtual PC) as our main development environment. We would have a base VM snapshot with a Visual Studio, and then when starting a project we'd just clone it and add specific requirements (e.g. SQL Server). It was pretty much manual but still a great improvement over having to clean or even format your host machine between projects. Also, migrating to new hardware was seamless, just copy the VM image and good to go.
Now, things have evolved a lot, and having switched to a mostly opensource stack and Linux development environment there's a wider array of options, plus greater automation capabilities. I've never been directly involved in the management of development tools resources or projects (except one or two small scripts) until recently, but I've tried to use whatever environments they provided, with varied results.
Keeping the "optimal" scenario of having everything on your machine (is the fastest and quickest in the short term but has lots of disadvantages too), I moved from manually managed local VMs to having remote dev machines, where you would rsync files, SSH when needed to restart a process, and usually deployed your code to another location (being web dev, mostly having a local dev with your kartones.localhost.lan and remote webserver like kartones.xxx.dev). This approach is not bad (as worked for me for quite a while and in multple jobs) but has two big disadvantages:
Being few people the remote dev machines is a good approach, but as you grow it becomes a severe limitation.
So, how do we solve this issues? Well, thanks to Virtual Box, Vagrant and Puppet we can now easily have provisioned development virtual machines: Local but instrumentalized VMs that closely match a production server and whose configuration and installed packages are managed from the same tool that setups production machines, just requiring different config sections (but mostly being a copy + paste + rename task). I've lived three iterations of this approach at different jobs, from a quite manually (and badly working) version, to a "working but not smooth enough to replace a local dev env" and to my current job setup, which works so nice we now don't support anything excepting the devbox.
It took us weeks of iterating and forcing the whole tech team to install it by themselves, just following the README instructions and providing either feedback or directly commits with improvements, but feels worth it because:
We bet so hard on having this process quick, easy and painless that if I was allowed to, I'd setup the devboxes to self-destruct after 2 weeks of use, to force everybody to re-install them and be always sure that no matter what happens, you can reprovision and have a working dev environment in a few minutes. I manually do delete mine (including the code repositories) and you feel at peace and calm when you just do:
And this is just the beginning, now with containers with Docker & the like we're moving towards an "optimized" version where you can replicate something really like production, in your local machine, with disposable instances, always updated (and using the same mechanisms than production, to avoid nasty errors) and doing a much better resource usage. But I have not talked about them because we haven't yet migrated to containers, so I have much to learn and experiment before being in a position to give an opinion, I'm just eager to try it!
As now I travel to work via underground, I have more time to read. The first book I've fully read is Code, from Charles Petzold, and I really encourage anybody wanting to learn how computers evolved up to late 90s to go grab it.
Author: Charles Petzold
Although the description of the book is a bit dumb, the title hints the contents: Learning from where do computers come, at both hardware level from morse code and the telegraph to current computers, and software level from raw circuit-based "programming" to assembler and high level languages. One note needs to be made, as the book was written in 1999 some technologies have changed (and even dissapeared), some numbers are obsolete and in general you shouldn't expect the book to teach you how an SSD hard drive work, but more instead a deep but general overview of the fundamentals of a computer.
The hardware level is what takes most of the book, starting with morse code and the telegraph to teach us basics of both data transmission and from where the integrated circuits come. This is the biggest and I guess hardest part to learn, because it is like taking your first half of the first year of university of computer science inside a book: Electronics, circuits, boolean algebra, binary, octal and hexadecimal systems and conversions... At least in Spain you learn this contents in 3 different subjects, so be prepared for some heavy circuit diagrams and calculations to repeat if you don't already know the topics. It is also the most beautiful part and where you will learn most of the amazing evolution path to personal computers.
The softwar level sadly suffers from having much less space, and while the internals of how old operating systems worked, how to manage files or input and output devices or how to draw pixels at old monitors are really interesting, I feel like it could have had a few more chapters digging more into details of old OSes, more old programming languages, etc. We learn about Assembler, C, LISP and a few others but very briefly (except ASM). Also some chapters are a mixed bag, where you are told about screen resolutions and then jump to digital audio, then disk storage... surely it is all I/O but I would have prefered a clear separation. That said, it is still great and I've learned some interesting facts.
Nostalgia also kicks in for me, but having lived the AMSTRAD PC/W & CP/M era, MS-DOS and the surge of GUI-based operating systems, I really enjoyed learning how simpler computers designed the hardware interruptions mechanisms, loaded the BIOS, why Macintosh was always different from PCs and other low-level details not usually taught anywhere else (at least condensed and in a simple language).
Really recommended read, mandatory if you like to know how things work under the hood. And also curious to read 17 years later and see how some technologies have been surpassed and their limits solved.
The ZX Spectrum was a classic from the eighties, with its long loading times and 15 colors. It wasn't the fastest nor the best but it definetly had really good games and it's relatively cheap price made it common when I was young (before videoconsoles took its place).
While I don't have much time to learn how to code for it (and if I had, I'd focus on learning more original GameBoy development), I love when people write tutorials and/or posts about how certain stuff from old machines worked, and I just found some jewels which are also quite up to date (as a matter of fact, the author is still writing posts in the series). Just take a look at them and learn how things worked in the Speccy, and how more actual techniques can be applied to squeeze some extra speed or improve the development process:
Also, I went on to read a bit about the sprite color glitches and found that after the link's main article, in the comments section there are a few examples of how to minimize the problem, make sure not to skip them as the article only mentions the issue but doesn't provides solutions.
The full toolset to develop for the spectrum can be found at https://github.com/jarikomppa/speccy, including some custom-made tools, an image conversor for the Spectrum, and even a sample game, Solargun.
An interesting game programming library recently made is libzx; It provides drawing and buffering techniques, fonts management, keyboard handling, audio and music... Definetly worth a look.
Another toolset I've found is the spanish La Churrera, which includes not only a C framework but also tools to manage graphics, sound, and even a map editor.
Update #1: Added img2spec repo link.
Update #2: Added libzx library link.
Update #3: Added La Churrera framework link.