5 reasons why Wired Up And Fired Up develop for (and
on) Macs
There's been a couple of posts
recently about why software companies support
the mac and I thought I'd throw my hat into the
ring and try to explain why Wired Up and Fired
Up are so mac-centric.
1) Macs are my tool of choice. As well as building Macintosh applications I do a lot of Java development and without a doubt Macs are the best platform for this work. I've occasionally had to work on client sites which give their developers Windows machines and it's really, really painful.
My main gripes with Windows (aside from usability issues) are related to things that any operating system should be able to do out of the box but windows can't, such as - SSH onto a server, find text in files (the dog doesn't work, I have tested it thoroughly, many, many times), cope with spaces in directory names and so on.
I simply can't imagine why anyone, given the choice, wouldn't use OS X which does all of these things and more whilst maintaining a friendly, easy to use attitude.
The only downside to using Macs for a Java dev is that the bleeding edge Java builds aren't always available. For example, Java 6 probably won't be around until Leopard which won't be around until October now. I've personally never found this a problem as I'm yet to find a client who is that up to date either (most banks round here are still thinking about whether Java 5 is a good idea or not). If I did, I'd run up some linux distro or other in VMWare or parallels and compile my code in there.
2) The developer community is, quite simply awesome. The majority of Mac developers have blogs and the majority of them are excellent at imparting information. There are also mailing lists, IRC channels and a veritable cornucopia of information available to help you get started irrespective of your abilities, choice of language or framework. Sometimes there's almost too much information, but fear not because almost all of it is good and I'm yet to come across anyone not willing to point you in the right direction if you ask nicely.
3) The user community is, quite simply awesome as well. As a consultant and I get to speak to a lot of clients and as an independent software developer I get to speak to a lot of customers and I can't think of a bad thing to say about any of them :) I get loads of feedback on all my apps - not all of it is positive but all of it is useful and it all gets fed back into making my current (and future) application portfolio better. I am also constantly amazed at how many contributions I get back from the user community; extra scripts for Relaunch, offers of localization help. It's almost as if everyone cares about making the OS X experience better for each other, which is, like, totally egalitarian and nice. Awww.
4) The development tools are not only free but excellent to boot. I know that XCode has it's foibles, but really they're not that bad. The CHUD tools are, again, invaluable and virtually anything that you cannot get for free from Apple you can get for free (or near as dammit) somewhere else. Compared to the Java IDE's I use (Eclipse/IDEA/NetBeans) I think the Apple Developer tools stack up really well and compared to buying an MSDN Subscription there's no contest - plus you don't have to learn C# (a language so complete it doesn't even have a Set in it's collections API)
5) Oh, right, did I mention the hardware? It's gorgeous (and reasonably reliable). In the bad old days I used to have a Toshiba Tecra running FreeBSD, I thought it was pretty cool at the time, it wasn't. It was horrible. It's still in the loft and occasionally when I go up there I look at it and shudder...
With regards to reliability I find Macs a bit like car engines, you either get a good one or you get a duffer. As a general rule of thumb, if it works when you take it out the box it'll probably be ok for quite a few years. I've still got an old iBook G3 kicking around, I had to replace the disk after about 4 years but it was constantly on and constantly in use (it still is, just for web browsing and other light duties). I quite often buy hardware from the Apple Refurb Store, I'm not sure I'm willing to recommend this approach, but over the years I've never had a problem with anything I've purchased this way - I like to think that it's better somehow, as it's had individual attention.
Those then, are my main reasons for developing for, supporting and using Macintosh computers and so far it's been a good relationship. I'd like to think that it will continue to be so.
1) Macs are my tool of choice. As well as building Macintosh applications I do a lot of Java development and without a doubt Macs are the best platform for this work. I've occasionally had to work on client sites which give their developers Windows machines and it's really, really painful.
My main gripes with Windows (aside from usability issues) are related to things that any operating system should be able to do out of the box but windows can't, such as - SSH onto a server, find text in files (the dog doesn't work, I have tested it thoroughly, many, many times), cope with spaces in directory names and so on.
I simply can't imagine why anyone, given the choice, wouldn't use OS X which does all of these things and more whilst maintaining a friendly, easy to use attitude.
The only downside to using Macs for a Java dev is that the bleeding edge Java builds aren't always available. For example, Java 6 probably won't be around until Leopard which won't be around until October now. I've personally never found this a problem as I'm yet to find a client who is that up to date either (most banks round here are still thinking about whether Java 5 is a good idea or not). If I did, I'd run up some linux distro or other in VMWare or parallels and compile my code in there.
2) The developer community is, quite simply awesome. The majority of Mac developers have blogs and the majority of them are excellent at imparting information. There are also mailing lists, IRC channels and a veritable cornucopia of information available to help you get started irrespective of your abilities, choice of language or framework. Sometimes there's almost too much information, but fear not because almost all of it is good and I'm yet to come across anyone not willing to point you in the right direction if you ask nicely.
3) The user community is, quite simply awesome as well. As a consultant and I get to speak to a lot of clients and as an independent software developer I get to speak to a lot of customers and I can't think of a bad thing to say about any of them :) I get loads of feedback on all my apps - not all of it is positive but all of it is useful and it all gets fed back into making my current (and future) application portfolio better. I am also constantly amazed at how many contributions I get back from the user community; extra scripts for Relaunch, offers of localization help. It's almost as if everyone cares about making the OS X experience better for each other, which is, like, totally egalitarian and nice. Awww.
4) The development tools are not only free but excellent to boot. I know that XCode has it's foibles, but really they're not that bad. The CHUD tools are, again, invaluable and virtually anything that you cannot get for free from Apple you can get for free (or near as dammit) somewhere else. Compared to the Java IDE's I use (Eclipse/IDEA/NetBeans) I think the Apple Developer tools stack up really well and compared to buying an MSDN Subscription there's no contest - plus you don't have to learn C# (a language so complete it doesn't even have a Set in it's collections API)
5) Oh, right, did I mention the hardware? It's gorgeous (and reasonably reliable). In the bad old days I used to have a Toshiba Tecra running FreeBSD, I thought it was pretty cool at the time, it wasn't. It was horrible. It's still in the loft and occasionally when I go up there I look at it and shudder...
With regards to reliability I find Macs a bit like car engines, you either get a good one or you get a duffer. As a general rule of thumb, if it works when you take it out the box it'll probably be ok for quite a few years. I've still got an old iBook G3 kicking around, I had to replace the disk after about 4 years but it was constantly on and constantly in use (it still is, just for web browsing and other light duties). I quite often buy hardware from the Apple Refurb Store, I'm not sure I'm willing to recommend this approach, but over the years I've never had a problem with anything I've purchased this way - I like to think that it's better somehow, as it's had individual attention.
Those then, are my main reasons for developing for, supporting and using Macintosh computers and so far it's been a good relationship. I'd like to think that it will continue to be so.
|
Lo-fi Command Line Timesheets
I am an avid user of the Todo.txt
command line task list script and have been
using it a lot recently since I went
all freelance.
In the same vein I've been looking for something that could keep track of my time-sheets for me. Now, I know there are some excellent apps out there already that do this, but I wanted something an order of magnitude simpler. In fact, all I needed to do was keep track of which days I had worked for a particular client.
So I came up with timesheet.sh, it's a simple script that you run from a unix command line. It creates a text file named after the current month (if there isn't one already) and in the text file you'll see the month's calendar courtesy of the tool 'cal' - the current day will be replaced by a couple of # symbols (marking it as 'worked').
All that I need to do every day when I'm doing work for this particular client is remember to type ./timesheet.sh in the terminal and the text file gets updated. When it comes to a new month the script simply creates a new file and carries on as if nothing had happened.
Here's how the file April currently looks for me...
I also added the ability to mark holidays (HH) and sick days (SS), you can see here that Good Friday and Easter Bank Holiday Monday are marked as holidays.
To do this you can just do ./timesheet.sh holiday or ./timesheet.sh sick
Of course, if you're not around to do this you can retrospectively do it in your fave text editor (which is probably called vi ;)
I'm not sure if this is of any use to anyone, but I thought I'd throw it out there and see. I had planned to extend it, but it does what I want for now so I haven't... If you do come up with any cool new ways of using it please let me know :)
Some things it could easily be modified to do include; tracking multiple clients (either using different file names or a directory structure), adding extra symbols for different events (including possibly, hours worked), counting up the number of days worked per week and over the month and perhaps even generating a .txt invoice (how cool, er, I mean retro, would that be?).
Anyway, the script is available for download below, remember you'll probably need to make it executable before you can run it.
Download timesheet.sh
In the same vein I've been looking for something that could keep track of my time-sheets for me. Now, I know there are some excellent apps out there already that do this, but I wanted something an order of magnitude simpler. In fact, all I needed to do was keep track of which days I had worked for a particular client.
So I came up with timesheet.sh, it's a simple script that you run from a unix command line. It creates a text file named after the current month (if there isn't one already) and in the text file you'll see the month's calendar courtesy of the tool 'cal' - the current day will be replaced by a couple of # symbols (marking it as 'worked').
All that I need to do every day when I'm doing work for this particular client is remember to type ./timesheet.sh in the terminal and the text file gets updated. When it comes to a new month the script simply creates a new file and carries on as if nothing had happened.
Here's how the file April currently looks for me...
I also added the ability to mark holidays (HH) and sick days (SS), you can see here that Good Friday and Easter Bank Holiday Monday are marked as holidays.
To do this you can just do ./timesheet.sh holiday or ./timesheet.sh sick
Of course, if you're not around to do this you can retrospectively do it in your fave text editor (which is probably called vi ;)
I'm not sure if this is of any use to anyone, but I thought I'd throw it out there and see. I had planned to extend it, but it does what I want for now so I haven't... If you do come up with any cool new ways of using it please let me know :)
Some things it could easily be modified to do include; tracking multiple clients (either using different file names or a directory structure), adding extra symbols for different events (including possibly, hours worked), counting up the number of days worked per week and over the month and perhaps even generating a .txt invoice (how cool, er, I mean retro, would that be?).
Anyway, the script is available for download below, remember you'll probably need to make it executable before you can run it.
Download timesheet.sh
Minimalist NoodleBoard
Many thanks to Ian Dean who has sent me a cut down
version of the NoodleBoard
widget.
He writes:
"The Dashboard as an idea is already messy so I have tried to streamline the graphics slightly so it looks like a plain whiteboard.
I am sending you the updated widget incase you find it useful."
A copy of the widget he sent is available here (click to download).
If you've never used NoodleBoard before, you'll probably want to head on over to www.noodleboard.com to find out more and set up an account.
He writes:
"The Dashboard as an idea is already messy so I have tried to streamline the graphics slightly so it looks like a plain whiteboard.
I am sending you the updated widget incase you find it useful."
A copy of the widget he sent is available here (click to download).
If you've never used NoodleBoard before, you'll probably want to head on over to www.noodleboard.com to find out more and set up an account.