Category Archives: Computer Science

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.

Looking Back on Sprint 2

The second sprint was a bit more open ended, with far fewer discrete tasks to complete than during the first sprint. This meant that rather than working independently during class to complete individual environment set up tasks, we worked as a team during class to discuss the user stories contained in the Google Doc. I feel that once again the team worked well together and everyone contributed to achieving the goals for this sprint. There are a few places where I see room for improvement, and this was discussed during our in class retrospective meeting.

One of the first tasks that I personally completed this sprint was looking at the mockup tool, Balsamiq. While I was a little unsure about this at first, seeing some of the mockups that other teams did later on in the sprint helped me to better understand the tool. I think that for the next sprint, using Balsamiq as a team to visualize our ideas will be extremely helpful.

Although I had already completed the build ng2-amrs and connect your ng2-amrs to the server tasks, these tasks remained on the sprint backlog because not everyone on the team completed them during the first sprint. By the end of sprint 2, however, all members of the team had completed both of these tasks and they were moved to the completed board. This was important because these tasks are essential to beginning actual development, which will likely occur as early as the next sprint.

Another task that was left over after the first sprint was learning how tests work in Angular. Although we were told at the end of last sprint that this task was probably not essential, we decided as a team to include it in the second sprint because the majority of the team had already completed it. Members of the team who had already looked at resources on Angular testing shared their sources with those who had not yet completed the task.

The most significant tasks for this sprint had to do with generating design ideas from the user stories shared by the AMPATH team through the Google Doc. We met as a team during class time and began by reading the user stories together as a group. Although much of the team had already read the user stories independently before class, I feel that talking them out was helpful in providing clarification. Members of the team shared their individual understanding of different parts of the document, and asked questions where understanding was lacking.

After we felt we had a general understanding of the user stories, we looked as a team to the tasks that were listed further in the document. We then brainstormed ideas in a document for the first task on the list. This is the task that addresses offline login and offline data storage. We collaborated with the group directly behind us to share our thoughts and also get a better idea of how they were planning on going about development.

I think that we as a team are becoming more comfortable collaborating with one another, and also with sharing our ideas with among the other teams. I think that in future sprints we need to continue to attempt to clearly communicate our intentions with other teams so as not to do overlapping work. Although the effects of duplicated work were not very severe during this sprint, it could result in a lot of wasted effort in the future. I am looking forward to continuing to work with my team in the third sprint and using what we have learned to work effectively and efficiently.

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

Software Development as an Art

Hoover and Oshineye make some excellent points that I strongly agree with in the Craft Over Art design pattern in Apprenticeship Patterns. Although I had never thought about software development in terms of art, I found their discussion of art versus fine art to be interesting and well supported. While it is relatively simple to argue that software development is a craft, I would imagine that claiming that it is art would generate a bit more controversy. In my opinion, Hoover and Oshineye do an excellent job of supporting their claims that software development, by nature of being a craft, is also an art – but not a fine art. The distinction that they make between craft and fine art has to do with purpose. Because software development’s purpose is to make a useful product for customers, it can be seen as utilitarian in a sense. The purpose of producing fine art is purely for beauty.

The important caveat that Hoover and Oshineye introduce in the Craft Over Art pattern is that the craft of software development may produce something beautiful, but it must produce something useful. This may mean that craftsmen must choose utility over beauty when it is necessary. Considering the interests of the customer over personal interests and balancing conflicting demands is important in building and maintaining strong relationships with the customer.

This pattern applies in a couple of ways to my current undertakings. The importance of creating software that addresses real problems for real people is something that is somewhat new to me. Writing code for AMPATH Informatics is exciting because of the real-world significance that my contributions have. The other place where this pattern applies is in my independent study web development project for Massachusetts HOSA. While the customer-development relationship is a bit different in both of these cases, many of the same tips from the Craft Over Art pattern apply. While I may not be paid for my services, I still have expectations placed on me by the instructors and organizations involved in these projects. Understanding and carefully considering my responsibility to deliver a product that is first and foremost useful will help me to foster strong relationships with the collaborators on these projects.

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.

The One Thing All Newcomers Can Offer: Enthusiasm

The one thing that just about any recent college graduate has to offer a prospective employer is enthusiasm. While enthusiasm may help with getting in the door somewhere, once starting out on a new team of experienced developers the newcomer may be less willing to express that same enthusiasm. Although it may sound juvenile, the desire to fit in applies just as much in the workplace. This desire may prevent a newcomer from sharing valuable excitement and new perspectives with the team. Overcoming this fear of and sharing your excitement and creative ideas will be far more beneficial in increasing learning and value throughout your apprenticeship. In Apprenticeship Patterns, Hoover and Oshineye cover this topic under the Unleash Your Enthusiasm pattern.

