Somewhere in there...

I has surrounded it!

Many thanks to Ben for making my post with the clunky attachment with tons of questions readable  :)

The Intern's Desk

My Desk 

As an experiment, I decided to keep my to-do list on my wiki homepage.

My main problem is that there is so much I need to read, it can seem like I'm doing absolutely nothing.  (It also feels that way!)

Oh well, little by little, as the cat eats the fish:

[PATCH] OPW 2013: Build System Gtest Addition

Details can be found here:
[PATCH] OPW 2013: Build System Gtest Addition

The original project proposals can be found here:

My First Blog post (Hello World reloaded)

Swimming Lesson Progress...

...going swimmingly....

(Have a break.  Watch Catweazel :)

Happy Birthday to me!

Let's get cool in the apr_pool

This week, I'm taking swimming lessons: Object Oriented Programming with ANSI C & apr_pools.h File Reference.

Outlambda'd !

So, I decide to mail a MUD friend with my OPW success to brag a little about my 'Supersize Me' coding experiment and he shows me his 'Superconcise Me' project!

 *DRUMROLL*

John Tromp scooped "Most Functional" in the 2012 International Obfuscated C contest!

       Int L[A],m,b,*D=A,
        *c,*a=L,C,*U=L,u;s
         (_){u--&&s(a=*a);}
          char*B,I,O;S(){b=b
           --?b:m|read(0,&I,1
            )-1;return~I>>b&1;
             }k(l,u){for(;l<=u;
              U-L<A?*U++=46^l++[
               "-,&,,/.--/,:-,'/"
               ".-,-,,/.-,*,//..,"
              ]:exit(5));}p(Int*m){
             return!*U?*m=S()?U++,!S
            ()?m[1]=p(++U),2:3:1,p(U)
           :S()?U+=2:p(U[1]++),U-m;}x(
          c){k(7*!b,9);*U++=b&&S();c&&x
         (b);}d(Int*l){--l[1]||d(l[d(*l),
        *l=B,B=l,2]);}main(e){for(k(10,33
       ),a[4]-=m=e-2&7,a[23]=p(U),b=0;;e-2
      ?e?e-3?s(D=a),C=a  [3],++1[a=a[2]],d(
     D):c?D=c,c=*D,*D=    a,a=D:exit(L[C+1])
    :C--<23?C=u+m&1?O      =O+O|C&1,9:write(m
   ||(O=C+28),&O,1)+        1:(S(),x(0<b++?k(0,
  6),U[-5]=96:0)):(          D=B?B:calloc(4,X))
 ?B=*D,*D=c,c=D,D[            2]=a,a[++D[1]]++,D
[3]=++C+u:exit(6)              )e=L[C++],u=L[C];}

I don't know the name of the program(this is the obfuscated C contest after all...), but I think it's the Lambda beast.  

And suddenly the Subversion octopus does not look quite as scary anymore, relatively speaking (however, no easier at all!)  If the 'Lamda beast' was a song, I think it would sound like this:

Gratz John, and thank you for a lovely coding perl!

Make work -- wasting the world's time...

Example offenders:

The person who coded the change to the mouse wheel in Firefox without restoring the original behaviour.

Most users will end up looking the fix up and applying it because the current set behavior is annoying.  That's 5 minutes of the their lives they won't get back, now multiply this a few million times and it's quite a massive time sink.


The people who decided that <tt> is going to be obsolete in HTML5.  

The Subversion website has 2559 <tt> tags and as many closing tags.  In theory, a simple find-replace will suffice, in practice that's 5118 changes that can go wrong.  Billions of hours will be wasted on this repair job all over the world :(

Time is the only true possession we have.  Don't waste it.

How long should learning to use application X take?

