A weekly exploration into topics to make you a better Ruby dev.
Our latest issue was 4 days ago: Benchmarks
Developers love benchmarks. Part of it's professional: we want to write fast code. But there's something else, too. In the abstract world of computers, speed is the most tangible metric we have.
"Heap," like "hash" is a term that can mean many things. Depending on the context, it could be a special kind of binary tree, the pool of memory that's available to be used by a C program, or the structure inside of MRI that holds every object that your Ruby program creates. Each of these is different, but they're all interesting.
Most programmers love to simplify. If we inherit a monolithic code base, we want to separate it into individual, testable components. If components are tightly coupled, we pull them apart and establish rules for how they interact. Our development environments have undergone a similar process over the past several years.
We're not supposed to like bugs. I suspect that if you were given a button that could magically make your codebase bug-free, you'd push it. (And probably make a killing as a consultant.) But would that be any fun? Programming would be a lot different without that occasional surge of endorphins when things finally work after being broken in strange and subtle ways. Of course, I'd never admit that. It'd probably make me look like a bad engineer.
Sooner or later all abstractions leak. You may find yourself wondering why your app is slow or why a form isn't posting. In times like these a little knowledge about the underlying network protocols can save you hours of frustration.
The Front End
It's been over 10 years since Rails popularized the MVC pattern. A lot has happened since then. Front-ends have grown and grown and grown. Clients who used to be happy with a few effects from script.aculo.us now want single-page applications (SPAs). In this brave new world, what are we to make of the pitiful little "V" in "MVC"?
Rubyists have always had a strange relationship with design patterns. They smell a little too much Java, like people in starched shirts and ties writing serious software for humorless people. Yet Ruybyists use and rely on patterns just like all developers. We've even been known to have the occasional religious war over them. The history of Ruby over the past 10 years is intimately tied to design patterns. In this issue of the RubyLetter we're going to look at where patterns come from, how they evolve over time, and how knowing them will make you a better developer.
Relational databases are incredibly powerful computing engines. What do we do with them? CRUD. We use them as dumb data stores. We tame their complexity by ignoring it. There's nothing innately wrong with this approach. But I thought it'd be interesting to talk about how we got here and what life might look like if we started to take better advantage of the power of the database.
Legend has it that programmers love precision, that we sweat the details, that we endlessly debate tiny variation in syntax and code organization...so what's the deal with hashes then? In Ruby, "hash" can mean several different things, depending on the context. Let's untangle this mess.
Page 1 of 2