7 John McCarthy Papers in 7 weeks – #1 How My Thermostat has Beliefs and Goals

3 Replies
http://www.flickr.com/photos/midnightcomm/447335691/sizes/n/in/photostream/

http://www.flickr.com/photos/midnightcomm/447335691/

Ascribing Mental Qualities to Machines or How My Thermostat has Beliefs and Goals

After reading John McCarthy’s paper this week Ascribing Mental Qualities to Machines, I can honestly say that it has changed the way I think about programs and most certainly thermostats. For you see, I realize now that my thermostat has beliefs and goals. No, it does not have beliefs about what the weather is going to be tomorrow, or when the next George R.R. Martin book is going to come out. But it does have beliefs. It has three of them to be exact:

  • The room is too hot
  • The room is too cold
  • The room is OK

It also only has one goal:

  • The room should be OK

Wat?

Why should we think of a simple thermostat this way? It is not very complex. In fact, we can completely understand its state and reason about its behavior by looking at its small and complete program listing. What benefit can there possibly be to endow the humble thermostat with its own beliefs and goals?

Start Small

Let’s step back. We are talking about designing and building intelligent systems, not just programs. The example of a thermostat is indeed small, but let us try out our ideas on a easy to understand system first. Later we can consider applying it to more complex systems.

Beliefs and Goals are Easier to Understand and Reason About

Using a higher level construct to express state can make it easier to reason and understand intelligent systems. It also is useful in describing states that are not completely known or have portions that are not easily observable. In short, defining a program’s state in terms of beliefs and goals may be closer to our natural way of thinking. When I consider my co-worker sitting next to me. I cannot hope to observe the complete mental state of him at that moment. Although I could hope to describe it at a high level with beliefs and goals. I could even hope to predict future behavior with this knowledge of his beliefs and goals, (which most likely has to do with the goal of eating more bacon).

Easier to Debug and Correct

Once we have a higher level model of a systems mental state and behavior. It would be easier to debug, communicate, and correct problems. For example, If I come home and the room is way too cold, I could look for the problem in terms of beliefs and goals. Does the thermostat have a faulty belief? Or did it have a good belief that the room was too cold? If so, then the problem was that it could not act on its belief to tell the furnace to turn on. If it could communicate and know the problem, perhaps it could message me and I could arrange a service call, or it could even self-correct. Another example, is my recent experience with my Roomba. I came home the other day to find my Roomba had not returned to its charging station after its scheduled cleaning. Instead, it was stopped under my bed. What went wrong? Did it believe that the battery was low? Or was there some other faulty belief? It would be nice if it could tell me.

Delving Further – What is a belief?

McCarthy talks about defining a belief as a function of the system’s state. For each state, there are beliefs that can be expressed as a sentences in a language. The machine does not need to understand the meaning and concepts in the English, French or any given language. That is for us to interpret. The important part is that there is a mapping of the state to this sentence. Taking our humble thermostat for an example:

(defn thermo-belief [temp]
  (cond
    (> temp 70) "The room is too hot."
    (< temp 70) "The room is too cold."
    :else "The room is OK."))

We can test our thermostats beliefs with something like:

(deftest thermo-beliefs-tests
  (is (= "The room is too hot." (thermo-belief 71)))
  (is (= "The room is too cold." (thermo-belief 69)))
  (is (= "The room is OK." (thermo-belief 70))))

This testing or criticizing the belief structure of the thermostat is what McCarthy called a Second Order Structural definition for mental qualities. This differs from a First Order Structural definition in that, rather than criticizing or testing an individual belief, he sought to describe them by testing/ criticizing the structure of the whole set of beliefs.

In the example of our thermostat, to have a “good” belief structure, in accordance with Second Order Structural definition, it the must have some consequences or actions of it beliefs. Furthermore, these actions most be consistent with its goals.

It might be expressed in code like this:

(defn thermo-action [belief temp]
  (case belief
    "The room is too hot." (dec temp)
    "The room is too cold." (inc temp)
    "The room is ok." temp))