(Music: I can't get started)
I don't often write essays or letters, but when I do, I use
LaTeX, the typesetting system.

Why?  Well, LaTeX produces beautiful quality that no other application manages. I have one template for letters and one for essays, and at some point, 12 years ago, I learned to use ~20 commands, and now I am a proficient LaTeX user. 

LaTeX sounds like an impressive, complex skill that is tough to learn, but -- not if you have the right walk-through.  I can teach anyone how to use LaTeX to my (low low) standard within 60 minutes at the most.

If basic LaTeX use can be taught in an hour, then nothing else should take much longer than that.

But it does.  Often, writers prefer to teach rather than produce walk-throughs, with the laudable aim of empowering users with knowledge.  But sometimes I don't want to learn, but just get from A to B so I can continue on my merry way.  And even if I come to study, reading the walk-through first gives my learning experience a solid structure to build on.

You can judge the true quality of a tailor by what they can do for their fattest customer.  Likewise, you can judge documentation by how useful it is for the thickest, laziest, busiest user.

Dress to code -- sew cosy sleeves

Sitting at the keyboard leads to having cold forearms, which in turn, results in cold hands.  Turning the heating up usually ends up with me being too warm, whilst my hands and arms still remain icy.

What is needed here is sleeves -- which are so practical (and decorative) but never found on sale anywhere.

I make mine like this: Cut 2 patches of stretchy material (velvet, cotton, lycra, etc) so that you have wrist + 4cm at one end (so it can slide a bit over your hand) and elbow + 3 cm, and as long as your arm, so that you get a nice crinkle effect and the entire contraption is comfy.

Hem broadly on both ends(so it sits well and does not roll, 2cm at the wrist, 3 cm at the top), sew together lengthwise with 0.5cms seam allowance, job done.

Trophy time!

My first bug report in the Subversion issue tracker.

Ok, I'm now ready to re-board my pumpkin carriage and continue to travel the stony road to learning how the Subversion build system works :)

Contribute documentation as you learn

If you ask on the dev list for advice and are not pointed to the man page, FAQ or other such document for the answer, then chances are high that what you've just been taught should be documented.

Working on the documentation is a good way of keeping your momentum going(there is _always_ something to be done) and beginners often have a talent for flushing out problems,  because they only have the information that is accessible for them and usually they take instructions literally and think in a different way to experts.

This often is a quite valuable talent, so use it whilst it lasts.

Sleep!

Sleep can be a bit difficult to catch when there is so much going on in your mind whilst learning so many new things.

Here is my trick:  I listen to an audio book I know quite well (so that I don't feel I miss anything if I drift off).

My two favorites are:

The World's Lumber Room, which is beautifully written and read by a lady with a lovely voice.  All you ever needed to know about what happens to the world's decaying matter!

The History of Rome Podcast, gripping stories about long dead Romans and their wars, 20-30 mins in length, and there are 179 of them, so you will not run out of soap opera material anytime soon.

How to Mess up a Patch [Pt. II]

Failures are are a valuable part of the learning process, but no-one likes to repeatedly have failures in public -- the dev mailing list is quite a public place, and being a rookie among so many good coders is quite intimidating.

So it's easy to get stage-fright here and start to feel a little bad about your performance -- it's a totally healthy reaction.

However, don't get bogged down, but always analyze how you arrived at the failure and if in doubt, listen to Zappa:

Finally, remember, your mistakes currently are simple ones.  As you get better, your mistakes will get more sophisticated, and you'll end up thinking fondly of the time when a white space or a simple procedural error was your biggest problem.  So, enjoy this happy time whilst it lasts :)

How to mess up a patch [Part I]

Strictly speaking, this should have been [Part 15] or so. I keep making mistakes, and it is not for want of checking -- my 'spidey sense' just isn't honed and there is quite a bit odd detail to be observed. Lucky for me, the Subversion team are eagle-eyed and patient!


So what went wrong in today's patch?  Let's count the ways:

1.  I didn't take a break before proofreading.
2. My original goal was to do A, then I found that doing B was superior, but then claimed I did A instead of B in the log message.    Always check your entry and exit contract.
3. I assumed something weird and didn't question it. What I should have thought instead was: how odd! and investigated.
4. I didn't consider that two Apache sites would have uniformity in architecture, concept and appearance.

All this looks perfectly obvious in hindsight, but actually, it's not so trivial.  It's not that the individual tasks are difficult, it's just that there are so many of them!

Pre-Internship Patches

Here is my collection of accepted patches so far:

[PATCH] Test for line ending bug in svnrdump (issue 4263)

[PATCH] Fix for "\r" in "svnrdump load" (issue 4263)

[PATCH] Update to out-of-date code comments

[PATCH]: Re: Proposal for OPW project(get-deps.sh I)

[PATCH]: Re: Proposal for OPW project(get-deps.sh II)

My First Blog post (Hello World reloaded)

The Apache Foundation Subversion team has accepted me as their Gnome Outreach Program for Women intern for the next 3 month.

My current project list is as follows:
Community Guide: complete the 3 patches that are due, 2 minor changes, one section on how to make changes to the website ETA : Week 1

Add gtest to the build system for C++ Bindings. ETA : week 3
The svn diff project: Bug 2044 and Bug 2447 ETA : week 6

The svnadmin freeze project ETA : week 12

+ other bugfixes as directed
+ projects discovered by grepping for 'FIXMEs' etc
+ another project if I happen to run out of work :)

Those are very conservative estimates -- I have not coded anything in 10 years and so, I have no sensible way of estimating how long I will need to complete this.

My goal is to code as much as I possibly can and see just how much I manage (re)learn in 3 month -- I've never worked with coders as good as are on the Subversion team, so this is as close to 'Supersize Me' as one's coding hobby can get.

Maybe it can be done, maybe it can't. I'm going to try!