Author Archives: Mike Morley (mpekim)

One More Sprint (CS-448 Sprint Retrospective Blog 3)

INTRODUCTION: As the final Sprint of my team’s Software Development Capstone project introduces its conclusion, I feel as though it is a good time to reflect on the results of this sprint. Going further, some aspects of this blog (specifically the conclusion) will involve reflection of the project in its entirety. To start, I believe that this sprint may have been weaker than previous ones. Factors supporting this argument include the idea that we now have experience from the previous sprints and that we should be more prepared; factors against the argument include non-work related considerations (such as future semester set-up).

POSITIVE FACTORS: During the final sprint, these favorable events had occurred:

  • Our team had made progress on getting Keycloak into a Docker container. Hopefully, futures semesters will be able to complete the project for us (allowing connection to the AWS Team, and other teams in general).
  • Speaking of progress, our Product Owner (our Instructor/Professor) has mentioned that the team has made an impressive amount of progress in general. Factors involved with the amount of progress include comparisons to previous semesters’ work, and consideration of the fact that our team had quite literally started this project from scratch.

NEGATIVE FACTORS: As much as the team has improved, there were still some bumps in the project’s road. These bumps include:

  • To contrast the statement in the “Positive Factors” section, work on the Keycloak Docker container has been completed, but we do not have a final product yet. However, in our defense: part of this sprint was spent setting up the project for the teams that will work on it in the future.
  • As mentioned in the “Self-Improvement Suggestions” section below, this team has done quite well during this sprint (considering the fact that the Scrum Master was not as involved as previous sprints). I understand that Scrum Masters do not have a drastic amount of authority over the rest of the team; at the same time, too little involvement with the team’s work essentially makes them a facilitator “in name only”.

TEAM IMPROVEMENT SUGGESTIONS: Even though we have no more sprints left for the project, it is still a valuable form of criticism to discuss where the team can improve. Factors involve:

  • I believe that additional dedication to Sprint Planning would be beneficial for the team. While our first two sprints involved research of our issues (in other words, we didn’t know what we needed to do), having a clear idea of the end goal will make for more efficient work. This is opposed to issues being brainstormed and abandoned like darts thrown at a board.
  • In addition to Sprint Planning, having a better structure for our Sprint Review/Demo classes can help. While we get our work done, it’s also important to know how to present it in a neat, organized manner that is easy for the Product Owner to interpret.

SELF-IMPROVEMENT SUGGESTIONS: In addition to team improvement, there is always room for self-improvement. Some ideas for my own improvement are:

  • Since I was the Scrum Master for this sprint, I must say that I was not as involved with the role as I would have liked to have been. In future projects, I would like to dedicate more time to the role; hopefully, outside commitments won’t weigh me down like they did during this semester.
  • In future Scrum work, I would also like to be more involved with Gitlab issue board work (this factor ties into my criticism of my Scrum Master performance). I feel as though reviewing and commenting on issues isn’t enough; taking the initiative and creating issues is a key factor of being a leader on the team.

Considering the project (and its semester) as a whole, I will say that I appreciate my teammates and the work that they have done. We have all made this Capstone project a pleasure to be involved with; in fact, due to how pleasant the overall experience was, I have shown interest in working with the LibreFoodPantry software outside of the class. To be honest, there’s no reason not to be involved – working with LFP has varying levels of commitment. Regardless of the commitment level, the work is a great way of acquiring work experience and keeping Software Development skills fresh.


From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Just Gotta Keep Sprinting… (Sprint Retrospective Blog 2)

