noidi
Joined 17 years ago
Karma
293
Submissions
37
Member since
Feb 26
[ my public key: https://keybase.io/noidi; my proof: https://keybase.io/noidi/sigs/PRrVfSWOvPXpNYSqCd-jTqtp908Wo2ARs8bCCwA_ub0 ]
View on Hacker NewsRecent submissions
Comment · 14 years ago
Note that the installation instructions on that site are completely out of date. You don't need a C compiler anymore, just clone the repo and enable the extension, as described in the README: https://bitbucket.org/durin42/hg-git
Comment · 14 years ago
I disagree with labeling work on less-imporant tasks as procrastination. I think it's often (but not always) more effective to breeze through less important tasks that you're itching to do instead of slowly trudging along the highest priority task that you detest. The unpleasant topmost task becomes much less daunting once you've built momentum with a few easy wins and can see yourself as a producer instead of a procrastinator.
There's also the idea of structured procrastination, [1] which turns procrastination into a productivity tool. It's based on the insight that an unpleasant task may become attractive when seen as a way to procrastinate on something even more unpleasant. For a true procrastinator it means working productively on tasks #2..n instead of reading Hacker News thinking "one last article and then I'll start working on task #1". It's an excellent way to avoid getting stuck in a vicious cycle of procrastination, and calling it "hidden procrastination" is unnecessarily negative.
Comment · 14 years ago
For another clever take on mocking in Python, check out Ian Bicking's minimock: http://blog.ianbicking.org/minimock.html
Comment · 14 years ago
Martin Fowler has spoken against feature branching as well: http://martinfowler.com/bliki/FeatureBranch.html
Comment · 15 years ago
> I do a lot of research and learn about programming in my spare time, but have hardly any personal programming projects to show.
I think this point is not stressed enough whenever this subject comes up. A person who spends all his free time reading CS research papers and experimenting with different solutions to problems he encounters in his field is not passionate by this standard if he doesn't have a pet _project_ to show at the interview.
Comment · 15 years ago
I think generally object validation should remain separate from construction. The documentation for Python's FormEncode library explain this well:
> Validation is contextual; what validation you apply is dependent on the source of the data.
> Often in an API we are more restrictive than we may be in a user interface, demanding that everything be specified explicitly. In a UI we may assist the user by filling in values on their behalf. The specifics of this depend on the UI and the objects in question.
> At the same time, we are often more restrictive in a UI. For instance, we may demand that the user enter something that appears to be a valid phone number. But for historical reasons, we may not make that demand for objects that already exist, or we may put in a tight restriction on the UI keeping in mind that it can more easily be relaxed and refined than a restriction in the domain objects or underlying database. Also, we may trust the programmer to use the API in a reasonable way, but we seldom trust user data in the same way.
-- http://formencode.org/Design.html#validation-as-directional-...
Lately I've even played with the idea that maybe Clojure style strict separation of data and functions is just taking the single responsibility principle of OO design to it's ultimate conclusion as the responsibilities of storing a piece of data in memory and the responsibility of deriving new data from it are separated...