Last year I did have too much time on my hand, and while I spent a lot of time chilling, I did miss using my brain at least a little. So I worked on these two challenges. Exercism #12in23 I am a big fan of exercism, which is a site with exercises to learn all kinds of programming languages. The quality of the tracks varies a lot, nonetheless the most popular ones are very useful. There is also a mentoring element, which I haven't used myself. ...
"One click" deploy (*) Recently our CEO Raj Kumar spent a week in our Barcelona office where the majority of our engineering department is located. I was working on some ideas for him to meet the team and get some insights into our daily work. While most of the company is aware of UI/UX and front-end changes we are doing to our site, some of the back-end and infrastructure work can seem like black magic. I think it is important to take every opportunity to bring this output closer to the rest of the company and especially the leadership. By chance I watched the very good presentation “Getting Real about Managing up” by Kellan Elliott-McCrea, which contains as one example the idea of letting your CEO deploy to production. One of the goals of our engineering team is continuous deployment. I set this out when I joined Devex to give us a far goal to aim for. I was inspired by Etsy’s Code as Craft blog and the book “Web Operations”. For me the important part was not continuous deployment itself, but all the changes in engineering culture required to achieve it. You need a good technical base from unit to integration tests, infrastructure as a code, continuous integration and a infrastructure team that is working side by side with the developers. At the beginning this seemed to be an impossible task, QA and deployment were completely manual, there was no unit testing, no code reviews, a clear separation between developers and operations. The code itself was a mess too, with lots of moving parts, outdated libraries and no easy way to introduce testing. But we slowly made progress, simplified the system and slowly worked our way up from deploying once in a blue moon, to once, then twice a week. Currently we are at one deploy a day, with some manual involvement of QA. The deployment gets kicked off by a chatbot and is well documented in our engineering handbook. The short version looks like this: Check QA status Tell the chatbot to deploy Check the metrics Everybody in the engineering team is already in the rotation of deploys and it is easy enough for everyone in the company to do it. Our CEO Raj Kumar was happy to do it and sat together with our two infrastructure engineers to help him along. Because there are some permission requirements it was also easier to do it from the workstation of our lead engineer. After some hiccups in QA the progress went smoothly and we had a new release in production. I guess in the end he was surprised how boring it turned out to be. Which a deploy should be. btw: we are hiring: Check out our current open positions *) the hat is part of the deploy protocol and not a fashion statement
It is fairly common that you might be contributing to multiple git repositories which make different git configuration necessary. Mine and probably the most common case is that I am using different contributor email addresses for my private and work git repositories. You might also want want to have separate global git ignores or other options that differ in multiple repositories. The way I do it is having one <span style=“font-family: “courier new” , “courier” , monospace;">~/.gitconfig which looks like this: ...
When I joined Devex a bit more than six years ago most of the code base was in one large monolith. This monolith was based on Ruby On Rails and was responsible for delivering devex.com. urn This part was called "neo". I guess because it was a rewrite of a previous Java version. I am not sure if it was a reference to Matrix or the Greek meaning. There were already some initiatives in place rewriting parts of it in different services, but the monolith was always looming in the background. Any changes to it required increasing amount of work. It was like someone tried to put the definition of technical code into code. I generally against rewrites, they tend to last for years and you loose a lot of knowledge that is baked into the original. I also have nothing against Monoliths. So I tried refreshing the code base by upgrading the dependencies, getting the few tests to run and making local development easier with Vagrant. I realized fairly early that this was not going to work. So we went with a gradual rewrite. Whenever we worked on part of the site we migrated it to our new architecture (Also a Monolith or at least a Duolith). Now six years later we finally switched off the remainders of "neo" and I thought we should celebrate in style. Legacy code is after all something that successfully supported you for a long time and enabled you to start with something fresh. Devex wouldn't be were we are without "neo". Cremation - ignore the dog So we staged a proper funeral, where everybody who wanted said some words. We also collected printouts of the most annoying bits of code, some very dated looking screenshots and some email and chat conversations from the very beginning. This was my eulogy: Today we say goodbye to maybe the best known system at Devex.+ Neo - from Greek meaning young or new, which he was neither. Or from the Matrix character, handsome, powerful and agile, which he was also not. We all have memories of him that will stay with us for a long time. We laughed about his quirks. He had amazing depths, which brought us sometimes close to tears trying to understand him. His heritage will live forever in our data structures. Finally we burned the printouts, collected them in an urn (aka hummus glass) and cheered with Cava while chatting about the "good" old days. I hope you can give your legacy code also the sendoff they deserve. The End Update (March 2020) We got a present from our CEO while he was visiting the Barcelona Devex office this week.... RIP Neo Mug