Oct 13

My links of the week – October 13, 2013

This weeks links cover multiple subjects from to NoSQL to Performance Tuning and  Responsive Design.

  • Buck Woody’s Data Science Laboratory System – Document Store Databases is the 9th article on a series hosted on the Simple Talk website, on setting up a Data Science Laboratory server. The whole series is a great read. In this article, the concept of a document store database is presented. The system chosen for the server is MongoDB and the author provides a brief walk-through of the installation process and includes links to multiple useful references on MongoDB. An excellent read.
  • Microsoft’s Patterns and Practices Team Data Access for Highly-Scalable Solutions: Using SQL, NoSQL, and Polyglot Persistence is a guide to on how to design and build applications and services that can take best advantage of SQL and NoSQL databases by combining them into a polyglot solution. It provides an end to end walk-through of a business application that uses SQL Server with a variety of NoSQL databases, showing how the designers selected the databases to closely match the various business requirements.
  • Brent Ozar’s Performance Tuning kCura Relativity is an excellent overview on how to approach performance tuning in a real world case and includes links to other useful resources for performance tuning. A great article on performance tuning.
  • Jes Schultz Borland’s Get a Report of Your Server’s Top 10 Worst Queries provides a guide to finding a SQL Server server 10 worst performing queries, and building a report with the results, using SQL Server Reporting Services. The article includes additional links that may be of use, even to tune the offending queries, once you find them. A good read.
  • Allen McGuire’s My DBA Toolbox is a good example of a DBA toolbox. Includes links to tools, scripts, articles and blogs that should be present in a DBA’s arsenal.
  • SMG Research Reveals DBA Tools Not Effective for Managing Database Change is an unsigned article that addresses some findings of a study that “examines the views of application development and deployment professionals in large organizations with $100 million or greater in IT department spending”. Including in the findings is the high number of organizations surveyed that feel that the DBA tools available are not very effective dealing with database application changes. The article includes a downloadable infographic with some interesting and surprising figures. A very interesting read.
  • Kenji Hiranabe’s Modeling in the Agile Age: What to Keep Next to Code to Scale Agile Teams raises the question of whether modelling is still useful, in an age where Agile methods are mainstream and working code and tests are considered the most important team artifacts. The article proposes a strategy to overcome the difficulties of making models live beyond conversations, based on keeping “big picture models” on architecture, domain model and key use cases. An excellent read.
  • Rockford Lhotka’s Does .NET Have a Future? addresses the future of .Net as a relevant technology. The author’s opinion is that not only .Net, but also Java and the underlying operating systems (Windows, Unix / Linux) will gradually fade away into “the misty twilight of time”. The article explains how this relevance fading will occur and how developers can deal with the this obsolescence and points to Javascript as the alternative platform. An interesting read.
  • Konstantin Lebedev’s So We Wanted To Build A File Uploader… (A Case Study) is an article describing Russian email provider Mail.ru development of a file uploader to overcome the difficulties experienced with their previous Flash based uploader. An attention grabbing article on the development process, up to the final result, a file uploader using multiple technologies and freely available on GitHub.
  • Daniel Mall’s Now With Responsive, is a great walk-through on the conversion process he used to make the site responsive. The article addresses several steps, from CSS to Sass conversion, changing the page location where javascript is loaded, using webfonts and resolution independent graphics. A very interesting read.
  • Rachel McCollin’s Design-Based Media Queries proposes a rethink of the way breakpoints are usually employed in designs. Considering the frequent design-based media queries are becoming untenable,  due to the explosion of devices used and the multitude of resolutions featured, Rachel proposes defining breakpoints based on the design, to make sure that the designs adapt to any devices widths while ensuring readability and to ensure that navigation items are large enough to be used in touch based and mobile devices. A very interesting read.

That’s all for this week. Thanks for reading.

Mar 17

Always chasing the next (software) utopia


The techniques, methodologies and tools at the disposal of those who build software are always improving. New tools are made available, new approaches are presented as the next best thing and often promoted as such. There is nothing wrong with new techniques, methodologies or tools, quite the contrary. We all benefit from such developments, if and when we can properly determine when to use them, considering their advantages and disadvantages.

Most software systems need to use some kind of data store. Traditionally, this data store was a relational database, but the picture has changed a bit in recent years, with the rise of NoSQL databases. NoSQL databases gained rapid acceptance, especially in high scalability scenarios, but they also seem a very interesting option when addressing another common problem faced by software developers – the object relational impedance mismatch.

Accessing the data store, especially a relational data store, as always been a source of problems for developers. Before NoSQL was another option, Object Relational Mappers, such as NHibernate or Entity Framework were offered as possible solutions to the impedance mismatch problem, while offering other advantages. ORMs are still used and their use will sure see a rise, and some ORMs now support NoSQL databases, as well. The overall goal of softening the burden of software developers, when accessing data stores, remains as a valid one, of course.

Sometime ago ORMs started offering Code First Design. While before the ORM would deal with an existing database, Code First Design offered the possibility of leaving the details of choosing and implementing the database structure to the ORM. In theory, this was just another step to set developers free from the tyranny of the storage layer. The problem is that when using relational databases, the mapping is basically a generic one, not taking into account the specificity of the relational database management system, not only in terms of the required indexes to enable the best possible performance, but also in terms of poor choices for the data types chosen to implement some table fields – it’s common to find situations where basically all string properties are implemented as nvarchar(max) fields, in a SQL Server database, which will mean accessing these fields will be slightly more costly to access than length limited nvarchar or varchar fields. The fact is that each relational database has specific characteristics that make generic design by a tool less adequate than a design that takes into account those specific characteristics. This starts with the database design (in Code First strategies) and continues with the usual issues associated with ORM tools, while exploring the database – that is, with the non optimal code generated when querying the database.

Of course, we can always argue that ORMs and Code First Design, as any other tool or strategy, needs to be applied in circumstances where their disadvantages are less noticeable and where their advantages recommend them. This is undoubtedly true. However, if we look at beginners books on topics such as .Net MVC, or tutorial material offered by Microsoft on its web development technologies, examples are almost always given using Code First approaches. I think this conveys quite a wrong idea to programmers starting their own path on such technologies and sometimes the consequences can be serious. I have seen it more than once, in real, production systems and those consequences are not always easy to overcome, at least without some effort.

If there were no performance penalties from Code First Design, or you could establish some degree of control over the generated code, I confess I would be inclined to take advantage of maintaining the data store totally transparent to the code. The reality is totally different though. I understand all technologies need to start, evolve and mature, but I would also like to see less promotion of not as mature technologies, at least without a clear indication of its caveats. ORMs will improve and Code First implementations will, too. At this time, however, the scope of apps where either is more limited then we would be lead to think, in my opinion.

Most systems have to be designed, implemented and deployed in scenarios where we have certain performance requirements and limited computational and financial resources. This is quite common in web applications, where I would think most apps are not cloud scale and need not be. The systems we develop need to be able to work within those limitations and that can be a bit incompatible with our utopias. Naturally, we always need to have utopias we can chase and they can be a driving force for evolution, but it should never be forgotten that we apply technologies in real systems and the negative consequences  of our own utopias should, preferably, be avoided.


Note: The image used in this post was obtained from here.