blufive: (Default)
In the middle of an interesting post about online identity, [ 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)

Via slashdot, I learn of the passing of John Backus (NYT obituary) co-creator of the Backus-Naur Form, and the guy who led the team that developed the Fortran programming language. Predictably, practically the first comment on the slashdot thread is knocking Fortran.

Back when I was studying engineering at University in the early nineties, I had to learn Fortran - my final year project involved writing a moderately substantial program using it. Well, the biggest program I'd ever written at the time. I learned a lot about the day-to-day stuff of programming from that project; it was probably the formative experience that convinced me that I'd quite like to do such things for a living. As a result, at times like this, I feel a need to leap to the defence of the language.

FORTRAN (from "FORmula TRANslation") may have flaws, but comparing it to C is like comparing the Wright Flyer to a Sopwith Camel. Yes, the Camel is the better plane, but I don't hear many people complaining about the Wright Flyer's poor rate of climb - as the name implies, it was pretty radical that it flew. Fortran, developed in the mid-to-late 1950s, was the first high-level programming language to see widespread use. Before it came along, programming was done in assembly language, if you were lucky.

In this context, "high-level" means two main things: "approximately readable by normal people" and "you don't have to worry about the precise design of the CPU you're running on". Assembler language is neither - it's pretty much a one-to-one mapping of the raw machine code into easier-to-remember mnemnoics like "LDA", "JSR" or "BNE" (I said easier, not easy), you need to keep tabs on exactly what data is currently in which bit of the CPU and tell the cpu when to ship stuff out into the main memory.

High-level languages like Fortran separate the programmer from most of that stuff by providing a more human-friendly language (usually built around a combination of real words and algebraic-style expressions) for the programmers to work with, and a "compiler" that translates the human-code into the machine-code. The designers of Fortran made a few mistakes, which have been fixed in many newer languages, but they didn't exactly have the opportunity to learn from the mistakes of others, because no one else had done it before. Criticising Fortran for its lack of (for example) Polymorphism is like complaining that the Wright Flyer didn't have seat-back DVD players (the early models didn't even have SEATS).

For all its faults, Fortran (albeit in an evolved form) is still in widespread use today. As its expanded name implies, Fortran is not a general-purpose language - it was invented specifically for the purpose of mathematical computation. They added native support for Complex Numbers well before support for characters (i.e. text) and there are some extremely high-powered mathematics code libraries available. If you want to do some seriously heavy-duty computational fluid dynamics, Fortran's still a contender. Which is why they taught it to me, 'cause that's the sort of thing aero engineers do.

Not bad for a programming language that's over half a century old (a milestone that the grand old man of programming languages, C, won't reach for another 15 years or so).

So, RIP John Backus. Thanks for inventing the most important tool of my profession.

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


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(
  at org.apache.jasper.compiler.JspReader.skipUntil(
  at org.apache.jasper.compiler.ParserController.getPageEncodingForJspSyntax(
  at org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(
  at org.apache.jasper.compiler.ParserController.doParse(
  at org.apache.jasper.compiler.ParserController.parse(
  at org.apache.jasper.compiler.Compiler.generateJava(
  at org.apache.jasper.compiler.Compiler.compile(
  at org.apache.jasper.JspC.processFile(

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:

  a bad file

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'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)

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... )


blufive: (Default)

April 2017

234 5678


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2017-09-24 12:05
Powered by Dreamwidth Studios