311 karma · joined November 12, 2009
TL;DR: MVC Model is Logical model - business object (invoice) with business logic (delete_line_item), Rails Model is Physical model - persistence layer for RDBMS (add, update, delete, find rows).
In all but the most trivial applications, the latter assertion contradicts the former, and the former, is just outright wrong.
In MVC, Models are meant to model the logical objects of the system. An invoice is an object one which one acts. It is probably composed of several other objects (header, line items, addresses, etc.) which may in turn be composed of other objects.
Only the most trivial application have a one-to-one mapping from RDBMS rows to objects, which is what the OP asserts.
One does not write one's Models with the persistence layer in mind, one writes them with the business logic in mind.
So to me, this is where Rails gets the name Model wrong. The untrained, just starting out with rails learn that business logic goes in the model, so there is goes. But add_address() has no business living int he rails Model file for the invoice header, because that model is meant to be dedicated to manipulating invoice_header records in our RDBMS.
I don't see how somebody from the state police, talking to the media, saying "Ryan Lanza is the name on the driver's license" does not constitute being "identified by law enforcement".
It may have been "erroneously identified by law enforcement" but that does not make "identified by law enforcement" a false statement, no matter how much you want it to be.
If you're holding the reserve from your own pockets, you're very trusting, to the point of being naive.
Additionally, the longer you hold the money, before sweeping it to the merchant, the more interest you earn on it.
She quit general practice, and became a cosmetic surgeon, with a cool-ass laser. Insurance doesn't cover cosmetic procedures, so she doesn't have to deal with them any more.
The world lost a fantastic Family Doctor because of how insurance handles billing and payment.
In order to get the cert for dsac.dla.mil (the computer shop inside the US Defense Logistics Agency) we provided reference to the act of Congres establishing the DLA, and then the command chain that proved that my boss had the rights/responsibility for the SSL cert for the domain.
The process could take weeks, but in the end you could trust that the server on the other end was who they claimed to be.
Fast forward tot he internet boom, and everybody needed a cert, and there folks realized that generating certs was physically easy, and could be lucrative, so they started selling cheaper and cheaper certs. but you can't vet an organization for 29.95, so that aspect of SSL Certs was conveniently forgotten as the masses rushed onto the web.
Everybody thinks SSL Certs are about the encryption. We know that the Cert only establishes the identity of the other party. The encryption is performed using a key which is shared after the cert is used to establish trust.
So now, people are starting to realize that cheap certs don't provide trust, and we're seeing $1500 vetted certs again, and browsers that change colors to signify trust levels.
However, to make this personal, I have a Comodo cert that I got for free with domain registration at namecheap, and a bunch of browsers don't want to trust it.
So I'm stuck between not having revenues to buy a super-cert, and having people refuse to use my app because their browser is saying my app's cert isn't trustworthy, and they aren't technical enough to override the warning.
So will these $50 wildcard certs fare any better?
Applications need UX usablilty. Cornflower Blue icons can come later.
I can't be the only one?
I know several hundred Vice Presidents at JP Morgan Chase.
And really, if your business card tells me that you're a Programmer/Analyst 3, then you're either doing something wrong, or you're a robot, and you probably work between Programmer/Analysts 2 and 4.