I find the concept of Node.js interesting, in that it’s a web server stack (similar to LAMP) but without all of the typical components of a stack. In other words, it’s everything LAMP is but contained in a single installation (if you don’t count all of the modules you have to require).

Here’s the down-and-dirty truth: I am getting somewhat tired of creating web applications with LAMP (specifically the “AMP” part). Not that it doesn’t suit my needs, or that it is particularly laborious or troublesome, but that I know there must be something better out there. Something that I might already know a lot of (JavaScript). Something that reduces the exposure to (and the need to code around) the annoying database layer.

I particularly hate having to code three different server-side layers: PHP, MySQL, and Apache (if you count htaccess).

Node.js seems like it simplifies all of that into a single layer, and uses JavaScript for everything (and a heavy dose of JSON).

Here are some initial oddities I’ve noticed when using Node.js:

• Odd use case: 'use strict';
• Functions within functions.
• Exposing functions to other modules. Example:

function init(exchange, orderType) {
    ...
  } module.exports = {

Otherwise it’s all very familiar to me already (due to it being JavaScript) and I am picking it up fast. It’s just a matter of finding real-world projects that I can apply these new skills to (which will continue my involvement and learning process).

(Multi-purpose devices like any smartphone also have benefits but that’s not the focus of this post.)

I want to go from camera to web more quickly than I currently do. By “web” I mean a submission to a personal server/domain (where the image is saved and a public URL is provided), or any social sharing site or web service.

I want this for web-enabled camera devices, and non-web-enabled camera devices.

One option is Dropbox automatic uploads (once a camera is attached):

This seems to work very well, and there is also an equivalant on iOS (once you take a photo and open the Dropbox app, it automatically uploads it).

Next, I could use Zapier (or something similar) to process new uploads to Dropbox:

This seems to work great – it’s a fully automated camera to web process that only requires taking a photo and connecting it to a computer (or loading the app on iOS).

The best part is I can do this with cameras that don’t have WiFi or any web features.

I’ve toyed with the idea of ditching my complicated server and software setup and moving to a “jump right in and start blogging” service like Tumblr. In fact, the idea of switching is so compelling at times, I’ve created numerous accounts at times when I really feel the urge. Those accounts always end up sitting static as I either run out of time to play around with it, or find a valid reason to keep using the approach I am using.

If I were to ever switch, I would need ability to:

1. Import all blog posts and feedback.
2. Have the same URL’s for blog posts and RSS feeds.

(#1) would be especially tricky with feedback, as there would need to be some way to relate feedback posts to blog posts.

(#2) would require a CNAME (most services offer this) and a custom URI structure of my choosing (YYYY/MM/DD/post-slug). RSS feeds would be tricky too because I don’t want existing subscribers (all four of you) to have to subscribe to another URL.

I would need some control on a hosting level to handle htaccess stuff and truly configure the crap out of things (if I felt inclined).

I’m doubting any service could offer all this in an easy-to-setup fashion. Most blogging services treat potential customers as new bloggers, which I think is a mistake because a lot of older bloggers (like myself) may want to be relieved of hosting and coding to use a service that lets them easily migrate from that scenario, but still give them some power if they want it.

So this is where I stand: intrigued by SAAS, but not wanting to give up the control I have over every aspect of my site.

Anytime you have to clone the same repository on the same server (for different apps/folders), it requires you to pull changes in each folder (every time a change is pushed).

A better way is to create a single folder on your server, and anywhere you need to access that cloned repository, just create a symlink (dynamic folder link) to the main folder. This way you only have to pull once, and every spot instantly gets the changes.

Creating a symlink is simple using the command line. Let’s say you name your cloned repository “cloned” and your app directory is called “global.” First navigate to the appropriate directory, then issue:

ln -s /path/to/cloned/directory global

A new folder called “global” will appear, but instead of holding files itself, it just links to the source directory. Your web application won’t know the difference.

Common server components

1. Create domains under the new web host.
2. Upload files to appropriate domain directory.
3. Databases created and data imported.
4. Email accounts created (specifically, any MX records pointing to other servers like Google Apps).
5. Cronjobs created.
6. Make sure PHP version is correct.
7. Other DNS settings (like domain CNAME’s).

Script updates

1. Database connections in case you could not name everything identically.
2. Directory path references if it differs from previous server.
3. Any configuration needed in .htaccess files (such as forcing a PHP version).
4. Any php.ini settings, such as date.timezone.

Once all of this is complete, it is usually safe to update the name servers for your domains to point to the new web host. Often some things are not noticeable until you flip the switch, so sometimes you just have to flip it and try to fix things as quickly as possible.

One aspect of branches I have trouble with is their names. I never know what name to give new branches, as it never seems to fully encompass the following things, without becoming too long or wordy:

1. Section or feature of the software I am working on.
2. When I started development in the branch (useful for knowing what state the software was in at that point).
3. Reason for creating the branch.

For one thing, a long branch name requires extra typing every time you want to interact with Git from the command line. Who wants to type “git pull my_really_long_branch_name_from_20120229” every time you need to do something?

Most importantly, branches often change scope or direction, making the branch name sound irrelevant after a while.

(Note: I have the same problem with CSS class names.)

So I’ve started naming branches more abstract, generic, and system-like. For example, I will often just use a simple numbering system, such as “1″ or “2″. I will then keep track (using some other system) what each branch pertains to (description, when it was created, etc).

After my initial trial-and-error, I have yet to find a seamless solution, but I’ll post what I’ve done so far.

I currently use TortoiseGit, and Pageant to store my SSH keys. I chose “TortoisePLink” during the SSH setup when installing TortoiseGit.

Pageant seems pretty straight-forward. You add SSH keys to it, and somehow it communicates with TortoiseGit when accessing GitHub.com.

The problem is when you need to access multiple GitHub.com accounts. You can add multiple SSH keys to Pageant, but it only seems to use the first one listed (the one at the very top):

I can’t figure out a way to have it use a different key from Pageant depending on the TortoiseGit settings (for each local working directory).

I have two GitHub.com accounts – one for work projects, and another for personal projects.

I use the same servers to develop/deploy these projects, albeit in separate directories.

I need to be able to authorize myself (via SSH keys) to either GitHub.com account (and repositories within) on a per-directory basis, all on the same server.

It seems that the local git client wants to use the same SSH key every time it authorizes access to GitHub.com, rather than alternating it depending on the directory I am working in.

For example, here is an illustration of the setup on my server:

root/
  work-project/
  personal-project/

I want work-project to authorize to GitHub.com account A. I want personal-project to authorize to GitHub.com account B.

Multiple SSH keys

I’ve already set up multiple SSH keys – one for each GitHub.com account. Example:

.ssh/
  work_rsa
  personal_rsa

Both keys have been added to their appropriate GitHub.com accounts.

I’ve also already created a config file inside the .ssh/ directory with the following contents:

Host github.com
    Hostname github.com
    User git
    IdentityFile ~/.ssh/work_rsa
    
Host github-matthom
    Hostname github.com
    User git
    IdentityFile ~/.ssh/personal_rsa

I’ve also ran these commands:

ssh-add ~/.ssh/work_rsa
ssh-add ~/.ssh/personal_rsa

This should allow both SSH keys to be used, which it does, but only partially.

It seems like it only honors the most recent ssh-add command. In other words, as long as I run one of the above commands, I am then able to authorize to that GitHub.com account from that point forward. But as soon as I run the command again (for a different account), it then always uses that account to authorize. Therefore repo access attempts fail because it can’t authorize the other user.

I can’t figure out how to have it automatically know which SSH key to use based on the directory I am working in (since each directory is associated with a different GitHub.com account/repository).

UPDATE (12/31/2011)

I seem to have figured it out, thanks to this site.

I re-configured the names of my SSH id_rsa files:

.ssh/
  id_rsa_work
  id_rsa_personal

Next, I updated the .ssh/config file to reference the new file names:

Host github.com
    Hostname github.com
    User git
    IdentityFile ~/.ssh/id_rsa_work
    
Host github-personal
    Hostname github.com
    User git
    IdentityFile ~/.ssh/id_rsa_personal

Notice, in particular, the second Host listed:

Host github-personal

This matches the file name id_rsa_personal. This also matches the actual GitHub.com account name (Note: “personal” is just used as an example, and is not my actual GitHub.com account name). So you would include your alternate GitHub.com account name here, as such:

Host github-ACCOUNT
    Hostname github.com
    User git
    IdentityFile ~/.ssh/id_rsa_ACCOUNT

Next, make sure the directory you create on your server is pointing to the appropriate GitHub.com account:

git remote add origin git@github-ACCOUNT:ACCOUNT/test.git

Again, replace “ACCOUNT” above with your actual GitHub.com account name, which should match the same name you referenced in the config file.

Now you can pull or push to that GitHub.com repository, and it will always use the correct SSH key.

I don’t think you need to run ssh-add ... anymore, but it doesn’t hurt to do this as you can save time from having to re-enter your SSH key password repeatedly.

Let me know if anyone notices any errors in my explanation, or easier ways to handle all this.

UPDATE (01/03/2012)

I forgot to mention I also had to add a .bash_profile file at the root of my server, containing these contents:

SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
    eval `$SSHAGENT $SSHAGENTARGS`
    trap "kill $SSH_AGENT_PID" 0
fi

Otherwise I could never run ssh-add.

I use Amazon Web Services for file storage (S3) with access through my own domains (CloudFront). S3 is great for backing up files and data, and serving them with redundancy and scalability, but what if I could take it a step further and serve entire websites from it? This is not possible with S3, but it is with EC2.

The main problem with S3 for serving websites is that it doesn’t have access to a PHP interpreter (for my situation), nor is it meant to be a full-fledged server environment.

The benefits of EC2 are that you’re literally given a machine instance to work with, just like the computer in front of you. You have full root access and can install whatever you want. You can also stop and start each instance as often as needed (thereby avoiding monthly or long-term costs). It’s literally a “pay for what you use,” on-demand service.

My history with EC2

I think EC2 has been around the longest (of all Amazon Web Services), but I never ventured into it because:

1. I already pay third-party companies to host my websites, albeit in a more fixed manner.
2. I was confused by the large barrier of entry for EC2 – it seemed complicated to get set up.

I’ve taken steps regarding #2 above, thanks to some helpful articles. I started here. This post was also very helpful.

Creating my first EC2 instance

Very quickly I was able to create a new EC2 instance and access the URL through a web browser:

Exciting! Now how do I upload and manage files on the server?

I could already connect via SSH to the server (mentioned in the article above), but I really needed to use a graphical interface like WinSCP because I use that every day to connect to other servers via SSH/SFTP. Plus I don’t know all of the SSH commands for editing files, and it just seems more time-consuming to do everything through the command line.

WinSCP is a SSH, SFTP, FTP, SCP client, so it’s easy to connect to your EC2 instance just like you would through a strictly command-line program like PuTTY. So I could connect right away through WinSCP, but I couldn’t upload/edit files. I was getting “Permission denied” errors.

“Permission denied” errors

After heavy searching, I discovered I had to authenticate as the “root” user after establishing an SSH connection to my EC2 server via WinSCP.

(I’m not a server administrator, so a lot of this is new to me.)

To authenticate as the “root” user, I just issued this command via Putty:

sudo su -

Now I was accessing the server as the root user via Putty. (To be clear, I had a connection open via Putty and WinSCP – Putty for pure SSH commands, and WinSCP for graphical access.)

I navigated to the public web directory using WinSCP (/var/www/html).

But I still couldn’t upload/edit files through WinSCP. This is because WinSCP was still treating my connection as the non-root user (in this case, the user was “ec2-user”).

To allow user “ec2-user” write access to the public web directory, I ran this command via Putty (as the root user):

chown -R ec2-user /var/www/html

I also made sure permissions on that entire folder were correct:

chmod -R 755 /var/www/html

Now I could upload/edit files to my EC2 instance using WinSCP!

Uploading a PHP file

The first thing I did was create an index.php file and put some basic PHP code in it:

echo "test";

When loading my EC2 URL in a web browser, it output “test” as it should! So that means the PHP is being interpreted as expected.

Unique IP address

The next thing I did was assign my EC2 instance a unique IP address. The default URL looks something like this:

http://ec2-101-30-8-29.compute-1.amazonaws.com/

This is somewhat long and ugly if I were to share the site with anyone. Instead I can associate an IP address to my EC2 instance:

Now I can access my EC2 webpage using the IP address alone.

Where to go from here…

As I continue to play with EC2, I imagine I’ll find a lot of useful things. I still haven’t set up a MySQL database, or installed other software on my EC2 server. This post was just to mention my initial experience with EC2.

Would I replace my existing third-party hosting with EC2? Probably not. For most of my personal sites, I don’t need such incredible redundancy and scalability, and having to manually configure everything can be a pain for a novice user like myself.

But for quickly getting a web server up-and-running (to test things or share information), and shut it down as soon as you’re done, it’s a very nice service to have.

Answer: OAuth allows you to authenticate at the source site, as opposed to the site or app that you are connecting with. This increases security, since you are not providing the third-party site with your username or password. The third-party site only receives a key that is used to perform updates or obtain data on your behalf.

As a developer, instead of storing usernames and passwords to connect to another site on behalf of the user, you store a key instead, which is typically a long string of text, about 30-50 characters.

From a development perspective, the OAuth process involves these three steps:

1. Obtain request token.
2. Direct user to URL using token from step #1.
3. Obtain access token.

Step #1 involves submitting a POST request that returns data (the request token) back to your application. Step #2 is just providing the user a link that includes the request token in the URL. Step #3 is when the user is directed back to your application, after authenticating on the external site.

Once step #3 completes, you will have a key that can be used to perform updates, or obtain data on behalf of the user.