Farewell to Google's CodeSearch

It seems that part of Steve Jobs' legacy was to give Larry Page some advise: focus. This according to Steve Jobs' recently published biography.

So Larry Page took the advise seriously and decided to focus. His brand of focus is to kill projects that were distracting to their goals. One of them, -and the one I cared the most about- was CodeSearch..

What did CodeSearch do for programmers?

The CodeSearch service was a unique tool as it indexed open source code in the wild.

Codesearch is one of the most valuable tools in existence for all software developers, specifically:

  • When an API is poorly documented, you could find sample bits of code that used the API.
  • When an API error codes was poorly documented, you could find sample bits of code that handled it.
  • When an API was difficult to use (and the world is packed with those), you could find sample bits of code that used it.
  • When you quickly wanted to learn a language, you knew you could find quality code with simple searches.
  • When you wanted to find different solutions to everyday problems dealing with protocols, new specifications, evolving standards and trends. You could turn to CodeSearch.
  • When you were faced with an obscure error message, an obscure token, an obscure return value or other forms of poor coding, you would find sample bits of code that solved this problem.
  • When dealing with proprietary protocols or just poorly documented protocols, you could find how they worked in minutes.
  • When you were trying to debug yet another broken standard or yet another poorly specified standard, you knew you could turn quickly to CodeSearch to find the answers to your problems (memories of OAuth and IMAP flash in my head).
  • When learning a new programming language or trying to improve your skills on a new programming language, you could use CodeSearch to learn the idioms and the best (and worst practices).
  • When building a new version of a library, either in a new language, making a fluent version, making an open source version, building a more complete version you would just go to Codesearch to find answers to how other people did things.

It is a shame that Google is turning their back on their officially stated mission "To organize the world‘s information and make it universally accessible and useful". It is a shame that this noble goal is not as important as competing with Apple, Facebook, Microsoft, Twitter and Yelp.

Comparing Search Engines

While writing this blog entry, I fondly remembered how Codesearch helped me understand the horrible Security framework that ships with iOS. Nobody informed the Apple engineers that "Security through obscurity" was not intended for their developer documentation.

In this particular case, I was trying to understand the semantics of kSecReturnData. How to use this constant and how it interacts with the keyring system is both tricky, and poorly specified in Apple's docs. Sometimes things fail without any indication of what went wrong, other than "error". So I used CodeSearch to figure this out (along with some other 30 constants and APIs in that library that are just as poorly documented).

These are the results of looking for this value in three search engines as of this morning.

First Contender: GrepCode

GrepCode shows absolutely nothing relevant. But shows a bunch of Java packages with no context, no code snippets and if you make the mistake of drilling down, you wont find anything:

Not useful.

Second Contender: Codease

Codase is indexing 250 million lines of code, usually it takes minutes to get this page:

Maybe the server will come back up.

Third Contender: Koders

Koders is part of Black Duck, and searching for the term renders a bunch of matches. Not a single one of the results displayed actually contain a single use of the kSecReturnData constant. And not a single one of the snippets actually show the kSecReturnData constant. It is as useful as configuring your browser to use StumbleUpon as your search engine:

Not useful.

Google's CodeSearch

And this is what Codesearch shows:

The big innovation on Google's search engine is that it actually works and shows real matches for the text being searched, with a relevant snippet of the information you are looking for.

We are going to be entering the dark ages of software research in the next few months.

Is there a hacker White Knight out there?

Running a service like Codesearch is going to take a tremendous amount of resources. There are major engineering challenges involved and hosting a service like this can not be cheap. It is probably not even profitable.

Larry Page's Google has already dropped the project. We can only hope that in a few years Sergey Brin's Google or Eric Schmidt's Google will bring this service back.

Microsoft is too busy catching up to Google and wont have any spare resources to provide a Bing for code search. And if they did, they would limit the search to Win32 APIs.

Thanks!

