Posts

Showing posts from June, 2013

Static constructors and sealed classes - how to make your code untestable

Image
In almost all programming languages there is a possibility to put some application logic in static constructor. However, it's usually up to the platform to decide when to execute the code we put there - usually it happens when we the environment runs a piece of code that refers that class. Recently I was reading through the Windows Azure Training Kit (written by Microsoft) and this is a piece of code from the kit: public class GuestBookDataSource{ ... static GuestBookDataSource() { storageAccount = CloudStorageAccount .Parse(CloudConfigurationManager.GetSetting("DataConnectionString")); CloudTableClient cloudTableClient = storageAccount.CreateCloudTableClient(); CloudTable table = cloudTableClient.GetTableReference("GuestBookEntry"); table.CreateIfNotExists(); } ... } This code will open or create a cloud SQL table before accessing anything around it. As the code runs only once, it's seems like an efficient way to do the initialization of the ...
Image
One of my projects uses a self hosted executable that is accepting incoming connections on port 80. The package has an embedded Jetty so I didn't need to deal with any low level TCP stuff. That is the good part. The bad part is that it turned out that the hosting environment (Ubuntu linux) for security reasons by default does not allow a non-root user to use any TCP port below 1024 - so the first free for all port is 1024.                                                                                                                           One easy solution would be to set up Nginx and forward the traffic it receives on port 80 to my self hosted app on a different port. Quite e...

Are we developers the romance writers of the science world?

Image
As developers we tend to do repetitive, sometimes tedious labour every day. We stand at a scrum/kanban board every morning pretending the problems we are facing are interesting, hard and we are the only solution to them. Maybe we think we are the smartest in our team. Maybe everyone in that team thinks he is the smartest. Anyhow, the job we have to deliver as an everyday developer relies roughly on the same technologies. We like it or not, but most of our work is based on someone else's work, someone else's idea, methodology. It's so rare that we, as everyday developers can add something brand new that wasn't there before. And no, a HTML5 progress bar is not all that new. And no, creating a iPhone app that uses Facebook login is not new either. But if we are not really in the invention part of the game, surely the people at the big fancy IT companies are, right?                                  ...