Marius Gheorghe

Building software : make it work, make it good, make it fast

REST services and documentation

In theory REST is the pinnacle of simplicity. Just a HTTP request (GET or POST) along with the data and that's it. In practice things get a little bit more complicated. The biggest problem i noticed with REST services (apart from having crap documentation most of the time) is that some people writing services expect the passed parameters in certain place but they usually fail to document this. Basically you can pass datato the service "stored" in 3 locations :

  1. as parameters in query string
  2. as custom http headers
  3. in body (either url encoded or a json object for more complex stuff)

Like i said sometime people expect a certain parameter in a certain place but forget to document this. When writing services you'll make the life simpler for all people consuming the services if you check in all 3 places. Overall it just makes things simple.

Another interesting thing i noticed is that , instead of actually writing some docs about how to consume the service, some companies started to offer libraries for this. A few days ago i was looking to do a integration with a SMS provider and frustrated about their docs i've decided to look at their library. Lo and behold it was a 9 (!!!) Mb assembly !!? Curiosity got the best of me and i cracked it open with dotPeek to see what's inside . The service code were fairly small but it had 2 (!!) 3rd party "REST frameworks" bundled up along with their code. Why the heck you i use a bloated library like this ? Just because they can't properly document a web service with 5 frigging parameters ?

Usually people bitch about SOAP (when compared with REST anyway...) but the Microsoft tooling for SOAP was unmatched. Just paste a url in VisualStudio and 30 seconds later you wrote code against that web service without needing to actually look at any kind of documentation. It just worked.

On CSS media queries...

Media queries are a nice (and long overdue i might add) addition to CSS. They allow you to write CSS based on a few simple criteria (there are more but these 2 are the most important) :
- the device orientation (portrait or landscape);
- the device width and height.

The problem is that usually you want to write your CSS a bit more "high level". Writing styles for the device width/height is no good.....usually you want to have different layouts based on the type of device : phone, tablet and desktop. And unfortunately even if you know the type of device your code runs on (by chopping the user agent ) there is no way to write a media query based on that information. Would be really nice to be able to write something like :

@media screen phone

@media screen tablet

Maybe we can write code like this in CSS4. But i won't hold my breath.....

Few tips for writing better CSS

So here's few tips for writing better/cleaner CSS :

- the most important is to start using LessCSS . LessCSS has support for variables and mixins (among other things) which really help with reducing the amount of code you need to read/write while making things a lot "cleaner".

- start with a simple reset (and sensible defaults) style to make sure the markup looks the same on all browsers.

- for deployment split the styles in multiple files (organized by a criteria that make sense in the context of the project. For instance the styles related to entity X go to the file x.less ). There's no point in working on a single giant file. At deployment you can merge all less file in a single one.

- style by element id or class name ? It there's a chance to apply that style to more than 1 element make it a class. Otherwise use the id.

- it kind of goes without saying but use the same indentation everywhere, stay consistent with the naming, use long descriptive names for classes/elements ids (no dumb abbreviations) and generally make the code as easy to follow as possible.

Happy CSSing !

Trunk based development

"Trunk based development" is the style of dev in which you never create branches. Basically there's only the code in the trunk and toogle switches that enable/disable the "features" at runtime. If a feature is not ready, on deployment is configured as disabled and all "UI references" to that feature are disabled/hidden.

