OSCON 2005: August 2005 Archives

I had a great time at OSCON this year, and it is going to be a challenge to take all the of the technology and inspiration that I have after going to this conference and pour it into work. Some random notes:

• why the lucky stiff put on quite an interesting show. Even though there were many glitches, I was highly entertained.
• Ruby, driven largely by Ruby-on-Rails, got the most buzz of the show. Driven by great speakers like David Heinemeier Hansson and the aforementioned lucky stiff, I was compelled to go to all of the Ruby talks that I could. I bought the Rails book online, and am currently trying to come up with a way to use Rails at work.
• Dick Hardt's talk was brilliant, and now I'm interested in identity management. I went to a LID talk, and that was a bust, so I think that I need to check out OpenID instead.
• This was a hard conference to blog. A lot of information comes at you pretty quickly, and it was hard for me to synthesize it all into what I wanted to write down. I tend to just copy down the slides, which is a pretty dumb thing to do, since they tend to appear online after the conference. So, I need to get better at listening, understanding, and regurgitating -- all in realtime.
• Planet OSCON was a huge success (IMO). It allowed me to keep track of what all of the other OSCON bloggers were saying, without getting noise from the entire Internet.

All things being equal, I definitely got a lot out of OSCON this year. But, there were still somethings missing. Namely, I'm pretty interested in Blogs, Wiki, and other forms of social software. So, I'm wondering if there is a different conference that I should be going to (ETech, maybe?). We'll see how OSCON applies to life and work, and that will guide my decision about wether-or-not to go next year.
-Andy.

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:

• main, and universe repository - recommend only keeping the Ubuntu repositories active
• apt-get install pkg = version#, to force specific version
• there is some package pinning stuff that you can do in apt, but it sounds complicated

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.

• debian developer policy documents are good to read for questions about system startup, etc.

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:

• Stack machine
• 300 instructions
• OP tree, not bytecode
• Never serializes these instructions out to disk (attempts to do this that have been bigger and slower)

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:

• Too complex
• REST more scalable than SOAP
• SOAP based on new and untested technologies (WS-I, for example)
• REST more accurately models system by keeping strong relationship between URI and resource. Don't hide details in XML config files ("XML sit-ups", to quote DHH).

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.

DarwinPorts

• Conceptually similar to FreeBSD ports
• Customization via "variants" system (unique to DarwinPorts)

Building Darwin

• It's possible to patch and/or modify darwin code, compile it, and then layer MacOS X on top.
• Software Update will over-write such a system, however
• There are potential problems:
• Default compiler version (MacOS X ships with several GCCs)
• Many tools needed for the build don't come with OS X by default
• Environment variables
• Aliases

Default Compiler Version(s) - All of these gcc versions have been the default compiler in one release of MacOS X or another.

• 2.95.2
• 3.1
• 3.3 (compiler for Tiger OS)
• 3.5
• 4.0 (default in Tiger)
• The gcc_select command will switch the default around

Environment Variables

• SRCROOT - where the source code lives
• OBJROOT - intermediate .o files
• SYMROOT - debug versions of binaries
• DSTROOT - final finished binaries
• MACOSX_DEPLOYMENT_TARGET - allows flagging APIs as deprecated
• RC_RELEASE - Tiger
• UNAME_RELEASE - 8.0
• UNAME - Darwin
• RC_ARCHS - ppc i386 (architectures that binaries should be compiled for)
• RC_ProjectName - Name of project being built
• Even more variables....

Build Aliases - same sources, different results (client vs. server, for example)

• Based on $RC_ProjectName
• Examples are DSPasswordServerPlugin, cctools (compiler), libc (& libc debug)

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.

Extensions are code that run in the browser just as if it was a part of Firefox. This talk is geared around "the trunk" (the upcoming Firefox 1.5). Popular examples:

• AdBlock
• Greasemonkey
• BugMeNot
• FoxyTunes
• Many toolbars: Google, Yahoo, A9, Netcraft

Structure of an Extension

• Install Manifest -- structure of extension, and where it should go in the Firefox system. Aids in deinstallation. No protection -- extensions can be written that don't cleanly uninstall.
• "Chrome" (User Interface components)
• Components (non-UI) - integrate with services, hook to other parts of system, etc.
• Defaults (Preferences)

Packaging

• "Zippy" files: zip file with a .xpi extension.
• Can package traditional "heavyweight" plugins (flash, pdf reader, etc.) as Zippy files
• Don't need GUID's anymore for directory name for extension.
• install.rdf file needs to be in root of .xpi.

UI Development with XUL

