I arrived at Princeton on a rainy Monday morning, and after sorting through the chaos of getting moved into my room despite keys/IDs that don't work, I joined my lab for an introductory lunch. It was great talking about CS and music with the other undergraduates and professors in our Soundlab working on the Fauvel project. We then jumped right in with learning about Fauvel under musicologist Anna Zayaruznaya's guidance, looking through a real-sized copy of the 18"x26" manuscript and deciphering the intricate calligraphy, unusually notated music, and beautiful artwork. Professors Fiebrink and Zayaruznaya then explained their vision for the digitization of Fauvel, and as we discussed all of the goals for this project and this summer, both small and large scale, immediate and eventual, we began to divide up the initial tasks between the three undergraduates.

The next few days focused on getting all our equipment set up, figuring out how to download and install the necessary programs and environments despite very slow wifi and the Princeton bomb scare. It was a very confusing experience, especially because the school had not bothered to alert visiting students like myself, but the other members of my lab were incredibly friendly and we ended up all working together and snacking on pizza and watermelon off-campus.

Once things settled down, I began working on my individual task for Fauvel - transforming the text from the Strubel edition of all poetry, lyrics, and image descriptions into an XML "Content" file that would enable efficient and organized navigation within the work. I read a paper by Alan Thorne, a CS major at Princeton, on his ideas for how to clearly mark each type of object found in the manuscript - images, poetry, and music - and began to write a Java program that would read in the text from the Strubel and transform it into valid XML.

I found myself enjoying the coding greatly, as it pulled from some of the web scraping skills I had developed in my CS classes at Columbia - teaching a program to recognize certain stylistic or textual clues and classify accordingly - while introducing new elements like music which I am passionate about. By the end of the week, I discovered that there were many unusual aspects of Fauvel which appear more and more as you get deeper into the manuscript; although these little quirks ultimately make Fauvel even more interesting to study, they also complicated our current plans for XML markup. Professor Fiebrink and I therefore arranged for me to meet with Alan Thorne and Professor Zayaruznaya to discuss the unusual elements I had found, how they fit into our existing scheme for understanding Fauvel - Are they music? Are they text? Did Strubel add these words in as an editor, or do they exist in the original manuscript? - and how to notate accordingly. It was very exciting to meet with Alan; I had started off as merely reading his work and trying to execute it perfectly but now was able to take everything to the next level and explore his reasonings behind his suggested XML encoding. I felt like I'd truly learned something about not only Fauvel and XML - a new language for me - but also gained experience with the more general challenge of representing data in a way a computer can understand.

By the second week, I had taught my XML-markup-Java-program to interpret the text files I was feeding it, with lyrics and poetry copied and pasted from the first 150+ pages of the Strubel edition of Fauvel. However, the full Strubel was nearly 700 pages, and, luckily, my lab did not expect me to format the entire text file myself. The plan was to have each person format 100 or so pages (with me making up the remaining, trickier sections); my first goal was therefore to make the requirements of the input text file as simple as possible - all my labmates would have to do was copy and paste from the Strubel, merely checking for OCR (PDF text/image recognition) errors and adding in a few indicators like "STARTPOEM" or "ENDPOEM" on either end of a section of poetry. The Java program would take care of the rest, a guarantee I needed to make as certain as possible, or else I would have to then go back through the 300 pages formatted by my labmates and redo that work, cutting down our efficiency. So I worked for hours to teach my program to recognize as many unique, unexpected cases as possible, tackling challenges like indicating the embellished "drop cap" letters that start off a new section of poetry or a new stanza in a musical object.

Finally, I felt like my program was ready to be used by our entire lab, so I presented it to our whole group, hooking up a projector to my laptop in order to walk through a demo copy and paste with minimal additional formatting. We split up the remaining 500 pages, and my labmates began what they jokingly called "Alison work". By the middle of the week, they each sent me their sections, and I began running their text files through my program, checking that the computer was interpreting and classifying each object as I intended. Throughout this process, I discovered other unexpected input, such as page changes in the middle of a musical or poetic section, which I again took to Professor Zayaruznaya and Alan for consultation. In some cases, various resources - i.e. an online catalogue of the musical objects in Fauvel - would contradict others/our understanding of the manuscript, and so I worked with the professors to make a final ruling based on our own best judgment.

