|
Any experience with?
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I think there aren't that many Japanese CP-Members 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Well, there were - but the last time Clonezilla attacked Tokyo, most of them perished... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: but the last time Clonezilla attacked Tokyo, most of them perished disassembled.
ftfy 
|
|
|
|
|
Yes, but the last time I used it was a few years ago. It worked well, but it wasn't the most user friendly. Other options are EaseUS Todo Backup or Aomei Backupper.
|
|
|
|
|
I can second AOMEI - I use it and it's damn good! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: What are your methods?
Well, I take several approaches, often multiple ones:
- Determine test fixture -- what do I need to set up to actually debug / test? How do I isolate the test fixture? How can it be automated so I'm not clicking through the UI?
- Write the test first. I actually do this very rarely because I find it hard to express the test results ahead of time. It's only when I write the actual code that I think, ok, this needs to be tested, that needs to be tested. Also, when dealing with new technologies, I often don't know what the format of the data is until I get the hardware or API working -- what does the card scanner actually give me, what does the JSON actually look like?
- Step through the code. I do this almost all the time to make sure that I'm understanding correctly the tech with which I'm interfacing.
- Write the test after writing the code. For certain things, I definitely do this. Once the baseline code is working, I can then throw different scenarios at it. Useful scenarios that represent anticipated use cases, not just mindless contract testing or the like.
- Debug the tests.
- Try out the code via the UI. Funny thing is, that often reveals things I didn't consider.
- Put the app in front of someone else. Not so funny is seeing how other people go about using the app, and the bugs that are revealed in that process. Not just algorithmic bugs, but also UX bugs -- if the user experience sucks, I consider that a bug.
- Put the app in front of select customers. Very revealing and is the best way to discover that the spec itself is buggy.
So debugging is not just about code. It's about the user experience, whether the spec accurately captured the user's needs, and understanding how stuff is used in the wild.
Marc
|
|
|
|
|
Oh, Marc!
That was far too serious for Sunday...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: That was far too serious for Sunday...
I know.  But it got me thinking!
Marc
|
|
|
|
|
Debugging? Testing? Pah! That's what customers are for.  
|
|
|
|
|
You don't work for HP do you?
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: What are your methods?
No need to debug if you get it right the first time! Of course, this rarely happens!
"Go forth into the source" - Neal Morse
|
|
|
|
|
I used to check in insect repellent with my code in TFS. I had to stop because of that awful code smell.
"You'd have to be a floating database guru clad in a white toga and ghandi level of sereneness to fix this goddamn clusterfuck.", BruceN[ ^]
|
|
|
|
|
I test as I go. I'd rather debug 10-50 lines than get 100's of lines in to find I must have been smoking the wacky taccy with code that had no hope of ever working.
When people bring me code they want help debugging, I usually gut the code to something smaller and gives proof of concept instead of dealing with all the bells and whistles they coded before finding if the core code was going to work in the first place.
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.
|
|
|
|
|
'Prince of Tides' author Pat Conroy dies at 70[^]
Cancer is a [REDACTED].
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
human-ice interactions
This reads like it was completely computer generated. Then again, I've known some women I would certainly describe as "glacial." 
Marc
|
|
|
|
|
In Australia 'ice' is colloquially used to describe Meth.
Might be relevant gor Trump.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
But, did you ascribe the adjective, "glacial," only after you were unable to melt them, and there was no run-off ?
«In art as in science there is no delight without the detail ... Let me repeat that unless these are thoroughly understood and remembered, all “general ideas” (so easily acquired, so profitably resold) must necessarily remain but worn passports allowing their bearers short cuts from one area of ignorance to another.» Vladimir Nabokov, commentary on translation of “Eugene Onegin.”
|
|
|
|
|
Marc Clifton wrote: I've known some women I would certainly describe as "glacial.
Does that refer to their mood or speed of thought? Or perhaps what seems to be the case here, both.
|
|
|
|
|
|
Mladen Janković wrote: Feminist Code: Critical Code Studies Working Group 2014 | HASTAC[^]
In a rational world, the author of this piece of drivel would be tarred, feathered, and run out of her university on a rail.
In our world, she'll probably be put on the short track to tenure. 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Well that's one 'possibility space', certainly but let's not get too caught up in paradigmatic analysis too hastily lest we collapse the dialectic. It is essential that we lucubrate on perambulation before we envisage accelerated motion.
I am not a number. I am a ... no, wait!
|
|
|
|
|
You, sir, are a doubleplusgood duckspeaker 
(see Nineteen Hundred and Eighty Four)
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)