• Passed the C# 70-483 exam (MCP)

    Passed the C# 70-483 exam (MCP)

    Today, after a few weeks of preparation I passed the C# 70-483 exam and became a Microsoft Certified Professional. Woohoo! :)

    Besides getting a cert, was it worth it? I would say in case of this particular exam – yes. I was already familiar with many topics covered by the exam but it did fill some gaps in my C# knowledge. And I enjoyed learning the new bits. It also did feel like I had to learn some details by hard at some points, which was less enjoyable.

    What did I use to prepare myself? I used the official practice exams from measureup, the 70-483 ref book, the Wrox Certification Toolkit book for this exam, in a few cases the official documentation and of course – StackOverflow. I feel the practice exam was very beneficial, the official ref book was also helpful but in my opinion very badly written. It’s as if the book has no structure and as if the authors didn’t communicate between themselves so that would make sense and so you could learn in some kind of logical order. Instead, the book jumps between topics in an unexpected way. The Wrox book was ok. I didn’t go through it in full detail, but read a few bits and pieces where I felt I wanted to get more details which I haven’t been satisfied with by the ref book. Both books seem to be riddled with various mistakes in code.

    Overall, I’m very happy I studied for this exam and that I passed. If you’re considering doing it – do it, you’ll be happy to learn new things and it isn’t really that hard but be prepared to put some time in it. Good luck! :)

  • Contributing back – InfluxData.Net NuGet

    Contributing back – InfluxData.Net NuGet

    On project that I currently work on in Dovetail, we’re using the InfluxDb time-series database. And it’s a really cool thing to be working with.

    Recently we had to move to a newer version of InfluxDb and the library that we were using at the time became a bit stale and didn’t support the newest version of InfluxDb (v0.9.6) which we had to move to. So, partially out of necessity, and partially “because I can” and wan to, I decided to update the currently existing library and then re-release it as a NuGet package under a slightly different name.

    *drumroll* – the code for the InfluxData.Net NuGet is available on Github. It already had a few code contributions which is quite exciting. The whole codebase has been refactored, additional tests written and I believe that the codebase is now quite stable. I plan on expanding the library API to support most of the stuff that InfluxDb provides, and I also plan on implementing the API’s for other InfluxData products such as Kapacitor and Telegraf.

    If people keep using it in the future, I’ll consider it a success and it will make me happy. :)

  • Enhancing RESTful WebAPI controllers with RPC style endpoints

    Enhancing RESTful WebAPI controllers with RPC style endpoints

    During the setup stage of the new project I’m working on, the decision was made to try and use RESTful WebAPI controllers that would support RPC style endpoints as well. I did a bit of research and found a nice post from Carolyn Van Slyck that explains how this can be achieved by creating a few different routing rules in the WebApiConfig file. I wasn’t however fully satisfied with this approach so I tried to do it in a different way.

    If you follow .net’s WebAPI conventions, you can simply write action methods that start with http verbs (GET, POST, PUT, DELETE) and everything will work out of the box with the default WebApiConfig setup. For example you can name your RESTful action methods something like GetAllProducts, GetProduct, PostProduct, etc… No extra action route attributes (such as RoutePrefix, Route, HttpGet/Post/Put/Delete) are needed for this approach. WebAPI will in this case expect the correct http verb.

    However, as soon as you add a custom action, it will start causing problems (you will start getting the infamous “Multiple actions were found that match the request” response). Say you add CustomGetEndpoint method – this will cause GetAllProducts and GetProduct to not work any more. Luckily by adding a few things we can make it work.

    The first step is to enable attribute routing in your WebApiConfig:

    The second step is to add the RoutePrefix to your controller and to add the Route and http verb attributes to all your custom RPC actions (they of course don’t have to start with “custom” but you can name them whatever you want):

    In this case ProductModel is very simple:

    Keep in mind that if you are using a BaseApiController class which inherits .net’s ApiController, ensure that all your methods are protected. If you make your BaseApiController methods public, this will mess up the routing and you will start getting the “Multiple actions were found that match the request” response (took me long enough to figure that one out!).

    That’s all folks, you can now enjoy both worlds at the same time. Enjoy!

  • Automatic WebAPI property casing serialization

    Automatic WebAPI property casing serialization

    If you work a lot with WebAPI’s and JavaScript and would like to follow the convention of lowerCamelCasing your JSON and UpperCamelCasing your .net model properties, you can do that by using Newtonsoft.Json CamelCasePropertyNamesContractResolver. This works for both directions “WebAPI -> client” and “client -> WebAPI” so that’s cool as well. You should simply set this up in your Global.asax and you’re good to go.

    Well that was an easy one. It was also my chance to try out the Gist GitHub ShortCode plugin. I think it works great, and it’s easier to use. I like it! And if you’re using WP, you should try it as well. Hopefully if won’t take me too long to migrate everything from the Code Colorer plugin that I’ve been using so far. :)

Back to top