I’m fascinated by virtual machines. Along with compilers, Bach’s canons, or the Russian nesting dolls, they induce this unique kind of awe one feels when faced with infinity. A VMWare on Windows running macOS running VirtualBox running Ubuntu running Chrome running jslinux running… have I mentioned my Intel 8085 simulator? Okay then, what if told you that for an entire year I did all my work in a virtual machine? In the age of Vagrant and Docker, this might not come as a surprise, but this story has little to do with these tools.
“The Pragmatic Programmer: From Journeyman to Master” by Andy Hunt and Dave Thomas was published in 1999. It retains the status of one of the most well-respected works on the subject of programming craft. Despite numerous recommendations from colleagues and endorsements by the tech celebrities, I’d been procrastinating on this title for many years until finally giving in and reading it this January. While commonly commended for its practical advice, I would be surprised if “The Pragmatic Programmer” could teach anything new to an experienced developer from 2017. Instead, our industry-wide fascination with this book feels largely ideological, which motivated me to explore its context in better detail.
Almost as our native languages help shape our mindsets and personas, there’s little doubt that our choice of programming languages bears a profound effect on the programming experience and produced results. Unfortunately, many of these effects are subtle and hard to qualify, which makes the choice of programming language a notably heated argument. My personal interest in programming languages is both practical and academic. While I’m always on the lookout for a better tool to get my job done, I leave some room for pure exploration that won’t yield any apparent benefits. This is exactly how I picked up Haskell. In this post, I’m going to focus on the use of Haskell to solve a regular task at work and the lessons I learned doing that.
Prior to launching this blog as a centralized place for all of my English writing, I spent some time performing the long overdue housekeeping on the server that hosts my websites. One of the goals was to unify the process of deploying updates for each of them. I’d grown tired of using a variety of ad hoc utilities ranging from rsync to Capistrano to manually running Git commands on the server. I wanted one tool to rule them all, so I embarked on a quest to find it.
Try8085 is an integrated development environment and a simulator of the Intel 8085 microprocessor. I developed it in 2009 in collaboration with my fellow students Daniil Zapyatoy and Ilya Beda during my third year at ISIT. The project was supervised by docent Oleg A. Ikonnikov (Ph.D.), who’d later employ it to teach undergraduate students the 8085 assembly language. About six months ago, I revitalized this old codebase and released it under the GPLv3 license. I was driven by a mixture of nostalgia and curiosity, but, to my surprise, I found great peace of mind reconnecting with this artifact of my past. Now, I’d like to share some thoughts on Try8085 and the lessons of legacy software in general.
Abstraction is a form of simplification at a cost of information loss. This is especially true for computer systems. Even the most ubiquitous abstractions: file systems, automatic garbage collection, or virtual memory, all take their toll. No abstraction is capable of overcoming the underlying limitations, but it easily obscures them, becoming a possible source of error. When that happens, the programmer’s job is to debug the abstraction, untangling it knot by knot, until the abstracted implementation is revealed. Not too long ago, while working on a bug fix for DeployBot, I had to grapple with an abstraction supported by most modern operating systems: symbolic links. It started out as a simple task but ultimately led me to improve my understanding of the subject.
Update (May 4, 2017). This post has inspired OmniGroup to provide official support for NGINX installed via the
nginx-extras APT package. After using OmniFocus 2.9 for several weeks, I have removed the previously suggested workaround from the solution. The rest of the article may still be of some interest as a primer of debugging a proprietary application.
One of the less talked about features of OmniFocus is its support for using a private server for storing and syncing your data. While the complimentary OmniSync Server remains a great option for most users, I for one welcome this advanced alternative. Being a happy user of OmniFocus for Mac for almost a year, I finally splurged on the iOS version in January. This motivated me to look into what it’d take to self-host my OmniFocus data.
Another DeployBot guide of my authorship was published today. This time I talk about implementing “ChatOps” with DeployBot. Check it out if you’re a user of DeployBot, or just curious what it is about.
Recently I took a Quiet Friday to read the new book by Ben Vandrift and Alex Miller called “Clojure Applied”. As the title suggests, it’s intended to help the reader cross the gap between learning the basics of the language and starting to use it for practical applications. Overall, I liked the hands-on approach taken by the authors, and I wish this book had existed when I was a beginner. But, as one would expect, I didn’t find all of the answers I was hoping to see. If you’re curious which ones, check out my detailed review on the Wildbit blog.
It is all thanks to yourself. — Anonymous Hunter
Despite buying Bloodborne on the release weekend, it took me almost 6 months to trudge through the game to the easiest ending. I’d give up for weeks, only to return again, as if I was a hunter stuck in the night of the hunt.
I’ve just published “Deploying Laravel to DigitalOcean” to the newly introduced guides section on DeployBot. It is a comprehensive step-by-step manual to setting up automatic atomic deployments of a typical Laravel project with DeployBot.
While (hopefully) none of my readers picture me as a PHP framework nerd, I do have some experience with PHP from the “old days”. Talking to Laravel developers in DeployBot support, I realized — while there no shortage of LAMP tutorials on the Internet — it’s still incredibly hard to find a good one that would work for atomic deployments.
I authored another new post on the DeployBot blog. Eugene and I reworked the environment settings page to display connection status to each one of user’s servers. It’s one of those changes that look simple on the surface, but make a world of difference in the day-to-day user experience.
DeployBot is the youngest Wildbit product. It’s an offshoot of Beanstalk aimed to provide to the inherited deployment facilities to a larger audience of GitHub, BitBucket, the users self-hosting their Git repositories. I helped the DeployBot team with the design and implementation of the API. Check out my announcement post on the official DeployBot blog for more details.
Update #1 (July 2015) dploy.io has been re-branded as DeployBot. Updated the post to match the new name.
Not long ago, I got a rare chance to apply Machine Learning at my daily job. For an internal prototype of a potential Beanstalk functionality, we needed a module that would — given a repository — provide us with a concise, knowledgeable description of its contents. Not just “45% PHP, 50% HTML” (e.g., linguist), but closer to “Rails 4.1 project using Rake, Grunt, Vagrant, and Capistrano”.
It’s nice to be back on Beanstalk again! Several weeks ago, I was asked to take a fresh look at our 5-year-old webhooks implementation, and I couldn’t be more excited. I’m a huge fan of webhooks! After hyperlinks, they’re the primary means of integration on the web, and the web is all about connecting the disconnected. For this new version, our designer Eugene and I attempted to make the process of hooking another application up to Beanstalk a breeze. For additional details and screenshots, read my announcement post on the official Beanstalk blog.
Last month I spent some time re-working the official Postmark Ruby gem. As with any other production library, change is difficult. Any significant update turns into a task of finding a compromise between the two conflicting forces: integration with modern development tools and backwards compatibility. This is why I consider this latest refactoring a success: it’s a complete rework of the library that is fully backwards compatible.
This project allowed me to reflect on the current state of the Ruby ecosystem compared to 2009, when the original version was released. I only started writing Ruby professionally in 2011, but I believe I got a good sense of the older days out of working on the legacy parts of Beanstalk and Postmark. As I wrote in my release announcement, Ruby has seen a lot of positive changes since 2009:
…the tools and the entire infrastructure have significantly matured. Bundler, RSpec 2 and the new language features have brought the developer’s experience to a whole new level. Thanks to the amazing Travis-CI continuous integration service, the value of automated testing has grown even more, although it had always been particularly high in the Ruby community. Practicality of Ruby development has moved further with automated monitoring of projects’ code quality provided by Code Climate for free to all open source projects. The other trend is the uprising demand for concurrency support, popularized by JRuby’s real threading, Celluloid and Sidekiq. I’m glad to see how the influence of functional programming languages is affecting the Ruby community, which now favors pure data structures and tries to avoid unneeded abstractions and reduce the amount of mutable state in code.
Lately, I’ve been pushing a lot of commits to GitHub, which made me sorely miss my Beanstalk Tools plugin. Struggling with GitHub’s web interface, I’ve realized that adapting my existing plugin to support GitHub wouldn’t be too much work. From there, it was just a matter of finding spare time.
I wanted to share my announcement blog post for the new Postmark feature Eugene and I have been working on. I’m very proud with how it turned out. Even though I was pretty stressed out about the complex database migration involved in the deployment, everything went smoothly in the end, and Postmark customers are already loving it.
Tired of incessant, tiresome jumping between Beanstalk and my code editor, I finally dedicated some time to integrating Sublime Text with Git, Subversion, Beanstalk, and all the things. The result of this little project is the Beanstalk Tools plugin for Sublime Text 2. The source code is available on GitHub, while the plugin itself can be easily installed via Package Control. Check out the README, or read the
overly enthusiastic more detailed description I posted on the official Beanstalk blog.