I just committed my first draft of documentation for Manos’s middleware layer. Its a pretty quick and easy read and I’d appreciate any questions, comments, death threats or concerns that you may have. The doc is written in markdown so you can read is pretty easily on github here:

http://github.com/jacksonh/manos/blob/master/docs/middleware.md

Things still need to be fleshed out, especially with some examples of what methods can be called from inside the middleware hooks, but this gives you a basic idea.

The Gist

Middleware gives your application an easy way to “do something” for every request/response transaction that goes into an application.

You get these methods to register middleware:

RegisterMiddleware (IManosMiddleware mw);
RegisterMiddleware (string name, IManosMiddleware mw);

RegisterMiddlewareBefore (IManosMiddleware mw);
RegisterMiddlewareBefore (string name, IManosMiddleware mw);
RegisterMiddlewareAfter (IManosMiddleware mw);
RegisterMiddlewareAfter (string name, IManosMiddleware mw);

ReplaceMiddleware (string name, IManosMiddleware mw);

And your middleware can override any of these methods:

ProcessRequest (IManosContext)
PreProcessAction (IManosContext, IManosTarget)
PostProcessAction (IManosContext)
ProcessError (IManosContext)

From those methods you can easily re-write parts of the request, redirect to another URL, abort the transaction, manipulate the generated html or just log something to disk. Really the sky is the limit.

Most developers will never have to write their own middleware but a lot of really important plumbing pieces of a web framework can be written using middleware. Things such as the auth system, rate limiting, url rewriting, and red/black testing are important components of a web application and will make use of the middleware layer. So its important that I get this part right.

Some cute C# tricks

Over the last couple of days, I did some extensive refactoring in MDB's backend and completely rewrote it.

The new backend now lives out-of-process and is written in C++ and there's a managed C# counterpart which talks to the C++ classes over a wire protocol.

One big mistake I made in MDB's old backend was abstracting things in the wrong way. The old backend was basically just wrapping C functions like ptrace() or waitpid and making them accessible from managed code. The big problem with this was that these functions have very specific calling semantics which needed to be replicated on the managed side to use them correctly.

Take ptrace() as an example - this function has to be called from one special thread and from this thread only. Or waitpid() as another example - interrupting it isn't trivial and there is no easy way of waiting for both the child process and user input. Because of this, more and more hacks where added to the managed part of MDB - hacks which were designed to work around specific calling semantics of these system calls. All this stuff made porting MDB very difficult. For instance, when you want to port it to Windows, WaitForDebugEvent must be called from the thread that created the child process - so the "wait event loop" has to be completely different than on Linux.

Primary goal of the new backend is wrapping functionality, not functions ... like "step one instruction, give me an event when done" - it doesn't matter how exactly we wait for the target to stop again, all we're interested in is getting that event.

This doesn't imply rewriting all of MDB in C++, but doing a little bit more in C++ than was previously done in C will make the C# code so much cleaner and so much more portable. As an added benefit, all the managed code will be fully debuggable by a managed debugger - something that was impossible in the old MDB :-)

The backend refactoring is now done, and we can do multi-thread single-stepping, so this afternoon, I cross-compiled Mono (trunk) from Linux to Windows, enabled mdb support in the runtime and started to play around with it ...

MuseGames.com & Unity Technologies are teaming up for a new bi-monthly Unity “Prefab” based contest called The Fabricator Contest! The contest will be a regular event that will challenge members of the community to show their stuff by creating prefabs based on specific themes, and of course because it’s a contest that means winning entries [...]

Add contact profiles to gmail

Last night I added support to Manos to parallelize HTTP transactions.

All I did was change this code:

foreach (HttpTransaction transaction in transactions) {
    transaction.Run ();
}

To this:

transactions.AsParallel ().ForAll (t => t.Run ());

I got a chance to run apache-bench on both versions today and here are the results:

foreach loop

