Sunday, January 11, 2015

My Week at Hacker School

I first heard about Hacker School last summer. I had run into my friend Lindsey Kuper at a conference in Edinburgh. She told me that she had been a resident and that I should do it too.

"You’ll like it," she said. "I can put you in touch with the people.”

I like being told I'll like things--makes it so much easier to decide. I needed to finish my thesis and get a job, but I also like to say "yes" and deal with the consequences later. One "yes" led to another and I found myself booking travel and accommodations for a week in New York in November.

Since I was busy working on my thesis and getting a job, I did not try too hard to figure out what to expect. Plus I was told I would like it. I had opened a tab with the Hacker School website and skimmed Phil Guo’s blog post on his residency. When people asked me about it, I would say words like "immersive," "free," and "retreat for programmers" and then change the subject.

When the time came, I made my way to my Soho room and then to the address they had emailed me. The second-floor open office space of Hacker School was abuzz with all the chaos and excitement of the first day of summer camp. The beginning of my residency, they told me, coincided with the first day of a new "batch." Every six weeks, a group of new students begin their twelve-week Hacker School experience, joining a group of more seasoned Hacker Schools finishing their experience. Residents are given the unique opportunity to insert ourselves for one or two weeks at a time and observe the unfolding of this social experiment.

A hidden advantage of starting with a batch was that I was initially anonymous. After I acquired my key I took my place by the breakfast spread of pastries and fruit. My PhD has trained me well for standing next to free food: smile politely; introduce yourself; do not take too much food at once. The first person I met was student who had quit a math PhD program (which he had begun at an impressively young age, I later learned) and spent the last year programming and traveling the world. The second person I met was a student who started teaching herself Lisp while working in a bar. She had just quit her dog-walking business to do Hacker School.

After the fifth person it was time for orientation. Here I finally learned the key facts. While Hacker School has hours of being "in session," students and residents all have a key to the space at all hours. Outside of check-ins at 10am and weekly presentations on Thursdays, students are responsible for their Hacker School experiences. The students decide what they want to learn and how they want to go about it--the faculty are there only for guidance and check-ins. Hacker School differs from many of these other 12-week programs in that it is not focused on teaching a specific skill (unlike, for instance, the Ruby on Rails boot camps). In addition, there is a focus on learning skills (functional programming; cryptography) rather than completing specific projects. Some students have a project or direction in mind when they arrive, but many seem to just show up and see where the experience takes them. (You can read more about why they started Hacker School here.)

Orientation kicked off a fun and perspective-changing week. On the first day, I introduced myself, stated my interests (programming languages and functional programming among them), opened “office hours” and waited to see what would happen. I advised some people on learning Haskell and Scala--and also “paired” with them for periods of time. I talked to one student who had gotten into programming through activism and organizing (I later read online that he had been quite involved with Occupy Wall Street) and introduced him to a friend working with city data. After I gave talks about the history about programming and about my work, some people asked me about programming languages and also programming languages research (verification; static analysis). One morning by chance I sat next to a student, Pedro, and we struck up a collaboration to create the Markov Tweet generator that now powers @MarkovRMS. Pedro was eighteen, from Sao Paolo, and had the coolest development environment of anyone I'd ever met.

Pedro, Libby, Fernando and I had dim sum for lunch one day.
And Pedro was only one of many fascinating people I met that week. There were students who were teenagers and students in their fifties and sixties, with grown children. Some had not gone to college; other had PhDs--one woman had studied Computational Geometry and coauthored a paper with MIT professor Erik Demaine, one of the most well-known people in our field. Some people hoped to transition into a programming job: some from non-programming backgrounds and some from having taken breaks from programming to do startups focused on other things. (From the placement of alums, it seems that students are quite successful in getting the jobs they want.) Perhaps because Hacker School gives a second chance to people who have not been programming since birth, the program is far more diverse than the typical tech company.

At Hacker School I was impressed not just with the individual students, but with the community that Hacker School has created. The students are respectful and supportive of each other while working on problems together and also while doing social activities--of which there are many. One reason this is impressive is because tech and programming culture are infamous for being "macho," "aggressive," and unwelcome to women and other minorities. In addition, it is quite an achievement to create a safe environment when the students do not have the built-in trust that comes from having superficial similarities. While many companies leverage “like me” bias to build trust in their teams, the only thing Hacker Schoolers often have in common is a baseline level of programming ability and the fact that they have left their jobs, families, and friends to focus on programming.

