Creating a Personal Project

Question

Again I concede the great and wise S/O:

I am thinking about putting together a personal project to help me learn Ruby better (!rails) and GUI programming.

I am probably going to do MacRuby but could do wxRuby or something else as well.

So I wanted to get some options on how to guys decide on personal projects.

That aside, what are some good idea for a personal project that will be:

1. Fun to do.
2. Difficult enough to learn from.
3. Expose me to a wide variety of concepts that I might encounter in the real word. Ei. Using different libraries to deal with different types of data and networking.
4. Possibly useful, (this is less of a concern than the learning experience)

Furthermore, when building a large project by yourself how do you begin to get organized? UML, drawings, or some other method.

Thanks for the great answers in advance.

Answer 1

Hi, This maybe is a little of topic but you said you where looking at MacRuby and wxRuby for the windowing toolkit. I think you should also add shoes (http://www.shoooes.net/) into the mix of toolkits you are considering. It works on Mac, Linux, and Windows and has a very ruby like API.

As for an idea about what type of program to create, what about creating a nice git interface? I know for me personally it would be great to have a nice local view to view the repository history.

Answer 2

How about going for a project on which you have worked on earlier, although, in a different language/platform. See if can be implemented as is or any part/module that you can develop.

This will help in a way that you exactly have the requirement and the desired output and hence this will help you to focus.

For personal development, I will say one needs at least

• Requirements jotted down on a sheet
• A bit of designing in terms of overall application architecture
• Lots of hard work
• A lot of Googling.

Answer 3

What do you wish existed? Write it!

Seriously, the less structure you impose on a personal project, the better. But I would start with some simple guidelines:

Start small. Think of something that you can get mostly working in a day or so. At the absolute most, a week.

Just like writers should "write what they know," you should "code what you know" or at least what you wish you knew. Pick a project that matters to you. Don't be afraid to re-create something that already exists. Do you wish you had better syntax highlighting? Write something to do syntax highlighting. Do you wish there was a better search engine? Write one. Think of something you do all the time, and figure out how to make it easier or more fun to do that.

Write unit tests. Until I started incorporating them into my daily coding, I always thought of them as something that was a safety net, but really they're just an easier way to write code. I know everyone already knows this, but it's worth repeating. Just because you're not writing a multi-person project, don't avoid unit tests. They'll make your life easier and give you a better sense of progress.

I wouldn't worry a whole lot about organization. For god's sake don't bother with UML. Sketch, think, draw, if you have access to a whiteboard draw all over it, brainstorm with your friends -- preferably in real life! preferably with argumentative ones! -- also don't be afraid to write code even if you think it's wrong. Write, test, think, refactor, repeat. Your editor, compiler and debugger are a great sketchpad.

Most importantly, have fun! Do something you'll enjoy! If it's an onerous task you won't learn much. If you're solving a problem you want to solve -- even if you don't solve it as well as others already have -- you'll learn, and that's the point, right?

Answer 4

Sketching is what I do most of the time. Just sketch out how a UI looks or how a few classes interact - it helps you put the big picture together.

I also start writing code. If I think I'm going to need a net module, for example, I might write the high level interface out for it:

void DataRecive(SocketDataArgs& args)
{
    Command* cmd = CommandFactory::CreateCommand(args.ReadString());
    cmd->Init(args);
}

ISocket* socket = SocketFactory::InstanceSocket();
socket->Connect("localhost", 4500);
socket->OnDataRecive() += &DataRecive;

(yes I did implement a delegate system in C++ that allowed for syntax like that, and yes it was awesome, and yes I know boost already did it :p)

It would be longer then that but the idea is for me to get the high level interface of my code figured out.

The next thing is Unit Testing. That is where you write a code snippet like the one above before you write the actual classes. Then you work on the classes until the unit test does what was expected. This again, allows you to figure out how your code all fits together.

And finally, you would want to take "steps." Figure out which components you can nail down in a short timeframe and get those done first. The more individual components that make up your project the easier this is. That way you have a sence of satisfaction every step of the way and the last portion of the project (putting things together) works great. Unit testing makes this easier.

I don't know Ruby at all, but these are very general programming techniques that will help you even in a professional position.

Answer 5

You could always scour GitHub for any existing open source projects using wxRuby and see if they had a TODO you could contribute to. There's plenty of existing projects with a lot of issues queued up in their trackers.

Answer 6

I had this same question.

First I spent time brainstorming something that would be fun to build but not necessarily useful. I wanted something that would hold my interest beyond just a neat tool. You may want a tool, and that's fine, but realize that tools are usually simple and do only one thing. You could choose to do one big project or lots of little tools.

Second, I thought extremely long term and figured out what language/technology/platforms I would need to achieve those goals. Those long term goals are not necessarily achievable, but they do help one get excited about the project, and help you to choose language/technology/platforms that won't prevent you from reaching those goals.

Third, in terms of organization, I use a mind mapping tool to capture and organize my ideas. The mind map helped me keep both long and short term goals, and helped me figure out where to start first. Finally, I created a tiny road map and limited each iteration to only a few, achievable tasks. The first tasks were stuff like setting up SVN, creating main(), and writing skeleton code. I keep editing the mind map and road map, adding new features first to the mind map, then figuring out where they go in the road map. I implement only from the road map.

On organization, I only use in-code comments as documentation, but I also scatter readme.txt files within each package/namespace/directory to leave a bread crumb trail for me and potential other users. (I consider those higher-level comments.) I don't use UML or anything because UML can be time consuming to update when you are the only developer and you are doing this in your free time. I aim to make the current code structure obvious and simple, with no future functionality built in. When I add a new feature, I refactor to keep that new feature as obvious and simple as all existing features.

GL, and the most important thing is to find something you will not grow tired of. (I went back to a tiny little game I wrote on a TI-82 calculator over 10+ years ago for my project.)