Gordon Mohr explains why one should never attribute to conspiracy what can be more easily explained by imcompetence or sloppiness....
SCO is making an effort to completely discredit the GPL. Looks like the test in court that some people have wanted for the GPL is increasingly likely to take place.
The CST Online Tutorials have changed urls a few times over the last couple of years - I've posted the link above in response to some questions about where they are. In response to a site redesign by Cincom marketing, it's likely that the Smalltalk pages will be moved again in the near future - the main page link will work - but it's probable that the internal links will be rearranged. To get to the online tutorials:
- start at the main page
- Select the Education link on the left bar
- Select Online Tutorials, which should show up under Education after you select it
Here's an interesting story on the variance in internet usage (men and women) in different regions of the world. The author has an interesting theory on how the 'market size' of language usage affects community building.
Peter de Jager has some interesting thoughts on how adaptations for scarcity (both human and technological) backfire when the norm switches from scarcity to abundance:
Anyone considering a new technology should at least ask the question: "What are the long term consequences if this advance reduces costs to zero, or increases access so that everyone with a desire to do so, can use the technology?" That might seem to be a giant 'societal' question of value only to economists and city planners, but it has applications closer to home.
I'll have to think about this one. He makes some interesting points.
ok, this was just bizarre. I had to run my daughter out to dance class - before I left, the mouse wheel wasn't working with BottomFeeder. I figured I must have somehow broken something, and decided to just leave it while I was out. 2 hours later, I get back. I get the login screen - keyboard doesn't work. Ok, maybe the USB cable is loose. No dice. Try the laptop's basic keyboard - still no response. Ok, this is now really weird. I can't login; fortunately, I can shutdown from the login screen. A reboot clears the problem. So my question is, what the heck was it? Do I have some virus/worm that got through my firewall? Did my machine overheat and stop something from working right? Did XP just have a senior moment? Is this some bad side effect from the last Windows Update? I have no idea....
Windley has some excellent advice for anyone looking to promote blogging within an organization. The primary one:
Don't do it if you're not prepared, as an organization, to speak the truth. Blogging promotes, but also requires to some extent, a culture of candor.
That's really, really important, IMHO - and it's one of the reasons that I'm totally unimpressed with the campaign blogs of the various presidential candidates - they are all nothing more than blow dry marketing exercises. Part of the appeal of blogs for readers is getting a much less filtered view of a person and/or an organization. If you can't handle opening up that way, then you probably shouldn't bother.
Peter Drayton writes about an interesting event at the MS PDC:
Larry O'Brien's Alternate Programming Languages BOF is happening later tonight. There was some scheduling confusion, in case anyone is wondering where/when: it's at 11pm tonight in room 406AB. Here's the BOF abstract:
C# is super and VB .NET is invaluable, but it's been argued that the greatest benefit of .NET is the level field it provides for programming languages both familiar and exotic. This session brings together language enthusiasts and implementers in a casual atmosphere to discuss and demonstrate both existing languages and works-in-progress. Does the runtime help or hinder particular programming types? Is anyone using alternate languages in production? And, is it possible for us to perform an impromptu interop-a-thon: F# -> Eiffel -> Haskell -> Python -> Fortran -> Smalltalk -> ... ?
If you're at the show, see if Smalltalk gets a mention.
I'm not sure I like the way that the new sblog is set up. In particular, have a look at the feed. That's a link that immediately issues a 302 to a relative url. I'm not sure that's a great idea; nevertheless, the fact that it wasn't working in BottomFeeder was a bug which I just fixed (in the dev stream). The problem was - I wasn't expecting relative urls in the redirect (which is a bug). That's fixed; you should be able to deal with SBlog feeds now (or any other feed that issues a 302 and redirects to a relative url)
Update: - as you'll see in the comments, the lack of links in the feed is an "out of time" issue, not something silly. So what I wrote below just makes me look bad. Oh well... removing foot from mouth...
I have another issue with the SBlog feeds though - there are no link items - either for the feed itself, or for the items. Now, I understand the whole idealogical position of "HREF Considered Harmful". That's all fine and good, but it clashes with the expected usage of the web and of blogs. Those feed elements really, really need links....
There are a few things to iron out before I can release 3.2 of BottomFeeder - but I've also started the transition to VW 7.2. That's going to be released in November, and it will require a new BottomFeeder runtime - so while I'm at it, I figured I'd clean up a few other issues. There are some packages I've decided to split out and make loadable at startup - mostly so that they can be more easily updated by end users. I've got the basics of that in order. I've also got most of the 3.2 issues ironed - the only possible worry is the new "new in tree" view, which I've gotten some reports of trouble on. I'll be looking at that and trying to reproduce.
So here's a post on LongHorn, replete with the now obligatory "It's better than Mac" yelling. In the middle of the post is something I found amusing, and kind of sad:
Speaking of Allchin, you've not lived until you've watched a group vice-president (Allchin owns Platforms, which means that he has ultimate responsibility for what goes into Windows - what you'd expect to be a fairly PHB role) go head to head with Don Box on the latter's preference for emacs (Allchin's apparently a vi man) and then write code live on stage in front of seven thousand geeks and a worldwide audience. Oh, and argue variable naming conventions too. Either a) the guy's been drilled to within an inch of his life or b) he's a quick re-learner (or, even more scary, c) he's more competent than about 50% of the dreck that wears the "Software Developer" badge)
So - to write code, neither of these people use MS tools (like, say - VS, or even an MS text editor)? They stood in front of an audience and made the implicit point that either Emacs or VI are better for code development than MS tools are. That, to me, is a marketing blunder of the first order. Wonder if anyone else picked up on it....
InfoWorld TechWatch has an interesting take on RSS - it's reached maturity with the tech crowd, while "corporate" still isn't using it much. I can attest to that - the Smalltalk engineering group here at Cincom uses RSS, blogs, and aggregators quite a bit - but our marketing group is still trying to wrap their heads around the idea. It's going to be catch up for awhile at that level, I think
Ted Leung has a suggested Python project - creating an automated type annotater for Python programs - the stated goal being to provide a tool that could be used on Python files to give some confidence that type unsafe operations were not going to happen. IMHO, there's a better goal for that kind of thing, and it's something we see the need for in Smalltalk - communication with external systems. Whether we think it's a good idea or not, the majority of the non-Smalltalk development world is manifestly typed. In particular, the popular RPC mechanisms - CORBA, SOAP, RMI, DCOM - all expect manifest type information. What that means for a Smalltalker (or Python developer) is a need to annotate the interface - IDL, WSDL, etc. Having something that reliably inferred types for the purpose of generating those interop specs would be highly useful - and, IMHO, far more valuable than any other output. A good set of tests proves more about correctness IMHO.
The Register reports that there are emerging issues with outsourcing in India:
India's business process outsourcing market is expanding rapidly, but cracks are beginning to show. Concern is growing over a tightening supply of skilled IT workers, and a high rate of attrition among workers in the sector, particularly in offshore call centers.
So - demand for these jobs is up - which tightens supply, makes people move between jobs more quickly - and raises costs. Not a terribly big surprise - Silicon Valley watched that progression in a big way during the late 90's, and it's simply repeating itself in India. Watch for costs to rise enough that over the next few years - given the inherent overhead of outsourcing - savings will pretty much evaporate in India. That will drive the business elsewhere, but:
- English language skills aren't as prevalent elsewhere as they are in India
- The problems brought up in this article are going to repeat no matter where the outsourcing goes
Basically, the savings associated with outsourcing are going to be a pretty short lived phenomenon.
I saw this news yesterday - Microsoft laid this guy off because of a picture he posted to his blog. The issue seems to be security - MS is a large company with a number of enemies, and they have policies dealing with physical plant security - i.e., no photos. This photo seems pretty inocuous, but it also looks like they were simply following policy. It's another thing you have to be careful about in corporate blogging - bottom line, you kind of need to imagine that everything you write is actually a phone call at corporate headquarters - and ask yourself whether such a phone call would be appropriate.
Tests are fine, but - If your test sucks, it proves nothing. That's what I took away from this afternoon's little discovery. I had not been able to reproduce the reported problems with the all new in tree view for Bf - and it was the sample feed setup (the test) that was wrong. My tests weren't deeply nested enough to show me that I simply wasn't following the tree nodes down all the way - and thus, missing some of the nodes. Having fixed that, the view now works as expected. That gets me a step closer to allowing 3.2 out the door - it was the last known issue.
Post 3.2, the code will switch to VW 7.2 - and a new runtime. With a new runtime, I'm breaking the system into more loadable components, so that updates are less monolithic. I'm also going to start looking into a way to save/load the feeds and feed info faster.
Supporting the new in tree view in BottomFeeder, I had to get the tree widget - the one holding the feeds and folders - to dynamically change based on attributes of the contained items. As it turns out, the tree widget already supports that quite easily - Have a look at class TreeModel. From the class comment:
childrenBlock: block with one argument. Is evaluated to get an object's children. The result is expected to be a SequenceableCollection. Defaults to: [:ea | ea children].
So the childrenBlock is what determines what the tree shows. Change the block, and you change the items displayed. In my case, I simply had to add query methods to the folder and feed objects. These methods look like this:
RSSFeed>>displayChildren "custom display of items" ^#() RSSFolder>>displayChildren "custom display of items" ^self children select: [:each | each hasUnreadItems]
Feeds have no children; they are nodes. Folders, on the other hand have to be tested. The #hasUnreadItems method actually does the work of drilling all the way to the bottom of a given folder, in search of unread items. The main point is though - in order to change the way the tree displays, all I had to do is send this message in response to a user request:
self feedTree list childrenBlock: [:each | each displayChildren]. which replaces the default block of: self feedTree list childrenBlock: [:each | each children]
And that's all there is to it. Modify the block that determines children to display, and create any necessary support protocol in the objects you put in the tree. I had been resisting looking at this, as I somehow convinced myself that doing this would be hard. I got constant prodding from Micahel Lucas-Smith though, and - as a result - got a new feature added to BottomFeeder
Here's a perennial favorite in VisualWorks: You have a dataset widget, and you would like to dynamically add a column at runtime. How do you do that? Well, there's been a support tip on this for years - and I made use of that tip in BottomFeeder. The all new view has 2 modes:
- Show a restricted tree, with only the new items
- Show all new items in a 2 pane (no tree) view
For the latter view, we add a column (with the feed name) to the dataset, so that you can tell where the item in question came from. So how is that accomplished? Here's the relevant code snippet:
table := self widgetAt: #feedListID. columns := table columnDescriptors asOrderedCollection. columnSpec := self class zoomedColumnSpec decodeAsLiteralArray. columns addFirst: (columnSpec columnWithBuilder: self currentBuilder). table setColumnDescriptors: columns. table invalidate. self hasAddedColumn: true
The spec is the spec for a single column - I extracted a column spec (copy) from a dataset spec, changed the attributes to match what I wanted, then saved the result as a class method. Then, at runtime, I can grab that spec object, and just slam it into the dataset. It can be removed just as easily. That's it!
Michael Wallent in this morning's Longhorn UI panel: "We want to make existing applications look like DOS applications when they run on Longhorn."
His point was actually that Longhorn applications will exhibit not just different visual style but different behaviour. It is not a matter of applying Avalon chrome to an existing application. The actual interaction must change to fit the Longhorn Way. That means WinFS integration, shell visualisations and so on.
Hey - what if Windows isn't the only platform I care about?
Michael Lucas-Smith is not amused by the things MS calls refactoring.
Presidential Candidate Howard Dean gets carried away - literally :)
We are throwing a Halloween party this evening, so we are deep into party prep. Happy Halloween all!
Java Today has an article on rolling your own vs. buy - an old argument, actually. The "Huh" part for me came here:
He changes the too frequent parsing of the feed that he described in his first article by adding "a new class to handle the selective updating of feeds based on the provided update information." In the second half he creates a blog roll using " the JSTLforEach tag to loop through the feeds, creating a list of links to the home pages for the feeds. For good measure, we also print the dates of the feeds, so we can see when each one was last updated."
Huh? Why would I be parsing xml when I create a feed? I have an actual object model here - the blog entries are all objects - I push a static xml file out whenever there are new entries/updates/comments, and have the server create XML from the objects using a Sax driver. Having the static feed files reduces load on the server as well. As to update times, well - that's part of the object model I created for the entry objects. As to the blogroll, that's a list of what I read on a normal basis (i.e., created by hand) - not a list of things I happened to link to....
If you get asked "What's a weblog?", then read this. I'll have to consider my answer to that question sometime, but the post I linked to is a great summary.
Heh. KIds come to my door:
Them: Trick or Treat!
Me: We'll take the trick
Me: What, no trick? I'll have to take all your candy
Funniest response to that yet? One kid yelled No! and ran off. Yes, I do give them candy after the exchange :)
What do you want, I'm wearing a jester outfit this year...
BottomFeeder has had an issue with images overlaying text. Basically, the support in the html component we use for tags with layout information embedded is somewhat limited. I found a work-artound for this issue yesterday, and images should no longer show up on top of text in the item pane - which makes things much nicer. I should have looked into this long ago....
Doc Searls puts his finger right on it - the things that keep the RIAA up nights:
Just 'cuz it's new water doesn't mean you can't learn how to swim in it. In fact, the networked world is one where you get to make your own water. The big industries aren't in charge here, much as they like to think they are, or should be. This is the People's Market. Nothing communist about it, either; because the Networked World loves to support markets, commerce, transaction, conversation, relationship, opportunity, enterprise and fun - all those qualities that make real markets the real cradle of real civilization.
In fact, this is the chance that artists finally get to make markets the way they'd like. To love business, even. Trust me, you can do it.
Cutting out the layers of separation between producers and consumers is what scares the crap about the RIAA - the rest is all just sturm and dang in concealment of that baseline fear.
The .NET guy is protecting his blog from comment spam - so far, I think I'm protected mostly by obscurity. Entropy seems to be increasing in the blog world, just like everywhere else...
Spotted in StronglyTyped - you can build PacMan in it! Who knew Excel was a game platform?
I've just released BottomFeeder 3.2. A summary of what's new:
- Proper handling of Http Moved responses. 301 is followed, with links updated. 302 is followed, but links are not updated
- With 301/302 responses, relative urls are now supported
- Added filtering of feed items. Users can filter on title/category/content, and do so at a global level or on an individual feed level. Filters at the feed level override any global filter
- The 'New' view can show the 2 pane view, or show a tree that is restricted to feeds with new items (and folders that contain such feeds)
- Added support for defining Amazon search feeds. This uses the Amazon API for defining RSS enabled queries
- OPML feedlists are more properly supported; in previous versions, the defined OPML directory structure was not followed. It is now
- Instead of proxy settings being off when the server name is deleted, there is a checkbox in settings for turning proxy support on and off
- Updated the Http access to properly handle proxy responses of 100 Continue
- When Feed Auto-Discovery fails, we return a more useful error message
- Fixed some inconsistencies in menu items that were enabled/disabled based on the online state of the app
- Added an optional ability to track timeouts on feeds across multiple updates, and mark a feed as 'bad' if it failed too many times
- If updates fail on 10% or more of the feeds in a row, the user will be prompted as to the online state (unless the setting is turned off)
- A new, updated version of TypeLess ships with this version of BottomFeeder
- Addressed the problem whereby images in the html view sometimes overlaid text.
There's a lot of new stuff, and a lot of improvements to what was already there. The upgrade tool can be used; no need to re-install.
Charles Miller contributes his 2c on what a weblog is. Quicktime required to read the presentation.
I've ignored Enclosures for about a year now. With 3.2 of Bf just shipped, I figured I'd have a look at them again. I added simple support for enclosures this evening. What does that mean? It means that, if an item has an enclosure, then you'll see a clickable link in the item pane. I decided against the whole background/overnight downloading thing for a couple of reasons
- available bandwidth
I think most people using an aggregator, at least at this point, are on a high speed connection - so the time savings for downloading overnight are vanishingly small. Additionally, I didn't really want to have an extra (easily forgettable by users) directory of large content that would build up - building the software infrastructure for managing that just doesn't seem reasonable to me at the moment. Heck, maybe I'm wrong - if I am, Bf users will tell me. In the meantime, just providing a link to the content in the item pane is the simplest thing that could possibly work
Ole Eichorn is not excited about LongHorn:
If you're still reading and haven't clicked your back button in disgust, let me explain. The most important thing is not how easy it is to build code, the most important thing is how well the code runs once it is built. This concept seems to have escaped the Longhorn developers, and from this viewpoint Longhorn and its underlying technologies are pretty unexciting.
Ole goes into quite a bit of depth as to how and why performance will suffer in LongHorn - along the way, he makes a number of interesting observations - one of which I disagree strongly with:
I can appreciate that there may be debug code and features which haven't yet been optimized, but performance isn't something you add in later. It has to be designed in from the start. There were zero cases where I heard a presenter at the PDC say "this was done for performance". Functionality for developers was the guiding design principle.
Uh, no. The mantra is:
- Make it work
- Make it fast
In that order. In that regard, MS might even be approaching things the right way (although I have my doubts about their ability to get there). I suspect that this thought comes from Ole being a C++ developer - C++ being a language that is painful to refactor and introduce change into. Using better languages, one can rip out layers that cause problems and replace them (I've done this with parts of BottomFeeder all along, for instance).
- Opentalk for ObjectStudio - We are delivering this in preview (beta) for this release, with full support in the next cycle. This allows object to object communication between VW and OS; OS developers can take advantage of VW features like Web Services, Web Toolkit (etc) - and VW developers can ship a fully native Windows GUI - all with full object level communications back to the main application
- Better searching in VW - it seems like a small thing, but a type ahead matcher in senders/implementors/find class/Store makes for a much nicer development experience.
- Better scalability in VW web applications - a lot of R&D has gone into creating a more scalable application server
- VM plugin support - the Squeak plugin system has been ported to VisualWorks. This will allow for easier integration of platform services
- Beta Support for WinCE - we have started adding support for small devices to VW - and, unlike Java and .NET - not with a cut down library
- Beta Support for dotNET Connect for VW - Conceptually similar to DLLCC, allows you to connect VW applications directly to the .NET runtime
There's a lot of other new stuff as well - check out the summary page. We should be shipping the new VW and OS versions later this month. Stay tuned!
Getting started in VW is likely easier than this - after you get it downloaded and installed. None of this:
First question: "what's a PATH"? I indulged in a brief description of command processing shells. This only led to obvious follow up questions which quickly forced me to confront the fact that, despite ten years of experience with computers, this teenager had never spent any time typing commands at the DOS shell. That's because he never needed to. Returning to the key question of how exactly to "add Java to your PATH" I was greatly relieved to find out that my student had already found a likely looking chat forum, asked about doing this, and within a few minutes recieved the proper incantations. Which was a good thing, since my memory of hacking the DOS PATH has me struggling to edit a long line of crytpic text through a small window in some kind of shell environment editor dialog mess. For the last N years I've been using Cygwin and bash and although that's more familiar to me, I'd hate to have to try and convince a teenager of its charms.
As fate would have it, the fun was only beginning. Our Java programming book began with the legendary "Hello World" example. Creating the text in WordPad was easy enough, but where to put the file? No, not in the C:\J2DSK Folder (what's Java doing there anyway?), and not at the top level in the "My Documents" folder. I advised creating a HelloWorld subfolder for the app. More confusion about getting the "Command Prompt" started in the correct working directory and then (finally) typing:> javac helloworld javac: invalid flag: helloworld
With hands waving I explain that javac isn't going to just guess that the file you're referring to is "HelloWorld.java". Software that can't be relied upon to DTRT isn't common in the teenage world of game consoles and web sites and chat clients; but we persevered. Sadly, it feels like climbing up a steep hill with a backpack. And the backpack just got heavier.
heh. VW - in a workspace, type: Transcript show: 'Hello World'. Highlight with the mouse, pick 'Do it' from the pop up menu. Yes, there are issues with getting started in Smalltalk
- The download/install experience needs work
- You can get buried in the blizzard of classes
However, the latter is true if Java as well, and the former - we are working on. In the meantime, we don't have the arcana seen above...
I've been talking to a BottomFeeder user in the Smalltalk IRC Channel, and the issue of figuring out what version of a plugin he had loaded came up. Bf didn't report that info until about 20 minutes ago, and now it does (assuming you grabbed the update). Seeing this, the following comment flew by in the IRC:
Oh, this is just too great: "[13:47]
anyway to have the runtime show its loaded version number?" ... "[14:08] User - grab the update.. it will show plugin version info in the about box"
Now that's the power of Smalltalk in action...
Tim Bray clearly hasn't seen enough people swearing at web based email apps. And when he says people only prefer rich clients for content crteation - what the heck does he think most non-techies do all day, anyway? They create content, using word processors and/or spreadsheets, for the most part. Sheesh.
Steve Maine shows how to "reverse" a dictionary (make keys the values, and vice versa) in C#. It takes about a page of code. The Smalltalk?
dict associations do: [:each | dict at: each value put: each key. dict removeKey: each key].
It's kind of sad watching the curly brace crowd produce a page of code and call it a major leap forward....
Scoble is excited about using a GPU for Longhorn. Meanwhile, say I wanted to run a server. Value to me: Zip. On the other hand, I could likely run a server using Linux or FreeBSD on an old Pentium.
This story has an interesting case study of the development of a web app. The developers ended up going with Lisp rather than Java for productivity reasons - based on their evaluation, they would have done as well with Smalltalk. Take a look - here's an interesting snippet:
As software developers we had the most experience building web applications using Java technology. In the Java world you find all the necessary tools, frameworks, libraries and servers to build almost anything. Java is very good at absorbing all the great abstractions like object technology, garbage collection, model-view-controller, layered systems. However, the Java world is becoming very large and complex. And all things touched by Java (especially the J2EE part) have a tendancy to become overly verbose and cumbersome. This is partly because of limitations in the Java language itself (full static typing, no interactive or dynamic modifications at runtime, little room for data driven programming) and partly it is a community thing (standards reached by consensus and political motivations).
Because we had a past exposure to both Lisp and Smalltalk, we knew that there were very good alternatives to Java. Thanks to Java, a type-safe runtime with automatic memory management and garbage collection became accepted both on the client and server side. People now know that the small price in performance is dwarfed by the advantages in productivity. Lisp and Smalltalk easily match Java feature-wise, but add full dynamic typing, allow interactive and dynamic modifications at runtime and allow for much easier data driven programming. The best part is that current Lisp and Smalltalk implementations often consume less memory and run faster than Java.
The bottom line - if you build the same way as everyone else, the liklihood of your gaining an advantage over the competition is very slim. If, on the other hand, you are willing to look at alternatives - and gain productivity in the process - you have a decent shot at getting a leg up.
Paul Graham shares some words of wisdom about software development:
For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.