A BottomFeeder user ran across some oddness today - when auto-browsing items in a feed, he noticed that it worked on Windows, and broke on Linux. This was puzzling. We dove into the bowels of the request and socket response, and found out that in this case, the server was inaccurate in telling us how large the response was. For some reason, the Windows low level facilities cleaned this up, while it just barfed (and gave us a timeout error!) on Linux. It looks like there's a server problem there, but also some issues with the VW code. In the meantime, we discovered that turning keep-alive off for the request solved the problem. Having it off is likely the best thing in Bf anyway, since I'm not doing persistent connections...
Via the Sharktank:
Newly hired programmer pilot fish at this small insurance company can't help noticing the behavior of his programmer co-worker. Not only does the co-worker keep odd hours; he often doesn't show up for work at all. Result: Co-worker has a project that looks like it will take twice as long as it should to complete. Why is he allowed to get away with this? baffled fish asks boss. "He's not," boss says. "I've told him that as soon as he's finished with the project he's working on, he's fired."
Frank Hayes of ComputerWorld makes a few good points about the commoditization that is happening in the IT sector:
It's a matter of supply and demand. There are lots of programmers out there -- and with offshoring, "out there" gets bigger every day. With that much supply, programming skills can't command the extra money they once did. They're a commodity, and they're likely to keep getting cheaper.
If you're a programmer, that should make you worried.
If you're an IT manager, you should be worried, too. On the one hand, you can't afford to keep a lot of expensive commodity programmers on staff. On the other, some of those programmers know your systems -- and your business -- intimately. And that knowledge can make a huge difference in the business value your IT shop can deliver. It's an asset you can ill afford to lose.
I have some doubts about offshore development - unlike manufacturing, we don't really have well understood best practices - and it seems to me that offshoring could easily lead us back to the old "Ivory Tower" days, where business throws requirements over the wall, and N months later, the offshore staff throws an application back. With the communication difficulties imposed by timezone and culture, I rather suspect that this is a floater left in the offshoring pool that no one is talking about (yet). On the other hand, since local IT staff have been so lousy at delivering quality in a timely fashion, non-IT management may not notice - to their mind, it sucked before, so what if it sucks after? At least the suckage comes at a lower cost. The interesting part of Hayes' article comes later:
That means it's time to start redefining your programmers.
Not just renaming them all as "analysts," or prettying up their job descriptions with businessy jargon. But actually redefining what they do in the context of your business organization.
You can't afford programmers who are just good at writing code. What you want your programmers to do is to understand your business processes -- and how to use software to automate, streamline and even revolutionize those processes
That's a good point, and an excellent recommendation. There's a simple issue though - it assumes that the CIO is on board with the idea. In my experience, lots and lots of CIOs are very disconnected from business reality. They are off worrying over trivia that has nothing to do with what the business actually does. Before you can have an IT staff full of business analysts, you have to have a CIO that is a business analyst. How many outfits have that?
Scoble points to this set of articles on computers and schools. Now, I don't know whether computers are directly causing problems (as argued here) - but I do know this - an astonishing number of students cannot perform basic arithmetic tasks. Watch the fun in any store when the computers and registers go offline - it's a test to see if anyone can calculate bills, and most clerks seem to fail it. What I'd really like to see is a lot more time spent on basics. My wife and I had to drill our daughter ourselves - they simply weren't doing that at all in our supposedly "great" suburban school. Interestingly, the instruction (at least locally) in reading and writing skills seems pretty good - they stress that stuff a lot, and it shows. I would gladly trade away all the computer lab time they get for better mathematics instruction though. And why in the heck do they think it's a good idea to introduce calculators - they started that in 2nd grade! Insanity....
Wired News covers the Rover problem - some kind of nasty comms problem, unclear at this point if it's hardware or software related. This points out to me why you need manned exploration if you are serious - robots are fine, but like anything else - they break. And when they break, you might well need a repairman. Consider mission critical software systems - do you ever need to call in a consultant to get things going? It's the same problem. Do you just leave the critical software in a broken state, or do you call to get it fixed?
The existing Web architecture provides a couple of ways for polling based applications to save bandwidth including HTTP conditional GET and gzip compression over HTTP. Very few web sites actually support both well-known bandwidth saving techniques including the Dylan Green based on a quick check with Rex Swain's HTTP Viewer. Using both techniques can save bandwidth costs by an order of magnitude (by a factor of 10 for the mathematically challenged). Before coming up with sophisticated hacks for perceived problems it'd be nice if website administrators actually used existing best practices before trying to reinvent the wheel in more complex ways.
That said, it would be a nice additional optimization for web sites to only provide only the items that hadn't been read by a particular client for each request for the RSS feed. However I'd like to see us learn to crawl before we try to walk.
Well said. BottomFeeder supports both mechanisms - but it is astonishing to see how few sites do either one
Gordon Weakliem asks "what good is it" about niche languages:
Via Patrick Logan, I found a post by Roy Osherove asking, essentially, "what good is Smalltalk", and specifically, how can these languages make me more productive? His questions specifically target libraries and interop, and the situation's pretty bad for any language except Perl and Python.
I think Gordon needs to take anothet look at Smalltalk - VisualWorks supports a wide range of security protocols, COM, CORBA, Web Services, C call outs, and has .NET connectivity to boot. We now support the CE platform - both intel and StrongARM. Over in IBM land, VAST connects to just about all the IBM stuff, WebSphere in particular. Interop is actually pretty good in Smalltalk
From RSS Winterfest - Bill French said: "Email is where information goes to die". That's a good point - Scoble related that his 1 GB of email just vaporized on his way out of his last job - whereas everything he's posted to his blog is "out there". Interesting. If you left your company right now, would any of your personal knowledge base survive to inform your successor?
I've been listening to the presentations at RSS Winterfest, and Chad Dickerson has an interesting presentation on how InfoWorld uses RSS. On the IRC channel for the conference, I found this case study interesting:
Multiple groups within Triple Point are now using weblogs. The development teams use them to post frequently asked questions, design documentation, daily test results, status reports, and other information. With a mixture of individual and project weblogs, the information tends to categorize itself, and others can easily subscribe to the portions they care about. The sales force is also using weblogs to keep abreast of prospects, processes, and general questions and answers, promoting quick and seamless communication across the entire team.
Interesting - we'll have to see if web logs gain more internal traction than Wikis have...
For those of you already familiar with C#, it's clear that Xen is simply C# with additional features and capabilities. In fact, it's just C# with two of its most used APIs -- XML and database manipulation -- now built directly into the language
The architects behind Xen believe that if an API is used frequently, it should be considered for incorporation into the primary language. The popularity of XML and relational data structures make them the most likely candidates for inclusion.
I'm a little skeptical. I can't really see the difference between a decent library and adding to the language; then again, in Smalltalk that difference is, in fact, a very hard to see line - nearly everything in Smalltalk is the library. What this will likely amount to is a larger set of built in features in C#, which will serve mostly to complicate the beast. Just how many reserved words are there in C# now? Smalltalk has 5....
So says Darl McBride, in one of his latest lunatic ravings....
Actually, Smallblog RSS feeds do work, although I had to do some workin BottomFeeder to deal with them. Hitting the RSS feed url gives you a 302 (temporary redirect) to a funky url. Things work just fine if your RSS reader distinguishes a 301 (permanent relocation) from a 302 (temporary). BottomFeeder does - it leaves the feed url alone, and gets the 302 on each update cycle. I suspect that some readers treat 301 and 302 the same - and remap the feed url. This causes a problem on the next update cycle, as the new feed url was, in reality, only temporary (due to the way it's implemented in SmallBlog).
I actually prefer the way I do feeds in the Cincom Smalltalk blog server - I drop an actual XML file for the web server to deal with on each update. That allows compliant RSS readers to use conditional-get on the feed without my having to do anything - and it also reduces the dynamic load on the server a lot
Richard Morrison-Haefel makes some assumptions about open source development vs. commercial development:
The truth is: The difference between open source developers and commercial developers is the pretty much the same as the difference between a starving fine artist and a fat and happy commercial artist. The commercial artist, if she is any good, is probably paid a decent amount for creating logos, advertising, album covers and such things for someone else. A person who creates fine art, on the other hand, isn't likely to make more than a pittance even if they are lucky enough to get a show. While it's true that that some fine artists make it big, this is relatively rare when you look at the whole population. So why do people choose to create fine art, rather than commercial art? Freedom. Fine artists get to work when they want, create what they want, take credit for their work, and in the end enjoy the public scrutiny of their peers.
There are two problems with this analogy:
- It doesn't completely hold for art, with public grant money available for many non-commercial artists
- It doesn't hold up that well for software either - a fair amount of open source work - especially for Linux - is effectively funded development
Look at Apache - there's a foundation. Look at Linux - large amounts of work funded by IBM and others (Red Hat, SuSe, etc). Heck, Cincom doesn't pay me to produce BottomFeeder, but it works out as part of my promotional role. Yes, there are plenty of open source projects that are not being explicitly or implicitly funded. I would guess that most of the ones that succeed end up getting some form of support eventually
Roy Osherove wishes for another feature that we already have in Smaltalk. Actually, I'm kind of amazed that you can't step into .NET libraries without special tricks - what's up with that? One of the things that helped me learn Smalltalk was using the debugger to walk through system code, so that I could see what was going on "under the hood".
Smalltalk Solutions 2004 is fast approaching, and we need your participation! Smalltalk Solutions is a premiere venue for Smalltalk professionals, regardless of dialect, to meet and exchange ideas. We are currently accepting proposals for all varieties of talks involving Smalltalk technology and including presentations of other areas of technology from a Smalltalk perspective.
This year's conference is taking place in Seattle, Washington, May 3-5 2004. Presentations may be in the form of
- Technical Presentations
- Experience Reports
- Technology Demonstrations
- Half-day Tutorials
Presenters receive a free conference registration (one per presentation). Tutorial speakers will also receive a small stipend.
To submit a proposal, please go to http://www.smalltalksolutions.com/participate/participate.htm or email Alan Knight
Proposals should be received by February 15, 2004.
Keith Ray has some valuable insights:
Now the dynamic-typing people say that, in practice, it's very rare to pass a string into a function that expects an integer, or vice versa. (I have rarely experienced such a problem in C when trying to do manual refactoring, but that was quickly detected via crashes when running tests and the application.) However, there is a big loop-hole of type-checking in any language that has polymorphism, whether dynamically-typed or staticly-typed: your functions may require arguments whose type implement a certain interface (or be a subclass of a certain class), but there is nothing that forces the objects being passed into those functions to implement anything meaningful. In practice, this isn't a big problem - in fact, it happens so rarely that static type-checking advocates don't even think of this problem.
It's a good article, and points out some of the things that manifest typing advocates rarely consider - the holes in the systems that they claim are safer...
Doc Searls seems a little surprised that his positive spin on the Dean post-Iowa speech isn't getting traction - and in the process, I think he misses a lot about marketing against a persistent meme:
I see that my positive spin yesterday on Howard Dean's "barbaric yawp" speech got approximately no traction at all. Worse, the speech was (predictably) mocked by everybody in the major media from Stern in the morning to Letterman and Leno in the evening.
Clearly, its effects were regretable. It hurt the campaign. But it was also honest and authentic, and in the long run that can only help, for the simple reason that it was real.
There's some more stuff in there about the lessons of "Cluetrain", but Doc misses something much, much simpler - it's really, really hard to fight a growing meme. Simply putting your message out, and claiming that it will win because your voice is "authentic" is laughable. Why do I say that?
Let me jump back to 1995. Java was introduced, and - at least early on - many of the Smalltalk vendors and developers voiced the authentic opinion that Smalltalk was demonstrably better - more mature, more productive, in deployment, etc. Guess what - none of that mattered. Why not? Because the popular meme that Java was the future was adopted by many, many more voices - including the tech pundits. Soon enough, the Smalltalk vendors were being asked about their Java plans, and most of them adpted one (in particular, ParcPlace-Digitalk and IBM). Could Parc have stood alone and ignored Java? I think so, but it's not as if we could have "won" and pushed Java back under the rug. Once a meme reaches a certain level of credibility, having an authentic voice on the issue may take years to make a difference
It took Cincom - the new owners of VisualWorks as of 1999 - until roughly 2003 to be taken seriously as a safe place for Smalltalk by our existing customers, and to re-establish Smalltalk as something worth looking at for new prospects. That's 4 years. We managed to stay standing because we had an installed base that supported us. Not every product - and certainly not every political candidate - has 4 years to turn a meme around. Doc needs to take the rose colored glasses off, and realize that.
Mark talks about some of the difficulties in getting into VisualWorks:
Having hung out with a bunch of Smalltalker's on #smalltalk for some time now I'm getting used to them always talking about their increased productivity, but having read several comments in James Robertson's blog I hit one snag, whilst Smalltalk gives you a really nice productive environment, it would seem the packaging/deployment stage may be where they get hurt. I must say however that James's has shown great agility with my regular incessant BottomFeeder requests, suggestions, and bug reports - often having a new fix ready for the automatic updater within minutes of a problem being reported. I guess it all comes down to setups, and familiarity
Yes, familiarity has a lot to do with it. As Travis pointed out the other day (scroll through the comments) - packaging a VW application for deployment can be daunting. The Runtime Packager is powerful, but can also be hard to use - and error prone for the first time user. I've now got a stable, reproducible build/update process for BottomFeeder, but I had to build it myself. That's not something customers should have to do, IMHO.
So what to do? Well, engineering is working on a standard runtime deployment system for VW, one that will support network based updates out of the box. We are soon going to rolling out a network based installer for the NC product - which will be our first internal cut on that vision. You should start to see a deliverable take on this vision starting with VW 7.3 - we are aware of the issue, and working to remedy it.
Scoble is blown away by a PARTS like demo. Yeah, these things are cool - when Digitalk introduced it in 1995, there was tons of oohing and ahhing. (yes - yet again, Smalltalk was doing this eons ago... like a lot of stuff the curly brace crowd is only just now discovering) The trouble is, it doesn't scale. Yes, you can build some cool demos with lines connecting components. Now try to build something non-trivial that way. Notice what you get onscreen? A haze of lines - I recall calling it the green haze back in the day. If this sort of technology is used to connect very coarse grained components, then it has some value. At the level Scoble talks about? It's demo-ware that doesn't scale. Not only that, but the poor slobs who actually buy into it and build applications with it end up with extremely hard to maintain soup....
Patrick Logan notes that Python.Net handles .NET events, while the current VW bridge does not:
For the record, the very nice production quality Python.NET does support dotnet events in the manner described above. I have not looked at the code for how, but it is open source.
Update: My assumption below is incorrect - look at the comments for this item. Ok, that changes things, and makes me wonder if we can do the same thing that the Python folks have done. I expect so, and will ask engineering. This is one of the things I like about blogs; I get my misperceptions and mistakes pointed out almost immediately
Older, inaccurate part of the post below...
There's a slight difference here that I should note - Python.Net is native to the CLR, while VW is not. We are supporting .NET in a bridging fashion - similar to the way we deal with making external C calls. One might ask why we are doing it that way, and there are reasons:
- The CLR is not a friendly place for a dynamic language. Performance would be much slower for VW on the CLR
- Any effort to run on the CLR would involve removing a fair number of our base libraries, and instead hooking to the .NET libraries. That would make it very hard to keep the cross platform value we have now
As I said in the earlier post on this, we intend to support .NET events; I'm just not willing to post a firm date for such support yet
On comp.lang.smalltalk, there was a post lamenting the lack of support for .NET events in the .NET Connect for VisualWorks. I wasn't sure how to respond, so I asked the engineers working on the project - here's the answer:
Don't know about outgoing events (calling events from Smalltalk). But registering for events in .NET was not part of the version 1 plan. It is extremely difficult and there is no solution whatsoever at the moment (AFAIK for any *-.NET bridge).
The problem is that you need to give .NET a delegate object to call (type safe callback) and that has to be part of the managed world. We are thinking about synthesizing such objects (their classes) and having an extra callback mechanism with dedicated marshaling and ...
Calling the .NET-connect useless because of missing events is a result of an expectation mismatch. Events are heavily used in the UI part but rarely in the domain layer. Same as with Smalltalk. So at the moment we can use external domain functionality but embedding UI components is a different story altogether. Even with Event support today, we still have no concept for the emulated Windows.Forms widgets. These need a special wrapper environment that we very likely have to synthesize as well. For each Windows.Forms subform in an application. You get the picture.
.NET Events will be supported, but I'd rather not commit to a date until the engineers have had a better look
CNET News reports that Eclipse will be leaving IBM soon:
Eclipse, an open source development tools organization backed by IBM, plans to transition to an independent foundation by next month, a representative said on Tuesday.
The Eclipse consortium has filed papers to change its corporate status and expects to complete the process by the first week of February, said Eclipse chairman Skip McGaughey. The long expected change is timed to coincide with an Eclipse technical conference, EclipseCon 2004, to be held in Anaheim, California from February 2-5.
This is likely what will happen to Java when Sun spirals all the way down
Patrick Logan has some good things to say about Cincom Smalltalk:
There are a surprising number of new web applications running Gemstone Smalltalk too. I would probably choose Cincom's VisualWorks over Gemstone today since it now has a lot of server capabilities, better web tools and objects, as well as better product support.
You can use both as well - VisualWorks to handle the web and server side functionality, and Gemstone for seamless object persistence. It's a lot simpler than hooking (insert RDBMS here) up on the back end...
Derek questions a non-IT VP specifying technology that will be used:
A lot of organizations fall into this trap, that is someone dictating the solution who has no business doing so, instead of asking the IT department to find a solution that delivers his needs and meets the demands of the IT staff as well.
The problem also comes from the other end - especially in organizations with software development groups. IT will say "Here's the corporate standard" - without any regard as to whether the engineering group might need something that falls outside the standard (like, say, to support customers?) There's insanity on all sides of this issue, and way more than enough to go around. The way it ought to work:
- IT Guy - what do you need to be able to do? If talking to a development group, add "what do you need in order to support your customers?
- Non IT Guy - Here's what I need to do, can you support me in that area?
Instead, what we often get is IT shoving a 'standard' solution out, or in cases where someone else has more power than IT, IT being mandated to do things without regard to actual business needs. What we need is more communication, and less specification...
ISerializable asks some questions about Smalltalk. I was going to leave a long comment, but decided to post my response here, and point to it from there:
Well, the server I'm posting too is an example Cincom Smalltalk application, as is BottomFeeder
To get to your specific questions:
- Enterprise space - we have a number of customers using the product in that capacity - from Penn State with their online student information system, to JP Morgan for derivatives tracking, to AMD for managing wafer fabs
- Web services - supported for a number of versions now. There's a loadable component that supports SOAP, UDDI, WSDL (etc)
- Talking to other applications - Mostly the same as Java here - we have C level interfacing, things like web services or CORBA
- How widespread is it? TO be fair, not nearly so much as Java or .NET. There's Smalltalk work around (I get calls on a regular basis), and learning Smalltalk will, IMHO, make you a better OO developer regardless
- There are two Smalltalk implementations for .NET - #Smalltalk and S#
There's also a very nice set of online tutorials for learning Smalltalk on our website - I'd suggest having a look there. Another good tip is to check out comp.lang.smalltalk, or join the Smalltalk IRC channel - with questions. It's a friendly community, very open to questions
My advice to people trying to learn Smalltalk is pretty much the same advice I'd give for learning any new language - try something out. My own "aha" moment came a decade ago, when I redid my standard "learning app" in Smalltalk. I wrote this same application in Basic, Pascal, Imp (don't ask :) ), and Smalltalk. The application was a simple aid to solving simple cryptograms (like the puzzles they post in some newspapars on the comics page). I was astonished at how fast I got that done in Smalltalk, before I really even knew Smalltalk! The point is, trying to solve a simple programming problem I already understood was valuable - it taught me how Smalltalk worked.
There is no main. Rather than writing programs, you construct objects. Rather than running programs, you test objects. A Smalltalk environment will have several browsers up at a time. Some for browsing, others for editing. Another typical scenario is to have several *workspaces* up at the same time. A little code here, a few tests there.
I think Patrick's right - not having main() is a large part of the productivity question. Ironically, it's also one of the things that make Smalltalk hard to introduce to people - a common complaint from experienced developers, after their first encounter with Smalltalk is Where's my program? Once you get beyond that - and realize that you are holding clay - clay that you can mold into any shape you want - is when you really start to become productive.
The Iowa caucus results are interesting to me for marketing reasons. The Dean campaign has been getting loads and loads of press on their innovative usage of the internet - here's an example of something that popped up this morning, for instance.
In the end, the innovation didn't matter. I'm not going to get into the whys and wherefores of Dean's message, or anyone else's for that matter - it's not the point. The point is, all the innovation in the world wasn't enough. It's the same way with product marketing - you can have clever ads, and you can have interesting product placement (etc) - but in the end, your product has to be perceived as solving real problems. I'm also fairly well convinced that anger doesn't work - in politics or in products. People don't want to hear why the other guy's product stinks - they want to hear about what your stuff can do for them. Anger tends to gear up the faithful, and turn off the undecideds. There's a lesson in that for us Smalltalkers - and likely for Lispers as well
BottomFeeder 3.3 is out. If you have 3.2, you'll have to grab the new runtime - here are the install steps:
- delete all files in the 'app' directory
- delete all files in the 'plugins' directory
- replace bottomFeeder.im and bottomFeeder (nonWindows) or bottomFeeder.exe (Windows)
Here's a summary of what's new:
- Upgraded BottomFeeder to the VisualWorks 7.2 runtime. Users must download the new runtime.
- Initial Startup time has been greatly speeded up
- A complete overhaul of the posting tool. Thanks to Michael Lucas-Smith for all of his work and suggestions!
- How many items to cache can be set on a per-feed level now
- Feeds can be set to auto-browse individually, as opposed to the global setting
- Fixed a number of bugs and limitations in the feed auto-discovery module
- Improved the update tool
- Added two new feed builders - one for the Headline news service, one for the Yahoo news service
- On Windows, we now have better support for Unicode character display
- Added Support for Atom 0.3 syndication format
- Added support for the wfw comments module - Bf now follows per item comment feeds, inlining the comments (as per the includedComments support)
- Improved the Http package's handling of cookies
- Added a 'Flag for followup' property to items. Items may be marked as being flagged, and all flagged items can be viewed as a group
- Feeds may be marked as active or inactive (inactive feeds will not be checked for updates)
- Some minor UI layout tweaks in the main UI
See the Help About box for all the people who helped make this release possible. Thanks!
Over on QLOD, a new Smalltalker asks:
What makes me wonder though: Are Smalltalkers really that much more productive. In contrast to C or C with a bad ide and without libraries maybe, but in contrast to a more modern language ? (Think about something like AS1 with additional runtime typechecking and a big library like java, probably a bad example :)) Can anyone provide some pointers ?
A large part of the productivity comes from consistency. In Smalltalk, everything is an object. No primitive data types, no special rules on certain types of methods - which means you spend more time focused on the actual problem, instead of on how to fight the system to allow you to solve the problem. Another big thing is extensibility. We can extend any class in Smalltalk - need a new method in String? Go ahead and add it. No need to start wrapping all your string references with a new class, and wondering how to get third party libraries to play ball. Blocks add some capabilities that neither Java nor any CLR language have as well. Anyone else have answers?
Nu Cardboard relates some first impression thoughts, pointing out how off the mark they often are. I do like the "Smalltalk" references though:
The name Smalltalk: Is it for women? They're supposed to be better at small-talk than men.
The language Java: Looks like a C 'ers interpretation of Smalltalk
In Incipient, I read this bit on someone's desire's when using C :
I had an interesting conversation over a French-language programming newsgroup the other day. This person was inquiring about "Edit and Continue", tool support which would let him do simple, one-line changes to his C/C system from within a debugger session, and have the new code execute without needing to exit the program, recompile, rebuild, and start his session all over again.
My suggestion was to write small test programs to test bits of the program in isolation, which would obviate the need for debugger sessions as well as lengthy recompile/rebuild cycles. But, said my interlocutor, the programs I work on are "plugins" which fit within a larger architecture; I have to load the whole thing before I can test my own code. Even better, I replied. There should be a clean and well-defined interface between plugins and core, which will assist you in writing drivers and stubs enabling the above strategy. No, he told me, the "plugin architecture" mostly exists on paper. The program is actually a mess of tightly coupled spaghetti code. At which point I suggested that maybe that should be remedied.
Yes, writing small bits of code and testing are useful. Yes, having a cleaner base system is useful. But also - the limitations of C were his main problem. Had he done this using productive software - say Smalltalk, Lisp, Python, or Ruby - he wouldn't have had this problem at all, would have had edit and continue (only in an actual working state), and probably would have been able to diagnose the issues of the base system more easily. Instead, he got his productivity shot down, and a mass of confusion to boot. As well, that base system isn't really that poor student's problem either, and if my brother in law's Phd process was any indication, it's not as if he had time to deal with it anyway...
This week, a fat package of correspondence was couriered to Rowe's home, which claimed that all along his intention was to extract "a large cash settlement."
Customers of Microsoft could also be confused by the mikerowsoft Web page, the letter said.
Yeah, right - I'm going to visit this kid's site and confuse it for Microsoft's? Just how stupid does MS think people are, anyway? MS is making great strides at looking softer with all the bloggers - like Scoble - and then they go out and act like a bunch of ill mannered 6th graders going after a 2nd graders lunch money. Hey Scoble - why don't you clue in your management as to how stupid this makes MS look?
Update: Microsoft realizes that they look stupid
However, after the case received widespread coverage on the Internet, Microsoft has acknowledged that it may have taken things too far and has promised to treat Rowe fairly. A representative of the software company told ZDNet UK: "We appreciate that Mike Rowe is a young entrepreneur who came up with a creative domain name. We take our trademark seriously, but maybe a little too seriously in this case."
Sometimes, pointing out the insanity helps...
Gordon Weakliem has a cunning plan for his daughter. Now why didn't I think of that?
My daughter is subscribed to this neat thing called "Spy University" - every month, they send out a package of 'spy' materials - some of it pretty cool. She's gotten listening devices, spyglasses, lots of neat stuff. This month they sent along a cipher wheel for encrypting and decrypting simple messages. She had a lot of fun having me decrypt her messages, and having me send her messages. Eventually, I got lazy enough to whip up a simple single letter substitution tool. It's a simple UI that lets me look at the cipher text and have it replace (printing above the letter in question) the presumed plain. Took me less than an hour to do, and it sure is simpler than messing with that wheel :) Maybe I'll go back to doing the newspaper cryptograms....
On the xml-dev mailing list, I came across an interesting message from Michael Champion - makes a lot of points about why corporations tend to favor expensive solutions over cheaper ones:
I've had inquiries along these lines from the sales force of my employer (whose customers tend to be conservative, mainframe-centric shops). My newbie-to-the-mainframe-world response was something like "why would they want to buy something they can get for free?" The answer was basically that they want someone take responsibility for evaluating and testing code, who they can call when something breaks and be sure of an immediate response.
Not to get too far off topic, but "free" software is only free if you have the people with the time and expertise to exploit it effectively for your organization. There are plenty of companies out there who find it cheaper to license software for $50K/year (knowing that they can call someone on New Years Eve if it breaks) than to hire developers at $100K/year who will turn off their pagers on New Years Eve :-) This is one reason why mainframes still do the heavy lifting, years after a paper and pencil cost/benefit analysis of the hardware and systems software licensing costs would indicate that it makes no sense. This probably applies to all sorts of expensive DBMS, ERP, and app server software, not just mainframe shops.
The need for support is (and will continue to be) a big, big thing. This is one of the reasons we see stories like this - where IBM is offering some level of support to open source users.
Apparently, candle wax could be the next big thing in rocket fuel. Not an application I would have guessed at :)
Joi Ito goes on and on and on about the 'power law' of web (and blog) linking - the power law being, more or less, that the earlier you get in, the more linkage you get:
I think we are going to see an explosion in work designed to alter the construction and effects of this inevitable inequality (viz Sifry's experiments on moving recent blogs up the Technorati list) and I am optimistic about this change, as I believe the concentration of real thought and energy on what is actually possible, as opposed to cycles wasted on utopian declations, will be tremendously productive.So I'm glad Clay is willing to consider what we might do about the fact that the most influential blogs are by people in positions of privilege
It's all about content. Post interesting stuff that people want to read, and you get noticed. Post boring stuff no one cares about, and you don't get linked. It's really that simple. The 'top bloggers' may have had a first mover advantage, but they only stay at the top by being interesting. The main limiting factor I see in coming into contact with new stuff is the sheer volume limitation - for me, there's only so much stuff I can track, even using an aggregator. On the other hand, I have dropped stuff that has gotten stale, and added stuff that looked interesting as time has gone by. Meanwhile, Joi is worrying about how Technorati lists stuff. That is so not the problem. You want readers? Be interesting....
The Register reports that a couple of bozos have patented a naming convention:
The Net's two biggest registrars of domain names are being sued for infringing an email and domain name patent granted last month.
The lawsuit, filed yesterday in California, claims Network Solutions and Register.com are liable for selling, specifically, .name domains. It claims undisclosed monetary damages and an injunction against the sale of any more domains.
US patent 6,671,714 - "Method, apparatus and business system for online communications with online and offline recipients" - is owned by Frank Weyer and Troy Javaher, both of Beverly Hills in California, was filed in November 1999 and approved on 30 December 2003.
What's next? Patenting surnames?
US Senators are starting to syndicate content - here's hoping we see more of this sort of thing.
Blogging Roller links to a very interesting paper on blogging and markets. The thing is, this paper has value whether you buy into blogs or not; some of the main thrusts are valuable insights in any case:
There are certain issues to be stressed here. First, it is obvious that unless the weblog is unique, it 19s not going to work. Weblogs are an attempt to break free from the dehumanised, standardised, conformant with corporate guidelines on how to address an audience PR speak. This is why they work and Macromedia 19s Tom Hale gets it when he says 1Creaders should perceive the weblogs as the thoughts of community managers instead of corporate shills 1D. No doubt. But then he says that they wouldn 19t have been true blogs if they had put them on Macromedia.com. Why? Is it OK for employees to speak with a real voice but it 19s not OK for companies to do so? Primarily, it 19s a matter of mindset. Organisations have been stuck with rigid frameworks for way too long. It 19s only because of these mind frames that companies are compelled to traffic their voice to press conferences, press releases, investors and shareholders reports. Channelling one company 19s voice into routes more dialectic than traditional corporate outlets has been frowned upon as a mere illusion. But there is no illusion here. It all depends on your definition of a company and corporate (or marketing) communications.
This is perhaps the biggest issue that many organizations face - no one wants to read another breezy press release, and few believe the claims anyway. Even if you have useful information to convey. Think about restaurants - what claims do you put more value on:
- The ones from an ad?
- The ones from a restaurant reviewer in the newspaper?
- The ones from people you actually know who ate there?
I'd guess you put weight on those from the bottom up - and that points out the issue with most corporate websites - the information is top down, and that's the least persuasive form of information for an awful lot of people. The nice thing about a weblog is that it puts a face and a voice on the corporation, which puts it at the level of the reviewer (at least) - and possibly at the personal level eventually. That can only be helpful - look at the reviews at Amazon, for instance - sure, there are bogus ones there. But I look at them when I cruise Amazon for books on "counterfactuals" (like this one by Harry Turtledove, for instance). I don't always go with the reviews, but they do help me out - and I put more weight on them than I do in the publisher's blurb. Likewise, the thoughts of your lead developers and project managers - and the commentary provided back from actual users - are going to be given more weight than the product announcement.
In any case, I recommend the article. There's a lot there, and I don't agree with all of it - but it's a thought provoking read
Spotted in Sean McGrath says that Java (the language) is going to subside, with the JVM itself being targeted:
Groovy adds more grist to the dynamic typing mill. Java the language is on its way to becoming the assembler of the 21st century.
- Its there for a reason and does its job well.
- It can be programmed directly if push comes to shove
- Day-to-day work targeting the JVM is best done in something more productive.
It's really a pity that the JVM sucks so hard for dynamic languages - this would be a great way for Sun to add value over .NET, if they actually had a clue