About 10 results: "re.compile repo:imrehg/website"
Page 1 of 1
Filter Results
Sources
Languages
Filter Results
Try Search On



formatting-revisited.html in website https://github.com/imrehg/website.git | 75 lines | HTML
  1. <meta name="author_id" content="wilson.g" />
  2. <meta name="title" content="Formatting Revisited" />
  3. {% block content %}
  4. <p><a href="http://dseifried.wordpress.com/">David Seifreid</a> has been working for the past week to combine <a href="http://imakewebthings.github.com/deck.js/">deck.js</a>, a Javascript-plus-CSS slideshow package, with the <a href="https://github.com/dz0ny/AudioJS">AudioJS</a> audio player, so that we can re-do slides as pure HTML5 (instead of using PNGs exported from PowerPoint). At the same time, I'm trying to turn the course notes into long-form prose (what used to be called a "book") for people who prefer reading at leisure. How should all this content be managed? My <a href="{{root_path}}/blog/2012/01/never-mind-the-content-what-about-the-format.html">previous post</a> on 21st Century teaching formats described what I'd eventually like, but the tool I want doesn't exist yet, so what can be done now?</p>
  5. <li><em>tranascripts</em> of the narration; and</li>
  6. <li><em>prose</em> (the "book" stuff), which may include the same code samples and figures.</li>
  7. </ol>
  8. <p>I know from experience that the transcripts of the audio will be a starting point for the book-form material, but the latter will be longer. We'll therefore have four parallel streams of data: slides, audio, narration (as text), and the book. That suggests something like this (using the topic/concept distinction I discussed <a href="{{root_path}}/blog/2012/01/terminology.html">a couple of weeks ago</a>):</p>
  9. <pre>&lt;section class="topic"&gt;
  10.   &lt;section class="metadata"&gt;
  11.     &lt;section class="slide" popcorn-slideshow="start time in seconds"&gt;
  12.       Slide (or several slides if we're using progressive highlighting on a single logical slide).
  13.     &lt;section class="transcript"&gt;
  14.       Text transcript of the slide (or group of closely-related slides).
  15.   &lt;/section&gt;
  16. &lt;/section&gt;</pre>
  17. <p>Diagrams and images will be stored in external files and <code>href</code>'d in&mdash;I've played with putting the SVG directly in the document, but in practice, people are going to use different tools to edit the two anyway. I'd like to use inclusions for code fragments, so that they don't have to be duplicated in the slide and book sections, but there's no standard way to do text inclusion in HTML (which is odd when you think about it, given that other media are usually included by reference instead of by value).</p>

literate-programming.html in website https://github.com/imrehg/website.git | 103 lines | HTML
  1. {% block content %}
  2. <p>Last week's post about the <a href="{{root_path}}/blog/2011/03/tuple-spaces-or-good-ideas-dont-always-win.html">tuple space programming model</a> was so popular that I thought readers might enjoy a discussion of another beautiful idea that failed: <a href="http://en.wikipedia.org/wiki/Literate_programming">literate programming</a>.  Like Lisp and other toenail-based languages, it inspires a kind of passion in its fans that is normally reserved for gods, sports teams, and angsty rock bands.  And, like them, it leaves everyone else wondering what the big deal is.</p>
  3. <p>Literate programming was invented by Donald Knuth (one of the few real geniuses ever to grace computer science) as a way of making programs easier to understand.  His idea was that the code and the documentation should be a single document, written in a free-flowing mixture of Pascal and TeX, C and LaTeX, or more generally, a text markup language and a programming language.  Functions, classes, modules, and other things could be introduced <em>and explained</em> in whatever order made sense for human readers.  One tool would extract and format the text-y bits to create documentation, while another would extract and compile the code-y bits to produce the runnable program.</p>
  4. <p>It's a great idea, and for about six months in the late 1980s, I was convinced it was the future of programming.  I could use &delta; as a variable! I could call a function for calculating sums &Sigma;(...)!  My explanation of what the code was doing, and the code itself, were interleaved, so that whenever I changed one, I would naturally change the other, so that they never fell out of step!  And with a bit of tweaking, I could produce a catalog of functions (this was before I started doing object-oriented programming), or present exactly the same content in breadth-first order, the way it was executed (which was usually easier for newcomers to understand).  Cool!</p>
  5. <p>But then I had to maintain a large program (20K lines) written with literate tools, and its shortcomings started to become apparent.  First and foremost, I couldn't run a debugger on my source code: instead, my workflow was:</p>
  6. <ol>
  7. <li>"compile" the stuff I typed in&mdash;the stuff that was in my head&mdash;to produce tangled C;</li>
  8. <li>compile and link that C to produce a runnable program;</li>
  9. <li>run that program inside a debugger to track down the error;</li>
  10. <li>untangle the code in my head to figure out where the buggy line(s) had come from;</li>
  11. </ol>
  12. <p>After a while, I was pretty good at guessing which lines of my source were responsible for which lines of C, but the more use I made of LP's capabilities, the more difficult the reverse translation became.  It was also a significant barrier to entry for other people: they had to build a fairly robust mental model of the double compilation process in order to move beyond "guess and hack" debugging, whereas with pure C or Fortran, they could simply fire up the debugger and step through the stuff they had just typed in.</p>
  13. <p>I also realized after a while that the "beautiful documentation" promise of LP was less important than it first appeared.  In my experience, programmers look at two things: API documentation and the source code itself.  Explanations of the code weren't actually that useful: if the programmer was treating the code as a black box, she didn't <em>want</em> to know how it worked, and when she needed to know, she probably needed to see the actual source to understand exactly what was going on (usually in order to debug it, or debug her calls to it).  The only role in between where LP was useful lay in giving an architectural overview of how things fit together, but:</p>
  14. <ol>
  15. <li>that was something people only really needed once (though when they needed it, they <em>really</em> needed it), and</li>
  16. <li>that level of explanation is really hard to write&mdash;exactly as hard, in fact, as writing a good textbook or tutorial, and we all know how rare those are.</li>

alpha-test-of-drivers-license-exam.html in website https://github.com/imrehg/website.git | 232 lines | HTML
  1. {% block content %}
  2. <p>As <a href="{{root_path}}/blog/2012/06/a-supercomputing-drivers-license.html">we announced back in June</a>, we're working with the <a href="http://www.software.ac.uk/">Software Sustainability Institute</a> to create a "driver's license" exam for the <a href="http://www.stfc.ac.uk/Our+Research/24711.aspx">DiRAC</a> supercomputing facility. Mike Jackson at the SSI alpha tested our exam on four people last week; the exam itself, and his comments, are below. We would be <em>very</em> grateful for feedback from the community on the scope and level of the questions.</p>
  3. <h2>Exam</h2>
  4. <p>You have been given the URL of a version control repository, along with a username and a password for it. You have one hour to complete the following tasks. If at any point you would like clarification, please do not hesitate to ask. If at any point you are unable to complete a task, you may also ask for help so that you can proceed to the next task, but doing so will be considered equivalent to not completing that task.</p>
  5. <h3>Version Control</h3>
  6. <p>Check out a working copy of the version control repository. You will do all of your work in this working copy, and use version control to commit your solutions as you go.</p>
  7. <p><em>Solution:</em></p>
  8. <pre>svn checkout $URL</pre>
  9. <h3>Shell</h3>
  10. <p>Once you have a working copy, use the cd command to go into it. Use a single shell command to create a list of all files with names ending in .dat in or below this directory in a file called all-dat-files.txt.</p>
  11. <p><em>Solution:</em></p>
  12. <pre>find . -name '*.dat' -print &gt; all-dat-files.txt</pre>
  13. <p>The analyze.py program takes exactly two arguments: the name of its input file and the name of its output file, in that order. For example, if inputs/a.dat changes, running make will execute the command:</p>
  14. <pre>./analyze.py inputs/a.dat outputs/a.out</pre>
  15. <p>Edit the file Makefile in the root directory of the working copy so that if any .dat file in the inputs directory changes, the program analyze.py is run to create a file named .out in the outputs directory.</p>

ratios-and-rework.html in website https://github.com/imrehg/website.git | 35 lines | HTML
  1. <meta name="author_id" content="wilson.g" />
  2. <meta name="title" content="Ratios and Rework" />
  3. {% block content %}
  4. <p>It's been six months and a bit since we started working on Version 4 of this course, so I'd like to share two things we've learned about creating online tutorial videos:</p>
  5. </ol>
  6. <p>Let's start with "a long time". It takes me 3-5 hours to prepare a good slide deck for an hour-long lecture that I'm going to deliver in person. A slide deck for a screencast takes 8-10, because I need to prepare more slides: since there isn't a lecturer making eye contact and pointing at things to keep viewers engaged, a slide deck for online use has to have many more small transitions.</p>
  7. <p>Writing a script to go with those slides is another 3-5 hours, much of which is spent rearranging the slides as I discover things that don't work as well as I thought. I don't know if it's fair to count this as an extra cost, or whether it's just bringing time I would spend on the second run of a course forward to the first run, but it's still time.</p>
  8. <p>Recording audio takes about 1.5 times as long as the audio (if I stumble, I just pause, take a breath, and restart that sentence), so call it 1.5 hours. Editing takes longer than recording, so let's say 4-5 hours all in (again, including some rework as I notice glitches that escaped me before).  Getting everything off my machine and onto software-carpentry.org is another hour by the time all is said and done, so an hour-long lecture made up of 5-6 episodes comes in between 20 and 25 hours.</p>
  9. <p>But now we come to #2: the stuff that feels like it should be unnecessary. If I want to make a change <em>after</em> an episode has been posted&mdash;even a small one&mdash;it's substantially more work than changing a few slides in a PowerPoint deck would be. First, I need to record new audio, or get whoever originally created the episode to find a microphone and record some snippets of MP3 for me (having the voice change for a slide or two in the middle of a screencast is very jarring). Second, I need to re-export the PowerPoint slides as PNGs, and if the number of slides has changed, rename some of them: Camtasia refers to imported image files by name, and if I simply re-export and re-import, I have to go back and change the time boundaries for all the images after the ones that have been updated.</p>
  10. <p>How bad is this? Well, I just fixed a small mistake in <a href="/4_0/python/lists.html">the episode on Python lists</a>. It took almost an hour, start to finish, and the change in audio quality where the fix was made is painful.</p>
  11. <p>And then there's version control. PowerPoint is effectively a binary format: yes, there's XML in there, but version control treats that XML as lines of text, which means its diffs and merges are senseless. I've used HTML and LaTeX in the past&mdash;at least I can structure them so that line-oriented diff/merge is sensible&mdash;but both formats force a strong separation between text and image, where PowerPoint allows me to mix them freely as I would on a whiteboard. I don't like PowerPoint, but the final result is easier on the eyes than what I can do with today's HTML or LaTeX with equivalent effort.</p>
  12. <li>Has stable open source authoring tools with a long likely life in front of them (so that investing in them won't be insanely risky).</li>
  13. <li>Includes a decent text-to-speech engine (something better than <a href="http://www.xtranormal.com/">Xtranormal</a>'s, please) so that when I update what I'm displaying and the script of what I'm saying, I can just push a "compile" button and get a seamless video out the end.</li>
  14. </ol>
  15. <p>What's that? "And a pony for Christmas?" Yeah, that too. But let me share a secret with you: whoever builds this thing first will be rich, famous, and popular, because <em>this</em>&mdash;content creation and maintenance that the average instructor can afford&mdash;is the real bottleneck in online education.</p>

people-you-dont-want-on-your-team.html in website https://github.com/imrehg/website.git | 26 lines | HTML
  1. {% block content %}
  2. <p>Study after study has shown that the biggest causes of software project failure are over-optimistic scheduling and unstable requirements.  I think the only reason team dynamics isn't in the #1 spot is that it's hard for an outsider to judge after the fact. In my experience, though, how well people work together is a lot more important than how smart they are individually: everyone in the engineering group of the first start-up I joined was very good at their job, but when you put us together, our IQs somehow canceled out.</p>
  3. <p>I put together the profiles below to jump-start discussion in undergraduate project teams about the many ways in which someone can <em>not</em> contribute. If you have more to add, feel free to use the comment box :-)</p>
  4. <p><em>Anna</em> knows more about every subject than everyone else on the team put together&mdash;at least, she thinks she does. No matter what you say, she'll correct you; no matter what you know, she knows better. Annas are pretty easy to spot: if you keep track in team meetings of how often people interrupt one another, her score is usually higher than everyone else's put together.</p>
  5. <p><em>Bao</em> is a contrarian: no matter what anyone says, he'll take the opposite side. This is healthy in small doses, but when Bao does it, there's always another objection lurking behind the first half dozen.</p>
  6. <p><em>Caitlin</em> has so little confidence in her own ability (despite her good grades) that she won't make any decision, no matter how small, until she has checked with someone else. Everything has to be spelled out in detail for her so that there's no possibility of her getting anything wrong.</p>
  7. <p>Frank believes that knowledge is power. He enjoys knowing things that other people don't&mdash;or to be more accurate, he enjoys it when people know he knows things they don't. Frank can actually make things work, but when asked how he did it, he'll grin and say, "Oh, I'm sure you can figure it out."</p>
  8. <p><em>Hediyeh</em> is quiet. Very quiet. She never speaks up in meetings, even when she knows that what other people are saying is wrong. She might contribute to the mailing list, but she's very sensitive to criticism, and will always back down rather than defending her point of view. Hediyeh isn't a troublemaker, but rather a lost opportunity.</p>
  9. <p><em>Kenny</em> is a hitchhiker. He has discovered that most people would rather shoulder some extra work than snitch, and he takes advantage of it at every turn. The frustrating thing is that he's so damn plausible when someone finally does confront him. "There have been mistakes on all sides," he says, or, "Well, I think you're nit-picking." The only way to deal with Kenny is to stand up to him: remember, if he's not doing his share, he's the bad guy, not you.</p>
  10. <p><em>Melissa</em> would easily have made the varsity procrastination team if she'd bothered to show up to tryouts. She means well&mdash;she really does feel bad about letting people down&mdash;but somehow something always comes up, and her tasks are never finished until the last possible moment. Of course, that means that everyone who is depending on her can't do their work until after the last possible moment...</p>
  11. <p><em>Petra's</em> favorite phrase is "why don't we". Why don't we write a GUI to help people edit the program's configuration files? Hey, why don't we invent our own little language for designing GUIs? Her energy and enthusiasm are hard to argue with, but argue you must. Otherwise, for every step you move forward, the project's goalposts will recede by two. This is called feature creep, and has ruined many projects that might otherwise have delivered something small, but useful.</p>
  12. <p><em>Raj</em> is rude. "It's just the way I talk," he says, "If you can't hack it, maybe you should find another team." His favorite phrase is, "That's stupid," and he uses obscenity as casually as minor characters in Tarantino films. His only redeeming grace is that he can't dissemble in front of the instructor as well as Kenny, so he's easier to get rid of.</p>
  13. <p><em>Sergei</em> is simply incompetent. He doesn't understand the problem, he hasn't bothered to master the tools and libraries he's supposed to be using, the code he checks in doesn't compile, and his thirty-second bug fixes introduce more problems than they solve. If he means well, try to re-partition the work so that he'll do less damage. If he doesn't, he should be treated like any other hitchhiker.</p>
  14. {% endblock content %}


graph-layout-models-vs-views-and-computational-thinking.html in website https://github.com/imrehg/website.git | 102 lines | HTML
  1. {% block content %}
  2. <p>Money for me to keep working full-time on Software Carpentry hasn't materialized, so as I've mentioned in a couple of recent posts, I'm trying to find a way to organize the course material more coherently in the hope that other people will (finally) start to contribute content as well.  As part of that, I have spent the last two days trying to draw a graph showing the questions Software Carpentry seeks to answer, and the concepts that underpin the answers.  It's been harder than I expected, and I think the reasons might give some insight into how a computational thinker thinks.</p>
  3. <p>Option #1: use a generic drawing tool like Microsoft Paint.  The upside is, it's easy.  The downside is, it stops being easy as soon as I want to change things or collaborate with other people.  Paint doesn't have any notions of boxes, circles, or text: instead, it manipulates the pixels in images directly.  If I create a box with a text label, I can't group them together to make a single object, because <em>there are no objects</em>.  I could select and cut a region containing the box and label, then paste it elsewhere, but that wouldn't move the links connecting the box to other boxes.</p>
  4. <p>Storing my graph as an image also makes it hard to collaborate.  I can put the image in a version control repository, but if Grace edits her working copy while I'm editing mine, how do we merge our changes?  It seems strange to me that image diff-and-merge tools don't exist for Subversion, Mercurial, and other systems, but that's a yak I'm not going to shave today.</p>
  5. <p>Option #2: use an object-based drawing tool like Visio (or a reasonably modern PowerPoint).  This lets me group things, and links will stay attached as I move things around, but I still can't collaborate.  Switching to OpenOffice or Inkscape doesn't help: yes, they can save things as XML instead of in a binary format, but existing diff and merge tools work don't understand the structure of that XML, never mind its semantics, so they report differences at the wrong level.  It's as if my diff tool was working at the bitwise level, and reporting this:</p>
  6. <blockquote>
  7. <td>01100001</td>
  8. <td>011<span style="color: green;">10</span>1<span style="color: green;">0</span>0</td>
  9. <td>01100001</td>
  10. <td>011<span style="color: red;">01</span>1<span style="color: red;">1</span>0</td>
  11. <td>a</td>
  12. <td><span style="color: green;">t</span></td>
  13. <td>a</td>
  14. <td><span style="color: red;">n</span></td>
  15. </blockquote>
  16. <p>The same is true of interactive graph editors like yEd, Gephi, and so on.  If I have to eyeball two versions of a file and copy differences by hand, collaborating is going to be slow and error prone.</p>
  17. <p>Option #3: store my graph in a textual form that <em>can</em> be diffed and merged, and convert that textual form into the graphical representation I want (where "graphical" in this case means "visual", not "nodes and edges").  This is what LaTeX and HTML do: the human being creates content, and a tool transforms that content into something more readable.  Most of the translation is automatic, but all tools of this kind provide some way to control things more exactly, e.g., to force hyphenation at a particular point in a word, to center-align a title, and so on.</p>

Back to Top