Category Archives: Software

Python is addictive

Been a while since I’ve felt this way, but Python brought it back out. Python programming is pretty addictive. I find myself pondering the next little Python ditty to whip up, and going through  withdrawal without it. Gotta get my Python fix!

If you’re a developer who can taste a good design, a good implementation, you know what I mean.

Of course, there are plenty of things I wouldn’t write in Python.

 

Downsides of SaaS

Software-as-a-Service has its downsides, as one commenter notes:

We’re beginning to see the pitfalls of software-as-a-service in general: loss of control for for the user, increased security risks, and being entirely at the mercy of the providers’ future business strategies.

The context is Google discontinuing its RSS Reader.

A small outfit has motivation that a big one doesn’t. It matters not just to the provider, but the user. Opportunity abounds.

 

Downsides of Collaboration

Here’s an outstanding video on how collaboration can not only kill creativity, but dupe our very perceptions. Steve Wozniak:

Most inventors and engineers I have met are like me: they’re shy and they live in their heads. They’re almost like artists. In fact, the very best of them are artists. And artists work best alone where they can control an invention’s design without a lot of other people designing it for marketing or some other committee. I don’t believe anything revolutionary has ever been invented by committee. If you’re that rare engineer who is an inventor and also an artist, I’m going to give you some advice that might be hard to take. That advice is: work alone. You’re going to be best able to design revolutionary products and features if you’re working on your own. Not on a committee. Not on a team.

And it gets better from here.

You’ll undoubtedly apply it to situations closest to your heart.  It resonates with me and the software I write. Of course we can’t just make up our own requirements, but the final product needs to come from you.

I also hear a call to courage. Don’t be arrogant, but stand your ground. Use your best judgment. Don’t be dulled–or let your project be dulled–by the strongest personalities in the room.

Thoughts?

 

 

Software Runs the World: How Scared Should We Be That So Much of It Is So Bad?

From The Atlantic:

The underlying problem here is that most software is not very good. Writing good software is hard. There are thousands of opportunities to make mistakes. More importantly, it’s difficult if not impossible to anticipate all the situations that a software program will be faced with, especially when–as was the case for both UBS and Knight–it is interacting with other software programs that are not under your control. It’s difficult to test software properly if you don’t know all the use cases that it’s going to have to support.

Though there are a number of angles to this piece (and you should read it all), here’s another nugget:

This is one problem that regulation probably can’t solve directly. How can you write a rule saying that companies have to write good software?

Fantasecond response time

Here’s a fascinating in-depth study of one second of market data for a single stock:

HFT [High Frequency Trading] Breaks Speed-of-Light Barrier, Sets Trading Speed World Record.
Adds a new unit of time measurement to the lexicon: fantasecond.

On September 15, 2011, beginning at 12:48:54.600, there was a time warp in the trading of Yahoo! (YHOO) stock. HFT has reached speeds faster than the speed-of-light, allowing time travel into the future. Up to 190 milliseconds into the future, or 0.19 fantaseconds is the record so far. It all happened in just over one second of trading, the evidence buried under an avalanche of about 19,000 quotes and 3,000 individual trade executions. The facts of the matter are indisputable. Based on official UQDF/UTDF exchange timestamps, there is unmistakable proof that YHOO trades were executed on quotes that didn’t exist until 190 milliseconds later!

Millions of traders depend on the accuracy of exchange timestamps — especially after bad timestamps were found to be a key factor in the disastrous market crash known as the flash crash of May 2010. …

The lowly time-stamp. Not rocket science. Not crucial like price, right? What’s to get wrong? An exchange with unlimited resources couldn’t mess up like that, could it? (Assuming the analysis is correct.)

As a software builder, I wonder how did it happen?

It probably wasn’t buggy code: unit tests are good, but more of them probably won’t catch this one.

Was it sheer load? It wasn’t the highest overall traffic they experienced:

The chart below shows quote message rates for UQDF and multicast line #6 which is the line that carries YHOO quotes. … Although traffic from YHOO was a significant percentage of all traffic on UQDF, it was not high enough to indicate any problems. Note the much higher surge on the right side of the chart; there weren’t any known problems at that time in YHOO.

