Johnny's Software Saloon

Weblog where I discuss things that really interest me. Things like Java software development, Ruby, Ruby on Rails, Macintosh software, Cocoa, Eclipse IDE, OOP, content management, XML technologies, CSS and XSLT document styling, artificial intelligence, standard document formats, and cool non-computing technologies.

My Photo
Location: Germantown, Maryland, United States

I like writing software, listening to music (mostly country and rock but a little of everything), walking around outside, reading (when I have the time), relaxing in front of my TV watching my TiVo, playing with my cat, and riding around in my hybrid gas/electric car.

Tuesday, March 23, 2010

couple big letdowns from my car this morning

The first problem I had today was my car's front tire was completely flat.  Took me only several feet to figure that out.

Next problem I encountered was the local dealership does not stock the replacement tire and cannot get one from somewhere else until tomorrow.

Checking customer reviews of local tire shops revealed some get very good reviews, others get really bad ones.  All of them seem to take pretty much all day.

Wondering if there is any way to get my front tires replaced/balanced today, and into office for half a day.

I considered a couple fallback solutions if nobody can get the tires today.  It looks like nobody can.

One is I have the tires ordered and dealer and put on first thing tomorrow morning at the dealer.  Another place nearby can put the tires on Thursday, but they are totally booked up today and tomorrow (Wednesday) too.

The other option is a place a few blocks away, but they said they were too busy to give me an estimate over the phone and I need to get the spare on and drive it in to get the estimate.

Other option, which might work out better - is to use spare to get the short distance to/from nearby commuter rail Wed-Thu and have the front tires replaced Saturday morning.

It is kind of looking like may wind up using both of these options.  Thank goodness it is not supposed to rain tomorrow.  It is going to rain Friday, though.  

I just wanted to write some JSPs and draw some UML diagrams, and this is what I get to do instead.  Oh, well. Somewhere, there is an auto mechanic cursing the problems he is having with his computer, I have no doubt.

I did some searching on the web and found that the distance you can drive on a spare tire is a little longer than I thought, but still quite limited.  Another important fact I learned is that with many spare tires, you can only drive them safely at speeds under 50 mph.

UPDATE:  Lug nuts are on so tight that the trying to loosen them with the hand lug wrench does not make them budge.  In fact, the entire car rolls when I try.  Looks like I am going to need a tow.   Also looks like instead of making money today, I am spending a bunch.

UPDATE:  Someone wrote that they had the same problem and after trying lots of expensive power tools, they finally got their stuck lug nuts off using something called a breaker bar, which they bought for only $28.   Now, I have to track down a place in walking distance that has a breaker bar and give my boss an update.  I like writing JSPs so much more than this.

UPDATE:  It turns out, to use a breaker bar you need to have a socket wrench.  Moreover, the  breaker bar can damage the socket wrench.  Looks like now my only option is to tow the car "someplace".  Maybe I can tow it to the dealer, get them to put on the spare tire which will get me to/from the mass transit lot - and order the tires so I can have them put onto the car Saturday.

UPDATE:  My dealer informed me that the lug nuts on my wheels are probably secured with a wheel lock on each wheel.  I looked for and cannot find a "key" like the one she described.  So, this pretty much nails that I have to have my car towed to the dealership. At this point, it is abundantly clear I am not going to be able to get to my office for even a couple of hours.  So time for another call to my boss.

UPDATE:  The rear tire tread and sides look to be in excellent condition.  So at least I will not have to replace them for a good while.

UPDATE: Car is being towed to dealership.  Spare tire will go on for me to use to get me to/from public transit lot for remainder of this week, and two new tires will go on the front of the car on Saturday.

UPDATE: Just got back from dealership.  Rode shotgun in the tow truck on the way over.  I have temporary tire on until Saturday morning.  Fortunately, the part of my commute that is by car is really short.  Thank goodness for public transportation.