• Long topic; good resources for XUL development at developer.mozilla.org.
• Supplies UI controls, drag-n-drop, menus, toolbars, etc.
• Bound to actions through JavaScript
• You can do overlays, over Mozilla-supplied XUL, to plugin your own UI elements for the extension. XUL overlay can add, remove, or change elements in existing XUL.
• XUL is a document, which can be manipulated just like you would a DOM in DHTML.
• Site: xulplanet.com

Extension bits:

• Chrome Manifest -- where to put overlay and where to find it.
• Install Manifest
  • RDF/XML file
  • Identifies extension
  • Compatibility extension (allows to install in Thunderbird and Firefox, for example)
  • Take existing file and modify it -- to hard to do from scratch. Or grab an RDF generator.
  • Update information -- for update checking
  • Save as install.rdf

New testing bits:

• Can point firefox at a directory, so you don't need to repackage.
• Still need to restart browser to have it pick up new extension. But it seems like the browser will pick up code changes dynamically?
• If you turn off XUL cache, may not need to restart Firefox.

Creating New UI:

• Dialogs are in separate .xul files
• Functionality in .js files
• Use DOM methods to manipulate UI elements within XUL
• Use .css files to add images, set colors, change style, etc.

XPCOM Components

• Firefox supports XPCOM components in extensions
• This allows implementing code in JavaScript, C++ (Gecko SDK), etc. -- interacts with more of "the guts" of Firefox.
• Automatically registered by putting these files in components/ directory.

This was a bare-knuckle, how-does-XSLT-work kindof talk. I think I was looking for a gentler introduction. Something that would be more motivating. Working through examples, showing a problem, and how XSLT elegantly solves said problem. Basically, I think that this talk needs some presentation Aikido. The presenter, Evan Lenz, really seemed to know XSLT backwards and forwards. And he prepared a nice quiz, which was a great way to work through some of the complexities of XPath. In addition, it fostered some group collaboration, in that we broke down into teams of two in order to go through the questions. All he needed in his presentation was more of an emphasis on case studies, real-world examples, and stories. He was basically trying to teach XSLT in the course of this tutorial. Which, if I want to learn a new language, isn't typically how I go about things.
Some notes that I harvested from the presentation:

• Michael Kay's "XSLT Programmer's Reference", well-regarded text on XSLT.
• Eventually, the slides will be available here: http://xmlportfolio.com/oscon2005/.
• If XPath is about trees, XSLT is about lists. Populate arbitrary nodes from the source tree into lists. Iterate over those lists to produce result tree.

Languages:

• XSLT
• XPath - language for addressing parts of an XML document.
• XPath is part of XSLT is part of XSL

XSLT debugger (Xselerator is an example) is quite helpful in learning:

1. What does my XPath expression select?
2. And what substitutions are being made as a result?

PythonCard is good for building simple GUI applications

• NOT HyperCard (that was original intent)
• More like VB (today)

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.

A question for the OSCON blogosphere: is anybody interested in an Ubuntu BOF? Things that I think we could talk about:

• Upgrades:
  • How do I rollback patches that come out for Ubuntu?
  • When should I reboot after applying a patch?
  • When it comes time to upgrade to Breezy, how will I do it, and how will I ensure that my system doesn't blow up?
• Startup scripts: what is the chkconfig equivalent on Debian/Ubuntu?
• Documentation: aside from Ubuntu Guide, what other definitive documentation repositories exist? Is there anything like the FreeBSD Handbook?
• Where is the best place to go with Ubuntu questions?

If there is interest, I'll write the BOF up on the board, probably for later in the evening either tonight or tomorrow.
-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.

Some quotes from Larry:

• "As a child of the cold war, I know that seeing a mushroom cloud is a good thing -- it means that you haven't been vaporized yet."
• "You know, when you think about it, most Open Source software is written using other people's money."
• "Diversity in California is not only encouraged, it is required".

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:

• CamelCase mapped to underscored names
  
• URLs should be all lower-case, and use underscore's instead of CamelCase
  
• Table names are pluralized form of model (post model -> posts table)
  
• Assume primary key of id, and it auto-increments.
  

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:

• session is global hash that you can reference with variables for the user's session.
  
• rake is make in Ruby.
  
• breakpoint - super-cool way to debug. Can set it anywhere, stops execution and throws you into console to inspect things.
  

Tools:

• It looks like David is using TextMate as his text editor.
  
• iTerm
  
• CocoaMySQL - GUI for messing with MySQL tables.
  

"The way of harmonizing with the Flow (of the universe)"
Presentation isn't about subdoing audience, bending them to hour will, turning their energies against them

• More about connecting with the audience
• Sharing knowledge and ideas for their benefit
• Encouraging them to travel a path with you
• Helping them

presentation as a privilege

• when you speak, they may or may not be giving you attention, respect, etc.
• they are giving you their time (most precious resource)
• recognize it as a gift, start to enjoy it

