Work
Woah!
(null)/(null)/(null) (null) | Permalink
It's been months since I last did a post, needless to
say things have been a little busy. Firstly, I
finally made it over to France so it's farewell
cheerless marshes and bonjour Europe. I've spent the
last little while (er, six months) settling in and
working on a couple of ongoing contracts, things are
going well and I've pretty much sorted out everything
that I needed to sort out
(banks/utilities/taxes/welfare etc.) so I'm back at
the coal face cutting Cocoa code once more (and
updating this site).
Today though, I'd like to talk about CornerWeight, the free and handy car weight calculator. On the suggestion of one of it's users, John Thawley I've updated it and added a cross weight calculation. Now, the cross weight calculation is right hand drive oriented, which means that if you want it the other way you need to subtract the figure from 100. The new 'facelift' widget looks like this, I hope that you find it an improvement.
Click here to download
and install CornerWeight
I have a few planned updates to the remainder of the existing products and two new products in the pipeline, so stay tuned...
Today though, I'd like to talk about CornerWeight, the free and handy car weight calculator. On the suggestion of one of it's users, John Thawley I've updated it and added a cross weight calculation. Now, the cross weight calculation is right hand drive oriented, which means that if you want it the other way you need to subtract the figure from 100. The new 'facelift' widget looks like this, I hope that you find it an improvement.
I have a few planned updates to the remainder of the existing products and two new products in the pipeline, so stay tuned...
|
The oddest prime
(null)/(null)/(null) (null) | Permalink
Hot on the heels of the 25th anniversary of the
ZX Spectrum I'm pleased to announce that
Wired Up and Fired Up are two years old.
I'd like to thank all our clients and customers past and present for their support.
Over the next couple of days I'll try to blog about what's happened in the past couple of years and anything I may have learned along the way...
I'd like to thank all our clients and customers past and present for their support.
Over the next couple of days I'll try to blog about what's happened in the past couple of years and anything I may have learned along the way...
The wrong decision.
(null)/(null)/(null) (null) | Permalink
It's taken me a month to write this post. Not because
I'm a particularly slow typist nor because I couldn't
be bothered but because I've been very busy recently
making some wrong decisions.
Firstly, I have quit a very lucrative contract with an Investment Bank to concentrate on my freelance work and mac software development.
Secondly, I've sold my house and it looks increasingly like (almost certain, in fact) that we're going to move to France.
Wrong decisions are fantastics ones to make.
I know they're wrong decisions because when I tell people about them they look at me with a furrowed brow and they nod slowly and ask questions like - 'will you get a pension there?' and 'what if you can't find enough work?'
To which I reply, 'I honestly have no idea.' and 'I'll just have to make sure I do.'
There's really only one way to find out if this is really a wrong decision or not and I'd rather have a go than live with the regret of not knowing.
Firstly, I have quit a very lucrative contract with an Investment Bank to concentrate on my freelance work and mac software development.
Secondly, I've sold my house and it looks increasingly like (almost certain, in fact) that we're going to move to France.
Wrong decisions are fantastics ones to make.
I know they're wrong decisions because when I tell people about them they look at me with a furrowed brow and they nod slowly and ask questions like - 'will you get a pension there?' and 'what if you can't find enough work?'
To which I reply, 'I honestly have no idea.' and 'I'll just have to make sure I do.'
There's really only one way to find out if this is really a wrong decision or not and I'd rather have a go than live with the regret of not knowing.
Apropos of nothing...
(null)/(null)/(null) (null) | Permalink
We've been playing with Windows PowerShell at a
client site a little recently. Largely, on my part,
for amusement but also to see how 'the other half' do
things. It's an (almost) proper shell for Windows and
it's not half bad, slow as Christmas, but not bad.
My ex-colleague Adrian, aka millinad has been doing a lot more with it than I could ever be bothered to so, if you're interested I suggest you check out his blog about it.
We also knocked out a mostly functional Space Invaders clone. Hoo Hoo Ha! As Dr. Kawashima would say (repeatedly).
My contribution to the world of computer science and powershellian advancement is a fully functional Brainf*ck interpreter written in PowerShell. For those of you who don't know brainf*ck is a minimalist programming language comprising of only 8 instructions. Yes, eight. None the less it is Turing Complete and capable of computing any computable function of simulating any other computational model (just not very easily).
Still, I found it an interesting exercise and thought I'd share...
bf.ps1 - The PowerShell brainf*ck interpreter (thanks to Nik Crabtree for speeding up the 'memory' initialization)
add.bf - Adds two single-digit integers together (so long as the result is < 9)
triangle.bf - Draws the Sierpinski triangle
pi.bf - Calculates pi to 15 digits (if you can be bothered to wait, it took me 10 minutes to get to the 3!)
Oh, right, and Hello World which, for those of you who've yet to sample the delights of the language I've also printed below...
You can run the programs in PowerShell with :
Why am I writing about this? I couldn't think of anything pithy to say about the iPhone other than that, yes, I want one. And I had this kicking around for a rainy day and guess what - it's raining.
My ex-colleague Adrian, aka millinad has been doing a lot more with it than I could ever be bothered to so, if you're interested I suggest you check out his blog about it.
We also knocked out a mostly functional Space Invaders clone. Hoo Hoo Ha! As Dr. Kawashima would say (repeatedly).
My contribution to the world of computer science and powershellian advancement is a fully functional Brainf*ck interpreter written in PowerShell. For those of you who don't know brainf*ck is a minimalist programming language comprising of only 8 instructions. Yes, eight. None the less it is Turing Complete and capable of computing any computable function of simulating any other computational model (just not very easily).
Still, I found it an interesting exercise and thought I'd share...
bf.ps1 - The PowerShell brainf*ck interpreter (thanks to Nik Crabtree for speeding up the 'memory' initialization)
add.bf - Adds two single-digit integers together (so long as the result is < 9)
triangle.bf - Draws the Sierpinski triangle
pi.bf - Calculates pi to 15 digits (if you can be bothered to wait, it took me 10 minutes to get to the 3!)
Oh, right, and Hello World which, for those of you who've yet to sample the delights of the language I've also printed below...
>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]>++++++++[<++++>-]<.>+++++++++++[<++++++++>-]<-.--------.+++.------.--------.[-]>++++++++[<++++>-]<+.[-]++++++++++.
You can run the programs in PowerShell with :
./bf.ps1 add.bf
Why am I writing about this? I couldn't think of anything pithy to say about the iPhone other than that, yes, I want one. And I had this kicking around for a rainy day and guess what - it's raining.
Get funky at the meta-level.
(null)/(null)/(null) (null) | Permalink
For a long time I've had a theory that subsequent
generations of programmers should (and to a large
part do) stand on the shoulders of their forebears.
Each new generation of languages really being an
abstraction layer on top of previous ones.
In biblical terms it would go something like: Assembler begat Fortran; and Fortran begat Lisp; and Lisp begat COBOL and his brethren ALGOL... and so on, and lots of forking around and incest later we end up more or less where we are today. The point is, that as we progressed complex things got abstracted away to make life easier for the next lot. Fairly quickly, registers, interrupts and dealing with hardware became something Joe Programmer didn't have to deal with directly, later memory management and now even mind bogglingly complex concepts are a mere API call away.
And, that's probably right.
Every time I see an ostensibly simple computing problem (and let's face it, the problem domain in many corporate environments is often will-shatteringly trivial) made (complex^2) by genius hero coders - well, a small piece of me dies and floats away. You only need take an occasional gander at The Daily WTF to see real life examples of this happening on a project near you.
There are, I think, two main profiles for the people who do this; those who don't know any better and those who are bored and so re-invent the challenge into something more interesting to get them through the day. And, I give a small tip of the hat to the second camp as I understand their pain.
However...
Have you seen those mashup sites the kids are making with Google Maps and flickr and god knows what else? I doubt, if you looked at the code for any one of them that you'd find an optimal binary search algorithm or Euclidian approximations for pinning the cute flags in the right place. Why? Because they're mashups. Google has done the hard work and they've just taken it, bent it and thrown it out to the world as fait accompli.
People in the previous generation will mutter under their breaths about how the young whippersnappers don't truly understand what's going on - 'how could they possibly understand the fundamentals of geolocation?' and the young whippersnappers stick two fingers up at the old guard and say, 'thanks for the tools - we're doing it our way now grandpa!'
I know. "How Post Modern!", you're thinking and you're right, I am. I'd never heard of Post Modern Programming until recently but a lot of what they're saying rings true - to me at least. There's been, what, 40 years of squillions of really smart people writing software and if you don't think there's anything in their output worth borrowing then I'm not sure you're in the right job. Of course, we all reuse code all the time, right? Well, if that's true then why do I keep stumbling across functions to determine the length of strings or sort an array? Sure, understanding the fundamentals is important but I'd argue that it's not as important as making the best use of the tools at your disposal and no, I don't necessarily think the first implies the second.
The reality of programming in 2006 is that you're mashing existing things together - be they 3rd party jars in your class path, web services, the Cocoa framework or even getting out a Knuth book and using his binary search algorithm rather than writing your own.
Most of the clever stuff has been done at the lower level by really smart people and it's now time to get funky at the meta-level.
In biblical terms it would go something like: Assembler begat Fortran; and Fortran begat Lisp; and Lisp begat COBOL and his brethren ALGOL... and so on, and lots of forking around and incest later we end up more or less where we are today. The point is, that as we progressed complex things got abstracted away to make life easier for the next lot. Fairly quickly, registers, interrupts and dealing with hardware became something Joe Programmer didn't have to deal with directly, later memory management and now even mind bogglingly complex concepts are a mere API call away.
And, that's probably right.
Every time I see an ostensibly simple computing problem (and let's face it, the problem domain in many corporate environments is often will-shatteringly trivial) made (complex^2) by genius hero coders - well, a small piece of me dies and floats away. You only need take an occasional gander at The Daily WTF to see real life examples of this happening on a project near you.
There are, I think, two main profiles for the people who do this; those who don't know any better and those who are bored and so re-invent the challenge into something more interesting to get them through the day. And, I give a small tip of the hat to the second camp as I understand their pain.
However...
Have you seen those mashup sites the kids are making with Google Maps and flickr and god knows what else? I doubt, if you looked at the code for any one of them that you'd find an optimal binary search algorithm or Euclidian approximations for pinning the cute flags in the right place. Why? Because they're mashups. Google has done the hard work and they've just taken it, bent it and thrown it out to the world as fait accompli.
People in the previous generation will mutter under their breaths about how the young whippersnappers don't truly understand what's going on - 'how could they possibly understand the fundamentals of geolocation?' and the young whippersnappers stick two fingers up at the old guard and say, 'thanks for the tools - we're doing it our way now grandpa!'
I know. "How Post Modern!", you're thinking and you're right, I am. I'd never heard of Post Modern Programming until recently but a lot of what they're saying rings true - to me at least. There's been, what, 40 years of squillions of really smart people writing software and if you don't think there's anything in their output worth borrowing then I'm not sure you're in the right job. Of course, we all reuse code all the time, right? Well, if that's true then why do I keep stumbling across functions to determine the length of strings or sort an array? Sure, understanding the fundamentals is important but I'd argue that it's not as important as making the best use of the tools at your disposal and no, I don't necessarily think the first implies the second.
The reality of programming in 2006 is that you're mashing existing things together - be they 3rd party jars in your class path, web services, the Cocoa framework or even getting out a Knuth book and using his binary search algorithm rather than writing your own.
Most of the clever stuff has been done at the lower level by really smart people and it's now time to get funky at the meta-level.
Quick check out Qwickr
(null)/(null)/(null) (null) | Permalink
If you're a Java developer you ought to check out
Qwickr at your earliest
convenience.
It's a JPA (Java Persistence Architecture) tool for JEE5 applications. It's a pretty neat piece of software engineering that essentially gives you direct access to your underlying entity model using little more than a web browser.
Why is this good? Well, for a start you can construct and drill down into queries against your entity model in JPQL (which to developers may be simpler than SQL), it also extends JPQL and allows for INSERT statements. This means that you have effectively complete access to your underlying data as your applications see it. So, no more flushing caches when you need to simply change a record.
I can think of a whole bunch of times that this would have saved my life when working on a recent EJB3 project.
It's a JPA (Java Persistence Architecture) tool for JEE5 applications. It's a pretty neat piece of software engineering that essentially gives you direct access to your underlying entity model using little more than a web browser.
Why is this good? Well, for a start you can construct and drill down into queries against your entity model in JPQL (which to developers may be simpler than SQL), it also extends JPQL and allows for INSERT statements. This means that you have effectively complete access to your underlying data as your applications see it. So, no more flushing caches when you need to simply change a record.
I can think of a whole bunch of times that this would have saved my life when working on a recent EJB3 project.
What's with the new site?
(null)/(null)/(null) (null) | Permalink
Well, for those of you that didn't go to CocoaDevHouse London you missed
out on some excellent gifts from the main
sponsor RealMac Software.
One of which was a copy of RapidWeaver, their flagship product. I'd been looking for an alternative to iWeb for a while now as I've been having all kinds of problems trying to set up the funky stuff such as Google Ads. I know that you can use the likes of iWebEnhancer and I did, a couple of times, but it wasn't really what I was looking for.
I had looked at RapidWeaver, but never really figured out if it would do what I wanted it to do. Fortunately (for me) Nik Fletcher did an excellent short presentation on how to use it and answered all of my questions. The long and short of it is that you have a lot more control in RapidWeaver than you do in iWeb and it's an ace little product that is manufactured in the UK.
One of which was a copy of RapidWeaver, their flagship product. I'd been looking for an alternative to iWeb for a while now as I've been having all kinds of problems trying to set up the funky stuff such as Google Ads. I know that you can use the likes of iWebEnhancer and I did, a couple of times, but it wasn't really what I was looking for.
I had looked at RapidWeaver, but never really figured out if it would do what I wanted it to do. Fortunately (for me) Nik Fletcher did an excellent short presentation on how to use it and answered all of my questions. The long and short of it is that you have a lot more control in RapidWeaver than you do in iWeb and it's an ace little product that is manufactured in the UK.
Packaging OSX Applications Part 2
(null)/(null)/(null) (null) | Permalink
So, some smart-arse emailed me (Hi, Ron), with a
suggested improvement to the script I published
yesterday, and you know, he’s right...
His suggestion was to use a compressed .dmg as opposed to zipping the image as it creates less clutter for your users when they come to use it. He sent a patch, so here’s the updated package.sh
(Note - you can use the new -b option when finalising the image to create a bzipped image, without it you get a zlib zipped image)
The next thing I wanted to get onto was how you can set the background image of your .dmg, like everyone seems to do these days. Well, here is the easiest way I know.
1. Create your temporary DMG, open it and in it create a normal folder called hidden
2. Copy a suitable image into the ‘hidden’ folder
3. Show the View Options inspector (option-j) and select ‘This window only’ and change the background picture to the one in your ‘hidden’ folder.
4. Open the Terminal.app and navigate to your mounted drive (i.e. cd /Volumes/MyApp-temp )
5. Rename the ‘hidden’ folder to ‘.hidden’ (i.e. mv hidden .hidden )
Unmount and finalise your dmg and go to the pub..
His suggestion was to use a compressed .dmg as opposed to zipping the image as it creates less clutter for your users when they come to use it. He sent a patch, so here’s the updated package.sh
(Note - you can use the new -b option when finalising the image to create a bzipped image, without it you get a zlib zipped image)
The next thing I wanted to get onto was how you can set the background image of your .dmg, like everyone seems to do these days. Well, here is the easiest way I know.
1. Create your temporary DMG, open it and in it create a normal folder called hidden
2. Copy a suitable image into the ‘hidden’ folder
3. Show the View Options inspector (option-j) and select ‘This window only’ and change the background picture to the one in your ‘hidden’ folder.
4. Open the Terminal.app and navigate to your mounted drive (i.e. cd /Volumes/MyApp-temp )
5. Rename the ‘hidden’ folder to ‘.hidden’ (i.e. mv hidden .hidden )
Unmount and finalise your dmg and go to the pub..
Packaging OSX Applications Part 1
(null)/(null)/(null) (null) | Permalink
Something new is coming soon from Wired Up and Fired
Up Ltd and I’ve been looking at packaging recently.
There are two popular options for packaging an OS X application namely, a zipped package (.pkg) file or the zipped drive image (.dmg) and choosing one is really down to the type of application you are planning to unleash.
Ninjar, for example, uses a packaged install. This is because it’s a Spotlight plugin and needs installing somewhere off the beaten track that you probably don’t want to explain to most users. It also kicks off a spotlight re-index of the disk on install, again something that a managed install can do neatly without bothering anyone.
Most simple applications however, are better served by distributing them as a zipped drive image. You know the routine - image mounts, drag the new app to the /Applications folder and trash the image. Sorted!
So how do you go about creating the .dmg and putting your app into it? And how about getting a funky background image in there as well, like they do in that fancy Adium?
Well, I’ve put together a packaging script that simplifies this process to:
1. Run script to create a temporary .dmg of a specified size and name
2. Mount the .dmg and copy your application (and any supporting files) into it
3. Unmount the application
4. Run the script again to finalize the .dmg and zip it up ready to distribute
So, how does this work?
Firstly download package.sh
1. Copy it to somewhere into your home folder (easiest as you have full permissions there).
2. Launch Terminal.app from /Applications/Utilities
3. Change directory (‘cd’) to wherever you copied the packaging script and give it execute permissions i.e.
chmod +x package.sh
4. Run the script to create a temporary .dmg of a specified size, e.g.
./package.sh -a AppName -m 2
5. This will have created an image called AppName-temp.dmg roughly 2Mb in size.
6. In the Finder, navigate to the AppName-temp.dmg and mount it by opening it, it should mount on your desktop with the name ‘AppName’
7. Drag your application (and anything else) into the AppName drive on your desktop. When you are finished eject the drive by dragging it into the trash.
8. Back in Terminal.app run the script again to finalize and zip your image, e.g.
./package.sh -a AppName -f
Er, that’s it! You should now have an AppName.dmg.zip to distribute.
I’ve been using this script to help bundle up the beta versions of ‘the new thing’ and it seems to be working well. Feel free to distribute the script, add to it or mail me with suggestions. It is distributed under a Creative Commons Attribution license.
As for the funky background image, I’ll cover that in a later post....
There are two popular options for packaging an OS X application namely, a zipped package (.pkg) file or the zipped drive image (.dmg) and choosing one is really down to the type of application you are planning to unleash.
Ninjar, for example, uses a packaged install. This is because it’s a Spotlight plugin and needs installing somewhere off the beaten track that you probably don’t want to explain to most users. It also kicks off a spotlight re-index of the disk on install, again something that a managed install can do neatly without bothering anyone.
Most simple applications however, are better served by distributing them as a zipped drive image. You know the routine - image mounts, drag the new app to the /Applications folder and trash the image. Sorted!
So how do you go about creating the .dmg and putting your app into it? And how about getting a funky background image in there as well, like they do in that fancy Adium?
Well, I’ve put together a packaging script that simplifies this process to:
1. Run script to create a temporary .dmg of a specified size and name
2. Mount the .dmg and copy your application (and any supporting files) into it
3. Unmount the application
4. Run the script again to finalize the .dmg and zip it up ready to distribute
So, how does this work?
Firstly download package.sh
1. Copy it to somewhere into your home folder (easiest as you have full permissions there).
2. Launch Terminal.app from /Applications/Utilities
3. Change directory (‘cd’) to wherever you copied the packaging script and give it execute permissions i.e.
chmod +x package.sh
4. Run the script to create a temporary .dmg of a specified size, e.g.
./package.sh -a AppName -m 2
5. This will have created an image called AppName-temp.dmg roughly 2Mb in size.
6. In the Finder, navigate to the AppName-temp.dmg and mount it by opening it, it should mount on your desktop with the name ‘AppName’
7. Drag your application (and anything else) into the AppName drive on your desktop. When you are finished eject the drive by dragging it into the trash.
8. Back in Terminal.app run the script again to finalize and zip your image, e.g.
./package.sh -a AppName -f
Er, that’s it! You should now have an AppName.dmg.zip to distribute.
I’ve been using this script to help bundle up the beta versions of ‘the new thing’ and it seems to be working well. Feel free to distribute the script, add to it or mail me with suggestions. It is distributed under a Creative Commons Attribution license.
As for the funky background image, I’ll cover that in a later post....
CocoaDevHouse Update
(null)/(null)/(null) (null) | Permalink
Things, on the whole, are going swimmingly.
Thanks to our main sponsors...
So far we’re looking at holding the inaugural event at the Idea Store, Canary Wharf, London on the 9th Sept. The event is open to anyone from seasoned Cocoa Developers, to Macintosh newcomers and beyond, so don’t be shy pop in and say hello!
Stop by our wiki page to say hi and get the full story.
For those of you that haven’t heard of CocoaDevHouse then read on...
“CocoaDevHouse is a periodic local hackathon inspired by the Bay Area SuperHappyDevHouse. This ain’t your regular user group meeting at the library! (not that there’s anything wrong with that)
In the wiki spirit of Barcamp, this event is self-organizing, i.e., there is no permission necessary to start one in your city. Simply join a local event or start your own.
Whether you’re a nOOb, haXor, web developer, etc. bring your MacBook and get your Xcode on!
You’re invited to hang with other Cocoa ninjas - form green to black belt on IRC:
#cocoadevhouse on freenode.irc.net
For a glimpse of the action, joing the Flickr group.”
See you there!
Richy
So far we’re looking at holding the inaugural event at the Idea Store, Canary Wharf, London on the 9th Sept. The event is open to anyone from seasoned Cocoa Developers, to Macintosh newcomers and beyond, so don’t be shy pop in and say hello!
Stop by our wiki page to say hi and get the full story.
For those of you that haven’t heard of CocoaDevHouse then read on...
“CocoaDevHouse is a periodic local hackathon inspired by the Bay Area SuperHappyDevHouse. This ain’t your regular user group meeting at the library! (not that there’s anything wrong with that)
In the wiki spirit of Barcamp, this event is self-organizing, i.e., there is no permission necessary to start one in your city. Simply join a local event or start your own.
Whether you’re a nOOb, haXor, web developer, etc. bring your MacBook and get your Xcode on!
You’re invited to hang with other Cocoa ninjas - form green to black belt on IRC:
#cocoadevhouse on freenode.irc.net
For a glimpse of the action, joing the Flickr group.”
See you there!
Richy
Ninjar
(null)/(null)/(null) (null) | Permalink
Spotlight seems to be one of the most widely ignored
improvements in OS X 10.4 (Tiger).
However, I thought this would be a good use for it (at least if you’re a Java developer of any kind).
Essentially, it’s an importer that reads the content of .jar (Java Archive) files and publishes this as metadata to spotlight. Enabling you to search for class and package names and have spotlight do the legwork for you. No more renaming jars as zip files and unzipping them to rummage through them in the finder.
It should also help in resolving class-path and naming conflicts. Anyway, it’s free for anyone to use although donations towards it’s upkeep are being gratefully accepted if you find it useful.
However, I thought this would be a good use for it (at least if you’re a Java developer of any kind).
Essentially, it’s an importer that reads the content of .jar (Java Archive) files and publishes this as metadata to spotlight. Enabling you to search for class and package names and have spotlight do the legwork for you. No more renaming jars as zip files and unzipping them to rummage through them in the finder.
It should also help in resolving class-path and naming conflicts. Anyway, it’s free for anyone to use although donations towards it’s upkeep are being gratefully accepted if you find it useful.
Consensus killed the cat
(null)/(null)/(null) (null) | Permalink
This insightful blog post pretty much sums up my
feelings on consensus based decision making.
http://www.carte-blanche.org/issues/04/grassmann.html
I shudder to think of the amount of productive time (both micro i.e. personal and macro i.e. company) wasted trying to get a bunch of people to come to a consensus. The other problem with a consensus opinion is it never reflects anyone’s personal opinion, so no one can ever really get behind it and champion it and consequentially no one really cares.
As they sagely used to say, “in all the towns and all the cities, there are no statues to committees. “
http://www.carte-blanche.org/issues/04/grassmann.html
I shudder to think of the amount of productive time (both micro i.e. personal and macro i.e. company) wasted trying to get a bunch of people to come to a consensus. The other problem with a consensus opinion is it never reflects anyone’s personal opinion, so no one can ever really get behind it and champion it and consequentially no one really cares.
As they sagely used to say, “in all the towns and all the cities, there are no statues to committees. “
One kind of stuff
(null)/(null)/(null) (null) | Permalink
I’ve been looking at Seam
(http://www.jboss.com/products/seam) for a while and
recently attended a seminar with Gavin King himself
talking about it. However, I never really got around
to taking the plunge.
Wired Up And Fired Up were early adopters of EJB3 and have been using it now in production systems for over a year and, yes, it really is that much better. In fact, it is with great reticence now that we undertake any kind of legacy J2EE application work (unless it’s a migration to EJB3 of course...)
But for the most part we’ve stuck with a couple of old (and bad) habits when implementing web UIs. I think this was largely because I’ve been a web programmer since the days when a thorough knowledge of the state of state management was de rigeur and so any major abstraction on top of this just seemed to confuse the issue. To be fair, most web application frameworks *DO* confuse the issue.
Seam, it seems, will enable us to redress the balance a little bit. By leveraging the JSF component model we’re now looking forward to being able to create our own suite of web components as well as buying in components when required, however that’s not all...
Seam also extends on the three basic contexts typically available to web application developers (Application, Session and Request) and brings a new ‘unified’ context model to the table (Seam’s contexts are Application, Business Process, Session, Conversation, Page and Event).
Why more contexts? Well, if you as a developer are trying to track a user across several different requests, what do you do? Put something in the session and check for it’s existence? The problem with that is that the user is then precluded from performing similar actions in a different browser or tab at the same time. Also, you need to make decisions about session time outs and ensure that you clear out the session when the user starts doing something else otherwise your application tends to get horribly confused.
The Conversation context offered by Seam allows for this, it remains scoped to a browser window instance and is accessible across multiple requests.
The Business Process context effectively connects you into the powerful long-running, multi-user state management concepts afforded by a BPM engine, see Tackling complexity with crayons
While the Event context is roughly synonymous with the traditional Request and the Page context allows you to associate state with a particular page.
All the while Seam is working away in the background like a ‘state garbage collector’ cleaning up out of scope variables and abandoned conversations.
The main beauty of Seam though is it’s unification of the main concepts of EJB and JSF allowing you to bind Session Beans to page events and Entity Beans to the same page without the need for layers of facades, managers and locators. And all the while fixing a large proportion of those frequently encountered ‘back button’ issues and interrupted page flow problems (a problem for which we once even designed an ‘interruptible dispatcher’ based on a kind of request stack).
I’ve been at this for a little while now and, while there is a learning curve, I’m convinced that this is about as productive as Java Enterprise developers have ever been able to be.
Wired Up And Fired Up were early adopters of EJB3 and have been using it now in production systems for over a year and, yes, it really is that much better. In fact, it is with great reticence now that we undertake any kind of legacy J2EE application work (unless it’s a migration to EJB3 of course...)
But for the most part we’ve stuck with a couple of old (and bad) habits when implementing web UIs. I think this was largely because I’ve been a web programmer since the days when a thorough knowledge of the state of state management was de rigeur and so any major abstraction on top of this just seemed to confuse the issue. To be fair, most web application frameworks *DO* confuse the issue.
Seam, it seems, will enable us to redress the balance a little bit. By leveraging the JSF component model we’re now looking forward to being able to create our own suite of web components as well as buying in components when required, however that’s not all...
Seam also extends on the three basic contexts typically available to web application developers (Application, Session and Request) and brings a new ‘unified’ context model to the table (Seam’s contexts are Application, Business Process, Session, Conversation, Page and Event).
Why more contexts? Well, if you as a developer are trying to track a user across several different requests, what do you do? Put something in the session and check for it’s existence? The problem with that is that the user is then precluded from performing similar actions in a different browser or tab at the same time. Also, you need to make decisions about session time outs and ensure that you clear out the session when the user starts doing something else otherwise your application tends to get horribly confused.
The Conversation context offered by Seam allows for this, it remains scoped to a browser window instance and is accessible across multiple requests.
The Business Process context effectively connects you into the powerful long-running, multi-user state management concepts afforded by a BPM engine, see Tackling complexity with crayons
While the Event context is roughly synonymous with the traditional Request and the Page context allows you to associate state with a particular page.
All the while Seam is working away in the background like a ‘state garbage collector’ cleaning up out of scope variables and abandoned conversations.
The main beauty of Seam though is it’s unification of the main concepts of EJB and JSF allowing you to bind Session Beans to page events and Entity Beans to the same page without the need for layers of facades, managers and locators. And all the while fixing a large proportion of those frequently encountered ‘back button’ issues and interrupted page flow problems (a problem for which we once even designed an ‘interruptible dispatcher’ based on a kind of request stack).
I’ve been at this for a little while now and, while there is a learning curve, I’m convinced that this is about as productive as Java Enterprise developers have ever been able to be.
NewdleBoard
(null)/(null)/(null) (null) | Permalink
Last week I managed to sneak out a new version of the
NoodleBoard.
I’ve got a lot of paying work on at the moment, so keeping the ‘free-ware’ side of the business up-to-date has been hard. However I was really pleased with the new UI, which was done by Victoria Weston (a London based web/graphic designer) and I’d managed to fix a few bugs so it seemed a shame to sit on it all until the next major functional release, so we sneaked this out the door.
So far it’s been impressive and there has been a marked increase in downloads and sign-ups.
A few people have asked me, “What’s the point in NoodleBoard? Isn’t it just costing you money?”
And, well, yeah, it is. But not much, what it is doing however is proving some very interesting points...
Firstly, the server side of NoodleBoard is running on a virtualized installation of Fedora Core Linux (i.e. a shared server), it is written in J5EE (EJB3) and it all sits inside a JBoss 4.0.x server. And I’ve not had to reboot it once since it launched.
I’ve redeployed the entire server application a couple of times, but the JBoss deployer is extremely robust and I doubt anyone even noticed (and no, it’s not because no-one uses it :)
Secondly, I have learned a lot about selling (well giving away) software and support to end-users. As a consultant I’m all too used to finding solutions to, often in-house, business problems and really letting the client deal with the running of things. Now, I’m getting emails and even the occasional call about all sorts from all kinds of users - most (thankfully) are grateful and pleasant, a few are not.
I try and reply to them all with the kind of reply that I would expect.
Thirdly, marketing has become an interest of mine and it’s up there alongside version control systems and design patterns... I’m finding it fascinating, especially how quickly posts on blogs tend to cascade down and directly affect download rates, even on a small project like this.
I suppose the one thing I’ve learned since launching is that there’s still a lot left to learn. I think that being constantly reminded this is worth the bandwidth fees.
I’ve got a lot of paying work on at the moment, so keeping the ‘free-ware’ side of the business up-to-date has been hard. However I was really pleased with the new UI, which was done by Victoria Weston (a London based web/graphic designer) and I’d managed to fix a few bugs so it seemed a shame to sit on it all until the next major functional release, so we sneaked this out the door.
So far it’s been impressive and there has been a marked increase in downloads and sign-ups.
A few people have asked me, “What’s the point in NoodleBoard? Isn’t it just costing you money?”
And, well, yeah, it is. But not much, what it is doing however is proving some very interesting points...
Firstly, the server side of NoodleBoard is running on a virtualized installation of Fedora Core Linux (i.e. a shared server), it is written in J5EE (EJB3) and it all sits inside a JBoss 4.0.x server. And I’ve not had to reboot it once since it launched.
I’ve redeployed the entire server application a couple of times, but the JBoss deployer is extremely robust and I doubt anyone even noticed (and no, it’s not because no-one uses it :)
Secondly, I have learned a lot about selling (well giving away) software and support to end-users. As a consultant I’m all too used to finding solutions to, often in-house, business problems and really letting the client deal with the running of things. Now, I’m getting emails and even the occasional call about all sorts from all kinds of users - most (thankfully) are grateful and pleasant, a few are not.
I try and reply to them all with the kind of reply that I would expect.
Thirdly, marketing has become an interest of mine and it’s up there alongside version control systems and design patterns... I’m finding it fascinating, especially how quickly posts on blogs tend to cascade down and directly affect download rates, even on a small project like this.
I suppose the one thing I’ve learned since launching is that there’s still a lot left to learn. I think that being constantly reminded this is worth the bandwidth fees.
Tackling complexity with crayons
(null)/(null)/(null) (null) | Permalink
ur team has just finished implementing a large
workflow system using jBPM as a BPM engine. It
was, for all of us I think, our first brush with
Graph Oriented Programming (GOP) and a couple of
interesting things fell out of it.
Firstly, GOP has the beautifully neat side effect of handling state for you, both in a macro sense (think workflow) and a micro one (think page-flow). This has the knock on effect of removing a lot of complexity from the application - no more figuring out what to do next from the current context (or lack of it).
The approach we took when designing the application was to model each task in the workflow as a separate atomic use-case, each one implemented using an appropriate mechanism (in our case, dispatchers/Session Beans) but with the slight difference that at the end of each use-case we signal to the process that the current task has ended.
By doing this we effectively decoupled the process flow from the task implementation in all but a minority of cases.
But this is cool decoupling. Not just abstracting out application tiers for the sake of it - we could actually change and deploy a new process on the fly without modifying the code.
Shall I say that again? We could actually change and deploy a new process on the fly -
Without.
Modifying.
The.
Code.
Oh. Did I mention that jBPM allows you to deploy multiple versions of the same process?
No?
Well, it isn't quite true but it's close. Once a new process graph is deployed all new instances of the process that are started follow the new graph, existing ones continue down the path of the graph that was in place when they started.
Another thing we noticed is how immediately everyone grasped the concept of modeling process flow. For once we were using a modeling paradigm that 'ordinary users' could join in with (be prepared to allow some deviation from the standard UML notation). A lot of paper was harmed in the making of the system, but given the price of scrap paper I think it was worth it.
Firstly, GOP has the beautifully neat side effect of handling state for you, both in a macro sense (think workflow) and a micro one (think page-flow). This has the knock on effect of removing a lot of complexity from the application - no more figuring out what to do next from the current context (or lack of it).
The approach we took when designing the application was to model each task in the workflow as a separate atomic use-case, each one implemented using an appropriate mechanism (in our case, dispatchers/Session Beans) but with the slight difference that at the end of each use-case we signal to the process that the current task has ended.
By doing this we effectively decoupled the process flow from the task implementation in all but a minority of cases.
But this is cool decoupling. Not just abstracting out application tiers for the sake of it - we could actually change and deploy a new process on the fly without modifying the code.
Shall I say that again? We could actually change and deploy a new process on the fly -
Without.
Modifying.
The.
Code.
Oh. Did I mention that jBPM allows you to deploy multiple versions of the same process?
No?
Well, it isn't quite true but it's close. Once a new process graph is deployed all new instances of the process that are started follow the new graph, existing ones continue down the path of the graph that was in place when they started.
Another thing we noticed is how immediately everyone grasped the concept of modeling process flow. For once we were using a modeling paradigm that 'ordinary users' could join in with (be prepared to allow some deviation from the standard UML notation). A lot of paper was harmed in the making of the system, but given the price of scrap paper I think it was worth it.
Five NoodleBoard Facts
(null)/(null)/(null) (null) | Permalink
I thought it might be fun to publish a few facts
about our OS X Dashboard Widget NoodleBoard.
1. There are just shy of a thousand registered boards being shared by about three times as many users.
2. This equates to about 1GB per week of board data
3. Two percent of requests come to us via Apple Computer Inc. This actually makes them our number one user just ahead of Southwestern Bell and a bunch of US ISPs.
4. The average board size is about 3k when encrypted
5. Our busiest hour of the day is 2200 GMT
I’m currently working with some self-volunteered beta testers on a new version of the widget which should be out in the next week or so.
1. There are just shy of a thousand registered boards being shared by about three times as many users.
2. This equates to about 1GB per week of board data
3. Two percent of requests come to us via Apple Computer Inc. This actually makes them our number one user just ahead of Southwestern Bell and a bunch of US ISPs.
4. The average board size is about 3k when encrypted
5. Our busiest hour of the day is 2200 GMT
I’m currently working with some self-volunteered beta testers on a new version of the widget which should be out in the next week or so.
Damage Limitation Patterns
(null)/(null)/(null) (null) | Permalink
It's a fact that there are certain systems you can
implement to improve the chances of a software
project succeeding, Joel Spolsky lists 12 in his
essay 'The Joel Test: 12 steps to better code'
What I want to talk about here is how occasionally, one or more of your systems is going to break under the strain. In an ideal world this shouldn't happen and possibly wouldn't if you ran your own company (like Joel does), but in the harsh realities of the market people do unusual and sometimes stupid things such as fixing a bug in the wrong branch (or worse on a live server) and without an associated bug report filed anywhere.
Whilst everyone knows that this is a bad idea, sometimes the pressure on developers from other influences can be immense and not everyone's main motivation is to have properly working, well designed software. Managers, for example, often take on new hires simply because they have the budget in place today and might not in the future. For them having a big team is more important than having an effective one. This is not always necessarily a bad thing (although it usually is) but merely an example of where working, well designed software is not the primary consideration.
So, something in your perfect software factory breaks and it's almost always going to happen at a time of great stress, perhaps in the week before a major release, and no one really has the time to fix it at the moment. Around this time you'll likely hear people saying things like, 'What's the point in using CVS it can't cope with such and such a thing.' and 'I've never seen one of these systems work properly in the real world.'
Don't lose faith.
I've seen this happen so many times that I'm coming round to believe that the point of these systems actually is to fail. Thinking of them as barricades holding back the hordes of chaos is probably a good position to adopt. A few barriers might fall and you can put them back to normal after crazy week is over (and the hordes are off planning their next assault - I mean ‘project’), but imagine the state you'd be in if your entire project ran like that from beginning to end.
Striving for a sane build environment is a bit like painting the Forth Bridge, it's always only half way done and the other half looks like crap but without trying the bridge would have fallen down long ago.
What I want to talk about here is how occasionally, one or more of your systems is going to break under the strain. In an ideal world this shouldn't happen and possibly wouldn't if you ran your own company (like Joel does), but in the harsh realities of the market people do unusual and sometimes stupid things such as fixing a bug in the wrong branch (or worse on a live server) and without an associated bug report filed anywhere.
Whilst everyone knows that this is a bad idea, sometimes the pressure on developers from other influences can be immense and not everyone's main motivation is to have properly working, well designed software. Managers, for example, often take on new hires simply because they have the budget in place today and might not in the future. For them having a big team is more important than having an effective one. This is not always necessarily a bad thing (although it usually is) but merely an example of where working, well designed software is not the primary consideration.
So, something in your perfect software factory breaks and it's almost always going to happen at a time of great stress, perhaps in the week before a major release, and no one really has the time to fix it at the moment. Around this time you'll likely hear people saying things like, 'What's the point in using CVS it can't cope with such and such a thing.' and 'I've never seen one of these systems work properly in the real world.'
Don't lose faith.
I've seen this happen so many times that I'm coming round to believe that the point of these systems actually is to fail. Thinking of them as barricades holding back the hordes of chaos is probably a good position to adopt. A few barriers might fall and you can put them back to normal after crazy week is over (and the hordes are off planning their next assault - I mean ‘project’), but imagine the state you'd be in if your entire project ran like that from beginning to end.
Striving for a sane build environment is a bit like painting the Forth Bridge, it's always only half way done and the other half looks like crap but without trying the bridge would have fallen down long ago.
Coast Guard Use RunningTime!
(null)/(null)/(null) (null) | Permalink
I wanted to kick off the new blog with some gripe
about how businesses don’t ‘get it’ or some
controversial opinion on, say, how kids these days
don’t understand pointers properly but, instead, this
is totally cool...
A couple of days ago I received the following email from a member of the Australian Volunteer Coast Guard Association -
“I'm not managing a race car but the application is great for the complex maintenance schedules of a volunteer rescue boat. I am very excited. I was going to write a database to do this stuff but you guys have saved me.
And given that we pay for the boat, rescue equipment and fuel we use to rescue our local boaties the price of your service is fantastic.
Thank you for building a great on-line app.”
It was always in the back of my mind that this application would be useful for a lot more than racing cars but WOW!
Hearing this kind of news is always exciting and having grown up by the coast myself I’m really pleased to get this kind of feedback.
A couple of days ago I received the following email from a member of the Australian Volunteer Coast Guard Association -
“I'm not managing a race car but the application is great for the complex maintenance schedules of a volunteer rescue boat. I am very excited. I was going to write a database to do this stuff but you guys have saved me.
And given that we pay for the boat, rescue equipment and fuel we use to rescue our local boaties the price of your service is fantastic.
Thank you for building a great on-line app.”
It was always in the back of my mind that this application would be useful for a lot more than racing cars but WOW!
Hearing this kind of news is always exciting and having grown up by the coast myself I’m really pleased to get this kind of feedback.