pragmati.st

I attended the Web Content Mavens Meeting tonight. Phil Kemelor gave a presentation on “Tuning Up Your Web Analytics”

I didn’t think that the presentation itself provided much value. Everything that Phil said boiled down to the following: Make sure everything you do with web analytics helps the business.

In other words, think about what questions you want your web analytics to help you answer and always try to tie that back to something of business value. This is a very important point, but one that I feel is self-evident and certainly one that can be made in less than an hour.

I was disappointed that he didn’t offer specific suggestions for how to improve your usage of analytics. Instead he stayed in the land of platitudes with suggestions like “Reach out and touch a stake holder” That said, web analytics helps to answer questions that are business specific, so coming up with general advice is clearly a difficult task.

To be fair, I think that I am a bit more technical that the target audience of the talk, so maybe others did benefit.

In any case, the meeting had a good crowd and was well organized and the sponsors paid for free beer which was cool. Thanks to the organizers.

I went to the NovaRUG meeting tonight. Here is a recap.

Microformats

Ray Daly gave an introductory talk to microformats. It was a good introduction to what they are, included a few examples of pages tagged with hCard and hCalendar information, and showed off a few places where microformats are being used.

It was a good talk, but I think it may have glossed over what is cool about microformats: they require almost no effort to implement. One day I decided to add microformats to EasilyInvited. I had heard of them, but never used them or done any in depth reading. In 30 minutes I decorated all event instances with hCalendar markup.

The downside is that the killer app for microformats has yet to be written. Furthermore, the apps that are out there (like Operator) while cool are used by almost no one. So if no one uses them why should you implement them? First off, no one uses them yet Why not? The cost is miniscule and if nothing else the css classes they are based on make it easy to style your HTML.

Microformats are the lowercase semantic web. They are deliberately limited. They aren’t trying to solve all the ontology building problems that RDF and the capital Semantic Web are. They’re also here, work, and are based on the familiar technology of the current web. They’re REST and RDF is SOAP. Guess which one I prefer ;)

Open Layers

Gary Hurder then gave a brief presentation on some GIS stuff. He walked through OpenLayers a javascript library for displaying map information in modern browsers. Think of it as the google maps panning and zooming interface (plus a bunch of other stuff) with the ability to use whatever GIS data you want. It is pretty impressive.

I need to learn Smalltalk. Avi seems to be one of the smarter people I’ve ever seen speak.

I don’t come from the outside, I come from the future – Avi Bryant (received with laughter)

Avi Bryant is much younger than I would have thought.

Ruby in 2025

• Fast JIT compiled VM
• Multiple commercial Ruby vendors
• Best way to predict future is to invent it.

He’s not talking about Ruby in 2025 he is talking about smalltalk today.

Ruby and SmallTalk are the same language. Slide of Urdu and Hindi of the same phrase. Writing is different but they are said the same way and mean the same thing. People who speak urdu and hindi can talk to each other and apart from accent not know that they’re speaking “different” languages.

Ruby community can treat smalltalk as alien technology that we can learn from.

Ruby’s features make it inherently slow: false. True 20 years ago but we solved that problem

sun started strongtalk bought it all back and turned it into the JVM

And this is one of the greatest tragedies of the technology world.

Does performance matter? twitter cares, the rest of us don’t. ruby is fast enough. but there are other reasons to want fast implementations. Namely we want to be able to write ruby in ruby. Right now too much of the stdlib is written in C. (Note: there was a great blog post a while back about why it is important for a language to be self compiling a while back)

What if your Ruby ObjectSpace were transactional and persistent, could be distributed, wasn’t limited by memory, with no restrictions on what type of object (threads, etc.)

GemStone does this for SmallTalk now.

Objects get better with age – big difference between rails and seaside, in ruby you use objects for milliseconds. in smalltalk you keep them around for a really long time. A lot of the work is in creation and deletion of objects, if you get rid of that then you have a much better ratio.

State is your friend. In web development we work on making web apps stateless. If you embrace state then you can do a lot of amazing things, you can have a paradigm that feels like desktop gui programming.

Questions

Is SmallTalk good at interacting with the rest of the system?

