Lately I’ve been testing an application I wrote that will perform firmware and configuration upgrades on a Cisco router and then reboot it once the upgrade is done to apply the upgrade. These are being done over an SSH session, so when the router reboots my SSH session becomes unresponsive.

Once this happens you can’t interact with the terminal session anymore because the SSH client catches all of the commands and since the SSH session is toast they don’t do anything. ‘Ctrl + c’ doesn’t exit the session because of this.

Previously I’d either just exit the terminal window and open a new one or wait until the connection came back. But recently I discovered there’s a command to exit the SSH session, which is return + ~ + .

That means you hit return, type tilda, and then type a period. This will exit the SSH session for you and let you continue working in the same terminal window.

I was recently using Remote Desktop Connection for Mac to remotely work on a Windows PC. One thing that bothered me was I wasn’t able to scale the size of the screen. It was stuck at 1024x768, which was far too small for me to comfortably work.

One way to adjust the size of the screen is to edit the .rdp file. To do this, in the RDC file menu when your session is active click Save As and save the .rdp file somewhere on your system. Then exit the active session and open the .rdp file in your favorite text editor (I used Sublime Text). Find the DesktopHeight and DesktopWidth labels. You can increase both but probably want to ensure they have the same ratio. The default was 1024x768 (a 4:3 ratio) so I increased them to 1440x1080 (still a 4:3 ratio).

Then all you do is save the .rdp file, open it, and the new session should be at the new resolution.

Up until recently I didn’t realize you could style horizontal rules (<hr />). Of course you could use a div to do the same thing, but using a horizontal rule for its intended use is nice (and easier than using a div).

Here’s the CSS I used most recently on a website I’m making to customize the horizontal rule.

hr {
    width: 90%;
    border: 0;
    height: 1px;
    background: #000;
    opacity: 0.2;
}

Of course you can also name the style and apply it to the horizontal rule.

// CSS
hr.custom {
    width: 90%;
    border: 0;
    height: 1px;
    background: #000;
    opacity: 0.2;
}

// HTML
<hr class="custom" />

You can also do things like gradients, blurs, etc.

The easiest way to create a custom text input on a form is to remove the default border of the input and place a custom image behind it as its background.

Here’s the background I’m using:

Here’s the HTML.

<div id="search">
  <form method="POST" action="#" accept-charset="UTF-8">
    <input class="search" type="text">      
  </form>
</div>

And the CSS.

#search {
    width: 362px;
    height: 41px;
    background: url('/images/search_bg.png') no-repeat left top;
    line-height: 41px;
    margin: 10px auto 10px auto;
    text-align: center;
}

.search {
    border: none;
    text-align: center;
    outline-width: 0;
}

The line-height property sets the line-height to the same height as the div height. This has the effect of vertically centering the input (and hence the text) in the div.

The border property is the one that makes the default text input’s background invisible, and then we set the background of the containing div to the image we created with the background property.

The margin property is used to add a 10px margin to the top and bottom of the div. The auto attributes are used to center the div (and hence the input) in the middle of the page.

I received a phone call from my Mom yesterday because she was having difficulty joining a Wifi network at a hotel using her iPad. She said she was going into the Wifi settings, tapping the network she wanted to join, but then it would say “DHCP” and list a bunch of entries like “IP Address” and “Subnet Mask” and she didn’t know what to do.

After thinking for a few seconds I realized she was tapping the blue arrow at the right of the Wifi network instead of tapping elsewhere in the row. Tapping the blue arrow takes you to details of your connection while tapping elsewhere will simply try to join the network.

I looked up Apple’s support document for joining a Wifi network and it doesn’t tell you where you should be tapping, just that you should click the network you want to join. So in her case it wouldn’t have helped.

My point is, things like this aren’t completely obvious so you need to be careful when deciding how to make things work.

This is a post I read on reddit. Pretty awesome so I thought I’d share.

This is sort of how I started running too. When my life was falling apart and I thought nothing else could go right I started going to the gym to force myself into something social everday. Just to interact with people. Just to do SOMETHING.

And then I started running. And then it started being about me. And that feeling. And the act. And how free it was. How independent. How strong. How I didn’t have to hold back anything like I did with the rest of the world. On the treadmill, on the trails, on the track, in my running shoes I was allowed to be raw anger and pain and frustration and loneliness and strength, too, because fuck the world that doesn’t think it takes strength to be alone.

Fast forward six months – my first 5k. Six more – half marathon. A year – marathon. I’m still the only one I know who’s done it. I’m about to start training for the triathlon. And yeah, I like my body a lot better now, not so much because of the way it looks but because it is a powerful, independent, free extension of the strength I carry and I can show that any time.

