CoffeeScript (via WebEssentials)+ Visual Studio 2012 + Resharper 8.0 == memory headache!

Its been six months, time for a new post!

This one is more to brag than anything else, because I feel like a freaking rock star today :D

Our latest project for a customer is an EmberJS application written in CoffeeScript with an ASP.NET WebAPI backend.  This isn’t necessarily new territory for us, we’ve been working with EmberJS since Spring and things have been great.  For this project though, we decided to make the switch from plain old JavaScript to CoffeeScript and we love it.

What we don’t love is the absolute memory hog that VS2012 + CoffeeScript (via WebEssentials 2012) + Resharper 8.0 have become.  Several times a day we’ll have to restart Visual Studio because its hit its memory cap. Speaking of which, hey Microsoft, why don’t you make it a nice shiny 64-bit application, huh?  I’ve got 32GB of RAM in this laptop!

Anyway, Friday was our Technical Debt day and I decided to see if I could do something about it.  We’re already running a custom build of WebEssentials, because we wanted to change how it chose when it would generate the .js files, since we didn’t want to check them into git.

Since this only just started when we made the switch to CoffeeScript, I figured that how they compile .coffee files was the culprit.  Sure enough, when I looked under the covers I discovered they’re using IE to do the compilation.  Its also possible that when I upgraded the compiler script used by WebEssentials that broke it as well, but I didn’t want to downgrade.

My solution, instead of using IE to do the compile, what if I integrate V8 into WebEssentials?  It took half a day to get the first test running, but it was worth it.  Now when I do a build of our solution the memory use stays static instead of increasing by as much as 100MB per build!

If you’re interested in getting the code for yourself, I’ve published my forked version of WebEssentials and made a clone of the ClearScript repositories on my Github account:

Oh yeah, so why do I mention Resharper?  In my early testing after getting the V8 engine integrated I still saw some increased memory use.  This went away after installing Resharper 8.1 beta, however it could have just been a fluke as a co-worker running Resharper 7 didn’t see the increased memory usage.

Convention over configuration

At work, we’ve been making a lot of use of EmberJS; a Javascript MVC/SPA library that has really started to grow on me.

Part of the design philosophy behind it, like Ruby-on-Rails and ASP.NET MVC, is that rather than writing a configuration for things you just have to follow the conventions and things are “magically” picked up.

For example; when we add a new route and controller to our project it gets named App.NewsRoute and App.NewsController.  All I have to do is make sure the JavaScript is included and it’ll automatically get used when the user navigates to our /news route.  Similarly, we also don’t have to provide a custom route or controller.  If the default implementation of a route is fine then we don’t have to create the App.NewsRoute at all, It Just Works.

Sometimes this can be extremely frustrating, Ember is still a pre-release product and the documentation is rapidly evolving.  Making it difficult to know where to put things.  The most frustrating experience we had was getting an error from Ember telling us to add a serializer alias, but not being able to find out how to do this.

But, I digress.   This blog post is actually about…reporting!

Having recently spent the last 3-4 weeks working heavily in this environment (over 200 commits between three developers in this time frame) I’ve moved back to my reporting project and was quickly met with a deluge of thoughts along the lines of: “ugh, I gotta do this manually?”

There are some things I’ve already done to make it easier to load up and work with reports.  But, for the most part its been a manual process.  I need to make calls to this static method or to that extension method in the report script.

Here is where my thoughts about convention over configuration began to enter my head.

“What if, instead of having to write all the code to not only set up a custom control but having to write the marshaling code to get it to execute on the right thread, I could just do it ‘auto-magically?’”

“Why do I need to write method calls to set up the custom chart palette on each report where a chart is used?  Why can’t I just have some other code find it for me?”

And thus, was born Conventions.

Conventions allow me to do several things without having to actually write manual code in each report to do it!

The one I’m happiest with, is that I now have the ability to write a <name>Setup function to setup the contents of my custom controls AND it automatically gets called on the right thread! I can’t stress just how important that second part is, if you’re not careful you’ll wind up with the object only half-constructed and things behaving incredibly weird.