It was very exciting to be presenting my work to the other students and professors in my lab; coding, like practicing a musical instrument, can often be a very solitary and frustrating process. But the end result - whether a code demo or a music performance - is incredibly rewarding, when you have the opportunity to share what you've created with others and hear their feedback. When preparing my program for others' use, I had to consider many different guiding questions: To what depth should a user of my program have to understand the code to use it? (Usually, as little as possible; in this case, I even had to account for non-computer scientists, like the musicians working on Fauvel with us). What are common errors or variations in input that the program should preemptively expect? How can I do my best to ensure that my XML output is valid without having to go through all of what ended up being a 66,000 word document (that's about 300 pages in Microsoft Word)?

In this second week, I got some wonderful hands on experience with what it's like to create a program and then send it to other people for testing, understanding, and other feedback. It was very cool to take the concepts I'd read about in papers written by CS majors/Princeton graduates to the next levels as I posed new questions, based on my own discoveries in Fauvel, and I was excited to have added my own contribution to this huge, incredible Digital Fauvel project.

I learned an important lesson this week: the second language is the hardest. I don't mean that my first CS language - Java - was always a walk in the park either; I developed a love hate relationship with Java very early on in my Columbia CS classes, roller coaster-ing between being incredibly frustrated when stuck on a bug for hours and shrieking with pure joy when my program ran (or even outputted the proper number of, say, cows, in a silly card game). But by second semester, I had begun to feel at home in Java, quickly crafting new classes, methods, and programs.

At the same time, I realized that it was very important to branch out and learn other languages as well, and so I'd been gently introducing myself to JavaScript, Python, and others via Codecademy and other online tutorials. But this third week of my DREU internship was when I was challenged to write in a new language - C# - and produce something that was not merely a "Hello, World!" level console output. It was very confusing at first, and the many files that are edited simultaneously in Visual Studio (xaml, xaml.cs, and the XML file I was working from) only made the process more complicated. Of course, having to go through the always-painstaking installation / download process was even more frustrating.

But after hours of googling, combing through StackOverflow posts, and sometimes turning to my labmates or professor for some insight, I found myself becoming increasingly comfortable with C# as I created a program that could parse an XML document using C# - both of which are new to me - and return the desired information, whether it was a chunk of poetry, description of an image, or all the four-part motets in Fauvel. As I got to know the capabilities of SelectNodes, SelectSingleNode, selecting by attributes, and more, I was able to more quickly locate the target information, pruning out all the unnecessary text and tags along the way. I became excited about what I could create, and I was very proud at having stepped out of my Java comfort zone.

This newfound confidence came at a perfect time, too, because this weekend was the NYC Department of Education / Spotify joint hosted Music Education Hackathon (Friday Jun 28-Saturday Jun 29). Although I had attended parts of Hackathons at Columbia, I was usually too consumed with the built in workload of a full courseload to stay for the entire time. Still, listening to other coders' pitches and watching the demo live codes in awe had given me a great sense of the inspirational and supportive qualities Hackathons tend to have, and I enthusiastically planned with my labmates to stay up all night and build something that would ideally even apply to Fauvel.

The all-night coding process was not easy - right now, it is 11:30 am on Saturday, and I've been awake since 8:30 am yesterday (Friday). Since arriving here at Alley NY last night, I have drank about 5 redbulls and 4 coffees. We coded for 13+ hours straight, and I have no clue how I am still awake.

Our app is simple but I think very effective - inspired by my friend's recent endeavors into teaching himself to read music / play his favorite songs on the piano, as well as last week's lessons on medieval music notation to better understand Fauvel, we chose to make a note-teaching iPhone app called "TigerClefs" which trains and quizzes the user in identifying notes in various clefs, from the standard treble and bass to the slightly harder alto and tenor, and even adding in the mysterious and moving medieval C clef. While designing and building the app, we had to think about what capabilities were immediately needed - explanations, tutorials, and slow progression from recognition to recall - and which could be easily added later - like rhythm and ledger lines. We also had to make decisions about what would count as having learned/mastered a level, and we chose to strengthen the note learning by keeping all harder clef levels locked until the lower ones had been mastered.

Things that I learned: 1) Thank god we've been using repositories for Fauvel, because otherwise it would have been very hard for all three of us (Jamie, Chris, and myself) to collaborate on our code. 2) Git repositories don't solve all your problems, though, bc sometimes Google Code will freak out and tell you you must commit your changes immediately because auto merge is going to overwrite your progress!! And then begins the great journey of finding each little change in each of your files. 3) Learning Objective C in the middle of the night is very difficult. 4) Actually, I must admit I'm not a huge fan of Objective C at all... but I would probably have had an even rougher learning curve had I not spent time learning C# this week. 5) Debugging can take a long, long time - we were basically stuck on one or two bugs from 6:00 am or so til now. BUT 6) Hackathons are really, really fun - from meeting other sleep deprived, caffeine pumped coders in the middle of the night as we scavange for bags of chips and bottles of redbull to the miraculous feeling of an app that actually teaches you how to read medieval clefs rapidly, you end up feeling incredibly accomplished at the end. And even though we have not yet decided whether we will present our app officially this afternoon, we've created something that we - and our friends - can use, and it can even help with the Fauvel project as a medieval notation guide!

I used to worry that I was going into CS as a major because I had so many great friends in it, and that my friends were what I wanted to devote time to, not the subject. But I'm realizing more and more that the two go hand in hand - quite literally, as we coders cart around our laptops 24/7. :P But it's really quite true that the CS community is incredibly vibrant, warm, enthusiastic, creative, and lovably nerdy, and even if my eyes start to glaze over from all the methods and objects, I'm going crazy from the concatenations and instantiations, and I will forever be a minority in a sea of stereotypical male coders, I am glad to be part of this CS (Hello) world. :)

Returning from the NYC Hackathon, after being inspired by so many experienced programmers, I felt ready to dive into new projects for Fauvel. My feeling that I had gained confidence and expertise in CS was further confirmed when I worked to XML-encode the English translation of all near-6000 lines of Fauvel poetry; although the original Old French text had taken me a week, this encoding took about 1-2 hours.

With both the English and Old French text ready for navigation, I began writing the back-end code for many capabilities that our final digital surface should have - I started with fetching lines of poetry, image captions, and music lyrics by their "id" number and then created a method that could fetch any range of poetry lines, allowing for increased future flexibility: imagine a user drags her finger across a page, highlighting a rectangle of any 7 lines of poetry; our program can then translate it in a second. I then created searches that would allow the user to search for any word or phrase in Old French or English, with the intention of adding in Modern French (and perhaps even other languages) eventually.

