Welcome to JoshLong.com, home of my personal blog
<< Last | Next >>
July 5, 2011

AOP's Not Just Logging

If you've ever read about Spring's powerful AOP support then you've probably heard about the canonical example of introducing logging functionality - a cross-cutting concern - to your beans. The example goes like this: you want to log the start and stop time for every method invocation. You can either modify every method and introduce logging, which is tedious and error-prone, or you can simply use AOP to wrap every method invocation. With AOP, you'll get a chance to perform logging every time a method is started and finished, or both! This is a common example, but it doesn't even begin to illustrate how powerful AOP can be. The most powerful example of AOP is perhaps the Spring framework itself. It uses it every where! Let's look at some common examples:

  • In Spring, beans are by default singletons and have no particular guarantees about thread-safety. This is fine most of the time as many objects are thread-safe (e.g., the JdbcTemplate) so consumers never need to know. This usually ends up being the most performant, and most natural, style of Spring bean. One example where Spring uses AOP to acheive the feeling of thread-safety without concerning the developer with it is in Spring's EntityManager support. Spring will correctly inject a proxy EntityManager using AOP. EntityManagers are not thread-safe, but the consumer doesn't need to know. As an example, you might write: @PersistenceContext EntityManager em. Spring then automatically routes all concurrent requests to the appropriate, thread-local instance being maintained in the background.
  • Spring's declarative transaction management is based heavily on AOP. With a single annotation, Spring can start a transaction before your method is invoked, then commit (or, in the case of an exception, roll it back) when the method terminates. You don't need to know about this as a consumer, of course, but behind the scenes.
  • Spring Security can guard method invocation access, limiting the call to clients that are secured. This authentication checks against a security context, and - if authorized - proceeds. This works through the judicious use of AOP and some thread local state.
June 30, 2011

Reframing the Question

Just watched a recording on JavaEE6 and JBoss AS7. JBoss AS7's looks like it's evolved by leaps and bounds! I wonder if it's as mature as Glassfish now... Some of the new features in JBoss AS 7 seem to just be bug fixes.

  • It's faster (which is great, because it's always been dog slow. JBoss AS5 had startup times of 60 seconds or more on trivial applications!)
  • It doesn't leak classes (because previous versions had all sorts of classloader issues and this was a very common complaint)
  • It supports the full JavaEE6 specification (because JBoss AS6 - the first release of the JBoss AS server line after the JavaEE 6 specification was finalized - didn't, instead choosing to only support the web profile)
  • It's productized into part of the JBoss EAP (which is great, because JBoss AS 6 wasn't, and - as JBoss AS 7 is still not out yet, this means that Websphere (!!) was quicker to market with a supported version of Java EE 6 (both full profile and web profile) than JBoss!

Towards the end, one of the presenters made the nonsensical assertion that, basically, Spring is quite old (and was therefore straddled with all of this imaginary legacy code), and that CDI is - in contrast - quite new. This is an example of "reframing."

Spring's been around since 2003, in some form, and since 2004, in a big way. It's certainly older than CDI, sure. Obviously. However, applications written in 2004 still run without modification on Spring 3.0 and the upcoming Spring 3.1, with very few exceptions. The only exceptions are on the very few cases where we've deprecated certain APIs like our support for Apache OJB. Even still, if the older, relevant extension library is loaded, it runs. The supported parts of the component model haven't changed, just the libraries that we ship that build on top of the component model. Usually when we deprecate something, it just means we're not shipping it with the project, not that the code won't work on current versions of Spring.

In contrast, if you'd written your application on the "standard" EJB 2 (which was the norm when Spring first emerged), it would not run on contemporary versions of these Java EE 6 application servers, especially those that just support the web profile. For that matter, if your application in Seam 2 (which was current six months ago!), it would not run once you upgraded to Seam 3 without heavy migration. (Definitely not anything close to a drop-in upgrade)

Spring's older, but evidently far stabler than both the J2EE / JavaEE implementations and the standards. If you're running Java SE 5, then there's little reason Spring wouldn't continue to work on an existing J2EE 1.4 server. To boot, new versions of Spring support programming models that are more powerful and as lightweight, as anything JavaEE has, while maintaining backwards compatibility. It's unfortunate that JavaEE6 can't maintain its legacy code and add support for "new" component models at the same time, and even more so that this is what passes for a "standard." Spring has a better backwards compatibility story, within Spring as well as within J2EE and JavaEE application servers.

Don't let people maliciously reframe this point. Spring's maturity is a strength, not a weakness. The component model introduced in XML in 2004 still works today, and we've provided several alternative input configuration types to tap this same component model, including annotations and Java-based configuration. This is possible because any configuration mechanisms - be it XML, Java configuration, annotations, the Groovy BeanBuilder, or anything else, is eventually normalized to a common component type at runtime.

June 29, 2011

Geecon 2011 Roundup

What a couple of months! I've been running around like crazy. I attended Geecon, the Spring S2G Forums, and then the JAX San Jose conference, all in fairly short order. I'll try to put up roundups of my trips a bit more consistantly, starting with Geecon. I've been to many European conferences, but this one is now among my favorites. The conference has the unique combination of excellent speakers at a low price, like the SpringSource S2GX Forums or SpringOne.

Poland was the real surprise. This was my first time here and it far exceeded my many expectations. The Polish Zlati is cheap against the English Pound, European Euro and - yes - even the American dollar (2.6, in May). It's easy to be taken (in any country) as a tourist, but I found myself dropping my guard after five days. Nobody'd really tried anything, and most everything met with my expectations.

 Assert.assertTrue ( taxi.getPrice () <= expectedAmount,
    "the cab faire should never exceed " + expectedAmount+"!" ) );