Photo from alum Laura Bledait's blog.
While careful student selection accounts for part of the healthy community dynamics, Hacker School’s social rules play an important role in maintaining the safe environment:
  • No feigning surprise. This is when someone will say something like "I've never had sushi before" and someone else responds with, “Really? I didn’t know there were people like that.” This exchange makes the second person feels superior and the first person self-conscious.
  • No well-actuallys. A "well-actually" is when one person states a fact and someone else jumps in to correct the person on a minor technicality. Especially when people feel vulnerable and/or struggle with Impostor Syndrome, well-actuallys are much more harmful than they are productive.
  • No backseat driving. Nobody likes backseat drivers.
  • No subtle "isms." Hacker Schoolers are discouraged from engaging in sexism, racism, classicism, homophobia, etc. To avoid flame wars, people are also encouraged to take someone's word for it--without discussion--if they say an "ism" has occurred.
There is something to be said honest and open discussion and feedback, but these often require a level of trust and respect--both of which take time to build. Given that Hacker School brings together such a diverse group of people for such a short period of time, these rules are surprisingly effective in establishing an environment where people feel safe and supported.

The other aspect of Hacker School's culture that impressed me was how much the students were able to learn and produce despite the lack of curriculum or explicit goal structure. The weekly presentations--and job placement of the candidates--suggest that emphasizing learning and collaboration over specific projects and deadlines can be effective. I was amazed by the diversity and quality of the projects students showed during the weekly presentations. One guy had built an app that tells you where to get a cab based on previous cab pick-ups. Two students had built a simple web framework and then built some websites on top of it.  In addition to having fun work to show, it seemed like people had fun doing the projects in the first place.

The no-pressure atmosphere of Hacker School gave me the opportunity to finally try pair programming, a practice where one person does the typing and the other person reviews each line of code. To help with motivation and to prevent students from getting stuck, Hacker School encourages all students to "pair" on projects. Due to deadline pressure and perceived effectiveness of splitting up tasks my partner(s) and I had always agreed on interfaces and worked separately. With Pedro I discovered how productive it was to have two people look at code at the same time: for catching syntax errors, for finding deeper bugs, and for discussing how to construct the program. Working on code with someone else also allows you to finally have inside jokes about your code with someone besides yourself.

In short, Hacker School is a magical place. For those in a position to get involved, I highly recommend it. For everyone else, it's worth keeping up with what Hacker School is doing--how they are questioning our assumptions about how we learn and work. Hacker School showed me the value in being intentional about culture. It also showed me the value of taking time from my deadline-driven, task-driven life to learn--and play. Also, when I have my own research group, I am definitely going to encourage people to pair on programming and other projects.

Perhaps it was for the best that I did not try to understand what Hacker School was before I experienced it. There is nothing else quite like it. And it might be just what we need to build a more inclusive tech culture.

Saturday, January 03, 2015

Hello 2015!

When I was younger, I had no clue what it would be like to be in my 20s in the mid-2010s. I’d like to report that I never thought life would be so fun.

