slakin.net | mattsn0w.com

saving a copy of this here since things on the interweb tend to disappear.

There is some very good info here: http://www.allard.nu/openbsd/ specifically, I found the following hints helpful:

‘isakmpd -d’
Start isakmpd with ‘isakmpd -d’. Isakmpd will output things like wrong file permissions and typos in the configuration file. On connect you might see things like “NO PROPOSAL CHOOSEN” which can either mean that your configuration parameters between the client and the server doesn’t match, or that you have typed the wrong pre-shared key.

‘isakmpd -L’ and ‘tcpdump -avs 1440 -r /var/run/isakmpd.pcap’
This one is really nice to check if your configurations between the client and the server match and also to learn howto create isakmpd.conf files for new clients. With ‘isakmpd -L’ isakmpd will dump, in tcpdump format, everything it sends and recieves to /var/run/isakmpd.pcap. You then check what happened with ‘tcpdump -avs 1440 -r /var/run/isakmpd.pcap’. Look here for an example output of isakmpd -L and tcpdump. This output is typically what you want to send to the mailing list when you want help with something if the above doesn’t help you.

from vegaseat at DaniWeb.Com.


Python Code Snippet (Toggle Plain Text)
# handling date/time data
# Python23 tested vegaseat 3/6/2005

print "Wait one and a half seconds!"
time.sleep(1.5)
print "The end!"


taken from: Dirk’s Junk Box.

The Programmer’s 10 commandments
Tue, 03/04/2008 – 22:49 — Dirk
After more than a decade in the IT Industry, I have found, that few junior programmers make a success of their careers. Below I list what I consider the 10 commandments of a programmer should be. I’m convinced that any programmer that practice these will make a success of their career.

1. Know more than you “need” to know.
Knowing a programming language and being able to program in it is not enough. In today’s IT industry it is hardly enough to qualify you for doing a few loose projects at home.

You are working on a computer, that computer has both hardware and software components. You need to have a working knowledge and understanding of both. It is highly unlikely that you’ll be working on a stand-alone computer, so you also need to know at least the basics of networking.

So, when will you know enough? The answer is simple… NEVER!

2. Learn at least one new thing every day!

Every successful programmer I’ve ever met, has made learning new things on a daily basis an art form.

The IT industry moves at a ridiculous pace, make peace with the fact that you will never catch up with the current scene of all the available technologies. Be aware of the fact, that if you do not learn new things regularly, you will be useless outside your current place of work within 18 months.

3. Getting it to work is NOT ENOUGH!
Take pride in what you do. Honestly, just because you finally got your program working, does not not mean it is done. Clean up your code, comment it where needed and test the damn thing thoroughly.

4. Consider those that come after you.
Think of the guy that has to maintain your code, as a homicidal psychopath, that knows where you live. Write your code in a way that would make sure he never gets the urge to seek you out.

Too many programmers write their code in a way understandable to nobody other than themselves and the compiler or translator they happen to be using at the time. Don’t be one of them and when you find one, bang them over the head with a clue-bat.

Download some source code from a reputable open source project and look at it, compare what you produce to it and you’ll quickly find where you can improve.

5. Document what you do.
With applications like Javadoc and doxygen, there are no more excuses.
If you don’t document your applications you can not, by the biggest stretch of the imagination, call yourself a programmer.

At best, you are a glorified typist.

6. Follow, respect and take responsibility for the development process.
The development process from requirement gathering, through testing, deployment and maintenance. Has been developed by those you are now learning from. They had to learn it from the school of hard knocks.

Respect this experience and use their knowledge.

So when exactly are you done?
Only once the application is deployed, running and requires no more changes, can you say you are done. Before you reach that point, you can not factually state that you have finished your work.

7. Respect your peers.
Throughout your career you will be working with many other programmers, developers, software engineers etc. etc. etc.

You might reach a point where you are factually the most experienced or trained individual on a team. This is when you need to be doubly careful. Do not allow yourself to become arrogant.

In years gone by, it was possible for a single programmer to see to an employers needs. These days, if you want to progress beyond “Hallow world”, you’ll have to learn how to work with others.

Nobody likes an arrogant SOB, no matter how good he is. This will eventually lead to that individual’s downfall.

The IT industry is one of the few where a good reputation can get you far beyond the level of your formal education. A bad reputation on the other hand, will see you getting stuck at the bottom of the pile, regardless of how many degrees or certificates you spam your CV with.

