All posts filed under

web development

 

Umbraco packages - extending the mail engine from nibble.be

(Warning, technical post)

We've used Tim Geyssen's very good mail package on one of our recent projects

It's the one that was originally posted here.

We had problems with it timing out, and so took a look at the source code to see if it could be toughened up a bit. We made the loop that emails each member run in a background process.
 
We've patched Tim's original code, found here:

http://www.nibble.be/temp/MailEngine.zip
With a patch that you can download here:
http://www.welovetheweb.com/documents/MailEnginePatch.zip

e.g.

cd MailEngine
patch -p1 < ..\MailEngine.patch

It's now running 10,000 mail sends without issues.

Filed under  //   Content Management   email marketing   Umbraco   web development  

Javascript

Now there's a headline to conjure with. Just dropping the word casually into conversation at parties has young ladies flocking from all corners of the room, hanging breathlessly on my every word.

Back in the real world, javascript is the 'other' language that you are allowed to use on the web. HTML handles all the content, javascript does all fancy effects. It makes Google maps slide smoothly around the screen, Facebook posts appear without the whole page reloading, it underpins the auto-completing search on eBay and helps remember who you are when you come back to a page. In short: tremendously useful.

Unfortunately, it's awful. Total rubbish. Complete crap. Honestly, of all the languages you could have chosen to run the internet, this is the worst one, bar none.