UPDATE: Just made second wave of calls to customer and my agency letting them know that the problem with my car was solved with spare tire to let me get in for the remainder of this week.

THOUGHTS: I am kind of upset that something as mundane as a flat tire is so time-consuming and expensive to solve.  For one thing, the $69 tow is something I wish I could have avoided.  For another, needing to special order tires is a big pain. Wasting time in a futile effort to remove the lug nuts manually was also regrettable.  I might have the mechanics verify they are not on too tight Saturday when I have the real tires put on the car.


Monday, March 01, 2010

Why developers like the Macintosh

Because it comes with tons of developer software for free!

Labels: , , , , , , , , , ,

Friday, February 12, 2010

an aggressive QA tool

I woke up this morning figuring out how to build a modern QA tool.

It is not like any other QA tool I have seen.  It combines a handful of modern software development technologies that are not usually combined.

It does not fit any pattern I have seen before.  It combines technologies that are common but not part of the same discipline.  I am not sure if it is unique, but it certainly is original.

It was a very static technology when I was first waking up to the idea.  Within 10 minutes I had worked out a way to maybe make it very dynamic, almost interactive.  It is designed to thrash out serious bugs very quickly.  Like I said, it is very aggressive.

I have a very specific use case in mind.  I think it can be generalized, though.  The primary target is existing code.  However, at this moment, I am trying to think if it can be used for TDD (test-driven design). Preventing bugs from having any lifetime at all in new code would be very useful.

I am just letting it play out in my mind now. I am feeling unusually intuitive/creative this morning.  I am not planning to code this bad boy today because I have a lot of other stuff I want to get done.  When I do program it, I think it is going to be a lot of fun.

I think it will be almost fun to use too.  It will certainly make it a lot easier to do something that is insanely tedious and clearly not efficient or decisively productive now.

Certain types of bugs have been creeping into software for ages. Right now, there are likely a lot of these creepy bugs lurking in vital infrastructure and on ordinary people's desks.  Stuff almost everyone uses every day, and almost no one ever thinks could be a problem despite a well documented history to the contrary.

Such an inurement bothers me  because it fosters fecund problems that fester and fan out, frequently infusing facilities with faults. The faults have potential energy (PE) that ultimately reaches a trigger point and latches up hard - breaking whatever it grasps, until equilibrium is reestablished.

As I was wrapping this post up, my subconscious dredged up a word  have never used and barely ever heard before: "epistemology".  It turns out, that is a good word; a very useful one.

After I have the toolset created and as I am getting ready to put it into use, I think I will consult with that word a bit more.  It will probably allow me to imbue it with a lot abilities. It can certainly have some influence on the architecture.

A guy who seemed pretty wise to me once said on the radio, words to the effect:  "We must stop being gatherers.  We must become hunters."  He was so right.  Some problems need to be targeted right at their roots, boxed in, and eliminated

That is hunting.  That is not sitting back and collecting.  When one type of low-hanging fruit is exhausted, you have to change the game and convert something else to low-hanging fruit. To change the target and still be effective, you have to change the approach.  That is the core principle he was getting at, I am sure.

The domains of this radio show guest's problem and mine are kind of orthogonal to each other.  That is not to say that one does not know about the other, unfortunately.

That kind of bugs me.  I would like to disarm one problem of the other because right now it is too damned well armed.  And then the potential energy in the system can go back down to stable levels.  It is not at its resting level now.  It is at its triggering state.  In fact, it is constantly triggering.

Look up the mechanism whereby a nerve impulse causes a muscle to contract and what kind of change has to occur to get that muscle to relax again, and you will see how it resonates with the current status of Windows security.  In this case, intrinsic flaws have created an emergent environment that is in effect the clenched muscle.

The current praxis of trying to protect Windows and other programmed systems does not deal with this situation because it tries to model itself after ill-fitting military base-guarding techniques: perimeter defenses, passwords, encryption, etc.