Be competent

• be comfortable, confident on stage
• audience doesn't care what saying, only that you are saying well
• talk about topics you genuinely understand, actually use
• talk about real experiences that you have had

humility

• if you can't get out of talk, do research, and admit to audience that it is new to you as well

plan

• the battle is always won beforehand
• adjust languange to audience
• confidence that's reassuring (that material is comprehensible to normal human beings)
• flow that is captivating
• all arranged beforehand

making kick-ass preso

• budget 10 hours per hour of speaking
• Damian does more like 20

step zero

• most important decision
• what are you going to talk about? always have a choice about it, even if assigned
• talk about what you care about, passionate about, excited about

don't be boring

• all about attitude
• about enthusiasm

be entertaining

• always trumps informative
• hook 'em at the beginning, before they mentally change channels
• in given time, really only giving overview or sampler
• reassurance -- this material is attainable
• build cognitive framework in mind, that provides framework for understanding
• comprehensible material that resonates with audience
• so they can go and learn details later
• entertaining is the way to do this

the title

• supposed to convey vaguest hint of topic
• engender some sense of intrigue
• try working in a pop reference, those who get it will be smug and on your side
• try to make title short
• state main thesis in first three words, field of interest in last four words

blurb

• marketing pitch
• informative, without giving stuff away
• should say that talk is interesting and speaker is excellent
• show it by making interesting and excellently written
• give some sense of structure of talk
• short, easy-to-read, catchy, tantalizing

tell a story

• register shortage
• structure information hierarchically -- the story

less is more

• fundamental point of aikido
• will only remember 5 points, so choose 5 most important things
• find story that fits those 5 points smoothly

connect ideas

• connect to ideas that people already have and understand
• metaphor
• now, ready to begin writing the talk...

write handout first

• easier to arrange information in word, or text editor, than in presentation software
• outline style, so it translates well to slides

build a flow

• causal style
• chronological
• layered - drill down, build up; good for when length is variable; can adapt to needs of audience -- can choose when to go deep or stay up
• cumulative -- start simple, and build up
• simple narrative
• flow decides what topics go in, or stay out. if it doesn't re-inforce 5 points, it is extraneous

what is missing?

• where is leap too great for audience?
• need to go back and fill in gaps

create and condense slides

• squirt raw material into slides
• fix it
• start deleting words - handout best as proper sentences, slide points don't work as sentences

visual style

• this really matters
• coherence -- single visual entity
• harmonious whole
• different styles of presentation are needed for different objectives
• style can be a part of the message

persuasion

• great secret of persuasion is to not use many words
• short declartive statements, no hedging
• minimize decoration

to inform

• can use smaller, bulleted text
• softer hues, etc.

develop a style

• if you don't have one, don't use MS templates
• thief from apple, cool websites, etc
• reverse-engineer from a cool preso that you say

slide detail

• almost every slide is too busy
• too much text, too many ideas
• Damian typically runs 120 slides/hr

images

• use images like seasoning
• better made visually than spoken
• use them in an unexpected manner

animation

• meaningful, occasional
• want to animate a process
• if not easy in powerpoint, too complex
• almost never resort to video
• only if absolutely amazing, and really makes the point

color

• don't distinguish by color alone (color blindness)
• use luminance instead
• also application for a new font, or draw a luminance box around text to highlight, etc.
• tools for picking color schemes, like how artists can do (PowerPoint in MacOS X has one)
• check under worst case scenario -- set os to go black & white; will make slides that work for people of all visual perception abilities

highlight differences

• side-by-side hard for people to grok
• show transitions, only animate what changes

surprise them

• break up monotony of talk
• keep audience engaged
• variations in pace and style

put landings in staircases

• can always come up with more material than there is time -- people try to cram it all in
• people can't absorb all of that stuff
• they will need chance to absorb and digest
• asides, humorous bits, examples, etc. give this needed break
• make sure to intersperse some easier concepts
• can use landings as navigational beacons, to notify audience that new topic is starting
• signpost - common slide (like TOC), that you come back to as you progress, showing topics you have talked about, and what is coming next.

charts

• no-one understands charts
• put it in notes
• break chart down, and explain piece by piece
• same goes for graphs

look effortless

• the best presentations look effortless
• audience desperately wants the material to seem "easy"
• keys: competence, preparation, practice, organization, style, attitude
• be passionate, connect with audience, give of yourself -- but be self-less

don't read your talk

• worst case, read and then give summary that isn't on slide

rehearse

• secret of timing
• most important
• do it aloud

demonstrations

• great way to show audience what you are talking about
• people visualize better than they hear
• practice
• try and script software demos if at all possible.
• make demo smooth -- hot keys to get to example, and run with one touch