Become a Better Software Engineer in Five Minutes a Week

Subscribe to this podcast on becoming a better software engineer.

Set volume to 1 on OS X

I just discovered an easy way to set the system volume to the lowest value greater than 0. Use the Volume Down button to reduce the volume to 0, then hit the Mute button to increase it to 1. It's a shame that I'm the only person in the world who needs this feature; my earbuds are just too loud.

Corporate activism is the new activism

The US political system is broken. Everyone agrees on that. For an explanation, see This American Life's recent episode on campaign finance. Politicians must fund their campaigns by asking lobbyists for money. In return, lobbyists ask politicians for face time to explain their corporation's interests. Not some politicians; all politicians. Unless there's a public outcry, the interests of the citizens are outweighed by the interests of the paying corporations.

The most idealistic among us think that we can change this with grassroots activism. They believe that the internet will allow the people of the US to band together and make our politicians accountable again.

I don't buy this argument. People simply don't have time to care about most of the issues that affect them. Activism is a full-time job. That's why we have a representative democracy. We elect politicians to represent our interests in the lawmaking process.

Thus, I propose a "new" form of activism effective in today's political environment: corporate activism. Instead of trying to convince people to donate their time and money to a cause, construct a business whose interests align with your cause.

If your goal were to reform copyright law, you could create a business that would benefit from shorter term of copyright. For example, Netflix for public domain movies. If you want to eliminate software patents, build a software company which doesn't create or buy any patents. Your company would be certain to infringe on thousands of software patents, so it would be incentivized to lobby for patent reform.

The difficulty in creating your own activist corporation lies in keeping the company's interests aligned with your cause. Netflix could have been an advocate for sane copyright law, but now its deals with content companies form a barrier to entry which protects its business. Netflix would face increased competition were the US term of copyright to shorten or the penalties of copyright infringement to lessen, so it has no incentive to advocate copyright reform. Likewise Google could have been an advocate for net neutrality, but it struck a deal with Verizon, an opponent of net neutrality, to convince Verizon to carry Android phones.

Despite the risks, I see corporate activism as the most effective way to change the US political system today. This isn't how it should work, but campaign finance has been fixed, there are no reasonable alternatives.

A perfect life

A recent conversation about the future prompted me to reconsider my definition of success. I still want to create a product that improves the lives of millions of people and earns me millions. However, I don't need that level of success to support my ideal lifestyle. I require only four things:

Wife and kids

My life won't be complete without a mate to share my life with and children to teach and learn from.

Work I love

I need to spend my working hours doing something I enjoy for a purpose I believe in. Doing otherwise would be a waste of my precious time.

Three day work week

My wife and I need to be able to support our family's lifestyle working only 8 hours per day three days per week. That way, at least one of us will be home with the children every day. Until all of my children enter school, I want to spend more than half of my time with them. There's no more valuable gift I can give my children than my time and attention.

Ability to relocate

I want to move my family to a new area every two years. My own family's frequent relocations gave me a broader perspective on life and helped me develop my independence. I want to bestow the same benefits on my children. Also, I love to live in new places.

No commute

I refuse to waste hours of my life every week driving or riding to an office. Either I'll work close to home or I'll work at home.

I was surprised when I realized that this was all I needed from my life. I feel like I have more freedom in constructing my life than I had.

Learning to think and learning to do

All knowledge falls into one of two categories: practical and theoretical. The key to a successful career in computer science is balancing your interest in both.

Theoretical knowledge

I consider any topic which is independent of a specific programming language or platform to be theoretical knowledge. Theoretical knowledge encompasses abstract CS topics, such as data structures and algorithms; the underlying mathematical concepts, such as graph theory, combinatorics, and automata; and the hard problems of CS, such as computer vision, artificial intelligence, etc. These are powerful tools for solving hard problems and building things which haven't been possible before.

However, becoming an expert on a theoretical topic won't get you any closer to building a successful iOS app or web service. Without practical knowledge, you'll be dependent on your partner, team, or organization to allow you to accomplish your goals. You won't be able to implement your ideas on your own.

Practical knowledge

Practical knowledge is the stuff you need to know to bring your idea to the world. It's the connection between abstract ideas and useful products. Practical knowledge includes programming languages, APIs, applications, etc. Mastery of a few practical topics allows you to quickly build something which others can touch and use. Practical knowledge also brings independence: you can start a business if you have something to sell.

