Posted on
Aug 26, 2011
by: Stuart Ballard

A Veritable Cheezcopia of Internness

I arrived at Cheezburger 3 months ago today. My last day will be a week from now. In these few weeks, my technical skills have found fertile ground to take root and grow. The excitement of actively contributing to and influencing a real and epic vision has shown me how broadly I can apply myself. While I’ve been programming professionally since I was 19, the environment was intensely academic, so my knowledge limited me more than my ability to implement. Having goals which are rather less grandiose than transforming the field of computational metrology has allowed me to innovate with purpose and direction.

The Rabbit Hole was a deceivingly simple feature. The only web server I had previously worked on supported only GET requests, and was written in C. Very abruptly I got to write C# code in .NET framework using SQL to find pointers to really funny stuff and asp/javascript/css/html to provide it in an endless stream (all the while wondering what these strange things were). For me, creating an infinite scroll effect, randomizing display order, and customizing the page layout were all just ways to learn to use these new tools. Later I learned I had actually done a few clever and inventive things. The Rabbit Hole is finally open to the public, reachable from the site directory. On average, users have viewed about 60 lols in the Rabbit Hole before leaving, but with fully half of users only viewing one, there are quite a few who have already viewed thousands. It was my goal to waste your and others’ time as epicly as possible. I think I’ve succeeded.

Amongst the most rewarding experiences I’ve had is working on a pre-existing dynamic code base with a large team. Previously, I would work with (maybe) one other person, and usually build something from scratch. I still really don’t know how the whole thing works, but I understand how I can make it work. That has changed my perspective on development, and opened worlds of projects to me.

Apart from my technical advancement, I discovered that the business skills which pissed off my superiors to no end while I was in academia are actually valued at Cheezburger. Successfully pushing the build process redesign during CheezDevCon was deeply validating for me, and I think reflects extremely well on Cheezburger–as an intern, it was pleasantly surprising to find that I could actually impact the company in such a short time.

This summer has been truly transformative, and I’ve tried to exploit it for all it’s worth. There is, I’ve found, too much to gain. I’ll be back in Seattle–if not to work for Cheezburger, then at least to express my gratitude. Thanks Burgers!

 

No Comments | Leave a comment!

Posted on
Aug 9, 2011
by: jacob

Cheezburger DVCS Workflow: A History

In the beginning was the Code, and the Code was with Subversion, and the Code was Subversion. Cheezburger was with Subversion in the beginning.

Subversion was good, but, as a globally distributed team, Cheezburger really needed a way for developers to work offline, without having to coordinate with each other. Somebody ran an import script, and just like that Cheezburger was on Mercurial. There was one repository, “Current”, on the Kiln server, and we released by tagging and shipping from that same repository.

Eventually we realized that sometimes features take longer than a single release cycle to create, but we still want to push them to a staging server or show them to someone else. Using Kiln, branching was supremely easy, so we created branches for long-lived features and teams. The central integration repository was called Current, and we would tag and release from that repository.

A new problem arose with this system; namely, that it wasn’t clear which changes had been tested by our automatic continuous integration system, so in May 2011, we added a new branch called “Approved” that the CI system would push approved changesets to, and we shipped from there after tagging Current.

This system worked pretty well for a while, but every once in a while, a team would want to push a gigantic merge with old changes from their branch into Current in order to release. Then, the CI system would detect a failure, or the QA team would identify a fatal flaw, or the team would get cold feet for some other reason. Unfortunately, all the other teams would do the sensible thing and merge with Current, so their branches were also infected with the unreleasable code. Changesets got backed up behind the misfired release, tempers flared, developers threatened violence on lolcats. The first time this happened, promises were made that it wouldn’t happen again.

Then it happened again, with predictable results. Lolcats flared, developers got backed up behind the misfired release, and changesets threatened violence on tempers. A company crisis was declared, and a Serious Meeting was held. There was talk of separating the app into siloed services, which is certainly a viable solution, but would take a very significant amount of code and work. Eventually, the team decided on another change to our repository layout that would avoid this infuriating problem.

The rules of the system are pretty simple:

  1. Don’t pull from PendingTests, pull from Released instead
  2. Don’t push to PendingRelease or Released — let the tools automate this

Current had two functions: it was a place to put code that was about to be released, and a place to synchronize with other teams’ code. This new workflow has an identical number of entry points, but it separates the release functionality from the team integration functionality.

PendingTests and PendingRelease are both disposable: if unreleasable code makes it into either of these repositories, they can be deleted and recreated as clones of Released.

This workflow also imposes a natural lock on release: if there are changes waiting in PendingTests, Mercurial won’t let you push until you pull those changes down. But you can’t pull any new changes until the release is complete, because of rule #1. As a nice bonus, Kiln has a page that shows you related repositories. If you visit PendingTests and check out the outgoing changes to Released, you can see who is releasing, and exactly what their release will include.

