Borkopolis

May 11, 2011

Give your brain what it wants

Filed under: 20-minute,meta,skills — Mark Dalrymple @ 12:05 pm
Tags: , ,

Grumpy badger

You feed your body what it wants. You want to feed it what’s healthy. I know when I have a craving for something like broccoli, I treat myself to broccoli. There must be something in those wonderful tiny little trees that my metabolism is jonesing for.

The same thought applies your brain. Feed your brain what it wants. If you’re lucky, your brain will want what’s good for it. I know my head goes on kicks: “I want you to read as much about iPhone programming as you possibly can.” Reading programming books at this time is very pleasurable. I drop lots of money on books and end up reading all of them cover to cover, usually in my “leisure time”.

Later on brain says “OK, I want to learn as much about photography as you can.”. When that happens, I absorb photography books and websites. If I tried to feed my brain programming books now, it’ll balk, complaining like a 4 1/2 year old. “no no no no I want Photography NOW.” So I shelve the rapid learning of programming and dive into photography. Currently my brain is on a kick learning about the process of writing long-form fiction. I have no idea why my head wants that, but I’ve been having a great deal of fun reading about how to write mystery novels and NaNoWriMo.

I’m a huge fan of throwing lots of data at my brain, hoping some (or most) of it will stick, but I’ve learned that force-feeding my brain what it doesn’t want doesn’t always work well. Sometimes life interferes and I have to learn about Location Services or the MapKit when I’d rather be reading about f/stops and lighting ratios, but for the most part, I keep my discretionary reading time on stuff my brain wants.

I directly attribute my better-than-average skills in balloon twisting, programming, and photography to feeding my brain what it wants when it wants. All of these hobbies require direct physical application, but without that fundamental layer of information I build, I know I would have wasted a lot of time in the application and practicing phase of learning my crafts.

Just like you shouldn’t always feed your body pizza and delicious soft-serve non-dairy ice-cream-like cold sweet substances, you should be choosy what you throw at your head. An occasional snack of Jersey Shore or America’s Next Top Model won’t destroy your mental health, but you’ll want to consume higher quality materials for the sake of your brain.

May 7, 2011

Balloon Tools I Use

Filed under: 20-minute,balloons,skills — Mark Dalrymple @ 2:00 pm
Tags: , ,

Bloon bag

I don’t make balloon animals for a living, and I don’t consider myself a pro, but I do think I’m pretty good. Check out that look of joy on the frog picture at my getting started with animal balloons. It’s awesome being able to surprise and delight people.

Aside from the collection of balloons I use, I have a couple of tools that I use.

My favorite balloon accessory is my Twist-em-Up Busking Bag, seen up above here. You can hold several hundred balloons (maybe a thousand? I haven’t counted) in the middle. The 160s, 260s, and 350s live in the middle. There are four pockets around the perimeter that hold my specialty balloons. One pocket for geo blossoms, one for hearts, one for 321B bee bodies, and one for happy faces and aliens. I might have some white rounds for eyes, but typically I don’t carry a bunch of rounds. Each of the pockets have a couple of high bouncy balls.

The first tool in my arsenal is a small pump, a 160 Blaster that I keep in the middle of the bag. It fits perfectly in the space that doesn’t have any balloons in it. I can’t mount-inflate 160s, so I use this pump when I need to inflate a small balloon. It’ll inflate larger critters if my mouth is exhausted at the end of a long day.

Another is the T.Myers Ball Putter. This looks like a piece of wood with a nail in it, but it’s actually a piece of wood with a nail in it. You use this to put balls inside of balloons. Basically you stick the ball on the nail, shove the stick into the balloon, pull off the ball and pierce the skin of the balloon with the nail, and the ball falls into the balloon. Re-tie and twist your creature. Balls inside of balloons are very popular, because most folks have not seen balls inside of balloons, and wonder how they got in there. My friend Mr Kebbin drilled out the handle and attached a lanyard for me, which makes it easier to keep up with.

Speaking of stuff inside of balloons, the Magic Pipe is another tool. It’s a tube with a spike on the inside. Anything that fits in the pipe can be put in a balloon. Rings. Coins. Sugar. Water. Pushpins. I like making a clear dog with a sharp pushpin in the belly. Plus, this thing makes a really cool sound. You do need to be careful that someone doesn’t pop it – high velocity pushpins could be bad news. The magic pipe is even faster than the ball putter for putting stuff in the balloon, but unfortunately bouncy balls don’t work in the magic pipe.