Why?
It's as slow and unreliable as a 1975 Morris Marina, as unpredictable as an MP on acid and deliberately hamstrung by design so that it can't do anything harmful (although that hasn't stopped hacker types from finding ways to use it for evil).

This weekend, tired of being relentlessly pestered girls at parties, I decided to stay home and muck about with jQuery instead. jQuery is a code collection, written in javascript, that automates a lot basic tasks for you. We've been using it at We Love The Web for ages now as it does a lot of helpful stuff. It's useful because lots of people have spent lots of time overcoming the bugs in all the different browsers' javascript implementation.

Now: stop a second and think about that last sentence. That's right: the language that runs most of the internet works differently in every browser. So unless you use a Library like jQuery, you'll probably have to write at least four different versions of your code, each tuned to the peculiarities of a different browser. Does my ranting about how rubbish it is start to make more sense now? Imagine if you had to write every sentence on your website in Geordie, Mancunian, Received Pronunciation and Scots, just to make yourself understood. That would get annoying really fast.

So, back to my supersexy weekend. I set out to mock-up a glitchy text-based animation thingy in a few lines of code. I wanted to experiment with using jQuery and see if we could reduce our reliance on flash for motion graphics. Keep it simple, keep it fast, I thought.

The result isn't going to set the design world on fire, nor is it intended to - it's just a scrap of test code. You can see it here: www.welovetheweb.com/black3.html, neatly highlighting many of the problems with javascript in one simple page.

I'm not asking the computer to do anything hard: change the colour and size of some text. It's only about 20 lines of code. That's less than 1Kb. So why should it behave so unpredictably? It:

  • Stops arbitrarily for a second or two in Firefox from time to time.
  • Barely even runs in Internet Explorer 6.
  • Strobes eye-bleedingly fast in Safari on a Mac.
  • Looks rubbish in Internet Explorer 7, but quite cool in Chrome.
  • Runs at completely different speeds in each browser you test it on, even on the same computer.
  • Runs at achingly slowly on anything other than a fast, up-to-date computer.
Bear in mind that I was using a code library specifically designed to iron out the differences between browsers. It's just mental. If you were running Office on javascript, it would take about 10 minutes to load and a simple spell-check would take about half an hour.

How on earth could we possibly rely on something that flaky to try and get stuff done?
Why on earth do we put up with it?

I dunno. I sometimes think us Geeks *like* coding to be difficult, it's how we define ourselves: by being able to do things with computers that mere mortals can't. We'll put up with having to type 100 pages of gibberish without so much as a comma out of place (or it all goes wrong). And we do it willingly, in fact we even enjoy it.

That's the bit I really don't get - why we Geeks are drawn to computers so inexorably. I guess it's the same fascination that people had in days gone by for clockwork or steam engines - an overriding desire, when confronted with a machine, to know how it works and why. An itch to understand that just won't go away. That urge can overcome everything: even our equally natural desire to smash the thing to bits with a big brick when it just won't bloody well work, even after we've poured hours and hours into it!

So yeah, I've got a couple of party invites to look over now or, alternatively, I could read up about the document-object-model differences between Firefox and IE's javascript implementation.

Ooh, the agony of choice.

Filed under  //   code   javascript   parties   web development   young ladies and fun  

Many browsers make heavy work

I'd like to take you on a journey, back into time.

The year is 2004 and Internet Explorer version 6 (IE6) has a 98% market share. Web developers don't even hate it, because it's all there is. The collective geek psyche has been so scarred by the horrible piece of junk that was Netscape 4 that we're just grateful we no longer have to develop for it. The geeks we know all have myriad unprintable nicknames for Netscape. Honestly, it is so bad that we welcome a Microsoft monopoly if only we don't have to develop for Netscape any more.

So, for a while at least, life is uncomplicated. If it works in IE6, the client will sign it off.

Fast forward now to the present (complete with imagery of the sun flitting across the sky at high speed, seasons changing and all that H. G. Wells stuff).

Yesterday, for the first time, I heard the words I'd been dreading for a while: 'But it doesn't work on my iPhone.' A buttock-clenching moment for any programmer I think you'll agree, but it made me ponder recent browser developments. It couldn't possibly work, it was a flash site and Apple won't let flash onto the iPhone (yet).

Over the last few years, we've seen the trickle of new browsers become a flood.

2003: Apples release the Safari browser
2004: Mozilla releases Firefox
2006: Microsoft releases Internet Explorer 7
2007: Mozilla releases Firefox v2
2008: Google releases Chrome, Microsoft releases Internet Explorer 8 beta, Mozilla releases firefox 3 and the iPhone (v2) means some people are actually starting to use the web on their mobiles.

Now, in theory, as long as you confirm to web standards, then your pages should work everywhere.

Oddly though, the developer team here get distinctly tetchy every time I say this. Like all computing 'standards', it just doesn't work like that in real life: especially since IE6 doesn't conform to any known standard.

This is bad news for web developers: each new browser is a new thing to test against. Testing that used to take 10 minutes is now an open-ended task as we fix issues in each browser and check that the fixes in one didn't break things in the others. It can take hours. Multi-browser support is now approaching 10-15% of the cost of developing a small website. That's a lot.

We are having to explain to our clients why the same amount of work now costs more than used to. Here's an example: UK.gov recently talked about dropping support for any browser with less than 2% market share. A lot of technical people were grumpy about this, but we tend to adopt the same approach as the government: if less than 2% of the population use it and your clients can download a supported browser for free, do you really want to pay an extra thousand quid to support all those extra browsers? After all, because we build our sites properly - with a clean separation between style and content - it should degrade gracefully. In the worst case, you can always view it without the graphics: the information on the page will still make sense.

Cross-browser compatibility tweaking is entirely non-productive work, but at least the consumer benefits from all this competition in the browser world. Tabbed browsing and RSS news feeds in your browser are the most tangible benefits: both of which are great. There's also the intangible benefit of not having Microsoft own your gateway to the web.

You could say that web developers should view this as a Good Thing because we can charge more. In fact, it's frustrating because we just want to get on with making stuff work and delivering great websites, not piddling around mindlessly trying to make it look the same in Internet Explorer as it does in Firefox.

I'm not arguing for a return to Microsoft dominance here, that was unquestionably a bad thing. It actively held us back from developing great sites. It's more a plea for standards that actually mean something: if a web page is standards compliant, it really should display correctly in all browsers. At the moment it doesn't and that's just annoying for everyone.

Filed under  //   browsers   standards support   web development  

Chrome

Google's new browser could change everything about how you use your computer. This isn't really a post about their browser, however, more about who controls your business-critical data.

Chrome is the first browser that really tries to turn Javascript into a language that you can use for serious application development. Ah, that's technical and I've lost a lot of you right there: but it's important.

Google docs, Google's Microsoft Office 'killer' runs on Javascript.

We use Google spreadsheets here at We love the web, mostly for bug-sheets and progress tracking. We love the fact that we no longer have to email people lots of spreadsheets or get them to use an unfamiliar bug-tracking tool: they can update an online spreadsheet that they already know how to use and we get their updates instantly. These work well until they get to a certain size. They then start crashing our web browsers with annoying regularity. So, if Google docs were more reliable they would be a compelling proposition:

Google docs: Free, requires no maintenance, setup in minutes, instant online collaboration
Microsoft Office: several hundred pounds, complex install that requires regular patching and support, rubbish online collaboration

There are only two ways to do instant online collaboration through a browser: the flash plugin and Javascript. The flash plugin is wholly owned by Adobe and Google wouldn't want to be in hock to Adobe for a key plank in their strategy. That leaves Javascript.

Javascript is pretty awful: slow, unreliable, inconsistently implemented across Internet Explorer and Firefox, prone to falling over and not very secure. I've yet to meet a web developer who loves Javascript. You can do some great things with it, but mostly in spite of the language, not because of it.

This is the problem that Google seems to be trying to address with Chrome. It's the only real innovation in the browser for my money: a bullet-proof implementation of Javascript.

Everything else is pretty standard - Chrome is based on webkit, the same collection of code that Apple used to make Safari and a lot of the interface tweaks owe their inspiration to (have been copied from) an obscure, but well-regarded browser called Opera.

So, if Google docs would only work reliably then Microsoft really could become irrelevant: No longer would you fire up Word, Outlook and Excel when you got into the office: gMail and Google docs. would take over. Chrome is the tool that allows this to happen.

Hooray, you've saved hundreds of pounds per person in not buying Office!

Of course, there is a downside.

All your important business information would be held and maintained by someone else. Microsoft Office just provides the applications in which you work: you store your own data. Google Docs are stored, indexed and ultimately owned by Google.

Within days of Chrome's release, there was a right hoo-haa in the technical press when it was discovered that Google had put a term into the license whereby you granted a permanent and irrevocable license to Google to use, reproduce and distribute anything you uploaded through Chrome: photos, spreadsheet data; everything.

It was quickly removed, with an 'oops' style apology from Google, but that it was even there in the first place is worrying: that they ever thought this was reasonable. I don't trust anyone outside my accounts team with my financial information. Do you?

It's the same old story really: there's always a catch to 'free'. We use Google docs, and will continue to do so for lightweight online collaboration, but never for really important stuff. Think hard before you start entrusting business critical data to a third party. You never know where it could end up.


Note: There are various free office suites that work like Microsoft Office - the most famous is called Open Office, but there seems to be real resistance to it in business, possibly because many business people are nervous about an entirely free application suite that underpins the daily running of their business and isn't supported by a large company.

Filed under  //   Chrome   javascript   web development