<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Blog</title>
    <link rel="alternate" type="text/html" href="http://blog.lib.umn.edu/copen004/myblog/" />
    <link rel="self" type="application/atom+xml" href="http://blog.lib.umn.edu/copen004/myblog/atom.xml" />
    <id>tag:blog.lib.umn.edu,2012-03-04:/copen004/myblog//15962</id>
    <updated>2012-04-04T16:29:14Z</updated>
    
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type Enterprise 4.31-en</generator>

<entry>
    <title>Iteration 1</title>
    <link rel="alternate" type="text/html" href="http://blog.lib.umn.edu/copen004/myblog/2012/03/iteration-1.html" />
    <id>tag:blog.lib.umn.edu,2012:/copen004/myblog//15962.346464</id>

    <published>2012-03-19T14:04:04Z</published>
    <updated>2012-04-04T16:29:14Z</updated>

    <summary> Figuring out how to implement the scanner for iteration 1 was a difficult task, though it was made possible through teamwork and looking back at what we had learned earlier in the class. Working as a team was quite...</summary>
    <author>
        <name>copen004</name>
        
    </author>
    
    
    <content type="html" xml:lang="en-us" xml:base="http://blog.lib.umn.edu/copen004/myblog/">
        <![CDATA[<p>   Figuring out how to implement the scanner for iteration 1 was a difficult task,<br />
though it was made possible through teamwork and looking back at what we had<br />
learned earlier in the class.<br />
   Working as a team was quite helpful in making sure the code was error-free and<br />
finished on time; however, our final code could have been improved with certain<br />
changes that we certainly will try to make in the future. Most of the work was done with both partners working at the same space, sometimes on a single computer, sometimes<br />
on two. This approach was very helpful in weeding out simple syntax errors, such as<br />
misspellings, forgotten variable names, and misplaced symbols. Also, by working in the<br />
same space, but on different computers, we were both able to work on writing test<br />
cases simultaneously, stopping to check each others' work and quickly eliminating<br />
errors. However, by doing most of the work simultaneously, the iteration was not<br />
finished quite as quickly as it could have been: in fact, the not-quite-functional final<br />
product was not fully committed until mere minutes before the deadline. In order to<br />
avoid this kind of stress in the future, we should focus on spending more overall time<br />
working on the project, which would require both partners attending office hours during<br />
times the other partner can't come, as well as breaking up duties more effectively by<br />
planning the project and figuring out what needs to be done ahead of time. However, it<br />
is still important that the project be error-free as well as completely finished on time, so<br />
retaining a focus on simultaneous work will remain important in keeping the code<br />
airtight.<br />
   We have been using the iterative method for the project, and it has been a very<br />
efficient way to work on the project and one we would stick with, even if it were not<br />
required by the class. By separating different sections of the overall project into<br />
iterations, each of the iterations can be sufficiently coded and tested enough to be<br />
confident that it works before moving on. Within the iteration itself, we took an iterative<br />
approach, working on each subsection of the scanner and writing tests before going on<br />
to the next; for example, before making a loop to tokenize the input into regular<br />
expressions, we wrote tests for the regular expressions we had written previously. By<br />
sticking to an iterative approach within the scanner, we were able to work on each<br />
subsequent part of the code without running into problems with the previous section.<br />
   One of the most important actions taken to successfully finish the first iteration<br />
was using all of the many resources given to us. Although building a scanner seemed<br />
to be a difficult task at first, by looking back at the previous labs and lecture notes, we<br />
were able to figure out a framework for the project, and found that many of the methods<br />
used in the word count program could also be adjusted to work with the scanner.<br />
Attending office hours was also essential, as the TAs and professor were very helpful for<br />
pointing us in the right direction, though we could have attended more office hours than<br />
we did. Similarly, the Piazza board was helpful when other people had the same<br />
problems as us; however, we could have improved its helpfulness by posting our own<br />
questions as well. In any case, ample resources are provided for finishing the<br />
iterations; we simply need to figure out how to use them more effectively than we<br />
already have.<br />
   The largest difficulty in the first iteration was getting the scanner to pass all of the<br />
provided assessment tests. We were unsuccessful in achieving this; however, since<br />
grades are broken into two sections - human and machine grading - we should have<br />
this fixed by the end of the second iteration. Thanks to our way of working on the same<br />
computer, we were able to check one another's formatting to ensure that we would get a<br />
good grade in the human-checked section. By improving our team dynamic, working<br />
harder, and better utilizing the resources provided, we can be more successful on the<br />
second iteration.<br />
</p>]]>
        
    </content>
</entry>

</feed>
