|
Thanks, I was already wondering about this "needs a definition" part as I could not find any evidence confirming it.
Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Although somewhat obvious, it missed out on the unwritten rule that the answer to the whole thing should lay somewhere in the clue.
So while HIJKLMNO is a clever clue, Damp HIJKLMNO provides the confirmation.
just realised I'm replying to the wrong person - but can't be arsed to go back and reply to the original post, so there you have it
PooperPig - Coming Soon
|
|
|
|
|
This is a variation on one of the most famous crossword clues of all time:
HIJKLMNO (5)
It's an homage to that clue.
|
|
|
|
|
Oh, I know, I was just pointing out that the clue didn't have the answer as ay part of it - so no confirmation.
With a 'real' crossword this is less important, as the confirmation comes from other clues confirming letters in the proposed answer.
But when it is stand-alone, without the confirmation, there is every chance of multiple, apparently valid, answers.
d'you think I'm taking this too seriously?
PooperPig - Coming Soon
|
|
|
|
|
|
Just thought - coming from you, that should be
HJKLNO I M
if you see what I mean (if you don't, think avatars)
PooperPig - Coming Soon
|
|
|
|
|
Don't worry, tomorrow the clue will have a clue to what the clue's about.
veni bibi saltavi
|
|
|
|
|
But will anybody else?
Oh, and here's the first guess as to tomorrows answer: "GIN"
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Whatever should it be, I am sure Paris is not gonna like it.
Your time will come, if you let it be right.
|
|
|
|
|
...a really, really, really stupid idea.
Let's pretend that EJB3 was a good idea.
Let's double down on incompetent developers pretending they are passable data modelers.
Let's double down on incompetent developers pretending they are database administrators.
Let's double down on giving the application layers primacy over all others.
Let's double down on incompetent developers resolving the Object Relational Impedance Mismatch by completely ignoring it.
Let's double down on incompetent developers treating databases as little more than a bag for their crap.
Guess who is up all night fixing someone else's quagmire.
"I need build Skynet. Plz send code"
modified 11-Feb-15 1:35am.
|
|
|
|
|
Alaric_ wrote: Guess who is up all night fixing someone else's quagmire.
Never fear, super dog is here?!
|
|
|
|
|
tbh it sounds like you've got a management/personnel problem rather than a code/tool problem
unless you're saying there's some limitation in EF code first?
|
|
|
|
|
Sounds like a DB admin rant. remember that some DB admins think that programmers are the spawn of the devil* and should not be let anywhere near the sacred databases
*(not that some programmers are not the spawn of the devil)
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
Speak for yourself, little spawn.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
I thought you were busy annoying the Greeks
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
I was busy having a cold last week and having to fix an entire list of highest priority problems in motor testing software for expensive cars. I never was in the moneylending business.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
Bergholt Stuttley Johnson wrote: Sounds like a DB admin rant. remember that some DB admins think that programmers are the spawn of the devil* and should not be let anywhere near the sacred databases
For the record, I'm an application architect and C# developer first.
I'm also (I feel) a competent domain modeler, a competent relational data modeler, a competent "junior" database administrator, and a world class Service Nazi.
And no, you absolutely aren't supposed to touch a database as an application developer. The relational model is an implementation detail. You can touch the database while wearing a data modeler's or a database administrator's hat, but not as an application developer. You will break sh*t.
"I need build Skynet. Plz send code"
modified 11-Feb-15 11:09am.
|
|
|
|
|
yet by your own argument you should not be let near the DB, the problem isn't the Idea of code first but the fact that companies let staff attempt it without sufficient training - its not the tools its the implementation.
sorry but you have got to remember that sometimes DB is basically a bucket to store info used by the application, and as such it should be driven by the application.
I have had system that missed delivery dates due to DB admins over engineering simple dbs so the problem can be from both directions
I would ensure that any code first project on my watch at least had the input from the database side if not one assigned as part of the project, to write off a tool because you feel left out is not the answer
You cant outrun the world, but there is no harm in getting a head start
Real stupidity beats artificial intelligence every time.
|
|
|
|
|
Bergholt Stuttley Johnson wrote: yet by your own argument you should not be let near the DB
How so? You have misunderstood my argument(more of a rant than an actual argument) if you feel I said that.
Bergholt Stuttley Johnson wrote: sorry but you have got to remember that sometimes DB is basically a bucket to store info used by the application,
Implementation detail. That's not to the application developer to decide. That's for the data modeler to decide, even if those are the same person.
Bergholt Stuttley Johnson wrote: I have had system that missed delivery dates due to DB admins over engineering simple dbs so the problem can be from both directions
Over engineering is an orthogonal concern. If you have a defined layer of Views, Stored Procedures, and Functions as your interface into the database, then a DBA should have full rein to normalize the physical tables any way they see fit, within project constraints.
Bergholt Stuttley Johnson wrote: to write off a tool because you feel left out is not the answer
I never feel left out. Crappy Entity Framework implementations and Code First databases have generated a ton of work for me. It's just disheartening to have to explain to businesses that the green field developers that dropped in on them with industry jargon and "bleeding edge" tools royally ripped them off.
"I need build Skynet. Plz send code"
modified 11-Feb-15 12:30pm.
|
|
|
|
|
cjb110 wrote: unless you're saying there's some limitation in EF code first?
It's limited by design by not only allowing but promoting the structure of application artifacts(and the context that was used to write them) to dictate the persistence model of a system.
As with the DataSet, if you are developing a toy, it works great. If you're trying to do anything substantial, it falls flat on its face and costs you more than it helps you.
"I need build Skynet. Plz send code"
modified 11-Feb-15 12:52pm.
|
|
|
|
|
You don't understand Code Based modelling. Then, you have incompetent developers. That's now three problems, the third being you have no competent DB developers/DBAs.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
Brady Kelly wrote: You don't understand Code Based modelling. Then, you have incompetent developers. That's now three problems, the third being you have no competent DB developers/DBAs.
There's really very little to understand. Code based modeling came about as a way to "easily" maintain an implementation history of a database, which can be done just as effectively by other methods without castrating your data model.
"I need build Skynet. Plz send code"
|
|
|
|
|
The problem with being a clever bugger is that you might get to thinking that you can do everyone's job better than they can.
Development is a field that has lots and lots of clever buggers, ergo...
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
As with just about everything in software development, if it is implemented badly it is a crock of shite.
But blameth not the tool, for t'is the wielder of the tool that is the tool.
code 1st database could be a good idea if it is well understood by the developer who creates suitable classes to be stored efficiently etc.
But the people that want to use that sort of thing tend to be those that are scared of those three letters (SQL) so feel more comfortable treating that side of things as a black box.
it is, unfortunately, black like the heart of a serial killer.
I have worked at so many places where the developers use some sort of ORM system (code first or Data first) and just f*** it up because they don't think about what it's doing behind the scenes.
Imagine a system displaying three months of an appointment calendar, for three people, where appointments are, say, 30 minutes long. So 16 appointments per day, 90 days, 3 people - that's over 4000 appointments.
Now imagine someone uses an ORM to grab the details; each appointment has a customer, and a doctor - so off they go to the ORM and ask for the details of those appointments. What do they get back? Gigabytes of data, names, addresses, previous appointments etc. etc.
What gets displayed on the screen? Their name!
Because they wanted to save a little time writing some SQL by having some clever little system write it for them - but never thought to check what they were actually returning from the database was relevant to what they actually needed!
The appointment example was a real system - and they asked for it to refresh every 30 seconds so they always saw up-to-date appointments.
"It worked fine in testing" - yes - with a handful of test appointments for one person.
First real test at refreshing stopped the entire system as the network flooded with data from the database server.
I digress.
PooperPig - Coming Soon
|
|
|
|
|
I have just the opposite right in front of my nose at this very moment. There is no distinction between layers. The whole application's logic is squeezed into stored procedures and database triggers.
Main properties of this 'code':
- It's 100% unreadable. Any hint to what's going on is hidden under masses of SQL, crazy casts, magic numbers, wild joins and thousands of lines of spaghetti code.
- It's redundant, every single task is also done in a similar way in several other procedures.
- Things are never as they seem. On every data table are several triggers. The triggers are extremely long, often thousands of lines and try to handle every consequence of every thinkable change in their datatables. And, of course, they also set off some more triggers. Even changing the sequence of some unrelated SQL statements in an SP can cause a totally different reaction of the triggers.
If I had the choice right now, I would much more like to deal with an ORM running amok than with this trigger hell.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|