INTRODUCTION: Compared to the first sprint, “Sprint 2” has gone better in some ways. However, in other ways. we definitely have dropped in performance a bit. It’s no one’s fault; part of working within these sprints is figuring out what needs to get done now, and what can be done later.
POSTIVE FACTORS: Here are the following improvements since the last sprint…

  • We have set up a form of “login” based on Keycloak software. This Keycloak login has also been set up via JavaScript to act as a “re-direct” from the barebones frontend that we had created during the first sprint. I often refer to this “connected demo” as a HTML/Keycloak/VUE App or project. This is because that’s exactly what happens with the current demo: a user will start in the HTML index file, and then click on a button that redirects to a Keycloak login. Once credentials are entered, the Keycloak login will take the user to the VUE App.
  • The group has figured out how to work with Keycloak – in particular, we understand how to create users, set up privileges for users, and group them within a “realm”. We also understand the hashing algorithms used to make JWT Tokens, alongside the structure of a token when de-coded.

NEGATIVE FACTORS: The following factors, as of this sprint, should be worked on…

  • The group has reached out to other groups, as well as LibreFoodPantry staff. Still, I feel as though communication is key; the more communication that our group can make with other staff, the better.
  • Our team’s organization of the Sprint board could have been better. Specifically, I feel as though moving issues to the “Needs Review” section as they are completed would be preferable to moving them all at once.

TEAM IMPROVEMENT SUGGESTIONS: Here are some ways that the team can improve for the third, final sprint…

  • I have made the suggestion that the team could benefit from “POGIL-Style” roles, where each team member performs a specific task for the group. As emphasized throughout this blog, the role that comes to mind is “communications”; while not very “programming-heavy”, this role involves reaching out to other teams and staff. This keeps everyone “in the loop” so that they can plan their sprint work accordingly for the eventual project integration.
  • Similar to my discussion within the self-improvement section below, I feel as though the group can benefit from work that is focused towards issue/epic progression. While we are making progress, it seems as though we have to scramble to figure out exactly what is done during our sprint review.

SELF-IMPROVEMENT SUGGESTIONS: As for myself, here are some factors that I need to work on for the future…

  • I need to dedicate more time to this project. I have made this issue clear in the last retrospective blog, but failed to work on it. This project, and this class, are extremely important for my professional reputation. Having “outside factors” as a reason for why work isn’t done can only be justified for so long. Eventually, one side has to give: either the outside factors, or the project.
  • I feel as though “issue-focused” work would be better for long-term progress. While it’s great that I seem to be making progress with Keycloak, my work is scattered. This issue reflects itself in the progress made on the gitlab issue board.

When creating this blog, I took a quick look back at my first Sprint Retrospective blog; I wanted to make comparisons on mistakes that have been amended during the first sprint. Unfortunately, having this blog posted on time is not one of those amended mistakes. Looking on the brighter side, I feel as though focusing on these blogs is not as important as I make it out to be (this was a mistake that I made during Software Architecture).


From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

CS-448 AP Blog 9 (Read Constantly) – Reading Faster Prevents Coding Disaster

When you have read deep enough into “Apprenticeship Patterns” as much as I have, you start to notice a key feature of the book: many of the practices found within it are pre-requisites or co-requisites to other practices. Similar to a tech-tree structure found in a video game, proper software programming practices go hand-in-hand – this allows one to become proficient in many skills at once.

As usual, I have found that “Reading Constantly” is actually a practice that I already engage in. However, in contrast to the book, my level of “daily reading” is much smaller; I read for about 5-10 minutes each day, and it may not necessarily be related to the programming practices I need to study on. However, the book does state that reading during down time (even standing in line) is beneficial – perhaps, in an attempt to disagree, I was corrected by my own reading. This reinforces the idea: read, read, read!

I agree with Apprenticeship Patterns, and must also state that you should have a “queue” of books lined up; as you finish one, immediately start another. Tying in with “Practice, Practice, Practice”, constantly reading will keep you well-informed and up-to-date on problems that are relevant in today’s programming era.

When it comes to professional applications, “Reading Constantly” does not simply involve reading to obtain more knowledge. It also consists of:

  • Reading to acquire new connections within the academic community
  • Reading to apply skills from previous experiences
  • Reading to non-verbally communicate the idea that we are willing to improve ourselves

