701 reputation
37
bio website thehappypath.net
location Seattle, WA
age 33
visits member for 3 years, 8 months
seen May 13 '13 at 7:56

256th Generalist badge. It really should be gold :)


I love AI, psychology, spirituality, philosophy, mathematics, food, art, brain teasers, board games, and telling people they're doing it wrong.

I love music - Bjork, Patrick Wolf, Radiohead, The Knife, The Decemberists, Squarepusher, Dalek, The Smashing Pumpkins, Lemon Demon, MF Doom, Blonde Redhead, David Bowie, Stone Temple Pilots, Battles - I love music. Grooveshark is my friend :)

I am a Strange Loop.
Wound like there's no tomorrow.
I forget there is.


I have written a whole bunch of automation for all sorts of programming tasks (CI, deployment infrastructure, code generation, test case generation, test lab/deployment automation infrastructure, and a whole boat load of automated E2E, integration, and unit tests).

I've programmed mostly in C# for the last 7 years, though occasionally in a myriad of other tongues (C++, C, JavaScript, VB.Net, Java, batch scripts, Lua, Lisp, various DSLs and Python).

I've done a bunch of web programming lately, though I also like API design, and I like programming desktop applications and Windows daemons even better. As boring as desktop apps and services may sound, they're easy to write, and have a nice robust feel to them, much like crunchy peanut butter.

I dig Open Source Software.


Oct
28
awarded  Yearling
Mar
1
comment TDD - is it just about unit tests?
I think the intention of this post is correct, but I can see an outcome of the advice to be to test less ("your tests need to be written better"). This would not be ideal. I think the last paragraph deserves a little expansion. Testing internal behaviors is good. But maybe the OP's internal abstractions are poor/brittle and don't allow a refactor without major reshaping of the code. In such a case, throwing out the tests and writing new ones makes perfect sense. The old tests still provided value because they showed the internal code's behavior wasn't well defined/high level enough.
Mar
1
comment TDD - is it just about unit tests?
I'd be wary of relying too heavily on SQLite. Different DBs have different requirements and what works on one DB may break badly on another DB. Also, the more complex the object, the more mocking is likely to help reduce the brittleness of your unit tests, and increase your ability to understand them later. It sounds to me like you're assuming people will implement their own mocks. I'd suggest in most cases to use a mock object framework, and use a stateless or less stateful mocking style wherever possible.
Feb
3
revised Difference between Idiom and Design Pattern?
C++ templates aren't the template pattern.
Oct
28
awarded  Yearling
Jul
21
comment Should one check for null if he does not expect null?
@Kyralessa: I know how Nullable<T> works, and it does not solve the problem the way you think it does.
Jul
20
comment Should one check for null if he does not expect null?
@Kyralessa: Returning Nullable<T> doesn't solve the null ambiguity problem (did the parse fail or succeed? Was the contents of the string empty? Was the input null?). The TryParse idiom solves this, letting you know whether you have a working object or not. The logic to determine if the parse succeeded or not belongs in the parse method, not the method that uses the result of the parse. You're going to have to check if the parse succeeded anyhow, you might as well have that be returned out-of-band from the output.
May
21
comment Should one check for null if he does not expect null?
@Shahbaz: The clarification that you're talking about cases that give a silent failure when a null value is passed makes more sense. But your first Warcraft example seems to advocate that functionality (where no exception is thrown), and your second example seems to imply that throwing an exception would cause the problem. Your clarification in comments makes more sense. Maybe it would help if you edit the answer to clear up the confusion.
May
21
comment Should one check for null if he does not expect null?
@Shahbaz: The point is that "throw an exception" and "crash" should have identical behavior with respect to that transaction, and with respect to a re-submitted version of the transaction. If they don't identical behavior, then your transaction isn't atomic/idempotent enough.
May
21
comment Should one check for null if he does not expect null?
@Shahbaz: "Now crash in the beginning of transaction may not be bad, but in the middle can be catastrophic" - if this is true that this would be catastrophic, then you didn't design your transactional semantics correctly. A "crash" (exception being thrown) in the middle is exactly what you want to have happen, so the transaction will be rolled back and none of it will be committed. Checking for null and throwing your own exception should be identical to a null reference exception in this respect. It is a silent non-abort you need to avoid, so you should check for null, then throw.
May
21
comment Should one check for null if he does not expect null?
I'd go with failing fast and early even in production unless you can somehow log and report the error (without relying too much on savvy users). Hiding your deployed bugs from users is one thing - hiding them from yourself is dangerous. Also allowing the user to live with subtle bugs can erode their confidence in your application. Sometimes it is better to bite the bullet and let them know there was a bug and that you fixed it quickly.
May
21
comment Should one check for null if he does not expect null?
I didn't down vote, and I agree with your general idea. The language needs some work though. Your assertions define the contract of your API, and you fail early/fail fast if those contracts are violated. Doing this at the skin of your application will let users of your code know they did something wrong in their code. If they see a stack trace down in the recesses of your code, they will likely think your code is buggy - and you might think so too until you get a solid repro and debug it.
May
21
comment Should one check for null if he does not expect null?
This is terrible advice for anything where transactional semantics are actually required. You should make all your transactions be atomic and idempotent, otherwise any error you have will flat out guarantee lost or duplicated resources (money). If you have to deal with non-atomic or non-idempotent operations, you should wrap it very carefully in layers that guarantee atomic and idempotent behavior (even if you have to write those layers yourself). Always think: what happens if a meteor hits the web server at the moment this transaction is going on?
May
21
comment Should one check for null if he does not expect null?
@Kyralessa: For that parsing example, the TryParse idiom is preferrable: return a bool indicating success or failure, and return the result as an out parameter. Returning null here is not a great option as it mixes your parsing return value and flow control return value. Also if you named your method SomeType Parse(string), then the method isn't fulfilling its implicit contract given by the name of the method.
Dec
14
comment How can I create Assert.AreEqual(myobject,somevariable) a test in TDD before writing production code?
You could consider a test that fails to compile a failing test... </sarcasm> TDD's purpose is to help you, not to beat you over the head with regulations :) When @Ikke says interface, BTW, they mean public interface (class methods/properties), not a C# or Java interface.
Nov
24
comment Use open-source programs in your company?
"I do not know any (medium-big) company that does this" - companies that donate or release open source software (both spend resourced on open source)? Or companies that have a mainly or solely OSS IT policy?
Nov
24
comment Use open-source programs in your company?
@eversor: BTW, I'm a FOSS man all the way, but stranger's opinions on the net aren't nearly as useful for making an informed decision as balancing as many plausible factors as you can find :)
Nov
23
answered Use open-source programs in your company?
Nov
23
revised At which point is a continuous integration server interesting?
added 4 characters in body
Nov
23
answered At which point is a continuous integration server interesting?