10 Reasons Why Being a Lazy Dude is Actually a Good Thing

Started by DigitalBuddha, February 03, 2013, 08:23:09 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DigitalBuddha

    10 Reasons Why Being a Lazy Dude is Actually a Good Thing   



"I have always been a very Lazy Dude, and in fact I come from a long line of them. But the way I see it, laziness is in fact a Godly virtue. Here's a few reasons why..."
8)

Is this, ahhh, what day is this? - http://rebelzen.com/2008/09/10-reasons-why-being-a-lazy-dude-is-actually-a-good-thing/



DigitalBuddha


GreenMaude

Nice, I read another couple of posts, interesting blog! Cheers man

meekon5

As discussed before. This is why I'm such a good Database Administrator, I am naturally lazy and think the machine should do all the work, so therefore I have acquired a set of awesome skills with which to make it (computers generally) bend to my all powerful will!
"I have noticed even people who claim everything is predestined, and  that we can do nothing to change it, look before they cross the road."
Stephen Hawking

Where are you Dude? Place your pin @ http://tinyurl.com/dudemap

Hominid

Ya, if I have to do more than 3 times, it gets scripted in shell or Perl.  They call me the script king at work...



meekon5

Quote from: Hominid on February 04, 2013, 10:17:09 AM
Ya, if I have to do more than 3 times, it gets scripted in shell or Perl.  They call me the script king at work...

It actually frustrates me when the web guys here do all this lovely coding in PHP or Java (bloody data manipulation in the thin client instead of in the database engine, bunch of numpties) and I look at it and wonder why they just didn't do it in T-SQL on the server, we have some beasts of database servers doing bugger all here.
"I have noticed even people who claim everything is predestined, and  that we can do nothing to change it, look before they cross the road."
Stephen Hawking

Where are you Dude? Place your pin @ http://tinyurl.com/dudemap

RighteousDude

Quote from: meekon5 on February 04, 2013, 11:39:56 AM
It actually frustrates me when the web guys here do all this lovely coding in PHP or Java

They may exist, but I've yet to see any PHP undertaking that's made use of stored procedures and I've seen many that work with dozens of tables and not a primary key among them. I try to avoid PHP but quite often end up with clients who initially want something sane but later ask me to hack up their vBulletin or whatever for them. Gawd, it's like wading naked through a cesspool.

On the up side, the quality of the average deployed perl application has increased dramatically since PHP came along and siphoned off the numskulls, as Java has done for C++.
I'm just gone, man, totally fucking gone.

meekon5

Quote from: RighteousDude on February 04, 2013, 02:22:57 PM
...that work with dozens of tables and not a primary key among them...

We (the museum) )actually managed to buy a commercially available database backed product for Digital Asset Management, that had no keys or indexes in any of the tables. It would have been nice if the comity involved had had some ICT input because we would have laughed them out of the building instead of spending two years and over a million pounds trying to get the thing to work.
"I have noticed even people who claim everything is predestined, and  that we can do nothing to change it, look before they cross the road."
Stephen Hawking

Where are you Dude? Place your pin @ http://tinyurl.com/dudemap

BikerDude

J2EE and some type of ORM solution is what I deal with most often.
I try to keep logic out of the DBMS when possible. Decoupling app logic adds complexity.
But stored procs often have a big performance advantage.
Ideally I'd rather use JDBC and plain old sql whenever possible.
The ORM "fad" is turning out to be just that.


Out here we are all his children


cckeiser

Hey! Just found this.... Study: Work less, save the planet

Americans should work less, play more -- and in doing so, save the planet. That?s the basic formula a Washington think tank is shopping around as a way to cut down on global warming.

Read more: http://www.foxnews.com/politics/2013/02/05/study-work-less-save-planet/?test=latestnews#ixzz2K3IyyhIJ

There are not Answers.....there are only Choices.

Please...Do No Harm
http://donoharm.us

RighteousDude

Quote from: cckeiser on February 05, 2013, 01:53:50 PM
Americans should work less, play more -- and in doing so, save the planet.

The friction becomes unbearable when no one will pay you to play more and working less means you get fired. The shit is broke, man, broke bad.

