Category Archives: CS-499

Preparing to Present

Over the past semester, I’ve been working with Dr. Vallejos to build a website for Massachusetts HOSA. At the conclusion of my independent study project, I will be presenting my project to the Computer Science faculty and other CS students. In preparing for this presentation, I came to a couple of realizations about what I’ve learned from this experience.

While I certainly think that I have improved upon my technical skills in CSS and PHP, I think that what is perhaps more valuable is the immense amount of real-world project management experience that I have gained. This experience has already allowed me to build a better understanding of project requirements at work and for the software development capstone project with AMPATH Informatics. Being able to understand the requirements of stakeholders is essential to delivering a product that meets their expectations. Asking the right questions the first time will prevent having to reach out again and again for clarification of the requirements. People are generally very busy and they will not be available to answer your questions or provide you with information. Whether it is a customer, manager, or product owner, it is best not to waste other people’s time with comeback questions because of your own failure to fully consider the project’s requirements.

I also believe that I greatly improved my personal software development process throughout this project. Although it took a couple of mistakes for me to learn, I am thankful that I made these mistakes in a safe environment and lost nothing but a few hours of my time. I was initially pretty careless, making customization changes to the theme files directly on the web server itself, not backing up, and not tracking any of my changes. After losing all of my theme customizations by updating the theme, I decided to make some changes to this process. I implemented Git version control, allowing me to make and test changes locally before pushing to the actual website as well as tracking changes incrementally and allowing me to rollback to any revision, as desired. I also implemented automatic offsite backup in Google Drive, which runs weekly to ensure that even if I do mess something up, there’s always a working copy safely stored elsewhere.

I have always been an avid believer in learning through experience, and the MassHOSA website project has been a fantastic opportunity to learn through my experiences. Not only have I had the chance to both sharpen my technical skills and widen my skill set, I have gained invaluable experience managing a project and working with stakeholders on bringing an idea from the conceptual phase through to a working product.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Thinking Like an End User

I am getting ready to deliver a website product that I have been working on for Massachusetts HOSA. Because I’ve been working on the development of the website for the past couple of months, I am familiar with where to find everything. Once the product is delivered, however, it will be updated and maintained by Massachusetts HOSA. While I would be perfectly happy to continue helping out with the website as needed, I would like to minimize the need for my involvement by making the website as self-sustaining as possible.

In previous blog posts, I already outlined the setup of automatic backups. This makes me feel much better about enabling automatic updates for the WordPress installation. With automatic upgrades enabled, the site will be kept secure and up to date as WordPress and plugin or theme developers release new versions. I would be weary of allowing automatic updates if I was unsure of whether or not there were current backups because of the possibility of an update breaking the site. Occasionally there are incompatibilities between different plugin/WordPress version combinations, or simply bugs in a release that could make the site unstable. In case of such a scenario, having a recent backup that can quickly be rolled back to is essential.

The second part of making the site self-sustaining is to write documentation for the use of this specific WordPress installation. While WordPress is already extremely well documented, this vast documentation can sometimes be difficult to navigate efficiently. I would like to pick and choose the essentials to include in a slimmed-down version of documentation to provide to MassHOSA as a guide for the maintenance and updating of the website. This documentation will include guides for use of the WordPress platform, use of the various plugins that are installed, and also references to the locations of various resources such as backups and styling files.

I am extremely thankful for the opportunities that working on this project has granted me. While I may have had some prior experience building WordPress websites, this was quite different. I got a much better idea of the various stages of a design project and experience working directly with stakeholders to turn specifications into a working, real-world implementation.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Transitioning

After meeting to discuss the current status of the website, there are only a few tasks that remain. Although I am still waiting on some of the design content such as images and social media links to be provided, I think that the website design will soon be wrapped up. Once this happens, the next step will be education and training on the use and maintenance of the site. This should not be too intense because of how intuitive WordPress is to use.

Part of this training will likely involve the transfer of the hosting off of my personal virtual server to a permanent host. While I do not mind hosting the site for the time being, I do not want to be responsible in the case that my server goes down. When using a well known hosting provider, you are paying for someone to take on this responsibility. I have prepared the site to be migrated, and I do not anticipate any issues with migration. WordPress is rather portable, not requiring much more than a few directories and a small database.

One item that still needed to be addressed was the size of the font used on the website. Although it appeared appropriate on my screen, it was difficult to read from a distance on higher resolution monitors. While I had tested the website in a few different browsers and even on my mobile phone, none of these allowed me to view the site as if I were using a higher resolution monitor. During the meeting, when viewing the site at a higher resolution, the text appeared to be “zoomed out” and was difficult to read in some of the lower contrast areas of the page.