When I’m doing a job, like the First Lutheran easter egg hunt or a Take Your Offspring To Your Place Of Toil Day, I’ll be wearing my T’Snippet around my neck. This thing is a Canadian milk pouch slicer. It’s awesome for taking off unwanted nozzles or knots, as well as cutting off the end when I need to deflate the rest of the balloon.

My final tool is one that’s not available, because it was custom-made by a friend of mine. Mr Kebbin took some industrial-grade solder and made a shepherd’s crook kind of thing. This tool is great for double-stuffing balloons, as well as doing a deep tulip or hook twist. It fits in the middle of the busking bag with the 160 Blaster.

The tools have pretty specific purposes, but it’s great to have them when you need them.

 

May 6, 2011

Blast from the past : grpof

Filed under: history,programming,skills — Mark Dalrymple @ 1:48 pm
Tags: , ,

Dino rific

I stumbled across this little tutorial I wrote back in the mists of time, probably around 1996 or 1997.  And it was based on a tutorial I wrote at Visix, probably in 1993 during one of our Optimization Parties.  It describes how to read the output of gprof, a profiling tool available on most unix systems.  It’s even still there on Mac OS X.  So you kids with your fancy Shark and Instruments, here’s what some of your elders used.

gprof is not a GNU tool, even though it has the leading “g”.  That “g” probably stands for “call Graph” profiler. You’ll need to check your system’s documentation (e.g. man gprof) for exact instructions on getting gprof to work, but usually it just involves compiling and linking with -pg, running your program, and doing gprof gmon.out > oopack.

Here’s a 300K sample of output from gprof on the Dec Alpha if you want to take a look at it. This particular report is from a run of AOLServer 2.2.1 which involved fetching index.html 53,623 times.  The links that follow go to anchors in that 300K sample.  What was I wanting to profile?  I wanted a gut check to make sure that life in the server was sane, and if there were any obvious bottlenecks that maybe I could address if I had the time.  The test was to fetch index.html over and over again.

There’s 4 parts to gprof output:

  • Built-in documentation: Short form of everything here, and more.
  • Call-graph: Each function, who called it, whom it called, and how many times said calling happened.
  • Flat profile How many times each function got called, the total times involved, sorted by time consumed.
  • Index: Cross-reference of function names and gprof identification numbers numbers.

When I first start looking at gprof output, I go to the flat profile section. The big time consumers are usually pretty obvious. You’ll notice that each function has a [number] after it. You can search on that number throughout the file to see who called that function and what functions that function calls. Emacs incremental search is really nice for bouncing around the file like this.

Here you can see that DString is a big time gobbler:

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 17.7       3.72     3.72 13786208     0.00     0.00  Ns_DStringNAppend [8]
  6.1       5.00     1.28   107276     0.01     0.03  MakePath [10]
  2.9       5.60     0.60  1555972     0.00     0.00  Ns_DStringFree [35]
  2.7       6.18     0.58  1555965     0.00     0.00  Ns_DStringInit [36]
  2.3       6.67     0.49  1507858     0.00     0.00  ns_realloc [40]

Out of 21.05 seconds of total clock time, Ns_DStringNAppend consumed about 4 seconds, or about 18% of the time in and of itself. It was called 13 million times.

MakePath consumed one and a half seconds itself, and its children consumed three and a half seconds. At least one individual call to this consumed 0.01, and at least one individual call took a total of 0.03 seconds in MakePath and its children.

Handy tip – the function numbers in brackets are approximately sorted by time consumption, so a function with a [low number] will generally be more interesting than one with a [high number].

Now that you know that Ns_DStringNAppend is called a bunch of times, this could be a useful target for optimization, I’d look at its entry in the call graph section.

Before doing that, just for illustration, take a look at AllocateCa [33] since it has all of the interesting pieces of the call graph in a more compact size:

                0.04        0.18   53622/160866      Ns_CacheNewEntry [62]
                0.04        0.18   53622/160866      Ns_CacheDoStat [58]
                0.04        0.18   53622/160866      Ns_CacheLockURL [64]
[33]     3.0    0.11        0.53  160866         AllocateCa [33]
                0.16        0.17  160866/321890      Ns_DStringVarAppend [30]
                0.06        0.00  160866/1555972     Ns_DStringFree [35]
                0.06        0.00  160866/1555965     Ns_DStringInit [36]
                0.04        0.00  160866/1341534     Ns_LockMutex [43]
                0.03        0.00  160866/1341534     Ns_UnlockMutex [53]

The entries above AllocateCa [33] are the functions that call AllocateCa. The entries below that are the functions that AllocateCa calls. There are two numbers separated by a slash: the first number is the number of calls that the function has made, while the second number is the total number of invocations of that function.