public void MyCustomControlSetup(BulletGraph graph)
  /* This function gets called during report setup
     passing in the instance of my custom control.  It
     is automatically marshaled to the correct thread
     for Windows Forms.

The snippet above demonstrates all I have to do to get my code called at report runtime correctly. The name of the method just needs to be the name of the ActiveReports CustomControl followed by Setup. It also needs to accept an instance of the same type as the CustomControl is set to use.

If you’ve used the scripting feature in ActiveReports, you’re already partially familiar with the convention approach. When handling events the method in your code just needs to be named a certain thing and the event will automatically be handled. This just takes it to another level.

Unfortunately, there isn’t a way of making it work with without some input from the script developer. What stops that from working is the lack of access to the object that is the instance of the compiled script. However, all I need to do to access it is make available an extension method that accepts the code:

public void ActiveReport_ReportStart()

This one line of code gives me access to the report (rpt) and the object that contains the code methods/properties (this).

A few other things I’ve done with Conventions so far:

  • Introduce additional “events” that allow me to distinguish from getting all my data, doing data binding, and ‘post’ data-bind event.
  • Automatically hook up custom chart palettes based on what report is loaded and being able to “fall-back” to other palettes defined for the containing report or at the repository level. All just by placing a specially named file containing the palette next to the report.

Resharper 8 Default Keymap (VS scheme)

Google wasn’t yet turning up a link to the Resharper 8 Default Keymap (Visual Studio scheme) so here is my small part to help it find the PDF.

This PDF gives you a cheat sheet of all the keyboard shortcuts used by Resharper 8 with the Visual Studio keyboard shortcuts (instead of the IntelliJ IDEA scheme).

ToolStrip positions won’t save? Give them a name!

Tonight, I was working on an application using the ActiveReports designer control.

While I was working on it, I thought it would be nice to save the position of the ToolStrips for the user and reload them, since there are quite a few toolstrips to deal with.

Microsoft was nice enough to include a couple methods that do this for you as part of Windows Forms: ToolStripManager.SaveSettings(Form) and ToolStripManager.LoadSettings(Form).

Nice!  Just a few lines of code hooked to the Load and Closing events and voilà! Saving and loading of my ToolStrip positions!  I ran it once, to get those settings saved.  But then I ran it again, and all my ToolStrips disappeared!  WTF?!?

Continue reading

Time for a change

This week, I turned in my notice to ComponentOne/GrapeCity that I accepted a position with another company.

I’ll be joining my friend and former co-worker, Lucas Hardbarger, at InfoPlanIT LLC working as a Senior Developer/Consultant. There, I’ll be putting to use my expertise with .NET, ActiveReports, and GrapeCity ActiveAnalysis to enhance their existing product line as well as create custom solutions for their clients.

I got my start at ComponentOne/GrapeCity by joining Data Dynamics, Ltd. 7 years ago as a new Tech Support Engineer, 3 months later I moved up to a Junior Product Manager and before the end of my first year I was the Product Manager for Data Dynamics Reports.

A month or two before we announced that GrapeCity was buying out Data Dynamics, Lucas announced he was leaving Data Dynamics for InfoPlanIT. That is when I took over the Product Manager duties for bringing ActiveAnalysis to 2.0. I then continued in this role through the acquisition by GrapeCity up until the first maintenance release when I turned the product over to Shalini, one of my co-workers in our India office.

Shortly after this we turned our attention to ActiveReports 7, where I worked with Raji and Sergey from the original Data Dynamics team and several from our Japan branch.

Last July we announced that GrapeCity had bought out ComponentOne. Later that month, after a year and a half of development, we released ActiveReports 7 (after a hasty update of the product to match the new ComponentOne branding).

And that brings us to today. To leave after 7 years is bittersweet, but it’s time to move on to other things. This will be different for me, but I’m looking forward to it!

ActiveReports 7 Now Available!

Its done!  ActiveReports 7 is now available for everyone to download and purchase!  This release has been a long time coming, with work beginning back in October of 2010, if I remember correctly.

So much work has gone into this release. I’m proud of what the team has accomplished.

Now that we have released in the U.S., we aren’t resting just yet. We are already hard at work on the next version, which will be the basis for our release in Japan!

The major new feature in ActiveReports 7 is Fixed Page Layout. This new layout option gives developers a way of easily creating paper form designs like you see in invoices and bills as well as those ubiquitous tax forms from the IRS!

Below is the announcement that was posted to the forums just a short while ago!

Continue reading

ComponentOne, a division of GrapeCity!

Today, GrapeCity has announced that it has acquired ComponentOne!  You can find the news elsewhere…but what I’m excited about is the opportunities we’ll have in the future to make our components even better and leverage our knowledge across the company.

So far we don’t have any plans (and I probably couldn’t talk about them anyway), but the potential is HUGE!  I can’t wait to put my proposals out there and see what the rest of the company thinks!