texel

Courtesy of Evan Phoenix... apparently in MRI, attr_reader doesn't create a method, instead creating a NODE_IVAR in the method table of the class. This circumvents method creation/invocation overhead and is therefore faster.

Admit it: you just wanted to use an AST so that you could easily convert SQL to and from XML for an upcoming talk.

For me, it was the EPR/double slit experiment.

Right, having written a billing system, I'd agree with you wholeheartedly. I just got the impression that the article conflated rolling your own billing system with actual handing of the payments and credit card storage. Perhaps I was mistaken.

It's interesting that the author didn't mention a third option– you can build your own subscription management and dunning code, and then foist the high-risk credit card related stuff onto a third party. I'm not sure I'd necessarily suggest doing this over going with a provider like Chargify or Spreedly (both look like cool services), but that's what we've done at Onehub, and while it was painful, it's worked extremely well. We just store tokens and let our payment gateway, Braintree, deal with the actual card data and charging.

Additionally, if you are going to write any of your own billing code, I sure hope it's not buggy and poorly tested. If it is, you should probably test and debug it before unleashing it to your customers :)

This is a bit of hand waving (which is OK because we're talking about imaginary sci-fi constructs) but it was my understanding that since warp drive bends space around you, you're not actually going anywhere near the speed of light, and therefore you experience time similarly relative to people at rest.

You could certainly do this in-process, either shelling out or by creating a gem that calls your C library. Additionally, if you're fronting your app with a server like nginx, you could use something akin to http://www.grid.net.ru/nginx/upload.en.html, so you wouldn't have to buffer the entire image into your Rails process.

I've heard these references to "hitting a wall" a few times now, and it's a bit perplexing. From what I gather, it means that you'll get to a point where you need to understand more about the underlying framework in order to accomplish a particular task. Isn't this a given in any environment? Perhaps in some other stacks, you need to get your hands way dirtier way earlier, so the learning curve is much more spread out. But I don't think I've ever run into an issue with Rails where I've thought "oh no, the framework can't do this... time to start over." It's just Ruby, the entire thing is well documented, and there's a very helpful community glad to answer just about any any question you might have (in my experience, anyway).

That isn't to say that Rails is a panacea, or even appropriate for projects of every shape and size. But if you're building an MVC web app, then it's really well thought out, allows you to be very productive, and in my dealings with it, those benefits don't go away, even as your application grows significantly in scope and complexity. YMMV etc etc...

Let us not forget the MAC system: Move in After Completion.

Oh you're right about that. What may not be entirely obvious though is that oftentimes 1 query can be far slower than 3 queries. In a lot of cases, that one query would have to do joins against multiple tables– I've personally seen speedups of 20x or more by just decomposing a single complex query into a few smaller and more focused queries.

Well you're ignoring possible disadvantages, like locking an inordinate number of rows in several tables while a long-running copy takes place. Transactions are all well and good, until they run counter to the usability and stability of your app.

Correct me if I'm wrong, but I'm pretty sure ActiveRecord will issue a separate query for each of those :include clauses.

Can you point me to more information about master's degrees being a bad idea? My wife is about to start a master's program, and it'd be good to know ahead of time.

Do the existing MacRuby features still work (ie autodiscovery of IB outlets/actions)?

The given example of "unless myvariable.nil?" is a little bit awkard. In fact, the use of the "unless" keyword is, in my opinion, almost always awkward unless it's postfixed: "do_a_thing unless wait?"

Not only that, but most of the time, the expression could simply be written "if myvariable; ...; end", seeing as the vast majority of the time, we only care if the thing we're testing is falsy.

Ruby does give you the tools to be very expressive, indeed almost conversational in your coding style, but it also gives you enough rope to hang yourself.

I originally got into programming not for the exact same reasons, but for similar ones (reasons that were tangential to one of my primary interests). I guess I found that I loved it just as much and just never stopped, even though I never accomplished the original goal. These kinds of things can just as often lead to happy accidents, I guess.

There are a lot of projects aiming to fix that, but yes, YARV is a great improvement on the speed front. Synthetic benchmarks being what they are, it looks promising: http://rubychan.de/share/yarv_speedups.html

He's not praising all of them by any means though– on what points do you disagree?

Me too! Everyone knows the proper usage is "hella rad." Kids these days have no respect for grammar.

So... not a big Knuth fan?

Great, now I need to add a third dimension to http://github.com/texel/Effect.Circle

Thanks a lot.

The Mac Mini in question has no means for hardware video acceleration, so you're right, Silverlight does software rendering but faster. How on earth then is it not Adobe's fault that they can't do the same?

Shenanigans. I can watch HD Netflix streaming on my Mac Mini without a hiccup with CPU to spare, but 480p Lost on the same machine makes it cry for mercy. Pretty Microsoft doesn't have access to any super secret APIs that Apple saw fit to hide from Adobe.

You want AckMate: http://wiki.github.com/protocool/AckMate/

I don't think I made any assumptions about your feelings on static vs. dynamic typing, I'm just pointing out that even though on the surface they can be both used to solve similar superficial problems, static typing is woefully limited with regard to the scope of problems it can actually detect. Tests can go way farther to help verify the expected results of your code.

They don't solve the same problem though. All static typing does is make sure you don't have any type mismatches. Sure, it helps enforce assertions about your inputs and outputs, but there are a million ways your code can compile without issue and then proceed to fail spectacularly. The fact that, as this article states, tests are optional is another issue entirely, but it doesn't change the fact that static typing is only useful up to a point.

I know this is just a single data point, but they've already instituted a law like this within King County. It has certainly changed the way I order when I'm out. Accuracy of the numbers notwithstanding, you can clearly see huge differences in calorie counts between different menu items, and I've personally steered clear of some of the more daunting ones that I might have otherwise ordered.

Once again, that's just me, and it doesn't really speak to the accuracy of the figures.

Agreed. Not only that, but they have an awesome API. I've used it to write automation tools for our build/deploy process. Never underestimate the usefulness of a good API.

You're more likely to get downmodded because your first premise is provably false.

I'm sorry you ran into unprofessional people in the Ruby community, and you're perfectly within your rights to use whatever technology best suits you and your business, but comments like this are inflammatory and counterproductive.

Well, you should prefer acupuncture. It's a much more effective placebo.