HN user

ArtB

200 karma
Posts1
Comments114
View on HN

Yeah, but they might live for another 6 months, or 18 months. They might see there kid graduate or get married or met a grandson in that time.

Also, a close family friend was given 6 months to 3 years to live when her cancer spread through her body. It's been 10 years. She is getting sicker and sicker and on chemo the whole time, but she is still managing to attend the odd family function when she is feeling up to it.

This shit isn't a game, these are peoples lives and we need to make sure they can live it even if it means a few less unicorn start ups.

Object oriented does not require state: it requires encapsulation. I incorporate as much immutability into my code as possible and I would say most of our objects never have their state changed from instantiation and I write Enterprise Java all day long.

If it's the latter that's the domain job.

The domain's job is to represent and encapsulate valid transformations in the domain. If it's not valid within the domain then it doesn't belong in it. If you get a well-formed XML file that has -7 as a social security number, that is not something that your domain has to deal with. It should be caught by the corruption layer. It's not a valid value for your domain. Where I work we regularily build an import domain that allows users to see all the invalid data and manually correct it before allowing it into the rest of the system. Once I have an instance of a Person object I should be able to trust that it is sane.

The third, from the experience I have, is a big flashy "no no".

It depends; I'd say it's on a case-by-case. Doing a read can be much more acceptable than a write. It's all about trade-offs at that point, but the benefit of knowing "if I have an instance I know that it is sane" means you don't need to litter your code with guards and that pays dividends in maintenance and bugs and agility and testability and, yes, even performance. A big factor is the cost of load. I usually work on low-load (~14 concurrent users) high-importance systems (eg global pricing management) where correctness is at a premium and we usually have system resources to spare. YMMV. As I said: it depends.

Some validation only makes sense on a specific operation. The object you constructed, due to some business rule, may be invalid to delete but valid to update for instance.

These are two different concepts I feel you are mixing up. An object may be valid, but that doesn't mean it's valid for all operations. For example there is basic validation that a file object is valid if it exists, but if you only have read access to it .append("foo") will fail on it. But it's still a valid file. Your constructor should be checking for the first kind of validity, and your methods for the second.

What if you receive, from a webservice or something, a valid object format-wise but invalid from the business rule perspective?

That is what you need an [anti-corruption layer](http://www.markhneedham.com/blog/2009/07/07/domain-driven-de...) for. The object makes sense within that other services domain but not within yours. That domain may be closely related to yours, but it isn't you. You need a separate object for that (a simple struct ought to suffice usually). Then you act as a gatekeeper only allowing conforming objects into your system. Basically filter out the shit, and make sure if it makes it past your gate it is clean. Otherwise you might want to use the [state pattern](https://en.wikipedia.org/wiki/State_pattern) to allow for different validation rules of the same object (eg legacy accounts might not have an email address but all new ones must).

What if there's some info in the database that would allow or not you to construct the object the way you need? You would go to the database and check the info in your constructor?

This is touchy. Sometimes, if it's important enough then yes. Sometimes you can code around it (eg having case numbers auto-generated at time of persistence). Other times you bite the bullet. Other times you rearchitect the data (storing it in memory to do the check quickly). Or as a last resort, except it as a compromise and start coding up some roll-back functionality. Aim for the ideal, and know when to step backwards towards the practical: that is the art of software development.

EDIT2: The price is also way too much in my opinion. It basically costs as much as PHPStorm. Not sure why you would by DataGrip instead of Navicat.

Uhm for Navicat you need to buy a different license for each database and operating system you use. Where I work we use both SQL Server and MySQL and I use three different computers with different operating systems. JetBrains terms are much friendlier.

I honestly just use my Kobo for tech books like Manning and classics from Project Gutenberg. Otherwise dead tree.

And most mathematicians have been reluctant to invest the time necessary to understand the work because they see no clear reward: it is not obvious how the theoretical machinery that Mochizuki has invented could be used to do calculations.

I find this _deliciously_ ironic since that is the position most students have towards mathematics in general (replace "calculations" with "anything relevant in their lives").

Hmm, in your opinion do you think this would be a good technique then for digitizing paper maps? And if so, could you point in the direction of a library or textbook you'd recommend?

Is there an e-ink reader with a 8.5"x11"/A4 screen that'll display PDFs? All I want is to be able to bring all my tech ebooks with me to work and be able to look things up/brush up on things on the commute/flight etc.

With the plug pulled on Groovy I'd love to see optional static typing added to JRuby, even if it wasn't a Ruby-compatible extension.

Formatting -IMHO- depends on context. I have one convention I generally use which is chaining methods together on one line, but when chaining together builder method call I make one line per call. That means the semantics not the syntactics of the code determine my formatting. For this reason I abhor auto formatting code unless it is currently like an unrecoverable mess (ie NO thoguht put into it, not just "not my style"). Honestly, put your curlies wherever you like them, then don't effect readability as much as lacking comments or convoluted flow.

>> but my guess is that the majority of companies fall into the category where losing a person for a month is crippling.

I'm of the opinion that this is a reason to discourage the growth of small businesses. They are too small to absorb shocks like pregnancy or family emergency that contribute to the well-being of a society.

No, it should be part of HTML. A dimension or unit tag. It seems like a perfect continuation of semantic tags and the direction of XHTML 2 before the presentation-focused monstrosity that is HTML 5.