Just discovered this now. When you add a new action to an ASP.Net MVC controller, Resharper 5 marks the View() method as “in error”:

At first, I was a bit confused. I mean, the code was that simple, it was not possible that it should contain errors. But then I hovered over the “erroneous” method, and lo and behold:

There’s nothing wrong with the C# code, but it’s the actual view (the .aspx file) that’s missing. And I even have to option to create one. So, let’s try that:

I get a nice popup asking for some extra params. No need for them, so we just hit enter to dismiss the dialog. And yes, Resharper creates the view for me, at the correct location:

Easy as pie, but it’s a nice touch *and* a timesaver. But that’s what Resharper is for, isn’t it?

I needed to know how the Entity Framework does its change tracking, so I wrote a simple test to see what’s happening. Since we only needed to know what happened when you modify a property on an entity, I focused on that aspect (and not how deleting entities is tracked, for example).

Anyway: my conclusions… It seems that the Entity Framework sets the EntityState of an entity to Modified anytime you change a property. It does not matter what value you put in it.

To put this in a small list. The Modified state appears…

• … when you assign a different value (obviously)
• … when you assign a different value and then assign the previous value
• … when you assign the same value

Good to know.

In case anybody who can pull some strings reads this: I’d be interested in doing some testing of developing for Silverlight for Windows Mobile.

You never know, eh?

Besides, I have to find a good use for my HTC Touch HD except for twittering and making phone calls.

For a site I am developing, I needed a way to import a set of files in a Drupal system. The files were converted into nodes, each node having (amongst other stuff) a taxonomy term attached (think categories).

First of all: the taxonomy API is not really friendly towards other module developers (or at least, the documentation isn’t). The method for saving a term assumes it is called from the term/add form. No biggie, but not easy if you’re looking for a quick way to save a term (it turns out the method works fine outside the form too).

Anyway: taxonomy_get_tree caches its results per page. That means it’s quite performant to call it several times each page (for the same vocabulary). On the other hand: if you are doing a number of term updates to a vocabulary, those updates aren’t seen by later calls to taxonomy_get_tree, because the data is cached.

This bit me in the ass today: I was creating terms on the fly as I was importing files. Problem was that I saw the same term coming back multiple times, as if my code didn’t find the existing terms. Of course it didn’t: after the first call the “empty” tree was cached and I got stuck with out of date data for the rest of the import procedure.

So here’s a patch to solve that problem: it introduces a way to enable or disable that tree caching. If you disable the cache, the data will still be “remembered” (so once you turn it back on, it doesn’t require another database trip), but it will be reloaded with each call to taxonomy_get_tree(). And if you’re done updating the tree, just turn it (the caching) on again.

Here’s a patch against Drupal 6.3: taxonomy.patch.

Enjoy!

I came by this post about Firefox. It was based on an earlier (dutch) post by Webwereld, and it was about Firefox.

The be honest: I don’t agree with any of the points. Besides, all of the arguments given (except the last maybe) are actually strawman arguments. In essence: the points made against Firefox can be made against the other browsers too. Let me elaborate.

First: Firefox isn’t owned by Google: Google merely donates money to Mozilla in return for google.com being the default homepage. They don’t decide what the Firefox roadmap will be, for example. Compare this to the other “major” browsers (IE, Safari and Opera), which are all properietary systems.

Second: Firefox isn’t unsafer that IE. Or Safari. Besides, “unsafe” is a case of PEBKAC, most of the time. Saying that Firefox is unsafe is pure FUD, nothing else. I’ll agree there’s always time for improvement, but you can make the same case for the other browsers.

Third: Firefox neglects other OSes. Oh, great. So we absolutely need to be able to run Firefox on older OSes? That’s plain bullshit. The world and it’s technology evolve and it would be a foolish waste of resources to start supporting OLD OSes. Besides, again, the other browsers don’t support older systems anyway for newer incarnations of said browsers. You can make this case for almost any combination of browser with old-os.

Fourth: Firefox is slow. This seems to be based on a pure emotional reaction only. I haven’t seen any tests or reports that Firefox is much slower than the other browsers. The javascript rewrite isn’t about Firefox being slow: it’s about bringing javascript up to par with compiled languages. The other browsers have the same “problem”.

