Please create an account to participate in the Slashdot moderation system


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Ah yes... (Score 1) 43

So, the only financial transactions that any business engages in are securities trades? I guess I need to dig deeper to understand exactly how stock trades get involved in my employer making bi-weekly direct deposits into our (mine and my coworker's) accounts. I'll also ask my brother-in-law what stocks he is using to make payments to the corporation he is a franchisee of and to pay his food suppliers and such.

Or maybe CaptSlaq and H3lldr0p should find some other deceased equines to pummel.

When you have an error as massive as the last one caused in part by automation, it might possibly be understandable that such announcements of further automation are suspect until evidence of actual improvement has happened. How much evidence it takes to regain trust in a system is up for debate.

Comment Re:Mostly... (Score 1) 178

If the (then) future hadn't gone the way that it did

If there is anything that I have learned is if something can go wrong it WILL go wrong. Don't let it go wrong in the first place. Spend the extra 1 second and think about your code before you vomit your crap code into production. It isn't "premature optimization" until it makes it some degree harder to understand than the non-optimized version. Most of what people call "premature optimization" is really just writing correct code. Should I use String.EndsWith or String.Contains to find if a string has a certain suffix? Should I use an explicit cross join and filter in the WHERE clause or use inner joins? These are examples of the level of boneheadedness that most people write code. Don't get me started on multi-threading. If you don't find it intuitive, please don't do it. Most of the time I can make someone's code several factors faster with virtually zero effort while making it easier to read. And when I say "faster" I don't mean as in micro-benchmarking the code in simplistic situations, I mean production where the entirety of the code is being called many times on many threads. Sure, your "read the entire file into memory and write it back out" works fine in your simple tests, but throw it in production and the 400MiB files put massive pressure on memory when there are hundreds of jobs running at the same time all trying to load the entirety of files into memory before writing them out. STREAM the files. Then you have the issue of many times good code runs slower in synthetic benchmarks but runs faster in production. Everyone focuses on empirical evidence, but then compare apples and oranges when thinking their dev boxes or servers are the same as prod in that the computers are only running their code in tight loops

Bad code and bad coders exist. The bell curve suggests that some 50% of developers and code fall on the wrong side of that. I may be one of them, who knows.

I don't disagree with your assessment. As I've learned in my years of working as a sysadmin and developer, there's precious little code that can't have some sort work done on it for readability and/or performance's sake. Many (myself included) have lost sight of the forest for the trees time to time. Sometimes you get people doing things that they've never had to do before. Sometimes you wind up with a problem out of your league that has to be solved. It happens. Problems still have to get solved/code written though.

The other thing I've learned is that "Delivered puts food on the table. Perfect is the enemy of delivered." I always try to push the best code I can out the door, but sometimes I just don't have the experience or knowledge to write the perfect solution to everything I work on. I think everyone runs up on this from time to time. Anyone who claims otherwise is either lying or has stagnated in their career/work.

The best way I know to AVOID pushing crap out the door is to have a peer review done, preferably by a peer who is better than you. Many eyes and all. For many years, I had no peers to review and see the potential problems, working as a 1 man code shop.

That said, to address your example, slurping an entire file into RAM is a pretty dumb idea, if it's able to be processed in a window. I'm sure many people have horror stories of "wow, that's a dumb idea" that they can impart, myself included. Fix the problem, move on. If the dev who wrote the offending code is available, ask them what they were trying to do. Make it a teachable moment. Make the world better. [insert something about sunshine and rainbows here].

Or not. I'm just another user account on Slashdot.

Comment Re:Mostly... (Score 1) 178

The problem is it's the mindset and everyone seems to have it these days. "Oh, bandwidth isn't limited" "processors are more powerful" etc. You get a program built with 10 pieces of separate code that everyone failed to optimize and suddenly it's sucking 3x the bandwidth and 5x the processing power that it would have if everyone involved actually thought about optimization.

Where I work we go back and refactor a lot of our code and queries when we have opportunities to do so and in some cases it's horrifying the waste that's been put up with. A SQL query that "works" but takes 30 seconds gets rewritten properly and now takes .3 seconds. Back when that was the only app on that server it ran faster so it was "no big deal" but now it saves hours of batch processing time per day. And this is EVERYWHERE. People wonder why their octa-core phones run barely faster than phones from 3 years ago? Shitloads of wasteful coding in those app design tools is my guess.

That SQL query that "works" was effective for the time. If the (then) future hadn't gone the way that it did, that 30 seconds may have continued to be completely acceptable. Judging code on CURRENT use case misses the point of skipping premature optimization (and using that time saved on something else) when it's not needed.

That said, there often comes a time when it's required. That's when you do the optimization. Which sounds like it's exactly what you've done.

Working as intended.

Comment Re:Less header (Score 1) 226

Ugh, christ, it's people like you screaming "MUH VERTICAL REAL ESTATE" that killed the status bar and prompted Mozilla to push the URL of autocomplete suggestions off to the right side of the UI, completely unjustified relative to the other URLs making it impossible to scan with the eye.

It's people like you pushing UIs towards the lowest common denominator, the phone.

Please take a long walk off a short pier at your earliest convenience.

The 4:3 monitor isn't a thing anymore, and many monitors don't support tilt, so they're stuck in a wide screen orientation. Suggestions on how to preserve vertical real estate and fix your complaint are probably welcome. Code is even better. You sound like a smart guy, lets see some action.

Comment Re:How About Some Actual Data... (Score 1) 182

When those 100,000 people are dying of a horrible cancer, I'll make sure to send their families your address and let them know you voted to give them cancer because you were too cheap to pay for cleanup. "You attitude is dangerous and impractical". Those words are the reason the entire planet is polluted and dying. I would argue that you have the dangerous attitude.

The tone deafness of the parent posting this from a computer is delicious.

Comment Re:Headphone Jack is Pretty Crappy (Score 1) 536

It wears out ridiculously fast.

For what value of "ridiculously"? I don't have a single 3.5 mm jack in the house with bad connection poltergeists.

But then, I'm still running an NAD 7140 from the 1980s as my stereo amplifier. Had to go in there last week with electrical contact cleaner to take the crackle out of the volume and balance pots, but I'm sure the audio jack still works perfectly. I'd have replaced some of the electrolytics, too, if my ears could hear any defects.

Obviously, though, I'm not a desirable Apple customer on several counts (ability to fix things myself, willingness to keep using unfashionable equipment that still works fine, ability to tell whether unfashionable equipment still works fine), so there is that.

Yamaha M4 here, with a Parasound PHP 850 in front of it. Long live the affordable analog!

Slashdot Top Deals

panic: kernel trap (ignored)