However, practical knowledge isn't enough to change the world or even make a competent programmer. Without theoretical knowledge, you will waste time reinventing algorithms and trying to solve impossible problems. In addition, your plans will be bounded by the extent of your theoretical knowledge.

In practice, it's impossible to work in Computer Science or programming without some knowledge from the opposite field. Nevertheless, you can't reach your potential in either field without seeking a balance theoretical and practical knowledge.

Landing the perfect research internship

If you're considering grad school (and you should), you owe it to yourself to experience research for yourself before you make a decision. Spend a summer working on a research project at a university, and you'll know whether research is for you. Below, I share my advice for finding and landing your ideal research internship.

1. Find your internship

The first step to getting the perfect internship is finding the perfect internship for you. You need to consider things like location, pay, required skills. Pick at most ten internships to pursue further; if you apply for many internships, you won't have the time to form relationships with your potential researchers.
One great place to find research internships is the National Science Foundation. They fund REU (research experience for undergraduates) programs at schools across the country. You can find a list of participating schools on their website. Here's a list of organizations offering undergraduate research opportunities. Some universities offer independent research internships which they fund themselves. If you have a particular university in mind, try exploring their website to see if they offer independent internships.

2. Research the positions

This is the most important step in the process: learning about the positions. For each position, you must determine whether you want it and whether you're qualified to fill it.
First, sift through all the research opportunities available through each internship and find some which interest you (or don't bore you). This is difficult because you don't know enough about the research domain to make an informed decision. Keep cutting until you're left with a group of projects you can see yourself working on.
Second, read some research papers about the projects in which you're interested. Projects' websites rarely have the information you'll need to make your decision. You need to determine whether you're still interested in the project and whether you have the skills necessary to contribute to it. This process also gives you more information about the researchers.

3. Make contact

Before you even write your application, you should start a conversation with the researchers you're hoping to work for. Establishing a connection before the application process is the best way to improve your chances.
Contacting a researcher at a large university directly, however, can be a challenge. Sending an email is like playing the lottery: the odds are good that you will never receive a response. You can increase your chances by contacting the researcher's grad students, secretary, or postdoc students first. Other possible approaches are calling the researcher and sending them a letter. The keys to success are creativity and persistence.
Protip: If your researcher has a postdoctorate student, contact them first. They have more time than the researcher or their graduate students.
Your first email must be "perfect": free of spelling, grammatical, and cultural errors. The goal of this email is to give the recipient a reason to reply and give them no excuse to ignore it. It must be as short as possible, conveying only the core of your message. Exclude flattery, greetings, and anything else that isn't vital to your message. Don't attach your résumé; that's disrespectful of your recipient's time.
You have several options for the content of your message. You could ask a question about a project or ask whether the researcher is looking for a summer research intern. You may include some brief statement of qualification if it's relevant, but it's not necessary.
Below is the first message that I sent to Dr. Roy Campbell, my researcher for my internship at the University of Illinois at Urbana-Champaign:

Subject: ITI Undergraduate Internship question
I'm planning to apply for the ITI Undergraduate Internship program, and my first task is finding the professors with whom I would like to work. If I were to spend the summer working with you on your research, what would I be doing? I'm particularly interested in your research on p2p distributed operating systems and ubiquitous computing. Would I be able to choose my topic of research? Thanks for the help.

It has twice the lines that it should have, and it contains two dumb questions. However, it demonstrates my communication skills gives him a reason to respond. In that respect, it does its job.

4. Do the work

Once a researcher has responded to one of your messages, start reading everything you can find about their research and the surrounding field, starting from the most recent. Pick a interesting project from each researcher, but don't become attached to it. The more knowledgeable you are about a researcher's work, the more professional and motivated you'll sound to them. Plus, it's good practice for your internship.

5. Write your application

Writing an application is probably the least important step in the application process. However, it's also the step most likely to keep you from an internship. Your application must be "perfect" in the same sense as your first message, but it need not be a literary achievement. It should tell the reviewer why you would be a productive research intern. Anything irrelevant to that goal should be excluded.
Protip: Don't list "communication" or "writing" as one of your skills. If you can write, it will show in your application.

6. Follow up

If the website for your internship program doesn't mention a decision date, plan to contact the program administrator two or three weeks after the application deadline to ask about the status of your application. This step has two purposes. First, it helps you learn the decision on your application sooner. Second, it keeps the process moving. Without supervision, the application process could stall for months.

Conclusion

A research internship is a great way to learn about research and the grad school experience. They key to landing one for yourself is finding the right one and connecting with your potential researcher. Good luck!

My Summer Internship

Last summer, I researched cloud network security through an internship with the Information Trust Institute at the University of Illinois at Urbana-Champaign. It was the best summer I've ever had.

First, it was exhilarating and terrifying to move to a new city with only the things I could carry on a plane. I spent my first weekend in Urbana acquiring the things I needed to live: food, towels, toiletries, and a bicycle. Once I had settled in, I found Urbana-Champaign to be a wonderful place to live. When I spent time exploring the city, it rewarded with delicious restaurants, fascinating architecture, and stimulating culture. Exposure to Black Dog's barbeque pork sandwiches and brisket burnt ends and Murphy's Pub's hamburgers has destroyed my appetite for the substandard barbeque and burgers I've found here. Every day I wish I were back in Urbana.

Second, I enjoyed working on something substantial. My job was to research computer network security, devise a new network security system, build a prototype, and document the work. The research time gave me an excuse to learn how networks work. The planning stage introduced me to the process of brainstorming and planning with a team. In the prototyping phase, John and I managed to assemble a test network with 32 virtual machines, build two prototype security enforcers, and test our prototypes on the test network. To document our work, we created two posters and wrote a research paper which will be published by the International Workshop on Resilience Assessment of Complex Systems 2011. I'm proud of what I accomplished during the summer.

Third, I was honored and delighted to befriend my colleagues and fellow interns. It was a thrill to work closely with John, my partner on the project. We spent hours together slinging code, debugging the test bed, and writing posters and papers. I also enjoyed eating lunch with the other ITI interns Tuesdays and Thursdays at the internship seminars. On the weekends, my posse and I would meet to go bowling or eat dinner. We also had a few events at Europa House for all the summer iterns: a Walking Dead marathon, movie nights, and potlucks. The things I miss most about last summer are the friends I made. However, I expect to meet them again in the coming years on the cutting edge of industry and computer science research.

In summary, my summer internship at UIUC allowed me to live in a new city, research cutting-edge technology, and make new friends. Next summer will be even better.

My epic internship quest

Here's the story of how I spent four months of my life locating and applying for internships.

My initial plan was simple. Spend the summer doing a research internship at a major CS university to simulate pursuing a postgraduate degree. I had been receiving contradictory advice on whether I should attend grad school or go straight to work once I finish my Bachelor's degree. I thought I would settle the issue by experiencing research first-hand.

I applied to two REU programs: the Information Trust Institute at the University of Illinois at Urbana-Champaign and the Summer Undergraduate Program in Engineering Research at Berkeley – Information Technology for Sustainability at the University of California Berkeley. I sent seven inquiries by email to professors from both programs, receiving two positive responses. I spoke with Dr. Roy Campbell, a researcher at UIUC, and Leo Meyerovich, a grad student working with Dr. Ras Bodik at UC Berkeley. I submitted my applications successfully around the middle of February, although my UC Berkeley application was a day late.

During the application period, I stumbled upon another internship opportunity I couldn't ignore. Fog Creek Software in New York, NY was looking for a summer intern to help them build tools for programmers. The idea of working in New York under the venerable Joel Spolsky was irresistible. I didn't think I had a chance, so I drafted an email of application and sent it within two days. I didn't want to waste too much time on a fantasy.

When Fog Creek contacted me to set up a phone interview, I was both surprised and elated. I solved a few programming challenges from Project Euler to prepare for the programming examination, and I tried to anticipate the interview questions. Unfortunately, I forgot about most important question, "What programming projects have you done recently?" When the interviewer asked that question, my confidence was shattered, and I slipped into panic mode. During my programming test, I forgot how to use static variables, writing some terrible C. However, I spent my next class mentally debugging it, and I rewrote, tested, and resubmitted a not obviously broken version with a brief explanation later that evening.

At the end of the interview, I was told that I would be told whether I got the job within a couple days. I didn't hear back for about a week. At the time, I thought that meant that everybody at Fog Creek was too busy to bother sending me a rejection email, but in retrospect, I was probably a finalist who wasn't ruled out until the end.

Around this time I realized that what I wanted was an industry internship, so I refocused my efforts on finding an internship with a big tech company. I started gathering links and working on my resume.

Early in March, I heard about the Cascadia Fellowship, a program that matched technical students with Seattle-based startups. I answered a couple questions and provided a statement of intent. The following week, I received a mass-mailed rejection, in error, and then a personalized request for my resume and couple programming puzzles. Everything was due the following day. However, before the deadline, they sent me another impersonal rejection email. I ignored it and submitted my code before the deadline (barely). When I hadn't heard from them for a week, I asked if the second rejection was sent in error. I never received a response.

It was late in March now, and I didn't have an offer. I had narrowed down my list of major tech companies offering summer internships to Facebook, Google, Microsoft, and IBM. I missed the unpublished deadline for the Facebook software engineering internship, so that left Google, Microsoft, and IBM. I wrote a spartan list of reasons for Google to hire me and submitted my application. I filled out Microsoft's on-rails application, and submitted that next. Finally, I answered IBM's primarily experience-related application and turned it in.

After all this, I had only to apply to one more program: the Google Summer of Code. GSoC was my ultimate fail safe. I was accepted last year, and I felt that I had the process figured out. Unfortunately, I didn't have much time left to apply; I hadn't even looked at the list of mentoring organizations when the student application period began. I had eleven days to find at least two interesting organizations, pick interesting summer projects, and submit a detailed proposal to each, plus another two weeks to convince the organizations that I could complete my chosen projects.

I chose two organizations: Learning Unlimited, producers of a sophisticated Django-based web app; and Sencha Labs, developers of the JavaScript InfoVis Toolkit. I thought that LU was a long shot, but I found the project more interesting than the JIT. I split my application time between designing a student registration system for LU and fixing bugs for JIT. I had some independent experience with JavaScript graphics, and the project I chose was well within my capability, but I got cocky. I didn't spent nearly enough time learning about the core library; I simply assumed I would get the project. I worked hard on the LU project because I wanted it more and it was far more demanding. In the end, I was rejected by both projects because I didn't focus on either one. If I had dedicated myself to either project, I would've gotten it.

After the GSoC application deadline but before the decision date, I received a surprising message from UIUC. Dr. Masooda Bashir informed me that two researchers were interested in working with me over the summer, Dr. Klara Nahrstedt and Dr. Roy Campbell. Dr. Nahrstedt asked me for my resume, but Dr. Campbell remained silent. I sent him an email asking what he would be working on over the summer, but I didn't receive a response.

At this point, I was frantic. I hadn't received a positive response from any of the companies I had applied to, and when I didn't receive a decision from Drs. Campbell and Nahrstedt, I assumed that I hadn't made it into the highly competitive ITI internship. I tried to start over, looking for less exclusive internships, because I didn't want to waste my summer taking classes.

It was the beginning of May now. I had almost given up, but I decided to ask Drs. Campbell and Nahrstedt for final decisions. When I asked them whether they were still interested in working with me, Dr. Nahrstedt told me that I hadn't made the cut, but Dr. Campbell responded with an enthusiastic "Yes!" It was almost too late to file the paperwork, but Dr. Bashir came through for me. I received the official offer letter May 4.

Now, I've spent half my summer working at the University of Illinois at Urbana-Champaign, and I couldn't be happier. You could say that all my hard work paid off, or you could say that I got lucky at the last second. Either way, I'm just happy that I won't have to submit any more applications until the fall.

Lessons from gonzo programming

I recently experienced writing code under a looming deadline for the first time. After applying for the Cascadia Innovation Fellowship, I received a request for my résumé and two code samples due the following day.

The request described two pieces of code and asked me to implement them. I started immediately, dispatching the first with little effort and working on the second for a couple hours in the evening. Then, I unwisely decided to stay up to finish my second sample. I “finished” the code, “tested” it, and, satisfied, went to bed.

The following day, I worked on my résumé for most of the day, looking at the code again late in the evening. A simple test revealed a fundamental flaw in my algorithm, and I stayed up until 2:30 AM rewriting the algorithm, submitting my code only 30 minutes before the deadline.

I feel pretty good about my final code, but I didn't enjoy staying up late and coding frantically.

I learned a few valuable lessons worth sharing:

• Test thoroughly. If you're not trying to break your code, you're not testing.
• Prioritize. My résumé contained virtually no information I hadn't already submitted through my original application, yet I spent precious hours polishing it obsessively. I knew that the quality of my code would be the most important factor in my application, but I left my coding until the last minute.
• Use the obvious solution first. When I first considered the second piece of code, I skipped over the obvious solution in favor of a “faster” and “more general” solution that didn't work. I made the classic mistake of trying to solve a recursive problem non-recursively without first implementing the intuitive solution.
• Use git. After identifying the fatal flaw in my original code, I attempted to solve it with a set of small changes throughout the program. After working on the algorithm for about an hour, I rediscovered the obvious solution which was based on my original code. Thanks to git, it was easy for me to stash my changes in a new branch and resume work on my original version.
• Don't use C++. Because the prompt implied that solutions should be written in Java, I started working in C++ and asked if that would be OK. Instead, I should have asked if I could use Python: both of the challenges would have been almost trivial in Python.
• Never be without Programming Pearls. I left my copy at my dorm when I went home for spring break, so I couldn't refer to it to help me solve the problem. From now on, it's not leaving my side.

Thoughtfully designed electric razor

When I plugged in my inexpensive electric razor to charge, I pleasantly surprised by this delightful animation. I deeply respect this level of attention to detail. Whoever created this animation has converted at least one Remington user into a loyal Remington customer.

Why I want to work at Fog Creek

I'm applying for a summer internship at Fog Creek Software, a well-respected software company in NYC. I'm going to be interviewed by one of their developers next Tuesday, so I've been trying to anticipate the questions I will be asked and give them some thought. Tonight, I asked myself a simple but important question: "Why do you want to work at Fog Creek?"

First, I thought I wanted the experience. An internship at a reputable software company would look great on my résumé. I briefly considered whether I was in it for the office. Then, I thought that I wanted to prove to the world that I could build software, not just make little toys and read big books. However, I quickly realized the true source of my motivation: I want to work at Fog Creek to prove to myself that I can build software.

Until now, my most substantial project has been my work on OpenInkpot last summer. Assembling a cross-toolchain is highly technical work, but it's not a creative act. I didn't design the structure of the toolchain; I just put the pieces together.

I've tried to prepare myself for a career as a software developer by reading books on software structure and construction, but I know that's not enough. I won't know that I'm ready until I've built something real.

To become a software developer, I must develop software.

I was dead wrong

More than a year ago, I posted Programming is more than pointers and recursion, arguing that CS students don't need to learn about pointers and recursion. I wrote it in response to The Perils of JavaSchools, a 2005 blog entry in the legendary programming blog Joel on Software. I realize now that I was dead wrong, and I've decided to explain why (not only because someone from Fog Creek Software will be evaluating my blog.)

My central argument was that since pointers and recursion aren't often used in the software development industry, they aren't necessary topics for CS curricula. I was high on Python and Design Patterns at the time and fervent in my belief that all problems could be solved with straightforward, readable code. What I failed to realize is that if you can't (not don't) understand pointers and recursion, you can't have a meaningful career in programming.

