starjuice.net

What Google thinks you should be getting this week-end. Do you...

Fri, 26 Apr 2013 17:55:00 +0300

What Google thinks you should be getting this week-end. Do you feel lucky, punk?

Dig this

Tue, 16 Apr 2013 17:26:58 +0300

We have this custom in our office. Every now and then, someone will exclaim “It’s the X song!” for some value of X, while a song with appropriate lyrics is playing.

For example, Daniel Bedingfield’s I Gotta Get Thru This would almost certainly elicit an “It’s the Documentation At The End song!”. Almost certainly. If that song somehow managed to stay on long enough to reach the chorus.

Today, Bliss’s Monitor Access came on. Arguably, it’s the Refactoring song, because of the “Light that motherfucker up”. But when it occurred to me to name the song, it was in the “I know you gonna dig this” loop.

More specifically, it was in the “Dig dig dig dig” build up. So I called out “It’s the Node.js song!”. See, I’ve been punting node.js hard, and have been saying peeps will dig it. Sadly no dice, because as I said it, the track transitioned into the “this this this” bridge. So my timing was poor.

Rory’s was not. Without a moment’s hesitation, he asked “Because of this?”

JavaScript jokes. I kill me.

Conversation

Thu, 21 Mar 2013 11:49:30 +0200

<spook>: Surely there’s a worthwhile replacement for google reader?
<sheldonh>: spook: conversation. it’s awesome
<Helzibah>: there actually aren’t that many because Google reader cornered the market so well
<Helzibah>: the existing ones are certainly shaping up before sign-off day though
<spook>: sheldonh: where is it?
<spook>: that’s a shit name since it’s not googleable >:(
* sheldonh weeps for the species.

"Decide in your heart of hearts what really excites and challenges you, and start moving your life in..."

Wed, 20 Feb 2013 18:37:00 +0200

“Decide in your heart of hearts what really excites and challenges you, and start moving your life in that direction. Every decision you make, from what you eat to what you do with your time tonight, turns you into who you are tomorrow, and the day after that. Look at who you want to be, and start sculpting yourself into that person. You may not get exactly where you thought you’d be, but you will be doing things that suit you in a profession you believe in. Don’t let life randomly kick you into the adult you don’t want to become.”

- Astronaut Chris Hadfield’s answer to the question “Any advice to a young person who wants to get into this field?”, from his spectacular reddit IAmA (via apoplecticskeptic)

Free will at the office

Fri, 21 Dec 2012 11:51:52 +0200

Me: Have you read Free Will by Sam Harris?

Rory: What’s it about?

Me: You’re seriously asking me what a book called Free Will is about?

Rory: Well you can’t judge a book by its cover.

PWNT!

DRM

Mon, 10 Dec 2012 14:05:02 +0200

~~Saving you time.~~
~~Saving you money.~~
~~Putting you first.~~

Fuck off, it’s not all about you.

"He doesn’t want you because you’re mean and evil. He wants me because I’m nice and..."

Fri, 07 Dec 2012 14:26:25 +0200

“He doesn’t want you because you’re mean and evil. He wants me because I’m nice and sweet and pure. So fuck off!”

- Robin, in Once Bitten (Thanks, Helzibah!)

Delicious irony from Airbrake.

Tue, 04 Dec 2012 08:39:20 +0200

Delicious irony from Airbrake.

hi mate,I found a patch of yours, posted 2 years back. I have the very same problem, I want 12bits lenght vhids to keep them aligned with vlan ids. Did you face some side effect using it? I wonder why it was not merged to the branch. Any information you could give us is very welcome. Thanks in advance!

Mon, 26 Nov 2012 17:40:33 +0200

I’m pretty sure we backed it out, but I don’t remember whether that was because it crashed FreeBSD, or because it crashed adjacent switches. Sorry, I know that’s not very helpful. In the end, it was cheaper to give up and throw more firewall pairs at the problem.

"The problem with managers is that they’re totally disconnected from the everyday doing getting done...."

Fri, 02 Nov 2012 17:02:00 +0200

“The problem with managers is that they’re totally disconnected from the everyday doing getting done. In a pinch, they wouldn’t be able to do it if they tried. They can only talk about doing it, because that’s the role they’ve had to play, for their boss who can’t talk about doing it at all. He can only talk about talking about doing it. The more abstract level. The work around the work around the work. Where the bets are made.”

- The Management Problem — Whitney Hess

"Another advantage of values is that they’re easy to fabricate. So for testing it’s..."

Mon, 20 Aug 2012 14:59:00 +0300

“

Another advantage of values is that they’re easy to fabricate.

So for testing it’s really fantastic that you can fabricate inputs, to test programs using any technology. You don’t have to get the class library that has the right classes and interfaces and relate it to the stuff that you used in your program. Your program takes data, you can now write another program that produces data to test it.

And also for simulation purposes. So when you start raising your testing up to the next level, and you’re trying to drive your program to different kinds of situations, all you need to do is algorithmic generation of data to get a variety of simulation points for your program.

If your program can only get into a particular state by a series of interactions through objects, how are you going to algorithmically drive that program to different kinds of test cases? It’s a huge problem. It’s just a mess.

Whereas, if you can just algorithmically generate data, you’re done.

And again, it goes to this point about places. With places, you have to emulate an operational interface. It’s a ton more work. And also when you want to drive it, you have to drive it through the operational interface instead of with data.

”

- Rich Hickey in The Value of Values
Rich provides clear context for this notion of “Place” earlier in the talk.

@qcoding I’ve heard a rigid bottom leads to pain. Good luck! :-)— Sheldon Hearn (@sheldonh)...

