This is a month later than we had planned but I am excited to announce that we have just release fixx 1.8 into the wild. This is our biggest feature
release yet with 63 major issues raised by customers for a while.
Here is what is in store for 1.8,
You can now perform a 1-click import from FogBugz 6.0 and above.
Ability to backup and restore an entire instance of fixx through the Admin interface.
The Rich Text editor has been modified to now support XHTML and support for Textile/Markdown has been removed.
Ability to notify issue assignee when commenting.
Ability to have "private" issues.
More functionality in the API to deal with issues and comments.
I know it has been very quiet around here at the lab, but we have been incredibly busy working on the biggest release yet of
fixx and slaving hard to release a beta of solomon.
However, I did want to take this opportunity to announce firefixx, a Firefox extension for fixx. Currently, all you can do with
firefixx is drag & drop files into the browser to automatically attach them to an issue. As long as you are viewing an issue and have
permissions to upload files, just dragging & dropping a file into the main browser window will automatically upload it.
Although the functionality is basic (no feedback/progress or UI), we have big plans for this extension in the coming months. What's even
better is that firefixx is a BSD licensed project and the source is available on Github if you want to take it and write your own hacks. We
can't promise we will use all of them in the core extension but it's not like us to say no to useful contributions?
I decided that since I’m quite familiar with git, that it shouldn’t take too long to adapt the previous Subversion to fixx hook script to play nicely with git. You can find it here
The instructions for using this script to post your commit logs/messages to fixx are very much the same as that highlighted in the previous article. Just make sure to place this in the .git/hooks/post-commit of your repository and your good to go(after chmod’ing it ofcourse).
Next on the list – mercurial integration, so watch this space…
Since publishing the fixx api in January, we have received a number of requests for source control integration. As a result I’ve gone ahead and created a nice script to get the ball rolling on this front, to be ran as part of the post commit hook. A post commit hook is a script that is ran after checking in some new code to your SCM repository. Lifted directly from the svnbook itself:
Most people use this hook to send out descriptive emails about the commit or to notify some other tool (such as an issue tracker) that a commit has happened.
This opens up the opportunity for us to latch onto the post commit hook whenever we commit new code into our repository, and feed the recently changed knowledge into fixx using our api. This has a number of advantages, as it means that fixing bugs and your SCM system are no longer disjointed processes.
I bet you’ve done the equivalent of this before svn commit -m ''. Well now that commit message gets logged in fixx for everyone to see. Therefore it’s worth getting into the good practice of inputting descriptive commit messages.
If you think about regression bugs this is also ideal as you can see all the files that were changed/added in originally “fixing” that issue. This is just one of many reasons consolidating your SCM with fixx has value and is beneficial to your workflow.
Here at hedgehog lab we primarily use Subversion as our source control system for most projects, and this script in particular is tailored to work with Subversion through the magic that is svnlook. But I’m confident that this can be easily adapted to fit whatever SCM your currently using.
Note: For this script to work properly the only prerequisites are that you have a copy of fixx running, and both Subversion and Ruby installed.
Basically the script looks for the issue id, prefixed by a hashtag as part of the commit message in order to log the changes in this revision in fixx.
So if I committed some CSS changes to improve the rendering of fixx, my commit could go something like this:
svn commit -m '#12 Dashboard CSS Tweaks'
A new comment would be created under issue 12, with the following content.
Just to point out that the #issueId can be placed anywhere in the commit message, though if one is not present, it won’t be logged in fixx.
Since we want to bridge the gap between SCM and fixx completely, we have also roadmapped in new api functionality, so other options will be able to be supplied with the commit message to create, resolve and close issues in fixx sometime in the near future.
Instructions on how to go about using the script can be found within the script itself, which you can find here so enjoy!
Hi, I'm Rob, the latest addition to the team here at hedgehog lab. I started here last Monday, and I've been given a rather large task with a equally large and looming deadline.
I am the Product Manager for solomon, and I will be leading all aspects of this project, including all of the development. I am eager to launch a beta release in early May, so I will be spending April solely working on Solomon. You can sign up for beta preview to help us squish any bugs and get an early look at what we are doing. I am looking forward to running this project, and if you have any queries or feature requests you can get in touch with me on our Get Satisfaction forums and I'll be more than happy to help.
I've been spending my first week analysing the requirements and design for Solomon and familiarising myself with the environment and the technologies that it uses. The atmosphere here at "the lab" is great, it's a fairly small office with five of us working in close proximity. The discussions we have about projects or problems usually involves scooting a chair over to desk-share or drawing everything up on the whiteboard, which give us a very flexible and productive environment.
I joined the lab straight from University, where I attained a MSc in Computer Security and Resilience. Being given this much responsibility immediately is a welcome challenge, It should give me plenty of project management experience, and I must admit I enjoy being given the snazzy title of "Product Manager" at the age of 22!
Outside of work and education, I spend a lot of time exploring new technologies; I recently learned Flex and Adobe AIR, and I have a feeling there might be some fancy new applications in the pipeline using the Fixx and Solomon APIs.
My life isn't all computers and coffee though: I am heavily involved in the South Shields volunteer lifeguard club; I teach lifesaving, give safety talks in schools and during the summer I spend as many days lifeguarding on the beach as possible.
For those of you interested in what Solomon will look like, here is a preview of the contacts feature:
I intend to follow Damian's trend of blogging snippets of product insights periodically, so as soon as the beta of Solomon is out you can expect to be hearing a lot more from me. Goodbye for now, there's code calling...
I think we have already established the fact that I am not going ga-ga over SaaS and the hype machine which currently surrounds hosted software.
One frequent financial argument I always come across, on-line or off-line, for people choosing hosted software is the superiority of the subscription-based, pay monthly model, as a consumer. And to a large extent, this is an advantage that I cannot brush off easily. However, if we delve into the reasoning behind why people see this as a better model, it becomes apparent that these are exactly the kind of decisions that led to the excessive financial debt that plagues many people in their personal life.
People will gladly pay $19.99 a month, rather than a $149 up-front because the initial cost of the monthly option is nearly 10 times lower. Who can argue with that? If you decide 3 months into your product use that it isn't good enough, just cancel your account and you have only spent around $60. That is still a $90 saving over an up-front option. I am not really making my case here, am I?
Let me present another angle. What if you paid $149 for an up-front, self-hosted software product but it came with a 90 day refund policy? That is a total cost of zero to you.
What if you, for some weird reason, decided to stay with the product and the product offered free upgrades for up to a year? That is a total cost of $149 with your up-front option, while your hosted option comes to $240. What if you decided to use it for 2 years? This is a very realistic usage pattern for most people, where systems are used for years.
"Great! But what about the time and effort you spend installing, configuring and upgrading this self-hosted product." What if the product took an average of 5 minutes to install, configure and 5 minutes every time you upgraded it?
No matter how you look at this hypothetical situation, only 1 option makes financial sense for the person making the purchasing decision. Yet, it comes as no surprise to me that many would take the subscription option, because it allows you to "pay in instalments" despite the high overall cost.
To be clear, there are many domains and scenarios in which the hosted option is the better financial choice. For me, this is any up-front option that costs more than 24 to 30 times (because I expect to use most software on average for 2 years) the monthly subscription cost for the hosted option.
So what has SaaS got to do with the Credit Crunch? Nothing except the fact that the financial reasoning behind both seems very dubious!
With the release of fixx 1.6 we also published a basic REST API so you tech heads can create mashups to interface with fixx for your bug tracking needs. To get the ball rolling, Mark decided to go ahead and create a time-tracking widget using Adobe Air.
What's really nifty about Adobe Air is that it's completely cross platform, so whatever flavour of Operating System your currently rolling with, Marks widget will work fine with it.
Since we're all about Open-Source here at the lab, that's exactly what we decided to do with it, as "fixx-track" can be downloaded here, so give it a try for yourself...I'm sure you'll be impressed! Alternatively, go one better and extend it to meet your workflows.
Just to make clear this isn't an official release from hedgehog lab, as you can read Mark's experiences creating fixx track on his blog. It's more an opportunity to stress the cool things you can do with our fixx API, and we hope that this release will create some motivation for the programmers out there, to see the potential behind this opportunity. We'll even showcase your work on our site if we think it's good! Why don't you download a copy of fixx to play about with our uber API to see what you're made of.
Another small but equally useful tip I'd like to share with our readers is the ability to show and quickly navigate to any recently viewed issues within fixx. Access to this list is universal across fixx`s entirety and can be activated by hovering over the clock icon present in the bottom right corner of your screen.
This action brings into focus a list of the most recent issues this user has viewed, showing the corresponding Issue ID and Title for each of these in turn. Once present the user is able to navigate to each of these issues by selecting the appropriate one from this list.
The user also has the option to clear their history from this menu if they wish to do so. A point to note is that this pane remains present whilst scrolling and dissapears after a short period of inactivity.
The rationale behind this particular piece of functionality is to provide an easy means to navigate fixx without breaking system state by pressing your browsers back button. So the next time your busy jumping back and forth between a set of issues your currently working on, keep this feature in mind to max out your productivity levels!
I know a few of you have been holding your breath for this one, and we are pretty excited about this release too. Quite strange, considering 1.7 is
actually a bug fix release, rather than a feature-intensive one.
Nevertheless, we are very excited about the massive performance gains 1.7 gives and a reliable API. We have some interesting API-related tools and blog posts in the pipeline, so keep an eye out.
Our next stop is 1.8, which will be our final feature-intensive release for the 1.x branch (everything after that will be bug fix releases). Yes, this does mean that fixx 2.0 is already in development, and boy is it looking good! The biggest feature going into 1.8 will be a more complete API, with all the missing functionality
implemented, and some serious bundled tools/scripts for Source Control Integration and bespoke migration of bug tracking systems.