Fifth: Addons create instability. In other news: clicking on attachments in your mailbox can screw your system over and turn it into a botnet-slave. Too little people realise that addons are actual programs. If you can’t handle your system with some responsabililty, that’s not the fault of the system but of the user of the system. Most of the time, it’s you who screws up. If you are careful with what you install, you don’t run in too much problems (or any problems at all). Nothing new there.

So, all 5 points tackled.

Actually, I think FF3 is the best browser expierence I’ve ever had. Opera may be fast but has too many issues with small incompatibilies. It also lacks a certain something that keeps me from using it more (I have it installed but I never bother using it). It might be the fact that is FUGLY as hell. Perhaps.

I tried FF3, Camino and Safari for a while on my Mac. Camino is good, but too terse, too sober. There’s not a lot of room for customisation. Safari has the same problem, but it’s browsing experience is better than Camino’s. But Firefox wins hands down: the lone fact that it has a “undo close tab” makes Firefox worth the while. And the Awesomebar may seem weird at first, but it’s a real time saver when you get used to it. And there’s a number of small things (menu’s, shortcuts, …) that FF has and the other browsers lack that makes Firefox a great browser. And for stability regarding add-ons: I repeat, mostly PEBKAC. Don’t go installing every extension you discover. Most are niche stuff anyway. If you know what you are dealing with, it’s no big hassle to fix it once something goes wrong (if you need Safe Mode, you screwed up badly enough to deserve it. I’ve never had to go to Safe Mode in FF).

I think FF3 is a top-notch choice for doing your browsing. It’s fast enough, it allows expansion if you need it (nobody forces you to install addons, remember), is one of the most standards-compliant browsers around. Needless to say: I wonder what the future brings…

Ah, nice to see Shoes getting some extra exposure. The latest developments giving us the possibility to actually package a Shoes app as an EXE or DMG is quite essential. “Deploying” a Shoes app was rather cumbersome before: you had to make sure (the correct version of) Shoes was installed, pass the script, directory or shy package to the user. And even then you weren’t sure that double clicking the script would actually run it with Shoes – if the user had Ruby installed, you’d have a problem (potentially).

But with the advent of native packaging this becomes a thing of the past. The packaging itself is a clever hack (on both platforms) and _why‘s working on support for Linux too.

So it might be time to start opening up Twingle after all. Although we’ll have to wait for Twitter IM to return, because it’s quite a useless app without it.

And it’s nice to see your comment featured on Scott Hanselman’s site.

Ah, there’s movement on the PDC website. Good, I was suspecting that’d postpone it again, but it didn’t seem that likely with Windows 7 on the way. But now it’s final: there’s going to be a PDC this year.

I’m keen on going, but I had to think twice when I saw the prices: $2395 for registration only. Wow, that’s a lot. I can’t remember paying that much for PDC05, to honest. But then I thought: I need to do some dollar2euro conversions. And yes, that price seems more reasonable:

2 395 U.S. dollars = 1 543.07068 Euros

That seems better. Given that I’d like to be staying in the Fig, which is priced at $159 and that food in the US isn’t that expensive, the cost of spending a week at the PDC in LA seems fair.

But then, getting there. 3 years ago I flew to LA with British Airways, and it cost me around 600 euros. Checking that same itinerary right now brings the price to 1500 euros. So I’d be spending the same amount of money on getting there as for the conference itself.

I’ll have to check if spending over 4500 euro is worth going to the PDC. At the moment, there’s not that much interesting stuff (for my “core” business) to justify that amount. On the other hand, it’s great fun and a great boost to start developing new stuff – granted that I’ll find the time after the PDC.

I’ll wait a bit more and let it sink in for a bit. I have until August 15^th to make up my mind (supposed that I want to make use of the early bird savings). But I’d really love to go: it was fun in 2005, and it’ll be fun now too.

What Jeff Atwood posted today is pretty much completely true. Amongst other things, I develop websites using PHP. And I frequently have to check the documentation to see how a function is called (because there’s no consistency indeed). But more: even if I know what it’s called (or I’m pretty sure of it), I still have to check how the order of the parameters is. Because there’s usually no consistency there, either.

Luckily there’s syntax highlighting in e so that I know I’ve got the correct function name:

versus:

(notice the coloring of functionexists vs function_exists).

