Not all abstractions are perfect. Some are leaky; some are just plain stupid. But wait! We can just introduce an abstraction on top of that, right? Let’s hide the stupid details and provide a new, better abstraction!
Abstraction creep is what happens when you try to save yourself from a shaky abstraction by introducing another abstraction, instead of just fixing that goddamn abstraction.
From Wikipedia’s article on JSON
One of my favorite aspects of the Ruby community is its strong commitment to Open Source. Thousands of Rubyists have written great libraries and placed the code up on GitHub (or elsewhere on the Internet) for everyone to use. Ruby has a fantastic tool to distribute these libraries: RubyGems. One of the reasons that Open Source runs so strong through Ruby’s veins is how easy it is to share your code.
While making a gem is really easy, there are a few additional concerns that you should be aware of when you distribute your code as a gem. Here’s an example of building a simple Gem, with some notes on best practices along the way.
Many years ago there was a tiny little
ladybug Ruby web framework called [Camping][camping]. Compared Rails’ thousands of lines of code, camping.rb was a tempting alternative for simple applications:
Welcome to the present, where every test framework ships with its own micro framework. Or was it the other way? Anyway, my point was: With so many alternatives, why would you want to go Camping? Why not Sinatra?
Some time ago, this discussion started over at the [Hackety Hack][hh] mailing list, so I decided to chime in and present SIX (UNIMPRESSIVE) REASONS CAMPING IS BETTER THAN YOU WOULD IMAGINE.
Every time someone mentions RESTful web services, there’s always that one person that has to chime in: “That’s not really RESTful, it’s just kinda RESTful.” I’d always filed that information away, under ‘things to learn later,’ and let it simmer in the back of my brain. I’ve finally looked into it, and they’re absolutely right: 99.99% of the RESTful APIs out there aren’t fully compliant with Roy Fielding’s conception of REST. Is that bad?
Maintaining a blog is surprisingly more difficult than you would imagine. The concept is so simple that anyone instantly understands it. The software has become so easy to work with that anyone can start one in a few minutes. Starting a blog has never been easier, yet keeping it updated still remains a most demanding task.
The truth is that blogging is often more about structuring and organizing than actual writing. Well, guess what? Successful software development is also often more about structuring and organizing than actual writing, so why not apply the same tools to your blog as to any other project?
Literate programming is an interesting concept that Don Knuth described in 1984, as an alternate way to write software. Literate programming places emphasis on the way that people think about software, rather than the way that computers do. Rather than write code in an order that’s imposed by the compiler, the literate programmer writes in words the way he expects a program to work, and then intersperses his description with code.
Design in web development is usually accomplished in three main steps:
Mockup-Driven Development attempts to merge the last two in order to make it easier to build, maintain and experiment with your application. Let’s have a look at some of the real issues present in today’s workflow and how MDD tries to solve them. We’ll also check out the current implementations, what issues they have and how we can improve them.
Advice is really easy to give to others, but really hard to take yourself.
A long time ago, I decided that it was a good idea to fight for simplicity. It’s something to strive for. There’s beauty in simplicity. Yet… simplicity is incredibly difficult.
Today we’ll explore a not so widely used feature in Ruby: overriding the the unary operators for fun and profit:
class CustomTimeless < Script # This script applies to every page: + url("http://timeless.judofyr.net/*") # ... except the front page: - url("http://timeless.judofyr.net/") # ... or the changelog: - url("http://timeless.judofyr.net/changelog/*") # ... and only HTML files: + type("text/html") def process(html) # Do funky thing with the HTML end end
This must be one of the coolest, yet quite unknown, technique in Ruby. For certain types of problems (e.g. when you have a set of rules) this gives you such an elegant way of describing the solution. There’s no meta programming or monkey patching involved, it’s short and sweet and best of all: it’s very intuitive.
Let’s have a look at this and a few other tricks you can do by overriding the unary operators.
Behavior Driven Development is a test-first software development methodology. It’s a fairly straightforward process if you’re familiar with other agile development methodologies.
I’d like you to welcome our newest author here at Timeless: Steve Klabnik. You may already know him as the maintainer of Hackety Hack, a contributor to Shoes or just a pleasant human being, and I’m confident that he’ll continue his awesomeness over here at Timeless.
The stage is yours, Steve.
Note: This is a more scientific follow-up to another essay called “There is no talent”. I recommend you to read that essay first, make up your mind about it and then continue with this article. At any time, feel free to contact me if you have any questions or something to add.
A few days ago I published an essay called “There is no talent”, which is by far the most popular essay I’ve written here. The general response seems to be that most people agree somewhat with the essay, but there’s also a significant group who agree completely and a smaller group who disagree completely. To be honest, I’m not surprised that I’ve received so many messages from people who partially or fully disagree with the previous post because the essay wasn’t really making a scientific argument, but rather an emotional one.
I’m good with computers. At least compared with others at my age. And believe me, I’ve heard it a lot: “Wow, you really have a talent there!” Well, apparently I do have a talent for computers. Or …?
At RubyConf 2010 Shugo Maeda [talked about Refinements][rc-talk]: A proposal for a new feature in Ruby which allows you to easily override methods without affecting other parts of your program:
module TimeExtensions refine Fixnum do def minutes; self * 60; end end end class MyApp using TimeExtensions def initialize p 2.minutes end end MyApp.new # => 120 p 2.minutes # => NoMethodError
Let’s have a look at the why’s and how’s of this proposal.
Roman Semenenko reported in that there’s yet another way to use tail-call optimizations in Ruby. I’ve updated the article with some details on how to use it, and also updated the benchmark so you can easily compare the performance between the different methods.
In May 2010 I attended [Frozen Rails][frozenrails] in Helsinki where Carl Lerche held a talk about Rails 3. Like everything else regarding Rails 3 it wasn’t a revolutionary talk, but I rather found myself nodding “Yep, that’s a better solution” every now and then (which after all is the whole idea of Rails 3).
When it comes to block helpers in ERB however, I wasn’t quite so positive. Block helpers have always been a little confusing in Rails - both their usage and their implementation. Rails 3 attempts to clean them up, but at what cost?
Welcome to Timeless, a community blog with focus on content.
I started my first technical blog in Feburary 2008 and have been blogging infrequently since then. As time has passed by, I’ve discovered that a blog is a surprisingly bad way to present technical content, both for the author and the reader. Timeless is an attempt at creating a new kind of blog with a focus on frequently updated, quality content which lasts longer than the beta of your favourite framework.
Since I’ve imported all the articles from my previous blog, there aren’t more changes here. There’s still of plenty of content though: Check out all the articles at the front page.