Hi everyone!

You’ve probably realized by now that we’ve got a 24 hour hackathon going on at COM1 Basement, on the 19th to 20th February (that’s this Sunday to Monday).

We know that some of you can’t join for a number of reasons – either you’re too busy, or you’re not sure you can build an app in 24 hours, or you have other things you need to do.

Well, we don’t mind!

We’d like to invite you to come drop by at any time during the hackathon! Come work on your own programming projects, come see how people build apps from scratch, enjoy the environment, the intensity, the free food, and the free coffee! [2]

Time: 19 Feb (Sunday) 1pm – 20th Feb (Monday) 1pm
Venue: COM1 Basement 1
Agenda: Bring your laptop, a programming project and some headphones!

And if you’d like, do come down to meet the judges and watch the conclusion of the Hackathon on Monday, at 12pm. We will have Erwan Macé from Google, Sarim Aziz from RIM, Professor Lee Wee Sun from SoC, plus a two other judges we’re awaiting confirmation from.

We hope to see you there!

(If you’d like to participate, you will have to pay the $10 registration fee to get a chance to compete for prizes.[1] We have raised enough money for food now, thanks to the kindness of our supporting organizations: IDA and NOC Odyssey Fund; so we’ll be using the money from registrations to fund future Friday Hacks, for the benefit of the NUS developer community).

[1] Currently prizes are:

• Blackberry Playbook
• Microsoft Natural Ergonomic Keyboard 4000
• Samsung Galaxy Ace
• AWS Credits
• Private Github Accounts
• Free tickets to NUS Startup Weekend (worth $45 each)
• Nokia Goodie Bags

[2] We’re doing this because we want to have as many students as possible exposed to the idea that hacking is fun, is doable, and is beneficial for their future careers! So come join us!

And this is true. We know this is true because musicians, painters and writers say the same thing; why should it be any different for programmers? Programmers get better when they program — with one unique difference.

The difference is this: code projects, the by-product of ‘programming practice’, are great additions to any resume. Employers will be able to read the code you’ve written. If they care about the kind of software you will produce for them, knowing how well you code matters.

Computer Science professor Matt Might argues:

Having emerged from engineering and mathematics, computer science programs take a resume-based approach to hiring off their graduates.

A resume says nothing of a programmer’s ability.

Every computer science major should build a portfolio.

A portfolio could be as simple as a personal blog, with a post for each project or accomplishment. A better portfolio would include per-project pages, and publicly browsable code (hosted perhaps on github or Google code).

Contributions to open source should be linked and documented.

A code portfolio allows employers to directly judge ability.

GPAs and resumes do not.

Building a portfolio is something we should all be working on. (Matt Might links to MIT student Ed Yang, whose personal portfolio is staggering in its impressiveness).

So the question becomes: what should I practice on? Programming assignments are tedious when done outside class, for no credit. There are only so many Project Euler problems one can solve before getting bored.

The answer, of course, is to start hacking.

There are a number of reasons to hack, all of them good ones. I think it would do to share some of them here for posterity. I’ll end with a number of things you can start hacking on, and one place, next week, where you can do it with your friends.

Hacking exposes you to real world technology

SoC programming assignments rarely cover cutting-edge technology. This is not the school’s fault: it’s too much of a hassle to keep up with the bleeding edge. The school’s job is to teach underlying ideas. Imagine updating your lecture slides every time Node.js changes. That would certainly get in the way of whatever concept you were trying to teach.

No, professors and employers expect us to pick up production technologies on our own. They teach us the ideas — we’re supposed to use those ideas to learn whatever it is we need for our jobs. Sometimes that means learning Python over the weekend. Other times it means learning enough C to debug the bloody PDF library that seems to print a puppy over every document you try to generate.

Most importantly, however, it means that the student who spends his weekends and holidays picking up production-ready technologies is a step ahead when compared to his peers.

Hacking makes you better

We know that practice is good for programming skills. What that looks like in practice (pun intended, forgive me) is that things explode in your face, and you scramble to fix those things, and then you learn new things in the process.

After which you become slightly better.

Hacking forces you into situations where you don’t know enough to begin building things. If you want to build a blog on top of MongoDB, for instance, you might begin by learning a web framework. After which you would need to learn to use Linux, because 99% of websites run on Linux. Learning Linux will enable you to install MongoDB and set up your web server. Then you’ll quickly realize that you’ll need to learn how to use a wrapper for MongoDB, which in turn will teach you how to find and read obscure documentation for a programming project.

Every trivial hack project brings with it a hidden cascade of things to learn. This is a good thing: it means you get to learn more the more hack projects you do.

