Tag: development

FCKEditor not working in Firefox for you?

Posted by – January 29, 2010

Just came across a cracking little bug in the old FCKEditor 2 code that we use on a number of applications.  In the last few days we’ve noticed that it’s just randomly stopped working in Firefox across all applications that use the editor.

After doing a little digging, this was tracked down to a 2010 related bug, and the fact that the newest versions of Firefox were released this calendar year.  Take a look at my user agent:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2)  Gecko/20100115 Firefox/3.6

In the FCKEditor code, it’s checking to see if I have a compatible browser by checking the date of release of the Firefox, with the following code:

stResult = reFind( "gecko/(200[3-9][0-1][0-9][0-3][0-9])", sAgent, 1, true );

You’ll notice that this regex doesn’t work particulary well for anything that might start with 2010, so you need to update your regex to the following:

stResult = reFind( "gecko/(20[0-9][0-9][0-1][0-9][0-3][0-9])", sAgent, 1, true );

Once you’re done and dusted, this should give you another 10 years of happy FCKEditor usage (if you’re that committed).

UPDATE:  After some more digging it would appear that this is only a ColdFusion related issue, as it is the only library to use a regex to find the date, all of the others use a substring style extraction of the date.

Users don’t want rich

Posted by – September 30, 2009

For many years now, software developers around the world have been releasing quicker and more capable software on an almost constant basis. Each year, we tend so see new releases of existing products that make the products better in every apparent way, shape and form, and we, the computing public, lap it up.

For instance, Microsoft Word is currently at it’s 11th(-ish) version and still going strong as one of, if not the, most successful word processing packages of all time.  Each year or two Microsoft bring out a new and improved version that adds more features and more capabilities to the average person’s arsenal.

Now, for a moment, have a think about the last time you used Word.  Assuming you’re not one of the 10% of people who “power-use” Word, see if you can name five features of Word that you use on a regular basis.

Formatting?  Tables?  Printing?  er….. Word Count?

Let’s for a moment consider Word, with each and every standard toolbar open:

word

There’s a lot there, and there’s a whole load of stuff in there that you’ve never even seen before. Now, think back to the last time you upgraded your installation of Word.  What was the reasoning behind it?  What was the reason that you (may of) reached into your pocket and forked out for the funky new Office installer?

Well, let’s take Word 2008 – the headline features there were the Ribbon UI, and support for Office XML formats… and that’s about it.  Which of those features made you upgrade? Word probably has more functionality than you need… in fact, waaay more functionality than you’ll ever need.  So, why don’t you just use WordPad which comes free and is pre-installed on Windows?  Or TextEdit on the Mac?

Now cast your mind across to the web applications that we, as developers, are creating every day for our clients, be it on a bespoke purely custom basis, or as a product that we roll out to a customer base.  I dare say, that somewhere in your company is a man who works in what some would call ‘Marketing’.  This person wants to sell the product out to as many people as possible, and he also wants all of the current user base to upgrade on a regular basis.  Therefore, you most likely have an army of developers creating new features here and there, and making the existing features more capable in every way you can in order to persuade the customer that WhizzBang Enterprises Widget-o-matic 2009 is the best-est thing since last years version (which is now obviously outdated, insecure, and prone to crashing).

Why do we, as software shops, do this?  Why do we insist on making our software more complex, and more difficult to use for our customers?

bob

Put yourselves in the shoes of your user (let’s call him Bob).  First of all, be aware that Bob is nothing like you.  Bob doesn’t use computers for the fun of it, he uses computers to get something else done, so that he can go home on time and get back to work on his new garden terrace.  Bob doesn’t really get computers, he doesn’t really get the web that much.  Sure he uses Facebook, and emails his chums, and even has his own website (which incidentally is just his twitter stream), but Bob’s interested in other things – Bob just wants to get his shit done and go home.

So, whats the major difference between you and Bob?  Well for starters, for Bob, his computer, and the software on it is a tool – nothing more, nothing less.  He uses his tools to write his documents, send them out to his clients, and ensure that he gets paid at the end of the day.  To Bob his computer is identical to the bag he uses to carry his lunch to work, a tool to achieve a task.

So, thinking about tasks – what do most people want?  Well, it’s simple really.  Simplicity.  People just want to go in, get exactly what they want done with the minimum of fuss, and move on.  Even us developers do it.  We don’t sit down in the morning and think “I’m going to sit down for the next eight hours and write some Ruby…”, we think “I’m going to sit down for the next eight hours, and get this project finished and out the door”.  Our tools are an ends to a means.