Programming these capabilities allowed me to both call upon skills I had developed in my CS classes at Columbia and take on new challenges. The XML parsing was similar to HTML webscraping that I had done when creating a program that answers trivia-type questions about the various awards from the Academy Awards Portal, a Wikipedia-type site with information about movies, directors, actors, actresses, and more. Meanwhile, adding in the search functionality raised new questions that I had to contemplate and discuss with Professor Fiebrink and the musicologists - What types of searches are people likely to want/need? What should a default option be - should words be case sensitive? Will users of Digital Fauvel ever need to search for multiple languages at once? As I turned to Microsoft Word, Adobe, Google Chrome, etc, I began trying to put myself in their companies' perspectives and figure out the pros and cons of various choices - a floating search bar, a simple vs. wide selection of advanced searches, and more. This allowed me to contemplate applications I use in everyday life from the more scrutinizing viewpoint of a computer scientist, something I often find myself doing anyway, which made the process all the more enlightening and enjoyable!

Once I finished a substantial part of the back end search and fetch coding, I then worked with Professor Fiebrink to tackle the front end design. She referred me to guidelines like Nielsen's 10 Usability Heuristics, many of which I have encountered before, but not in an organized form. I started by drawing some quick sketches of how the search sidebar would be used, from the initial "new tab" screen, before any searches have been conducted, to the more complicated "advanced search" options, with various types of search results displayed in a "findings" screen below. As I explained and scrutinized each part of my UI with Professor Fiebrink, she guided me through important over-arching principles for Digital Fauvel - allowing for easy flexibility/later additions, consistency with the rest of the UI, and always remembering that designing for a large tablet like Big Sur is very different than designing for something like an iPhone. Although I was tempted to jump right into the coding process and tweaking things later on if necessary, I increasingly understood the merits of first creating a simpler prototype that is easier to present for feedback and adjust accordingly.

Meanwhile, I again realized the confidence and experience I have gained in CS through a handful of encounters with my fellow CS majors from Columbia. One friend visited for the weekend, and we nerdily but excitedly headed out to Small World coffee for "coffee and code", one of my new favorite summer activities. When he mentioned some trouble he'd been having with a Java Swing application, I surprised even myself with the amount of genuine enthusiasm I displayed. During another conversation, a friend mentioned a Hackathon that UPenn is hosting in September and another in NYC held by Facebook in August. Although one person expressed doubt that we - as mere rising sophomores - would be able to create something during such a short span of time, I again was surprised at my own certainty that we could come up with a great idea and carry it to completion.

When I got the chance to visit my family last weekend, I commented to my younger sister Serina, "It's crazy that a year ago, I knew absolutely NOTHING about computer science". It was true - unlike many people in the CS community, I did not discover it until I got to college; I was not one of those high schoolers who taught themselves to program and began working in a start up before stepping onto a college campus. And sure enough, this feeling that I was entering the field "too late" gnawed at me throughout my first few CS classes, where I was certain the hundred+ people around me were all much more experienced and talented than I. This self doubt made my programming endeavors and CS final exams even more stressful, as with each one I asked myself if I was worthy of attempting the major. As a young woman who codes, it can be even harder to steer away from self-inflicting stereotypes about what qualities are prerequisites for being a "good coder". But with each passing week here, bonding with my fellow undergrad coders, attending CS events and staying up all night together, and learning from my professor, who has already taught me a great deal not only through our daily meetings/discussions but also by example (as a musician who discovered coding and found a way to combine both, a journey not unlike my own), I become more certain of what I ultimately aim to answer this summer: if I truly enjoy CS and if I am cut out for it - both of which, if thrown into a search method, would return results of "Yes". :)

During week 5, I was given the challenge of creating and pitching a set of prototypes for the Fauvel search sidebar, where users could search for text (in English, Old French, etc) in poetry, music lyrics, and images, indicating advanced preferences like case or whole word sensitivity, and explore previews of each search result before choosing whether to navigate to that page. I had already prepared most of the back end code for a variety of search capabilities, but now I had to set aside the back-end portion and focus purely on designing an easy-to-use, easy-on-the-eyes UI. Although I had been trained in my past CS classes to create GUIs from scratch - i.e. adding in coordinates, etc. myself - I did have to admit that the automated GUI builder in WPF / Visual Studio made scooting items around on the canvas much easier.

I had already drawn up a first draft of my designs by hand and met with Professor Fiebrink to discuss alternations, further decisions to be made, etc. Now, I had to transform my pencil and paper ideas into code, which forced me to become very familiar with using both xaml and its paired code-behind (xaml.cs). The interactions and distinctions between the two proved to be challenging but also very interesting, and as the week went on I became much more confident, adding TextBlocks to Canvases and StackPanels to Grids. Once I overcame the initial expectation that I would learn how to do something first and then need to use it in a program, I lost all hesitation at jumping onto google without a second lost, browsing through StackOverflow to create my vision of the GUI while simultaneously learning what Visual C# was capable of.

After creating a variety of possibilities for simple (default) search, advanced search options, result displays, etc, I was finally ready to present them to Professor Fiebrink. I'll admit I was a little nervous, as in the past, with larger CS classes, I had mostly dove straight into the coding process and only received feedback at the end of the project, without having to immediately make changes or rethink my perspective and technique. I was very happy to find that Professor Fiebrink really liked many of the design choices I had made, and it was incredibly interesting to engage in further discussions with her over the pros and cons of various details, my thought processes behind the different aspects of my design, and what the next steps would be.

