|
The point is that if you need to retry an operation, inject a class that handles retrying it and call THAT instead. What happens if you need to retry it twice? Just add another ?? GetMessage() to everything? Awful.
|
#
¿
Sep 14, 2012 17:21
|
|
|
|
| # ¿ May 17, 2024 18:40 |
|
|
Golbez posted:When you code for a system that you know is 5.3, do you include caveats for if your PHP suddenly reverted to 4.0? Because that's as likely as magic quotes being turned on on my server, so I wouldn't include caveats for that either. Yes? I don't do any PHP, but in perl it's good practice to require the version you need (see http://perldoc.perl.org/functions/require.html). Not doing that seems kind of crazy with a dynamic language to me. I think in python I had to jump through some extra hoops, but I still remember doing this check. If your code depends on some setting in the config being set a certain way to behave properly, then it drat well better fail fast and loud if it's not set as expected.
|
|
#
¿
Oct 4, 2012 17:22
|
|
|
I love to rip on MySQL as much as the next guy, but the horror is clearly not them. It's in the query that doesn't explicitly order by date. By definition, unordered results are unordered, and you will get weird poo poo like that.
|
|
#
¿
Dec 18, 2012 15:01
|
|
|
People who write terrible code shouldn't be ridiculed, they should just be fired, that's much nicer
|
|
#
¿
Jan 26, 2013 02:36
|
|
|
Doctor w-rw-rw- posted:People who write bad code should be handled by adults, not tried and convicted by immature manchildren. God drat. I'm being super lame by posting this but I was being facetious. I've worked with and rehabilitated people responsible for far worse things. But more posting bad code, less talking about bad coders.
|
|
#
¿
Jan 26, 2013 18:11
|
|
|
Nippashish posted:If you're using a random per-user (or whatever) salt how do you check the password when the user logs in? Do you store the salt somewhere? If so where, and why is this less vulnerable than not using a salt at all. If not then wtf how does that work? The point is that when your database is leaked because someone dumped out an old db archive that wasn't as well secured, or whatever infrastructure leak you discover, they still can't reverse the hash into your actual password that you typed in. This literally just happened with LinkedIn - someone ended up with all of the hashes from their database, and they were able to very quickly reverse a LOT of those hashes into the user's actual password! Why? Because they could simultaneously attack *all* passwords at once. That is, start a dictionary attack, hashing each possible word and checking all the stolen password hashes for any hits. Run this on a large grid over a few days, and you will get a lot of hits - all of the weakest passwords in your userbase. If they had randomized per-user hashes (and even if the attacker has possession of those hashes, which you should assume), they would have to run a new dictionary attack on each hash individually. This means that your weakest passwords aren't instantly crackable via a rainbow table or dictionary attack.
|
|
#
¿
Mar 5, 2013 04:49
|
|
|
One possible scenario was explained in this very thread.
|
|
#
¿
Jun 24, 2013 20:59
|
|
|
DAT NIGGA HOW posted:If he had said, "use this other system instead, it is better than cryptocat", then his message would have been constructive. But instead, he's just saying "cryptocat sucks dont use it", thats not constructive. It absolutely is constructive. The threat of public embarrassment about your product being broken creates an incentive towards quality, which benefits everyone who uses software.
|
|
#
¿
Jul 7, 2013 00:30
|
|
|
For some serious coding horrors, think of how you'd use the win32 api hack/workaround for longer paths from a C# application. The horror at the time I had to do this was me.  Edit: for a good discussion of why this is so horrific to do, see http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx npe fucked around with this message at 17:10 on Aug 26, 2013 |
|
#
¿
Aug 26, 2013 17:08
|
|
|
Movac posted:Sometimes I get glimpses of this parallel programming culture where improving skills or tools beyond the bare spartan minimum to get today's to-do list finished is considered a waste of time, and it scares the hell out of me. If that type ran computing, we'd still be using punch cards. This happens maybe more often than people realize. In my experience it can occur when a programming group is directly subservient to a business group engaged in something profitable but repetitive. Programming is odd in that the work you do can directly lead to making that same work easier and better - but to a business line, this may not be acceptable for "moral" reasons. They're paying you to make THEIR work easier and better, not to improve your own lot, and if they have to slog through repetitive tasks day in and day out, the programmers shouldn't get it any easier. This means that "I did it on my own time" won't always keep you in the clear - I've been trashed for that, too. It's far better to keep any improvements completely off the radar. I realize people will think I'm full of poo poo, but I've worked in the legal software industry for years and have been lectured at length about this hostility. "Programmers think they are so special. Well, they should suffer like the rest of us."
|
|
#
¿
Sep 5, 2013 02:26
|
|
|
GrumpyDoctor posted:So if "We don't mind if it takes longer" means "We're being micromanaged to hell," and "Our focus is on delivery and" means "We have no plan to manage technical debt," what's the secret code for an actual good place to work? Or are we all just hosed? There isn't any set of words for this, probably because if there was it would be quickly subverted by lovely places to work and would become a euphemism for something else. The reality is that a properly managed team will be constantly evaluating the cost/benefit of making progress on outward features vs managing technical debt. This means even in a healthy environment, this fight never truly goes away - it's more that you engage in the debate on an ongoing basis. Good teams find themselves asking a lot of "I can fix this very quickly, but it could lead to problems later. Is it worth it now to take the longer way to do it right?" And the answer will vary quite a bit, depending on the variables. Teams that have hard and fast answers in one direction or another, you should be wary of.
|
|
#
¿
Sep 9, 2013 03:45
|
|
|
Knyteguy posted:Can always go the consulting route, too. I'm not "old" but in my late 30's and know a bunch of mid 40's devs, which is probably what you mean. I think the ageism thing is overblown a tad, but what I think is definitely true is that the stakes are higher: no one is going to want to hire a mediocre 45 year old. You better bring some serious poo poo to the table, and be prepared to take on more responsibilities (project management, etc). And the flip side to no one hiring you because of excessive job hopping is no one wanting to hire you because all you did was work at one job with one tech for 20 years. Both are real problems, and a middle ground is probably not a terrible idea.
|
|
#
¿
Sep 27, 2013 21:11
|
|
|
Pollyanna posted:Cool. So why not write in another language like Scala, Jython or Clojure and have that run on the JVM instead? I work for a company that has taken the plunge and is attempting to do as much as possible in Scala, for this reason. I feel somewhat experienced to talk about this. The main reason most companies stick with plain Java is that it's well understood by a lot of people and there's a zillion native libraries for it. Yes, you can use almost all of these libraries from these other languages, but there are pain points (Scala does not suffer nulls gladly, so you need to be careful when interacting with regular java libs). Scala uses different types, and has tricks for getting around type erasure, all of which you will run into as a problem at some point or another. It's easier to hire people who know Java - it's been around forever and it's been the lingua franca of ENTERPRISE applications for years. If you need to hire 5 mediocre dudes quickly, Java is easy to find. But additionally, and more importantly, I would be lying if I said that it's pain-free to write Scala in practice. For one thing, if you have any mediocre programmers on your team they will quickly be lost and do terrible things. But worse, the toolchain support is sketchy at best - so far IntelliJ with the Scala plugin has been ok, but it's nowhere near as mature as native Java support. Compile times are much slower, too. I love Scala and think we made the right choice, but a more established, conservative company with a larger team will balk at these issues and I can't say I'd blame them.
|
|
#
¿
Oct 4, 2013 02:09
|
|
|
It's not that Oracle isn't aware of nulls - it's that the empty string is special case transformed into nulls for you. It actually used to be possible to accidentally get around this, and forcefully load in empty strings (using their bulk loader utility). These values would not count as nulls but couldn't be queried out unless you did things weird, like specifying length of 0 (since where foo = '' won't work, as '' is immediately transformed into NULL).
|
|
#
¿
Nov 13, 2013 19:57
|
|
|
rrrrrrrrrrrt posted:How many of the people claiming to "only" use a text editor have enough plugins loaded up to effectively make them IDEs? Even when I'm using Sublime or Emacs I usually have enough features loaded in (incremental compilation, REPLs, syntax highlighting, goto def, snippets, tags, etc.) that they're effectively mini-IDEs. Back in my days writing perl, I just used a bare-bones vim editor with a gussied up .vimrc that just covered syntax highlighting. The thing of it is, you can't really get any useful IDE features out of a language that relies so heavily on runtime shenanigans for everything, so there's no point. Putty/vim/bash/screen and a handful of scripts to do searches and such, and that was all I used for years. Static languages, though, I use an IDE. Static analysis is pretty great.
|
|
#
¿
Nov 18, 2013 23:05
|
|
|
Thermopyle posted:I'm open to being talked out of this, but my position is that people who think dynamic language IDE's don't do Feature X from their favorite static language IDE just haven't surveyed the field very well. There's not really a way to have this discussion without turning it into a static-vs-dynamic shitfest, sadly. The main thing I use an IDE for in C#/Java, is for that instant feedback that the thing I just typed will actually compile. And "it compiles" in perl is kinda worthless, because misnamed methods in perl compile just fine. So now you're forced to try and use on the fly eval of code to guess if something is legit, but this isn't always possible - what if I'm relying on loading in some external resource to determine the name of that method? Anyways - this was a real problem I had and I just gave up. There wasn't any way to guarantee that when I typed $obj->do_thing that it was a method that existed, and that's really all I want out of an IDE. All the other refactoring tricks are just gravy built on top of that one basic feature.
|
|
#
¿
Nov 19, 2013 14:31
|
|
|
|
| # ¿ May 17, 2024 18:40 |
|
|
Jewel posted:Who in their right mind is inserting ~3.75 million records into a DB every day? That's ~150,000 an hour. ~2500 a minute. ~43 a second. The electronic discovery industry crushes this number. A company I worked for loaded more than that daily, and there was always pressure to get that number up. Before anyone asks - it's because the entire process revolves around taking dumps of exported data (usually mail server archives and desktop images) and processing them into data that can be easily searched and accessed by a large number of lawyers. For legal reasons, the chain of custody within the company needs to be tracked, so every single email and every single document that gets transmitted gets at least one row in a database. We're talking multiple TB of email data at a time. Our bulk data loaders were burning 24x7. We had legions of people working shifts to just keep the processing scripts running. Maybe e-discovery is a horrors thread unto itself, though.
|
|
#
¿
Nov 20, 2013 16:24
|
|