Give me give me

"Give me give me give me account after midnight..."

Due to the overwhelming interest we have opened registration to all users! Hurry up! come get it while it's hot. First come, first served. Come and get your very own bill.gates, sergey.brin, and britney.spears accounts!

Go!



P.S.: New tutorial is up, watch the post-login screen for updates.

What makes us so special

The Pain

The Web 2.0 changed the way we use the internet. As web developers, it also changed the way we build rich internet applications: they are no longer server-side logic, where the browser only renders static content that’s composed at the server, but instead a mix of two kinds of applications, client and server. The reasons are obvious: the more the rich clients do - the better. The responsiveness of the interface will improve, and the load on the server will be reduced. The server does most of the business logic (except for the obvious task of serving the application to the client with all the required resources), and the client does the UI part, plus some non-critical logic such as form validation etc. Of course, there are a lot of other reasons, I just noted a few.

I would like to focus on the way that this transition to client-server applications changed the way that the two parts of the application communicate. First and foremost, the two parts are written in different languages (there are exceptions). Additionally, we now have to deal with state maintenance, AJAX calls to services at the server, data serialization using JSON or XML (sometimes both ways), deal with exceptions, security, optimizations etc. Finally, the two applications are executed in different, detached environments: we can’t debug them as a whole. When one side fails, we have to work very hard to let the other side know. For the past couple of years, these issues have been a pain we’ve all got used to. So guess what: we change that!

Code technology

When we write an application, we start by writing some code, and then compile it. If all goes well, we can even run it. Under the covers, a lot has happened – the code was parsed, checked, compiled, linked and finally was written to an executable file of some sort. Here at CodeRun, we add another stage, which we call the precompiler. As you expect, this stage runs just before the compiler does. Its primary task is to take the code that you wrote, and look for metadata attributes that tell it what to do. I’ll elaborate about two metadata attributes in a second, but there are a lot more than just two. The code is then re-written to another file, which is then compiled. Unless there are errors, it will stay quiet and you won’t be bothered. If there are errors, it will pinpoint the code that caused the error and suggest what you should do.

One language to rule them all, and then some code examples

We have discussed how web applications are usually written in two different languages, one for the server and one for the client. The first thing that we at CodeRun did was to change that. Everything is written in C#, and everything that can be written in C# can be translated to JavaScript. But you don’t want everything to be converted into JavaScript, and rightfully so. Some code should stay at the server side (for example, database access with secret connection strings), and some should be ‘pushed’ to the client (for example, visual controls and UI logic). For example, take the following code:

[RunAtClient]
public class Sample
{
 void ShowTime()
 {
  var time = DateTime.Now;
  MessageBox.Show(“The time is “+time);
 }
}

When ShowTime() is called, it takes the time and opens a message box that displays it. Notice the [RunAtClient] attribute above the class declaration: this is what instructs the precompiler to generate JavaScript code for that class. If there are calls to methods or properties that were not converted to JS, a synchronous AJAX call will be made to the server and the code won’t behave any differently than you might expect. Now, have a look at this code:

[Remotable]
public class MyServerClass
{
 public static DateTime GetTimeAtServer()
 {
  return DateTime.Now;
 }
}

This code runs at the server. It is not converted to JS, but can be invoked from the client. We will now change our ShowTime() method to call that method instead of DateTime.Now:

[RunAtClient]
public class Sample
{
 void ShowTime()
 {
  var time = MyServerClass.GetTimeAtServer();
  MessageBox.Show(“The time is “+time);
 }
}

This method now displays the time at the server, rather than the time at the client.

RunAtClient and Remotable metadata attributes (WARNING: Technical mumbo-jumbo ahead)

Our example above used standard c# code, with two attributes that are defined in the CodeRun.Extensions namespace. The JS code that is generated under the covers is interesting: for [RunAtClient] classes, the entire class, along with its methods and properties and their implementations are translated to JS. For [Remotable] classes, a proxy class is generated, which is effectively a skeleton class, where all the method implementations are replaced with an AJAX call to the server. The C# code at the server remains the same for both classes. Here are a few important things to know about the two metadata attributes

• They are inherited. If a class is derived from Sample in the case above, it will also be considered to have a RunAtClient attribute.


• They may be applied to methods as well. Here are two common scenarios:
  
  
  
  • Opt-out, for example, [Remotable(false)] on remotable classes. This may be used on [Remotable] classes that contain sensitive code that should not be executed by the client.
  
  
  • [Remotable] classes that wish to delegate some non-sensitive code to the client
  
  
• Mixing client and server code: You may create a class that contains both Remotable and RunAtClient methods, but remember that the calls may only be made from the client to the server. Calls in the other directions would fail, and would probably cause a compilation error.


• [Remotable] classes may not be instantiated at the client. This goes for all non-primitives that are passed as parameters to server methods.

Also note that DateTime exists both at the client and at the server. This is because we re-implemented the standard DateTime class in JS. The same goes for String, Int32, Boolean, StringBuilder and other commonly used classes. MessageBox is a utility class that’s implemented only at the client. HTML DOM related functions exist in the static CodStorm.WebClient.HtmlModel.HtmlDom class.

The "Hello World Sample" project includes the code above, and may be used to play with the [RunAtClient] and [RunAtServer] metadata attributes. On the next blog entry, I’ll write about some other cool metadata attributes that will make your code lean and mean. Cheers!

Dear Diary

Today is a historical date.

After a long period of intense programming in crazy hours, sunrises after sunsests, pizza over... well... another pizza, we are relasing the very first public version of our Online IDE (click!) Last-minute features, fixes, touchups, pixel adjustments, documentation writing, spelling corrections are being made.

So let me explain what an this all means. An Integrated Development Environment, or IDE for short, is a tool that web developers and programmers use to build Rich Internet Applications. Typically, this is an offline task, and IDEs are getting more and more heavy and bloated with features. When an application is ready, it needs to be deployed to an online server, a task that is not as easy as one would think. Versioning, databases and configuration are common setbacks,  and since everything is online today, the problem is pretty widespread.

CodeRun is based on a really simple concept - Code, and Run. That's it. Your product's lifecycle, from early prototyping and provisioning stage, through building and debugging a visually compelling application, and finally deploying to a production server, can all be done on our platform.  It takes only a few minutes to build your application. And there's more: you don't have to learn anything. We support C# and XAML, and that's all you really need to know (support for additional technologies is well underway). You can debug your applications online, manage the database, and even do some issue tracking. And all is done without installing anything. Your browser will do.

We have beta accounts to give. If you want them, they are yours (hurry up! hopefully, we will get so overwhelmed with applications that google's servers will choke).

I will soon blog and blab about how-to-do-this-and-that. Screenshots will be published too. You wouldn't believe how many hidden gems we have for you. Some had to be disabled for this version because we felt that are not ready for you ; some will be implemented soon. By the way, if you've got some suggestions, leave a comment here, or do that directly from within the IDE.  A voting system for that will be created real soon.

We are all tired here. Pizza is on the way . Our eyes are dry from a long day's work. We want to sleep. We could use a vacation. But more than anything, we want you to give our IDE a test drive, you will love it!

So cheers from everyone: Barak, Gilad, Dan-el, Nir, Frankie, Gili and yours truely.

Peas out.