Understanding pointers means more than memorizing the illogical C pointer syntax. It's an understanding of the difference between reference and value, between creating lightweight pointers and copying massive objects. Any programming job that doesn't require you to think about whether a variable should be a pointer or a value probably doesn't provide any challenge or variety. It certainly wouldn't provide any job security or marketable skills. Pointers are fundamental to programming.

Likewise, recursion is more than replacing a function call with the function's body; it's an illustration of the encapsulation of functions. Recursion is a stepping stone to first-class functions and closures. These aren't academic knick knacks with no practical application; they are powerful features in many popular languages.

In summary, Spolsky was right and I was wrong. Pointers and recursion are powerful tools that belong in the belt of every software developer. If you can't learn them, stick to HTML and CSS.

Where I have been

I haven't written an entry on this blog for about a month and a half. I stopped posting because I was unsatisfied with the quality of my entries. In a word, they sucked.

I realized this after listening to 149 Surprising Ways to Turbocharge Your Blog With Credibility!, Merlin Mann's and John Gruber's talk at the SxSW Interactive conference. Their advice to aspiring writers is simple: write well about topics which interest you.

Before now, I was putting frequency before quality, partially due to a foolish commitment to write one blog post a week during this year. I was writing pointless updates because I didn't have the time to create anything meaningful. Now I know that was a mistake. I am not a blogger; I'm a college student who enjoys writing.

