Archive for the ‘Software’ Category

Miscellany 19

Sunday, September 25th, 2011

I’ve been accumulating a lot of links. Time to clear the tabs out.

A good overview of corruption in Obama’s DOJ here.

Interesting discussion of poverty here.

This must have something to do with truth in advertising: a supermarket chain has been forced to withdraw ads that show happy customers.

Useful knowledge: How to avoid going to jail for violating 18 USC 1001.

Not, perhaps, the best dietary choices.

It’s been a long time – I haven’t read much about spontaneous human combustion since I was in high school.

I’ve seen photos of people with elaborate facial tattoos before, but never in this context.

This is interesting – a section of Idaho where major crimes can’t be prosecuted.

Time for Science and Technology:

Carbon nanotube cables that conduct electricity as efficiently as copper? Bring it on!

This is a bit old, but … we can now measure the magnetic properties of a single proton.

This is also a bit old … a new type of car engine. These come around every so often. I was quite taken with the Wankel rotary engine, but it had problems with manufacturability. Maybe this one will work out better.

Visual cryptography. Interesting, but I’m not sure how easy it would be to extract the information into text form.

A visual reference to computer ports.

Fairly computer-centric, but, then, I am employed in the field of software, and I love the title – Here be dragons: advances in problems you didn’t even know you had.

New and improved wireless technology.

Fossilized feathers found in 80-million-year-old amber.

Here’s a scale model of the solar system. Be prepared to do a lot of scrolling.

On the subject of the solar system, here’s an orrery that I think is pretty damned impressive.

Continuing with science, the Ig Nobel awards are about to be announced.

Scientists are also planning to make an artificial volcano.

Here’s something unusual: placebos are becoming more effective. How’s that work?

Been hearing voices with nobody around? You may not be as insane as you feared – birds are teaching each other to talk.

A Z-machine interpreter and a list of games for it.

Technology keeps on improving our lives – here’s a self-inflating bicycle tire.

The Document Which Used To Be Called The MIT Lockpicking Guide. I downloaded a copy when it was called that. Related: a series of lessons on YouTube.

Some products aren’t well-designed. Here’s one example from a trade-magazine blog on the topic.

Time for a little humor.

Here’s something that’s a staple of Jay Leno’s “headlines” segments: marriage announcements.

Got OCD and like to cook?

Lord of the Strings?

I like some of these modified signs.

Not quite humor, but close … Which Programming Languages Make You Cuss More? More accurately stated: which programming languages have more cussing in comments in the code I looked at?

Miscellany 17

Sunday, August 21st, 2011

There’s not quite an hour left in the 52nd anniversary of Hawaii becoming a state (in this timezone, anyway). Time to clear out the browser tabs.

Andy Firth believes that people who code for a living aren’t learning enough about the abstractions they use and what those abstractions are hiding. I happen to agree with that. My list of things that coders should study/know would be somewhat different than his, but that is likely to be just because of our differing backgrounds.

The economy is going to hell in a handbasket. My company isn’t exempt from problems; our customers have taken to using us as a bank that provides no-interest loans – customers on net 30 terms have been taking 90 days or more to pay. Here’s a good roundup of poll results with respect to the economy and the government’s handling of it.

Perhaps this chart explains some of the problem. Pay particular attention to the last two lines.

Accounting rules have, of course, contributed to where we are today with respect to manufacturing.

Oh, for the days when farming was fun!

While we’re on the subject of dynamite, I’d like to suggest this as a problem that can be solved with a suitable application of high explosives.

I don’t agree with Fred all the time, but he’s almost always worth reading. He’s got a sobering take on the London riots.

The closest I can come to matching this customer service story is to note that I used to be a regular-enough customer at a local Mexican restaurant that the staff knew my usual order. Nowhere near the same thing. I’ll have to get to a Morton’s sometime when I feel as though I can afford it; such service deserves reward.

I need to find out more about this. There may be nothing there, but, if there is …

Free online classes in AI. Might be fun. Here’s more information about other online education sources.

I saw an interesting documentary on burlesque a couple of weeks ago. This song was in part of it, but never sung in its entirety. I looked it up because it sounded fun. Note: the page automatically plays a MIDI file of it.

The rich fantasy life of Google Chrome

Wednesday, June 8th, 2011

Then again, it’s more science-fictional than fantasy. I found this photo of the fake “Blue Screen of Death” Easter Egg in Chrome over at Doug Ross’s place. One of the first things I noticed was that the filenames are faked, and many of the ones that aren’t puns (serial/cereal, for example) are references to science fiction (HeartAu, rdaneel, and wntrmute among them) or popular culture. Some are even dual-reference – “bowser” can be considered a pun on “browser,” and also associates with “shanana.”

