Today is the ten year anniversary of the incorporation of Ximian, Inc. A company founded by Nat Friedman and myself whose goal was to advance the state of the Linux desktop. It was also an excuse for Nat and myself to hang out as we had become best friends forever in the previous two years.
Our conversations over the years have always been a little surreal. I have megabytes worth of logs that look like this:
Ximian was made up of friends that shared this vision, and its founders had no startup, business or management experience when we launched the company. We learned on the job and we were advised by friends that believed in our goals, and by people that cared about our mission.
From the archive: Ettore Perazzoli, Raph Levien, Nat and myself in Summer of Linux.
Ximian hired 90% of its employees from open source contributors in the community and folks that we had met over mailing lists or IRC channels.
Nat was a Computer Science and Math graduate; I was a math drop out and we had no management experience. This means that we made every possible management mistake in the book, but all of our friends and employees stuck with us as we learned and as we worked to get the company off the ground.
This is an interesting time to reflect on 10 years of hacking adventures. Writing, funding and advancing the state of the art of open source. In the next few weeks, Nat and myself will be publishing some short stories from Ximian.
Today Ximian has been incorporated into Novell. Our goals have been expanded, but we still continue to work to advance the state of the art in Linux.
Looking forward to another 10 years of joy and hacking.
Posted on 19 Oct 2009
I woke up this morning and found that the amazing Craig Dunn put together an iPhone app for the Monospace Conference using MonoTouch!
The app provides the schedule, access to the twitter feeds for the speakers and the conference, access to the MonoSpace blog, speaker profiles and access to their blogs and twitter feeds and a map to find the event.
You can learn more, see larger screenshots and download the code to run on your iPhone from Craig's Post.
Posted on 17 Oct 2009
Over the past few weeks, the final details of the program for the Monospace Conference have been announced, and now the event is just less than two weeks away. Some key details you may have missed:
From the Mono team, various engineers will be presenting on special topics:
The Monospace conference will be held in Austin, TX on Tuesday, October 27 through Friday, October 30. To register for the event, visit the Monospace Conference Registration Page.
Check the program for more information.
Registered Monospace attendees will receive a $150 discount on MonoTouch, if they purchase in the month of October.
Posted on 16 Oct 2009
When we were designing the MonoTouch APIs we had to map some of the constructs used by CocoaTouch and Objective-C to what C# developer expect.
Like other modern toolkits, the behavior of a control can be customized by the programmer by hooking up to events and the responses to those events.
This is a common pattern used in other toolkits. In Gtk+ objects emit signals, and the programmer can connect event handlers to individual signals, for example this is how you would connect
void pause_player () { // pause the player. } void configure_pause () { button = gtk_button_new_with_label ("pause"); gtk_signal_connect (button, "clicked", pause_player, NULL); }
In the ECMA CLI world developers hook up to events by connecting to events directly in the object, it is similar in spirit:
void configure_pause () { button = new Button ("Pause"); button.Clicked += delegate { // Pause the player here. }; }
In both the Gtk+ and the ECMA CLI worlds there can be multiple subscribers to the event.
In CocoaTouch, instead of having an event per action they use a pattern where the components emits all of its messages to an instance of an object. If a button were to emit messages like "clicked", "clicked_violently" and "caption_changed" all of those messages will be sent to an object that implemented the required interface.
I am going to give myself a literary license and use some terms loosely and write a little bit of imaginary C#.
A button implementation would look like this:
interface ButtonDelegate { optional void clicked (); optional void clicked_violently (); optional void caption_changed (); } class Button { public ButtonDelegate Delegate { get; set; } public Button (string text) { ... } public string Text { get { return text; } set { text = value; DoSomeRepainting (); Delegate.caption_changed (); } } public EventHandler () { ... if (event_this_is_the_user_clicking){ // Send the message to the Delegate Delegate.clicked (); }
The user of the Button class then needs to implement the interface ButtonDelegate to respond to messages. This in Objective-C is made simple by allowing this interface to have optional methods.
This would not work with C# interfaces as those require that all the methods on the interface are implemented.
So we came up with a design that would blend those worlds together.
We can support the Objective-C model where a class can satisfy the contract by just registering methods to respond to the actions. A user could respond to some events like this:
class Foo : NSObject { void ConfigureButton () { button = new Button ("pause"); button.WeakDelegate = this; } [Export ("clicked")] void pause_clicked () { // Pause the button. } }
In MonoTouch we expose the "WeakDelegate" property as the weakly-typed version of the delegate, that means that you can assign to it anything that derives from the NSObject class, and respond to messages by just annotating your method with the [Export ("name")] attribute.
But weakly typing could introduce errors. What if the parameters of the method or the return value do not match the actual signature of the selector. If the developer introduce a typo, the compiler would not be able to point this out, and you would get a nice crash or some corrupt memory.
So we introduced strongly typed delegates, these require the programmer to implement a class and override methods that have a very specific signature. The code would then look like this:
class Foo : ButtonDelegate { void ConfigureButton () { button = new Button ("pause"); button.Delegate = this; } // strongly typed: override ensures that this method exists in // the base class, or the contract is not satisfied. public override void pause_clicked () { // Pause the button. } }
The ButtonDelegate class is flagged with a special attribute, the [Model] attribute which informs the MonoTouch runtime that only methods that are overwritten from this class will be dispatched, any other methods will be considered optional and treated like optional methods.
The problem of course is that if you wanted to respond to multiple buttons, you would have to actually distinguish them somewhere in your pause_clicked with some sort of closure value, or use helper classes, one for each button that you want to respond to. But that is a minor detail.
So Objective-C developers that like the separation between model, view and controller can continue to use those patterns.
That being said, although there is a lot of literature and discussion about the clean separation of Models, Views and Controllers, most samples I run across are a hodgepodge of Controller code for all sorts of things. At least the production code and the samples I have seen make it obvious that the separation of concerns is mostly academic, and in practice an instance object becomes a general purpose responder to all events, very much like you see in Gtk+, Qt, or Winforms.
Our approach also has a limitation: the hodgepodge approach does not really work with the strongly-typed signatures as you can only derive from one class at a time. The solution is to use separate classes for each controller. Although that cleans things up and has some aesthetics associated with it in terms of clean separation of concerns, in my opinion, it is not very practical.
With MonoTouch we wanted to preserve the C# style of programming where you could attach code to these notifications one-by-one.
With C# you can use anonymous methods or lambda functions. These are incredibly powerful as they are able to capture the environment in which they were created. This means that you can trivially pass information and share information between multiple handlers.
Additionally, you more than one method can "subscribe" to the same event, you are not limited to a single method being the receiving of the events.
This means that in MonoTouch you configure buttons like this:
void configure_button () { button = new UIButton (dims) { Text = "Pause" }; button.Clicked += delegate { // Pause the video }; }
What MonoTouch does internally is that the first time that you attach to a C#-like event, it create an instance of the ButtonDelegate that merely raises the event in the C# style.
This means that you only pay for the memory usage if you use the feature. But when you do, you can subscribe to individual events and you can have more than one listener attached to the event.
Although we brought the pattern to most places in MonoTouch where a delegate was used, it is notably missing from the UITableView as we felt that the number of methods that had to be overwritten were too big for the model to make sense.
In a few instances like UITableView, we suggest that developers just use the strongly typed version of the delegate classes and override the methods accordingly.
One of the things that I would like to see is a UITableView derived class that can present the data and style the data entirely based on properties discovered at runtime with System.Reflection.
Another thing that I want to see is support for System.Data data binding style versions of the UITableView and other UI controls in a single page.
More details on the low-level implementation are available on the API design document on the web site.
Posted on 15 Oct 2009
Meinrad Recheis has lead the effort to bring a full managed GIT implementation to the .NET and Mono worlds and he just announced the release of GitSharp 0.1.3, the first public release of Git#.
The code is based on the original work from Kevin Thompson who ported the JGit Eclipse plugin to C#. Meinrad has put together a great community of contributors that integrated every JGit improvement, the credits for the first release are as follows:
An easy to use API is being developed on top of the GIT core, check out some of the examples.
Posted on 12 Oct 2009
In 1991 or 1992, I wrote a curses-based file manager for Unix, a clone of the DOS Norton Commander.
Unlike the Norton Commander, curses, xterms and Linux did not support the mouse. So I called my file manager "The MouseLess Commander".
Linux at that time was a cauldron of hot ideas. And Alessandro Rubini created a library for console applications to get mouse support on Linux. We worked to add mouse support to the MouseLess Commander and by the end of this exercise we renamed the file manager to "The MouseLess Commander With Mouse Support".
Somehow I was talked into changing the name of the Mouseless Commander with Mouse Support. Since I was pretty bad at naming, we organized a vote on the mailing list and eventually the current name "Midnight Commander" was picked.
I miss the previous name.
Posted on 06 Oct 2009
Richard Stallman does not seem to have anything better to do than launch personal attacks against me. In his last piece he has decided to call me a Microsoft apologist because I do not participate in his witch hunt.
I merely happen to have a different perspective on Microsoft than he has. I know that there are great people working for the company, and I know many people inside Microsoft that are steering the company towards being a community citizen. I have blogged about this for the last few years.
At the end of the day, we both want to see free software succeed. But Richard, instead of opening new fronts to promote his causes, attacks his own allies for not being replicas of himself. To him, ridiculous statements like Linus "does not believe in Freedom" are somewhat normal [1].
A few years ago, I had the chance to listen to Benjamin Zander in person talk about his world of possibilities. His book "The Art of Possibility" had a profound effect on me.
Benjamin tells this story in the book:
Two shoe salesmen were sent to Africa in the early 1900's to scout the territory.One telegraphed back: "Situation hopeless. Stop. No one wears shoes."
The other telegraphed: "Business opportunity. Stop. They have no shoes."
Since we only have a limited time on earth, I have decided to spend my time on earth as much as I can trying to be like the second salesman. Looking at opportunities where others see hopelessness.
This is why I love my work, because I work with friends that have consistently beat the odds and we have consistently proved our critics wrong. Because everyone that I work with wants to change the world and nobody I work with is dominated by fear.
Far too many times, fear has prevented people from coming up with creative solutions. I rather work on constructive solutions to problems than moan and complain.
Fear mongering is a vibrant industry, it is the easy way out for those that can not lead with the example. Create a bogeyman, make things up, lie, or tell half-truths, and demonize and you got a recipe to energize your base.
The documentary "The Power of Nightmares" is a fascinating view at the industry of selling "safety" to the scared population and how leaders like to scare people to push their own agendas. Richard's fear mongering is no different.
Richard Stallman frequently conjures bogeymen to rally his base. Sometimes it is Microsoft, sometimes he makes up facts and sometimes he even attacks his own community [2]. His language is filled with simple, George W Bush-eque terms like Good vs Evil, Us vs Them.
The creation of the CodePlex foundation was an internal effort of people that believe in open source at Microsoft. They have been working from within the company to change it. Working at CodePlex is a great way of helping steer Microsoft in the right direction.
But to Richard, this simply does not compute.
To Richard, the state of the world is hopeless. I on the other hand see possibility and opportunity.
Not only you attract more bees with honey than with
vinegar, there are lots of shoes to sell.
[1] Plenty of attacks on other open source/free sofftware
advocates/developers are readily googable.
[2] the "open source" vs "free software" non-issue and the
"Linux" vs "GNU/Linux" wars of the 90's that haunt us to this
day.
I am now closing the comments for this post. Feel free to
move this to
the Slashdot
forum.
Comments
Posted on 05 Oct 2009