Our release process has grown more complicated over time, but these complications actually allow us to develop code independently from each other without stepping on one anothers’ toes. In addition, we have been able to incrementally grow an automated testing system, which lets us move ever closer to our goal of continuous deployment. I’m totally jealous of IMVU’s nine minute release pipeline — ours takes over an hour: 38 minutes in continuous integration and 30-45 minutes to release. There’s clearly more room for us to improve! Let us know what your team’s workflow looks like in the comments.

 

Posted in Development Practices | No Comments | Leave a comment!

Posted on
Jul 20, 2011
by: lorenichc

The Myth of “Too Old to Learn to Code”

I was having drinks with a friend the other week when we started talking about our jobs.  He likes his position at a tech company, but he’s not a developer (though he works a lot with developers).  He’s had an interest in becoming a developer himself for a number of months, but when he casually mentioned this to his boss was told, “You’re too old.”  I asked him how old he is.  “Twenty-six.”  I know he’s not a rare example, as I’ve had similar conversations with 30- and 40-somethings over the years.

Now, I’ve read a number of books about learning how to code, and none of them said anything to the effect of “Please – if you’re old enough to legally drink, put this book down and take up needlecraft.  Your brain just won’t be able to process anything in here.”  But it’s a myth that’s out there – perhaps indirectly perpetuated by the press that the Zuckerbergs of the world get when they create the newest startup-of-the-moment while barely out of high school.  But here’s a secret – you don’t need to have good knees, a decent throwing arm, or be able to kick a ball over fifty yards to get into coding.    In fact, can you believe that some developers are actually out of shape? (That was a joke.)  No, all you need is ambition, interest, and a bit of smarts.

So, regardless of whether you’re in your seventies and want to create a new Firefox extension to help manage your news feeds, or an over-the-hill twenty-something that wants to make a career change into coding, start learning SOME technology and get building.  If you don’t care which technology, here are a couple of resources that will get you introduced to a few more popular web application solutions.

Good luck, and have fun!

 

Posted in Developer Tips and Tricks | No Comments | Leave a comment!

Posted on
May 17, 2011
by: scottporad

Round Peg, Square Hole: How to Know If a Developer is a Good Fit for Your Team

Over the last few months, we have been recruiting developers, and we’ve started to get a sense for the type of developer who is a good fit for our team.  These attributes probably apply for developers at most web startups, so I wanted to share them with you.

Before I get into it, the most important thing to know is that technical skill is a threshold requirement.  The assumption is that any person who is a fit for our team will have the relevant technical experience to do the job.

Beyond that, here’s what we look for in someone as a good fit…

Passion
One of our goals is to create a team of amazing developers, and one of our beliefs is that nobody is the best in the world at something they don’t care about deeply.  So, we look for evidence that the developer is passionate about computers and really loves programming.  Examples of this are things like open source activity, cool side projects, non-mainstream programming languages, etc.  (Any programming experience before college is a good indicator as well.)

Motivation/Self-Directed Worker
As a small company, we don’t have layers and layers of management.  This is great, because it creates a terrific work environment.  However, it also means that even individual contributors need to be able to get a project to completion and can work without being prodded.

Agile
We are team of passionate developers that implement the most modern and progressive web and software development practices. We are an Agile/Scrum shop that embraces iterative development, test automation, continuous deployment and DevOps.  That’s not a fit for everyone, so people with that type of experience tend to like it here.

Cheezburgler
Working at Cheezburger is not like working anywhere else in the world. (Honestly, it’s a little bizarre.) So, we need to find people who understand our culture and we look for evidence that the applicant is either a Cheezburger user, a fan of our sites, knows about our sites or has read the dev blog. Basically, did the applicant write a cover letter specific to us or in some other way show that they care about working at Cheezburger?  Or, are they just blasting out their resume to any company with an open chair?  Instant bonus if their cover letter is written in lolspeak.  (Just kidding.)

Start-Up
Cheezburger is doubly unique: not only do we have our own, special culture, but we’re also a small, startup.  Startups are entirely different beasts than major corporations, and the experience doesn’t always translate.

Consumer-Facing Web Sites
There are as many types of software developement as there are flavors of ice cream, and we happen to work on a specific type: a high-traffic, consumer-facing web site.  Yes, a person who has been working on desktop apps can work on web sites, but the environment is different.  We’ve found that people with previous experience in this environment tend to be better fits.

Hard-core
Great developers love challenges and love working on hard things.  So, we ask this question: have they done anything that other developers would think of as hard?  This doesn’t mean they have to come from a job where they only coded in assembly, but a little bit of assembly experience does improve the code a developer writes even when they are coding in a high-level language.

