What makes a good engineering culture

http://www.quora.com/What-makes-a-good-engineering-culture

One of my favorite interview questions for engineering candidates is to tell me about one thing they liked and one thing they disliked about the engineering culture at their previous company. Over the course of a few hundred interviews, this interview question has given me a sense of what good engineers look for and what they’re trying to avoid. I also reflected back on my own experiences from the past six years working across Google, Ooyala, and Quora and distilled some things that a team can do to build a good engineering culture:

1. Optimize for iteration speed.

2. Push relentlessly toward automation.

3. Build the right software abstractions.

4. Develop a focus on high code quality with code reviews.

5. Maintain a respectful work environment.

6. Build shared ownership of code.

7. Invest in automated testing.

8. Allot 20% time.

9. Build a culture of learning and continuous improvement.

10. Hire the best.

JavaScript: The new lingua franca of the internet

&yet has a great post today which is beginning to outline the the framework of a “Javascript” ecosystem for a complete web application written all the way through the stack with Javascript. The server-side models and DB structure usually have strong relations to the content being displayed in the browser. For a web store the item has a title, description, price, related items, etc. You have one application model written in one language, displayed in the browser in HTML with some fancy JavaScript to model the object again and handle all the changes. Why duplicate all this code over and over, in different languages? Write it once in backbone and be done.

&yet has taken the stack of

• backbone.js
• CommonJS
• Socket.io
• node.js

If you are looking at a seamless JavaScript stack, and already are using CouchDB you should also take a look at backbone-couchdb which is taking a different approach to the same complete JavaScript stack concept.

CoffeeScript: Why I’m never writing Javascript again

If you program in Javascript and haven’t heard of CoffeeScript yet, you are missing out. I’m not going to talk about installing it or the basic usage of it as the original documentation and a few blogs already have talked about it.

What I want to talk about is why it’s so amazing and why I can never write Javascript again. I’ve been programming Python for quite a while now and when  you do work on the web (like with Django) you will eventually have to deal with the browser and if you want to do anything beyond basic form processing you’ll need to deal with Javascript.

The maturation of libraries like jQuery has made life, infinitely easier but, Javascript itself is still a strange little language. It’s actually deceptively simple, it that any decent programmer can probably trial and error his/her way through a simple Javascript feature pretty quickly. This is actually one of the strongest features of the language, most people can write Javascript without actually knowing Javascript but, this lack of structure and ease of use is apart of it’s tricky nature. Once you begin to do complicated things the quirks of the language start to arise: undefined oddities, antiquated array manipulation, limited standard library, strange object models, and for me personally as a Python programmer the mess of braces and semi-colons peppering my code with distracting syntax.

CoffeeScript is essentially a combination of a Ruby-esque syntax and a healthy dose of just the good parts from Javascript. What you get is a fairly clean language that always “compiles” into very readable and workable Javascript. Which means anywhere you need to use Javascript: in the browser, in node.js, on the iPhone; you can use CoffeeScript.

I’m going to be writing a few posts playing with CoffeeScript in the future but, right now I’ll give you a few “out-of-the-box” examples of CoffeScript that isn’t just a basic example

Node.js chat server in CoffeeScript

Appcelerator iPhone Application in CoffeeScript

Why you should upstream cache your 404′s

There’s a great reddit thread going with the Onion’s Tech team on their recent transition to Django and this gem is buried in the conversation

Deep link to post

And the biggest performance boost of all: caching 404s and sending Cache-Control headers to the CDN on 404. Upwards of 66% of our server time is spent on serving 404s from spiders crawling invalid urls and from urls that exist out in the wild from 6-10 years ago. [Edit: We dropped our outgoing bandwidth by about 66% and our load average on our web server cluster by about 50% after implementing that change]

Amazing result for such a simple change. Bang for your buck optimizations are always the best ones.

Redis: Relations in a NoSQL world: Using Hashes