There’s also a disclaimer hidden in the hexdump, which you can decipher yourself, or drill down into the link chain to find. Be careful, though, and remember: Cape does not enable wearer to fly.

Chrome fake BSOD

Miscellany 14

Sunday, April 17th, 2011

Just a collection of assorted things.

First, I’ve heard beautiful women described as “hot,” and I’ve heard of “hot sex,” but even given that, I’m surprised to find out that someone caught fire while watching porn.

Staying with the subject of sex for a moment, this is a wonderful practical joke.

Now for a couple of recipes. Before he joined Pajamas Media, Stephen Green used to do something he called the Friday Recipe. He’s just posted the first one in a while, and it’s a good one.

He doesn’t include a dessert, though. If you’ve a sweet tooth, this may fit the bill.

Looking for somewhere to live, and not enamored with anything on the market in your area? Try looking in Italy.

How do you know when someone’s trying to guide your thoughts? Here’s some good information.

Government surplus items available here.

And, finally, regular expressions are often incredibly useful. Unfortunately, they are also sometimes incredibly hard to generate correctly. This site can help.

This looks familiar

Thursday, March 10th, 2011

William Woody has a post about developing Java code to implement the factorial function. More specifically, it’s about how not to. He starts with a very simple (and straightforward) implementation, then produces updated version after alternate version in order to handle various possible conditions that the code may need to support.

The operative word is “may.” He concludes the post with a discussion of appropriate pains to take in an implementation, as well as which requirements for a programming task are actual requirements. As he says,

So please, do us all a favor: if you have the urge to add complexity because “someday we’ll need it, I just know it!”, or because “it’s not sufficiently flexible enough” or “we need reusability in our code” or (God help us!) because it’s “cool”–just go home early.

I’ve not programmed in Java, but the points he makes are applicable no matter what the language. I believe that part of the problem is that there is a subgroup of programmers who aren’t happy unless they’re showing off how convoluted they can make their code. I remember a cartoon I saw, either in an issue of Forth Dimensions or in one of Leo Brodie’s books, Starting Forth or Thinking Forth. The cartoon shows two programmers in space looking at the Earth-Moon system. One, the Forth programmer, is saying, “No good – too complex.” The other, labeled, I believe, “Ada programmer,” is saying, “No good, too simple.”

I’ve worked with both types of programmer, and I’m currently maintaining a large piece of code written over a decade ago by one of the “no good, too simple” types. He came from a background in academia, and felt that his MSCS made him more qualified to define application requirements and design products than the combined 30 or so years experience in the field that my boss and I had at the time, because neither of us had a Master’s degree.

It’s pretty hard to figure out what any given piece of code in that application does, because nothing is simple and straightforward. It’s all convoluted, indirect, and involved. It puts me in mind of a button I bought at an SF convention a few decades ago, which reads, “Never make anything simple and efficient when you can make it complex and wonderful.” As an example, the program maintains a pair of ring buffers. Conceptually, these are fairly simple and straightforward. There are some boundary conditions you need to be careful with, which are discussed at the link, but other than that, they’re easy.

In the software I’m maintaining, they were implemented as state machines with 64 states. Talk about violating Occam’s Razor! The C source file containing the implementation is 15k in size, with almost 600 lines of actual code. What comments there are in the file mostly relate to the encoding and meaning of the state numbers – very little of the code has descriptive comments stating what the code is doing.

Years ago, I ran across the statement that the fastest-executing and most bug-free code in a system is the code that isn’t there. That made tremendous sense to me, and it’s why the ring-buffer implementation I just described offends my sensibilities so much. To me, it’s just intellectual masturbation. He wasn’t writing for efficiency, or for clarity, although I’ve no doubt he’d claim that that was exactly what he’d done. He was writing to show off, to himself if no-one else. There may have been some attempt at job-security-through-obfuscated-code going on, as well. If so, that didn’t work. After all, I’m maintaining his code, and have no idea where he is, nor where he’s been for years. Actually, although the comments in the file describe it as a “robust” ring-buffer implementation, I had to make a correction to it several years ago – there was a bug in his code (color me surprised) that caused a persistent error condition after a particular error occurred. The code, of course, couldn’t detect that it was in that particular error state. Eventually, though, a customer could.

