On Thu, May 26, 2005 at 07:03:04PM +0200, Felix Rabe wrote:
Hi everybody,
As I have some time until July for "doing nothing" a few hours a day ;) , I'd like to volunteer for doing something, ie. Inkscape things. I'm learning C++ currently (Stroustrup's book). I use Ubuntu Linux on i386 and did quite some programming using Python and PyGTK in the last few months.
What is needed / do you use aside from cvs, g++ and a text editor? (And
For me, that's pretty much it, although I've found a few other tools handy:
`grep -sr` comes in quite handy to locate strings in the codebase.
gdb is worth learning if you plan on doing bug fixing or solving crashes.
For gtkmm, probably my most useful tool is the gtkmm.org website, since it has all the docs for the code. ;-)
what text editor, as I used Emacs, tried Vim, and use gedit currently. No flamewars please, I'm glad there are so few of them here :o) , just "I use editor foo (because ...)".)
I spent a summer back in an internship during college teaching myself emacs, so that's all I use.
Do you use Valgrind, any test suites, gdb / ddd ... ? Where do I start to learn how to use them?
I probably wouldn't worry about this too much at this point, were I you. Get comfortable coding and compiling first.
gdb is worth learning, but there's only a few commands that you really need to learn - run, bt, break, and step.
Again, though, as I said above, gdb is useful mainly for bug fixing; for regular coding activities I rarely use gdb.
If you get interested in doing performance optimization, there are some handy tools for that like gprof. See the 'Profiling' page I wrote in wiki for directions.
Also, do you recommend some literature / books, as I did not (and most probably will not) study computer science? (I have a "Design Patterns", Gamma et al, here.) I have a small budget for good material.
Make sure you have a Linux commandline reference guide (I like the O'Reilly one), and a C++ reference of some sort, that includes coverage topics like templates and the STL data structures. Plus I guess whatever other books you find interesting/useful. I grabbed a Gnome book a few months back since I was planning on working on the gtkmm stuff, although it turned out to not have much about gtkmm in it so I found the gtkmm.org website more directly useful, and just used the book for background info.
I am also self-trained in CS; my schooling was in regular engineering. The areas I had to spend time on, beyond just learning the details of the programming language, were data structures, code optimization, and OO architecture & design. IMHO, the best way to learn is through application - i.e., code, read, code, read, code.
Working on an open source project like this is probably the perfect way to learn this, since you can watch and interact directly with skilled coders, and question them about the reasons for why they do certain things, and get direct feedback on your own coding.
Design Patterns is useful if you are planning on doing architecture level work. For a mature codebase like Inkscape you'll probably be doing more refactoring work than architectural work, however DP can help you identify and understand Inkscape's internals a little better. However, from a more practical standpoint I would recommend the book 'Refactoring'. Also, I recommend studying mental's coding style closely, he's the best refactorer I've ever met, and just looking at the techniques he uses for gradually converting the code teaches you a lot.
I also wonder about more exotic things - do you print out code you wrote for review (my printer doesn't work atm), do sports, drink coffee (I'm not going to do that, just wondering), gather regularly on Jabber - anything that might be of interest in terms of a programmer's life and how to get / remain productive.
My printer isn't even hooked up to my Linux machine. ;-) (Pretty much I use it only for printing copies of my tax forms and the occasional map.)
Regarding productivity, whenever I start even a modest project, I'll start a todo list. Then I pick a goal and work towards it; during the process I notice all sorts of other things that are needed, but instead of shifting focus to those, I just add them to the end of the todo list. That way (in theory) I don't get distracted from the matter at hand, but don't forget whatever the item was.
Sometimes being on Jabber is a plus to productivity; for instance it can be handy if you're stuck on a problem or need background info about some code. In general, though, it tends to reduce productivity since it's so distracting. ;-) That said, you can learn to tune it out and catch up while you're waiting for compiles to finish. ;-)
Good practices include committing your code frequently (either to CVS or through patch submissions). I try to commit whenever I've completed a set of changes that work properly. Don't intentionally check in broken code, but also strive to avoid working too far out of sync with the main codebase.
Beyond that, just have fun and take time to take pride in your work. :-)
Bryce