Presenter – Robert Cooper
Had a good lunch – everything food-wise that you can possibly put on a stick – finishing with chocolate covered cheesecake on a stick. Who can complain about that?
Now sitting in Cooper’s session on Google Web Toolkit – a Java to javascript compiler. It’s certain to be way over my head [again] but I’ve got to be loyal to the old AnyDevice crew.
Some paraphrase, etc.:
“It’s a combinatorics problem” you don’t hear that very often.
full implementation for the DOM. Specific implementation for all major browsers – 5 compilations per application based on user agent [expanding to 8] Monolithic compile to all the customized environments. Can be hacked to tailor experience per environment.
The application looks like a single unified app, but the model gets altered per environment — keeps the javascript footprint small. Lots of squeezing happens in the compiler. The shell is built with SWT system’s SWT browser component – uses the native browser for the environment. Includes RPC system, but you’re not bound to use it. Shell, standard development environment — take native browser and hook in controls to native byte code. Supported on net beans, eclipse and others. Shell dynamically compiles Java in the background so almost like working in an interpreted environment. Translates everything back to regular running java code which enables use of a java debugger. Platform includes a remote testing system. Unit tests can be farmed out to each individual browser which can help isolate browser specific problems. Includes an embedded Tomcat server, which is a little weird to work with compared to regular Tomcat. GWT very similar to java 1.1 in experience. Limited reflection implemented, can do simple data binding. Binding a grid form to a data feed — continuous environment updates, support for data validation in forms. Can use reflection to create animation effects — helps make it easier to build an application. More return on javascript size when the application is more complex. Very heavy footprint for simple, hello-world type stuff, but cleans up a lot as part of the library. Better returns on file size over growth of application. Has a very specific support for caching. Automatic versioning system based on md5 hash of compilation. Nocache.js is the bootstrap file. That’s the only file that requires pragma nocache. Some files can be cached permanently, because versioning will take care of them.
Helps protect application from cross-site scripting attacks. Currently have 3 applications in production now, all used internally, but some have 5000+ users.
Show & tell: soft scroll module — force a button to be visible in a pane. Nice for enhancing user experience. Makes for a highly portable user experience — can be ported to many emergent platforms like Nintendo Wii and iPhone. Abstraction over browser differences (like directx calls versus firefox canvas) simplifies keeping user experience consistent across platforms.
Still some problems as to where the web designer fits into the process – right now you really need a programmer on the UI. The new version coming, GWT 1.5, will allow html to be compile to be regular gwt widgets so a designer can make a layout and have that dropped into the development process. 1.5 will also have have Java 1.5 syntax — will make life happier for working in the IDEs. Google is starting to see widespread adoption so you’ll start to see some standardization and optimization.
Live from Barcamp – Day 2 – Session 4 [for me] Ruby on Rails panel
Looks like just two panelists. Didn’t get the names.
Starting discussion with scaling issues of mongrel server. I was expecting more of a discussion of rails, pros and cons, this seems to be more of a discussion of memory use on the server and scalability. Database load failed to scale for Twitter, sooner than the ability to run enoug instances of mongrel. Logan, jumps in and interjects “F*ck scalability” with the contention that when you have the problem of scalability you better have money coming in and can then deal with the issue. Is Ruby creating a brain-drain on Java talent. Still more jobs for java developers? There is a rebutting point that sometimes an app can catch fire before monetization and can outpace the scalability of Rails. PHP might be better. But how do you anticipate rate of acceptance, and usage growth? In one company, not named, prototyping is done in rails, but all that code is tossed for the production environment. The prototyping is useful for creating real requirements, but in the company referred to it is all java for the production.
Lookup: panelist mentioned a video on building a blog app in rails in 15 minutes – assume this can be found on youtube
Panelist expresses difficulty in his experience getting separate rails apps to communicate well. Not well-suited task for rails. Application growth tends to get unmanageable. Not just a rails problem. Michael chimes in with a plug for Ruby and reinforcing the point that Rails is not very ruby-like. Learning and loving Ruby can enrich the experience and open new doors. Very expressive. Syntax for ruby is very expressive. Ruby is fully object-oriented.
Rails vs. Symfony — Symfony is a framework for php that borrows much from rails — panelists likes rails much better — more nuance, better unit testing. Other frameworks, like Zend, etc. don’t provide the full simplicity, but they do help put you in a better paradigm for development.