Hacking puts you in touch with actual developers

One of the quickest ways to learn about the software world is to contribute to an open source project. Many coreteam members contribute to existing OSS codebases, one even implemented a new diff algorithm for Git. SoC provides students with a good Firefox course with which to learn about Open Source. Both approaches to OSS will eventually require us, as students, to meet with and talk to working, breathing developers.

But hacking on your own projects are also a good way to meet other developers. If you’re solving someone else’s problem, he or she may find you on Github to contribute to your code.

Again, this teaches you things you might otherwise have to wait for graduation to learn.

Hacking gives you projects to show

Showing off matters in both sense of the term: hacking projects make you more attractive to future employers; and showing off to your friends keeps you motivated to continue hacking on things.

The latter is sometimes more important than you might think: many a programmer has built a world-changing tool with the partial intention of showing it off to his friends. Facebook and Linux certainly started with some element of this.

Hacking is good for you; start hacking today!

Programming for personal projects makes you a better programmer, helps you score girls gives you opportunities, and makes you more attractive to employers.

It’s not hard to start hacking – pick a problem you’ve always had, and think about how you might solve it with code. Alternatively, pick a cool new technology you want to learn, and find a way to use that to solve your burning problem.

If you’d like to get a head-start, come join us at our Hack & Roll Hackathon, on the 19-20th February. Sign up here, or read more about the event at this link. We’re trying to get more SoC students to hack on stuff, so if you’d like to learn how to start doing so, in the company of your peers, come join us. It’s only $10 per person, and even then for food.

In the words of a much-loved SoC lecturer: happy hacking!

PS: if you like this post, please consider sharing it with a friend!

For tomorrow’s Friday Hacks (10th February 2012) we will have Kailash Sethuraman from Google coming to speak about the Go Programming Language, and Andy Croll of ImpulseFlyer coming to speak about Test Driven Development. These talks will both be held at the Ngee Ann Kongsi Auditorium.

(The Ngee Ann Kongsi Auditorium is the large red-stone auditorium above NUS University Town’s Starbucks — which is, in turn, impossible to miss if you’re around the area).

We have chosen to post this announcement late in the week, as all related information, links, and email blasts have already gone out to the faculties two weeks before. All registered attendees have also received an email earlier this week informing them of the location and rough agenda.

Here it is again, for easy access:

6.00pm Pizza is served. :D
7.00pm Kailash Sethuraman – The Go Programming Language
7.40pm Andy Croll – Test Driven Development
8.30pm Talks finish, participants are free to leave or to hang around and socialize and/or hack on personal projects, homework, and the like.

We’re sorry to report that registration has closed for this talk, as we are oversubscribed. Tune it to our mailing list if you’d like early announcements for future Friday Hacks!

For those who have registered, see you there!

Update: here are the slides for Kailash’s Go talk, and the slides for Andy’s TDD talk.

If you want to have a fun, educational weekend at the Start of Recess Week, in which you get to build something cool and stand to win some prizes, then join us at the hackathon.

Date: 19th (Sun) to 20th (Mon) February 2012 (ie Start of Recess Week)
Time: 1pm (Sun) to 3pm (Mon)
Venue: Tentatively in NUS School of Computing (Soc) Basement 1 (B1)
Registration Period: 25 Jan to 12 Feb 2012 only. Registrations will be closed once we have reached 80 people or on 12 Feb.
Registration Fee: $10 (to contribute for food)
(Note that venue will be confirmed in February. Registrants will be informed of the confirmed venue.)

Registration Link:
http://bit.ly/hacknroll2012
https://docs.google.com/spreadsheet/viewform?formkey=dDRZeUhUQXJybHdsa1oySEpxYVRUdWc6MQ

The 2 top team(s) will get prizes from Blackberry, Microsoft, and others (full list of prizes – tablets, phones and keyboards to be won, will be released in February)

Only a maximum of 80 people can be accommodated for the competition so get in on the action before it’s too late.

Lead-up Talks/Workshops
17 Feb 12 – “HTML5/CSS3 Workshop” (by Blackberry/RIM)

More details coming soon.
Stay tuned to http://nushackers.org/hack-and-roll/ for the latest details!
Rules are found on http://nushackers.org/hack-and-roll/ as well.

PS: This hackathon is only open to NUS students.

Take, for instance, the recent Ideas Meet Skills event by the Startup@Singapore team. The event is made in good faith, but the assumption is there in all its glory: ‘Have a great idea you want to realize or the gumption to excel in a start-up … but not both?’ the poster declares. ‘Register Now!’