If you use a smalltalk environment you are giving up textmate, svn, grep. You don’t work with text files, you work with objects. It does not integrate with normal dev process. Can you call out to C or environment? yes, but he likes ruby api for extending C libraries better. The bulk of DabbleDB is in Smalltalk, but they use http to call to ruby to handle some integration.

What is the first step to having turtles all the way down? (pure objects)

Implementation of the Ruby Standard Library in Ruby instead of C.

I agree they are similar. It seems like there are significant differences (mixins, multiple inheritance, argument passing, etc)

He thinks that Ruby can be implemented on a stock smalltalk VM. He’s implemented ruby mixins in smalltalk as an exercise.

Could you run us through an example of how you develop in Squeak? How do you cleanup when you have messy data without control-c and starting over?

He brings up a smalltalk image (think core dump of irb session) of dabbleDb. If you don’t save, you can go back to a fresh memory DB. He keeps a DB instance in the smalltalk image and he can just reset the DB. “So your objects may get screwed up, but you through them away”

What about Rubinius?

He thinks that it is great that there are all these implementations going on, but commercial smalltalk vendors have spent a whole lot of time and money to get really optimized VMs.

Rails seems to be moving away from object systems towards loosely coupled interfaces?

He agrees that Rails and Seaside/Smalltalk have very different philosophies. But he thinks that it is a good idea to see what other dynamic languages (smalltalk) has gone. If you reject that, cool, but you should at least know what is possible. He is opinionated but with different opinions than rails.

Seaside was a tough sell to ruby and java people until I showed them the debugger in seaside. Demo it

You get a stack trace in the browser, but if you hit debug, you get a debugger in your image. You can edit the method in the debugger an save it, then hit proceed in the browser and finish the response. Similar to the irb command line debugger David shows this morning. Continuations let you hit back and go back to the error that you had before. I’m describing it poorly, but that is one of the best things I’ve ever seen. You can run the debugger or class browser in the browser.

I know a lot of SmallTalkers who are glad to be off it because of image based development and collaboration

It did suck. First thing that he did when he got his first consulting gig was to write his own version control system. Similar style to Git other distributed version control systems.

Steven Smith of FiveRuns

Is Rails ready for the Enterprise?

Is the Enterprise ready for Rails?

Rails is becoming the certer of an evolving exosystem. Example, last year there was no exhibit hall. This year the conference has tripled in size and there are a fair amount of companies in the exhibit hall.

He’s talking about quotes from various magazines, uptake indicators (1 mil downloads, 700,000 in the last year) Big name companies using rails.

Notable tools built with rails: 37signals, 43things, jobster, Revolution Health.

He argues that Enterprise isn’t a four letter word because it is a validation of the adoption of rails.

Ever popular monty python killer rabbit sketch. Rails being the rabbit, knights being the enterprise / enterprise web frameworks.

Devon Jones, Architect of Web Systems, Vonage Stephen Becker, Developer, Vonage

They’re going to talk about the way that they have integrated with their legacy systems.

Rails at Vonage

• Subscribe System
• VFax
• A bunch of internal things like Metrics Mole to show business people decision so that they can
• RESTful services

Last year facing a software crisis. Rapid customer growth led to software developed quickly and crufty.

Large projects are a problem. They try to do small programs and projects, deliver on the order of months not weeks, and have 1 or 2 features per app, with transparent interfaces so they can chain them together.

When you have a system that is hard to change eventually you decide to replace it. Traditionally you go with a long project trying to replace the old one and owing to scope creep you end up trying to do to many things. (Sound familiar to anyone? PAS?)

Working on a legacy system is like working on a car while it’s going 60.

He is citing the Standish Group study. This has got to be the most cited study ever.

Change gradually and consistenly because people fear change, the smaller a project is the less risk there is, allows for rapid course adjustments, and it shows success early and often which helps sell stakeholders.

He just quoted ESR from tAoUP which is funny because I was thinking how much what they are describing sounds like the unix way.

Forget code reuse look for program reuse. Simple, transparent interfaces like REST (or unix pipes) make it easy to debug, test, and chain programs together.

Ripping apart a lafre legacy EJB system.

1. Find what specific feature you need\
2. Wrap it in a RESTful interface
3. create a test suite for that RESTful interface.
4. Implement the RESTful service outside of the legacy system

