Scoble gets some pushback from management:
Why the change? I'll be honest, I've gotten a bit of heck from people inside Microsoft and upon talking with my friends and co-workers about it, I've decided that my new policy will be not to link or talk about stuff unless Microsoft has officially released something
I've been wondering for awhile whether Scoble (or some other corporate blogger, like me) would get tripped by something like this.
Sean McGrath links to a great article discussing typing - static, ddynamic, manifest, etc. He makes some good points about the costs of manifest typing, and how TDD is much, much cheaper in a dynamic language.
Have a look at the comments as well - there are some choice comments from people who clearly have never seen a dynamic language - one commenter states that many tool driven refactorings are impossible without manifest typing! Guess he's unaware that the refactoring broweser was invented in Smalltalk
Via Sean McGrath - a link from the Joel on Software forum on the static/dynamic thing
You might have seen aa few ups and downs for the blog (and other services here). I was trying tto debug a posting problem that cropped up mysteriously - making this server capable of handling multiple blogs had a lot of small issues the price I paid for relying on a singleton when I started writing the server.
Since sometime last night, my network connection has been rotting on me. What do I mean by that? Well, after 2 hours or so, most pings are failing, websites are inaccessible, ftp is unusable... So I go power cycle the cable modem, and all is well. I had a comcast tech out a few days ago - my modem is fine, and the signal strength into the house is just fine - so the problem is further out. I just called them, and got a message that they are aware of problems in my area. So my question is, is this related to Sobig? Are my ISP's systems being overloaded, or is it something else?
Wired News has discovered XP:
The Mountain Dew-fueled all-nighter is history. Today's supercoders work 40 hours a week. And two to a computer. It's called extreme programming - and it's revolutionizing the software world.
do they issue cool superhero outfits now? There's also aa fascinating analyst quote further down in the story:
The software development process is profoundly screwed up. According to the Standish Group, which conducts an annual industry-wide survey, 15 percent of all information technology projects get canceled outright, costing the sector $38 billion each year, and companies spend $17 billion annually on cost overruns. Those products that are finally released contain just 52 percent of the features customers asked for. Throughout the industry, projects are chronically late - only 18 percent hit deadline - and consistently, maddeningly flawed. Estimates of the number of bugs contained in shipped products run from one defect in every 1,000 lines of code to one in every 100. According to Watts Humphrey in his book A Discipline for Software Engineering, IBM at one time spent $250 million repairing and reinstalling fixes to 13,000 customer-reported flaws. That comes to a stunning $19,000 per defect.
So here's a question. Most of these projects are using the popular, statically typed languages. Allegedly, static typing catches a lot of errors that a dynamic language would pass through. If that's the case, then why are all these errors getting into software?? The emperor has no clothes, and all of his acolytes are standing naked with him....
Phillip Brittan compares Java and .NET, and puts his finger on Java's problem:
Java takes a language-specific approach to solving problems, .NET takes a platform-specific one
He has some suggestions, and says he'll offer some more - however, opening the JVM to other languages is going to go nowhere until Sun unfreezes the JVM. So long as the JVM sucks as a platform for dynamic languages - which are gaining buzz - the JVM will be seen as a monoculture for one language. Meanwhile, .NET - and Rotor, the cross platform cousin - will adapt and grow to better support dynamic development.
Jon has an interesting post that delves into blogs and for pay content (MSDDN in this case). Have a look at this Scoble response to a complaint about content not showing up on MSDN:
Publishing is too hard for many Microsoft employees. Blogging makes it easy. Would Chris even bother if he needed to figure out who was responsible for publishing stuff like his over at MSDN? Would Chris bother if he needed to have three meetings just to get his stuff approved to post up? I wouldn't. I'm not gonna publish on microsoft.com or msdn.com unless I have to. The process is just too daunting...Think that most of Microsoft's 55,000 employees know how to get something through the publishing system at MSDN? I don't think so. Blogs take up the slack.
To which Pete Cole responded:
Errr, as a stupid sap paying $1000s for MSDN subscription I would rather that a company the size of Microsoft SORTED ITSELF OUT - please explain to me why I should even have to answer the question of which I would rather he do? If the MSDN people are a pain in the butt, then management should sort them out.
The trouble for me is that the API surface I write against is documented neither on MSDN nor the Web - I spent my life in a haystack of needles looking for the right one to put the thread through.
That's interesting. It's really just an extension of what's been going on in the world of newspapers and publishing - why buy the New York Times, for instance, when you can read it here free? That's now expanded out - developers are asking why they should pay for content, when they get better answers from blogs. It's hardly limited to blogs. A question recently arose at Cincom related to support - people regularly ask questions on comp.lang.smalltalk, on the vwnc mailing list, and on the Smalltalk IRC - and if the right people are looking, they get answers fast. Does that take away from support?
I think the answer to both is no. Yes, you can get good answers from non-traditional support channels, or good information from blogs. However, it's catch-as-catch can. You may get an answer when you need it, you may not. Paid support is a guarantee that someone will pay a attention to your problem right now. Of course, if support doesn't respond quickly, then the why am I paying? question will gain ground - in the more connected world we live in now, paid support needs to hop to it or be seen as obsolete - which will impact revenues. On the publishing side, it means that the paid content had better have something compelling that the free content doesn't have. If it doesn't, watch people stop paying...
Netgear inadvertantly hoses the University of Wisconsin with a massive DOS attack - not through a willful attack, but through bad programming. Now UW gets to suffer for years....
I've seen a few questions go by recently about threads in VW - so I thought it might be useful to publicize the existing information. Have a look at this page for information on controlling the thread pool. In your image, look at class ProcessorScheduler - in particular, look at these methods:
Those two methods will tell you what's going on, and how to control how your external API threads are managed. There's a wealth of information available on that page and in the method comments - go take a look!
Just noticed the change this morning. Thanks Google!
I posted on the ongoing Yankee surge and Red Sox swoon a few days ago - now I find this in the Boston Globe:
Meanwhile, Kevin Kernan's game story on last night in the New York Post leads with this: "It has come down to this. The Yankees and the Curse of the Bambino have gotten so deep into the New England mindset that at Quincy Market they are selling Babe Ruth "Reverse The Curse" dolls at a lovely little shop called The Christmas Dove. Fans here can't even celebrate holidays without thinking of the Yankees and the Curse of the Bambino."
I love reading Boston sports pages at this time of year :)
I was asking whether my crappy network connectivity over the last few days was Sobig related - apparently, it was. See this comment on the item. If the VPN blockage thing is true, Cincom's IT folks are not going to be happy about it....
Michael Lucas-Smith says that with:Style is getting closer to release. Very much looking forward to it.
Ted Leung notices that more and more interest in dynamic languages is cropping up. If it gets through to the large IT shops, maybe the horrible project failure rates will decline.
Ted Leung links to some interesting comments on the amount of 'line noise' in various programming languages. Doing a Smalltalk comparison took a small bit of effort:
In looking at the example, I grabbed 25 or so lines of Smalltalk from a few methods, and created a small noise filter - #($# $^ $! $( $) $[ $] $: $; $.) are 'noise' in the sense of the comparison here. Running over a small bit of Smalltalk code, I came up with 35. Now, the question is, is the colon really noise in Smalltalk - since it conveys semantic information? I don't know. to some extent, the measure is poorly done for all these languages, but there's the value I came up with.
Dewayne Mikkelson hits it dead on with this observation:
Yesterday's posting hit a nerve. (Seems at least three people agree with me!) What might we be able to accomplish on our projects if we put our attention on learning to increase the relatedness of people on our projects rather than studying for the PMI certification exam? Does anyone really think that doing better work breakdown structures will make our projects successful? No one. That's what I thought. How about learning to repair trust between two important team members? Now that would make a difference. Not the role of a project manager, you say? Then who's role is it?
yeah, that caught my eye. As product manager, I've attempted (more than once) to cool down out of control conversations between team members. It becomes more difficult when
Ted Leung points to some research on the impact of messaging interrupts during the day. As expected, phone calls are a big one - the recovery time from one is 15 minutes (time from getting the call to returning to the task at hand). However, email is more intrusive than you think. The recovery time there is 64 seconds - and you'll see a lot more email interrupts. At one point I had my mail arranged so that the poll was once an hour - maybe I should go back to something longer than the default (which is 5 minutes in Eudora)...
I decided to have a look at Comcast's policy on VPN's this morning (Comcast is my ISP). So I'm reading the page:
Do you allow/support Virtual Private Networks (VPN)?
Comcast allows customers to utilize VPN software in accordance with our Acceptable Use Policy and other terms of service; however, we do not provide technical support for them. To get support, please contact your software company's system administrator.
Ok, that sounds reasonable. Off to the Acceptable Use Policy document. Here I find this:
Prohibited uses include, but are not limited to, using the Service, Customer Equipment, or the Comcast Equipment to:
.....
resell the Service or otherwise make available to anyone outside the Premises the ability to use the Service (i.e. wi-fi, or other methods of networking), in whole or in part, directly or indirectly, or on a bundled or unbundled basis. The Service is for personal and non-commercial use only and you agree not to use the Service for operation as an Internet service provider or for any business enterprise or purpose, or as an end-point on a non-Comcast local area network or wide area network;
As I read that last clause, using VPN makes my system and end-poinit on a non-Comcast WAN - which is prohibited. So I can 'use VPN within the limits of the AUP' - meaning, I have the degenerate case, where I can't use it. Now to be fair, Comcast doesn't seem to care - I've had numerous techs tell me that they won't come after people using vpn unless they are chewing bandwidth in other ways (running servers, etc) that cause a problem. Still, the stated policy is at odds with the friendly sounding answer. I guess my question is, has anyone at Comcast read this page's question and compared it to the actual policy? Or is clarity optional now?
Two Towers goes on sale on DVD and VHS. So how many of us will buy this (the theatrical release) and the extended release in November? Likely it will be the same set of people who (like me) show up for the midnight openings of the LoTR movies...
Tim Bray has a roundup of good email alternatives. If you've had enough of Outlook, get thee over there now.
Tim Bray wonders if IT is a good career possibility anymore. Scoble ponders teaching his kid Chinese. Meanwhile, they (and most of the other bloggers, for that matter) are missing the trendlines completely. Business 2.0 has a very interesting article on this topic in the September issue (which is not online yet, so no direct links. The short answer - get ready for a sellers market in the IT realm again, and soon.
Ok, your immediate reaction is that I'm nuts. People have been getting laid off in droves, and offshore outsourcing has been all over the news of late. So where am I coming from? Simple - demographics. The demographic trends indicate a coming shortage, starting sometime in the next two years. And based on the numbers, it could easily be a bigger crunch than 1998-2000. What's driving this? The baby boom generation is starting to retire, and that cohort is bigger than the ones following it - by a lot. Just look around any IT shop, and what do you see? An awful lot of people within a few years of retirement
What's that you say? That the stock market tumble and loss of 401k value will keep them at work? The trend towards early retirement has been solid for 40 years now, through downturns a lot more severe than the recent one. Even the Social Security Administration - which would love later retirement as a way of being able to show better long term numbers - can't find evidence of people staying at work.
Ok, what about growth rates, automation, and immigration then? Automation hasn't slowed employment in the tech sector in the past - it's just shifted it. Immigration - legal or otherwise - isn't big enough to cover the lossage. And even if we assume average growth rates, the demographics show a crunch. What about all that outsourcing? Well, the most aggressive analysts predict something like 3.5 million jobs leaving to other shores over the next 15 years. India has something like 150,000 tech workers - which is barely 2% of the size of the US tech force. In other words, even if costs stay low there (which they won't), it's a small impact.
The doom and gloom outlook in this sector is overstated, and overstated badly. The demographics pretty much ensure a turn-around - and more quickly than you think. Go to a newstand and grab the Business 2.0 mag for September, and have a look at the charts.
If you tried registering for and downloading Cincom Smalltalk over the weekend, you likely had a nasty experience - a badly applied patch made it such that new users couldn't properly register or download. No one was really paying a lot of attention over the weekend, which is our fault. My apologies to all who had problems - if you register now, it should all work fine.
The Register quotes FSF counsel Eben Morgan, who says that there is no danger of the GPL being overturned as a result of the SCO and IBM suits. Eben has far more faith in the courts than I do - I wouldn't guess anything about what will or won't result when a court looks at the GPL. The Register does make a good point about overseas results - regardless of what US courts do with the GPL, any number of things could happen overseas. As far as I'm concerned, it's all unknowable...
Jon's Radio discusses dynamic languages and rapid development. He relates the rapidity of early (and ongoing) Perl based server scripting, and notices that the client side is still mainly static. Well, here's one developer doing RSS from a dynamic language (Smalltalk). Jump right in; the water's fine!
I am getting positively buried in Sobig virus emails. Most are coming through my Cincom email address, with the viral attachment stripped by the Cincom mail system. However, that's still inundating me in the messages. Is this happening all over today?
With the help of a style sheet from Michael Lucas-Smith, and some instructions from Anthony Lander, I've redone the BottomFeeder home page. Thanks guys!
ESUG 2003 in Bled, Slovenia has started, and there are some early reports of goings on on the ESUG Wiki:
Fast Company has some interesting advice for those who want to encourage and create new ideas - don't always hang with the same crowd. Interesting article - here's the summary points:
- Cut the cord to the familiar faces around the water cooler.
- Mix it up.
- Take a class with strangers, seek out ideas from people you don't ordinarily talk to, do anything to get out and mingle more with folks from other professions.
- Broaden your social horizons.
In other words, if you want new ideas, meet new people...
PCWorld.com reports that the DOS attack on SCO was carried out by a senior member of the linux community. Ok, that's bright. Could this moron have thought of a better way to make potential corporate adopters of linux think less of open source and the open source community? Here's an enlightening set of comments:
In an interview last week, SCO chief executive officer Darl McBride complained of being picketed, targeted with crank telephone calls at 2 a.m., and even challenged to a fistfight by an SCO detractor.
"Terrorists do things designed to intimidate people, and we see a lot of that going on all the time--people trying to attack us or people that we're associated with," he said at the time. "If you look at a DoS attack, that's a form of cyberterrorism," he said. "When you're shutting people's Web sites down, you are impacting commerce. That's against the law."
Raymond and fellow open source advocate Bruce Perens condemned the attack, saying that the open source community would be better off compiling evidence against SCO's claims, rather than attacking SCO directly. "I think it's important that we hold the moral high ground here," said Perens. "We are the good guys. We are the ones who are having false claims made about us."
It's really, really hard for me to work up any sympatthy for McBride - but the sort of harrassment he's getting is beyond the pale - and it doesn't help. Rather, it makes him - and by extension his argument - seem more reasonable. If you engage in this sort of idiocy, realize that you are offering aid and comfort to SCO...
Ted Leung covers a lot of interesting ground on dynamic systems in this post, but this paragraph on the benefits of GC really jumped out at me:
In the early 90's when I argued with people about Lisp like languages, I was always getting pushback on the syntax, and on garbage collection. Today, I no longer have to argue with people about garbage collection. Java and C# have made it acceptable. But people misunderstand its importance in constructing modular systems. Most people like garbage collection because it eliminates memory smashes. This is true and definitely a big benefit. But the bigger benefit of having garbage collection in the language is that subsystem designers no longer have to worry about which subsystem owns the memory. This makes it much easier to break things apart and reuse them. When you have to manage memory by hand, your subsystem has two "protocols" jammed into a single mode of expression (the API). You have the application level protocol for the subsystem, and you have the memory management protocol for the system, so that subsystem users know how to interact with objects that came from the system. We don't have to deal with that any more and that decouples subsystems a lot. So we killed two birds with one stone, but we only saw the carcass of the smaller bird.
I just love the way he put that.
I don't need to lok any further than my inbox to tell me that Sobig.F is still spreading like a fire in a dry forest. I'm getting a steady drip - 3-10 virus mails - on every download of mail. Most of them are coming into my Cincom account, and have the attachment stripped by the corporate mail system - but I'm still dealing with the detritus down here. The interesting thing now is some of the forged 'from' addresses - I've received mail allegedly from marketing feedback points at CNN and Fox news now. For someone interested in doing the research, there's an interesting "Six degrees of separation" paper in all this...
Mitch Kapor receives a fascinating email - a request from the PR firm of a 'well known Silicon Valley' firm VP to publish a comment on his blog. This is interesting on two levels:
I posted on an earlier post by Jon here - and today he follows up with an interesting explanation of why static typing advocates distrust dynamic languages - a lot of it is based on extrapolation from Perl:
In this discussion, Perl is a red herring in more ways than one. First, there's the ongoing confusion between two axes of typing -- strong versus weak, and dynamic versus static. For example, both Perl and Python are dynamic, in the sense that you need not declare a type when first assigning to a variable. But while Perl's typing is weak -- you can just assign a date to a variable that holds a number or a string -- Python's is strong. Once a variable has a value, Python cares very deeply about what its type says that thing can or can't do. Bruce Eckel's assertion to the contrary raised hackles in the Python community. Dynamic typing and strong typing are orthogonal.
But there's another sense in which Perl is a red herring here. Perl isn't interactive in the manner of Python -- or, for that matter, VB6 as compared to VB.NET. Those who have resisted adopting VB.NET have sometimes been characterized as knuckle-scraping Neanderthals who must be dragged kicking and screaming into the modern OOP era, or else left behind. But while the .NET Framework has much to offer, I think the VB6 crowd are right to demand a more interactive way to use it. As programming increasingly relies on external services and alien environments, it becomes as much a game of exploration and discovery as of design and specification. I think dynamic languages and interactive programming environments help make us better explorers and discoverers, and I think that's only going to matter more as time goes on.
This is a good observation, and I think he's on to something - a lot of people assume that static = strong, and dynamic = weak. No matter how many times we point out how wrong that is, a lot of people just don't get it. In a way, it's almost reassuring that Python developers are getting the same misconceptions thrown at them that we've endured for years - because everywhere you see 'Python' above, you can slap in 'Smalltalk'.
Linux Today points out - via a Washington Post story - that the OS has been shipping, by default, in insecure mode. This is old news, but it's still relevant - we will be paying for this mistake for years to come
Tim Bray and Don Box both think that software development is a declining profession. They need to read this
CNET News has an interesting little story about Evite, who distribute calendars. Not only did they get the dates of the major Jewish holidays wrong this year (they apparently listed the 2002 dates) - the calendar list Yom Kippor as a "Day to Party":
"In addition, we also wish to apologize for having listed Yom Kippur as one of our 'Reasons To Party,'" the mea culpa continued. "We understand and respect that Yom Kippur is a Day of Atonement, a day to be taken seriously to reflect and fast, and as such, one of the most important Jewish Holidays in the year."
Whoops
Michael Lucas-Smith compares static types to the common cold. I'd hope we can get over static types sooner though....
Don Park talks about Korea, but I'm linking because of this great line at the end of his post:
Monty Python is like herpes. Once exposed, you are stuck with it for life.
Ted Leung points out that the next challenge for open source goes beyond cloning simple unix services, and into creating better applications. Here's my two cents - if you attempt that using the same languages and tools as everyone else uses, you won't get there. What you need is a productivity enhancer that few others are using. Like, say - Smalltalk
The Washington Object-Oriented Architecture and Design group is having a roundtable discussion tonight. I don't have a list of topics - for all I know it will be open discussion. It ought to be interesting - there's typically a good crowd at these events. It's at the Rockville (MD) Best Western at 7pm if you are interested and in the area. The hotel has wi-fi, so I'll be blogging the discussion as it happens
Ted Neward has some great advice on both ends of that:
Think of a good review as QA for the authoring process, and treat a reviewer as somebody who's part of your team, not as some antagonist who's trying to make you look bad. At the end of the day, they're just trying to help you not look like an idiot in front of potential thousands of people.
Gordon Weakliem is tired of programming:
The funny thing now is that computers really aren't fun anymore. I think I've had it beaten out of me, I've spent too many nights and weekends chasing down stupid quirks, stuff that's not even programming, just accounting and janitorial stuff. I still read programming books in my free time, but most books just depress me. That thought occurred to me while reading one of the Agile process books, so I quit reading about process and started trying to find things that would take me back 12 years, back to when Pascal was neat, and everything seemed easy.
The prescription for that problem - avoid the manually intensive curly brace languages. Work with Smalltalk, or Lisp, or Python, or Ruby. Watch the janitorial tasks disappear and the fun come back.
WOAD Roundtable on development issues. It's a small group - only 7 of us here. We started a discussion about the rationales for moving a typical Fortune 500 shop from a set of "stovepipe", unconnected applications to some unified architecture based on (whatever). It's done a lot; it fails most of the time. Here's why:
However, we hardly stayed focused on this - the discussion ranged all over the place. The conversation ranged over to modeling and code - round tripping - do models, help - can a model be language independent? IMHO, models end up being language dependent - because the design choices you make will depend on the implementation environment you'll live in.
Interesting - one guy has the same issue trying too move from VB to C# that I see in moving people to Smalltalk - management always asks "but how will we maintain it if you leave?" They also seem to believe that large numbers of cheap developers are better than small numbers of good ones. Which is why many outsourcing projects will fail, IMHO...
What about electronic notes - tablets, etc - as opposed to paper notes? I personally prefer paper, a lot. Some think it's a paradigm shift we need - I think people just prefer something they can easiily mark up anywhere they are - i.e., paper. It also makes a difference what the task is - some are far more optimal with paper (ad hoc notes at a meeting, for instance) - others need somethinig that can be archived and passed around more (the person taking minutes at the meeting). Neither is better...
Code inspections - how deep do you go, what do you and don't you inspect? Hand too much over, and you get people mindlessly checking off. Actually, how much value do these kinds of things have? Do such inspections pay off, or is pair programming and TDD going to give you a better bang for the buck? Code inspections to fix consistency issues in code? To my mind, if you have that problem, you have other issues that need addressing. If you have a team so large that you need inspections to enforce consistency, then you have a larger problem.
Re pairing - the idea of pasturing out slower developers and leaving the 'top guys' alone - that's a project smell. If putting the top guys with the newer people for mentoring is a problem, you made staffing mistakes. Maybe - on government projects especially - you don't have the power to get the right staff. In general, you don't want to have a staff where you have to pasture people. That's project smell. Good analogy - It's like the old craftsman, journeyman, apprentice system - yes, the apprentice mostly works with the journeyman - but the craftsman should spend some amount of time with the newbies - both benefit, and both learn new things.
In the end, most of this falls into project management - good process, good results. Bad process, bad results. How do you get junior people trained? What's the mentoring process? It all depends on what kind of junior people you have. How much hand holding do they need? Interesting set of points, actually. Too much too fast for me to transcribe...
Security and Windows - I'll go back to this. The mac hasn't had nearly these problems, and it's been around a long time, and has a decent sized user base - if it were as insecure as Windows, we would have had some big issues reported by now.
SWEBOK - bleah. Nothing good to say about this from any corner. Heck, I've commented on this before. The problem is, this may be used to rate developers and projects from a 'malpractice' standpoint. As usual, watch the lawyers get rich, and the rest of us suffer.
I know this rambled all over the place... but that's the way the conversation went - we bounced all over the place, exchanged a lot of ideas, had a few laughs.
The Ottawa Carleton Smalltalk Users Group is proud to announce a special distinguished speaker to kick off its 2003/2004 year. Visit the OCSTUG web site for more information.
You Can't Do That With Smalltalk! " Can You? Lessons From The Past " Challenges For The Future
Dave Thomas
Date: Thursday, September 18, 2003 Time: 6:30 PM Location: Room 5115, Herzberg Laboratories, Carleton University (see details below) Abstract
In this talk I provide a personal perspective on the evolution of commercial Smalltalk as it escaped from the Parc to the Street. The papers and dialog I see today in the Smalltalk community, and especially the Squeak communities are very much reminiscent of the excitement we felt as researchers and developers in the early 80s. Our challenge then was to be able to keep using Smalltalk in research or commercial development outside our tiny community.
In the early 80s we had very limited access to the technology and the implementations lacked the features and performance needed for any kind of serious industrial or research use. Indeed many of us lacked the hardware to even use the technology in a serious application.
We examine the technical and business contributions that both enabled and hindered the development of a vibrant commercial and educational Smalltalk industry in the early 90s. We show that by stepping up to and addressing several external challenges the Smalltalk market was created and flourished.
We briefly discuss the Smalltalk commercial inertia, language entropy and developer arrogance that allowed it in part to be eclipsed by other technologies rather than evolve to meet the needs of web and open source communities. We advocate for constantly evolution of Smalltalk, rather than the preservation Smalltalk as an interesting software artifact for every trapped in its own self-image. There are many exciting things happening outside Smalltalk that we need to bring into our world, and some old baggage we need to throw out.
We challenge future Smalltalk advocates to address the needs of the external developer community to enable the wider spread use of Smalltalk. Unless the needs of the broader development community are met Smalltalkers will remain in their cloisters preaching to each other rather than saving developers from middleware hell.
Speaker Dave Thomas From Bedarra Corporation, Carleton University and University Of Queensland Dave Thomas is a popular keynote speaker and a recognized international expert in: software engineering; virtual machines; object technology; embedded systems and end-user programming. Dave is best known to the Smalltalk community as the founder of Object Technology International (OTI) developers of Envy/Developer a unique CM environment for object oriented development; virtual machines (Smalltalk/Vmac and Envy/Smalltalk) and IDEs for IBM VisualAge for Smalltalk; for Java; Micro Edition for Embedded Systems and Eclipse. In recognition of his contributions to object technology Dave was elected to the IBM Academy
He is currently CEO of Bedarra Corporation, which he founded in 1998. Bedarra provides assistance to new ventures both in new and existing companies as well as R&D and competitive analysis. Bedarra focuses on the transfer of research from the lab to commercial success. Bedarra has assisted more than 30 companies in Australia, Canada, the US and Europe. Bedarra is currently focused on: eLearning; Next Generation Application Development; Agile Software Development and Pervasive Computing.
Dave was recently appointed a founding Director in Agile Alliance, which promotes fast user, focused software development. He is on the editorial board of the new online Journal of Object Technology (JOT) and a columnist in Otland. Dave is an adjunct research professor at Carleton University and the University of Queensland in Brisbane Australia where he works with the DSTC research lab.
Location Details
The meeting will be held in Room 5115, Herzberg Laboratories (building 13 on the map ). Pay-parking is available in Lot 1, 2, and parking meters can be found along University Drive. Free parking is available across Bronson Avenue opposite Lot 5.
Please RSVP to david@simberon.com if you plan to attend
Ted Leung has a post on product liability, and how it's going to impact the software industry. He sums it up thusly:
The software industry as a whole needs to find ways to improve software reliability. If we don't find a way to do it, the legal system is going to find way to do it for us.
I'm a whole lot less hopeful than that. Product liability cases often help one set of people, and one set of people only - the lawyers. Look at the Tobacco suits, and who got most of the money, for instance. And it's not necessarily the case that suits help - look at the stupid Stella Liebeck coffee case - the upshot of which is that I can't get a decent cup of coffee at McDonald's anymore. Liability suits are a very coarse grained way to fix a problem - and in some cases, the fix may well be worse than the original problem. Another example - go look at a ladder. Notice all the nasty warning labels on it? Those exist because of liability suits. Now imagine software with that kind of thing ....
I've seen my share a wiki skeptics, as detailed in this post. Clay Shirky hits the nail on the head when he points out why they are resilient - it takes more effort to despoil a wiki than it takes to restore the original content. I saw this first hand a few years ago when a complete idiot decided that it was his god given right to deface pages here. He carried on for about a week and a half, gettting increasingly angry after each rollback of his graffiti - but he eventually gave up - because his bad behavior was more work than my restorations.
There are a few other really good points in the post that go beyond wikis - the introductory points about process, for instance. Ted Leung points out this followup. Ben Hyde clearly doesn't agree with Clay's process arguments - both points of view are worth reading.
I've been telling people this for years - but most people have to use a dynamic language first before they really get it. Now he should try out Smalltalk, and see what productivity is really like
I've never been a big fan of manual labor (meaning, I've never liked it when it was my hands that had to the actual labor). I never cared for it as a kid, when I got drafted into the varrious home improvement projects my Dad undertook, and I still don't like them. On the other hand, I like crafting software - it's been a lot of fun building this blog and BottomFeeder.
So the sense of satisfaction I get after finishing a home project always comes as something of a surprise to me. Recently, we had to address a drainage issue. We put in a patio, steps, and a sidewalk (garage back to the patio) 2 years ago. That was a huge job, and involved a lot of moving of earth - nearly 10 tons of gravel and sand, plus all the dirt and sod we dug up. I still stand back and admire that work. Unfortunately, we caused a water problem when we put the sidewalk in - it was too high, and dammed the water coming from the sump pump outlet next to the foundation - after every rain storm, the pump would run for days, and we ended up getting a minor leak into the basement
Clearly, we had to fix that. We got to it this summer. We had to tear up most of the sidewalk, and about a fourth of the patio. We then dug over 100 feet of drainage trench. Into those trenches went four inch perforated pipe. That's hard work on two levels:
Every time it rained (which has happened a lot this summer), the trenches had to be re-leveled. We finally got the pipe in, and the trenches filled back in. Then there was rebuilding the sidewalk and patio - and let me tell you, the briicks never want to fit back in the way they should. Still, we got that done, and waited for the first rainstorm (which perversely now that we were done held off for days). It worked - the water drained down and away from the house. No more lake on the patio, no more leak in the basement, no more constant ruunning of the sump pump. Success!
There's still some cleanup to do - we don't have all the blocks near the steps back in yet, for instance. The major work is done though, and in looking at it, I find that I have a higher level of satisfaction than I ever get from software. Which amazes me. Perhaps it's the sense of "permanence" - those bricks and pipe will be there, long after I've moved from this house (which itself is 20+ years away, at least). BottomFeeder likely won't last as long as those bricks, which is probably why I take more satisfaction away from that job. Doesn't mean I want to go to work as a bricklayer though :)
The Register has some reader feedback on preventing email viruses - interesting selection of comments....
Gordon Weakliem wonders how he missed the passage of the 27th amendment a couple of years ago. This site explains why (see dates) - the Congress passed that amendment - without a time limit for ratification - back in 1789. There it lay forgotten for more than 2 centuries before 3/4 of the states actually ratified it. In recent history, amendments passed by Congress typically have a time limit for ratification - typically 7-10 years, if I recall. The ERA amendment, for instance - stalled out 3 states short of passage when time ran out on it.
If you are using BottomFeeder 3.0 or the in dev stream, use the update tool and update. An alert user spotted a bug in the http code that was causing a lot of cpu usage - and a generally slow update loop. With the fix, the update loop is a lot faster - and plugins like TypeLess are not bogged down during updates. Tip of the hat to Martin Kobetic for his help on this!
Patrick Logan explains why you really want a dynamic language:
Lists, maps, arrays, even self-referencing structures can all be entered end edited in a command loop or workspace using a very simple (i.e. few characters) syntax. There are also the mundane (now that Java brought them to the masses) aspects of these languages like garbage collection and array bounds checking
Productivity is greatly enhanced when you can explore the bounds of a problem easily. Most of the static language crowd still doesn't get this
Steven Denbeste explains the difference between user friendly and user hostile - in short, it's usually a mistake to assume you know what the user needs:
Your job as a tool designer is to give your customer what he wants, not to give him what you think he needs. Your job is to let him do what he wants, not to force him to do what you think he should do. If a customer comes up with a hacky solution which works, let him use it. In that case, it means he's still concentrating on his problem. Once your tool gets in the way and tries to force him into some stylistic channel or other, then he not only has to concentrate on his problem but also on trying to figure out what way your tool is willing to allow him to solve it. Whether or not the result is "better", you've made the problem harder to solve, and that means it's going to take longer and require more effort. That's the opposite of what tools are supposed to do: they're supposed to enable fast solutions, not prevent them.
Something to consider next time you get ready to deliver....
Dave Buck explains the problems inherent in trying to express blocks in a statically typed language.
Wired News points to some research on trains and fuel cells. The idea would be to get subways onto fuel cells - and off the grid. There's a basic problem with this, to my mind - cost/benefits. How often do the subways lose power? Not terribly often. What would be the cost of putting in a fuel cell based infrastructure? Pretty high, I'd guess. The question is, how would you prioritize that over other needs and problems - when the problem fixed by fuel cells is rare?
This is one of the sorts of problems that - to my mind - IT shops understand very badly. Over the last 7 years or so, there have been tons and tons of projects launched to replace the entire infrstructure of a business - from whatever it was to J2EE (and possibly .NET now). It's as if no one ever looked at the opportunity cost of that - how many other things could have been done - and probably a lot more quickly and cheaply - by simply adapting what they had instead? How many expensive consultants would never have been hired (only to be fired later when things went badly)?
Web Services has the potential to make such mistakes obsolete - instead of rewriting (with a high risk of failure) - simply add web services api's to what you have. It's a virtual certainty that such API's can be added to your existting applications, and the liklihood of success is far, far higher than in a full rewrite scenario. To my mind, the shops that pay attention to opportunity costs are helping their businesses. The ones that don't are creating a business drag
The Washington Post reports that the FBI has found the loser who unleashed one of the MSBlaster variants - some 18 year old kid in the Seattle area, apparently. The worst part is, he's traded the transient high of pulling this prank for the long term pain of the big house - I seriously doubt that the authorities will cut him any slack. I wonder if he'll reappear years from now - like Mitnick did - older and wiser...
CNET News.com surmises that Sobig may be a funded effort - on the part of spammers. Think about it - Sobig sets up an anonymous SMTP server on multiple clients, and has the ability to call back to some kind of central server (for content). What we could be seeing is either:
As CNet puts it:
Security researchers believe that the creator of the Sobig mass-mailing computer virus won't stop with Sobig.F--the money may be too good. The Sobig viruses, the first of which started spreading in January, are designed to load special software that can make spam anonymous on people's PCs. The tens of thousands of computers infected by the virus can then be used by bulk e-mailers to send unsolicited messages that can't be tracked.
"It is very well planned, very well designed and very well executed," said Mikko Hypponen, director of antivirus research for security company F-Secure. Hypponen believes that the virus' author likely sells the list of compromised PCs to spammers. "For once we have a virus with a very good motive: money."
If this is the case, get ready for more of the same. One more reason to transition your mailing lists to RSS feeds with comment capability....
Chris Double points to some continuation based web servers - and misses Seaside - there are implementations for Squueak and for VisualWorks
Update - spoke to soon - Chris updated the page....
Danny Ayers doesn't think much of the barefoot post (on developing w/o static types) which I linked to yesterday. He says:
Let's say I come across a method like this :
def do_upload(pagename, request): ...Here I can guess from the context that it's a http request, so let's say I want to get the date header and print it in W3CDTF format. If it was typed, then I'd simply look in the documentation for that type (class). But how do I find out what methods 'request' supports?
hmm. We don't have that problem in Smalltalk. We have tools that can find implementors and senders of methods for us instantly - so it's an utter non-issue. The type information adds nothing of value in that regard. I'd suggest downloading a Smalltalk implementation and taking a look - you'll see why it's not a problem.
Martin Kobetic kelped me out with another interesting bug - and the fix does three things:
When I added module support, one of the methods that looks for an appropriate handler for a module had a nasty little bug - it did this:
subclasses := self subclasses
Well, that was in a class method, and it turns out that 'subclasses' is an inherited class instance variable. Dohh! On each run through, the subclasses of class Module got more and more massive - and searching through them got slower, and there were multiple matches of appropriate handlers - all manner of badness. That's fixed now, and the application is much more well behaved now.
I posted earlier on an interesting - and nansty bug I had introduced into BottomFeeder. As it turns out, the problem I created can manifest itself in other ways. Here's what I did, each time I checked modules (and I have 151 feeds here):
subclasses := self allSubclasses.
That looks inocuous enough. Trouble was, I did it in a class method. Recall that classes are instances of their Metaclass, and descend from Class (up to Behavior). Look at the instance variables for Behavior:
Smalltalk.Core defineClass: #Behavior
superclass: #{Core.Object}
indexedType: #none
private: false
instanceVariableNames: 'superclass methodDict format subclasses '
classInstanceVariableNames: ''
imports: ''
category: 'Kernel-Classes'
One of them is 'subclasses'. So look again at what I did - each time through that loop, I made subclasses into a bigger collection, all filled with duplicates! When I looked at it in my development image, I had over 10,000 subclasses of the class in question! No wonder I was chewing memory, and no wonder iterating over the subclasses (that's what the code in question did) was taking a long time, and getting slower each time through!
Fixing it was a simple matter of changing the code to use a temp variable - problem solved. There's a larger lesson here though - look at Behaviior abd the subclasses down to Class. You don't want to use a variable that matches the name of any of those instance variables on the class side - referencing them in tools is ok, but assigning new values to them is a very bad idea. The only real hint you'll get is that you won't be prompted to declare a temp variable - but that's very, very easy to miss.
I'm looking at adding a code critic rule to flag these issues - if I get that working, I'll post an update. In the meantime, watch out for this sort of thing if you start seeing oddball behavior in an image.
Slashdot notes that AOL is blocking Live Journal links - so a live journal blogger who tries to link to an AOL blog gets a 404. That's just fascinating. Is this image vampire blocking gone wrong, or something stupider?
|
| Subscribe to WebVelocity |
| Visit this group |