Of course, this isn't the end of Welcome to Obscurity; it's the end of the shallow updates that have composed most of this blog's content for the last year. I will be writing infrequent, in-depth, polished entries about things about which I care.

Other news

Although I haven't been updating this blog lately, I have been blogging elsewhere. I started Life at the U to share my college experience with my family. It's been a huge hit within my social circle, so I've been updating frequently, sometimes multiple times per day.

New look, same direction

Well, I've finally ditched my custom template for a generic Blogger template. The reason? I wanted to use Blogger's native share toolbar, and my template didn't support it. I simply don't have the time to wade into the HTML and add the feature, so it's time to bid farewell to originality and let Blogger handle my layout. That is, until I find the time to switch to Tumblr.

In addition, I've disabled comments. This blog isn't meant to be a noisy discussion by a large group; it's a platform for me to talk about what I find interesting: myself, my projects, and other things. If you'd like to respond to one of my posts, feel free to by posting an entry on your blog or sending me an email at [redacted]. I'd love to hear from you!

Neocubes mini review

I can't remember what I did before I carried a Neocube around with me. I must have waited quietly at doctor's offices, staring blankly at the walls or perhaps skimming the ancient magazines. Now, I simply pull my Neocube out of my pocket and begin constructing a polyhedron. If I don't have long to wait, I'll wrap the chain of spheres into a solid tetra- or icosahedron. If the other waiters are glancing at watches and complaining about the wait, I'll attempt a modular dodecahedron or a wireframe truncated icosahedron. I can fight off boredom for hours when I have my Neocube with me.

