Author Archives: gmatthew

The Dangers of Complacency

In a field that continues to rapidly evolve, staying up to date with the latest and greatest tools and techniques is essential. Complacency is simply not an option if one wishes to remain competitive and relevant in the information technology field. Not surprisingly, however, there are certain tools that we become familiar over time, through repeated use and practice. There is nothing wrong with this, as familiarity with certain tools or techniques allows for more accurate estimations about work, and helps to limit risk. In Hoover and Oshineye’s Apprenticeship Patterns, they present a pattern that helps software apprentices deal with the complexities of complacency titled Familiar Tools.

In the Familiar Tools pattern, Hoover and Oshineye start out by acknowledging how valuable it is to have a set of tools that you feel comfortable using. Not only does this make you more valuable to employers, it makes the work easier and more valuable to the developer as well. From increased productivity to more accurate estimates, familiarity is important in the progression of a software craftsman.

Although the word is never explicitly mentioned, this pattern also seems to issue a warning about complacency. Hoover and Oshineye caution apprentices from becoming too set in a narrow range of familiarity, as that puts them at more risk for becoming irrelevant should the popularity or usefulness of those familiar tools fade.

This pattern was pretty easy for me to appreciate, as I already enjoy learning and improving through personal and professional development. Perhaps this desire to stay ahead of the curve is part of the reason that I became interested in the field to begin with. I have always enjoyed staying up to date with the latest and greatest gadgets, trying out beta builds, and experimenting with technology. Although the context is a bit different in the Familiar Tools pattern, the idea is very similar. The quote by Eric Hoffer that is included in this pattern also spoke to me, it is, “In a time of drastic change it is the learners who inherit the future. The learned usually find themselves equipped to love in a world that no longer exists.”

When entering the computer science program three years ago, it was repeated time and time again that the material that I would learn in college will likely be outdated by the time I am entering the workforce. While this is simply a fact of the computer science field, I feel that I am doing well at keeping myself informed and appreciate the efforts by my educators in keeping my education relevant and valuable in a rapidly changing world.

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.

The Beginnings of my Map

I’m typically not much of a long-term planner. While I have defined some goals and aspirations, they sometimes seem more like rambling dreams than achievable objectives. Although I may know what I want, defining actionable items for getting there is a different and far more challenging accomplishment. I like to make the most of every day, doing the best that I can and hoping that hard work and positivity will take me somewhere amazing, wherever that may be.

Much like the story told by Desi in the Draw Your Own Map pattern in Hoover and Oshineye’s Apprenticeship Patterns, I have begun my Information Technology career in a sort of hybrid role in Systems/Application Administration. The differences between my experiences so far, thankfully, have been far different from those described by Desi. Rather than facing pressure to concentrate only on furthering the interests of others, I am encouraged to create a valuable experience for myself.

While I am well aware that it is not the responsibility of anyone else, employer, professor, or colleague, to give me a hand out, I am extremely grateful for all of the support that I have received in that regard. I feel as though I have a good sense of my career position  and potential options for the future because of the support that I’ve received and the experiences that I’ve had.

Although I see absolutely no need to consider other paths at this time, the Draw Your Own Map and the stories shared by Desi and Chris were somewhat reassuring. It is comforting to know that even if there comes a time when it may feel like it, you are never really stuck. I feel extremely grateful to currently be in a position where my goals and desires for professional advancement are not only heard and considered, but seem to be top priorities. I am in a supportive, flexible environment, where I’m encouraged to set and work to achieve goals for personal and professional growth, development, and learning. Right now, the possibilities and prospects seem to be wide open. The next step for me is to use this opportunity to discover the values that are important to me.

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 3

During the third sprint, we began digging into the code of the ng2-amrs application and really started to attempt to gain an understanding of the existing implementation. There were quite a few hurdles throughout this sprint, including the cancellation of both the second in-class work day and the in-class review and retrospective day. This made communicating ideas between team members significantly more difficult, and I think this has also impacted our performance for this sprint. I still believe that we are working well as a team, and doing the best that we can given the circumstances. Standup participation was 100% for this sprint, which (I believe) is a first for the team.

