Nelz's Blog

You’re job is not done once you’ve released the code…
"Post Release: Closing the loop":
http://googletesting.blogspot.com/2007/10/post-release-closing-loop_02.html

Testing Will Challenge Your Conventions:
http://blog.objectmentor.com/articles/2007/07/17/testing-will-challenge-your-conventions

I loved this post! It vocalizes several things I’ve noticed in my own coding since I’ve adopted an opinionated testing practice.
(Though, I should say I don’t 100% agree with all the items:

• #3 – You can get around a private visibility modifier, using reflection.
• $4 – Fat constructors may be a smell indicating a refactoring candidate.

)

Java Spec: Measures and Units
http://www.javaworld.com/javaworld/jw-10-2007/jw-10-jsr275.html?page=1

Fantastic

"Confessions of a Terrible Programmer":
http://kickin-the-darkness.blogspot.com/2007/09/confessions-of-terrible-programmer.html

I struggle trying to achieve the egoless-ness that Marc has exhibited, though I shall strive for this more and more every day.

Thoroughness is my (our?) stumbling block. I am blown away by the descriptions in the comments of some other Great Programmers. (Search on the term "rigor" to be amazed yourself…)

"Session State is Evil":
http://davidvancouvering.blogspot.com/2007/09/session-state-is-evil.html

I have been heading down this path for a while now… While I don’t necessarily think Session State is "evil" per se, I do think you need to avoid it for any kind of scalability.

"Hard Questions About Architects":
http://blogs.tedneward.com/2007/09/20/Hard+Questions+About+Architects.aspx

I’ve seen Ted Neward speak, and I believe exemplifies pragmatism in the realm of software engineering.

The Deep Synergy Between Testability and Good Design:
http://michaelfeathers.typepad.com/michael_feathers_blog/2007/09/the-deep-synerg.html

What You Need To Know About Secure Password Schemes:
http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/

This article really helped me to see what we should concentrate on when encrypting passwords: Time. Time, as a product of scale, is the only way you are going to be able to fight brute-force techniques.

If you are encrypting one password, making it cost an order of magnitude more will be negligible in your end user’s experience. But, for a brute-force attacker, that order of magnitude multiplied by the millions of combinations that they have to attempt would make your database of encrypted passwords much less attractive for cracking.

These articles present some interesting ‘out of the box’ thinking on the overall process of software development…

The Development Abstraction Layer
http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html

For Best Results, Forget the Bonus
http://www.alfiekohn.org/managing/fbrftb.htm

Good Agile, Bad Agile (by a Googler)
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

I like the anti-session ideas presented here to help out with web site performance:

http://develooper.com/talks/rwws-oscon2005.pdf

(My summary: DONT use sessions. If we are only holding 2-3 chunks of information, then put them into a cookie (with an MD5 hash to prevent user munging) and use that for identity, thereby freeing you of session information.
This solution is just as secure as sessions, as both are vulnerable to man-in-the-middle attacks, because a session ID is stored in a cookie anyways…)

The "father" of RDBMS’s now likes column-based DB’s:

http://www.javaworld.com/javaworld/jw-09-2007/jw-09-columndb.html?fsrc=rss-index

(Uses Google’s column-based DB as one example…)

Use views (and other techniques) to preserve good DB design, while also providing the functionality that your client wants…:

http://weblogs.sqlteam.com/jeffs/archive/2007/06/05/60223.aspx

Correlating good grades to good working performance?:

http://calnewport.com/blog/?p=67

(D’oh! I was one of those that always did a bit less well in the non-technical classes… I think now, however I would do fairly well…)

Using JDepends within your unit tests to ensure non-leaky API’s:
http://www.jroller.com/kenwdelong/entry/managing_dependencies_with_jdepend_and

Cautions while using Mock Objects:
http://dev2dev.bea.com/pub/a/2007/06/mock-shortcomings.html

Maven Pains:
http://weblogs.java.net/blog/zarar/archive/2006/12/the_pain_of_mig_1.html

(I am still in favor of Maven, but I believe people moving to Maven should be aware of the overhead…)

Snarky Software Engineering "Laws":
http://haacked.com/archive/2007/07/17/the-eponymous-laws-of-software-development.aspx

Translating from Programmer-ese to English:
http://fishbowl.pastiche.org/2007/07/17/understanding_engineers_feasibility

Presentation Layer Performance Tuning:
http://www.welterlin.com/whitepapers/presentationLayerPerformanceTuning.php

Javascript in the JVM? (I think I’d prefer to use GWT:
http://weblog.raganwald.com/2007/07/javascript-on-jvm-in-fifteen-minutes.html?retitled

Code Critiques as an Interview Tool:
http://hupp.org/adam/weblog/2007/04/15/code-critique-as-an-interview-tool/