How much experience does a Computer Science Degree provide?

Many companies employment requirements include a computer science degree or "Equivalent Experience".  In reality, the "Equivalent Experience" of a college computer science degree is much lower than employers believe.

Most times companies quantify equivalent experience as an amount of time, which is 4 years.  Just because school normally lasts for 4 years, does that mean an individual gains 4 years worth of computer experience from a computer science degree.

  A core component of the US bachelor degree is a humanities education.  This comes in the form of required courses in art, english, history, philosophy, mathematics, social studies and often contain a physical education aspect.  The vast majority of 4 year programs require courses from the above disciplines, in hopes of creating "well rounded" students.  These courses are required even in technical programs.  

I looked at the requirements for a computer science degree at UMBC (major requirements).  70 computer science and math credits are required for a degree.  In my browsings, I have seen anywhere between 70-90 credits required in the field.  For calculation purposes I will assume 80 credits required.

80 credits total / 15 credits per semester (average) = 5.3 semesters of school 

A semester is roughly 3.5 months of school.

5 semester * 3.5 months per semester = 17.5 months 

Um. This is 1.5 years of 15 / per week instruction?

84 weeks (1.5 years) * 15 hours of instruction per week = 1260 hours of instruction

1260 hours is 31.5 40 hour weeks, significantly less than 1 full year.

Django Request/Response Cycle, How Requests Die and Responses Are Born

This summer I decided to start contributing to django.  Looking through the easy picking tickets, I realized it would be beneficial to develop an understanding of some of the core components of the django framework before jumping into tickets.

I plan on writing blog posts about the internals of django, starting with today's:  What is the path of a request through the django framework, and what is the path or a response out of the framework.

Lets begin with describing the entry point, and all major functions that are called for a request/response.  We can then elaborate on the important functions.  Django uses the WSGI standard to interact with web servers, there is a lot of information available about this standard on the web.

Basically, django will be returning a callable application with the signature and return value the same as

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

When deploying django the webserver needs to know of the location of the wsgi.py file that belongs to your project, this is where it retrieves the callable application (like the one above)

If we look in the wsgi.py file where django that is included with django we see:



from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Ah HA!

So lets start tracing how our application is built!

1. get_wsgi_application is a public wrapper function that returns a WSGIHandler instance.
    Notice how WSGI handler has a lot in common with the above sample application:
   
    Django calculates the correct response status codes and headers and calls the `start_response` function that was passed into the app (from the webserver?) when the application is called.  It then returns the response.

2. So we are already at a dead end! Django returned our app to the webserver.  I don't know when the webserver actually calls our app or what start_response actually does, and we don't need to, we can just trust that the wsgi modules/wsgi servers do things right!  The response is calculated when our application (WSGIHandler instance) is called.  This takes place in WSGIHandlers.__call__.

3. The first thing WSGIHandler does is attempt to load middleware that is registered in the settings.py file.

4. The next significant action is the instantiation of a a new WSGIRequest

5. The last main action is retrieving a response for the new request object in get_response.  This is where the bulk of the request logic comes into play.  This function is responsible for calling all middleware hooks at the correct times, and for resolving a url to a view function, and executing that view function.  This is where those nice error messages of your view did not return a HTTPResponse object comes from!

This has been a quick, pretty high level architecture overview, of which main functions django calls to turn a request into a response.  There ARE other things going on like emitting signals along the way, and a couple config options to prepare a request for processing, but this is pretty much the gist of it.

Loading jQuery plugins using require.js and backbone.js

I recently began using backbone.js through the package grunt-bbb.  I ran into a little bit of trouble loading external javascript libraries through require.js, specifically jQuery plugins.


For anyone new to backbone.js development, I would strongly advise you check out grunt-bbb.  It is a framework and build system for backbone.js.  It provides commands to generate scaffolding and for building/testing/linting your project.

Below are instructions specific to grunt-bbb, but can easily be adapted to any project using require.js.


require.js configuration provides a `shim` option. According to the docs:

Configure the dependencies and exports for older, traditional "browser globals" scripts that do not use define() to declare the dependencies and set a module value. 


This allows you to define what order packages are loaded in.  This is necessary because your jQuery plugin relies on jQuery.

In your require.js config it is important to provide both the location of your plugin and specify that jQuery is dependent on your plugin

The above code points to where the js plugins are located (without.js extension) and registers them as

 dependent on jQuery.

Now all you have to do is load the scripts in your module's define statement:





define(["app", 'prettyPhoto', 'jqueryui' ], function(app) {

});

The plugins are loaded by the key you define in `paths` object! 

The Cult of Twitter

Twitter is a very unique product.  It comes as no surprise that it has a unique relationship with its users. This relationship is really shines when the service goes down.  The twitter fail whale is iconic.  Little blue birds trying to carry a whale.  As someone who doesn't even use twitter, I have seen this image many places, at many times.  What is most intriguing to me is how Twitter branded themselves to be so cute.  By using imagery like that found on the fail whale, they have taken the absolute worst possible thing that could happen to a web service (ie. it not functioning) and turn it into something cute and tolerable.  

When twitter goes down, the site is filled with the image of small blue birds carrying a whale.  The second twitter goes down the internet blows up with articles about twitters outage.  This is no different then other mega services like gmail or facebook.  The difference is how users react to it.  No other service has this relationships with its customers.  Twitter failing has become "cute" because of the fail whale.

The reason people can interpret this as cute, is because twitter is not a necessary service.  It is a leisure service.  Even though companies can indirectly use it to gain customers or advertise, it is still primarily recreation.  This becomes apparent when, by contrast, a service like gmail goes down.  Personally, when gmail goes down by work stops.  I don't even receive that many emails per day (probably only a few per hour) but when gmail goes down I get up from the computer, because it has become synonymous with work.  I don't think twitter will ever have this relationship with its customers.

What do you think?  Do you get angry when you see the fail whale, or is something you can shrug off until the service comes back up?