Deploying a Website with Git in 4 Steps

Posted on January 25, 2012 by Stephen

Git is incredibly handy for moving work around to different machines, so a reasonable thing to consider is actually deploying a website to your server. I’ve done this in a few different ways, but this is a simple recipe to accomplishing the task. In these steps, I assume you’ve already SSH’d into the server and you know where your web root is.

On the server, outside of the web root:

mkdir myRepo.git
cd myRepo.git
git init --bare

On the local machine:
```
git remote add myServer myUsername@ServerHostname:~/path/to/myRepo.git
git push myServer master
```
The name for your remote can be whatever you want, but the server hostname needs to be what you use to SSH into your server. The way we’re setting this up, unless you have SSH certificates already installed, this process will ask you for your password every time you attempt to push something up to the server.
Back on the server, in the web root, at the location you want the website to be deployed:
```
git clone ~/path/to/myRepo.git .
```
And then, to make the live repository auto-update, you need to modify the hooks/post-receive file in the bare repository. You may need to rename it from post-receive.sample, but this is what it should contain:
```
cd /absolute/path/to/myLiveDir
env -i git pull --ff-only origin master
env -i git submodule sync
env -i git submodule update --recursive
```
The reason for those last two commands is so your submodules, if you have any, will remain in sync and checked out on the deployed repository. You might also need to change the permissions on this file, if they’re not already correct:
```
chmod 755 post-receive
```

And you’re set. All you need to do to push new commits to being live on your server is:

git push myServer master

For those interested, what’s happening here is that you’re pushing to a repository on your server. It’s a bare repository, so it only contains the git object version of your files. This repository, however, upon receipt of new commits, will push them to a regular repository in the web root. The reason to have essentially a proxy repository is because, without overriding some protective settings, git disallows updating a non-bare remote repository:

Refusing to update checked out branch: refs/heads/master. By default, updating the current branch in a non-bare repository is denied, because it will make the index and work tree inconsistent with what you pushed, and will require ‘git reset –hard’ to match the work tree to HEAD.

So, setting up this proxy allows you to keep this setting intact. Further, because we told git to only allow fast-forward updates, we have to resolve any potential merge conflicts before the live repository will accept any changes. It’s pretty simple to stay ahead of this, just don’t make any commits directly to the live repository and always reconcile with the bare repository before attempting to push.

Related to this and the topic of a planned post, you can use a similar strategy to version and synchronize a database schema. It’s definitely a more complicated, and somewhat riskier process, but one that deserves some attention soon.

Searching Browser Internals on Chrome

Posted on January 22, 2012 by Stephen

I recently switched to Chrome in celebration of Tyler joining the Chrome team at Google, and it’s been really great. The Omnibox is perhaps one of the best features, but the experience out of the box did leave some things lacking.

As a user, I often visit websites and bookmark them to save them for later reference, or I don’t, and I just expect to be able to find it in the browser history. This seems pretty standard. My thought is that the Omnibox should be more helpful in this process. Sure, I could just search again or use one of the few history or bookmark suggestions that pop down, but sometimes I really just want to get a quick search within the scope of things in my history or bookmarks, perhaps with the ease of a search engine keyword. Fun fact, you can do this! It just takes a little digging into the Chrome settings.

So, say you want to be able to type “h javascript” to search your history for anything Javascript, simply go to your search engine settings (chrome://settings/searchEngines). Here, you can add History with “h” as the keyword and the following as the URL:

chrome://history/#q=%s

You can do the same for bookmarks with:

chrome://bookmarks/?#q=%s

Perfect. Now if only this were a more noticeable option, perhaps as a default setting; I’m sure other people would love this were it more obvious.

Sysadmin

Posted on October 18, 2011 by Stephen

I recently (mostly) finished a transition to a new server. I came from a free web host that was pretty good, but had some significant limitations (mainly in PHP, but also that I was limited to software they provided). Now I have my own VPS. I struggled a bit getting set up, but now I’m much better from it. To someone getting started on this kind of project anew as I did, here’s a few pieces of advice:

Use an OS that has a package installer. SSH and SFTP are great, but they are only minimally convenient when it comes to installing lots of software. When you consider every little thing you’ll end up needing (which is a lot—my server didn’t even come with cURL installed), having an easy way to get all these little things is vital to your sanity.
Consider the software you’re planning to use. Not doing this is a mistake I have yet to pay for. As I type this, I’m using Lighttpd as my webserver. Because I’d like to deploy an instance of Diaspora*, I’m likely going to need to switch back to Apache or some more conventional server. The issue is Lighttpd will not allow some of the server to be on http and some of it to be on https. It’s all or nothing. I certainly would like parts of it to be on https, but not all of it should be. If I had known these things ahead of time, I could have prevented myself from duplicating a lot of work. On the other hand, I suppose these things must be trial and error for a while, unless you read every little detail beforehand.
Set up a significant block of time to get your server up and/or make switching to your domain name one of the last things you do. For a while during the installation of various things (i.e. WordPress), the website, when visited, would display some confidential information. This is a problem. The suggestion here is that while these hiccups are difficult to avoid for a new sysadmin, minimizing the time and visibility of these issues can significantly mitigate the problem.

That’s it for now. Later to come: a step by step on how I now deploy parts of my site using git, because conventional knowledge didn’t seem to work for me and might not for you either.

WebIAT 2

Posted on August 29, 2011 by Stephen

After a long while, I finally have a working version of WebIAT online. I originally developed this for some cool folks over at the UCLA Anderson School of Management: Geoff Ho and Margaret Shih, but they graciously agreed to open source the work so I can continue working on it.

The software manages and runs Implicit Association Tests. These experiments, pioneered by Anthony Greenwald, determine a person’s association between different paired categories. They could be many things, but commonly they have to do with positive/negative and some class of people potentially facing discrimination, like black/white or employed/unemployed.

The version here is an early alpha, but it is up and running here: http://iat.stephensearles.com/admin/. The current login available publicly is username: test password: test. This will change soon. Further, any data on the site could be wiped off as I continue to develop, so don’t put anything there you’re counting on. Other than that, let me know what you think! Play with the site, and if you like, tinker with the source code here.

Why here, why now?

Posted on August 15, 2011 by Stephen

At the start of this blog, I would like to take a moment to outline my own expectations for what I plan to do here. The thought to start a website at all came from a need for a place to publish code and demos online. Done. Registered the domain and there’s already a bit of code here. The bigger question, though, is what can I do with this here website? What does it represent to me? Sure, the main thrust behind it will be to host my own code, but at the same time, I can use it to express more than my ability to write code.

I had always been hesitant in the past to start something like a blog. I worried about being held to the words I publish online. I feared the likelihood that nobody really has much interest in what I have to say. So why have a blog component to what could be a much simpler website? Despite all my concerns, I have a voice and I should use it. What more, it really is an exciting privilege that I can write these words on my own website. Now, I step into an emerging global conversation on the Internet on my own terms, not on those of any social media platform, not within the domain of anyone else. This is an important point, because in the era of Facebook, on the possible brink of a paradigm shift toward Google Plus, we need to remember that the Internet is more than the websites that are already there. We can take it back and reclaim it as the public and open virtual space it once was.

While I won’t hold myself to a particular topic for this blog, this post should be telling. Code and critical thinking will both be prominent. With that, I’d like to note that there is some code already here: jEditUndo and SelectWithOther.jEditable. Both plugins to an edit-in-place jQuery extension, developed for a much bigger project I’d like to talk more about very soon.