New blog: ProjectEuler solver

I've decided that if i'm going to solve 332 problem's it's best be in a separate blog, so i'm opening a new blog, i think i'll call it: 'ProjectEuler solver'

Here it goes... http://projecteulersolver.blogspot.com/

Project Euler - Problem 2 - Tcl

#Each new term in the Fibonacci sequence is generated by adding the previous two terms. By starting with 1 and 2, the first 10 terms will be:
#1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...
#By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.
proc problem2 {} {
 set term  2
 set term-1  1
 set sum  0

 while {$term <= 4000000} {
  if {($term % 2) == 0} {
   incr sum $term
  }

  set tmp  ${term-1}
  set term-1  $term
  set term  [expr $term + $tmp]
 }
 
 return $sum
}
# solution-2: 4613732

Project Euler - Problem 1 - Tcl

# If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
# Find the sum of all the multiples of 3 or 5 below 1000.
proc Problem1 {} {

 set items {}

 for {set idx 3} {$idx<1000} {incr idx 3} {
  lappend items $idx
 }

 for {set idx 5} {$idx<1000} {incr idx 5} {
  if { [lsearch $items $idx] < 0 } {
   lappend items $idx
  }
 }

 set rval 0
 foreach item $items {
  set rval [expr $rval + $item]
 }
  

 return $rval
}
# solution: 233168

Project Euler - Very nice problems for every programmer.

Just found this very nice site - http://projecteuler.net/ while searching for some nice math/SW problems to sharpen my knowledge.

I intend to practice through them, very nice job guys!! Very nice idea!!

One problem for a week, ~54 weeks a year, lots of problems to solve :).

Anyway it looks fun, there are around 332 problems as I write.

When I'll solve a problem, I'll post it here...

BOOK REVIEW: 97 Things Every Programmer Should Know - Part III

Previously: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer_08.html

More Highlights... 

• Choose your tools with care... Keep in mind a few things when selecting tools for your application:
• Each tool have it's own assumptions, this can be in conflict with your architecture assumptions. This will lead to conflicts, workaround and will make your architecture and code more complex.
• Upgrading the selected tool or tools might not be an easy and automated task, this can lead to upgrade problems or complexity.
• Some tool's configuration is not an easy task, better keep than in mind.
• Heavy dependence on one tool will probably be a constrain in the end, leading to heavy price, slow maintenance, performance, can lock/kill your tool's ability to evolve, bad tool can lead to the anti-pattern 'lava flow'.. and more...
• Free doesn't totally mean free. Support costs, a lot. Check support agreements first.
• Free - GNU license means you have to distribute your source code!
• ISOLATE the tools by using Interfaces and Layers.
• Code in the Language of the Domain
• There is no functional difference between: 
• if (portfolioIdsByTraderId.get(trader.getId()) {.containsKey(portfolio.getId())) {...}} // AND
• if (trader.canView(portfolio)) {...}
• User domain names like: Trader and Portfolio... This will reveal secrets instead of creating ones.
• Domain names will make your code more obvious when a new programmer will do  reverse engineering to understand your code.

That's it for now.

Next: TBD...

BOOK REVIEW: 97 Things Every Programmer Should Know - Part II

Previously: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer.html

More Highlights... 

• Prefer code re-usability than rewriting chunks of code.
• Write tests to the code you want to refactor. This will give you an idea of the expected results, and will ensure you provide the same results after you'll refactor.
• Prefer many small changes than one big change!
• Test your code per development iteration.
• Review the old system tests, they probably hold some tests you don't even think of and can save lot of pain and time. Each test was probably added with a reason.
• Don't refactor / redesign because you think the code / technology is old! This is not a good enough reason to redesign / refactor!

• Do a cost-effective analysis and prove that the new technology will benefit over time.
• More share, less code, MORE DEPENDENCY!
• When you create a library, each change in it will require a lot of effort from the users of this API.
• If it depends on other shared code, each change in it will cause you to change will cause your users to change...
• Be smart before you release shared code!
• Always leave the region you touched cleaner than you found it.
• Many small improvements, in time, will make your code much better and much easier to read.
• Improve a name of a variable, write help if you understand something, repair typos found... split big function into two smaller ones...decouple...
• Care for your team's code!
• Check your code first before you blame others.
• Mature, widely used code are not likely to have many bugs.
• Version 0.1 release of something is likely to have many bugs.
• Compilers bugs are rare, you better try and check yours first.
• remember Sherlock Holmes’s advice, “Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth,”

Next: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer_09.html

