Monday, October 18, 2010

Tuesday, September 28, 2010

Learning Scala: Day One

http://www.scala-lang.org/

The mail site for the language.

Downloaded and installed using the lzPack Installer (A jar file).  To install I selected the file once it was downloaded and selected 'Open'.  Java did the rest.


A web site that lets you interactively try Scala.


An online book on Scala.

Friday, August 20, 2010

When Refactoring to a Class

Start with the variables first.

Create the class with only the variables first and then use the new class that contains the variables.

Once that is working, move in the function to the class.

Wednesday, August 18, 2010

Practical Notes

When doing refactoring it can be helpful to look at a variable that requires refactoring and see what routines it touches.  The routines it touches are possible methods in a refactored class.  (see my work logs notes for this day for an example).

What is the difference between a structure and a class in C++?  http://www.codeguru.com/forum/archive/index.php/t-194315.html

Basically there are a lot of neat stuff like the 'this' pointer, inheritance, polymorphism.  Where would I want to use a structure instead of a class.  In COM I must use a structure.

What does the #pragma once do?  http://en.wikipedia.org/wiki/Pragma_once

It is a non-standard pre-compiler directive which causes the current source file to be only included once in the compile.


Friday, August 6, 2010

Refactoring Study Notes

http://sourcemaking.com/refactoring



Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior.


 the purpose 

Optimization fits refactor but the code my be harder to understan.

Always be aware of which hat you are wearing.

Tidying up the code.

Regular refactoring help the code maintain its shape.

Eliminate duplicate code.

 Make the code better communicate its purpose.

Design decay

Rule of three:  1st time just do it.  2nd time wince.  3rd time refactor.

When to refactor:
  1. add a function
  2. fix a bug
  3. code review
Small code review, use code.

Large code review, use UML and CRC 
(class-responsibility-collaboration) 
cards.

Design reviews with groups, code review with individuals.

{What about using a random process to select the individual reviewers pairing?}

Ken Beck:  "Programs have two kinds of values:  what they can do for you today and what they can do for you tomorrow."

parasitic indirection - indirection that gives not value

int someValue()
{
   return noValue()
}

int noValue()
{
   return 1;
}

avoid refactoring when close to a deadline. 


OK

Tuesday, July 6, 2010

Pattern Study - Structural

Design Pattern Grouping:

  1. Structural Patterns
    1. Adapter
    2. Bridge
    3. Composite
    4. Decorator
    5. Facade
    6. Flyweight
    7. Proxy
  2. Creational Patterns
  3. Behavioral Patterns
Links:


Pattern Study - The Future of

I got this from Judith Bishop book, C# Design Patterns, page 256.

Some problems with design patterns:

  • Traceability - hard to maintain when programming language doesn't support the underlying pattern.  Pattern can be spread across several classes.
  • Reusability - design pattern is not encapsulated and must be reimplemented each time it is used.  {What about a design pattern template, several template classes that ease the implementation of a pattern?}
  • Writability - methods with trivial behavior not support be language can be tedious to write and maintain.
  • Maintainability - multiple patterns can lead to a large cluster of mutually dependent classes causing high coupling between the classes.
The current research is how to transform design patterns into reusable artifacts so the programmer doesn't have to implement them over and over again.  {Addressing all the above problems.}

Pattern Study - UML

Class 
  • Class
  • - attribute
  • + operations()
Interface
  • <<interface>>
  • IClass
  • +operations()
Note
  • descriptive text
Package (grouping of classes and interfaces
  • Package
Inheritance
  • A <--- B (horizontal) : B inherits from A
Realization
  • A <-- B (horizontal): B implements A
Association
  • A --- B: A and B call and access each other's elements
Association (one way)
  • A --> B: A can call and access B's elements, but no vice versa
Aggregation
  • A <>--- B:  A has a B, and B can outlive A
Composition
  • A <<>>--- B:  A has a B, and B depends on A.

Friday, July 2, 2010

Scrum Software Development

http://en.wikipedia.org/wiki/Scrum_(development)

An iterative, incremental fremwork for project management and agile software development.  Many spell it with capital letters, but it is not an acronym.

Take from a rugby technique.  First mention by name in 1991.

Groups:

Scrum Master
Product Owner
Team

Roles:

Pig: "their becon on the line"

Chicken:  customer

Thursday, July 1, 2010

Re: Absolute and Relative Paths

absolute path vs relative path

On Fri, May 28, 2010 at 4:35 AM, Stan Hughes <hughes.stan@gmail.com> wrote:
path

Wednesday, June 30, 2010

Using MSBUILD and DEVENV to Clean

http://msdn.microsoft.com/en-us/library/5ak1w89s%28VS.80%29.aspx

devenv /clean Debug Solution.sln

One can also specify the project and project configuration.

Can also run the application after it is built.




Monday, June 21, 2010

msvcprtd.lib(MSVCP100D.dll) : error LNK2005: already defined in gtestd.lib(gtest.obj)

This error occurs when the C/C++ Code Generation Runtime Library in gtest is defined differently from testing code using it.  The gtest project was defined as MTd (Multi-threaded Debug) and the testing project defined as MDd (Multi-threaded DLL).

Fix:  Changed the testing project to use MTd.  From the Property Pages select Configuration Properties ==> C/C++ ==> Code Generation ==> Runtime Library ==> Multi-threaded (/MT).