Comic Relief’s offices weren’t quite what you’d expect—a smart floor in a posh block, right by a certain security service’s s3krit headquarters—but definitely very Comic Relief, as you can see from the distinctly nose-coloured cast in the photos of the event. Rob managed to keep breaking the ice all evening, with such ruses as encouraging a group photo of everyone with angry faces.

The two main talks were as informative as ever, although there was definitely a different feel to them. Whereas previous “big-hitter” NGO projects showed Drupal in an “enterprise” environment (make of the words in quotes what you will), the slightly more close-ended projects, presented by the majority of the development team involved in them, warmed the group as a whole up more: there was more discussion in the round and sharing of—or at least hinting at—solutions to common problems. Oliver MacColl, Brett and Ben Dodd presented the inmyname.com / White Band Action, and Francesco Moretto discussed the implementation of CiviCRM and Drupal that lay behind the recent online relaunch of UNIMI’s alumnus society, ALGIUSMI.

You can’t get the likes of Amnesty International or Greenpeace to talk at every meeting, so it was nice to see the event’s structure capable of embracing projects that were no less impressive by not having a big name behind them. It bodes well for the future, too, as smaller-scale Drupalers should feel emboldened to come forwards and share their experiences with everyone else.

If you weren’t there, there’s now an IRC channel devoted to the UK Drupal scene, where a fair few of the D4NGOs crowd hang out: do pop in and say hi.

I provide below some reasonably solid HTTP fetching and cacheing in ASP/VBScript. I hesitate to add “because almost everything I found on the web was rubbish” because that would show hubris in the face of me having just had to sanitize the code, quite likely introducing typos along the way. These code samples also come with no warranty and no likelihood of me answering awkward questions about them. To invoke the fetcher/cacher, put the following in your currently executed VBScript file:

<% Dim strUrl, strUrlKey, objWinHttp
strUrlKey = “top_menus” %>
<!– #include file=”fetch.inc” –>
. . .
<% strUrlKey = “side_menus” %>
<!– #include file=”fetch.inc” –>
. . .
<% strUrlKey = “footer” %>
<!– #include file=”fetch.inc” –>

Some notes on this below, but here is the actual fetcher/cacher to put in fetch.inc and bring it in with the above:

<%
‘ @description remote calls to get livery
‘
‘ @param strUrl might need to be Dim-defined in wrapping file
‘ @param strUrlKey must be Dim-defined and set to a particular
‘   livery identifier in wrapping file - also appends it to the URL
‘   query string that it gets
‘ @returns HTML on standard output

strUrl = “http://example.com/?livery=” & strUrlKey

‘ Cache timeout is 60 minutes
‘ Application(foo) fails gracefully if key foo does not exist
If DateDiff(”n”, Application(strUrl & “.LastModified”), Now()) >= 60 Then
  ’ If cache expired, get the page
  Set objWinHttp = CreateObject(”Msxml2.ServerXMLHTTP”)
  ’ Turn error handling on
  On Error Resume Next

  ’ Timeouts will now be handled
  objWinHttp.open “GET”, strUrl, False
  objWinHttp.send

  ’ If no error, trust content
  If Err.number = 0 Then
    ’ Lock the application scope and insert page and cache date
    Application.Lock()
    Application(strUrlKey) = objWinHttp.responseText
    Application(strUrlKey & “.LastModified”) = Now()
    Application.UnLock()
  End If

  ’ Turn error handling off
  On Error Goto 0

End If

‘ Regardless, read from the application
Response.Write(Application(strUrlKey))

‘ Tear down object
Set objWinHttp = Nothing
%>

The Dim statements before the <!--include--> make it all a real pain in the arse. Some server configurations will arbitrarily interpret and run ASP files without Dims; some won’t. And you can only ever Dim a variable once in a particular variable scope, or everything dies horribly; you have to keep track of whether or not a variable has already been declared, pretty much by eye.

Depending on your server, you might also not have access to the particular DLL that provides Msxml2.ServerXMLHTTP. If that’s the case, then there are other possible ways of making the HTTP call out there on the web: it’s just that the Graceful Exits bouncer isn’t letting them through the door.

Now, if you’ll excuse me, I need a shower.

You can read a breakdown of the worst bits on The Web Standards Project, but here’s the feedback I just emailed webguidelines@coi.gsi.gov.uk:

Hi,

I appreciate the COI’s desire to provide roadmaps for cross-browser support, but I’m otherwise dismayed at the recent publication’s back-to-front emphasis regarding browser standards support. It feels like the publication has been put together by people who are remote from the current thinking on web standards and how best to both promote them and take advantage of them.

As a web developer I’ve had a reasonable amount of experience in developing sites cross-browser, and generally the quickest and cheapest site creation (and the least patronising or inconveniencing to the eventual end users) is effected by developing first on the most standards-compliant browser available, regardless of its user base. Then, once the site is stable and well-built according to the standards (which are there for reasons other than semantic fussiness), one can use *freely* *available* frameworks to compensate for browsers which do not follow the standards (which may be more popular). It involves more effort at the start in exchange for a much smoother site construction later on.