For sprint planning this time around, we chose the “Offline Login Service” story from the product backlog, as this most closely aligned with what we had begun researching during the second sprint. We broke this story up into tasks, some of which were assigned to everyone on the team, and some of which were assigned to individual members.

One of these tasks, assigned to Dominique, was the “Collaborate with ‘Field Idiots’ to determine how to decrypt and encrypt user data/passwords” task. I am interested in learning more about what Dominique discovered about the encryption implementation that the Field Idiots team will be using, but am unsure if she was able to do much collaboration because of the cancellations.

The “Collaborate with ‘Everyone Else’ about API for retrieving offline data/user information” task was assigned to Luigi and Matt. Once again, I am unsure whether or not they were able to achieve much collaboration due to the cancellations. This collaboration is critical to our progress moving forward, as we must be aware of the requests that we should be sending to the local storage databases in order to implement an offline login.

The “Investigate session management” task was assigned to myself. The main discovery that I made while investigating how the ng2-amrs application handles sessions is that we may not need to change much about the session itself. If the existing code for session management can be modified for usage offline, this would be a far more effective solution than rewriting an entire session manager ourselves.

The remaining tasks were assigned to all of the team members, and were more for big-picture existing implementation understanding and design strategy. The first task was to “Investigate current logon process,” something that we started as a group on the first in-class work day. While we made some progress, I was hoping to use the second in-class work day to share what I had discovered independently and also hear what others had discovered.

The design-strategy task that we created based on the advice of Dr. Wurst was to “Look into ‘Bridge’ design pattern”. I remember looking at the pattern briefly last semester, but needed to refresh myself. I found some online resources that seemed to give a good overview of the pattern and shared them with the rest of the team in our Slack channel.

The final task shared by all team members was the “Create overall architecture/design of offline login feature using Balsamiq.” This task was started during our first in-class work day by Matthew. The design that he created gives a good high-level picture of what our service should accomplish. While I was hoping to discuss possible additions to our design with the rest of the team, this was impacted by the cancellation of class last Thursday.

While there were certainly some hurdles to overcome during the third sprint, I think that we did a good job of making the best of the situation. We communicated more through Slack during this sprint than in previous sprints, and the quality of information that was shared during the standups has improved significantly. Overall, I am happy with our progress and looking forward to getting more in-person collaboration time in the near future.

 

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.

Money Shouldn’t be the (Only) Motivator

While money is certainly important, and should be a consideration – it should never be the primary motivator for choosing a particular career or even for choosing particular projects or roles in a position. Making decisions based on financial considerations alone is a quick way to end up hating what you do and having little opportunity to improve your situation. Making the correct choices about what you use at motivating factors to drive decision-making can help make software craftsmanship a more rewarding and valuable career. Following some of the advice given by Hoover and Oshineye in Apprenticeship Patterns should allow a new or aspiring software craftsman to identify the motivating factors that drive success in the position and lead to a satisfying career.

It is easy to stay motivated when things are going your way and you are working on projects that you find engaging, fun, and adequately challenging without being overly difficult. The problem that the Sustainable Motivations pattern is hoping to address, rather, is when things get a bit more difficult. Sometimes it becomes difficult to see the passion in software craftsmanship. For example, sometimes in the course of developing the necessary technical skills to become a master craftsman, the aspiring develop will be faced with hurdles such as ambiguously specified projects, or shifting and conflicting demands of customers. It’s times like these, argue Hoover and Oshineye, where the motivation and determination of the aspiring craftsman are truly tested.

While I feel lucky to be actively interested and continuously challenged by my current work, I am sure that my luck will run out at some time in the future. I will be presented with a project that I find tedious, frustrating, and maybe even exhausting. I am confident in my ability to remain focused and motivated on working towards the end goal of becoming a craftsman, however. I feel that as Hoover and Oshineye mention, if I ever begin to have doubts they will easily be overcome by a need to continue earning money or the desire to maintain a reputation as a technologist. These motivators should keep me in the craft until my situation improves and passion returns as my primary motivating factor.

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.

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.