Concurrency Level:      200
Time taken for tests:   4.208 seconds
Complete requests:      10000
Requests per second:    2376.40 [#/sec] (mean)
Time per request:       84.161 [ms] (mean)
Time per request:       0.421 [ms] (mean, across all concurrent requests)
Transfer rate:          187.98 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   15 200.8      0    3003
Processing:    28   68  21.8     61     819
Waiting:       28   68  21.8     61     818
Total:         30   83 202.9     61    3084

Percentage of the requests served within a certain time (ms)
  50%     61
  66%     67
  75%     75
  80%     79
  90%     87
  95%     96
  98%    205
  99%    215
 100%   3084 (longest request)

With AsParallel

Concurrency Level:      200
Time taken for tests:   2.791 seconds
Complete requests:      10000
Requests per second:    3582.49 [#/sec] (mean)
Time per request:       55.827 [ms] (mean)
Time per request:       0.279 [ms] (mean, across all concurrent requests)
Transfer rate:          283.38 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   4.1      0      34
Processing:    21   37   7.2     36     240
Waiting:       10   37   7.2     36     240
Total:         21   38   8.4     36     240

Percentage of the requests served within a certain time (ms)
  50%     36
  66%     38
  75%     39
  80%     40
  90%     44
  95%     50
  98%     63
  99%     73
 100%    240 (longest request)

Tomorrow evening (Wednesday, September 1), I will be speaking on “Mono, MonoTouch, and MonoDroid” at the North Dallas .NET User Group at 6p.  I hope the title speaks for itself, but you can find event details and a map, as well as RSVP on Eventbrite.

Five years ago October, NDDNUG was the first .NET user group to give me the opportunity to present.  I’d like to imagine that my presentation skills have improved substantially since then.  More realistically, you should come anyways, simply because the evening will be action-packed with coverage of the many exciting things the Mono team are working on these days.

I'm going to go back to the basics today and describe how Plastic handles renames during merge with two different cases:

Rename a file, modify it in parallel in a second branch and check how the two branches are correctly merged back, which means: the result file is renamed and it contains the changes from the two branches.

Divergent merging: what if we rename a file in one branch and also in a second one to a different name and we merge back?

As simple as it might sound, renaming during merging is one of the points where most of the SCMs break... And the good news is that Plastic simply excels there.

Handling renames during merge

The scenario is very simple:

Create branch task003, rename and modify file agent.cs there

Create branch task004 (in parallel with task003) and modify agent.cs there

Merge back both branches to main
The expected result is: getting agent.cs renamed and including the changes from the two branches.

This is what Plastic does, but systems like Subversion dramatically fail: SVN will create two files as result and won't directly merge the changes...

The following screencast shows Plastic in action dealing with this example:

Divergent renaming

The scenario is the following:

Rename a file on a branch

Rename the file to a different name, in parallel, on a different branch

Merge the branches together

Plastic is able to detect the double rename and come up with a solution: choose one of the names or propose a new one. But Plastic won't end up creating two files and leaving you alone to handle further merging (changes on the files) yourself.

Interestingly this is exactly what Mercurial does: it will create two files with the two names and warn you to solve the situation somehow.



Check it in action here:

One of the key features in the new Plastic SCM 3.0 is the Windows Shell Extension integration.

It's a feature that users coming from SVN or CVS were missing (the great "tortoise" family of tools, you know) so we finally cached up here, did our homework and released a very neat integration.



The really cool thing about the ShellExt is that you can use the entire Plastic GUI from it: the branch explorer, running merges and diff, the changeset browser, code reviews... everything is just there... which ends up creating a very tightly integrated and neat interface. You can access all the replication functionalities too, of course.

Here's a short screencast (remember we've a YouTube channel) here showing most of the views popping up and so on.


The ShellExt shares most of the code with the Windows GUI, which is great for maintenance. We had to do a good refactor of some pieces (not that big at the end :P) in order to be able to display "views" on standalone windows, and then also some threading considerations to integrate with Explorer, but the result, IMHO, is really good.

Enjoy!

Last Tuesday, we presented Mono Accessibility 2.1. We worked really hard on this release. Our main goals were, among other things, to improve our UI Automation Client API implementation, polish the interaction with at-spi2, better Moonlight accessibility and to handle custom and client-side providers. The great work made by all the contributors was the reason [...]

I recently upgraded my RSS reader from the older version I was still using to the current version. That turned out to be a mistake. The new version was even more broken than the old version, so I decided it was time to switch. I remembered RSSOwl from several years ago when I tested it on IKVM (it uses the Eclipse Standard Widget Toolkit, so like Eclipse it was a good test app back when AWT support was completely useless).

I downloaded the most recent version and played with it and it appeared to suit my needs. Of course, after I decided that I was going to start using it, I wanted to run it on IKVM and not in dynamic mode, but compiled with ikvmc. Fortunately, RSSOwl uses OSGi in much the same way as Eclipse, so I was able to reuse the work I did to get Eclipse to compile with ikvmc.

To play along at home, follow these instructions (on Windows):

• Download rssowl-2.0.5.win32.zip, ikvmbin-0.44.0.5.zip and rssowl-clr.zip and put them all in the same directory.
• Open a Command Prompt and go to the directory where you downloaded the zip files.
• Run these commands:
  unzip rssowl-2.0.5.win32.zip
cd rssowl
unzip ..\ikvmbin-0.44.0.5.zip
unzip ..\rssowl-clr.zip
mk
• Start RSSOwl by running rssowl-clr.exe

As most of you probably know, Mark Probst (schani) has been hard at work in the past year on implementing a new, generational, garbage collector for Mono (called sgen). The hopes were high for this work as the currently default garbage collector in Mono, boehm, is not really up to the task and causes major slowdowns under certain workloads. The hopes were high, but Mark managed to meet and exceed them :) The test page can be found here. Below are results of a simple test, to run several thousands of requests against a small ASP.NET page, served by XSP. The first run is a "warm-up" one - that is, at the very first request gmcs is invoked in order to compile the .aspx into an assembly. The second request is "pure", without the compilation toll. The test consisted of running the following command line on the client machine (2.2GHz dual core):