Let me repeat that: building sites according to web standards, then accommodating bad browser behaviour, is CHEAPER, QUICKER and MORE ROBUST than what you implicitly propose i.e. building with bad-but-popular browsers in mind, and then looking at shoe-horning in browser-specific fixes for the others.

If you inconvenience the users of good browsers because there aren’t many of them, you are taking us back to the bad old days of 1990s browsing. I haven’t seen the phrase “We advise you to upgrade your browser version” (which I take verbatim from p4 of your report) on any site I respect and trust for almost ten years. Ask any decent web developer: it’s no longer necessary, and frankly it reveals far more about the mindset of the site designers than about the state of web technology.

Like the proposal’s guidelines, its consultation is happening the wrong way round, and highlights a top-down mentality behind composing such documents. Sharp, savvy developers recruited from any of the vibrant UK web conferences—dConstruct, OpenTech, Barcamps—would have been glad to have helped the COI out before this fundamental missing of the point was published, were they to have been asked. It would certainly have saved both COI and the web community at large a lot of heat, friction and wasted effort.

Yours faithfully,

J-P Stacey

PS: I was originally going to send this via your website’s feedback form. After having read your proposals for building good sites I decided to email it instead, just in case.

You’ve got a month to comment yourself, if you’re a UK or European developer. Feel free to use the above template, only I’d recommend changing the name at the bottom.

“IDEs are draining users away, but it’s not the classic fat-client IDEs that are ultimately going to kill Emacs. It’s the browsers. They have all the power of a fat-client platform and all the flexibility of a dynamic system. I said earlier that Firefox wants to be Emacs. It should be obvious that Emacs also wants to be Firefox…

“… [N]ow the browsers are starting to sprout desktop-quality apps and productivity tools. It won’t be long, I think, before the best Java development environment on the planet is written in JavaScript.”

I’m more of a vi user these days—it behaves much more consistently over emergency ssh sessions—but as a general advocate of Emacs over IDEs I can see his point. Browsers should want to be like Emacs, or at any rate more like the VM of your choice.

Between browser-as-VM, Firefox, ECMAScript and compatibility frameworks there’s the seeds of an RIA revolution. After all, to what extent will industries gladly rest their financial weight on RIAs, so long as they’re all written in Flash-on-the-browser, and so long as browsers remain so unpredictable and Flash remains… well, Flash?

sp_rename
  [ @objname = ] ‘object_name’ ,
  [ @newname = ] ‘new_name’
  [ , [ @objtype = ] ‘object_type’ ]

So say you have a table called t_est, with a column in it called est_client. You want to rename these to t_job and job_client respectively. Firstly, with some trepidation, you rename the table:

sp_rename ‘t_est’, ‘t_job’

You find, miracle of miracles, that it works! SQL Server warns you about stored procedures breaking, but looking at other dependent tables you find that foreign key constraints have all been updated so you still have referential integrity.

At this point, you might try renaming a column called, say, est_client to job_client as follows:

sp_rename ‘est_client’, ‘job_client’

That’s wrong, of course, as you soon find out: the object_name needs to be qualified to distinguish it from . So you might try:

sp_rename ‘t_job.est_client’, ‘t_job.job_client’

Well, that was successful, but: oh! You now have a column called t_job.job_client, in the t_job table. It looks like new_name shouldn’t have been qualified after all: you should have assumed inconsistency where consistency was implied by the spec. Well, dealing with Microsoft’s tech documentation is certainly a learning experience at the best of times, so chalk this one up to experience. But if you now try to learn from your mistakes and revert the column name, you find you can’t, because:

sp_rename ‘t_job.t_job.job_client’, ‘job_client’

tries to rename the column job_client, owned by user t_job, in table t_job… to job_client. After much headscratching, you finally realise that you can employ double quotes to qualify the column name and make SQL Server treat the dot as a literal dot and not a separator:

sp_rename ‘t_job.”t_job.job_client”‘, ‘job_client’

You sit back, grudgingly satisfied. More time passes. Spring arrives. The owls are not what they seem.

REST plays the same role as open source and open APIs: It eliminates tooling and vendoring as artificial barriers to adoption.

Interestingly, a corollary to this was brought up at Barcamp Brighton this weekend. During Gareth Rushgrove’s talk about REST and Nabaztag, a chap whose name I’ve again forgotten (although I’m sure someone like Fatty will enlighten me) pointed out that much of the push of SOAP is coming from the vendors, because the vendors make their money from selling tools, and REST development needs very few tools, most of which are free.

Undoubtedly there’s a set of problems that REST finds hard, but this truism is extended by SOAP vendors to the hard-to-prove (but also hard-to-contradict) claim that it’s a larger set, or a set more pertinent to enterprise solutions, than the set which SOAP finds hard. It convinces the consumers, because intelligent data mining and storage has always been a difficult problem, and a simple solution like REST feels like underkill for the job in hand. They let you confuse libre and gratis, the vendors point out (I see them sitting on the consumer’s shoulders with tridents at this point): so where’s the hidden cost of this free lunch?

(hat tip to Simon Willison)

Our development is explained on those list postings: I’ll put a diagram and more coherent explanation up here when I get a chance.