Most of you have probably noticed the new look of CodeRun.
In addition to the new website, this version is much faster and supports a broader range of browsers. Coderun now offers a new service called cloud hosting. This basically means that you can write your application and host it online, with a few simple clicks and no installed software at all. Check out the free trial.
Gilad created today a few videos that are well worth checking out:
Create: http://www.youtube.com/watch?v=M7fspIbpRGA
Debug: http://www.youtube.com/watch?v=Ccd5Ap-liFw
Deploy: http://www.youtube.com/watch?v=Hqv42zH7kz4
Cheers,
Alon.
Monday, October 5, 2009
Tuesday, July 14, 2009
CodeRun adds support for Visual Studio solutions
We are in the process of rolling out support for Visual Studio .SLN files, stay tuned!
Thursday, June 25, 2009
CodeRun gets a new debugger
I'm pleased to announce that CodeRun has a new debugger. Still a bit rough around the edges, but works very well. We'll continue improving it in the next few days.
Thursday, April 30, 2009
Javascript: The missing parts
Looking at the way YUI is modelled, I tried to figure out how their type system works.
As it turns out, there isn't one. There is no standard way of doing these things:
Problem: Method overloading.
Description: Some methods may accept different argument type and number of parameters, and behave differently for different combinations. Pro: API seems smaller. Con: API is a lot larger, you can't remember which combination does what.
Solution: Suffix _every_ method name with the argument types. It seems a bit too much at first, but if your not hand-writing the JS code (hint hint), it shouldn't be a problem. Also Intellisense would be more helpful, and less reference documentation would be required. When you think about it - that's cheating. There is no one overloaded methods, but different methods with different names.
Examples:
Problem: Multiple constructors
Description: Similar to method overloading, but the same solution will not work. You will end up by having N different prototypes, but you need only one. Also, instanceof will not work.
Solution 1: Instead of using many parameters, use an object literal as a single parameter. Pro: Solves the problem. Con: You will need to memorize or document the object literal. This is also valid for method overloading, but since you usually call more methods than constructors, and this does change the code structure, it is a better fit for this scenario.
Example:
Solution 2: A constructor has 4 parts to it: (1) Instance creation (2) Base ctor where applicable (3*) instance fields initialization and (4) ctor body. The new() operator does (1). You do the rest in your code. This code demonstrates what is being done:
Edit: Correction - I double checked with C# and apparently (3) occurs before (2). Instance members are initialized before the first statement of the ctor of their declaring type. So if class A is derived from class B, and both contain some field initializers, A's fields will be initialized before B's fields.
*Some languages (like C#) allow you to initialize instance fields in their declaration. They are initialized at construction time, between the base constructor call and the actual constructor code.
However, this does not fit in an expression, but rather in two statements. The solution is simple: have init() return the "this" instance. That way, you can write something like:
Since the new() operator takes precedence over the dot (.) operator, this expression does exactly what we need. the expression
More stuff next time. Cheers!
As it turns out, there isn't one. There is no standard way of doing these things:
Problem: Method overloading.
Description: Some methods may accept different argument type and number of parameters, and behave differently for different combinations. Pro: API seems smaller. Con: API is a lot larger, you can't remember which combination does what.
Solution: Suffix _every_ method name with the argument types. It seems a bit too much at first, but if your not hand-writing the JS code (hint hint), it shouldn't be a problem. Also Intellisense would be more helpful, and less reference documentation would be required. When you think about it - that's cheating. There is no one overloaded methods, but different methods with different names.
Examples:
Element.hide$Element(myElement);
Element.hide$Id("myElementId");
Element.hide$ElementArray(document.getElementsByTagName("p"));
Element.hide$IdArray(["id1","id2"]);
Problem: Multiple constructors
Description: Similar to method overloading, but the same solution will not work. You will end up by having N different prototypes, but you need only one. Also, instanceof will not work.
Solution 1: Instead of using many parameters, use an object literal as a single parameter. Pro: Solves the problem. Con: You will need to memorize or document the object literal. This is also valid for method overloading, but since you usually call more methods than constructors, and this does change the code structure, it is a better fit for this scenario.
Example:
var anim = new Animation({element:myElement});
var anim = new Animation({elementId:"myElementId", finished:function(){alert('done!');}});
Solution 2: A constructor has 4 parts to it: (1) Instance creation (2) Base ctor where applicable (3*) instance fields initialization and (4) ctor body. The new() operator does (1). You do the rest in your code. This code demonstrates what is being done:
var a = new Example.MyContact();
a.init("john","doe",31,"Mexico");
Edit: Correction - I double checked with C# and apparently (3) occurs before (2). Instance members are initialized before the first statement of the ctor of their declaring type. So if class A is derived from class B, and both contain some field initializers, A's fields will be initialized before B's fields.
*Some languages (like C#) allow you to initialize instance fields in their declaration. They are initialized at construction time, between the base constructor call and the actual constructor code.
However, this does not fit in an expression, but rather in two statements. The solution is simple: have init() return the "this" instance. That way, you can write something like:
myFunc(new Example.MyContact().init("john","doe",31,"Mexico"));
Since the new() operator takes precedence over the dot (.) operator, this expression does exactly what we need. the expression
a instanceof Example.MyContactevaluates to true. The code resembles the overloaded style we have in OO languages, with a tiny addition.
More stuff next time. Cheers!
Sunday, April 19, 2009
NoMoreJs Scooped?
The concept of language translation between a modern Object Oriented language and a lower level language has been here a long time. That's what compilers do. In this short post, i'll review some tools that translate your code to the beloved JavaScript language.
A friend commented on my last post, (re-) introducing me to GWT. Apparently, I've been asleep and that's what Google has been doing for some time with Java to JavaScript conversion. However, GWT is a JavaScript framework by its own, so there is a tight coupling between the compiler and its target platform.
Then, more research has found out JSC, which is even crazier than GWT. Instead of converting a modern language, it translates MSIL instructions to JavaScript. It appears to me like a Reflector plugin that exports JavaScript (hey! that's not such a bad idea).
But the real gem that I found was Script#. Apparently, Microsoft has been using this for a couple of years now. It supports JQuery as a target platform, and really looks advanced with all the bells and whistles. It's closed source (how surprising), and apparently pretty popular outside the Redmond Giant.
CodeRun's compiler, while not really advertised, is far more advanced than all of the above. The generated code requires a really thin stub, but in return you get a Type System that supports generics, debugging, profiling, and native remoting. However, right now the type compiler is coupled with the type system and remoting stub. I want plain-vanilla JavaScript.
So I'm still gamed. Writing compilers is fun!
A friend commented on my last post, (re-) introducing me to GWT. Apparently, I've been asleep and that's what Google has been doing for some time with Java to JavaScript conversion. However, GWT is a JavaScript framework by its own, so there is a tight coupling between the compiler and its target platform.
Then, more research has found out JSC, which is even crazier than GWT. Instead of converting a modern language, it translates MSIL instructions to JavaScript. It appears to me like a Reflector plugin that exports JavaScript (hey! that's not such a bad idea).
But the real gem that I found was Script#. Apparently, Microsoft has been using this for a couple of years now. It supports JQuery as a target platform, and really looks advanced with all the bells and whistles. It's closed source (how surprising), and apparently pretty popular outside the Redmond Giant.
CodeRun's compiler, while not really advertised, is far more advanced than all of the above. The generated code requires a really thin stub, but in return you get a Type System that supports generics, debugging, profiling, and native remoting. However, right now the type compiler is coupled with the type system and remoting stub. I want plain-vanilla JavaScript.
So I'm still gamed. Writing compilers is fun!
Wednesday, April 8, 2009
Work in progress: No More JavaScript
I Love JavaScript. I Really do!
I've known it for about 10 years now, and wrote a good tens of thousands of code lines.
Until that one day, when we decided to use our compiler technology to generate the JavaScript code from the C# code.
Pros:
+ No more syntax errors
+ No more ugly coding style
+ No more using obscure JSON objects to store data
+ Structured language (C#).
+ C# type system that includes inheritance, interfaces, generics), method overloading.
+ Pretty and solid code
+ Powerful (JS Code can still be written if you want, and there are a few hacks to be more powerful should you require that).
+ Compressible code
+ Less maintenence
= Debugging (the generated code structure make it very readable).
Cons:
- One might argue that the development cycle will take more time. In reality, the cycle is much shorter, since most of the syntax problems are done at compilation time.
- Everything has to be typed. This include 3rd party libraries. I will get back to that shortly.
- The type system is not standard. Then again, every JS library has its own way of writing code.
But now and then, I want to build this cute little website, where I can do pretty simple things. To keep it lean and mean, I often choose to write some JS code by myself. After all, how much code will you need for this project. Well, as it turns out, I'm always underestimating. And then I turn to big, established libraries, such as Prototype and YUI. But they require memorizing and being very close to the reference documentation, if you want to get something done.
This brings me to the breaking point - the IDE. I use Visual Studio for writing JavaScript. I am very familiar with it, and very productive most of the time. Debugging is great (IE only, though), but it can be better with JavaScript. Due to the over-powerful nature of the language, nothing is simple when you want to get Autocomplete for a member of a variable ; or when you call an API that can get either a string or an
element or whatever. Some properties are offered on Mozilla only; some events are IE-specific. What's missing is a solid structure for the unstructured language. Order in the chaos.
So I came to the inevitable conclusion - No More JavaScript.
No More Javascript. The sound of these words make be both terrified and relieved. I now realize that this has been the one thing that held me back on so many projects. JavaScript will become the Assembly language of the web. Bookmark these words!
I've decided to do whatever I can to spread the love with this kind of technology. My long-term plan is to give it as open source and support the major JS libraries. Unfortunately, the current compiler technology is proprietary and uses 3rd-party licensed libraries. I am looking for alternatives.
For the short-term, I'm currently spending time on converting the YUI interface to C#. This takes a LOT OF TIME, but i'm really happy with the results. My goal is to build a website that's completely written using C#, but still uses the cross-platform power and wide community support of YUI. For the time being I'm moonlighting, which makes me excited and happy! And when I'm happy, I buy domains.
Cheers!
-Alon.
I've known it for about 10 years now, and wrote a good tens of thousands of code lines.
Until that one day, when we decided to use our compiler technology to generate the JavaScript code from the C# code.
Pros:
+ No more syntax errors
+ No more ugly coding style
+ No more using obscure JSON objects to store data
+ Structured language (C#).
+ C# type system that includes inheritance, interfaces, generics), method overloading.
+ Pretty and solid code
+ Powerful (JS Code can still be written if you want, and there are a few hacks to be more powerful should you require that).
+ Compressible code
+ Less maintenence
= Debugging (the generated code structure make it very readable).
Cons:
- One might argue that the development cycle will take more time. In reality, the cycle is much shorter, since most of the syntax problems are done at compilation time.
- Everything has to be typed. This include 3rd party libraries. I will get back to that shortly.
- The type system is not standard. Then again, every JS library has its own way of writing code.
But now and then, I want to build this cute little website, where I can do pretty simple things. To keep it lean and mean, I often choose to write some JS code by myself. After all, how much code will you need for this project. Well, as it turns out, I'm always underestimating. And then I turn to big, established libraries, such as Prototype and YUI. But they require memorizing and being very close to the reference documentation, if you want to get something done.
This brings me to the breaking point - the IDE. I use Visual Studio for writing JavaScript. I am very familiar with it, and very productive most of the time. Debugging is great (IE only, though), but it can be better with JavaScript. Due to the over-powerful nature of the language, nothing is simple when you want to get Autocomplete for a member of a variable ; or when you call an API that can get either a string or an
element or whatever. Some properties are offered on Mozilla only; some events are IE-specific. What's missing is a solid structure for the unstructured language. Order in the chaos.
So I came to the inevitable conclusion - No More JavaScript.
No More Javascript. The sound of these words make be both terrified and relieved. I now realize that this has been the one thing that held me back on so many projects. JavaScript will become the Assembly language of the web. Bookmark these words!
I've decided to do whatever I can to spread the love with this kind of technology. My long-term plan is to give it as open source and support the major JS libraries. Unfortunately, the current compiler technology is proprietary and uses 3rd-party licensed libraries. I am looking for alternatives.
For the short-term, I'm currently spending time on converting the YUI interface to C#. This takes a LOT OF TIME, but i'm really happy with the results. My goal is to build a website that's completely written using C#, but still uses the cross-platform power and wide community support of YUI. For the time being I'm moonlighting, which makes me excited and happy! And when I'm happy, I buy domains.
Cheers!
-Alon.
Friday, March 27, 2009
On the rise
The number of users has essentially doubled in the last week. It's super exciting and it wonderful to see users from all over the world.
We are planning the next big release that will include more browser support (FireFox mainly), a new website, and lots of content.
I'm also writing a Feature Insight series that will start by introducing the Debugger, some Integration kits, and whatever Ii find exciting to write about.
Cheers,Alon.
Tuesday, March 24, 2009
Some web development rants
I am a web developer. Part of my job consists of writing code that will work on about 3-4 completely different browsers. Most of the difference is in the layout and styling engine. As for the JavaScript code, the code I write is targeted towards the lowest common denominator. The thing that bothers me the most is the developer tools (or lack of) the browsers offer. There is no single, unified debugger, and one must know how to use each and every debugger in order to cover all browsers. That sucks.
1. Internet Explorer, still used by the majority, has its standalone script debugger, or Visual Studio. Being the most stable and feature-complete, it sets the standard for the others.
PROs: Stable. Rather fast. Visual studio is home.
Cons: Not extensible. For IE only. Not integrated with the Web Developer Toolbar. No auto-complete.
2. FireFox, the choice of the new web. Your options include the Venkman debugger (which I won't discuss), and the popular FireBug (which I will). The thought of an open-source debugger is great. The FireFox architecture seems to be pretty sweet if you can just write your own debugger. It also has various add-ons like YSlow that improve it even further. The guys at Aptana even made a remote debugger, based on FireBug, which seems to me a step in the right direction. However, FireBug itself is really buggy. And slow. As a user of Firebug, I must say that I'm a little disappointed. As a developer, i know that it is not an easy thing to build and maintain. And at the end of the day - I don't like FireBug. There, I said it. I even googled a bit about 'firebug sucks', and found only this very old entry at SitePen. Is ranting about FireBug a taboo? It sure seems like it.
PROs: Open-source. Integrated with a DOM explorer, very useful for modifying styles at runtime.
Cons: Slow, rather unstable, watches are not implemented properly.
3. Chrome, the new kid. I use chrome myself for everyday browsing. It's feels faster than the rest, usually performs better, and feel very light. The browser itself has bugs, but I'll discuss the development tools. Or lack of those. There is a rather good debugging framework, available through ctrl+shift+L window. But it's good for debugging your Hello World application, not the full-blown IDE that I write.
PROs: I guess when the debugger will be available it'll rock. Till then:
CONs: Way too verbose and crude to work with.
4. Safari. Well, i tried and could not figure it out - you need to install Safari, then install the latest WebKit build, then run a batch file that seems to be broken, and then fail. I guess that when Chrome will render correctly, safari will too. At least, that's what I'm counting on.
PROs: Anyone?
CONs: Couldn't figure out how to even launch this one.
Conclusion: A few weeks ago i thought about putting some time on trying to improve the chrome debugger, but it seems that the debugger is undergoing some critical changes, so i'll wait. As for FireFox and FireBug, i sure hope that the new versions will keep improving. Speed improvements and stability are always promised, and probably delivered, but it's still not what i would call production ready.
So this is my rant for today. There are more (hint: IE8, WCF), so i'll save them for later.
Go FireBuggers GO!
1. Internet Explorer, still used by the majority, has its standalone script debugger, or Visual Studio. Being the most stable and feature-complete, it sets the standard for the others.
PROs: Stable. Rather fast. Visual studio is home.
Cons: Not extensible. For IE only. Not integrated with the Web Developer Toolbar. No auto-complete.
2. FireFox, the choice of the new web. Your options include the Venkman debugger (which I won't discuss), and the popular FireBug (which I will). The thought of an open-source debugger is great. The FireFox architecture seems to be pretty sweet if you can just write your own debugger. It also has various add-ons like YSlow that improve it even further. The guys at Aptana even made a remote debugger, based on FireBug, which seems to me a step in the right direction. However, FireBug itself is really buggy. And slow. As a user of Firebug, I must say that I'm a little disappointed. As a developer, i know that it is not an easy thing to build and maintain. And at the end of the day - I don't like FireBug. There, I said it. I even googled a bit about 'firebug sucks', and found only this very old entry at SitePen. Is ranting about FireBug a taboo? It sure seems like it.
PROs: Open-source. Integrated with a DOM explorer, very useful for modifying styles at runtime.
Cons: Slow, rather unstable, watches are not implemented properly.
3. Chrome, the new kid. I use chrome myself for everyday browsing. It's feels faster than the rest, usually performs better, and feel very light. The browser itself has bugs, but I'll discuss the development tools. Or lack of those. There is a rather good debugging framework, available through ctrl+shift+L window. But it's good for debugging your Hello World application, not the full-blown IDE that I write.
PROs: I guess when the debugger will be available it'll rock. Till then:
CONs: Way too verbose and crude to work with.
4. Safari. Well, i tried and could not figure it out - you need to install Safari, then install the latest WebKit build, then run a batch file that seems to be broken, and then fail. I guess that when Chrome will render correctly, safari will too. At least, that's what I'm counting on.
PROs: Anyone?
CONs: Couldn't figure out how to even launch this one.
Conclusion: A few weeks ago i thought about putting some time on trying to improve the chrome debugger, but it seems that the debugger is undergoing some critical changes, so i'll wait. As for FireFox and FireBug, i sure hope that the new versions will keep improving. Speed improvements and stability are always promised, and probably delivered, but it's still not what i would call production ready.
So this is my rant for today. There are more (hint: IE8, WCF), so i'll save them for later.
Go FireBuggers GO!
Subscribe to:
Comments (Atom)
