Reputation
2,128
Next privilege 2,500 Rep.
Create tag synonyms
Badges
9 16
Newest
 Yearling
Impact
~536k people reached

  • 0 posts edited
  • 2 helpful flags
  • 160 votes cast
Apr
27
revised Why are websites (even this one) sometimes “Down for Maintenance”?
added 31 characters in body
Apr
27
comment Why are websites (even this one) sometimes “Down for Maintenance”?
True. But then I'd argue that the problem isn't with formal verification of specifications, but with the validation of those specs. If your specs are invalid, then obviously everything will fall apart from there, but validation of specs ("are we really building the right thing needed by the intended user for the intended purpose"), that's not the focus of verification (*"given these specs, are we building this thing right, or can it be built?"), informal or otherwise. I guess I should have put a caveat on that (wrt to validity of the specs.)
Apr
26
answered Why are websites (even this one) sometimes “Down for Maintenance”?
Apr
22
answered Costs of Switching to Java
Apr
22
answered How do you ascertain the quality of a potential employer's code before you take a position?
Apr
22
answered Preparation for Ph.D
Apr
14
answered At what point do immutable classes become a burden?
Apr
13
comment What's the proper way to exit program in C?
There is no such thing as "which is the best". You code according to your "exit" requirements.
Apr
12
comment Would you still use Java in your next project, despite the whole mess in JCP
Quitting the JCP != quitting the platform.
Apr
12
comment Will Java still be relevant in 5 years?
As someone who has been working with Java since 1998 in application and systems development, while paying attention to the evolution of both Java (the programming language) and the JVM, I agree with this answer. If someone disagrees, I'd say either he doesn't work in Java much (which is ok) or he doesn't pay attention to the industry he's working on (which is bad.)
Apr
11
answered Is Information Technology really Engineering?
Apr
11
comment Off-shore bug fixing
@Dan - yep, your statement is far more correct. No such dichotomy exists.
Apr
11
answered Off-shore bug fixing
Apr
11
answered Career advice: PhD in theory of programming languages
Apr
7
revised Stored Procedures a bad practice at one of worlds largest IT software consulting firms?
added 261 characters in body
Apr
7
answered Stored Procedures a bad practice at one of worlds largest IT software consulting firms?
Apr
7
comment Stored Procedures a bad practice at one of worlds largest IT software consulting firms?
How do you version stored procedures on the server? - you version control the store proc source code. When it's time to deploy, you grab the store procs (from a given baseline) and you (or your dba) deploy to production. Redeployment (be it on testing or production) certainly blows out the stored exec plan, but that will happen independently of whether you source control your SPs or not.
Apr
7
comment Stored Procedures a bad practice at one of worlds largest IT software consulting firms?
@greyfade - "I have yet to see source control for SPs" - are you kidding me? A store proc is just a bloody text file that you upload in your database engine (which takes it, compiles it and installs it for execution.) Every place I've worked that has stored procs, we store the store proc source code in, say, CVS, clearcase or whichever SCM that was in use. Saying that store procs cannot be source-controlled (because they are in the db) is like saying my application source code (Java, C# or whatever) cannot be source controlled because it is compiled and deployed in production.
Apr
7
comment Stored Procedures a bad practice at one of worlds largest IT software consulting firms?
Hmmm, well... 1) The usage of db stored procedures does not necessarily imply that business logic is being put in them. 2) stored procs are some of the easiest things to unit test. 3) store procs are not necessarily conductive of test-first practices, true, but not everything that is computable can be test-first'ed. 4) debugging shouldn't be an issue since store procs should contain nothing more than easy-to-verify SQL statements and cursors. Also, debugging should take place by first testing and debugging the SQL statements in code, and then moved into store procs... just IMO btw.
Mar
21
comment EE vs Computer Science: Effect on Developers' Approaches, Styles?
"I'm not really comfortable with something unless I understand what is going on under the hood." - that is the mark of responsible engineering. +1 to you sir.