If you know any students who are interested in open source software, the Google Summer of Code is a great opportunity. Encourage them to apply. The application period is open now and ends April 3.
One thousand students will be paid $4500 by Google for a summer of working on open source projects and will be mentored by experienced open source developers. To my mind, the experience and mentoring is almost more valuable than the case (although obviously that varies greatly depending on the economic situation of the student).
If you look at the list of projects, you'll see that there's something for every taste. Projects range from low-level bit banging in C on bare iron to bioinformatics to games to a wide variety of so-called "social" apps in a wide variety of different programming languages. Students and mentors come from almost one hundred different countries as well, so there's an enormous amount of diversity on that front as well.
I've been a mentor for three of the four years the program has been in existence (2006, 2007, 2008) and last year had the satisfaction of seeing one of my original students become a mentor himself. It's a lot of work, but very satisfying. Unfortunately my project won't be participating this year due to a combination of cutbacks at Google (about 10%) and a desire to rotate in new organizations, but the ArgoEclipse team would still love to mentor any new folks, students or other, who are interested in getting their feet wet with open source development.
26 March 2009
11 March 2009
Freebase, open government, and enumerations
I'm preparing a short series of articles about Freebase, but Raymond Yee had a question about something I was working on over the weekend, so here's a quick hint to help him along.
What he calls "keys" are called "enumerated properties" in the Freebase documentation and there's an article on how to set them up. Unfortunately, the schema editor was broken when I was working on the National Register of Historic Places database schema, so I had to resort to reverse engineering things from the Explore view (accessible by pressing F8 on any page and scrolling to the bottom of the page) and then modifying the schema's property type by hand using their MQL query language. You can see the end result in the schema where item_number is typed as an enumeration.
There's also a good article on how to create a URL template that I used successfully to link to the original application submissions. For the Congressional Bioguide, it can be used to link back to the original biography.
Coincidentally and independently from Raymond's project, I was actually working on loading up all the Congressional Bioguide ID's last weekend because they are used in the XML form of legislation on THOMAS, which is run by the Library of Congress. I decided to take a slight detour to write a little name parser and Freebase name queryer in Python, so haven't actually gotten around to loading the IDs yet. One of the biggest problems in working with Freebase is reliably resolving personal names. They typically only have the main name that was used as the Wikipedia article name. There's really no telling what name form the article's editors will have chosen and even though the full name and some aliases are often identified in the opening sentence of the article, Freebase doesn't import this information from Wikipedia.
What he calls "keys" are called "enumerated properties" in the Freebase documentation and there's an article on how to set them up. Unfortunately, the schema editor was broken when I was working on the National Register of Historic Places database schema, so I had to resort to reverse engineering things from the Explore view (accessible by pressing F8 on any page and scrolling to the bottom of the page) and then modifying the schema's property type by hand using their MQL query language. You can see the end result in the schema where item_number is typed as an enumeration.
There's also a good article on how to create a URL template that I used successfully to link to the original application submissions. For the Congressional Bioguide, it can be used to link back to the original biography.
Coincidentally and independently from Raymond's project, I was actually working on loading up all the Congressional Bioguide ID's last weekend because they are used in the XML form of legislation on THOMAS, which is run by the Library of Congress. I decided to take a slight detour to write a little name parser and Freebase name queryer in Python, so haven't actually gotten around to loading the IDs yet. One of the biggest problems in working with Freebase is reliably resolving personal names. They typically only have the main name that was used as the Wikipedia article name. There's really no telling what name form the article's editors will have chosen and even though the full name and some aliases are often identified in the opening sentence of the article, Freebase doesn't import this information from Wikipedia.
24 October 2008
Mobile Internet World was tiny!
I swung by the Yankee Group's Mobile Internet World show in Boston yesterday to check out what was going on. Google's Rich Miner, the head of the Android effort, was doing a Q&A at 2 pm, so I figured I'd see what folks were asking him and check out the vendors on the show floor.
The show was tiny! Boston has two convention centers and when I arrived at the BCEC, things were so quiet that I was worried I was at the wrong one. I eventually wended my way to the back corner where the show was being held and found the show floor. There were only a couple of dozen vendors present and only three of those had anything other than the tiny pipe and drape style displays. I bumped into Derek Speed who I knew from Digital Semiconductor showing off the Moblin SDK for Intel, which was fun, but other than that it was pretty disappointing.
There were perhaps 80-100 people at the Google Q&A (or about 25-30% of the turnout that they had for their developer day in Cambridge last year). In addition to Rich Miner, they also had Justin Mattson from their developer program there to answer questions.
Nothing earthshaking was revealed in the Q&A. Rich said that the early reviews from the media were at the high end of the range of what he thought was possible. He was also pleased with the T-Mobile pre-sales. As for futures, he thought they could do a better job with integrated search (phone + web) and multi-modal search (voice), but didn't say anything about when/if that would be improved.
One thing that I missed before was that the App Market popularity would be computed on both downloads and usage, so they must be uploading usage stats. Rich said there was no plan to expand the app market to content types other than apps because it wasn't a profit center for them.
If they have the show again, I'll definitely look more carefully at the exhibitors list before deciding whether it's worth even an hour or two.
The show was tiny! Boston has two convention centers and when I arrived at the BCEC, things were so quiet that I was worried I was at the wrong one. I eventually wended my way to the back corner where the show was being held and found the show floor. There were only a couple of dozen vendors present and only three of those had anything other than the tiny pipe and drape style displays. I bumped into Derek Speed who I knew from Digital Semiconductor showing off the Moblin SDK for Intel, which was fun, but other than that it was pretty disappointing.
There were perhaps 80-100 people at the Google Q&A (or about 25-30% of the turnout that they had for their developer day in Cambridge last year). In addition to Rich Miner, they also had Justin Mattson from their developer program there to answer questions.
Nothing earthshaking was revealed in the Q&A. Rich said that the early reviews from the media were at the high end of the range of what he thought was possible. He was also pleased with the T-Mobile pre-sales. As for futures, he thought they could do a better job with integrated search (phone + web) and multi-modal search (voice), but didn't say anything about when/if that would be improved.
One thing that I missed before was that the App Market popularity would be computed on both downloads and usage, so they must be uploading usage stats. Rich said there was no plan to expand the app market to content types other than apps because it wasn't a profit center for them.
If they have the show again, I'll definitely look more carefully at the exhibitors list before deciding whether it's worth even an hour or two.
Building Google's Android on 64-bit Linux
This week Google released the sources for all the open-source components of Android including the kernel, the frameworks, the SDK, and most, but not all, of the bundled apps.
My laptop is a dual boot system that mostly runs Windows, but Linux and OS X are the only supported Android build environments, so I fired up Linux (64-bit Ubuntu 8.04 Hardy Heron). Things don't quite build out of the box for 64-bit Linux, so here are some tips to get you going.
In addition to the dependencies listed at http://source.android.com/download#TOC-Linux you'll also need the following:
Follow the rest of the directions on the Android site to install their repo tool (and git if you don't have it), fetch sources, and then do
My laptop is a dual boot system that mostly runs Windows, but Linux and OS X are the only supported Android build environments, so I fired up Linux (64-bit Ubuntu 8.04 Hardy Heron). Things don't quite build out of the box for 64-bit Linux, so here are some tips to get you going.
In addition to the dependencies listed at http://source.android.com/download#TOC-Linux you'll also need the following:
$ sudo apt-get install ia32-libs g++-multilib gcc-multilib lib32z1-dev lib32ncurses5-devThere's an additional problem with a missing softlink to the 32-bit version of the X11 client library that you can resolve as follows:
$ cd /usr/lib32It really ought to be included in one of the standard packages, but doesn't seem to be on Ubunto (the shared library itself is included in ia32-libs however).
$ sudo ln -s libX11.so.6 libX11.so
Follow the rest of the directions on the Android site to install their repo tool (and git if you don't have it), fetch sources, and then do
$ cd ~/mydroid (or wherever you put things)to build your own shiny version of Android from scratch. This took over an hour on my laptop, so be patient. When it's finished, you should be able to change to the results directory and running the freshly built emulator
$ make sdk
$ cd out/host/linux-x86/sdk/android-sdk_eng.You should see an Android emulator window pop up on your screen running your freshly built code._linux-x86
$ tools/emulator
17 October 2008
What's wrong with UML?
The catalyst for finally starting a blog was Kenn Hussey's post about What's Wrong with UML... I wanted to contribute to the discussion, but my comments would have been way too long for that little tiny comment box.
Apparently the Object Management Group (OMG) has asked its members to come to the next meeting with a list of their top three things which are wrong with UML. Wow! Where to begin?
Without meaning to criticize Kenn, because I think he's done more than almost anyone to help open up UML and the OMG process, I think his list is made from much too much of an insider's perspective. Here's his list:
Interoperability - The dirty little secret of all the UML tool vendors is that there simply is none -- and no one cares. I could go on about XMI this and MOF that, but let's start with the basics. UML is a visual/graphical modeling language. There is absolutely no way to interchange the graphical representation. WTF? With a little bit of luck, a consultant who's got a bag full of XSLT scripts, and two tools that don't stray too far from the spec, you might be able to get the semantic contents of your model across from one tool to another, but what about all those diagrams that you spent days and weeks slaving over? All completely gone. You'll need to redraw them from scratch. Sure, a spec for UML Diagram Interchange was promulgated (six or seven years after the initial UML specs were released), but no one's implemented it and the Eclipse folks have said that they consider it unimplementable so they're going to work to get their own standard adopted instead.
Even if we just look at the semantic contents of the model, as serialized in an XMI file, interoperability is very dodgy. Different tools have different bugs in their XMI reading/writing code which don't get fixed, vendors use proprietary extensions, and different tools implement different versions of the spec, but the biggest problem is that there's no systematic focus on improving interoperability. It's been broken so long that people don't expect it to get fixed. Each customer is own their own to fight with their own specific vendor and the vendors believe they have no incentive to fix the problems since it helps guarantee vendor lock-in. (They're wrong in their belief that this is to their economic benefit, but that's another story).
Compatibility - I mentioned different tools implementing different versions of the spec. Why is this important? Because the OMG has paid absolutely zero attention to compatibility between versions. UML 1.5 is the only version which was a pure superset of the previous version. In every other release, they've made incompatible changes at multiple levels of the specification. Not only have they changed the language itself in incompatible ways, but they've incompatibly changed the metamodel that's used to define it and the file format that's used to serialize it. Two tools which both implemented UML 1.3 wouldn't be compatible if one serialized using XMI 1.0 and the other serialized using XMI 1.1, let alone if one implemented UML 1.3 and the other implemented UML 1.4
This has an obvious negative effect on interchange/interoperability, but it has impacts throughout the modeling ecosystem. Vendors waste engineering effort reimplementing things just to conform to the new specification. Customers have to upgrade tool chains in lock-step and may not be able to upgrade at all if even a single vendor lags. Downstream standards groups working on modeling standards for bioinformatics, finance, or health care have to either freeze on an old standard as their basis or let the incompatibilities ripple downstream to their consumers.
UML 2.x deserves a special mention here because it is such a massive dislocation in the time/space continuum. In addition to the normal changes in the layer above (MOF) and the layer below (XMI), fundamental concepts of the UML itself were completely thrown out and reinvented for UML 2.x. These changes were so extensive that the OMG didn't even attempt to produce a change-barred spec or keep a comprehensive list of them. Instead entire sections will have a tiny little note at the end that says something like "This concept from UML 1.x has no equivalent."
Object Management Group (OMG) - This is probably going to seem harsh, and since they're local, I may even have friends working there, but I believe both of the problems above, and many of UML's other problems, can be traced back to the OMG and how it works. I'll reserve detailing the problems for a separate post, but they can be summarized as:
As far as UML goes, there are any number of problems which could be enumerated, but if the interoperability nut could be cracked, they could build the momentum to address the other problems.
UML has been around since 1999 and its whole raison d'être is to be the lingua franca of the modeling world. Why not make it a goal to actually achieve this aim before the 10 year anniversary rolls around?
Apparently the Object Management Group (OMG) has asked its members to come to the next meeting with a list of their top three things which are wrong with UML. Wow! Where to begin?
Without meaning to criticize Kenn, because I think he's done more than almost anyone to help open up UML and the OMG process, I think his list is made from much too much of an insider's perspective. Here's his list:
Let's take a few giant steps back here to get a little bit better view of the problem from the point of view of a UML user. As someone who's spent years working on an open source UML editor where I actually have to deal with users who are affected by this problems as they try to do their work, let me give you my list:
- Un-intended inheritance
- Undefined namespaces for standard stereotypes and primitive types
- Inability to create a usable XML schema for UML
- Lack of Interoperability
- Incompatibility
- The OMG
Interoperability - The dirty little secret of all the UML tool vendors is that there simply is none -- and no one cares. I could go on about XMI this and MOF that, but let's start with the basics. UML is a visual/graphical modeling language. There is absolutely no way to interchange the graphical representation. WTF? With a little bit of luck, a consultant who's got a bag full of XSLT scripts, and two tools that don't stray too far from the spec, you might be able to get the semantic contents of your model across from one tool to another, but what about all those diagrams that you spent days and weeks slaving over? All completely gone. You'll need to redraw them from scratch. Sure, a spec for UML Diagram Interchange was promulgated (six or seven years after the initial UML specs were released), but no one's implemented it and the Eclipse folks have said that they consider it unimplementable so they're going to work to get their own standard adopted instead.
Even if we just look at the semantic contents of the model, as serialized in an XMI file, interoperability is very dodgy. Different tools have different bugs in their XMI reading/writing code which don't get fixed, vendors use proprietary extensions, and different tools implement different versions of the spec, but the biggest problem is that there's no systematic focus on improving interoperability. It's been broken so long that people don't expect it to get fixed. Each customer is own their own to fight with their own specific vendor and the vendors believe they have no incentive to fix the problems since it helps guarantee vendor lock-in. (They're wrong in their belief that this is to their economic benefit, but that's another story).
Compatibility - I mentioned different tools implementing different versions of the spec. Why is this important? Because the OMG has paid absolutely zero attention to compatibility between versions. UML 1.5 is the only version which was a pure superset of the previous version. In every other release, they've made incompatible changes at multiple levels of the specification. Not only have they changed the language itself in incompatible ways, but they've incompatibly changed the metamodel that's used to define it and the file format that's used to serialize it. Two tools which both implemented UML 1.3 wouldn't be compatible if one serialized using XMI 1.0 and the other serialized using XMI 1.1, let alone if one implemented UML 1.3 and the other implemented UML 1.4
This has an obvious negative effect on interchange/interoperability, but it has impacts throughout the modeling ecosystem. Vendors waste engineering effort reimplementing things just to conform to the new specification. Customers have to upgrade tool chains in lock-step and may not be able to upgrade at all if even a single vendor lags. Downstream standards groups working on modeling standards for bioinformatics, finance, or health care have to either freeze on an old standard as their basis or let the incompatibilities ripple downstream to their consumers.
UML 2.x deserves a special mention here because it is such a massive dislocation in the time/space continuum. In addition to the normal changes in the layer above (MOF) and the layer below (XMI), fundamental concepts of the UML itself were completely thrown out and reinvented for UML 2.x. These changes were so extensive that the OMG didn't even attempt to produce a change-barred spec or keep a comprehensive list of them. Instead entire sections will have a tiny little note at the end that says something like "This concept from UML 1.x has no equivalent."
Object Management Group (OMG) - This is probably going to seem harsh, and since they're local, I may even have friends working there, but I believe both of the problems above, and many of UML's other problems, can be traced back to the OMG and how it works. I'll reserve detailing the problems for a separate post, but they can be summarized as:
- Industry trade group, not a standards body
- Don't eat their own dog food
- Closed to participation by individuals, (most) users, and open source groups
- Too slow
- Too fast (ie not careful enough)
As far as UML goes, there are any number of problems which could be enumerated, but if the interoperability nut could be cracked, they could build the momentum to address the other problems.
UML has been around since 1999 and its whole raison d'être is to be the lingua franca of the modeling world. Why not make it a goal to actually achieve this aim before the 10 year anniversary rolls around?
Subscribe to:
Posts (Atom)
Posts