In this case, the action of a belief is returning a new state, the temperature. Our thermostat could issue a command to the furnace to turn on. But, let us keep it simple for the moment and just think of its action directly changing the temperature. Now, our believing thermostat program can be described as having beliefs as well as taking actions from them.

(defn thermostat [temp]
  (thermo-action (thermo-belief temp) temp))
 
(thermostat 33) ;=> 34

So now we have a thermostat that has beliefs and consequences from these beliefs. We still need to figure out how to test that its belief system is consistent with its goals. Thankfully, it only has one goal to keep it simple. The goal is that the room should be OK.

(def goal 70)

Let’s say that the thermostat is doing what it believes will achieve its goals, if the new temperature is closer to its goal.

(defn distance-from-goal [g t]
  (Math/abs (- g t)))
 
(distance-from-goal goal 80) ;=> 10
 
(defn closer-to-goal [g t nt]
  (&gt; (distance-from-goal g t)
    (distance-from-goal g nt)))
 
(closer-to-goal goal 75 73) ;=> true
(closer-to-goal goal 75 76) ;=> false
(closer-to-goal goal 56 57) ;=> true

We can now construct a test to see if the thermostat actions are consistent with its goals.

(deftest themo-behavior-test
  (is (closer-to-goal goal 4 (thermostat 4)))
  (is (closer-to-goal goal 74 (thermostat 74)))
  (is (closer-to-goal goal 75 (thermostat 75)))
  (is (closer-to-goal goal 56 (thermostat 56))))

Given this particular thermostat example, we could even recursively show that it will reach its goal:

(defn thermo-simulation [g s]
(if (= g s) "Woo hoo!"
(thermo-simulation g (thermostat s))))
 
(thermo-simulation goal 73) ;=>; "Woo hoo!"
 
(deftest thermo-goal-achievement-test
(is (= "Woo hoo!" (thermo-simulation goal 73)))
(is (= "Woo hoo!" (thermo-simulation goal 100)))
(is (= "Woo hoo!" (thermo-simulation goal 33)))
(is (= "Woo hoo!" (thermo-simulation goal -33))) )

Our thermostat’s beliefs are good!

What if ….

The way that McCarthy explains the Second Order Structural definition as criticizing and testing beliefs, made me start thinking about test driven design. What if we were to start thinking and designing our programs with this testing of belief and goal structure? It could be IDD (Intelligence Driven Design) rather than TDD/ BDD. From experience, I know that TDD has changed the way that I think about coding and resulted in cleaner and more robust programs. I wonder what effect IDD could have on our program’s creation and perhaps the future of AI. Could changing the way we approach our definition of state and behavior change our software to become more intelligent? Wait a minute. If we write a test system to criticize another programs beliefs and goals, wouldn’t we be designing a program that would have beliefs about another program’s beliefs?

…

…

My brain get exploded.
It is in fact, turtles all the way down :)

7 John McCarthy Papers in 7 weeks – Prologue

7 Replies

In the spirit of Seven Languages in Seven Weeks, I have decided to embark on a quest. But instead of focusing on expanding my mindset with different programming languages, I am focusing on trying to get into the mindset of John McCarthy, father of LISP and AI, by reading and thinking about seven of his papers.

Why?

Get out of your box

If you are comfortable, you are not challenging yourself to grow. You are doomed to stay in your same mindset and your little box and your world gets smaller. As an Object Oriented programmer, I was happy in my little box. Then one day, I discovered Clojure and Functional Programming and my world became bigger and richer because of it. I hope to glean a similar box expansion, by exploring the thoughts of McCarthy. Especially, since I have the nagging suspicion that we are somehow doing programming “completely wrong.”

Slow Down

Reading papers is an antidote to today’s relentless stream of Twitter and Hacker News techno stuff. It forces you to slow down and read something …gasp, maybe even the same thing multiple times and digest it. Thinking slow and eating more veggies is something we could all do more.

Structure

Following a somewhat arbitrary schedule of seven papers in seven weeks gives a structure that gives an measurable goal and timeline to this endeavor. Which gives you a fighting chance of actually getting it accomplished.