So, by taking some time to read every day, I am essentially performing both a “working” and “recreational” activity. I am able to boost my workplace performance in an enjoyable manner. Similar to the ideas found in the coding dojo, reading should come at ease, with information effortlessly flowing in like a gentle stream. Forcing yourself to learn new information is both un-enjoyable and ineffective.

Overall, I think that everyone and anyone who is considering an advancement in their career to read constantly. In a way, it makes us similar to our machines – we take in new input, compute it within our brains, and create solutions as output for our audiences. It’s a beautiful cycle, and it all starts with a good book.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

If At First You Don’t Succeed… Sprint, Sprint Again! (Sprint 1 Retrospective)

INTRODUCTION: Looking back on this sprint, I can say that our group has performed quite well. better than expected, honestly. Perhaps I have an irrational fear of “events always going haywire”, but at least this phobia keeps me well aware of the situation (“on my toes”, you might say).

Considering the activity found on our group’s gitlab project, we can see that this sprint has consisted mainly of research write-ups, alongside some minor work for the frontend, backend and API of the IAMS.

POSITIVE FACTORS: Here are some factors of the sprint that I believe went well:

  • Our group had satisfactory distribution of work.
  • The group was able to present a “proof of concept” demo that met specifications for the current sprint. Examples include a basic frontend/backend/API system.
  • A lot of research was done during this sprint; our group was able to learn a bit about Kubernetes, VUE, Node.js and other software that is crucial for the IAMS.
  • Keycloak has not been set up, but a plan has been made to get it running by the end of the second sprint.

NEGATIVE FACTORS: Here are some factors that I believe can be worked upon:

  • The group seemed to struggle with suggestion a proper amount of weight for each issue. Specifically, we seemed to “underestimate” the difficulty of certain issues (such as setting up a Kubernetes distribution). In short, the group often weighted issues as easier than they actually were.
  • I feel as though having “more concentrated roles” within the team would be beneficial. While we had two teams (coding and research) led by a scrum master, I feel as though we can have “individual” roles. Applying roles such as “Quality Assurance”, “Presentation Director” and “Merge Coordinator” would help make a better team.

TEAM IMRPOVEMENT SUGGESTIONS: In order for the team to improve, some suggestions that I would improvise include:

  • More communication. While our group had used discord and gitlab to an impressive extent, I feel as though there can always be improvement. Additional communication can give us a better idea of our current position in the project, as well as create solutions for the next steps forward.
  • Enforcing the “Scrum Structure” more properly. This is an extension of the previous criticism (“More Communication”). In addition to standup meetings, the group should be engaging in a “Daily Scrum” meeting every day, (regardless of class)

SOLO IMPROVEMENT SUGGESTIONS: Personally, I feel as though my team worked spectacularly. If anything, I believe that I was the worst one on my team (following the Apprenticeship Pattern: “Be the Worst”). In order to improve upon my own performance, I believe that I should look at the following shortcomings:

  • Dedicate more time to the work. Unfortunately, while I am busy with other factors (such as work, other classes, and so on), this is not an excuse. This project is meant to be treated as though it is a paid job; the performance delivered should reflect a similar quality.
  • I would also like to reach out to LibreFoodPantry staff, as well as other groups, more often. Communication and cooperation are key factors to creating this massive project; each group creates their “piece of the puzzle”, and then it will all be fit together towards the end.
  • Finally, having a greater understanding of my role (such as “Coder”, “Quality Assurance”, and so on) would be crucial to future work. As of this sprint, I seemed to dabble on various topics without concentrating on anything in particular; this can lead to messy, unfinished work.

Most importantly, I would like to point out that this retrospective blog was posted late (it was meant to be done before the start of Sprint 2). This, in itself, is an error that needs to be rectified in future sprints – timeliness and containing work within the sprints is essential in order to keep the project from falling apart. It’s okay if work carries over to another sprint, but that usually needs to be planned from the get-go.

All in all, the first sprint never goes perfect. No matter how hard one tries to make it go right, something always goes wrong. The point of this lesson (and by extension, this class) is to ensure that we look back on these errors; we then perform research on them so we can modify our work habits. All of this is done to ensure that the mistakes don’t occur again in future sprints. As I look forward, I will do my best to enforce these new policies.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

