The Future of the NCAA

About two years or so ago, I’m a little fuzzy on the date in particular, I made a prediction to a friend (or someone in my family, or a coworker, two years ago is a long time to remember specifically). Because of this, and because I want to get the credit when I’m correct (or be liable if incorrect), I’ve decided to write down this prediction:

By 2033 at the latest, the NCAA will not exist.

They’re making too much money and not compensating the people who are providing the product and it needs to end. The NCAA as an organization is too big, too unwieldy and too stuck in the mud with their backwards thinking as to what college athletics is to continue to exist.

Gone are the days when students decided to try out for football in the fall, and then decide to play baseball in the spring as well. What we have now are specialized players who are stuck in college because either they’re forced to (by the NBA) or because there isn’t a better alternative (like an NFL minor league).

Anyone who thinks the players on the football and basketball teams are “amateurs” who should just be happy with getting an education are lying to themselves. There is nothing amateur about their schedules, amount of time they spend practicing and preparing.

There are a bunch of issues that need to be figured out and debated before this can happen. These are just some of the questions that need to be figured out before we can fix the issue, and getting to a correct answer for all of these is going to take some time.

  • What about the non-revenue sports?
  • Are  women’s sports players paid even though they aren’t necessarily generating money?
  • Are better players compensated more for their skill compared to the lesser skilled players?
  • How can the smaller schools compete with the larger ones if players can always get more money by going to the larger schools?
  • Do you just give them money? Or is compensation restricted to certain things like housing and food?

Though I’m confident that the NCAA won’t exist by 2033, I’m not sure what exactly going to cause its fall. But here’s a stab at what I think is going to happen, at least in some form.

1) The NCAA will slowly start bending on rules regarding compensation starting at the conference level.

2) The NCAA won’t move quickly enough on this and either the conferences, or the high profile / big money schools will get together and create a new organization where they get to decide what the rules are. In one fell swoop, the NCAA will be gone.

So here’s hoping that this page from the internet will still be around in 2033, and here’s hoping that the NCAA will not.

Ask Questions to Humans

Quick mention to another site I have out there. Ask questions to Humans. I decided to take a new approach this time and not do the “normal” side project for a web developer. Instead of actually building a site with some sort of framework, I used only tools that someone with a much less technical background could build. The entire site is static, being served from s3. The form is powered by Wufoo, and payments are by Stripe. Sure someone is going to need knowledge of html and other web services, but I wrote no server-side code for this project. I’ll have more thoughts on that later because it’s such a mental switch for me to not immediately whip out a new rails project, but in this case, for just a fun website to put up, being able to finish a beta version in two nights was key.

Taking advice from tattoos

Personally, I’m not a fan of needles, so I haven’t even considered getting a tattoo. If I were so inclined though, I’d listen to a piece of advice that I read somewhere on the internet a while ago. I can’t remember it word for word, but it went something like this:

If you’re thinking about getting a tattoo, take a picture of it and hang it in your bathroom. If in a year, you’re still inclined to get the tattoo, then go ahead and do it.

This advice mirrors very well to all the different side projects that I have brewing in my mind. When I come up with some “brilliant” idea that I want to work on, I’ll use some low overhead method to make sure I’ll still be interested in the future  before writing any code. If after a week or so, I’m still excited about the project, then I’ll go ahead and get more advanced.

This worked really well for my relatively new homebrewing hobby. With significant overhead in equipment, I wanted to make sure that this wouldn’t be a one and done hobby (and it wasn’t!).

The time frame of consideration isn’t important, but it’s key to just make sure that you’ll still be interested in it months down the line.

Asking for help

Generally, and I’m pretty sure exclusively  so far on this blog, I’ve written about technical topics. This time though, I’m going to switch it up and write about an issue that I’ve been dealing with at work — asking for help.

Being a relatively inexperienced developer working on a dinosaur of an app (still running rails 2), I run across a bunch of different issues everyday. Most of these issues could be solved by the more experienced devs in minutes. Turns out it helps to have years of experience working with the app in question. My issue is to try to balance the amount of headbanging I go through against how annoying it is for those guys to stop what they’re doing and help me.

Now there isn’t an exact answer to this question, but I have come up with a one way to know if it is finally time to call in reinforcements if I can’t come up with the solution on my own (which is still the desirable outcome).

All I do is imagine that the person who I’m going to ask the questions is already standing next to me and I have to justify all of the things I tried and make sure that I have an answer to all of their questions. Obviously this doesn’t always work. If the issue is truly one that you don’t know, you can’t phantom prepare for, you aren’t going to get it right. But making sure you go through a phantom question session makes sure you’ve covered all your bases, as well as letting the other guy know that you’ve given a good effort.

 

Favorite Vim Commands