The Answer is Never Too Far Away

When we are presented with a problem, more often then not, the answer comes to us from some of our recent thoughts and experiences. Many breakthroughs in new technologies have come from cross pollination across different fields. Exposing yourself to a new ways of thinking gives your creative problem solving abilities new and powerful ammunition.

Encourage Others

Serendipity moves in mysterious ways. By sharing your travels and thoughts, who knows what might spark in someone else’s mind…

So I encourage you to join along. Pick a paper that appeals to you and read it this week. Think about it, talk to your co-workers about it, maybe write about it, or even code from it. But most importantly, slow down and take a moment to peek outside your box.

A Clojure REPL Driven Roomba

4 Replies


One of the things that I love about Clojure is that it can go anywhere that Java can.  That is why, when I found out that the Roomba already had a Java library written for it – I was excited to be able to hook it up to my Emacs / Swank and be able to control it from my editor.

It is great fun! If you have a Roomba at home and you want to play along…

  1. Read Setting up and Configuring Bluetooth and Roomba part from this post.

  2. Checkout the sample project clj-roomba from github.

Have fun doing this like this:

(def roomba (RoombaCommSerial. ))
 
;;Find your port for your Roomba
(map println (.listPorts roomba))
(def portname "/dev/cu.FireFly-943A-SPP")
(.connect roomba portname)
(.startup roomba)  ;;puts Roomba in safe Mode
;; What mode is Roomba in?
(.modeAsString roomba)
(.control roomba)
(.updateSensors roomba) ; returns true if you are connected
 
 
(.pause roomba 30)
(.playNote roomba 72 40)
(.playNote roomba 79 40)
(.spinLeft roomba)
(.spinRight roomba)
(.goBackward roomba)
(.goForward roomba)
(.turnLeft roomba)
(.turnRight roomba)
 
(.stop roomba)
(.reset roomba)
(.vacuum roomba true)
(.vacuum roomba false)
(.clean roomba)
 
;; Get the sensor data
(.updateSensors roomba) 
(.bumpLeft roomba)
(.bumpRight roomba)
(.wheelDropLeft roomba)
(.wheelDropRight roomba)
(.wheelDropCenter roomba)
(.sensorsAsString roomba)
 
 
(defn bark [r]
  (doto r
    (.vacuum true)
    (.playNote 50 5)
    (.pause 150)
    (.vacuum false)))
 
(bark roomba)

A quick video of hacking Roomba in action

Next up – Getting more roombas to implement Rich Hickey’s ant colony demo…

Talking to your Roomba via Bluetooth and RoombaComm

Leave a reply

I love Roomba. It cleans our floors and it can be hacked to help teach my kids programming. Win!

Here are the setup steps that I used to get going talking to Roomba:

  • Ordered a Rootooth bluetooth connection for Roomba.  I could have build one from scratch, but I am a busy mom and hacker.
  • Removed the cover from Roomba to expose the ROI port (Video).
  • Setup the Bluetooth adapter on my Mac
    • Start Bluetooth network assistant
    • Have the firefly adapter deteted
    • Enter the passkey: 1234
    • Click edit serial ports to see what port it assigned.  Mine was FireFly-943A-SPP.  Alternatively, you can look at /dev directory
    • Next, you need to configure the baud rate for your Roomba. I found these instructions helpful
    • Install zterm on your mac  - set the serial port to your roomba and the baud rate to the correct baud rate
    • On zterm you now should be able to echo any key you type
  • Download RoombaComm java package
  • Look at the README.  You will need to run makeit.sh to build and ./rxtxlib/macosx_setup.command (for Macs)
  • Finally run RoombaCommTest.sh to connect up and control your Roomba!

Baba Yaga and the Clojure Reducers

9 Replies

Baba Yaga's House

Once upon a time, a young girl decided to take a break from her code and stroll in the forest. It was quite a pleasant day, she packed her lunch in her bag and set off. While she was walking, she started thinking about a concurrency bug that her OO project was having. As she pondered the complexities of mutablilty, state, and threads, she must of strayed from the trail and lost track of time. By the time she looked around, she realized that she was totally lost.

