101 reputation
5
bio website eamon.nerbonne.org
location Groningen, The Netherlands
age 32
visits member for 3 years, 5 months
seen Apr 5 at 9:37
My work and hobby concern programming: I'm interested in data-mining, and enjoy collecting interesting stats from last.fm's openly accessible web-services.

Apr
5
comment Why is “Select * from table” considered bad practice
This is probably one of the most important reasons here, and it's got just a tiny fraction of the votes. The maintainability of a codebase littered with select * is much worse!
Mar
1
comment Is it okay to make coding style changes on an open source project that doesn't follow best practices?
I think rubocop encourages poor style with several of its default guideline so while this isn't the answer you're looking for, if you're trying to fix styling because of rubocop warnings, you're likely trying to solve the wrong problem.
Feb
9
comment What to do when you are faced with programming task that you have never done?
I think I spend possibly even a majority of my time removing functionality people thought they needed, when in fact it turns out it was only mildly handy and problematic when it comes to quickly adapting to new needs. Your warning is spot on!
Nov
29
comment Why don't relational databases support returning information in a nested format?
This is possible for instance in PG 9.2, albeit with an unhandy syntax. See, for instance: stackoverflow.com/questions/13227142/…
Nov
29
comment Why don't relational databases support returning information in a nested format?
For example, ORM's often cause more work for the DB-engine and unnecessarily large query results by unfolding data they see as a hierarchy into an SQL set query just to recreate the hierarchy client-side. Any query projection that's not in normal form necessarily duplicates data; this is a waste. We do so anyhow, not because normal forms aren't useful, but because that specific db-client case cares not about the model as a cohesive whole, but cares about a specific view or summary.
Nov
29
comment Why don't relational databases support returning information in a nested format?
Let me put it this way: you can use SQL to concatenate a bunch of strings or sum a bunch of numbers. These operations are assymmetric too, but they're nevertheless useful in queryies. In theory, you could probably use SQL to build a nested, hierarchical JSON-document too; but doing so is really impractical and slow. The point isn't that such a presentation is useful to the database, it's useful to a database "consumer".
Nov
29
comment Why don't relational databases support returning information in a nested format?
@BillKarwin that argument makes sense against using hierarchical structures in the database schema - where you can define constraints, etc. But as a query projection, you don't have any of these downsides. The whole point of a query is to extract data from your model; assymmetry is inherent in that operation. Constraints, updates etc? You're not changing anything, so none of these matter.
Nov
28
comment Why don't relational databases support returning information in a nested format?
@BillKarwin I'm not sure which symmetry you mean here - it's just a question of projecting data into a nested format, nothing intrinsic about storage.
Nov
18
comment What does SVN do better than Git?
This question was recently put on hold as primarily opinion based. That classification is wrong; note that the question was open for a long time; that there are many questions about the virtues of DVCS, and that the question doesn't ask whether it's better (opinion), but what it does better. The differences are not opinion but whether the overall product is - that's tricky (but not the point of this question).
Nov
17
awarded  Excavator
Nov
17
awarded  Editor
Nov
17
revised What does SVN do better than Git?
Added binary file & simplicity advantages.
Nov
15
awarded  Commentator
Nov
15
comment Using multiple Git repositories instead of a single one containing many apps from different teams?
see: programmers.stackexchange.com/questions/161293/…
Nov
15
comment Using multiple Git repositories instead of a single one containing many apps from different teams?
@olibre: I'd avoid multiple repos unless you actually need it. When you do, it's not hard to split repos.
Nov
15
comment Using multiple Git repositories instead of a single one containing many apps from different teams?
So basically using multiple repos is just a perf optimization?
Nov
5
comment Should you always pass the bare minimum data needed into a function
@MarjanVenema sorry that came across too harsh. I just mean that an authorization system shouldn't be an end in and of itself. Sometimes just distinguishing between admins and others is enough.
Nov
4
comment Should you always pass the bare minimum data needed into a function
@MarjanVenema - the idea that the User class must not "decide" whether an instance is an admin strikes me as being a bit cargo-cultish. You really can't make that generalization so strongly. If your needs are complex, then perhaps it's beneficial to encapsulate them in a separate "system", but citing KISS+YAGNI I'd like to make that decision actually faced with that complexity, and not as a general rule :-). And note that even if the logic is not "part" of User it can still be useful as a matter of practicality to have a passthrough on User that just delegates to a more complex system.
Jun
24
comment Best practices for sharing tiny snippets of code across projects
+1 - I think it's worth mentioning this approach even if it's not one you want to use very often. Some snippets are more like design patterns - you'll reuse em, but slightly differently everywhere, and perhaps in different languages, and perhaps you'll want to change them. Also, a broadly reused library is inflexible in that changes to its API are very risky. Finally, having this approach as a fallback increases the quality of shared libraries by keeping experimental stuff out of them a little longer.
May
19
comment Why don't relational databases support returning information in a nested format?
Isn't it slighty absurd to argue that to avoid data duplication, you must write your query in a flat, data-duplicating manner?