At one point, I was taken for a ride (literally!): a taxi charged me 50 Polish Zl for a ride from the central square to my hotel which was otherwise consistently 19-24 Zl (even in traffic). By comparison, a train ride from Krakow to Lodz is 54 Zl, and the trip is several hundred kilometers. That said, 50 Zl is roughly 19 USD at the moment, which is not enough to feed two adults and a child at McDonald's (the lowest of the low) in the states. So, it's all relative. The takeaway is that even being ripped off didn't feel so bad in Poland.

I did a university talk on the first day (the university talks are three hours each), and I did a second, single-hour talk, on the first day of the conference proper. The university talk was interesting because fully 70% of it was live coding or walk throughs or demos of some sort and I had dual screens, so I ended up coding using a 50' theatre-screen! I still have some small neck pain! :-) Next time, I'll simply mirror my screens. Ow.

The audience was great, I never know what to expect of audiences. Some times they ask questions, some times they don't. These audiences did a fine job of asking questions all throughout the talks and outside, during the conference! Wonderful. This makes these trips worthwhile. The in-the-conference-hall discussions are invaluable, and redeeming.

After the first two days, I decided to have a look around. The conference promoters were kind enough to help arrange a tour of the salt mines for Heinz Kabuts, Heinz' son Maxi, and myself. Heinz is a personal hero of mine. I suspect most Java developers have read his pearls of wisdom as dispensed in his newsletter at some point or another. I found him through Bruce Eckel, whose book - Thinking in Java - helped me learn Java 13+ years ago. (I liked the book so very much that I sent Bruce a brief letter, the majority of which has appeared in the reader comments section of the book since 2003!) So, to finally get a chance to hang out with Heinz was great - he's even cooler than I imagined! His son Max is quite the character, and of course is already programming!

In the photo, Juergen Holler, myself, Eugene Ciurana, (name unknown, sorry!), and Cyril
As usual, hanging out with Juergen Hoeller was a unique and wonderful experience. I joined SpringSource to get a chance to work with him and others like him, and I'm always grateful for his time. The truth is, he gives of his time to anybody. No question too small, no topic to inane, and no JIRA too trivial. Juergen is easily one of the most indulging, humble people you'll ever meet. Brilliant. If you get a chance to attend a conference where he's speaking, do so. You'll invariably learn something! I always learn something.

