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

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


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

Friday, April 8, 2011

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


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 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
    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 "
    } -cleanup {
    } -result [list [ format "%u" 0xDDCCBBAA ] [ format "%u" 0xFFEE ]]



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

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

    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.

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