Different
There is strength in diversity, so we don’t want a team of carbon copy robots who all know the same tricks.  We want a strong fabric of developers who each bring something to the table to make us better as a team.  So, we ask, is the candidate different enough from the other people on the team to help give a broader more open perspective to development? Does this person add experience and capability to our team that we don’t already have? Do they have some skill or experience that helps us round out a weakness?

Does this sound like you?  If so, join our team at http://jobs.cheezburger.com.

 

Posted in Building Great Teams | No Comments | Leave a comment!

Posted on
May 6, 2011
by: james

Introducing the Cheezburger Better Database Schema Manager

Cheezburger is pleased to announce the release of its database schema management/migration software: Cheezburger Better Database Schema Manager or CheezBDSM.

The CheezBDSM is the schema management solution used by Cheezburger Network to handle database migrations on our production site handling millions of users per month. Our production database is over 100GB containing information on 15 million assets for over million users. We deploy to production about once a day, and this is the code used to manage all those database migrations. It has served us well.

We are excited to be open-sourcing this bit of code and contribute back to the community that has served us so well. We are also super excited to be releasing this during Alt.Net Seattle 2011 conference. We will be hosting a session during the conference to help those interested get started with BDSM or answer any other Cheezburger-related questions you may have.

Github Repo: https://github.com/cheezburger/Cheezburger-BDSM

 

Posted in Open Source | 1 Comment | Leave another comment!

Posted on
Apr 29, 2011
by: Aimee L

MAMP Mayhem! Updating the MAMP Root Password

The Situation

Huh?
I use MAMP as a part of my local development set up and I like to use a common root password between the different computers I use so that things are a little less confusing to keep track of. MAMP uses the default password ‘root’ for the root user account, this gives me the heebeejeebies, so I always like to change it.

Sadly, MAMP was a real bear when it came to updating the root password and there wasn’t much documentation out there on how to fix it. Updating the password wasn’t an issue, but getting phpMyAdmin to work after the update was. I finally got things to work and this is how I did it:

The Solution

Challenge Accepted

  1. Start MAMP
  2. Go to the phpMyAdmin page
  3. Go to Privileges and edit ‘root’ to your preferred password.
    note!     If you try to restart MAMP and get to the phpMyAdmin page at this time it will not work. It is best to leave both the Apache and MAMP servers running until you finish updating all of the files.
  4. Edit the following files with your new password (search for ‘root’ and the items you replace with your new password will be obvious, it will look like the code below):
    $cfg['Servers'][$i]['auth_type'] = 'config'; // Authentication...
    $cfg['Servers'][$i]['user'] = 'root'; // MySQL user
    $cfg['Servers'][$i]['password'] = 'thisiswheremypasswordis'; // MySQL password...
    • /Applications/MAMP/bin/phpMyAdmin-X.X.X/config.inc.php
    • /Applications/MAMP/bin/mamp/index.php
    • /Applications/MAMP/bin/stopMysql.sh
      note! Don’t be confused by the ‘p’ prior to the root password, you only replace ‘root’ with your new password. The ‘p’ should bump right up against your new password. This applies to all files with this syntax.
    • /Applications/MAMP/bin/checkMysql.sh
    • /Applications/MAMP/bin/quickCheckMysqlUpgrade.sh
    • /Applications/MAMP/bin/repairMysql.sh
    • /Applications/MAMP/bin/upgradeMysql.sh
    • /Applications/MAMP/bin/mamp/English/index.php
      note! It is not necessary to update this file, I recommend avoiding updating this file unless you plan to use the server locally only. This is simply your start page file and I use it as a way to remind myself what the new password is. You can always replace the password examples with hints to stay more secure, or just leave it be completely since it will not change functionality.
  1. Edit the /Applications/MAMP/bin/phpMyAdmin-X.X.X/index.php file below the line containing, “ * @uses $GLOBALS['cfg']['Server']['user']” by adding the following:
    * @uses $GLOBALS['cfg']['Server']['password']
    note! Do NOT replace ‘password’ with your new password for this step, it’s simply telling MAMP to use the password you just set up everywhere else.
  2. Stop your servers.
  3. Restart your servers.

The Results

FYea!
That’s it! If you update the password in this manner, you will not only get rid of those MAMP error connecting messages, but you will be able to access phpMyAdmin again using the new password.

Don’t be surprised by the new set up, once you change the root password, phpMyAdmin will require that you log in each time you open the page. Use the new password that you just added to the files. When you go to the phpMyAdmin page, you will see a login screen instead of the phpMyAdmin home page.

The Problem Solvers

Problem Solved
If you can’t get to phpMyAdmin to change the default ‘root’ password, don’t fret, you can also do it via terminal using the following code:

$/Applications/MAMP/Library/bin/mysqladmin -u root -p password NEWPASSWORD