I should thank Google for funding that project for as long as they did as well as the Google engineers that worked on it as long as they could. Over the years, it helped me fix problems in a fraction of the time and helped me understand complicated problems in minutes.

The Google engineers whose projects just got shutdown for in the name of strategy and focus are probably as sad as all of us are.

On the plus side, I get to share this rant on Google Plus with a dozen of my friends!

Posted on 29 Nov 2011 by Miguel de Icaza

Updated Documentation Site

Jeremie Laval has upgraded our Web-based documentation engine over at docs.go-mono.com. This upgrade brings a few features:

New Look: Base on Jonathan Pobst's redesign, this is what our documentation looks like now:

Better Links: Links to pages on the site will now properly open the left-side tree to the documentation you linked to. This has been an open request for about six years, and it got finally implemented.

Search: the search box on the web site uses Lucene to search the text on the server side, and shows you the matching results as you type:

Easier to Plug: MonoDoc/Web now easily supports loading documentation from alternate directories, it is no longer limited to loading the system-configured documentation.

No more frames: For years we used frames for the documentation pages. They had a poor experience and made the code uglier. They are now gone.

Powered by Mono's SGen: We have reduced the memory consumption of our web documentation by switching to Mono's Generational GC from Boehm's. The load on the server is lower, responses are faster and we scale better.

The source code changes are now on GitHub in the webdoc module.

We have also added Google Analytics support to our web site to help us determine which bits of documentation are more useful to you.

Posted on 22 Nov 2011 by Miguel de Icaza

Hiring Mono Runtime Hackers

As Mono grows on servers, mobile and desktop platforms, we are looking to hire programmers to join our Mono Runtime team.

The Mono Runtime team owns the code generator, the just-in-time and ahead-of-time compilers, the garbage collector, the threadpool and async layers in the runtime and mostly works in the C-side of the house.

If you are a developer with low-level experience with virtual machines, just in time compilers or love garbage collection, real time processing, or you read every new research paper on incremental garbage collection, hardware acceleration, register allocation and you are interested in joining our young, self-funded and profitable startup, we want to hear from you.

Send your resumes to jobs@xamarin.com

Posted on 18 Oct 2011 by Miguel de Icaza

Upcoming Mono Releases: Change in Policies

We have historically made stable releases of Mono that get branched and maintained for long periods of time. During these long periods of time, we evolve our master release for some four to five months while we do major work on the branch.

Historically, we have had done some of these large changes since we have rewritten or re-architected large parts of our JIT, or our garbage collector, or our compilers.

There were points in the project history where it took us some 9 months to release: seven months of new development followed by two months of beta testing and fixing regressions. With Mono 2.6 we tried to change this, we tried to close the release time to at most six months, and we were relatively good at doing this with 2.8 and 2.10.

We were on track to do a quick Mono 2.12 release roughly around May, but with the April bump in the road, this derailed our plans.

Since 2.10.0 was released two things happened:

  • On Master: plenty of feature work and bug fixing.
  • On our 2.10 branch: bug fixes and backporting fixes from master to 2.10

Now that things have settled at Xamarin and that we are getting Mono back into continuous integration builds we are going to release our first public beta of the upcoming Mono, it will be called Mono 2.11.1. We will keep it under QA until we are happy with the results and we will then release Mono 2.12 based on this.

But after Mono 2.12, we want to move to a new development model where we keep our master branch always in a very stable state. This means that new experimental features will be developed in branches and only landed to the master branch once they have been completed.

Our goal is to more quickly bring the features that we are developing to our users instead of having everyone wait for very long periods of time to get their new features.

New Features in Mono 2.11

