Share

Something that has bugged me for a significant amount of time is the guarantee that the software you deliver to your client / customer is not going to have an adverse or malicious affect on their business.

If we look at threats like viruses and malware applications we can protect against those. We have tools and scanners that pick up signatures and take the appropriate action. If we look at the vectors of these attacks they are always external. So something from the outside has to get into your machine in order for them to be effective.

First lets do a bit of digging. Generally the biggest threat to any internal business system is not external attacks, it is the internal attacks. How many times have you heard about a disgruntled employee using back doors or knowing how to access the devices remotely and wreaking havoc on the business systems. At a stage this type of attack was considered to be more prevalent and more successful than any other type of attack. The reason for this is a little thing called trust.

When a company employs an individual they entrust certain knowledge to this individual. If the individual is responsible for the I.T. systems then even more trust is placed in them. Unlike computers or routers or any other computational device that supports it, you cannot revoke access to the knowledge that the individual has gained while working on, configuring and perhaps even installing in your infrastructure. Some might suggest a segregation of this knowledge in such a way that one role / position does not have sufficient knowledge to compromise the infrastructure. This might work in larger companies but how do smaller companies manage?

Now lets take a look from a different perspective. What if you develop software for customers. Your code is going to be running in a trusted environment. It might require elevated permissions to perform the tasks that you are expecting it to. Your clients / customers are placing a significant amount of trust in the company you work for and thereby placing a significant amount of trust in your integrity and moral view points. Should a software vendors employees at any stage become upset with the company they work for and decided to teach their employers a lesson the impact on the client / customer could be catastrophic. Yes I am aware that the customer / client can take action against the vendor and in turn the employer takes action against the employee.

My main concern about this chain is how reactive it is. How do you proactively and cost effectively guarantee the code you are releasing will not harm the environment it is being deployed into. Perhaps the idea of paired programming would keep developers in check. The other angle is a dual sign off on a commit to the source repository. Much like banks that require the signature of all partners in a business to authorize spends, dual sign off on a commit would require that two developers approve the code before it is committed to source control. If one developer has some nasty ideas, the second developer can spot them and rectify the code or raise a flag. I don’t see a way that an automated tool could accomplish this. Perhaps it could look for certain signatures and point them out for manual verification but there is no way to decide if something is not supposed to be there.

Either way, if you are entrusted with a code base best you remember that with great power comes great responsibility. Any one with other ideas, please share.

Tweet

Share

Recently I was tasked with doing some investigations as to the best route to go. Now before you go getting all excited I am not going to be posting performance comparisons or declaring an outright winner. What I am going to point out is how to make the decision based on other factors.

As I was looking for feed back on the respective technologies it became very clear that this is a holy war that no one can win due to the emotional attachment to our egos and having to be right and the lack of really clear distinctions between the two.

First lets look at some basic best practise in writing maintainable software:

1. Make code readable
2. Use automated testing
3. Use version control
4. Ensure software is well designed
5. Use less code
6. Encapsulate
7. DRY – do not repeat yourself
8. Loose coupling
9. Write unit tests

This is the essence of what I feel the articles in the reference section encapsulate. The primary reason for writing maintainable code (asides from having to maintain it) is to facilitate change. Businesses are becoming more dynamic and cannot afford to wait for months or years for the implementation of a vision they had. First to market is more important than ever with smaller businesses finding it easier to compete due to software and the internet.

Now the generally preferred structure of a software application is view layer, business logic layer and data layer. If designed properly one can very easily attach multiple views for different platforms to the solution without having to reengineer the business logic. The data stores can also be swapped out with relative ease or perhaps extended to include other data stores.

So what is a stored procedure? According to wikipedia: “A stored procedure is a subroutine available to applications accessing a relational database system. Stored procedures (sometimes called a proc, sproc, StoPro, StoredProc, or SP) are actually stored in the database data dictionary.”

Now the benefits claimed with using stored procedures have always been related to performance. It is a common belief that stored procedures run quicker than generated SQL. While this might be the case with an experienced writer, I have had the distinct displeasure of seeing it go horribly wrong as well. This does not mean that I have not seen it happen in code but generally it is easier to fix the code than the stored procedure due to the unit tests. When changing a stored procedure inevitably you are going to have to change code. When changing DB structure you will have to change all the procedures that use that dataset and the code that maps to it.

Now let us get out of the emotional stuff and start comparing apples with apples.

If we have a look at the the description above on how to write maintainable code let see how stored procedures match up.

1. Make code readable – Well no, it is a structured query language. While it looks like bad English sometimes it can be difficult to read.
2. Use automated testing – I haven’t seen a way to automate the testing of stored procedures
3. Use version control – I have not seen a way to handle versioning of stored procedures with ease
4. Ensure software is well designed – Being procedural in nature there is very little design that can happen
5. Use less code – There are certain things you can do in code you can’t do in SQL. So you might end up having to write far more SQL to facilitate it.
6. Encapsulate – While some might argue that the procedure is encapsulated in the database I would argue that the logic is not encapsulated where it should be.
7. DRY – do not repeat yourself – With having to name tables and operations continually there is a great deal of replication happening
8. Loose coupling – Can stored procedures be interchanged between database vendors? Well yes, if you haven’t used vendor specific functions. It is also tightly coupled to the database unfortunately.
9. Write unit tests – I would if I could! Haven’t seen this in Stored procedures.

