Recently, I had the opportunity to work on an exciting in-house project for Grio called Filedart. This service, which will launch in the near future, affords the denizens of the web the ability to effortlessly upload content to the cloud by dragging photos or files to a small icon in their taskbar. After the file is uploaded by the client, the service automatically copies a mini-fied URL to the client’s clipboard. This URL leads to a brand-new, public web hosting wrapper for that file that they can easily distribute to their friends of colleagues to share. The service is free, and users don’t even have to log-in to use it.
Here at Grio we strive to constantly improve the quality of our software. But what exactly does that mean? Is there a way to measure software quality? What are the metrics? What are the tools needed for this endeavor?
By now, my post on unit tests influenced you so much that now you have 100% unit test coverage. But yet, some functional bugs still creep in and you still get the dreaded “It’s a bug because you didn’t build what I wanted” bug.
So let’s take a look at acceptance tests and how they can you help you improve your external quality and your compliance with product requirements.
A few weeks ago I had to deal with setting up a cron job that periodically updated some db tables of a Ruby on Rails application running on Heroku. Here’s a brief step-by-step tutorial to make your life easier in case you were approaching the same task.
Over the years, I’ve used a variety of editions of Eclipse with a variety of plugins. These days I try and minimize all of that and ask Eclipse to do as little as possible as infrequently as plausible. The below is a diary of sorts of the events that led to that choice.
A selection of ways Eclipse has failed me:
- It lies about custom key bindings being set, doesn’t actually set them despite indicating it has, and stores the bindings in the robust and never problematic Java-properties+XML standard format resulting in configuration files that look like this:
org.eclipse.ui.commands=<?xml version\="1.0" encoding\="UTF-8"?>\n<org.eclipse.ui.commands>\n<activeKeyConfiguration keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration"/>\n<keyBinding commandId\="org.eclipse.jdt.ui.edit.text.java.search.references.in.project" contextId\="org.eclipse.ui.contexts.window" keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence\="COMMAND+SHIFT+V"/>\n<keyBinding commandId\="org.eclipse.ui.window.previousPerspective" contextId\="org.eclipse.ui.contexts.window" keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence\="ALT+COMMAND+CTRL+ARROW_LEFT"/>\n</org.eclipse.ui.commands>
Normally I could care less what format software stores its config files in, but despite the braindead format I’ve still had better luck editing this file by hand than trying to get Eclipse to handle it correctly. If your config file format is too error-prone for your software to handle, maybe it’s time for a change.
Recently I started work on an iOS game. I decided not to use the Core Animations framework provided by Apple and instead experiment with some third party game engines. I chose Cocos2D as it is an all in one package. It gives you the ability to add and control sprites, add cool graphics and animations, access to a sound engine and also 2 physics libraries.
Agile project management software. Neat little colored digital cards moving left to right. To do, in progress, done. Backlogs, teams, and burndown charts. Flurries of emails – sometimes useful, sometimes not, often routed to folders and never read.
Up until recently, most of us made exclusive use of feature rich tools like Jira, Pivotal Tracker, or Assembla. If you are a developer, tester, pm, or stakeholder in today’s world, you probably still use one of these tools every day. In fact, you are probably so familiar with your particular task management tool that it seems like a natural extension of your work. A job doesn’t feel done until it’s corresponding card is marked, reassigned, and/or dragged and dropped.
If you have used XCode’s built in unit testing frame work , then you’ve likely hit one of the frustrating points of trying to test your application when making api calls over a network. (I’ll save you some time, and let you know the test dies before the call can finish). That’s not great, but it does not mean you can’t test your application and it’s ability to hit your api.
Recently, I came across a blog from Tanvi, a Mozilla Security Engineer (you can find her on Twitter @TanviHacks) talking about mixed content