All are useful techniques but none solve the core problem: the central flaws in the thing being protected - buggy software.  Bugs gotta go!

The bugs are not just creating an opportunity for attacks:  they are responsible for the rapid evolution and growth of the attackers.  You can winnow the population size of the attackers, or strive to do that anyway.  However, you cannot devolve them.  Evolution is mostly a one way street.  Population control has no effect on how inimical individual members of a species are.  Nor does population control prevent future population growth.  Bugs gotta go!

Labels: , , , , ,

Tuesday, February 09, 2010

How I do not like snow

Snow sucks.

Saturday, January 16, 2010

Quite a decade

As often happens when we start a new year or a new decade, The Register has published an article reflecting the past decade.

The theme of the article is how big companies became bigger, and some really big companies failed in the past decade.  It also looks over some of the technologies that went over smoothly, like USB.

It is a fascinating retrospective.  The title is a little demented since it picks on Google for being the opposite of what they are.

I just ignore that like I ignored the claptrap that made the spectacular hacking of Siliicon Valley possible.  All the illogical statements like: hackers do not find bugs/flaws in software, they wait until patches come out; bug in product that has been out for over 8 years is a zero day vulnerability, because the press release says so; IE is safe now, because one more out of a cornucopia has been fixed.

The facts in the article are interesting.  The title, I dunno.  I suppose it was an ad.  It did not fit the facts, and really we all learned decades ago to ignore "paid testimonials" from watching TV commercials.

Looking back over 2000-2009, there were a lot of dramatic changes.  More than the article hinted out, since it fixed its gaze mainly on a few companies, and not the broader canvas of computing.  In the really long run, I am not sure those companies matter.  I think the computing situations we are in matter more.
  • search is fundamentally important because the web is so dynamic and so big
  • computing has become incredibly untrustworthy
  • cost of flaws is pushed off onto the public, with the press and the government supposed to take on the roles of technical support
  • computer languages and application servers are incredibly powerful today
  • web browsers are much faster and more efficient than IE6 and Netscape 4
  • companies that talk about all the great things they are doing with computer security are the ones whose products get hacked far more than any other
  • security companies do get hacked the same ways the rest of the industry does
  • we cannot shutdown giant botnets or stop them from attacking US companies and agencies
All of these things are somewhat surprising to me.  Consider history.

In the 1970's, computers had just transitioned from DP centers to hobbyist desktops, and finally to appliances.  TV set top video games like Atari were introduced. Schools taught programming courses on minicomputers and mainframes - with terminals, paper & magnetic tape readers, and mainframes.  You could get access to a computer at MIT by request, if you could explain a worthy project.  People who brought down computers were outcasts, and banned.  It was truly the "honor system".  Hackers were not a threat to the aveage person or typical company at all.  Operating systems consisted of some device drivers, a file system for hard disks, and maybe a BASIC interpreter.  You turned on your computer, and it was on instantly or a matter of seconds.  The US was a self-contained computing bubble and we really did not attack ourselves that much, obviously. We were building something.

In the 1980's, computer displays transitioned from raw text to friendly GUIs and so desktop publishing, word processing & spreadsheets caught on.  Now, we were using these tools we we had created to write/print letters, organize personal and business information, and basically retire typewriters.  Wonderful video games for Apple's and PC's arrived that were better than arcade and TV set video games, in some cases.  Two-dimensional graphical role playing games arrived on home computers. Computer flaws that caused serious problems were pretty rare.  Macs just worked.  PCs just ran MS-DOS most places during this era.  The first PC and Mac viruses came out.  The Mac had absurd vulnerabilities like the ability to attach executable code to desktop icons.  Society's biggest dangerous hack in that era was a malfunctioning worm that shutdown government/commercial/university computers all around the United States for a day.  Academians at MIT and elsewhere snagged copies of it, analyzed it, solved the problem of how to stop it, and shared it.  So the worm did not live long.

