In the second part of this post on rescuing web applications, I'll go through some techniques for refactoring the codebase of an existing project. This is for the case where you've decided that there is hope for your project, and that the best course is to take the time to fix what's already there, as opposed to starting again from scratch.
Most programmers have the best of intentions. We all like to produce code that: a) nails a particular feature; b) runs quickly; and c) reads well. Despite these intentions, we've all ended up in the situation where our code has degraded into something ugly, unperformant or useless (aliteration unintentional). Sometimes it's out of our hands, e.g. when a client decides that yesterday's critical feature is no longer on their agenda, leaving redundant code littered through our project. Sometimes it's preventable, like when we gradually add tiny bits of code without refactoring to adopt it, or without introducing new tests. However it happens, it's an inevitabilty that we need to accept. In fact, rescuing projects from these situations help us learn and grow as developers.
Back in 2011 I created the Vdebug plugin for Vim, which provides a visual debugger interface for debuggers that support the DBGP protocol, the main one being Xdebug for PHP. I created it mostly for myself, as I wasn't happy with the other plugins out there. At the time I was almost entirely developing in PHP, but Python was the first language that I really enjoyed, so Vdebug was an opportunity to return to it.
Something I commonly want to do is evaluate a bit of code and insert the result into my Vim window. For example, if I want to generate a 40-character UID, I could use ruby's SecureRandom class:
TL;DR
I created a ruby gem to provide email and slack notifications for Systemd services, which gives visibility over process stops, starts, restarts and reloads. This post documents why and how.
I also need some testers, so if this is relevant to you please give it a go and send the appropriate feedback.