einhverfr

842 ms·

3271.
by einhverfr 15y ago
Disagree here. Figure an hour of planning saves 10 hrs dev time and 100 hrs bugfixing. That doesn't mean spending months planning. It does mean doing your best to plan over a few days, then prototype, review, and start implementing. If t
3272.
by einhverfr 15y ago
That's what prototyping and peer review are for, I write up a schema, send to everyone else on the team, get feedback. If users are invovled get it from them too.... take in all the feedback, write up a new draft, wash, rinse, repeat until
3273.
by einhverfr 15y ago
And you lose the ability to do data constraints well. Put clearly: Declarative data constraints (including referential integrity, but also check constraints and the like) are the single most important features of RDBMS's for most applicati
3274.
by einhverfr 15y ago
"If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, etc. On the other hand if you abstract you
3275.
by einhverfr 15y ago
First of all, RDBMS's are not perfect for all jobs. They have serious shortcomings in some areas (semi-structured and unstructured data for example) A lot of other stuff can be stored in an RDBMS but isn't really optimal for it. Ideally h
3276.
by einhverfr 15y ago
hstore?
3277.
by einhverfr 15y ago
Agreed and of course a clear understanding of what the tradeoffs of approaches are. In the end, I think that more than years of experience is the best marker. I have come into codebases written by a few developers for 20 years that made
3278.
by einhverfr 15y ago
I am often both playing with experimental technologies and pushing the envelope vs best programming practices. If you look at the approach of LedgerSMB's use of PostgreSQL (see http://ledgersmbdev.blogspot.com/2011/10/design-of-ledgersmb..
3279.
by einhverfr 15y ago
That's why I have come to define "elegance" as "simplicity perfected." The best solution is the one which makes use of a number of clear, easily understood, simple solutions in combination to solve a problem. But the wrong approach to simp
3280.
by einhverfr 15y ago
"So you advocate over-engineering a just-in-case tour-de-force, instead of agile, iterative, responsive development. How are you getting up votes????" There's a time and a place for heavy engineering, and a time and place for agile, iterati
3281.
by einhverfr 15y ago
Absolutely agree. Find customers, not a job. It may lead to a job, or you may fall in love with the freedom if being able to fire your boss (namely your customer) and make it a permanent lifestyle. It's what I did and I never looked back.
3282.
by einhverfr 15y ago
I think the fundamental problem exposed in the article is actually not the hiring criteria, but rather that resumes are usually screened by HR departments who have no clue about what a job entails. So the hiring managers have to provide hi
3283.
by einhverfr 15y ago
One might think that it ceases to be a straw man when someone rushes to defend it.
3284.
by einhverfr 15y ago
When it comes to software engineering, I always think back to my first year Calculus teacher, Mike Lavender, and his admonishment that "in mathematics, power tools are consider inelegant where hand tools will do." Words to live by in progr
3285.
by einhverfr 15y ago
It's not an issue just of figuring out what the user wants. It's figuring out what is not working for the user and why. In general you can assume that what's not working for current users will not work for a large subset of future desire
3286.
by einhverfr 15y ago
Exactly right. I am going to state the obvious here. UI's should be designed around their input methods. If the input on a tablet and a desktop are different (mouse vs fingers) then use a different UI. Plain and simple. Gnome 2.3 was a
3287.
by einhverfr 15y ago
The issue here is a lack of communication. For example in LedgerSMB, we get occasional users asking for MySQL support. We send them a (lengthy) canned response detailing why MySQL support is not on our priority list and in fact why we wou
3288.
by einhverfr 15y ago
Wondering if you can write sprocs that use Lucene in PL/J?
3289.
by einhverfr 15y ago
Clustering is also faster than VACUUM FULL and can be used as a replacement where that is needed.
3290.
by einhverfr 15y ago
guess not.
3291.
by einhverfr 15y ago
Wondering about using the pg_trgm option for this sort of search. Might not be perfect but it might help a lot and as a side effect might suggest where words are misspelled too.
3292.
by einhverfr 15y ago
I mentioned ARRAY support in the context of complex types, but it could definitely get its own entry. I haven't played much with hstore, but there are a few places LedgerSMB might be able to use it in the future. SQL/MED is also worthy of
3293.
by einhverfr 15y ago
I mentioned it in the "this could be included but it didn't meet my criteria and here's why" section in the last couple paragraphs. Yes, it's highly underrated, but my focus was just a little narrow perhaps.