Articles about software
When you run a SaaS business sending out invoices is your lifeblood. Hopefully, you're generating a ton of invoices and sending them off to your customers.
Here are a few best practices to consider after automatically charging your customers.
I don't go to many conferences - I am pleased that Baruco is one of them.
I really enjoyed the conference. It was well organized with a stellar lineup of speakers. I've returned home from Barcelona with things to ponder, things to try out, and a list of books to read.
So the Ender movie is coming out. That's... well, it's coming out.
This had me thinking about the book series and one thing from there struck me as being more science than fiction nowadays (don't worry, no spoilers):
In the later books of the series Ender has a digital assistant called Jane. Jane takes the shape of small in-ear dongle - a "jewel", which Ender communicates with using voice commands.
Could we create - or at least approximate - Jane using existing consumer technologies today?
I recently needed to run some geographical analysis and PostGIS seemed like a perfect fit for this. So off I went to install it, here's how.
Let's assume I write software for a living.
Let's assume I built something and the total cost of development is a nice round number like $10.000.
Let's assume I expect to sell a certain number of copies, say 1.000.
Let's assume I like to turn a profit (I do) and not give away my work (I don't). How much should I charge?
$1? Don't be ridiculous.
$10? Assuming every copy is sold that'd put me at break even. But at $0 net I might as well not have built anything. And if I don't sell 1.000 copies, I'd have lost money.
$20? Now we're talking. I'd be looking at recouping my costs and making a decent profit - I might even be able to pay for food and housing for a few months.
$100? If 200 customers find my something worth that much, why not?
Now, let's assume the number of copies with certainty cannot exceed 1.000 for whatever reason.
How much would you charge?
Squeezing UX design into an agile process is hard. I think so and Joshua Porter thinks so. He reasons that this is because "design is about solving problems", and solving problems cannot be squeezed into 2 week iterations.
Hm. I wonder what that says about developers?
After upgrading my Redmine installation to Redmine 2 (the development branch) emails stopped being delivered.
I send emails through Google Apps for Domains, so I had the following in my configuration.yml (previously email.yml):
delivery_method: :smtp smtp_settings: address: "smtp.gmail.com" port: 587 domain: "substancelab.com" authentication: "login" user_name: "firstname.lastname@example.org" password: "passw0rd" tls: true
I am pretty sure it used to work before the upgrade, now; not so much.
Dear Open Source Software
I don't think I have ever written you before, but there is something I wanted to get off my chest.
I just wanted to let you know, that you rock! Just the other day, you saved my customer a bunch of money - and made me look like a hero.
Okay, I realize you only did so because I had done part of the work already. And I am probably giving you credit for something you didn't really do, but thanks to you a team of strangers had implemented features I needed and given them back to me.
Also, the way you enable people I have never heard about to take something I have created and transform into something they can use, is mind boggling.
PS: I know, I know... I don't contribute often enough, and I will some day, I promise. Soon.
There are basically two kinds of deadlines: Real, and Arbitrary.
Real deadlines are those necessitated by some external, unchangeable event. For example legislation, the company running out of money, the CEO having to get up in front of the world press and announce the product, or a marketing campaign kicking off.
Just because I can never remember how to do this:
psql my_database -c "COPY (SELECT stuff FROM my_table) TO STDOUT CSV" > my_file.csv
Works in at least PostgreSQL 8.4.
Some third party systems needs to send requests to your web application in order to work.
That's fine in production where you have a public facing webserver running, but when you're developing locally you have to jump through a few hoops.
My parents have a digital camcorder. A week long vacation with said camcorder, my parents, and their only grandchild produces a fair amount of raw footage. Before we headed back home after the vacation I wisely snapped up all the footage from their camera hoping to eventually run it through iMovie.
Turns out their camcorder stores its clips in MTS/AVCHD format, and I didn't grab all the fluff^Wnecessary files. As a result iMovie '11 cannot import the MTS video clips.
Luckily, if you're using Ruby, you can now use the r-conomic gem to handle SOAP and the other tedious bits for you.
I don’t get Apples insistence on getting rid of scrollbars in OS X. What have they got against them?
They take up screen estate, sure, but seeing how the smallest Mac display has a resolution of 1280 by 800 (on the 13" Macbook) a scrollbar really doesn’t take up that large a piece of the total pixels. And with the new Lion/iOS style they are practically invisible unless you look for them.
When building a new software project, you should focus on building your core functionality – usually the magic sauce that makes your company money.
This might seem obvious, but many people don’t realize just how much extra work is needed to support the money making part. Not only are there many supporting features, it can also be hard distinguishing them from your core features; after all, they are all needed to run the business, so they must be important, right?
Unless you have unlimited funds, your success is going to be dependent on your ability to figure out the correct set of core features to work on.
There is an old saying; “You never miss the water till the well runs dry”. The meaning is that it’s easy to not realize what you have until it is no longer there.
The opposite is also true – possibly in life, but definitely in software development: You don’t know what you need until you have it – even if it’s just a sliver of it.
When I previously wrote about the tyranny of software updates, one of the takeaways were that it would be nice if someone were to create a centralized, out of band, update mechanism for installed applications.
Lo and behold, with the invent of the Mac App Store, Apple has done just that for us OS X users. Applications you buy in the store are also upgraded in the store. Fantastic! software updating bliss is here! We’ve finally reached application update nirvana.
Not quite. Unfortunately the app store update process has a few drawbacks:
Manually quitting and restarting applications
The experience of updating comes to a grinding halt when I am told that X applications are running and I need to quit them. I have to command-tab around and manually search my dock and menu bar to find applications that I happen to have running.
And that’s not even the end of it. When the applications have been updated, I have to launch them again manually. At least, in-application-updates have the ability to upgrade and relaunch on their own.
Certainly this is escalated by the fact that I have primarily bought applications that launch on login and are running all the time, so having to find and start them is something I only do when updating.
A separate application to find updates
Despite what Apple would like, I don’t have the Mac App Store running all the time. I don’t even have it in my dock as that’s reserved for stuff I use. As a matter of fact, I only launch the app store when I want to find new software. Updates at that point is nothing but an inconvenient distraction – especially as I have to go through the search-and-destroy-and-revive process mentioned above.
I still think that there would be value in having application updates bundled with my system software updates. At least that is checking for updates ever so often and notifying me when there are some – I don’t have to do anything but click the “Upgrade now” button.
Two steps back
The Mac App Store application update progress is one step forward and two steps back. I am hoping both of the backwards steps can be fixed in software.
Certainly. a software update API that applications can hook into could be added, so applications can relaunch themselves when updated. Making the update check an automated, regular event should be easy as well – the infrastructure is there already.
I am still hoping we’ll get something equivalent of Debians apt, wrapped in a nice Cocoa UI.
Staying on top of errors that happen in your production Rails applications is a must. Unfortunately trawling through log files get old really fast, and getting enough information about where the error happened can be hard.
That’s what services like Honeybadger or Airbrake solves. Whenever an error occurs in your application the details are sent to their service, where you are able to see when, where and how many times a given error has occurred.
However, if you’re uneasy about sending this level of details to a third party service – or if you’re simply a cheapskate like me, there is another way using Redmine.
Some months ago, the people I share offices with had an exhibition showing off their works. They are all visual designers and artist, so their works are fairly easy to exhibit.
I turned down being part of the exhibition, primarily because I couldn’t figure out what to showcase.
Adium has moved one step closer to the approach I’ve suggested applications take for software updates:
“Install on Quit” is a great option and sure beats the “install now and interrupt what I wanted to do”. I would prefer that the upgrade dialog only popped up when I quit the application, but I’ll take any incremental improvement.
We Mac users have been blessed with self-contained applications that (for the most part) don’t require an installation/setup. This means trying out a new application is a simple matter of downloading and double clicking and the app is running.
However, in many cases people end up having their applications installed to their Downloads folder instead of the “proper” Applications folder, because they don’t know or care where their apps are running.
Stay, a great window helper application with an ungoogleable name, recognizes this antipattern and is able to move itself to the Applications folder if it’s running from Downloads.
What a great way to recognize and prevent a potential headache for your customers.
One of the many things I try to make my customers realize, is that their web application is never done.
There is always something that can be made easier to use, pages that can be made to load faster, new features that can be implemented, existing features that can be made more powerful, or landing pages that can be optimized.
When I founded Substance Lab I knew I wanted to build a virtual business – or at least as much as it could be. Why should petty details like physical locations decide whether I can help my clients?
From the get go, I chose primarily web applications to run my business on. Also, it kind of makes sense because that’s what I am building, and there is no better way to learn about good and bad web applications than using them yourself.
Let me give you a rundown of the most important ones.
There you are, sitting at your desk. Your thoughts are coming alive on the glowing display in front of you, brought into existence by your fingers effortlessly running across the keyboard. The outside world has become a distant memory – even the music flowing into your ears from your headphones has grown muffled and removed.
You are in flow.
Suddenly an unexpected idea spawns in your head. This idea must be preserved and dealt with, but you can’t risk losing your flow, so you quickly launch your favorite notes application to jot the idea down before it escapes the grasp of your mind.
A new version of UberNotesMaster is available, would you like to download it now?
Stumped, you try to gauge whether the update is quick enough that you won’t lose your flow, but you have already lost. Your flow is interrupted, the idea is escaping, and your application is still not updated.
Do you prefer the plague or cholera?
Typically, when an application announces that it has a new version available, you have two options:
- Upgrade now and generally disrupt what you are doing
- Ignore and continue to run outdated, potentially buggy and insecure software, and get annoyed the next time you launch the application.
While I like upgrading my software as much as the next person, I launch an application for a reason; to use it – instead the application forces me to choose between performing the task at hand or get the latest version of the software. You know what, I want both!
Update after use
Instead of asking me to update an application when I am actually trying to use it, how about dealing with the update after I am is done using the application?
This way, the upgrade dialog could appear when I quit the application, and the update would take place while I am doing my work in another application. A much smoother experience whose only interruption is easily dealt with.
It might, however, prove to be quite frustrating when you attempt to shut down your computer and all running applications want to update themselves. Also, OS X users are known to never actually shut down applications and also never restart their machines, so they would end up never updating.
A variation of the above would be to still ask me, the user, when I launch the application, but allow me to say “Yes, I want to update, please download and update in the background while I continue with my task at hand”. The actual update then happens after I quit the application, making the entire process almost invisible to me.
Out of band updates
We could also move the application update process out of the actual applications themselves. This strategy is known from the iTunes App store, where updates to all installed applications happen in the background while you’re doing other stuff. Smooth and seamless and allows you to maintain your installed software when /you/ are ready for it.
The process in itself is probably the smoothest offered, but it also bears the penalty of centralization. This software updater application somehow needs to know about all independent and unique applications you have installed and be able to update them.
Larger software vendors like Adobe have taken this approach and created their own – usually pretty crappy – updater applications. I would love to see something kickass here – preferably from the ISV community, but it could also be interesting seeing Apple build this into their own Software Updater app (or in the Windows equivalent if one exists).
Now, excuse me, I have to update my blogging application…
Google recently released their variant of YSlow called Page Speed. Like YSlow, it's an add-on for Firebug and it provides a bunch of recommendations for optimizing the clientside performance of your websites. This time, I'll let it loose on the homepage of Lokalebasen.
Every so often, a client wants their web application to send out emails that could benefit from a bit richer styling than what’s provided with your basic text emails. Occasionally, they’re right, and you find yourself walking down the path of HTML emails. But beware! That path is perilous and behind every corner lurks the big, all-consuming monsters of HTML emails; Email clients.
I have been moonlighting as a freelance webdeveloper for the last couple of years. The first year, I was using my spare evenings and weekends until I began having trouble finding enough time to dedicate to new projects.
- Windows is confusing and all about nothing – just like any episode of the Seinfeld show.
- Microsoft needs to piggyback on Apples creativity.
- Even though everyone and their brother use Windows, group pressure isn’t going to make me switch away from OS X.
Ah well, at least the Gates/Seinfeld episodes were somewhat amusing.
It proves that it will be a long time before we dispense with the desktop
apps. I for one only used stikipad as and when I wasn’t at my own computer
and needed to collect info/data as and when for later.
While I am obviously miffled about losing my data, I disagree with that sentiment. However, the Stikipad fiasco does prove that cloud services can be as fickle as the physical hardware we rely on today. And yet, even after several harddisk failures, we continue to store our data on harddisks.
The ultimate reality is that I am the one who should’ve been keeping a backup of my data – just as if I had the data on my local machine. Having my data stored somewhere in the cloud doesn’t free me from that responsibility. Unfortunately, I am not aware of any real, usable solutions for doing that kind of backups – a dormant business opportunity, perhaps?
Stikipad disappearing from the net and taking my and everybody elses data with it is unfortunate, but doesn’t prove anything general about other services.
It does turn out, though, that the cloud of tomorrow isn’t all that different from the physical hardware of today.
For a long time I have been using a wiki service called Stikipad to jot down things I wanted to save for later; like business ideas, drafts for blog posts and presentations, stuff like that.
Unfortunately Stikipad has looked like this the last 2 weeks or so:
This essentially means I cannot get at my data and have not been able to for weeks now. As if that isn’t bad enough in itself, I don’t know squat about what is happening, why a data center move is taking weeks to complete, or when I might see my data again.
The sound of silence
While I can understand the sticky situation they might be finding themselves in, they need to pull their heads out their butts for a second and provide information to their customers. They haven’t answered emails, they don’t reply to comments, and their support site is down.
At least a thousand people used to have public wikis hosted with Stikipad and are now left with only a non-informative “We are moving data centers”. Fine, move data centers all you want, I really don’t care. But I do care about my data, which you are currently keeping away from me.
And to add insult to injury, Stikipad is apparently charging their customers for a non existant service.
If you’re using web applications…
There a couple of lessons to be learned here – both as a consumer and a producer of “cloud services”. To the consumers out there looking for the next new thing to make their online life easier, I say
- Don’t sign up for a service that doesn’t allow you to get your data out of the system in a structured way. To Stikipads credit, they did provide that feature, and I do have a fairly recent backup, so this is probably not a total disaster for me.
- Use that backup/export feature! Use it regularly and not only when you want to cancel your account – I did not, shame on me.
If you’re producing web applications…
The most important lesson for producers of web applications that deal with other peoples data – and I sure hope the Stikipad guys are taking notes here so they don’t end up accidentally screwing more people over – is that you need to always communicate. Especially in times of trouble. Set up a blog on one of the numerous blogging services or hook your company up with Get Satisfaction.
I don’t care how you do it, just don’t shut the fuck up.
tds_iconv_info_init: client charset name "" unrecognized
make sure you have put
client charset = UTF-8
into your freetds.conf – not
client charset = utf-8
Note the case difference.
I can’t believe the amount of hours I have wasted setting up FreeTDS and ODBC connectivity on various systems by now – and still I get bit by crap like the above.
2 hours down the drain, and all I had to do:
sudo port install ImageMagick sudo port install rb-rmagick
As you’ve undoubtedly noticed, assuming you follow at least a few blogs, listen to podcasts, or otherwise read the press, Apples iPhone has been released.
Ever since Steve Jobs non-announcement of 3rd party iPhone applications really being web sites, there has been a rush of developers trying to move into this apparently new market. Never before have so many developers been in such a hurry to cater to a tiny percentage of the market running a closed, proprietary technology.
Ah well, let’s for a second forget the folly that is creating web applications targeting a single device, however sleek and sexy it might be, and investigate exactly what these so-called iPhone applications are.
First of all, let me start by saying that I am located in Europe, which in Apple-lingo means “Yeah, we’ll get to you eventually”. I’d definitely like an iPhone, so feel free to write this blog entry off as me being miffed that I can’t buy one. You’re probably right.
This also means that my entire iPhone experience to date has been through iPhoney, which is likely to be far from the real thing.
Anyways, back to our regularly scheduled program: Me ranting about what qualifies a web site as an iPhone application.
What makes an iPhone application?
- Ability to work at both 320 pixels and 480 pixels width?
- Should it have the iPhone look’n’feel?
- A version served only to the iPhone?
- Using iPhone-specific features (like the ability to perform phone calls)?
- All of the above?
I can use google.com just fine in an iPhone, that hardly makes it an iPhone application. When websites that are basically simulations of how a website might look and feel on a real iPhone can be qualified as a top 25 iPhone application something is seriously amiss with our definition.
I assume a bunch of people are releasing so-called iPhone applications for the simple and easy advertising that it is at this point, but if all it takes is to make sure your website can scale down to a width of 480 pixels, the whole point of claiming to have built an iPhone application becomes void.
Or perhaps I am simply missing something not having access to a real iPhone. Perhaps all the websites I visit have a secret way of detecting an iPhone and serve perfect, iPhone optimized goodness to the lucky few. Or perhaps people are grasping for straws, attempting to draw attention to their application:
- Serve a custom stylesheet to iPhones
At least, people smarter than me – and in particular, people smarter than me who own iPhones – have already tried to define some of this stuff.
And when the iPhone is eventually released here, I’m hoping development best practices will have been settled on. And hopefully people will have come to an agreement what the heck an iPhone application actually is.
Imagine this: I’m at work when someone tells me: “Hey, you need to check out this podcast”. “Sure”, I say, “I’d love to”. So I fire up my iTunes, add the podcast to my subscriptions, and forget all about it. Then when I get back home to my podcast-syncing machine, the podcast is downloaded and put on my iPod without me having to do a thing.
Sounds like a great experience and very Apple-ish, right? Too bad it doesn’t work that way.
An iPod isn’t allowed to be connected with two different iTunes libraries, which I can understand. Apple needs to deal with DRM issues and I can live with that. But why doesn’t iTunes store my podcast subscription settings on their server?
iTunes already logs me in automatically, the technology needed to store this really doesn’t appear to be that big a deal, and the podcast content isn’t DRM protected or even stored on their network. The infrastructure is there!
But I still have to send myself an email (or add a task to my ToDo list or whatever) and remember to subscribe to the podcast when I get home, or erase all my existing iPod contents to connect it to a new library. I expect more from Apple.
You know we’re sitting on four million pounds of fuel, one nuclear weapon and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn’t it?
After launching the rewritten and redesigned BiQ I got word of seemingly random IE installations crashing within seconds of opening BiQ. I could not find a way to reproduce this and it only occured on a tiny minority of client installations, so I shrugged it off as yet another reason to upgrade to Firefox.
After 6 months of evangelizing and advocating, followed by 6 more months of rewriting, and then 3 more months of building new features and enhancing existing ones, we have finally launched the new version of BiQ.
Going from ASP/VBScript on Windows 2000 and IIS to Ruby and Rails on Debian served with love by Apache proxy balancing to a Mongrel backend, using memcached for relieving the database of those common queries, with continuous integration provided by Cruise Control and easy deployment through Capistrano sure as heck feels good.
Add to that the fact that the new look is quite delicious and powered by standards compliant XHTML sprinkled with a tiny amount of Ajax and a hint of microformats and Atom feeds, and has a blog and some new killer features and you’ll probably understand why I am happy.
Now it is time to make the site even better. ;)
Last week I took a quick executive decision to deploy BiQ on Debian Etch instead of Sarge as initially planned. Mainly so we could take advantage of Ruby 1.8.5 (let me hear you scream “Mongrel”) and Subversion 1.4.something.
Today, yet another reason for going with Etch just bit me in the behind while using our development machine:
Podcast syncing in my iTunes Jukebox (or whatever the name Apple wants us to use for it) is broken.
I’ve it set to “Sync all unplayed episodes of all podcasts”. iTunes reports that I currently have 11 unplayed podcasts in my iTunes library. However, the iPod holds only 5 podcasts after updating.
At least it’s better now. After the first update today my iPod held only one podcast.
There’s plenty of free space on the iPod, and I can’t tell if there’s some switch somewhere that I need to flick. Piece of buggy software.
What other, easy to use podcasting clients are available? I’m also missing the ability to add non-podcast files to my podcast queue, say in the case of presentations where I don’t have a feed, but only the direct download.