On the final day - Saturday - Heinz (and son Max), Emmanuel Bernard and I took a tour of the Za Kapane mountains - and the region surrounding it. What an amazing tour! We also took an impromptu boat trip, and floated downstream on a river bordering Slovachia on a wooden raft / boat for a few hours. I'm a throughly crispy critter at this point -- I burnt in the sun and am now watching my skin turn into flakes. This was very good fun and the conversation even greater. We then toured the regions specifically, stopping in markets, at castles, and at other geological oddities like a mountain that resembled a sleeping man. As the tour guide - Carolyna - predicted, I was asleep in my seat as we returned home.

Emmanuel (a French speaker) and Heinz ( a German speaker) both speak impeccable English, and it always depresses me that I've let my language skills fall so far behind while they do so well in so many other languages!

Several people asked me about the code to my university talk, which was a walking tour through all of Springdom. It introduced core Spring and the advanced component model underneath, AOP, and the proxy facilities, it introduced Spring's support for data processing and backend architecture (including JDBC, JPA, Hibernate, various NoSQL options, batch processing, event driven architectures, messaging, integration, and services), Spring's support for web applications including rich clients and web clients (including Spring @MVC - both standard HTML and REST, Spring Flex, Spring Mobile and Spring Android) and it introduced the world of Spring in the cloud. The code is here and I'll put the slides up as soon as possible and tweet it from my Twitter handle @starbuxman.

