software

by

Cypht 1.0.0 Released

After more than 3 years of work, over 3,300 commits, 8 release candidates, 126 resolved issues, and 35,000+ lines of code, I’m pleased to announce the first official stable release of the Cypht webmail program is now available! As anyone who has worked in creating releases for software knows, it’s hard to draw a line in the sand. There is nothing worse than creating a release only to find out the next day you forgot something critical or missed an important bug fix. At the same time, creating releases is a crucial part of getting your software into the hands of users.

I created the release branch 2 months ago with the hope that it would only take a week or two to work out the kinks. After eight release candidates, we finally hit the “it’s good enough, let’s do this thing” point. The way I’m structuring releases in git is to create a release branch from the master branch, then porting applicable bug fixes from the master branch to the release branch while putting out pre-release candidates. Point releases will come from the same branch, but primary development continues on the master, until the next major release, which starts the process over again. I first learned this style of releasing from the Squirrelmail project lo these many years ago. In those days we used diff and patch to port fixes from trunk. With “git cherry-pick” this process is a LOT easier.

The downside to this approach is that over time the master branch diverges from the release branch, and it can get harder and harder to port fixes. The solution is to release often, effectively “dead-ending” the prior release branches as new ones are created. This is a good thing since it encourages frequent releasing. Enough has changed in the master branch in the last 2 months, I’m already eyeballing a 1.1 feature release.

I want to thank everyone who contributed code, filled out a bug report, sent me an E-mail inquiry, requested a feature, donated a translation, or told me they love/hate it. The primary force behind Cypht development is what I want a webmail client to do, but feedback is super important to broaden our user base. I greatly appreciate everyone’s feedback and support for the project.

If you are looking for a secure, lightweight self-hosted webmail that provides access to all your E-mail accounts from one place, give Cypht a try and let me know what you think!

https://github.com/jasonmunro/cypht/releases/tag/v1.0.0

by

The Future of E-mail

I think about E-mail a lot. I’m weird that way. I think of E-mail as an annoying neighbor who wanders over to your yard on a regular basis to chit-chat when you are obviously busy – It just won’t go away. It’s like a realization had in the shower in your early 40’s about your hairstyle choice – It hasn’t really changed in 20 years. And (last simile, I promise), like an untreated rash – It’s not going to just fade away. Trust me on that last one.

Every so often somebody declares that “X software” will kill E-mail, usually referring to some sort of instant message program like Slack. I will admit that while I worked at Automattic we used Slack to a much greater degree than E-mail, but they served different purposes. If E-mail is the electronic version of mail, glorified IRC Services like Slack are the electronic version of a phone call. I don’t recall the US Post Office going out of business when the telephone was invented.

After the “E-mail killers” comes the revolutionaries, changing the way you use E-mail forever. It’s new! It’s shiny! Never mind the fact it’s built on the same old plumbing, don’t worry about that! It has smart-<feature>! It solves all the problems with E-mail you didn’t even know you had until we told you! The world is saved! I like exclamation points!

As a webmail developer, I’m not trying to revolutionize anything. I’m certainly not interested in killing off E-mail. Channeling my inner curmudgeon, I actually like E-mail. But I also think there is room for improvement. With my latest Open Source webmail project, called Cypht (which this blog is designed to shill for), I’m trying to address those areas of concern. Unfortunately for you, I’m going to elaborate.

I have lots of E-mail addresses, mostly because I’m a dork, but I bet that if you have any E-mail account at all, you probably have more than one. Work account. Gmail. Maybe your ISP crams one down your throat like mine does. A throw-away account. Some other free E-mail service you signed up for that one time for some secretive reason you don’t want to talk about.

I want a webmail solution that I can host, that gives me direct access to all my accounts. I don’t want to forward everything to the Google content-mining advertisement delivery interface. I don’t want to POP messages from one account to another in a chain of complicated hops that somehow results in two copies of everything. I want an E-mail delivered to account X to stay in account X, I just want to check it at the same time I check Y and Z.

In my not so humble opinion, this is the most useful feature of Cypht – aggregated views from multiple accounts. You can still go old school and browse folder hierarchies like it’s 1999, but you can also see all your unread messages from all your accounts in a single view. Or search them all at once. Even though this software is not even alpha quality yet, the search feature has already saved my butt more than once.

Well shoot, I got so focused on pimping my project that I forgot to say anything meaningful about the future of E-mail. So here are some half-assed predictions. I predict that E-mail will persist for at least another 20 years as one of the main underpinnings of the internet, and that for the most part it will go unchanged. IMAP servers will still be IMAPing, and SMTP servers will keep SMTPing. Or maybe we will all be using Slack to E-mail and back to Slack gateways, so we never have to login to an E-mail client again. Heck if I know, I’m terrible at predicting things. Either way I need to go pick up my rash ointment.

by

Potato Driven Development

You can find countless blog posts by software people claiming that writing code is a craft, science, or art. You can find an equivalent number of posts stating it is not a craft, science, nor art. Some like to split hairs and claim our titles define us: coder vs programmer vs engineer vs developer. The earth shattering insight to be gained from all this is that writing software encompasses a large variety of tasks, and that programming means different things to different people. This results in the adoption of a variety of methods trying to perfect the process of software creation. Unfortunately, restricting how programmers work in this regard requires a trade off that in many cases is counterproductive.

The collective body of knowledge used at any given time to support “best practices” is a moving target. I remember years ago (get off my lawn damn kids) when I was lambasted for not using a third-party template system in an Open Source web application written in PHP. Two years later I was reading about how using a third-party template system added unneeded overhead and projects that used them were poorly designed. I’m not saying this just to point out that I am consistently two years ahead of the curve, though that anecdote is a nice proof so feel free to be impressed. Today’s best practices can quickly become tomorrows regrets. A healthy dose of common sense goes a lot further than a Hacker News consensus when it comes to making sound decisions.

Since writing software is perceived dramatically differently by those that perform it, the enforcement of a strict development methodology restricts creativity in a way that limits a developer’s performance. All successful organizations impose some level of structure on their workflow. I’m not suggesting development shops devolve into a code slinging free for all, but I do think there are gains to be had if we lighten up on fierce adherence to unyielding paradigms. Software development is for me a very creative process. Trying to box that creativity  into a one size fits all methodology inevitably diminishes its expressiveness.

There is no silver bullet for creating bug free software. If there was we would all be kicking back with our feet up on the desk shooting shiny projectiles wildly around the room while untrained monkeys generate flawless code. The most important assets to producing good software are the people behind the product. No automated test system can replace a programmer with a deep understanding of the problem domain. No development methodology can compensate for a coder that does not have an adequate skill set. Give developers the freedom to choose their editor and IDE, and their approach to design software. Doing so empowers them to perform their best and increases their productivity. Of course if they don’t choose vim as their editor they are obviously idiots and should be fired immediately.

If writing tests before writing code works for you, great. If you like to build POC code before finalizing the design of a product you absolutely should.  If spooning another developer while you pair program is your thing, then I say more power to you. My personal method of stirring up software inspiration involves staring intently at an uncooked potato for one half hour before writing any code. I call it PDD and plan on selling merchandise and training seminars at a very reasonable rate so stay tuned.