Monologue

Admittedly I was more than happy today when I went to the SD Times front page and read: “Branching and merging: the road ahead for SCMâ€, which is cool considering “branching & merging†is the heart of our daily work.

This is our mantra!!

We always say “branching and merging is goodâ€, we designed Plastic SCM from the ground up back in 2005 to help all the small and medium teams in companies out there moving towards parallel and later distributed development.

And now, certainly thanks to DVCS major players like Git and software heroes like Linus Torvalds, it became a major industry trend.

Version control used to be a commodity circa 2004, but 2005 rocked the SCM world and a new wave of tools tossed the foundations of the configuration management sector: big tools like PVCS and ClearCase and mass-oriented ones like Subversion started to vanish away.

And a brave new world emerged shaped to the form of the new development trends: agile, faster, more dynamic and fully distributed.

But, as usual, there’s confusion:

centralized minds making bold statements about what DVCS can and can’t do.

I’m trying to come up with a list in the purest Chuck Norris facts style about what’s true and what’s not true about DVCS. But, to start with, I’ll simply try to check whether 4 DVCS myths stated in the article in SDTimes are true.

Myth one - DVCS has a steep learning curve

Replace “dvcs†by “git†and you’ll get the original statement.

Well, it is simply incorrect: there’s much more to DVCS than Git. Give a try to Hg, check Plastic SCM or simply read a little bit more about Git and you’ll find that learning DVCS is not harder than learning Subversion or Perforce.

Myth two- DVCS GUIs aren’t there yet

“There is no effective GUI yet, so it appeals more to power users than enterprise developers.†(sic Perforce’s Randy DeFauw)

As a Plastic SCM developer this is fun to read. I know he is talking about Git, but still :P Our system is all about cool GUI and advanced DVCS. Compare Plastic SCM with others and check our GUI effectiveness.

Myth three- DVCS requires a full replica on each developer machine, compromising security

Today I feel like we were doing our homework down here at Codice: while this can be true for Git or Hg, the good thing with Plastic SCM is that it is all about choices: you want it centralized, fine, you want it distributed, fine too, you want a full replica, right, you just need to replicate a single commit (changeset) to your laptop, work on it and push back to the main server later on… fine!

Regarding security: ACL based sec, triggers, up to 7 standard database backends, LDAP support built-in… what do you mean by “compromised�

Myth four - DVCS can’t deal with big files and it is only designed for text

Down here we test Plastic SCM 4.0 with a checkin of 1Tb in a single file.

You read correct: 1 TeraByte inside a single file.

And yes, we run circles around Subversion while doing it.

SO: maybe Git or Hg have big trouble dealing with big files, but Plastic SCM is distributed and can deal with files as big as you can handle, that’s why, for instance, some reputed game developers already use Plastic SCM.

Myth five - There is no “master†file or canonical source

Tell that to Mr. Torvalds and his “dictator/lieutenant†controlled integration model.

No master file? Being distributed doesn’t mean there’s no canonical source. You can have more than one repository but still kwon which one is the master copy.

Unable to do a replica doesn’t mean you’re better organized (SVN, Perforce), it only means you’re unable to do distributed work.

The implementation of joinad operations for the Task<'T> type is quite similar to the implementation of Async<'T>, because the two types have similar properties. They both produce at most one value (or an exception) and they both take some time to complete.

Just like for asynchronous workflows, pattern matching on multiple computations using match! gives us a parallel composition (with the two tasks running in parallel) and choice between clauses is non-deterministic, depending on which clause completes first.

Unlike asynchronous workflows, the Task<'T> type does not require any support for aliasing. A value of type Task<'T> represents a running computation that can be accessed from multiple parts of program. In this sense, the type Async<'T> is more similar to a function unit -> Task<'T> than to the type Task<'T> itself.

The key difference between tasks and asynchronous workflows is that the latter provides better support for writing non-blocking computations that involve asynchronous long-running operations such as I/O or waiting for a certain event. Tasks are more suitable for high-performance CPU-intensive computations.

Note: This blog post is a re-publication of a tutorial from the TryJoinads.org web page. If you read the article there, you can run the examples interactively and experiment with them: view the article on TryJoinads.

Just two more days of military life before I submerge yet again into a six plus month IT engagement that will keep me quite occupied. It has been great to see all my military brothering.

The US military is going through the 1991 "Ultra-SlimFast" diet yet again. Long live the Economy. May we not see the events of 2001's 911 yet again.

Remeber: "Mas sabe el Diablo por viejo que por Diablo"

I recently started to experiment with ClojureScript. In order to get a little bit beyond ‘hello world’ I decided to convert one of Raphaël‘s examples to ClojureScript. According to the projects homepage Raphaël is ‘a small JavaScript library that should simplify your work with vector graphics on the web’.

The sample I used draws a kind of clock. It can be found here. The relevant JavaScript code:

