I only just started using Docker, a nice little project that lets you package whole server systems as lightweight containers that can run isolated from the rest of the hardware.  It has some warts, but overall it's pretty exciting technology.

Today I was thinking about email.  Email is difficult.  I don't know why, since it's one of the oldest technologies around.  But setting up an email server such that it's easily configured and doesn't let spammers get away with murder is such an aggravating experience that it's often easier to pay someone else to host it for you.

The problem I've encountered is that I would like to use a service like Postmark or Sendgrid, but they explicitly prohibit non-transactional emails.  This means that if you use their service to send email, then it must send one unique email to one person based on some user performing an action.  They explicitly can't be used to send many of the same (or similar) emails to multiple recipients, which they classify as "bulk email".

My use case is that I would like to have a site that maintains membership within an organization.  Within that organization, there are smaller groups.  When an event is due to occur for that group, I would like to send a (mostly if not entirely identical) email to all of the members of the group.  I suppose I could argue the case that these messages are entirely opt-in via the site, which is why these services won't send them, but rather than try to do that, it would be easier if I could configure my own email server and some code to do at least the API parts of what these services do.

Yes, I realize that I won't be getting everything that I would pay for with those services.  For example, if I have deliverability issues, I'll have to figure them out myself.  But realistically, my use case has maybe a hundred members, and if a couple of people have issues, it's not going to be a big hassle to work them out.  The main problem is that I would need to install an email server.

I was thinking about this problem and my recent experimentation with Docker, and I thought that an MTA + SMTP + IMAP container might solve my problems.  If such a thing existed, I could very easily run a single docker command to erect an email server on my host.  The point of the server would be ease of configuration, so it would hopefully either use MySQL (external!) as a data/config store, or allow configuration files to be updated from outside the container somehow.

Sadly, I searched through the Docker Index, which lists publicly accessible docker containers, and there doesn't seem to be any such animal.  I wonder what the interest would be in the creation of such a thing, and whether I could enlist a Courier/Postfix/Dovecot expert to help me out.  If I could then build an externally-accessed web-based API that was like what Postmark or Sendgrid provides (maybe in node.js or Python?) on top of that Docker container, that would be perfect.  I wonder how many people could make use of such a thing.

Feature branches are a great way to add new functionality to a project, while giving others the chance to review and improve the code.  Feature branches are usually created to address a specific issue, either implementing a new feature or a fix for a reported issue.

When performing a code review of a feature branch for an open source project, there are several key points to keep in mind:

Pre and Post

Since a feature branch is usually created to address a specific issue, you should be aware of the issue that the branch is trying to address.  When you test, you need to understand the problem and the effect it has.  It's somewhat pointless to run the code from the feature branch without having seen the issue that's being addressed.  If you're familiar with the issue from having run the original code, that's fine, but an awareness of the difference is essential to knowing whether the issue is fixed.

Run the Code

This one seems kind of obvious, but based on my experience with developers (especially inexperienced ones) doing testing, sometimes the developer of the feature branch doesn't even test his own code!  It's essential that someone runs the code before passing it, not just to make sure that the code addresses the issue, but that it doesn't introduce regressions.

This and the the prior requisite mean that you need to know what the point of the feature branch is and then run the code form the feature branch to ensure that it runs correctly and doesn't break existing behavior.

Code Review

It is important to look at the code to see how a new feature is being implemented.  In this way, potential security issues and inefficiencies can be addressed and exposed.  The code must read well: From a logical point of view, from a syntactical point of view, and from a documentation point of view.  If a first read-through of the code is difficult, it will be even more difficult to understand in the future when the contributors aren't around for discussion.  These issues should be surfaced during the review.

People often think that a read-through of the code is the entirety of a code review, and it is not. It is essential that the code be run and tested in addition to a read-through, for reasons mentioned above.

Other Notes

Remember that a feature branch is created to address a specific issue.  If, during the course of review, a new issue is discovered, it is not necessarily the responsibility of the feature branch under review to implement it.  Consider whether the issue would stand alone both before and after the feature branch.  If it would stand alone, it should be filed as a separate issue. Remember that "the perfect is the enemy of the good", where achieving perfection in a code review can often force unnecessary delays in the inclusion of otherwise good code.

Code conventions are important, and blatant ignorance of convention should be a reason to reject code on review.  It is a good idea to update the code being altered to better conform to conventions, but be aware that everyone makes typos, and missing a space or two required by code convention in a 300-line change isn't a good reason to reject an entire branch. This type of pedantry only subjects the whole project to delays, and this low-hanging fruit can be picked up by later code-quality sweeps.