8. Respect the user.
Yes, there will be times when you think the user is the most irritating, uneducated, short sited being produced by this universe, for the sole purpose of making your life hell.

I’ve found, that when you respect the user, listen to their opinions and grievances while taking action to improve their lives. You invariably end up with someone, that will listen to you and take your advice.

Over the short term, this could take a lot of work and effort. But over the span of a career, those users are the best references you can possibly gather. They are the ones that will tell your future employer, that they are absolutely devastated at seeing you leave and that they don’t understand why your current employer can’t make a plan to keep you.

9. Demand the best of yourself.
Do what you have to, check it, improve it, check it again, read some relevant material on what you have to do, check it again, test it to death, clean up your code, test it again, do your documentation and… test it again.

Even after you have done this, you can be sure there is at least one more thing to do. Find it and do it.

Do all of the above to the best of your ability.

10. Demand the best from your peers.
You will never survive if you are the only one doing all the things needed in order to make sure your product is a good one.

Your peers share responsibility with you, if they are not doing their best it will come back to bite you when you least expect it. Do not tolerate incompetence, but also help and educate where needed.


syntax on
set nocompatible
set autoindent
set smartindent
set tabstop=4
set shiftwidth=4
set expandtab
set showmatch

# map F2 key to toggle auto indent while pasting indented code.
nnoremap :set invpaste paste?
set pastetoggle=
set showmode


*NIX Commands. These are endlessly useful.

EOP

I was setting up nagios at my new job and found myself in a position where all I have is vim to select, copy, and paste text(don’t ask, I use evilwm). I came across this useful bit of info from This page on creating splits or multi-file editing in VIM.
The below text is copied from the above link.

Opening a file in a split

Assuming you are already editing a file in a vim session and want to split the screen and edit a second file, you can use either of these commands:

:sp filename Splits the screen horizontally and opens filename in the new area.
:vsp filename Splits the screen vertically and opens filename in the new area.

For most purposes, horizontal splits are easier to manage. Any split can be further split — you can edit as many files in a single instance of vim as you like.

Managing splits

Once you are editing multiple files, you will probably need to move back and forth through your files and manage the size of the splits so that you can see the relevant portions of the files you’re interested in.

The prefix for all the below commands is — that is, hold down Ctrl and type w. Press before typing any of the below commands.


Moves to the next split.
k Moves to the split above the current split.
Up Moves to the split above the current split.
j Moves to the split below the current split.
Down Moves to the split below the current split.
+ Increases the size of the current split by one line. (Try combining this with counts -- e.g. 5+ will make the split five lines bigger.)
- (Minus sign) Decreases the size of the current split by one line.
_ (Underscore) Maximize the current split (that is, make it take up as much room as possible.)


Saving and quitting

Each split acts something like an individual instance of vim — so

:w

and

:q

work on the current split.
If you want those commands to apply to all the splits instead of just the current one, add a to them

--

for instance,

:wa

saves all the open files,

:qa

quits all open files (and exits vim), and

:wqa

saves and then closes all open files.

in my new job i’ve been tasked with something ugly. webifying a windows CLI command. in my venture to find a way for PHP to spawn an interactive shell I came across this site: CommandWindows.Com.

Yes, yes, yes… windows sucks and we all know it(this is a very good blog post, highly recommend reading it!).
It turn’s out good’ol sysinternals made psexec.exe with the purpose of spawning CLI commands that require interactive console(eg. Platform LSF tools).

Put this one in the books for some way back memory I hope to never need in the future.

I do and do not recommend learning this.

Advanced BASH Programming – String Operations

They certainly can come in handy though if you don’t want to do some basic grep/awk work.

little example:

$ foo="my words"
$ echo ${foo#my}
words
$ echo ${foo:1}
y words
$ echo ${foo:2}
words
$ echo ${foo:3}
words
$ echo ${foo:4}
ords
$ echo ${foo:1:2}
y
$ echo ${foo:1:3}
y w
$ echo ${foo:1:4}
y wo
$ echo ${foo:1:5}
y wor
$ echo ${foo:1:6}
y word
$ echo ${foo:2:6}
words
$ echo ${foo:3:6}


insert

import pdb; pdb.set_trace() 

in to area of code area you would like to debug then run script.

These commands allow you to step through the code from the point of where pdb.set_trace() is placed in your script.

p