A Constant State of “Update”(ing): Using Apprenticeship Patterns to Become a Master Programmer

“Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” has been considered to be an acclaimed read by many of my fellow students. After giving the book a try, I can also see why it is such a big hit. In essence, this book speaks to programmers on a “relatable, spiritual” level on how to turn their passion for software development into a lifelong process of constant improvement.

To be honest, the most interesting part of the reading for me was found in Chapter 4: Accurate Self-Assessment. This is because it is instrumental to my learning style that I am “the worst of a group”, or that I am always in a zone that I need to focus on improvement. Throughout my college career, I have been the type of person to rant and rave about how “I’d rather get a ‘C’ and master two programming languages, than receive an ‘A’ and still show evidence of struggling with one.”

Considering my own views on how I work with software, I feel as though this book has been mainly a “rehash”, or a reinforcement of my beliefs. This is due to several factors, including the “Be the Worst” philosophy as mentioned in “Accurate Self-Assessment”; this can also be seen in “Chapter Two: Emptying the Cup”, where they state the importance of becoming extremely proficient with your first programming language.

Unfortunately, as amazing as this book is, I cannot say that I agree with every last line of its code. One spot where a “warning of disagreement” occurs is when “Chapter 6: Construct Your Curriculum” does just that – it tells me how to create my own study plan (outside of college classrooms and office hours). Perhaps this makes me contradict myself with my own “unorthodox schedule”, but I learn best when I don’t feel like it’s forced. Instead, my most efficient learning is recreational; it seems as though material sticks with me the best when I ingest it in the same way that one would ingest a juicy diary or a football roster.

For me, I found the chapter “Walking the Long Road” to be the most useful for continuing my career as a software engineer. This is due to the fact that it acts as a reason for using the philosophies found in “Accurate Self-Assessment”. By this, I mean that people (including myself) need to understand that becoming a master craftsman, and especially a master programmer, does not “just happen” overnight. it takes years upon years of grinding, of constantly “being wrong” and being challenged to find alternative solutions to problems.

Overall, “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” has been a fun, yet informative read. As mentioned before, I agree with most of the book; even in times of disagreement, I can see where the authors are coming from. I am looking forward to the applications of this book in my career as an aspiring software developer.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

One Step Backward, Two Steps Forward

“You have to spend money to make money.” – Peter Griffin (Family Guy)

This quote is probably one of the most familiar antitheses to the idea of “one step forward and two steps back”. Alongside this week’s reading of “Apprenticeship Patterns”, we are going to figure out how retreating into our competent “safe zones” can actually be a beneficial way to make progress into unknown territory.

In essence, the pattern describes about finding an “acceptable limit” of disregarding challenges in order to polish up on familiar material. By finding patterns in previous progress, we can empower ourselves to embrace the challenges of the unknown. It is important to note that the “limit” is respected – going too far ahead into the unknown leads to a lack of progress from ignorance. Retreating too far into the safe zone causes another lack – from fear.

I understand that taking some time to work on an easy, familiar project is a great way to create a productive sabbatical. To be honest, I have been practicing this pattern long before reading up on it; making familiar homework assignments and simple games has been a hobby of mine. Plus, once skills are learned with a “back of our hand” level of proficiency, it makes the mind bored with these tasks – it craves something more novel, no matter how challenging.

“Retreating Into Competence” stresses that we must make the regression quickly turn into progression, otherwise we may end up in a rut. While I don’t necessarily disagree, I wonder if there is a way to “charge the catapult” for an even greater forward effect. Exactly how far can we pull back on our efforts towards familiarity in order to shoot ourselves among the star s of the unknown? Is minimizing our refreshment emphasized because the “catapult method” has a short charge limit? My interest for these questions makes me want to experiment with the pattern (this would be best done in conjunction with some Breakable Toys).