So, coming back to our software, why do we make it so complex? Why are we so obsessed with feature richness and whiz bang interactions – the vast majority of people couldn’t care less, they just want to get their work done with the minimum of fuss.

Let’s take a look at richness in applications (the aforementioned whiz-bang element). Recently, there has been a huge movement by Adobe and Microsoft to get developers into using rich platform technologies such as Flash and Silverlight.  Whilst this is all very well, have a quick think about how many applications you use on a day-to-day basis you would consider to be rich (and buzzword bingo favourite “an immersive experience”).  Personally, there’s only one (Balsamiq Mockups if you want to know).  For most, it’s a twitter client.

So, what does this say?  Well for me it’s a sign that while we developers love to see the demo apps that are coming out and what some people are knocking out, but at the end of the day it’s ultimately simplicity and straightforward-ness that we prefer – we just want to get our work done.

In essence, I guess we might be guilty of three things – one, overestimating the users motivation and involvement in using the wonderful creation that you’ve just put out there. Secondly, of overcomplicating what we’re making the users use purely for the marketing aspect, rather than making a genuniely good product, and thirdly, for not really eating our own dog food and actually using this rich applications that we keep telling everyone they need.

Overally, we, as developers, need to keep it focused and keep it simple.  Distractions are aplenty, and we developers are incredilby suspectible to them all which makes us more prone to not keeping it simple…

Talking to the old duffers

Posted by – May 27, 2009

The other day, on my 31st birthday of all days, I can only have what can be described as a “stupid  bint” drive into the back of my Mini Cooper.  Fast forward a few days, and I find myself stood in the foyer of my local Enterprise Rent a Car whilst the Mini’s in getting some repairs done (whilst I endure the Kia Cee’d)

Whilst standing in the queue of other loaners I found myself stood next to a “Community” board, which from what I could see consisted of letters sent in by “happy” customers.  Most of these letters were praising the service they had received and how great the company was.

victor_meldrewNow, a couple of things crossed my mind at this point – firstly, who the hell writes these letters (aside from old people with time to burn), and secondly, why do they write them?

More…

It’s Enterprise-y Sir…

Posted by – May 23, 2009

One of the many discussions we’ve being having recently at Monochrome towers is that of the Enterprise space. Normally the commentary we have is that of:

“WTF does Enterprise mean?”

Generally, we come back to the same thing.  Big business likes to call itself “Enterprise” because it somehow makes what they’re talking about more important.  By saying you’re building an Enterprise application somehow makes it better, even though the requirements may be identical to that of a smaller non-enterprise company.

Now, let’s slide this back a bit and take a look at software.  There’s a whole raft of stuff out there in the software market that calls itself “Enterprise” with no real definition of what this actually means.  Usually, you’ll see the same thing, i.e. a couple of extra features, slightly better performance, and a MUCH higher price tag.  Just like the wedding market:

So, what do you actually get for your money?  Usually it’s not much, as you can’t really buy real enterprise level services off the shelf.

But this then raises the question – what are enterprise level services?

In my mind, these are the things that don’t necessarily some in the shrink-wrapped box.  Let’s, for a moment, take the example of Snap-on tools.  Whilst they aren’t normally referred to as an enterprise service, I believe they are a good example of one.  Snap-on, on a basic level, manufacture tools for the motor trade.  You go to them and buy one of their socket sets, or whatever else may offer.  Now, this is exactly what you can do at any auto-factor anywhere on the planet. However, Snap-on are more expensive.

So what makes Snap-on a good analogy for the enterprise?

Well, for a minute, put yourself in the shoes of the guy using the tools.  One day, your tool will fail. One day it will break, and you’ll need to either use a workaround, or down tools and try and get hold of a new one.  This could mean lost money, a trip down to the auto-factor’s again for something potentially out of stock, or something worse like an unhappy client.

This is where the enterprise support of Snap-on steps in and justifies it’s extra cost.  Your tool fails, and you’re stuck.  So you give your local Snap-on dealer a call (which are all mobile based), and he comes round and gives you a replacement tool free of charge.  You then carry on with your work and go home happy.

Therefore, in my eyes, Enterprise means that you are buying a service, not a price-tag.  You’re buying something that means you won’t lose out at any point, or that someone else will worry about keeping something functioning.  You’re basically paying an insurance policy against having to worry about anything.

This leads me to believe that we’re suffering from the effects of those f**kwits known as marketing departments who sit there spouting their mar-bollocks trying to peddle their crap.  Unfortunately to a marketer, sticking Enterprise on the name means they can charge five times as much as provide much the same thing.

So, next time you’re buying Enterprise, consider the price hike you’re being nailed with and have a serious think about what you’re actually getting for your money.