Finally, keep in mind that a lot of contributions to open source are done by passers-by with an itch to scratch for your software.  Contributed code is a gift, and should be treated as such. Being kind and professional while adhering to a set of rules (whether these or set by the project for how reviews are to be completed) can set your project apart and make for more happy, frequent contributors. 

I'm teaching a class on Source Control Managment for Girl Develop It on Monday.  In this class, I'm going to cover the basics of version control and how to accomplish it using Git.  But one thing that many people have asked about this class while I've been talking about it is, Why should I learn about version control?

There are many reasons to learn version control, but I've come up with what I think are five great reasons that you shouldn't avoid using a versioning tool, no matter what your skill level:

Resilience

Don't confuse my words here - SCM is not the same thing as reliable backup.  But imagine if you could go back in time and look at your code as it was yesterday, or the week before, or even just look at what you did half an hour ago.  If you could take back the last hour's worth of "oh, no, I just deleted that essential file" or "I overwrote that working routine, and now it's all broken", wouldn't that be great?

Good SCM allows you to do this.  You can look back through your coding history, find a version that works, compare it with what you have, and either go the whole way back or take just the parts you need.  It's like a time machine for code.

Collaboration

Sartre said, "Hell is other people."  I don't know where it is, but there's an even hotter place reserved for working with those other people on code.   It's next to impossible to share work, especially when you're all working on a small-sized project and need to get at the same files at the same time.  You make a change, then someone else overwrites your change with their own stuff, and soon enough you don't know what version of what file has the required features in it and then.... hell!

A primary purpose of SCM is to facilitate the sharing of code between developers.  It's a tough task, but the tools for it have been around for a long time.  With good VCS, you can make whatever code changes you want and then use the tool to integrate with the work that everyone else has been doing.  The tool will help you easily merge everything back together so that nothing gets lost.  Then, cake!

Efficiency

Have you ever looked at a chunk of code and thought, "I bet I could get this to be more efficient"?  Did you think about how you'd need to keep a copy of that file elsewhere just in case your changes didn't work out?  And what happens if you are in the middle of those changes, and someone needs a different change to the same code right away?  The whole operation becomes a drag, and you think it would be easier just to keep the status quo.

With SCM, you're free to experiment.  You can create cheap branches of the code you have and make any changes you want without fear of affecting the working code.  And if someone asks you to make a quick change to the code they're using, you can easily switch back and forth between the versions.  It's almost too handy.

Accountability

I know I've looked at code and said, "Who was the idiot that did this?"  Usually it's me that's the idiot.  But sometimes I see other people's code and I want to know the reasoning behind how it was written.  If people are just editing files on a server somewhere, it's kind of hard to keep track of who did what, and even harder if multiple people are all editing the same file.

When you have a good versioning program, you get a set of tools that you can use to figure out who wrote what, why, and when.  As you add things to your code, you are automatically encouraged to create a brief log of what you've done so that others can see what you were trying to accomplish when you wrote it.  And if you need more explanation, the name of the person is right there in the log so you can chat about their change.

Integration

You have your bug tracker open in one window and your code editor in another, and you've just finished fixing that bug.  What's the process?  Save.  Upload.  Write "fixed" in the bug tracker and submit it.  Next bug and repeat.  What's with all of these steps?

With SCM, you can configure your system to do things automatically when you're done with your code.  When you finish with your changes and push them to the main code server, it can trigger both a deployment of that code to the staging/production environment and can take your log message and apply it to your bug tracker, closing the ticket for you automatically.  Later, when people are looking through the fixed bugs, they can see exactly what code you changed that fixed it.  And you get all of this with just one VCS command?  Incroyable!

Conclusion

These are just the handful of benefits of using an SCM system that I came up with.  As you use one, you'll come up with personal benefits that you might not have even considered before!

Don't be afraid to learn SCM.  Professional, experienced devs use it routinely, and it's so easy to get started and step up your game.  Come to my Girl Develop It class on Monday, and in under 3 hours you'll be ready to apply SCM to all your projects!

I often have to select colors from images for use in my HTML.  Taking a screenshot to use image editing tools to capture that color is inefficient, and the images I am sourcing aren't always coming from a web browser to be able to use browser extensions for that purpose.  That's why I like a desktop tool:

This is a pretty handy tool for Windows that quickly captures colors from anywhere on the screen, and is significantly faster than other color pickers I've used in the past.

I think the growing trend for publishing technical books before they're complete and asking for feedback is really interesting, and I've found many books published this way that are affordable, timely, and high-quality.  That's one thing that interested me about the description of Steve Jalim's book on being your own boss:

Having gone that route myself over a year ago, I'm interested both in the insights that Steve has to offer, and in the ability to potentially contribute my own insights back to such a book. Check it out for yourself.