Windows Live Writer beta 2

After such a long time we got Windows Live Writer beta 2 available for download. One thing you'll immediately notice is much improved user interface (snapshot taken in Vista).

image

I am just not sure where is the spell checking option now.

Here is a list of other improvements:

New Authoring Capabilities

  • Inline spell checking
  • Table editing
  • Ability to add categories
  • Page authoring for WordPress and TypePad
  • Support for excerpts and extended entries
  • Improved hyperlinking and image insertion
  • Paste Special
Integration and Compatibility
  • SharePoint 2007 support
  • New APIs enabling custom extensions by weblog providers
  • Automatic synchronization of local and online edits
  • Integration with Windows Live Gallery
  • Support for Blogger Labels
Plus...
  • New look and feel
  • Available in 6 languages
  • Improved accessibility and keyboard support
  • Many other frequently requested enhancements!

Read more about new features here. I am sure that this is a great news for many bloggers.

Neverending saga of writing data into Program Files folder

Writing application data into Program Files folder is bad. Period. Only the files at install time should be written to Program Files folder.

Otherwise one is facing

  • security issues (i.e. an application could inject code) and
  • practical issues (if one is not an admin then one can't use the application since there are no default permissions for non-admins to write there - application will most probably crash).

For any other data generated by applications there are better locations, such as isolated storage. Program Files folder should contain only files needed to run, eh, programs and not the data generated by those programs. And same is true for registry: HKEY_LOCAL_MACHINE is not a place to store runtime data.

However, not many developers realize these problems and so there are a ton of applications that want to store data next to their executable files. In fact, I stumbled today upon an application that should be written correctly - e-banking for companies, which I use to communicate with my bank. The application goes by name HAL E-Bank/Personal by Halcom, a Slovene e-commerce company (software, services, certificate authority), and is used by many banks in Slovenia. One would expect that such application (written by such company), where security is important, would avoid this amateur mistake. Wrong. They store a plethora of application data in Program Files folder at runtime. Ouch. Bad, bad application. And not to mention also that their executables aren't signed.

Even [MS] realized that this is a huge problem and thus it built Vista with this in mind - providing support for running problematic applications even under normal user account and thus avoiding messing with Registry and Program files folder. The feature is named File System and Registry Virtualization (you'll find more info on Vista security here), but this is another story.

The bottom line is: Don't ever build applications that write data to Program Files folder.

Mountain biking with GPS

I used to mountain bike a lot when I was keh keh younger These days time is more of a luxury and thus I manage only one or two rides per week. On the other hand, I am better equiped now. Sometimes I take my Qtek 2020 PocketPC, Pharos GPS bluetooth and use GPSDash (warning: seems like development stopped a long time ago) utility to display my position on map and to read a ton of other data derived from GPS unit. It is fun and GPS shows position very well, just the altitude is in the range +/- 100m - this is normal as GPS units aren't built for measure altitude (due to satellites position). Anyway, this nice GPSDash utility lets me exporting recorded path to Gogle Earth format. IOW I can look where I rode directly in Google Earth application.

Attached is a clasic tour over mt. Sveta Gora, which has the highest round inclination in Slovenia.

In my downloads section you will find an utility that lets you export OziExplorer maps format to GPSDash's one.

Intel acknowledges that there is a problem with Apple software and their RAID drivers in Vista

I finally contacted [MS] support center about iTunes/Vista/Intel RAID situation (so far I managed to contact only Intel technical support - they said that this isn't a problem in their drivers). Rok, the [MS] support guy, listened to me and after a couple of hours he found this article on Intel's website - a very recent modification of article I guess. Here is an excerpt of interest:

2294301, Timeouts, degraded RAID volumes when playing/transcoding video files in Apple iTunes* and QuickTime* software, Windows Vista

This is hardly surprising after all. The breaktrough is that they acknowledge that there is a problem with iTunes and QuickTime - the same problem we figured a while ago. Intel could see the problem a while ago, too, if they'd looked into the problem.  But they didn't - instead they buried their head in the sand, at least publicly.

The bottom line is that one of the parties involved acknowledged the problem and I suppose it will fix it in near future. Yes, there is a light at the end of the tunnel for us...

UPDATE 17.5.: After a reader posted a comment that there are new drivers version 7.5 I went checking Gigabyte web site and yes, there they are ("original" Intel drivers, not tied to Gigabyte mobos) and so are included release notes - it is clearly stated that they've fixed problems with Apple software. If you trust them, of course (a month ago or so, the technical support guy claimed that this problem doesn't have anything to do with their drivers). The same reader is reporting that the problem is actually gone with these latest drivers. A warning here is in place: Although it is not stated on Gigabyte web site, these 7.5.0.1017 SATA RAID drives are production candidate quality (aka RC version if you are a developer) and not final fully tested without errors (just with known issues). I think I'll wait a bit more, at least until final version is released and more positive reports will appear on the Internet. But if you dare install new drivers and test iTunes, please, don't hesitate to report the outcome (if your computer still boots :-P).

.net will dive into parallelism

According to Soma .net will push for parallelism. This is hardly a surprise as multicore CPUs and multi CPUs are becoming mainstream. Microsoft Research has already some projects that explore the area (Accelerator - technical report, C Omega, Polyphonic C#, ...). But wait, one can already utilize multicore by using threads in a way or another, why would you need additional support? Right, one can use threading, however threading and synchronization is hard to manage and do properly, specially when project grows. Furthermore there is no GPU programming support (besides using it for graphics). That's why [MS] will push for easier and more powerful parallelism.

What about side effects - is it wise to give such a powerful feature in hands of unskilled developers? Imagine a developer who heard that parallelism will speed up the application and so he starts using parallelism for everything. IOW .net is a tool, more and more powerful, but only in hands of a skilled developer who knows how to use it - and opposite is also true, unskilled one can now create a huge mess faster and easier. I am not saying that there shouldn't be implemented, just that developers should use it wisely as any other tool. It is no magic wand.

Anyway, be prepared to start thinking in parallel - you won't escape it in near future.

My ORM presentations at NT Konferenca 2007 (Slovene event)

A year passed like nothing and NT Konferenca, biggest national [MS] event, is here again. This year I'll be all ORM oriented, in fact, I'll give two presentations on topic: LINQ to SQL and ADO.NET Entity Framework (which was recently postponed to 2008  - won't make it into Orcas).

Nedless to say that I am an ORM convert and really excited about ORM products in general. Even more now, that [MS] is LINQing the ORM products. I have deliberately written ORM products because LINQ wave will hit all ORM products, not just [MS]' ones, like Tsunami and this is soooo good - I really can't imagine an ORM product ignoring LINQ for more than three months. IOW writting ORM queries using LINQ will be much more clear, readable and concise - this is huge huge benefit for ORM community (note that using LINQ for ORM queries is just a part of where LINQ shines).

There are two things I have to figure out though:

  • why the heck is [MS] going with two very overlapped ORM products instead of focusing on one and make it great.
  • how to explain to DBAs that ORM product is not a public enemy and a threat to them, at least not when used properly

So, see you there!

Inserting records containing timestamp columns in ADO.NET Entity Framework

In case you are playing with ADO.NET Entity Framework you might have seen that, by default, when you have timestamp columns in a new entity they are being inserted into the database when inserting and saving new entity. This behavior isn't a correct one, since timestamps are server generated, and one gets a clear exception from SQL Server saying:

Cannot insert an explicit value into a timestamp column. Use INSERT with a column list to exclude the timestamp column, or insert a DEFAULT into the timestamp column.

This isn't a bug in Entity Framework or something. It is rather a bug in EDW that doesn't create correct definitions. The fix is rather simple:

  • open [yourefdefinition].ssdl file (formal description of the database)
  • find your timestamp columns, i.e.
  • <Property Name="COLUMNNAME" Type="timestamp" Nullable="false" />
  • add the attribute StoreGeneratedPattern="computed" to each such column, i.e:
  • <Property Name="COLUMNNAME" Type="timestamp" Nullable="false" StoreGeneratedPattern="computed" />

That's it. Make sure you rebuild your code, otherwise updated ssdl file won't be copied to target folder* and application will load the old one.

More on the subject in this thread.

* Note: if you only change non compilable files (such as .ssdl and .msl ones but not .csdl - the later will invoke EntityModelCodeGenerator custom tool that will regenerate entity types and ObjectContext derived class that represents your database and thus force a rebuild) and re-run the application, IDE will know that your application files (compilable ones) weren't modified and it won't re-build the application - it will just run the application. As a collateral effect the modified files won't be copied to target folder and your application will use the older ones.