My Community

Deconstructing Lebowski => Lebowskian Philosophy => Topic started by: DigitalBuddha on February 03, 2013, 08:23:09 PM

Title: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: DigitalBuddha on February 03, 2013, 08:23:09 PM
    10 Reasons Why Being a Lazy Dude is Actually a Good Thing   

(http://img853.imageshack.us/img853/9431/dividera.gif)

"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/ (http://rebelzen.com/2008/09/10-reasons-why-being-a-lazy-dude-is-actually-a-good-thing/)

(http://s3.vidimg.popscreen.com/original/9/MjQ1NDkzMjUz_o_dudes-bowling-tape.jpg)
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: Hominid on February 03, 2013, 09:12:42 PM
Love it DB...
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: DigitalBuddha on February 04, 2013, 02:34:04 AM
Love it DB...

Far out, mang! 8)(http://dudeism.com/smf/Themes/default/images/post/thumbup.gif)
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: GreenMaude on February 04, 2013, 05:56:23 AM
Nice, I read another couple of posts, interesting blog! Cheers man
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: meekon5 on February 04, 2013, 09:43:20 AM
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!
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: 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...
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: meekon5 on February 04, 2013, 11:39:56 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.
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: RighteousDude on February 04, 2013, 02:22:57 PM
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++.
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: meekon5 on February 05, 2013, 07:18:28 AM
...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.
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: BikerDude on February 05, 2013, 08:13:43 AM
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.
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: cckeiser on February 05, 2013, 01:53:50 PM
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 (http://www.foxnews.com/politics/2013/02/05/study-work-less-save-planet/?test=latestnews#ixzz2K3IyyhIJ)

Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: RighteousDude on February 05, 2013, 11:58:44 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.
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: RighteousDude on February 06, 2013, 12:36:39 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.
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: Zen Dog on February 06, 2013, 05:22:53 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.
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: RighteousDude on February 06, 2013, 07:38:49 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
Title: Re: 10 Reasons Why Being a Lazy Dude is Actually a Good Thing
Post by: BikerDude on February 06, 2013, 08:21:07 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.

For me the big thing is to keep DBA's out of the equation because in most large agencies the "process" suxs.
You throw a request over the wall and twiddle thumbs till it's implemented.
The goal for me is to implement the system so I can sit someone down and pull the whole project for Subversion or CVS and twiddle a couple configs and have a working system. Ownership is a huge advantage.
As soon as you start to spread that out you get anguish from other people's nonsense.