JavaScript

Core Addin Challenge: 2 weeks with CodeRush/Refactor Pro (CR/R!)

Jay Kimble — Tue, 05 Aug 2008 19:43:58 GMT

[As previously mentioned I have committed to switching from ReSharper (R#) to CR/R!... the end result will be a regular guy’s comparison of the 2. DISCLAIMER: By no means is this meant to be a slight on R#, but more of me looking at CR/R! a little closer -- I think a number of us took a cursory look at CR/R! and while we found value a surface look doesn’t really give you the full picture... I’m going through the challenges of using CR/R! because it IS different from R# and hopefully I can help folks who are trying to compare between the two and decide which is best for their situation]

Turning the corner (sort of)

Tuesday I turned the corner I thought that there was no coming back (more on that in a second). The thing about CR/R! is that it’s truly a learning experience. CR takes over your environment in such a way that, while it still looks like Visual Studio, you need to re-educate yourself a little to all its nuances. It can actually get in your way (and there have been a couple times with Mark and Rory (and Koen HanHoefkens, the author of the excellent --and free-- CR_Resolve plugin) where I have asked "how do I turn xxx feature off." The most annoying one for me is that I tend to highlight code and start to overwrite with new code... for the most part there are no pains here, except when the character you type is a "(" which is often the character I am typing when changing an "if" statement. What happens is that this embeds your selection in a set of parenthesis. This was actually easy to turn off... the feature is called "embeddings" which is found in the shortcuts section of the options (there are lots of options with CR/R!). Before I shut them all down I discovered some really rich stuff here... for instance you can highlight code, type "c" and your code is instantly surrounded by a try catch with your cursor setting in the catch block. I still turned off the parenthesis, but I left the rest of them on.

I’ve also started figuring out some of the templates.

I’m still learning here, but the topic is very deep!

BTW, I’ve found that this product enhances your experience while working with ASP.NET HTML, JavaScript, VB, C#, and even Script# (C# variant that creates JS files).

My One hiccup

I have experienced one hiccup over the last several days: PERFORMANCE/MEMORY FOOTPRINT. I’ve had VS crash a few times. I finally think I have the problem figured out (a not so well behaved plug-in I installed... I installed some really old plugins... well they didn’t seem that old).

Currently the only DXCore plugins I have running (besides CR/R!) are CR_RESOLVE, and the "Highlight Current Line" both from the community plugins (mentioned in the last post). I also have turned off the Code Analysis (temporarily).

I am still watching this closely (and am sure that Mark Miller will chime in either personally or publicly with a few more suggestions, but I don’t think he needs to... this lesson should be heeded that you need to be careful which addins you install in VS... they can make things run less than smoothly, and adding a bunch of them all at once makes it even harder to determine where the problem really lies).

DLRScript 0.55 released for Silverlight2 Beta2

Jay Kimble — Thu, 24 Jul 2008 20:12:15 GMT

[UPDATE: I forgot to add the link to the project - http://www.codeplex.com/dlrscript/]

It took a bit of time for this release. In the end I had to take everything a step back (as well as there are probably a few "mid thoughts" in here as the release of SL2 Beta 2 caught me a bit by surprise... actually the changes to the DLR caught me more by surprise).

The step back is that we no longer get script code lines when there are issues. I’ll try to bring this feature back, but right now if it breaks, you’ll know it via an alert with a .NET error.

Future direction
I need some feedback on this. I’ve been thinking about scrapping any attempt at jscript compatibility and am thinking more about ecma3 support (DLRJScript has an ecma3 mode). The benefit there is that I could start focusing on building a better set of client-side APIs instead of a more compatible one. That said, I’m not sure how qualified I am at coming up with a "better" set of client-side APIs.

I do want some feedback though. Let me know what you think: jkimble-at-gmail.com.

Tampa User eXperience (TUX) User Group is coming September 10th, 2008…

Jay Kimble — Fri, 18 Jul 2008 03:35:18 GMT

I am proud to announce that I and a couple other guys are starting User Group that revolves around User Experience (or UX) in the MS tools eco-system. The other guys are Shawn Cady, Perry Panagopoulos, and Bill Reiss (MVP) [Bill always gets his MVP props].

I could give you all their backgrounds, but I’ll make them do it at the first meeting. I’m sure Papa Fish (aka www.devfish.net) the local MS Dev Evangelist (my Blog Father) Joe Healy will be around (at least for the first meeting).

TUX' Focus
Our focus will be on the "now" of Ajax and how it integrates with ASP.NET (in all its various forms), and the "future" of Silverlight2, and anything in between (like adding Silverlight2 controls to Ajax sites, etc); we’ll not be stuck in just Web either... we’ll probably do some WPF as well. We’ll also be dealing with some of those more abstract things that you need to get better at (like how to be a better designer, creating good user experiences, etc.), and we will do our best to keep this group "devsigner-friendly" (devsigner is a developer who is also a designer).

We have a lot of really creative ideas to make this fun and useful to you today as well as with an eye for the future (but I don’t want to blow them all)... We will definitely keep this interactive and will try to help you solve your problems as well (at least we’ll be around to chat with you before and afterward).

First Talk: Intro To MS Ajax Scripting
The first person to present will be me. I will be pulling a talk out of my paid pile which means that you have probably never seen me give this talk (unless you work at one of the companies I gave it at)... this is very special and will never be repeated (well, maybe). This talk is one that I have yet to see anyone give (for free). It’s an introduction to the MS Ajax scripting framework. Oftentimes you see a demo where someone shows you how to build an Ajax Extender control where a JavaScript is thrown in, but rarely (I’ve never seen it done) does someone talk to you about building the script behavior which is used to create the Server-Side Extender (I will in fact be doing just this). You will leave this talk with the knowledge of how to do it. As is often the case when I talk about JavaScript, I’ll end with a Script# demo which will make your life a lot easier (so we’ll build the last demo in C# which will be compiled to MS Ajax-style JavaScript); this big demo is a selection grid behavior that I built for my employer to replace a commercial grid component that we were using; you’ll definitely have a use for it.

Bonus
We’ll have Pizza provided by Answers Systems, so just get there after work... you don’t need to eat first.

AND!!!! Bill Reiss (MVP) has graciously given us an MSDN Premium Subscription (used to be MSDN Universal) to give away, so don’t miss it.

Where/When will it be?
We will be holding these events at my workplace: Answers Systems in Oldsmar, FL. Better directions than this will follow in the near future (we will have a web site soon), but it’s right next to (West of) the Oldsmar Fleamarket on Tampa Rd (aka Hillsborough Ave). We plan to open the doors at 6:30pm with the activities starting at 7:00pm.

Can’t make it, but you really wanted to see my session?
<sarcasm>So you are in my fan club (Eric Wise, I know that’s you since you maintain some of my stellar code), but you live in another state (like say the cold state of Ohio... where it’s 40 degrees Fahrenheit in August) so there is no way you could see this session by me, but you really, really want to see it, but the plane ticket is so expensive.</sarcasm>

Well, we plan on videoing our sessions and making them available online (as long as the speaker is OK with it, and I am... SO this is the LAST time I’ll be able to charge for this session... unless I revamp it which I will).

Afterwards...
I’m not Joe Healy so I can’t pick up the tab, but there is a Starbucks down the street that many of my colleagues and I like to frequent (Stimulants... I need a good stimulant not a depressant... but we could be talked into depressants), so don’t be surprised if we all end up somewhere afterwards or maybe somewhere else...

RSVP
If you plan on coming please drop me a line via the contact form on this site. We need this to help us figure out how much Pizza to buy.

PS
In October (the 2nd Wednesday), Bill will be doing a Silverlight2 talk (He’s a Silverlight MVP and a soon-to-be Silverlight book author). It will be more of an intro, but he plans on really giving a nice overview from both the diesgn standpoint and the development standpoint.

And, yes, we actually have a a list of things we’re thinking about for November... nothing definitive (yet), but we plan on being way ahead of the game (as best as we can).

Script#: Events/Delegates in an Atlas/MS Ajax style script

Jay Kimble — Thu, 22 May 2008 13:30:48 GMT

First of all if you don’t know what Script# is, it is a C# language variant available in VS2005/2008. The difference is that it can be used to create JavaScript. The compiler produces an assembly (usable in other Script# projects) and a set of JS files (a release and a debug version). Nikhil Kothari (the author) also has 2 script frameworks you can target: Nikhil’s framework, and the "Atlas"/MS Ajax (aka MS ASP.NET Ajax) framework. There are difference in what you can do when using the "Atlas" framework.

Event Limitations

Let me start with a quote from the Script# Dox (regarding limitations in "Atlas" targeted scripts):

"No support for auto-generated event accessors. Auto-generated event accessors require the existence of a Delegate class with Delegate.Combine/Remove semantics, which are not provided
by ASP.NET AJAX. The workaround is to explicitly implement the 2add/remove accessors for events in your code, rather than have the compiler generate it. "

Basically this is saying there are issues with building events in your classes with Script#. It’s not impossible, but it’s not automatic like it is in Nikhil’s Script# (client-side) framework.

Since I recently had to do this and had to search the Internet for a solution (which there is no answer for), I thought it would be good to document how to do it (for both my reference and for others).

How To Add/Remove Events

That comment about needing to create your own add/remove logic is really simple to handle, but your class needs to derive from Sys.Component (or a class like behavior and control which derive from Sys.Component). The code looks like this (In Script#):

        1: // add a handler to an event

       2: public void add_MyEvent(EventHandler fn)

       3: {

       4:     this.Events.AddHandler("MyEvent", fn);

       5: }

       6: // remove a handler from an event

       7: public void remove_MyEvent(EventHandler fn)

       8: {

       9:     this.Events.AddHandler("MyEvent", fn);

      10: }

The reason we need to derive from Sys.Component is that Sys.Component gives us the Events property. Events is the container for all our events. New ones will be dynamically generated within that container. Let’s see a simple property we can build to easily get the event back when we want to invoke it.

       1: private EventHandler MyEvent

       2: {

       3:     get

       4:     {

       5:          return (EventHandler)this.Events.GetHandler("MyEvent");

       6:     }

       7: }

All of this is well documented. The hard part is. Now I have the event how do I call it with Script#? You might start looking for invoke or apply syntax (which I did. But the answer is quite simple. The EventHandler is a function/method that you can call directly like this:

       1: EventHandler evnt = this.MyEvent;

       2: evnt(sender, new EventArgs());

BTW, you can do the same type of thing with delegates... they’re just simp0le functions.

I hope that helps someone...

[I really need to write a fuller post on building Behaviors with Script# (in case you don’t realize Behaviors are the foundation of ASP.NET Ajax Extender Controls).]

Necessary Evil??

Jay Kimble — Fri, 09 May 2008 19:30:01 GMT

I want to write today about the 300lb Gorilla that none of us really wants to talk about. I'm talking about the people we use to find new jobs. As you may be aware I closed down IntraDynamics, LLC (well, I have greatly curtailed my company's offerings),and got a new job (at Answers Systems, Inc.)

I was "exchanging notes" with my new boss regarding the process and discovered some things (none of this is surprising, but you may want to think about it next time you are pursuing a new job).

I had two recruiters that were aware of my interview process with Answers. One was the company who placed me and the other was a company I trusted (in the past) who appeared to be working hard to place me somewhere else (even asking about where I was in the process with Answers). In fact I was actually told that Answers (who offered me a job in less than a week) was slow in their hiring process. All this makes sense (the other recruiting company was trying to get the fees for me and wanted to do the placement with Answers, so they needed me out of the way). They inappropriately asked Answers about me.

There's that side of things. The other is that it took a long time to get my deal finalized (almost another week). Why? Recruiter placement fees. Now mind you there was a slight change in things with me (I went from "contract to hire" to just "hire"). The company wanted as much as 35% of my yearly salary for placing me (now mind you it wasn't because they did a great job finding me, etc.. they were in the right place at the right time).

To be honest all Answers needed was someone else to pre-screen candidate's technical abilities. All that the placement firm did was monitor Monster.com and send out an email. There were a few additional things they did (like call me everyday regardless of whether there was new info or not).

I don't mean to be trashing on someone (that's why I left the company names out), but I was in shock of the fees they wanted to collect. My boss, Perry, and I started talking about what would be better.

Eric Wise' idea of having a computer programmers trade association seems like a good idea. We would pay dues, but the organization would allow us to take tests and "prove" our abilities (or at least allow it to be easier to pre-screen applicants). Maybe there would also be a mechanism for referring.

I've been thinking about this. We could do it now you know. We could set up a site to create the organization. There would need to be a set of testing sub sites (maybe you would only be allowed to test every 6 months or every year). When the companies we work for are looking for people we could simply look in the organizations site to see who is currently available and match up test thresholds to what we are looking for. We could then refer these folks to our companies avoiding the whole recruiting industry.

Maybe I'm just dreaming...

DLRScript update

Jay Kimble — Thu, 24 Apr 2008 15:46:22 GMT

I have begun working on DLRJScript-JavaScript compatibility. I was actually successful running my first externally created JavaScript -- EcmaUnit 0.4 (which is a small JS testing framework). I did have to make a couple modifications.

I’m becoming aware of the size of this job though. I’m currently porting a Mozilla-compatible XmlHttpRequest object which I think will work with all the major Ajax frameworks. I’m not sure which Ajax Framework I’ll actually target as the first on to run. I could stick with the man and make it work with the MS Ajax client library, I could go with Prototype that so many people swear by or I could use something else (JQuery is looking rather interesting to me in this regard). The biggest thing I require though is either an extensive sample project or a test suite itself. This makes it easier to see if my JavaScript replacement is working OK or not. Once I have a reasonable compatibility (one or more frameworks working fairly good with minimal issues) then I’ll move over to making the various languages capable of communicating with one another (so I can loadup JQuery and then use it, clientside, from Iron Ruby).

In case you forget why you might want to do this, it’s simple really; DLRJscript is faster (because it’s compiled) then traditional JavaScript (which is interpreted).

DLRScript 0.5 Notes...

Jay Kimble — Mon, 14 Apr 2008 18:33:12 GMT

As you may or may not have seen, over the weekend I released a new version of my DLRScript project. It’s coming along. It adds 3 things: File loading via the src attribute, better exception reporting for DLRJScript(it shows you what line of script code failed), and improved DLRJScript performance.

File Loading
I could probably write a bunch on this (and probably should in another article). Basically I am dynamically loading content (script files) from the server. I also extended HTML a bit in that you can now use the same script tag to load a script from the server and to write additional code that will load after the script has loaded. It looks like this:

        1: <script type="DLRJScript" src="/somefile-on-the-server.js">   1:     2:     function doSomething()   3:     {   4:         // Code found here   5:     }</script>
  

JS Performance
Because of the new way I am creating the JScript engine, I get JScript code to compile, so the code that executes is faster than standard interpreted Client-Side JavaScript. I did a simple test which is within my project over on CodePlex. The test simply adds 15 <hr /> elements to a hidden div. It records the time before and after the routine. First run in the DLRJScript results in about the same speed as standard client=side JavaScript. The second run results takes about 1/2 the time and the third trip is even faster (the 4th-6th attempt takes about the same amount of time as the 3rd run, so I figure that’s as fast as it gets). I’m not sure if this implies that the DLR optimizes code even more after subsequent runs of code or not (I know the .NET spec supposedly will optimize code after it has been run a few times).

Anyway, my test is not scientific in case you are wonder. There could be additional processes on my box that may make the results vary. Everything is a very crude approximation. I did run the client-side version several times to see as well with about the same results.

The Future
Ok, my plan is to get my DLRJScript to be more compatible with standard client-side JavaScript using DOM2. Right now I know I’m not even at DOM1 spec. I will be testing various libraries to see if I can get them to run with my implementation. It may result in a faster way to run JavaScript in the browser. Also, since the code is really running within the SilverLight plugin, the script code should be standardized and run the same in every browser (well, at least in theory).