My current vim syntax highlighting (maximum awesome) shows a few things that my coworker’s editors don’t. Mainly showing tabs that other’s have typed (since maximum awesome expands tabs to spaces so they won’t show up) and trailing whitespace. I’m a huge fan of this since it makes sure that the code I’m writing doesn’t have unnecessary characters.

But working on old code that’s been written and rewritten by a bunch of different people who really had no interest in keeping to syntax standards, these show up as ugly splotches on what should be a clean vim window. Luckily, as is often the case, there are two vim commands that can turn a mess of a file into something a little better.

:retab

Retab works to change all the tabs in the file, and “redoes” them in whatever format defined in your vimrc. If you’re using maximum awesome, that would be :expandtab, which, like I mentioned, expands a tab into the corresponding number of spaces (which is set to 2 in maximum awesome). So :retab changes all the garbage tabs into 2 spaces.

:%s/\s\+$//

A little funking syntax, but this command (found by googling) finds and removes all the trailing whitespace.

With these two commands, and a little more formatting to make sure that the indentions are correct, a file that looks confusing because of poor syntax becomes something much more understandable. And it helps out everyone in the future who has to work on the file. Both outcomes make it worth the time and effort.

Deploying a node application to Nodejitsu

tl;dr – Nodejitsu + custom MongoHQ database are really good to get something out the door.

Running and dealing with your own server is, let’s be honest, a pain in the ass. I don’t want to be dealing with that initially (maybe ever really) when all I’m trying to do is test out an application. With all this in mind, I looked into using a PaaS to deploy my little application I’ve been working on.

Relatively arbitrarily, I ended up going with Nodejitsu (over others listed here because, why not. I needed to pick one and this seemed decent. I also like that it was node specific, unlike Heroku for example. Means that they care only about node applications. And at least off the bat, I’m happy with that decision.

Following this guide, I was up and running in under 10 minutes, most of that time being server setup time on their end. I was able to pick a subdomain, and hit my landing page and see the app deployed on the web. Considering I had never used a PaaS before, I was more than happy with the result. Unfortunately, I hadn’t set up a database yet, so actually registering wasn’t an option.

Nodejitsu provides a database creation service from both their command line interface, as well as a web interface. To start, I created a mongohq db from the web, and copied the uri into my configuration file. I’ll take a second to say that I was also surprised at how the NODE_ENV variable was already set to production. So since I had my config file setup, I didn’t have to do anything special. Also, Nodejitsu has an interface where you’re able to set any environment variables you want from their website.

I tried connecting to their database using the credentials that Nodejitsu gave me, but the server seemed unresponsive. After trying a few different ways to connect, I ditched going through their db management, and went straight to Mongohq itself.

Over there, I was able to create a database and a prod_test user along with a password. I was able to connect to that db right away with those credentials, so I put the new uri into my config file, redeployed, and 20 seconds later, I was interacting with a full database!

So with about 30 minutes of fussing around, I had a fully db backed node application running on the internet. This is way less time and complication than I was expecting considering I had tried to run my own server up until now.

Environments in a node.js application

One of the important issue in all web applications is having different environments for different uses. In particular, you’ll probably want to have different environments for development, testing, and production. I ran into this issue when I first started writing tests for an app I’m working on (sidenote: turns out testing is fun). At the time, the database connection was going to the development db, which isn’t what you want for contained testing. After searching around for a while, and after finding a bunch of different ways to handle the configuration, I settled on the following implementation.

var production = {
    database: {
         url : 'mongodb://localhost/worldpic'
     }
};
var development = {
    database: {
      url : 'mongodb://localhost/worldpic'
    }
};
var test = {
    database: {
        url : 'mongodb://localhost/worldpic_test'
    }
};
module.exports = function () {
     switch(process.env.NODE_ENV){
        case 'production':
             return production;
        case 'development':
             return development;
        case 'test':
             return test;
        default:
             return development;
     }
};

This file I called config.js and I put that in the config folder (so config/config.js). The other thing you could do, and something that I might in the future, is split the environment variables into their own files in the config folder and require them in the config.js file.

With this done, you can get a config object by running in app.js (or server.js if that’s your style)

var Config = require('./config/config')
var config = new Config();

From there, you can access the desired database url by running

config.database.url

The same syntax would be used for any environment variable that you might want, such as external api keys.

The last part is actually setting the NODE_ENV variable. This is done from the command line when you run node or mocha (for testing)

NODE_ENV=test mocha

for example, or

NODE_ENV=development npm start

You don’t actually need to specify the env if you’re using development since it defaults to that, but being specific is always good.

And that’s it! Structured configuration for node that’ll make your life way easier.

Developer, Golf on the Mind writer, Packers, Brewers, Bucks fan