“The two most important days in your life are the day you are born and the day you find out why.”
― Mark Twain
A quote from Mark Twain.
“The two most important days in your life are the day you are born and the day you find out why.”
― Mark Twain
This week, I will be writing a reflection on the “Nurture Your Passion” pattern. This pattern addresses developers who feel that their work environment is stifling their passion for the craft. I don’t have any personal experience with this problem, but I wanted to reflect on this pattern because I found the advice about how to nurture your passion to be quite useful.
The first bit of advice, provided by Oshineye and Hoover, is to work on things that you like and spend time building Breakable Toys, which I reflected on in the previous post of this series. The second bit of advice they provide is to seek out kindred spirits, or, other people who are also passionate about software development. They recommend seeking out a group that focuses on something you want to learn about, and keeping a blog about things that interest you in the field of software development. The third bit of advice they provide is to immerse yourself in the literature of software development. This tip, in particular, felt relevant and useful to me because I have begun seeking out literature that can help me acquire knowledge and skills that will improve my employability. Oshineye and Hoover make the point that studying the classes and becoming immersed in relevant literature can help reignite your passion for the craft. I still feel very passionate about software development, but I will heed this advice and refer to it in the future if I ever find myself in a rough place. The next piece of advice they provide is to draw your own map, which means to seek out organizations that will offer career paths that you have a passion for. Their final piece of advice is to not be discouraged by demoralizing tasks and coworkers, and to set clear boundaries that define the kind of environment you are willing to work in.
I think that I have been doing a good job of nurturing my passion, so it is a positive reinforcement to find patterns like this one, in the book. I am still passionate about software craftsmanship, and I don’t see it diminishing anytime in the near future. This pattern has further strengthened my foundation and provided me with advice that I will continue to carry with me, as a developer.
Our first sprint was an introductory one where our team officially organized on GitHub and Slack, created local working copies of Ampath’s application, and began looking at Angular resources.
Our team worked well throughout this sprint, despite not having all members present for 1/2 of our in-person meetings. The required tasks included in this sprint’s back-log were fairly easy to complete, but I did run in to some trouble during the installation of the application’s dependencies. I was absent for the first meeting following our sprint-planning-meeting, but all of my teammates were extremely helpful in getting my application compiled and running at the following meeting; they each gave me a different piece of advice and the combination of those pieces of advice was instrumental in the completion of this task. I also received some help from Shane R. who is on one of the other development teams.
We began the sprint by organizing on GitHub so that we could create a working copy of Ampath’s application that would be at our team’s disposal, that we could then clone into local working copies on our individual machines. We then organized on Slack so that we had a direct means of communication between the members of our team and with our professor. Finally, we organized on Trello so that we could set up product and sprint back-logs to keep track of what has been and needs to be done.
The next task we had to complete for the sprint was to install the application and its dependencies on each of our machines. Everybody had a little trouble at first but my troubles persisted right up until the last day of the sprint. After quite a bit of trial and error, I realized a couple mistakes I was making in the installation process. Apparently, the package-lock.json file in the application’s main directory was having some effect on the success of its compilation, so I had to delete it. The second mistake I made, was that I was doing all of the installation in Git Bash instead of WebStorm’s built-in terminal. I had attempted installing the application’s dependencies using Git Bash for the first 4 or 5 attempts and got the same compilation error at the end of each attempt. Finally, by using WebCharm’s built-in terminal to install the application’s dependencies, I was able to successfully compile the application and run it, thus completing all the tasks required of me on the sprint back-log.
My installation process summed up:
Clone application to PC
Delete the package-lock.json file
Open application in WebCharm
Using WebCharm’s terminal, follow directions to install dependencies and update software (found in README file)
Get Google Chrome extension for ability to log into the app (also mentioned in README file)
So, it was a fairly simple and straight-forward sprint, this time. I think the main piece of knowledge that I took away was, kind of, how developers are able to contribute to open-source applications using GitHub and, overall, how a development team organizes to contribute to such a project of this size and magnitude. I can now apply this knowledge if I am ever offered an opportunity to work on an open-source application that I am interested in, or if I ever want to form a development team that utilizes an Agile/DevOps style of development.
This semester, I am tasked with writing 10 blog posts, each being a reflection of a pattern defined in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye – this is the first of those blog posts.
This week, I will be writing a reflection on the “Breakable Toys” pattern. The use of this pattern arises in the situation where a developer feels like failure in the workplace is not an option, and desires a safe space in which he or she can make mistakes and not suffer terrible consequences as a result. Most people believe that failure is one of the best ways, if not the best way, to learn anything and so, if a person feels like they are in a situation where failure is not an option, it becomes harder for them to learn in that situation. The “Breakable Toys” pattern is the solution for developers in a similar situation to the one I have just described. A “breakable toy” is a personal project that is similar in toolset, but not in scope, to a system that you would typically see at work. The idea behind using a “breakable toy” is that it allows you to try your ideas and techniques, safely, even if they lead to a catastrophic failure. On this scale, the outcome of your attempts will only affect you, giving you the freedom to learn from your efforts without the fear of affecting others in the process.
The reason I chose this pattern to be the first subject of reflection in this series, is because it is a pattern that I already try to utilize in my own life. I am currently trying to land my first internship as a developer and a couple of the companies I have been in contact with have asked me to complete coding problems (as you would expect). I am a person who has a slight fear of failure – not enough to prevent me from trying to achieve things, but enough to give me a ton of anxiety in ‘make or break’ situations – so I began creating “breakable toys” to refresh my knowledge of data structures, algorithms, and fundamental programming concepts. These “breakable toys” were quite useful to me, and they helped me to solve the programming problems, posed by my potential employers, in the interview process. I also found a lot of enjoyment in creating “breakable toys” and solving coding challenges, so I have started to make more of an effort to make that a regular activity in my life. I believe I am starting to utilize another pattern covered in the book: “Practice, practice, practice”, which will likely be the subject of next week’s reflection.
Thanks for reading.
The subject of this blog post is the first chapter of “Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman” by David H. Hoover and Adewale Oshineye. I found this to be a phenomenal read and I am excited for what the book has to hold. I now officially consider myself an apprentice software developer; I feel that I possess many of the values that Hoover and Oshineye use to define good software craftsmanship, which has reinforced and revitalized my feelings toward my field and abilities.
I really appreciated that this first chapter was devoted to defining key terms and concepts that will appear throughout the book. I think these definitions will help me better grasp the concepts and and overall goal of the book, as I continue reading it. I did not really consider myself an apprentice, until I read the definition provided in the book. Marten Gustafson, an interviewee from the book, defines apprenticeship as being in the “state/process of evolving and looking or better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways”, which I believe is the state of mind that I am currently in.
Something that really resinated with me, from Hoover and Oshineye’s definition of an apprentice, was the part where they talked about the need to learn how you learn and grow effectively, and how this inward focus on yourself and your need to grow is the essence of being an apprentice. Up until now, I don’t think I was allowing myself the kind of inward focus they are describing – which is something I want to change. I now feel that I truly am an apprentice and, as such, I ought to be a little more focused on myself and my progression toward becoming the master developer that I hope to be.
I also really appreciate Hoover and Oshineye’s understanding that the readers of this book will come from all different kinds of situations and circumstances, and they often reiterate the fact that the purpose of the book is not to dictate the right courses of action but to shape your mindset to that of a good software craftsman – “Since most newcomers’ experiences do not resemble the ‘ideal’ apprenticeship, the modern concept of apprenticeship is mainly a frame of mind: you recognize that you are still at the beginning, even if you’ve been programming for several years, and you are prepared to take steps to create your apprenticeship out of the circumstances you are in”. I really connected with this because, I have been programming for years and have never considered myself a true apprentice – because I wasn’t.
I have realized that, even though I have a bit of experience, it does not by any means make me an apprentice or software craftsman. But, I am now prepared to take the necessary steps to create my apprenticeship, and work toward not only becoming a master developer but a master software craftsman. I am excited to continue learning from this book and I look forward to the journey ahead of me.
I found an article on SoftwareTestingHelp.com entitled “Web Testing: A Complete guide about testing web applications” and I thought it would be relevant to review and summarize it in a blog post. I have been working on my first true web application, recently, and realized that I may get to a point in its development where I want to conduct tests on it. During my search for resources on the subject, I found many articles that covered a good portion of web application testing, but this guide was the most comprehensive and helpful, in my opinion. Having read it, I feel that I will be able to conduct more inclusive and thorough tests of our application, if necessary.
This guide covers the 6 major web testing methods:
Testing links, forms, cookies, browser optimization, databases, etc.
Testing navigation, conent, user assistance, etc.
Testing the application server and database server interfaces.
Testing the web security of the application.
We have begun work on the web application for the final assignment, so I wanted to find out what design patterns and principles are most commonly used in the development of web applications. The result the came up the most, in my search, was the Inversion of Control (IoC) principle, a design principle used to increase the modularity and extensibility of programs, especially web applications that expect to experience growth. This principle is also useful in event-driven programs, which is how it relates to a project like ours While we don’t really need to consider the growth of our application in the context of our class, it could be potentially useful to follow the Inversion of Control principle as much of our application will be event-driven. I found it incredibly interesting to learn about the IoC principle and knowing how it works will surely benefit me in the development of other web applications in the future.
IoC is a design principle in which most of a program’s flow of control is received from a framework, rather than being directly implemented in the main parts of the program. In traditional programming, the code that expresses the purpose of the program calls into libaries to perform tasks, but with IoC, it is the framework that calls the task-specific code. This principle is given its name because adhering to it effectively inverts the control of the program from implementation to frameworks. Adhering to the IoC principle serves the purposes of decoupling execution of tasks from implementation, focusing a module on task it is designed for, freeing modules from assumptions, and preventing side effects when replacing a module. Software frameworks, schedulers, event loops, dependency injections, template methods, and callbacks all follow the IoC principle.
The IoC design pattern is, in my opinion, a difficult one to fully grasp. The most helpful explanation I found about the pattern was in a YouTube video uploaded by Christian Richards, entitled “Programming – What is… Inversion of Control”. In the video, Christian provides the example of a program that wishes to make a new user; when constructed, an integer variable is passed in, as a parameter, to the User class’s constructor and is used to dictate what kind of SQL Database Access Layer (DAL) will be initialized and stored in the new user.
The fact that the User class is responsible for a new DAL object to store within itself means that the User class is tightly coupled with the creation of new DAL objects.
In order to improve the modularity and extensibility of the program, Christian knows that he should adhere to the IoC principle, and decouple the creation of DAL objects from the User class. The User class should not contain code for deciding which kind of DAL should it should use; instead it should simply know how to work with DALs, and let the implementation dictate which DAL to use. This can be done by creating an interface to represent DAL objects (let’s call it ‘IDAL’), create concrete DAL objects for each different kind of DAL and implement IDAL in each one, modify the User class’s constructor to take objects of IDAL type, and then modify the main implementation of the program to create and pass in a concrete DAL object to the User constructor, upon construction. Now, the User class is simply responsible for dealing with the DAL object, rather than deciding which kind of DAL object to use and only then working with it.
Here are excerpts of Christian’s program, before and after adherence to the IoC principle:
static void Main(string args)
User user = new User(1);
public User(int IDALtype)
if(IDALtype == 1)
dal = new MySQLDAL();
dal = new SqlServerDAL();
static void Main(string args)
User user = new User(new MySQLDAL());
public User(IDAL IDALtype)
dal = IDALtype;
Continue reading “Post #15”
As a follow up to my previous post about our upcoming group-code-review, I thought I would review another article I found that compares group code reviews to peer code reviews. “Peer Review vs Group Review: Which Is Best For A Code Review?“, written by Stephen Ritchie, provides an answer to this question as it is often asked by clients in the field. Ritchie begins by stating that that both methods have advantages over the other, depending on the development team’s particular circumstance.
Ritchie defines a group code review as a code review in which a portion of the development team comes together to review code while the rest of the team provides feedback for improvement. He believes that group code reviews engage the individual developer, the team, and the team’s leaders in ways that evoke experience and judgment to find and fix problems. As I mentioned in the previous post, Ritchie also believes that effective group code reviews let tools perform fundamental review and let the focus of the developer review to be a spotlight on parts of the code that do not utilize the best practices and designs. Ritchie feels that discussing code, as a group, serves as an excellent transfer of knowledge from the more experienced to the less experienced. If a group code review is conducted properly, it opens up a healthy dialog between developers about the chosen conventions and why adherence to them is important. The main advantage of group code reviews is that it allows for a group of developers to learn and grow together, improving relationships and cultivating the transfer of knowledge and experience. The main disadvantage of group code reviews is that it can be challenging to get all group members up to the same working pace. Group code reviews can suffer if group members become diverted or distracted. This can potentially lead to a worsening of relationships among developers.
Ritchie defines a peer code review as a code review in which one developer’s code is reviewed by another developer. A pair of developers would meet and one developer would review the code of the other, and provide constructive feedback. Peer code reviews are similar to group code reviews but their personal nature generally ensures a thorough and properly done review. The main advantage of peer code reviews is that pairs of developers who conduct peer code reviews have likely collaborated and formed a bond in the past that allows for issues to be better-handled and addressed immediately. The is also somewhat of a disadvantage in that it necessitates that you have a decent relationship with the person you are reviewing with, if you wish to conduct the review effectively. A bad relationship between the reviewer and the developer being reviewed can result in a lack of collaboration and dialog and, inevitably, a poor review overall.
Ritchie believes that, for teams that have many developers with years of experience, it is more efficient to conduct peer code reviews. This is because the time of identification to resolution of an issue is much shorter, due to the personal relationship between peers. Ritchie prefers peer code reviews to group code reviews because they quickly improve the developers’ skills while simultaneously making progress in the implementation.
I agree that peer code reviews are more personal and allow for faster feedback and resolution to issues but I also appreciate the fact that group code reviews bring many resolution strategies and points of view to the table. For the small projects I have worked on, I have always found peer review to be more effective – but I think that, because larger projects generally require more developers, a group code review is necessary to get all the developers on the same page. I think that the code we are reviewing could be done by a pair of developers, but I am looking forward to seeing if the group review will provide better solutions and insight.