Suggestion 1:

Use the system. See what features / services are used. Step through in a debugger until you find where the real logic is.

As soon as you find it drop a RESTful service around it and then you can build the rails front on that.

Now you can make the legacy code use the RESTful service.

Now you have enought understanding to build a Ruby functional test suite for the RESTful service. U

Use the functional test suite and JDBC logging to figure out what is done in the old DB.

Now you can tun off the old code. The rest of the legacy app is still there and is still crap, but represents future targets.

Active Record in Legacy DBs

• Database Degradation
• Documentation
• Nonstandard DB schemas
  • 8 different ways to represent false in the same column
  • terminated spelled 6 different ways in the same column
  • Dates stored as varchars
  • csv data in columns

You can define custom module methods to fix this. Exclude columns

User Interface Integration

• Transparent Proxy: Noodle, Transproxy and Squid – Less legacy change
• Single Sign On Keys – Alternately you can use SSO keys. – More legacy change

It worked at Vonage. They get more maintainable code out quicker, it’s well tested and has much fewer lines of code.

They repurpose old data. They have project tracking tools, test harnesses for java code written in rails,

Where does Rails fit?

• Rapid Prototyping. You need something small and quick this is the framework.
• Mission Typical tasks – Applications that are a little more forgiving, not quite “mission critical” things
• Cost analysis – Development time vs. hardware. Hardware is cheap, developers are expensive.

What are they working on: composite keys

Resources

Questions

What do they do with their DB?

What they try to do is create clean services, then when all DB clients are using the service they can clean up the data without fear of breaking existing apps.

In terms of risk management, does the slow migration force your hand in terms of design?

A little, you have to maintain compatibility with legacy services.

Are they working on a API. eg. can we get access to our voicemail

They’re working on it, but management isn’t sold quite yet.

How do they do SSO?

Most solutions aren’t very cross language / platform. They rolled their own. Simple, textual interface.

From a deployment operations perspective how do you deal with the many small apps?

Take a look at JRuby. You can use your existing deployment strategy by using WAR files. If you don’t want to push to J2EE. Use Capistrano.

My take: Automate everything and I imagine that you’ll be fine.

When a Rails app shares with a legacy how do you use fixtures?

His opinion is that you shouldn’t use fixtures for testing. He is in the mock camp because he doesn’t think that a fixture based test isn’t a unit test. If you want to use them have the DBA create a separate schema with the same structure but no data. Developer: suggests kissing DBA ass.

A lot of the issues with legacy work are building relationships and bringing people who control the legacy systems don’t want them to change.

Do you gather business rules or reverse engineer?

The code is the business rule. People get confused about rules, the code doesn’t.

How do you maintain business owner interest in infrastructure improvement?

Deliver early and often shows real benefit. Once you can show them that they can get features they want quick they won’t go back. Projects like this thrive on agility. They use two week development cycles. Ability to readjust priorities is a huge win.

Is there an online communithy around these issues

Enterprise Rails Yahoo group??

Dirk Elmendorf, Cofounder of Rackspace

This presentation was a bit basic but I think that it is a great description of how to get a team of “normal” developers working in rails. It strikes me that a lot of things that they do “aren’t the rails way” but it seems to work for them.

Twitter faces capacity scaling. Not easy, but not interesting to him.

He does internal apps. Growth limited by size of company.

Building a Rails Team

• Having an anchor is important. They didn’t have enough, so they cheated and hired ThoughtWorks
• Buy the book , read the book, learn it as a team. Gives some shared experience. Rails is a DSL for web apps. Since you’re already a developer learn Rails first, then dive into mastering Ruby as you go along.
• Introduce advanced topics over time. KNow your team and its limitations. Don’t throw metaprogramming at newbies.
• Names are important, things have a place (convention over configuration) spend a bunch of time teaching the team this. Make sure they get this.

First App Safelist was built for the Red Cross to provide a place for them to organize the 10,000 Katrina evacuees in San Antonio. Time was short. People were on buses on their way to San Antonio. Only one person knew Rails at that point. The situation was special, because they were reuniting families and such. But the lessons weren’t special. The same patterns have repeated for other apps.

Building the App