After the Geecon conference, I took a trip to Lodz (pronounced, I learned, as "wooj"), in Poland, to visit a friend of mine (who I know by way of my mother's online bridge tournaments). I spent a few wonderful days there surrounded by truly wonderful people. I can't possibly hope to relay all the great experiences I had there, but I will share one. I was asked to talk to a young man of 13 years - my host's nephew - to encourage him in his computer studies. I reluctantly obliged and sat with him. The conversation was moving pretty well, he explained that he was trying to learn Java, and that he loved the new Android mobile phones. I asked him how he was proceeding in his Java studies, and he trotted out Thinking in Java, in Polish! I asked him which phone he most fancied (that, he later explained, he was saving up to purchase) and he responded that he liked the Google Nexus S (which I both have and love!). I materialized the iPad I had in my backpack and he was uninterested, fascinated more with the Nexus S. I asked him to bring out his laptop so I could help him get setup to program in Java. He rebooted and - this is the part that kills me - he already had Ubuntu installed, but was still taking his first steps and hadn't quite figured out how to get on the internet. Amazing! What a kid! I think - and you can never tell him this - that I emerged from that discussion more inspired than he was. What a wonderful experience.

I was a curious kid, growing up, and I owe any success I've had to this curiosity. I was programming very early in my life, and this was fortunate, because it's empowered me. I've heard it said that there will be two types of people -those who consume computers, and those who control computers. I'm privileged, I think, to be among those who can control computers. I'm excited by this kid's potential - indeed, by all of our potential.

After Poland, I was then off to the Spring S2GX Forums in Amsterdam and London. I'll cover that trip, however, in another post.

April 21, 2011

A Script for Retrieving Wayward OS X Windows

Dear Lazy Webs,
I just had to unplug my secondary monitor and follow the procedure outlined here to get a wayward OSX window back on my display.

Is there a better way?

March 22, 2011

So Close, but... So Far

Started today pretty impressed that Interoperability @ Microsoft was a sponsor at EclipseCon, which kicked off today. So, score one for community and interoperability. Then, I see that Microsoft is suing Barnes & Nobles and others for their use of Android in their tablet environments. Huh. They almost went an entire day without being ... Microsoft. One for the history books.

March 18, 2011

The Mystery of the Indexer Segfault in Eclipse CDT, a True Story

I just hit a good 'ol fashioned segfaulting bug! For reasons I'm not proud of, I had cause to write some C++ code. I downloaded Eclipse CDT (And before some sadist comes along suggesting I should've stuck with vi or butterflies, I've tried just about every C/C++ environment out there. I'm one of those guys that just doesn't understand writing C or C++ code without an editor. I'd sooner write Java than C or C++. Far too many things that can go wrong, it seems.) I downloaded the latest one based on Eclipse Helios, installed it and then created a new C++ project (File > New > C++ Project > Executable > Hello World C++ Project). As soon as the Eclipse indexer started churning, Eclipse suddenly just disappeared! One second, I'm looking at Eclipse, and then a blink later, I'm staring at my computer Desktop! The darned thing had segfaulted on me! I triaged the droppings it had left just before it died - here are the salient excerpts of the log:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV  (0xb) at pc=0x00007ffc8537f61e, pid=412, tid=140722453255936
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot (TM) 64-Bit Server VM  (19.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x29861e]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
---------------  T H R E A D  ---------------
Current thread  (0x0000000040530800):  JavaThread "CompilerThread0" daemon
  [_thread_in_vm, id=422, stack (0x00007ffc7fc69000,0x00007ffc7fd6a000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1  (SEGV_MAPERR), si_addr=0x000000000000000d
Registers:
RAX=0x0000000000000000, RBX=0x0000000000000005, RCX=0x0000000000000000, RDX=0x00000000d8000000
...
Register to memory mapping:
RAX=0x0000000000000000
0x0000000000000000 is pointing to unknown location
...
RDX=0x00000000d8000000
{other class} 
 - klass: {other class}
RSP=0x00007ffc7fd671e0
0x00007ffc7fd671e0 is pointing into the stack for thread: 0x0000000040530800
"CompilerThread0" daemon prio=10 tid=0x0000000040530800 nid=0x1a6 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
...
RSI=0x00007ffc85a840d0
0x00007ffc85a840d0:  in /usr/lib/jvm/java-6-sun-1.6.0.24/jre/lib/amd64/server/libjvm.so at 0x00007ffc850e7000
...
R9 =0x0000000040534d90
0x0000000040534d90 is a global jni handle
R10=0x00000000404f5790
0x00000000404f5790 is pointing to unknown location
...
R15=0x0000000000000001
0x0000000000000001 is pointing to unknown location
Top of Stack:  (sp=0x00007ffc7fd671e0)
0x00007ffc7fd671e0:   0000000000000005 000000004080b200
...
Instructions:  (pc=0x00007ffc8537f61e)
0x00007ffc8537f60e:   48 89 fe 0f 84 2e 01 00 00 4c 8b 05 8a 13 83 00
0x00007ffc8537f61e:   8b 53 08 41 8b 48 08 48 d3 e2 49 03 10 8b 4a 18 
Stack: [0x00007ffc7fc69000,0x00007ffc7fd6a000],  sp=0x00007ffc7fd671e0,  free space=1016k
Native frames:  (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x29861e]
V  [libjvm.so+0x296c0b]
...
Current CompileTask:
C2:1110      org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTFunctionDeclarator.postAccept
 Lorg/eclipse/cdt/core/dom/ast/ASTVisitor;)Z  (97 bytes)
---------------  P R O C E S S  ---------------
Java Threads:  ( => current thread )
  0x000000004129e000 JavaThread "Worker-9" [_thread_blocked, id=781, stack (0x00007ffc623e6000,0x00007ffc624e7000)]
  ...
  0x00007ffc79ad8000 JavaThread "org.eclipse.cdt.internal.ui.text.CReconciler" daemon [_thread_blocked, id=760, stac

My many years of experience have helped me in these situations - they inform my professionalism and abiity to react decisevly and appropriately. It is imperative that one keep is cool when things don't work out as planned.

So, I sucked my thumb, all the while whimpering a little. I mean, c'mon! Somewhere in the millions of lines of Linux source code and the entire 30+ million lines of Eclipse source code was a bug, actively working to ruin my day! You'd cry too if you just thought about it a little.

But I had one last defense before the false recourse of sticking Eclipse itself under a bugger (and, how I would've done that remains unclear; I couldn't very well have used Eclipse CDT to debug itself and the interactions between Eclipse CDT and the native code in the JRE!). I knew that I could ask my old pair programming pal, Google! I then started scanning looking for unique, repeatable information (i.e., something that would make a good, precise Google query.). At the bottom, I found "org.eclipse.cdt.internal.ui.text.CReconciler," and away I went! I asked The Google about any issues with that class in Eclipse CDT, and was given this Eclipse forums link. That eventually led me to this bug report. That is where I found a workaround. It didn't quite match my situation, but the fix was the same: add -XX:-UseCompressedOops to the end of my eclipse.ini.

So, I hope this blog has helped you avoid this particular bug. It'll probably be fixed soon, but my pain remains. The worst part about all of this? I did all that work just to end up in a position where I could write C++ code! That's like... helping the Dentist look for his really big drill so he can give you a root canal!

Meh.

March 12, 2011

Hot to Retrieve Your Application From Google App Engine

Sometimes, just sometimes - once every 5 years - I need to reverse engineer my own binary because I've either FUbar'd the code or the code is lost to me. Don't care to explain why the latter is true this particular time, but it is true. I need a built version of an application so I can run it through a trust Java Decompiler like the trustworthy JAD tool. JAD tool hasn't correctly reverse current Java code since Java 1.5, but it does come close and it's far easier to simply clean that up (you can see the structure of the code, even if it isn't immediately obvious what to do to get it to compile again).

In my particular scenario, my deployed Spring application lives on Google App Engine. So, at least it's safe. A bit too safe, unfortunately. I didn't know how to get a copy of the binary for my own purposes from Google App Engine. I did some Googling and found some documents that suggested a fix - use the Google App Engine's SDK tool appcfg - to download the deployed source. Only catch was that the documents describing the tool were for the Python SDK, not the Java SDK. I looked at the Java SDK and even tried running the command as described in the Python documents and got nowhere. So, I cheated. I did some more Googling, and by this I mean I simply contacted my friend at Google. He pointed out that I'd already had the answer: use the Python SDK to download your Java application!

So, if you're on Google App Engine, and if for one reason or another you obliterate your only copy of the source code and if you want to work against a deployed binary (a very specific situation, sure, but it could happen to somebody else besides me... one day!), then run the following command:

./appcfg.py -e $YOUREMAIL@gmail.com download_app -A $YOURAPPID $NAME_OF_FOLDER_TO_WRITE_THE_RESULTS_TO

March 9, 2011

Getting Started with Various LAMP Languages

A friend of mine pinged for some good bootstrap content on various technologies, namely Perl, MySQL, PHP, Python, Linux, C and C++. I learned (or, tried to... I'm convinced I'll never understand C++ and Perl) all of these different things over the years and so my knowledge is either outdated or incomplete. Nevertheless, I figured some of it might help others, too, so I'm reprinting a cleaned up version of my response email here. This information, of course, reflects my biases and experience and, except Perl, reflects professional experience in some form or another.

Perl: Never. ever. use. Perl. I don't know it (couldn't seem to sit and learn it with a straight face. It made me anxious), and can't recommend it unless you're a hard core system administrator who doesn't know Python, Ruby, C or Bash. It's horridly unreadable to all but the most exacting of eyes. It's been stuck at version 5.x for the last 10+ years. 6.0 has been "in progress" since 2001, code-named "Parrot." When Parrot becomes real I could easily see taking it on again.

PHP: it's a dead simple language - I don't know that there's a good introduction to it since I learned it when it was at PHP 3 from the early 2000's. (It's the 5th language I learned, after Java, C, Python and JavaScript). I tended to dislike the language at 3 and 4. 5 seems markedly improved, though I haven't used it since 4. The community's active and in agreement about its strengths. Typically, it lives inside a web server (Apache, Ninx, Lighttpd). It has no built-in modularization mechanism besides classes - no name spaces and compilable unit, so you end up sharing source code. The latest and greatest is PHP 5.3, which means that 6.0 isn't out yet. Most "extensions" to PHP are written in C, not PHP, presumably because it's not fast enough, or can't be used to manipulate enough things to achieve the extension. PHP does have PEAR (PHP extensions, libraries) and PECL (C extensions), last I checked, to provide a way to bundle standard classes and binary extensions. If you want to do core web programming, then PHP's an OK way to go. I'd still argue for Java (or a JVM language, like Groovy or Scala), Python or Ruby on Rails though. Sorry I can't help you learn it - it truly is easy, though. Google for tutorials. The original language was little more than a macro processor, and following its evolution was dead simple. Most of the object-oriented features in 4 and 5 were approachable given my background in Java, so that came naturally, too.

C: C is markedly more difficult to learn than PHP and at the same time much friendlier for the simple things. (Brian) Kernighan & (Dennis) Richie wrote the introduction to C, back in the 70's. People still refer to the variant of C as "K&R," or they refer to a particular standard. C99, for example, is the standardized version of C that came out in 1999. I only know "C99"-ish C, not proper "K&R" C. I only write C when I'm trying to glue stuff - typically operating-system specific stuff - together: Java and Windows, OSX, or Linux, via C, for example, or Python and something else, via C. I rarely have a use case for a full, stand-alone C program, if I'm honest. I almost always write modules that use C. C has no library - just a few standard types and the very, very loose language itself. So, the language itself is very easy, if a bit useless. You'll need to bind to something - either to your operating system (i.e., through POSIX or some additional APIs, or to some other library) to do anything. I've only met one person I'd call a "master" at C. To learn C, I learned by Googling and spending lots of time looking at Linux sources (sources included with Linux, not only the source for the Linux kernel itself) and so on. Check out SourceForge or Github.com.

C++: I tweeted recently that Herbert Schildt's now outdated C++ book was available for free download, which you might try finding. I think it was on MSDN (the Microsoft Developer Network). I learned C++ from Bruce Eckel's amazing "Thinking in C++" back in the 90s. He also wrote "Thinking in Java," which I loved so much so that I wrote in to him and gave a positive reader comment back in 2001. My comment is on one of the few pages on the inside front cover of his book, book under "reader comments" to this day ;-) He used to make the books available for free download, which I suspect you could still find if you Googled. Otherwise, you can buy the two volumes of it on Amazon. In college I also read "Starting Out With C++" which was... lame compared to "Thinking in C++," but it's also thorough (and shorter!), so it might be a good intro-read to ramp you into it. As with C, but to a lesser extent, to make use of C++, you need third party libraries since C++'s core standard library is kinda crap compared to Java or .NETs or Pythons, etc, so one popular choice is to use a platform abstraction like Boost, or Apache Portable Runtime (APR) or Netscape Portable Runtime (NPR). Some good books on Boost/APR that I often refer to these days when I've (rare) occasion to write C++ is "Beyond the C++ Standard Library" and "Cross Platform Development in C++." The first introduces Boost, the second introduces ... APR and a lot of other stuff. All that said, C++ is not as universally used (or even close to as universally useful) as C, and it's far, far, far, far more complicated than Java or C. I would avoid C++ if possible. The only reason I liked C++ is because I then understood why Java was an improvement.

Linux: I have no good book on Linux to recommend, only several that all helped fill in parts of the puzzle: Red Hat Linux Administrators' Handbook, O'Reilly's UNIX Power Tools, Practical MythTV, EXTREMETECH "Hacking Ubuntu", EXTREMETECH "Linux Toys" I and II, the "Official Gnome 2 Developer's Guide," etc. Of course, with this one I was lucky to have a talented Linux ninja - Mario Gray) - to really push me into it and make sure I didn't have a chance to escape until I'd seen everything he wanted me to see. By then, I didn't want to escape. Linux worked wonderfully. ;-)

MySQL: MySQL's dead simple. sudo apt-get install mysql-server-5.1 on Ubuntu Linux, and then follow any tutorial on the internet. It's a a database with 3/4 of the features of PostgreSQL and Oracle. It's also a ...scary open source project at the moment, because of all the politics surrounding licensing. MariaDB, MySQL, Drizzle, Percona, etc. I know Google has patched it over the years to suck less. If you need scalability and speed, use a NoSQL option. If you need features and an amazing, open-source database, use PostgreSQL. If you need a little bit of both AND commercial support, use Oracle, or the EnterpriseDB PostgreSQL build. Don't use MySQL unless you can avoid maintaining it. Amazon and Google App Engine for Business provide MySQL-like databases for their clouds, for example.

JavaScript: If you know absolutely nothing about JavaScript, then Webmonkey, formerly part of Wired.com, had Thau's Javascript Tutorial. That's how I learned it back in 1997. Don't let the 2010 date fool you, that tutorial's almost as old as the net itself. I learned it on IE 4 and Netscape 3 or 4. Since then, webmonkey.com shutdown and was sold, and then brought back to life after a few years shutdown. So, that tutorial is old content on TWO different versions of webmonkey.com! Since then, I've just read other people's code or wrote code and used Google for answers to things.

Python: Python was one of the easiest languages to learn since it was designed to be easy to learn, and, if I recall, Guido van Rossum (Python's creator) had experience with ABC, a learning language, which influenced Python's creation. I got my first look at Pyhon in the late 90's, or early 2000's. I think Bruce Eckel, again, mentioned Python in one of his books and that was enough to catalyze me to learn it properly. It's not hard to get going quickly, and for many years I kept it as my in-my-backpocket language, to do real work when Java might've been too complicated or if the task leant itself particularly well to Python's strengths in leveraging operating system-specific tools and APIs. Python has a large part of the POSIX APIs almost directly exposed through Pythonic APIs, for example, so your C skills come in handy there. It's a very good glue. I haven't really done more than played with Python's more recent web-tier support (and WSGI API, which provides the gateway interface between a web framework and application to the underlying web server, in much the same way servlets sits on top of the webserver, but below Java-based web applications.). I did have a pretty good experience with Zope (and the Plone CMS), which sort of predates all the current crop of Python web-framework killer-apps like Django and Turbogears. I have an older version of O'Reilly's "Programming Python," and I saw that it's since been updated, but it's huge - and as much a tutorial as a reference.

So, that's a lot of how I got started. I'd of course be interested in any suggestions since a lot of this is outdated (At least, I hope it's outdated and that better texts have come since!).

March 6, 2011

Dependency Injection and Inversion of Control Have Been Commoditized

The world of enterprise Java looks very different than it did 10 years ago. 10 years ago, I started following the news, the open-source projects, etc. In essence, I joined the "cult" of Java and haven't looked back. Even as I write Groovy and Scala code, I still feel a part of that cult today.

The marked progress hasn't been more apparent to me than today, when I read that Apache Excalibur had been retired. Apache Excalibur, for those of you who weren't lucky enough to watch the IoC and DI wars in the early 2000s, is an IoC container that's been around forever. It hosted Java components that could be defined using the Avalon framework. So, Excalibur was a container with type contracts, like an EJB server was (up until November 2009 when Java EE 6 came out) to EJBs, not a POJO IoC container as you'd expect today. It was basically a way to build and manage enterprise components and also take advantage of the Avalon component lifecycle and services. I remember looking at Excalibur in 2001 or 2002 and being very excited by it. Same with the Pico Container which also is still alive and kicking today, to my surprise!

So... was anybody using Excalibur today (besides Apache James, the open-source Java e-mail server, which I'm not even sure still uses it and which I quite like as a test e-mail server)? Is this a market segment I've just been obvivious too? I've of course been oblivious to community trends at other big events, too. When EJBs first came out, I got suckered by the press and marketing behind it and thought it was going to be a fantastic tool. It took me a year or so to get to a point where I simply didn't care anymore about my job options, I refused work in EJBs! I think the community also had the same reaction - at one point, we all sort of realized nobody else liked EJBs, either! I became a huge fan of XDoclet during this period, and an even bigger fan of Ant. I no longer have 80 hours a week to spend wrestling with code that could be written in a fraction of the time in .NET or Python. I no longer like Ant, or XDoclet, of course. For that matter, it took me a long, but happy and oblivious year to realize people were employing JSF 1.0. I didn't think anybody would use JSF if things like Apache Tapestry and, later, Wicket and Echo and GWT were there. So, clearly, I've got a history of bad predictions. Sometimes, when a technology or trend just doesn't make any sense to me, personally, I tend to take for granted that others won't use it, too. Anyway, when the IoC/DI competitions started flaring up, I paid attention because I was definitely looking for an alternative to the then current stack.

Things are very different today. Dependency injection is commoditized today - everyone uses the Spring framework, and some also use Guice or CDI. Naturally, I'm very biased (I work for SpringSource), but I'm pretty sure you'll find that's true too. You might check job listings, or informally just ask people if they use IoC or DI, and if so, which container implementation.

I would argue that Spring has been, from day one, a very good IoC/DI container. In the beginning, there were arguments about pure-play IoC, and how one container supported constructor-injection, and another supported method or property injection. I remember when Apache Hivemind (a project that grew as an offshoot of Howard Lewis Ship's work building Apache Tapestry 4.0) made its debut and only supported interface based injection, all the while giving us novel ideas like factory methods and method-based injection. Spring didn't pick favorites or impose philosophies - it supports all of those things! Spring goes out of its way to be as straightforward and flexible as possible.

This too doesn't matter, I think. Conceivably somebody could simply build all of these things (and I'm sure many have) pretty easily. So, while Spring's an excellent DI and IOC container, I hardly think everyone adapted it because of that alone. Spring won because it offered a component model and a supporting ecosystem of libraries and frameworks that were built from the ground up to support clean, IoC-centric, POJO-centric Java code. Core Spring (and everything you'd need to have a competent, pure-play IoC container) all lives in 1-3 .jars, depending on which parts you want and whether you also want the component model that comes with it.

It's all the other stuff that you can do with Spring that has made it a crucial tool in every developer's toolbox today. These frameworks deliver real value to customers because they simplify or enable outright solutions that they couldn't otherwise build. I think this is more true every day as the industry continues to grow and evolve, and Spring tracks it in lockstep, providing support for all th emerging trends and technologies. The cloud and big-data are two key areas where the players and - indeed-the game itself is changing so fast that no standards body could ever hope to do a good job standardizing there.

Anyway, enough of that rant. Just my two cents, as always. If you weren't paying attention to IoC or DI, then you don't know what you missed and this post won't be of much help ;-) It's interesting to see that today there's a very active debate about IoC and DI in both the .NET and ActionScript communities. The discussion there feels very simialar to the intense debates we had in the Java world 10 years ago. And there too, the winners will be the ones that deliver the most business value beyond simply supporting the "dependency injection" pattern.

Rest in peace, Excalibur.

January 26, 2011

Birthday week 2011

Well, it's that time of year again! My dad's birthday, my birthday, and my favorite little 3 year old's (My buddy's little girl Makani - she's a whopping three years old already) birthday! I'm taking a trip to Portland, Oregon with the misses this Friday to visit dad and see the family. I'm really looking forward to that. Nothing quite so wonderful as perpetually, if only slightly, damp trees and coffee. :-)

At "work" at SpringSource (where I spend the largest chunk of my day and usually the happiest part, too!) we just posted "Green Beans: Getting Started with Enterprise Messaging in Spring." I had a fairly big hand in that and feel like it'll be a very good introduction for a lot of people to two of the most important tools you can have in your arsenal, AMQP and JMS. In my humble, bordering-on-insignificant-opinion, the Spring support for JMS has always been second to none. It's easier to use JMS from Spring than it is from Java EE or anything else by far, and it has been for most of the last decade. It's way easier to use AMQP-based brokers from Spring than anything else! Check it out - add that extra asynchronous kick to your architecture and code!

For my new year's resolutions, I decided I needed a hobby (err, besides coding...). I sat down and wrote up a list, like this:

  • work out and diet. Aim to lose 10 lbs a month. This was basically a fear-based reaction. It reflected a lack of resolve in last year's resolution, which was to gain 1 lb a month. I was told to never negotiate out of fear! Don't negotiate with terror (ists)! Choosing this would amount to an affront to the basic liberties I've long held dear.
  • Read comics more. I used to read comics a lot as a boy, and look how I turned out; I'm fi... well... eh, I could be worse!

Anyway, after giving option one due reflection, I decided for option two, because ... well, who wouldn't? So, for my birthday, my wife bought me (sssh! She doesn't know this yet, it's a surprise...) a Marvel Comics digital comics subscription. All told, it was like $60.00 for armchair-easy access to all the comics you could ever want to read from the last... at least 10 years (I missed a lot of stuff in the last ten years!) as well as new stuff. The only gripe is that it uses Flash to display the comic books on the screen (which isn't normally something I care about one way or another) and it doesn't have an iPad app. It works ok on my Google Nexus S, and of course my Linux Book Pro works perfectly, but they're of clumsy form factors. I want it to work on the iPad. I'd even pay an extra ten dollars.

Maybe next year...

<< Last | Next >>