April 2004 Archives
Ryan Lowe makes a good argument why Testing is a First Class Job. Resonates with my post regarding Bugs. Bugs. Bugs. and offers lots of detailed insight.
Notepad 2. freeware. Syntax-Highlighting etc. (via shahine.com/omar/)
A new Smalltalk for MacOS X. I hope these guys will be more successful than QKS in the early 90s.
Compilers and Compiler Generators.
Great read for everyone interested in compilers. Of course, it's only an introductory text, but still useful.
Frank Sommers asks: At the network's edge, is software a service business?.
Interesting enough, German ISVs targeting the SOHO markets are fighting with this problem since the early 80s. Looks like a great opportunity for us :-)
Keith Pitty and Charles Miller have some very useful thoughts on software testing and finding bugs.
Automated software tests taking care of possible regressions are extremly important, especially if you intend to release often. However, automated tests are not an after-thought, neither unit-tests nor acceptance-tests. If you change the fundamental algorithmn, you are not finished as long as the unit tests don't reflect the new/different boundary conditions. If you add a new feature, you're not done as long as you've added a new acceptance test covering the feature. This requires a lot of discipline on behalf of the developers. Plus it requires patience on behalf of management, because changing the algorithmn/implementing the feature will take a little bit longer than expected. Last but not least, having automated tests provides a great starting point for external testers, ensuring they don't complain about those nasty regressions.
Having external software testers is vital to find the bugs in areas/paths not vovered by automated tests (most likely the majority of bugs). Developers test their code to see if it works the way they think it should work. They're testing with knowledge of the code written a couple of minutes ago. They want to see it work, not fail - after all, who want's to see his/her work fails? External testers expect the code to deliver the results they expect. Plus, they want to see the code fail, which, BTW, create a significant tension between the two camps. Make sure to remind everyone involved that both teams are working together to deliver a great product.
Keith makes a good point about over-reliance on automated tests. However, note that you got to have a comprehensive suite of automated tests first, covering all the regressions you want to avoid by all means. Then start worrying about over-reliance on automated tests. But not the other way round.
Scans of Apple publications from the very beginning to the 90s.
Very nice photo blog covering the Smoky Mountains (via Critical section).
Finally, my AiBook, 1.25GHZ, 1GB RAM, 80GB drive arrived.
It feels great. The system is way more responsive than my old TiBook 866. However, due to some misconfiguration in CodeWarrior, builds are about 8% slower on the AiBook. Haven't figured out why, yet.
Putting all connectors like USB, Firewire etc. on the left & right side of the unit instead of putting them on the back is a major design flaw. The backlit keyboard is cool, though.
Haven't tried the Bluetooth connectivity to my P900 phone, yet.
Looks like it's running cooler than the old TiBook, too.
...Mark Cuban talks about what business the NBA is in. Excellent read for everyone who thinks pro-sports is still about sports. It's not. It's about entertainment.
Porchdog software has a Windows implementation of the Zero Configuration Networking standard. Plus a cool little app (both MacOS X & Windows XP) for a shared clipboard called Spike. (via Tao of Mac)
- Order pizza via phone (we had calzone, salami pizza, plain pizza bread and a salad)
- Arrive at pizza shop talking on your new P900 phone
- Tell waiter your name
- Waiter starts interviewing you about phone
- Calls other waiter to check out phone
- Cooks from kitchen arrive, check out phone
- Pizza cook stops making pizza, checks out phone
- Everybody starts arguing about the P900, it's price, wether Symbian is superior to PalmOS etc.
Yet another Flash-Game: Hasentöter. Rabbitkiller.
Robert Andersen. Affordable rates.
I wish both sides would spend more time on the future, and less on the past. Whether you believe Bush is doing a great job or a horrible job, whether you believe we should have invaded Iraq or not, whether you believe the tax cut was helpful or horrible, it is what it is. Bush is president. We did invade Iraq, and are occupying it right now. We did enact the tax cut. So my question for both candidates and both parties is: given that it is what it is, what are your plans? - Ole Eichhorn
What a great post. This struck a chord in me (No, I won't comment on US politics, although I would have a lot to say about the current administration :-).
Let's get over it.
How do we change this situation? How do we innovate?
Adriaan Tijsseling announces ecto for Windows, a frontend for Movable Type and others. Cristian Vidmar reminds me what I dislike about ecto for MacOS: Lack of WYSIWYG HTML-editing.
Fundamental issues with open source software development by Michelle Levesque.
Michelle raises a couple of good points, however, the issues mentioned can be found in commercial software development, too. I hope to find some more time later this week to comment on User interface design and Feature?centric development. Reminder to self: I wanted to ramble about document-centric computing, too.
Nach einem Stromausfall fährt unser PC zuhause nicht mehr hoch. Mach einfach gar nichts mehr. Love it.
w3's take on the neverending saga: A character is not a byte.
Henry Minsky writes in a comment on a previous post of mine: I believe the new Laszlo component classes do make some significant strides in addressing the issues you raise, such as how can classes be extended and customized, and how can some of the well known grunt work be handled by the system instead of by the developer for each app.
In a broader context (and not talking about Lazlo specifically), having a consistent, straightforward way to customize and extend the system is key.
IMHO, the lacmus test for extensibility is the exclusive use of public extension mechanisms in the system itself. I've seen numerous systems whith great extension mechanismns. However, most of them feature some "private", non-documented, "highly discouraged" extension mechanisms, too. If you need private extension mechanismns or if your own code features some elaborate ways to work around deficiencies in the system, revise the system. Even if you break compatibility.
While you're at it, eat your own dogfood and use your own UI framework to create helper apps etc.
And if you want to make the job of UI developers easier, provide the source code to the UI framework/subsystem/helper apps etc. or however you may call it. Judging from my experience, having access to the source code is extremely important. No amount of documentation, sample code etc. can make up for access to the source code.
Sarah Allen: Good GUI involves interaction design. You can't draw a picture or a flow chart of it. To know if it's going to work you have to prototype it or even fully implement some of it.
In the context of the discussion about UI programming, sticking with it is extremly important when doing UI development.
Put v1.0 out of the door. Listen to customer's feedback. Act on it. Add in a healthy dose of what you learned in the meantime. Put v2.0 out of the door. Listen to your customer's feedback. Act on it. Add in a healthy dose of what you learned in the meantime. Put v3.0 out of the door. Still with me? Keep on going. It just get's better.
Extending the discussion about why UI programming is hard, David Temkin comes up with a great post on the lost art of user interface programming.
I can't say enough good things about his post. His recapitulation of the influence the Web had on UI programming is a must-read.
The advent of the Web moved the emphasis plus the "coolness" to the backend. UI work was only considered cool because it was delivered in the HTML to a generic application called the browser. Coming up with a half-way decent UI required ridiculous amounts of coding (mostly in environments and languages which, uhm, were not on par with the tools used for desktop application development). In terms of user interaction, moving to HTML was like starting to focus on flintstones and spears again to provide for daily food. And despite all the hard work, you ended up with a UI which was a far cry from the rich interactivity users where experiencing on their desktop systems.
The advent of the web also killed some of the more interesting approaches to human-computer interaction like document-centric computing (witness OLE or OpenDoc). While there's a lot to say about the deficiencies of these approaches, they were off to a great start trying to put the GUI to the next level - but I'm getting off-track here, looks like this is material for another post.
On a related note, some of the now famous GoF patterns were widely used or even originated in the UI frameworks created the late 80's and early 90's.
It's great to see that companies like Lazlo are starting to come up with tools enabling developers to deliver a rich user-experience on top of the now omni-present network we all depend on in our daily work.
There is simply no substitute for sticking with a problem long enough to receive and process the feedback generated through customer use of your system - Luke Hohmann
While this citation was made in the context of becoming a software architect, the statement certainly holds up in a broader context: If you want to become a master in your craft, you got to stick with it for a long time. All Silicon Valley start-up-build-1.0-burn-out-fast-and-switch-jobs-guys repeat after me: ...for a long time...
I'm talking a significant amount of calendar years, folks. And make sure not to confuse "sticking with it" with "not learning new things".
The Secret Source of Google's Power (via another interesting post on Google (kottke.org))
Excellent post. Eye-opening on what Google has built and what Google will be able to accomplish if they stay on-track.
Here's a CAD weblog from the creators of upfront ezine.
A few pictures from our trip to Avoriaz, France.
Check out Eric M. Burke's post GUI Programming is Hard. In a related post, Rick Schaut talks about UI design. Both posts hit the nail right on the head and are considered a must-read. Yes, I'm talking to you, dear reader involved with SW development or SW sales.
Why is creating a great UI hard?
- Because it requires artistic/aesthetic skills most software developers don't have
If you're lucky enough, you will have a great UI designer or at least someone who has a great feel for how the UI should look (from an aesthics point of view) and feel (from an interaction point of view) - Preferrably someone who is also working very close with customers
- Because the tools used are not up to the task
As Rick Schaut says in his post, as soon as you start to go beyond the "put-a-few-edit-fields-checkboxes-and-buttons-on-a-form" UI, you are basically on your own. Most trivial example: I have yet to encounter a multi-column list box control which ships as part of a standard UI framework which can be easily extended without - all of a sudden - forcing the UI developer re-invent basic things like managing focus etc. And don't get me started on more complex interaction in forms/dialogs. Most likely, UI developers already have a very hard time coming up with an elegant, approachable UI for the applications problem domain. Being forced to re-create basic UI mechanismns doesn't help a lot.
And while I'm rambling along, I have yet to see how using XML to describe the UI will help tackling the problem.
Dave Temkin, CTO of Lazlo Systems started promising blog with a great Lazlo overview.
Lazlo is an XML-based development environment and deployment environment for building rich internet applications. Basically, the compiler outputs SWF-files.
It takes some time to get used to the verbose XML syntax, but it looks like a couple of major players are moving in the XML/UI direction, e.g. XAML within Longhorn or XUL in Mozilla.
However, I'm pretty sure that using XML for UI development won't change the basic premise: UI development is damn hard. I'm not talking "Hello World" type apps here, folks. I'm talking UIs for complex real-world applications.
How do we enable developers to create visually appealing, consistent UIs? How do we empower developers to extend the set of given UI controls in a consistent & straightforward manner? The latter is what all UI development environments/class libraries/frameworks etc. fail. But the latter is what UI developers are struggling with.
Using XML doesn't change anything.
Interesting project dealing with the integration of Outlook and Movable Type.
Not sure if I'm brave enough to install it. Like Don, I'm wondering if the build corruption issues have been addressed.
Here's a cool service for MacOS X third-party developers: Centralized online update & patch services for applications. Are there equivalent services for Windows?
Sure, there are security/privacy issues, but don't get me started on these topics...
While I'm at it, anybody knows about a Smalltalk-like code browser & editor for the Visual Studio environment? Uhm, no, I'm not talking about the classes view in the project window.
I had a nice meeting with a customer this morning - they are using Smalltalk (VisualWorks) to schedule the trains for a large part of Germany. That was neat; the system has some very nice graphical pieces with very fast zoom in/zoom out capabilities. That was cool.
[Smalltalk with Rants]Smalltalk is one of the best-kept secrets in the industry. I remember KHK working on a Smalltalk framework (X-Line) for business applications back in the early 90s. Third-party developers were expected to buy a source-code license and develop vertical-market applications based on the framework.
Using Smalltalk for this kind of project was a very bold move by KHK.
Of course, the project was a major failure. But the main reason for the failure wasn't Smalltalk's lack of capabilities, it was mismanagement and misjudgement of the markets needs and driving forces.
Uhm, plus, we shouldn't attribute delays in the German train systems to the use of Smalltalk in the scheduling application :-)
