I have this small SaaS web application. It has no homepage and it has no signup form or signup site. It has no marketing campaign and people only hear about it from current users. I manually onboard new users and show them around, personally. From face to face. To put it short: “I do things that don’t scale”.
The people using my software depend on it for its purpose, though. They earn real money using it and they are serious about it. They have feature requests and get annoyed when something doesn’t work — for good reason. That’s why whenever I develop a new feature or roll out a security update or fix a bug, it is really important that I don’t mess things up. It is okay to have a few minutes of downtime when the app restarts, there is no need for deployments with zero downtime. But other than that, the software and all things the users got comfortable using should work as intended.
To achieve this there are a few things in place that make this easier for me. Let me tell you about them.
After having people ask me for it and considering the benefits, I will enable comments on my blog. Right now I’ll use disqus.com for this purpose. I am in the middle of creating my own comment system — based on Github issues — but that’s still a work-in-progress and I don’t know when I’ll be able to finish that. So please try commenting if that’s your thing.
Some people learn programming because they want to fulfill a wish. Perhaps the wish is to get a (new) job. Or they want to take on a career where you can be creative and get paid well. Some learn programming because they have an idea for a piece of software, an app or a service.
Once they’ve completed the introductory course, you often see them stumble and wait. They aren’t sure what to do next, afraid to not know enough to get started with their idea. They go hunting for even more lessons on programming. Hoping the next course will teach them the things they don’t know yet.
Well here’s the secret:
The other day I had created a form without a submit button. It is a simple checkbox, which toggles if a user is admin for a project.
It looks like this:
I have a list in my simplenote app that contains ideas, headline and snippets for possible future blog posts. Right now there are about ten entries. It’s hard to tell how many exactly, because some are just a headline for a kind of mini series about something. Some of these possible posts are about ruby/rails technologies. Some are about workflows (e.g. deployment). One or two are about things I did earlier in my career, so they are something about funny or interesting anecdotes, or just for reliving and remembering things. Some ideas are even about me.
But all these posts have one thing in common: They are for me. Every single post would eventually be written by me for me. What I mean is, that these topics are things I have a personal interest in. Let me make an example:
You and I, we develop software. The things we create run inside browsers and on smartphones. They run on computers and on servers. They serve the need of some, and sometimes the needs of hundreds. Or thousands. Or, if we are lucky or have the right setting, millions use our software or parts of it. The systems we develop and write have many moving parts. They consist of a lot of different technologies. Depending on what you develop, you have to be a generalist, more than a specialist. But it depends.
If you use Github.com and have some popular repositories you might want to know where your traffic comes from. Github doesn’t offer anything to track visitors so you completely in the dark. The only way to track the popularity of your repository is to count the stargazers. This didn’t satisfy me.
Because one of my main themes for this blog is learning, I want to share with you a resource I just stumbled upon. It’s a collection of links to free programming books. The collection has its origin on stackoverflow but migrated to Github for collaborative updating. There are links to several languages available so you don’t necessarily read an English book. You can find the collection on Github.
HTML5 video sucks. Flash sucks. If you want to use HTML5 video anyway you should consider using a third party library. I suggest mediaelement.js.
Integrating HTML5 video in your website and making it work in every browser (yes, Internet Explorer as well) still is no piece of cake. As I had the ‘pleasure’ of dealing with this task in the last weeks I want to write down what I found. There are some hoops you have to jump through, surprisingly even when dealing with a modern browser like Chrome. The only ‘just works’ solution seemed to be .mp4 files with Safari. But as I am on a Mac that might just be only my point of view. So let’s get this going one browser at a time.