We all think about our apps as our babies and we want to get to the finish line. Finish lines are only for consultants and demos. All successful apps evolve. If you screw around you end up with an app that is a nightmare. Changes have consequences. Downtime is important to avoid. Testing is the tool that helps to alleviate that pressure. Tests are a safety net that answer the question: Does it still work?

They support a number of apps and don’t work on all of them all the time. Tests help you get back into an app after a layoff. Tests are interactive documentation. Tests enable change. By having that net they show problems that pop up in another place and gives yo a chance to fix it and fix it before anyone even knows.

rcov is a coverage tool that will show you how good your test coverage is. They’ve learned that if your coverage is < 75% then you really need to do manual testing. If your coverage is perfect you still need to test.

Supporting IE. Use Selenium to test the UI in the browser. See my notes on the first morning session. Delay selenium usage until the UI design has stabalized because selenium tests are very closely coupled to the app.

Another App: Sensei. Performance evaluation tool. Two weeks to build it to avoid another year of paper process. Had to work and be secure because private information that. How do you verify that? Testing. Roled the app out right before RailsConf last year. Changed the app a lot over the last year. Added collaboration so that multiple people can review employees and made sure that they could still audit the security.

Playing with others

Cardinal rule of enterprise: no app is an island. Integrate early. Sometimes things seem easy that aren’t.

• SOAP wasn’t seamless when connecting to Java CRM. They had to get the head of the SVN trunk for Ruby SOAP. This proved to be a hard thing to track down.
• LDAP Authentication – They built out a custom LDAP plugin. That way all their apps can use it and it allows for really clean code sharing. By segmenting from the app, it removes the temptation to code to the app.

Testing with integration is hard. This is where you do mocking and stubbing. They use both flexmock and mocha. They will arm wrestle to choose at the end of the conf.

• XMLRPC with a python app. Blew up on mongrel. Content length was being sent twice. They monkey patched the bug so it would work after submitting it to the Mongrel project. You want to standardize the location fo this type of change. Make sure that something nonstandard like this is really clear. They created a dir called app/core_ext
• WS is just a function call across a network. so it really isn’t anything like a function call. They aren’t reliable. They added a bunch of code to handle edge cases. They’re setting up a message bus. ActiveMessaging on top of ActiveMQ??

Final App: IP Space Commander Manage > 200,000 IPs and many multiples of that of private IPs. Obsessed with IP blocks. Doesn’t do anything else. Has to integrate with CRM, Ticketing, provisioning, authentication, etc. They are buildig a collection of apps where they have to integrate smoothly. They go with a message bus.

Jamis just made a joke about the sea of macs. I guess I’m not the only one who thought that it was noteworthy.

there are before and after hooks as well as a bunch of callbacks. start and finish are only tied to top level tasks.

Upgrading to Capistrano 2.0

shouldn’t be too bad unless you did a lot of customization.

1. capify . to set up.
2. 3rd party extensions like mongrel cluster won’t work.
3. overridden or extended tasks might blow up
4. some of the variables have been changed
   • there is a “compat” mode that provides a facade of tasks with 1.4 names delegating to 2.0 cap -Ff compat
   • seems like compat mode would be a good way to figure out what has been deprecated in your resumes and what you need to change.
5. cap -Ff upgrade upgrade:revisions dropped the revisions log in 2.0. There will be a file in each release directory that says called “revision” that specifies the revision that was built.

Done with the slides.

Questions

Why wasn’t Capistrano developed as an extension to rake?

Similarities are mostly superficial. Rake is dependency oriented. Capistrano is declarative. Rake for local, Capistrano for remote and hasn’t encountered much overlap.

What is up with Ezra’s shell?

I don’t really know what they are talking about but I’ll need to know.

What is the recommended way for setting environment variables?

There is some method that you can pass

What other types of cluster admin tasks do you do?

Cap isn’t moving away from deployment. Deployment will always be a central task, but Cap 2 makes it much more modular and more accessible for sysadmins. 37s uses for troubleshooting. Their sysadmin keeps cap shell all the time. Uses to check filespace etc, which was a big deal before they moved to using S3 (they were running out of space) Someone uses for their config files. They set their apache config files as erb templates.