GUIDE: TDD unit testing tools for Tcl

As promised in http://shloemi.blogspot.com/2011/03/tdd-tools-for-tcl.html here is my experience with tcltest package and eclipse.


The story
Suppose we have a function called 'bits_serialize'.

This function should serialize a given data into bits_per_io bits per package (for examples see the tests below and what they return).

This function have the following signature:  bits_serialize {bits_per_io description}, where:

• bits_per_io
• How much bits each package have.
• description
• a pair of {data bits}, where:
• data 
• the data we want to serialize.
• bits
• the size, in bits, we want to serialize this data.

let's test this function using tcltest...

Test code

# Generated using http://pygments.org/

source unit-under-test.tcl ;# contains the definition of bits_serealize 

test base--always-ok {This is as simple as it gets.} -constraints {
} -setup {
} -body {
 return TRUE
} -cleanup {
} -result TRUE

test bits_serealize--partial-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x01 16 "]
} -cleanup {
} -result [list 1]

test bits_serealize--full-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0xFFFFFFFF 32 "]
} -cleanup {
} -result [list [ format "%u" 0xFFFFFFFF ]]

test bits_serealize--over-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x060504030201 64 "]
} -cleanup {
} -result [list [ format "%u" 0x04030201 ] [ format "%u" 0x0605 ]]

test bits_serealize--way-over-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x060504030201 320 "]
} -cleanup {
} -result [list [ format "%u" 0x04030201 ] [ format "%u" 0x0605 ] 0 0 0 0 0 0 0 0]

test bits_serealize--cross-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 "
  0xFF 1
  0xFF 2
  0xFF 3
  0xFF 4
  0xFF 6

  0x04030201 32
 "]
} -cleanup {
} -result [list [ format "%u" 0x201FFFF ] [ format "%u" 0x403 ]]

test bits_serealize--quanta-and-half {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 "
  0xFFEEDDCCBBAA 48
 "]
} -cleanup {
} -result [list [ format "%u" 0xDDCCBBAA ] [ format "%u" 0xFFEE ]]

eclipse-unit-testing

Results

++++ base--always-ok PASSED

++++ bits_serealize--partial-quanta PASSED

++++ bits_serealize--full-quanta PASSED

++++ bits_serealize--over-quanta PASSED

++++ bits_serealize--way-over-quanta PASSED

++++ bits_serealize--cross-quanta PASSED

++++ bits_serealize--quanta-and-half PASSED

My impression 

I definitely recommend using this unit!! and to my surprise eclipse supports it built in (see picture ==>).

BOOK REVIEW: 97 Things Every Programmer Should Know - Part I

I'm reading the book and would like to share my opinion about it.

Technicals
Version read: February 2010: First Edition.
Free review links:

• Google books (90% content)
• Amazon (Table of content + content)

My first impression reading the book

   My first impression was very good, the book started with ideas I've learned to understand by bad experience and good books advices.

Highlights

• Don't take your time, no matter how easy it looks.
• When given a project/job/work-item, don't 'take your time', be fast - especially at the beginning of the project and don't tempt to do shortcuts to save time it'll cost you with great interest ('lava flow' anti-pattern) later on. 
• If you have debt's - manage them (excel / notepad ... any way) and repay them as soon as possible.
• Apply functional programming principles.
• Less mutable depandancy will make your functions more durable to variables state (especially in multi-threaded domains (see immutable definition).
• Ask yourself 'what will the user do', talk to him, interview him, show him basic GUI behavior, include him, watch him in action.
• Most of the user behave in the same basic way to complete a given task.
• They also make the same mistakes.
• Prefer obvious way of doing things than faster (shortcut) ways.
• What the user request and what he really wants usually have a big gap.
• Watching a user for an hour might save you a lot of redesign later on.
• Watch the user work is better than guessing what he needs.
• Automate your team's codding.
• Use auto generated code tools.
• Creates code templates for reuse.
• Use formatting tools.
• Use static code analyzers to find anti-patterns and break them if found.
• TDD your code, measure test coverage.
• Apply written guidance for important things you can't automate.
• Guidances should be dynamic according to the project evolution.
• Do the above for the important things.
• KISS principle!! 
• Simplicity
• Readability
• Maintainability
• Speed of development
• 'Sounds good' / beautiful design/solution/code.
• Read others code
• Find a good open source expert code and read it, refactor 'Microsoft.Net' code for example.
• Simple objects with single responsibility.

Next: http://shloemi.blogspot.com/2011/04/book-review-97-things-every-programmer_08.html