The config file is contained in your .ssh folder located in your home. There are a few directives in the files that I use constantly. Here is an example of a file that I might have setup

Host local-server-name

HostName 0.0.0.0

Port 22

User Me

IdentityFile ~/.ssh/local-server-name-key

The first value Host is what I want to use as a name for that server locally. Depending on how much typing you like to do you can make it as long or as short as you want. HostName is the ip or address used for connecting to the server normally. The Port only needs to be added if your using a port other then 22. User is the user name that you wish to connect to with. IdentityFile is the location of the private key that you might have setup on that server for authentication.

Once this file has been created and you have all your servers added, you can now access any of these servers via there name in most commands.

Connecting to the server via SSH

ssh local-server-name

Sending a file to the server

scp ./filename.text local-server-name:/

Your configuration file can have as many entries as you want for as many servers as you want. You can even have the same server setup multiple times with different User or User/IdentityFile. I hope this was helpful, I know it has saved me a ton of typing on many occasions.

My New Years Resolution this year was to do a much better job at maintaining this site, as well as keeping to a sort of floating posting schedule. I will try and maintain at least one post per week, maybe more if I find the time. I want to also start posting reviews on items that I use, enjoy, read or like in hopes that maybe someone else thinking of getting such items will see value in them.

Freezing

Let’s say your sitting in front of a newly created project, you just setup the environment, installed all the foreseeable libraries, setup the structure of your project, and create the repository and committed all your changes. Your missing one thing, a requirements file, a file outlining to yourself or anyone else that might work on your project exactly what libraries you have. Creating such a file really is not that difficult, deciding where you want to put it, that can be tricky. I always place my requirements file right at the root of my repository. To create this file just run the following command, either keep it as is to drop your file in the current working directory, or add a path to it.

pip freeze > requirements

You now have your very own requirements file setup specifically for your project. The only task left for you at this point, is to add it to your repository and commit the changes. If down the road you need to install new libraries, running this command and overwriting your file, is perfectly fine, just be sure to commit those changes also.

Unfreezing

If you are about to work on an existing project, and have this project checked out and ready to go. The first thing you will want to do is setup the environment for that project, and activate it.

virtualenv --no-site-packages --distribute [project_folder]

cd [project_folder]

source bin/activate

Afterwards enter the project folder, assuming the original developer used similar naming conventions and named there requirements file requirements, you can install all the required libraries.

pip install -U -r requirements

If the original developer didn’t use any kind of environment, and they just simply listed the requirements. You are still in a good spot, you can build the environment from here using pip to install all the packages you need then saving your own requirements file.

Step 1

Download the necessary packages

wget http://www.mysql.com/get/Downloads/MySQL-5.5/mysql-5.5.13-osx10.6-x86_64.tar.gz/from/http://mysql.mirror.rafal.ca/

wget http://sourceforge.net/projects/mysql-python/files/mysql-python/1.2.3/MySQL-python-1.2.3.tar.gz/download

Step 2

Uncompress the archives

tar -zxvf mysql-5.5.13-osx10.6-x86_64.tar.gz

tar -zxvf MySQL-python-1.2.3.tar.gz

Step 3

The first thing thats needed to be done is located the exact path of mysql_config, which should be located directly in the bin/ folder of the extracted files from MySQL, for my files they are located in ~/temp/mysql-5.5.13-osx10.6-x86_64/bin/ with this in mind change your working path to the root of your extracted MySQL-python-1.2.3 and modify the site.cfg file so that it now contains a mysql_config

vim site.cfg

mysql_config = ~/temp/mysql-5.5.13-osx10.6-x86_64/bin/mysql_config

Step 4

Now its time to build the library while still in the root of your extracted MySQL-python-1.2.3 be sure to run the build

export ARCHFLAGS="-arch i386 -arch x86_64"

python setup.py build

note: I added the export to allow for 64bit compiling under the newer versions of xcode

Step 5

Now that the build is complete, you don’t have any use for the extracted version of MySQL server, but we still need the libraries. Enter back into the root of the mysql-5.5.13-osx10.6-x86_64 and lets put them on our systems. Afterwards you can delete the files associated with MySQL Server (mysql-5.5.13-osx10.6-x86_64)

cd ./lib/