(An organizer told me that such events are almost entirely full of business people; it has been very difficult to get technical people to come. And no wonder – with a mistaken premise, is it any wonder when technical people fail to turn up?)

This assumption is more pervasive than one would expect: in my short time in the NUS Entrepreneurship Society (NES), I have heard all sorts of people express it. What took me by surprise was the number of Engineering students who subscribe to this belief. One would think that people from Engineering would be careful about making such assumptions, given the number of jokes engineers make about working under the tyranny of a technically naive, pointy-haired boss. But no, they express it all the same.

The idea is wrong on at least two assumptions. The first assumes that technical people have no ideas (or that they have bad ones). The second assumes that technical people need ideas people to do things. Disprove the first assumption, and the second automatically follows as false.

It is easy to show that technical people have some proficiency with ideas: if they were no good at them, they would not have entered a technical course in the first place. Getting a programmer to come up with ideas for startups is no more than one conversion process away: you simply have to show him how.

What is more interesting to ask is this: are business people better at coming up with ideas than technical people?

The answer to that is: not usually. The key difference between programmers and business people is that programmers can test their ideas, and business people can’t (or at least won’t). That testing process is called hacking.

Joshua Schachter said it best in his Founders At Work interview:

Livingston: What do you think about technical founders versus businesspeople founders?

Schachter: I have never had a great deal of trust for people who don’t execute on core ideas. I understand the value of needing someone to deal with that kind of stuff — someone’s got to do the VC pitch and there’s got to be a CFO, etc. But the guy who says, “I have a great idea and I’m looking for other people to implement it,” I’m wary of — frequently because I think the process of idea-making relies on executing and failing or succeeding at the ideas, so that you can actually become better at coming up with ideas. It’s something you can learn. It’s a skill, like weightlifting. That failed; that worked; continue. You begin to learn how to make ideas. So if you are someone who can’t execute and all you can do is come up with ideas, how do you know if they are any good? You don’t really know if it’s a good idea until you’ve executed it. You need to understand the cost of execution and so on.

Schachter’s logic is rooted in experience: Del.icio.us was the last in a string of random hack projects he had done while working at Morgan Stanley. Zuckerberg had hacked up at least two other projects before doing Facebook; Evan Williams did Pyra, Blogger, and Odeo before doing Twitter. Dennis Crowley did Dodgeball before Foursquare (which he admits is an execution of the ideas he had while working on Dodgeball). In fact, most successful tech companies are founded by people with several past projects. This should not surprise us: in science, the most prolific scientists tend to be more successful. The more ideas you’ve tested in the past, the better you get at coming up with new ones.

When seen in this light, a majority of NES’s entrepreneurship efforts fail to make sense. Ideation workshops are exercises in futility, as they have no hope of real world verification; ideas-meet-skills events fail to attract the people with skills, because the people with skills don’t need such workshops.

It is true, however, that you don’t have to be a technical person to test ideas. Hacking is simply the easiest, cheapest way to do so. You can – like Derek Sivers (CD Baby) and Jason Fried (37signals) – test ideas by hiring programmers to implement products for you, and then learning from those successes or failures. Or you can spend an adolescence tinkering with electronics like Steve Jobs did. But because such methods are more expensive than simply hacking something up, business people tend to stay idle.

In truth, I suspect that the people in NES don’t really believe that technical people are bad at ideas, or that they are lousier than ‘ideas’ people. I suspect they keep at it because it’s much easier to attract large audiences with the lie (‘come do a startup if you have an idea, it doesn’t matter if you can’t execute on it!’) than it is to convince hackers to do startups.

What is the solution to this? The answer is obvious: grow the community of hackers, and then tell them to start startups.^[1] Every year, Y Combinator does something called Startup School – an invitation-only event for technical people, designed to inspire them to take the leap into startupdom. The talks are amazing. The effects even more so. (The sign-up page states that ‘Many founders have told us that this event was what finally made them take the leap.’) And while business people are allowed to attend, hackers have priority.

Perhaps it’s time to start focusing on hackers in Singapore. After all, there are already too many ‘ideas’ people out there: attending workshops, sitting in conferences, pitching business plans – and going nowhere.

^[1] The first is hard, something we at NUS Hackers are still trying to figure out. The second is easy (and can best be done by NES) but will probably have limited effect until the first problem is solved.

This essay was prompted by a recent request to get NUS Hackers to promote more ‘ideas + skills’ events – in particular, to get our members to join such workshops. The coreteam – myself included – reacted with knee-jerk negativity. This reaction, to me, was curious: we could not articulate a proper reason for it, yet we all felt very strongly against it. This essay is written as an attempt to figure out why.

