DHTML KISS

I’ve been tardy in following up to the previous entries about my adventure in dhtml. Well, the floating, transparent div was a problem too. The goal was to highlight a column, but floating the div over the top of the text just served to make it harder to read. Back to the drawing board…

I fell back to the very first thing I thought of but quickly moved past because it seemed too inelegant, inefficient. Shame on me. Now I have the javascript looping over all the td’s in the table and setting the background color of each — either to the highlight color if the column is correct, or to the background color of the row otherwise (to remove the previous highlight if it existed). There’s no performance problem and this is actually more cross-browser friendly. I’m humbled. I’ve given talks including the point of the ‘evil’ of premature optimization, but it is so easy to fall into.

potential differences [/dhtml] permalink

Developing and Testing Mindsets

Mike Clark writes about tearing down the barriers between testers and developers. I’m all for that, but I’m not convinced that abolishing the terms “QA” and “tester” is the right approach.

At my current job, one of the resons I was hired was to get a test driven mindset into the development community. One of the things I had to do was to make sure that the testers did not feel threatened by this push. I’ve gotten to know the testers and have begun reading articles and blogs from testers. I believe there are important differences in the skills and mindsets of good testers and developers, and I want to mine that before the distinctions of the titles are taken into question.

Test Driven Development is primarily a design tool, and secondarily a verification tool — and even as a verification tool it is woefully incomplete. It focuses only on the small scale. Testers focus on the verification angle — the design is secondary to their task. They’re looking mostly at a functional or system level of granularity, and this is much closer to the level the users are going to judge the quality of the software from.

Our lead tester told me the other day that she comes from a programming background, but ssshhh…. don’t tell anyone because she hates doing it. I replied that I don’t have the tolerance of detail that she has and would hate being a tester, but that I have great respect for the job they do. I still don’t have a complete picture in my mind if what the fundamental difference is. Programming certainly requires attention to detail, but it is different somehow. I’m going to be exploring this more in upcoming blog entries and try to understand what and how we can learn from each other to further our common goal of better software.

potential differences [/testing] permalink

I’ve Been Interviewed

Help Net Security has interviewed me regarding the work I did on Maximum Security 4th Ed. last fall. It’s my first interview. It feels both weird and cool at the same time.

potential differences [/security] permalink

DHTML Not So Fun

As a follow up to my previous entry, I’ve found that I was too clever for my own good with that “shadow” table. It becomes a real problem with the window is resized (which includes during printing!). I’ve got a new direction to try. I’ll follow up once I’ve had a chance to work with it. The plans are to use an absolutely positioned DIV with a solid color and mostly transparent floating over the top of the column of interest. With a stylesheet specialized for printing I can completely hide the DIV if it becomes a problem.

potential differences [/dhtml] permalink

Future of Computer Languages

Paul Graham’s The Hundred-Year Language essay got me to thinking. Which is good because I was somewhat distracted by the secondary between-the-lines message. It’s clear that he’s leading people down the garden path, trying to lead them to the conclusion: “Lisp is it!” I’d much prefer that he be upfront and state that as his thesis rather than this failure at subtlety. He may well be right. I’m not going to argue against it, but the average developer today is not ready for it. So, how do we pragmatically take mainstream development, and average developers into the future now?

The answer is to get the mainstream to stepwise accept new languages that truly improve productivity. I’m talking about the types of steps such as moving from assembler to compiled languages, from procedural to object orientation, from pointer arithmetic to garbage collection. Each new language we learn requires a time investment — mostly of tools and available libraries; syntax issues get easier with each successive language. Sometimes there’s a deeper paradigm shift such as the steps above. When choosing a new language to learn, that’s what I look for — something that will truly broaden my thinking and that might be that next step ahead that the industry needs to go.

Thinking through this helped me to explain my intuitive reluctance to embrace Objective C. I truly admire the language, especially as an alternative to C++. In an IM session Glenn Vanderburg eloquently said: “It’s an exceptionally beautiful ugly kludge.” I share the sentiment. It was a great engineering choice for Apple because it allows them to have one foot in the C ruled world of unix, and another foot in the loosely typed world conducive to GUI development. Still, it is a step backward to manual memory management for me, and not something that will move me ahead as a developer.

That’s also what bugs me so much about .NET from a technical perspective (I won’t go into the political objections ;-). It’s purely a lateral move that will require a lot of time gaining expertise in the libraries and tools with no fundamental forward motion in the state of software development. I’m probably going to have to learn it in order to pay the bills, but it won’t move me forward as a developer.

I think RubyCocoa is my next step of development.

potential differences [/lang] permalink

DHTML Fun