If MySQL won’t restart, it probably didn’t stop properly when you stopped and restarted the servers. Quit MAMP and use the following code in terminal, then start MAMP again and it should start up without issue.

$sudo killall mysqld

You will need to enter your operating system administrator password to complete the command.

Pro-Tip: I tend to do terrible and risky things that obliterate my local server set up on a regular basis, so to save time, I created a project in my editor (TextMate) with all of the files that need to be updated so that I can reference that and update extremely quickly.

Run into any snags I didn’t cover here? Have additional pro-tips or suggestions?
Feel free to comment below and I would be happy to include them in this post.

 

Posted in Developer Tips and Tricks | No Comments | Leave a comment!

Posted on
Apr 21, 2011
by: John Clayton

Who’s On Port 80?

Here at Cheezburger we run on two main platforms – ASP.NET powers cheezburger.com, and WordPress powers all of our content sites. This requires us to run both locally to develop against. A common setup on the team is to use IIS Express or Cassini on any arbitrary port to run the ASP.NET applications, and WampServer on port 80 to run WordPress.

This has worked well…until today when Apache decided that it wouldn’t start.

tl;dr

If Apache won’t start on Windows, you don’t have IIS installed, Skype isn’t being dumb, and you have the Web Deployment Tool installed, then try disabling the Web Deployment Agent Service.

Not the usual culprits

I typically do not run full IIS on my dev machine due to port contention like this and using IIS Express is just easier.

Windows Features

A quick check of the Windows Features confirmed that it was not installed.

The next most common issue is that for some dumb reason Skype will claim ports 80 and 443 with its default settings. I’d just upgraded Skype, so it was worth checking.

Skype Options

Nope, that option stayed unselected after the upgrade.

Digging deeper

Having ruled out the most common programs that could claim port 80, I downloaded one of the many terrific Sysinternals tools, TCPView, which shows detailed information about all open TCP connections on your system.

TCPView

Now we know that the port is being held by the system…not exactly something we can simply whack on the head. Unlike the many svchost processes running on your system, Process Explorer can’t tell you what all is running in System.

WampServer also has a utility for checking the status of port 80.

wamp

That gives us a little more detail – even without IIS installed HTTP.SYS, the kernel-mode HTTP driver, is still listening for HTTP requests.

Jackpot!

Just as I was about to give up and just change Apache’s port, Scott Hanselman posted an article about using SSL with IIS Express, including reference to the netsh command. Scott was using it to add an entry for HTTP.SYS, but maybe it could show me what is behind the port snatching?

netsh http show urlacl

netsh

Looks like the Web Deploy agent is what is preventing Apache from using port 80. According to Programs and Features, I just happened to have gotten an updated version today as well, probably from the Web Platform Installer while getting the MVC 3 Tools Update and other items updated the same day.

programs features

Rather than uninstalling Web Deploy I opted to disable the Web Deployment Agent Service, which had been set to start automatically. After making this change Apache is now able to start!

Given this appears to be new with the latest version of the Web Deploy Tool, I’m not sure what ramifications there may be from disabling this service locally. My best guess is something to do with WebMatrix.

 

Posted in Developer Tips and Tricks | No Comments | Leave a comment!

Posted on
Apr 14, 2011
by: Crystal Beasley

5 Absurd Things About Working at Cheez

  1. The mascot for our management tools is called Rumples. Rumples is a nice guy. He hangs out and drinks coffee and keeps us entertained by his continual antics like pooping on the carpet and saying embarrassing things.
  2. We refer to coworkers as “burgers.” The group who work in Seattle are “Seattle Burgers” and so on and so forth.
  3. We hire a lot of hilarious people. Sometimes they write on our whiteboards and walls.

  4. Customer service requests and office signage comes in the form of LOLs

  5. Yes, it really is as fun as it looks!!
 

No Comments | Leave a comment!

Posted on
Apr 14, 2011
by: scottporad

Hello World!

On behalf of the Product Development team at Cheezburger, welcome!  We’re the team of developers, designers, testers and product managers that create the Cheezburger web sites!

In this space, we’re going to pull back the covers and show the action behind the scenes.  Yeah, yeah, yeah…from the outside, we look like a simple network of funny web sites.  But, on the inside, from a product and technology perspective, we do a lot neat things, and have a lot of fun doing them, so we wanted to share that with you!

If you want to know more about product development at Cheezburger, don’t hesitate to contact us and, if appropriate, we’ll reply on the site.  And, if you want to join our team, we’re always hiring, so check out our job listings.

 

No Comments | Comments Off

 

Powered by the cute and insane WordPress. Entries (RSS) and Comments (RSS).

Legal Information: Cheezburgers in Technodise™ is a trademark of Cheezburger, Inc. By using this site, you are agreeing by the site's terms of use and privacy policy.
© 2007-2013 Cheezburger, Inc.