It was then she spotted a very strange hut on chicken legs in the middle of the forest. The door was open, and there was a ladder leading up to it. She yelled “Hello”, but there was no response. She climbed up the ladder and entered the hut to see if she could find anyone inside. The hut was empty except for a pile of old books, a large kettle, and very skinny, malnourished black cat. Her heart went out to the poor cat. She took her sandwich from her bag and watched as the cat greedily ate it. The cat looked up at her and said, “Thank you for your kindness. Now, you should really get out of her before Baba Yaga …”

A large gust of wind came at the door and Baba Yaga appeared. She smiled an iron tooth grin at the girl and said, “What do we have here? An intruder!”.

The girl stammered out, “I am sorry, it is just a mistake. I am lost ..”

“Too late!” Baba Yaga grinned larger. “You are now my slave and if you don’t complete my tasks, I will eat you for my supper.” She thought for a moment and then pulled a book titled The Odyssey from the pile. “Your first task is to calculate the hash code of every character this book. Then sum of the values of only the even ones. Make sure you have it done before I return. And do it fast, I will be timing you.” Baba Yaga turned and disappeared in a gust of wind, with the door slamming and locking firmly in place behind her.

The girl sunk to the floor and started to weep. How could she complete the task? The cat rubbed up against her and purred, “You showed kindess to me where Baba Yaga never has. I will help you. It seems like this task would be best suited to a Clojure map, filter, and reduce, don’t you think?”

The girl wiped her eyes. “Cat, I think you are right.” She picked up the book. “The first thing we need is to get the content of this book into a vector.”

(def odyssey-text (vec (slurp "odyssey.txt")))
(class odyssey-text) ;=> java.lang.PersistentVector

“The vector contains all the characters. See, we can grab the first one and find its hash code this way.”

(first odyssey-text) ;=> \P
(class (first odyssey-text)) ;=> java.lang.Character
(.hashCode (first odyssey-text)) ;=> 80

“Now, all we need to do is to make a function to find the hash code and map it to the entire string.”

(defn hashcode [c] (.hashCode c))
(map hashcode odyssey-text) ;=> (80 114 ..... )

“Next, we need to filter only the even ones out.”

(defn hashcode [c] (.hashCode c))
(map hashcode odyssey-text) ;=> (80 114 111..... )
(filter even? (map hashcode odyssey-text)) ;=> (80 114 ... )

“Finally, we just need to sum all these values up with reduce.”

(reduce + (filter even? (map hashcode odyssey-text))) ;=> 33702446

As soon as she had gotten her answer, Baba Yaga appeared back through the door. “Well, you seemed to have found the answer. But, let’s see how long it took you.”

(dotimes [n 5]
  (println (str "map - filter - reduce - ( run " n " ):"))
  (time (reduce + (filter even? (map hashcode odyssey-text)))))
       ;=> map - filter - reduce - ( run 0 ):
       ;   "Elapsed time: 6932.227 msecs"
       ;   map - filter - reduce - ( run 1 ):
       ;   "Elapsed time: 5433.219 msecs"
       ;   map - filter - reduce - ( run 2 ):
       ;   "Elapsed time: 5157.45 msecs"
       ;   map - filter - reduce - ( run 3 ):
       ;   "Elapsed time: 5397.058 msecs"
       ;   map - filter - reduce - ( run 4 ):
       ;   "Elapsed time: 5224.334 msecs"

Baba Yaga chuckled “Have it done again in under 5 seconds by the time I return. I am getting hungry.”

The girl starting sobbing again. “How am I supposed to make it faster?”

The cat calmly cleaned himself and said “I have heard that Clojure has a new Reducers library that allows you to do composable, parallel, reducible functions like mapping and filtering. Try this in the namespace.”

(ns reducers.core
  (:require [clojure.core.reducers :as r]))

“The new parallel versions of map and filter have the exact same shape as the regular versions. So all we need to do is use the new reducer versions.”