I'm not whining about it; my work week is 3.5 ten hour days and I do okay that way. When I can score 27 billable hours per week I'm fuckin' dancin' all over the house. But most folks can't get by on fewer than 40 or more billables per week because the fruits of their labor go in the main to executives and shareholders. We should work less? Sure. We can work less? Not today. It's a fuckin' broke system when the more people you fire the bigger your annual income.
I'm just gone, man, totally fucking gone.

RighteousDude

#12
Quote from: BikerDude on February 05, 2013, 08:13:43 AM
I try to keep logic out of the DBMS when possible. Decoupling app logic adds complexity.
But stored procs often have a big performance advantage.

That's where I see the glitch. If I can poke a stored procedure into the database I can gain both a runtime advantage and a code (non-) complexity advantage. If portability is a concern I can use a fucking phrasebook that says use this query for this database, that query  for that database, and some really obscure shit for some really obscure database. In, out, done. Cheap, easy, good, pick all three.

Not so very long ago (from the perspective of a 50+ Dude) I wrote a middleware-ish application that tied big-name routers, an ubiquitous network security scanner, and an ERM system together. The interesting part was interfacing to the ERM, which has an API and whatnot but that requires developer seat licenses and all kinds of other bullshit that I wasn't enabled to wade through to get at it. We had us a big ole geeky motherfuckin' teleconference with some managerdoids involved to make sure that no fiefdoms were encroached, and the final solution was that the DBA's who understood the ERM would create some procedures, and all my code would have to do was spew some data at the database. No API bullshit, no seat licensing, no pain at all. Some DBA spent four minutes crafting a nice procedure, and I passed it some data. It was easy as jerking off manually with a palm that profusely sweats oil when aroused.

So my end just spews data, their end just twiddles it with DBA-fu, and that is that. It works so fucking well that they haven't had a beef in six years.

That's my perspective as a developer. If some DBA can improve my queries, fuck it, let 'em at it. I don't want to learn which SQL works with which database and which are more efficient. Let the guys who live and breathe that shit file bug reports. Meantime, I'll think about my code. Win  : fucking win. Put the logic into the fucking database where the guys who live and breathe that shit can deal with it, and in the end everyone wins.
I'm just gone, man, totally fucking gone.

Zen Dog

Quote from: RighteousDude on February 06, 2013, 12:36:39 AM
Quote from: BikerDude on February 05, 2013, 08:13:43 AM
I try to keep logic out of the DBMS when possible. Decoupling app logic adds complexity.
But stored procs often have a big performance advantage.

That's where I see the glitch. If I can poke a stored procedure into the database I can gain both a runtime advantage and a code (non-) complexity advantage. If portability is a concern I can use a fucking phrasebook that says use this query for this database, that query  for that database, and some really obscure shit for some really obscure database. In, out, done. Cheap, easy, good, pick all three.

Not so very long ago (from the perspective of a 50+ Dude) I wrote a middleware-ish application that tied big-name routers, an ubiquitous network security scanner, and an ERM system together. The interesting part was interfacing to the ERM, which has an API and whatnot but that requires developer seat licenses and all kinds of other bullshit that I wasn't enabled to wade through to get at it. We had us a big ole geeky motherfuckin' teleconference with some managerdoids involved to make sure that no fiefdoms were encroached, and the final solution was that the DBA's who understood the ERM would create some procedures, and all my code would have to do was spew some data at the database. No API bullshit, no seat licensing, no pain at all. Some DBA spent four minutes crafting a nice procedure, and I passed it some data. It was easy as jerking off manually with a palm that profusely sweats oil when aroused.

So my end just spews data, their end just twiddles it with DBA-fu, and that is that. It works so fucking well that they haven't had a beef in six years.

That's my perspective as a developer. If some DBA can improve my queries, fuck it, let 'em at it. I don't want to learn which SQL works with which database and which are more efficient. Let the guys who live and breathe that shit file bug reports. Meantime, I'll think about my code. Win  : fucking win. Put the logic into the fucking database where the guys who live and breathe that shit can deal with it, and in the end everyone wins.
Unable to read.Eyes glazed over after first para.
If you believe you can tell me what to think.
I believe I can tell you where to go.

RighteousDude

Quote from: Zen Dog on February 06, 2013, 05:22:53 AM
Unable to read.Eyes glazed over after first para.

Ya think it was tough to read? Fuck, man, my whole head glazed over writing it.  :o
I'm just gone, man, totally fucking gone.