Wed, 15 Aug 2012 08:15:00 +0300

@qcoding I’ve heard a rigid bottom leads to pain. Good luck! :-)
— Sheldon Hearn (@sheldonh) August 15, 2012

Flex for flexibility

Mon, 13 Aug 2012 22:45:36 +0300

Robert C. Martin (Uncle Bob) wrote something in The Clean Coder that has rocked my little world:

Much has been written about the principles and patterns of software design that support structures that are flexible and maintainable. Professional software developers commit these things to memory and strive to conform their software to them. But there’s a trick to this that far too few software developers follow: If you want your software to be flexible, you have to flex it!

The only way to prove that your software is easy to change is to make easy changes to it. And when you find that the changes aren’t as easy as you thought, you refine the design so that the next change is easier.

I’m seeing the benefits of this kind of thinking with interface_enforcement, a library I’m developing for elective test enforcement in Ruby.

The wall of doubt

I started out by implementing interface enforcement as a proxy. This produced code that seemed fine. However, I had a few doubts about distribution of responsibility and clarity of abstraction, and I couldn’t think my way through them.

Experimental refactoring helped a lot. I extracted ad absurdum from one bloated family of classes, and gained insight into the true nature of the family. Then I inlined most of what I’d abstracted, but now into fewer, more clearly defined collaborators.

Still, there remained an opaque core in there, that I couldn’t break into.

The hammer

So I took Uncle Bob’s advice one step further and started working on an alternative enforcement strategy prematurely. I say prematurely because I was pretty sure I would never ship it, and the primary strategy of proxying wasn’t finished by a long shot.

The additional strategy is enforcement by injection. How it works doesn’t contribute to my point. What matters is that it’s a different way to apply an interface to an object. It’s a different delivery mechanism for the core value of the library.

The breakthrough

This additional use case applied pressure to my code from a different angle. All of a sudden, inappropriate responsibilities and missing abstractions leaped out at me. Being forced to distinguish an interface from the method of applying it exposed opportunities for valuable refactorings toward cleaner code in surprising places.

I’m pretty sure that the injection strategy is a dead end. Sure, it will make automatic interface enforcement possible. But I’m not sure how desirable automatic enforcement is, and injection is brittle with dynamic test subjects. Proxying is verbose, but I have a strong intuition that it’ll be bullet proof.

The insight

No, the primary value of an additional delivery mechanism is not in its usefulness as product. The value is in its usefulness as design constraint. Having pressure applied from a different angle highlights inappropriate coupling and complicated decoupling.

If you want your software to be flexible, you have to flex it!

I know Uncle Bob’s advice was intended to support continual refactoring. But sometimes great advice extends to multiple levels. And on this young project, I’m already benefiting from developing two delivery strategies, even though I plan to ship only one. And who knows? Maybe the second strategy will turn out better than I can imagine right now. Only more use cases and refactorings will tell.

