This is a test post.
Here's some code Continue reading
Uncategorized
Inject a newline in a linux command’s output to improve readability.
(for posterity, ’cause I always forget…)
- Add alias:
alias nl="sed 'N;s/\n/\n\n/'"
- Enjoy! For e.g.
ps -ef | grep -i username | nl
This injects an extra newline after every newline in the command’s output. Makes it much easier to read verbose output such as searching for java server processes (glassfish, WL) which have really long command lines.
Cherry-picking a GIT merge commit from a branch.
Git doesn’t let you cherry pick a merge commit from one branch on to another branch. For e.g. a:
git cherry-pick ac61858fac21c33f47e95f3bac4c8cc3a643195b
Where ac61858 is a merge commit generates the following error:
error: Commit ac61858fac21c33f47e95f3bac4c8cc3a643195b is a merge but no -m option was given.
This is because the merge commit is merge of two lines of development. So when using it to cherry pick to another branch, GIT doesn’t know which of the two branches to merge to the destination branch.
This is explained @ http://stackoverflow.com/a/12628579/209952.
In order to get this to work, you need to use the -m option, with the parent to pick.
Also, cherry pick commits the changes with a message right away. If you want to avoid an immediate checkin, use the -n option.
So, say you have a RELEASE branch with two merge commits C1, C2. You want to merge these changes (and only these) back to, say, MASTER. Here’s how you would go about it:
git checkout MASTER git cherry-pick -n -m 1 C1 git cherry-pick -n -m 1 C2 git commit -m"Merging feature xyz changes from RELEASE to MASTER"
Note the “-m 1” in the above commands. 1 means in include changes merged to RELEASE, 2 would mean use the state of RELEASE at the time of merge.
Duct tape programmers – A slightly older, but good read.
Duct tape programmers are pragmatic. Zawinski popularized Richard Gabriel’s precept of Worse is Better. A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.
"When in doubt, leave it out"
Heard this little gem of an advice, while watching a Youtube video interview of Joshua Bloch.
Effective Java Programming with Joshua Bloch
Less is more. If you’re not sure if you need to add a certain capability, leave it out. You cal always add it later.
Beautiful advice. Over the years, the one thing that I’ve seen is that if you make a product that is chock-full of complex features, multiple configurations, etc, most users will just go with the defaults that you give them. So the payouts of having a complex set of features usually isn’t there. So go ahead, be lazy! If it’s not required, don’t do it.
Why You Should Always Salt Your Hashes – Added Bytes
A nice article about hashing passwords before storing to the db.
Why You Should Always Salt Your Hashes – Added Bytes: I guess one of the comments there echoes my sentiments… “Well-written, though it’s sad it has to be written at all.”
"Google it!" bookmarklet
Here’s a nifty little bookmarklet based on this post : LetMeGoogleThatForYou Bookmarklet – Added Bytes
Drag this link on to your bookmarks or bookmarks toolbar. Then, to Google something that you read on a webpage, just select the text you wish to Google and click the bookmark!
It’s no biggie, just a way to make life just that little bit easier…
URL Rewriting for Beginners – Added Bytes
A pretty neat tutorial on URL rewriting.
Is anyone listening?
Well, does it really matter 😉
Tech Tidbits 