So Apple finally got around to releasing Java 6 for OS X.
Pity it’s Leopard only, but better than nothing (I really have to get around to upgrading).
This Java for Mac OS X 10.5 Update 1 adds Java SE 6 version 1.6.0_05 to your Mac. This update does not replace the existing installation of J2SE 5.0 or change the default version of Java.
I finally got around to registering a domain name, and self-hosting this blog on a real webserver.
So, update your bookmarks to www.rawblock.com (redirects from the old rawblock.blogspot.com should be working though). I think there might be some feed issues with the way blogger does the templates. Anyway, will see how it goes.
I’m trying to migrate it from blogger to wordpress eventually, but this is the first step.
I’ve been a bit quiet on this blog of late, mainly due to the usual work stuff, and the fact I’ve been playing a lot of Team Fortress 2, and blogging about it on my other site at ubercharged.net. I’ll get bored of that eventually and go back to blogging about coding again some day soon 
Update
Done! Migrated to a self hosted word press install.
blogger isn’t nice enough to allow redirects for each individual post (it just redirects to the home page), but I’ll just have to live with that one.
First post from the new host.
Looks like its working 
There are two programming buzz areas that get a lot of thought mileage on the interweb at the moment: Dynamic typed languages; and languages that support concurrent programming. Both are important concepts that are driven by their own good reasons, but they exist in isolation in separate communities with very little overlap. Each is pursuing their own goals separately of the problems the other is trying to address (and making great progress with).
Ruby, Python and their dynamic siblings are getting a lot of attention at the moment. There are good reasons for this which have been well discussed in the blogosphere, and I’m not going to churn out more flame bait by dredging them up again.
For all that dynamic languages have going for them, there is one big elephant in the room that no one wants to talk about much: They are dog slow, and they pay lip service to dealing with the changing CPU landscape. Slow has been fine for the past couple of decades. So you have a slow language. No problem. In a few years CPU clock rates will have doubled and it won’t be slow any more.
Problem these days is that clock speeds have been standing still for some time. The real action is in cramming more cores onto each CPU, and cramming more CPUs in your computer. If your Ruby app runs slow now - you’re in trouble. That is about as fast as it’s going to get. Maybe the next generation CPUs might creep up to 4ghz, but that’s about it. There are physical limits to this stuff, and we’re right on them. There is only so far circuits can be shrunk and clock speeds increased before electrons stop flowing round them.
This isn’t such a problem for Rails and other web apps. The standard response is that you throw more hardware, and separate OS processes at it, and this does work well for web apps that are dealing with isolated requests to a shared database. In this case, better faster hardware will save you, and this is a good thing. It lets developers get on with writing code rather than tweaking every last micro-optimisation out of their code. Joel Spolsky touched on that the other day.
But there are other apps that don’t work as well with the shared nothing scaling approach. I can think of a whole class of applications at Shine Technologies where there is a need for high throughput batch processing with a lot of data flying back and forth between parallel processes. Currently these are written in Java, but I’d love to be able to use a dynamic language like Ruby for them. It just isn’t an option though due to the poor performance. They need to run as a single app spread across multicore and/or multicpu and/or distributed CPUs. Ruby doesn’t make that so easy.
Which brings us to languages tailored to do exactly that:
Erlang and other functional languages that allow massive concurrency are the other hot ticket item on the blog rounds these days. Message passing is seen as one of the saviors to guide us past the clock speed stagnation into proper parallel programing that doesn’t suck.
And to be honest, it looks like the best approach out there at the moment. The Erlang way is to use immutable state, asynchronous message passing, and extremely light-weight processes to enable concurrent, scalable applications. The fact it also makes it easy to scale apps across a distributed grid is the icing on the cake.
But as pointed out by Cédric Beust, the language itself is a little clunky. I’ve been working my way through Programming Erlang
Which is the dirty secret of the concurrent crowd. Erlang is elegant and powerful, but not as accessible, fun or productive as dynamic languages are.
Both these types of languages have huge strengths, and some weaknesses that are solved by the other camp. But they exist almost totally independently of each other. When discussing one, it’s almost as if you’re in a different universe to the other. The concepts don’t intermingle at all.
What I’d love is some twisted love child of Erlang and Ruby. Something that would be something like:
Ultimately I think that they will both drift together as part of their natural evolution. I’m just surprised it hasn’t started to happen yet. When it does happen, it will probably from the dynamic side going more concurrent rather than the other way round. Dynamic languages have a hole in performance that can only be fixed with concurrent programming techniques. Where as users of concurrent languages are happy with the current functional approach and probably have less of a need to change their entire programming style.
Combining these two languages approaches together could make for a killer super language with the best of both worlds: The productivity, pleasure, and agile development offered by dynamic languages; with the performance and scalability increasingly available from concurrent focused languages as multi-core, multi-cpu boxes and distributed processing become standard.
Eric Redmond over at Death by Overcoding has posted a discussion on 5 Reasons Static Typing Sucks
It’s a great article, and I agree with pretty much all of it. For the most part excessive static typing is a PITA. The illusion of safety is just that. Static compile time checks only catch the most trivial of bugs, and even then, most of those would have manifested themselves the first time the code was even run. When it comes down to it, the trade offs of the traditional benefits of static typing (you don’t shoot yourself in the foot; you and the compiler always know what’s going on), are often outweighed by the disadvantages discussed in the article.
However, the one thing I’ve always liked when working with static type systems, and one that is often glossed over when discussing dynamic typing systems, is how easily tools can interpret and navigate code. When coding Java in Eclipse, it’s amazing how easy understanding a massive code base can become. You’ve got simple hyperlink navigation, sophisticated refactorings, and smart code analysis that can show you what is called from where and how. Even interfaces and figuring out which implementation is used (which is kinda dynamic typing for Java) can be groked easily with a good IDE.
Got a class with some methods? Want to find where it’s called from? Check. Want to find what methods can be called on the argument you’ve been passed? Check. Want to refactor a whole class hierarchy? Check.
I really love Ruby, but the first thing that struck me when I sat down to code is how much you’re on your own figuring out what is happening. Got a method with an argument passed in? What is it? What can you do with it? Dunno. Want to call another method? What arguments does it take? What about the block it accepts? What does it return? Dunno.
Dynamic languages are great for quickly writing simple elegant code, but not always so great for following and debugging existing code (especially code someone else has written).
Try digging into the internals of Rails, and you’ll become very familiar with the free text search of your text editor. What the hell is that variable? Where was it even instantiated? Dunno. Once you understand the general layout of the classes and modules its pretty straight forward, and thankfully Rails has a pretty well laid out architecture. Which is probably the whole point. If your Ruby code is clean and well designed, then obviously it’s going to be easier to navigate.
So really it comes down to good developers doing smart things. The size and complexity of a good Ruby code base is significantly less than something comparable written in Java for instance. As with most things in software development, this is about trade offs. Ruby is smaller and simpler, but the tools don’t allow you to refactor as easily as Java (the agile purists will say your unit tests allow you to refactor, but it’s still a lot more manual and involved than the automatic refactorings you can do in Java).
It means that in dynamic languages, its more important to have a good design so you don’t get lost in dynamic spaghetti down the track. But at the same time you’re more likely to have a good architecture in the first place because you’re not wasting mental energy focusing on satisfying the static typing system. One of the weakness of static typing discussed in the original article touches on that - the fact that more design must be done up front to predict the future when using static typing. With dynamic typing you’ve got less baggage stopping you from evolving your design as you work, so you can apply the YAGNI principle more easily.
…Although I do still miss being able to zip around Ruby code like I can in Java.
(Yeah, I know Netbeans is getting there, but it’s still a long way behind what you can do with tools analysing and refactoring static typed code).
A decade ago, people said you couldn’t do refactorings and static code analysis with Java. Maybe IDEs will evolve enough over the next few years will make this true for Ruby as well, and we’ll get the best of both worlds.
Recently there’s been a lot of discussion around how processes in Erlang could be considered to be objects and that Erlang can therefore be considered an object oriented language. I really think that’s stretching the definition. They’re kind of right, but in the same way that the people who saw a vision of the Virgin Mary in a cheese sandwich were right.
Way back in 2004 you may remember some crazy woman announced she had a 10 year old toasted cheese sandwich which miraculously had the face of the Virgin Mary cooked onto it. The sandwich eventually sold on ebay for $28,000, which just added to the circus factor.
I’m not going to get into a theological debate over snack food, but I really just see a random burn marking. But then I’m not particularly religious, so I’m not looking for images of the virgin in the first place. If you were a devout Catholic with a love of toasted treats, you might be. If you were a Beatles fan, you might see the face of John Lennon or Ringo Starr.
As for me, I did see a kiwifruit with a mark the shape of New Zealand the other day. But then I am a New Zealander and kiwifruits come from New Zealand, so I’m more inclined to see that. Other people might miss it.
People look for patterns that are already familiar to them. When they encounter new things, first instinct is to apply existing knowledge to it. It happens with cheese sandwiches and kiwi fruit, and it happens with programming languages.
First up, Ralph Johnson wrote in Erlang, the next Java
Processes certainly support data abstraction and polymorphism. An Erlang process is a function that reads from the incoming message queue, pattern matches to find a particular message, and then responds to it. A function structured in this particular way is similar to a class in Smalltalk. Moreover, given several kinds of processes that have a common protocol and that share some things in common, it is easy to factor out the commonality into a function that they can both call. This is similar to class inheritance. So, you could even say that Erlang supports inheritance, though it does it very differently than in Java or Smalltalk. I imagine that many Erlang programmers think about programming as modeling. So, Erlang fits all the characteristics of an OO system, even though sequential Erlang is a functional language, not an OO language.
Kirit Sælensminde picked that up and ran with it in Erlang as an OO language.
As I’ve been looking more and more at Erlang it strikes me more and more that there is an object oriented language hiding just below the surface.
Chris Petrilli also commented in Object-oriented processes comparing Joe Armstrong’s comments on how Erlang is not considered to be OO, and comments by Dr. Alan Kay on the original definition of OO.
So, messaging is a core of both OOP and what Armstrong calls Concurrency Oriented Programming. In both cases, the concept of messages are used as a strong isolation mechanism to keep one piece from peering into another and fiddling with the internals. In the case of Smalltalk, for example, that piece is an Object. In Erlang, its a Process.
So are these guys right? Well, yeah. Technically. It’s more than possible to shoehorn an OO mindset into Erlang. I have to admit I thought exactly the same thing when I started looking at processes receiving and acting on messages. You can definitely apply OO thinking to the concept, and yes I have be doing mostly OO work for the last few years. This linking is a pretty useful human skill for picking up new knowledge, but you have to be careful though to stop and ask how much of that is accurate, and how much is from the mental filters inherent from previous experience.
You can apply pretty much any programming metaphor to any language you like if you shine the light the right way and squint hard enough: You can do Object Oriented programming in C if you want (it’s ugly and involves passing lots of “this” structs, but you can do it); you can do functional programming in Java (kind of, but without most of the power and elegance), or even duck-typing if you love your keyboard; and you can even fake a static typing system in Ruby if you’re a masochist. Does that mean those languages are actually productive writing code in that style? No. Sure it’s an interesting academic comparison, but of little value at the end of the day except to highlight the shortcomings in using those languages in that way.
So what about the cheese sandwich?
When I say that finding the OO in Erlang is like finding the Virgin in the cheese sandwich, I mean that if you look hard enough expecting to find something, then you probably will.
This is mostly all pretty harmless, and its a big benefit to learning a new skill to build on top of existing knowledge. However, we need to be wary of the fact that there are different ways of thinking about things. If we go applying all the old thought patterns because that’s what we’re most comfortable with, we risk missing a huge opportunity to do things in new and better ways. And Erlang does definitely provide that. There are numerous valuable and unique concepts that would be missed by examining it through just through the lens of an OO expert and nothing else.
Like most bits of Rails, ActionMailer has an elegant and coder friendly interface. With a bit of set up, it’s remarkably quick and easy to get running from vanilla Ruby outside of Rails.
Recently I’ve needed to bulk email a bunch of files to an internal server for testing purposes. I’ve used ActionMailer inside Rails in the past, and wondered how hard it would actually be to get it up and running standalone. Sure, there are a stack of other mail gems and libraries in Ruby to do this, but they expose a lot of the internals of STMP and can be a pain to use. Definitely overkill when all you want to do is quickly fire off some mails from a script. (ActionMailer is actually built on top of a lot of those libraries, and acts like a coder friendly wrapper).
My requirements were pretty simple: Iterate over a bunch of files, and attach each one to a separate email and send to some address.
Here’s what the code looks like for the ActionMailer class:
require ‘action_mailer‘ ActionMailer::Base.smtp_settings = {:address => ‘smtp.example.com‘, :domain => ‘example.com‘} class FileMailer < ActionMailer::Base def file(to, sender, file_name, content_type, strip_ext = true) # strip any directory fluff subj = file_name.gsub(/.*\//,’‘) #remove the file extension if required subj = subj.gsub(/\.\w*/,’‘) if strip_ext #standard ActionMailer message setup recipients to from sender subject subj #setting the body explicitly means we don’t have to provide a separate template file body ‘‘ #set up the attachment attachment :content_type => content_type, :body => File.read(file_name), :filename => file_name.gsub(/.*\//,’‘) end end
The only thing different from Rails, is that you need to explicitly configure the SMTP details via ActionMailer::Base#smtp_settings.
It’s worth noting that you don’t actually need to create a .rhtml view file if you specify the body attribute of your message. I ran into a few blogs claiming there was no way to turn off the .rhtml requirement - a quick inspection of the ActionMailer source code proves otherwise. I’m sure it violates good MVC design, but if you’re just throwing together a quick script, who cares. I’ve left the body in the example as an empty string (the server at the other end was only interested in the attachement), but you can specify whatever string you want there.
To use the mailer class, you just call it in the normal Rails ActionMailer manner. With ActionMailer you don’t call the mail action method you implemented, but a generated method prefixed with deliver_. So in our example, even though we implemented a method file, we actually call deliver_file (passing it the same parameters).
FileMailer.deliver_file(’recipient@example.com‘,’julian@example.com‘,’my_file.csv‘,’text/csv‘)
An interesting bit of digging on damnhandy into the WWDC session list points out that Java on Leopard (Mac OS X 10.5) is going to sport a 64 bit Java VM, along with Swing support for the new Leopard UI features. The WWDC notes are pretty brief and just buried in the general session listing page, so details are still sketchy.
javascript:void(0)
The interesting thing damnhandy points out, is that seeing as Leopard Java (Java 6?) is going to be 64 bit, it probably won’t run on Tiger (Mac OS X 10.4). That’s kind of a shame, but it’s better than nothing. I posted a few weeks ago that as a developer, I just want something that lets me develop Java code for other platforms and could care less about Swing support for the new Leopard UI. I wish Apple would either release Java 6 that runs with Tiger (even without Leopard support), or release the source to OpenJDK if they aren’t going to maintain it.
The session took place at 9am PDT (about 7 hours ago). Haven’t been able to find any details yet as to what was in it, but will update when info become available.
Update - actually, there was no new info. So Java 6 on OS X is still out in the wilderness…
A while back I wrote about my frustrations trying to get Ruby to talk to Oracle on Mac OS X. I’ve tried a new approach using JRuby and ActiveRecord-JDBC with great success.
What I’m after is quite simple: I just want to use Ruby for some simple housekeeping scripting tasks which occasionally means connecting to Oracle to shunt data around. So this is all outside of Rails, which adds to the fun.
The basic problem with Oracle on Mac OS X is that Oracle support is lousy (add that to my list of complaints :P). There is no standard client install, hence no standard Oracle C libraries. While there is a stripped down version of the libraries - it is only available compiled for PowerPC. So no go with Intel CPUs (unless you want to recompile Ruby for PowerPC and run in emulation mode - just to allow you to build the OCI adapter. yech)
So I gave up.
Until I gave it another shot with JRuby and ActiveRecord-JDBC. Here’s a quick guide:
From the command line:
gem install activerecord
gem install ActiveRecord-JDBC
A trap for new players is to make sure you’re using JRuby gem utility, and not the Ruby one - tripped me up.
This can be whatever you’ve already got, or maybe a new DB. Here’s what I’m using for this example:
--our table to test the setup.
--note standard activerecord setup with 'ID' as primary key
create table TEST_MESSAGES
(
ID NUMBER not null,
MESSAGE VARCHAR2(100)
);
alter table TEST_MESSAGES
add constraint test_messages_pk primary key (ID);
--sequence used to populate PK
create sequence test_messages_seq;Make sure you’ve got your Oracle JDBC driver in a handy directory, and run export CLASSPATH=ojdbc14.jar from your favourite command prompt. You can get the ojdbc14.jar driver file from Oracle’s JDBC download page, although in general I find Oracle’s site on a par with trying to Find Permit A-38 in terms of frustration…
Now for the fun bit.
# active_record is the standard rails AR require require ‘active_record‘ # jdbc_adapter is in ActiveRecord-JDBC, and makes a JDBC adapter # available to ActiveRecord require ‘active_record/connection_adapters/jdbc_adapter‘ # Connect to the database # - this is required because we’re running without rails. ActiveRecord::Base.establish_connection(:adapter => ‘jdbc‘, :driver => ‘oracle.jdbc.driver.OracleDriver‘, :url => ‘jdbc:oracle:thin:@server:1521:database‘, :username => ‘username‘, :password => ‘password‘) # our model class that maps to the table we created class TestMessage < ActiveRecord::Base end # insert a record hi_message = TestMessage.new hi_message.message= ‘Hello World!‘ hi_message.save # and another one for fun ar_message = TestMessage.new ar_message.message = ‘This is activerecord JDBC on Oracle‘ ar_message.save # should spit back out both our inserted records TestMessage.find(:all).each do |m| puts m.message end
In this example I used ActiveRecord standard table structures, but in practice I was connecting to legacy databases. ActiveRecord is still quite useful with legacy databases, but you just have to do a bit more setup. set_primary_key and set_table_name will get you some of the way. has_many and belongs_to with the :foreign_key option will get you most of the rest of the way.