So the system would pass a generic stress test. Yet still allow this.

Maybe the system was stressed in some unexpected way. This stress’ profile wasn’t predicted, characterized, mitigated. The system design didn’t account for it.

A multi-tasking operating system is likely part of the picture. Maybe another task was started that tied up crucial resources, even just CPU. Maybe not even a lot of resources, or not for very long. A multi-tasking operating system is geared to never say “enough.” Another task in the CPU’s ready queue? No problem. Out of RAM? Swap some to disk: user programs can’t even tell!

Information hiding gets us off the “honors system” with memory usage. But in the time domain, you’re still very much on the honors system: no one can make you complete your task in a given time. In fact, any innocuous-looking call can have any amount of code hiding deep inside it.

You can make a user wait for a tenth of a second or more and still seem really responsive. (Think “garbage collection.”) But a real-time data feed won’t wait. It’s a different ball-game.

Maybe we’re just seeing a hardware limitation hit. Maybe the best machines money can buy just can’t keep up with certain kinds of volume. There’s no guarantee they can.

Interesting stuff. Hat’s off to the author for such a detailed analysis.

Via ZeroHedge.

Conserving Screen Height: Killing “Height Cruft”

With the onset of HD, monitors are now wider than they are tall. Great for video, but not for computing.

If you’re a developer, consider screen height a limited, precious resource. Conserve it. Trade width for height. Kill height cruft. (Can I coin that?)

Button bars: traditionally horizontal at the top of the app. Can you make it vertical, to the left or right?

Even the traditional menu bar (“File Edit View … Tools Window Help”) crowds you down by its height.

Case study: Amazon’s Instant Video in Internet Explorer. IE adds menu items and multiple button bars at the top. Then amazon’s web-site adds its headers across the top. The video winds up a tiny fraction of its potential size, squeezed by all the height cruft. Not to blame Amazon: there’s a “full screen” button, and F11 in IE takes away a bunch of stuff (if you know about it).

The lesson: when every layer adds its own, it compounds.

Software developers take heed.

As a user, there’s lots you can do to conserve height.

Did you know you can put the Windows task bar to the left or right? I put mine to the left, as narrow as possible. You lose a little of the icons’ descriptions, but mousing over gives them back. It flushes out some bugs, too: some programs start in the upper left corner, winding up under the task bar. (To move the task bar, put the mouse on the middle top edge and drag it to the middle left.)

Most software today lets you move menu bars, and the best ones let you dock them to the left or right, making them vertical. Very nice, though they can truncate text menus. Your word processor has several: don’t live with them crowding you. It’s worth retraining your eye to work with them vertically. (Convince your complaining co-workers, too.)

For working with source code, height is particularly valuable. Source-code flows down, and seeing more at once is better. I have a two-monitor set-up on my desk-top, and my cheap, last-generation NVidia video card lets me turn one monitor sideways. A $40 monitor stand and you’re in business. This has been an indispensable productivity boost for me. Don’t work with all horizontal monitors.

When looking at code, can you bump your font-size down one? You’ll see a lot more.

Update. I promise I’m not making this up: one day after this pontification a client passes along a request to do exactly this: rearrange things to conserve screen height in a program I wrote a couple years ago. File this under eerily prescient or physician heal thyself?

The next make?

Many build systems exist to help people build their projects in a cogent manner and avoid the stupefying (albeit powerful) makefile: CMake, scons, boost.build, bjam, ant, etc. Each has its following, often based on the propensity of the audience (C/C++, python, Java).

Here’s another to add to the mix: Cake. And this brief intro on the Boost-interest digest makes the pitch.

No makefile at all. You put compiler flags right in the source code, and it walks your source, looking for special comments and using some naming conventions.

I like the idea of compiler flags in the source. Source-code attributes like dllimport and pragma comment(lib…) prove that’s useful.

You need g++ and make (behind the scenes), so that constrains its user base. Will the naming conventions be too restrictive? It uses a global configuration (in /etc/), but I can envision wanting a project-specific common configuration file, too, being the control freak I am. Will it accommodate?

Put it on your watch list.