I quickly wanted to show the directory structure that we used for this course, and the git branches associated with them. We are using a CentOS 6 machine with apache as the web server. We also installed php for the git scripts which lie in the web root.

> /var/www/html/ – Web Root, No Git Association

> index.html – Show a list for Master / Development / or Users, No Git Association

>> master – The final project ready for deployment, Git Master Branch

>> test – The most complete branch for testing, Git Development Branch

>> development – Used for user directories, No Git Association

As I played a major role naming the directories, I take the full blame for the blunder of naming a directory test and linking it to a development branch, and then proceeding to name a directory development and using it for something else. Sorry about that guys.

 

CS401, the capstone for WSU Computer Science, is a very useful class as it shows some real world applications. As a member of the server group, I was able to help set up the back-end of the project and integrate the code with a working web page. In order to accomplish this, I was able to practice my scripting, working with apache, improving git abilities, and again, finding the headaches associated with permissions. Some of the most satisfying results of the class were working with others on a large project, trouble shooting with peers, and seeing a full scale development task move from infancy to completion throughout a single course. It was a great semester and very valuable to future success.

Although the overall class was a success, there’s always some things that could have been done better. I wish I would have gone back to fix the git script, it was done so it worked and then it was forgotten about. I wish I went back and maximized the efficiency of this script. The other opportunity I wish I grasped a hold of was working with some of the html, css, and javascript of the other groups, possibly helping to debug or lend a hand when needed because I would have liked to learn a bit more of those languages.

All our code throughout the semester was placed on git and then brought to the server for testing/deployment. Instead of having to log on to the server and pull code every time a change was made, we wanted to update the server every time a change was made.

In order to accomplish this, we looked into GitHub’s web hooks, which work by calling a script every time a pull request goes through. The idea of this seemed simple, but we ran into some problems with permissions. In order to accommodate this, we decided to delete the whole directory and re-clone it into the same place by the following php script:

<?php
    date_default_timezone_set(‘America/New_York’);
    $gitRoot = “/var/www/html/master”;

    // Use in the “Post-Receive URLs” section of your GitHub repo.
    if ($file = fopen(“log.txt”, “a”)){
        fwrite($file, “Update ” . date(“F j, Y, g:i a”));
    }

    if ( $_POST[‘payload’] ) {
        $delete = shell_exec(“rm -rf $gitRoot”);
        $clone = shell_exec(“git clone -b master https://github.com/CS-Worcester/CS401Spring2013.git $gitRoot”);

        fwrite($file, “\n\tPayload Received\n\tClone: $clone\n\n”);
    } else{
        fwrite($file, “\n\tNo Payload Received\n\n”);
    }
?>

The better way to do this would be to pull changes into the directory, which is much quicker because it updates only the changed files. This wasn’t followed up on after the quick fix because the quick fix was needed early in the semester, and other things arose before re-addressing the issue.

After creating the user directories, we had to allow the user a way to put their code in the web directory. There were two main ways to accomplish this that was explained on an as-need basis in class. The two (perhaps three) methods are to modify code locally and use FileZilla to transfer files to the directory, modify code locally and use scp to place the code on the server, or ssh into the server and modify code directly in the test directory.

From working with individuals throughout the course, the majority seems to be using FileZilla, but it’s nice to have the option to work directly in the folder’s code.

When we started working on a web project, we were using git for individual parts of the project but we wanted to see the projects as a web page and updating git to wait for results was a bit more difficult than expected. Because of this, we decided to create user directories on the server hosting the project which would render everything through the web server. This made testing much easier, as any scripts could be tested locally.

The user directories were creating using the following script:

user=
pass=
users=
passwords=
count=0

while [ 1 ]
do
    # Prompt and get the username
    echo -n “Enter username [Blank to Exit]: “
    read user
    if [ -z $user ]; then
        break
    fi

    # Check for errand username formats
    if [[ ! $user =~ ^[a-z] ]]; then
        echo “Invalid username”
        continue
    fi

    # Set up the user and directories
    useradd $user -d $BASE_DIR/$user

    mkdir $WEB_DIR/$user
    chown $user:developer $WEB_DIR/$user
    ln -s $WEB_DIR/$user $BASE_DIR/$user/html
    chown $user:developer $BASE_DIR/$user/html

    users[$count]=$user
    count=$(($count + 1))

    # Check for more users
    echo -n “Another User? (y/N): “
    read another
    if [ -z $another ]; then
        break
    fi

    if [ $another != ‘y’ ] && [ $another != ‘Y’ ] && [ $another != ‘yes’ ] && [ $another != ‘Yes’ ]
    then
        break
    fi
done

for (( i = 0; i < $count; i++ ))
do
    echo “Username:    ${users[$i]}”
    echo “${users[$i]}” >> users.csv
done

The script creates a new user given a user name and creates a home folder for that user. Then a directory is created in the development folder of the web directory with the same name as the user name. The permissions is then corrected so the correct user can edit their code. Once this is done a symlink is placed in the user’s home folder to make it a little easier. To place your code in the web directory you just needed to place your code in your own html folder.

To access an individual’s web work, you could go to cstest.worcester.edu/development/ and get a list of the user directories. You could then view the work by clicking on the correct user.

Working with the Worcester Art Museum has been a good experience for working with a client and making sure a project will be complete and thorough. Throughout the course there were both some challenges faced and milestone achievements.

Most of the work I did during the semester was done in the server group so there was not as much direct interaction with Tim and WAM as most of the other groups, although there was some. The server group started by ensuring that the final project would be able to be deployed on the Worcester Art Museum’s iPads and that the project was easy to maintain. After deciding to move to a web page as the main project deployment wasn’t an issue. As it turns out, the museum has a web server where we can deploy the finished product and they can maintain it locally. With all these things established, the server group looked for ways to potentially expand, and that’s where working with a climate can be challenging.

Part of the initiative for the server group was to look into a way we could use a database to improve the features of the project. The major ideas that surfaced were to email coloured images to a provided email, save images for other patrons to view, save high scores for the puzzle, and leave comments about the exhibit. When talking to WAM about these features it was determined that databases weren’t going to be used because it added to the complexity of maintenance. This was a bit of a bummer because as a group we were really looking to contribute a front end feature instead of all back end.

In the end, it all worked out, and every thing went well. At this point we are just finishing up some final polishing and getting ready to deploy the finished project. 

 

All computer science courses up to this point have dealt with individual or small group assignments. In these assignments we began with either a complete instruction set or a template, a starting position, and an end goal. Using these assignments we have been able to learn concepts and basics which can be placed together to form larger projects.

During this capstone course we have moved away from this fairly standard model, going over a semester long project, breaking into groups, and determining different paths to take to get from point A to point B. Unlike most classes where deadlines were weekly, and assignments complete, this course featured a more abstract plan. Although updates on progress were given, the deadlines were defined by the groups and almost anything was acceptable providing the project would be completed on time.

This model is close what I’m expecting in the real world. Tasks, mostly small parts of larger projects will be assigned, and a deadline given. Based on this deadline, we will have to develop a plan, determine what course of action needs to be taken, and meet the deadline. I enjoyed that this class was like that and it has really prepared me for my future career opportunities.