However, I'm not the only one to enjoy playing with a Neocube. Every person to which I've shown my Neocube, from little kids to my own Grandpa, has been mesmerized. Some people make jewelry, some construct flat shapes, and some just like coiling the chain of magnets, but everybody enjoys playing with them. My extended family liked playing with my Neocube so much that I purchased a big batch for gifts.

Neocube is one of the best pocket-sized time-waster I've ever seen, comparing favorably in wait-time compression with the iPhone and iPod Touch. If you want to have a 'cube of your own (and send me some pocket change), you can buy one from Amazon for only $16 (at last check). Don't miss this deal!

You. Will. Be. Cancelled!

The words popped up every few sentences, turning the already repetitive lecture into a free-form poem of dullness. The comptroller missed no opportunity to remind students — in broken English — that there would be consequences for missed late payments, including cancellation and late fees. He loved to use the phrase "It's gonna cost ya!" to emphasize that the comptroller's office would be more than happy to take your money.

The USF comptroller's presentation dragged on for an eternal fifteen minutes before the incident. The comptroller asked a simple question about the repercussions of a missed deadline, expecting to answer it a second later. Instead, a student in the balcony shouted "You. Will. Be. Cancelled!" and laughter rippled through the auditorium.

Suddenly, the atmosphere of the lecture changed completely. When the comptroller concluded the answer to his own question with "You might be cancelled," the audience burst into laughter. He immediately recognized his newfound catchphrase and began using it to spice up his presentation. He loosened up, and the students began listening intently to wait for the next catchphrase. When he concluded his presentation with "Don't get cancelled!" the entire audience applauded loudly.

