Monday, October 28, 2013
Rails Best Practices
1. gem install rails_best_practices
2. gem install ripper
3. From the root of the project run:
rails_best_practices -f html .
to generate the report.
2. gem install ripper
3. From the root of the project run:
rails_best_practices -f html .
to generate the report.
Invalid command 'SSLEngine', perhaps misspelled or defined by a module not included in the server configuration
This error is caused if mod_ssl is not installed. On Cent OS : sudo yum install mod_ssl
Imperative Vs Declarative Programming
Imperative Programming
Imperative programming is the oldest programming paradigm. It is based on the Von Neumann-Eckley model of a computer. Programs written in imperative programming languages consist of a program state and instructions that change the program state through assignment statements. Program instructions are imperative in the sense of imperative verbs that express a command.
Examples of imperative languages are assembly, Fortran, Algol, Cobol, Java, C/C++. These languages specify a sequence of operations for the computer to execute.
Procedural abstraction and structured programming are its design techniques.
Imperative Program = Algorithms + Data Structures
-- Nicholas Wirth
Imperative Programming + Procedures = Procedural Programming
Procedural abstraction allows the programmer to be concerned mainly with the interface between the procedure and what it computes, ignoring the details of how the computation is accomplished. Abstraction allows us to think about 'what' is being done, not 'how' it is implemented. Imperative language constructs : assignment, conditionals, looping and data structures.
Flowchart can be used to model imperative programs. For example flowchart for computing Fibonacci numbers.
Declarative Programming
Functional languages and logic languages are declarative. Declarative languages such as SQL, Haskell, Prolog describe the solution space. They provide the knowledge required to get there. They don't describe the steps needed to get there.
Reference : Presentation by Computer Science Assistant Professor Mary Ellen Weisskopf
Imperative programming is the oldest programming paradigm. It is based on the Von Neumann-Eckley model of a computer. Programs written in imperative programming languages consist of a program state and instructions that change the program state through assignment statements. Program instructions are imperative in the sense of imperative verbs that express a command.
Examples of imperative languages are assembly, Fortran, Algol, Cobol, Java, C/C++. These languages specify a sequence of operations for the computer to execute.
Procedural abstraction and structured programming are its design techniques.
Imperative Program = Algorithms + Data Structures
-- Nicholas Wirth
Imperative Programming + Procedures = Procedural Programming
Procedural abstraction allows the programmer to be concerned mainly with the interface between the procedure and what it computes, ignoring the details of how the computation is accomplished. Abstraction allows us to think about 'what' is being done, not 'how' it is implemented. Imperative language constructs : assignment, conditionals, looping and data structures.
Flowchart can be used to model imperative programs. For example flowchart for computing Fibonacci numbers.
Declarative Programming
Functional languages and logic languages are declarative. Declarative languages such as SQL, Haskell, Prolog describe the solution space. They provide the knowledge required to get there. They don't describe the steps needed to get there.
Reference : Presentation by Computer Science Assistant Professor Mary Ellen Weisskopf
Friday, October 25, 2013
Error! ncursesw was replaced by ncurses a long time ago, please uninstall 'ncursesw',
$ sudo port selfupdate
$ sudo port upgrade outdated
$ sudo port upgrade outdated
Thursday, October 24, 2013
Solving Problems in Software Development
As software developers we are in the business of solving problems. A problem can be described using multiple representations such as text, diagrams and equations. If you understand the relationship between different representations of a given problem, you will be able to translate one representation to the other. If you are dominant in one representation and when you are given a problem to solve in your weaker representation you can translate into your dominant representation and solve the problem.
1. Understand the Problem
- What do you need to find?
- What are the unknowns?
- What information do you obtain from the problem?
- What information, if any, is missing or not needed?
2. Devise a Plan
- Look for a pattern
- Make a table
- Draw a diagram
- Write an equation
- Work backwards
- Identify a subgoal
- Examine related problems and determine if the same technique can be applied
- Examine a special case of the problem to gain insight into the solution of the original problem.
3. Carry Out the Plan
- Implement the strategies from the plan and perform the computations.
- Check each step of the plan as you proceed.
4. Look Back
- Determine whether there is another method of finding the solution
- Determine if there are more general problems for which the techniques will work.
References:
1. Billstein, Libeskind and Lott have adopted these problem solving steps in their book "A Problem Solving Approach to Mathematics for Elementary School Teachers (The Benjamin/Cummings Publishing Co.).
2. Technically Speaking: Making Complex Matters Simple by Steven Rudich
1. Understand the Problem
- What do you need to find?
- What are the unknowns?
- What information do you obtain from the problem?
- What information, if any, is missing or not needed?
2. Devise a Plan
- Look for a pattern
- Make a table
- Draw a diagram
- Write an equation
- Work backwards
- Identify a subgoal
- Examine related problems and determine if the same technique can be applied
- Examine a special case of the problem to gain insight into the solution of the original problem.
3. Carry Out the Plan
- Implement the strategies from the plan and perform the computations.
- Check each step of the plan as you proceed.
4. Look Back
- Determine whether there is another method of finding the solution
- Determine if there are more general problems for which the techniques will work.
References:
1. Billstein, Libeskind and Lott have adopted these problem solving steps in their book "A Problem Solving Approach to Mathematics for Elementary School Teachers (The Benjamin/Cummings Publishing Co.).
2. Technically Speaking: Making Complex Matters Simple by Steven Rudich
Polya's Problem Solving Technique
Polya's First Principle: Understand the problem
- Do you understand all the words used in stating the problem?
- What are you asked to find or show?
- Can you restate the problem in your own words?
- Can you think of a picture or diagram that might help you understand the
problem?
- Is there enough information to enable you to find a solution?
Polya's Second Principle: Devise a plan
Polya mentions that there are many reasonable ways to solve problems. The skill at choosing an appropriate strategy is best learned by solving many problems. You will find choosing a strategy increasingly easy. Here is a partial list of strategies:
- Draw a picture
- Look for a pattern
- Consider special cases
- Solve a simpler problem
- Make an orderly list
- Use a formula
- Solve an equation
- Guess and check
- Eliminate possibilities
- Use symmetry
- Use a model
- Work backwards
- Use direct reasoning
- Be ingenious
Polya's Third Principle: Carry out the plan
This step is usually easier than devising the plan. In general, all you need is care and patience, given that you have the necessary skills. Persist with the plan that you have chosen. If it continues not to work discard it and choose another. Don't be misled, this is how mathematics is done, even by professionals.
Polya's Fourth Principle: Look back
Polya mentions that much can be gained by taking the time to reflect and look back at what you have done, what worked, and what didn't. Doing this will enable you to predict what strategy to use to solve future problems.
Here is a summary of strategies for attacking problems in mathematics class. This is taken from the book, How To Solve It, by George Polya, 2nd ed., Princeton University Press, 1957, ISBN
0-691-08097-6.
1. UNDERSTAND THE PROBLEM
- First. You have to understand the problem.
- What is the unknown? What are the data? What is the condition?
- Is it possible to satisfy the condition? Is the condition sufficient to determine the unknown? Or is it insufficient? Or redundant? Or contradictory?
- Draw a figure. Introduce suitable notation.
- Separate the various parts of the condition. Can you write them down?
2. DEVISING A PLAN
- Second. Find the connection between the data and the unknown. You may be obliged to consider auxiliary problems if an immediate connection cannot be found. You should obtain eventually a plan of the solution.
- Have you seen it before? Or have you seen the same problem in a slightly different form?
- Do you know a related problem? Do you know a theorem that could be useful?
- Look at the unknown! Try to think of a familiar problem having the same or a similar unknown.
- Here is a problem related to yours and solved before. Could you use it? Could you use its result? Could you use its method? Should you introduce some auxiliary element in order to make its use possible?
- Could you restate the problem? Could you restate it still differently? Go back to definitions.
- If you cannot solve the proposed problem, try to solve first some related problem. Could you imagine a more accessible related problem? A more general problem? A more special problem? An analogous problem? Could you solve a part of the problem? Keep only a part of the condition, drop the other part; how far is the unknown then determined, how can it vary?
Could you derive something useful from the data? Could you think of
other data appropriate to determine the unknown? Could you change the
unknown or data, or both if necessary, so that the new unknown and the
new data are nearer to each other?
- Did you use all the data? Did you use the whole condition? Have you
taken into account all essential notions involved in the problem?
3. CARRYING OUT THE PLAN
- Third. Carry out your plan.
- Carrying out your plan of the solution, check each step. Can you see clearly
that the step is correct? Can you prove that it is correct?
4. LOOKING BACK
- Fourth. Examine the solution obtained.
- Can you check the result? Can you check the argument?
- Can you derive the solution differently? Can you see it at a glance?
- Can you use the result, or the method, for some other problem?
Reference : http://math.berkeley.edu/~gmelvin/polya.pdf
- Do you understand all the words used in stating the problem?
- What are you asked to find or show?
- Can you restate the problem in your own words?
- Can you think of a picture or diagram that might help you understand the
problem?
- Is there enough information to enable you to find a solution?
Polya's Second Principle: Devise a plan
Polya mentions that there are many reasonable ways to solve problems. The skill at choosing an appropriate strategy is best learned by solving many problems. You will find choosing a strategy increasingly easy. Here is a partial list of strategies:
- Draw a picture
- Look for a pattern
- Consider special cases
- Solve a simpler problem
- Make an orderly list
- Use a formula
- Solve an equation
- Guess and check
- Eliminate possibilities
- Use symmetry
- Use a model
- Work backwards
- Use direct reasoning
- Be ingenious
Polya's Third Principle: Carry out the plan
This step is usually easier than devising the plan. In general, all you need is care and patience, given that you have the necessary skills. Persist with the plan that you have chosen. If it continues not to work discard it and choose another. Don't be misled, this is how mathematics is done, even by professionals.
Polya's Fourth Principle: Look back
Polya mentions that much can be gained by taking the time to reflect and look back at what you have done, what worked, and what didn't. Doing this will enable you to predict what strategy to use to solve future problems.
Here is a summary of strategies for attacking problems in mathematics class. This is taken from the book, How To Solve It, by George Polya, 2nd ed., Princeton University Press, 1957, ISBN
0-691-08097-6.
1. UNDERSTAND THE PROBLEM
- First. You have to understand the problem.
- What is the unknown? What are the data? What is the condition?
- Is it possible to satisfy the condition? Is the condition sufficient to determine the unknown? Or is it insufficient? Or redundant? Or contradictory?
- Draw a figure. Introduce suitable notation.
- Separate the various parts of the condition. Can you write them down?
2. DEVISING A PLAN
- Second. Find the connection between the data and the unknown. You may be obliged to consider auxiliary problems if an immediate connection cannot be found. You should obtain eventually a plan of the solution.
- Have you seen it before? Or have you seen the same problem in a slightly different form?
- Do you know a related problem? Do you know a theorem that could be useful?
- Look at the unknown! Try to think of a familiar problem having the same or a similar unknown.
- Here is a problem related to yours and solved before. Could you use it? Could you use its result? Could you use its method? Should you introduce some auxiliary element in order to make its use possible?
- Could you restate the problem? Could you restate it still differently? Go back to definitions.
- If you cannot solve the proposed problem, try to solve first some related problem. Could you imagine a more accessible related problem? A more general problem? A more special problem? An analogous problem? Could you solve a part of the problem? Keep only a part of the condition, drop the other part; how far is the unknown then determined, how can it vary?
Could you derive something useful from the data? Could you think of
other data appropriate to determine the unknown? Could you change the
unknown or data, or both if necessary, so that the new unknown and the
new data are nearer to each other?
- Did you use all the data? Did you use the whole condition? Have you
taken into account all essential notions involved in the problem?
3. CARRYING OUT THE PLAN
- Third. Carry out your plan.
- Carrying out your plan of the solution, check each step. Can you see clearly
that the step is correct? Can you prove that it is correct?
4. LOOKING BACK
- Fourth. Examine the solution obtained.
- Can you check the result? Can you check the argument?
- Can you derive the solution differently? Can you see it at a glance?
- Can you use the result, or the method, for some other problem?
Reference : http://math.berkeley.edu/~gmelvin/polya.pdf
Saturday, October 19, 2013
What vs How in Test Driven Development
Example #1 for What vs How
Music sheet is not music. It is description of music. This is the 'What' or Logical Design.
Music is played using musical instruments. This is the 'How' or the Physical Design. There are many physical designs for a given logical design.
Example #2 for What vs How
John Lennon wrote the song Come Together. This is the 'What'. The examples of 'How' in this case are the performances of :
- Beatles
- Aerosmith
- Michael Jackson
to the same song Come Together.
Separate Logical Design from Physical Design
How do you separate What from How in our code? Chris Stevenson's TestDox style expresses the subject in the code as part of a sentence.
- A Sheep eats grass
- A Sheep bleats when frightened
- A Sheep produces delicious milk
- A Sheep moves away from sheep dogs
This can be automatically converted to specifications in code :
describe Sheep do
it 'eats grass'
it 'bleats when frightened'
it 'produces delicious milk'
it 'moves away from sheep dogs'
end
When you think about the system from outside-in fashion you focus on intent. You focus on what you are doing rather than the implementation which is the 'how'.
References
1. Test Driven Development: Ten Years Later by Michael Feathers and Steve Freeman on
Fun Stuff
Search YouTube and watch the videos for Come Together performed by The Beatles, Michael Jackson, Aerosmith and Elton John
Music sheet is not music. It is description of music. This is the 'What' or Logical Design.
Music is played using musical instruments. This is the 'How' or the Physical Design. There are many physical designs for a given logical design.
Example #2 for What vs How
John Lennon wrote the song Come Together. This is the 'What'. The examples of 'How' in this case are the performances of :
- Beatles
- Aerosmith
- Michael Jackson
to the same song Come Together.
Separate Logical Design from Physical Design
How do you separate What from How in our code? Chris Stevenson's TestDox style expresses the subject in the code as part of a sentence.
- A Sheep eats grass
- A Sheep bleats when frightened
- A Sheep produces delicious milk
- A Sheep moves away from sheep dogs
This can be automatically converted to specifications in code :
describe Sheep do
it 'eats grass'
it 'bleats when frightened'
it 'produces delicious milk'
it 'moves away from sheep dogs'
end
When you think about the system from outside-in fashion you focus on intent. You focus on what you are doing rather than the implementation which is the 'how'.
References
1. Test Driven Development: Ten Years Later by Michael Feathers and Steve Freeman on
Fun Stuff
Search YouTube and watch the videos for Come Together performed by The Beatles, Michael Jackson, Aerosmith and Elton John
Test Driven Development Background
What is Test Driven Development?
You write a test first before you write the code. You use the tests to drive the design.
It uses one of the XP concepts : Test-First programming to achieve another XP concepts : Emergent Design.
In Emergent Design you start delivering functionality that has business value and let the design emerge. You will deliver functionality A with unit tests and then build functionality B. Then refactor to reduce duplication due to A and B and let the design emerge.
Origins of Test Driven Development
Extreme Programming Explained - Embrace Change by Kent Beck
Refactoring by Martin Fowler
Why TDD ?
- It results in simple design and minimal code.
- Higher quality code due to less defects
- Lower cost to maintain
- Brings fun back to programming
When is TDD not applicable?
- Multi-threading
- Asynchronous Code
- Prototyping
- Exploratory work such as Architectural spike
- Checking the structure of user interfaces such as HTML
- Testing usability of user interfaces
What makes TDD difficult
- Doing TDD without pair programming. TDD and pair programming are complementary.
- Existing code base with no tests
Wednesday, October 09, 2013
Flog Scoring
Score of Means
0-10 Awesome
11-20 Good enough
21-40 Might need refactoring
41-60 Possible to justify
61-100 Danger
100-200 Whoop, whoop, whoop
200 + Someone please think of the children
Subscribe to:
Posts (Atom)