I am strongly against software patents, and as such I’m very happy that ThoughtWorks has decided to sign the EU petition against software patents.
I recommend any individual with the same views to sign – and to convince their company to do the same. You can do it here: http://www.stopsoftwarepatents.eu.
One of the problems you might encounter using a native Emacs on top of Mac OS X is that your custom PATH variable doesn’t really translate into your running Emacs instance. This might show up as making it impossible to run things like Ruby or Ioke from inside of Emacs – complaining that it can’t find the executable in question.
Another thing you might notice is that your Ruby environment is messed up – all the gems you so carefully installed isn’t around, and overall things just seem weird. One thing that could cause this is when you have a custom built Ruby installation in for example /opt/local or /usr/local instead of /usr. But Emacs just seems to pick up the original versino that shipped with OS X.
The reason for all these weird behaviors is that if Emacs is started from the Dock, or using the application directly, it doesn’t actually pick up the carefully prepared PATH variable you have in your terminal. Instead it will go ahead and use the default system PATH, which is very restrictive.
The way I prefer to solve this is to make sure that OS X plist version of the PATH variable is the same as my terminal one. I do that by resetting this plist on every login. Of course, OS X will not actually reload this without a reboot. If you just want to fix this once – and you’re reasonably sure you won’t change the path again, you can execute this command from the terminal and restart. Everything should be fine after that. The magic incantation looks like this:
defaults write $HOME/.MacOSX/environment PATH “$PATH”
(Note, I’ve had to solve this problem twice, since the first time I encountered it I didn’t blog about it. So now I’m blogging so it might also stick in my long term memory. Maybe it’s enough if it’s in my blog term memory…)
The title for this blog entry is actually dual in purpose. I will talk about the two last days of JavaOne, the Thursday and the Friday this week. But one of the big rumors from the news room this year was that it is likely that this JavaOne will be the last one ever. I can’t really comment on that, but this JavaOne did feel a bit less enthusiastic than it used to. Anyway. The last two days were less hectic than the first ones, so this entry won’t be very long.
My first session of the day was Neal Fords talk about design patterns in Groovy and JRuby. I’ve seen this talk before, and it is pretty good – Neal talks about how some of the classic Gang of Four patterns disappear in languages that support more advanced features. So Neal showed some of these. After that he went through some new patterns he has seen in dynamic languages, such as his Type Transmogrification pattern.
After that Tobias Ivarsson talked about how to explot concurrency in dynamic languages. I was a bit surprised to see Scala in this talk, but it did make sense. The content was very good, although Tobias ran out of material quite quickly. It was interesting to see how different the concurrency performance of JRuby and Jython was – but of course this is something the Jython guys easily can fix, once they’re done with the more pressing issue of getting 2.5 compatibility. In fact, they are making rapid progress on this, and this week saw a new release candidate released. Good stuff.
After that Charles and Tom did a talk about scripting Java with JRuby. This was a new version of the classic JRuby talk, and I think it worked really well. Most of the talk concentrated on a larger example instead of looking at small tidbits.
After that me and Charles spent a few hours in the ThoughtWorks Studios, taking a look at how the JIT compiler works with Mingle.
The first and only BOF for the evening was the JSR 292 Cookbook BOF. This session went into some more details on how it works, showed some code that uses MethodHandles and also had Charles talk about his experience with using invoke-dynamic in JRuby.
The Friday started with Gosling’s toy show. Sadly, I missed most of that. My first session was an introduction to the internals of IBM’s Java Virtual Machine. A very interesting presentation that looked at the kind of optimizations their VM does – including showing how the assembly generated will be different depending on how hot the code in question is.
After that Brian Goetz and two other HotSpot engineers talked about the kind of things HotSpot do to make Java code fast. Together, those two talks gave a pretty thorough understanding of how JVMs can be made fast.
This year at JavaOne was pretty good. Lots of fun stuff going on and many interesting sessions.
Not sure how known this antipattern is. I’ve seen some libraries that are very good at not doing it, but I’m also seeing lots of Ruby code that does use it without reason.
What I’m talking about here is the common usage of using instance_eval on a block to make it possible to use other methods inside of that specific block. If you want to do stuff based on method_missing inside of a block, this is the way people generally use.
So what’s the problem with it? Well, the problem is that blocks are generally closures. And you expect them to actually be full closures. And it’s not obvious from the point where you write the block that that block might not be a full closure. That’s what happens when you use instance_eval: you reset the self of that block into something else – this means that the block is still a closure over all local variables outside the block, but NOT for method calls. I don’t even know if constant lookup is changed or not.
Using instance_eval changes the rules for the language in a way that is not obvious when reading a block. You need to think an extra step to figure out exactly why a method call that you can lexically see around the block can actually not be called from inside of the block.
There are ways around instance_eval usage in a library – you can always assign self to a local variable outside of the block, and then call methods on that local variable. How ugly does that sound?
In almost all cases, if a block needs to handle method calls on a specific object, it should send that object in to the block as an argument. Take a look at routes in Rails – they could have been defined with instance_eval, but they’re not. There is no reason to use instance_eval for this case. Rails send in a route instead. File.open doesn’t use instance_eval with the block. It could, but instead it sends in the file. This is because there is no need to use instance_eval, and sending in the object as an argument gives the definition more power.
This doesn’t mean instance_eval should never be used. That’s not true, it’s a hugely useful feature, but it should definitely be used with good taste. If you’re unsure when to use it, don’t!
Best presentation at JavaZone so far was Gilad Bracha’s talk about NewSpeak. I might be one of a few number of people who thinks this of course, since for most Java developers NewSpeak is quite out there. For language geeks though, it’s a gold mine of interesting ideas, realized in a very nice way.
So, what is it? Well, NewSpeak is a new language created by Gilad Bracha (who used to work as Language Theologist for Sun – meaning he was one of the theory geeks for Java). NewSpeak actually doesn’t have anything to do with Java. It doesn’t run on the JVM. It’s not written in Java. It doesn’t look like Java. In fact, it’s closest relatives are Smalltalk, Self and Beta. It runs on top of Squeak, but there are plans to make it run outside too – probably targeting V8 for this.
If you were just to glance at the language, it looks a lot like Smalltalk. Gilad has based the syntax on Smalltalk, but have no problem with adding or removing things to make more code more readable, more accessible, and so on. But as it turns out, many choices in Smalltalk happened to be there for a reason, and having them gives lots of benefits.
So what are the nice features of it (except that it’s based on Smalltalk?) Well, these are the things that I took notice of:
In conclusion, I really like what I see in NewSpeak. I look forward to when it’s released (it will be open sourced under Apache 2.0). It’s got some fresh new ideas about how to approach language design.
Read more at Gilad’s blog: http://gbracha.blogspot.com/, or at http://newspeaklanguage.org/.
I am really happy to announce Ribs 0.0.2. This version changes loads of things – I realized that I didn’t really like some of the decisions I made for the first version, so this release is totally incompatible with 0.0.1. I haven’t added associations yet, since I wanted to push this out with the new way of defining stuff before doing that.
Ribs is a library for JRuby, that allows you to persist Ruby objects using Hibernate. Some time ago I wrote about ActiveHibernate. I have now decided to implement this myself, and the result is the Ribs project.
The functionality in 0.0.2 is about on par with 0.0.1. You can do a few more things, but not much.
I have made some simplifications which means that you never need to define anything as long as your model follows conventions. That means basically that you can just start working with a class or an instance of a class, if you want too.
So what are the main differences compared with the first version? The first one is how you define mappings from properties to other things. It now looks like this:
class Blog Ribs! :table => :fox_blog do |r| r.id.primary_key! r.title :column => :blog_title r.body :column => :dfsvdfdgdf_TEXT r.something.avoid! end end
These changes will make it easier to add support for complex objects and associations later on.
Ribs has an identity map on by default. It can be turned off on a definition by definition basis by an option to the Ribs! method call.
But the really large difference with this version of Ribs is that it no longer puts anything in the model classes. Yeah, that’s right. All database dependent state is kept elsewhere. This means that you’ll have to define your classes yourself (or use some helpers I’ve defined). If there is no accessor for a property, Ribs will set data on the classes using instance variables instead. The data in a specific instance is not tied in any way to a specific repository or to a specific mapping. I’ve put the layers in to make it easy for a model to have several different mappings for different databases.
So how do you do things with the database if no methods are on the model, and still have it look nice? Like this (assuming Blog has attr_accessors):
blog = R(Blog).create :id => 1, :title => "Foo" blog.body = "Well now, look at this:" R(blog).save blog = R(Blog).all.first R(blog).destroy! R(Blog).get(1)
OK, I admit, there’s three more characters to type for all this stuff. I know, it sucks. No, not really. I’ve done stuff with it for a week now, and it feels quite natural. And there are some other benefits to this approach. The large one is obviously that there is no pollution of the models going on. They are really just simple POROs (and a Struct works quite well for these objects). When you call R, you can supply an optional database parameter, meaning that you can work with the same model – even the same instance – against different databases. There is also some other benefits tied to the fact that all database operations can be parameterized like this. And the base case still feels quite nice.
So, that’s Ribs 0.0.2. I would really like comments on it. The next one should be the big one – with associations of some kind.
More documentation can be found here: http://olabini.com/projects/ribs/doc.
You can download the gem at: http://olabini.com/projects/ribs/downloads/ribs-0.0.2.gem.
The git repository is at: git://github.com/olabini/ribs.git.
You can also install it through gems.
The project is released under the MIT license.
I am currently sitting with Ribs, trying to decide how the definitions for associations should look like. I’ve also decided that I don’t want to use the current scheme for properties either. I also have some interesting constraints. First, I do not want to evaluate the block using instance_eval, so introducing nice method_missing hooks in the block context is out (so I can’t do anything like “has n” as DataMapper). Also, all definitions need to be able to take additional parameters in a hash. So something like “rib.has * :Posts” won’t work either.
I have come up with something that I’m reasonably happy with. It’s quite terse but definitely readable. It doesn’t pollute any namespaces. And hopefully it will only be used when the model need to differ from the conventions. I’m thinking about taking conventions a step further with Ribs and automatically try to figure out associations based on naming and foreign keys – but I haven’t decided about that yet.
All of these examples are supposed to be executed inside the Ribs! block, with r being the Rib parameter. I’ve decided to allow the table name as a parameter to the Ribs! method call instead of being something you set inside.
First of all, setting which property/properties are a primary key, I’m thinking about one or more of these alternatives – where track_id is the property name:
r.track_id :primary_key r.track_id :primary_key => true r.track_id = :primary_key r.track_id.primary_key!
I’m skittish about the track_id= alternative, but the others I think can coexist quite well.
The next thing is to handle the mapping from one property name into a different column name (if no column name is specified, the property name will be used, of course):
r.title :column => :track_title r.title.column = :track_title
Nothing very extraordinary here. I would probably like to have both alternatives here.
The next one is more interesting. I haven’t yet decided how to handle specifying primitive types. This code is supposed to handle the case that in ActiveRecord are covered with has_one and belongs_to. I don’t really see why they have to be different, really, so I’m thinking about doing something like this:
r.blog :is_owner r.blog :is => Blog
I’m skittish about :is_owner, but it also feels slightly icky to have to specify the type of all single associations. This is definitely an area I would like to have some good ideas about.
Finally we come to the one-to-many and many-to-many associations. What makes this different is that I can have both a Set and a List (and also Map) since Hibernate handles these for me:
r.comments :list_of => Comment r.comments :set_of => Comment r.comments :is_set r.comments :is_list
Once again I’m not sure how to handle it in such a way that you don’t have to write the name of the other entity in all definitions.
Anyway, this is what I currently have. I would appreciate innovative ideas here – especially if they are innovative within the constraints I’ve set for myself.
I feel like I’ve been picking a bit on DataMapper in my recent posts, so I first want to say that I like most of what I see in DataMapper, and is generally just nitpicking. I’m also what I’ve noticed there to give examples instead of making up something. And actually, one of the reasons is that it was some time since I read much Ruby code, and DataMapper happens to be one of the things I’m looking a lot at right now.
Which brings me to something Sam Smoot said in the discussion about adding operator methods to Symbol. (In the blog post Simplified finders in DataMapper). What he said was this:
That might satisfy some, but it ranks pretty low on the “beauty” gauge. And that really does matter for adoption…
Now, the reason I’m bringing it up here is not to pick on Sam or DataMapper (Really!). Rather, it’s because an attitude that I’ve noticed all over the Ruby world lately. In most cases it’s not explicitly said like this, but I like Sam’s quote because it verbalizes exactly what it’s about. You really want your library to look nice. Beauty is really important in a Ruby framework. It really is important, and lots of focus is put on it. And one of the reasons for this is to drive adoption.
Since it’s been verbalized like this, I’ve realized that this is one of the things that really disturbs me with the Ruby communities fascination with making everything, absolutely everything into a DSL.
Now, I really do like thinking about DSLs and working with them. Being a language implementor brings that out in me. But a DSL really has it’s place. Why shouldn’t you make everything into a DSL? Why shouldn’t everything look nice? First of all, the initial development might just not be worth it. A DSL-like approach generally involves more effort, so maybe a regular API works fine? A DSL introduces cost, both in development and in maintenance. Everything you do needs to be balanced. My coworker Marcus Ahnve gave a very good example of this today. He wanted to use ctags with an RSpec file, but since ctags doesn’t understand “describe” and “it”, there was no way for it to extract any useful information from it. Now, this is a trade of the framework designer has to make, and in the case of RSpec I think that the DSL is totally justified, but in other cases it’s not.
So take the issue at hand. Adding a few methods to Symbol, so that finding information in a database will look a bit nicer. In real terms this involves polluting the Symbol namespace with methods that have a very narrow scope. The usage (that looks more or less like this: Exhibition.all(:run_time.lt => 3)) uses something that reads easily from an English/SQL perspective, but not necessarily from a Ruby perspective. The main question I have when seeing this is what the eventual cost down the line will be for having it. Is this approach expandable? Is there any possibility of clashes with other libraries? Will someone else easily maintain it?
Focusing on beauty to generate adoption seems like the wrong choice for me. You add things that might not be so good long term, to get a larger initial code base. I would prefer to make the right choices for the right reasons first, and then let adoption be driven by that.
In summary, be responsible when designing APIs. I know those are very boring words. But it’s a reality, and your users will thank you for it.
PS: Sam just wrote a new comment, saying that the Symbol operators will be optional in the next DataMapper release. Good choice.
It seems I’m spending lots of time reading about DataMapper currently, while planning the first refactoring of Ribs. While reading I keep seeing Sam’s examples of simplified finders compared to the ActiveRecord versions. A typical example of the kind of thing I’m talking about is something like this with ActiveRecord:
Exibition.find(:all, :conditions => ["run_time > ? AND run_time < ?", 2, 5])
Which with DataMapper would be:
Exibition.all(:run_time.gt => 2, :run_time.lt => 5)
Oh, and yeah, it the typo is directly from the DataMapper documentation. So what’s wrong here? Well, in most cases it probably does exactly what you want it too. And that’s the problem in itself. If you use these simplified finders with more than one argument, you will get subpar SQL queries in some cases. Simply, if you don’t control the order of the clauses separated by AND, you might get queries that perform substantially worse than they should. Of course, that doesn’t happen often, but it’s important to keep it in mind.
And incidentally, I really do hate the methods added to Symbol.
It’s been some quiet months actually. But now that’s over. The next three weeks I’ll be showing up in Oslo, Santa Clara and Aarhus:
Hope to see you there.
|
I am a software developer working for Centro de Autonomía Digital, mainly with privacy, security and cryptography issues. I have worked on many different things in my life, including programming language design and implementation, security, privacy and cryptography, artificial intelligence and more. |
|
Quito |