Engineers have dedicated years of their lives to optimizing every part of the bicycle. Even simple parts, like brake levers and foot pedals, have been studied in excruciating detail. Why? When these parts come together, you get one, holistic biking experience, and that’s what that people want (and are willing to pay for). But it only takes one bad part to cheapen the whole experience. We can learn a tremendous amount about products by taking a look at the bicycle.

1. Two things make a bike “high-end”: the parts and their integration.
2. The experience suffers to the “min” of the parts.
3. You’re always selling an experience, not technology.
4. Aside for engineers: the value of your part is derived from the whole.

For my final project in Computational Methods in Biological Modeling in Simulation, I’m making an agent-based simulation of how Ebola spreads.

It’s about time I took a break to work on something completely unrelated to Appcubator for a couple of days. So this weekend, on a whim (thanks to Connor O'Doherty whom I bumped into on Thursday night), a few friends and I went to a hackathon at Virginia Tech called VTHacks.

The team consisted of me, Steve McQuaid and Shikha Nalla. We brainstormed the night before the hackathon of ideas to build. We wanted to build something simple and impressive that would wow the audience on a live demo. We must’ve gone through a hundred ideas, but we ended up going with this one:

What is that, you ask? That is Steve holding a phone, with our “Game Controller” loaded. He’s playing a rendition of real-time multiplayer snake on the laptop.

The idea came from the thought that Xbox and PS3 controllers are really annoying. You have to buy and keep several of them for special occasions, they break, they get oily, the wires get tangled and if they’re wireless you need to buy batteries. Video game controllers are just a pain.

Yet most kids these days all carry touch screen phones in their pockets, which could easily serve as a controller for your video games. Imagine if you could join a live video game by taking out your phone and opening up an app. You could control your video console and TV without even bending down to pick up a controller!

Inspired by this vision of a controller-free world, we built a simple proof of concept to demo what the user experience would feel like.:

We used socket.io to do the realtime stuff and canvas to do the mobile controller UI. I worked on the backend game implementation and the overall architecture. Shikha designed and implemented the mobile controller. Steve worked on the backend and the board rendering.

Github: https://github.com/nshikha/vthacks

So that’s part of what we worked on last weekend. We also got our hands on a parrot quadcopter, and Steve stayed up all night making a web server so you can control the quadcoptor from a website using the keyboard.

Github: https://github.com/stevemcquaid/ar-drone-keyboard

Overall, we had a blast hacking on cool projects. It was a ton of fun demoing our stuff to people and watching their reactions. Also, this serves as kind of a hackathon closure for me, since it’s my first time at a hackathon where I had a good grip on how to write software.

One of the hard lessons I’ve learned in the past year, is that writing code is not a good thing. In fact, you should write as little code as possible.

I’m not talking about removing all the whitespace from your code and writing everything on one line. Let your code breath, let it be readable. That’s totally fine.

But avoid adding features. Avoid making your codebase larger. If you can get by with fewer features, you should. If you’re not succeeding with few features, there’s no rule that says adding features is going to change that.

More code means more stuff in your head. It means you’ll have a hard time changing things later on. You’ll have more baggage to maintain, more test cases to consider.

Be lazy. Get away with less. Because when you realize you have to change your code - and you will - you’ll really thank yourself for having less code to think about.

Less code lets you move fast, and markets are first come first serve.

A “computer programmer” is literally defined as someone who writes and maintains the source code for computer programs.

In reality though, the job description is more like this:

“A [computer] programmer uses his knowledge of how a [computer] works in order to control it for his or her own benefit.”

If we make one simple word substitution, we get this:

“A [blank] programmer uses his knowledge of how [blank] works in order to control it for his or her own benefit.”

Sound like someone you know in a creative profession?

• Teacher - Learning programmer
• Lawyer - Legal protections programmer
• Accountant - Tax law programmer
• Doctor - Humans and Medicine programmer
• Writer - Language and rhetoric programmer
• Artist - Intersting-idea programmer
• Actor - Emotion and appearance programmer
• Chef - Food and taste programmer

As a programmer, it seems like my job is not so different from a lot of common jobs, but somehow, many people consider programming to be “too hard” to learn.

Let me tell you a secret - once you understand computers and software, programming becomes easy. The hard part is understanding computers.

So if you’re trying to learn how to code, try to learn how existing software works. Then try to code a bit. Rinse and repeat.

And another note - Just like there are many fields within law or medicine, there are many different aspects of software:

websites, games, web services, data storage, large scale computation, cryptography, user interfaces, operating systems…

These topics have some things in common, a lot of which is covered in your typical “codecademy course”, but they are completely different on a higher level. A patent lawyer might not know anything about divorce law, and a foot doctor might not know how to fix a brain tumor, but all lawyers know the Bill of Rights, and all doctors know the basic components of blood.

The most important thing to remember is that no one is born automatically understanding how computers work. No one is born knowing anything works. In that regard, we’re all the same - and indirectly, we’re all programmers in one way or another.

I’m writing a web app in Node.js and the Express framework, to serve as a hub for all textbook transactions at CMU. I recently finished the core backend functionality, ie models, controllers, and basic views.

Some cool features:

• Searching for textbooks by course number, course name, or textbook name. This is implemented simply using regex, and I sanitize input to escape special regex characters.
• Completely ajaxed, single web-page. When you click a button, the response is nearly instant, using a higher-order function to ajax specified forms and links.
• Modular code. Functionality is broken down into models and controllers/presenters, and views.
• Session_id based authorization
• Each user has two list of books: buying and selling
• Restful api

 I started the app to bridge the gap between textbook sellers and buyers at CMU. That will be the MVP, but I realized that there should also be an option for people to sell directly into major book websites, so I’ll integrate with the Amazon APi among several others. In addition, it would be really slick if students could send a link of their schedule and CMUBookstore would automatically populate the buy list for that user. Authentication will be done by either facebook, or password. 

There’s still a lot of work to be done, from account creation/deletion, to building the UI. I am looking for some help on the UI, so contact me if interested. 

For now, checkout the source code on github!

https://github.com/ksikka/CMUBookstore