I think I’d probably have the same problems in C# if Visual Studio didn’t have intellisense. Not so much with the language itself, but with the Framework associated with it. So what Jeff says is not only valid for PHP, but for all languages+frameworks these days: there’s so much functionality that it’s hard to get anything done without having to resort to some kind of documentation system (beit Intellisense, help files or the web). The days of (productively) developing something in just a plain text editor are over. And that is PHP’s problem: most of the PHP scripts are created using a simple editor. Why? Because the good tools come at a certain price (e.g. Zend Studio, or Visual Studio). And like Jeff says: most of the PHP scripts are written by basement-locked script kiddies, who can’t (or won’t) afford such an editor.

Visual Studio (and thus VB and/or C#) has a free express edition, which makes it the best choice to develop any .Net code in (unless you want/need the more expensive versions of Visual Studio). While those tools are probably available in one form or another for PHP too, the problem is migitated for Visual Studio because downloading Visual Studio is the preferred starting point to start .Net development. In fact, it’s harder to start developing without Visual Studio.

So there: it’s not only about (framework) inconsistencies, but also about toolset visibility and availability. A good (and readily available) toolset can migitate a lot of the deficiencies of the language/framework used.

It’s been a forthnight since Mollom released their API, and I’ve been working some spare moments on a library wrapper for that API. Given that here are wrappers for Drupal, PHP, Ruby, Java and Python, I figured that a .Net version was missing too. Also, I can use this for a future project, so it’s not a complete waste of (free) time.

Anyway.

NMollom, a wrapper for the Mollom API. Building the library wasn’t really hard, as the API exposes a set of  XmlRpc calls you can use to talk with Mollom. Using a free XmlRpc library for .Net, a proof of concept lib was quickly built. The challenge was however to conceive something that abstracted the details of the API away (mainly the session management) but still keeping the use of the library easy but also versatile. I still like perl’s TIMTOWTDI, so you still have a number of options to work with the API.

The objects that the main API class returns are mostly serializable, so they can be stored in ViewState, or Session, or even Application. Or to a file. This is necessary since we’re dealing with a stateless architecture (the web). Basically, the session_id the various Mollom calls return is kept private inside the objects since you don’t really need to know it’s actual value. Keeping it for reference (for future calls) is the most important thing. That said: you can still read the value if you really want it.

But this is just a wrapper around the Mollom API, and you still need to do quite some work behind the screens to get it working. So the next step is some ASP.Net controls that do the dirty work for you. Using the current wrapper library, of course.

All of this is open sourced under a MIT license. If you want to help or codevelop this, feel free to contact me and I’ll give you access to the repository. Or you can send me a patchfile. Whatever suits you best.

I don’t know if if you know Skitch, but it’s a tool to share images from your desktop with people online. It’s sort of a fancy screenshot tool with the ability to post to the web (there’s more to it, but that’s all that matters for now). Pretty handy, but the problem is that it’s Mac only.

I use a similar tool on my Vista installation: WindowClippings by Kenny Kerr. Basically a fancy screenshot maker, but it’s a lot better than the standard tools in Vista, so I use it quite a lot. The best part is: it supports addins.

And so I decided to create a “Send To Skitch” addin for WindowClippings. Skitch has a maildrop function: send a mail with an image to a specific skitch.com mail address and it appears in your skitch stream. It’s currently the only way for non-Mac users to have the Skitch experience. But combine the Skitch maildrop functionality with the SendTo addin function of WindowClippings and we’ve got magic:

You have to provide some settings, of course: first of all the email address of the skitch maildrop (you can lookup this up in the maildrop section of your skitch settings) and secondly the hostname of the smtpserver to use to send the mail. There’s no way to find this out automatically easily, and it works for me for now,  so I’ll leave it at that. I might create a webservice that sends the mail for me, so that I don’t have to bother with the smtp server, but that’s maybe something for a next version. You can set both settings in the “Add-In Settings” of the Skitch addin. There’s no checking if these are actually correct, so when you’re not getting uploads in your skitch stream, the values you provided might be wrong.

Anyway, you can download the DLL here. Place it in the same folder as WindowClippings.exe, choose “Register Addin” in the Addins tab, select the SendToSkitchAddIn.dll. The Addin should now appear. It’ll say: inactive, because you didn’t provide any email+server combination. Fill those in (using the Add-In settings button) and you’re set.