Once I processed her feedback, it was time to combine the front end and back end, putting the GUI together with the actual search methods. The biggest part of this process was learning to create tabs dynamically - i.e. by clicking a "new tab" button. My labmate, Brendan, helpfully directed me to a very detailed, well explained tutorial, and I started off by getting a very basic dynamic tab set up. By closely pouring over this tutorial, the code Brendan had made so far for the larger Fauvel facsimile tabs, and other information I found online, I was soon able to recreate the GUI with event handlers and all. It was sometimes difficult to translate the xaml code that I had used to make the mockups into the code behind (C#) needed to make a new tab dynamically, but I became increasingly familiar with the lingo - i.e. setting myTextBox.Foreground = Brushes.Black instead of .

As the week went on, I got more and more excited about the sidebar. The front and back ends were coming together nicely, and the feedback from Professor Fiebrink was both helpful and motivational. Beyond the specific scope of Fauvel, I also felt more in control of my coding, quickly and smoothly creating small programs to carry out little tasks in a more efficient and accurate way, such as when I was comparing the objects on each folio/page as indicated in my XML file for the original manuscript text (the content file) to the objects listed in my other labmate Jamie's XML file which listed the position of each object (the layout file). Being able to swiftly imagine and implement a program and its classes, methods, etc. was a great feeling, and as I finished my fifth week and first half of my time in DREU at Princeton, I headed home to NYC for the weekend with a big smile. :)

I sent my friend a CS related joke about the struggles of debugging, and to my surprise, he began a whole lecture on how all I ever do when talking to him is complain about CS. Although I realized that there is some truth to his claim, I also realized that most of my friends know that as much as I groan about being stuck on a bug for hours or as frustrating as it can be to stare at StackOverflow post after post for an entire afternoon, the sheer amount of joy and pride I feel when my code finally works, when I've managed to communicate with a computer and teach it to think the way I do, is worth it a million times over. It is true that a big part of the CS culture is sharing good natured jokes at our own (the programmers') expense, grumbling about compiling errors and GitHub battles. But I do not believe this stems from an underlying dissatisfaction with the field. In fact, I think it's the opposite - we share these comments and rants because we know that at the same time we share the secret knowledge that, no matter how much we complain, we love computer science: the process, the headaches, the thrill of building a program and watching it run.

One of my big challenges this week was transforming the WPF visual interface code I had created for the search sidebar into functioning code for the Microsoft Surface, with all sorts of listeners and event handlers. The trickiest part was finding that certain types of objects - such as the WPF ComboBox, which allows a user to select from a list that drops down when clicked but usually only neatly displays the selected item - does not translate smoothly into code for the Surface (the machine for which we are building the Digital Fauvel). I felt frustrated trying to rewrite code I had already created and, I had thought, perfected, as I had slaved over the placement of every box and line's coordinates, testing out different looks to see what sort of design was easy to understand, appealing, and worked well with the rest of our interface. Now, having to consider changing my graphical interface due to limitations of the Surface seemed like backwards progress to me.

However, on the same afternoon, I solved a problem that had previously stumped me - in the search sidebar, we displayed a preview of each search result, with an image thumbnail of what the poem, piece of music, or image looked like on the actual page of the manuscript, as well as a textual excerpt of the surrounding poetry, lyrics, or image captions. I had been trying to format the excerpt so that the search word would be bold, to easily grab the user's attention, while the rest of the excerpt would be normal. However, preliminary attempts to format a specific part of a String revealed the task's difficulty. There were certain results about Inline formatting of the C# TextBlock, which allows for FontWeight (bold, italics, etc) to be set, but I couldn't seem to get the Inline Runs to work for the C# code behind.

But when I tried the same searches one more time today, I suddenly found an example code where the TextBlock - let's call it myTextBlock (creative, I know!) - can add an Inline Run as such: myTextBlock.Inlines.Add (...and then some sort of code with a string and its formatting). Suddenly, I could add multiple Strings to a TextBlock, each with a unique FontWeight - or even its own size, font type, etc. The only thing left to do was chop up the excerpt text accordingly, and by the end of the day I had the bolded search query up and running for all sorts of search results. I was very excited, not only because I had solved this particular issue but because my discovery of this solution reminded me that any problems I get stuck with - such as the ComboBox dilemma - aren't at all permanent. I've learned that it's perfectly okay to step away from the screen when a particular issue is giving you a headache - or at least switch to tackling a different headache! - and often, when you return to the problem with a clear head, you can find a way to fix it.

Meanwhile, I was also having a great time collaborating with other members of the Fauvel Project. Within the CS scope of things, I was very pleased when my labmate, Brendan, and I were able to quickly and efficiently tackle a problem together - he simply asked me to write up a method that would access an XML file that listed the contents and layout of each manuscript page and return a List of objects that I created called BoundingBoxes, which had coordinates and an identifying name (i.e. 1rMo1 means the first motet, a type of music, on page 1r). Then, he would take my method's output and display each BoundingBox over the manuscript page's image, so that we could check whether we had marked the boundaries of each section of poetry, music, or imagery properly. I'm not quite sure what about our exchange made me so happy, but I think it had to do with how easily both of us are able to shape the code into whatever we need, into two pieces that come together to create the outcome our project needs. It amused and amazed me that last fall I had no idea whether a method should be void or not, or what that even meant, and now I could whip up a new class called BoundingBox and have another method returning List within minutes.