In order to use this pattern professionally, I need to start thinking about time. Every moment of the past that I can regress to, was at one point “an unknown future destination”. Figuring out the methods on reaching these past points can lead to notes for successful exploration of a project’s future. Analyzation of the past should be done as scientifically as possible; getting wrapped up in the nostalgia of success or wallowing in the failure will cause us to miss the future that lays ahead.

Fun fact: this pattern itself is a “regression”; I am doing it by using a token to go back to Week-4.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

People have always asked me: “why are you so smart?”. Well, the truth is: my intelligence and my memory are a result of the same process that leads to world-famous athletes – we practice, practice, practice. I study academically during my semesters, and I study recreationally during my vacations; a true thirst for knowledge always welcomes a refill to the chalice.

This constant flow of acquiring knowledge comes with a cost though; more often than not, I have been incorrect over and over again. However, such is life within the field of science – experimentation is the process of challenging what we know to falsehood, and seeing if its truth still holds.

Connecting this ramble to Apprenticeship Patterns, I am pleased to tell you that the pattern for this week is “Practice, Practice, Practice”. The product within is just how it’s advertised; this pattern emphasizes that beginners learn best through “doing”, by performing actions under the guidance of professionals.

I find it interesting that the idea of “practice making perfect” is challenged; the new idea becomes “practice makes permanent”. Upon further analysis, I do have to say that I agree with this confrontation of the old adage – learning techniques improperly can lead to code smells. Proper, constant feedback while learning will prevent the coding landfill from becoming overwhelmed.

Personally, I would have to slightly disagree with the idea that apprentices must rely on their own resources to practice. I understand that this self-reliance can develop an independent learning process for the apprentice; however, a true leader reduces their aid for an adept apprentice (instead of completely removing it). Sure, beginners need more attention, but lifelong guidance builds relationships and motivates crafters; it’s easier to experiment when you feel tethered to a base.

While I have always stuck to the idea of constant practice, I will consider the idea of getting more constant feedback for my future professional habits. Personally, I have always had a fear of being judged for my shortcomings (and have only confronted this fear recently). In order to become the best of the best, we must practice our katas, within a dojo of coding professionals. As seen with other patterns in the book, we must assume that we are the worst (in a positive way), and confront our ignorance. Through practice, practice, practice with breakable toys, we achieve the proficiency that we strive for.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

‘C’ is For Coding; That’s Good Enough For Me

If you haven’t noticed already, there seems to be a trend of various coding practices that I tend to agree with. This is not merely a case of “kissing up” to the professionals, but rather it is the fact that I know I have been taught from the ground up by well-respected individuals. Many of the practice patterns found in “Apprenticeship Patterns” are ones that I have already been aware of, or still agree with despite their novelty. An additional agreement to add to this repertoire is the importance of “Your First Language”.

For me, this “first language” was C. To be honest, I don’t feel like there is a better option to select. C is an excellent, “mid-level” language that follows many of the practices found within my studies. For example, in “Apprenticeship Practices”, the book warns of becoming stuck within your “native tongue”; I feel as though this is negated (or at least parried) by many of the practices in C. C works closely with hardware, and involves skills found in assembly language, but can also be used to emulate higher level languages such as Java.

When it comes to my professional career, “my first language” is a philosophy that has given me a greater appreciation for the diverse landscape of large-scale projects. The C language has elements similar to Python, such as arrays. While data structures are not an impressive connection (they can be implemented among pretty much any language), it does make crossing the gap easier. Once at Python, I can learn about dictionaries, “key: value” pairs that can have an ideological equivalent found in .yaml files and JSON, and so on.

Interestingly enough, despite the emphasis on programming diversity, the pattern stresses finding a first language and staying strictly to its community. I feel mixed emotions about this philosophy: on one hand, it sounds as though “bridging gaps” found between languages should be avoided. On the other hand, constant practice is the best way to learn a first language, and that practice can be boosted by feedback from a desired community around that language.

Overall, I have an appreciation for the idea that beginner programmers should stick to one language when starting out. However, if I were to make a suggestion for that first language, I would suggest C. While challenging to learn, its connections to other languages and diverse applications can make powerful programmers.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Code, Run, Break, Repeat.

