ENTRIES TAGGED "Ruby"
Using closures in a different way
this references can often be totally unrelated to the lexical scope of a function. To work around that we often see tricks like:
var that = this;
this. Sounds crazy? Let’s see.
Reducing object bloat begins with doing less
In almost every project there are those objects which seemingly get involved in every aspect of the application. These are the so-called “god objects”: they can do everything (omnipotent), they know everything (omniscient), and they are everywhere in the application (omnipresent). Most often these are objects which are at the intersections of business logic: User or Account, Project, and Order are all usual suspects.
One of the core tenants of object-oriented programming is that large problems are made up of many smaller problems, and as such, can be solved by providing solutions to those smaller problems in the form of objects. God objects violate this core tenet by trying to be one solution for too many problems.
A typical example of a god object is the
User model of many Rails applications. Here,
User might be responsible for user specific information as well as knowing about phone numbers, emails, profile information, preferences, and handling authentication. It’s too much and it results in
User being coupled to every aspect of the application.
Although there are many tactics a developer can employ to limit the influence of these “god objects”, one of the simplest is just reassigning some of their responsibility, and using a delegation pattern may be the simplest way to do just that.
Let’s look at four different ways we can use delegation in Ruby.
Disposable robot assassins and spreadsheets
Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.
Bowkett explored many options and iterations of his automation ideas,
- The roots: Martin Fowler’s classic Refactoring. [at 00:50]
- “Probably the first time ever you see a developer or hacker enthusiastic about using a spreadsheet… I am that fluke.” [at 01:48]
- Matching method names with the ack and wc Unix command line utilities, and finding some useless methods. [at 5:58]
- “More complex information… surfacing an implicit object model.” [at 7:45]
- Filter scripts and text streams [at 14:45]
- “Towlie, because it liked to make things DRY”, using similarity detection in Ruby. [at 16:37]
- Building on JSLint [at 20:10]
- “Have script that… tells you this file is the one that people have edited most frequently. [at 30:29]
- Grepping through git history [at 32:53]
- “Automatic refactoring will let you get to better code much faster.” [at 36:25]
It’s an amazing mix of capabilities that let you build your own robot (code) assassins.
Exploring Ruby's "each" method
It seems like more and more languages these days are getting support for closures in one form or another. (Even Java is getting in on the game, finally.) Ruby has had closure-like structures called blocks since its early days, though, and they’re central to the language. Used properly, they can reduce repetition and even make coding less error-prone. Understanding blocks can give you some great ideas to take home to your language of choice. (Or, who knows? Maybe you’ll decide you like coding in Ruby better!)
Today, we’re going to show you just one of the many Ruby methods that use blocks:
each. We’ll show you some repetitive code that, in most languages, would be hard to refactor. But using
each, we’ll quickly wring that repetition out.
How dabbling in a new language now can lead to innovation later
Being a polyglot programmer has its benefits; most of us have read or heard about those benefits from various respectable sources. I’d like to highlight the importance of being a polyglot learner before being a polyglot programmer.
You heard me right—learn a new language, but don’t rush to use it in production. At least not right away. I have used this approach and have realized two major benefits:
- Enhanced design skills, and
- The ability to adapt quickly to an evolving mainstream language
Most programmers currently code in one of the mainstream languages like Java, C#, and C++. On a typical enterprise project, chances are we’re using one of these languages. It might seem like a tall order for most of us to be able to intermix other languages. However, it’s becoming more critical that we do. Let’s discuss why.
Learning languages through frameworks
I love frameworks. I love that frameworks like Rails and Bootstrap, in particular, make me more productive: People smarter than I have taken care of several decisions that distract from the typical goals of my web applications. I spend most of my time developing within the friendly confines of such frameworks, in part because I enjoy building—and delivering—applications I can show off to non-programmer friends (or clients, for that matter). They’re just not as impressed when I show them a Hello World app or a completed kata, for some reason.
Of course, there’s a danger here. With out-of-the-box, “omakase” Rails, it’s increasingly possible to create powerful applications with a rich understanding of Rails, but a so-so (or worse) understanding of Ruby itself. A well-done framework hides much of the complexity of a language, so the developer can focus more on the problem domain. But if and when an application’s requirements deviate from those for which a stock Rails installation is suited, a couple of things might happen for the developer who’s not sufficiently grounded in the language. At best, programmer productivity slows considerably. At worst, dirty hacks and kludges start appearing in the code base, and technical debt mounts quickly.
Tom Stuart's new book will shed light on what you're really doing when you're programming.
It’s great to see that Tom Stuart’s Understanding Computation has made it out. I’ve been excited about this book ever since we signed it.
Understanding Computation started from Tom’s talk Programming with Nothing, which he presented at Ruby Manor in 2011. That talk was a tour-de-force: it showed how to implement a more-or-less complete programming system without using any libraries, methods, classes, objects, or even control structures, assignments, arrays, strings, or numbers. It was, literally, programming with nothing. And it was an eye-opener.
Shortly after I saw the conference video, I talked to Tom to ask if we could do more like this. And amazingly, the answer was “yes.” He was very interested in teaching the theory of computing through Ruby, using similar techniques. What does a program mean? What does it mean for something to be a program? How do we build languages that can handle ever more flexible abstractions? What kinds of problems can’t we solve computationally? It’s all here, and it’s all clearly demonstrated via Ruby code. It’s not code that you’d ever use in a real application (trust me, doing arithmetic without numbers, assignments, and control statements is ridiculously slow). But it is code that will expand your mind and leave you with a much better understanding of what you’re doing when you’re programming.
The Fluent conference co-chairs look ahead.
Peter Cooper and I have tried to capture some of this power in the upcoming Fluent conference, so that attendees can find their ways to the tools that work for them. We also have an online preview coming this Thursday, April 4th.
Java's wild ride, multicore drives functional, and a look at how the usual programming suspects stacked up in 2010.
This year brought confusion and chaos in the Java space, continued growth for functional languages due to the attack of multicore, and the usual popularity for all of the dynamic languages we know and love.