I was also working with non-coders to get some feedback on the design and usage of my search sidebar - namely, a graduate student at Princeton named Jenna Phillips who specializes in Medieval history. I walked her through my program, asking her to do things like search for certain key words, open a new tab, look for extended search options, etc, as my labmate Jamie and I took notes on what aspects of the program/interface were intuitive and which were confusing. I discussed various aspects of displaying search results with her, talking about pros and cons of showing more versus less text in the excerpt, and considering what other sorts of searches users of the Digital Fauvel would want to carry out. It was interesting to hear another person's perspective and watch someone else interact with my code; when you work on designing something yourself, as your vision is shaped over time, it can be easy to forget the assumptions you are making and how much understanding you end up accumulating with your code. Having a fresh pair of eyes is always a good idea - I remember that I would always work on CS projects with a couple friends, because a small bug that would trap me for 2 hours could be found and squashed by a friend in 2 minutes, simply because something tiny and obvious that I had taken for granted or gotten too accustomed to was actually completely out of place or missing.

During this week, the Golandsky Institute - comprised of a summer symposium and music festival - was holding talks during the day and concerts in the evening. I not only found myself turning pages for two concerts, which were amazing experiences that reminded me why I love and devote myself to music, but also had the good fortune to attend a talk on healthy computer usage. As a recovering victim of repetitive stress injury due to writing, typing, and piano, something that I've mostly got under control but still struggle with during finals' weeks each semester (and have to be very careful about during this summer's' 8+ computer-hour days), hearing techniques to combat - or even acknowledgment of - the daily stressors and potential risks of large amounts of technology usage, something that most high school or college students have no way to avoid, between heavy workloads and the technology we grew up using. Approaching computer-usage with the same techniques and mentality as I have learned to approach piano-playing - being careful of posture, taking frequent breaks, and replacing the isolation of small muscle movement (i.e. with repeated, small motions like mouse clicking) with larger muscle efforts (using your forearm when typing, clicking, etc) made a lot of sense, and I realized that most of these principles were things I had already learned in my musical endeavors, I just needed a small reminder to apply them. This talk showed me yet another way that CS and music are not so different after all.

Overall, a good week of collaboration, caution, and code... despite the insane heat wave. A word to the wise: If anyone is reading this and considering working at Princeton for the summer (if anyone reads this at all...), bring a powerful fan. Or two. Or three. I wish I could take some of the wonderfully AC'd air from the CS building back to my dorm with me, because living without air conditioning in the summer (100+ degrees day and night this week) is rough. Ice packs are nice too. :)

As the weather finally cooled down to a bearable temperature, I continued the quest to transform my WPF search user interface into a touch enabled version for the Surface. I soon found that one of the biggest difficulties of figuring out how to change ComboBoxes to SurfaceListBoxes or ScrollViewers to SurfaceScrollViewers was that there are not as many StackOverflow/other online posts and answers for our machine, the Microsoft Surface 2.0, because the number of coders working with this particular tablet is much lower than the number who have wrestled with often-faced challenges for other types of technology. Instead of focusing on this lack of information for the Surface, I tried to focus on appreciating the wealth of shared knowledge that does exist for many other code-related tasks.

This common practice of maintaining an extensive, detailed help forum online is really very representative of the CS community and its attitude towards learning. There are so many resources online, from APIs to websites like codecademy where you can easily and simply learn to code, or even write your own lesson. This cycle of learning from other coders' questions and struggles and then helping others in turn is far from the stereotype of coders as solitary creatures who only interact with computers and other machines, never emerging into the light of day to converse with actual humans.

In the spirit of collaboration, on a smaller, more personal level, I have also found myself working more and more closely with the other two undergraduate students on the Fauvel project. Throughout this summer, we have gotten a great sense of each of our areas of expertise, allowing us to smoothly delegate tasks to each other and quickly get tasks done as a group. When I have questions about Surface or touch-related objects, I can turn to Brendan, who figured out a way to tackle the lack of a Surface-friendly ComboBox. When confronting the never-ending task of encoding and XML (this week, we prepared and encoded the entirety of the Modern French translation of all poetry and music lyrics), Jamie and I worked side by side, discussing each question about how to categorize or label certain aspects of the material as we discovered new quirks. In a field where we do indeed spend many hours a day attempting to communicate with machines, it is great to have human company while doing so, exchanging laughs and frustrated groans from across the room in our cozy Soundlab.

