Courtenay has posted a step by step tutorial on using memcache within your Rails application. He not only discusses caching… but also how to _“precache the data so that each page load is blazing fast without sacrificing user experience._”
Read more about it on the caboo.se blog.
A few weeks ago, Brian Ford was in my office and we were discussing BDD and how we can make this process even easier for our clients to understand… much less our own internal staff. With all concepts, each person has their own idea about what it is, why it is important, regardless of whether or not it’s accurate. This can cause some people to not find a good need for some practices.
During our discussion, Brian grabbed one of my whiteboard markers and drew diagrams to explain how he saw BDD vary from TDD. He has since posted an article on his blog titled, what’s it worth to me, and discusses his circular view of Behavior-Driven Developent and the importance of using Dialogue to evolve shared meaning.
One of the coolest parts about my job (aside working with cool people everyday..). is getting a say in where we spend some of our money as a company. One of the things that Allison and I decided that we really wanted to do as a company was encourage sustainable business and growth in our local community. Everyone here loves Portland, Oregon.
This screenshot was taken after we took headshots for our transportation passes.
{width=”240”
height=”150”}
Our awesome Office Manager, Nicole Fritz has started a blog, which she plans to, “…not only to let people know what goes on behind the scenes at PA, but to give other startups hints and tips about cool admin things that I have learned along the way (from taxes to how to get the right people “on the bus”).”
Nicole has posted an article, which introduces people to some of the great tax credits that small businesses like PLANET ARGON can take advantage of… in particular how we are now taking advantage of a tax credit for public transportation, bike storage, carpool programs, and more.
If you’re a customer of ours or are running a small business… you might consider subscribing to her feed.
How many times have you participated in a conversation with someone and realized that you really didn’t understand what they had said. Or… perhaps you’ve been talking and even though the other person is nodding, you’re not confident that they’ve really heard what you’ve been saying. Yet, you might find yourself nodding in agreement when they speak… and walk away… totally clueless about what you just talked about.
Were you really listening? Were they speaking over your head? Were you speaking over their head? Perhaps you were distracted? Whatever the reason… it’s probably worth thinking about. We all do it from time to time.
Even worse, you were only thinking about how they were wrong and you had the right answer already in your head…
In Dialogue, there are rules for participation, which we’ll explore in future writings.
One might wonder if we’ve been trained to work this way. In school, we had classes that taught us to debate one another… further cultivating a society focused on you versus I. But, what about the community? What about the team? What about us? Sadly, most of the teamwork that we saw encouraged was in the form of sports. To be fair… we did have debate teams… but the purpose was to argue for one side of an argument… not to find a way for both sides to work together. One might wonder our society would be like if we encouraged Dialogue in the same way.
Perhaps we need Dialogue teams. ;-)
Dialogue allows teams of people to work together. It’s a process that cultivates learning and discovery. Dialogue is not a process that encourages the passing of judgement or pushing for specific outcomes… the aim is to share understanding. Through empathetic listening and questioning, the seeds of trust are planted.
Dialogue-Driven Development is about building trust.
I came across this great table, which contrasts Dialogue and Debate. It’s worth taking a few moments to review.
Here are a few that caught my attention…
Dialogue Debate Dialogue is collaborative: the sides work together. Debate is a type of fight: two sides oppose each other to prove each other wrong. In a dialogue the goals are finding common ideas and new ideas. In a debate the goals is winning with your own ideas. In a dialogue you contribute your best ideas to be improved upon. In a debate you contribute your ideas and defend them against challenges. In a dialogue you listen to each other to understand and build agreement. In a debate you listen to each other to find flaws and disagree. In a dialogue you may consider new ideas and even change your mind completely. In a debate you do not admit you are considering new ideas and you must not change your mind, or you lose. Dialogue encourages you to evaluate yourself. Debate encourages you to criticize others. Dialogue promotes open-mindedness, including an openness to being wrong. Debate creates a close-minded attitude, a determination to be right. ——————————————————————————– ————————————————————————————————————
There is something to be said about the art of Dialogue, which is why we’re so excited about the d3 project.
As overheard on the d3 mailing list.
_“My strategy so far is to unemotionally ask them to step back for a minute from the “I want this feature” phrase. Start thinking about value delivered to the user; start thinking about HOW the user is going to use whatever information or functionality you’re delivering to them.”_ —“David Goodlad”:http://david.goodlad.ca
_“People have emotional attachments, pet ideas, favorite ways of doing things, and they are quick to impose those, under the guise of “business requirments”.”_ —“Brian Ford”:http://blog.brightredglow.com/
“Dialogue-Driven Development has the opportunity to step up in this environment and redefine the interaction between customers and developers.” —Brasten Sager (link)
..we’re just getting started. ;-)
If developer to client, developer to developer, or developer to user interaction is important to you… come talk with those of us involved in the Dialogue-Driven Development project.
It’s only been a few nights since James Adam announced his newest plugin for Ruby on Rails.
{width=”240”
height=”160”}
I don’t have proof yet… but I’m guessing by the following picture that
llor.nu became the first Rails application to use
acts_as_hasselhoff.
{width=”240”
height=”160”}
If you can get yourself to look past Hasselhoff… here are a few more pictures from AJAXWorld 2006 in Santa Clara, California.
{width=”240”
height=”160”}
{width=”240”
height=”160”}
{width=”240”
height=”160”}
Yes… that is Eric Hodel, Joe O’Brien, Michael Buffington, Ryan Davis, and James Adam.
While at AjaxWorld, several people asked me about our team, processes, and if we had any job openings. The answer to that is… “yes!”
We’re always looking for more developers. There is one catch though… we want you to be located in Portland, Oregon. Many people have responded to our ads as remote contractors, but what we’re really after is great people to join our team here in Portland.
If you’re interested in joining our team, send a thoughtful cover letter and your resume (plain text… no word docs) to jobs@planetargon.com.
Update
Since a few people emailed to ask more about
Portland. here are
some interesting facts and links. :-)
here](http://en.wikipedia.org/wiki/List_of_Portlanders) (Sally
Struthers! hah)
Just got back to my hotel room after giving my talk, Rails meets the legacy world here at Ruby on Rails seminar at AjaxWorld in Santa Clara, California.
As promised, I wanted to post some the slides from my talk today.
A few weeks ago, I announced the Ruby on Rails Legacy mailing list, which I also talked about in my talk. I invite you all to stop by and ask questions… and help the community grow.
If there was one thing that I wanted to really express in my talk… it was that you’re not alone. You’re not the only one faced with a situation where you need to work around legacy conventions, opinions, and politics.
…you’re… not… alone. ;-)
Heading out to go see James Adam talk about plugins… !
I woke up this morning and came across an article written by Brasten Sager, titled, Of Dialogue and Development in which he discusses his initial (and healthy) criticism of Dialogue-Driven Development.
But d3 is an evolving thing. Its earliest forms offered very little definition, leading me to believe there was little to it. As it has evolved the goals and mindset of d3 and its proponents have become a little more clear, and after further consideration I’m now convinced that my original critiques may have been wrong.
I encourage you to read his article, which offers ideas (and diagrams) on how d3 might be injected into your existing process.
A small number of interested developers have been sending us questions about d3 and were wondering what the next step was for the community. We’re working hard on outlining patterns of dialogue, which is where we plan to put of our focus into. A small group of people have joined our mailing list and IRC channel over the past few weeks, where some conversations have occurred. After reading through Brasten’s post, I believe that our IRC conversation last week was a good example of how people with different ideas about something… can come together and have a shared understanding, which is exactly what Dialogue-Driven Development is about.
Through shared understanding, we can accomplish so much more.
“In true dialogue, both sides are willing to change.” —Thich Nhat Hanh
Thanks to the hard work of Brian Ford, we now have a website to announce, which will be the portal to various conversations, patterns, and resources related to Dialogue-Driven Development.
Sitting in my hotel room in downtown San Francisco, CA. Mr. London himself, James Adam (of Rails Engine fame)… and I have been spending some time wandering around the area, which is where I grew up. We ventured over to Berkeley and down the coast to Santa Cruz yesterday. :-)
We then took the Cable Car late last night…
…and had food with almost too much garlic.
Today, we’re heading down to Santa Clara, CA to check-in at AjaxWorld Conference and Expo, where we will both be speaking tomorrow at their Ruby on Rails seminar.
Congrats to Steven Baker…who got married this weekend! He’ll be meeting us in Santa Clara later and speaking tomorrow as well.
If you’re going to be at the conference, be sure to introduce yourself. :-)
What do we mean exactly when we say that we want to participate in thoughtful dialogue in a project? What is our intention with this? When I recently came across some essays by David Gurteen and read his definition of dialogue as being “a disciplined form of conversation” it got me thinking about how we often forget that like all skills, practice makes perfect. What make our conversations discilplined in the first place? Based on my experience, dialogue (disciplined conversation) manifests when all participants in a conversation are practicing mindfulness. I don’t believe that most people learn or behave well by being beaten into submission, so we must come to an understanding while we actively involve ourselves in dialogue. Most of us are civil towards one another, which does wonders for allowing us to tolerate each other, but I still can’t help but feel that we’re still missing the mark when it comes to having consistent and thoughtful dialogue.
Over the past several months, our team has been spending quite a bit of time and energy analyzing these problems. What we really starting to uncover is that the real problem seems to exist somewhere outside of our development methodologies. Working under the Agile umbrella provides no silver bullet. The real issues seem to exist much deeper in our human nature.
We’re not all that great at communicating
Humans are not perfect… therefore… our ideas are probably far from perfect as well. Our thoughts aren’t perfect. Our interactions aren’t perfect. We’re consistently inconsistent (heh) and while we can rely on averages to some extent to calculate probabilities, we can’t always explain why somethings still go horribly wrong. The principles outlines in the Agile manifesto stress the importance of focusing on people not processes and responding to change. If we are to put a heavy focus on the people involved in projects, we must acknowledge our strengths and weaknesses and find innovative ways to improve our communication skills.
On a daily basis, we’re faced with complex problems. Hopefully, we’re using a lot of our prior experience to aid us in making rational decisions about how we respond to them. There is a lot that goes through each decision that we make. We can’t automate this process (yet), but we can definitely share our lessons with one another. Our intentions need to be thoughtful and empathetic to the needs of all parties affected by each decision. As humans, we have the opportunity to really listen to the concerns of others and use not only our logical intelligence… but also our emotional intelligence.
Much of this comes down to each of us learning to understand how we make decisions and interact with people. It’s our goal with Dialogue-Driven Development that with your help, we’ll be able to outline patterns of dialogue, which we hope will be of great value to the community. Our team has been analyzing our interaction with clients and discussing what has worked well and what hasn’t. How did our clients respond to approach X versus Y? It’s important that we capture this information and have conversations about the results.
“The meaning is what holds it [dialogue] together. ..Meaning is not static – it is flowing. And if we have the meaning being shared, then it is flowing among us; it holds the group together…in that way we can talk together coherently and think together.” - David Bohm
Doesn’t that sound beautiful? Who wouldn’t want to reach such levels of project enlightenment?
d3 aims to be to communication what BDD is to specification
While at RailsConf Europe, I had the privilege to speak with several Rail developers… several of which are doing contract development for several clients, just like our team. We discussed d3 for a while and I walked away feeling really excited about the whole concept. When I explained that our team didn’t see d3 as a replacement for Agile methodologies like Scrum, XP, etc… but as another tool in our tool belt. Dialogue between developers, clients, and users should be agnostic about particular methodologies. We’re really excited about Behavior-Driven Development as a best practice in our development process and we’re seeing Dialogue-Driven Development as another best practice that we start using from the initial point of contact with a potential client to long after we deliver the working product that we were contracted to develop.
We’ll be posting some fun announcements about the d3 project in the coming week(s). Stay tuned…
I meant to post this list of quotes I was compiling while at RailsConf Europe 2006, but never got a chance to do so.
“This is definitely the first time that I have eaten pizza while walking in the rain.” - David Black
{width=”240”
height=”186”}
“Rails is not about inventing your own style.” -DHH
{width=”240”
height=”133”}
“Nobody is passionate about something that they suck at.” - Kathy Sierra
“But it’s not about the tools you build, it’s about what your users do with them.” - Kathy Sierra
“What can you help your own users kick ass at?” - Kathy Sierra
“Talk to the brain not the mind.” - Kathy Sierra
{width=”240”
height=”180”}
“My computer might be at risk. Well, oh well. Life on the edge.” - David Black
{width=”240”
height=”139”}
Jonathan Lim also posted a few on his blog as well.