Design question: Dependency checking is a very hardwired syntax have you thought about a more general way to do dependency checking?

He didn’t know there were other options. Just wanted to get something working. Open to someone coming up with a better way to do it. Need to support windows as a platform to deploy from limits choices. Example Jamis had to declined patch do to cd syntax differs on windows from POSIX.

Most deploy example seem to be simple. Where can you go for examples of more advanced stuff?

Eventually: Capify.org The wiki is a cool tool also. Right now the best place is the list. Another good place is blogs example. Tim Lucas. Capistrano is soft of hard to learn. There is an O’Reilly book that covers the basics, but is small and doesn’t get into detail.

How do you parametrize tasks?

Suggestion: use either environment variables or capistrano variable. Do it the same way you would parametrize a Rake task.

Isn’t it kind of messy to use environment variables?

The problem isn’t so technical, but how do you specify those on the command line. Jamis likes the env variable. Dirty on windows (what isn’t? that’s mine) A task that needs to take many parameters is a smell. Can prompt by using lambda.

Demo of “CocoaCapistrano” little ssl like thing

How did you record your scripting demos?

wrote a script called text_movie. The demos were smoke and mirrors.

What do you do with long running migrations (order of days)?

He doesn’t know. There longest migration was 3 hours. The guy asking now just runs them and prays. Another guy uses Capistrano to kick off the processes and has a separate system to do the migration and monitor it.

Deployment Migration. Can’t running deploy without migration break?

Yes. But safer than messing up data. Very hard to stop alter table on a row with 4 million rows. You can roll back if you blow up your app by not doing a migration. If you think deploy should migrate by default you can make it by putting an after hook. This is what they do at Shopify.

First off, I can not overstate how overwhelmingly popular the mac is. There are probably 100 laptops in the room right now and I see 4 non macs. It was the same this morning in the JRuby session which is where you would expect to find the more corporate people. Those who do have non macs appear to be running Ubuntu. I think I’m the only person with a windows box in the room. And I am a Mac user who only has this dell because work gave it to me. Not that this is news or anything, just thought I would mention it while I’m waiting for the room to fill out.

Presentation Slides

Capistrano started out as a deploy tool when basecamp got pushed to multiple servers. Now it is used for more, It can be used for

• ad-hoc monitoring
• server maintenance (they edited nfs mounts against 6 app servers with one command)
• troubleshooting – grep logs across multiple servers

Capistrano is a tool for executing tasks on remote servers.

Capfile

• internalruby dsl similar syntax to rake, but not compatible.
• specifies what servers to run against and what task to do.
• Gateways – Allow you to manage a cluster by tunneling through your 1 gateway server. Useful when the individual cluster servers aren’t publicly accessible.
• Can specify multiple roles (a role is a collection of servers) and limit takes to particular roles.

invoke lets you run a particular command against whatever servers you want (even without a capfile) shell lets you run a shell (better than invoke because less typing and faster bc connections are cached) this is experimental so beware, but I can see how it would be crazy useful.

Namespaces

• new in Cap 2.0.
• default tasks, task named :default can be executed as the namespace name.

Variables

• set, eg. set :deploy_to, "$HOME/rails-apps/#{application}"
• -s foo = bar (sets after recipes loaded)
• -S foo=bar (sets _before recipes loaded)
• in capfiles check if the variable exists before setting to avoid conflict with command line parameters

Transactions

• not overwhelmingly robust, but is pretty cool and definitely helps

Deployment

• love how opinionated about the need for source control they are. I agree 100% if your code needs deployment it needs source control.
• looks really easy. Like everything with rails I’ve dealt with well thought out.
• deployment tree looks like a good way to manage releases

Dependencies

dependency checking is a good idea. lets you check things about servers like whether the expected directories exist, their permissions are correct, and subversion exists. you can add your own dependencies as well. Custom dependencies let you check if arbitrary directories, gems, permissions, PATH. this is effin brilliant. still sort of experimental, only does what Jamis needed but will be growing.

script/spin tells how to start server. see slides for details. compare to process supervision tools like init, svscan, runit. You can override deploy:start

some tasks use sudo by default.

deploy:cold – first deploy. laughs at “it never works the first time.” Problems are normally that the webserver / mongrel / fcgi setup.