Along the lines of celebrating CS culture and companionship, I have added a new section to this website - a page of links with some of my favorite CS jokes. Most of these were posted by my Columbia CS friends in our "Computer Scientists" Facebook group - a safe space for us to share our coding related frustrations, joys, and, above all, embrace our nerdiness. Echoing what I wrote last week, the abundance of jokes at the CS field and our (the coders') expense does not mean we do not love it. Instead, it is merely a reflection of how fully we have embraced the entirety of CS as part of who we are - the good, the bad, and all the things that drive us crazy.

As I refined the search sidebar for Fauvel, I also began exploring command line image editing tools that would allow me to create all the thumbnails (i.e. for a section of poetry, piece of music, or image) for search results preemptively, instead of taking time during search to fetch and crop the images. I was initially intimidated by the task of writing a script, as I had never written one before, but with a little googling and some guidance from my labmate Jamie, I soon realized it wasn't that hard at all. When I finished the ThumbnailScript and ran it using bash, I was very pleased to watch the thumbnails being produced one after another. The next day, I worked on incorporating these new thumbnails (and additional minithumbnails for image results) into the main set of code, and I was delighted to see that a 200-result search now took 1/20th the amount of time it did before.

We also acknowledged that we are approaching the end of this summer's work and addressed the remaining tasks - everything from planning a fun outing as a lab to properly documenting and commenting the work we have accomplished and what is left to be done, for the next generation of Fauvel Scholars. It was exciting to realize that we have, in fact, reached significantly high levels of expertise on the study of this manuscript and the means by which digitiization and further exploration is made possible. I found myself discussing the challenges and complications that are raised by programming for a touch interface with my labmate Brendan as we swiftly moved between the Surface and the computer, tweaking the code and immediately running it for testing. Thinking back to the first week, when all we knew was how to run the default Surface code and see a black screen fill the display, marveling over the touch sensors when we poked at it, it truly felt like we'd come a long way, opening new tabs, zooming, displaying translations, and searching this powerful digital tool that we'd made ourselves.

As I waited for the train back to NYC for the Facebook Hackathon, I started talking to a rising senior in high school and her mother whom I met at the station. They asked me a lot of questions about both Princeton and Columbia, and then we began discussing Computer Science. She asked me how and why I chose to study Computer Science, and I was surprised by how genuinely excited we both got as I described the inspirational and supportive qualities of the last Hackathon I attended and the incredible feeling you get when your code compiles and runs and you can share the program you've created with your friends, and how comfortably I was able to describe the Fauvel project and my contributions. I told her to keep the DREU program in mind, if she ended up moving in a CS direction, and I was happy to see her pull out a notebook and jot down the suggestion. There are moments when this manuscript and our project seem like such a small endeavor in the face of the entire field and all the possibilities out there of what to study, but I see more and more every day how the things I do and the ways I learn to think about and solve problems give me a better sense of my direction for the next few (or more) years. And if I can inspire a friend or two to give CS a try, I'll feel like I've done my part in helping the CS community grow.

I have now arrived at the Facebook Hackathon, and I'm thinking that I might just write about it as the 24 hours go by... so here goes!

• 12:00 PM. Got to Facebook. The security systems are pretty intense, which is intimidating but very cool. The ID badge they gave me has the sketchiest mug-shot type photo of me. I'm here with Kaushik waiting for Mark (both CS buddies from Columbia) in this very nice, colorful lounge with lots of free food and drinks. I keep reminding myself I can't go too crazy with the caffeine this time (9-10 coffees and redbulls at the last Hackathon definitely freaked out my mom) but perhaps I shall turn to smoothies this time around. As usual, the male female ratio can be aptly described as such: The odds are good but the goods are odd. There seem to be quite a few teams that preformed, or even people who arrived with their entire team. I'm sort of enjoying people watching, actually.
• 2:38 PM. Kaushik, Mark and I have snagged a nice, big conference room with comfy benches along the side - a good thing to have, considering we more likely than not will crash and take naps at some point. We picked an idea which several Facebook engineers were excited about when we chatted with them for advice, which was encouraging - a way of "sanitizing" your Facebook profile for college or job application processes, checking photos for inclusion of alcohol (namely, red solo cups, at least for now), and posts with profanity. Now, we're struggling with my favorite part of programming (read: least favorite, by far) - installation. It can be very frustrating to wait for all these programs to get downloaded and installed when all I want to do is jump into the actual coding, but hopefully it'll be resolved soon. The good thing is that this time, unlike the Music Ed Hackathon, we're starting our work at 1:00 PM instead of 10:00 PM. Supposedly this should help with energy and productivity rates, although I'll be honest - I'm starting to get a little sleepy... Trying to avoid all coffee/frappucinos, but I've started drinking some tea.
• 4:22 PM. Starting to figure out php...
• 6:30 PM. Wrote a php program that takes in a string and identifies all the bad words in it, matching against a long list of nearly 500 "bad words" that we found online. It was kind of amusing asking the Facebook interns for assistance with why one explicit word was being found but another wasn't; luckily, they had great senses of humor and found the whole situation funny. I'm not at all familiar with php, so it was a bit tricky figuring out the syntax, but once again Google helped me out with most of that! It's gotten frustrating at points, but we're starting to make progress - Kaushik on the Heroku and Facebook app part, Mark with OpenCV for image/objection recognition (namely, SimpleCV), and my work on php and text filtering. On a separate note, I have now drank 1 smoothie, 2 teas, and 1 (my first) frappuccino.
• 8:13 PM. Struggling. Pygame, something I need to download to use SimpleCV (a simpler version of OpenCV for object recognition), is not installing properly. I switched to creating a Facebook app hosted on Heroku to try working on the recent-post-fetching part of our project, but then Heroku and Facebook Developers stopped working properly. Feeling frustrated. Kaushik is getting a Facebook engineer to help us out though so hopefully that'll get us somewhere...
• 8:35 PM. There's something pretty cool about being on Facebook at Facebook. In other news, the good news is that I have finally successfully installed one program. But now it turns out I need another too. Aaskldjfdlksfjdlkfjdklfjdklfjladkjslkdjfdf
• 9:00 PM. The nice Facebook guy came back to check on us! It was awkward bc I was sprawled out on the nice couch taking a nap. The good news is whatever buttons he pressed in fancy Facebook world helped me get past the Facebook Developer App Creation issues, but it seems that the bigger problem is that none of us can get onto our Heroku apps or GitHub... which could be an internet connection issue... Meanwhile, I am still on the great journey that is installation. My terminal is printing colorful things, though, so that gives me hope.
• 9:15 PM. OpenCV seemed to install properly, but trying to import it via Python is leading to a segmentation fault... Mark has helpfully told me that it is a bad fault, but no one has much clue of how to fix it.
• 9:30 PM. Heroku problems continued... Gabe the Facebook guy is being super nice and helpful though! Things that I wonder: How can we get around app timeouts for Heroku? What are segmentation fault errors? Will I stay awake for the next 15 hours? The only good news is that Mark is making progress.
• 9:47 PM. PROGRESS! HAPPY! The solution? Doing the same thing a twentieth time which happened to work, so that was nice. Mark is making progress too. He can now find red blobs. We are aware that this could be an issue if there are people wearing red shirts, but for now we will avoid people with red shirts. Ha.
• 10:00 PM. Bad news: the Heroku app stopped working. Good news: It's a new error. Bad news: We still don't know why it's happening... Except our guess is that when we log in to Facebook to access our app (which Kaushik and I have done),
• 10:17 PM. We have discovered that we can reach our Heroku app site if we open an incognito window in Chrome. Hmm...
• 10:38 PM. Mark took a pic of me and Kaushik sleeping. Now we are awake. Eating goldfish. We are feeling optimistic. Not sure why. Wonder how long this will last.
• 11:11 PM. MAKE A WISH! I wish to be alive in 12 hours. In the meantime, I'm beginning to make sense of the default Facebook app page and try and modify it to show photos and statuses only. Photos are easy because they're already there, but statuses are harder...
• 11:24 PM. Git struggles. :(
• 12:42 AM. There is not a lot of documentation for Facebook status fetching. Is it bc Graph API is a new thing?? thingsIWonder.add(that). Good news is that we got Facebook tshirts. They're cute. The small is a dress on me though. Oh well. We keep getting redirect loops on our app. Why? Why does this happen?
• 12:53 AM. This is hard and I'm tired. :( Now the boys are brainstorming ridiculous alternative ideas.
• 1:18 AM. Not sure why I'm so exhausted... Feeling really drained. :( At least now there is pizza!

For the next hour and a half or so, Paul, a major engineer at Facebook, came in to help us figure out the redirect issues that we kept running into when trying to navigate to our Heroku app's URL. After numerous examinations of the error logs, cookies, and even the fundamental Facebook code, we found that there was a bug in the default app created from the Facebook Developers page! Mark joked that we should actually get paid for this discovery, since people are usually paid to locate bugs in Facebook.

At this point, it was almost 3:00 AM. We could either hack around the bug (i.e. hard code our app for a test user, to get around access token and cookie issues), or we could try creating a completely different project. Mark and I debated the two options for a while, but ultimately decided that we had already learned a lot about image recognition, php, Facebook apps, debugging, etc. That plus our extreme fatigue (which I knew from my last Hackathon experience was only going to double and triple in the next 9 hours) pointed us in the direction of the wonderful land of sleep, so we hopped on a subway uptown.

Although I was a little disappointed that we didn't end up executing our project 100% and presenting it, I still felt like I'd gotten a lot out of the Hackathon. The Facebook office was very cool, and we'd gotten to chat with quite a few engineers - two of them (one technically working with business and not the actual coding) hung out with us in our conference room for a while, trading ideas and advice and contributing to motivational music choices via Turntable, the cool group DJ site that I actually use with Jamie, Brendan, and Chris in our Princeton Soundlab too. Watching Paul, clearly an expert in Facebook and its code, debug the default app was interesting for several reasons - we learned a lot from his debugging approaches but also saw that even the highest level coders can't just magically fix every bug. I suppose this could have been disheartening, along the lines of "You mean we can code for years and years but still not understand how to fix things??", but I saw it more as reassuring - there's no need for us beginners to feel intimidated or helpless or hesitant to reach out for help, because we all get stuck at some point or another.

Overall, it was a great experience. I'm glad that I opted for sleep at 4:00 AM, because I'm still quite exhausted and can't imagine how much worse I'd feel if I'd pulled an all nighter. It was very cool to have worked with Mark and Kaushik, both of whom will be my CS classmates at Columbia for another three years, and we're all looking forward to tackling another hack together during the coming year. I also had fun updating this website periodically, and I'm glad that the progression of my project, thoughts, and insanity are recorded here for my family/family to stay posted during the Hackathon and also as a fun memory for me to look back on.

This week, I again found myself trying to teach a computer to think like a human. I was working on a multi-word search capability for Digital Fauvel - while it is easy to match or find an exact phrase with more than 1 word in it, assuming they appear in that exact order, it is much trickier to treat the multiple words independently. One question that arises is how close together the words should appear in the text to qualify as a search result - if a user searches "torcher Fauvel", is it expected that an entire page will be marked as a match if the two words each appear once, 50 lines apart? Should every word - say, in a 5 word search - HAVE to appear in order to return a match, or can a passage that has 4 out of 5 satisfy the user? Many of these answers depend on whether the user is searching for a specific segment - say 5 lines, which is what we are using for now - that uses the specific words "Fortuna" (Fortune) and "Fauvel" versus a segment with the more general topic of Fortuna and Fauvel - in the latter case, the search breadth would perhaps need to be wider than 5 lines.

In the process of contemplating these questions, I had to make a lot of choices independently, in order to move forward with the coding, while allowing for later flexibility and adjustment. For example, the multi-word search currently only returns results that match every single search word, no matter how many there are. However, I was careful to mark off an adjustable section of code, for the purposes of easier re-design should someone decide later to allow more lenient search returns. Since multi-word search can include anything from two words to technically any number above that, I had to keep that in mind when designing things like the styling of the text excerpt in the result close up section (where a thumbnail and text excerpt for a selected search result are displayed), since I needed to be able to search for X number of words and bold those only, in any order, and whether some of them appeared adjacent to other search words or not. I also engaged in several high level conversations about these search-related questions and concepts with Professor Fiebrink, who echoed many of the possibilities and considerations that I myself had come up with and also noted that these are very large-scale questions. It was very interesting to discuss and weigh the pros and cons of potential choices, and, as she pointed out, I'm lucky to have met these important challenges after a relatively short amount of time in the Computer Science field.

I also learned a great deal about the implications and values of what we have created this summer. Princeton musicologists Anna Zayaruznaya and Jamie Greenberg came to our lab along with MIT's Michael Scott Cuthbert, who is an expert in both the music and programming spheres of Fauvel. We presented our work to them and then talked about/asked their opinions on the next steps for the project. Although Anna had seen our work earlier this summer, her last time in our lab was perhaps 4 or so weeks ago, and she was extremely excited by and pleased with our progress. Her praise was wonderful to hear, as we, like parents who watch their kids every day and don't always notice any change, hadn't fully realized how far along our Fauvel code on the Surface had developed. We had a great time watching Anna, Jamie, and Michael play around on the Surface, trying out different functions, searching for words in one language and then another, zooming in on images and then toggling a translation overlay, both because it made us happy to see how much they appreciated what we were creating and also because watching them use our program taught us a lot about the expectations other users may have for Digital Fauvel.

As I round the corner to my last week of DREU and last few days on Princeton campus, I realize how much I will miss working in the SoundLab. Part of it is indeed that we have all become good friends, taking turns to pick music on Turntable or ordering Chinese food and sharing funny YouTube videos during lunch. We've made countless jokes about petting Fauvel that no one outside of our lab will ever understand, and we've overall made a summer full of quite a lot of hard work into a fun one nevertheless. A big part of our sense of companionship and accomplishment is also our mutual understanding of how far we've come from the first week, when both "Fauvel" and "C#" were very much foreign to us. And although we know that once we leave this lab, not many people will know who Fauvel is or why this manuscript is important, many of the skills we've picked up along the way will still apply - from CS-specific things like how to navigate git (I was even able to reorganize and clean up our repository, finally debugging the mysterious .gitignore issues) to life skills like working closely with other members of a team without stepping on each other's toes or driving each other crazy.

Brendan, Jamie, and me - plus "Big Sur", our Microsoft Surface 2.0:

The Fauvel undergrads (Brendan, Jamie, and myself) with Professor Fiebrink

A fortune cookie recently told me: "The time for reorganization is now." This seemed very fitting, as a good part of my last week at Princeton was spent preparing for the next generation of Fauvel scholars: commenting our code, documenting our findings, creating lists of "Future Steps", both immediate and far off, and organizing our repository. Although I am sad that I won't be as involved with the upcoming developments, it was still very exciting to share the information we've gathered (tips for encoding, instructions for preparing visual/audio files, etc). Meanwhile, while writing my final report (XML and Search Capabilities for Digital Fauvel) for DREU, I was also looking back at the prior research on encoding and UI design that had served as a foundation for our work this summer, making me all the more aware of this cycle of collaboration and communication.

Writing about my research was intriguing in itself, because as I learned to describe Digital Fauvel in a way that made sense (and was interesting to) all sorts of audiences, including coders who know no music and musicologists who have never coded, I became even more aware of the overarching significance of our work. The cross-disciplinary efforts between the music humanities and computer science made our project relevant to present and future work in both fields, and the questions I had faced represent greater challenges that are inherently present in the intersections of two fields. Writing my paper gave me valuable experience in writing about computer science, something I have not yet encountered in my studies. Furthermore, thinking about the ways in which the various sections of Fauvel that I focused on connected to and built on each other made me realize the high level I reached by the end of my time in the Soundlab.

I left Princeton for the last time yesterday, bidding my labmates, Big Sur (our Microsoft Surface 2.0), and Fauvel farewell. Although I was initially intimdated by the idea of diving into computer science research for 10 weeks as a CS beginner, over these two and a half months, I know that I have learned a great deal, and more importantly learned how to learn more CS skills. I started off knowing very little about Fauvel, and now I can talk about its story, musical genres, quirks, and intricacies for hours. I have learned to work closely with a team, from concrete skills like using repositories for version control to more general principles like dividing up a large project so we can work independently but cooperatively. I have found that my two passions, music and computer science, are not only possible to bring together but also very powerful and extremely interesting when combined. Aside from the actual work I did in my lab, I also learned a great deal about the CS culture (supportive, fun, and definitely nerdy in the best possible way) by spending time with my labmates and pulling all-nighters at Hackathons.

I walk away from Fauvel happy that my contribution to the project will be forever part of Fauvel, and thankful that I am close enough to Princeton that I will have the chance to see the project continue to grow. I am now all the more excited to return to Columbia in two weeks and start coding, Princeton CS coffee mug in hand as a reminder of all the laughter and learning from this summer. But before I do that, I'll get to enjoy a week on vacation in Europe with my family... and visit the original Fauvel manuscript at the National Library in Paris. =]