So just yesterday we posted a tutorial on how to use redis to store relational despite relations not being supported. Soon after we published the documentation on the new redis hash type went online. Now hashes by themselves aren’t exactly relations but, more so an object field store. Extending the same concepts from our first article in namespace utilization and using hashes we can accomplish the same thing in a more formal fashion.

We will repeat the same exercise from the first article, creating a username password store, using hashes.

Read the rest of this entry »

Redis: Relations in a NoSQL world

In the first article in our series on Redis we talked about how to get started and the basics of the simple data structures that are available in redis. The simple structures are good for basic operations like storing strings and keeping counters but, using it for anything more complex requires relating one set of data to another. At first glance this is a bit of a problem since redis by design is a flat dictionary with no relations but, with a bit of application code and adherence to some mental programming standards you can build some quite complex applications using redis.

Read the rest of this entry »

Getting Started: Redis and Python

So if you have been following NoSQL movement, the migration of some types of data to non-relational datastores has recently picked up speed. For web (and other developers) this has lead to some impressive engineering resources developing some amazing tools being open sourced for the world to use. One that caught my eye recently has been Salvatore Sanfilippo’s redis which has been taken under the wing of VMWare, solidifying and validating the great work that Salavatore has done making redis an amazing tool in any developers arsenal.

A very simplified explanation of redis is that it is an in memory key-value store like memcached but, it is persistent on disk, unlike memcached which is volatile. Along with being disk-persistent redis also supports some basic data structures like lists, sets, ordered sets, hashes, and of course basic key-value string storage like memcached. Redis, with disk-persistence and basic data structures, remains blazing fast with published benchmarks of 110,000 SETs per second, about 81,000 GETs per second.

This post is the start of a series of articles on redis for Python programmers. A prerequisite for this is going to be some basic Python knowledge, which if you haven’t used before I highly recommend the free web book Dive Into Python. This is going to be a simple overview of the basic data types and usage for Python programmers and we will slowly progress into more complex usages, so if you haven’t done anything with redis before this is a perfect start.

Read the rest of this entry »

Tutorial: Writing our first views

So far in the tutorial we’ve started our project, setup the database, enabled the admin interface, created models for our blog, and we just did a brief tutorial on Django’s ORM and DB-API. Now let’s look at getting data out of our database and onto the web page using views.

This section will be a bit short because we won’t really be using templates, which we’ll cover in the next section. We will just be looking at how the urls.py file and the views.py file interact and how we can use what we learned in our ORM tutorial not in the shell but, in our application.

Read the rest of this entry »

Tutorial: Learning the DB-API and ORM

So far in the tutorial we’ve started our project, setup the database, enabled the admin interface, created models for our blog. We’re going to slow down on actually developing our blog and talk about exactly how we get to the data we’ve stored in the database so far. The Admin Interface is great but, it doesn’t provide good programtic access to the data. Let’s open up a python shell but, we’re going to do it a special way when working with Django. From the command line in our root project directory (blog/)

$ python manage.py shell
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>

Now this might look like a normal Python shell because, well it is. We’ve just loaded up some stuff in the background like path information to make our lives a bit easier. Now we have two models that we created in the application “main”. Let’s load those up in the shell.

Read the rest of this entry »

Tutorial: Create our models

So far in the tutorial we’ve started our project, setup the database, enabled the admin interface and now we’re ready to start to define the database for our project, a simple blog.

This is where we will start working with the models.py file in the “main” application directory (blog/main/). The models.py file is a definition file where we tell Django what all of our database models are. Let’s start with some categories for our blog entry.

from django.db import models
from django.contrib import admin

class Category(models.Model):
    Name    =   models.CharField(max_length=255)
    def __unicode__(self):
        return self.Name
admin.site.register(Category)

Let’s walk through this real quick since this was a lot of code real quickly. The first two lines we are first importing Django’s base class “models”. This is what we’ll subclass all of our models off of. The next line imports the Django admin object which we will use to include our model in Django’s admin interface.

Read the rest of this entry »