As a .Net developer you can choose from a variety of logging frameworks. All are more or less built to mitigate the shortcomings of the built in tracing framework. While System.Diagnostics.Trace has some helpful concepts, it misses many basic features most other logging frameworks can offer out of the box.
Log files could be a great place to find the answer on what went wrong in our applications. They should contain all the necessary information to understand the state of the application before and while the error happened. Instead most log files are giant collections of data without much structure and even less meaning. What is unfortunate in one single application is a problem as soon as multiple applications need to work together.
As a little distraction from writing I was procrastinating on Hacker News and Reddit. The blog post “Why are we interviewing Developers by asking Architect questions?” caught my attention and got me thinking about the term "maintenance developer". Those mythical species of developers who are so insisting that their work is so fundamentally different from all other things that developers do. As Ted Winslow points out they should not need to know anything about architecture. Others think they don’t influence the code and therefore don’t need training. Visiting a conference is a waste of time, then all they do is maintenance…
Geofences are a nice feature that can help you to focus on important things based on your location. At work you care for other things than in the supermarket. Showing your groceries list is a help there, but at work it's a distraction at best. Applications that support geofencing can help us when the technology is used wisely.
This year's NDC Oslo was once more a remarkable conference. Great speakers doing 9 parallel tracks for 3 days crated an enormous amount of content. So far I can give you an overview on the sessions I attended. It will take me some time to catch up on all the other sessions I want to watch. Those sessions will be part of another post in a few weeks.
The videos of the NDC can be found on Vimeo. I can highly recommend the presentations I mention in this post. With many more to watch I'm happy for any recommendations.
The next version of RavenDB will have some exiting new features. Beside many optimisations, improvements and new functionality you will get a new RavenDB Management Studio. Dropping Silverlight is only one of many improvements you will notice. Let's have a look on what is changed and how much still works as expected.
Dogfooding, as in use your own software, is a great way to find the pain points in your product. When you build a project management tool you could track its progress within that tool. If you are annoyed to insert the same values over and over again so might be your users. To improve this small part not only makes your life easier, but also helps the other users.
I'm using Kanban since 2011 to organize my work. From everyday tasks to small software projects and big holiday trips I could leverage the power of a simple and hassle free approach to reduce my work in progress. With less work in progress one can concentrate on getting the work done and is not constantly rescheduling it as part of an unsuccessful attempt to do multi-tasking.
Even if Kanban is a success for me, I had the feeling that something is missing to adapt Kanban in a bigger software project. When people with different responsibilities work together there need to be some common rules on how the work should be done. Plain Kanban doesn't answer this.
When you develop a web API and a client for it at the same time you often run into errors. But where did they happen? In the API? Or in the client? It would be a simple thing to pinpoint the source without that many moving parts. A stable client that works would be a great help. But where can you get one flexible enough to handle your API?
As it turns out there is a great extension for the Chrome browser that could save you hours. With Postman you have all the flexibility you need to test your API, and it is stable enough to find the errors in your API.
Changes in the application often result in modifications of underlying data structure. Properties need to be added, removed or renamed when your application adapt to the new business needs. Today you will see how RavenDB handles this use case and how this differs to a relational database.