In other words, for 160866/321890 Ns_DStringVarAppend [30], AllocateCa called Ns_DStringVarAppend 160866 times. Across all of AOLServer, Ns_DStringVarAppend was called 321890 times.

Similarly, for 53622/160866 Ns_CacheNewEntry [62], means that Ns_CacheNewEntry called AllocateCa 53622 times, and AllocateCa was called 160866 times total.

So, just by looking at this snippet, you know that the three Ns_Cache functions each call AllocateCa about once per serving of index.html, and that AllocateCa makes a single call to Ns_DStringVarAppend, Ns_DStringFree, etc… each time. What’s also interesting to note is that someone is calling Ns_DStringFree more than Ns_DStringInit. This may be (or may not) be a bug in AOLServer. You can go see Ns_DStringInit and Ns_DStringFree yourself and track down who the culprit is.

The floating “3.0” on the left is the percent of total time that the function consumed. The two columns of numbers are the amount of time (in seconds) that the function consumed itself (AllocateCa took 0.11 seconds of time total to run its own code) and the amount of time in the function’s children (0.53 seconds were spent in its children)

Getting back to real analysis of DStringNAppend, you can see that MakePath made 50% of the Ns_DStringNAppend calls. Since you know that there were 53623 fetches of index.html, that means that for each page, MakePath was called twice, and for each call to MakePath, Ns_DStringNAppend was called 64 times.

If one call to MakePath could be elided (since it’s getting called twice), or if fewer than 64 Ns_DStringNAppends could be done per call, we could see a performance boost.

Just browsing the gprof output can be an illuminating exercise. If you have a gut feeling that a particular function is a hot spot (say, Ns_LockMutex [43]), you can see the call graph for that function, see if it’s consuming lots of time, or if it’s being called a whole bunch.  Here it was called 1,341,534 times, or about 25 times per page serve. Maybe that’s high.  Maybe that’s right.  Sometimes a suspected culprit isn’t there, or you find a surprising time waster.

Because this sample gprof output was done on a Dec Alpha system, there was some suckage involved, such as no explicit time recorded for system calls. So we don’t know if, for example, select() blocked for a long time on each call.

(slightly edited and re-posted over at the miniblog)

 

May 5, 2011

How to Sight Read

Filed under: 20-minute,music,skills — Mark Dalrymple @ 10:56 am
Tags: , ,

Banned music

I’m a pretty good sight-reader, and I’ve written about that before. Put most (reasonable) pieces of music in front of me and I’ll be able to play them. Over the years I’ve built a system where I can get a feel for a piece before playing the first note. I’m usually in an ensemble situation, being in a band or orchestra or a quintet, where you have a little bit of time between getting your part and when you have to start playing.

I look for places where things change. Those places will be where you have the highest probability of messing up during playing. It’s easy to get lulled into nap-land with a long string of whole notes only to discover that you have a run of sixteenths after the page turn.

First, I glance down the part from beginning to end. I look for keys. What’s the opening key? Are there any key changes in the middle? Are the key changes related? Going from C to C minor is pretty easy for my brain to handle. Going from Db major to E major, not quite so easy. Does the key change often, or is it fairly stable?

Next I glance at the tempo markings. Is it something slow? I like slow. Slow makes easy to get the notes in. Look for tempo changes throughout. Does it go from Gravé to Presto?  That’ll probably be a tough spot.

Next up is the road map. It’s embarrassing to be the only one who takes a repeat. You might be lucky enough to have a group that reacts consistently when faced with repeats in a new piece, but this would be a good question to ask otherwise. A simple “are we taking repeats?” takes away some of the stress. Don’t forget in some situations you don’t take repeats on a D.C. Be aware of the rules different styles of music have. Also be aware that some pieces naturally have complicated road maps. Waltzes, minuets, and polkas tend to be the worst. Concert band marches tend to be the most predictable.

Look at the page turns. Is there evil lurking just over the fold? Jot down a little note or a big “V.S.” to know there’s no prep time after you turn the page. You may have been given a photocopied part that’s offset by one page, so the nice page turn rests the composer gave you are now in the wrong place, and your page turns happen in the middle of a phrase. You’ll need to figure out now how you’ll handle that. Can you play this phrase with one hand while turning with another? Can you mentally grab a couple of notes and turn before it’s time?

Next I look for big blobs of scary notes. What are they made of? Is it a bunch of scales and arpeggios? If so, I can handle that. I might pencil in the name of the scale as a reminder. If not, this will be the parts that I silent practice until it is time to start.

