## Sunday, April 10, 2011

### 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```

## Saturday, April 9, 2011

### 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 maintenanceperformance, 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:
• 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...

## Friday, April 8, 2011

### 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,”

## Thursday, April 7, 2011

### 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 ==>).

## Saturday, April 2, 2011

### 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.

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.
• 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