(r/fold + (r/filter even? (r/map hashcode odyssey-text))) ;=> 33702446

“But, is it faster? The girl hoped.”

        ;=>   r/map - r/filter - r/fold - ( run 0 ):
        ;     "Elapsed time: 4702.766 msecs"
        ;     r/map - r/filter - r/fold - ( run 1 ):
        ;     "Elapsed time: 4617.575 msecs"
        ;     r/map - r/filter - r/fold - ( run 2 ):
        ;     "Elapsed time: 4596.329 msecs"
        ;     r/map - r/filter - r/fold - ( run 3 ):
        ;     "Elapsed time: 4636.259 msecs"
        ;     r/map - r/filter - r/fold - ( run 4 ):
        ;     "Elapsed time: 4572.804 msecs"

“No!” Baba Yaga stormed in the room. “Cat! You helped her! You mangy thing. Get out of here!” She shoved the cat out the door. “Let me look at that. I don’t believe it. I want to see the all the filtered hash values for myself.”

The cat peeked around the corner and spoke softly to the girl. “Luckily, into uses reduce.”

(into [] (r/filter even? (r/map hashcode odyssey-text))) ;=> [80 114 ... ]

While Baba Yaga was intently inspecting all the values in the vector, the cat motioned to the girl to slip out the door. Once outside, she grabbed the cat in her arms and ran as fast and as far away as she could. She was relieved to finally reach her home safely. Where she and cat lived happily for ever after writing Clojure code.

The End

For more information about Clojure Reducers
For the code on github if you want to explore yourself.
More about Baba Yaga Russian Fairy Tales.

How to include non clojars/maven clojure version in your lein project

2 Replies

Do you need to have a specific version of Clojure in your leiningen project that you can’t get from Clojars?

I ran into this problem when I wanted to run a sample project on Clojure’s reducers – which is not in the current Clojars version of 1.4.0.  I needed to use the most recent version, (unreleased), of 1.5.0.  These are the steps to get you running.

  • Clone the clojure git repository 
  • In the project directory – run ant to build the jar
  • Install the jar into your local maven repo

mvn install:install-file -DgroupId=org.clojure -DartifactId=clojure -Dfile=clojure-1.5.0-master-SNAPSHOT.jar -DpomFile=pom.xml

  • Now you can update your lein project.clj with

(defproject reducers "1.0.0-SNAPSHOT"
:description "FIXME: write description"
:dependencies [[org.clojure/clojure "1.5.0-master-SNAPSHOT"]])
Run lein deps and you should be all set.

 

This trick also works with running leiningen projects with Datomic.  In this case – download the Datomic library and from the root directory run
 mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic -Dfile=datomic-0.1.3164.jar -DpomFile=pom.xml

******* Update *******
I found out that there is already an alpha version of Clojure on Maven. So you don’t need to do the build. http://mvnrepository.com/artifact/org.clojure/clojure/1.5.0-alpha2

It would simply be
(defproject reducers "1.0.0-SNAPSHOT"
:description "FIXME: write description"
:dependencies [[org.clojure/clojure "1.5.0-alpha2"]])

Day Dream Dinner

1 Reply

In a day dream, I met a genie.  He kindly offered to setup my dream dinner for me.  All I had to do was name six guests and they would receive gilt invitations to the best restaurant in the world.  Of course, they would all be delighted to attend and would be spared the nuisance of travel arrangements by handy magical teleportation.  I hesitated for a moment, there are so many people that I would like to name.  The genie tapped his foot impatiently.  Alright here they are:

 

Philip Wadler

Daniel Friedman

Rich Hickey

Philip Glass

George RR Martin

Neil Gaiman

 

Who would you name?

The Software Bathtub Curve

Leave a reply

toaster

I have had my Dualit Toaster for close to 19 years now. It has never broken down. It has reliably toasted my bread every morning with the mere turn of a dial.