In my opinion, this dynamic lecture was the highlight of the whole orientation.

Porting OpenInkpot: the Hanlin V3

Ten days ago, I received device that will monopolize my summer: the Hanlin V3. The performance of this e-reader — or rather the lack thereof — is the primary motivation for my project. According to the OpenInkpot community, this device has a slow processor and little memory. My project's goal is to reduce the memory footprint of OpenInkpot in order to improve its performance on devices like the V3. I decided to purchase the V3 to better empathize with the benefactors of my project and to help motivate myself. If I want a faster e-reader OS, I must build one for myself!

I'd like to write about the V3 soon, but I haven't used it enough to make a fair assessment. Thus far, it appears that the device deserves its reputation for sluggishness; however, I won't speculate on the source of the poor performance. I'll write more later.

GSoC project status update

Now that I've finished this semester's final exams, I've started working on my GSoC project: porting OI to uClibc, the featherweight C standard library. I'll post project updates periodically, saying what I'm doing and relaying what I've learned. I promise they won't all be this boring.

The first step of my project is adding my new architecture, Linux based on uClibc, to dpkg, the foundation of the Debian package management system. dpkg plays a part in packaging code, installing applications, and compiling binary packages; it's a very important tool. Before I start modifying dpkg, I plan to learn about dpkg and the relevant build systems; I'm starting by reading the Debian New Maintainer's Guide.