So you, more power to you. Run. Run for as long as it makes you happy. There’s nothing like that first ten miler that you take in the middle of the night without your phone or telling anyone where you went and you think it’s never going to end and when you finally finish your legs are fucked for the next three days, but fuckitall if it wasn’t worth it. Running’s like that. Welcome to the family.

Original Post

When creating an init script, make sure the lock file it creates in /var/lock/subsys has the same filename as the init script. When switching run levels the rc scripts check for the existence of a file in /var/lock/subsys with the same name as the script, so if the lock file has a different name than the script the service won’t start/stop correctly even if there are start and kill symbolic links in the /etc/rc*.d directories.

I recently created an init script that used a different name for its lock file and it took me quite a while to figure out the issue. Oops.

When NZBMatrix was shut down I eventually came upon Newznab and installed it on my local server. After enabling a few groups I ran update_binaries.php and it seemed like it was working, but when I ran update_releases.php after update_binaries.php had finished it didn’t create any releases. The issue is the regex’s (or lack of) that come with the free version of Newznab. One easy fix for this is to donate to the project and get Newznab+. This includes the most up-to-date regex’s.

If you want to just try out Newznab and want to get some releases on your site before you donate, you can do the following (this is a Linux example):

cd /tmp
wget https://raw.github.com/kop1/newznab/master/db/latestregex.sql
mysql -u USERNAME -p DATABASENAME < latestregex.sql

That will update your regex’s so update_releases.php will create some releases. If you’re happy with Newznab I highly suggest donating and getting Newznab+. It comes with lots of improvements and you’re directly supporting the people who work on it.

Paul Graham has a ton of great essays on his website to do with startups, programming, and being an entrepreneur. I’ve read quite a few of them in the past and they’re all really insightful and give great advice.

The latest one I read was Holding a Program in One’s Head. It gives some awesome advice for programmers.

I get really frustrated when I see a commit message that doesn’t adequately explain what the author did and why he did it. Commit messages are really important. They’re the only source of information on why a change was made. If a change introduced a bug, a commit message can help explain why the author made that change, and will help shed some light on what functionality the author expected to change. This can be extremely helpful when trying to figure out what commit introduced that bug. You need to be able to use those commit messages (especially the header line) to quickly cross-reference the issue you’re seeing to help narrow down what change caused the issue.

In addition, if you’re working with other developers on the same repository, your commit messages will help them understand what you’re working on and why you’re making the changes you’re making. Commit messages are a great way to share knowledge about the inner workings of a code base. Your own understanding of the code you wrote will never be better than when you’re writing its commit message (as long as you commit often!).

Writing detailed commit messages can also help you review your own code. I can’t count how many times I was writing a commit message, and while going over the diff making sure I didn’t forget anything, I saw something I either didn’t mean to include (maybe a random debug log to figure out why something wasn’t working) or something I could refactor. Writing detailed commit messages has been extremely helpful in making my own code better by forcing me to review the changes before I committed.

I really like the way Linus Torvalds writes commit messages. He always provides a lot of detail about what he’s doing and why. They’re an awesome source of information. Without his detailed commit messages, looking years back into the history of the Linux kernel at one of his commits you’d spend significantly more time figuring out why the change was made.

Here’s an excerpt from one of his projects (subsurface) on what he expects in a commit message.

A good commit message looks like this:

Header line: explaining the commit in one line

Body of commit message is a few lines of text, explaining things
in more detail, possibly giving some background about the issue
being fixed, etc etc.

The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about
74 characters or so. That way "git log" will show things
nicely even when it's indented.

Reported-by: whoever-reported-it
Signed-off-by: Your Name <youremail@yourhost.com>

where that header line really should be meaningful, and really should be
just one line.  That header line is what is shown by tools like gitk and
shortlog, and should summarize the change in one readable line of text,
independently of the longer explanation.

Please, when writing a commit message, take the above advice and make the message meaningful.

Another rule you need to follow is to commit often. Commit every time you make a change that you could possibly want to roll back in the future. These changes can be big or small, but should only ever be one “thing”. If you renamed a class, make a commit. If you refactored a method in that class to make it faster, make a commit. Why can’t you commit the renaming of the class and the refactored method in the same commit? What if you later found out the refactoring of that method introduced a bug? Rolling back that commit will not only revert the changes you made to the method but will also change the name of the class back to its old name! That’s not something we want. Now we have to change the name of the class back to its new name after reverting the commit.

That’s a simple example, but if you keep your commits to one “thing” you’ll save yourself the headache of having to re-implement changes after reverting a commit that included multiple changes.