|
... is totally hilarious!! 
Whether I think I can, or think I can't, I am always bloody right!
|
|
|
|
|
He always was[^]
Especially the Jasper Carrott version[^] (Possibly NSFW, but probably is if you have headphones on)
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
"Well I like it.", said Florence.
|
|
|
|
|
"That's obvious!" said everybody, cockily.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
It is indeed the best so far....
I liked the Klose somersault one also.
Don't mean to advertise but you can try my app to view them all 
|
|
|
|
|
|
|
I must be missing something, I just see some football related animated gif?
Iain.
Edit: I guess you mean this? http://www.google.com/doodles/world-cup-2014-27[^]
"Today" stale very quickly...
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
|
Recently I have to work with AGV controller to integrate it with .NET application via TCP/IP Socket. Factory is using it to control robots on the factory floor. The only issue is factory is working at 100% capacity (by the way it produces water heaters ) and there is only one controller available to use when one of the production line is not using it. Despite the fact that everything worked OK when I have tested it and during UAT. There are strange issues happening and only way to test those was to put my untested code in production environment. Finally I was able to figure out that Controller is giving up connection once in a while failing to recognize message from .NET or other way around. I still have no idea why it is doing it but at least I was able to provide solution to reconnect and resend. Deploying untested code in the production was scary.
What would you do when there is no way to replicate situations happening in production environment ?
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
virang_21 wrote: What would you do when there is no way to replicate situations happening in production environment ?
Pray. 
(Seriously though, I sympathize that you had to put untested code into prod.)
/ravi
|
|
|
|
|
I'm in a similar situation WRT a BI tool that's too expensive for us to buy a second license for a dev server; the best option I've found it to keep a supply of medicinal scotch and bourbon at home. 
OTOH we at least can schedule our test deployments around when no-one needs the server to be available; which doesn't appear to be the case in your problem. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
|
It loads now.
|
|
|
|
|
|
This problem has been *already* been solved.
Many times over.
Since computers were invented.
By NASA, by the Military, by safety critical industries.
Seek education in their solutions.
|
|
|
|
|
Michael Kingsford Gray wrote: By NASA, by the Military, by safety critical industries.
Yep, when something blows up, they patch it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
If only you had their budget...
They will never have seen anything like us them there. - M. Spirito
|
|
|
|
|
I've done that more times than I'd like to admit...
Strange error occurring in production, test on my machine and everything runs fine.
Just make some fix that -could- solve the problem and ask the user to test it.
We don't have any specialized test environment or anything. So if it doesn't work on my computer, or that of a colleague, well, we're forced to test in production.
Actually, only our two biggest customers test our changes in a test environment.
Our other customers can't be bothered by setting up test environments (or have us do it).
So when we've done the 'developer testing' we can put the code in production and pray we've programmed what the customer wanted
Luckily this approach works for us and our customers most of the time (we always keep backups of previous versions in case something breaks).
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Add a LOT of logging to see what is happening.
Always assume connections are not open and test them before attempting any communication.
|
|
|
|
|
Add lots of logging until you are sure you understand what the real problem is (although sometimes you have to take your best guess or add code to fix the symptoms without finding the root cause in a truly complicated system).
I worked on an automated conveyor system at one time. One customer kept having their box counts off and the shipping company was so aggravated they threatened not to ship for the company any more. The programmer tried lots of things to fix the "faulty sensors". The problem was finally solved when he was at the company late one night and saw a bored employee playing with the blinking lights. The employee had no idea it was throwing the shipping counts off.
Production always seems to come up with some combination of circumstances you don't think of.
|
|
|
|
|
Member 8824288 wrote: Production always seems to come up with some combination of circumstances you don't think of.
Don't they ever! I could probably share a ton of horror stories with you since I used to program conveyors as well.
Of course the biggest problem we always had was what I called the U shaped communication channel. Worker would note a problem, mention it to his supervisor, who'd mention to his boss, until the company I worked for was called about it, and then it eventually filtered down to me. (AKA the Telephone Game)
What would start as a simple problem would turn into "The conveyor is on fire, running backwards."
We once thought we were clever hiding a "Dump All" report behind "Ctrl-A", never expecting the operators to rest with their palms pressed down on the keyboard covering CTRL and A and the terminal autorepeating requests for reports that would print for a half hour each. We'd had to reset the computer because we had not added a "delete print job" to our report queue, although even if we had, there would have been hundreds to delete.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Like others have said, plenty of logging always helps
Including unit/integration tests in your solution can also help you to simulate various error conditions and allows you to design your code to handle these scenarios.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
I work in a similar environment where there is one "machine" fully automated manufacturing process with robots, vacuum chambers heaters, gauges, etc. At times I cannot get to this equipment because it is under test and this keeps me from testing my code base. I finally bit the bullet and created a number of virtual machines which are deployed onto other computers. These vMachines will use the identical messaging system TCP/IP, RS232, RS485 (same infrastructure used in production). The nice thing about my virtual machines is that they can be setup to fail for specific reasons. Also the virtual machines do not need to produce the full list of features, just the areas that you need to test.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
