The Evolution of a Static Website

Next month I’m giving a talk on the evolution of the deployment tools and processes in the last couple of decades.  This article is going along the same lines but over a much shorter period of time and only covering the static websites, not web applications.  Still quite impressive as to how far and how fast the technology is changing.

Front-End Checklist

This Front-End Checklist is pretty awesome and quite extensive:

The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your site / page HTML to production.

It is based on Front-End developers’ years of experience, with the addition from some other open-source checklists.

It goes over generic HTML bits, meta information, web fonts, CSS, images, JavaScript, security, accessibility, performance and more.

The best part is that large parts of this list are pretty easy to automate and integrate with your deployment / continuous delivery tool chain.

MailChimp vs. Amazon SES + Mailwizz

Here’s an interesting story of moving away from MailChimp to a combined setup of Amazon SES and MailWizz, which resulted in overall 92% reduction of the monthly bill.  Given it’s not the same functionality, but if you are technical enough and your requirements are simpler than all the functionality of the MailChimp, this looks like a good alternative.

What you should know as a founder of a software company

What you should know as a founder of a software company” is a nice overview of subjects, with links to learn more, for anyone who is thinking about or have already started a software company.  The article goes through:

  • UX design
  • Visual design
  • Customer support
  • Marketing
  • SEO
  • Press outreach
  • Writing
  • Tech
  • Laws & accounting

Of course, no one article can tell you everything you need to know to run a software company – there’s just too much – but this one is a good place to start.

On Empathy & Pull Requests

I’ve trained more people on the subject of pull requests than I care to remember.  But I’ve never came close to explaining the best practices as well as this Slack Engineering blog post does:

Basically, your reviewer is totally missing context, and it is your pull request’s job to give them that context. You have a few options:

  • Give it a good title, so people know what they’re getting it into before they start.
  • Use the description to tell your reviewer how you ended up with this solution. What did you try that didn’t work? Why is this the right solution?
  • Be sure to link to any secondary material that can add more context — a link to the bug tracker or a Slack archive link can really help when describing the issue.
  • Ask for specific feedback — if you are worried that the call to the `fooBarFrobber` could be avoided, let them know that so they can focus their effort.
  • Finally, you should explain what’s going on for your reviewer. What did you fix? Did you have any trouble fixing the bug? What are some other ways you could’ve fixed this, and why did you decide to fix it this way?

Not every pull request needs every single one of those things, but the more information you give your reviewer, the better they will be able to review your code for you. Plus, if someone ever finds a problem in the future and tracks it down to this pull request, they might understand what you were trying to do when they make a follow-up fix.

Give your reviewer all the context they need to get up to speed with your bug so they can be an informed, useful code reviewer. It’s all about getting your reviewer onto the same page as yourself.

Postcardware

I am not the biggest fan of shareware or other ways of limiting user rights when it comes to software, but if I had to pick one and call it my favorite, I’d go for the  postcardware.  Have a look at this good example:

Open source software is used in all projects we deliver. Laravel, Nginx, Ubuntu are just a few of the free pieces of software we use every single day. For this, we are very grateful.

When we feel we have solved a problem in a way that can help other developers, we release our code as open source software on GitHub.

A lot of our packages are postcardware —free to use if you send us a postcard.

 

Periodic Table of Software Engineering

I came across this Periodic Table of Software Engineering, and I think it’s an excellent visualization.  For those working their way to become software engineers, it provides a nice map of skills, topics, and knowledge areas to cover.  For the rest, it clearly explains why software is so much more complex than anybody thinks.

What is the hardest part about learning to program?

Quora runs an interesting question – “What is the hardest part about learning to program?“.  As always, there are plenty of insightful answers with suggestions, tips, shared stories, research and statistical data, and more.

For me personally, this answer in particular was useful, as I’m very well familiar with the phenomena, but never knew there was a name for it – Dunning–Kruger effect.