Thursday Night

Paul Betts’s personal website / blog / what-have-you

SassAndCoffee hits 1.0!

July 12th, 2011 at 10:23 pm


What does SassAndCoffee do?

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

  • Add the package reference via NuGet
  • Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
  • Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
  • To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

What’s New in SassAndCoffee 1.0 – Rigging VS2010 to be compatible

The most common issue that people experience with using SassAndCoffee wasn’t actually an issue with the code at all – the symptoms were that it would work fine on their development machine, but when they deployed to production, all the SCSS/CoffeeScript files would return 404 File Not Found.

Why? Since VS2010 doesn’t recognize these files, it sets its build action to ‘None’, which means the files won’t be deployed. However, since VS runs your app locally from the same directory, it would still find the files on your box. The ultimate case of “Works On My Machine”!


The Properties Dialog, where you can reset this property

Well that’s annoying. How do you fix it?

Now, when you install SassAndCoffee, you will see a dialog offering to install a file onto your box – this “pkgdef” file will configure VS to consider Sass/SCSS/Coffee files as Content. Here’s the details on how this works.

Configurable Caching Support

SassAndCoffee now has three types of cache options, which can be configured by adding a setting to the appSettings block with a key of SassAndCoffee.Cache:

  • NoCache – Compile every file when requested, don’t cache anything
  • InMemoryCache – Cache a limited number of files in-memory, but don’t persist anything to disk
  • FileCache – The default option (and previous behavior) – cache compiled files in App_Data

What else is new?

  • SassAndCoffee had its first external contributions by Steven Robbins and Ken Browning! You have no idea how excited I am about this.
  • The biggest change was support for NancyFx by Steven’s Herculean effort to decouple the core compilation code from the ASP.NET pipeline. SassAndCoffee is now in a great place for other non-ASP.NET frameworks to use as well, such as Manos.

Threading bugs in ReactiveUI in Silverlight

June 23rd, 2011 at 3:41 pm


The symptoms of this bug

If you use the Silverlight version of ReactiveUI, you will currently encounter a lot of issues that appear to be the classic InvalidOperationException, where a Silverlight object is being accessed by a background thread – it might look something like this:


at System.Windows.Threading.Dispatcher.VerifyAccess()
at System.Windows.DependencyObject.GetValue(DependencyProperty dp)
at System.Windows.Controls.Primitives.ButtonBase.get_Command()
at System.Windows.Controls.Primitives.ButtonBase.UpdateCanExecute()
at
System.Windows.Controls.Primitives.ButtonBase.OnCanExecuteChanged(Object
sender, EventArgs e)
at ReactiveUI.Xaml.ReactiveCommand.b__0(Boolean b)
at
ReactiveUI.ObservableAsPropertyHelper`1.<>c__DisplayClass4.< .ctor>b__0(T
x)
at System.Reactive.AnonymousObserver`1.Next(T value)
at System.Reactive.AbstractObserver`1.OnNext(T value)
at System.Reactive.AnonymousObservable`1.AutoDetachObserver.Next(T
value)
at System.Reactive.AbstractObserver`1.OnNext(T value)
at
System.Reactive.ScheduledObserver`1.<>c__DisplayClass639.b__637()
at System.Reactive.ScheduledObserver`1.b__634(Action
self)

You’ll also see the message in the Console output, "WPF Rx.NET DLL reference not added - using Event Loop"

How to fix it

The easiest way to fix this is by adding this block to your App.xaml.cs:

protected override void OnStartup(StartupEventArgs e)
{
    RxApp.DeferredScheduler = DispatcherScheduler.Instance;
    base.OnStartup(e);
}

What’s the Deal??

One of the goals of RxUI was that the core library didn’t have a dependency on WPF/Silverlight: since an Observable Model object or an Observable collection is useful regardless of the domain! However, to do this, we need to do some trickery to ensure the experience is correct.

In a Console app, we don’t have a message loop, so we use EventLoopScheduler; this has the result of creating a single thread where all of our “UI actions” happen – it’s a Dispatcher without the Dispatcher. In WPF/Silverlight, we do have a real message loop, so we want to use DispatcherScheduler as our “put it on the UI thread” scheduler – but, we can’t link to System.Reactive.Threading.dll without pulling in WPF, even if we don’t use it!

What I do is, in the RxApp startup routine, I use Reflection to attempt to find the DispatcherScheduler Type and instantiate it at runtime. In WPF, the code that is currently there works like gangbusters – in Silverlight though, you have to be way more specificLukas Cenovsky does a great job tracking down the bug in this mail thread: you have to specify not just the fully namespaced Type name, but the fully qualified assembly name! (i.e. not just “System.Reactive.Windows.Threading”, but all of the version details and the public key token.

How come this doesn’t happen in unit tests?

Because in Unit Tests, there is no working Dispatcher (you can queue items to it, but they will never run) – ReactiveUI knows this and switches the Scheduler automatically in a unit test runner to Immediate, which makes writing simple unit tests far easier. That has the side-effect for me though, that some of my code is never covered by a unit test. Oops!

tl;dr; - Reflection works a lot differently on Silverlight, and is generally way more of a pain.

New Release: SassAndCoffee 0.9 – now not glacially slow!

June 6th, 2011 at 3:02 am


What does SassAndCoffee do?

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

  • Add the package reference via NuGet
  • Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
  • Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
  • To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

What’s New in SassAndCoffee 0.9 – Speed, Speed, Speed!

SassAndCoffee now embeds the V8 Javascript Engine – this improves compilation speeds dramatically compared with previous releases. This feature only works on x86/amd64 on Windows, but if you’re on Mono or some other platform, SassAndCoffee will fall back to the old Jurassic-based engine. All of this is behind the scenes though, nothing changes from the perspective of a user (except for the NuGet package went from 400kb to 3.7MB!) Compilation speeds for Sass are improved as well through better reuse of IronRuby engine instances.

What else is new?

  • The Sass @import directive now works – this is an awesome feature of Sass that really allows you to clean up your CSS files and write them more like code and keep it DRY!
  • Reliability improvements – less crashification and race conditions

New Release: SassAndCoffee 0.8

May 30th, 2011 at 10:20 pm


What does SassAndCoffee do?

SassAndCoffee is a library for ASP.NET (both MVC and old-school WebForms) that adds drop-in support for two new languages: Sass and SCSS, a language that allows you to write reusable, more structured CSS, as well as CoffeeScript, which is a JavaScript dialect that is much more syntactically elegant, but still preserving 100% compatibility with regular JavaScript.

How to use SassAndCoffee

  • Add the package reference via NuGet
  • Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
  • Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)
  • To get the minified version of a file (either a coffee file or a standard js file), ask for the “.min.js” version (i.e. “scripts/test.min.js”)

Some things you don’t have to do

  • Install any extra software, such as Ruby – everything is embedded in resources.
  • Do any special configuration or make manual changes to your config files – NuGet will handle that.
  • Run any commands to update the files – SassAndCoffee builds the files on the first request; if you make CSS / JavaScript changes, it’ll rebuild automatically.
  • Do any special setup whatsoever when deploying – if it works on your box, it’ll work on the remote box (*)

* – a special note: VS2010 likes to mark CoffeeScript files as ‘do not deploy’ – make sure to hit F4 and mark them as content

What’s New in SassAndCoffee 0.8 – Minification and Combination

SassAndCoffee now supports JavaScript minification thanks to Mihai Bazon’s UglifyJS project – for both CoffeeScript files as well as your existing JavaScript files. It’s quite simple to use – anywhere you reference a JS file in your Views, rewrite the reference to “.min.js”.

It’s also a good idea to combine several Javascript files into one file to minimize requests – however trying to do this by-hand is a maintenance nightmare. To this end, SassAndCoffee will do this work for you. Here’s how to do it:

  1. Open your View file, you probably have references to a bunch of scripts, whose source looks something like: @Url.Content("~/Scripts/jquery-1.5.1.min.js")
  2. Copy the actual references (i.e. starting from ‘~’ on) to a file whose extension is “.combine” (i.e. ‘debug_all.combine’). These files don’t necessarily have to exist on-disk (i.e. they can be a CoffeeScript file). You can also just write a list of filenames, relative to the .combine file.
  3. Reference the file as if it was a JavaScript file (i.e. ‘debug_all.js’)
  4. If you change either the combine file or any file that it references, it will rebuilt – no need to rebuild anything by hand!

You can see an example of how this is used in the WebTest project on GitHub.

What else is new?

  • Scripts are compiled/minified in parallel, improving performance. Unfortunately, minifying a significant number of scripts still takes a long time – this will be dramatically improved in the next release.
  • Several bugs were fixed, such as fixing projects that didn’t have an App_Data folder, as well as a race condition where zero-length files could possibly be served up.

New Release: ReactiveUI 2.3.1

May 29th, 2011 at 4:27 pm


What’s New

ReactiveUI 2.3.1 is a maintenance release. The big difference is to fix the NuGet packages because they were targeted at the wrong branch of Rx.NET – I had built against the 1.0 branch, but only the 1.1 branch is published.

Wrong Branch?

With the latest release of the Reactive Extensions, the team has split the product into two branches – the stable release (having a version number of 1.0.10425), and the experimental release (which begins with 1.1). While the term “Experimental” sounds scary, it’s currently a bit of a misnomer – Experimental is just the Stable release with some extra methods added. Conveniently, they tagged all of the differences with an Attribute called “Experimental”, so you can use a disassembler such as ILSpy or JetBrains’ dotPeek to find all of the new cool stuff if you find the “ExperimentalAttribute” class, then “Find Usages”.

Keep in mind, that the reason that the release is Experimental, is that these new APIs are subject to change – they might work differently in future releases, or be gone altogether.

One more thing

It’s not all boring changes – I added one small feature that folks were asking for: in your class definitions, if you have a custom property getter/setter and can’t use RaiseAndSetIfChanged, you can now use the Expression syntax with RaisePropertyChanging/RaisePropertyChanged. So, “RaisePropertyChanged(x => x.SomeProperty)”.

What is Rx-Xaml?

For the current Rx release, the DLL that contains “ObserveOnDispatcher” (and everything Dispatcher-related) is in a separate “System.Windows.Reactive.Threading.dll” assembly. This DLL is needed for any project that uses WPF/Silverlight/WP7. The Rx team decided to publish two separate packages for this DLL, “Rx-WPF” and “Rx-Silverlight”. While this is easier to grok, it also makes it difficult for projects like ReactiveUI that support both WPF and Silverlight, since I can’t write the dependency in my NuSpec file correctly. So, I created a new package, “Rx-Xaml”, that is a simple merge of “Rx-WPF” and “Rx-Silverlight” – based on the platform, it will do the right thing. I’ll keep this package up-to-date, so feel free to depend on it.

Announcing: SassAndCoffee 0.5

May 16th, 2011 at 2:33 am


Sass and Who What Now?

One of the new controversial features that is being added to the latest version of Rails, is the default inclusion of two languages that make web development easier – one for simplifying CSS called “Sass”, and a language for writing more readable, elegant Javascript, which is called CoffeeScript. The examples from these two sites illustrate the languages far better than I could.

Both of these languages share some common characteristics – they both try to generally stay “true” to their target language (i.e. CoffeeScript compiles down to clean, readable JavaScript that generally has a 1:1 mapping from source to target statement), and they both attempt to solve some of the historical “ugliness” associated with their target language. I’ve used both Sass and CoffeeScript before in the past and I think they are a brilliant contribution to web development, and allow you to write cleaner, more reusable code.

These two languages have excellent support in Rails, as well as in node.js, two of the latest “hip” web development platforms, and I was surprised that someone hadn’t beaten me to the punch and created NuGet packages to enable support for these – a lot of people had solutions for different pieces, but most were proof-of-concepts or were difficult to use. With NuGet, there is zero reason that web libraries should be anything other than “one-click install”.

So without further ado, I present, SassAndCoffee – an ASP.NET library to add drop-in support for Sass/SCSS and CoffeeScript!

How to use SassAndCoffee

  • Add the package reference via NuGet
  • Add a .coffee, .scss, or .sass file to your project (an easy test is to just rename a CSS file to .scss)
  • Reference the file as if it was a CSS or .JS file (i.e. to reference “scripts/test.coffee”, you should reference “scripts/test.js” in your SCRIPT tag)

That’s all there is to it! Files will be cached in your AppData folder and will be regenerated whenever you modify them.

How does it work?

SassAndCoffee embeds the original compilers in the DLL as (Sass 3.2.0 and CoffeeScript 1.1.0 as of this writing) and uses IronRuby and Jurassic respectively to execute the compilers against your source.

Why is this better than [SOMEOTHERPROJECT]

  • No external processes are executed
  • You don’t have to install Ruby or node.js
  • It’s in NuGet so you don’t have to fiddle with web.config
  • Files are cached and are rebuilt as-needed.

Thanks

Several folks helped me out with some of the integration details of this project – if it weren’t for them, I would still be stuck in the mud right now:

  • David Padbury for helping me out with the CoffeeScript compiler
  • Levi Broderick for giving me a few hints as to how to rig up the HttpModule
  • Jimmy Schementi for telling me the proper way to redirect ‘requires’ to an embedded resource

Dear Designers: please put dialog box buttons in the correct order

May 11th, 2011 at 2:03 am


Windows and OS X arrange dialog box buttons differently

I see so many people making this mistake lately, even in Microsoft’s own shipping software. The order of the dialog buttons is specific to the OS you’re targeting. It is confusing to users when you switch the button order, and if they aren’t paying attention, they may click the wrong one.

On Windows and KDE

From the Windows UI Guidelines:

Present the commit buttons in the following order:
OK/[Do it]/Yes
[Don't do it]/No
Cancel
Apply (if present)
Help (if present)

This has the result of pushing “The Thing You Want To Do” toward the middle of the dialog.

OS X is different

From the Apple HIG:

The buttons at the bottom right of a dialog all dismiss the dialog. A button that initiates an action is furthest to the right. This action button confirms the alert message text. The Cancel button is to the left of this button

Usually the rightmost button or the Cancel button is the default button. The default button should be the button that represents the action that the user is most likely to perform if that action isn’t potentially dangerous. A default button has color and pulses to let the user know that it is the default. When the user presses the Enter key or the Return key, your application should respond as if the user clicked the default button.

On OS X (and GNOME on Linux), the “Thing You Want To Do” is near the corner of the window. Personally, I think this is more sensible, but I’ll value user interface consistency over “better” any day of the week.

New Release: ReactiveUI 2.3

May 8th, 2011 at 1:36 pm


What does ReactiveUI do?

ReactiveUI is a M-V-VM framework like MVVM Light or Caliburn.Micro, that is deeply integrated with the Reactive Extensions for .NET. This allows you to write code in your ViewModel that is far more elegant and terse when expressing complex stateful interactions, as well as much simpler handling of async operations. Check out this video for an overview:

YouTube Preview Image

ReactiveUI on Hanselminutes

Check out the recent Hanselminutes episode about the Reactive Extensions as well if you’ve got more time. Scott and I chat about some of the ideas in RxUI and how we can take the ideas in the Reactive Extensions and use RxUI to apply them to Silverlight and WPF apps.

What’s new in ReactiveUI 2.3 – update to work with Rx 1.1.10425

As you may have noticed, the latest version of Rx has changed quite a bit, in both the functionality and the namespace structure. The latest build is just a release to make RxUI compatible. Another fix is, that since NuGet 1.2+ fixes the support for WP7, so I’ve updated the normal packages. If you’re already using the WP7-specific packages, I’ve updated those too.

Where can I find the library?

On NuGet! The best way to install ReactiveUI for a project is by installing the ReactiveUI package for WPF/Silverlight/new WP7 projects, or ReactiveUI-WP7 for existing Windows Phone 7 projects.

If NuGet isn’t your thing, you can also find the binaries on the Github page: ReactiveUI 2.3.0.0.zip.

Where can I see a sample?

A sample project for WPF 4.0 that includes everything you need to see how it works is on the Github page: ReactiveUI 2.1 Sample.zip. It includes a small sample app, the RxUI binaries, and some sample test cases.

PSA: Parallels Shared Folders breaks IIS Express

May 2nd, 2011 at 3:12 pm


If you’re using Parallels Desktop and you’re trying to use the awesome new MVC stack (IIS Express, SQL Compact, Razor views), you’ll find something quite frustrating: you’ll get error messages to the effect of “redirection.config: File cannot be found”.

Disable Parallels Shared Folders

The cause is that files that are normally local are being redirected to network shares. Disable this in Parallels and all will be right with the world again!

ReactiveUI posts now in PDF format

April 18th, 2011 at 1:34 am


Since my blog software is rather lacking as an official document source for ReactiveUI, I’ve put together the blog posts in chronological order, cleaned them up, and compiled them into a single PDF, called “The Zen of ReactiveUI”. I’ve also created a version in ePub format, so that you can put it onto an eBook reader. If you’re interested in either RxUI, or the Reactive Extensions in general, I think the PDF is a good read – it talks about not only how RxUI works, but a lot of interesting background behind how things work.

Get the document here: