with everything but Java itself?
I don't know if this is the greatest idea, but their products weren't doing well before they went open- how will then do now? I think the adoption rate won't change drastically. I guess a second question is how will it affect the future quality of these projects. Just because they are free and the source is open, there isn't a community of developers around these things that Sun will be able to leverage (such as the amazing community around Eclipse). So, what do they gain, besides maybe making BEA and IBM drop their prices? My guess is that they won't drop their prices- and now they have some numbers to say that Sun doesn't think there software has instrinsic value, while theirs is worth upwards of $10k/CPU.
Wednesday, November 30, 2005
with everything but Java itself?
Monday, November 28, 2005
Thanks to one of his comments, I read through all of Geo-Web.This blog does a decent job of expaining what the heck GML is. GML itself is one of those things that is too "meta" to be of use to most people, but GML application schemas and profiles defined for particular purposes can be useful. The author tries a lot of analogies to explain what GML is, but it's pretty different from most things.
Think about the specification for SQL- most of us never look at. In fact, we are usually only concerned with the variant of SQL that applies to the database we are using. We might try to write database independent code, but what's a VARCHAR here is a VARCHAR2 there etc. We then define different databases using the DDL (Data Definition Language) aspects of SQL, and you end up with particular columns and tables, etc.
Now, imagine if the specification for SQL was written in XSD. That's the thing about GML that could make your head fall off, it's like a specification for creating XSD, written as an XSD. And by the way, the schema for XSD is also an XSD. This is what makes us not love the XML folks so much.
Ben Galbraith has a great story and presentation on this stuff, here's a recent article on this stuff.
Posted by Matt McKnight at 4:08 PM
I think a great definition for beta is things that are feature complete, but not yet fully tested. If you want to do a release that is not feature complete- whatever your definition of complete is- I would go with a 0.x numbering scheme. The guy in this WSJ article who says his site is beta because he hasn't finished all of the features yet, seems to be a little misguided. It would seem that beta has come to mean "not finished", as opposed to "not fully tested".
I blame Google for this, although everyone else is getting in on the game as well. If you call your first live public site a "beta", it doesn't leave you a lot of room for improvement. I think the expectation this it lets you get away with buggy software, which is entirely different from incomplete software, is a bad expectation to create. In fact, one could argue that few software products are really complete (even after they begin sending email). From agile perspective, we should be getting more comfortable with releasing evolutionary products, but they should products where a limited set of features work correctly, and the ones that don't are not included.
Posted by Matt McKnight at 2:57 PM
Previewseek web search: "
Beta web search Previewseek aims squarely at Google and bills itself 'the world's most advanced search engine.' PreviewSeek's about page compares a search for the word 'Java' on Google and says its results are smarter:
Previewseek immediately understands that the word Java can mean many different things. Did you mean Java the island, Java the coffee, Java the programming language, or Javanese (the language spoken by people on Java island)? If you are not sure, Previewseek immediately gives you definitions of each different meaning. On Google, if you were interested in Java the island, you would have to click through over 70 pages of irrelevant results for 'java' before getting to your very first relevant result! In Previewseek, you just need to click once to get all the appropriate results.
Uhhh...maybe you should just query "java island". It really annoys me when people do some dumb query on a single ambiguous word and complain about the results. The previously mentioned search even gives you some options for "java island map" as a suggested alternate query.
Posted by Matt McKnight at 2:27 PM
WebWork merging with Struts to become Struts Ti: "Patrick Lightbody, in 'WebWork joining Struts,' has announced that WebWork is going to merge into Struts, becoming the 'Struts Action Framework 2.0.' The main benefit for WebWork, he says, is the Struts community, while Ted Husted says that the intention for Struts Ti was to use WebWork as the core for the action framework."
This is an interesting combination- I wonder which parts of Struts they would keep in this scenario? Two places where it was always lacking were in the construction of multi-page flows and in simple UI construction. I think the problem with a lot of these frameworks is that they just go too far down the old configuration road. If everything is configurable, you don't really have an application, you just have another layer in a stack. Too many of these things make you feel like you are programming in XML, rather than using it as a data representation format. Maybe they can slide in some Rails style convention over configuration principles in as part of the integration....
Posted by Matt McKnight at 12:22 PM
Sunday, November 27, 2005
Thought Experiments>Tim Bray has some interesting thoughts on the new Office XML formats. One of the key elements here is backwards compatibility. Microsoft over the years has gone to amazing lengths to preserve backwards compatibility in its products, at the cost of simplicity. It still seems to be a weak argument in this case for including that in the new XML format- even though there are billions of legacy word documents, that doesn't mean they should be in the new format. It's far easier to build support for the old formats into the new Office suite and support for the new formats as a plugin to the old Office suite.
Still, the question of whether Microsoft or OASIS have come up with the better format is a fair one. However, that should be evaluated on the basis of features and performance, not by who came up with it. The idea Tim has of getting them to agree on the basics is good one. It reminds me of how KML uses the basic GML standard for points, while putting it's own structure around it.
XML does allow for sharing the common bits with namespaces. Maybe the world should switch to RelaxNG... another great OASIS standard. Then we might be able to know what we are doing. With XML Schema, all too often, the meaning is obfuscated by the syntax.
Posted by Matt McKnight at 10:18 PM
Friday, November 25, 2005
Google Analytics- amazing how something this cool got so much bad press. It seems to be a natural human tendency to try and cut down those who are doing well. Anwyay, this picture [click for the larger size] shows where you all (the measured readers of this blog in non-rss form) are located (with the exception of India, who was cut for purposes of scale). Very interesting, I think it's hackable into a Google Local map.
Posted by Matt McKnight at 10:35 PM
Just wrapped up reading this one on my flight from IAD to SFO: Agile Estimating and Planning, by Mike Cohn. It has some very practical direction on how to put agile planning practices in place. I think a lot of people need materials that are pretty detailed. I agree with the principle that methodologies should be adapted to fit the needs of the teams, but having all of the options laid out makes that a multiple choice decision, rather than a free response.
I faced the very trials that he described when attempting to figure out how to put story points or ideal days in place for size estimates. Ideal days do make that initial hump of estimating easier- they give people a frame of reference. Once we did that a couple of times though, I just switched to a couple of size measures (Extra Small (0), Small (1), Medium (3), Large (5), Extra Large (10)) and everything bigger than 10 ideal days had to be split into smaller tasks. At that point, the numbers were just relative sizes, and we could call them points without anyone thinking we weren't being serious.
The one place that I thought the book fell down was the one thing I was really looking for advice on, how to transition from that list of things that you are about to tackle in an iteration to the particular assignments that have to get handed to developers. Mike recommended doing some detailed estimates at that point, down to the hour level. I have to say I am closer David Anderson's approach on that point. Don't estimate at that level. However, I think David's all or nothing approach of doing no estimating is really only appropriate for Feature Driven Development, where all of the features are roughly equal. With the approach we usually take, bug fixes and everything else have to get factored in there, and there can easily be order of magnitude differences between the amount of work for each work item/task. However, coming up with the size estimates is pretty easy when there are only 5 choices.
So, Mike's book is good- far more practical than most of the other agile management books that seem to be coming out of the woodwork... You should check it out. The price jumped up pretty high on Amazon, but it's worth it.
Posted by Matt McKnight at 9:59 PM
Wednesday, November 23, 2005
This one makes even less sense than proprietary APIs- there is criticism of KML claiming that it is a proprietary format. I suppose the comparison is to GML, which is supposedly a non-proprietary format. In what sense is KML proprietary?
- It's an open format. Published on the web. Documented.
- There is no use restriction on the format. Other vendors and developers are encouraged to use it.
- It is widely used and implemented by a growing variety of vendors.
- Suggestions and comments on the format are accepted via a public forum.
- Even the compressed binary format (KMZ) is just using the common zipfile compression algorithm, which has implementations on every operating system and modern programming language, rather than something that you need to buy a seperate product to use.
It would appear that the only salient difference in proprietary-ness is that KML was developed by a single company (albeit with input from others), whereas GML was developed by a standards committee. The salient difference in the marketplace is that KML is usable and hand-editable, whereas GML is rather too complex for use without tools. In contrast to what one might expect, the standards committe developed format requires tools to create, whereas the one developed by Keyhole does not. Then again, looking at the history of the OGC, they were primarily pushed forward by the other vendors attempting to cooperate in opposition to dominance in the marketplace by ESRI and ESRI formats such as the shapefile and the arc .e00 formats, which had become the accepted interchange formats for vector data. This infighting has led to OGC standards in most cases being worse than standards which have been defined by individual vendors.
So far they have only been able to come up with "superset" type standards which have been overly philosophical in their approach- not designed with implementation efficiency in mind. I think there is a something to be said for formats that have been proven with a high performing implementation. Think of a reference implementation, such as Apache Tomcat now is for the Java Enterprise Edition for the Servlet specification. It is possible to create a poorly defined or bloated spec such that the implementations are going to be burdened by poor performance.
The proprietary label should be reserved for those formats which are protected by copyright or obfuscation and don't allow for open use- think of the various DRM music formats offered by Apple and Sony- not an XML format that is documented on the web. And oh yeah- ESRI is supporting KML now too- if you need any more proof that it's not proprietary, you must work on a standards committee. I've been there, I'm not going back.
Posted by Matt McKnight at 10:23 AM
Tuesday, November 22, 2005
I have always been a prety big fan of Ray Ozzie of Lotus Notes and Groove fame. I think he has really nailed all of the complexities of synchronization and replication in his products. If you compare how long it takes to set up replication for a Notes database to how long it takes for an Oracle database, you will see what I mean.
Another technology that I have been a big fan of since discovering it is RSS. RSS is dead simple- an XML format for html links and their summaries. It is a bit of a mistake to call it "a format", since there are several popular versions of RSS and Atom out there. The whole concept of having an RSS feed for a site, search, or topic that you are interested in is that you can have a tool watch that file for changes, and then display the summaries of the new content to you, allowing you to decide if you want to click on the link to the original source.
Now, Mr. Ozzie likes the dead simplicity of RSS, and thinks he can do the whole magical synchronization/replication thing one more time, but this time with a creative commons licensed standard that will do it for the whole web. His first little example is a calendar. I love it because my whole team has this problem while working at customer sites without their mobile devices. I also love it because it almost seems like he developed this whole technology to solve a problem that he and his wife were having with synchronizing their calendars. In two weeks. And if it's going to be in Office/Outlook/Exchange, it's going to be a viable solution for the whole internet. This may mean no built-in iCal for Outlook, but maybe we don't need that anymore.
Posted by Matt McKnight at 9:37 AM
Although they are on Debian, these instructions seem pretty detailed.
I am looking to do this soon with my little HR system. I also have a strange desire to write an agile planning tool, but do it mostly as an integration project. I am interested to see how Rails does as glue code versus how it does building apps. I have a feeling it will do well.
Posted by Matt McKnight at 9:29 AM
Monday, November 21, 2005
Kent Beck describes developer testing as one of the XP practices that can done on your own. In other words, you can do it without any buy-in from the rest of the team. You can load up JUnit for free and then start testing.
If your code is noticably better, if other people have the tests as a guide to how to change your code, people might get interested. If there are skeptics, you have to wait for that “teachable moment”- when they have a tricky bug that you can help them fix by writing a test, running the test, making a little change, running the test, repeating until it passes. Little by little, opinion can change that way. Just repeating “we need to do developer testing” doesn't have the same effect.
Working on your own does have disadvantages. Finding a community of people that can help you make the change. Even if you're the only one doing developer testing on your project, reach out across your company, reach out for like-minded individuals.
Posted by Matt McKnight at 10:42 PM
In this discussion over at TSS, the concept of proprietary APIs came up, with Hani Suleiman labeling Hibernate and TopLink proprietary, and EJB 3.0 as non-proprietary. I have seen this logic again and again, and it is wrong.
Nothing makes the API of Hibernate more proprietary than EJB 3.0. You could argue that one API is defined by the implementors and the other API is defined by vendor approved expert groups, but which is which? The difference is that there is only one proprietary implementation of the Hibernate API at the moment, and there will probably be multiple proprietary implementations of the EJB 3.0 API. The very nature of published APIs is that they cannot be proprietary, only the implementations can be. While there can be copyright or other restrictions on them, those generally are not published. See .Net versus the Mono project. There is nothing but time to stop BEA from putting out their own Hibernate 3 compatible code that is optimized for their app server, it might even be worth it for them to do so.
Another important thing to think about is which APIs are better- those designed by committees to address the needs of everyone, or those that solve specific problems? If we were talking about applications, I would choose the latter. I might do the same for APIs.
Posted by Matt McKnight at 11:28 AM
Friday, November 18, 2005
While I am not sure they have finished scaling the response processing, the user application for Analytics is now quite responsive, and is just really a cool web app. Here's my question- why no GoogleMaps integration?!? Every twobit js hacker with a dot to plot is doing gMaps integration, and these guys have a doinky flash map that zooms in on everything (not just the map, the label text gets massive too).
Still, better than I had last week, which was nothing. I wonder about this whole "free stuff" strategy though. It seems like Microsoft used to do the same thing, and ended up getting a really bad name for putting little companies out of business. I guess we can be glad that Google at least buys one of the little companies before it makes the products free, but the competitors are going to be hurting. The other problem with free is that implies that the product has no value, or is annoying (adware). Somehow Google have made adware palatable by limiting it's reach. Reminds me of the anchor reading the sponsors' messages on NPR compared to the other stations where the commercials blare at 150% of the normal volume with some jerk shouting.
Posted by Matt McKnight at 11:16 AM
Tuesday, November 15, 2005
Pissed at Google: "We seem to be hearing from more people that Google doesn't do that great a job outside of its core focus, search. So again, when Google decided to make its Web analytics software free yesterday, some people weren't happy with how the company handled it. They were pissed, says Ethan Stock, chief executive of valley events start-up Zvents. "
Well, they should have done the gmail thing and scaled this thing gradually. This was just too good. The Zvents guys doesn't get it either, they did cut off signups pretty quickly. But it looks like it was already too late for them to serve up their current customers.
I think one idea for scaling things up would have been to keep current customers on the existing infrastructure. I have to assume they had no idea how many people were looking for a cheap and easy web analytics solution.
Posted by Matt McKnight at 4:58 PM
Monday, November 14, 2005
Posted by Matt McKnight at 3:20 PM
Tuesday, November 08, 2005
How To Use CIA For Continuous Integration: "CIA runs on the server where your Subversion repository lives. It watches for commits, checks out the most recent tree of the related project, and runs all the unit & functional tests. If there are failures, they are logged to the database, as well as emailed to a pre-configured address."
It seems like many of the CI tools have interesting names- Cruise Control, Damage Control, now CIA. Beyond the names though, anyone doing team development needs to be doing this.
Posted by Matt McKnight at 3:53 PM
The Day When Microsoft Pays You To Use Their Software: "An opinion piece over at Silicon.com is joking about how Bill Gates should be paying people to use Windows in response to a Bill Gates comment that Google should be paying people to use its search engine....Meanwhile, with Microsoft's recent announcement that they're focusing on software as a service, they did clearly say that they expect much of it to be ad supported. While many people question whether or not they can actually pull that off, if they can, how hard is it to leap from ad-supported software to 'make money' supported software?"
If everything is ad supported, who's going to buy the ads? It sounds like a bubble to me.
Posted by Matt McKnight at 3:49 PM
Friday, November 04, 2005
Ruby is nice, it's a very concise Object Oriented language with a good community around it. But there is some weirdness. One selling point of Ruby is that it is dynamically typed- you don't have to declare variable types, which allows for a lot of flexibility. However, there is a cost in that those of us lazy types that have been saving the part of our brain that remembers and types out method names on objects for more important things. Well, I'm actually just letting that part of my brain rest. Now, with Ruby, I can't hit the [.] key and get a list of all of the legal calls, because, I could literally type anything and it would work. There is a magic thing called method_missing that lets you call things that don't exist.
Anyway, I think I should at least be able to get the list methods that are available in the object and its super classes, if the IDE knows what class we are dealing with, which is possible when you have the types declared. I am downloading Komodo now to see if that pans out, results here tomorrow?
Posted by Matt McKnight at 12:49 AM
Thursday, November 03, 2005
Posted by Matt McKnight at 3:27 PM
The new Yahoo!Maps beta looks like a decent ripoff of Google Maps GUI. They added a very cool overview window that previews your zoom extent. They even updated the Ajax API. Very nice. I was a little disheartened to see all of the Flash APIs. I really hope web development doesn't go in that direction, as I don't really like the interaction between those components and the rest of the page. However the JS-Flash API appears to make everything accessible with no Flash programming required, so maybe that is least evil way forward.
Posted by Matt McKnight at 2:52 PM
Tuesday, November 01, 2005
I used to work for a government customer that had (has?) a hideously bloated and rigid process for building software systems, that completely forgets about the actual building of it. I recognize and appreciate the parts of that process that have to do with project selection and budgeting and the like. However, it has completely glossed over the building of the actual software. In a 3 year schedule template, only 30 days are devoted to actual development. It's inside out. It also doesn't work.
Anyway, I was in there before trying to sell agile processes- and basically failing. It was hard enough to get them to buy into iterations, becuase their whole mindset was based on control gates as the measure of progress. Of course, the only control gate with any teeth was "user acceptance review", so you had to wait until the bitter end of the project to find out how far things were off course.
Now I am realizing that the agile process I was trying to introduce need to be sold as MORE process, not less, as I had presumed. We are really addressing massive gaps in their structure. The problem becomes layering this inside of a existing framework of control gates. So, if we have a systems requirements review, the waterfall methodology suggests that we cannot pass this control gate until we have all of the requirements gathered in specific enough detail to begin design. Of course, this is an out of control gate you just sail through, unless your reqs happen to tramp in someone else's turf, in which case you have to fight to have a widget in your app, because some other project is in charge of those types of widgets.
The real mindset change is, after a certain point, replace control gates with measures of actual progress, such as running features. But how do we know if the requirements are right if we don't have a requirements review control gate? Well, first, the control gate never did work, so maybe the requirements review=the acceptance test. The only control gate with real teeth is the one we should use. How do we validate the design? Performance test it. By bringing these tests earlier in the cycle, I feel like there is a way to actually evolve the current process, rather than to blow it up.
Agile is scary for lots of reasons, but I think they are good reasons. It's kind of scary to say that you have to have working code early enough to do an acceptance test on it at the beginning, but that's exactly the kind of scare that is need to ensure quality gets built in from the start. It's kind of scary to give up control gates, but what about replacing these control gates with ones that actually have teeth? It means you might fail earlier, rather than being able to coast along for a long time without having to show results.
Posted by Matt McKnight at 12:38 PM