Dynamics! Most avocational musicians are terrible about dynamics, especially quiet dynamics. Look for the ff and pp passages so you know what part of the dynamic range of your instrument you are aiming for.

Look at the last measure, especially if it is a march. Most marches have a stinger at the end. But many do not.  You do not want to be the only one to play a stinger at the end of a march that doesn’t have one.

Finally, it’s good to be very aware of what’s going on around you. A section that looks scary might be a unison part everyone is playing. It’s OK if you grab a quick glance at the part of the player next to you and see if everyone is flurrying at the same time. The page turn that’s in the middle of a phrase might be a whole-band unison, in which case you can probably drop out and turn the page.

The worst thing you can do before sight-reading is to ignore the part, and just try playing it from top to bottom. A two minute glance through the part can show you where the hard parts are likely to be, and what parts are going to be easy. You can mentally recover during the easy parts so you can tackle the hard parts you know are coming up.

May 4, 2011

Logs is Logs

Filed under: 20-minute,skills — Mark Dalrymple @ 1:00 pm
Tags: , ,

B3K5149 pshop

Sometimes the simplest suggestions become the most powerful. Back in my first job, my VP of Engineering (Jeff Barr, now über-evangelist at Amazon) told me that he kept a simple text file of what he did over the course of a day. It’s just a quick activity log, without a lot of extra hooplah and gadgetry. I gave a try, and sure enough it’s proven to be a hugely powerful tool.

I have a file called “borklog.txt” that’s always open in my emacs session. This is the same emacs session I do all of my code editing and AMOSXP DocBook editing in, so it’s very quick to bop over to my log and jot down what I’m doing (C-X b bo-TAB RET). Keep adding little notes every day and you will build a detailed account of what you’ve done with your life. “Gee, December was a productivity nightmare” “oh that’s because I was doing an emergency backport for this programming book, and I played 37 concerts.”

The format is very simple. At the top of the file, I have any random must-do TO-DOs because I know I look at this file every day, and then there’s the daily logs. The date, a line separator, and unstructured notes about what I did.  Sometimes there’s asides when something was surprisingly hard or easy.

==================================================
friday march 18, 2011
--------------------------------------------------
landed profile stuff.
tried to do auido routing stuff, but looks like the 
MPMusicPlayerController is too high level

update play/pause button in media breakout box at updateUI time, 
so it catches pausing by unplugging headphones.

AMSOXP : move shark to a supplement. Start Instruments research.
lldb crew says it's too soon to write about. bummer

thursday march 17, 2011
--------------------------------------------------
Cocoaheads!
Got the profile layout looking good.

wednesday march 16, 2011
--------------------------------------------------
get the 15-second ease-in/out for zones. this is surprisingly hard
added Xs on profile to show where the cues actually are. can 
tap on the profile to toggle between ease-in or not.
Input gino's "Stand and Deliver" class into the ipad

These are some Actual Notes from my Actual Work Log. If I wanted to see where I was looking at lldb for AMOSXP, I use the emacs incremental search to look for ‘lldb’ or ‘AMOSXP’. I have what I’ve done when I construct my weekly progress reports. Back at Google when I did my quarterly OKR writeups, or my annual Perf Review, I frequently discovered stuff I had forgotten I had actually done. That let me pad my review (er, be more accurate). After four and a half years, my google-log.txt was over a megabyte of info. I could easily find when pushed a new release of a product to production, or when I was working on specific features for another team.

I usually transcribe meeting notes into my log. That way I can see what day a meeting happened and what was said. I can type fast enough I can usually label who said what. This is very handy for conference calls, especially after the fact. “Uh, I remember you saying that we were not going to be doing the snoozlebarf feature now, instead that’ll be folded into the next version of Google Desktop.”

When I was a contractor and billing hourly, I’d add the start and stop times for work I did. At the end of the day I’d compute my hours-per-billable-bucket, and at the end of the week, I’d accumulate those values. Kind of manual, but it never took more than five minutes if I kept on top of it.

So why not buy or write a fancy notes taking app? What I have works for me, is always available since I’m always inside of emacs, or just a window and a couple of keystrokes away. Text files are easy to back up. I can put my notes file up on my Slice and keep an emacs running in screen there, making it easy to get to from any machine. No need to worry about safely syncing a proprietary file format for an app. It’s easy to sync text.

So if you’re longing for a quick and dirty, yet effective method for keeping tabs on your life, I recommend the simple tools: a text file and your favorite decent editor.

 

Blog at WordPress.com.