[_] Grow the f*** up!
[_] Kill yourself now and avoid the rush (and collect your darwin, because morons like you shouldn't be reproducing) !
[_] Send me your money and I'll tell you how to get into the secret government refuge.
[_] It's the rapture, silly! Welcome our new overlords
[_] This is our tax dollars at work?
[_] Cheese!
You don't tell them you're doing that... you just do it. It's quicker anyway...
You could have made the wrong call, chasing dead end, the time is up and what was required is not done. Happens as often as not, though experiences improve your percentage.
... if you haven't developed the nose for bugs, then you're wasting your time anyway. Some people have it, some don't. It's like some people are afraid to question code because it mostly works. If they haven't got the "nose" for it, debugging is going to be hell for them. Boring. Frustrating.
The same people who complain that their mouse is defective because it can't go any further - and they can't figure out to pick the thing up and move it back? Yeah, been there, done that.
Move the monitor when they're not there, an inch or so a day. They'll never notice.
Our initials were tagged to every LOC that was touched. Talk about personal responsibility.
THAT is a key point. There should always be an @blame line or equivalent. I put my external email there, so that even 10 years down the road, if a problem comes up, they know who to blame, or who to ask.
Everyone who's worked with me on code has, when the time comes to part ways, thanked me. They've seen me stand up to the boss for them, they've seen me take the heat for their screw-ups rather than point fingers, etc. Heck, I've even written their reports for them, their on-line dating ads, negotiated claim settlements with their car insurance, done their backups when they haven't, recovered them from those backups when the inevitable "Oh shit... ummmm... do you have a copy of all my files for the last year? I think I deleted them", taught them stuff they should have already known but didn't, helped the testers find the bugs, made the coffee, bought snacks for everyone, tried to explain the boss's point of view to everyone so that they could see there's two sides to it, taken the boss aside and told him when he's pushing against a piece of string or being really counter-productive, told him to F off when he's gone too far overboard, etc.
It's the right way to work, and I've been doing this for too long to bother with the BS of negotiating how long something is going to take, or how many corners can be safely cut. In case of urgency, I'll cut as much as I can, but there's a limit before it gets counter-productive, and having to do it logged into a live server, editing the code, recompiling, linking, etc., sure, I'll do it, but I'm going to be extra cautious, and it's going to be replaced asap with code that's properly fixed before I do anything else, so kindly don't bug me for the rest of the afternoon:-)
Then you have a process and management problem, not a coding problem.
One person should have the authority to approve or disapprove.
It's like when you make a complaint, and they say "I'm sorry, I can't do that." The proper response is "Then why am I wasting both of our time talking to you? Please pass me to someone who can."
For most of your arguments, please read my responses elsewhere. There's no reason why you can't clean up small areas of code, and the time savings will start to add up.
As for:
Good luck getting them on board with your big plans, when they are already working 60 hours a week trying to get their actual assignments done
This is a management problem. If people are doing 60 hours a week on code, they're working well below peak efficiency, and probably introducing more bugs than they're fixing. It also indicates that management either didn't allocate resources properly, over-promised, or otherwise screwed up in their planning. In other words, they didn't "manage" properly.
It's also a programmer problem, because programmers often don't have the guts to say "I'm past my peak. I'm going home. See you guys tomorrow." and confront management over the screw-up over resource allocation and planning.
How many times has coding become a negotiating session, where each side is trying to bargain as to how long it'll take? That's just stupid. If you say "One to two days" they hear "one day", and then cut it in half. So you add an extra day, they still cut it to one day, because they expected you to add the padding... and $DIETY help you if you run into something unexpected - which you will, because it IS buggy code if you have to fix it, so there's going to be something unexpected by definition.
1. Refuse to play the "negotiate how long" game. Be honest. And be up-front that you're being honest. "Honestly, it'll take what it takes. Or do you want me to lie and pull a number out of my rear end that we both know is BS?"
2. It's not your responsibility to fix managements' screw-ups. They didn't allocate the resources, or they over-promised? The only way to prevent that from happening again is to not let them make it your problem - because it isn't your problem. Make it clear that it wasn't the programmers who over-promised, but the marketroids, and respond positively with a "Yes we can do it - here's what we believe it's probably going to take in terms of people and time."
Failing that, book in sick and start interviewing for another job. As a coder, you can fix broken code, but not broken business processes. And if you're a manager, stop trying to manipulate people. There's a big difference between managing and manipulation.
OMG, somebody fire this jerk. In most cases adding macros MAY make the code more readable for you, but the next poor guy who comes along can no longer look at that section of code to see what's going on, but must now combine the code he's reading with a macro that he can only assume was implemented properly in the first place.
People will often hard-code a value, figuring that eventually, they'll "fix it". "Eventually" never happens, so you have your code littered with hard-coded magic constants.
Which is easier to figure out, ERR_INDEX_OUT_OF_BOUNDS or -4096? OP_UPDATE_CLIENT or 32.
Which is clearer:
unsigned long mask = 8196;
... or...
unsigned long mask = CUST_IS_ENABLED & CUST_HAS_BALANCE;
Now, let's see an example of what happens if we then use a macro...
#define DB_DEFAULT_NAME "whatever";
#define DB_DEFAULT_HOST "boxen_489"// NOTE: don't want to use localhost by default!!!
#define DB_DEFAULT_PORT 40000// NOTE: this is to connect to the second instance by default
#define DB_DEFAULT_USR "db_acct_496"
#define DB_DEFAULT_PW "hey_stupid!"
char* DB_name = DB_DEFAULT_NAME;
char* DB_host = DB_DEFAULT_HOST;
char* DB_usr = DB_DEFAULT_USR;
char* DB_pw = DB_DEFAULT_PW;
int DB_port = DB_DEFAULT_PORT;
#define DB_USE(mysql_resource) mysql_real_connect(mysql_resource, DB_host, DB_usr, DB_pw, DB_name, DB_port, null, 0);
This ensures that sane defaults are used (for that particular app) if nobody changes anything, but that it can be changed at runtime. Defaults are set in one place, code is simpler to maintain, and easier to read. Any time you can fix it so that you always have defaults that "just work", that they can be set in one place, and that you can make it simpler to read, you've increased maintainability and squelched a few potential bugs.
And then you have the original author of the body of code you just killed/refactored. He wont be so amused about you rewriting in one week what he spent four months writing. Expect to hear nitpicks and complaints from his side. You won't be able to ask him anything about the code anymore because "you destroyed it."
Getting over that one is easy - show them the bug, the solution, and offer to let THEM file the bug fix. You get them on your side, you get the code cleaned up, and you get increased communications. It's simple if you don't see this as an exercise in boosting your own ego at the expense of others, but as a task that is inherently interesting, like any puzzle.
Case in point: One day, I found, fixed, committed, and logged as fixed, 28 bugs. This overwhelmed testing, obviously, as well as the guy who was the maintainer of the code. So, next day, I sent him the diffs and let him edit and commit. Problem solved - except that he couldn't keep up with committing the diffs. So, in the end, we ended up that I'd send him the diffs, he'd look at them, and if he had no beef, I'd commit them and he'd pull the changes out. As for logging the fixes, who cares who got credit? (but since I had root access on the machine hosting svn, it was no big deal to get his password and log them as fixed by him so as to reduce conflict).
Also, there's no reason why you can't make the fix, and comment it out, with a "NOTE: Candidate fix for bug #nnnn. Send blame to me@youknowwhere.com". This way, anyone looking at the code sees (1) that there's already a potential fix, and (2) that there's a contact to discuss it with.
Also, refactoring should never be "huge" on production code. Incremental. As limited in scope as you can make it. But even with those restrictions, a 50% reduction in bloat over time is reasonable, because a lot of code is copy-and-paste, because people are in a hurry. If you explain to them that you KNOW that it's not their fault that they had to do a quick copy-n-paste, that it's f***ing marketing that always over-promises, and that you're doing it so that we can ultimately make our own lives easier, they'll get on board. If you act like a total ass and go "gee, that was stupid of you", of course you're going to get a big F.U. in response.
As for taking the blame, if you can't stand the heat, you really should get out of the kitchen. We don't have to produce perfect code when fixing it. Just better code than it was before. It's an iterative process, after all. If we fix 10 bugs and introduce 1 new one of equal or lesser severity, we're way ahead of the game. Saying "Oops - I had a brain fart when I wrote that" isn't that hard to do. It'll get people laughing with you, and not at you.
Just some thoughts. But yes, I really do enjoy fixing code. Even ghastly, undocumented code. Yes, it makes me want to scream sometimes, but when it starts coming together, it's NICE!
The more complicated the page layout, the quicker it is to just update the data via xhr than to do a complete page refresh. On the server side, it's less work (just the data, instead of the data + complete page), and the formatting of the data is simpler - for example, you can often just use a single long delimited string, and let the client parse it out; On the client side, parsing out data is fairly quick - and lets face it, your machine probably has more idle cpu cycles than the server, so it's quicker for you to do the extra parsing than it is to wait on the server doing it. Additionally, if you don't have to reflow the page (and you shouldn't have to in many cases), you get another big saving in time.
Of course, there are also bad implementations that make you want to pull your hair out, but for things like displaying and editing customer records, etc., it's much quicker.
Also, try using that to zoom on Slashdot in IE8. It ain't pretty.
[_] And slashdot is pretty when it's not zoomed?
[_] So don't use IE.
[_] I use curl, wget, and lynx, you ignorant clod!
[_] In Soviet Russia, slashdot zooms YOU!
You don't have to use the browser-based zoom if you're in X. Ctrl++ (outside the browser window) scales up the whole desktop. Your browser still thinks it's rendering 1:1, so everything is still "pixel-perfect" in terms of the browser's physical placement of elements. Give it a try. You can also set your virtual desktops (since you can have more than one, each with as many monitors as you can connect to your box) to be larger than your physical desktops, and scroll around.
And for those times you're really stuck, if someone else has a badass monitor on another machine, forward the apps' display there. (do that with Xeyes and tell people you're "keeping an eye on them while they work" - you'd be surprised at how many fall for it:-)
It's not for our benefit. The reason that spammers post to sites is to get higher in the search engine rankings. You should know that by now. Better to have their site associated with terms such as spam, counterfeit, fraud, scum, etc. and drag down their rank in searches that don't include those terms.
I haven't felt comfortable with ever using PHP's own cookie-less session handling, just because I cringe at any URL I see that contains "?PHPSESSID=
Tell me about it. It just looks fugly.
Well, you'll always have to pass the session id to the server on every xhr, but you don't have to receive it - you already have it:-) What you do is include a second variable, which you also pass to the server, and it passes you a new value back. This way, it makes it easy to be sure that you don't get into a weird state (such as when someone repeatedly hits the submit button, or back/forward/back/forward). Or you could concatenate/explode the two values in one variable. Of course, you still have to do sanity checks... I guess there's no free lunch:-)
I have code that I wrote independent of work that isn't covered by an nda that I'll probably clean up and share that does session management w/o cookies or gets - it can work with either ajax or a conventional POST (using POST makes it easy to work on a single section). It's one of those "one of these days" things. When I put it out there, I'll mention it in my journal so you can grab a copy.
It also includes code for a javascript widget framework that supports multiple languages, etc., and the layout is via css.
What I want to do first, though, is a bit of experimenting with xml. Normally, I *hate* xml, but I find that some browsers can do neat tricks with it...
You're there anyway - why not clean it up a bit. Every file you touch, clean it up (because people in a hurry always leave a mess). It'll help decipher what's going on, so you're less likely to fubar something.
Do that often enough, and the code becomes more workable, and you'll begin to see duplication that can be remedied with no impact, as well as find a few errors. Check the bug list - if you've found the source of a bug, tell the powers that be that, while doing the mods, you found the source to bug xyz. Then log the fix.
You don't tell them you're doing that... you just do it. It's quicker anyway. Start by cleaning up the formatting and moving stuff into headers, some righteous macros to make the code more readable, etc., as a first step in "getting familiar with the code. After all, you don't want to break something while fixing a problem. You'll probably notice some code that looks like it's either "copy-n-paste" or dead. Keep it in mind.
You'll find potential for simplifications as you go along, and you'll also probably find other bugs and stupidities, like parameters that are never used (that happens a lot as code gets modded). Code that doesn't smell right. Signed ints that are unsigned elsewhere. Potential buffer overruns. Unsanitized unput. In-line code that really should be in a separate function call both for clarity and for re-use. Look through the bug list - if the bug (or potential bug) you found is there, great - mark it as fixed. If not, log it, then mark it as fixed. Either way, your fixed bug count goes up - and if you can show that you've fixed bugs before they're found, that's just a bonus.
Now start a bit more higher-level fixing. Nothing too wild, but if you have to add a bit of functionality, use that as an excuse to simplify the code that it touches. You'll probably confirm some of the dead code from the first step. Remove it. You'll probably confirm cases of multiple instances of copy-and-paste - refactor them as well into something a bit more same. Now you've removed a few more bugs, shrunk the file size, and added some functionality.
Now that you've done that, review the code again, and look for more instances of copy-and-paste. Code that was written in a hurry will have LOTS of it, so you'll definitely be able to give it some more w8loss treatments. And since you didn't bitch and moan TOO much about making the mods, and they actually work, they'll probably be happy to let you graze on the bug-fix list. There's always bugs, nobody wants to touch them, and as you clean up the code, you'll see it start to shrink.
A 50% reduction on crappy spaghetti code is reasonable under those circumstances.
At that point, you own the code. You're in the loop for changes that might break it. When you say, "okay, but it's going to take x time" they're more likely to actually listen. Consider it office politics for nerds.
Everyone knows maintenance is difficult and boring, and therefore avoids doing it
Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.
It's all in the mindset. It's only boring if you limit yourself to the boring parts.
You replied to someone looking for a high pixel density monitor. You brag about throwing out a lower-density monitor, in your throwaway and OFF-TOPIC first paragraph.
You are a fucking moron.
I pointed out that I've thrown out a monitor that does the same res they're looking for; yes, it's larger, but that's in keeping with the article - older people need larger monitors for the same resolution. There are plenty of hi-res CRT monitors of various dimensions that either have to get re-purposed or tossed. That being said, my other advice still stands - just get a better LCD screen. Lower energy consumption, turns on quicker, better picture than some 10-year-old screen that's probably got a munged-up cloudy anti-glare coating.
Now, more on-topic - From the Fine Article:
is there a source for 24-27" monitors running at 1366x768
The original poster is looking for lower-pixels-per-square inch, not higher. My point, which still stands, is that there are plenty of boat-anchors just sitting around that are going to end up in the trash that can do what this guy wants - for free. A pair of FREE 21" 1600x1200 run at lower resolution (say, 1024x768) will more than do the job of the original poster, and he doesn't have to worry about people watching TV on them. As a matter of fact, I have 2 19" monitors that are just hanging around that would fit the bill just fine, and I'm sure I'm not the only one.
Or do you have something against recycling, unless it's your own AC shit?
The unfortunate thing about all of this is that it requires the developers to comply, I tend to think that the developers interested in complying with anything aren't really the source of the problem they're trying to fix.
I think the problem isn't with developers, but their bosses, who aren't interested in doing the right thing if it's going to take time and cost money (time == money). Making it a requirement will give developers a bit of leverage when the boss wants them to write stuff that's really intrusive, like reporting back timestamped keystroke mouse movement data. And no, this is not a hypothetical situation. I can talk about this because we never actually deployed this as a bot detector except in a limited internal test - the powers that be finally *got* my point that it was excessively invasive. We could actually follow testers from site to site by rewriting urls so everything after the initial contact was proxied. At that point, "all your cookies are belong to us."
This is probably how link affiliate hijacking is done. It's not that complicated, and both cookie and non-cookie forms of passing info around are vulnerable. What's worse is that all web sites are vulnerable to this form of attack, and even out-of-band validation (like asking them to confirm by tending a text message with a pre-defined code from their cell - they think they're directly connected to site x, not through a proxy) doesn't help.
Getting rid of dns and using an numeric address would kill it dead - no proxying 4 U!:-) A dotted-quad number is fairly easy to remember, but who is going to want to remember ff:04:2d:88:e9:00:21:45:80:c9:22:22:01:55:12:b8 when we go IPv6? Still, I can see it happening for some apps - get there via dns the first time, do a redirect to the absolute ip address, and bookmark the ip address but show the site name. Always handy to have a few ip addresses around to quickly figure out if the net is down, or just the dns server:-)
Actually, you're a bit off. Studies published in the dead-tree version of Scientific American a couple of decades ago showed that it was the change in refractive index, not the lens hardening. They showed that for the same amount of curvature, older lenses produced a different amount of light bending (refraction). Newer research here shows that the actual change in curvature wasn't what we originally believed, and that this new data explains the change in refraction as the eye ages. It is this change in refraction that makes people far-sighted, when the age-related lens thickening would have been expected to make people near-sighted with age.
Older people get bifocals because, with the change of curvature of the lens, they can no longer focus up close. Not because the lens has hardened, just because it's shape and refractive properties have changed so the same amount of muscle force results in less change in focus. Picture it as a camera that you've changed the lens on, so it can no longer focus from 2" to infinity, but is now limited to 3' to infinity, if that helps.
So what will happen as you age is that your eye will lose the ability to focus up close because its refractive properties have changed, and you'll be less myopic. It's a fair trade-off.
Congratulations. In your attempt to brag that you had an even larger monitor *with the same resolution* and only cared about handing it off, you completely failed to understand the concept of density.
How very nice of you to not understand the original posters' problem. I understand the concept of density - but older people suffering from loss of visual acuity need more ABSOLUTE SIZE, not density. A 21" with the same 1600x1200 will be a lot more useful to them than a 17" with the same resolution.
How very Alanis of you, then, to be so dense. Doncha think? (Seriously, do you not? I recommend trying it.)
You might take your own advice, and actually RTFS...
Seriously, there is no excuse for people in a business environment to still be using crappy monitors - or even single screens. Spend a grand on a couple of decent monitors and a dual-head video card - amortized over the next 5 years, that's less than 10 cents an hour - and your people will more than pay back the extra cost in increased productivity and FEWER MISTAKES.
Errors cost money. Having to squint at stuff on-screen, or having to continually flip through a stack of windows, is $MONEY. The investment will pay for itself within months (or even weeks, if it prevents a few errors or lets people find them quicker).
When a crappy 14" 640x480 VGA monitor cost $600, and a 15" SVGA was in the 4 figures, being cheap on displays was understandable. It's not now, not when businesses should be seeking every method to increase productivity and lower error rates so they can keep clients happy and retain customers (and thus retain their employees).
When a company has a RIF (reduction in force), they should at the very least reapportion material such as LCDs so that more people can double their video real estate. It's not just a morale booster, it more than pays for itself. And while they're at it, cannibalize the ram to bump up those marginal boxes that the underlings, who do the work, are stuck waiting on while the boss has the very latest to watch an f***ing useless podcast on. It's really a shame to walk into a company and see the boss doing that on a half-decent 22" LCD while the secretary in front is struggling to transcribe figures into a spreadsheet on a fuzzy 14" CRT. So yes, I laid the 21" on them. She needed something better, and it was just taking up space here.
I understand that peoples priorities are different, and not everyone understands the cost/benefit ratio of having decent displays. "Oh, it's just a monitor."
Did they tell you that your near vision was definitely going to be shot? (There's no "possibly" about it short of changing the laws or refraction of light). If not, sue the SOBs.
After having LASIK laser eye surgery, most patients no longer need corrective eyewear
... is misleading at best, and at worst a lie. Most patients will eventually need glasses or contacts as their eyes age, though if you were originally near-sighted and DON'T get lasik, you could end up not needing glasses as your eyes change.
As a person that is nearsighted, I have to say, it is not as much of a problem as far sighted people have, but it is still a problem. This is particularly true when switching focus distance like looking back and forth between a computer screen and text on paper. In the last year I have found myself taking off my glasses to read fine print on labels, etc. more and more, its just a matter of my eyes don't focus that close anymore.
The fine print is a killer, but it always has been, even for people with 20/20 vision. It's made that way on purpose. "THE BIG PRINT GIVETHand the fine print taketh away" sort of thing. Have you tried taking your glasses off when using the 'puter? I did that decades ago, and my eyes actually adapted okay. Still near-sighed, but for computer work it was fine after a few days of fuzziness, and as the decades went on, things got better - except for the aforementioned fine print. I still need glasses to see "normally", but for computer work - just a good pair of screens and decent lighting, and it's been that way since forever (I think its because display technology has pretty much kept pace with changes in my eyesight:-)
What you'll probably notice if you dump the glasses for computer work is that your vision is sharpest not at the fovea, but slightly away from it; learning to quickly scan large blocks of text (aka speed-reading) will help you profit from that.
If the user isn't running javascript, you can't use an xmlhttprequest, same as if they aren't using cookies, you can't use a cookie to store state.
1. My sites are not broken, if the browser saves a cookie without asking consent it's not because I told the browser to save a cookie without asking consent, I just told it to save a cookie. If the browser the user happens to be using does not comply with the RFC that's not the fault of my application.
According to RFC2965, which YOU pointed out, your site is broken. It says "Both the user agent and the origin server must assist informed consent. I've reproduced the section below.
What I (and the EU) don't like about cookies is that sites tend to drop a LOT of them, they do it without my permission, and they use these for tracking purposes between sites both by aggregating the data and by the "same-server" or "same-domain" permissions policies, which end users aren't aware of, and wouldn't understand if they were. This is totally against end-user expectations of privacy, and what the EU proposes is that no site use a cookie without informing people that they do so, and what they do with the data. To me, this is reasonable behaviour, and it's the expected behaviour in RFC2965. The objection isn't to cookies per se, but to the way that they have become pervasive and intrusive.
It's true that using a post is more secure than a get, but that wasn't the original question. The original issue was whether it was even possible to do away with cookies, and it is, in all cases.
Moreover, for someone so concerned about what the RFCs say, I'm a little surprised that you're so willing to ignore RFCs 2109 and 2965. Turns out we've already got a state management mechanism for HTTP.
RFC 2109 has been superceded. Here's the exact wording from FRC 2965. I'm not ignoring it - it says exactly what I've been arguing for - that as a site developer you MUST get informed consent from the user before you drop cookies on them.
6. PRIVACY
Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.
(emphasis added)
Look - it's just proper etiquette. Advertisers shouldn't be able to track you from site to site with cookies, which is what they do now. It's an invasion of privacy, and it's just wrong. The EU is on the right on this one, same as Canada was right to threaten to take Facebook to court if Facebook didn't fix it's problems with unauthorized sharing of user data with 3rd party developers (which enabled a lot of phishing schemes, btw).
The default should be to preserve privacy. And, in the event that the user doesn't accept cookies, we can do a different session management technique that doesn't require cookies, and that would require us, as site developers, to directly communicate with advertisers wrt the customers - and only after getting customer permission for sharing that information. Informed consent. Since we wouldn't be following customers when they go to other sites, and since there is no session id stored on the client computer, customer privacy is preserved wrt 3rd parties. This is a "Good Thing", no? Sure, advertisers will hate it. It's not up to the end user to come up with a business plan for them, and it's not up to us to, either, unless that's what they're paying us for. If the want to do that, let them pay to "pick our
Slashdot Mirror
[_] Grow the f*** up!
[_] Kill yourself now and avoid the rush (and collect your darwin, because morons like you shouldn't be reproducing) !
[_] Send me your money and I'll tell you how to get into the secret government refuge.
[_] It's the rapture, silly! Welcome our new overlords
[_] This is our tax dollars at work?
[_] Cheese!
The same people who complain that their mouse is defective because it can't go any further - and they can't figure out to pick the thing up and move it back? Yeah, been there, done that.
Move the monitor when they're not there, an inch or so a day. They'll never notice.
THAT is a key point. There should always be an @blame line or equivalent. I put my external email there, so that even 10 years down the road, if a problem comes up, they know who to blame, or who to ask.
And congrats on your code.
Everyone who's worked with me on code has, when the time comes to part ways, thanked me. They've seen me stand up to the boss for them, they've seen me take the heat for their screw-ups rather than point fingers, etc. Heck, I've even written their reports for them, their on-line dating ads, negotiated claim settlements with their car insurance, done their backups when they haven't, recovered them from those backups when the inevitable "Oh shit ... ummmm... do you have a copy of all my files for the last year? I think I deleted them", taught them stuff they should have already known but didn't, helped the testers find the bugs, made the coffee, bought snacks for everyone, tried to explain the boss's point of view to everyone so that they could see there's two sides to it, taken the boss aside and told him when he's pushing against a piece of string or being really counter-productive, told him to F off when he's gone too far overboard, etc.
It's the right way to work, and I've been doing this for too long to bother with the BS of negotiating how long something is going to take, or how many corners can be safely cut. In case of urgency, I'll cut as much as I can, but there's a limit before it gets counter-productive, and having to do it logged into a live server, editing the code, recompiling, linking, etc., sure, I'll do it, but I'm going to be extra cautious, and it's going to be replaced asap with code that's properly fixed before I do anything else, so kindly don't bug me for the rest of the afternoon :-)
Then you have a process and management problem, not a coding problem.
One person should have the authority to approve or disapprove.
It's like when you make a complaint, and they say "I'm sorry, I can't do that." The proper response is "Then why am I wasting both of our time talking to you? Please pass me to someone who can."
Strictly a management problem.
For most of your arguments, please read my responses elsewhere. There's no reason why you can't clean up small areas of code, and the time savings will start to add up.
As for:
This is a management problem. If people are doing 60 hours a week on code, they're working well below peak efficiency, and probably introducing more bugs than they're fixing. It also indicates that management either didn't allocate resources properly, over-promised, or otherwise screwed up in their planning. In other words, they didn't "manage" properly.
It's also a programmer problem, because programmers often don't have the guts to say "I'm past my peak. I'm going home. See you guys tomorrow." and confront management over the screw-up over resource allocation and planning.
How many times has coding become a negotiating session, where each side is trying to bargain as to how long it'll take? That's just stupid. If you say "One to two days" they hear "one day", and then cut it in half. So you add an extra day, they still cut it to one day, because they expected you to add the padding ... and $DIETY help you if you run into something unexpected - which you will, because it IS buggy code if you have to fix it, so there's going to be something unexpected by definition.
1. Refuse to play the "negotiate how long" game. Be honest. And be up-front that you're being honest. "Honestly, it'll take what it takes. Or do you want me to lie and pull a number out of my rear end that we both know is BS?"
2. It's not your responsibility to fix managements' screw-ups. They didn't allocate the resources, or they over-promised? The only way to prevent that from happening again is to not let them make it your problem - because it isn't your problem. Make it clear that it wasn't the programmers who over-promised, but the marketroids, and respond positively with a "Yes we can do it - here's what we believe it's probably going to take in terms of people and time."
Failing that, book in sick and start interviewing for another job. As a coder, you can fix broken code, but not broken business processes. And if you're a manager, stop trying to manipulate people. There's a big difference between managing and manipulation.
People will often hard-code a value, figuring that eventually, they'll "fix it". "Eventually" never happens, so you have your code littered with hard-coded magic constants.
Which is easier to figure out, ERR_INDEX_OUT_OF_BOUNDS or -4096? OP_UPDATE_CLIENT or 32.
Which is clearer:
unsigned long mask = 8196;
Now, let's see an example of what happens if we then use a macro ...
#define DB_DEFAULT_NAME "whatever"; // NOTE: don't want to use localhost by default!!!
// NOTE: this is to connect to the second instance by default
#define DB_DEFAULT_HOST "boxen_489"
#define DB_DEFAULT_PORT 40000
#define DB_DEFAULT_USR "db_acct_496"
#define DB_DEFAULT_PW "hey_stupid!"
char* DB_name = DB_DEFAULT_NAME;
char* DB_host = DB_DEFAULT_HOST;
char* DB_usr = DB_DEFAULT_USR;
char* DB_pw = DB_DEFAULT_PW;
int DB_port = DB_DEFAULT_PORT;
#define DB_USE(mysql_resource) mysql_real_connect(mysql_resource, DB_host, DB_usr, DB_pw, DB_name, DB_port, null, 0);
This ensures that sane defaults are used (for that particular app) if nobody changes anything, but that it can be changed at runtime. Defaults are set in one place, code is simpler to maintain, and easier to read. Any time you can fix it so that you always have defaults that "just work", that they can be set in one place, and that you can make it simpler to read, you've increased maintainability and squelched a few potential bugs.
Getting over that one is easy - show them the bug, the solution, and offer to let THEM file the bug fix. You get them on your side, you get the code cleaned up, and you get increased communications. It's simple if you don't see this as an exercise in boosting your own ego at the expense of others, but as a task that is inherently interesting, like any puzzle.
Case in point: One day, I found, fixed, committed, and logged as fixed, 28 bugs. This overwhelmed testing, obviously, as well as the guy who was the maintainer of the code. So, next day, I sent him the diffs and let him edit and commit. Problem solved - except that he couldn't keep up with committing the diffs. So, in the end, we ended up that I'd send him the diffs, he'd look at them, and if he had no beef, I'd commit them and he'd pull the changes out. As for logging the fixes, who cares who got credit? (but since I had root access on the machine hosting svn, it was no big deal to get his password and log them as fixed by him so as to reduce conflict).
Also, there's no reason why you can't make the fix, and comment it out, with a "NOTE: Candidate fix for bug #nnnn. Send blame to me@youknowwhere.com". This way, anyone looking at the code sees (1) that there's already a potential fix, and (2) that there's a contact to discuss it with.
Also, refactoring should never be "huge" on production code. Incremental. As limited in scope as you can make it. But even with those restrictions, a 50% reduction in bloat over time is reasonable, because a lot of code is copy-and-paste, because people are in a hurry. If you explain to them that you KNOW that it's not their fault that they had to do a quick copy-n-paste, that it's f***ing marketing that always over-promises, and that you're doing it so that we can ultimately make our own lives easier, they'll get on board. If you act like a total ass and go "gee, that was stupid of you", of course you're going to get a big F.U. in response.
As for taking the blame, if you can't stand the heat, you really should get out of the kitchen. We don't have to produce perfect code when fixing it. Just better code than it was before. It's an iterative process, after all. If we fix 10 bugs and introduce 1 new one of equal or lesser severity, we're way ahead of the game. Saying "Oops - I had a brain fart when I wrote that" isn't that hard to do. It'll get people laughing with you, and not at you.
Just some thoughts. But yes, I really do enjoy fixing code. Even ghastly, undocumented code. Yes, it makes me want to scream sometimes, but when it starts coming together, it's NICE!
The more complicated the page layout, the quicker it is to just update the data via xhr than to do a complete page refresh. On the server side, it's less work (just the data, instead of the data + complete page), and the formatting of the data is simpler - for example, you can often just use a single long delimited string, and let the client parse it out; On the client side, parsing out data is fairly quick - and lets face it, your machine probably has more idle cpu cycles than the server, so it's quicker for you to do the extra parsing than it is to wait on the server doing it. Additionally, if you don't have to reflow the page (and you shouldn't have to in many cases), you get another big saving in time.
Of course, there are also bad implementations that make you want to pull your hair out, but for things like displaying and editing customer records, etc., it's much quicker.
[_] And slashdot is pretty when it's not zoomed?
[_] So don't use IE.
[_] I use curl, wget, and lynx, you ignorant clod!
[_] In Soviet Russia, slashdot zooms YOU!
You don't have to use the browser-based zoom if you're in X. Ctrl++ (outside the browser window) scales up the whole desktop. Your browser still thinks it's rendering 1:1, so everything is still "pixel-perfect" in terms of the browser's physical placement of elements. Give it a try. You can also set your virtual desktops (since you can have more than one, each with as many monitors as you can connect to your box) to be larger than your physical desktops, and scroll around.
And for those times you're really stuck, if someone else has a badass monitor on another machine, forward the apps' display there. (do that with Xeyes and tell people you're "keeping an eye on them while they work" - you'd be surprised at how many fall for it :-)
It's not for our benefit. The reason that spammers post to sites is to get higher in the search engine rankings. You should know that by now. Better to have their site associated with terms such as spam, counterfeit, fraud, scum, etc. and drag down their rank in searches that don't include those terms.
Tell me about it. It just looks fugly.
Well, you'll always have to pass the session id to the server on every xhr, but you don't have to receive it - you already have it :-) What you do is include a second variable, which you also pass to the server, and it passes you a new value back. This way, it makes it easy to be sure that you don't get into a weird state (such as when someone repeatedly hits the submit button, or back/forward/back/forward). Or you could concatenate/explode the two values in one variable. Of course, you still have to do sanity checks ... I guess there's no free lunch :-)
I have code that I wrote independent of work that isn't covered by an nda that I'll probably clean up and share that does session management w/o cookies or gets - it can work with either ajax or a conventional POST (using POST makes it easy to work on a single section). It's one of those "one of these days" things. When I put it out there, I'll mention it in my journal so you can grab a copy.
It also includes code for a javascript widget framework that supports multiple languages, etc., and the layout is via css.
What I want to do first, though, is a bit of experimenting with xml. Normally, I *hate* xml, but I find that some browsers can do neat tricks with it ...
In other news, researchers finally announced that H1N1 isn't the boogeyman of flus - it's either the same, or less, severe compared to the regular flu season. Now people won't be so worried if they don't get a flu shot. Tomorrow!
You're there anyway - why not clean it up a bit. Every file you touch, clean it up (because people in a hurry always leave a mess). It'll help decipher what's going on, so you're less likely to fubar something.
Do that often enough, and the code becomes more workable, and you'll begin to see duplication that can be remedied with no impact, as well as find a few errors. Check the bug list - if you've found the source of a bug, tell the powers that be that, while doing the mods, you found the source to bug xyz. Then log the fix.
You don't tell them you're doing that ... you just do it. It's quicker anyway. Start by cleaning up the formatting and moving stuff into headers, some righteous macros to make the code more readable, etc., as a first step in "getting familiar with the code. After all, you don't want to break something while fixing a problem. You'll probably notice some code that looks like it's either "copy-n-paste" or dead. Keep it in mind.
You'll find potential for simplifications as you go along, and you'll also probably find other bugs and stupidities, like parameters that are never used (that happens a lot as code gets modded). Code that doesn't smell right. Signed ints that are unsigned elsewhere. Potential buffer overruns. Unsanitized unput. In-line code that really should be in a separate function call both for clarity and for re-use. Look through the bug list - if the bug (or potential bug) you found is there, great - mark it as fixed. If not, log it, then mark it as fixed. Either way, your fixed bug count goes up - and if you can show that you've fixed bugs before they're found, that's just a bonus.
Now start a bit more higher-level fixing. Nothing too wild, but if you have to add a bit of functionality, use that as an excuse to simplify the code that it touches. You'll probably confirm some of the dead code from the first step. Remove it. You'll probably confirm cases of multiple instances of copy-and-paste - refactor them as well into something a bit more same. Now you've removed a few more bugs, shrunk the file size, and added some functionality.
Now that you've done that, review the code again, and look for more instances of copy-and-paste. Code that was written in a hurry will have LOTS of it, so you'll definitely be able to give it some more w8loss treatments. And since you didn't bitch and moan TOO much about making the mods, and they actually work, they'll probably be happy to let you graze on the bug-fix list. There's always bugs, nobody wants to touch them, and as you clean up the code, you'll see it start to shrink.
A 50% reduction on crappy spaghetti code is reasonable under those circumstances.
At that point, you own the code. You're in the loop for changes that might break it. When you say, "okay, but it's going to take x time" they're more likely to actually listen. Consider it office politics for nerds.
Registrar: XIN NET TECHNOLOGY CORPORATION
Whois Server: whois.paycenter.com.cn
Referral URL: http://www.xinnet.com/
Name Server: NS.XINNET.CN
Name Server: NS.XINNETDNS.COM
Status: ok
Updated Date: 01-nov-2009
Creation Date: 01-nov-2009
Expiration Date: 01-nov-2010
Just FOAD, mkay?
Domain Name: COOLFORSALE.COM
Registrar: XIN NET TECHNOLOGY CORPORATION
Whois Server: whois.paycenter.com.cn
Referral URL: http://www.xinnet.com/
Name Server: NS.XINNET.CN
Name Server: NS.XINNETDNS.COM
Status: ok
Updated Date: 01-nov-2009
Creation Date: 01-nov-2009
Expiration Date: 01-nov-2010
Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.
It's all in the mindset. It's only boring if you limit yourself to the boring parts.
I pointed out that I've thrown out a monitor that does the same res they're looking for; yes, it's larger, but that's in keeping with the article - older people need larger monitors for the same resolution. There are plenty of hi-res CRT monitors of various dimensions that either have to get re-purposed or tossed. That being said, my other advice still stands - just get a better LCD screen. Lower energy consumption, turns on quicker, better picture than some 10-year-old screen that's probably got a munged-up cloudy anti-glare coating. Now, more on-topic - From the Fine Article:
The original poster is looking for lower-pixels-per-square inch, not higher. My point, which still stands, is that there are plenty of boat-anchors just sitting around that are going to end up in the trash that can do what this guy wants - for free. A pair of FREE 21" 1600x1200 run at lower resolution (say, 1024x768) will more than do the job of the original poster, and he doesn't have to worry about people watching TV on them. As a matter of fact, I have 2 19" monitors that are just hanging around that would fit the bill just fine, and I'm sure I'm not the only one.
Or do you have something against recycling, unless it's your own AC shit?
I think the problem isn't with developers, but their bosses, who aren't interested in doing the right thing if it's going to take time and cost money (time == money). Making it a requirement will give developers a bit of leverage when the boss wants them to write stuff that's really intrusive, like reporting back timestamped keystroke mouse movement data. And no, this is not a hypothetical situation. I can talk about this because we never actually deployed this as a bot detector except in a limited internal test - the powers that be finally *got* my point that it was excessively invasive. We could actually follow testers from site to site by rewriting urls so everything after the initial contact was proxied. At that point, "all your cookies are belong to us."
This is probably how link affiliate hijacking is done. It's not that complicated, and both cookie and non-cookie forms of passing info around are vulnerable. What's worse is that all web sites are vulnerable to this form of attack, and even out-of-band validation (like asking them to confirm by tending a text message with a pre-defined code from their cell - they think they're directly connected to site x, not through a proxy) doesn't help.
Getting rid of dns and using an numeric address would kill it dead - no proxying 4 U! :-) A dotted-quad number is fairly easy to remember, but who is going to want to remember ff:04:2d:88:e9:00:21:45:80:c9:22:22:01:55:12:b8 when we go IPv6? Still, I can see it happening for some apps - get there via dns the first time, do a redirect to the absolute ip address, and bookmark the ip address but show the site name. Always handy to have a few ip addresses around to quickly figure out if the net is down, or just the dns server :-)
Actually, you're a bit off. Studies published in the dead-tree version of Scientific American a couple of decades ago showed that it was the change in refractive index, not the lens hardening. They showed that for the same amount of curvature, older lenses produced a different amount of light bending (refraction). Newer research here shows that the actual change in curvature wasn't what we originally believed, and that this new data explains the change in refraction as the eye ages. It is this change in refraction that makes people far-sighted, when the age-related lens thickening would have been expected to make people near-sighted with age.
Older people get bifocals because, with the change of curvature of the lens, they can no longer focus up close. Not because the lens has hardened, just because it's shape and refractive properties have changed so the same amount of muscle force results in less change in focus. Picture it as a camera that you've changed the lens on, so it can no longer focus from 2" to infinity, but is now limited to 3' to infinity, if that helps.
So what will happen as you age is that your eye will lose the ability to focus up close because its refractive properties have changed, and you'll be less myopic. It's a fair trade-off.
How very nice of you to not understand the original posters' problem. I understand the concept of density - but older people suffering from loss of visual acuity need more ABSOLUTE SIZE, not density. A 21" with the same 1600x1200 will be a lot more useful to them than a 17" with the same resolution.
You might take your own advice, and actually RTFS ...
Seriously, there is no excuse for people in a business environment to still be using crappy monitors - or even single screens. Spend a grand on a couple of decent monitors and a dual-head video card - amortized over the next 5 years, that's less than 10 cents an hour - and your people will more than pay back the extra cost in increased productivity and FEWER MISTAKES.
Errors cost money. Having to squint at stuff on-screen, or having to continually flip through a stack of windows, is $MONEY. The investment will pay for itself within months (or even weeks, if it prevents a few errors or lets people find them quicker).
When a crappy 14" 640x480 VGA monitor cost $600, and a 15" SVGA was in the 4 figures, being cheap on displays was understandable. It's not now, not when businesses should be seeking every method to increase productivity and lower error rates so they can keep clients happy and retain customers (and thus retain their employees).
When a company has a RIF (reduction in force), they should at the very least reapportion material such as LCDs so that more people can double their video real estate. It's not just a morale booster, it more than pays for itself. And while they're at it, cannibalize the ram to bump up those marginal boxes that the underlings, who do the work, are stuck waiting on while the boss has the very latest to watch an f***ing useless podcast on. It's really a shame to walk into a company and see the boss doing that on a half-decent 22" LCD while the secretary in front is struggling to transcribe figures into a spreadsheet on a fuzzy 14" CRT. So yes, I laid the 21" on them. She needed something better, and it was just taking up space here.
I understand that peoples priorities are different, and not everyone understands the cost/benefit ratio of having decent displays. "Oh, it's just a monitor."
Did they tell you that your near vision was definitely going to be shot? (There's no "possibly" about it short of changing the laws or refraction of light). If not, sue the SOBs.
And this claim ...
9% report no change or worsening of vision afterwards Not worth it. Glasses are safer, and they make you look smart - and this study proves it's more likelyt to be true if you're nearsighted.
The fine print is a killer, but it always has been, even for people with 20/20 vision. It's made that way on purpose. "THE BIG PRINT GIVETHand the fine print taketh away" sort of thing. Have you tried taking your glasses off when using the 'puter? I did that decades ago, and my eyes actually adapted okay. Still near-sighed, but for computer work it was fine after a few days of fuzziness, and as the decades went on, things got better - except for the aforementioned fine print. I still need glasses to see "normally", but for computer work - just a good pair of screens and decent lighting, and it's been that way since forever (I think its because display technology has pretty much kept pace with changes in my eyesight :-)
What you'll probably notice if you dump the glasses for computer work is that your vision is sharpest not at the fovea, but slightly away from it; learning to quickly scan large blocks of text (aka speed-reading) will help you profit from that.
I don't have access to the internal code for competitors' sites, obviously :-)
There's actually a patent - # 6539494 - for using a second session id wrt failover and backup.
If the user isn't running javascript, you can't use an xmlhttprequest, same as if they aren't using cookies, you can't use a cookie to store state.
According to RFC2965, which YOU pointed out, your site is broken. It says "Both the user agent and the origin server must assist informed consent. I've reproduced the section below.
What I (and the EU) don't like about cookies is that sites tend to drop a LOT of them, they do it without my permission, and they use these for tracking purposes between sites both by aggregating the data and by the "same-server" or "same-domain" permissions policies, which end users aren't aware of, and wouldn't understand if they were. This is totally against end-user expectations of privacy, and what the EU proposes is that no site use a cookie without informing people that they do so, and what they do with the data. To me, this is reasonable behaviour, and it's the expected behaviour in RFC2965. The objection isn't to cookies per se, but to the way that they have become pervasive and intrusive.
It's true that using a post is more secure than a get, but that wasn't the original question. The original issue was whether it was even possible to do away with cookies, and it is, in all cases.
RFC 2109 has been superceded. Here's the exact wording from FRC 2965. I'm not ignoring it - it says exactly what I've been arguing for - that as a site developer you MUST get informed consent from the user before you drop cookies on them.
(emphasis added)
Look - it's just proper etiquette. Advertisers shouldn't be able to track you from site to site with cookies, which is what they do now. It's an invasion of privacy, and it's just wrong. The EU is on the right on this one, same as Canada was right to threaten to take Facebook to court if Facebook didn't fix it's problems with unauthorized sharing of user data with 3rd party developers (which enabled a lot of phishing schemes, btw).
The default should be to preserve privacy. And, in the event that the user doesn't accept cookies, we can do a different session management technique that doesn't require cookies, and that would require us, as site developers, to directly communicate with advertisers wrt the customers - and only after getting customer permission for sharing that information. Informed consent. Since we wouldn't be following customers when they go to other sites, and since there is no session id stored on the client computer, customer privacy is preserved wrt 3rd parties. This is a "Good Thing", no? Sure, advertisers will hate it. It's not up to the end user to come up with a business plan for them, and it's not up to us to, either, unless that's what they're paying us for. If the want to do that, let them pay to "pick our