Ultimate top 25 Chuck Norris programmer jokes
These classic Chuck Norris Programmer Jokes will make your inner geek cackle with glee, and if you’re into continuous integration there’s even a Hudson Plugin to share them with your team!
GWT 2.0 rocks
GWT 2.0 was just released ushering in some much-awaited changes like development mode in a real browser, code splitting, declarative UI, resource bundles, and HtmlUnit-based testing. My team just upgraded from 1.7.1 and the process couldn’t have been easier.
Unlike the massive type and project config changes in 1.6 there is very little that requires tweaking for 2.0. We simply swapped in the new gwt-user, gwt-servlet, and gwt-dev jars (just a config change since we finally use ivy), tweaked our Eclipse run configurations to add some new parameters for dev mode, and were off in running in IE 8, Firefox, and Chrome. Dev mode is a relief and way faster than the old IE-6-based hosted mode (best experienced in Chrome or Firefox but still an improvement in IE 8), and Speed Tracer provides an easy way to figure out what’s going on in the UI similar to Firebug Net mode. It’s also convenient to have everything the compiler needs on any OS wrapped into the single gwt-dev jar now, so no more gwt-dev-${os}.jar parameters in our build across different environments. We haven’t had a chance to play with the declarative UI but I can’t wait to see what it’s capable of.
But all the great new features aside, the most surprising aspect of the upgrade was that our entire codebase was already 100% compatible. Not only did this make “upgrading” the project a non-event, but the project can now go forward building on both GWT 2.0 and GWT 1.7. This includes not only our massive amounts of homegrown GWT code but also GWT incubator, GWT math, GXT, and a handful of other libraries we’re using. This is extremely powerful for us because we also export a client source jar with a limited set of widgets used by other projects, and they’re now free to upgrade GWT at their leisure. Even better, a GWT 1.7-compiled client can perform RPC calls seamlessly with a GWT 2.0 server using the existing 1.7 serialization policies, so all sorts of combinations of legacy clients hitting our latest and greatest server are possible. Long-term I’m sure everyone will want to be on 2.0 but it sure makes getting there easier!
Hats of to the team at Google for all their hard work and such a solid delivery.
Upgrade the Windows 7 RC to any retail version
For anyone else who’s been running the Windows 7 RC and now have your hands on the real deal, here’s a great guide for upgrading to retail without requiring a clean install.
Java performance myths
Awhile back I posted a link to some good Java performance basics. Today at the office I saw an incredibly outdated JavaTM Performance Tuning and Java Optimization Tips from 1999 being circulated as a good read (that’s JDK 1.2!) and it made me cringe. I was inspired to dig up some Urban performance legends and then more Urban performance legends, revisited. A lot has changed in 10 years, and many things we used to lament over (think inlining source code) are far better left to the modern compiler.
iPhone, Gmail, and Exchange sync nirvana
For the past year or so I’ve been syncing my iPhone exclusively with Gmail for email, calendar, and contacts. I finally decided it would be nice to have a full sync of my work email and calendar from the corporate exchange server, but did not want to lose the ability to access my contacts in Gmail, which also serves as my primary repository for phone numbers on the iPhone and contacts in Google Talk. I also did not want to manage those contacts through Outlook going forward.
After researching a couple of options I finally landed on a great setup using gSyncit, which is $14.99 but well worth the price for the hassle it eliminates. The trial version is fully capable of syncing one entire calendar and up to 20 contacts which is sufficient to verify that it will meet your needs. gSyncit runs as an Outlook plugin, so it will definitely be most useful on a machine that is constantly – or at least frequently – connected to the the internet. Since I have a desktop at work that remains on with Outlook always open, I installed it there.
The number of options you can configure and tweak are impressive, but for my needs I simply set up two profiles, one for syncing calendar (with Outlook as my primary), the other for contacts (with Gmail as my primary), and set it to automatically sync every hour. The default sync range of 365 days in both directions was a little slow for my calendar so I changed it to only grab 30 days prior and 365 days in the future, which easily synced my calendar and several hundred contacts in under a minute.
I did back up my contacts and calendar first in case anything went wrong (and would recommend you do the same!), but surprisingly on first sync it correctly reconciled everything in both places, no duplicates, and most importantly no corruption of the web of recurring meetings, exceptions, live meeting info, etc. that fill my corporate calendar in Outlook. It’s one of the most error-free two-way calendar syncs with Outlook I’ve ever seen. On the contact side, I was also impressed that it brought over all of the fields correctly (even pictures) from Gmail into Outlook.
Finally, with my exchange account and Gmail happily in sync I converted my iPhone to sync exclusively with exchange. This consisted of simply deleting the Gmail exchange account on the iPhone and then configuring one for my corporate exchange server. Afterwards, I did re-add an email-only account for Gmail so that my iPhone can still pull personal email directly.
The final result is that my iPhone is continuously synced in both directions with my corporate exchange server (via push) for work email, calendar, and contacts, and with Gmail for my personal email. In addition, those contacts and calendar are synced periodically (currently every hour) with Gmail so that I can continue using that as my master contact repository. Note that gSyncit allows syncing as often as every 5 minutes but I didn’t find this necessary since I change contact information infrequently, and if it’s an urgent change I’m probably making it directly on my phone anyway rather than through Gmail.
Definitely give gSyncit a shot if you’re looking for a painless way to keep an Outlook calendar and contacts in sync with Gmail so that you can sync your phone exclusively with the exchange account!
Top 10 reasons to date a geek
Check out these top 10 reasons to date a geek. Classic, and so true!
Paper storage
It’s good to know that when longevity matters, there’s a paper storage solution still alive and kicking! Thanks to Olly for this hilarious project.
GXT 2.0 final fails
It’s been four months since I first wrote about my experience starting to use GXT and freshly diving into a 2.0-M1 upgrade. Since then my project has upgraded to 2.0-M2, 2.0-M3, RC1, RC2, and finally 2.0 GA, with even a couple svn trunk builds in between for good measure. In fact after M2 I stopped writing about because it was just more of the same messy, things-don’t-work-like-they-used-to-or-at-all-and-worse-are-different-in-every-browser shananegians every time. I kept hoping that our experience was simply an artifact of so many changes in 2.0, their dev team being clearly overwhelmed, and would still converge on some form of synergistic vision by the final release. I was sadly mistaken.
GXT fails, and this will be the last time I bother to comment on it unless it spontaneously improves before I stop using/thinking about it entirely. My project is removing it where possible, minimizing its use when necessary, and hoping to leave it in the dust by way of GWT 2.0 and incubator advancements over time.
Some examples of the types of issues still present (albeit changing flavors regularly) in GXT 2.0 final are:
- Component and/or layouts only render correctly – or at all – when wrapped in a specific type of parent component that otherwise has no bearing on its functionality
- Many components, including the really visible ones like Grid, render differently in each browser, or sometimes not at all (especially in Chrome)
- Components behave in wildy different ways when aspects of their state such as hidden/visible or enabled/disabled are set prior to render, during render, or after render, e.g. calling hide() before something is displayed causes it to appear malformed and non-functional rather than being hidden
- Tooltips – and popups in general – don’t display, display in random locations, refuse to hide, or render incorrectly when re-used; in fact unconstrained use of “new” keyword any time you need to display something has become a necessary anti-pattern on my team to get things to render correctly
- Funny, but sad, breaking API changes like removing Window.close(), with explanations like “because it never worked like you’d expect it to so you never should have used it anyway”
- Arbitrary (accidental?) functionality tweaks like changing which item is selected by default when you open a new combo box or when which actions on a check box (blur, click, etc.) actually fire the change event; these are superb at breaking UI tests
- Heavy-handed style approaches (think programatically setting element.style from a private method) that make customization difficult
- Continued prevalence of heavy BeanModel-based models and stores and expensive run-time massaging of data; someone should really teach them about generators
- No visible effort to take advantage of, or at last synchronize with, up and coming GWT best practices like MVP, dependency injection, command pattern, and compile-time optimization rather than run-time inflation
- Many things… are still… so slow; forcing your user to choose between waiting while a component spins in IE 7 vs. having it load lightning fast but not work correctly in Safari or Chrome is so web 1.0
I’ve heard that GXT 2.0.1 is just around the corner with “many fixes”. Right.
Stacking GWT 1.6 workers with ant parallel for super-fast builds
Having just built a new machine around a Core i7 950 enthusiastically overclocked to 4.2gz, I couldn’t help but explore the possibilities of a lightning-fast GWT compile. I regularly build a project that involves a core services war that’s pure Java along with a GWT 1.6 war consisting of two modules that requires 3 permutations each, all wrapped into an ear at the end.
Historically this took about 3 minutes running serially on a reasonable Core 2 Duo. It would run the core services war build, then the GWT build one module at a time, each using GWT 1.6’s -localWorkers 2 to at least make use of both cores.
The potential of 8 concurrent threads across the i7’s four cores and the presence of two GWT modules plus another build compelled me to resurect some old-school Ant parallelization to stack as much work as possible during the build. With a bit of tweaking it’s easy to have ant running multiple targets – some GWT and some non-GWT – at the same time, so that entire modules, not just permutations, are built in parallel. For example, something like
<target name="gwt"> <java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false"> <arg value="module1" /> <arg value="-localWorkers" /> <arg value="1" /> </java> <java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false"> <arg value="module2" /> <arg value="-localWorkers" /> <arg value="1" /> </java> </target>
becomes
<target name="gwt"> <parallel threadsperprocessor="1"> <java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false"> <arg value="module1" /> <arg value="-localWorkers" /> <arg value="4" /> </java> <java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false"> <arg value="module2" /> <arg value="-localWorkers" /> <arg value="4" /> </java> </parallel> </target>
The result was phenomenal. My 3 minute build now takes only 40 seconds! If you have lots of cores available be sure to consider stacking ant parallel with GWT workers for a big improvement. Keep in mind that running many modules in parallel may also require ridiculous amounts of memory (around 600mb per module in my case), but on an i7 system you should have at least 6gb anyway right? 
Spring4gwt, or Spring’s harmony for GWT
I’ve had an idea itching at me for awhile now, which started shortly after building a complex enterprise application using GWT connected to Spring services on the server. There are countless blogs out there describing various ways to wire up Spring with GWT, and Google’s own Gin is quite adequate for client-only dependency injection. But what I’d really like is something that ties this all together, and in the true spirit of GWT, makes it easy for a seasoned Java developer to apply proven, consistent DI practices in both the client and server using the Spring knowledge they likely already have.
My vision is basically this:
@Component
public class SomeGWTComponent {
// Some other client-side component
@Autowired
private MyWidget widget;
// A remote service proxy to a server-side Spring service
@Autowired
private MyService service;
public void doSomething() {
widget.doClientStuff();
...
service.doServerStuff("data", new AsyncCallback<String>() {
public void onFailure(Throwable caught) {
...
}
public void onSuccess(String result) {
...
}
});
}
}
}
It’s important that MyService is a vanilla Spring service on the server – no extension of RemoteServlet required – and that MyWidget is any other GWT component. Injection should occur when the component is created, potentially with varying scopes just like on the server, and potentially also with @PostConstruct support for code to be executed after injection, leaving the constructor available for any pre-injection initialization. And finally, as much work as possible should be done during GWT compile minimize the run-time cost.
The approaches to GWT lookup/injection I’ve seen out there have at least one the following gaps:
- They’re client-only (Gin)
- They’re largely run-time, and slow (MVC helpers in component libraries like GXT)
- They involve SpringMVC or other unnecessary server-side complexity (most blog guides)
So I’m going to try to bring this altogether in one simple library with the following goals:
- Simplicity: Access Spring services from the client through a generic exporter; no service-specific mappings in web.xml, forced type hierarchy (services should be existing Spring POJO’s), or dependency on SpringMVC. In other words, when a new Spring service is added to the server it should require zero configuration changes to be accessible in the client if desired.
- Consistency: Client-side dependency injection with native Spring look and feel; freedom to inject private members, via constructor, or via getters/setters with same Spring annotations and conventions that are already familiar.
- Performance: Do all the heavy lifting with GWT generators to keep the client lean.
Behold, spring4gwt where I’ll do my best to make this a reality! The initial version captures objective #1, bringing together a generic servlet for exposing Spring services without turning each into its own RemoteServlet mapped in web.xml. Up next: accessing those services with Spring DI in the client!
Recent Comments