HotRuby - Ruby on JavaScript & Flash →
hotruby.accelart.jp
For serious? Wow.
March 2008
16 posts
Proposal to encode Klingon in Plane 1 of ISO/IEC 10646-2 →
std.dkuug.dk
And to think… this was rejected! Man, who do you have to ♋ in a kinky ⚧ to get a character into Unicode?
What a ♨ pile of ☣. Fucking ☭s…
A Common Mistake in "REST vs. Foo" Arguments →
ramenlabs.com
There’s a good rebuttal here that responds one by one.
But, there’s something else here, which I see repeated again and again. I posted this in the comments. Reprinted for your edufication:
I think there’s crucial distinction between between XML-RPC as a protocol and RPC as an architectural style that’s not being made here.
XML-RPC is a protocol built in an RPC style, and it’s the protocol that’s responsible for the serialization, API, and library support that you’re pointing to. A similar RESTful system could use XML, YAML, JSON, etc as serialization methods (and as you rightly point out, these serialization formats aren’t the issue) as long as it abides by a couple of architectural constraints.
Those are (roughly):
- Addressability of application resources (e.g. URIs for data)
- An explicit, simple, and consistent interface (e.g. the familiar HTTP “verbs”) that dictate how the server state changes (i.e. when to save/delete something or when we can reuse/cache a result and which operations will have the same results when reapplied in case the first try failed).
- Hypermedia as the mechanism for client change. You indicate the “next steps” for the client.
And by no means is a RESTful architecture limited to HTTP, it just happens to be the most widely deployed protocol of the style.
If we’re talking about architectural styles, RPC vs. REST is a better comparison — indeed, it’s one that Fielding devotes a lot of time to in his thesis. Some simple weaknesses of RPC apparent right off the bat are that we loose the ability to cache results in the client, intermediaries, and server because the protocol (as an implementation of an architectural style) doesn’t make it explicit if we’re just supposed return a value, or if we’re supposed to change something in the application.
Could this be the answer to page_attachment woes? →
giantrobots.thoughtbot.com
All due respect to technoweenie and all, but the internals of attachment_fu could really use some refactoring. The main entry point, has_attachment, is over 60 lines long. There’s modules including modules (using the send(:include, ...) hack, which as we all know, won’t work in 1.9). alias_method_chain, which is interesting and useful in a lot of places, is overused. Processing is especially adapted for images — even though any kind of attachment might need processing. Changing any of this requires going through a lot of spaghetti.
I haven’t had a chance to play with Paperclip yet, but this much is promising:
And this isn’t just for avatars and images. You can upload anything. No thumbnails are made by default, so it won’t automagically choke on your Excel docs.
Only One Week Till Opening Day →
jdland.com
Oh man: fantasy baseball draft this weekend and now this. Getting to be about that time of year…
JExcel Character Set Issue (Solved!)
In a recent project at work, we came across a quite dastardly problem that had to do with the bane of every programmers’ existence: incorrect character set translation. Some background here: We’re reading Excel sheets using the JExcelAPI, a Java library for parsing and writing Excel files (which, apart from this has been pretty darn good). We really need characters like ü, ã, ô, etc. because we’re hoity-toity and like the be correct when we spell Zürich, São Paulo, Düsseldorf, and Côte d’Ivoire. The last piece of the puzzle is that we’re using Excel for Macintosh.
So here’s what’s going wrong: Excel seems to always store its strings in Latin1, regardless of operating system. JExcel, however thinks that if it’s running on a Mac, it should convert strings from Mac Roman. The result is that when it converts to Unicode (which, as you well know, is the encoding Java naturally uses for its strings), it get’s things horribly mangled.
BTW, this good resource for seeing how all of the Unicode characters can be represented.
The solution is to set the jxl.encoding system property to ISO8859_1.
Testing private methods →
jasonrudolph.com
Definitely better than Object#send(:include, ….) (and it’ll actually work in Ruby 2.0).
Notice the def @ninja.flog_publicly(*args)… did you know you could do that? Sure you did, you just didn’t realize it (I sure didn’t). All those times you used def self.some_class_method? Same concept, same notation, different use case.
CS162: Operating Systems and Systems Programming (Berkeley) →
inst.eecs.berkeley.edu
I found the podcast of this class going through iTunes U. Lecture notes and other course materials available here.
Fun With Domino's →
thesneeze.com
The great thing about the web-app-ification of the service industry is that you don’t have to worry about getting a weird look from an actual human when you ask for something out of the ordinary. The Robot Race has no sense of the absurd.
Ruby-Java Bridge + Capistrano = Frustration
So I just deployed a Rails application that used the RJB for the first time. Yeesh.
Here’s the thing: you of course need to have the environment variables set up in order to gem install rjb. Unfortunately, Capistrano doesn’t use these environment variables in its commands. Without it, you get a notice like this:
can't create Java VM
Bummer. I ended up following these instructions. There’s probably a better way, but this seems to work.
Need Help With attachment_fu resizing? →
imagemagick.org
I had some trouble finding documentation for attachment_fu’s image resizing/thumbnailing. Basically, it follows these RMagick conventions (even though it can use other processors like image_science and mini-magick).
YARV Ported to Objective-C/Cocoa →
trac.macosforge.org
The rationale behind this effort is to solve in a very efficient way all the bridging problems RubyCocoa, the Ruby bridge to the Objective-C runtime, has to work around.
I’m still rooting for Rubinius, but this is interesting. But I wonder, when Rubinius is done, won’t efforts like these be much easier? Will they be able to be done entirely in Ruby? Will they be able to be loaded in on the fly, monkey-patching what they need to?
I’d like to see…