Agile Requirements – How do you eat yours?

Posted by – March 16, 2009

One of the things that I have been looking at a lot recently is the definition of what we, as a team, are building – a commonly missed task by many teams which can often lead to cowboy coding.

Now, there are many viewpoints on how this can be done, the age old preference being that of creating a 10,000 document that everyone must adhere to and be measured by. The trouble is, the document takes months to write, even longer to get approval on, and then an eon to code. By the end of this process, the document owner has retired, the development team have cycled their staff three times, and your dog has died. But, more importantly, because these days is moving so damn fast in business, your document is now worthless as half of the requirements are now invalid – either because the workflows in place have subtly changed or the market the product is aimed at has.

So, what do we do about this? Do we just ignore the requirement making it up as we go along, or do we do something a little more clever. Most people seem to leave it to making it up as you go along.

  1. Ask engineer how the damn thing works.
  2. Deafing silence.
  3. Crickets.
  4. Tumbleweed.
  5. Just start writing something. Anything.
  6. Give this something to the engineer.
  7. Watch engineer become quite upset at how badly you’ve missed the point of everything.
  8. As the engineer berates you, in between insults he will also throw off nuggets of technical information.
  9. Collect these nuggets, as they are the only reliable technical information you will receive.
  10. Try like hell to weave together this information into something enlightening and technically accurate.
  11. Go to step 6.

Well, at Monochrome, we’ve been doing Agile now for a fair while, and the key mantra there is

Just barely good enough

But what does this mean? Well, in essence, don’t bother doing anything until literally just before you need it, and even then, only do the absolute minimum to makes things work. If you do things to early, you’re opening up the risk of change, and if you do too much, you’re pretty much wasting your time (the minimum amount is just enough after all). This means no massive tombs of out of date guff, and also a lot less time spent writing.

For us, we find that documentation in the form of multiple screen wireframes that are annotated with functional detail tend to suffice, especially when accompanied by some background blurb to describe the things you can’t see. This is especially effective for two reasons – firstly it’s nice and visual, which means clients are more likely to read it, and it also gives you a nice document to directly compare your screens and functionality against – it’s almost testable.

Now, here’s a question back to you guys, all of which will be either reading, writing or somehow interacting with requirements on a daily basis – how do you eat yours? What do you find works, and what do you wish you could have?


The Great Single Skill Myth

Posted by – March 15, 2009

Whilst reading the feedback to my last, apparently controversial, blog post about learning a new language to improve you own skillset I noticed something about the way we, as developers, sell ourselves and describe ourselves to one another. Every developer I know, even myself is guilty of it, and there is almost an entire industry revolving around this same concept.

So, what is this? In essence, this is our need as developers to label ourselves with a particular technological expertise – for instance, you may be a PHP developer, you may be a .NET developer, you may be a Java developer – which is fine, but very few of us will just describe ourselves as just a developer, or even web developer in preference.

As I have said before on this blog, technologies themselves (in the form of languages etc) are tools – they help us achieve an end game which is the delivery of a product to an end user, be it a web application, desktop application, or even the innards of an internet enabled doorstop. We as developers simply use these tools. We do not swear any form of allegiance to them, and we definitely do not use them in exclusion to others so why do we so often feel the need to label ourselves with them.

For instance, here is a list of all the various development tools I use day to day:

  • ColdFusion
  • Ruby on Rails
  • Javascript
  • ActionScript 3
  • SQL
  • CSS
  • HTML
  • jQuery
  • Flex
  • MXML
  • XAML
  • Silverlight

However, if I were to describe what I am trying to achieve with these tools it’s much simpler:

  • Develop and deliver web applications for my customers

So, why would I feel the need, as so many do, to label myself as a CF or Rails developer (or indeed any of the 12 or more items in the list above).

Lets, for example, take a look at a very close relation to us developers, the designer. Now, a designer would never ever describe themselves in terms of the tooling they use, i.e. as a ‘Photoshop designer’ or an ‘illustrator designer’ – but by the end game they are trying to aim at, a ‘web designer’ or ‘packaging designer’ – so why do we do it? Why do we feel this need?

The only area of my activities where I would expect to be describing people in the way we actually do is that of the dark dingy world of recruitment, where I am specifically looking for a particular skill set – I specifically need some Flex skills, or a Javascript guru. However, if I were marketing myself to a recruiter in order to get a new job, surely I would want to keep it as broad as possible to maximise my potential opportunities.

Well, here is where I declare that I do not have the answer, but I am interested in any ideas anyone might have as to why we do it. Why do we have a preference to label ourselves with some sort of technological allegiance rather that simply saying ‘Web Applications developer’?.