As I mentioned earlier I’m using this site and two others as an excuse to update my web authoring skills. At work I was also asked to do what initially seemed to be a simple task, but ended up not so simple. There’s a table of data with alternating row background colors to help legibility. Based upon what a user selects from a select list on the page we want to highlight a particular column of the table by changing its background color.

So, I quickly learned about the new col tag table child, as well as the document.getElementById javascript method. However, a straightforward col.style.backgroundColor = x call didn’t work. After some research I discovered that row backgrounds are drawn on top of column backgrounds. It was time I enter hack mode.

I ended up dynamically creating a “shadow” table absolutely z-positioned behind the primary one, matching it’s position, size, and number of rows. The shadow table’s rows had background colors. The primary table’s background colors were all transparent, so that when I set a column’s background color, it was visible. Problem solved.

I think a lot of developers look down upon doing javascript and html work (and GUI work in general) and that’s really a shame. Elegant code and ingenious solutions can be found in the user interface arena.

potential differences [/dhtml] permalink

OS X as a Postscript RIP

A couple of weekends ago, my old printer died just as my wife was working on taxes. She still hasn’t made the leap to OS X, so I had to get the new HP 5550 printer working from her desktop — quickly. The printer is attached to my SMC Barricade wifi router. Well, it ends up OS 9 can do IP printing, but it assumes the printer understands postscript, which mine doesn’t. I knew the CUPS framework could handle the rasterizing of postscript to the HP, so I just had to figure out how to do it from the OS 9 machine.

I had already discovered linuxprinting.org when I first setup the TiBook to print to the HP. Gimp-print gets a lot of press, but for HPs, I recommend hpijs. Another section of that site offers PPD-o-matic which allows the OS 9 machine to set various aspects of the printing through it’s normal IP printing infrastructure, even though it’s really an inkjet it’s printing to.

My last piece of the puzzle was to find an article at macosxhints.com to setup an lpd daemon on the OS X box. So, with some trepidation I pointed the OS 9 machine to print to the TiBook. I pictured OS 9 converting to postscript, spooling it out over ethernet to the router, which sent it over wifi to the TiBook, which then rasterized the postscript, and spooled it over wifi back to the router, which dumped it to the printer. Nothin’ but net! My jaw dropped when it worked flawlessly the first time I tried it. I love OS X!

Note that this solution would work with any printer that OS X can print to, and from any client that can talk to a networked printer, and it’s free. Did I mention I love OS X?

potential differences [/mac] permalink

Rendezvous Virtual Hosts

This is one of three websites I find myself involved in either setting up from scratch or giving a major face-lift. The other two are my hobby website for country guitarists that I’ve been doing for 10 years, COWPIE and my church website, Hope Reformed Church. So, on my TiBook I’ve got all three setup as apache Virtual Hosts. I thought it would be really cool to have them all published under Rendezvous, but it’s not as easy as it sounds. I’ve emailed Joe Maller a bit about it after reading his post on macosxhints and he told me today that he’d published an article on it over on O’Reilly’s site.

It’s getting late, so I doubt I’ll fully digest and play with his ideas this evening, but from a quick skim, it’s still too hackish for my tastes. For now I’ll just do without rendezvous. I’ve already entered the cowpie.local and hrc.local hosts in my /etc/hosts file, so it’s not too hard to bookmark them.

There’s an app called Rendezvous Beacon I downloaded the other day that I had high hopes for because it says it can advertise on behalf of another host, but I can’t get it to work. Maybe it’s because I registered my hosts in my /etc/hosts file and it’s only looking in the netinfo database. I haven’t had time to dig any further.

potential differences [/mac] permalink

Transparent Prefs

I love the fact that OS X has a hackable preferences infrastructure. So much of it is hackable which is what makes it such a great developer platform. I’m bringing this up because in order to get around the Blapp prefs problem I mentioned yesterday, I just opened the prefs file in the plist editor and took care of it :-)

potential differences [/mac] permalink

Working the Kinks Out

I thought I’d write an entry as I’m starting out doing the customizations, and in order to get rid of the default entries. I’m not expecting many visits yet since I haven’t publicized the blog. Blapp is giving me some problems right now. It doesn’t want to accept my custom remote connection string. If I close and re-open the prefs, it reverts to the default string rather than keeping the one I entered. I’ll use Fugu until I get a chance to track the issue down. So many things to do, which reminds me …

The blog will also probably be a test-bed as a update my html skills. I haven’t really learned much new since tables were introduced. Now it’s time to learn stylesheets and dhtml. There’s an experimental flavor I’m playing with you can visit if you’re brave :-) I’m hoping to have bypassed the really messy years of incompatible browser implementations and not have to fight with those issues. Plus, I suspect whatever audience I may gain over time will have modern (read: standards compliant) browsers and I can get away with using some advanced features.

potential differences [/blogging] permalink