Given my recent tinkering with Ruby and Rails, Tim Bray's mention of JRuby made me check it out. Its supposedly compatible with Ruby 1.8.2 and supports most builtin classes and BSF (Java world's common scripting language harness).
There are some interesting experiments going on in the JRuby world such as integrating Spring Framework into JRuby which allows Ruby objects to be weaved together using Spring configuration. There weren't many references to Rails on JRuby though.
While searching, I also ran into an article comparing the latest crop of Java-based scripting languages.
Choosing a Java scripting languange: Round two
p dir=”ltr”>Here is a performance comparison chart from the article which I found interesting:
As you can see, current implementation of JRuby is really slow. But I think its performance should increase to be comparable to Jython after a few round of optimization.
Mid-experience comment on Ruby syntax: so far it feels better than Perl but worse than Python. I am finding Ruby code difficult to read and focus on. Endless jutting ends and seemingly frivolous abuse of special characters annoying too. Expressions like:
class Dog < Animal
creates conflicting echos in my head because meaning of '<' in general conflicts with it's meaning in Ruby. Differences can be explained away but I think the designer of Ruby language don't realize that logic does not dance on eyelids. Damn. I am slipping into poetic zen mode again. Help!
Apparently, hot from the oven:
Setting up a Rails Development Environment on Windows Using Eclipse.
My only complaint is that setting up external rails commands is rather tedious and commands have no guard rails (sorry) due to command line level integration with Eclipse.
NOTE: I am not completely sold on Ruby nor Rails. I am playing around with Ruby on my breaks just to get the bitter taste of real world engineering out of my mouth.
WEBrick is usually shut-down with control-C but since it is launched as a Eclipse external tool, it has to be shutdown directly from the Eclipse Debug view.
Currently deployed contactless credit card are vulnerable to bump-and-relay attack. Roaming harvesters, equiped with modified readers that relay signals into a stolen transaction exchange network (STEN), bump into a contactless credit card carrier. Roaming spenders, equiped with a device that replays contactless card signals relayed through STEN, make purchases anywhere contactless credit cards are accepted. STEN matches harvesters and spenders on-demand.
Note that this vulnerability is not high risk for card issuers because:
Most contactless payment cards are currently used for small amount transactions of limited types (i.e. tranportation, vending machine, etc.)
STEN is difficult to setup, avoid detection, and defend.
Profit sharing at large scale is difficult.
Still, I could see small scale localized operations happening because the cost of investment and risk of capture are both low IMHO. Thankfully, there are several solutions to this vulnerability, some of which are already being implemented.
One obvious solution is to require two-phase commit for transactions above certain size. Another more low-tech solution, which I have not seen anyone propose yet, is to provide RF-shield sheath for cards so they can't be read unless the cardholder takes it out. I like this soution the best because:
It's simple and effective
No change is needed to existing systems.
Solves the multiple-contactless-cards-in-a-wallet problem as well.
Creates branding/marketing opportunities.
Kinda cute looking, no? Add a MP3 player and sell it as iJet!
Korea's aerospace industry is still in its infancy but I am happy to see that its first jetfighter is about to be deployed. T-50 is a trainer jet based on the F-16 design although it's smaller (80%). A-50 is the attack jet version. It's not a bad start but I doubt I'll live to see the first Korean manned-spaceship take flight.
While Linux enthusiasts have touted security as one of the advantages Linux has over Windows, I fear Linux desktops' use of plain password dialogs to acquire system privileages on-demand is a serious vulnerability because:
- Password dialogs appear too frequently, creating complacency and training users into typing in the superuser password reflexively.
- Password dialogs can be easily emulated.
Are there any Linux features I am not aware of that protects against this?
Erik Veenstra has some interesting ruby articles and tools. Check out RubyWebDialogs and DistributingRubyApplication. Both uses his Tar2RubyScript and RubyScript2Exe tools. Cool stuff.
Quite a number of years ago, I was pitching the idea of group search and group memory to a few select VCs. Thankfully, no one really understood what I was wailing about. I am thankful because I I believe being right at the wrong time is worse than being wrong at the right time. So all the hectic search and social software related activities going on these days mean bitter smiles for me.