This year I will be skipping the Guadec conference. Like Ted Gould we are expecting our first baby this year around the same time that Guadec will take place.
The good news is that next year any of you attending my talk at Guadec 2011 will get to enjoy a presentation packed with baby pictures.
I wish a happy Guadec to all the Gnomers attending!
Apple and its AppStore did for software programmers what Google's AdWord did for bloggers and writers: it provided a mechanism for people to make money while doing what they love.
The AppStore takes a big weight from the shoulders of software developers by taking care of the distribution and billing system.
If I was in charge of the Windows 8 future (or MacOS for that matter), I would try to reproduce that formula on my mainstream operating system. And it seems from the leaked presentations that this is where Microsoft's head is.
The leaked mockups for the AppStore are creative, but the entire slide deck misses the fundamental point that people are scared of installing software on Windows.
Everyone is scared of installing applications on Windows either because they break the system or because you might be accidentally installing malware. In either case, the end result is countless wasted hours backing data up, reinstalling the operating sytem and all the applications.
An AppStore wont fix this.
For a Windows appstore to work, they need to guarantee that installing software wont ever break the system.
They need to produce an appliance that allows users to install and remove software in seconds, and yet, guarantee that installing and removing apps will never break the system. This is not a problem that can be solved by hiring an army of curators and people that just sit all day rejecting apps.
To solve the problem, Microsoft needs to both alter their kernel to ensure the safety of the host OS and come up with a new way of distributing applications. They need:
The Sandboxed Execution System: would prevent applications from touching the registry, installing any drivers, any hooks, any visualizers or any other deep integration features that applications typically use to integrate with the OS.
The sandboxed execution system would prevent applications from looking at the file system, except for locations that have been predetermined for sharing.
The kernel would have to enforce what files they get access to, what devices and what components they get access to. And should be set to a bare minimum.
Self Contained Applications would be required to install software from the network, or from their appstore. These applications would get absolutely no rights to modify anything outside their directory. Any extension points that they could register with the system ("open with") would have to be registered with the public extension point contract.
Public Contract for Extension Points Any extension points like "open with", or handlers for mime-types would be self contained in a manifest in the application directory.
Instead of having every app poking at the system registry and dumping their junk everywhere, applications would list all of their requirements from the operating system on the manifest and the OS would rebuild its internal data from all of the application manifests available from a user.
Limited APIs: File access APIs, display access APIs would have to be altered to give applications limited access to the host operating system, and to give them as little access to anything that most applications do not need.
The above obviously does not apply to frameworks like the .NET framework, Java or Adobe's AIR. But beyond frameworks, there are very few cases where an application really should have legitimate access to all of the features in the OS. Video games certainly do not need it, and even applications like Visual Studio would not need it.
Chris Toshok has just announced our 7th preview of Moonlight 3.0. You can get it from our preview site.
What is new in this release:
Today Infragistics announced that their NetAdvantage for ASP.NET will support Mono out of the box.
We loved working with Infragistics on this project, and I am very proud of the work that the Mono team did to get these fabulous controls working with Mono.
You can read more about Infragistics and Mono on Infragistics site where you can also try out some of their sample applications running on Linux with Mono.
From the press release:
"In recent years, our customers have indicated that their organizations are moving to mixed IT environments and require UI tools that enable them to deploy applications in either Windows or open source environments," said Dean Guida, CEO of Infragistics. "With Mono compatibility in our ASP.NET toolkit, we enable developers who have a need for open source development to create UIs that are the basis for Killer Applications and deliver the best user experiences possible."Infragistics ASP.NET toolset excels in top performance, flexibility and usability and enables developers to build rich Web applications for line of business. By providing full compatibility with the Mono runtime, Infragistics extends this functionality to the Mono community.
Coinciding with today's NetAdvantage for .NET 2010 Volume 2 availability, Infragistics highlights the ASP.NET toolkit's Mono compatibility through Sample Showcase hosted on a live Linux Server running Mono: http://mono.infragistics.com/
For us this is a very important milestone as developers building .NET applications need to complement the core framework with packaged components like the ones that Infragistics provides.
It also shows the maturity of the project, as commercial ISVs start supporting more Mono on Linux.
We have finally released MonoDevelop 2.4. You can read a high-level description of the changes or see screenshots with the details. I would go for the screenshots myself.
We made packages for OpenSUSE, SLES, Windows and MacOS X. For other Linux distributions, you should consult with your favorite package provider or you can build it yourself from sources.
Congratulations to the team. They not only improved the UI and the editing experience, but they support Gtk#, ASP.NET MVC, Silverlight, MonoMac and MonoTouch deployments from the same IDE. We have also added support for WCF references and T4 macro processing.
For the next release we have a couple of big goals in mind for MonoDevelop:
As you can see from our list of MonoDevelop Tasks there are plenty of tasks that currently have nobody assigned to. This includes even popular features like F#, IronPython, IronRuby or PHP support.
We have limited resources and a huge wish-list. If you want to help us take on any of those tasks, please join us on IRC at irc.gnome.org on channel #monodevelop, or join our mailing lists.
Perhaps my favorite feature in MonoDevelop 2.4 is the "Navigate To" functionality that we added. This new feature is hooked to Control-comma on Linux and Windows and to Command-. on Mac.
This feature lets you quickly jump to a file, a class or a method:
I used to navigate between my files by opening then from the solution explorer, and then using Control-tab or the tabs. Needless to say, the old way just felt too clumsy for a fast typist like me.
With Navigate-To, I can just hit the hotkey and then like I would in Emacs, type the filename, type or method and jump directly to the method. This is fabulous.
This will also search substrings, so you can either start typing the name of a method or you can fully qualify the method (for example: "Vector.ToString").
But it gets better, you can use abbreviations, so instead of typing "DialogViewController" you can just type "dvc":
BREAKING UPDATE Michael just told me of a cute extra feature: if your match is for a filename, if you type ":NUMBER" it will jump to the selected file to the specified line number.
The result:
One cute feature of C# 1.0 was the introduction of the Conditional attribute. When you apply the conditional attribute to a method, calls to this method are only included in the resulting code if the appropriate define is set.
For instance, consider:
[Conditional ("DEBUG")]
void Log (string format, params object [] args)
{
Console.WriteLine (String.Format (format, args));
}
Calls to Foo.Log become no-ops unless you pass the -define:DEBUG command line option to the compiler.
What is interesting about this compiler-supported feature is that that the code inside the method Log is checked for errors during compilation as any other regular method. They are first class citizens.
I am proud to introduce my first iPhone App built entirely using standard HTML5 technologies.
I felt that I had to go with HTML 5 as I did not want to write the app once for the iPhone and once for the Android. I am also open sourcing this application in its entirety, to help future generation of mobile HTML 5 developers learn from my experiences and hopefully help them write solid, cross platform mobile applications using HTML 5.
I use this app every time we go to a pub, or when we are having lunch at the Cambridge Brewing Company.
Before you check it out, my lawyer has advised me that I need to add the following disclaimer:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I give you: iCoaster.
Stay tuned for my Cheese Table app, coming soon to the iPad.
From my survey on iCoaster for iPad:
"I am currently resorting to use my four iPhones to create one giant iCoaster; this is ridiculous. Need iCoaster HD!!!!""Buying an iPad every time I want to put a drink down is expensive, though it is better than getting those little rings all over my shiny new table."
"Four coasters per iPad would be ideal"
"Please keep up the great work. Not sure what I would do without this app, would at least have a lot of ruined coffee tables."
Sadly, we do have some bugs being reported, and I can assure everyone that I am working around the clock to fix these issues. Ensuring that iCoaster is reliable is my top priority:
"If I put my drink on iCoaster, and then rotate my phone to the landscape orientation, my drink gets spilled onto my lap. Please fix this in the iPad version."
Update: We have confirmation that it works on WebOS and Blackberry as well. HTML5 FTW!
Update 2: Due to popular demand, I am launching an effort to bring iCoaster to the iPad. If you want to participate in the beta for iCoasterHD, please fill in this survey, your feedback will help me prioritize features.
Update 3: iCoaster works on walls too: http://yfrog.com/c9wlkogj.
Update 4: For those of you complaining about the missing DOCTYPE Geoff Norton has done what any honorable open source contributor would have done: he forked iCoaster and made it HTML "compliant": icoaster-fork.
Update 5: After today's brouhaha over Apple's HTML 5, Mike Shaver from Mozilla talks about the elephant in the room.
Update 6: iCoaster's HTML 5 fork has been forked to support full-screen on WebKit and Opera browsers.
Update 7: We have a Silverlight port! This enables iCoaster to run on the upcoming Windows Compact Edition Media 7 Series Phone Embedded Release Plus Pro Advanced.
Update 8: We got a Unity port of iCoaster, and showing true open source spirit, sethillgard open sourced the code.
Last week we released our first beta for the upcoming MonoTools2.
There are four main features in MonoTools 2:
Download our betas from this page. On Windows, you would install our plugin for either 2008 or 2010 and you need to install Mono 2.6.5 on the target platform (Windows, Linux or MacOS).
On Linux, run `monotools-gui-server' or `monotools-server', this will let Visual Studio connect to your machine. Then proceed from Windows.
On MacOS, double click on the "MonoTools Server" application.
Once you run those, MonoTools will automatically show you the servers on your network that you can deploy to or debug:
ASP.NET debugging with this is a joy!
This release is the first one that uses our new soft debugger. With is a more portable engine to debug that will allow our users to debug targets other than Linux/x86 for example OSX and Windows.
This is the engine that we use on MonoTouch and that we are using for Mono on Android.
Our previous debugger, a hard debugger, worked on Linux/x86 systems but was very hard to port to new platforms and to other operating systems. With our new soft debugger we can debug Mono applications running on Windows, helping developers test before moving to Linux.
When you are developing large applications or web applications, you want your turn around time from the time that you run hit Run to the site running on Linux to be as short as possible.
Cheap Shot Alert: When dealing with large web sites, we used to behave like J2EE: click run and wait for a month for your app to be loaded into the application server.
This is no longer the case. Deployments that used to take 30 seconds now take 2 seconds.
Our plugin now supports the Visual Studio 2010 new features for plugin developers.
This means you get a single .vsix package to install, no system installs, no registry messing around, no dedicated installers, none of that.
The full plugin installs in 3 seconds. And you can remove it just as easily.
Then you can just from VS's Mono menu pick "Run In Mono" and pick whether you want to run locally or remotely.
We now also support multiple profiles, so you can debug from Visual Studio your code running on Linux boxes, Mac boxes or your local system.
MonoTools was our first Windows software and we learned a lot about what Windows developers expected.
We polished hundreds of small usability problems that the community reported in our last few iterations. You can also check our release notes for the meaty details.
And we integrate directly with SuseStudio to create your ready-to-run appliances directly from Visual Studio.
