<scriptkiddie> Anyone know how RubyInline chooses its tempory directory?
I have an app running as one user, but ImageScience
(which uses ruby_inline) is trying to write to
/root/.ruby_inline
<zenspider> scriptkiddie: did you look?
<zenspider> scriptkiddie: did you even remotely bother to look?
<zenspider> I mean... you ARE a developer, right?
<scriptkiddie> I googled. Didn't see anything immediately about
ruby inline tempory directories
<teferi> Did you try looking at the source?
<zenspider> this is a huge pet peeve of mine
<zenspider> so, calibrate accordingly
<scriptkiddie> No, digging through the source is after nobody
can answer such a siple question.
I simply don't get it. Never have. I'm of the opinion that real developers read at least as much code as they write. That they're driven to learn and they do that by exploring. I have this in mind when I design my developer tools, and I keep my code as short and clear as possible. I try to make the job easier to look through my code. I don't get it when I see blindly-unthinking questions like the above.
(I guess I should also add that the question is easily answered with basic googling... so, yeah.)
So... are you a developer, or a script-kiddie? Do you want to hone your craft? Improve your code? Improve yourself? Or do you do the minimal job possible to get by and go home for the day? Do you rely on the knowledge and skills of others to do your job?
Absolutely agree. Back in the days of Rails 0.5, I learned Ruby mostly because I simply read 90% of Rails' source code, figuring out what it did and trying out stuff in irb. Though nowadays I wouldn't recommend this approach to someone new to Ruby (Rails' code complexity has increased a lot) there are bound to be other great projects which lend itself equally well.
And still now, I read about as much source code as actual API documentation.
I agree too - to a point. I definitely think there is some middle ground these days. Don't get me wrong, I do believe there is a point where exhaustive "learning" comes in to play. But, sometimes I don't really want to know the gore inner details of some system...I just want the damn thing to work as expected and I don't have time to figure it out from the roots.
This kind of reminds me back when Linux was first getting some "amateur" attention in the mid 90's. Somebody would pop in an IRC room and ask how to get something to compile, or why X wouldn't start. To me, the OS was a means to the end. And, I never understood why so many were quick to drop the RTFM line. The answer or a pointer in the right direction would've been so much better for all involved.
There's also the notion of being lazy. Or even the pain of perpetual learning. Sometimes it is OK to not know - simply because somebody else already has the answer...especially when know how something works internally has no real benefit.
Again, please don't think I'm trying to justify laziness (or that I even would rationalize the context of the dialog. But, sometimes I really believe there is middle ground between script-kiddie and developer. The software role is becoming more about integration. Ruby is well primed for this, which I think is why you guys probably see the script-kiddie mindset often - even though it may be an individual who is well-versed in the bigger-picture software ways.
This kind of brings up the community rub too. Maybe this is a script-kiddie, or really just a kid. (Wearing my leadership hat) Maybe it would just be better to help the guy out with your experience, sans the rudeness. Because, at the end of the day who really gives a shit about what your pet peeves are.
"Hey, here's a sample code snippet I found that doesn't compile anymore now that I've hacked it up. Can you fix it for me?"
"Can you just Google it for me and tell me the answer?"
"Psst. What'd you put for #21 on the fill in the blank section? And #22, 23, and 24, what about them?"
"Can I just turn in your essay and you write a different one and turn that in?"
. . .
"I really tried but I'm stuck, can you get me unstuck?" != "I'm lazy, do it for me."
@kitplummer,
"I definitely think there is some middle ground these days."
Of course there is a middle ground. But really the middle ground doesn't range from 0.0 to 1.0. There is no 1.0 but there are plenty of blindly-unthinking 0.0's. No, instead it ranges from 1 (newb dev) to as high as you can achieve. All I'm really asking is: are you a developer or not?
This individual wasn't "just a kid"... I edited plenty of the transcript out. No, this person had zero desire to learn, zero desire to teach themselves, and absolutely no compunction to waste other's time in that regard. But, I can appreciate you giving them the benefit of the doubt.
I don't think that what we're seeing is a shifting of the guard towards integration. We've been down the 4GL/CASE/code-generation route time and time again to no avail. It won't happen, not even with ruby. No, what we're seeing is yet another wave where we lower the bar by hiring anyone and everyone without standards in the name of (blindly unthinking) greed. Like CASE, we've seen it before, and we'll see it again.
"Because, at the end of the day who really gives a shit about what your pet peeves are."
In case it isn't utterly obvious, I do. Welcome to my blog.
I understand your sentiments but taken to the extreme what you've expressed is totally dysfunctional outside the context of snarky IRC channels, where it is totally awesome.
Once there is more than one person on a project, the best use of everyone's time is not for every person to go find the answer to every question on their own. That would be pathological.
More than once I've seen an 'intelligent' engineer spend a shit-ton of time figuring out something that the guy in the next desk knows cold.
How does that make sense to anyone?
@stochastic,
"... but taken to the extreme ... ... How does that make sense to anyone?"
How does taking anything to the extreme make sense to anyone?
Congratulations for squelching a script kiddie's sense of curiosity, ensuring he or she will never graduate to developer.
I ask questions of people about Rails all the time, that could be answered if I spent half an hour poring through its source code. But if I have to do that, Rails' docs and community have failed. That should be the last resort.
You could be a little nicer.