Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

503 Fix (UPDATED)

FortKnox (169099) writes | about 10 years ago

User Journal 17

Annoying as hell, but if you delete your cookies for slashdot and relogin, you usually can avoid 503's as long as your session stays live (some bored people figured it out and posted it to slashdot's bug tracker). But if the system has to log you in based on your cookie, it'll die. Hope that helps your browsing experience, and makes you laugh at someone who has had a major website up for countless years still doesn't know how to handle cookies.Annoying as hell, but if you delete your cookies for slashdot and relogin, you usually can avoid 503's as long as your session stays live (some bored people figured it out and posted it to slashdot's bug tracker). But if the system has to log you in based on your cookie, it'll die. Hope that helps your browsing experience, and makes you laugh at someone who has had a major website up for countless years still doesn't know how to handle cookies.

Update: Got the word from pudge himself. Cookies aren't the problem (actually, I believe the words were, Cookies aren't the problem... ignore fortknox and listen to sllort (I can't believe I just said that :-). Sllort had just mentioned after me that cookies weren't the problem). Guess my credibility has gone downhill since I've been put in "The List" in Trollback... ;-)

cancel ×

17 comments

Sorry! There are no comments related to the filter you selected.

D (1)

Oculus Habent (562837) | about 10 years ago | (#9868801)

I got a 503 on the logout... then a few 503 on login.

It logged me in, even though the login page hasn't actually loaded. I'll stick with https, which gives me the lowest 503/page ratio.

*Clears throat*
GAH~!

S also keeps me from browsing at the speed of bleeding out through a hangnail.

Re: D (1)

Com2Kid (142006) | about 10 years ago | (#9870719)

when was doing HTTPS (seems /. is fixed, for now), I would get the front page to load fine (if not somewhat slow) but as soon as I clicked any link, it was not https and I got a 503.

Joy...

I'm just amused (1)

Safety Cap (253500) | about 10 years ago | (#9868908)

that some folks who've supposedly been coding for a number of years still employ all 36 worse practices [stevemcconnell.com] and refuse to admit it to themselves or grow beyond their current (in)competence level.

Re:I'm just amused (1)

gmhowell (26755) | about 10 years ago | (#9870010)

Personal favorites in this situation:

#7: Friction between developers and customers. Friction between developers and customers can arise in several ways. Customers may feel that developers are not cooperative when they refuse to sign up for the development schedule that the customers want, or when they fail to deliver on their promises. Developers may feel that customers unreasonably insisting on unrealistic schedules or requirements changes after requirements have been baselined. There might simply be personality conflicts between the two groups.


The primary effect of this friction is poor communication, and the secondary effects of poor communication include poorly understood requirements, poor user-interface design, and, in the worst case, customers' refusing to accept the completed product. On average, friction between customers and software developers is so severe that both parties consider canceling the project (Jones 1994). Such friction is time-consuming to overcome, and it distracts both customers and developers from the real work of the project.

#11: Lack of user input. The Standish Group survey found that the number one reason that IS projects succeed is because of user involvement (Standish Group 1994).

#15: Insufficient risk management. Some mistakes have been made often enough to be considered classics. Others are unique to specific projects. As with the classic mistakes, if you don't actively manage risks, only one thing has to go wrong to change your project from a rapid-development project to a slow-development one. Failure to manage risks is one of the most common classic mistakes.

#22: Shortchanged quality assurance. Projects that are in a hurry often cut corners by eliminating design and code reviews, eliminating test planning, and performing only perfunctory testing. In the case study, design reviews and code reviews were given short shrift in order to achieve a perceived schedule advantage. As it turned out, when the project reached its feature-complete milestone it was still too buggy to release for five more months. This result is typical. Short-cutting a day of QA activity early in the project is likely to cost you 3 to 10 days of activity downstream (Jones 1994). This inefficiency undermines development speed.

#27: Code-like-hell programming. Some organizations think that fast, loose, all-as-you-go coding is a route to rapid development. If the developers are sufficiently motivated, they reason, they can overcome any obstacles. For reasons that will become clear throughout this book, this is far from the truth. The entrepreneurial model is often a cover for the old code-and-fix paradigm combined with an ambitious schedule, and that combination almost never works. It's an example of two wrongs not making a right.


They're all freakin' beautiful, and incredibly apropos. I really like the customer focus ones. Why? Perhaps because my intro to IT prof in business school had been a high mucky-muck at IBM South America, and customer focus was one of his big things.

Sorry for making your journal so long with the quoting Josh. Just thought it was some good stuff for those too busy refreshing the 503's to get offsite. BTW, isn't it likely that the 503's make things worse by increasing the attempted hits? IE, instead of one click, one page, it takes 10 load attempts to get one page.

Ooh, better copy this in case it gets messed up on submit.

Re:I'm just amused (1)

FortKnox (169099) | about 10 years ago | (#9870152)

Don't apologize. Happy someone pointed out the ones that really stand out and describe slashdot to a t.

If development for the new site falls under any of the rules, someone email me and smack me around.

This is easy (1)

Safety Cap (253500) | about 10 years ago | (#9870391)

If we're going to run it like a real project, then we'll need risk regular management reviews. I usually include those worse practices automatically along with risks identified from the WBS.

If risks are reviewed once every other week (I'm assuming the dev pace on the new system will be a bit slower than a paid-for project, because we all gotta eat), that should be sufficient to prevent risk realization.

Re:This is easy (1)

FortKnox (169099) | about 10 years ago | (#9870485)

I plan on publishing each step publically, and letting everyone eye it. That way we can catch things early that we may miss (especially with use cases and requirements).

Something else that's funny... (1)

dmorin (25609) | about 10 years ago | (#9868928)

I'm sure none of the folks that run Slashdot care a lick about people that complain and keep coming back. It's like when you hate the service at a store and say "I'm never shopping here again!" and yet you still do. The "unsatisfied customer" rule only works when the customer's dissatisfaction results in lower revenue. (I know, I know, brand recognition, blah blah...)

But I'll bet the lost ad revenue is killing them. Can't see the page, can't see the ads. That hits them where it hurts.

Re:Something else that's funny... (1)

elmegil (12001) | about 10 years ago | (#9868981)

With FK's help, we'll be fixing the first part soon enough.

are we there yet? (1)

Em Emalb (452530) | about 10 years ago | (#9869455)

Are we there yet?

Re:are we there yet? (1)

daniil (775990) | about 10 years ago | (#9869616)

Yes.

Re:are we there yet? (1)

FortKnox (169099) | about 10 years ago | (#9869618)

workin on it... like I said, may take a couple months until we get something worthy of playing with and keep you off of here. Patience, please.

Bloody hell (0)

Anonymous Coward | about 10 years ago | (#9869629)

This sucks.

Apparently the only thing more time-consuming than reading /. in the morning is being unable to read /. in the morning...

Sigh,

Pixie

The real 503 Fix (1)

KMAPSRULE (639889) | about 10 years ago | (#9869673)

I had to fire up RadHat 7.2 today to debug some stuff for a delivered product that is unfortunately staying at RH7.2 for a LOOONG time.
Anyhow the real fix is to view slashdot in Communicator 4.78...I have not had a single 503 error since loading it up in Netscape 4.78.

Re:The real 503 Fix (1)

KMAPSRULE (639889) | about 10 years ago | (#9869888)

there goes that theory...just took a longer time to happen

I'll bet most of you (1)

ellem (147712) | about 10 years ago | (#9870369)

would prefer a 503 to reading this post.

tap
tap
tap

has it been 20 seconds yet?

Didn't see this fix (1)

Quantum Jim (610382) | about 10 years ago | (#9871097)

I've been pinging /. and using its IP address to navigate to slashdot when the domain name doesn't work (see journal). Strangely, cookies don't reconize the site in that case. I wonder if that's why my workaround worked.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>