A few years ago, one of my friends asked me for advice. He was frustrated, mostly out of his job. I wanted to help, but he was at the other side of the globe! I couldn't give him a ready solution. But instead, I sent him my recepie of solving a problem. Here it is.
1. Identify the problem
This is the first step. Unless we identify the exact problem, with all its details, we won't be able to prepare a solution for it. If you could prepare a problem statement, not more than a few lines, that would help much to make things clear.
2. Make a list of all possible solutions
When you are aware what the problem is or what is bothering you or what is it that you are not satisfied with, think of all the possible ways in which the situation could be improved. Even if a solution looks simple, or complex, far fetched, or lengthy, do add it to your list. Include only practical solutions.
3. Choose the best solution from the list
When you know the all possible ways, choose the best one. Depends on what is best for you in that situation. Choosing the best one would require comparisons and judgement on the criteria that you have.
4. Implement the best solution that we now know
Go ahead, its time for action.
When I have a problem, I tend to think in this way. And it works for me. And who doesn't have problems in this world? Sometimes I think that we are here to solve problems. We are all problem-solvers.
Friday, December 26, 2008
Sunday, December 21, 2008
screen 'em
Some of the tasks that I do involve running commands that take way long to finish - some take a few hours, others take a couple of days. Obviously, you can't be staring at the terminal till the task is done. And if you close the terminal, the command dies away. So how to run these commands? Simply running them in background won't help, as they would be terminated when you log out.
One idea is to run them in background, and using nohup.
$ nohup my_cmd &
$ exit
This would start the command in the background in such a way that it won't be stopped even if you log out. But you won't see the output at your terminal. nohup would redirect it to a file named nohup.out
Once I start the command using nohup, there is no way I can interact with it. And I can't see the output at the terminal. Sure, there is a way if I really want to. Keep watching: $ tail -f nohup.out
A better alternative in these scenarios is to use the GNU Screen utility. It offers many useful features.
* I can start the command and leave it alone. Later, I can see how it is progressing whenever I want to.
* I can start the command from one computer, and then see how it is progressing from a different computer. So I can start the task at office, then go home, and when I find time, check how it is going.
* More than one users can share a screen. So if my colleague wants to check, he can also connect to the same screen and see the progress.
* Multiple terminal sessions can be created in a screen session. So I can keep running the command in one of them, and do something else in the other.
* Screen is very helpful when the network connection is unreliable. I would still have the task running even if connection breaks.
Enough. Tel me how do I start.
Check if a screen session is already running
$ screen -ls
Attach to a not detached session
$ screen -x
Start a new screen session
$ screen
Create a new terminal session
CTRL+a c
Toggle between two terminal sessions
CTRL+a CTRL+a
Go to the nth terminal session
CTRL+a n
Send the command character CTRL+a to a window
CTRL+a a
Detach from a screen
CTRL+a d
Terminate the screen
$ exit
man screen for more information
One idea is to run them in background, and using nohup.
$ nohup my_cmd &
$ exit
This would start the command in the background in such a way that it won't be stopped even if you log out. But you won't see the output at your terminal. nohup would redirect it to a file named nohup.out
Once I start the command using nohup, there is no way I can interact with it. And I can't see the output at the terminal. Sure, there is a way if I really want to. Keep watching: $ tail -f nohup.out
A better alternative in these scenarios is to use the GNU Screen utility. It offers many useful features.
* I can start the command and leave it alone. Later, I can see how it is progressing whenever I want to.
* I can start the command from one computer, and then see how it is progressing from a different computer. So I can start the task at office, then go home, and when I find time, check how it is going.
* More than one users can share a screen. So if my colleague wants to check, he can also connect to the same screen and see the progress.
* Multiple terminal sessions can be created in a screen session. So I can keep running the command in one of them, and do something else in the other.
* Screen is very helpful when the network connection is unreliable. I would still have the task running even if connection breaks.
Enough. Tel me how do I start.
Check if a screen session is already running
$ screen -ls
Attach to a not detached session
$ screen -x
Start a new screen session
$ screen
Create a new terminal session
CTRL+a c
Toggle between two terminal sessions
CTRL+a CTRL+a
Go to the nth terminal session
CTRL+a n
Send the command character CTRL+a to a window
CTRL+a a
Detach from a screen
CTRL+a d
Terminate the screen
$ exit
man screen for more information
Saturday, December 20, 2008
bad command or file name
Really? Is my command so bad? Then what would a good command look like?
Long gone are the days when I last saw the (in)famous error message. Most of us would have forgotten it by now. One of the blogs that I was reading today mentioned about it. And in a rhetoric manner.
Why would you want to tell someone that something they entered is bad? Or something bad has happened? Isn't that really foolish? Didn't Mom tell them: "If you can't say anything nice, don't say anything at all." At least, don't say a bad word.
A major reason why software is not easy to learn is that it doesn't give positive feedback. We learn better from positive feedback, rather than from negative feedback. Would you prefer a hired ski instructor who yells at you? Or a restaurant host who loudly announces to other patrons that your credit card was rejected? Certainly not. Then why the should software tell me that I failed?
In my opinion, to be given negative feedback by software - any software - is an insult to human. Yes, I've read the three laws of robotics, and can recite them for you even during sleep.
Forget robotics and the mean machines, but for me, to be told by software that you have failed is degrading. And the same should be for everyone. There is nothing so important inside that dumb box that you can justify degrading a human user. If you want to protect you files, do it. But do so without bothering me. It's all right to protect the computer but not at the cost of bothering the user.
If I mistype a command, with bash, csh, sh, tcsh, zsh - they all tell me:
command not found
Well, that's better - it tells me without insulting me that my input could not be processed. And it even hints that what I entered was treated as a command, without misleading me to file names.
An error message is the program reporting on its failure to do the job, and it is interrupting the user to do this. So it must be polite, illuminating, and helpful.
Have you never heard - The customer is always right
Long gone are the days when I last saw the (in)famous error message. Most of us would have forgotten it by now. One of the blogs that I was reading today mentioned about it. And in a rhetoric manner.
Why would you want to tell someone that something they entered is bad? Or something bad has happened? Isn't that really foolish? Didn't Mom tell them: "If you can't say anything nice, don't say anything at all." At least, don't say a bad word.
A major reason why software is not easy to learn is that it doesn't give positive feedback. We learn better from positive feedback, rather than from negative feedback. Would you prefer a hired ski instructor who yells at you? Or a restaurant host who loudly announces to other patrons that your credit card was rejected? Certainly not. Then why the should software tell me that I failed?
In my opinion, to be given negative feedback by software - any software - is an insult to human. Yes, I've read the three laws of robotics, and can recite them for you even during sleep.
Forget robotics and the mean machines, but for me, to be told by software that you have failed is degrading. And the same should be for everyone. There is nothing so important inside that dumb box that you can justify degrading a human user. If you want to protect you files, do it. But do so without bothering me. It's all right to protect the computer but not at the cost of bothering the user.
If I mistype a command, with bash, csh, sh, tcsh, zsh - they all tell me:
command not found
Well, that's better - it tells me without insulting me that my input could not be processed. And it even hints that what I entered was treated as a command, without misleading me to file names.
An error message is the program reporting on its failure to do the job, and it is interrupting the user to do this. So it must be polite, illuminating, and helpful.
Have you never heard - The customer is always right
Subscribe to:
Posts (Atom)