A couple weeks ago NUS Hackers released the unofficial NUS CORS API. I decided to leverage on the API to build something, just for the heck of it. Long story short I ended up building nuscors.com. The site is a faster way to search for a module in the NUS CORS database: you could call it an ‘instant search’.

Now I’m gonna say this this a bluntly as possible, the initial design goals of the site were as follows. Cheap Free, Fast Search, Up before the CORS bidding period started. My other more sneaky goal was to have everyone in NUS use it and become a hero. Some of those goals were met and some are “in the pipeline”.

Anyway from this point on I speak some geek.

In the planning phase of the application and after some poking around I realised that the Unnoficial CORS API was written in Flask (Python). I immediately told myself to rewrite the API using some Ruby. Turns out the NUS CORS site was down on that day and life saved me from myself (phew). I ended up downloading the json file from the api site.

I used heroku as the hosting service for the application. This meant that the app was easy and free to deploy. Unfortunately, all free services come their limitations. In this case it was a 5 megabyte shared database. I didn’t want to have any connection with the database (pun intended) for a couple of reasons but most importantly it would add time to the page load.

In a nutshell the site works by downloading a static json file and then running a search on that downloaded file. Once the functionality was completed I designed the look and feel of the site to mimic Google instant search.

That, my friends, is how nuscors.com was born. Hope you enjoyed the read, if you have any questions join the NUS Hackers mailing list and mail me there.

The first is an instant CORS search at nuscors.com, built by Rollen Gomes a week after the launch of our Unofficial CORS API. Simply type a module name or code to have the list filtered down to the module you’re looking for. It’s blazingly fast in a desktop browser, and I must say that it’s really changed the way I do my module planning.

The second cool project is a shuttlecock launcher built by James Yong (and a few other contributors) on the side, for two years, while at SoC. No technical details released, but see below for a demonstration:

Enjoy!

It reads like a good motto to me. Let’s break it apart to see what it means:

1) ‘Shit’ is random because it’s not fair to just build useful stuff. Sometimes fun, throwaway projects are worth doing, because they give you new ideas.

2) Building stuff for fun is important because programming should be fun. (If it isn’t fun and you’re in Computing then you might have a problem.)

3) Building stuff for experience is equivalent to ‘practice makes perfect’. We are told in school that the best way to become good at programming is to do lots of it. But building personal projects is also a rather useful trick to learning new things – for starters, you’ll bump against a lot of production-ready tools that you might not otherwise need when solving school-created problems. Also, building stuff is sometimes a good excuse in itself for learning new tools – e.g. the unofficial CORS API was used as an excuse to learn and deploy MongoDB.

4) Doing it for glory is a raison d’être for NUS Hackers. The respect and attention of a close community is a powerful motivator for any student programmer. If we succeed in creating such a community, we will give our peers a reason to build things for their own benefit. Everyone wins in that scenario.

I think we’re 2, 3 years our from achieving this. We have a lot of work ahead of us.

This is Cedric (aka Eli online), the current president of NUS Hackers.

I’m here to tell you about some of the things we have planned for the next semester, as well as to ask for your input on how we can do certain things better. This will be a long email, but I hope for your patience as I explain some of the initiatives, partnerships and decisions we’ve made behind the scenes. (This closed-door decision-making is also something that will change, but more on that in a bit).

As most of you already know, the NUS Hackers is a club dedicated to the spread of hacker culture and open source software in NUS. Historically, most SoC students don’t really have a culture of building things for fun. We know this because our seniors told us, employers outside tell us, and entrepreneurs tell us the same things over and over again: where are the good programmers? Where can I hire good programmers? Why are SoC students not like MIT/Stanford/X university ones, who build things and learn things on their own, outside school?

(For a taste of what employers think of NUS SoC grads, refer to this Hackerspace.sg thread)

Our response to this is to get more people hacking. This isn’t a completely altruistic motive – the more you hack, the more you release open source code, the more attractive you become to future employers. (i, you display initiative when you launch your own projects ii, tech-savvy employers (the good kind) can read your code before they hire you).

Also, if we get enough hackers together, it benefits everyone in the group, as NUS Hackers will be the go-to place to look for talent for startups, employers, and professors in NUS (research).

We are a long away from that. We did a few new things that were in the right direction last semester, but we were disorganized:

• Friday Hacks were announced too late in the week
• The venue kept changing
• We didn’t pursue opportunities to pass down to members as aggressively.
• Nobody released open source code.

Here’s what we’re going to do about it.

Friday Hacks – Talks:

We have found that attendance increases when there’s a talk announced early in the week. With that in mind:

• Friday Hacks will be in one venue for the whole of next semester. I will try to lock down Seminar Room 2 ERC @ Utown, but if that’s not possible, I will announce it here and on the blog.
• Talks will be announced on the site in advance. I have redesigned the nushackers.org front page to display a list of speakers and topics for all the weeks in the semester, as well as open slots that students, professors, and outside speakers might want to pick to speak. I have also created a general information page for speakers – including a map and parking locations.
• I want to provide free dinners to everyone, for every Friday Hacks. Coreteam members have good working relationships with several large companies, and I am will find sponsorships to make this happen. (Free pizza makes sense, by the way – we want to build community amongst hackers. Plus speakers from various companies can join right in).

Hacking

Last semester, we found that not many people knew what to hack on. OR that they did homework. That’s not completely cool: a big value-add of hacking is that you learn and build things outside the curriculum. Here’s what we’re doing about that:

• I spent a week building, and just released Treehouse – a dashboard for NUS Hackers projects. A post may be found here: (I’ll do a proper announcement post soon)
• Check the project page and the people page out. I’m pushing updates as we go along.
• Going forward, we will use Treehouse to keep track of all hacking activity in NUS Hackers. :)
• The site is capable of parsing git repositories, so as long as you have a publicly available git clone address, it will grab it and parse it and attribute it to the right contributors.
• It also has social features, and karma, meaning there is some built-in troll-protection. I will moderate and build extra anti-flamewar controls if required.
• Please sign up, and remember to use the email address you use to sign your git commits.

What we will use Treehouse for:

• Next semester, for a four week period at the start of the semester, we will get everyone to work on projects, with a show-and-tell and the end of the four weeks.
• What kind of projects? Any kind – but preferably ones that benefit the NUS community. E.g. I’m planning to do a Javascript skinner for IVLE, to make it user-friendly and awesome-looking. You can also choose to build mashups on top of the CORS API we released a few weeks back. Plus: let’s do it in teams! (Anyone want to work with me?)
• This hacking will take place during Friday Hacks, for four sessions. (You can also work on it in your spare time, of course, which means):
• Treehouse will be used to keep track of these projects.
• More details on how we’re going to organize this next week.

Of course, it goes unsaid that coreteam should set the example for the rest of us. So I’m going to make sure everyone builds something ;-)

Communication

I realize that we’ve not been clear on everything that’s going on in the club. Consider this email my apology, and know that I’ll work on pushing atomized updates to the mailing list in the near future. (Or we might move to Treehouse, I don’t know).

I also realize that the coreteam has two options in achieving our goal: grow the team, or write more software to make managing the club easier. For the time being, I believe the latter option is the answer. Because: i) we’re hackers, ii) we want to avoid bureaucracy like NES or NUSSU. Being small and scrappy has its benefits.

That’s all from me folks.

Please chime in if you have suggestions, ideas, or pointers.

Thank you for your time,

Ced

The project is open source and available on Github. (The README provides implementation details.) Ray Chuan will provide a requirements file in the near future. You’ll need pymongo, MongoDB, Flask and Scrapy to run the project yourself,  but it’s not a big project to read — just took 4 days to write — so do feel free to fork, comment, open bug reports, and send us Pull Requests.

Why?

There are two reasons for doing this: in the best case, we intend to ask the CORS team in NUS to implement a RESTful API (and we don’t mind doing it for them – if anything, this project shows that the easy bit is the design and implementation of the API; the hard bit is in the scraping and parsing of data).

Should this approach fail, the NUS Hackers will host and maintain this API for as long as is needed.

The truth is, I think, that a CORS API is long overdue. Over the past few years, there have been a number of student-initiated projects to build better CORS-related tools. The Unofficial Timetable Builder, built originally by Koh Zi Han, Tan Kian Boon, Liu Linxi and Wang Sha (and currently maintained by Zi Han), exposes a beautiful timetable-building interface to CORS. As does NUSchedule, built originally by Lionel Chan, Victor Loh and Colin Tan (currently maintained by Chris Chua). Both project rely on scraping to get its timetable data; NUSchedule uses a clever Javascript-based scraper.

I’m not sure why the CORS team hasn’t provided an API — Zi Han says that he’s been petitioning for one for years. But I can guess as to the reasons: the CORS team may be overburdened, or perhaps they see little utility in building and maintaining an API.

Regardless, we’d love it if you build cool apps on top of this. You could build, say, a timetable builder, or a fast AJAXy search engine, or perhaps a Google Maps mashup to plot lecture and tutorial locations on a map of NUS!

We’ll be in contact with the CORS team, and will update you as to the status of building an API for them. Hopefully, we’ll not need to host this API for long.

Happy hacking!