I have had my dishwasher for 1 year and 2 weeks. It has all sorts of cool buttons and modes so that I can customize my wash cycles to suit my dishes and my mood. Precisely two weeks after the warranty expired, it began to blink randomly and stopped working. The control board had died. This was not an isolated incident. I have gone through many such failures with other appliances, my refrigerator, stove and washing machine.

Looking at my toaster and dishwasher, I made a couple of observations:

  1. The more complex the product, the less reliable it is, and the shorter the life span.

Sure, it would be cool if I could control my toaster with my mobile phone app, but just having a heating coil and a dial gives the advantage of having a lot less things that could go wrong.

  1. A product is only as reliable as its least reliable part.

You can pay a small fortune for a oven built of stainless steel with all the latest technological advances in color display and computerized air flow. But if it relies on the same computer circuit board that all the other ovens use, (the one gives out after a year), then your investment is not any more reliable.

I also noted that these observations could be translated to software as well. Certainly, in the case of building software, the more complex the system the more things that can go wrong. The same could hold true that overall software system is only as reliable as the least reliable part of it.

This brought me to the larger question.

How do the manufacturers know, with such accuracy, when the product is going to fail? Could you apply the same principles to software?

The Bathtub Curve, according to wikipedia, is widely used in reliability engineering. It gets its name from the shape of the curve, which looks a bit like a bathtub. It is talked about in three sections:

  1. Decreasing failure rate (early failures)
  2. Constant failure rate (random failures)
  3. Increasing failure rate (wear-out failures)
bathubcurve

With software, we don’t talk about failures so much. We do talk about bugs, but even that is a bit misleading because it doesn’t take into account the need to accommodate features and evolving changes. So let’s talk about “issues” instead that can be broad enough to accommodate traditional bugs, gaps of functional needs, and performance related items.

The Software Bathtub Curve might look like the following:

 

Decreasing issue rate (launch & growing pains)

This is the early stage of the software. After its initial launch, gaps in functionality, bugs, and performance issues are readily identified and corrected. The main factors of reliability here are communication, responsiveness and agility.

Sample questions for determining data for this part of the curve:

  1. Do you use a dynamic language/ framework that allows rapid development? +10
  2. If the product owner and developers were in the same restaurant would they recognize each other? + 10
  3. Can the product owner and developers recognize each other by voice? +5
  4. Do you have a daily standup? + 5
  5. Do you really stand up the whole time? +2
  6. How many outside integration points are there? -5 for each
  7. How many programming languages and frameworks are there? -5 for each
  8. Do you release often? +5 for every 2 weeks (-1 for each week longer)
  9. Do you work over 40 hours a week regularly? -10
  10. Do you have an automated test suite? + 10
  11. Does it have regularly have untended errors in it? -5
  12. Do you use pair programming or code reviews? +10

 

Constant failure rate (random failures)

This is the time when the software reaches maturity. The business needs do not change drastically, but require minor refinements. Random issues occur from 3rd party integration issues or real world data issues. Major factors for reliability in this phase are avoidance of technical debt, data curation, and code quality.

  1. Has the team scaled down to just include a minimal or junior support staff? -10
  2. Do new features/ fixes get put in with the appropriate refactoring and tests? + 10
  3. Do new features/fixes more often just get stuck in there in the easiest way possible? -5
  4. Do your tests still all pass +10
  5. Do you get advance warning when a 3rd party api is changing? + 10
  6. Do you test that change in advance? + 5
  7. Do you still talk to the product owners? +5
  8. Do you care about code / data quality? + 10

 

Increasing failure rate (Failure to adapt to new business needs)

This is the final phase in the software life cycle. The new business needs cannot be met with the exsiting software and the cost of changing or adapting it is too high or not possible. Major factors for reliability and length of life span include openness and complexity of design and architecture.

  1. Do you have have to pay for a closed vendor product? -10
  2. Do you use open source languages and libraries? + 10
  3. Are you afraid to change anything because it might break? -10
  4. Is your main software language more than 1 version behind the latest? -5 for each version behind
  5. Does the mention of new features install fear instead of passion? -500

 