For me, 2014 was a year of growth. I did some things I’m proud of: supervised a Masters of Engineering thesis, published my first articles outside of my blog (for instance this Wired opinion piece), and started giving public talks about both computer science and technical privilege. I also started journaling again and have a better framework for reflecting on how I feel about my life. Here are some things I’ve been working on in the last year.
  • Building my personal community. Surrounding myself with like-minded people interested in similar things is important not only to my happiness, but also my personal growth. In the last couple of years, many of my friends have graduated and moved away. I’ve also moved on from actively contributing to building other communities, for instance Graduate Women at MIT. This has all left a bit of a lonely void, but it’s also given me a chance to think about how I want to focus my time—and social energy. I’ve been thinking about how my interests in computer science and technology fit in with my desire to more directly engage with and contribute to society. To explore this, I’ve been adding more people with writing, journalism, and civic participation interests to my personal community. I’ve also been exploring this through running NeuWrite Boston, a workshop for scientists and science writers. I feel incredibly grateful to learn from and grow with the brilliant fascinating people who are part of my world!
  • Taking breaks. After spending years trying to find work/life balance on a daily or weekly level, I’ve realized that I’m better at sprinting and resting than moving along at a consistent pace. (Also, in many cases, work/work balance is good enough for me.) Rather than limiting myself to 8-10 hour workdays I’ve given myself permission to go harder when I’m in the middle of something good. Afterward, rather than just pretending I haven’t overworked, I’ve also been more conscious about giving myself the appropriate amount of time to recover. As part of this, I experimented with taking longer—and different—breaks. I spent more time on beaches this year than I did in previous years. I also traveled for my longest consecutive block of time yet: following a conference in Edinburgh in the beginning of June, I traveled around until a friend’s June 28th wedding in Croatia. (Part of this was work/work balance, with research visits I had arranged.) When I came back I was shocked at how relaxed I felt--and about the new ideas I had formed about my life and work. (Sara Watson also wrote this fun article about what I learned about my Android phone.) Even though I'm taking longer "breaks," it doesn't seem like I've been getting less done--and I've been appreciating how changes of scene and pace has left me feeling more rested.
2015 is supposed to be a year of change: I’ve applied for Assistant Professor positions and I’m supposed to finish my PhD. Depending on how many interviews I get, this spring could get quite busy. By the end of the spring I will have made some decisions that constrain my life’s possibility space for the next few years—but it will still be a large space with many exciting things. I’m a bit nervous because I’ve seen other people I respect and admire struggle with this time in their lives, but I also have some great examples of people who managed to really enjoy their final years. Given all that’s about to happen, here are my resolutions for 2015:
  • Know my priorities and keep them in perspective. While it’s important to play the game to be able to keep working on the problems that I find most interesting and challenging, it seems all too easy to get consumed by the game. There are real pressures involved in obtaining and doing the job of an Assistant Professor: you may be familiar with the reported long hours and poor mental health of young academics. It will be important to remember why I want to be in academia in the first place: for the problems, for the people, and for the platform for improving access to computing—not necessarily for the prestige or for things that other people might want. It’s also important to remember what’s important to me about being a human as opposed to a disembodied virtual research-generating entity: my health (physical and mental) and my relationships with other people. Regular reflection is important for keeping all these priorities in perspective. Towards this I would like to meditate and journal at least once a week. Continuing to take the appropriate breaks will also help with this.
  • Embrace uncertainty—rather than fearing it. It feels comfortable and it feels safe to know that good things are going to happen. I spend a good amount of time wishing I could know what would happen. (Knowing where I’m going to be geographically is a big one.) On the flip side, it’s incredibly exciting not to know what is going to happen. In addition, I am lucky enough that nothing really bad is going to happen. In the words of my friend Alison, I know I’m going to have “a roof over my head and food to eat.” Even if I don’t end up getting something I want at the time, any outcome will provide opportunities for growth. Whenever I’m thinking about how I wish I knew what was going to happen, I would like to remember how exciting the possibilities are—and how they are all good. Keeping things in perspective will help. :)
Because people are more likely to achieve things if they publicly announce their intentions, I’ll also say some of the things I’d like to work on this next year. After finishing my thesis I’m excited to work on some of my future research ideas. I’d also like to keep reducing the gap between my professional and personal interests. I’d like to keep thinking about how my interest in programming languages can be combined with my interests in civic participation and social justice. (In this theme, Ari Rabkin and I are writing a piece for the first 2015 issue of Model View Culture about how social biases manifest as biases against programming languages.) Part of this involves thinking about how to make computing accessible to more people. I remain deeply interested in thinking about empowering people through the design and dissemination of programming languages as well as through promoting equal opportunity in computing.

Something I didn’t always realize was that rather than becoming your Final Self at some point, you keep growing—and if this is something important to you, you can get exponentially better at it every year. I’m liking my Current Self better and better every year. I can’t wait to see how we grow in 2015!

Sunday, October 05, 2014

Technical Privilege Reading List