In the 1990's, personal computers were fast, attractive and easier to use.  RISC computing rose to its peak and began to fall.  The Intel/AMD x86 processor architecture merged as dominant.  The 68k architecture expired. The Mac switched from it to PowerPC (RISC).  Three-D computer games for PCs debuted.  Windows finally caught on.  The web caught on when Mosaic was introduced in the early days.  The Wall that symbolically separated Eastern Europe from the Western world was torn down.  Eastern Europe had serious economic problems.  Russia gave back East Germany to West Germany.  Much of the rest of the former Soviet bloc declared "I quit," and left as well!  Russia had to use conventional trade agreements to make economic agreements.  East European gangs were unleashed.

What happened in this latest decade was the US got hacked hard.  Over and over, the Windows operating system got pounded.  Mistakes by users, errors by programmers, flaws in server/email/browser applications began to be exploited by curious, noisome little vandals - in.  In 2001, thse suddenly had very serious ramifications when exploited. Global worms infested millions of Windows PCs in 18 minutes.  It was a game-changer, or at least a warning shot over the bow.  A couple years later, that warning rang true.  Criminals bent on thievery, extortion, and exploitation started hitting those same Windows computers. They never let go, overall - they just grew, and grew their giant armies of compromised computers.

Computers are much faster today than they were a decade ago.  No doubt faster and easier than almost anyone dreamed they could become, back in the 1970's.   GNU C sped up the state of the art in compiler technology, making very fast software possible.  Intel and AMD made very fast computer processors.  Every application has benefited from those type of improvements.  Speed has gone well.  Safety has not.

Computers are vulnerable for a lot of reasons today.  Most of those reasons were evident in the 1970's or 1980's.  Computer language designers declared they would not get in programmers' way and stop them from making mistakes in their programs.  C, still the main one used today for system programming - along with its descendants C++ and Objective-C for applications programming, had a lot of risks.  It made it easy for a programmer to make a mistake and never notice it.  Many mistakes were made.  Though unnoticed by their creators/maintainers, they were noticed by criminal elements.

Today, commerce and security is threatened by a ball dropped three decades ago.  That ball has kept rolling.  How long before we switch balls or fix it?

Sunday, December 20, 2009

just saw a Chrome commercial by Google

Looks like Google has revved up their advertising machine for their Chrome browser.

I just saw a commercial for it this evening. I tried out the new Mac-compatible beta out today. Fast and W3 standards compliant are how I would summarize my immediate positive impressions.

It seems to run as fast as the latest Firefox 3.5 and Safari 4. I have not run any benchmarks.

I am curious when Google is going to improve the support for native Mac UI features like Safari has. The Mac provides a system-wide Dictionary and other text processing services that set it apart from other operating systems. Adding support for them to Chrome will make it far more attractive to Mac users.

I am also curious about getting Java support.

In general, this is a most impressive first beta for a web browser to a new platform.

Labels: , ,

Friday, November 20, 2009

reformatting resume is a big job

I have been sharpening my Microsoft Word skills by cleaning up the formatting and layout of my resume.

I have been working as a software developer for quite a long while. A dozen or more years each as both an employee and a consultant. So, yes - it is long.

I think this is the last time I will try to do it as a word processor document. I hear Apple Pages are good so I might try that some as my final attempt at using a word processor on it. MS-Word does not really seem suited for holding this much information. I like using MS-Word for technical writing. I would use it still if I could fit my resume on a page or two.

I am kind of toying with the idea of putting it into LaTeX next time. I think it would probably be a lot easier for me to retool the formats. I have also been toying with the idea for a while now of doing it in XML. That would be nice because I could pull bits of it out with XPath expressions, or XQuery queries, or little XLST stylesheets. Also, I could type in a bit of CSS and style it for rendering in my browser as well. Anyway, that is the direction I will proably go in next time.

Related pages & news