cap deploy will push a new version. cap deploy:rollback does exactly that. Note: deploy doesn’t run migrations by default. Jamis thinks any prod DB changes should be explicit. I agree (not that my opinion is very valuable ;) )

Deployment Strategies

• different ways of deploying apps. pretty cool. extensible so you can write custom ways of deploying apps.

Can use other types of source code control other than subversion. none of the stuff we use at work is supported. lots of other things are.

They're working on a stripped down version of GlassFish that gives the benefits of an app server without the whole JEE stack, and they're starting to work on it. GlassFish developers managed to put a gem together during JavaONE last week. ("this thing is two weeks old and it's already at version 10" laughter) Benefits of doing this is that you can use GlassFish as a dev server. If interested read GlassFish blogs, wiki, and JRuby extras project. Could be cool in the future, but I still think that the main benefit of JRuby is slipping ruby in the back door. So the WAR deployment is really useful, and if you're setting up your own servers I would lean towards doing it the native ruby way.

Talking about running Mephisto (what runs this blog) on JRuby.

MySQL has no known issues and passes 100% ActiveRecord tests and is hooked up to their CI server. If you use mySQL don't worry about it.

Derby (JavaDB) and HSQLDB are replacements for SQLLite and works really well but there are a few failures. Good target for small apps and are useful because they are embeddable and shippable. Mingle is using Derby. Unpack and run and your app is up. Doesn't require DB setup.

PostgreSQL has a few failures, but they haven't gone after it real hard yet. Failures are almost exclusively with migrations. The other buggy areas are quoting and rounding of BigDecimals.

Oracle focus is just starting. They haven't done much direct work with it, but some people are doing prod deployments with it. Progress is quick on the ActiveRecord-JDBC gem because it is .

SQL Server hasn't been examined at all. Some people are using it, but they JRuby developers aren't using Windows (shocking for Sun employees, I know) so they have trouble testing this.

Migrations work well, but some DBs lack required features. For instance Derby can't ALTER TABLE

Fixtures work well. Bugs are normally with the JRuby YAML implementation

Native Extensions. Option 1, don't use it. If you use pure ruby you can use out of the box. Option 2. Use a Java library. Option 3: port the library. sometimes pretty easy to translate. Option 4: Port by wrapping a Java library. basically create a facade. for example JRuby Digest was originally written in ruby by pulling in java crypto stuff into ruby code.

OpenSSL was completely reimplemented in Java for JRuby. Pretty impressive and about the worst case situation. YAML was originally written as a pure ruby implementation and then was rewritten in Java for the performance gains.

You can deploy with Mongrel. It works, but it isn't the best way to use JRuby bc you don't get the benefits of the JVM. WAR files are the best for eiting servers. this is what you're going to want to use in a big enterprise. Can take advantage of existing investment in infrastructure. Pool DB connections, cached results, pool execution threads and request handlers.

Good line: "Java EE has a lot of bathwater, but a lot of baby" i haven't used JEE enough to know, but I would imagine that they had to get some things right. ;) Good things are like (Java Message Service, Java Persistence API, Java Transaction API, Easy deployment, clustering, failover, management and it scales great (even though the complexity of the platform makes it tricky)

Eventually they wannt to have a Grizzly/GlassFish lightweight, gem installable version. You get the installation benefits of Mongel, and the managements and clustering benefits of an App Server.

Tom is demoing Mephisto in JRuby by packaging it as a WAR using GoldSpike. The WAR file will contain JRuby, all the Gems, and your application code. Benefit: each app within the app server is completely independent and can be running different . Wow. That deployment was easier than getting this blog running on DreamHost. They've also got Typo working recently and are moving all their blogs over to Typo on JRuby.

"Java is mature, trusted, reliable (and often boring)" but there are a lot of libraries out there. Another good line: "'To them: 'it's just jave', to you: 'it's just ruby'"

demo of using ROME to add Atom feed to demo app. automatically produces ruby style properties so that you don't have to use java getters and setters in Ruby code. this is really cool.

