Blog

Sep 25 2012

Comments

The Hero, the Young Gun, and the Polyglot (a welcome)

It is time to welcome three new members to the Relevance team. With this new batch, we welcome two international travelers (from the Great White North and the Island of the Sun) and one local product to the team. All will be located here in beautiful, sunny Durham, and needless to say, we're thrilled to have them aboard.

With that, let me introduce (drumroll please):

Ryan Neufeld

Ryan Neufeld is an aspiring young software craftsman hailing from the bitter cold Canadian province of Manitoba. After half a year of foraging spare bits of Internet for pairing beyond the wall, Ryan has finally packed up his family and relocated to Durham.

Ryan is quite the young gun, having already worked at a number of startups and established companies at a senior level, all before reaching the ripe-old age of twenty-five. Having peeked behind the curtain of Ruby and Rails magic, Ryan's next mission is to take on Clojure and Datomic.

Daemian Mack

Daemian has been fascinated with computing since he got his first machine, a Timex Sinclair 1000, at the age of 7. Soon after he acquired a Commodore 64, discovered BBSes, and was forever hooked. He stumbled upon Ruby around 2007, and in the time since, Ruby and he have created tools for MLB operations teams, powered web communities and helped extend "publishing" (i.e. advertising) systems. He has also enjoyed occasional forays into building enterprise cloud platforms with Python.

Over the last year he's gotten to spend some quality time tinkering with Clojure, and hopes to spend much more.

When he's not coding, he's probably fiddling with emacs, discovering the joys of homeownership, enjoying his children, adding habañeros to things (not children), or buying books faster than he can possibly read them.

Yoko Harada

Yoko was named Ruby Hero 2012 because of her dedicated contribution to open source projects. She wrote a Java API for JRuby to connect Ruby and Java or JVM languages. The API was written during her son’s ski practice at a coffee shop nearby the ski area. She likes to mix multiple JVM languages using her API; for example, Ruby and Clojure, which ended up in her awesome landing at Relevance. Also, Yoko built and has maintained the pure Java implementation of Nokogiri, an XML API for Ruby. She likes XML processing since she worked for a Japanese government-sponsored XML project. At that time, she was deeply impressed by one of the project members, who, still now, keeps working very hard for standardizations of XML specifications internationally. From him, she learned that English is a must-have tool for communication. Now, Yoko is practicing the pronunciation of the word, “Relevance,” which is incredibly difficult for Japanese people. Yoko has organized Rails Girls Tokyo, the first chapter in Japan. In Yoko’s mind, Rails Girls Durham is next.

Huzzah!

Sep 22 2012

Comments

Clojure Conference Organizers - Podcast Episode 016

cover art

It's fall, and that means Strange Loop is happening! So what better time to release an episode we recorded back in July with Alex Miller, Marco Abis, and Lynn Grogan? Alex is the organizer of Strange Loop as well as of Clojure/West, Marco put together EuroClojure, and Lynn is the key person at Relevance responsible for pulling off Clojure/conj. Getting these three together was Lynn's idea, and I think after listening to the episode, you'll agree that it was a good one!

We talked about what's involved in organizing a conference like these, and heard a few horror stories about the things that the organizers have to deal with while the rest of us are enjoying the talks and the camaraderie.

By the way, I'll be at Strange Loop myself this year. If you happen to be there, come over and say hi - it's always great to meet listeners!

Download the episode here.

Read More »

Sep 21 2012

Comments

Using Datomic from Ruby

We are all very jazzed at Relevance about Datomic. But so far, the people working on JVM projects have had all the fun, as Datomic's peer capabilities are exposed as a JVM library.

