When it comes to the production environment it is a real test for the application as the users start using the application. It is very important that the performance of the application is something that has to be proactively measured and is a continuous constant effort to get the production environment fine tuned to the need. As far as Rails is concerned there are few insights here and there on the scalability and performance of the application. Stefan Kaes has written a package called Railsbench consisting of some Ruby and shell script code that can do some performance measurement of Rails application. Complementing the plugin is this article by Stefan on “A Look at Common Performance Problems in Rails” that talks about some common performance problems. But as mentioned by Stefan in the article some analysis of the performance of the application is necessary to apply the relevant changes to the application.

If you are new to Rails application development then troubleshooting even the common mistakes and errors might be difficult. The Ruby on Rails Wiki has a “TroubleShooting Rails” page that has solutions for common starting trouble problems. Bookmark the page, just in case you are stuck.

I have been writing few posts on troubleshooting. I thought why not a mind map of what I would do when I am stuck with during development. Remember what really means to get stuck is when does not even know what the problem is. Usually when we know a problem we can work on the solutions. But a lot of times during development you know things are not right but you don’t even know what is causing things to go wrong. That’s when someone is really in troubleshooting mode because to fix it one has to find out what the problem is. I quickly drew a mind maps of where I would look for a problem and then document and track the whole process until I find the solution. Hope this mind map helps.

Click this link “Troubleshooting - Mind Map” to view the map. Click on the Original Size link to view the map clear.

Note: - If you are new to Mind Maps look at the series of posts on Mind Maps.

During development when some issue blocks the progress most often it is not a single step fix that solves the issue. There might be several things that need to be done to really address and fix the issue.  This might even involve backtracking previous steps and altering some statements/dependent programs/input values etc. And more than likely some nasty issues can take a while altering and backtracking and at one point things might get set and the issue gets solved. This could be a time consuming process but ultimately there are couple of home works to be done after fixing any long time issue. One is to understand what the actual problem was and the other is to truly understand the steps that fix the problem. If one had been trying different permutation combination of changes to fix the problem then it is most likely that the actual path to fix the problem maybe too difficult to recollect after finding the solution. In essence the developer might be happy that he/she fixed the issue but may not have done those two home works.  The advantage of doing those home works is the lesson one learns in fixing that issue and most importantly the time that it saves the next time when the same issue is encountered is enormous.  The easiest way to make sure that the steps to fix a problem are captured is to keep open a simple editor and note down each and every step before making it.  The bread crumbs approach helps in two ways. One to retrace back and another is the documentation of steps to fix the problem. In fact if the fix to the issue runs for days there is no harm in version controlling this whole bread crumb document.

I have gone through nerve cracking troubleshooting situations and finally ended up identifying the problem to be a silly typo mistake.  It is something that every developer goes through at least once in his/her lifetime. In some programming languages and scripting languages the variables need not be declared and can be directly used. In such languages there is a high chance that somewhere a simple spelling mistake in the variable could cause everything to go wrong because the misspelled variable becomes another variable.  In effect the statement containing the misspelled variable name can cause unexpected outcome that may become very difficult to troubleshoot.  And if the program does not throw up any error and executes successfully but the outcome is not what is expected then it can become challenging. The best way to handle such a situation is to log the values of variables at key points of the code and isolate the statement that contains the misspelled variable.

Read my other Troubleshooting Tips.

During development normally the thought about performance of the application does not come to mind. That is because you test your code in your own desktop and if everything works functionally you move on. Some of the performance problems might show up during the load/stress test of the application by the quality team. But one problem that can really take a lot of time to find out is a memory leak. This is very common in web applications if not been thought and tested out before hand. A web application receives multiple requests hitting the server. Each request is treated as a thread that spawns a process in the web server and loads the appropriate objects from the application. When the response is sent, the objects loaded have to be released to clear up the memory.

Think about this, a web application continuously will keep receiving requests as long as the web server is up and running. If after a request is complete a used by the request doesn’t get cleared then for every request there will be an object residing in the memory till the web server’s life goes down. Now how can this happen? Why doesn’t the web server or the component that is responsible for handling that particular technology/programming model take care of it? The answer is it does but if you do not clean the object references and/or keep the scope of the objects in such a way that it is marked for removal once the execution comes out of that scope, the component that takes care of removing the object will think the object is still in use and will not remove it from memory. So if your web application project has gone live and after some time if you are hitting the memory limits then your application might be leaking. So it is imperative that the application be tested for memory leaks beforehand. There are tools that can determine if there is a memory leak in your application. Refer “Memory Leaks” in wikipedia that has detailed explanation as well as some good pointers.

SQL Injection happens when keywords/characters specific to the database requests are injected via user input.  The best example to explain about SQL injection would be the search text box in a web application.  We know that some of the characters in SQL query are used for special purposes.  Say for example the “%” in a query that uses like keyword matches anything.  Suppose if I give a search text as “Hello %” and click on search the application that does not avoid SQL injection might bring results that has “Hello” followed by anything.  What I might really want is to bring results that actually contain “Hello %”.  The search example was a simple scenario; think about critical applications like banking applications.  If the input is not scrutinized for SQL injection the result could be catastrophic. Few languages provide built in functions to escape SQL injection before an input from user is passed with the query.  Refer Vlado’s blog on SQL Injection for good reference links.

You are very sure that you have written the program syntactically right, logically right, but the output doesn’t seem to be the one you are expecting. You think that the logic is correct and the input is correct but still you dont get the expected output. One of the possibility for the failure of your code could be a side effect of a certain statement. Maybe you are hearing this term for the first time, but I am sure after looking at the below example you would say “Oh is this called side effect?”

public void foo(int x, int y) {
  if (x > 30 && (y=x*2) > 30) {
    x = x + 10;
  } else {
    x = x + 5;
  }
}

Assuming the above code is a java code, if I pass a value of 10 and 30 to x and y respectively what values of x and y do you expect once the if condition is executed? If your answer to this was 15 and 60 for x and y respectively then you are wrong. What happens here is a side effect. Remember the truth table of logical gates? Lets look at the truth table of AND gate.

What it signifies is that if both the inputs are true then the output of AND is true, but otherwise even if one of the input is false then the output is false. Now consider in a condition when the first expression evaluates to false. Since the result of the overall condition is going to false, there is no use in evaluating the second expression, hence the second expression is not evaluated at all. In software engineering terms this is called short circuiting. Side effects could come in different forms and short circuiting is one of them. Side effect depends on the programming language execution style as well. Be on the lookout for one when you write the code. Side effect could happen when you try to use short cuts and try to be more cryptic in your code. In the above example the expression y = x*2 should be taken out of the if condition for the expected result.