Demo of NetBeans Ruby support. Some really cool stuff: Integrated RDoc, code complete, go to definition. This is impressive and I'll have to check it out. I have had a post floating around the back of my head about tooling in dynamic versus static languages. I love textmate, but this would be really nice to have. Basically my argument is that these things would be great to have with ruby but you can live without them. In Java or .Net it would be unbearable to have to write code in a text editor. There also is a Swing based IRb built in to the code. It handles embedded grammars (eg. ruby in an rhtml file) I'm going to need to check out the tooling talk later in the week.

Someone is snoring. Jesus, I used to sleep in class in college, but this is actually useful, expensive, and brief. Unbelievably rude.

Questions: Discussion of compilation to bytecode. Approx 50% of the ruby syntax can be compiled. Currently done in a JIT manner.

DSLs in JRuby. Good idea, you can write Ruby based internal DSLs for ugly java APIs. Good point, the "rubyfication" of the java libraries makes much prettier apis. Not quite a DSL, but much more useable.

Exceptions: you can catch Java exceptions, to catch a specific one just import it.

Initialize in Ruby vs. constructors in java. They chain nicely.

Streaming notes:

Why they are doing it? expand java, expand ruby's reach. no better way to learn a language than to implement it. also it's just freaking cool.

they ask if java sucks. not many say it. they like ruby better (who doesn't)

jruby allows you to access java libraries. once pulling in java you can use ruby language features (enumerable, concatenation, etc.)

even converts ruby case "set_size" to java 'setSize" when calling java methods.

Thomas is demoing the install. Really simple. set the environment variable and that's about it. I've got to figure out how to slip this into LM. you can also check out from svn and build via ant. plug to help. I'm going to have to try this.

comes with gem. Mongrel supports JRuby. RDoc runs crazy slow. Rails "just works" because it is pretty much all ruby code. Thoughtworks is pushing mingle 1.0 on JRuby to calm "enterprises"

ruby unicode support sucks (my word, not theres) threadings, scaling Rails, and having to write in C to get performance. Good point. No one wants to write C they are trying to get the benefit of optimized JIT bytecode compiling

Unicode support: JRuby has their own identical ruby 1.8 striing implementation but also exposes java unicode strings and switch back and forth between java and ruby strings well.

Supports ruby thread api. They hate critical=, kill, raise because there is not a safe way to do this (I'm real rusty on this, bc it has been a while since I've written real multi threaded code) Make less assumptions about control of threads and you'll be fine.

JRuby threads generally equal system lhreads owing to JVMs being native threaded. This lets you use multiple cores out of the box. Also does thread pooling. Get true concurrent threading. You can screw it up (like any concurrent system) but the internals are good.

What is the biggest benefit of JRuby? My argument: you can convince your PHB to let you use it.

Pretty much all pure ruby code runs fine.

Tom demoing installing rails and bringing up an app. WebBrick boots up nicely. Installed mongrel, brought it up. They are emphasizing the same thing that strikes me, what is remarkable is how unremarkable it is. Everything looks really simple.

DB implementations. Pure ruby connectors (MySql, Postgres) run fine. jdbc adapters run fine and faster. You can use JNDI for connection pooling. Connection pooling important for licensing requirements if connecting to oracle (many connections = mucho dinero)

Classpath sucks. you can do the traditional, or you can just drop whatever you need in JRuby/lib directory.

Setting up JDBC is also really simple. Migrations work fine, but required a lot of db specific work under the hood because JDBC doesn't handle schema management. MySql passes 100% of ActiveRecord tests. Postgres has 17 failures out of over 1000 tests.

C Extensions don't work (unless they're ported to Java) Example RMagick doesn't work but is in progress.

Performance. Java isn't slow, but it is slow at startup. After startup about the same speed as the C implementation, some specific cases are faster. Command line performance still sucks.

Deployment.: Mongrel should work. A couple things like forking off subproccesses and process management don't work. JRuby deployments are normally done by deploying to a App server. Project is called GoldSpike, and is a rails plugin for ulding WAR files. One plugin in pure ruby, produces a deployable, server agnostic WAR file.Plug for Glassfish ("it's tiny for an app server, which means it's huge" laughs from the room)

Tom demoing deploying a rails app on an app server. one rake task, produces a war. Wow! that was really easy. I think that this is going to make bringing rails to big companies much easier.

Break