People have been asking about the books I mentioned during last Friday's Challenging Technical Privilege Symposium at MIT. (The symposium was fantastic. So many people came and asked great questions. The video should be up soon!) Below I list the books I mentioned, along with some other books for people interested in the topic. Enjoy. (These are heavy topics, but these books are well-written, engaging, and provide actionable solutions.)

Essential Reading
  • The Curse of the Good Girl (Rachel Simmons, 2010). About how we socialize girls to self-censor. An important read for parents and educators of girls, and also for everyone else to understand why women behave more conservatively than men. (The question of whether this is a "curse" is up for discussion, but it certainly holds women back in a man's world.)
  • Talking from 9 to 5: Women and Men at Work (Deborah Tannen, 2001). Georgetown sociolinguist talks about the "cultural" differences between the way men and women speak and how this affects workplace dynamics--and evaluations. She observes, for instance, that men aim to achieve dominance in conversations, while women aim to prevent their conversation partner from being subordinate. Men assert facts; women give compliments. Because of these dynamics, observers will agree that men "win" workplace conversations.
  • Unlocking the Clubhouse (Jane Margolis and Alan Fisher, 2003). Talks about the authors' research about why women tended to shy away from studying computer science and why women leave. They give concrete explanations for how women are socialized to have less interest: for instance, in families the computer will much more likely be in a son's room than a daughter's room. They also talk about phenomena such as how women cite poor performance as the reason they leave computer science, but in fact they are doing better than men who stay. (Curse of the Good Girl!)
  • Why So Slow? The Advancement of Women (Virginia Valian, 1999). I learned so much from this book! It is full of useful facts and explanations. Psychology professor Valian talks about studies that show there is bias against women: for instance, when people are shown resumes with women's names, the resumes need 1.5x the achievements to be assigned the same title. She talks about everything from work to clothing (how men have a uniform whereas all women are "marked") to physical traits (hypermasculinity is associated with competence, whereas hyperfemininity is associated with incompetence) to misconceptions about gender and emotional stability (people talk about women's monthly cycles, but men have both a daily and a yearly cycle). Understanding these gender biases and difference is an important first step towards improvement.

Other Reading

A related thing I also mentioned is the Representation Project's movie The Mask You Live In, coming out in 2015, about American constructions of masculinity and how it's limiting to men. I highly recommend watching the trailer!

Sunday, September 21, 2014

Some Cooking Updates from the Kitchen-Field

I've been making some slow and steady progress in expanding my cooking repertoire. I even got some plants to aid in cooking! Here are some reports from the kitchen-field (because there are plants now, see) covering the main advances. With thanks to Aliza Aufrichtig and Loris D'Antoni for their expertise and consultation.

Here are some things I've started keeping around my kitchen:
  • Ginger root. I use this with onion or garlic as a base flavoring in stir-fries. I also use it to make ginger lemon tea, which pretty much cures all ailments. (Lazy person's amendment to the recipe: just cut the ginger coarsely and cook it for a really long time instead of grating it.)
  • Dried shrimp. Great for various easy-ish Chinese gourd dishes, for instance bitter gourd and winter melon.
  • Sichuan peppercorns. These little numbing things are great for putting in stir-fries (at the beginning is when I do it), broths, and probably other things. You can use them whole or grind up them up to distribute the flavor.
  • Parsley. Okay, I was late to the party with this universal garnish. I've started getting it more and I even tried to have a parsley plant for a while. The plant didn't go well; Loris made me feel better about it by saying that parsley plants don't regenerate that much anyway. Loris told me about the trick of freezing parsley into ice trays so you have exactly the right amount to use later. (I am not that fancy; I freeze my parsley all together loosely in a container and then shake out a handful at a time.)
  • Basil. Late to the party on this one too obviously. I didn't start using it a lot until I tried having a basil plant, since I had trouble keeping fresh basil around. (This plant didn't go well either.) In preparation in harvesting all those leaves from my basil plant (that actually wilted before anticipated harvest), I bought a lot of basil from the store and practiced using it. I learned how to freeze it--a real innovation! I also invented a great snack: Greek yogurt, blueberries, honey, and BASIL.
  • Thyme. I only recently learned how to cook with thyme, but it seems to go great with tomato pasta sauces and meats. Loris tells me thyme is a good herb to have fresh in my kitchen, so I recently acquired a thyme plant. Fingers crossed that this plant lasts longer.
  • Turmeric, coriander, cumin, and various other Indian-related spices. (I got a masala dabba to hold them!) They're useful for Indian recipes, obviously. I've also started playing around with putting these spices into stir-fries in small amounts.
  • Thai fish sauce. This one is pretty pungent, but I've started using it to put on noodles (along with sesame oil) and also to flavor stir-fries. It look me a couple of days maybe to get used to the taste and smell, but I really like it now.