Upon reading the first line of “Breakable Toys”, I knew I was in for a pattern that I could connect to. Often, my behavior can be related to a “bull in a china shop”; while not outwardly malicious, my clumsy nature with unfamiliar material can often lead to mishaps and damages.

This is where the breakable toys come into play. According to “Apprenticeship Patterns”, journey-programmers can benefit from making similar programs to the ones that they work with in their profession. These “dummy programs” can then be played with to one’s content, allowing for all sorts of experimentation without worries of destroying the actual project.

To me, I found it useful that the pattern recommends “creating a familiar game like tic-tac-toe in many different languages”. It reminds me of my earlier projects where, as stated in a previous blog, I would practice new languages with familiar tactics. I find it to be a valuable way of connecting “Breakable Toys” to other patterns (such as “Your First Language”).

Most importantly, I believe that “Breakable Toys” is one of the most instrumental patterns to my professional future. Science is not a field involving constant “correct-ness”; science instead does quite the opposite, and computer science is a subset of the broad field. With breakable toys, we are constantly trying to find wrong answers, to push boundaries and discover what can and cannot be done with languages, data structures, APIs and the like.

Perhaps I need to read the section again to fully understand it, but I am at a bit of a loss for the example action being “to create a wiki”. As stated above, I think that better examples for breakable toys would involve familiar projects/programs in new languages, or using different algorithms/data structures. The wiki can be a good start as a “portfolio” to hold all these projects, but on its own I don’t feel as though a wiki is allowing much time out of the comfort zone.

Personally, I feel as though “breakable toys” is an easy concept to understand, but is also a bit more difficult to apply in practice. As I question the pattern’s “classic examples” (like the Wiki), I push forward as the pattern implies as its intention. However, as I leave this comfort zone, I wonder if I stray too far, over my head of expertise (even for a “failure-safe” experience)…

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

No Stranger To Shame

I think it’s a fair statement to say that anyone who has ever seen me fail, knows that I have often failed spectacularly. Failures of mine come with embarrassment, enigmatic errors and explosions as far as the eye can see. Long story short: I’m no stranger to shame.

Due to my experience with failure (and my tolerance towards the ensuing embarrassment), I often fail without thought or fear. This is an essential personality for learning exactly how I fail, and how to improve upon this type of failure. Reading Apprenticeship Patterns’ reflection on the topic has also helped me come to terms with “failure analysis”.

According to the book, everyone has experienced failure at some point; people that haven’t either never left their comfort zone, or are denying a past failure. It also dabbles on selecting which failures are worth improving upon to salvage sub-par skills. Finally, it admits that some skills may have to be left to rot, as an example of embracing our non-perfect nature.

I agree with the idea that no one is perfect; extending on the topic, I also agree that “ditching” some forms of failure are necessary to becoming a specialized worker. As the old saying goes: “a jack of all trades is a master of none”; I admit myself that trying to work on various topics only results in a mess of files, each one being less impressive than a single, focused file of well-written software.

However, I run into conflict with the pattern early on: its solution mentions “working on problems that are worth fixing”. In my opinion, as contrary as it may be to my above statements, ALL problems are worth fixing. The priority should be chronological, not a binary form of “assert/ignore”. Yes, figuring out our failures and becoming specialized is great, but even a specialist should be somewhat familiar with as much material as possible. A good team member benefits from a great crew, but can also proceed on their own (even if the progress slows down).

Going forward, I plan on using this pattern in my Capstone adventures (as well as my professional career) by trying to figure out what my specialty is. Which failures are the most extravagant? Which ones are fixable? Which ones are worth the effort despite the challenge? A big problem about my stance in computer science is that my stance is too vague (this was the original reason why I declared this major).

Hopefully, I will be able to cut down on this “vagueness”; despite computer programming being applicable in many fields, I will find the one that I am meant to work in. By finding my failures, the search will increment ever more closely to a successful result.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.