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:

    $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:


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

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

    # 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

    count=$(($count + 1))

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

    if [ $another != ‘y’ ] && [ $another != ‘Y’ ] && [ $another != ‘yes’ ] && [ $another != ‘Yes’ ]

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

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.

Throughout this capstone course, small groups worked together to create an overall project. Because of the format of the class, a method of collaboration was needed and the one that made the most since was git through github. Git allowed the teams to work individually on their parts and then merge changes to the larger effort. This way of collaboration and version control worked well to assure the fluidity of the project. The only setback associated with using git was the fact that it was a new concept to many in the class and the features were being learned throughout the course.

There is currently the initiative to introduce git in the first programming course offered as a way of working with lab partners and submitting assignments. After students learn to use git in one of the introductory courses the idea can be used throughout the college career as a means of collaboration, version control, and centralized organization. Dr. Wurst is in the process of drafting a lab to introduce git and will use it as the way submit assignments.

Version control such as git is valuable for individual development as well as large group projects and learning it early on will be very valuable throughout college and career. Personally, I’m very excited to see how the idea of introducing git early on will change the dynamic of the Computer Science major at Worcester State.

Hello everyone,

Now that we have an open ssh port on our server, individuals can log on and look at the code structure or play around with their own development folder. Once you have a username, you should log onto the server and change your password for security reasons.

Using SSH to Gain Access to the Server

The easiest way to gain access to the server and change your password is to use SSH. If you are using a windows machine you should install putty. Once you have putty installed you can place the url in the server field and leave the port on 22. When the prompt shows up enter your username and then type your password. If you are using windows or mac, you can SSH from a terminal by typing ssh username@server and then type your password when prompted. Be aware that you won’t be able to see any characters when typing your password but it’s being entered.

Changing your Password

Once you’re logged onto the server which is running CentOS you can easily change your password by typing passwd and hitting enter. This will prompt you for the current password and then you can type your new password. Again no characters will show up but this is normal.

In Your Home Folder

You should see one directory in your home folder, which is where you can place all the files that you want to test through the web server. This is a folder that is sim linked to a folder in the webroot. In order to test any code that you place in here you can go to cstest.worcester.edu/development/your_username or simply go to cstest.worcester.edu and navigate to your folder from there.

If you have any questions, please blog about them or send out a message on the ListServ.

If you’ve noticed, GitHub offers three ways to access a repository, two with read-write access and one with read-only access. For this project, each user is granted push-pull access (read-write) so eac of us can contribute code. The two methods which provide both read and write access are HTTP and SSH.

Using HTTP you can download an application and gain access using your GitHub credentials. As a member of the project you’ll be granted write privilege with these credentials (the project is open source and therefore, anyone already has read privileges). 

The other option is to use SSH, which allows you push and pull directly from the command line. In order to do this, however, you need to copy your public ssh-key into the ssh section on your GitHub account. Once the key to your computer is in the settings on your GitHub account you’ll be able to push to the database.

Once I have some more time to sit and work on it, I am planning to provide some steps to accomplish this. I thought having the information now would be helpful for those who would like to look into it more individually.