I've also started keeping around Sauvignon blanc or Gruner Veltiner (white wines) for the purpose of cooking pasta sauce. I've tried using it with vegetables as well (as well as capers with vegetables), but I haven't entirely gotten the hang of that yet.

Here are some favorite recipes that have proven to be easier than I anticipated:
Here are some snacks and other things I've recently invented:
  • Well, that snack with Greek yogurt, blueberries, honey, and basil.
  • This other snack that involves dicing up a pear or nectarine, heating it with maple syrup, and then adding a couple spoonfuls of Greek yogurt. Optional oatmeal makes it more cobbler-like.
  • This sauce for baked salmon with chopped up capers, parsley, basil, vinegar, and olive oil. Salt and pepper the salmon to your liking, bake at 350 degrees for 15ish minutes, and then put the sauce on.
Also food-related: coconut oil is great for maintaining bamboo cutting boards and sesame oil is a great hair and body moisturizer. Who knew? Jump on; it's trendy to use oils for everything now.

Thursday, September 18, 2014

Experiment: Daily GitHub Checkins

I've been doing a lot of relatively mindless but decently labor-intensive code-related work (colloquially known, especially in the brogrammer community, as "coding bitch work"). I've been building up some web-based case studies in my Jeeves programming language. I've also had to take over some student code. Taking over this code was particularly painful because of all the managerial regret I felt: regret about not having made them document better, about not having made them do more work. The takeover process has involved a lot of commenting, test-writing, and the occasional small extension to test that I really know What's Going On.

Anyway, to try to mitigate the pain of these various tasks, or to spread it out and prolong it, I've decided to break from my usual model of nothing-nothing-nothing-OMGdeadline and do a small task every day that I work (which, note, does not include all days), big enough to warrant a GitHub checkin. (For those on the outside, being a computer science PhD student, at least if you're me, involves a lot of paper-reading, talk-preparing, writing, thinking, and "thinking" in addition to coding.) I hypothesized that this would be good for me to make incremental progress on some things that just aren't fun to do, as well as improve the general documentation state and cleanliness of my code and tools. I get pretty obsessed with arbitrary routine, so it's worked out decently well so far. (Check me out.) This policy has definitely made me write some documentation and tests I otherwise would not have written. (Although my pseudo-officemate Joe would argue that this is not "real work.") I'll report on things after we hit "OMGdeadline" and let you know how well it worked.

In the spirit of doing things in smaller increments, I'm also making it a goal to do smaller blog posts instead of the Blog Essays (also see my profile on Medium) I've gotten into a habit of doing. I've dramatically curbed my email habit (I wrote a thing here), so maybe these more frequent blog checkins will give my pent-up words somewhere to go.

Thursday, May 15, 2014

Dual Booting Windows 8.1 and Ubuntu 14.04