The next thing that I will be looking at for the MassHOSA project is QuickBase. I am familiar with the platform because of an internship where I am currently auditing and validating user access to QuickBase. Despite this familiarity, there may be a few obstacles to making the desired changes. After a quick inspection of the application, many of the features required to make the desired changes to the application are blocked due to the QuickBase tier in use. I will be looking for workarounds and discussing the potential solutions during my next meeting.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Preparing to Migrate a WordPress Site

Now that I’ve got a functional website built for the MassHOSA project, it is time to start preparing to move it the website to its permanent home. Development has been straightforward partly because it has taken place while the server has been living on my personal virtual private server. With full SSH access to the development server, it was much easier to make server-side tweaks to various environment settings. Many of these tweaks had more to do with my server being misconfigured than with WordPress, however. I am hopeful that the permanent hosting environment that is selected will require minimal modifications. Many of the hosts that we’ve looked at, for example, have environments tailored specifically for WordPress hosting.

To begin preparing, I copied the entire WordPress directory to my local machine using SCP. While this took some time, I wanted to be sure that everything was transferred and remained intact. I did not necessarily trust that FTP was up to the task, as I have had some problems with file integrity after using FTP for large-scale file transfers. While there may have been many other contributing factors, I thought I would try SCP instead this time, at least for the downloading of the website files to my local computer. FTP may be the only option for uploading the files to the new host, as many shared hosts do not allow SSH access.

The next step of the preparation process was to export and download the contents of the database associated with the installation. Choosing how I export the tables is important, because of the limited privileges that may be available for importing the data on the new host. To ensure that I would be able to import the tables on the new host, I used the account used by WordPress to access the database, and exported all of the tables in the database. This way, even if the new host allows only one database, I will be able to migrate all of the necessary tables and simply update the wp-config file to point to the correct database.

Thankfully, if anything goes wrong during the setup of the site on the new host, I have the working installation on my virtual server to fall back on while working things out. I hope that I have not overlooked anything and that the migration will be straightforward and painless.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Using Git with WordPress

As part of my continued efforts to not lose all of my hard work, I’m implementing tools to help me track changes and have decided to use version control to do it. I’ve chosen to use Git because of my relative familiarity with the tool.

For a bit of background, my web server is running Ubuntu 16.04.3 LTS and the latest version of WordPress at the time of this writing, version 4.9.4. Because GitLab allows for free private repositories and the nature of the project makes a public repository undesirable, it was chosen over GitHub. One thing to note about this setup is that I have full shell access to the server, allowing me to install programs and edit properties as necessary to get things setup. When the website is eventually migrated to its permanent hosting location, some changes may be necessary to the following setup to accommodate the server implementation. Many shared hosting providers do not allow shell access, and a new strategy would need to be considered in this case.

I started the setup by performing a bit of housekeeping with

sudo apt-get update

and then performed the initial Git installation with

sudo apt-get install git

I then performed the usual Git setup, uploading my SSH user’s key to GitLab and setting my username/email with

git config –global user.name “Your Name

git config –global user.email “youremail@domain.com

After cd’ing to the directory of the website files, I issued the command

git remote add origin git@gitlab.com:MassHOSA/masshosa-website.git

An important step here is to make sure that no sensitive files are tracked by Git. I did this by adding a .gitignore with the following:

#————————

#  Main ignored items

#————————

/../wp-config.php

/wp-config.php

.maintenance

versionpress.maintenance

/.htaccess

/web.config

