So much for a nice meal - my wife's car had a flat, so I got to spend quality time with the jack. Joy. The meeting went pretty well - the customer I was meeting with looks like they will be expanding their use of VisualWorks. Always a good sign when the decision makers stay in the meeting, and the meeting goes for 90 minutes. So now I'm catching up on the day's mail and feeds...
I am off visiting a customer in Washington, DC this afternoon. I'll have more to post later
After a power outage a few days ago, I forgot to restart the application that generates the feed. Dohhhh!
Spotted in comp.lang.smalltalk:
We're planning on going to Java because it seems to have a larger community right now and because we just don't have anyone left that can program in Smalltalk.
Before committing youself to this plan, I recommmend sizing Dome (I'm sure Reinout or Bruce could give you rounded figures on no. of classes, no. of methods, and no. of statement and cascade lines, if you are not set up to get them yourself). Then compute how long the Java rewrite will take you by assuming only a sane number of lines of code per day written by whoever does it. Check this by getting a rough estimate of how many years of effort wrote it in the first place (find someone who was on the project, ask them how long and average team size, thence fudge up a guestimate), then multiply by three (it's slower to program in Java) and divide by your 'porting is easier than writing' fudge factor.
The above should take you very little time (there's no point in getting very accurate numbers as software metrics is a very imprecise science). If the two figures that result are
- within even very rough hailing distance of each other
- both way over any realistic budget the rewrite could ever have
then I recommend you stop even thinking about it (and, even more important, stop even talking about it as it will just block more sensible solutions). Instead, devote your limited budget to specifying what changes you want and posting them on Dome's pages. Invite people to convert the requirements into XP tests, agree their tests with you (good Smalltalk XP tests are very readable even by non-Smalltalkers) and thence solve them. It might happen even if you offer no money. It will happen if you offer money. It will be much cheaper than the rewrite even if the latter were feasible.
I think you should provide a parcel load of your vw7.0nc port as the first thing.
Just my 0.02p. HTH.
Yours faithfully Niall Ross
That's as good a summary on this topic as I've ever seen, and I've written about this before.
I had sent Scott an email, and got back a very nice response. I had only just added this support into the 2.8 dev stream, so I went ahead and posted a 2.7 patch last night that adds this to the shipping version. Bf should pick it right up; if not, here's a download link.
People wanting performance may want to ponder the stats on this page:
Table 1. Results of the benchmarking applications
Technology Connect time Send string (21,000 characters) Receive string (22,000 characters) Send 5,000 integers Client LOC Server LOC Actual message size sending 1,000 characters Actual message size sending 100 integers Raw sockets 0.002242 0.001377 0.001359 6.740674 57 25 2,279 85,863 CORBA 0.000734 0.004601 0.002188 1.523799 37 18 2,090 27,181 XML-RPC 0.007040 0.082755 0.050199 100.337219 29 17 4,026 324,989 SOAP 0.000610 0.294198 0.279341 1,324.296742 32 10 4,705 380,288
Making the RPC mechanism human readable sure has helped. snicker.
I saw this interesting post from Ted Leung's blog:
David Czarnecki states his reasons for not using a database to store blojsom's entries. Most of the reasons that he lists are quality of implementation issues in other blogs.
I have a different take. The reason that I liked blosxom's filesystem based approach is that ultimately, I view my blog as a part of my personal information infrastructure. And I want to be able to take that infrastructure with me wherever I go (especially after today's Centrino launch). The biggest problem that I have with using a regular SQL database is the disconnected operation problem. The blog has to be up and running on the web all the time. But I want to be able to work on entries on an airplane or on the ferry, and I want an easy way of synchronizing the web version and my private version. I'd rather not write a database synchronization package. So at the moment, the use of the blosxom filesystem seems to be the best that I can do. But the nasty mtime sorting is really a pain.
While I never gave it this level of thought before, this is why I've not moved this blog to a database. Setting up a test environment was vastly simpler - I just ftp all the files from the server - and I can have the whole thing on my notebook as well. With my offline posting tools, being able to post to an offline version of the blog is less relevant for me now, but still possible - and it makes for nifty demos.
One of the tricky aspects of API design, especially when designing the base APIs for a programming language, is deciding what goes in, and what stays out. Think of a string. There are an enormous number of things you can do with strings, but to put all of those operations on the String class would just be impractical and bloated. So as the designer, you take those operations that you feel would be most generally beneficial, such as finding the length, searching for and extracting substrings, and so on, and leave out the rest.
Some languages, such as Smalltalk, Objective-C, Ruby, Python, Perl, CLOS... Okay, a great many languages allow you to add behaviour to existing classes. So, for example, if your application really needs a method that reverses a string in-place and the language designer has decided that's not necessary for the supplied String class, you can add your method directly to the String class and be done with it.
Some languages, and this is where Java sits, don't let you do this. If you want to extend a class, you have to subclass it. And then you're stuck with whatever the superclass has made visible. And you can't do it with String anyway, because String is final. This is why most projects I work on end up having a StringUtil class, and every project ends up with a DateUtil. There are things we want to do to strings and dates all the time, but there's no way to put those things where they really belong, on the String and Date classes. Which is why having a Util class isn't a code-smell per se, it's a smell in the underlying language.
This is an area you can get into wonderfully interesting discussions on. IMNSHO, it is language smell when you can't slap code where it belongs. In VisualWorks, everyone always had their own version of CommonApplicationModel - subbed off of ApplicationModel. What that told me, as Product Manager, was that there were vast unmet needs in the current implementation.
That's what it always means
Internet News has a story making the complaint that MS' XML format in the upcoming version of Office will not be terribly interoperable:
Edwards said that Office 2003 beta's handling of the XML file format means that firms will not be able to tap the rich collaborative features of Open Office 2003 without resorting to proprietary Microsoft file formats. And to truly unlock its collaborative potential, firms will have to standardize on the Windows XP operating system (Office 2003 won't run on Windows 9x), as well as Windows 2003 Server, SharePoint Server, Exchange Server, etc. As for the file formats, he called Office 2003's XML "crippled," because it strips XML files of all presentation and formatting information when saving them in the XML file format. It does not do this when saving files in Microsoft's proprietary file formats.
"Although it's still early in the review process, it does look as though XP XML has been so seriously crippled as to be useless to anyone but the big content management and collaboration system providers," Edwards said. "Reports are that when saving to XML, [Office 2003] strips out the presentation and formatting information, leaving near raw content. It appears, at least from the non-enterprise systems user's perspective, that all the really cool collaborative advantages are based on saving files in the XP proprietary format. Which means that "all" the users in the collaborative effort must be on the XP platform, using XP Office, connecting through XP servers. What kind of universal connectivity and exchange is that? XP users won't even be able to collaborate equally with the 200 million Win9x users. Not unless they upgrade."
And why exactly is this a surprise? Regardless of what you think of MS vis-a-vis anti-trust - if you had the hold on the Office market that they have, what would possess you to make it easier on competing (and free) tools?
Eliot Miranda recently spoke at Stanford - a video feed of his talk is available. Check it out!
Here's a homework project. Go to the RSS Search engine. Now go to Google. Search for these words: "InfoPath" and "OneNote." What do you notice? I like the quality of the RSS results a LOT better
I think I understand why Google bought Pyra better now. Try doing a search for Smalltalk in both places as well - for fairly obvious reasons, I like the results better ;-)
Getting the replay tv hooked into the various a/v components was the usual holler fest - my wife and I reduced to jello before we got things working in something resembling the way we wanted. The stumbling block was audio going out of the TV. Instead of having to set the Receiver, VCR, and TV on separate inputs, we wanted to have the TV pumping audio back out from whatever it was tuned to.
This was harder than any reasonable person would want
The nicely labeled Audio out always took out whatever was coming in from the antenna/cable feed - regardless of what input it was tuned to. Arghhh! We had to shudder open the manual.
Sidebar - how is it that Sony has such brilliant folks building hardware, and then hires people with a minimal grasp of English to write the manuals? Would it be too much to ask to get an understandable manual?
Anyway, back to hell. The manual claimed that we could get what we wanted by plugging the jacks into the Audio out "var/fixed" plugs on the back of the TV. That was obvious (not).... and it didn't work, at least not right off. The "var/fixed" referred to the volume being pumped by the TV. For reasons not at all clear to me or my wife, setting it to "variable" on the TV silenced the audio output, while setting it to "fixed" gave us audio - but controllable only by the receiver's remote, and not the TV's remote. That led to some swearing. The TV and the receiver are the same frelling brand!
So this morning, I'm reading Ellen Goodman's column, since Instapundit referenced it. Now, I'm no luddite - I have a 100 Mbit house (wired) LAN, and an 11 Mbit wireless house LAN, two replays, and a number of computers on the LAN. But heck, there was a lot of common sense in that article. A lot of the electronics are getting too complex - maybe audiophiles understand it all, but I sure don't. My Living Room Receiver seems to constantly forget whether the CD input is analog or digital, and the readout on the blasted thing requires me to lie on the floor to read it!
There's a market opportunity for some vendor that makes a sharp break with current component plugs, and goes to something simpler, like a USB based interface whereby the receiver figures out what it's got plugged into it when it powers up. The current ugly proliferation of remotes and oddball cables can't be making anyone happy
I've learned at least as much this time around as the kids I've been working with. This looks like a good place to start next time around. Today, I'm going to use the EToys demo that is in Squeak, and then next week, try to come in with a new one. When I teach this class in the spring, this is the way I'm going to go about it.
The 80 hour replay is back and set up, with the new 51" widescreen TV. We are busy configuring it now. My wife's first word's when we got it back:
In my (limited) experience, nobody at a university has any clue as to what OOP really is about. In one "advanced" Java class, the professor once said that he had never been able to find a purpose for inheritance and that it would be best not to use it
Wow. And one of the stated reasons for going with Java is that the students come out of college already knowing it. Hmmm. Based on this, there's a reason for not using Java. And this is consistent with my interactions with Java people who did not start out in Smalltalk - there is very, very little understanding of OO principles. Not that inheritance can't be done badly; it quite often is, and deep inheritance trees are typically a danger sign. But look at that comment above - no discussion of pros/cons, no explanation as to why using composition is often better (see class List in VisualWorks, for instance) - just a flat No.
Take a look at this comment further down in the Lambda thread
I was about to make a snide comment along the lines of "How would you write a GUI toolkit in Java without using inheritance? Without subclassing you would need to add a hook interface for every imaginable behaviour of every component!"
Then I started to remember how Swing is written :-)
Later on in the thread we find this piece of brilliance:
Inheritance is the key to separation of interface and implementation, and hence polymorphism, in a statically typed OO language. This is perhaps the primary facet which separates languages like Java from "object-based" languages like VB.
Frankly, I don't know how projects of any significant size are accomplished using dynamically-typed languages, with their lack of interface inheritance
Translation: I've never worked in a dynamic language, so it can't possibly work. You have to love these people. This seems to be the pattern of learning going on in Java and C# - We know nothing about these other technologies, so they must be bad. Richard Gabriel had it about right in Worse is Better.
The more things change....
Blogs I would read a lot more often if only they pinged weblogs.com when they updated.....
Without pings, they languish at the bottom of my blogroll where I won't notice or visit them. My blogroll is my only mechanism for keeping track of the blogs that I read regularly - aggregators just don't do it for me, and with tabbed browsing my blogroll is almost as efficient for staying up to date.
Personally I don't check there - I use BottomFeeder to aggregate. My peeve is the lack of a good RSS Feed. Still, I took this point to heart - my habits aren't everyone's - and updated the blog to ping weblogs.com after each update. I'll have to look at blo.gs and see about pinging it as well....
Linux Today writes on Buffer Overflows:
"Buffer overflow problems always have been associated with security vulnerabilities. In the past, lots of security breaches have occurred due to buffer overflow. This article attempts to explain what buffer overflow is, how it can be exploited and what countermeasures can be taken to avoid it.
"Knowledge of C or any other high level language is essential to this discussion. Basic knowledge of process memory layout is useful, but not necessary. Also, all the discussions are based on Linux running on x86 platform. The basic concepts of buffer overflow, however, are the same no matter what platform and operating system is used..."
Here's a hot tip - use a better language. Those of use using better tools (Smalltalk, anyone?) don't have this problem. So long as developers choose to create tools in primitive languages, problems like this will persist. Time to leave the sharp sticks and pointy rocks behind guys.
Lots of people have been talking about this McDonalds WiFi experiement. Apparently, they are going to put in access points in a few cities, and offer an hour of free access if you buy a value meal.
I'm sure business travelers will like this; I would have loved such a thing when I was traveling more often. Still, McDonald's is not my ideal for hanging out and surfing. Starbucks seems much nicer, and has lots more power outlets. Not enough seating though. McDonalds, if they want this to work out, is going to have to install more access to power.
What I'd really like to see is places like Borders or Barnes and Noble doing this - they have comfortable seating, books, and coffee - just about perfect for this kind of niche. Unlike McDonalds - which mostly wants to shepard people in and out - those outfits are encouraging people to linger. What better way to do that than to offer WiFi?
I had someone complain about the fact that BottomFeeder always launched a new browser in Linux. I had no idea how to go about reusing an existing browser - but there were helpfule folks on the IRC channel, (thanks pete!) who lent a hand.
So now, in the latest dev build, you can launch a page from Bf and have it reuse an existing browser - so long as it's Netscape or Mozilla.
Next time someone says that Java is the answer, have them read this. Then show them your development cycle in Smalltalk.
No, I haven't finished laughing quite yet:
Interesting thread at TSS about 'edit/compile/debug/startup cycle for people on various J2EE projects'.
I'm pretty much sure that any VS.Net user will laugh at us seeing all these wasted minutes and seconds on silly compile/deploy cycles. Ant and Maven are a solution to a problem: treating software development like a factory line consisting of many steps which can be automated. The problem is with all these steps and complexity of each step we end up struggling with a giant slow build process.
The solutions offered look awfully complex to this Smalltalker...
Matt Croyden spotted something interesting:
Here's the MSDN article. I'm not sure if the final version of Office 2003 will be as ugly as these screenshots, but I hope not. It looks like the Easter Bunny got in a fight with Office 2003 and Office 2003 lost.
Seems you can integrate things like Google's web services (just like I did in BottomFeeder - the picture is amusing.
Have a look here for the up to date roadmap presentation.
The Fuzzy Blog writes on vendor/consultant squeezing in the IT sector, and how it's going to hurt:
From the Wall Street Journal:Mr. Kheradpir Puts the Squeeze on Tech For clues to the tech sector's failure to revive sagging sales, pay a visit to Shaygan Kheradpir. Verizon's chief information officer relentlessly pushes his charges to get more out of less equipment, an attitude that spells gloom for tech giants.
The article is excellent and a wake up call I suspect for a lot of us. This is very similar to what I wrote recently about all vendors getting squeezed in the down economy
this is not surprising to me. I've been saying that the outsourcing trend is nothing new either - it went through manufacturing like a scythe as back when I was in high school (anyone remember the movie "Mr. Mom"?)
What's new is things like outsourcing and cost cutting hitting IT. In a very real sense, it's a sign that the industry is growing up - customers are starting to hold us accountable. This also went through manufacturing - see this story on GM and GE cost cutting around suppliers.
John Lam makes some interesting observations about test-first as it relates to GUI development:
I've been spending a fair amount of time recently writing GUI rendering code. I've also been spending a fair amount of time recently grappling with unfamiliar API's. These experiences have revealed two areas where test-first development doesn't quite work:
- GUI rendering code where "correctness" is determined by how something must look
- Early stage implementation where interface churn is the norm
The first case encompasses virtually all of GUI development, regardless of whether your GUI is an HTML page or a traditional Windows application. In these cases, whether or not something is "correct" depends on how an object appears. Unfortunately, there are usually several different ways to render the object, all of which yield correct results. Furthermore, it's really hard to determine how an object is rendered programmatically, whereas it is usually quite simple for a human to determine if an object looks "correct".
Yeah, I can definitely see that. A lot of the GUI is subjective rather objective. A test can tell you conclusively whether or not a transaction happened - it can't tell you whether the foreground and background colors are frelled. Ultimately, you're going to have to do some human factors work.
Gordon Weaklien writes:
Jon Udell is right. The problem with writing for the web isn't that there are no editors, the problem is that your editors speak up only after you've stuck your foot in your mouth, as I just did when I labeled scope and polymorphism as design patterns
Yep. The Test comes first, then the lesson....
The talk went pretty well - I didn't get to meet Matt Croyden, local blogger - maybe next time. The presentation was fairly well received, and generated a good conversation - lots of good points and questions. The upshot of the conversation seemed to be that there are cultures surrounding the various programming camps, and that the culture surrounding Smalltalk encourages frequent testing - more so than the C language family. IMHO, this is due to the fact that in C , Java, C# (et. al.), you spend a fair bit of time just trying to make the compiler happy - a situation that simply does not come up in Smalltalk. All by itself, that explains a lot of the differences.
I think I got most of my points across, and had a good exchange of ideas with the group.
I handed out a few NC CD's - I should have had more. Of course, people can always follow the download links. Afterwards, we headed out to a local watering hole for some more conversation. All in all, it was a very pleasant time.
There were a few more updating issues with the new HTTP code, which I think I've addressed. In the process, I ran across some oddball XML parsing barfs; there are a handful of feeds I follow that currently have bad XML - unclosed HTML tags, invalid characters. The landscape for well formed XML isn't getting any better...
I'm uploading a new dev build. I've also slapped up the new parcels for the upgrade manager. It seems that in the transition to the new HTTP access I split out, I broke the handling of gzip decoding. That's now handled.
Just a reminder that I will be speaking at the XP DC Group tomorrow night. Follow the link for details.
Just a reminder that I will be speaking at the XP DC Group tomorrow night. Follow the link for details.
"Sun is waisting no time taking advantage of the SCO lawsuit against IBM. They are making statements trying to play up Solaris as a safe harbor for worried Linux and IBM users. John Loiacono, VP of Sun's operating platforms group, "For people looking at the issues at hand, we are a safe harbor. We have absolute rights to our technology ... We're changing our strategy around Linux (but) we're pausing because we're trying to figure out what the implications of this are going to be". So, this begs the questions... What are the short term implications for the new Linux based desktop we've been hearing about from our fair weather friends? How will the SCO lawsuit affect Sun's long term strategy with Linux and Open Source?"
So how does this all play out? The smart thinking seems to be that SCO wants to be bought. In the meantime, it could make for some entertaining industry watching from the cheap seats....
After this post, I had it pointed out to me that mailto: links in BottomFeeder (and Twoflower) did not work. They do now. On Windows, the mail tool associated with mailto: links will be spun up. On other platforms, a mail window will open, allowing the user to send mail to the recipient specified in the link.
This is an interesting post. apparently, the way Java installs, the JVM optimized for client usage (rather than server) is the default:
Amazing, then, isn't it, that most default installations of Java-based (as opposed to native-code implementations) J2EE containers don't make use of the VM tuned specifically for long-running server operations?
To fix this, if you can get at the command-line used to invoke the JVM, add the "-server" option into the command line parameters. If this is somehow hidden away from you, simply rearrange the options found in the jvm.cfg file in the JDK to list the "server" option first. Bear in mind, however, the comment at the top of the jvm.cfg file: this file format is subject to change and may use a different mechanism sometime in the future. (Case in point: the JDK 1.3 mechanism didn't make use of the keywords following each entry-KNOWN, ALIAS, and so forth.) Future J2SDK releases may change this mechanism, so be prepared to do a little spelunking when J2SDK 1.5 is released.
Now sure, it's easy enough to deploy VW servers badly - deploy an image without mucking about in MemoryPolicy and ObjectMemory, and you'll eventually get bitten. I guess what I'm curious about is, how many people even know about these sorts of server tuning, without regard to development tools?
I've posted a new screen shot of BottomFeeder. It occurred to me that the old shot was getting long in the tooth....
So some folks in Java land are figuring out that versioning issues might require shipping a custom runtime:
Ted has a post detailing how to use a private JRE install for a java based app to side step versioning issues. This is great stuff, I used Ted's earlier white paper on the subject to do a private JVM on a current project. If you're a Java guy you need to be reading Ted's blog.
While I understand what the motivation is, doesn't this minimize the "it's standard, it's everywhere!" argument for Java? I can build faster in Smalltalk, and ship a custom runtime (smaller as well). So where's the advantage?
After the refactoring I did, testing continued to show regressions here and there. Not a big surprise. I think I've got all of them fixed though; testing hasn't turned up any new problems.
The bottom line is, I think the 2.8 BottomFeeder release looks good for synching up with the VW 7.1 release. When VW goes gold, I'll package a new image, and push Bf. The objective now is to not have to do a new base image build after that until VW 7.2 ships.
There will be some new goodies shipping with 7.1:
- Twoflower - Holger's vW based browser, which we use in BottomFeeder
- BottomFeeder - this will be shipping with the product as a goodie
- CST Blog System - the code that powers this blog will be available for your perusal as well
I've slapped together a brief "How-To" on the blog as well, which should ship on the CD. It's not full doc by any stretch of the imagination, but it should be enough to get interested parties going.
Here's an interesting article:
Here's what it isn't:
- The Internet isn't complicated
- The Internet isn't a thing. It's an agreement.
- The Internet is stupid.
- Adding value to the Internet lowers its value.
- All the Internet's value grows on its edges.
- Money moves to the suburbs.
- The end of the world? Nah, the world of ends.
- The Internet's three virtues:
- No one owns it
- Everyone can use it
- Anyone can improve it
If the Internet is so simple, why have so many been so boneheaded about it? Some mistakes we can stop making already
and here's what it is:
All we need to do is pay attention to what the Internet really is. It's not hard. The Net isn't rocket science. It isn't even 6th grade science fair, when you get right down to it. We can end the tragedy of Repetitive Mistake Syndrome in our lifetimes - and save a few trillion dollars worth of dumb decisions - if we can just remember one simple fact: the Net is a world of ends. You're at one end, and everybody and everything else are at the other ends.
Go read the whole article - there's a lot more
I finally decided that the Http access code in BottomFeeder was too spread out and hard to understand. So with the aid of the RB, I refactored it. I already had an HttpClientModel class I had built awhile ago to centralize such access, but I had not been using it. This morning I changed that - I was able to get rid of bunches of duplicated code, and shove all the app's requests through a simple API. Made it a lot easier to toggle between straight requests and conditional-gets. The nice part is, it made the Http access work better - the duplicated code was slightly different in variosu places, and now it's all far easier to work with.