It appears that Windows remains ahead in this operating systems arm race: dual booting with Linux has become even more difficult. Here are some updated instructions from the last time I dual booted, in an "idealized order" I have inferred through my various failures*.
  1. Shrink the size of your Windows partition and create a new simple partition for your Linux installation to go in. (More.)
  2. Get an Ubuntu image onto a DVD or a USB drive.
  3. Turn off Fast Boot in Windows. (More.) If you don't do this, your system is going to boot straight into Windows every time.
  4. Disable Secure Boot in your BIOS. (More.)
  5. Enable UEFI and disable Legacy Boot in your BIOS. (More.) I'm not sure why this has to happen, but my Ubuntu Boot-Repair kept failing until I did this.
  6. Boot from your image. (If you haven't turned off Fast Boot, you might discover that there are new ways of doing this in Windows 8.1. But you should have turned off Fast Boot.)
  7. Follow the instructions and install Linux onto the partition you've set aside for it.
  8. Run Boot-Repair to reinstall your GRUB.
After these many steps, you should be able to enjoy the pleasures of dual boot. Enjoy.

* I found this post to be quite a helpful resource during the process. Because I somehow still kept failing, I felt that my shorter summary may be helpful for people who, like me, thought they didn't need such a detailed step-by-step.

Tuesday, April 01, 2014

Run Your Research Demo Site on the Cloud

Last week, Travis Hance and I spent hours wading through the many blog posts of the internet to figure out how to set up a simple website on Amazon EC2 using our Jeeves language, which runs on Python and C++. Because we want to spare you this trouble, we put together this definitive* post for people who want to run the simplest possible research demo site on Amazon EC2. We cover the following:
  1. How to set up an Amazon EC2 instance and SSH to it (to the install and configure whatever you like).
  2. How to set up and configure an Apache web server on your Amazon EC2 instance.
  3. How to set up your database and what to do if you want to host your own database on your Amazon EC2 instance.
  4. How to configure virtual hosts on your Apache web server if you want to use the same server to host different projects on different subdomains.
This post assumes you have experience using Django and testing things on your local machine. We're using Django 1.6.2 with Apache 2.4.9. These instructions are tailored for an Ubuntu instance, but they probably generalize as well.

Is Amazon EC2 for me?

The first thing to do is to determine whether you need to run your own EC2 server. Amazon's Elastic Compute Cloud (EC2) gives you elastic compute in the cloud. The biggest win is you can easily change how much capacity you have with minimal friction. It's also just a nice way to host servers without managing your own physical machines.

If you just need vanilla Django hosting, then you should probably find some other hosting service that can manage things for you. In our case, we wanted to use the Z3 SMT solver, which runs on C++, so we needed to run our own server.

Fellow CSAILers may be interested to learn that I have also set up a mirror site on our department's OpenStack cloud. This is free for people in our department and is useful if you don't need permanent cloud data storage.

How to set up a cloud instance.

Once you decide you want to set things up on EC2, it's pretty easy to get started. As of the time we signed up, there is a free Linux tier that gives you 750 hours at no cost. Amazon recently announced further price cuts, so the situation may be even more exciting by now. To set up your own Amazon EC2 server, sign up here and follow the i nstructions for launching a new instance.

SSHing to your EC2 instance.

In order to SSH to your instance, you will need to set the permissions of your servers to allow this. You can do this by going to your EC2 management console and adding your IP address (or all IP address if you want to live on the edge) to the "Inbound" list of allowed SSH addresses.

You'll also have to use an RSA key, which you should have generated sometime during the setup. Go to the "Instances" tab under your console to get the public DNS name. Then you can SSH to your instance:

ssh -i [location of your RSA private key] [username]@[public DNS name]

For Ubuntu instances, the username is "ubuntu."


Installing software.

Congratulations! You now have root access on an EC2 instance. You have the freedom to install software the way you would on any other machine. You can check out a copy of your code, as well as everything you need to run it, this way.

How to run a web server.

We'll be describing how to use the Apache HTTP web server for serving websites off your machine. To run your server, first download Apache and the WSGI (Web Server Gateway Interface) module for interfacing with Python programs.

sudo apt-get install apache2 libapache2-mod-wsgi

Once you have done this, you should be able to access the Apache configuration file in /etc/apache2/apache2.conf. This file tells a webpage how to interact with Apache, by describing for instance how paths should be resolved.

To make sure your Apache server knows about your demo project, first you'll want to set your Python path and alias your / path to wherever your WSGI configuration file is.

WSGIScriptAlias / /home/ubuntu/srv/testproject/testproject/
WSGIPythonPath /home/ubuntu/srv/testproject

You'll also want to add "Alias" entries for the static/ and media/ directories:

Alias /static /home/ubuntu/code/jeeves/demo/conf/static
Alias /media /home/ubuntu/code/jeeves/demo/conf/media

Finally, you'll want to add a "Directory" entry to set the permissions for the directory where you'll be serving your Python files from.

<Directory /usr/share>
  AllowOverride None
  Require all granted

To put these changes into effect, restart your Apache server:

sudo /etc/init.d/apache2 restart

You'll also want to change the permissions of your static/ and media/ directories to make them owned by the www-data group.

sudo chown -R www-data:www-data path/to/static/
sudo chown -R www-data:www-data path/to/media/

Now everything should work! Go to your hostname in the browser and see for yourself. Okay, so it is likely that there were some configuration errors and you get a "Bad request" or other error. When this happens, it is helpful to check your Apache error log, which can be found in /var/log/apache2/error.log.

Oh, and for Apache configuration files: a gotcha is that order matters, so for redirects you should put the most specific first and the most general last. A consequence of this gotcha is that if you have aliased '/' and you already have a Directory entry for '/', you need to move this to be after the Directory entry for the directory aliased to '/'.


Setting up your database.

If your Django application uses a database, you'll want to hook that up as well. Django has pretty good documentation for how to edit your for the database of your choice. You may need to install Python-specific libraries for interfacing with these databases. For instance, for MySQL you will want to install the python-mysqldb Ubuntu package. Once you have configured your database settings, running "syncdb" will set up your tables:

python syncdb

We found that our site ran much faster if we hosted the database locally. We followed the standard instructions for installing and running a MySQL database. For those who have never done this before, here is what you should expect to do:
  1. Install MySQL server.
  2. Configure your server by, for instance, setting a password for the root user.
  3. Start your MySQL server.
  4. Create a new MySQL database for use by your web application.
EC2-related: if you want to be able to access your database through SSH from other hosts (for instance, to back up your database from elsewhere), you will need to add a SQL entry to your security settings permitting access from the allowed IP address(es).


Getting ready for production.

Now you are ready to go! For your website to look the most professional, you will want to set DEBUG = False in your file. Once you do this, you will need to make sure the ALLOWED_HOSTS list includes your domain. An easy way to do this is to add the host '*' to the list.

And make sure the secret key you use in production is secret! 


How to host multiple projects on one server.

You might want to serve multiple demos, each with their own Django projects. There are a couple of ways to do this. One is to do the appropriate aliasing in your Apache configuration file for different subdirectories (For instance, If you go this route, you will have to make sure your redirects, includes, etc. point to the right place.

Another option, the one we took, is to use virtual hosts to put each project on its own subdomain. Here is how to add each new virtual host:
  1. Add a VirtualHost entry to your /etc/apache2/sites-available/[site name].conf file. For the main site the file is 000-default.conf.
  2. Enable this site:
    a2ensite [site name]  
  3. Reload your Apache configuration:
    sudo /etc/init.d/apache2 reload
Here is my VirtualHost configuration for that lives in my /etc/apache2/sites-available/ file. This post is getting long so I'm getting too lazy to explain all the parts, but you can see how I'm specifying paths, aliases, listening on port 80, and all that good stuff.

<VirtualHost *:80>
    DocumentRoot /home/ubuntu/code/jeeves/demo/conf

    WSGIDaemonProcess jconf processes=5 threads=1
    WSGIScriptAlias / /home/ubuntu/code/jeeves/demo/conf/
    ErrorLog /var/log/apache2/jconf-error.log

    Alias /static /home/ubuntu/code/jeeves/demo/conf/static
    Alias /media /home/ubuntu/code/jeeves/demo/conf/media
    Alias /logs /home/ubuntu/code/jeeves/demo/conf/logs

    <Directory /home/ubuntu/code/jeeves/demo/conf>
        Order deny,allow
        Allow from all

Note that if you want things to run on subdomains, 1) you will need to use your own domain (rather than Amazon EC2's dynamically assigned DNS) and 2) you need to make sure you have DNS entries for the subdomains (you need to tell someone which IP addresses you would like for these subdomains to resolve to). There are instructions here about setting up your own domain name with EC2. Instructions for mapping subdomains will vary based on domain manager. (For CSAIL domains created with WebDNS, you can create subdomains by editing your hostname file and adding aliases for your subdomains.)


A final word.

There are a lot of details (version numbers; deprecation; death) involved with these web things, but it is so satisfying to get everything working. And if at first you don't succeed, try, try, try again.

* This claim is intended to be tongue-in-cheek. I had told Travis that there was so much misinformation on the internet that I wanted to write the definitive blog post. He laughed because this sentiment surely motivates every other post out there.