window.onload = function () {
    var r = Raphael("holder", 640, 480),
        angle = 0;
    while (angle < 360) {
        var color = Raphael.getColor();
        (function (t, c) {
            r.circle(320, 450, 20).attr({stroke: c, fill: c, transform: t, "fill-opacity": .4}).click(function () {
                s.animate({transform: t, stroke: c}, 2000, "bounce");
            }).mouseover(function () {
                this.animate({"fill-opacity": .75}, 500);
            }).mouseout(function () {
                this.animate({"fill-opacity": .4}, 500);
            });
        })("r" + angle + " 320 240", color);
        angle += 30;
    }
    Raphael.getColor.reset();
    var s = r.set();
    s.push(r.path("M320,240c-50,100,50,110,0,190").attr({fill: "none", "stroke-width": 2}));
    s.push(r.circle(320, 450, 20).attr({fill: "none", "stroke-width": 2}));
    s.push(r.circle(320, 240, 5).attr({fill: "none", "stroke-width": 10}));
    s.attr({stroke: Raphael.getColor()});
};

As you can see the JavaScript code is already quite compact. I especially like the use of the anonymous function in the inner loop. What I did next is a very straightforward conversion to ClojureScript just to see if I could get that to work. This turned out as:

 
(ns raph.hand) 
(defn clj->js
  "makes a javascript map from a clojure one"
  [cljmap]
  (let [out (js-obj)]
    (doall (map #(aset out (name (first %)) (second %)) cljmap))
    out))

(defn- attr [object attributes]
  (.attr object (clj->js attributes)))

(defn create-hand [paper]
  (.getColor.reset js/Raphael)
  (-> (.set paper)
      (.push (-> (.path paper "M320,240c-50,100,50,110,0,190")
                 (attr {:fill "none", :stroke-width 2})))
      (.push (-> (.circle paper 320 450 20)
                 (attr {:fill "none", :stroke-width 2})))
      (.push (-> (.circle paper 320 240 5)
                 (attr {:fill "none", :stroke-width 10})))
      (.attr "stroke" (.getColor js/Raphael))))

(defn create-circle [paper angle hand]
  (let [c (.getColor js/Raphael)
        t (str "r" angle " 320 240")
        circle (.circle paper 320 450 20)]
    (-> circle
        (attr {:stroke c, :fill c, :transform t, :fill-opacity .4})
        (.click #(.animate hand (clj->js {:stroke c, :transform t}) 2000 "bounce"))
        (.mouseover #(.animate circle (clj->js {:fill-opacity .75}) 500))
        (.mouseout #(.animate circle (clj->js {:fill-opacity .4}) 500)))))

(defn ^:export draw []
  (let [paper (js/Raphael 0 0 640 480)]
    (let [hand (create-hand paper)]
      (doseq [angle (range 0 360 30)]
        (create-circle paper angle hand)))))

The ClojureScript takes a couple of more lines than the JavaScript original: 36 versus 23. This has mostly to do with a couple of helper functions to convert Clojure maps to JavaScript maps.

A couple of things I learned/noticed during the conversion:

Finally the html code I used to test my code:

<html> 
  <head>
    <title>Hello, world</title>
    <script type="text/javascript" src="jslib/raphael-min.js"></script>
    <script type="text/javascript" src="raphtest.js"></script>
  </head>
  <body>
    <script>
        raph.hand.draw();
    </script>
  </body>
</html>

And to compile

cljsc src '{:optimizations :advanced :output-to "raphtest.js" :externs ["lib/raphael-min.js"]}

For a really good explanation on how to set up a more robust ClojureScript development environment, have a look at Sean Corfields blog.

Asynchronous workflows provide a way of writing code that does not block a thread when waiting for a completion of long-running operation such as web service call, another I/O operation or waiting for the completion of some background operation. In this article, we look at the new expressive power that joinads add to asynchronous workflows written using the async { ... } block in F#.

Note: This blog post is a re-publication of a tutorial from the TryJoinads.org web page. If you read the article there, you can run the examples interactively and experiment with them: view the article on TryJoinads.

(Click for a larger version)

If you have been following my blog, you've probably already heard of joinads. It is a research extension of F# computation expressions (or monads in Haskell). The extension makes computation expressions more useful in domains like parallel, concurrent and reactive programming. However, it can be used for any type of computation including, for example, parsers. If you're interested in detailed description, you can find it in two academic papers that I blogged about previously: PADL 2011 and Haskell 2011.

The extension adds a keyword match! - as the syntax suggests, it is akin to pattern matching using match, but instead of pattern matching on values, you can pattern match on computations like Async<'T> (or on other monadic values). Just like other features of computation expressions, the match! syntax is translated to applications of several methods defined by the computation builder.

I won't say more about joinads in this post, because you can now easily try joinads yourself...

This past week, I've started to get back into photography a bit more (thanks, Nina!) and started taking my camera into the office with me every day to remind myself to take photos. As a result, I've taken a bunch of photographs of my co-workers in the office.

Would you like to meet the hackers?

The Founders

Most of you would probably recognize the infamous Miguel de Icaza, Xamarin's CTO:

Next up is our very own Steve Jobs, Nat Friedman, our CEO and the man who reminds us to pay attention to the details:

Another person many of you will recognize is our very own COO, Joseph Hill:

MonoDevelop Team

Well, okay, I've only got a photo of the famous Michael Hutchinson, but he's a very important player in the development of MonoDevelop.

QA Team

Next up, we have the QA team. They do their best to make sure that we, the developers, didn't break anything. When they aren't testing a specific application before a launch, they hammer away at our products and try to find weak spots in our code (but we still love them anyway!)

This is PJ, and as you can see, he's demonstrating how to QA popcorn corn cobs:

(Did it pass the test, PJ?)

Next up is Lindsey. She's been working on writing automated tests to make it less likely for releases to include regressions. Let's hope she's successful!

Release Team

Alex Corrado is the man behind the curtain. He's our head Release Team engineer and also the brilliant mastermind that started CXXI, the Mono C++ interop project that we hope to give him time to finish someday soon.

Web Team

The newest addition to our ranks (just this week, in fact!), but long-time contributor to the Mono project, is Bojan Rajković. You can see we've already put him to work (he is no doubt puzzling over some ASP.NET code on his screen).

Documentation Team

Nina is the only Cambridge resident on our Docs Team. Specifically, she hacks on our Documentation Portal. She's also the one who has encouraged me to get back into taking photographs, so she'll have to put up with me using her as a guinea pig the most. Here she is taunting me with her hot cup of Chaider:

You can now get the Slides for my Mono for Game Development talk.

Or you can go straight to the resources for the talk.

Just two days ago, we launched MonoTouch 5.2, featuring a memory profiler, unit testing framework, and a new generational garbage collector. With this release we also bundled a popular library called MonoTouch.Dialog; so it’s as easy as adding a new reference to the library to include it into your project.

MonoTouch.Dialog makes building native user interfaces in iOS incredibly easy. But how do you actually use it? Mike Bluestein, who you might recognize from our Xamarin Seminars, has created a 15 minute introduction on MonoTouch.Dialog to get you started.

[ http://www.youtube.com/embed/j7OC5r8ZkYg?version=3

Important: To view this video in HD, open it up in YouTube or select 720p in the video above.

Using MonoTouch.Dialog allows applications to be created with rich, table-based user interfaces, without all the complexities associated with creating such interfaces manually. At the same time, MonoTouch.Dialog doesn’t limit the ability to customize such applications. This video introduces MonoTouch.Dialog by way of an example that demonstrates how to create a master- detail style of application. It shows how to use MonoTouch.Dialog to present hierarchies of information and use it to create table based user interfaces automatically.

For additional information be sure to check out our MonoTouch.Dialog tutorial.

It is a great honor to participate this weekend on the online AltDevConf conference. This is an online two-day event

I will be participating in the talk on Cross Platform Game Development using C# with Matthieu Laban and Philippe Rollin.

You can register here for our session on Saturday at 3pm Eastern Standard Time, noon Pacific Time, and 9pm Paris Time.

If you are located in the Paris time zone, that means that you get to enjoy the talk sipping a tasty hot chocolate with some tasty baguettes.

Build Great iOS Apps in C#

We’re very proud to announce the availability of MonoTouch 5.2. This release represents months of improvements, with over 300 new features, bugfixes, and enhancements. This is without question the best release of MonoTouch to date.

Here’s a quick rundown of some of the new features in MonoTouch 5.2.

Faster and easier creation of iPhone/iPad Dialogs

MonoTouch.Dialog is a new API that allows developers to create HIG-compliant native iOS screens and dialog boxes and to show table-based information easily. It removes the burden of creating callbacks, data sources and delegate implementation to render tables. MonoTouch.Dialog comes with a range of custom cell renderers that vastly reduce the time it takes to build complex screens and you can even create user interfaces dynamically on demand from JSON data served up online! You can learn more in our MonoTouch.Dialog tutorial and you can also browse the online API documentation.

Memory Profiler

The new MonoTouch memory profiler enables you to identify memory usage hotspots and fix them quickly, tracking the memory usage of managed objects, showing which objects are still referenced, and who is referencing them.

New Garbage Collection Engine

This version of MonoTouch also includes Mono’s new generational garbage collector. You can opt into this new garbage collector by selecting “SGen” as one of the options in your build settings. For certain apps, this can lead to lower memory usage and better performance.

On-device unit testing

Ensure that your app is ready to release with our built-in unit testing framework for running unit tests on both the iOS simulator and your device. You can run your tests manually, or automate them with Instruments. Check out our tutorial on writing unit tests for MonoTouch for more information.

New Libraries

From Mono, we brought the System.Numerics library that brings the Complex and Big Integer data types as well as support for Memory Mapped IO.

But wait, there’s more…

MonoTouch 5.2 also includes more than 300 customer requested enhancements that make it easier to develop great iOS applications. See a full listing of new features and capabilities here.

MonoTouch 5.2 is available immediately to all MonoTouch customers currently within their annual subscription period; just run MonoDevelop and select the Check for Updates menu item.

For complete product information about MonoTouch, and to download a free trial, visit http://xamarin.com/monotouch.

To see example apps built with Xamarin technology, visit: http://xamarin.com/apps.