Obviously, the biggest advantage (or should i say the only advantage) of this style is that you avoid long running branches and the code merging problems that appear because of them (good luck merging a 2 month branch when there was a big refactoring on trunk. Merging often doesn't really help either). But there are also a lot of disadvantages :
  • PITA to work on a feature that depends on another feature in development which is not deployed yet
  • Old codebases get full of unused toggle switches
  • Testing becomes a lot harder because the permutations of all features in on/off state needs to be tested
  • dependency management gets harder. For producation you may need ver A of a dependency while a new feature in development might depend on ver B of the same dependency. And there's no backwards compatibility guaranteed.

Overall this style of development is interesting but in reality is only feasible when the app is comprised of a few features without dependencies between them. And that is very rare, so most of the time branches are the superior solution.

Powershell aliases are worthless

Powershell aliases are mostly a waste of time. They have 2 big problems :
- you can't alias a command with multiple parameters. Basically you can't have

Set-Alias scxc "svn update c:\work\trunk"

Actually you can set that alias. But it fails when you run it. So as a workaround you'll have to use a function

function scxc()
   svn update c:\work\trunk

Which brings me to the second problem.
- aliases aren't persisted by default. You have to use Export-Alias and Import-Alias between sessions. And here's the kicker : aliases with functions can't be exported and imported correctly.

A much better solution is to skip aliases and add all this stuff directly to your powershell profile (by default you can find it in %userprofile%/MyDocuments/WindowsPowerShell/Microsoft.PowerShell_profile.ps1).
Just edit it and add functions there that act as aliases.

Some thoughts on WinRT 1.0

Overall i'm kind of dissapointed with WinRT. In v1.0 the scope of the API is very limited. When you came to WinRT from the .NET world , you'll be shocked to see how many things are missing. Things that we took for granted in WPF a few years ago. The XAML situation is pretty sad : new XAML parser (whose "error reporting" sucks....everything gets spitted at runtime as XamlParseException with a generic description), no multivalue binding, no UpdateSourceTrigger,no a lot of nice little stuff from WPF etc. Other notable stuff that are missing : sockets, local database (where are you Sql Server CE ?), full reflection etc.

I'm guessing that 3-4 years ago when they started working on this they had to decide between a limited API available for multiple environments (C++, JS and .NET) and a proper API consumed only from .NET .I guess the recently fired Sinofsky had a say in choosing of the first version and now honestly it doesn't seem to me such a great choice. Trying to build the Win32 "follower" in a few years for multiple environments it's a futile attempt. Also it's worth mentioning the ARM support...maybe a few years ago it sounded very nice but today (with Haswell releasing in a few month, ARM support doesn't seems at all that great (and let's face it the ARM devices are not that cheap).

It's interesting to see what will happen next. I guess the Windows 8 rumored "Blue" update (which should be released next summer) will "fix" and expand the API a bit (and the update itself will be pushed by Microsoft asap on existing devices) but i'm quite curios what will happen after that. Will Win 9 continue to "expand" WinRT or they'll start over ?

Fixing the “Unable to activate Windows store app” problem

I had a nasty problem today with Windows 8 dev license and packaging an app for Windows Store. Basically after i have created a package for Windows Store, my Windows dev license expired. I dutifully updated the license and then lo and behold....everytime i wanted to run/debug the solution from Visual Studio i got this :

"Unable to activate Windows Store app. The activation request failed with error 'The application cannot be started. Try reinstalling the application to fix the problem."

Looking at the Event Log i found out that the app cannot be started because it's in state "17". Brilliant.

Googled for this problem and found some stuff here150151. Unfotunately none of those stuff worked for me.
The working fix for me was to create a new Windows Store project , move the files from older one (without Package.appxmanifest, Package.StoreAssociation.xml, *.pfx ) and runs fine now.

Versioning often deployed web apps




Sometimes i deploy Shopkeeper 2-3 times a day. Bringing value to the customer one little step at the time. In this case, obvioulsy, the classic versioning scheme doesn't really works. So, for a deployed version of Shopkeeper, the version is the Mercurial revision id from which it was built.
Here is how this works in practice :

- when i do a deployment build i also generate a file with data about the current revision

- the output is

- and finally displaying the version in the actual customer website:

Building my own

It's nice to be a developer. If no one builds the app i want i can just build it myself. And this is exactly what i have done for Windows Phone 7. Here are my current projects (OSS) :


News for Hackers - a client for HackerNews (code located here159)


Searcher - a simple app that allows you to search using multiple search engines (code located here160)


Unfortunately i can't publish them to the official WP7 marketplace (because i can't create a developer account from Romania) but feel free to try them if you have developer unlocked phone.


HackerNews OSS project for WindowsPhone 7


I really like HackerNews but the WP7 browser is not really the best way to enjoy the site content. So i cooked up NewsForHacker, a OSS app that will hopefully make HN more enjoyable on a WP7 device.

Unfortunately i can't publish the app on Marketplace (can't create a dev account from Romania) so if you think you can help with this, please contact me.