P.S. Okay, I lie. I don’t plan to ship interface_enforcement at all. It’s an exploration, and clearly disclaims itself as such on the front page. Shipping isn’t the point. :-P

"When I see creators constrained by their tools and their ideas compromised I don’t say..."

Mon, 13 Aug 2012 14:28:00 +0300

“

When I see creators constrained by their tools and their ideas compromised I don’t say “Oh good, an opportunity to make a product, an opportunity to start a business or an opportunity to do research or contribute to a field.” I’m not excited about finding a problem to solve. I’m not in this for the joy of making things.

Ideas are very precious to me. And when I see ideas dying it hurts. I see a tragedy. To me it feels like a moral wrong. It feels like an injustice. And if I think there’s anything I can do about it I feel it’s my responsibility to do so.

Not opportunity, but responsibility. Now this is just my thing. I’m not asking you to believe in this the way that I do. My point here is that these words that I’m using, injustice, responsibility, moral wrong; these aren’t the words we normally hear in a technical field.

We do hear these words in association with social causes. So things like censorship, gender discrimination, environmental destruction; we recognize these things as moral wrongs. Most of us wouldn’t witness a civil rights violation and think “Oh good, an opportunity.” I hope not. Instead we’ve been very fortunate to have people throughout history who recongized these social wrongs and saw it as their responsibility to address them.

And so there’s this activist lifestyle, where a person dedicates themselves to fighting for a cause they believe in. And the purpose of this talk is to tell you that this activist lifestyle is not just for social activism.

As a technologist, you can recognize a wrong in the world. You could have a vision for what a better world could be and you can dedicate yourself to fighting for a principle. Social activists typically fight by organizing, but you can fight by inventing.

”

- Bret Victor in Inventing on Principle

"Objects were made to encapsulate IO devices. So there’s a screen, but I can’t touch the..."

Sun, 22 Jul 2012 17:51:41 +0300

“

Objects were made to encapsulate IO devices. So there’s a screen, but I can’t touch the screen, so there’s this object. And there’s a mouse, but I can’t touch the mouse, so there’s this object.

That’s all they’re good for. They were never supposed to be applied to information, and when you apply them to information, it’s just wrong.

But I can now say it’s wrong for a reason. It’s wrong because it’s complex. In particular, it ruins your ability to build generic data manipulators. If you leave data alone, you can build things once that manipulate data and you can reuse them all over the place. You know they’re right once, and you’re done.

The other thing about it, which also applies to Object Relational Mapping, is that it will tie your logic to representational things. Again: tying; complecting; intertwining.

So represent data as data. Please, start using maps and sets directly. Don’t feel like “I have to write a class now, because I have a new piece of information.”

”

- Rich Hickey in Simple Made Easy

"When you write your tests first, you have to design the production code to be accessible from the..."

Sat, 21 Jul 2012 20:11:00 +0300

“

When you write your tests first, you have to design the production code to be accessible from the tests. Since you haven’t written the production code yet, the tests have a tremendous influence on the design of the production code. And that influence is to make the production code testable. Writing tests first makes production code testable. And another word for testable is decoupled.

The only way to test lines of code is to access them from the tests. But the only way to access them from the tests is to decouple the functions that contain them. So the act of writing your tests first causes you to have a system that is far less coupled than otherwise. In short, you get a better design simply by writing your tests first.

”

- Robert C. Martin in Clean Code, Episode 6 - TDD - Part 1

Using the rspec documentation

Fri, 20 Jul 2012 10:26:00 +0300

I’ve seen a lot of newcomers to rspec trip up over the documentation; where to find it, and how to become familiar with it. The two common mistakes are:

Reading the documentation for rspec-1 instead of rspec-2.
Getting lost in the API documentation, instead of the user documentation.

With a little guidance, it’s easy to become familiar with the rspec documentation. Start by knowing that it’s documented at a site called relishapp.com, which hosts documentation in the form of cucumber test output, for several projects, including rspec. So rspec is at relishapp.com/rspec/.

With that clear, I recommend that you perform an initial review of the structure and key elements of the documentation up front. The following review, which should take you less than half an hour, will set you up for easily finding the documentation you need when you’re knee deep in testing.

Getting Started

Start here and bookmark the site. Notice the package names on the left side of the page, RSpec Core, Expectations, Mocks and Rails. Once you’ve read the getting started advice on the page, you can click through to Rspec Core.