I probably put more emphasis on clean and simple code than most programmers. It often ends up longer than other implementations, because I tend to ignore a number of advanced features of the language, unless the code is meant to demonstrate the use of that feature. This is because most of our customers aren’t programmers; they’re engineers who want to learn as little programming as necessary to get the job done, and the code I write has to serve a pedagogical purpose, as well as being useful. As a result, the code I write tends to be very simple with a lot of comments. Unfortunately, that doesn’t always mean it’s bug-free.

Coding style may be a matter of preference, but coding complexity, at least in this regard, is a matter of corporate culture. At a previous job developing dedicated word processors (that is, a computer system that could only do word processing), back in the early 1980s, I was at one point tasked with making an update to a particular piece of code. The code was designed to be incredibly efficient; it was written in an incredibly convoluted manner in order to minimize execution time. It took me three weeks to understand the code, after which the change took less than a day. Coincidentally, the original author had taken three weeks to write the code.

The convoluted code saved several milliseconds over what a naive implementation would have taken. It executed once during system startup. I suspect that you can guess my feelings about the efficiency of that module.

The author moved on to the “new product” project that the company started. Apart from a few supervisors, nobody in the “current product” group could move over to the new product group – they staffed it up with recent graduates who’d used Unix in school. That was their problem. Apart from the supervisors, several of whom were addicted to cleverness in their code, nobody working on the new product had ever delivered a product.

The current product line that was providing all the company’s income was based on 8086 hubs and 6800-based terminals (80×24 characters, IIRC, but they might have had larger displays). The new product under development was to be 68000-based, with a bit-mapped graphical display so that you could do WYSIWYG word processing. They gave us a product demonstration at one point. The system took somewhere between 30 and 90 seconds to come up (this was around 1983 when most personal computers were effectively instant-on, and even PC-XTs only took a few seconds to boot DOS), and the bug list was written ceiling-to-floor several times on butcher paper that covered one wall. One bug was that you couldn’t print – not a good thing for a word processor company’s upcoming flagship product.

This has been a long rant, but my point is largely the same as Mr. Woody’s: complexity for the sake of complexity, or for anticipated future needs, is a bad thing. My elaboration on that point is: make sure you’ve got someone who knows what needs to be done, and ruthlessly prevents unnecessary complexity.

How’s that again?

Saturday, October 9th, 2010

While computer software engineers, the guys who write the software, are projected to be among the fastest-growing jobs, rising 32 percent over the next 10 years, demand for computer programmers, the guys who write the instructions for a computer to use that software, is expected to shrink 3 percent in the next decade.

Another step along the road to cyberwar

Friday, October 1st, 2010

We’ve had computer worms before, but Stuxnet is the first I’ve heard of that was written to deliberately target something other than just another computer – that is, to affect the real world.

There are good discussions here, here, here, here, here, and here that are worth reading.

I certainly don’t know who wrote it or why, nor do I have the geopolitical knowledge to forecast many of the consequences that can be expected. It is an escalation of the state of conflict between computer security and system attackers.

It appears that the people behind Stuxnet are well-funded and very capable. One wonders if they have any other development efforts in progress, or if there are other similar groups at work already.

Need to figure something out?

Monday, September 6th, 2010

This looks useful.

Engineering versus …

Sunday, August 29th, 2010

I’ve enjoyed doing software development, but it hasn’t been the most lucrative career. Of course, if I’d gotten into web development a decade or so ago, or been actively involved with any of the other hot-technologies-of-the-moment, I could have earned more money. Of course, at the moment, I consider myself lucky to be employed at all.

It fits in with something I read years ago … there’s a “money stream” that flows through organizations, and the closer your position is to being on the banks of the stream or actually within it, the more money you earn. As a programmer, I’ve usually been nowhere near the stream.

There are other problems with being employed as a technical person. Management often considers engineers fungible, so experience is discounted – except when your resume is being considered. I can remember seeing advertisements that required five years experience with software that had only been available for three – if you hadn’t been working on the development team, you didn’t qualify for the position. I also remember a cartoon from some years ago showing a hiring manager reading a resume, with dialogue on the order of, “I see you have ten years of experience with the technology, twenty-four patents, and forty publications. No Master’s degree. The position requires a Master’s degree.” At least this time around, I haven’t seen any ads that state “x months in the position offered” as a requirement.

Then you have the pressure. Not just feature and schedule pressure, but the knowledge that your work may be safety-critical. If you’re programming the anti-lock braking system for an automobile, or the fly-by-wire stability system for an aircraft, you are subject to worries and pressures that someone programming a media player application doesn’t have.

All of which leads up to this picture, which I found here:

Engineering plea and response

I, for one …

Tuesday, May 11th, 2010

Welcome our new software masters.