That changed a few weeks ago when the REST API for Datomic was announced. Suddenly, we have client access to Datomic from any language we choose. We quickly came up with a Ruby client for Datomic and an edn data reader and writer for Ruby. (edn is the data format Datomic uses for input and output, and by implementing edn in Ruby, we get to use native Ruby data to talk with Datomic.

Over the last two days, I've created a sample application using Ruby and Datomic. It is a wiki which saves all its data in Datomic and can read the history of pages from there, using only a few simple queries. The really interesting part is how easily we were able to use Ruby data structures in the place of edn to make easy-to-manipulate and easy-to-read schemas and queries. Here's the DB schema in Ruby:

[{:"db/id" => id(:"db.part/db"),
  :"db/ident" => :"page/name",
  :"db/valueType" => :"db.type/string",
  :"db/cardinality" => :"db.cardinality/one",
  :"db/fulltext" => true,
  :"db/doc" => "The name of a page.",
  :"db/unique" => :"db.unique/value",
  :"db/index" => true,
  :"db.install/_attribute" => ":db.part/db"
},
{:"db/id" => id(:"db.part/db"),
 :"db/ident" => :"page/text",
 :"db/valueType" => :"db.type/string",
 :"db/cardinality" => :"db.cardinality/one",
 :"db/fulltext" => true,
 :"db/doc" => "The text of a page.",
 :"db.install/_attribute" => ":db.part/db"
}]

There are only a few differences between edn and this: mainly, edn keywords allow more characters than Ruby symbol literals, so we have to quote the symbols in Ruby.

Queries are even more fun:

datomic.query(dbname, [:find, ~"?id", ~"?name", ~"?text",
                       :in, ~"$db", ~"?name",
                       :where,
                         [~"$db", ~"?id", :"page/name", ~"?name"],
                         [~"$db", ~"?id", :"page/text", ~"?text"]],
                      :args => [{:"db/alias" => "example/wiki"}, name])

Given a variable name, this will pull back the DB id, name, and text for the page named that in Datomic. In this data structure, you'll notice one thing that probably isn't familiar to most Rubyists. The tilde (~) is used as a unary operator on strings to create edn symbols, which don't have an analog in Ruby. This capability is added by edn-ruby, our edn reader and writer.

To see the entire history of a page, we can write this query:

datomic.query(dbname, [:find, ~"?v", ~"?time", ~"?tx",
                       :in, ~"$cur", ~"$hist", ~"?uniq-attr", ~"?uniq-val", ~"?hist-attr",
                       :where,
                         [~"$cur",  ~"?e",  ~"?uniq-attr", ~"?uniq-val"],
                         [~"$cur",  ~"?tx", ~":db/txInstant", ~"?time"],
                         [~"$hist", ~"?e",  ~"?hist-attr", ~"?v", ~"?tx", true]],
                      :args => [
                        {:"db/alias" => dbalias},
                        {:"db/alias" => dbalias, :history => true},
                        :"page/name",
                        name,
                        :"page/text"])

Is this particularly Ruby-ish right now? No, not yet. Is it very cool? Yes, definitely. Datomic queries are built out of data structures: arrays, hashes, and other primitive data types, which allows us to easily use map, inject, and other Enumerable methods with them. A significant source of power and concision in queries comes from the use of not one, but two distinct data types for identifiers: symbols and keywords. Most languages cannot come close to this expressiveness, but Ruby handles it with ease. Ruby symbols can act as both identifier types, with the sly introduction of a unary operator "~" to distinguish them.

We have just begun to see what kind of amazing applications we can build with Datomic. Follow the Ruby Datomic client and the sample Ruby/Datomic wiki on Github to see what we come up with next.

Sep 18 2012

Comments

The Secrets of Building Software

I was privileged to be asked to speak at the CED TechVentures 2012 Entrepreneurs Workshop this year, and I was part of a series of 8 speakers, each given 7 minutes to talk about aspects of the startup process. My topic was "Secrets of Building Software". Seven minutes is not a lot of time, but I wanted to capture my thoughts from my talk and add a point that didn't make it into my time on stage.

So, here are the 6 (now 7) secrets:

1: The first secret of tech startups: everyone must code

Your team of founders might bring a ton of knowledge, creativity, and experience to the table, but at least one of you must know something about writing code. Just like if you were starting the All American Pie Company, one of you must know how to bake. Or if you were starting 37HorseFarms, one of you must know something about horses. See, the thing is, programmers are a proud, vainglorious lot, and they have a finely tuned sixth sense: they can tell who knows what they are talking about and who doesn't. You need someone with a big enough clue to show up on their radar or, in the immortal words of a previous boss, they will "flip the bozo bit" on you. And trust me, once flipped, that bit don't flip back. Once a bozo, always a bozo, and you may as well try starting that horse farm.

Now, I'm not saying you have to run out and become DHH. But at least one of the founders must know the difference between a web application and an iOS app and be able to say "I'm not sure I follow, but do you mean X?" without "X" being some value of stupid.

2: Get to know your OFR

A lot of people like to talk about building your MVP (minimum viable product). I'm not a huge fan of the term. When somebody has a grand idea for a system, somewhere in his or her head is a Perfect Sparklepony, trying desperately to get out. When you say "MVP", you make them think you are going to turn their Sparklepony into a severed hoof. Minimum Viable Product is all about cutting things, eking things out, squeaking by. It isn't an optimistic phrase.

I prefer the term "Optimal First Release". Optimal means you aren't cutting scope; you are communicating your unique value so that people care that you exist. I hear from founders all the time that there is already a primary competitor in the space, and their "MVP" has to be feature-comparable with that competitor or nobody will buy it. Really? Who would buy a feature-for-feature knock-off of the thing they already have? Why bother? If you aren't thinking differently, then what is the point?

What you need to do is figure out what you are doing differently, and do that, just that. Oh and do it as excellently as you can. Here's the thing - you can definitively prove that you can eventually do that other stuff. How? Point at the competitor. THEY did it, and, as you already know, THOSE guys are LOSERS. If they could do that, so can you. And everyone will believe that. What sets you apart is that OFR - the thing that only you can do. You can catch up on the rest.

3: Features - Speed - Quality: Pick One

You've heard the "pick two" thing before, and if you haven't, well, there's a whole bunch of books you should read, starting with "The Mythical Man Month" and working forward from there. Fast-forward to now, and here's what I'm telling you: optimize quality over features and speed. Every time. The world is full of poorly thought out features that don't string together coherently. But there is an painful shortage of carefully crafted, easy to use software that makes people's lives better instead of worse. We are all drowning in software that we have to use, and systems that subtract years from our lives and deaden our souls. Spend time making software that's a joy to use. Nobody gets excited by checklists of features; but they thrill to quality.

Keep in mind that there are multiple definitions of "quality". There's how well the code is written, and there's how well the feature is received. High quality code is easily maintained, scales well, doesn't break under simple stresses, and is a joy to work with in the future. High quality features are written from the user's point of reference, cover the majority of cases with the smallest amount of user effort, and enable the user to spend more time on important stuff instead of clicking on random crap. The first stuff is important for you, and the second stuff is important for your customers. Make sure you plan for both.

4: Friends don't let friends code alone

Software should never be developed in isolation. Programmers the world over suffer from the same character trait: after 15 hours of staring into a monitor listening to the Tron soundtrack, they cross over into "I'm a genius" mode where their crazy, never-been-tried-before solution is clearly the best way to do whatever it is. And the simple convenience of a second set of eyes is usually all the inoculation we need to avoid this syndrome. Don't let anybody in your world fall down this rabbit hole. Even, and especially, yourself. Get a buddy. This does not necessarily mean you have to practice pair programming the way we do at Relevance. It does mean that you shouldn't be shipping features that have only had one person involved in their creation.

5: Software Development Plans that go More than Four Weeks are Comic Books (and they probably have pretty pictures, too!)

Grand plans may be sweeping, majestic and even convincing, but they are also fictional, and should be enjoyed as such. When somebody shows me a development timeline that shows specific features being delivered on specific dates months in the future, I assure them that the only thing I'm 100% certain of is that the plan, as written, won't happen. Weathermen can't predict the temperature three days from now, because the weather is a chaotic system. Software is a chaotic system too, made of people, and technology, and business goals, and money flows, and geopolitical problems, and, well, life. You can't predict that far in the future. You can SET GOALS. You can MAKE PLANS. But you should know that those plans are going to change. Operate on hardcore, short-term, iterative planning that helps you steer.

Look at it this way. It is 1492, and you are standing aboard the Santa María. Her prow is valiantly aimed to the west. You know you are embarking on a sea voyage. You have to know vaguely how long it is going to take, and how many men to man the ships so you can pack the right amount of food, supplies, etc. But what is the target? Is it "the Port of Tokyo in 194 days?" Or is it "Japan, hopefully before winter"? The key point is to be able to steer, and adjust, and maybe take advantage of the New World when you stumble on it along the way.

6: Software Development is Mostly a People Problem

Don't listen to people who tell you there is only one way to solve any particular problem. "Oh, you HAVE to use Oracle for that." "This is clearly a problem for Python." "Rails is the sendero luminoso." Forget that; tools serve the craftsman. Find people you can trust and can work with, and let them use the tools that make them most effective. 90% of the problems they'll be solving for you aren't algorithmic anyway, so help get the tools out of the way of the problem-solving by being flexible about them in the first place.

Clearly, there are limits to this rule; there are tools that AREN'T capable of solving certain problems. You can't turn SQLite into a cloud-scale graph database. You can't use iCal as a word processor. You'd never want to get COBOL running on an iPhone. But when multiple tools CAN solve the same problem, optimize for the people.

7: Don't Take the Easy Way Out

Focus on simple, for everyone involved in the system. You, your developers, your investors, the users, everybody. Build simplifying things, make them awesome, and don't scrimp trying to get there. There are no easy ways out; somebody always has to pay the price. When you take the easy way out when building software, it is usually at your users' expense.

Let me give you a story, told to me by one of the Relevance team. She has used the same exterminator for years. In every year before this one, the exterminator would show up, do whatever they do, then write a one-page note saying "I was here on this date, I did these things, and here's what you owe." Then the exterminator would tape it to the door and leave.

This year, the exterminator approached her after the job was done and asked if she could sign off on the work. Saying "yes,", the exterminator proceeded to haul a full-sized printer and a hand-held device into her kitchen, make her spend 15 minutes trying to sign on the crummy hand-held device, then spent another 15 minutes printing out three pages of paper with a bunch of details and boilerplate and a poor representation of her signature. Incredulously, she asked "what is the point of all this?" His response was telling: "they say it makes it easier on the back-office folks."

The "easy" in this case is that the system now makes it easy to process all those work streams and invoices and pieces of paper. But the exterminator AND HIS CUSTOMER spent an extra 30 minutes struggling through a difficult process to finish the job. And the kicker — the evil secret here — is that there aren't any "folks" in the back-office anyway; they've been replaced by Skynet, who is really loving having his fleshy robots out doing all the drudge work.

Great software is about removing difficult, boring, repetitive, failure-prone, tangled, messy, awful things from the world. Easy is about foisting your pain onto somebody else. And you almost always arrive at "easy" by starting at "cheap". Think carefully about the investment you are about to make into the system, and the change you want that investment to have in the world. And spend wisely on simple, high-quality, well-developed, easily-digested releases so you can succeed in a world desperate for real successes.

Sep 04 2012

Comments

Where to Find Relevancers: September Edition

Want to meet a Relevancer in person? Here's where you can find us during the month of September:

Mountain View, CA 9/4-9/6
Clojure Training at Y-Combinator
Trainers: Stuart Sierra, Luke VanderHart

Mountain View, CA 9/6, 6pm
Clojure Meetup
Speaking: Stu Halloway, Stuart Sierra
Attending: Justin Gehtland, Luke VanderHart

Mountain View, CA 9/7
Day of Datomic at Y-Combinator
Trainer: Stu Halloway

Columbus, OH 9/11-10/16
Newbie HTML/CSS Class
Trainer: Jen Myers

Boulder, CO 9/19-9/21
Rocky Mountain Ruby Conference
Speaking: Russ Olsen: Eloquent Explanations

St. Louis, MO 9/23-9/25
Strange Loop
Speaking: Stu Halloway: Intro to Clojure
Speaking: Stuart Sierra: Functional Design Patterns
Attending: Mike Nygard, Craig Andera, Jason Rudolph, Tim Ewald, Brenton Ashworth, Chris Redinger

Raleigh, NC 9/27, 6pm
Find your Calling in the Web Industry
Panelist: Marc Phillips

Aug 07 2012

Comments

Michael Fogus - Podcast Episode 015

cover art

It was a sad day when I heard that Fogus was leaving Relevance, even if it was for a pretty good reason. So when Kovas Boguta asked if we were going to have him on the podcast to share his experiences at the company, I thought, "Well, of course we are. Why didn't I think of that?"

As always, it was a pleasure to speak with Fogus. We had a chance to talk about what he thought Relevance does well, and more importantly, where he thinks we could do better. As a special treat he also shared with us an exciting project he's working on... we thank him for choosing the podcast to announce it! Enjoy the episode!

Download the episode here.

Read More »

Aug 06 2012

Comments

Where to Find Relevancers: August Edition

Want to meet a Relevancer in person? Here's where you can find us during the month of August:

Durham, NC 8/8, 6:30-8pm
West End Ruby at Relevance HQ
Attending: Clinton Dreisbach, Sam Umbach, Larry Karnowski

Durham, NC 8/16, 7pm
TriClojure Meetup at Relevance HQ
Speaking: Jason Rudolph
Attending: Chris Redinger

Madison, WI 8/24-8/25
Madison Ruby
Attending: Lake Denman, Sam Umbach, Michael Parenteau, Kevin Altman, Jen Myers

Jul 31 2012

Comments

Rich Hickey - Podcast Episode 014

cover art

I recently found myself in Durham at the same time as Rich Hickey. Obviously, Rich has quite a few major accomplishments under his belt, including creating Clojure, ClojureScript, and Datomic, three technologies I personally use and love. Understandably, I think, I've wanted to have him on the podcast since the show started.

As it happens, Rich is also a super nice guy, and was therefore kind enough to sit down for a few minutes and indulge me. I really enjoyed our conversation about Clojure, music, Datomic, the fascinating question of whether our ears have a "focus" mechanism, how to design things by taking them apart, and a variety of other topics. I'm sure you'll enjoy listening to this episode as much as I enjoyed recording it!

Download the episode here.

Read More »

Jul 03 2012

Comments

Where to find Relevancers: July Edition

Want to meet a Relevancer in person? Here's where you can find us during the month of July:

Durham, NC Every Tuesday - 7pm @ Splat Space
Splat Space Open Meeting
Attending: Alan Dipert, Splat Space founder and Meetup organizer

Durham, NC 7/10
Techcrunch Mini Meetup at Tyler's Taproom
Relevance is sponsoring this event!

Portland, OR 7/16-7/18
OSCON
Speaking: Alan Dipert, Clinton Dreisbach
Talk: Computing with Clojure

Burlington, VT 7/28-7/29
Burlington Ruby Conference
Speaking: Jen Myers
Talk: Developers Can't Design (And Other Completely Untrue Design Myths)

Chicago, IL 7/31-8/3
Clojure Training
Trainers: Stuart Sierra, Luke VanderHart

Jun 19 2012

Comments

Marc Phillips - Podcast Episode 013

cover art

When someone suggested that I should have Marc Phillips on the show, I knew right away it would be a fun episode. And, as I think you'll hear from the moment the intro music starts, I was right! Marc and I talked about retrospectives, agile coaching, and the many wonderful qualities of monkeys.

Download the episode here.

Read More »

Popular Tags