blufive: (Default)
At Eastercon, one of the few items I managed to get to, between wrangling offspring, was the "Ethics of AI" panel.

It was an interesting item, if a little "bitty" – I get the impression that there are so many unresolved issues that a single hour’s discussion couldn’t devote any significant period to any of them, so it mostly just bounced from one issue to the next. However, I was struck by how many of the issues are applicable, right now, to "dumb" software, never mind anything approaching an AI.

One of the topics (briefly) discussed was the issue of legal liability for the actions of a piece of software. I mentioned the very common software licence clause denying all liability for anything a program does. [livejournal.com profile] majorclanger quickly pointed out that such clauses are unlikely to survive any significant contact with the UK legal system (I don't recall the details he gave of the act in question – something about unenforceable/unreasonable contracts?). There are presumably similar laws in other jurisdictions.

In some ways (i.e. as a user of software) I think thatIs a good thing. If a company releases software that does damage somewhere, then there should be consequences.

On the other hand, as a professional programmer, I'm a little more uneasy. IIRC, one of Alan Turing's great contributions to computer science was a proof that it's impossible to prove exactly what an arbitrary lump of software is going to actually do before you run it. For trivial programs, you can make deductions via human inspection, but that fails utterly for even relatively small lumps of code.

For any real-world-useful software, it's basically impossible to prove that it is bug free. With care, you can probably assert that it probably has no major bugs. For huge software projects (say, an operating system[1]) even getting that far can require carefully-co-ordinated person-centuries or person-millennia of effort, backed up by even larger quantities of automated computational grunt work.

(Things get murkier still if the software in question has eleventy-billion little config switches that the user can fiddle with, some of which are labelled "if you get this wrong, very bad things will happen")

Surely there has to be some sort of cut-off, where a software company can say "look, we did everything reasonably possible to ensure that the software was good, we can’t be held liable for a one-in-a-trillion bug that only kicks in when you make a typo at 12:42pm on a Tuesday in March when the wind is blowing from the south-east"? There are industry standards and quality standards and acceptance testing and so on. Presumably some of those things are actually recognised in law as a defence for the software producer?

So, how many liability issues have actually made it to court? Certainly in my professional experience, screw-ups with major real-world consequences have mostly been resolved via negotiated financial settlements. Has anyone ever tried to seriously lean on a "no liability" licence clause, and if so, what happened?

[1] Scientific American once printed an article (probably about a decade or so back) which argued, totally seriously and very persuasively (yeah, I'm biased) that Windows 2000 was one of the most complex artifacts ever built. Yes, they included things like Airliners and Moon Rockets. Big software is complicated.
blufive: (Default)
In the middle of an interesting post about online identity, [livejournal.com profile] eggwhite wrote something I want to highlight for everyone working in any sort of software development environment:

I'd been banging on and on about how identity was important, meaning one thing. The folks I'd been working with had heard me banging on about identity being important, but hearing something entirely different. Identity meant different things to different people on the team, and that was muddying the waters.

Spotting this sort of thing happening in real time, especially during spec-thrashing-out type meetings, is an incredibly valuable skill.

Practice, learn, and draw attention to it when it happens, because this stuff leads to bugs. Not just common-or-garden "oops, sorry, fixed in a couple of hours" bugs, but "oh $%^$, we'll have to re-plumb half the world and de-cromulate the dinglebat to even begin sorting that mess out, it's gonna take months, we're doooomed!" bugs.

(consider this a rather late speak-out geek-out thing)
blufive: (Default)
If you work in the business of generating web pages to display to users, you need to know: there's going to be some major changes in the browser landscape over the next year or three.

There are several things going on out there. Any one of them could make a serious difference to the web at large - but they're all either happening right now, or imminent.

Mobile devices are going be everywhere.

I'm seeing reports[1] that at least one major chipmaker is planning to ship a system-on-a-chip imminently which they reckon will allow roughly-iPhone-3GS-equivalent handsets to sell at retail, without contract, for ~$100. Those things are going to be hitting the high street in less than 6 months.

I'm not sure I believe that precise graph of price vs. time (or even that I read it right) but I don't think they're wrong by more than a factor of two on either axis. Smartphones (more accurately, pocket frackin' computers[2]) are going to go mass market, and soon.

In 2010, smartphones sold roughly 300,000,000 units. That's about the same as the number of desktop PCs sold in the same period, apparently. This year, they're going to sell more. When those $100 beasties hit, it's going to seem like everyone's got one.

Mobile devices are not second class web citizens any more

These things have proper browsers on them. Most are webkit-based (like Chrome and Safari) so they do proper standards-based rendering, including lumps of the new CSS3 whiz-bangs. They have proper javascript engines with better performance than you may expect.

I did some ad-hoc performance testing recently. Mobile safari on iOS 4-point-(mumble) on an iPhone 3GS was about a factor 10 slower than Chrome 8 on my workstation. So: only 10 times slower than one of the fastest browsers out there running on much beefier hardware. That's comfortably in the same league as (probably even somewhat faster than) IE8 on the same workstation. It leaves IE7 in the dust.

Add those two items together (low prices + web capability) and you get: mobile devices are going to become a very popular way to access the web. This is going to happen fast - if we're lucky, we've got a year or two to prepare for it. Right now, I'm seeing mobile safari at about 1.5% to 3% of sessions on the websites I work on. That's up from basically zero 12 months ago.

All those browser support conversation, where you say things like "we'll support all the browsers over 5% market share in our stats"? They're going to get gate-crashed by mobile devices in less than 12 months' time, quite possibly less than 6. Maybe not any one browser on its own, but in aggregate, it all adds up fast.

The only thing I can see slowing this down is the mobile phone operators, and their we're-not-price-gouging-our-customers-honest-guv data payment plans. Even on that front, for $100 or so, I'd be seriously considering buying one of these beasties for use via wi-fi hotspots only (hell, that covers my house and garden, for starters - anything else is a bonus) and screw the phone people.

It's the browser wars all over again

All these new devices come with their own browsers and, unfortunately, there are loads of the buggers [3]. They're all subtly different. They're all running on different hardware, with different screen sizes. You're really, really, really, going to have to test on the real damn hardware.

The good news is that they mostly follow the standards. If you can:
  • persuade the photoshop weenies to give up on pixel-perfection ('cos the screen dimensions are all over the show)
  • do at least a bit of work to tailor the design to the realities of small screens (by dumping cosmetic fripperies and focusing on making the site suitable for whatever it's supposed to actually do)
  • refactor all the UI stuff to cope with touch instead of/as well as mouse interactions (which is quite a big deal, especially if the site's supposed to do any quantity of data entry)
  • avoid the real bleeding-edge stuff like webGL
...then you shouldn't have too much trouble keeping the browsers mostly in line.

Javascript performance has just gone up like a rocket.

IE is still the biggest desktop browser, and it sucks, especially the older versions. On the desktop, almost everyone still has to support IE6/7[4]

All the other desktop browsers are an order of magnitude faster than IE8, which is itself significantly quicker than IE7 and 6. IE9 is going to be seriously competitive with everyone else. Don't get me wrong, performance is still an issue, but the browsers are now probably less of a bottleneck than your code is.

Now, that's not bleeding-edge, but it's sure as hell quick enough to run non-trivial things at a sensible speed. Remember: there was a perfectly-playable port of Lemmings to JS done years ago, before all this optimisation occurred. Some of the stuff that people are doing out there in browser-specific-tech-demo land is amazing (like, real-time-chromakey[5], real-time hardware-accelerated 3D graphics[6])

So: You can now write real app-scale code in websites browsers. This has started to get through to people, though I still see a lot of comments like "javascript is a toy, you can't do anything serious with it" from people who really should know better, if only because it's been smacking them in the face for a year or two now.

Conclusions

Mobile devices are going to become at least a significant way of accessing the web within months. In the long run, a good chance of becoming the dominant way. That's long run in internet time - I'll go out on a limb and say: 5 years, maybe. Mobile devices are probably going to be what finally rams the stake through the hearts of IE6, 7 and maybe 8 (with Firefox and Chrome cheering from the sidelines).

The possibilities for mobile devices to run really cool things via pure web tech are much greater than most people realise - and web tech runs on all of them without having to port to a zillion different native development environments, or get sign-off from Apple before you can ship anything. [7]

The references I can be arsed finding, with added footnotes


[1] http://tech.fortune.cnn.com/2010/12/22/2011-will-be-the-year-android-explodes/

[2] Not that long ago, the state-of-the-art in phone games was "snake". An iPhone 3GS (which is now moderately old hat, tech wise) has far more computational shove than the system I used to play Half-Life all the way through. Yeah, these things happen to be phones, but, first and foremost, they're full-on pocket computers. People just haven't really cottoned on to that bit yet, because the future just went and snuck up on us.

[3] http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html [8]

[4] On sites I interact with professionally, I'm still seeing IE6 at about 5-8% and IE7 at 12-20%. I can't quite pull the trigger yet, but IE6's days are numbered.

[5] https://developer.mozilla.org/samples/video/chroma-key/index.xhtml works in firefox 3.5 and up, allegedly. No idea about other browsers.

[6] http://webglsamples.googlecode.com/hg/aquarium/aquarium.html. You'll need a Firefox 4 beta or another WebGL-enabled browser (I believe the pre-release chrome builds can do it too, though I've not confirmed it personally)

[7] I hear the cry: "How do people make money from web apps?". That requires rather more prognosticating than I'm willing to commit to right now. One possibility is Operator Billing - it's going great guns in Africa. But that requires the mobile phone networks to be more forward-sighted than "give us $LOADSAMONEY-per-byte, and Get Orf Our Land Network" and "new handset is 10% better than old one, upgrade now!", so colour me somewhat skeptical for the moment.

[8] On the subject of mobile browser landscape and mobile web, just read everything PPK writes. Even if/when he's wrong (not often, on past track record) he's wrong in interesting and educational ways.
blufive: (Default)

Dear Compuware,

Speaking as someone who writes web applications professionally, the web interface to TrackRecord is a huge, steaming pile of shite.

Let me enumerate the ways:

  • Accidentally clicking the incorrect option in a dropdown list results in a bug being snatched out of my hands allocated somewhere I can't edit it.
  • ditto if I carelessly used the mousewheel while focus is in the wrong place. This is why using "onchange" handlers to submit forms is BAAAAD, m'kay?
  • Once I've started an edit, I can't escape. <valleygirl>Guys, like, Transactional database access? Duh!</valleygirl>
  • Something resembling a useful search interface that doesn't require configuration of specific queries by a sysadmin would be cool, too.
  • It corrupts its own database on a daily basis (ok, that's not necessarily the web interface, but I thought I'd slip it in anyway)

Yours, etc.

Dear Employer,

Give me a real bug-tracking system to work with. If you're too terrified of (for example) bugzilla, I'll even take the old in-house character-cell-based relic instead. It may use arcane keystrokes, but it only corrupts the database once or twice a week, and the search facilities let me slice'n'dice by client, or who's dealing with it, or when it was logged, or status, and I can scroll through lists of bugs a good deal quicker than the average glacier. Oh, and once a bug is closed, it disappears unless I specifically go looking for it, rather than just cluttering the place up.

Yours, etc.

blufive: (Default)

(With apologies to readers who don't give a flying #'%^ about J2EE programming. That'll be most of you, probably)

A general principle: If (when) I run into an IT problem, Google can't help me find a fix, and I subsequently find a fix on my own: write it up and publish it somewhere search engines will find it, to help the next poor schmuck

Problem:

Jasper (tomcat's JSP compiler) goes boom with the exceptionally-cryptic (compared to its normal error messages) stack trace:

java.lang.ArrayIndexOutOfBoundsException: 8064
  at org.apache.jasper.compiler.JspReader.peekChar(JspReader.java:154)
  at org.apache.jasper.compiler.JspReader.skipUntil(JspReader.java:279)
  at org.apache.jasper.compiler.ParserController.getPageEncodingForJspSyntax(ParserController.java:415)
  at org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:386)
  at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:170)
  at org.apache.jasper.compiler.ParserController.parse(ParserController.java:101)
  at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203)
  at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439)
  at org.apache.jasper.JspC.processFile(JspC.java:727)

What to do about it:

Jasper is barfing on a bad tag.

This is a known (and fixed) bug in Jasper (see bug 29866 for the gory details)

The problem is a bad JSP file, with an un-terminated xml/html/jsp tag at the end of the file. For example:

<p>
  a bad file
</p

Note the missing ">" at the end. To cause the problem, the broken tag has to be right at the end, without even a newline after it.

Google and Apache.org's bugzilla got me that far. However, in practice, you probably have a zillion JSP files in place, and don't want to trawl the lot looking for a single typo. Worry not, there's a clue in the error message:

java.lang.ArrayIndexOutOfBoundsException: 8064

That number at the end is the exact size of the bad file, in bytes. Some cunning command-line use of dir or ls should help you find the culprit...

blufive: (Default)

I know I read this paragraph about 9 months ago, but I was reminded of it recently, and find it even more appropriate now:

Imagine a world where speaking or writing words can literally and directly make things happen, where getting one of those words wrong can wreak unbelievable havoc, but where with the right spell you can summon immensely powerful agencies to work your will. Imagine further that this world is administered: there is an extensive division of labour, among the magicians themselves and between the magicians and those who coordinate their activity. It’s bureaucratic, and also (therefore) chaotic, and it is full of people at desks muttering curses and writing invocations, all beavering away at a small part of the big picture. The coordinators, because they don’t understand what’s going on, are easy prey for smooth talking preachers of bizarre cults that demand arbitrary sacrifices and vanish with large amounts of money. Welcome to the IT department.

Ken Macleod, from his introduction to Charles Stross' "The Atrocity Archives"

blufive: (Default)

As many of you probably know by now, my day job is programming computers. A year or so back, a non-technical friend, having got that question out of the way, followed up with "so what does that mean, then? What do programmers actually do all day?" This occurred at about 1am, and I wasn't exactly sober, so I did what any other programmer would. I babbled incoherently.

The question remained with me, though, and it's become clear that the answer is far from obvious to many people. So here's a slightly more detailed answer for interested non-techies.

Read more... )

werk

2005-01-12 21:29
blufive: (Default)

On Saturday, the Financial Services Authority takes over regulation of the UK general insurance market.

I work as a computer programmer for a company that sells software to insurance intermediaries.

Let's just say things are a little busy right now, and customers that are still changing their requirements are likely to be disappointed if they want them live by the end of the week.

Profile

blufive: (Default)
blufive

April 2017

S M T W T F S
      1
234 5678
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2017-09-24 11:58
Powered by Dreamwidth Studios