/wp-content/*

!/wp-content/db.php

!/wp-content/index.php

!/wp-content/plugins/

/wp-content/plugins/versionpress/

!/wp-content/mu-plugins/

!/wp-content/themes/

!/wp-content/languages/

!/wp-content/uploads/

!/wp-content/vpdb/

#————————

#  Log files

#————————

*.log

error_log

access_log

#————————

#  OS Files

#————————

.DS_Store

.DS_Store?

._*

.Spotlight-V100

.Trashes

ehthumbs.db

*[Tt]humbs.db

*.Trashes

at this point it was safe to issue a

git add .

and commit with

git commit -m “Initial commit”

and finally push changes with

git push –set-upstream origin master

And that’s all there was to it. I’m now tracking all of the changes that I’m making to theme and plugin files. These are the only files that I really care about reverting and recovering changes that I’ve made. Everything else is backed up regularly using Updraft.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Using Git with WordPress

As part of my continued efforts to not lose all of my hard work, I’m implementing tools to help me track changes and have decided to use version control to do it. I’ve chosen to use Git because of my relative familiarity with the tool.

For a bit of background, my web server is running Ubuntu 16.04.3 LTS and the latest version of WordPress at the time of this writing, version 4.9.4. Because GitLab allows for free private repositories and the nature of the project makes a public repository undesirable, it was chosen over GitHub. One thing to note about this setup is that I have full shell access to the server, allowing me to install programs and edit properties as necessary to get things setup. When the website is eventually migrated to its permanent hosting location, some changes may be necessary to the following setup to accommodate the server implementation. Many shared hosting providers do not allow shell access, and a new strategy would need to be considered in this case.

I started the setup by performing a bit of housekeeping with

sudo apt-get update

and then performed the initial Git installation with

sudo apt-get install git

I then performed the usual Git setup, uploading my SSH user’s key to GitLab and setting my username/email with

git config –global user.name “Your Name

git config –global user.email “youremail@domain.com

After cd’ing to the directory of the website files, I issued the command

git remote add origin git@gitlab.com:MassHOSA/masshosa-website.git

An important step here is to make sure that no sensitive files are tracked by Git. I did this by adding a .gitignore with the following:

#————————

#  Main ignored items

#————————

/../wp-config.php

/wp-config.php

.maintenance

versionpress.maintenance

/.htaccess

/web.config

/wp-content/*

!/wp-content/db.php

!/wp-content/index.php

!/wp-content/plugins/

/wp-content/plugins/versionpress/

!/wp-content/mu-plugins/

!/wp-content/themes/

!/wp-content/languages/

!/wp-content/uploads/

!/wp-content/vpdb/

#————————

#  Log files

#————————

*.log

error_log

access_log

#————————

#  OS Files

#————————

.DS_Store

.DS_Store?

._*

.Spotlight-V100

.Trashes

ehthumbs.db

*[Tt]humbs.db

*.Trashes

at this point it was safe to issue a

git add .

and commit with

git commit -m “Initial commit”

and finally push changes with

git push –set-upstream origin master

And that’s all there was to it. I’m now tracking all of the changes that I’m making to theme and plugin files. These are the only files that I really care about reverting and recovering changes that I’ve made. Everything else is backed up regularly using Updraft.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Backing Up

In light of what happened last week, I decided to make coming up with a strategy for backup a priority on the Massachusetts HOSA website. After all of the work that I put into the design the first and second time around, I do not want to risk losing it again. In many regards, I am thankful that losing the data happened when it did. It has allowed me to improve my habits and develop in a more efficient and sustainable way.

The first thing that I made sure to do once I had restored the design of the website was to make an initial back up of the files and database. Although there are more efficient ways (I’ll explore some of these later), I chose what was easiest at the time and copied the files from the web server to my local hard drive through an FTP client. Through an SSH session, I dumped the contents of the database to a .sql file and transferred this file to my local computer, again through FTP. I am now far less paranoid making changes, because I know that I have this backup to fallback on should I mess anything up beyond repair. This backup contains the entire base site, with all design completed per original specifications.

After meeting to discuss the next steps, I will undoubtedly be making more changes to the site. Rather than having to initiate these backups manually each time using the process I described above, I would like to have some way of automatically backing up changes on some sort of a regular schedule. After researching plugins that could accomplish this, I found UpdraftPlus. I wanted to use a plugin rather than something server-side because we will be migrating the WordPress installation to a different server following development. By using a plugin rather than some sort of cron job or script on the server I would eliminate the need to completely reconfigure the backup service after the migration.

After initial setup, I ran a forced backup using the UpdraftPlus plugin. Despite a few files that the tool was unable to backup due to incorrect file permissions, the backup ran smoothly and stored all of the pertinent website data, including a database backup, on my Google Drive account. The only thing that has to be done at this point is to transfer the backup location to someone who will be able to access them if needed following development. I’m very happy to have found a solution to the problem of backing up, and looking forward to not worrying about breaking the website.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Recovering from Tragedy

After last week’s post I made a simple click that I’ve made probably hundreds of times before when I updated WordPress on the MassHOSA website. The difference this time, however, was that I wasn’t only updating the WordPress core but also the theme that was currently being used on the website. Depending on the update, you can sometimes get away with updating themes without losing customizations. If, however, the update includes changes to say styles.css, for example, your customizations will be obliterated.

I have nobody to blame but myself for this mistake. I was fully aware that updating a theme could wipe out customizations, and WordPress even has a handy warning on the theme update screen:

But, I was not thinking and clicked update – and lost all of the customizations that I had made to the theme, permanently. Here lies another issue: backups. I should have been making regular backups of both the WordPress filesystem and SQL databases, since at this point I have put a significant amount of effort into both the design (stored mainly on the filesystem in CSS and PHP files) and the content (stored mainly in the SQL database).

While this incident was certainly frustrating, it’s not that tragic. I was able to restore the customizations (this time in a child theme) in a matter of a few hours, and am happier with the outcome this time than I was after my original modifications. Using a child theme forced me to do things a bit differently than the first time around, but at this point I already had a pretty good idea of the changes that needed to be made. I am happy to be doing things the right way now, as my original design would not have been sustainable. Making changes directly to the themes CSS files means that you cannot apply updates as they become available. While this would be fine if updates only ever contained feature additions or style modifications that you were not interested in, this is not advisable when some updates contain security patches. Given the choice between leaving my website vulnerable to attack and losing customizations, I would rather put in a couple of hours of doing customizations the right way than face the repercussions of a breach.

 

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Adding Content to the Skeleton, an Adapted Scrum Methodology

This week marks the beginning of adding real content to the skeleton site that I have been developing for Massachusetts HOSA. The content was provided to me in the form of a word document, with titles to differentiate between pages and sections. The first thing I did upon receiving this document was break the document down into individual user stories. I then created a Trello card for each story and placed the cards on the product backlog list. During this process, I was reading and building an understanding of the product owner’s vision for the website, as well as attempting to come up with potential acceptance criteria. I was also informally coming up with estimates for the amount of time and work that each story would take, but decided not to include these as part of the stories as it would offer minimal return on investment with me as the only developer. I looked at this process as a sort of modified Scrum Story Time meeting.

The next step was Sprint Planning, in which I plucked some of the story items that I saw as most important and placed them on the Sprint Backlog list. During my modified Story Time, I had already, for the most part, broken these stories down into small enough pieces to be worked on as tasks. This was the simplest way to handle breaking down the requirements, and is allowable because I’m the only one that is working on these tasks.

Once I felt that I had taken enough stories from the backlog to keep me busy for a week, I began work. This involved adding content in the form of text and images to existing blank pages on the skeleton website, as well as creating new pages as needed. Some of the story items involved formatting things like the footer and sidebar to achieve the desired effect. Throughout development, various questions arose.

Each time that I encountered something that I needed clarification on, I added a comment to the Trello card. For this reason (and many others), I really like using Trello cards to represent user stories and tasks. Using Trello also allowed me to attach images, checklists, tags, and mentions directed at specific users. I like the idea of keeping all of the relevant information about a specific user story in a single place rather than scattering it across email, in-person meetings, and Trello. I’ve been attempting to document any information passed through other communication channels into Trello so as to have a complete log of interactions.

I’m looking forward to getting into some more specific development on the site. Next week’s post will include a review and retrospective for this sprint.

 

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Turning Dummy Links Into Real Links

Often, when I’m designing a website, I will sketch out a diagram of what I think the relationships between different pages will be. Here’s an example of one of my early sketches:

Even if the finished product is vastly different from the original diagram, sketching out some of the pages and their relation to one another helps me to get a better idea of the overall layout of the website. Skipping this step has, in the past, led to a jumbled mess of pages with no real organization. It is much easier to change a few pages’ organization when problems arise rather than having to redesign the entire website from scratch. The design step is also great for determining parent-child relations. In the above diagram, for example, every page is a child of the HOME page, and all of the child pages link back to HOME. The first generation of children are the WHAT IS HOSA?, CONFERENCES, CHAPTERS, as well as the three callout pages HEALTHCARE PROS, STUDENTS, and TEACHERS. Under each of these pages exist multiple other pages or sections all related under a common theme. Some of these pages link to related pages that exist elsewhere, such as the Find a Chapter link under both CHAPTERS and STUDENTS.

The overall goal here is to make the site as easy to navigate as possible. When I have a basic skeleton of the site set up, I will often ask someone unfamiliar with the organization to attempt to perform a particular task. If I have done my job, they will be able to navigate the site without knowing more information than what I have given them in the description of the task. I watch closely as they move around the site, asking questions to clarify why the user makes certain choices. Things that seem obvious to me may be completely unexpected to a first time visitor to the site. This sort of testing allows me to make improvements to the flow and organization of the site.

 

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.