You’re probably here because you heard screen is a more “safe” way to ssh, so that a broken connection won’t terminate your processes. Here’s how to do it:
Installation
sudo apt-get install screen
Initial connection
$ ssh rachum@server
$ screen
Reconnection
$ ssh rachum@server
$ screen -ls
There is a screen on:
6786.pts-0.ubuntu (05/10/2013 09:42:11 AM) (Detached)
1 Socket in /var/run/screen/S-rachum.
$ screen -r 6786.pts-0.ubuntu
… And that’s all you need to know to get something out of screen.
Read More
The other day I got an email that really hit me on the head. It was titled “JOOLS, Y U NO SPECIFY A LICENSE?” and here’s how it read:
FYI, your Jools project on GitHub specifies no license. It looks like you intend it to be Open Source or Public Domain, but without specifying a license explicitly, the license is “all rights reserved, no reuse or redistribution allowed”.
Though I don’t mention the project or you by name, the lack of a license inspired this post:
HTH,
Jens Knutson
Harsh, but I know I had it coming. From time to time I hear about license X or license Y, or see a post on HN about which license to use, but I never paid much attention. Licensing is a problem for people with successful projects, I thought. Who has time? My job is to build stuff!
Well, as it seems, not specifying a license can mean failure for your project. I thanked Jens for his email - all the while thinking how many people were in the same situation and didn’t send me an email? Oh man, This is bad.
Don’t let this happen to you. Got an open source project? License it today.
Ever forget how to take a hex string like “2D” and convert it into binary data? Or how to parse an ascii-binary string like “101101” into a plain integer? Me too.
That’s why I crafted this table. It doens’t include all conversion, but it includes every conversion type I know, and you can chain them to get from any source type to any destination.
Every from/to cell assumes that the “original” integer is 45. Enjoy!
Number Conversion Chart
More Python Posts
This is a nifty little trick for making Bash a little more intuitive (for my taste). Usually, when you press the up key, Bash will bring back the last command you typed. This is cool, but what bothers me is that sometimes I start typing a command and then remember I executed it before. So I press the up key and… Bash shows me the last command, disregarding what I typed. What I want it to do is search history for things with the prefix I entered.
Here’s what you do to achieve this. In your inputrc file (~/.inputrc for personal configuration, /etc/inputrc file for global configuration), add the following lines:
"\C-[OA": history-search-backward
"\C-[[A": history-search-backward
"\C-[OB": history-search-forward
"\C-[[B": history-search-forward
The weird symbols at the start of each line represent up/down arrow keys in keypad/ANSI modes. I wish Unix configurations would use proper readable symbols, but a man can only dream.
Little things matter. I’m often amazed of how I can feel I mastered a certain tool or technology, only to discover I’ve missed some basic way of using it. It happened to me on Windows a couple of weeks ago when I discovered cool keyboard shortcuts, like Win+E (which opens My Computer), or on Eclipse when I found out there is a menu that finds everything. On Linux, I’ve found that this happens all the time. Now, finding out how to use awk or sed is one thing, and it requires learning a complicated tool. But there are a lot of little things that are so easy to pick up, that it’s a shame that people miss them. Playing around with directories is so common in a Unix shell, and there are so many tricks you can use.
The basic way of moving around is, of course, cd path/to/dir. So far, so good. What more can you do?
Read More
I so often come across various kinds of boilerplate code regarding dictionaries in Python, that I decided to show some of it here and share the more concise way of performing the same operations.
Presenting: The Dictionary Playbook.
Read More
At my workplace we use Mercurial. We don’t usually work in feature-branches, but in the default branch instead. This is usually not problematic, but I keep running into the following situation: I started working on feature A (on the default branch), when suddenly I am forced to work on (and ship) feature B instead, for whatever reason. When that happens, I usually say to myself “God damn it! I wish I worked on A in a branch to begin with!”.
Enter hg rebase. Here’s what you do.
Read More
I can’t believe I’ve been using Eclipse for - what? - 4 or 5 years now without using Quick Access.
Sidebar - I’ve long been promoting Eclipse’s excellent menu search. It lets you search menu windows for each and every preference and value. For example, consider looking for how to enable print margin display (for keeping your code from exceeding 80 character rows; you do that, right?). Imagine sifting through this intricate hierarchy of menus:
Read More
In the last month, I was in several situations where I was bored to death and had only my Android phone for amusement (Samsung Galaxy S2, for those wondering). I have the itch to program or do something productive in these situations, but for the life of me, I can’t think of any such option and I usually end up playing a brain-numbing game instead.
I am catching up on some reading in Hacker News, but when I have several hours to pass, it’s just not enough. There’s a new Github app out there, but my repositories don’t have enough activity for me to do anything with it. I also didn’t find any free Git client for the Android, so just getting my code is kind of a hassle. Same goes for a Python shell of some sort.
So, the title of this post is an actual question on my part, not rhetorical: how do you stay productive on your phone?
A lot has been written about the concept of flow, and I was well aware of this particular psychological mode way before I had a name for it. I like saying that I’m in the zone. In The Social Network, they refer to this state as being wired in. The most interesting thing about the zone is, of course, how to get there. I can’t really pinpoint the variables that help me get in the flow (possibly because when I’m in it, I usually don’t think about it), and Wikipedia agrees:
One cannot force oneself to enter flow. It just happens. A flow state can be entered while performing any activity, although it is most likely to occur when one is wholeheartedly performing a task or activity for intrinsic purposes.
There are three conditions that are necessary to achieve the flow state:
- One must be involved in an activity with a clear set of goals. This adds direction and structure to the task.
- One must have a good balance between the perceived challenges of the task at hand and his or her own perceived skills. One must have confidence that he or she is capable to do the task at hand.
- The task at hand must have clear and immediate feedback. This helps the person negotiate any changing demands and allows him or her to adjust his or her performance to maintain the flow state.
When I was reading this article, I simultaneously thought about how this translates to programming and I was surprised to see that every point mentioned very clearly suggests opinions I’ve held strongly for quite some time. Here’s what I came up with:
- “It is most likely to occur when one is wholeheartedly performing a task or activity for intrinsic purposes” - good programmers love what they do. You can fake your way into mediocrity, but to reach the top, you’ve got to care.
- “One must be involved in an activity with a clear set of goals.” - small programming cycles, consisting of well separated, well-formed tasks, as advocated by agile methodologies, are the most effective way to focus on what you’re doing, do it well, and move from your finished task to the next one with ease.
- “One must have confidence that he or she is capable to do the task at hand.” - some people, and rightly so, are sometimes surprised by my hubris. While I try not to offend anyone, I believe that hubris is one of the virtues of a good programmer. It’s the thing that makes you write programs to do something that’s already been done, because you believe you can do it better.
- “The task at hand must have clear and immediate feedback.” - some more agile words of wisdom. To me, this translated directly as unit tests. I never work better than when I, in an obsessive-compulsive manner, run unit tests as often as I save my code.