If there is one thing that I am sure about, it is my desire to make a real difference through software development. I am passionate about making a difference and excited to begin this journey. I will admit, however, that I would be a bit hesitant to express this eagerness if other members of the team seemed to be skeptical of me. It would be far easier to take the conservative approach and try to match the excitement level of the team. Taking this approach is not the most effective strategy in these situations. It would be far more valuable to both the team and to the apprentice to fully embrace that enthusiasm and use it to inspire and motivate the team. Rather than viewing your excitement as an annoyance to the team, you should view it as an asset that will help the team.

When first starting out, it may be difficult to find ways to make any meaningful contributions to the team. You will need to earn the trust of the team before taking on risky tasks that may jeopardize the integrity of the work as a whole. One way to make contributions while also gaining the respect and trust of the team is to ask questions and unleash your enthusiasm. If you’ve found the right mentor, your enthusiasm for the craft of software development will be rewarded. This mentor will guide you, and you will give him or her a renewed excitement for the craft.

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

Whoops, I Picked the Wrong Theme

After spending many hours attempting to accomplish what I thought would be a relatively simple task, I decided to change the theme of the the Massachusetts HOSA website. Although my post last week went into detail about the many reasons that I originally chose to use the Trusted theme, there was one problem that became obvious to me as I attempted to adjust the size of the image slider the displayed on the homepage of the theme. While I expected these kinds of edits to be as simple as adjusting the size of a div container, it turned out that the theme used more complex embedded functions and jQuery to make the theme responsive. This responsive nature made it difficult to edit the size of the image slider and set it to a smaller, constant size.

It was around this time that I began to question whether or not it was worth my time to continue debugging and teaching myself how the Trusted theme set up the slider. I decided to instead look for a similar theme that may be easier to edit. I found the Consulting theme and found the slider to be much easier to edit. I was able to set the maximum width for the slider at 700px while still allowing dynamic resizing for responsiveness and support for mobile devices. Unfortunately, this nullified all of the changes that I had made to the Trusted CSS files that brought the site into compliance with the HOSA style guidelines. I did, however, discover a far more efficient way to edit the Consulting theme that I kicked myself for not thinking of earlier. First, I used Chrome’s Developer Tools to find the color code that I wanted to change. I then used the “Replace All” tool in TextMate to change all occurrences of the that color code with the desired color. Overall, the second time around for customizing the theme was far smoother and more efficient than the first.

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

Starting out by Sweeping the Floor

As I will soon be starting out in a new position at an unfamiliar company, I was more than happy to look to Apprenticeship Patterns for help in making the most of my apprenticeship. While the position may not be exactly what Hoover and Oshineye had in mind when they wrote the pattern, I found the Sweep the Floor pattern to be almost universally applicable to any entry-level position. When you are just starting out, you may not feel comfortable taking on some of the more complex tasks. You may be unsure of where you fit in as part of the team, and the team may be unsure of you. The Sweep the Floor pattern offers advice on how to contribute to and earn the team’s trust as well as growing professionally when you are just starting out as an apprentice.

I found the inclusion of the story from Paul Pagal to be comical and also informative. As mentioned, there are certain less glamorous tasks that simply need to get done in order for the team to be able to function. While they may not be glamorous, they provide an opportunity to make yourself useful and appear motivated. This most certainly will not go unnoticed, and should lead to progressively more interesting and complex tasks. As your skill level as well as comfort level increases, you will begin to take on riskier tasks.

Hoover and Oshineye follow the story by saying that having to do less glamorous work to get your foot in the door may be tough to swallow for some apprentices who feel they’ve already paid their dues. While I’m not trying to discount the value that I feel my formal education has, I’m not sure that I agree that this counts as paying your dues. Until you’re part of an actual team facing real-world problems, you haven’t paid your dues. This is part of the reason that I feel completely content starting off with more menial tasks. I am more than happy to begin proving my worth and showing my team that I am ready for bigger challenges by starting off with some of the less glamorous tasks. After all, somebody has to do it.

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

Looking Back on Sprint 1

The first sprint contained a lot of small tasks for setting up the environment and getting familiar with the ng2-amrs system. While some of these tasks were simple, others that originally seemed simple became difficult and took more time than the team and I originally expected. Overall, I feel that the team worked well together and that we were able to complete the bulk of the story items for this sprint. There were a few areas where I think we could improve for the next sprint, and these topics were discussed during our retrospective meeting in class.

One of the first tasks that was completed for the sprint was to Create a GitHub organization for your team. Dominique assigned herself to this task, and created the organization. She invited all of the other team members to the organization during a class work day and ensured that we were all able to access the organization.

Another task that was completed quickly due to its relative simplicity was the Choose a label color for your team. Matt assigned himself to this task and changed the label color on the appropriate card on the Class Scrum Board.

I assigned myself to the Fork ‘ng2-amrs’ from CS-Worcester-CS-448-SP-2018 to your organization task. I was able to complete this task only because Dominique had already created an organization for our team and gave me the necessary permissions.

The Read README.md and Read CONTRIBUTING.md tasks were relatively simple, and all members of the team completed these tasks early in the sprint.