In the end, although it is interesting to compare software to the appliance Bathtub Curve, it is a leaky abstraction at best (sorry, couldn’t resist). Software is living thing. It needs to respond to its ever changing environment and needs. Furthermore, it is made up of a collection of living people who care and tend for it as well. However, there are clear factors that can go a long way to increasing the reliability, usability, and lifespan of software as well. We, as software developers, should keep them in mind as part of the ultimate goal of creating living, quality software.

 

Code Mash 2012: Bacon for the Brain

1 Reply

I was delighted to see first hand, why 1200 CodeMash tickets sold out in 20 minutes. It was full of awesome. This was easily the biggest conference that I have ever attended. It was held in the luxurious and fun Kalahari conference center and ran as smooth as silk, expertly supported by a volunteer staff.

One of the things that I really appreciated about the conference was the diversity of people from different technology backgrounds. There were many developers from .NET, Java, Ruby, and Python worlds all coming together to swap stories, share ideas and learn something new. It created an opportunity for everyone to get out of their box and their comfort zone. I was particularly impressed by one woman that I talked to, who came from the .NET world but had made a conscious decision to not attend any .NET talks at all.

The talks that I attended were all superb. Here is a few of my personal highlights:

  • Jim Weirich’s Roman Numeral Code Kata: He did a live coding demonstration of the Roman Numeral kata by TDD and refactoring. The joy that he shows when his tests turn green and the love of the beauty of the code that emerges from refactoring, embody for me what Software Craftsmanship is all about. He simply is an inspiration.
  • Joshua Smith’s Prolog Talk: An excellent talk by and excellent speaker. He demonstrated the basics of Prolog reasoning by doing a family tree example. I am intrigued by it’s use with Semantic Web RDF reasoning and it’s similarity to Clojure’s core.logic. It is top of my list of things to look into.
  • Jen Myer’s Developers Can’t Design: She touched a chord for me, since I wish that I had more design skill. She masterfully pointed out the similarities of solving problems in design just as we solve problems in code development. Another key take away for me, was the need to have a holistic design for our applications. Siloing designers in Photoshop and then having developers take it from there is reminiscent of failed waterfall patterns. Embracing holistic design feedback at all levels of the project is needed to produce excellent applications.
  • Elizabeth Naramore’s Building Open Source Communities: This talk was a gem. She touched on the importance of Open Source communities by focusing on it’s essential component – people. Communication is so important in facilitating the flow of ideas that turns into the magic that fuels a vibrant community. One of her points, that I took away is to remember it is the little things that count. Don’t forget to say “Thank you.”

Another thing that delighted me was the strong interest in Clojure that was present at the conference. I had the good fortune to present an introduction to Clojure and I was so happy to talk to many people during the conference that said that they were interested in learning more at the language. There was even an Open Space that got spontaneously organized on Clojure on Friday.

The only downside of the conference was that it was hard to choose between the Open Spaces and the excellent talks going on. I did attend one that Justin Searls hosted on Friday afternoon. It was a blast. People paired up creating a simple JavaScript To Do app from different frameworks. John Andrews and I took the opportunity to explore ClojureScript. In particular, we played around with the new ClojureScript One and also the Enfocus library. At the end of the hour, we were having so much fun, I wished that we had another day just to continue.

All in all, it was an awesome time and I recommend it highly. If I had to sum it up in a phrase it would be: Bacon for the Brain :)

 

Getting Ready for CodeMash

Only one more day until CodeMash.  I am really looking forward to my first one.  I have heard nothing but wonderful things about this conference that brings together developers, geeks and their families for a week in January in Sandusky, Ohio.

I am also looking forward to the opportunity of presenting my “Once Upon a Time in Clojureland” talk.  It is an introduction to Clojure in a Fairy Tale format.  I am hoping to share my enthusiasm for the language and inspire others to try it out for themselves.

If you haven’t seen it, you should check out the Mashed Code Magazine.  It is full of awesome.  It also contains a piece that I wrote under my super secret identity.  Hint, it is about Monads :)

Well off to pack and get things organized.  I’ll post my full coverage in the following days …