{"id":907,"date":"2009-11-03T10:11:43","date_gmt":"2009-11-03T15:11:43","guid":{"rendered":"http:\/\/mikeconley.ca\/blog\/?p=907"},"modified":"2023-12-20T16:25:18","modified_gmt":"2023-12-20T21:25:18","slug":"code-spelunking-for-students","status":"publish","type":"post","link":"https:\/\/mikeconley.ca\/blog\/2009\/11\/03\/code-spelunking-for-students\/","title":{"rendered":"Code Spelunking for Students"},"content":{"rendered":"

Last Friday, I went to the FSOSS conference at Seneca@York Campus<\/a> with Zuzel<\/a> and Greg<\/a>.<\/p>\n

One of the talks I attended was an open discussion about getting students involved in open source software<\/a>.<\/p>\n

I’m going off of memory there, but I believe one of the speakers at that talk said something like:<\/p>\n

Students generally don’t have to deal with large code-bases in their school assignments…1000 lines of code is really nothing.\u00a0 When students work on an open source project, they get dropped into a massive code-base with only a fork, a spoon, and a compass.\u00a0 They have to find their way around, and that’s where the real challenge and learning is.\u00a0 This is a skill that most students just don’t get with normal school assignments.<\/p><\/blockquote>\n

Again, I’m paraphrasing.<\/p>\n

So is this true?\u00a0 Hm.<\/p>\n

During my undergraduate career, I’ve certainly had to explore strange code that someone else has written.\u00a0 But nothing even close to the size of, say, the Mozilla Firefox code-base<\/a>.\u00a0 Or the Chromium code-base<\/a>.\u00a0 I mean, these are massive<\/em> wads of code.\u00a0 This is not a criticism of my teachers or the UofT CS program by any means – it’s just an observation.<\/p>\n

But some students explore these large code-bases on their own in their free time.\u00a0 During my (admittedly brief) break before summer work began, I started poking around the Firefox code.\u00a0 I made two discoveries:<\/p>\n

    \n
  1. The code that I saw was, in my opinion, very well written<\/li>\n
  2. I was completely lost, and didn’t know where to start<\/li>\n<\/ol>\n

    I still haven’t worked on any software that is nearly as large as Firefox.\u00a0 Not even close.\u00a0 MarkUs is a nice chunk of code<\/a>, but minuscule in comparison.<\/p>\n

    So just go with me on this for a second.\u00a0 Let’s assume that a large code base is intimidating and difficult for students to wrap their heads around, and this is one of the main challenges in getting those students to contribute to open source software.<\/p>\n

    Again, I only have my own experience to back up that claim.\u00a0 Looking at Firefox, I didn’t know where to start.\u00a0 I didn’t know where to go.\u00a0 I didn’t know which way was up.\u00a0 I was lost.<\/p>\n

    So how can students get a better grasp on a mountain of code?\u00a0 A few ideas:<\/p>\n

      \n
    1. Write tests for the code, starting small and going big.\u00a0 This is a relatively easy way to play with the code without having to change it. This assumes, of course, that the software has been designed to be easy to test…<\/li>\n
    2. Ask someone else.\u00a0 Go into the appropriate IRC channel and ask around.\u00a0 This, of course, has<\/a> it’s own problems.<\/a><\/li>\n
    3. Read up on the developer documentation.\u00a0 Let’s just hope it’s up to date and relevant…<\/li>\n
    4. Read up on someone else’s experiences exploring the same code base.\u00a0 Good luck finding those.<\/li>\n<\/ol>\n

      Not Quite Blueprints<\/h3>\n

      I’ve always thought of computer software as being like an invisible machine inside my computer.<\/p>\n

      And to me, the source code is a bit like the description of the blueprints for that invisible machine<\/em>.\u00a0 It’s not the top-down crystal-clear cutaways that a blueprint provides…it’s a flat, textual interpretation of those blueprints.\u00a0 And it takes quite a bit of reading before those descriptions sink in, and the “personality” of the machine becomes clearer.<\/p>\n

      In his article “Code Spelunking Redux<\/a>“, George V. Neville-Neil<\/a> says:<\/p>\n

      Working in this way is a bit like trying to understand the United States by staring at a street sign in New York City. The ability to look at a high-level representation of the underlying system without the fine details would be perhaps the best tool for the code spelunker. Being able to think of software as a map that can be navigated in different ways\u2014for example, by class relations and call graphs\u2014would make code spelunkers far more productive.<\/p><\/blockquote>\n

      I was thinking a lot about that on my ride home from FSOSS.\u00a0 When I got home to my computer, I found out that there are some really cool alternative ways of viewing software.\u00a0 Here are three that I found quite interesting:<\/p>\n

      Codecity<\/a><\/h3>\n

      Imagine that you’re curious about developing on Firefox.\u00a0 You can wade through the swaths of source code…<\/p>\n

      or you can stroll through a city that represents the software<\/em>:<\/p>\n

      \"CodeCity\"<\/a>

      CodeCity<\/p><\/div>\n

      CodeCity is an integrated environment for software analysis, in which software systems are visualized as interactive, navigable 3D cities. The classes are represented as buildings in the city, while the packages are depicted as the districts in which the buildings reside. The visible properties of the city artifacts depict a set of chosen software metrics, as in the polymetric views of CodeCrawler<\/a>.<\/p><\/blockquote>\n

      Imagine virtually driving around that city, hearing a guided tour through your headphones…you can walk into buildings, check out the different floors…check the plumbing.\u00a0 Interesting idea.<\/p>\n

      Cocoviz<\/a><\/h3>\n

      Or how about a neighbourhood…<\/p>\n

      \"CocoViz\"<\/a>

      CocoViz<\/p><\/div>\n

      CocoViz address software comprehension by a combination of visualization and audio. It uses common place metaphors (like houses) for an intuitive understanding of software structures and evolution.<\/p>\n

      For each source code entity, evolution and structural aspects are mapped to such metaphors and annotated with different audio, to represent concepts such as design erosion, code smells or evolution metrics.<\/p>\n

      The tool is used in the software evolution analysis domain but offers DB-, XML-importer and a plugin architecture to extend its use into other domains.<\/p><\/blockquote>\n

      EvoSpaces<\/h3>\n

      Another attempt at using the architecture\/neighbourhood metaphor.\u00a0 This one does a neat job of displaying execution traces though – check out the video demo<\/a>.<\/p>\n

      These are cool ideas.<\/p>\n

      But are they useful? Are they usable?\u00a0 Do they work? <\/em>Could they help students get a firm grasp on a large code-base?\u00a0 Can they help visualize the evolution of software?<\/p>\n

      Has anyone actually used any of these?<\/p>\n","protected":false},"excerpt":{"rendered":"

      Last Friday, I went to the FSOSS conference at Seneca@York Campus with Zuzel and Greg. One of the talks I attended was an open discussion about getting students involved in open source software. I’m going off of memory there, but I believe one of the speakers at that talk said something like: Students generally don’t […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[5],"tags":[345,562,558,557,125,560,559,563,561],"class_list":["post-907","post","type-post","status-publish","format-standard","hentry","category-computer-science","tag-architecture","tag-blueprints","tag-code-spelunking","tag-exploring-code","tag-firefox","tag-fsoss","tag-large-code","tag-metaphors","tag-students"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/prmTy-eD","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/posts\/907","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/comments?post=907"}],"version-history":[{"count":18,"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/posts\/907\/revisions"}],"predecessor-version":[{"id":3208,"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/posts\/907\/revisions\/3208"}],"wp:attachment":[{"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/media?parent=907"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/categories?post=907"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mikeconley.ca\/blog\/wp-json\/wp\/v2\/tags?post=907"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}