MSConfig - System Configuration UI

Very helpfull tool.


(*1) "Some of its functionality varies by Windows versions:

• In Windows 98 and Windows Me, it can configure advanced troubleshooting settings pertaining to these operating systems. It can also launch common system tools.
• In Windows 98, it can back up and restore startup files.
• In Windows Me, it has also been updated with three new tabs called "Static VxDs", "Environment" and "International". The Static VxDs tab allows users to enable or disable static virtual device drivers to be loaded at startup, the Environment tab allows users to enable or disable environment variables, and the International tab allows users to set international language keyboard layout settings that were formerly set via the real-mode MS-DOS configuration files. A "Cleanup" button on the "Startup" tab allows cleaning up invalid or deleted startup entries.
• In Windows Me and Windows XP versions, it can restore an individual file from the original Windows installation set.
• On Windows NT-based operating systems prior to Windows Vista, it can set various BOOT.INI switches.
• In Windows XP and Windows Vista, it can hide all operating system services for troubleshooting.
• In Windows Vista and later, the tool gained additional support for launching a variety of tools, such as system information, other configuration areas, such as Internet options, and the ability to enable/disable UAC. An update is available for Windows XP and Windows Server 2003 that adds the Tools tab.^[1] It also allows configuring various switches for Windows Boot Manager and Boot Configuration Data."

Read more about it here - http://en.wikipedia.org/wiki/MSConfig

To activate it, WIN+R (or Start-->Run), then run 'msconfig'.

Result

Resources

• (*1) MSConfig - Wikipedia, the free encyclopedia

Bad experience: Reasons why the last project was a disaster.

Usually I try my best to work in an ordered manner.
This means:

1. Interview the project manager (the person responsible for the success of the project) for the story.
2. Convert this story to requirements.
3. Present the project manager with the requirements.
4. If approved go to the next level.
5. Do a High Level Design (HLD) 
6. Present this HLD sidelong the requirements and estimate roughly the solution time in human days labor.
7. If approved go to the next level.
8. Breakdown the HLD to low level design (LLD).
9. Estimate LLD and present estimated more accurately time  in human labor.
10. If approved go to the next level.
11. Implement the LLD and stick to it (no time for adventures).
12. Do unit test, system test as much as i can (depends, sometimes not possible).
13. Present a working machine.
14. Be happy and relax.

This time, everything went wrong! Why?

Here were the flow of things:

1. Pressure to implement as fast as possible (reasons: no time, no budget).
1. I broke and agreed to 'be fast'.
2. Skip HLD + LLD, start implement! ==> no thoughts of risks, everything looks easy when you don't think about it deeply.
3. Implementation got some problems I didn't see in advance (and frankly, none can think that deeply).
4. More and more problems arose ==> delivery time breaks ==> more pressure.
5. No one is happy, all is waiting for the delivery => more pressure ==> shorter code, less secure code, BAD CODE!
6. ... The test-bench is too complex to operate... Catastrophic :-)

Next time - Do it right! 

If the project manager don't want to do it right, ignore him :), take your time, design it, show him the design, say 'i thought about it and found some problems' (when doing the hiding HLD + LLD).

You only get an advantage in the start, when things get rough (and they do!) you will cross the break-point and start to be slow (because you can't load all the HLD into your head).

In the end the project worked, the code, barely, but did managed to work, the time for this project took much longer then 'fast and short' (twice if not more the time it should take), and a bad taste was in the mouths.

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

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

First post...

Hi,
For some reason my blog was deleted (probably inactivity), so... here i go again :)