how do you "freeze" individual gems in Rails 3?

Ok, this wasn't documented anywhere, (the best I could find was the Rails 3.0 announcement and the Bundler rationale) so after reading the Rails guide I hacked around with it on my own.

In the old days (Rails 2) you could do something like this:

rake gems:unpack

and it would take the required gems and copy them into vendor/gems.

But Rails 3.0 gets rid of this handy feature in favor of Bundler's approach. Bundler's basic approach assumes that you'll always run bundle install in every deployment environment and that it can go to the internet to get the gems. Neither of these assumptions are valid in my case.

There is one way of doing this:

bundle install --deployment

but that copies everything, rails, ruby, 10,000 gems I've never heard of (well ya, I've heard of 'em, but sheesh) and nicely bloats the target environment. So it seems it is all or nothing.

Anyone else figure this out?

the single most important unstated rule about BDD...

I've been co-leading a book club at work studying the RSpec Book. One thing that was difficult for me and other people new to Behavior-Driven Development (BDD) is that it often seems like the authors modify code in the BDD part of the cycle instead of waiting until the Test-Driven Development (TDD) part of the cycle.

For example, the first chapters dealing with BDD seem to make a lot of changes in actual code files and only at the end of Chapter 4 do they drop the inscrutable phrase, "now we have our first logical error." I know they mean "our first error that requires going into TDD" (because that's the next chapter), but how does this differ from all the code mucking they've already done? At first glance it looks like you can just skip around writing whatever code you want.

But I've found that the authors of the RSpec Book follow a really important rule that they don't come out and say:

When in the BDD cycle you can define new classes or methods (and even arguments to methods) BUT you are not allowed under any circumstances to change or define the implementation of those classes and methods.

This is super important because it explains why the authors sometimes write code while they're still in the BDD phase-- they aren't skipping around after all!

It makes sense when you think about it because BDD is all about the behavior and interaction between classes (outside), whereas TDD is all about the functionality and implementation of classes (inside). So, of course, in BDD you'd want the flexibility to define an interface on the outside as much as possible before being driven down into TDD.

Many programmers are confused at first about the difference between BDD and TDD and as a consequence, many more have blogged about the philosophical differences (google it!) but I haven't seen any clear rules before. This rule really helps solidify the differences in practical terms so you know exactly when you are in BDD and when you aren't.

are entropy and risk related?

A friend of mine who is a plasma physicist posted a personal version of his presentation on the nature of the instability generated by a Maxwell's Demon wire-array. Well who doesn't like Maxwell's Demon, the little imp who goes around subverting Newton's Second Law of Thermodynamics by decreasing entropy?

Well since my friend's version had a lot more physics humor in it, I said he had invented a new field: "stand-up physicist" (although some may claim Feynman has first dibs on that)... my friend went on to say that next time he should relate the demon size collapse to our financial cycles. Heh heh...

But wait... I think that implies a really interesting question: is the concept of risk (including financial risk) somehow related to entropy?

In a time when our markets are being determined more and more by the math of physics and information theory, the idea that lowering financial risk is somehow akin to lowering entropy would be a very deep insight into the limits of a financial system.

Think about it. So far, Maxwell's demon hasn't beaten the 2nd law on the large... you may lower local entropy, but in the large, things always bounce back to a net entropy increase. Sound familiar? Markets and quants may be able to locally lower risk through use of financial derivatives, but ultimately, in the large, the markets always bounce back.

Wow. I just googled for "risk entropy" and apparently people in the field are already well aware of the connection. Well, even if it's not original, it's still a fascinating relationship.

Actually, this source summed it up great (duh!):

Any project, large or small is associated with expected and unexpected problems. The analogy mentioned above could be derived from the Second Law of Thermodynamics. The Second law of thermodynamics deals with a concept : Entropy. Entropy, in short, is the amount of disorderliness of the system. Entropy is also a measure on the information contained in an system. In information technology, entropy is considered as the amount of uncertainty in an given system. This has a defined relation, "As the amount of information increases, the disorderliness of a system (entropy) decreases".

compiling opengl-redbook examples on Lucid guest

[UPDATE]

Rats! Turns out that any video setting or reboot gets confused with the nvidia driver present -- even though it isn't set, it doesn't play nice with the virtualbox driver... convinces it there is no 3D present and runs it in software (dirt slow). I eventually uninstalled it... maybe it's freeglut, but not sure. Needs more research. Later.

------------

I'm starting a class this fall in computer graphics and I thought I'd experiment with trying to compile some of the examples in the redbook. I have to wait for our class copies of VisualStudio (our course is taught targeting Windows), but I wanted to try some things, so I decided to use my Lucid Lynx Ubuntu 10.04 instance to compile examples.

First off, VirtualBox rocks. You have to hand it to the team because their 3D acceleration is strictly super-awesome... it lets me run full compiz settings while running on a i7 920 GTX 260 equipped Windows 7 host. It's fast! Like pretty close to native fast. So fast that I simply use ubuntu in VM mode instead of dual-booting. (Actually, I pretty much like everything about Windows 7 too, except maybe the filesystem changes, but there are more tools available for Linux, so it helps to have the best of both worlds.) Make sure 3D acceleration is enabled in your vm before you start; I also used the max setting of 128 MB VRAM. Anyway, back to the story...

Once in the guest OS, I downloaded the samples via apt-get, installed the usual libs... in this case the ones suggested here. Like the poster I tried the shipped makefile at first and got:

$ make
make: *** No rule to make target `$@.o', needed by `hello'. Stop.

Ug. I suspect some dialect of gnu make doesn't like that variable name or syntax, but gave up trying to understand it too much (yeah, lazy) and switched to the suggested longhand:

$ g++ hello.c -lGL -lGLU -lglut -o hello

Success! Then I ran it:

$ ./hello
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0x24c10a0
Segmentation fault

Ug. Not what I wanted. Did some poking around and found that "nVidia and ATI "driver" installs on linux *replace* -lGL and -lGLU default Mesa installations with their own." So on a lark I tried

$ sudo apt-get install nvidia-glx-185-dev

And it worked like a charm!!


That's kind of obvious (because the VirtualBox 3D is supposed to be as clean a passthru as possible) but also kind of amazing (because the ubuntu guest is setup to use the virtualbox driver, not the nvidia 185 driver for ubuntu) -- it just worked... at least for this sample! :)

Enjoy!

DRM should live in the document, not the device

I started taking a closer look at Kindle. A new semester is starting up and I noticed that several of the optional textbooks for the course are available on Amazon in Kindle format, so I was interested in seeing what the format could do.

Here's what I found:

• If you are writing academic papers you can't cite Kindle versions very well. My suggestion to the Kindle development team is to expose "Locations" as standard URIs instead of the current proprietary bookmarks that only work on Kindle. URIs would be sharable and documentable and thus fit better with existing citation standards for electronic sources.
  
  
• If you are using Kindle for PC, and you have a programming book with source code samples, you can't copy/paste the samples from the app to your editor. It's very ironic that you have to retype in code snippets when you're reading an ebook on your pc.
  
  
• If you have a book and a friend asks you about it, a very common social case is to say "oh, here, you can borrow it, I'm not reading it right now" -- you can't do this with the Kindle because the DRM is in the device, not the document. I have to loan my entire library (and the Kindle too) in order to satisfy this use case. For this reason, I'm beginning to think that DRM (document rights management) should live in the doc, and merely enforce uniqueness and have nothing to do with "rights" or licenses per se.

I know the suits will be shocked at this idea: "but but, we were going to get all this money from individual sales forced on the customers!" -- no, I don't think you would. I think people will simply shrug and say "sorry, can't loan you the book, but you can buy your own" and then people will either say "ok", or "never mind".

However as books move to this new medium, I realize that the concept of a "library" simply doesn't work with DRM in the device. You can't loan licenses in the current model. Of course, the publishers again want to water at the trough of infinite profits -- but I think the reality will be far worse -- libraries will simply dry up and there will be little in electronic initiative to replace them.

Open formats may fill a little of the gap, but right now this is limited to academic papers and a handful of independent authors... it's hardly enough to keep libraries working... furthermore, open formats don't really encourage a library (except maybe digitally speaking) because you can just make copies of them.

If DRM lived in the doc, I could buy it, I could share it, but I couldn't copy it. If my friend had it, I wouldn't have it. This satisfies the "scarcity" requirement of the publishing industry (without scarcity, there is no value for books or any media).

But somewhere along the way, DRM became about "licenses" tied to devices. So I can't share, I can't own, but everyone can buy their own copies. Of course, the consumer market says "hey, well in that case, I don't use that book all the time, it's not worth the same price" -- and publishers are again shocked that consumers don't want to pay for ebooks at only 20% off.

Even the OReilly subscription model is hard to stomach at $300-400/yr for access to their entire library. I've paid a huge amount, but at the end of the year, I own nothing. It's really hard to see any value in that arrangement unless I'm constantly using 10 books every day, and even then... I can't share them with any colleagues. Then again, at $50-$100 per computer graphics book and factoring that such technology books are obsolete within a couple years on average -- after a certain point, subscriptions do look "cheaper"... but it's still pretty expensive from my perspective.


I ended up buying physical copies.

how to call lambdas without call()

One thing that is rather nifty in javascript is the ability to assign anonymous functions to variables and then simply call them. For example, Protovis has this nifty method for creating a mapping function from the specified domain to the specified range:

var y = pv.Scale.linear(0, 100).range(0, 640);
y(100);  // 640
y(0);    // 0
y(50);   // 320

Neat!! Well, how about Ruby?

Well, I've been reading Metaprogramming Ruby (which is a really fun book so far) and we have lambdas. However, with a lambda, you usually have assign the lambda and then call() the lambda.

It looks like this:

f = lambda {|x| x}
f.call(10)  # 10

But I wanted this to be more like javascript's syntax, so I did some tinkering. Here's what I came up with:

the privacy of feedly feeds

A while ago I confronted Feedly about an apparent hole in their firefox plugin on Twitter:


They claimed they don't store credentials per-se and after further investigation I believe them, but there's still something not quite right.

See, if you install the plugin, everything appears normal:

But when you turn on Firefox's "Private Browsing" mode and click the Feedly button, you still see your feeds!




Fortunately, after a while, Feedly attempts to update your feed and displays the login screen:



So this tells me that what feedly says is probably true, they don't cache your credentials in the plugin. However, they still apparently cache content from your feeds for a little while until the next refresh period. By itself, this content cache isn't a bad thing (it's a performance optimization and saves network bandwidth) -- but the fact that their local content cache doesn't respect privacy modes in the browser is somewhat disturbing... does that mean that they cache outside the browser's model? or does that mean that firefox doesn't secure local data? Either conclusion would be troubling.

Does this actually expose private information in practice? I can't guess how you'd exploit it, but it certainly doesn't give me a warm fuzzy feeling either.