In writing Herald, I ended up writing some code that is used to rotate the units on the battlefield. I eventually got off my lazy ass and released it as a jQuery UI plugin on github. So I’m announcing the release of jquery-ui-rotatable. If you use it, let me know – I’d love to see it in use around the place.
Category Archives: Tech
Herald made open source
I’ve not had a lot of time recently to work on Herald, so I’ve decided to make the source of it available on github. Please feel free to fork the repository there, make changes, submit any back that you think would benefit the project as a whole. Hopefully this work will help someone.
In general, my job has taken up all my spare time, so I’ve not had time to be on any forums, paint any miniatures or play any games (yes, it’s a bad situation). Hopefully these circumstances will change in the next month or two and I’ll be able to get back into painting, modeling and gaming again.
Herald Update Dec 3rd 2012
I’ve added the ability to save your report, which actually starts to make the software really usable. It’s a little bit ghetto, but easy enough to use. In the Game tab, click the “Export Report” button and a bunch of text will appear in a text area which you can then save in a file, e-mail to your buddy, whatever. Copy and paste that same text back into the text area and hit “Load Report” and you’re back in business.
Final features to be implemented should be done this week. I’ll be adding action icons to indicate things like shooting, death, and so forth. And most importantly, I’ll show battle damage to units, so that you can see the strength of the unit deteriorate (and grow, if you’re pesky undead) over the course of the battle. Once that’s all complete, I’ll take Herald out of alpha and start announcing the beta to a wider audience.
Announcing Herald Alpha
I’m pleased to announce the ‘alpha’ release for my Herald Battle Reporter software. You can read all about Herald here on my blog or you can just jump right in and start playing with the tool by clicking on the link below.
Why choose Python?
I like writing code in Python, as much as I’ve enjoyed writing code in any other language (and I’ve written in a bunch commercially).
I got to thinking today about what it is that really makes Python a great language. In fact, it’s missing some features that I like (e.g. closures). Obviously it has a whole bunch of cool features, but then so do most of the other dynamic languages (like Ruby, PHP or Perl) — for those of you who don’t know me, I’m much happier in a dynamic/interpreted language environment than a static/compiled one (and yes I know those pairs don’t strictly go hand-in-hand)
After thinking it through, I realized that it’s the maintainability of Python that makes it great. I can read through any Python that someone in my whole company has written and understand it and know why it’s working the way it is. And so can anyone else on my team, even without huge depth of experience in the language. The choices that have been made about its structure and support make it inclusive for anyone to be a part of the community, rather than inadvertently excluding certain types of people.
So, Python is now officially my language of choice, because more than any other language, it makes my team a happier place and wants me to be part of its community.
Mail, iCal, Snow Leopard and Exchange
I’ve been using iCal on Snow Leopard for about three months or so (I was on the pre-release program) as a replacement for Entourage. My company uses Microsoft Exchange for mail and calendar, and I thought it would be valuable to record my experiences with using Mail and iCal. I’d been using Entourage for both mail and calendar for over a year and had become somewhat frustrated by the unintuitive interface, so I was excited to be replacing it.
Setting up mail to work on Mail.app is very simple, assuming your Exchange server is correctly set up. Put in your e-mail address and password, and poof! it’s done. Calendaring on iCal set up must happen automatically as I don’t recall ever having to do anything there.
Mail has a somewhat frustrating keyboard shortcut for send (Cmd-Shift-D) compared to the Cmd-Enter of Entourage. That was my only real gripe, although I’ve been using Mail for long enough that this is really just a matter of retraining the fingers. Mail crashed and froze a couple of times importing all my e-mail from Exchange (I had about 20,000 messages, plus attachments) but eventually it got there. I can use the same security certificate to sign and encrypt e-mail as I did with Entourage, with no extra set up required, which was awesome. Typical mail use throughout the day is generally better, as the Mail app is more responsive and intuitive than Entourage, and integrates properly with all my other apps.
iCal however falls short in a lot of ways. Historically, I’ve had a love/hate relationship with iCal, primarily due to the months I spent writing SyncBridge, a failed app that was designed to fix a lot of the shortcomings of iCal. (Why did it fail? A buggy Apple API in Tiger (Sync Services, deprecated in Leopard) combined with Apple announcing their Calendar Server and me burning out trying to write the app while holding down a day job – I feel this historical context is important as I have no doubt it biases me). However, I was keen to give iCal the benefit of the doubt and I thought that surely anything would be better than Entourage.
The verdict? Well, it’s better in some ways and worse in others. Here’s the gripe list:
I cannot subscribe to any calendar other than my own. In organizations running Exchange, there are typically shared calendars that many users can read and write from – this is useful in things like event planning, team rota and so forth. I can’t access these at all from iCal.
iCal receives the click to highlight the window, and creates an event for me from that click, which I never intend – thus I waste time deleting the event.
All my events are the same colour. Yes, I can have multiple calendars and thus multiple colours, but as I said above I can only subscribe to my own calendar. Previously I would make things different colours so I could easily tell which meetings were regular recurrences that I’d booked versus stuff that my manager invited me to, versus stuff that someone not on my team invited me to, etc.
I can’t send any kind of message when I decline an event. This means I need to fire off an additional e-mail to say “Sorry, could you move this event forward an hour” or whatever. I also can’t accept or decline an event with sending a notification to the organizer (or the attendees when I’m the organizer). Not a big pain, until you discover that you also cannot cancel an edit. Yes, that’s right, if you edit an event and then decide that you don’t want to keep your changes – TOUGH LUCK! If you press Escape to close the editing window it asks you whether you want to send or go back to editing – no option to just throw away the edits! This was especially annoying when I made a change to meeting with 60 invitees that I didn’t need to send.
Also, I cannot update the meeting without also updating every attendee. This is annoying when I want to invite people to book the slot in their calendar, and then build up an agenda over time – I now need to keep the agenda separately, and fire an update just at the last minute.
Finally, forwarding an iCal invite requires a right-click. There is no menu option or context menu button or keyboard shortcut – you must right-click on the event and select “Mail Event”.
In summary then: Mail is an improvement on Entourage, iCal still needs a lot of work to come close to Entourage and Entourage is still short of Outlook. I know, I just said that a Microsoft app is a better than an Apple one. It’s true.
WordPress hacking
Anyone using WordPress should beware some nasty hacks, like that recently suffered by my good friend. Creators of malware should every bone in their hands broken. Twice.
My MacBook Pro is devalued
I’ve had my MBP since November. Thanks to Moore’s Law, there is now a faster and shinier version available, which means that the price for a used 2.4Ghz MacBook Pro with the same specs as mine has dropped to about $2000 (according to eBay).
This is actually good news for me. I was considering selling the laptop so I could help fund various other things I needed to do. By the time I’m able to sell, the price will be low enough that it won’t be worth my while 
Command Line History Meme
From Cimota.
cat ~/.zshist | awk '{a[$1]++} END {for(i in a)print a[i] ” ” i}’ | sort -rn | head -10
2870 ls
2444 cd
659 vi
348 rm
254 svn
232 ssh
206 telnet
182 whois
180 egrep
179 sudo
From nothing to something: iterative app development
1. Prove it works
write the simplest code possible to show one thing working end-to-end
This can be as horrible and hackish as needed. I regularly hardcode things like URLs, integers, strings, file names/paths: whatever is needed just to show that the idea works. E.g. for Rickshaw, I started off by always sending a file called rickshaw.png, which just got removed and replaced by a URL – the URL in the e-mail was hardcoded to be a reference to http://localhost/~aidan/rickshaw.png, and I happened to have the file in that directory. The whole workflow appeared to work, even though none of the upload magic was there. I proved out two concepts though:
- that attachments could be manipulated after sending
- that the resulting e-mail still made sense
2. Add to it
write the next most important bit simply, then test it all
This can be harder than you think. Not the writing, but choosing what bit is the next most important. For me, I wanted to have that file be written dynamically. The important thing is to keep it small – do it, test it and be happy with it. Some things lend themselves to automated testing: some don’t. I’m a fan of test-driven development, but I don’t get hung up on ensuring coverage – look at Microsoft Windows Vista: excellent automated test coverage, crappy user experience. Test manually where it makes sense, and automatically where needed.
3. Repeat step 2
You go from your tasks being “remove hardcoded URL and replace with URL generation code” to “Add application icon” and “Build website to sell app”. One step at a time, doing the most important thing at any given time.
Rickshaw had no user interface for quite some time – it was just a plug-in that was copied from the command line. Eventually that was good enough that a UI for configuring it was the most important thing. Then a button that tested the configuration before using it. Then some code to install the plug-in. License keys. Usability enhancements. And so on.
None of this is new or original – it’s all common sense, especially if you’ve worked in an agile development team before. The great thing about working this way is you see results early on. I had a working prototype of Rickshaw which did “uploads” to localhost (using NSData writeToFile:atomically) within a week, and real uploads within three weeks. The downside is that you feel very close to finishing at an early stage.
If you consider the entirety of what’s needed to build an app as being 100% of the effort, I’d lay out the effort required for different parts as something like this:
- Hack to prove concept: 5%
- Prototype to prove hack: 15%
- Making prototype robust: 30%
- Getting it ready for users: 50%
Open source projects are one of the first three stages (corresponding roughly to ‘alpha’, ‘beta’ and ’stable’ projects). The last stage takes just as long as the first three, and it’s the reason why commercial Mac apps (in particular) are better than open source apps for Linux – as much time has been spent getting the application to work well for users as has been spent getting the application to work for the developers.
If you’re developing an app for any platform, ensuring you spend the time in that last stage is what will make your work stand out.