ab2 -n 50000 -c 20 -k http://192.168.1.2/hi.aspx

The server was a quad 2.4GHz Xeon machine with hyper-threading on (giving 4 real and 4 "virtual" cores). The tests were conducted with Mono from the master branch. Both machines were running 64-bit Linux (OpenSuSE 11.3). The first set of results is for the boehm gc:

# ab2 -n 50000 -c 20 -k http://192.168.1.2:8080/hi.aspx
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.2 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Mono.WebServer.XSP/2.7.0.0
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hi.aspx
Document Length:        699 bytes

Concurrency Level:      20
Time taken for tests:   34.739 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49520
Total transferred:      51478420 bytes
HTML transferred:       34950000 bytes
Requests per second:    1439.30 [#/sec] (mean)
Time per request:       13.896 [ms] (mean)
Time per request:       0.695 [ms] (mean, across all concurrent requests)
Transfer rate:          1447.13 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.0      0      17
Processing:     4   14  26.1     10    1220
Waiting:        4   14  26.1     10    1220
Total:          4   14  26.2     10    1224

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     12
  80%     13
  90%     22
  95%     38
  98%     52
  99%     57
 100%   1224 (longest request)
# ab2 -n 50000 -c 20 -k http://192.168.1.2:8080/hi.aspx
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.2 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Mono.WebServer.XSP/2.7.0.0
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hi.aspx
Document Length:        699 bytes

Concurrency Level:      20
Time taken for tests:   55.495 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49518
Total transferred:      51478320 bytes
HTML transferred:       34950000 bytes
Requests per second:    900.98 [#/sec] (mean)
Time per request:       22.198 [ms] (mean)
Time per request:       1.110 [ms] (mean, across all concurrent requests)
Transfer rate:          905.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0  13.7      0    3053
Processing:     2   22  38.9     11    1535
Waiting:        2   22  38.7     11    1535
Total:          2   22  41.3     11    3071

Percentage of the requests served within a certain time (ms)
  50%     11
  66%     12
  75%     12
  80%     13
  90%     65
  95%     92
  98%    115
  99%    241
 100%   3071 (longest request)

The second set is for the sgen gc:

# ab2 -n 50000 -c 20 -k http://192.168.1.2:8080/hi.aspx
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.2 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Mono.WebServer.XSP/2.7.0.0
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hi.aspx
Document Length:        699 bytes

Concurrency Level:      20
Time taken for tests:   28.736 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49520
Total transferred:      51478420 bytes
HTML transferred:       34950000 bytes
Requests per second:    1739.99 [#/sec] (mean)
Time per request:       11.494 [ms] (mean)
Time per request:       0.575 [ms] (mean, across all concurrent requests)
Transfer rate:          1749.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.0      0      29
Processing:     4   11  27.6     10    1383
Waiting:        4   11  27.6     10    1383
Total:          4   11  27.8     10    1387

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     12
  80%     12
  90%     14
  95%     15
  98%     18
  99%     23
 100%   1387 (longest request)
# ab2 -n 50000 -c 20 -k http://192.168.1.2:8080/hi.aspx
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.2 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Mono.WebServer.XSP/2.7.0.0
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hi.aspx
Document Length:        699 bytes

Concurrency Level:      20
Time taken for tests:   33.681 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49512
Total transferred:      51478045 bytes
HTML transferred:       34950000 bytes
Requests per second:    1484.52 [#/sec] (mean)
Time per request:       13.472 [ms] (mean)
Time per request:       0.674 [ms] (mean, across all concurrent requests)
Transfer rate:          1492.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0  23.6      0    3089
Processing:     2   13  24.2     10     674
Waiting:        2   13  24.2     10     674
Total:          2   13  33.8     10    3099

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     12
  80%     13
  90%     14
  95%     16
  98%     21
  99%    172
 100%   3099 (longest request)

The points of interest are:

• Requests per second. Both tests show that the second run is slower, which is to be expected since there are more objects to be collected. Boehm has much more work here since it has to perform a lot of big collections, while sgen wins by having two kinds of collections - major and minor. Sgen wins hands down here.
• Percentage of requests run in given time. Boehm shows a pretty big difference in times here, while sgen is more uniform and, once again, faster.
• Throughput. And for the third time, boehm loses here considerably - sgen by taking advantage of its minor collection feature spends less time freeing memory and therefore gives better transfer.
• Memory usage. This is not shown above, but sgen left xsp with more memory at the end of the test run than boehm (~900mb vs ~800mb), but this is expected to change as sgen development progresses.

One thing to note is that you need to run mono with the -O=-aot option when testing sgen (at least on x86-64) since AOT somehow causes it to crash XSP. So, two conclusions here. Sgen is going to make Mono much, much faster and, as Gonzalo> put it (hitting the bull's eye): <gonzalo> YOU ROCK :D (in response to Schani's question if Gonzalo was kidding regarding the performance improvement)

While the 0.44 release candidates have been baking, I've been working on 0.45. There are some interesting changes related to resource handling and stub classes.

Resources

 Previously, if you looked at the URL returned by ClassLoader.getResource() for an ikvmc compiled assembly you see something ugly like this:

 ikvmres://IKVM.OpenJDK.Jdbc,%20Version=0.44.0.5,%20Culture=neutral,%20PublicKeyToken=13235d27fcbfff58/META-INF/services/java.sql.Driver

Now with 0.45, you see:

jar:file:/C:/.virtual-ikvm-home/assembly/IKVM.OpenJDK.Jdbc__0.45.3887.0__13235d27fcbfff58/resources/resources.jar!/META-INF/services/java.sql.Driver

This is also a bit strange, because C:\.virtual-ikvm-home doesn't actually exist, but it is the IKVM Virtual File System directory that was introduced with the switch to OpenJDK, to facilitate the fact that OpenJDK likes to load lots of files from the installation directory.

Starting with 0.45, the virtual file system is also used to load resources and stub classes. When you compile your jar with ikvmc, the resources in the jar will be copied into a new jar (usually with the same name) and that jar will be attached as a managed resource to the target assembly. This resource is projected into VFS and the normal Java resource loading mechanism is (more or less) used to load resources from the jar.

This has two main advantages. The first is that this makes it more likely that Java code that makes various assumptions about being being able to explicitly open a resource jar, will work. The second is that this method of storing resources, usually results in smaller assemblies.

Another benefit of this change is that I finally fixed the issue with ikvmc skipping resources due to name clashes. Previously there was only a single resource namespace per assembly, but now an assembly can contain multiple resource jars.

Stub Classes

Some Java code requires .class files for system classes. This is usually because they want to do dynamic code generation and Java's reflection isn't really good enough for that. For a long time IKVM has supported this by dynamically creating the .class files (in a runtime equivalent of ikvmstub) whenever code tried to load a resource that ended with .class and a corresponding type was found. This used the same ikvmres protocol mechanism as normal resources. With this snapshot, the stub classes have also moved to VFS. They are still generated on demand, but they are now accessible via the Java file IO APIs. This means that the sun.boot.class.path property can now point to VFS and that Java code, like javac, that depends on sun.boot.class.path will now work.

You can now build a working javac.exe like this:

ikvmc -main:com.sun.tools.javac.Main -out:javac.exe -r:IKVM.OpenJDK.Tools.dll

The resulting javac.exe will be very small (4KB), because all the code is in IKVM.OpenJDK.Tools.dll (the equivalent of tools.jar).

Changes:

• Fixed java.util.zip.Inflater to throw exception for corrupt zip files (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36560).
• Added the ability to nest ikvmc response files and added error handling to response file reading.
• Made most ikvmc warnings local to the target that is being compiled (in multi target mode), to allow warnings to be suppressed (or turned into an error) for a specific target.
• Added -writeSuppressWarningsFile: ikvmc option.
• Added support for comment lines in ikvmc response files.
• Volker implemented Window.setMinimumSize().
• Massive change to change resource handling. Java resources are now stored in jars that are stored as managed .NET resources. The jars are projected into VFS and the assembly class loaders know how to load resources from these jars.
• Volker added support for "My Computer" folder.
• Volker fixed a regression in Toolkit.createImage(ImageProducer).
• Fixed build to work when Mono isn't installed.
• Stub classes are now projected into VFS.
• Stub classes (as resources) are no longer generated if a resource with that name already exists in the assembly.
• System property "sun.boot.class.path" now points to stub classes in VFS.
• Removed the requirement to have peverify and ilasm in the PATH. They are now located automatically and if they are not found, the corresponding build steps are skipped.
• Separated managed and native build steps and made managed the default target. This allows doing a build with "nant" with just nant and JDK 1.6 in the PATH.
• Changed default build target to automatically generate a CommonAssemblyInfo.cs with todays build number.
• Fixed java.lang.ref.Reference to not store a strong reference to java.lang.Class objects, if class GC is enabled. Note that class GC is only available on .NET 4.0 and when IKVM is specifically built for .NET 4.0.

Binaries available here: ikvmbin-0.45.3887.zip

After restoring a bunch of stuff from a backup today I found this incredibly helpful:

git diff --summary | grep --color 'mode change 100755 => 100644' |  \
                  cut -d' ' -f7- | xargs -d'\n' chmod +x
git diff --summary | grep --color 'mode change 100644 => 100755' |  \
                  cut -d' ' -f7- | xargs -d'\n' chmod -x

Taken from: http://stackoverflow.com/questions/1580596/how-do-i-make-git-ignore-mode-changes-chmod

Hi all!

It all started when Josh Cooley told me about this post:  http://devlicio.us/blogs/tuna_toksoz/archive/2010/07/27/codebetter-devlicio-us-msdn-ultimate-giveaways.aspx

I sent a mail talking about Npgsql and how a VS.Net would help us to add design time support and today I received a very nice mail saying that Npgsql was choosen to receive an MSDN subscription!

I'd like to thank the people who contributed to make this possible: Codebetter Crew: Ben Hall, Ward Bell, James Kovacs. Devlicious Crew: Hadi Hariri, Christopher Bennage, Tim Barcz, Rob Reynolds.  Lostechies Crew: Eric Hexter, Jimmy Bogard, Keith Dahlby and Josh Cooley for heads up!

Thank you very much! Your support to OSS projects is awesome!

And stay tuned for better support of Npgsql inside VS.Net :)

Two more bug fixes and this will hopefully be the final release candidate.

Changes:

• Changed version to 0.44.0.5
• Don't seal @Internal classes.
• Fixed bug #3046925.

Binary available here: ikvmbin-0.44.0.5.zip

Sources: ikvmsrc-0.44.0.5.zip, openjdk6-b18-stripped.zip

The sources zip no longer contains any binaries.

Unity 3 is looking to be our biggest release to date — bringing with it source-level debugging, deferred rendering, best-in-class lightmapping and occlusion culling, and a unified editor. As we are getting close to the end of our pre-order window, I decided to asks members of the dev team what features they are most excited [...]

As a follow-up to my Getting Started with Unity blog post, I wanted to bring your attention to three recent tutorial sites: First up is design3, a subscription based site created by Noesis Interactive, who create professional courseware for Universities. They have over 200 Unity specific videos and more on the way. Whether an educator, a [...]

At the end of the day I used to leave myself post-it notes so I’d know where to start the next day. Here’s my new system:

internal XamlContext ()
{
     Resources = new List ();

     1. CASCADE XMLNS MAPPINGS
     2. STRUCT -> INT TYPE MAPPING
}

Incase you haven't heard of MonoDroid before, it is a future product to be released by Novell which allows you to use C# and the .Net framework to develop applications on an Android device. If this sounds something you're interested in, then make sure...(read more)

Well, if you’ve been waiting for some kind of stable release of OpenVP for Banshee, you will love this. OpenVP is part of the Banshee Community Extensions 1.7.4 release! Go get it, and be sure to file any bugs you come across.

We’re having a great Summer: We passed the 200,000 user mark, we passed the 30 million webplayer mark, we won the Develop Grand Prix, and we’re getting ready to ship Unity 3. To celebrate all this, we decided to throw a party.  For our blog readers who happen to find themselves in the SF bay [...]