Rspec Core

This is an index of core topics. Make a note of all the topics available, then read at at least:

Rspec Expectations

The whole .should / .should_not vibe. You need to know about expectations (i.e. .should and .should_not) and matchers (e.g. .have(3).elements). Expectations are described on this page, and matchers are described under Built in matchers and Custom matchers. Notice the list of Built in matchers; you’ll be coming back to this list a lot.

Rspec Mocks

Rspec’s support for faking out behaviour . Test doubles stand in for real objects, and rspec lets you define test double objects, as well as stubbing out methods on specific objects and and classes. Read at least this page, Message expectations and Argument matchers.

With this review under your belt, you’ll have seen enough of the structure of rspec to know what kind of thing you need to read about (e.g. a built in matcher) and where to find documentation for it. Happy testing!

Active Records vs Objects

Sun, 15 Jul 2012 14:03:00 +0300

The following started as a comment response to Uncle Bob’s “Active Record vs Objects”, but the comment trail is so littered with spam that I feared it would be lost.

In the article, Uncle Bob illuminates the flexibility cost of Active Record, providing background for its negative impact on The Clean Architecture pattern he presented in: Architecture: The Lost years.

If you’re a long-time Rails developer, you will probably experience two things as you read Uncle Bob’s concerns and watch the video:

an intuitive “Aha, so THAT’s the problem!” feeling, but also
a dread “But how else would persistence work in a Rails app?” sense.

Both responses are well-placed; don’t let the conflict stop you thinking! After all, what you’re struggling for is valuable: to have all the dependencies in your application pointing inward toward the domain model.

I don’t have the answers. I’m just embarking on the journey myself. And here’s how I plan to tackle it.

Start by designing your domain model with plain old Ruby objects, with no regard for persistence, making heavy use of Tell-Don’t-Ask. Once your domain model starts to look interesting enough to be worth persisting, then take a look at how you might go about persisting the data from your business objects without attaching additional behaviour to them. At all.

Take a look at the Repository and Row Data Gateway patterns and consider hand-coding them for a few iterations to get a feel for what you’d want from a library.

There seem to be three concerns that need to be addressed:

The Repository,
the Row Data Gateways, and
mapping data from the Row Data Gateways into your business objects.

Repository implementations exist. My gut feeling is that the active_record library probably works really well as a Row Data Gateway, as would data_mapper or just about any Ruby ORM. Mapping the data into business objects is a responsibility that must lie outside the business objects themselves if we are to maintain the correct direction of dependencies. But the business objects need to provide an interface to their data, violating Tell-Don’t-Ask.

And so I think our sense of dread stems from the fear of not being able to handle the data mapping concern correctly. Where does this responsibility lie? Observing the Single Responsibility Principle, it definitely doesn’t belong in the business objects or the Row Data Gateways. My guess is that mapping belongs in adaptors that are private to the repository, leaning on a mild Tell-Don’t-Ask violation in the business objects.

Dan Bernier provides another valuable perspective on this sense of dread. In Out of Love with Active Record, he demonstrates that the Repository pattern forces us to think about our applications’ data access patterns in ways that we have not had to think about them with fat active_record models. This thinking is hard, and I think it’ll pay off.

Here are some working examples that have captured my interest and gotten me thinking about how I’d like to solve the problem:

Shane Isbell’s hand-coded example, Simplifying Ruby On Rails Queries With The Repository Pattern
A framework that uses dependency injection (light coupling), Curator
A framework that promotes complete decoupling, Arden

I know of two books that deal with this issue (inter alia). I’ve only read Objects on Rails, but plan to purchase Clean Ruby soon too. The way these authors implement Data Context Interaction to separate persistence out of business objects looks promising.

Avdi Grimm’s Objects on Rails
Jim Gay’s Clean Ruby

And remember, the fact that it’s hard doesn’t always mean you’re doing it wrong.

Photo

Thu, 21 Jun 2012 10:31:58 +0300

Creationists believe God put dinosaur bones in the ground to test our faith. I believe God put...

Wed, 06 Jun 2012 15:40:57 +0300

Creationists believe God put dinosaur bones in the ground to test our faith. I believe God put Creationists here to test our sense of humor.
— Scott Weinberg (@scottEweinberg) June 6, 2012