March 20, 2014
Now, we want your help to reach the next generation of hackers. If you’ve got what it takes, join our team as a Campus Evangelist!
What you’ll be doing:
This is a part time opportunity promoting new challenges and hackathons at your school. As our “boots on the ground,” you’ll educate your peers about new challenges on ChallengePost, help out at hackathons, encourage them to sign up for our newsletters, and get them hyped up to participate!
Who we’re looking for:
We’re looking for motivated college and high school students who can commit 3-4 hours a week. If you love hacking and making connections - you’ll be great.
What you’ll get:
- Experience - You’ll be an integral part of our team with exposure to our partners, pipeline, and culture.
- A voice - ChallengePost is an inclusive environment. Got an idea? Speak up and you will be heard!
- Swag - Seriously, all the swag.
- Support - Need some help with Rails / your side projects / marketing / anything? You’ve got a lifeline to our whole team.
- Leadership - This is a new initiative for us and we want you to help us shape it.
March 18, 2014
Imperial Bear via ~db~
While bears have the luxury of hibernating through winter, the ChallengePost team keeps warm by staying busy!
We powered over 40 hackathons this winter, including PennApps & MHacks. And we didn’t let up on online challenges either. Developers created apps to reduce traffic congestion in London, empower the underbanked, and much more.
Here’s a handy roundup of upcoming hackathons and challenges. Mark your calendars!
MashHacks: Travel in Cambridge, MA (March 22) $11,250 in prizes
What developments will revolutionize the way we think about travel in the next decade? Join forces with programmers, designers, and tech buffs for one day to create the next big travel app.
Texas A&M HackerBowl in College Station, TX (March 22–23)
Hackers from across the state will battle for 24 hours to determine the best Hacker Team in Texas. Only one school can take home the Hacker Bowl Trophy. Will it be yours?Apps Foundry Contest in Luxembourg (March 28–30) $5,000 in prizesJoin the “killer-app” creation movement and hack the ground-breaking mobile app that will help you make it big. You’ve got 36 hours!Philly Baseball Hackday in Philadelphia, PA (April 6)The first Philadelphia Baseball Hack Day is a fun, friendly one-day hacking competition for baseball fans.Civic*Celerator in Honolulu, HI (April 18–19) $10,000 in prizes
Civic*Celerator is a series of workshops and events to develop user-friendly apps that provide relevant information about political candidates.
RECENTLY LAUNCHED CHALLENGES
CodeCombat Challenge Grand Prize: MacBook Air; Honorable Mention (3) iPad Air
- Build a new language parser for CodeCombat, a multiplayer game that helps people learn how to code
- Python, Ruby, Haskell, and other current languages are fair game
- Deadline: May 20
Delivery.com App Challenge: $65,000 in prizes
- Create beer, laundry, and food delivery apps using the world’s first open API in the online delivery space
- Accepted platforms: iOS, Android, Windows Phone 8, mobile web, PlayStation, Xbox, Google Glass, or any hardware technology that includes a software component
- Deadline: June 10
Dual Screen App Challenge from Silicon Image: $100,000 in prizes
- Make dual-screen Android games & apps in one of the following submission categories: 1) games, 2) productivity, or 3) entertainment/other
- Deadline: July 21
Appcelerator Enterprise App Challenge: $5,900 in prizes
- Show off your B2B or B2E app built with Appcelerator
- Deadline: May 16
Extreme Android Challenge 2014: $11,000 in prizes
- Build motion controlled games for Android devices
- Deadline: May 20
CHALLENGES ENDING SOON
Pebble App Challenge: $5K Grand Prize + Pebble Steel for Top 16 Apps
- Is your app the best in the Pebble appstore? The public will decide!
- Deadline: March 23
GSA Travel Data Challenge: $90,000 in prizes
- Design and create interactive tools that utilize federal travel data to increase transparency and accountability
- Deadline: April 11
Kii to Unity Contest: $10,000 in prizes + global distribution
- A challenge for game developers working on new mobile games which integrate Kii’s Game Cloud features
- Deadline: April 28
- An app contest for U.S. high-school students who create software. Share this with a budding developer you know. Any app goes!
- Deadline: April 30
Consumer Product Safety Apps Challenge: $4,000 in prizes
- Create applications and innovative tools that raise awareness of consumer safety reports and product recalls
- Developers are encouraged to mash up product recall data with reviews from sites like eBay & Amazon
- Deadline: May 23
Project Anarchy Mobile Game Dev Challenge: $150,000 in prizes
- Skill-based contest designed to reward game developers who make awesome games using Havok’s free mobile game engine, Project Anarchy
- Deadline: May 31
March 11, 2014
Why bother with Continuous Integration?
Long gone are the days of deploying code that isn’t fully and automatically tested. Why? Because, nobody wants to get a call from a client asking why the app suddenly stopped working and sheepishly explain how you broke it with the latest release.
Continuous Integration (CI) is the final step in Test Driven Development (TDD) before you merge a branch back into master. Of course, your tests will only guarantee so much — that’s where code coverage and code reviews come into play. But let’s set that aside for now.
We did a lot of research, and Jenkins CI was the utility best suited to what we were looking for: low barrier of entry, simple setup, and ease of deployment.
Integrating a CI solution within your process is no easy feat. We use CI results both in development and before we deploy to production.
For our developers, a typical process is:
Create a new branch off of master.
Write a few failing tests that describe the work to be done
Get tests to pass.
Run the branch on CI.
If everything passes, the branch can be merged into master. If not, the failing tests need to be looked at. Either the tests are now inadequate and need to be updated, or there are side effects not accounted for. Regardless, the tests must pass and you can’t merge the branch until the build is green.
Once a branch has been merged, Github notifies the CI server of this, and triggers a master build.
If the build is green, the master branch gets a tag and we deploy from that green tag. Otherwise, the tests and build need to be examined.
How we got down to 10 minute builds
We first set up Jenkins on an Amazon Web Services Elastic Compute Cloud (AWS EC2) slice. At the time, our test suite took about 50 minutes to run on local development machines. On EC2 it took north of 4 hours. Clearly that wasn’t going to cut it.
Next, we decided to keep things local and bought the biggest and meanest machine we could find without breaking the bank: an Intel Quad-core Xeon powered machine with 16 cores, 16GB of RAM (this was 2011), and plenty of hard drive space. That brought our test suite down to ~45 minutes. An improvement — but not nearly enough.
Our breakthrough came from splitting discrete jobs into discrete Jenkins CI builds. The internals of our application don’t need to be shared, but it’s composed of a few Rails engines. So, we created a Jenkins job for each engine. This got us down to 25 minutes per build, as everything ran in parallel.
Next we broke off cucumber and rspec tests into different builds. Then we profiled the slowest tests per engine and clustered them into a ‘slow’ and ‘not quite as slow’ builds. Voilà, a sub 10-minute build. It feels a bit like cheating, but we did it!
The current setup involves a master Jenkins server that runs on a VPS (Virtual Private Server) on the DigitalOcean cloud, our aforementioned machine that is now strictly a slave, and many other slaves spun up in the cloud for the lighter jobs. The process intensive jobs are tied down to our slaves labeled
Key Jenkins plugins
Over the years, we’ve come to rely on a number of Jenkins plugins and contributed to their development.
This plugin gives us one main entry point that then triggers many other jobs. The overall result of the build is the
ANDing of all the downstream jobs. (Hello, parallelization!)
This allows us to run multiple slaves that do the heavy lifting.
We want to authenticate using our GitHub credentials, without having to maintain our own user databases.
This plugin triggers builds for different branches from the command line.
It’s a lot easier to see which branches have been built by referring to them by nam rather than a git SHA or build number (the default).
Informs the team when the master build is broken! (Or that it has been fixed)
There are certain occasions on which we want to mark a build as failed.
I’ll explain this in another post – but suffice to say it’s very cool!
Remembering all our of the CI & build options can be a bit daunting, so we wrote a script to make things a bit easier on our developers (mainly myself, I am lazy.)
The script defaults to building the current branch, but you can pass a different branch name as an option.
It goes something like this:
$ build/schedule_build build [Output about build] [A TerminalNotification pops up] $
$ java -jar jenkins-cli.jar \ -i ~/.ssh/IDENTITY_FILE \ -s https://ADDRESS_TO_YOUR_SERVER \ -p GIT_BRANCH=BRANCH_NAME_TO_BUILD \ build JENKINS_JOB_NAME \ -f -w
If we hear some requests about open sourcing this script, we will definitely do so.
Most jobs have similar settings, but require a unique build script. That’s fine – but when since we maintain north of 11 jobs per build, it quickly becomes painful.
To make our lives easier, we developed a script that knows which tests to run depending on the name of the job. Now we just need to be careful about naming our jobs, but we’ve been very good at that since day 1.
Our build script uses a YAML configuration file:
project_name-development-part_a: build-commands: - do_this - do_that gemset: some_gemset_name project_name-development-part_b: build-commands: - do_this - do_that gemset: some_gemset_name project_name-master-part_a: build-commands: - do_this - do_that gemset: some_gemset_name project_name-master-part_b: build-commands: - do_this - do_that gemset: some_gemset_name
And the heart of the build script is this:
RUBY_VERSION_AND_GEMSET="$VERSION@$GEMSET" rvm use $RUBY_VERSION_AND_GEMSET --create bundle check || bundle install eval $TEST_COMMAND
$TEST_COMMANDis the concatenated commands specified in the configuration file.
Originally, since we triggered many builds at the same time (parallelization), we had clashes from job to job when they each tried to install the same gem. We naively opted to pass
bundle installon each job. But this proved to not be very efficient, since each job then maintains its own copy of the gems. It’s time consuming and when we spin up a new server, each job needs to fill this cache.
We solved this by implementing a semaphore for multiple shell scripts running on the same system. They actually run across multiple servers, so they don’t compete for resources.
A nice implementation of a semaphore that can be used effortlessly on shell scripts is Procmail’s lockfile program.
The updated build script can be summarized as:
RUBY_VERSION_AND_GEMSET="$VERSION@$GEMSET" LOCKFILE="/tmp/$RUBY_VERSION_AND_GEMSET" rvm use $RUBY_VERSION_AND_GEMSET --create lockfile $LOCKFILE bundle check || bundle install rm -f $LOCKFILE eval $TEST_COMMAND
When multiple processes get to the lockfile line, the first one can write the file. The other ones will wait there until the file is removed and then write it themselves. And so on and so forth until all processes have gone through that stretch.
This particular change has given us quick wins on overall build time and reliability.
Earlier, I referenced the embarrassment of a broken, untested build. Continuous Integration will definitely help you avoid that, but the benefits go deeper than that.
CI helps you iterate faster, build confidence in your work, manage conflicts, and ensure consistency. You might even consider it part of your team – so make sure you treat it like one and listen to its feedback!
March 7, 2014
This is the third post in a series about how to throw the perfect hackathon.
Someone call in the lawyers… Hackathons have both grown in size and spread around the world in recent years. Companies are using hackathons to engage their communities, non-profits are using them to help solve big problems, and so on. This increased awareness of hackathons means that people are looking at different IP and ‘openness’ arrangements — some of which you might want to think through with a lawyer.
Remember I’m not a lawyer - I’m a hacker. This isn’t legal advice; I just want to highlight some common issues you might want to keep in mind.
Who owns the output?
Over the past few years, organizers have experimented with different ways of capturing and distributing the work created at hackathons. Some of these have involved different intellectual property (IP) arrangements; I want to review these and offer some thoughts on how you might tackle ‘ownership.’
At the vast majority of hackathons, participants retain ownership of their work and this is usually the best model. My colleague Brian has written on this subject before. As he points out, a transfer of IP towards the event organizer seldom aligns with your goals and won’t build long term engagement with the developer community.
Rewired State, based in the UK, has tweaked the traditional hackathon model with their signature Hack Days. There are a few variations of hack days, but they include some form of IP transfer. Two points are important to note here: the developers are paid at market rates and the IP transfer is completely transparent & explicit when participants register. You can learn more about Rewired State and the different kinds of events they run on founder Emma Mulqueeny’s blog.
The international civic-focused hackathon series Random Hacks of Kindness (RHoK) takes a different tack. Hackathon projects must be published under an OSI approved license and the code is made available on a publically accessible code repository. Again, this is clearly communicated to the community in advance.
While these two examples are quite different in nature, they are both upfront about their restrictions / conditions up front for potential attendees.
“I don’t want people to use my data after the weekend.”
Executed properly, hackathons can be a quite compelling for businesses. It’s an opportunity to expose talented and motivated people to your team and technology. I’ve seen lots of great examples where companies have used hackathons as a way to get user feedback and new ideas. Of course, participants benefit too: inside access to new tech, it’s architects, and spirited competition.
However, providing data & services for the weekend and then revoking them afterward does not work. The only circumstance in which I’ve seen this done properly is when work at the hackathon revealed a major security bug in the API. In this case the organization explained to everyone involved why the API keys were being revoked and provided access again as soon at the bug was resolved.
From a practical standpoint, it’s going to be very difficult to ‘take back’ datasets that were released during the hackathon. If you know ahead of time that your data or services aren’t going to be public afterwards, don’t build your hackathon around them!
That’s all for this week. Next time we’ll focus on how to find and set up a great venue. Happy hacking!
February 28, 2014
The bi-annual PennApps hackathon, hosted by the University of Pennsylvania, has long been a standard bearer for large-scale college coding competitions. The Spring 2014 winner, The Homework Machine, embodies four key characteristics of a winning project:
Addresses a problem we can all relate to
At some point, every kid has wished for a way to automate tedious math homework. These students were probably more bored than lazy, but it’s a fantasy we can all wrap our heads around. Projects stand out when fellow participants, judges, and the less technically inclined general public can all appreciate their value.
This hack (1) learns your handwriting, (2) solves math problems, (3) guides a pen rigged to motors and a pendulum to mimic your handwriting, and (4) correctly answers in the exact right spot! Oh yeah, and it was built it in 36 hours!
The ‘internet of things’ is all the rage right now, and while hardware hacks shouldn’t be given preference over equally difficult software-only projects, they do tend to have more engaging demonstrations. The Homework machine produced tangible results - not vaporware promises of something to come.
A bit quirky
Creators Derek and Christopher didn’t plan to help 4th graders shirk their homework responsibilities. They just wanted to test their skills while having a good laugh, which is the whole point of a hackathon. You may learn new technologies, create the seed of a business, and meet recruiters too, but it’s all about building something awesome in a ridiculous setting.