Well, OSCON 2005 is over. It's been over for like, two days now, so I guess I should come to grips with it. Seriously, my return to the Bay Area coincided with a Rushabh visit, so I have had "the busy". I have a few things that I want to note about the conference, however.
The keynotes on the last day were pretty good. In fact, most of the keynote speeches (aside from the vendor ones) were pretty good. I have to say that I like the new 15-minute format -- it tends to cut down on the speeches that seem last forever, and bring the focus down to the good stuff. Case in point, I really liked Asa Dotzler's talk about Linux vs. the desktop. I mostly agree with what he had to say, namely that there are some migration issues, and more importantly some usability issues, for people that are trying to come to Linux from Windows.
But more so than that, I think that there are issues of innovation as well: People need a reason to switch their computer from one OS to another. And while I think that increased security and cost are two super-great reasons to switch to Linux, I don't think that those reasons are enough to get people switch to Linux in droves. Most people don't think about security, nor do they think about the cost of Windows (it is bundled in the cost of the computer, so they don't really notice it).
Anyway, after Asa's speech, I was kindof bummed, because I think that making a usable interface is hard work -- requiring usability experts, who conduct studies of users, focus on the interface, and refine it until it is great. And I wasn't really sure how free software was going to be able to get this sort of work. Thankfully, the end of OSCON was capped by a great talk from Miguel de Icaza, who addressed these issues and more.
First, Miguel talked about the work that Novell is doing on Linux, including doing usability testing with actual users! Wow! I was wondering how such a feat would be accomplished in the Open Source world, and I see that funding has come in to make it happen. But what's more important, is that the methodology that they used could be duplicated and repeated by the community. All you need is two cameras, the right software, and a whole bunch of time. So, I am heartened to think that Linux and GNOME might actually, eventually "get there" in terms of usability.
Finally, Miguel ended his talk by showing off Xgl. I haven't been able to find a lot of information about this, but basically it is an X server that outputs to OpenGL. This means that you get massive amounts of hardware acceleration, which can be used to do cool UI effects. Miguel demonstrated wobbly windows (the windows wobbled like jelly when dragged), virtual desktops on a 3-D cube (ala Fast User Switching in OS X, but better), an Exposé-like feature (again, from OS X), and finally, real translucent windows. All in all, the demo was amazing. But even more amazing, the Linux desktop now has a solid platform, in which really innovative things can start to be created. And hopefully, it is in this innovation, that cool new features will be created, which will compel people to start switching to Linux in droves.
Or, if not to Linux, at least to MacOS X... :)
-Andy.
Groovy is a Java-friendly kindof language. Java strengths: lots of reusable software, components and tools. VM and Binary compatibility, eases deployment. Allows for innovation at the source code level, as long as it produces JVM-compatible bytecodes. We reuse more than we write -- most code written is glue, bringing components together. Scripting is much better suited to this purpose. The reason for another Agile Language is that they want to be able to reuse all of the Java components and architecture that exist.
Groovy has been around since 2003, JSR-241. Has features of Ruby, Python, and Smalltalk. Uses ANTLR and ASM Java compilers (?). Features dynamic typing, with optional static typing. Native syntax for lists, maps, arrays, beans, etc. They also have closures -- chunk of code that can be passed around as first-class object. Regular expressions are built-in (w00t!). There is also native operator overloading, so if you add two arrays, the result is a concatenation. Basically, strings, lists, maps etc. work like you would expect -- Groovy takes care of a lot of the heavy lifting, and makes these things much easier to deal with. Groovy also adds some nice helper methods and such to the JDK.
They have a '?' operator, that will test an object for null, and cause the entire expression to return null, instead of returning an NPE. Expando (groovy.util.Expando) is a dynamic object. Create an Expando with some properties, and you can keep chucking stuff into it, in a free-form manner.
Groovy supports "currying" for closures, which is a little strange. It seems like it is the |var| thing in Ruby. Basically, you can define a block of code, which has some variables in it that you don't know what will be at the time of definition. Later, you can call the curry() method, and pass those data elements in. Groovy will fill in the variables in order - each time you call curry(), it will fill in the first, second, third, etc. variables.
Demos - XML-RPC is one of the cool features of Groovy. In the demo, there is a "groovysh" command, which is an interactive shell into the interpreter, much like Python or Ruby offers. There don't appear to be any semicolons at the end of line in Groovy. The demo shows Groovy interacting with Excel (using a wrapper around WSH), and then a Swing demo. Actions are properties of buttons, which is nice. Groovy looks like it could simplify cranking out quick Swing GUIs.
Some Groovy extras: process execution, threading, testing, SWT, Groovy Pages/Template Engine, Thicky (Groovy-based fat client deliver via GSP), UNIX scripting (Groovy API for pipe, cat, grep, etc.), Eclipse plugin (needs more work).
Perfomance isn't as good -- 20 - 90% of Java. Development time is much less than Java, but debugging kindof sucks. Ready for small non-mission critical stuff right now.
-Andy.
The Ubuntu BOF was pretty good. We had about nine people there, spanning seasoned pros like Jeff Waugh and newbies like myself. Since I called the BOF to order, I got to ask a lot of stupid questions, and luckily I got them all answered. What follows is some random notes that I scribbled down in a sticky:
Regarding repositories, my questions were around problems that I am encountering when I put in some quirky repositories (Multiverse and beyond). The problem is that the Ubuntu update thingy will look at all repositories, and start giving you packages from the non-stable area. Jeff recommended the following:update-rc.d --> manage startup scripts in Debian / Ubuntu. All this does is to manage the symlinks, I think. In Debian, everything in /etc/rc2.d that is executable will be launched -- there is no funny business.
For questions about the mythtv packages on Ubuntu, I was told to IRC. On the Freenode servers, #ubuntu, I should talk to mdz (Matt Zimmerman) about the mythtv package. I suspect that there might be a bug in the startup sequence, so that mythtv-backend doesn't start properly on boot.
Debian documentation is installed with Ubuntu and applies to Ubuntu.Ubuntu is building a linux hardware database - Ubuntu Device DB (system tools). Can report to central server. This allows the Ubuntu folks to press hardware vendors to support Ubuntu -- because they can back that need up with actual usage statistics.
Finally, someone told me that I can use "evolution --force-shutdown" whenever I want to restart Evolution cleanly, rather than just killing all of the processes. I'll have to try that the next time Evolution crashes.
XMPP is an IETF standard now (happened last year). Great for building custom applications because it is simply streaming XML. Speaker knew of a company that built server monitoring infrastructure on XMPP (when a server went down, it sent an XMPP message to the appropriate tech).
Jive Messenger is the premier OSS Java Jabber server. Good performance, web-based admin console, just released version 2.2, and integrated with Asterisk -- so they have VoIP integration (closing in on unified messaging).
XMPP client libraries: Smack and JSO. For simplicity and ease of development, Smack is the best. Other libraries have extra bells & whistles.
A port of the Perl 5 runtime to the Parrot interpreter (used by Perl 6). Allows you to run un-modified Perl 5 code on Perl 6. The focus is on Perl 5 XS, which appears to be the Perl module standard. Hence, the idea is to be able to run the CPAN modules that use XS on Perl 5 on Perl 6.
Perl 5 VM:Goal is to write and run Perl 6 code, run existing Perl 5 code, and run code that links to external libraries (XS). Call back and forth transparently. Pass data back and forth. Then we can convert Perl 5 code function by function to Perl 6 (nice).
After going through some problems with inline, the conclusion is that you need to have the code executing within one VM, with a single runloop. Can't compile Perl 6 code to Perl 5 -- VM not modern enough. Reverse is also hard -- Ponie provides another way. The Perl 5 language is defined by the C source (since there is only one implementation, and some quirks that aren't documented). There is a lot of complexity in how Perl 5 has been implemented, that must be bridged to get it working in Perl 6. There is a need to unify data storage, so Perl 5 data must be wrapped, so that it can be stored in Parrot.
Ponie is a big refactoring exercise. Work is linear -- each task depends on a previous task. Finding many bugs in the Perl 5 core. Fixing these, and making some improvements in Perl 5 core. What is still a little unclear from this talk, is how Parrot will actually work when it is finished. It looks like it will be integrated with Perl 6, and allow seamless execution of Perl 5 code, but I'm not sure. There might be an option to invoke it, or something.
-Andy.Talk is in praise of SOAP, but not to talk trash about REST. Simpler protocols are great, but SOAP has it's place as well. REST stands for "REpresentational State Transfer, and everything is based on URI. Relies on HTTP verbs (GET, POST, HEAD, PUT, and DELETE). Encodes parameters and details in the URI. Where REST is simple and straightforward, SOAP is complex and opaque. There is a basic spec for SOAP, as well as WSDL, WS-I, etc. XML-RPC is a third alternative, that sits in the middle -- encodes parameters and details in XML like SOAP, but uses HTTP POST like REST.
SOAP criticisms:The pitch is that REST and SOAP are not in direct competition. It is more like C vs. Java -- each tool has appropriate applications. Complexity is a gradient, not a binary switch. XML-RPC has SOAP beat in terms of number of implementations/platforms (80 implementations across 30 platforms). XML-RPC has some limitations that aren't being fixed in the spec?
More about complexity. Don't confuse complexity with detail -- Amazon can provide a lot of detail based solely on the ASIN in a REST call. It seems like one of the limitations of REST might be if you have variable-length arguments. Creating a REST URI that can accept this sort of data could be complicated and/or ugly. Is that the point of this talk? No way to define a contract with REST, as opposed to SOAP.
On the whole, I still don't understand what the benefit of SOAP is. It just seems like a massive PITA, and REST seems so much easier. Hmm...
-Andy.Need to download private headers. Apple really discourages the use of static libraries, to make the system more flexible, and easier to patch. Sometimes static libraries are needed by the system itself, so it is possible to build them. But Apple doesn't ship any static libraries by default.
Some internal tools are also needed: kextsymboltool, for example.
The good news is that DarwinBuild can track all of these potential problems, and can download all of the necessary bits to make compiling Darwin easy. It automatically sets up a chroot() environment, for example, so that build can be done without mucking with currently running system. You give DarwinBuild a release number (8C42, for example, which is 10.4.2), and it will fetch a plist file, which describes details of the build.
DarwinBuild can be used to build individual components, like bash for example. Just type 'darwinbuild bash', and it will fetch the latest sources, and do a build.
Next, we got a demo of using DarwinBuild to build a version of talk that has Bonjour support. Fairly nifty stuff. Using DarwinBuild, you can target specific releases of MacOS X -- building talk for a friend that is still running Panther, for example.I only had one person tell me that an Ubuntu BOF would be a good idea, but as it turns out, that is enough for me. I have signed up to do an Ubuntu BOF at 8:30 tonight (check the board for the room). Hope to see you there!
-Andy.
The links to the online evaluation forms are hard to find. So, here they are: Speaker and Session Evaluation form, and the Conference Evaluation form.
-Andy.
Creating an application is quite simple. There is a GUI environment, which you use to create a new application. Cross-platform, runs on Windows, Mac, and Linux. Dependent on wxPython underneath, which means that Mac is the least mature of all platforms.
The GUI design environment (the resource editor) is quite VB-like. You can drag and drop form elements, text labels, etc. PythonCard has runtime tools, including debugging, logging, and watching messages. Makes it easy to figure out what is going on in the application. There is also a built-in code editor. And there is also a python shell window that is always available. The shell has code-completion, which seems nice.
Stand-alone installers exist via the standard Python means (PyExe and some other packager for the Mac).
-Andy.Swik is "the free and open database of Open Source projects that anyone can edit". Trying to make better documentation for OSS projects. Also trying to make it easier to find OSS projects (solve the "which is the right project for me?" question).
For documentation, they looked into the Wiki concept. And because Wiki's are great, that is the route that Swik chose. Sounds like a simplistic Wiki -- they aren't using Textile or Markdown or anything.
For organization, they are pursuing tagging (ala del.icio.us). Don't need to worry about hierarchy or anything -- can just assign the tags that fit, and let the system sort it out. Tag analysis will afford another level of organization and capability for finding OSS projects (future).
Going back to documentation, didn't want to repeat documentation work that has already been done. RSS is the most popular way to get data about OSS projects. Aggregating RSS feeds for OSS projects? Also going after Web Services, for example using the freshmeat WS API to do integration with freshmeat.
From the demo, Swik looks very Google-like from the UI. Typing in a search term brings back a page that is a composite of several web services. Every project found builds a new record in Swik. This can be edited (Wiki-style), to add additional information, metadata (tags), etc.
I played around with Swik a bit, and it looks pretty cool. I added two projects, Unison and Joe, and it is pretty painless to get new data into the system. For the default homepage, it picks the Google "I'm feeling lucky" link, which I think is often wrong. The reason why, is because freshmeat doesn't publish the homepage for a project via their Web Service (and it might violate their TOS to spider it).
They are working on Open Sourcing Swik, and are soliciting comments about how to do it. Go to the Swik project on Swik to comment.
-Andy.
Now someone from Yahoo! is talking about a joint project between Yahoo! Research and O'Reilly Research, the Buzz Game. Looks like a way to hedge bets as to what will be "hot" in the coming months. Hotness is determined by search volume on Yahoo! search. Looks kindof interesting. Been out since March, but this is the first that I have heard of it.
According to their stats, Windows XP and Internet Explorer are still gaining buzz over Linux and Firefox, respectively. Whateva!
-Andy.
Okay, this conference is now officially super laid-back. You are supposed to wear your OSCON badge on a lanyard around your neck. And helpful attendants are supposed to check it every time you want to enter a pay-for part of the conference.
This is all well and good -- it is how most conferences work.
The problem is, it seems like the checks are totally lax. I took my badge off when I went to lunch, and I just now realized that I forgot to put it back on. I have entered the room for the XSLT talk twice now, and got acknowledged by the security person on the second time.
Wow.
-Andy.
At last night's blogging BOF (which I hope to write more about later), I asked how people were finding those who were blogging about OSCON. While I was aware of the part of the OSCON Wiki where people were putting information on their blogs, I didn't want to have to groom through all of those URLs in order to get the appropriate RSS feeds into NetNewsWire.
When I posed this question to the group, Casey West suggested setting up the Planet Planet software. While that is in and of itself a good idea, out of the box, the planet software requires an admin to add RSS feeds to the configuration. So, Casey followed that idea up with the notion of gluing a simple CGI to planet, which people could use to add their own blogs to the planet configuration (Wiki-style).
Whelp, we all agreed that it was a good idea, and now Casey has turned around and created it. Awesome!
So, if you want to play along with OSCON at home, this seems like the most definitive way to do so. I whole-heartedly suggest that you check it out.
-Andy.
Rails works by convention. It generates directory structure, and some stub files. This doesn't limit flexibility, because you can over-ride everything. What matters more is convention (where you put the braces, etc), not what the convention is.
Code/setup configuration do via generate command is the pathway into the generation engine in rails. You can create your own generators, to generate Rails apps that have your own custom elements (like authentication, etc). Use "./script/generate" to make a controller. Rely on convention that by default, controllers you create are exposed in URL based on their name (instead of having some nasty XML config file that makes this correlation). Based on how you refer to URL, some actions are assumed (no trailing slash, tries index action, for example).
Conventions:
For views, in order to process an action, Rails attempts to look in the views directory, to see if it can find a view that matches the action. If it finds a match, then it will apply the view to the output.
Rails does have a config file, in YAML format, which gets converted into a ruby hash automatically.
Just like generator, there is a companion command, called destroy. Can remove things that you create by mistake, etc.
Rails has automatic (default) model actions for different database types. If it finds a date/time type in the DB, it will automatically generate HTML to allow inputs for that type. Ordering on page corresponds to order of columns in DB table. Scaffolding is just for getting started, because look and feel will always need to be customized. The model queries the database, handling all of the necessary SQL by default. You can still plugin your own SQL, when it is needed. Models are created before making database table.
Need to key in model objects as to "what you mean" (many-to-one, many-to-many, etc). Use foreign keys in DB to do this. Convention is to call foreign key <table_name>_id, so that Rails can find the other table, and correspond it to the model for that table. Also some code in the model. Goal is to get all logic in the model, instead of in the DB. DB is just for storage.
Rails is targeted at greenfield development -- new applications being built from scratch. For example, Rails doesn't like composite primary keys. It can bend to work with legacy DBs, but if they are super-complicated, it won't work.
Can use console script, to interact with domain model in a CLI-type fashion. Can also be used to debug & administer live systems.
Layout: way of reversing responsibility between layout and template. Layout includes other files, so you can change formatting in one place. Inversion-of-control-like? Convention around file names, if file in layout directory shares same name with view, will automatically be used.
Rails has "filters", applied in a chain. Seems conceptually similar to workflow, hence filters in Remedy ARS. Apply filters in the controller class. Have granularity to specify which actions need to run which filters.
Rails has built in logging. Even better, you can access the logger, to do printf-style debugging. Call logger.info to do this.
By default, Rails stores session info in files in /tmp. Can configure it to store session info in DB or in memcache. That will work better for LB-style environments.
You can use inheritance. For example, if you rename layout file to be at application level, then all views will apply it, since they all inherit from application.
Unit tests are built in. Type "rake unit_tests" to run all of the unit tests. Type "rake recent" to test all of the files that have changed in the last 10 minutes. Unit tests good for testing model. What about controllers? There are functional tests for that. Use assert_response in order to make sure you get the response back from the application that you expect.
Includes AJAX helpers: bits of code you can invoke from Ruby, that will generate JavaScript in output to the browser.
Miscellaneous notes:
Tools:
Whelp, I have finally arrived:
Aside from barely making my flight in Pittsburgh this morning (crazy long lines at the ticket counter and security), my travel today was smooth. I checked into the hotel, grabbed some lunch and supplies, and then registered for OSCON. Tomorrow is going to be busy: there are several tutorials that I want to hop between. And when I have any spare time, I need to prepare for my blogging BOF. :)
-Andy.
It's that time of year again: O'Reilly's Open Source Convention starts next week. I'm going again this year, and as I was perusing the list of BOFs the other day, I noticed that there weren't any dealing with my current hot-button issue, blogging. So, I done volunteered to host one, and the suckers at O'Reilly fell for it.
Yup, I'm hosting "The blogging BOF". I''m pretty excited about this prospect, but also more than a little nervous. I'm not planning on preparing too much for it (which is good, because I don't have a lot of time), but still, I'm worried that it's going to be all awkward silence and nervous coughs. So, if you're going to be at the conference, please come and join me, because a BOF is only as strong as its participants.
-Andy.