cp ./*.dylib /usr/lib/

Step 6

From here its up to you, you can install the libraries system wide or you can install them on a per environment bases

source ./bin/activate

cd ~/temp/MySQL-python-1.2.3/

python setup.py install

Once you have completed all these simple tasks you will have a system or environment with a mysql connectable python. Also located in the MySQL-python-1.2.3 folder there will now be a dist/ folder which will contain a nicely packaged egg that you can use for future installs on your system. Which makes the whole process easier to install assuming you picked the route of installing on a virtual environment. Save the egg for later and use it again when you need a new install in a new environment.

easy_install MySQL_python-1.2.3-py2.6-macosx-10.6-universal.egg

There is a solution, VirtualEnv allows you to create an environment for python and all its libraries. This environment is separate from the rest of your system libraries, anything installed is only accessible from within the environment. I am planning on writing a few articles related to VirtualEnv, everything from setting it up, using it, and deploying a website using django with it.

Installing VirtualEnv is fairly simple, I am assuming that you already have easy_install installed.

sudo easy_install virtualenv

Once easy_install has done its thing, and virtualenv is installed there’s really only 2 main commands you will want to familiarize yourself with. The first command is used for creating a environment, making sure to use distribute (–distribute) for installing new packages and telling virtualenv to not use the systems already installed packages (–no-site-packages). Finally at then end will be the path (full or relative) to the project location.

virtualenv --no-site-packages --distribute ./project/

cd ./project/

Now that your environment is setup, all there is to do is enter the environment, this is easily accomplished

source bin/activate

From here you will notice that your prompt has changed, adding the project name at the start, anything you install from here is now installed on your environment and will only be accessible from with in. Installing new packages is easily accomplished using the PIP installer.

pip install django

To access your environment all you must do is execute a deactivate command anywhere from within the shell

deactivate

Although this might seem like a bit more work then your standard work flow, the benefits severely outweigh the extra work involved. The entire environment is portable, meaning you can dump a list of all libraries (including versions) to a file which allows anyone to completely build your environment on there computer without requiring you to upload the entire set of libraries to them. I will cover this later in the series, stay tuned.

I have decided that I want to keep a record of some of the stuff I am working on, as well as continue to help people learn in all areas. I plan on posting articles on things as I did before, problems I tackle and solve, solution to problems people have, as well as the usual rants and opinions. I am hoping that I will learn more by teaching others and others will learn as well. So anyone that can bare my horrible writing and want to learn new stuff together, are welcome to join me. I plan on keeping updates frequent and with substance.

from django.template import loader
from django.core.mail import mail_admins

def render_to_email(template, subject, context):
    template = loader.render_to_string(template,  context)
    mail_admins(subject, template)

The function works exactly like Django’s render_to_response function, with one added value to the function for setting the email’s subject

render_to_email('email_general_error.html', 'General Error', { 'request': request, 'message': message})

I personally am not a huge fan of using the “cachebuster” because deciding if something should be cached or not should be decided on by the site and less by the connection to the site for 90% of requests.

This kind of cache bypassing can be useful when trying to get a bit more performance from a image heavy website. By hosting your images with a cache set to essentially never expire, and having your website pass “cachebuster” type information at the end.

 <img src="/images/background.jpg?1273456709" >

The data at the end of the image url could be anything that indicates that the image has changed. When a request comes in the first time the browser would download the image based on the given url, each time afterwards it would continue to use the cache image. When you modify or change the image the data on the url would change and any hit from cached browsers would see the change and download the new copy of the image.

I am currently working on a template command for django that can do this easily, once its completed ill update this post.

window.localStorage['key'] = 'value'

Setting the value of the key is just a matter of assigning a variable. Obtaining an already saved value is also just as easy.

var value = window.localStorage['key']

Here is a small sample using a few basic functions to show how it might be used. You are able to enter text in the box and save it. when the page reloads that new value will display in the browser. When you click on load it will load whatever value is saved in the current storage.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
	<head>
		<title>Html LocalStorage</title>
		<script type="text/javascript" charset="utf-8">
			function save() {
				obj = document.getElementById('btn_text');
				if(obj.value)
					window.localStorage['text'] = obj.value
			}
			function load() {
				obj = document.getElementById('btn_text');
				value = window.localStorage['text'];
				if(value)
					obj.value = window.localStorage['text'];
			}
		</script>
	</head>
	<body onload="load();">
		<input type="text" value="" id="btn_text">
		<input type="button" onclick="save();" value="Save"> | <input type="button" onclick="load();" value="Load">
	</body>
</html>

Keep in mind that because of browsers are only starting to roll out these implementations now, it might not work in all browsers. Also be sure to use the most recent versions.

I’ll be writing and posting more HTML5 posts, giving examples and code on implementing some of the new exiciting things that will be out soon.

Here is a little back story. Everything was to some extent fine, well as fine as everything can be. Until April 8, 2010, Apple announced the new iPhone OS 4, they showed off some of the stuff people have been waiting for. Shortly after the announcement there leaked out a slight change on the new Terms Of Service indicating that Apple didn’t want applications not written in C/C++/Obj-C or “Open Standards” Html5, Javascript, and CSS on their platform:

Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This was just days before Adobe was to launch their new Creative Studio, containing a system that allowed users to write applications using Flash and export them to the iPhone. This was also after a large helping of applications had already been approved and sold on the iTunes App Store that were in violation of this very change, it’s unknown what the future for these applications is.

Now, was this a under-handed tactic, for Apple to pull off? A calculated move to screw over Adobe and everyone else that wouldn’t fall into the allow list? All very good questions, and questions that everyone will have there own opinions on.

Many speculate that this change was done in hopes of maintaining a powerful eco system of applications. There are a few reasons that can be used to argue this:

1) Applications written for multiple platforms always need to be written for the lowest common denominator, otherwise they are not really multiple platform applications. In this case Apple’s argument is that they want applications written to utilize all the capabilities of the iPhone, not just whatever the lowest machine the developers decided to support. This directly affects the customer in a positive way.

2) Applications written using a 3rd party library takes control of the eco system away from Apple and gives it to the 3rd party libraries. If Apple decides to release changes to the Operating System, they now have to rely on the 3rd party library makers to add the functionality on there side before those developers can use it.

3) Applications written in one language and simply translated to another language (C, C++, Obj-C), historically end up with a slower, performing application then the original. Works very similarly on the same basis that how you code something in Java isn’t the same as how you would code it in Python.

All these points can be argued back and fourth, for and against. But in the end it comes down to the customers. After all the dust settles, and either Apple changes there terms or they keep them and enforce it. Companies will still be writing iPhone applications, along with those Flash apps. Flash developers won’t be loosing there jobs, and C/C++/Obj-C developers will have more work. What will be different is iPhones will have native, fast running applications. While other phone customers will get the occasional Flash apps that might or might not be as good as a native app.

P.S: I understand that just cause the application is written in C/C++/Obj-C, does not mean they are guaranteed to run fast. But a properly written one will run faster 9 times out of 10 against a properly written flash app.