I am not going to run the code through the same assessment as we all know that code supports all the above. Right lets get into the next point. While stored procedures might perform better, does the saving from the performance increase compliment the additional cost of maintenance attached by using stored procedures? The next question we need to ask is this. How safe is it to have business logic reside inside the database as opposed to the code base? What the you had specific rules for the same entities in a database? You would have to replicate the initial procedure and fine tune it for each entity. Now should the shared logic change you have multiple places you need to go and change. Not good!

I am not going to go into data parity mismatching either as that is a seperate article all toghether! Just know that it is there.

Lets look at it from the other side. Yes generating SQL to query a database has a certain amount of overhead. That is the only concern that people have. Let me say that again, the only con that using code over using stored procedures has is the performance aspect. So what do we do? Well lets have a look at another definition: “"Premature optimization" is a phrase used to describe a situation where a programmer lets performance considerations affect the design of a piece of code. This can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing.”

Is this not what we are doing when we allow the decision to use stored procedures affect our system designs? How about we try this from now on. Lets write the application first, get it working properly (even if it is a single feature) and release it. Once we identify bottle necks we begin to optimise the bottle necks. This might very well include using stored procedures! Lets get out of the dark ages folks. There is no right or wrong in this realm. There is only deliver on time or don’t. Lets deliver on time Perfection is generally a refining process any way, expecting it on the initial iteration is absurd.

Just to clear up any ambiguity. This article does not serve to prove or disprove the use of SQL and stored procedures. The point of the article is to make you aware that using stored procedures needs to be handled the same as writing code, carefully, with a liberal serving of caution and most of all making sure that what you are gaining is worth what you spending to gain it. Store procedures have their place, as do ORM, procedural languages and hot dogs (in my tummy!)

References:

• http://www.basilv.com/psd/blog/2006/how-to-create-maintainable-software
• http://www.advogato.org/article/258.html
• http://www.crazysquirrel.com/computing/java/basics/maintainable-code-part-1.jspx
• http://haacked.com/archive/2007/01/09/Writing_Maintainable_Code.aspx
• http://codebetter.com/jeremymiller/2006/12/06/on-writing-maintainable-code/
• http://en.wikipedia.org/wiki/Stored_procedure
• http://en.wikipedia.org/wiki/Premature_optimization#When_to_optimize

Tweet

Share

More JSON goodness! While doing my tests using the Jasmine framework I started noticing in my code that the data I was submitting needed to be serialized from a JavaScript object to a JSON representation. One would think that this might be real easy but alas, it seems that only the newer versions of the browsers implement the stipulated methods to serialize the object.

Even everybody's favourite JavaScript library, JQuery, doesn’t implement a mechanism to do this. (check out http://stackoverflow.com/questions/2277405/json-stringify-missing-from-jquery-1-4-1 for further discussions and http://api.jquery.com/category/utilities/ for confirmation)

So I started going through posts and pointers from other developers. The first set of posts I read used a customised mechanism of serializing the object (http://blog.stchur.com/2007/04/06/serializing-objects-in-javascript/ and http://www.sitepoint.com/javascript-json-serialization/). While this looks very cool I wasn’t willing to replicate the functionality just in case I missed something.

Then I came across http://www.json.org/js.html which defined a mechanism to do what I needed but I still wasn’t convinced. So after a while of reading I came across (http://stackoverflow.com/questions/2277405/json-stringify-missing-from-jquery-1-4-1 –> last post which points to http://code.google.com/p/jquery-json/). HOOAH! This did exactly what I wanted and wrapped it up nicely.

So off I go implementing the methods using the functions provided in jquery-json. The more I did, the less I liked it. The code was starting to smell a bit. So instead of doing the the following over and over and over:

   1: //Convert to JSON string

   2: var jsonString = $.toJSON(myObject); 

I decided it would probably be better to wrap the entry point into this mechanism into a single entry point for my application. Allowing me to swop out the implementation if need be without having to remove/rename a stack of references. So it ended up looking like this.

   1: //Back to my handy helper class :)

   2: function Helper() { }

   3:  

   4: //Convert JSON to object

   5: Helper.getObject = function (jsonString) {

   6:     return $.evalJSON(jsonString);

   7: }

   8:  

   9: //Convert object to JSON

  10: Helper.getJson = function (object) {

  11:     return $.toJSON(object);

  12: }

A great deal of people might think this is over complicating it, adding an unnecessary layer etc. I would argue that it decouples my dependency on the jquery-json library or at least isolates it’s usage to one location. As pointed out previously, should I need to call a different library I would only have to change it in one file. Nothing really fancy about the code but might spark other ideas. The jquery-json library also implements a secureEvalJSON which seems to prevent possible abuse of the JSON returned. With that being said I am going to change my getObject implementation to use it

References:

http://code.google.com/p/jquery-json/

http://www.metaltoad.com/blog/using-jsonp-safely – interesting post on JSONP security

Tweet

Share

Ok don’t get misled by the title. What I am getting at is the more I learn about agile the more I am beginning to realise that it is merely a scaled down version of things that we used to do (perhaps still do). It is merely a means to getting more through put from a development team. This works quiet nicely in a web environment and systems that the owning company continues to build. I cannot however seeing it work for larger scale applications that get put on shelves and re-sold. I also read a very interesting article on mistakes companies make when adopting agile and couldn’t help but smile. Seems the only time we are productive is when we do everything that goes against our human nature. Read the article here

Anyways, one of my colleagues and myself are giving the paired programming and TDD (test driven development). I must say, that the two days we have done this and the features we have developed in the two days, are clean, neat and down right lean and mean. Lovely to look at and watch run. The best part about it all? It is fun, really it is a great deal of fun doing it this way. Bouncing ideas, pushing ideas, implementing the ideas. Finally, development is fun again!

Tweet