I'm a GSoC student!

After months of hard work, I was chosen by the OpenInkpot organization to port OI to uClibc. I will be spending my summer reducing the memory OI consumes to allow it to run on e-readers with little memory. If you're curious about the Google Summer of Code, check out the official FAQ.

Port OpenInkpot to uClibc

This GSoC proposal is for OpenInkpot, a Debian-based e-reader OS.

Project proposal

I plan to port OpenInkpot to the lightweight uClibc C library in order to improve its memory usage. Here are some of the other benefits this project could provide.

Possible benefits

• Increase number of devices on which OI could run
• Improve performance
• Decrease compile time
• Reduce firmware transfer and installation time
• Simplify porting OI to other architectures

Plan of action

Follow these instructions for porting IPLinux to a new architecture.

1. Acquire target device (my own e-reader!)
2. Add new architecture identifiers (uclibc and ucarmel) to dpkg.
3. Build and package toolchain for new arches.
4. • Cross-compile existing packages to new arches with toolchain, starting with most important packages
   • Build and test firmware once the necessary packages (uClibc, dpkg, and BusyBox) have been packaged
   • Test packages on device with chroot
5. Test complete firmware and allow autobuilders to start porting packages to new arches

Background

Programming experience

I've been programming for about two years. I've primarily used five programming languages: Javascript, PHP, ActionScript 3, Python, and C++. I've finished several small independent programming projects, but two in particular have taught me important lessons.

Last fall, I created an example game for Pygame2, a low-level Python wrapper for SDL. The game ran, but it was worthless as an example because my clumsy graphics abstraction obscured the underlying Pygame2 graphics calls. From this failure, I learned to never lose sight of the purpose of my project. My initial announcement for the flawed example.

Earlier this year, I decided to rewrite my Flash app for drawing snowflake patterns with Javascript and SVG. Once I chose the right data structure, the whole library fell into place. This project taught me that few programs must be complex; with enough thought, you can find a simple solution to many complicated problems. Read more about the SVG snowflake micro-library.

Personal qualities

I'm hard-working

When I am assigned a task, I feel compelled to do it as well as I can. I find it difficult to walk away from an unfinished task.

I'm self-motivated

Events in my life have taught me to work independently and seek out my own answers. When I discover a problem I don't know how to solve, I start looking for a solution. I check any relevant manuals, search for tutorials, look for examples, and — if I still haven't found a solution — ask for help. Finding answers on my own gives me a feeling of satisfaction and accomplishment.

I love programming

Writing code is my favorite hobby, and I will someday make it my profession. I'm not participating in the Google Summer of Code because I really need the money or I want another bullet point for my resume; I'm participating because I want to create software and learn more about software development.

Open-source experience

In addition my recent OI patch, I've spent some time working with Pygame2. While developing an example game with the unstable development version, I found, isolated, and reported several bugs.

GNU/Linux distributions development experience

I've used Ubuntu for about a year, learning much about Linux and Debian. I've become proficient at finding, installing, and upgrading Debian packages. I packaged my first .deb and started my own repository in order to test my fix for Ticket #834. I've compiled my share of source code, and I'm familiar with the GNU build system as both a user and a developer. I've written several bash scripts, and I'm comfortable with the major Unix commands and concepts. I've even spent some time configuring and troubleshooting the GRUB bootloader.

Kernel hacking

Unfortunately, I haven't worked on the Linux kernel yet.