M-, m- and em-square | Typophile

Posted about 8 hours back at ZachInglis.com

M-, m- and em-square | Typophile

Clojure: Mocking

Posted 1 day back at Jay Fields Thoughts

An introduction to clojure.test is easy, but it doesn't take long before you feel like you need a mocking framework. As far as I know, you have 3 options.

1. Take a look at Midje. I haven't gone down this path, but it looks like the most mature option if you're looking for a sophisticated solution.
   


2. Go simple. Let's take an example where you want to call a function that computes a value and sends a response to a gateway. Your first implementation looks like the code below. (destructuring explained)

   (defn withdraw [& {:keys [balance withdrawal account-number]}]
    (gateway/process {:balance (- balance withdrawal)
                      :withdrawal withdrawal
                      :account-number account-number}))

   No, it's not pure. That's not the point. Let's pretend that this impure function is the right design and focus on how we would test it.
   
   You can change the code a bit and pass in the gateway/process function as an argument. Once you've changed how the code works you can test it by passing identity as the function argument in your tests. The full example is below.

   (ns gateway)
   
   (defn process [m] (println m))
   
   (ns controller
    (:use clojure.test))
   
   (defn withdraw [f & {:keys [balance withdrawal account-number]}]
    (f {:balance (- balance withdrawal)
        :withdrawal withdrawal
        :account-number account-number}))
   
   (withdraw gateway/process :balance 100 :withdrawal 22 :account-number 4)
   ;; => {:balance 78, :withdrawal 22, :account-number 4}
   
   (deftest withdraw-test
    (is (= {:balance 78, :withdrawal 22, :account-number 4}
     (withdraw identity :balance 100 :withdrawal 22 :account-number 4))))
   
   (run-all-tests #"controller")

   If you run the previous example you will see the println output and the clojure.test output, verifying that our code is working as we expected. This simple solution of passing in your side effect function and using identity in your tests can often obviate any need for a mock.
   


3. Solution 2 works well, but has the limitations that only one side-effecty function can be passed in and it's result must be used as the return value.
   
   Let's extend our example and say that we want to log a message if the withdrawal would cause insufficient funds. (Our gateway/process and log/write functions will simply println since this is only an example, but in production code their behavior would differ and both would be required)

   (ns gateway)
   
   (defn process [m] (println "gateway: " m))
   
   (ns log)
   
   (defn write [m] (println "log: " m))
   
   (ns controller
     (:use clojure.test))
   
   (defn withdraw [& {:keys [balance withdrawal account-number]}]
     (let [new-balance (- balance withdrawal)]
       (if (> 0 new-balance)
         (log/write "insufficient funds")
         (gateway/process {:balance new-balance
                           :withdrawal withdrawal
                           :account-number account-number}))))
   
   (withdraw :balance 100 :withdrawal 22 :account-number 4)
   ;; => gateway:  {:balance 78, :withdrawal 22, :account-number 4}
   
   (withdraw :balance 100 :withdrawal 220 :account-number 4)
   ;; => log:  insufficient funds

   Our new withdraw implementation calls two functions that have side effects. We could pass in both functions, but that solution doesn't seem to scale very well as the number of passed functions grows. Also, passing in multiple functions tends to clutter the signature and make it hard to remember what is the valid order for the arguments. Finally, if we need withdraw to always return a map showing the balance and withdrawal amount, there would be no easy solution for verifying the string sent to log/write.
   
   Given our implementation of withdraw, writing a test that verifies that gateway/process and log/write are called correctly looks like a job for a mock. However, thanks to Clojure's binding function, it's very easy to redefine both of those functions to capture values that can later be tested.
   
   The following code rebinds both gateway/process and log/write to partial functions that capture whatever is passed to them in an atom that can easily be verified directly in the test.

   (ns gateway)
   
   (defn process [m] (println "gateway: " m))
   
   (ns log)
   
   (defn write [m] (println "log: " m))
   
   (ns controller
     (:use clojure.test))
   
   (defn withdraw [& {:keys [balance withdrawal account-number]}]
     (let [new-balance (- balance withdrawal)]
       (if (> 0 new-balance)
         (log/write "insufficient funds")
         (gateway/process {:balance new-balance
                           :withdrawal withdrawal
                           :account-number account-number}))))
   
   (deftest withdraw-test
     (let [result (atom nil)]
       (binding [gateway/process (partial reset! result)]
         (withdraw :balance 100 :withdrawal 22 :account-number 4)
         (is (= {:balance 78, :withdrawal 22, :account-number 4} @result)))))
   
   (deftest withdraw-test
     (let [result (atom nil)]
       (binding [log/write (partial reset! result)]
         (withdraw :balance 100 :withdrawal 220 :account-number 4)
         (is (= "insufficient funds" @result)))))
   
   (run-all-tests #"controller")

In general I use option 2 when I can get away with it, and option 3 where necessary. Option 3 adds enough additional code that I'd probably look into Midje quickly if I found myself writing a more than a few tests that way. However, I generally go out of my way to design pure functions, and I don't find myself needing either of these techniques very often.

Writing the Clutter cookbook

Posted 1 day back at townx - tech

I'm almost exclusively working on the Clutter cookbook at the moment, and I keep meaning to write about what it's like to spend your time writing. I'm not sure what's driving this need to explain myself. I think it's partly because I feel a bit unproductive at times, despite working pretty hard, and I feel like I need to understand why.

Perhaps if I explain the pattern of my work week. It goes something like this:

• Start the week thinking about which part of the Clutter API to write about. Clutter is pretty vast (well, not the API so much as what it makes possible) and flexible (so you have choices about how to implement a particular feature, animation, effect, UI element etc.). I am still finding stuff in there I haven't noticed before: new functions, configuration options I haven't noticed, whole new chunks of API (it's evolving like nobody's business). But at least I put together a plan with the Clutter maintainer, Emmanuele a while back, which puts some structure and priority around which things which are important.
• I then try to come up with a recipe idea to illustrate part of the API, or an interesting topic, or to answer a question I've noticed on the mailing lists or IRC channel. The idea might be something like "reusing an animation with different UI elements", or "handling mouse button presses", something like that. I may also look around at other treatments of the same thing in other cookbooks, tutorials etc., on the web and in O'Reilly Safari; perhaps even try to find videos of a particular UI effect (e.g. today I was looking at cover flow videos, implementations, patent applications [can I even write about that kind of effect?]).
• Then I try to write some example code to get a feel for the API. This might involve talking to the Clutter developers on IRC about how something works, or maybe sending something to the mailing list. Occasionally I find bugs and log them (this can suck up a lot of time as I try to do as much due diligence as possible before logging anything, and provide decent reproducible test cases if possible). I frequently need to write maybe half a dozen small programs and perhaps a small application to try stuff out (like: "what happens if I put this UI element over this one?", "how does the height of an element get reported if it's moved away from the view point (into the z axis)?", "If I set this property, how does that affect the object's behaviour in this context?" and so on).
  (The code I'm writing is in C, which I admit is a bit of a struggle. I'm just about getting to grips with it now.)
• At the same time as I'm writing this code, I'm maintaining my own git branches for each recipe I write, as they have to be kept isolated from each so they can easily be merged in one at a time (hopefully). This means keeping up to date with Clutter as it's being developed. So I'm also learning git (which I've never used a lot before) to pull changes in from Clutter master to my branches (and still sometimes screw it up).
• While I'm doing that, I'm also starting to think about this part of the API from a developer perspective: Are there alternative ways to do this in Clutter? Why should I use this approach? Why not this other approach? I start putting notes together about the code I'm writing, very rough to start with.
  At this point, I quite often find myself paralysed as I start writing the text for the recipe. Writing text is much harder than writing code, at least for me; particularly writing text about code. (I can write code until the cows come home, but writing text is much harder: which is why most open source projects have lots of code and very little, mostly poor documentation.) Sometimes, finding a decent "story" to tell about the recipe or piece of code can be frustratingly hard (like what I've experienced today when approaching ClutterAnimator :) ), and I find myself suffering what you might call "writer's block". At which point I make several false starts, write free-form pieces trying to articulate what I'm doing, what I'm explaining, just write anything at all to try to shift the block. Sometimes I can be blocked like this for half a day; frustrating, unproductive, prevaricating, maddening half of a day. Sometimes the best thing to do is take a break, go for a walk, do some admin or research on something else altogether. Then before I know it, thankfully, the next day everything slots into place again, and I can write again.
• At some point while I'm putting tangible paragraphs together in my rough draft, I move it over to the Docbook template for the cookbook. This means putting XML mark-up and formatting around what I've written so far. This then gets checked in with the code; edits are then checked in as I go along; occasionally I'll merge edits together (thankyou, git rebase -i) to make the development history less convoluted.
  I also take any screenshots and video (the latter using gtk-recordMyDesktop) I need and incorporate those into the XML template.
• Eventually, I get something together and end up with a first draft. Then I leave it for at least half a day before I go through it again, cleaning up the text and making sure my branch is spick and span.
  The process of iterating over the recipe to improve the text is something miraculous to me: I don't do it consciously, but somehow I can read text and rewrite it to read better. I don't know how I do it, to be honest. Which is good, because it means I've basically turned the skill into a habit; but that in turn makes it difficult to reflect on. I don't think I could teach it to anyone either, as I don't explicitly understand the unconscious rules I'm applying.
• Finally, I submit the recipe as a bug to the Clutter bugzilla. I typically post a bug marked as an enhancement request (e.g. http://bugzilla.clutter-project.org/show_bug.cgi?id=2288), along with a link to my git branch (e.g. http://gitorious.org/clutter-cookbook/clutter-cookbook/commits/cookbook-...). At this point, Emmanuele may come back to me with some requests for changes or comment on the bug; I try to respond as quickly as possible, and put a note on the bug when I'm done. At which point, hopefully, Emmanuele merges the work into Clutter master and the recipe is complete.
  In an average week, I can turn out one or two recipes. If I'm trying to write an introduction to some Clutter concept (e.g. last week I was writing an introduction to ClutterScript), it might be slower, as I have to understand the scope of the concept and find a way to communicate it.

It's the blockages which frustrate and shame me. I wish they didn't happen (they are pretty depressing too), but I think they might actually be an essential part of the "creative process". The miracle of copy-editing makes up for it :).

New PHP Licensing Option for Cloud Computing

Posted 1 day back at InfoQ Personalized Feed for unregistered user - Register to upgrade!

Zend recently announced an 'unlimited subscription' licensing option for its PHP products, in support of cloud computing. Virtualization and Cloud Computing challenge traditional concepts of software licensing, e.g. one license per user, one license per server, because of the dynamism and variability of running instances inherent in both concepts. Zend offers one way to solve this problem. By Dave West

Go forth and use proprietary browser features

Posted 1 day back at mir.aculo.us - Home

Here’s why you shouldn’t be afraid to use proprietary browser features–especially with stuff that’s more experimental and explorative in nature: First of all, lots of good things come from once-proprietary features. My favorite example perhaps is the .innerHTML property of DOM elements, that originated on Internet Explorer. This property is not only easier to use [...]

$3 off The Rails Upgrade Handbook ENDS TODAY

Posted 1 day back at omg blog!! lol!!

In celebration of the release of Rails 3 stable, I’m running a sale on my upgrade handbook. Be sure to get it soon because the sale ends today.

Click here to get you some sweet, sweet discounted eBook action!

IBM X-Force Report: Enterprise Security Exploits Are Raising

Posted 1 day back at InfoQ Personalized Feed for unregistered user - Register to upgrade!

IBM has published the IBM X-Force® 2010 Mid-Year Trend and Risk Report August 2010 (112 pages long, free registration required) containing detailed information about the security vulnerabilities and exploits of 2010, such as JavaScript and PDF obfuscation, the current security threat trends in the enterprise, and a look into the future. By Abel Avram

Presentation:Command-Query Responsibility Segregation

Posted 1 day back at InfoQ Personalized Feed for unregistered user - Register to upgrade!

Udi Dahan discusses the Command Query Responsibility Segregation (CQRS) pattern and its relationship to Domain Driven Design (DDD), detailing on queries and commands, what they are and how they should be used in an asynchronous programming environment. By Udi Dahan

Article:The Story of a Project

Posted 1 day back at InfoQ Personalized Feed for unregistered user - Register to upgrade!

By Olivier Mallassi

Presentation:Living and Working with Aging Software

Posted 1 day back at InfoQ Personalized Feed for unregistered user - Register to upgrade!

Ralph Johnson discusses principles, practices and tools relating to software development starting not from scratch but from already existing code which needs refactoring, maintenance, and sometimes architectural change. By Ralph Johnson

Clojure: Using Sets and Maps as Functions

Posted 3 days back at Jay Fields Thoughts

Clojure sets and maps are functions.

Since they are functions, you don't need functions to get values out of them. You can use the map or set as the example below shows.

(#{1 2} 1)
> 1

({:a 2 :b 3} :a)
> 2

That's nice, but it's not exactly game changing. However, when you use sets or maps with high order functions you can get a lot of power with a little code.

For example, the following code removes all of the elements of a vector if the element is also in the set.

(def banned #{"Steve" "Michael"})
(def guest-list ["Brian" "Josh" "Steve"])

(remove banned guest-list)
> ("Brian" "Josh")

I'm a big fan of using sets in the way described above, but I don't often find myself using maps in the same way. The following code works, but I rarely use maps as predicates.

(def banned {"Steve" [] "Michael" []})
(def guest-list ["Brian" "Josh" "Steve"])
> ("Brian" "Josh")

However, yesterday I needed to compare two maps and get the list of ids in the second map where the quantities didn't match the quantities in the first map. I started by using filter and defining a function that checks if the quantities are not equal. The following code shows solving the problem with that approach.

; key/value pairs representing order-id and order-quantity
(def map1 {1 44 2 33})
(def map2 {1 55 2 33})

(defn not=quantities [[id qty]] (not= (map1 id) qty))
(keys (filter not=quantities map2))
> (1)

However, since you can use maps as filter functions you can also solve the problem by merging the maps with not= and filtering by the result. The following code shows an example of merging and using the result as the predicate.

; key/value pairs representing order-id and order-quantity
(def map1 {1 44 2 33})
(def map2 {1 55 2 33})

(filter (merge-with not= map1 map2) (keys map2))
> (1)

I don't often find myself using maps as predicates, but in certain cases it's exactly what I need.

"If you want to make a business succesfull, it’s better to have a small piece of something..."

Posted 3 days back at ZachInglis.com

“If you want to make a business succesfull, it’s better to have a small piece of something large than a large piece of nothing.”

-

Chris Elsworthy, Dragons Den