Yup, another job opening. If you're interested or know someone who'd kick ass in this job, let me know.
The job is on-site in Sunnyvale, California.
<job_posting>
Enjoy solving hard problems creatively? Know all the GOF patterns? Can you make database schemas into 3rd Normal form? Do you know the difference between REST, SOAP, and MOM?
We are looking for an engineer to architect new services, build shared libraries, and refactor existing systems. You will work with Yahoo! News, Sports, Weather, Finance, Health and other groups to build exciting systems. You will deliver complex projects in demanding deadlines while helping other engineers design and implement their systems.
If you've had experience building high-throughput systems, can design an class hierarchy in your sleep, and know all about web services, then we're looking for you.
Qualifications
</job_posting>
I know some (many?) of the folks you'd be working with in this job. They're smart folks who love building great technology.
Oh, and don't ask me what "exciting systems" are. We all know that job listings are partly sales pitches, so that's what you get I guess.
Kasia is looking to attend JavaOne later this month in San Francisco, but the company won't foot the bill for admission. I guess working in Java all day long (and sometimes all night too) for several years isn't sufficient to justify a bit of off-site training.
Does anyone have a contact that might be able to score a ticket? I bet she'd even promise to blog about the conference.
Hmm. Tim works at Sun now. Maybe he knows...
Oh, and before anyone offers, a media/press pass won't help. They're typically limited access. I could get one of those if needed. It's relatively easy to do so.
Any ideas?
Everyone enjoys a good language bashing now and then--especially when it's a shining example of how the language makes it hard to do something amazingly simple, like reading a file.
Browsing Java documentation on Sun's Java site is incredibly frustrating because the site doesn't seem to support a basic operation I want: search.
Consider this example. I performed a Google search for java.util.Map.Entry and eneded up on this page. It has a lot of useful information on it. But now that I'm there, I was to search for something. I guess I have to go back to Google and start over. There's no search box on the page. WTF?!
Contrast this with any reference page on php.net, like this one (chosen at random). It's far more search friendly. There's a box right at the top of the page and a drop down box that helps me crontrol what I'm searching.
php.net docs: good.
Sun Java Docs: less good.
Oh, it's not just PHP. The MySQL folks get it too. Here's a randomly selected example from their docs. Notice the search box.
This cracks me up.
I remember back in the mid-90s when Java first came out. I actually read the Java 1.0 language spec. The whole thing. It was cool. One of the folks who was telling me about it (just before I read the spec) endorsed it by saying "it's like a cleaner C++ with no pointers!" I've heard the "you don't make pointer mistakes in Java" bit a lot over the years.
Despite all that, I'm still able to convince Java to throw a java.lang.NullPointerException at me. Every time I get one (which is pretty often right now) I have to laugh just a bit because this is the a language without pointers.
Riiiiight.
Success! I understand a bit of the object/interface model I'm working with--at least enough to add some functionality and not have it blow up. It compiles and runs. I've sucessfully extended my first real Java code in a meaningful way.
I got a TrackBack ping that lead me to K's article about my and Java which I thought was interesting. (K is not to be confused with Kasia who has been called "K" on some occasions.)
Apparently the transition I'm going thru is expected--or at least not unusual. That's makes me feel a bit less dumb when I'm struggling with this stuff. The other reassuring experience is sitting down with the code architect and finding that his design and implementation now stumps him to a degree too--at least in a few places.
K recommends that I look at Eclipse (again) as an editor that will help me out. I may have to do that. A fair number of folks have suggested it.
The next part is what has me wondering out loud...
I'll venture to give yet another advice. When getting to design with Java, know your Anti Patterns. Patterns are important, but I've found most experienced developers already use them (even if they can't name them). Anti patterns, on the other hand, are a tar pit for even the most seasoned developer. And Java lends itself to grandious designs, full of anti-patterns.
Okay. I'm the first one to claim complete ignorance on the whole "design patterns" fad. I call it a fad because it seemed to come out of nowhere (as most fads do) and everyone was talking about it for a while. Now it's pretty quiet again. So whether or not it really is a fad, it seems like one to a person that never really paid any attention to it. (I just figured it was a lot of noise being generated by the C++/OO/XP crowd.)
I assumed that design patters was a formal way of teaching folks to design their stuff the right way. You know, "here's the way to implement a foo... and here's how you do a bar." Something one step (or level of abstraction) above STL or other popular component libraries.
But that's all me thinking out of my ass. Like I said, I never paid any attention. Why? I never saw a compelling reason to. I don't follow fads. And nobody ever presented a good "here's why you should learn this" argument. I just saw a lot of folks going after design patterns and getting all intellectual and impressed with themselves for being able to use a bunch of fancy new words for the things that probably weren't new at all.
And, well, they didn't teach "Patterns" in my computer science program. I wonder if they do now?
Anyway, now I find out there are Anti-Patterns. Okay, fair enough. They must be the opposite of Patterns. So I followed the link and read the page about Anti-Patterns.
It doesn't tell me anything. Well, maybe a little.
An AntiPattern is a pattern that tells how to go from a problem to a bad solution. (Contrast to an AmeliorationPattern, which is a pattern that tells how to go from a bad solution to a good solution.)
A good AntiPattern also tells you why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead.
But beyond that it begins to feel really academic in a hurry.
Okay. So it's a collection of "you think you want to do this, but it's actually bad... here's why" stories and rules. Fine. Once you've learned the right way, you get to learn the wrong way too.
K's advice, then, is easy after you've gut thru all the OO babble. Learn the wrong ways to do things so that you can spot them. You shouldn't be re-inventing the same mistakes that others have.
That seems like good advice to me.
Ignorance is bliss. But not always. Sometimes it just makes you feel like you might have missed something important in all the hype.
So I've been working to understand the Java code I need to extend at work. And it's quite a bit of culture shock after being a Perl Hacker for the last... well, a long time. I've done Perl in some capacity now for over nine years.
Java folks love abstraction. Thanks to Kasia's blog entry on Interfaces, a bit of chatting with her, and reading up a bit, I now get interfaces. They're Java's answer to multiple inheritance. The provide a contract of sorts between various objects. And object that implements interface foo must provide (at least) all the methods defined in the interface. It's enforced at the language level. Very good.
The downside is that folks can get carried away, building so much structure that the real workings of a system end up obscured and hidden behind so many layers of indirection and abstraction. It makes my head hurt a bit. I've spent a bit of time manually drawing out some inheritance diagrams (anyone have a free tool to automate it) based on reading the code and associate javadocs.
I suspect that once I get my head wrapped around all the interfaces, I'll be far more productive and have a real understanding of the system's design.
The other thing I've noticed is that Java folks are big in infrastructure and re-usability. Really big. I'm starting to wonder if I'll ever see code that looks like someone wrote it to actually get some work done--without much regard for the random person who might want to sub-class it someday, maybe.
Don't get me wrong. This isn't bad, but it sure is different. It takes some getting used to. Instead of learning a new language and gradually putting it use, I'm forced to also learn several large frameworks along the way. It's a bit of a double hit. I feel like I've been thrust into a foreign country where I need to learn the language and function as a useful member of society--once with a lot of unwritten and complex rules that I just need to figure out.
Hey, I could have written about Apple's various MacWorld announcements but it seems like blogspace has that covered very well without me today.
So I'm reading some official documentation about JDBC and I run across this bit of text (emphasis mine):
The second major advantage is that the DataSource facility allows developers to implement a DataSource class to take advantage of features like connection pooling and distributed transactions. Connection pooling can increase performance dramatically by reusing connections rather than creating a new physical connection each time a connection is requested.
What does "physical" connection mean in this context? Is there really somebody sitting at a very small switchboard inside my server, putting plugs into sockets so that I can communicate and then removing them when the connection is no longer needed?
No.
It's all digital. The word "physical" does not belong at all. It conjures up images of a long ago era when telephone "operators" actually did operate as your local telephone switch.
I believe the point that the author is trying to make is this: creating new database connections may take a non-trivial amount of time which is all "overhead" as far as you're concerned. It's best to minimize or eliminate that. Connection pooling is the traditional solution. (Or you could use an alternative database server that doesn't have the per-connection overhead that the big one does. But that's really a side issue.)
That just bugs me.
Well, it's not really day #3. But I've spent a fair amount of time on Friday and over the weekend reading a copy of "The Java Programming Language" to refresh my memory on all this new-fangled Java stuff.
I decided it was time I wrote a stand-alone Java program to do... something. Normally, you'd expect someone to write the standard "Helllo, world." program and build from there. No, not me. That's too easy and likely to work on the first try.
No, for me a good first program is one that connects to MySQL, runs a query, and spits out the results. In this case, the query was to be SHOW DATABASES. As you might guess, that asks MySQL for a list of all the databases it knows about. Think of it as "Hello, MySQL."
So I headed over to the MySQL web site to download Connector/J the official MySQL JDBC driver.
Once it was unpacked and installed, I began working on the code. I had found some example code on-line was close to what I needed, so I adapted it a bit. Once it compiled successfully, I spent a lot of time chasing down a really dumb run-time exception. It seemed that Java could find the driver I had just installed. According to the docs, I could either put a whole directory tree into my CLASSPATH or just use the single JAR file. I opted for the jar file, because it seems cleaner. I'd rather deal with a single file. I'm sure that's a bit of a performance hit, but it's only startup cost and I really don't care about the startup cost. I'll be writing server-side code anyway, so it generally starts once and then runs for a long time.
Anyway, to make a long story short, Sun did something rather stupid. I wasted a good hour because I should have put an explicit reference to the jar file in my $CLASSPATH. It's not sufficient to simply drop the jar file into one of the directories specified in $CLASSPATH.
At this point, I felt like the guy in that one switch parody who, after upgrading to OS X from OS 9, says "What the fuck?!"
Do the morons at Sun (one of the oldest Unix companies!) not realize how Unix path variables normally work? Paths specify directory names, not zip, tar, jar, or any other type of archive files.
Note to Sun: Thanks for breaking 20+ years of tradition so that I could waste an hour scatching my ass on this problem. There's nothing like pulling dumb tricks like this to make the barrier to entry just a little bit higher.
Why can't Java just check all the *.jar files that happen to live in given directory? Is that too damned hard?
Anyway, the good news is that after I fixed that stupid problem (I copied the jar file to $JAVA_HOME/jre/lib/ext instead of endorsing Sun's bad decision), the code worked on the first try. Granted, the code's a bit verbose compared to the Perl equivelant, but it's a nice little class that could be reused in some other simple proof-of-concept code. It all reminds me a bit of learning C++ way back when.
Excellent. My version of "Hello, MySQL." works. That wasn't so hard after all.
Next up, learning a bit more about the JDBC API, connection pooling in Java, and related fun stuff. Oh, I also want to play with Connector/J's failover feature. It sounds like a neat idea that I just might have to implement in DBIx::DWIW for Perl.
I spent a fair amount of time today reading about and playing with IBM's Eclipse. My reasons for investigating Eclipse are twofold: (1) I'd like to see if it is compelling enough as an IDE to make me switch from GNU Emacs. (2) I was tasked with learning about plug-ins and what Eclipse was really designed for. We were wondering about using it as the framework on which to build some Java GUI tools.
On the first count, I've found Eclipse to be rather frustrating as an IDE. I have a project that lives in CVS today. I was hoping to point eclipse at this directory and begin working with the files. So far I haven't determined how that can be done. The wizard-like things that attempt to guide me thru the project creation process aren't terribly helpful in this regard.
Furthermore, my interactive response with Eclipse it less than I'd hoped for. On my Pentium 3 866 with 768MB RAM and a Voodoo 3 3000 running Debian Linux, it just feels sluggish. If I type a bit too quickly, it can't quite keep up with me. And some of the UI stuff just takes a bit too long to be pleasing.
Don't get me wrong. Eclipse is an amazing piece of software design. I just don't think it's for me. I should probably spend some time checking out what the Emacs world offers for Java programmers. If it's even half as impressive as the C/C++ tools, I should be just fine.
As to point #2, after reading the white paper, it's pretty clear to me that Eclipse was designed for software development. While it is a relatively generic framework, I'm not sure that it's appropriate for building the sort of tools we envision (data browsers, query interfaces, and management tools). Anyone have counter examples? Stories to the contrary? I'd love to hear/see 'em.
Tomorrow will probably be Avalon day, while Friday and Monday will focus on JDBC and MySQL connectivity.
Matt notes that there's a thriving java.blogs community. I must say, I'm impressed and surprised. Impressed at the amount of good Java stuff in the blog community and surprised by the "Yahoo using Avalon" headline that's currently on the site. Thanks for the linkage, Chris.
I guess I need to make a few new additions to my blogroll...
Well today was my first day in my new job and it was time to get reacquainted with Java. My first task was to get the existing code base working on my Linux workstation (rather than fight the Java on FreeBSD demons). I downloaded the JDK from Sun and installed it. Checked out the appropriate code from CVS. Ran the compilation process. It all compiled. Ran the script to start up the server. It started. On the first try. No tweaking.
So I guess this Java stuff really IS multi-platform, huh?
My next task was to modify the command line interface to the server (you telnet to a funny port and issue commands to it). I added an echo command, so you can telnet in and type echo foo at the prompt. If it works, the server says: foo
Yeah, this is high-tech
Anyway, that was hard that I thought it might be. If memory serves, I created 3 new classes and modified as many configuration files. I'm a little surprised at the amount of code necessary to do something that trivial. I hope it's not a sign of things to come. Maybe Perl has spoiled me a bit too much?
My next task is to learn more about the server framework we're using: Avalon from the Apache project. According to the Avalon site:
The Avalon project is an effort to create, design, develop and maintain a common framework and set of components for applications written using the Java language.
Lots of docs to read. And I need to brush up on my language skills. This whole "everything is an object" mentality is going to take some getting used to again.
Oh, I suspect there's gonna be a lot of Java commentary spewing from me in the near future. I'll create a Java category in my blog for it.