The Decide how you want to manage your team’s GitHub repository was completed as a class rather than as a team, so little effort was required on the part of our team.

Everyone on the team was able to complete the Clone ng2-amrs to your computer task, as Dominique gave all of the members of the team access to the organization’s fork of the project.

Some of the tasks that gave the team a little more difficulty were the Learn how tests work for Angular, Build ng2-amrs on your computer, and Connect your ng2-amrs to the server. While the team members that had the project built and connected to the server attempted to help other team members get up and running, there were a few different and unique problems that gave people trouble in building and connecting ng2-amrs to the server.

Matt was able to fix one of the most severe of these problems, namely that of the ladda module complaining about missing files. Matt shared his solution with the team and the rest of the class, and was able to help many people in successfully building the project.

We were initially waiting on the Ampath Informatics team to provide us with a link to a server that we could connect to. When this link was provided midway through the sprint, we chose to add the task to our sprint backlog as some members of the team were ready to accept more tasks. For this reason, it was not a concern that the entire team was unable to complete this task.

The final task that was not completed by everyone in the team was to learn about tests in Angular. Once again, this task was not of critical concern because we likely won’t be using testing heavily early on in the development process.

I think that the team worked well together, and that members supported one another throughout the sprint. One thing that we may be able to improve upon is communicating when we are having difficulty so that others are able to offer assistance. Or, on the flip side, asking and offering assistance when another member of the team seems to be struggling. I am looking forward to working with my team and getting into some of the more technical parts of the Ampath project.

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

Constructing a Curriculum

After recently completing a difficult, humbling and valuable phone interview for a position that I thought I was well qualified for, I decided to make a renewed effort in educating myself outside of the classroom. The discussion helped me to realize the areas where my skill set was lacking, and where to focus my educational efforts. While some classes offer information of a specific, desirable topic, I often find that I cannot find the exact topic that I want to learn as part of a course. I perform a quick search on Amazon, which reveals multiple books on the topic, and I quickly order one according to user reviews and ratings. This is the process that has occured time and time again, leading to a bookshelf full of books on varying programming topics. For many of these books, I have only just begun reading (or I got halfway through and was distracted by something else), and never fully gained an understanding of the topic that I set out to learn.

For these reasons, I found the problem statement of the Reading List pattern in Hoover and Oshineye’s Apprenticeship Patterns to be especially applicable to my current situation. The problem statement says, “The number of books you need to read is increasing faster than you can read them.” While I am constantly increasing my understanding of certain topics, new and improved methods are constantly being developed. Keeping up with the rapid pace at which software development changes is difficult, but following the advice of Hoover and Oshineye will undoubtedly give me a leg up on the competition. I like that the Reading List that they propose is essentially a priority queue, with the books that are most important at the top of the list and the ones that may not be as important towards the bottom.

I also appreciated the advice that Hoover and Oshineye gave when they suggested looking at the books that are referenced in those that you do read. When you see a pattern of many books referencing one in particular, be sure to add that one to your reading list, as it may contain valuable information not covered in the material referencing it. Looking at references for which books to add to a reading list is also great advice if the style or organization of one book is not working for you and you are looking for the same or similar information to be presented differently.

It was reassuring to me to know that I was not alone in feeling overwhelmed by the amount of information that I need to attempt to gain an understanding of. The strategies in the Reading List pattern are sure to help me in organizing and creating a plan for learning new software development techniques and improving my skill set. Setting goals and prioritizing what I read will allow me to use books as a tool rather than simply being overwhelmed by what I don’t yet know.

 

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

Customizing a WordPress Theme

With literally thousands of themes in existence, there is sure to be a WordPress theme out there that fits the needs of you or your business. Why spend your own time designing a theme when some generous person has already done the work for you – and posted it  online for you to access completely free of charge? While some themes may no longer be updated or maintained, many receive regular security patches and feature enhancements to ensure your site is not at risk.

The main considerations when choosing a theme for the Massachusetts HOSA website were a banner image and feature area to mirror the appearance of Georgia’s HOSA website (http://georgiahosa.org/). The theme I found that most closely matched this desired appearance was the Trusted theme by uxl (https://wordpress.org/themes/trusted/). The theme was highly rated, installed and active on more than 5,000 WordPress installations, and recently updated to ensure compatibility and security.

No theme is perfect, however. The first changes I needed to make were to the color scheme of the theme. I’ve work with CSS before, but found that Google Chrome’s Developer Tools (https://developer.chrome.com/devtools) made it much easier to isolate a specific CSS attribute or tag rather than digging through the more than 5000 lines of code. I used the HOSA Style Guide to make sure that the colors and images that I was using in development matched the requirements of the organization. This was a new concept for me, but I found it extremely helpful that the organization published all of the approved brand colors, fonts, and logo requirements in a single resource.

The website is now up and running on a development server, and the theme has been modified to match the appearance of the HOSA brand. The next task that I will be working on is implementing a slider in place of the banner image on the homepage that displays conference information with links to register for a conference.

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