"Ruby" entries

Delegation patterns in Ruby

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.

Read more…

Comment: 1

How to (semi-)automate JavaScript refactoring

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.

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Giles Bowkett demonstrated a wide variety of ways to write code that helps refactor code, showing developers a variety of ways to clean up and simplify their JavaScript. He gave ‘disposable robot assassin at large’ as his title, but it fit better with the code he was demonstrating.

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]
  • Switching to a Ruby parser for JavaScript to calculate differences [at 21:49]
  • JavaScript parsers: Esprima [at 27:26]
  • “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.

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment

Why Ruby blocks exist

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.

Read more…

Comments: 3

Be a Polyglot Learner First, Then a Polyglot Programmer

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.

Read more…

Comments: 3

How Setting Aside Rails and Picking Up Padrino Might Make You a Better Ruby Developer

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.

Read more…

Comment: 1
Four short links: 31 July 2013

Four short links: 31 July 2013

Mobile Image Cache, Google on Net Neutrality, Future of Programming, and PSD Files in Ruby

  1. How to Easily Resize and Cache Images for the Mobile Web (Pete Warden) — I set up a server running the excellent ImageProxy open-source project, and then I placed a Cloudfront CDN in front of it to cache the results. (a how-to covering the tricksy bits)
  2. Google’s Position on Net Neutrality Changes? (Wired) — At issue is Google Fiber’s Terms of Service, which contains a broad prohibition against customers attaching “servers” to its ultrafast 1 Gbps network in Kansas City. Google wants to ban the use of servers because it plans to offer a business class offering in the future. […] In its response [to a complaint], Google defended its sweeping ban by citing the very ISPs it opposed through the years-long fight for rules that require broadband providers to treat all packets equally.
  3. The Future of Programming (Bret Victor) — gorgeous slides, fascinating talk, and this advice from Alan Kay: I think the trick with knowledge is to “acquire it, and forget all except the perfume” — because it is noisy and sometimes drowns out one’s own “brain voices”. The perfume part is important because it will help find the knowledge again to help get to the destinations the inner urges pick.
  4. psd.rb — Ruby code for reading PSD files (MIT licensed).
Comment

Really Understanding Computation

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.

Comment

Where are JavaScript and the web going?

The Fluent conference co-chairs look ahead.

JavaScript and HTML5 just keep moving. One day it’s form validation, the next animation. Then it becomes full-on model view controller stacks getting data from sensors on devices and communicating with back-end servers that are themselves largely JavaScript.

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.

Peter and I paused for a moment to talk about what we’re doing and where we see JavaScript and the Web heading. Though we work together on the conference, our perspectives aren’t quite the same, something I think works out for the better.

Read more…

Comment
Getting started with data-related explorations of everyday things

Getting started with data-related explorations of everyday things

Using Ruby and R to improve your data skills.

Sau Sheong Chang describes the intriguing projects in his upcoming book, "Exploring Everyday Things with R and Ruby" and how other people can develop their own experiments.

Comment
Four short links: 5 September 2011

Four short links: 5 September 2011

Bitcoin Banks, Journo Ethics, Android and iOS, and Clever Algorithms

  1. Dan Kaminsky on Bitcoin (Slideshare) — short version: banks are an emergent property as it scales.
  2. Unethical Ventures (All Things D) — astonishing slam on the new venture fund that Michael Arrington (founder of TechCrunch) will be running while still writing for TechCrunch. This could have been a lot cleaner, of course, by Arrington simply resigning from TechCrunch, becoming a VC and perhaps starting a new blog where his agenda is much clearer, from which he could huff and puff away as he does with much entertaining gusto at real and (mostly) imagined slights. There is certainly precedent for VCs blogging, including Fred Wilson, Brad Feld and Ben Horowitz. And, despite my criticisms about ethics, it is clear that Arrington is a talented writer whose unique voice would be even stronger if it was truly seen as separate from what has become a news organization. But because of his obvious need to be the center of attention — requiring the ermine kingmaker mantle and foisting his patented I’m-here-to-tell-it-like-it-is attitude on us all — that appears to be impossible.
  3. An iOS Developer Takes on Android — a very easy to follow comparison of the two platforms from a developer who worked on both and who is carefully not partisan. I hadn’t realized before what an advantage OpenGL confers to the iOS devices. It’s not just for 3D games any more (he says, catching up with 2008).
  4. Clever Algorithms — book of 45 nature-inspired algorithms, code in Ruby.
Comment