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.

Writting LUA script 'User Manual' with ROBODoc

I've wrote a script using LUA for wireshark.
Now I need to document it, so I won't forget what I wrote when I'll come back to the code, 2-6 months later.

After a short research I've found this very nice documentation tool:

ROBODoc 4.99.40 User Manual

and here is an example config file (you'll need it later) I wrote (modified from this source: http://qe-forge.org/cgi-bin/cvstrac/q-e/fileview?f=espresso/GUI/Guib/doc/robodoc.rc&v=1.3)...

options:
    --src ../
    --doc ./api/printable/TBD-api
    --internal
    --html
    --singledoc
    --sections
    --toc
    --tabsize 4
    --index
    --nopre
    --documenttitle "TBD --  To Be Defined."
    --sectionnameonly
    --syntaxcolors_enable quotes,line_comments,block_comments,keywords,non_alpha

accept files:
 *.lua

ignore files:
 .svn
 doc

headertypes:
 e "Enums"    robo_sections

ignore items:

item order:
    FUNCTION
    SYNOPSIS
    INPUTS
    RETURN VALUE
source items:
    SYNOPSIS
    
header markers:
    --****
remark markers:
    --
end markers:
    --****
    
remark begin markers:
    --
remark end markers:
    --

keywords:
 and       
 break     
 do        
 else      
 elseif
 end       
 false     
 for       
 function  
 if
 in        
 local     
 nil       
 not       
 or
 repeat    
 return    
 then      
 true      
 until     
 while

source line comments:
       --
   

How to create Windows executable (.exe) from Python script

Now that your Pyhon program is loaded with command line arguments  your boss asks you to make it exeutable (EXE).

Here are some nice things I've found:

Tutorials:

• How to create Windows executable (.exe) from Python script
• http://www.py2exe.org/index.cgi/Tutorial

py2exe - http://www.py2exe.org/

getopt — Python's C-style parser for command line arguments.

Need to support command line arguments and options in your new Python program, here's what I've found:

Example code - http://www.eurion.net/python-snippets/snippet/Show%20getopt.html
Tutorial - http://www.doughellmann.com/PyMOTW/getopt/
Documentation - http://docs.python.org/library/getopt.html

Tip: HEX to BINARY File Converter Utility

In some cases - It's much easy to write in HEX in text then convert it to BIN file.

Intel HEX to BINARY File Converter Utility
http://hex2bin.sourceforge.net/
Direct file download: http://www.hex2bin.com/hex2bin/

GUIDE: Create your own free, cross platform binary log file with a viewer, with ease.

Hi, it can be done, and within days. Let's start...

Introduction
Did your boss just came to your office and asked you to dump stuff from the application to sniff what's going on in component #42?

Later on he'll might come and ask statistics, that it should support UNIX/Window/MAC/... , filtering, simple graphs, flow graph ...

Here are some pictures of these features in action:

I've wrote a tutorial to create a very simple (starter) sniffer. 

You can read more here... http://shloemi.blogspot.com/2011/05/guide-creating-your-own-fast-wireshark.html

Compile a TCL script into an EXE program

It can be done!

Solution:
How to compile a TCL script into an EXE program