These are some of the new features availalable in Mono 2.11:

  • We refactored our C# compiler to have two backends one based on Cecil, one based on Reflection.Emit. Fixing some important usability properties of our compiler.
  • Implemented C# 5 Async.
  • Our C# compiler has TypedReference support (__refvalue, __reftype and __makeref).
  • Our compiler as a service can compile classes now and has an instance API (instantiate multiple C# compiler contexts independently).
  • Added the .NET 4.5 API profile and many of the new async APIs to use with C# 5.
  • Improved our new Garbage Collector: it is faster, it is more responsive and it is more stable. It has also gained MacOS/iOS native support.
  • We made System.Json available on every profile.
  • We added Portable Class Library support.
  • We added tooling for Code Contracts
  • We added a TPL Dataflow implementation
  • We added fast ThreadLocal support
  • We brought our ASP.NET implementation to the year 2011 and it now sports a new enormously cute error page as opposed to that error page that we have which transports you mind back to 1999.
  • Mono's debugger now supports attaching to a live process (deferred support)
  • Our socket stack is faster on BSD and OSX, by using kqueue (on Linux it uses epoll already).
Posted on 14 Oct 2011 by Miguel de Icaza

WinRT and Mono

Today Joseph mentioned to me that some of our users got the impression from my previous post on WinRT that we would be implementing WinRT for Linux. We are not working on a WinRT UI stack for Linux, and do not have plans to.

WinRT is a fabulous opportunity for Mono, because Microsoft is sending a strong message: if you want your code to run in multiple scenarios (server, desktops, sandboxed environments), you want to split your UI code from your backend code.

This is great because it encourages developers to think in terms of having multiple facades for the same code base and the direction that we have been taking Mono on in the last few years.

Use the native toolkit on each platform to produce an immersive user experience, and one that leverages the native platform in the best possible way.

These are the APIs that we envision .NET developers using on each platform:

  • Windows: WinRT, Winforms, WPF (fallbacks: Gtk#, Silverlight)
  • MacOS: MonoMac (fallback: Gtk#, Silverlight)
  • Linux: Gtk#
  • Android: MonoDroid APIs
  • iOS: MonoTouch
  • Windows Phone 7: Silverlight
  • XBox360: XNA-based UI

Even if a lot of code could be reused from Moonlight, WinRT is a moving target. It is not clear that the Linux desktop, as we know it today, is keeping up with the growth of other consumer environments. I talked to Tim about this at Build.

Head-less WinRT

There are some GUI-less components of WinRT that *do* make sense to bring to Mono platforms. There is already an implementation of some bits of the headless WinRT components being done by Eric.

The above effort will enable more code sharing to take place between regular .NET 4 apps, WP7 apps, Mono apps and WinRT apps.

Posted on 26 Sep 2011 by Miguel de Icaza

WinRT demystified

Windows 8 as introduced at Build is an exciting release as it has important updates to how Microsoft envisions users will interact with their computers, to a fresh new user interface to a new programming model and a lot more.

If you build software for end-users, you should watch Jensen Harris discuss the Metro principles in Windows 8. I find myself wanting to spend time using Windows 8.

But the purpose of this post is to share what I learned at the conference specifically about WinRT and .NET.

The Basics

Microsoft is using the launch of Windows 8 as an opportunity to fix long-standing problems with Windows, bring a new user interface, and enable a safe AppStore model for Windows.

To do this, they have created a third implementation of the XAML-based UI system. Unlike WPF which was exposed only to the .NET world and Silverlight which was only exposed to the browser, this new implementation is available to C++ developers, HTML/Javascript developers and also .NET developers.

.NET developers are very familiar with P/Invoke and COM Interop. Those are two technologies that allow a .NET developer to consume an external component, for example, this is how you would use the libc "system (const char *)" API from C#:

	[DllImport ("libc")]
	void system (string command);
	[...]

	system ("ls -l /");
	

We have used P/Invoke extensively in the Mono world to create bindings to native libraries. Gtk# binds the Gtk+ API, MonoMac binds the Cocoa API, Qyoto binds the Qt API and hundred other bindings wrap other libraries that are exposed to C# as object-oriented libraries.

COM Interop allows using C or C++ APIs directly from C# by importing the COM type libraries and having the runtime provide the necessary glue. This is how Mono talked with OpenOffice (which is based on COM), or how Mono talks to VirtualBox (which has an XPCOM based API).

There are many ways of creating bindings for a native library, but doing it by hand is bound to be both tedious and error prone. So everyone has adopted some form of "contract" that states what the API is, and the binding author uses this contract to create their language binding.

WinRT

WinRT is a new set of APIs that have the following properties:

  • It implements the new Metro look.
  • Has a simple UI programming model for Windows developers (You do not need to learn Win32, what an HDC, WndProc or LPARAM is).
  • It exposes the WPF/Silverlight XAML UI model to developers.
  • The APIs are all designed to be asynchronous.
  • It is a sandboxed API, designed for creating self-contained, AppStore-ready applications. You wont get everything you want to create for example Backup Software or Hard Disk Partitioning software.
  • The API definitions is exposed in the ECMA 335 metadata format (the same one that .NET uses, you can find those as ".winmd" files).

WinRT wraps both the new UI system as well as old Win32 APIs and it happens that this implementation is based on top of COM.

WinRT Projections

What we call "bindings" Microsoft now calls "projections". Projections are the process of exposing APIs to three environments: Native (C and C++), HTML/Javascript and .NET.

  • If you author a component in C++ or a .NET language, its API will be stored in a WinMD file and you will be able to consume it from all three environments (Native, JavaScript and .NET).

    Even in C++ you are not exposed to COM. The use of COM is hidden behind the C++ projection tools. You use what looks and feels like a C++ object oriented API.

    To support the various constructs of WinRT, the underlying platform defines a basic set of types and their mappings to various environment. In particular, collection objects in WinRT are mapped to constructs that are native to each environment.

    Asynchronous APIs

    Microsoft feels that when a developer is given the choice of a synchronous and an asynchronous API, developers will choose the simplicity of a synchronous API. The result usually works fine on the developer system, but is terrible when used in the wild.

    With WinRT, Microsoft has followed a simple rule: if an API is expected to take more than 50 milliseconds to run, the API is asynchronous.

    The idea of course is to ensure that every Metro application is designed to always respond to user input and to not hang, block or provide a poor user experience.

    Async programming has historically been a cumbersome process as callbacks and state must be cascaded over dozens of places and error handling (usually poor error handling) is sprinkled across multiple layers of code.

    To simplify this process, C# and VB have been extended to support the F#-inspired await/async pattern, turning async programming into a joy. C++ got a setup that is as good as you can get with C++ lambdas and Javascript uses promises and "then ()".

    Is it .NET or Not?

    Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT.

    When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8.

    And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed.

    Now, you notice that I said "exposed" and not "gone".

    What they did was that they only exposed to the compiler a set of APIs when you target the Metro profile. So your application will not accidentally call File.Create for example. At runtime though, the CLR will load the full class library, the very one that contains File.Create, so internally, the CLR could call something like File.Create, it is just you that will have no access to it.

    This split is similar to what has been done in the past with Silverlight, where not every API was exposed, and where mscorlib was given rights that your application did not have to ensure the system safety.

    You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application and you wont be able to publish your app through Microsoft's store.

    You can still do whatever ugly hack you please on your system. It just wont be possible to publish that through the AppStore.

    Finally, the .NET team has taken this opportunity to do some spring cleaning. mscorlib.dll and System.dll have been split in various libraries and they have moved some types around.

    Creating WinRT Components

    Microsoft demoed creating new WinRT components on both C++ and .NET.

    In the .NET case, creating a WinRT component has been drastically simplified. The following is the full source code for a component that adds 2:

    
    	public sealed class AddTwo {
    		public int Add (int a, int b)
    		{
    			return a + b;
    		}
    
    		public async IAsyncOperation SubAsync (int a, int b)
    		{
    			return a - await (CountEveryBitByHand (b));
    		}
    	}
    	

    You will notice that there are no COM declarations of any kind. The only restriction is that your class must be sealed (unless you are creating a XAML UI component, in that case the restriction is lifted).

    There are also some limitations, you can not have private fields on structures, and there is not Task<T> for asynchronous APIs, instead you use the IAsyncOperation interface. Update to clarify: the no private fields rule is only limited to structs exposed to WinRT, and it does not apply to classes.

    UI Programming

    When it comes to your UI selection, you can either use HTML with CSS to style your app or you can use XAML UI.

    To make it easy for HTML apps to adhere to the Metro UI style and interaction model, Microsoft distributes Javascript and CSS files that you can consume from your project. Notice that this wont work on the public web. As soon as you use any WinRT APIs, your application is a Windows app, and wont run in a standalone web browser.

    .NET and C++ developers get to use XAML instead.

    There is clearly a gap to be filled in the story. It should be possible to use Microsoft's Razor formatting engine to style applications using HTML/CSS while using C#. Specially since they have shown the CLR running on their HTML/JS Metro engine.

    Right now HTML and CSS is limited to the Javascript use.

    In Short

    Microsoft has created a cool new UI library called WinRT and they have made it easy to consume from .NET, Javascript and C++ and if you adhere by their guidelines, they will publish the app on their appstore.

    Xamarin at BUILD

    If you are at build, come join us tonight at 6:30 at the Sheraton Park hotel, just after Meet the Experts. Come talk about Mono, Xamarin, MonoTouch, MonoDroid and MonoMac and discuss the finer points of this blog over an open bar.

    Comments

    There is a long list of comments in the moderation queue that are not directly related to WinRT, or bigger questions that are not directly related to WinRT, .NET and this post's topic, so I wont be approving those comments to keep things on focus. There are better forums to have discussions on Metro.

  • Posted on 15 Sep 2011 by Miguel de Icaza

    Xamarin and Mono at the BUILD Conference

    Continuing our tradition of getting together with Mono users at Microsoft conferences, we are going to be hosting an event at the Sheraton Hotel next to the conference on Thursday at 6:30pm (just after Ask the Experts).

    Come join us with your iOS, Android, Mac and Linux questions.

    Posted on 14 Sep 2011 by Miguel de Icaza

    MonoDevelop 2.6 is out

    Lluis just released the final version of MonoDevelop 2.6.

    This release packs a lot of new features, some of my favorite features in this release are:

    • Git support.
      • It not only provides the regular source code control commands, it adds full support for the various Git idioms not available in our Subversion addin.
      • Based on Java's JGit engine
      • Ported to C# using db4Object's sharpen tool. Which Lluis updated significantly
      • Logging and Blaming are built into the editor.
    • Mac support:
      • Our fancy MonoMac support lets you build native Cocoa applications. If you have not jumped into this Steve Jobs Love Fest, you can get started with our built-in templates and our online API documentation.
      • Native File Dialogs! We now use the operating system file dialogs, and we even used our own MonoMac bindings to get this done.
      • You can also check my Mac/iOS-specific blog for more details.
    • Unified editor for Gtk#, ASP.NET, MonoTouch and MonoDroid: we no longer have to track various forks of MonoDevelop, they have all converged into one tree.

    The above is just a taste of the new features in MonoDevelop 2.6. There are many more nominate your own!

    Congratulations to the MonoDevelop team on the great job they did!

    And I want to thank everyone that contributed code to MonoDevelop, directly or indirectly to make this happen.

    Posted on 07 Sep 2011 by Miguel de Icaza

    Learning Unix

    As I meet new Unix hackers using Linux or Mac, sometimes I am surprised at how few Unix tricks they know. It is sometimes painful to watch developers perform manual tasks on the shell.

    What follows are my recommendations on how to improve your Unix skills, with a little introduction as to why you should get each book. I have linked to each one of those books with my Amazon afiliates link, so feel free to click on those links liberally.

    Here is the list of books that programmers using Unix should read. It will only take you a couple of days to read them, but you will easily increase your productivity by a whole order of magnitude.

    The Basics

    The Unix Programming Environment by Kernighan and Pike is a must-read. Although this is a very old book and it does not cover the fancy new features in modern versions of Unix, no other book covers in such beauty the explanation of the shell quoting rules, expansion rules, shell functions and the redirection rules.

    Every single thing you do in Unix will use the above in some form or shape, and until you commit those to memory you will be a tourist, and not a resident.

    Then you will learn sed and basic awk, both tools that you will use on a daily basis once you become proficient. You do not have to ever be scared of sed or regular expressions anymore.

    Save yourself the embarrassment, and avoid posting on the comments section jwz's quote on regular expressions. You are not jwz.

    It will take you about a week of commuting by bus to read it. You do not have to finish the book, you can skip over the second part.

    Unix Boot Camp

    While Kernighan's book is basic literacy, you need to develop your muscles and you need to do this fast and not buy a book so thick and so packed with ridiculous screenshots that you will never get past page 20.

    Get UNIX for the Impatient. This book is fun, compact and is packed with goodies that will make you enjoy every minute in Unix.

    Learn Emacs

    Emacs has had a strong influence in Unix over the years. If you learn to use Emacs, you will automatically learn the hotkeys and keybindings in hundreds of applications in Unix.

    The best place to learn Emacs is to launch Emacs and then press Control-h and then t. This is the online tutorial and it will take you about two hours to complete.

    The knowledge that you will gain from Emacs will be useful for years to come. You will thank me. And you will offer to buy me a beer, which I will refuse because I rather have you buy me a freshly squeezed orange juice.

    Tooting my own horn

    Learn to use the Midnight Commander.

    The Midnight Commander blends the best of both worlds: GUI-esque file management with full access to the Unix console.

    The Midnight Commander is a console application that shows 2 panels listing two different directories side-by-side and provides a command line that is fed directly to the Unix shell.

    The basics are simple: use the arrow keys to move around, Control-S to do incremental searches over filenames, Control-t to tag or untag files and the F keys to perform copy, move or delete operations. Copy and Move default to copy to the other panel (which you can conveniently switch to by pressing the tab key).

    There is no better way of keeping your file system organized than using my file manager.

    Becoming a Power User

    If you can not quench your thirst for knowledge there is one last book that I will recommend. This is the atomic bomb of Unix knowledge.

    Unix Power Tools is a compilation of tricks by some of the best Unix users that got compiled into a huge volume. This is a book of individual tricks, each about a page long, ideal to keep either on your bedside or in the restoom to pick a new trick every day.

    Mavis Beacon

    At this point you might be thinking "I am awesome", "the world is my oyster" and "Avatar 3D was not such a bad movie".

    But unless you touch-type, you are neither awesome, nor you are in a position to judge the qualities of the world as an oyster or any James Cameron movies.

    You have to face the fact that not only you are a slow typist, you do look a little bit ridiculous. You are typing with two maybe three fingers on each hand and you move your head like a chicken as you alternate looking at your keyboard and looking at your screen.

    Do humanity a favor and learn to touch type.

    You can learn to touch type in about three weeks if you spend some two to three hours per day using Mavis Beacon Teaches Typing.

    Mavis Beacon costs seventeen dollars ($17). Those seventeen dollars and the sixty three hours you will spend using it will do more to advance your carreer than the same sixty three hours spend reading editorials on Hacker News.

    Classics

    All of the books I list here have stood the test of time. They were written at a time when books were designed to last a lifetime.

    Unlike most modern computer books, all of these were a pleasure to read.

    Posted on 06 Sep 2011 by Miguel de Icaza

    And we are back: Mono 2.10.3

    This is Xamarin's first official Mono release.

    This is a major bug fix release that addresses many of the problems that were reported since our last release back on April 25th.

    The detailed release notes have all the details, but the highlights of this release include:

    • MacOS X Lion is supported: both the Mono runtime and Gtk+ as shipped with Mono have been updated to run properly on Lion. This solves the known problems that users had running MonoDevelop on MacOS X.
    • Vastly improved WCF stack
    • Many bug fixes to our precise garbage collector.

    Major features continue to be developed in the main branch. Currently we are just waiting for the C# 5.0 Asynchronous Language support to be completed to release that version.

    Mono 2.10.3 also serves as the foundation for the upcoming Mono for Android 1.0.3 and MonoTouch 4.1.

    You can get it from Mono's Download Site.

    Currently we offer source code, Windows and MacOS packages. We will publish Linux packages as soon as we are done mirroring the contents of the old site that contains the Linux repositories.

    On C# 5.0

    Our new compiler, as you might know, has been rewritten to support two backends: a System.Reflection.Emit backend, and the brilliant IKVM.Reflection backend.

    The C# 5.0 support as found on master contains the C# 5.0 support as shipped by Microsoft on their latest public release.

    To try it out, use -langversion:future when invoking the compiler. You can try some of our samples in mono/mcs/tests/test-async*.cs

    Posted on 04 Aug 2011 by Miguel de Icaza

    MonoDevelop on Lion

    We here at Xamarin are as excited as you are about the release of Lion. But unfortunately we're not quite ready to support you on Lion yet, and MonoDevelop doesn't work quite right. We're working around the clock to make MonoDevelop work perfectly on Lion, and we'll let you know as soon as it's ready.

    Update on July 29th: We have most of the fixes in place for Mono and will issue a build for testing on the Alpha channel soon.

    Posted on 20 Jul 2011 by Miguel de Icaza

    Novell/Xamarin Partnership around Mono

    I have great news to share with the Mono community.

    Today together with SUSE, an Attachmate Business Unit, we announced:

    • Xamarin will be providing the support for all of the existing MonoTouch, Mono for Android and Mono for Visual Studio customers.
    • Existing and future SUSE customers that use the Mono Enterprise products on their SLES and SLED systems will continue to receive great support backed by the engineering team at Xamarin.
    • Xamarin obtained a perpetual license to all the intellectual property of Mono, MonoTouch, Mono for Android, Mono for Visual Studio and will continue updating and selling those products.
    • Starting today, developers will be able to purchase MonoTouch and Mono for Android from the Xamarin store. Existing customers will be able to purchase upgrades.
    • Xamarin will be taking over the stewardship of the Mono open source community project. This includes the larger Mono ecosystem of applications that you are familiar with including MonoDevelop and the other Mono-centric in the Mono Organization at GitHub.

    We are a young company, but we are completely dedicated to these mobile products and we can not wait to bring smiles to every one of our customers.

    Roadmaps

    Our immediate plans for both MonoTouch and Mono for Android is to make sure that your critical and major bugs are fixed. We have been listening to the needs of the community and we are working to improve these products to meet your needs. You can expect updates to the products in the next week.

    In the past couple of months, we have met with some of our users and we have learned a lot about what you wanted. We incorporated your feature requests into our products roadmaps for both the MonoTouch and the Mono for Android products.

    Another thing we learned is that many companies need to have a priority support offering for this class of products, so we have introduced this. It can be either be purchased when you first order MonoTouch or Mono for Android, or you get an upgrade to get the priority support.

    Next Steps

    Our goals are to delight software developers by giving them the most enjoyable environment, languages and tools to build mobile applications.

    We are thankful to everyone that provided feedback to us in our online form that we published a month ago. Please keep your feedback coming, you can reach us at contact@xamarin.com. We are reading every email that you send us and you can use my new miguel at new company dot com email address to reach me.

    We will be at the Monospace conference this weekend at the Microsoft NERD Center, hope to see you there!

    Remember to purchase early and often so we have the resources to bring you the best developer tools on the planet.

    Posted on 18 Jul 2011 by Miguel de Icaza

    Update on Mono

    I have a posted an update on Mono and the upcoming release of Mono 2.12.

    Posted on 06 Jul 2011 by Miguel de Icaza

    Mono Consultants

    We are getting flooded with paid support requests for Mono. Developers looking for us to fix bugs in Mono, to do some custom work, to port applications, libraries and adjust Mono for some specific needs.

    But we are trying to be a product company as opposed to a support company.

    We still want to help the Mono user community, and with all of the Mono talent out there, at least we can use this opportunity to get both groups in touch: the users that want custom engineering done, with the talented list of hackers.

    If you are a consultant available to do custom engineering and support for customers, we would love to put you in touch with people that need the custom engineering done. Email us at contact@xamarin.com, in the subject line, specify that you are available for custom engineering, and in the body of the message list both your Mono skills (C# or C coding) and your availability to engage on those gigs.

    We will then get you in touch with users that needs the work done.

    Posted on 30 Jun 2011 by Miguel de Icaza

    Xamarin Joy Factory

    Setting up a new company consumes a lot of time. Specially as we are developing as fast as we can not one, but two products: .NET for iPhone and .NET for Android.

    Structurally, we are better off than we were the first time that we built these products. We have more developers working on each product than we did the first time around, so progress is faster. But we also had to swap the developers around: those that wrote Foo, can not work on Foo again. This is just one of the things that we have to do to ensure a clean room implementation.

    Our vision is to create happy developers. We did that in the past by bringing the C# language, garbage collection, LINQ, strongly typed APIs, Parallel FX, intellisense and inline documentation to iPhone and Android developers. And by making it possible for the world's 6 million .NET developers to reuse their skills on the most popular mobile platforms.

    This time around, we are doing even more. We are addressing many of the frustrations that developers had with the old products and making sure that those frustrations go away.

    Nat and myself complement each other very well here. This means that there are a lot of new things that will be present in our offering that we never did in the past.

    There is a new level of polish that those familiar with Nat's previous products had (SUSE Studio, NLD/SLED, Ximian Desktop). Everyone at Xamarin can feel that Nat is hard at work when they noticed that one of the first things Nat did was to engage six design firms and an army of technical writers to ensure that our products go from "Nice" to "Amazing". And that was on his second week as CEO, a lot has happened since.

    I do not want to give away everything that we are doing, it would ruin the surprise, but we are here to deliver joy to programmers everywhere.

    If you are interested in working with us, and making mobile development and .NET development a joy that everyone can enjoy, check out our Jobs page

    Where we are now

    It gives me great pleasure to say that we have elevated the discourse on the iPhone simulator and my Chicken-powered TweetStation is up and running with the new iOS product. The picture on the left is TweetStation powered by MonoTouch, the picture on the right is TweetStation powered by Xamarin's iPhone product:


    TweetStation on MonoTouch

    TweetStation on Xamarin iOS

    Update: TweetStation now starts up on Device! We have the static compiler working!

    We also have the delicious iOS5 APIs exposed as strongly-typed and intellisense-friendly C#. We are now updating the APIs from Beta1 to Beta2, which should be completed today or tomorrow.

    Our Android efforts are moving fast. Only this morning we got Layouts to render on the device. This is a lot of work, as it gets Dalvik to start Mono, and initializes our entire bridge and exercises the C# and Java bridge. In addition, we have identified and fixed a serious problem in the distributed garbage collector.

    We also have a number of surprises for everyone in MonoDevelop, we believe that you guys are going to love the new features for iPhone and Android development.

    There is still a lot of polish left to do. We are working as hard as we can to have Preview releases in your hands, but we feel confident that we will have a great product for sale by the end of the summer. We hope you will all max out your credit cards buying it.

    Posted on 28 Jun 2011 by Miguel de Icaza
    « Newer entries | Older entries »
    This is a personal web page. Things said here do not represent the position of my employer.