As you may hope, or expect, this final sprint is where everything really came together, and we were firing on all cylinders. We had consistent communication when needed and otherwise had tasks we could work self-sufficiently on in the meantime. Our task board was positively stuffed with tasks that expressed the minute details of our process, and we managed to complete an incredible amount of their weight considering how many there were. Having spent the first sprint unsure of what tasks actually needed doing, and the second iterating on what we had created, I believe this was the moment all the building blocks fell in place; and it felt, at least personally, that tasks were clear and specific, comprised of all the things I wished to improve from the rough iterative process mentioned in the second sprint.

            I think having finalized our UI design, or at least cemented the layout, allowed for easier improvement of said design. In many ways, having a finalized user flow in place made so that much of the non-style code could be refactored to store and manage information more effectively. For instance, as mentioned in the note above, I began with calling REST API to log transactions in the weight entry component where the necessary information would end up: student ID and weight. After refactoring, I broke both the storage and management of guests into a service which could be more easily accessed by any component and centralized any API calls made using guest information. This worked perfectly except for a single instance, where I needed this service to call another component. Services can be easily imported by components but sending information to a specific component from a service is more complicated. As I understand, the code I used subscribes the component I needed to speak to, to the service, which then can send a signal to that component, which in turn calls one of that component’s methods.

            Regarding what did not work, it is a combination of both personal and group strategy. While we each could work effectively alone on our own independent portions, it meant that we all became intimately familiar with only one or two aspects of the project. This has especially caused problems most recently with trying to move our respective portions into Docker, as I was the only one who knew next to nothing about Docker. Therefore, I could not help my group members work on any problems my front end code may have caused. I see not keeping up with my group member’s Docker progress as a personal failing. Now both in this class and in the workforce to come, I am wishing I had this knowledge of such a powerful and seemingly common framework. Otherwise, I am very proud of the work my group members did and think given some more cross-cutting training we would be that much more of an effective team. Especially given everything that has been going on we have managed to put together a site that is nearly ready to roll out. (With the caveat, of course, that it may not be absolutely perfect but can perform all the tasks necessary).

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

It states that one should choose a complex, and necessarily open source, project in the language you are hoping to learn to fork and pore over. In doing so, one can internalize as many of the lessons this code may have to teach, the ways experts write in this language, the “tricks of the trade” if you will; and, as a result, be inspired to apply these concepts in ones own project. This unfortunately, sounds terribly boring. It’s hard enough for me, and many other students I know, to pick apart our own code only months after writing it. I can’t imagine trying to parse years of work by developers with an incredible knowledge of their chosen language. This seems like a recipe for frustration. I could easily see a student not unlike myself throwing themselves at a new language in this fashion and coming away discouraged and maybe even completely overwhelmed; to the point where they may shy away from learning that language at all.

Instead, I would propose a healthier middle ground. I find that in messing with the code you can find little victories where your exploration paid off – victories that, for myself at least, keep me motivated. However, as mentioned previously, learning completely on ones own may waste valuable time and internalize bad or inefficient habits. As such, I think one should push their abilities as far as they can manage, then seek guidance from communities online. There exist thousands of YouTube tutorials and stack overflow threads where more than one solution is reached to nearly every problem; so, unlike the open source project, you can pick a solution that has a logic you understand best and can implement. I may have no patience to dig through years of documentation, but I don’t lack the patience to instead experiment and ultimately learn the language/framework.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

I had already determined to seek out an internship or entry level position outside of my home state. Further, I wanted to join a company where I, of course, could be actually hired but one that would truly test the limits of my skills. Ideally, I would want it to be an internship though, cause as much as I want to make this change in scenery, I’m still hesitant to get stuck someplace I’m miserable. I think the true test will not just be getting a position away from home but finding a place for myself in that new place and maybe even gaining the confidence to stay and accept a job at the company – in the case of an internship.

I did find one internship that states that they will make no “intern-work” and one should be expected to work as a peer with the rest of their fellow employees; and on a massively used and well-known mobile application no less. I jumped at the chance to apply for this position, and I am incredibly hopeful I get it, as it is the perfect storm of conditions I am hoping for. Enrique’s story is still a little too dramatic for me to imagine emulating, but I hope if the opportunity to work in another country even presents itself, I will have the confidence to take it.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

As new learners, we tend to go in all different directions, not favoring any set method because we have yet to find the path of least resistance or best practices. Subsequently, we create puzzles pieces with our bits of knowledge that we all can combine to get a clear picture of a language, framework, et cetera. I have found as well, that what was often very useful was the ability to politely disagree – read: bicker like an old couple – with your peer and push back and forth on each other to really challenge one’s knowledge or understanding of something. It was through this back and forth that many of the solutions we were so desperately searching for came about; which is something the pattern even addresses, stating that it is imperative to avoid group think and challenge each other.

I remember distinctly have an erratic mass of code segments and illustrations of a particular data structure, the exact one I cannot remember, all over the board in the Science and Technology center study rooms. Data Structures, our major’s trial by fire, has crushed fledgling programmers of far greater skill than me. I can say with no doubt, that had it not been for these brain-storming sessions I would not have passed that class or even completely the projects thoroughly in the way that I eventually did. As I look forward to internships and even jobs after graduation, I hope to keep those around me who I have learned so much from and find new kindred spirits to take on this next chapter of my programming career.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

In sum, this pattern emphasizes that you have been charged with creating a functioning product, not necessarily a pretty one. The line, “the things we build for customers can be beautiful, but must be useful” says it all. I realize in constantly polishing a project before its feature complete, I end up throwing away a lot of work spent on “dolling up” features or elements of the user interface that may change or not even be used. I even caught myself making the same mistake even on a personal project using a different web application language, where I did not even attempt to make any forms or methods that communicated to the backend, instead spending time adding libraries for user interface elements that look nice and animate well. While there is certainly a place for those things, this pattern helps one understand that is when you have all of the parts of your application finalized.

I should have learned this lesson last semester with my final project. I spent so much time fiddling with the color palette and page animations, that the content on those pages was barren, or poorly formatted. It is nice, I think, that my webpage looks and animates nicely, but when pages break upon reloading then it hardly matters. If there is constantly some expectation of failure with a project, then the font you choose is hardly relevant. I think that is what this pattern helped me realize most about this weakness of mine; utility is the most important aspect of software, everything else is so much fluff.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

We
covered the Open/Close principle in a recent lab, and it prompted a desire to
cover some of the SOLID principles. I have determined however, that the length
of this blog is short enough that I should dedicate it to a single principle at
a time, beginning with the aforementioned Open/Close principle.

              This particular object-oriented
principle was outlined by Bertrand Meyer and states:

“…entities should be open for extension, but closed for modification.”

              This of course, is a complex way
of expressing a simple guideline for software development; which is that new
functionality should be able to added without having to radically change existing
code. The operative word, extension, is illustrative. If your code was a home,
and you wanted to add more square-footage (read: functionality), you shouldn’t
need to knock all the walls, or the whole thing, down to add a bathroom.

              In the blog chosen, the author summarizes
a talk he gave about the very subject. In it, he provides an example of a program
he is developing for a company that calculates the total area of a set of rectangles.
As the customer requests more and more shapes be added to the calculator, the original
code changes drastically and gets longer and longer. This modification is opposed
to this principle. In opposition, creating a Shape class that contains many children
of different specific shapes – each with their own area function – with the
ability to add more, eliminates constant modification of the main class, and
allows for constant extensionability in the form of new shapes.

              To say simply that code should be
modular is unhelpful, as it is broad and the general definition of so many more
good coding practices. Our class and homework provide another perfect example.
Why should we have to constantly Override and rewrite portions of a superclass’
methods in each of its child classes to achieve proper functionality. Instead, in
making a Quack/Fly Behavior interface we have established a broad mold that
many new behaviors can be built off of; access to all of which is then granted
by the relationship to the single respective behavior interface.

              Therefore, the ability of code to be
extended with new functionalities, using a single reference – in this case the behaviors,
or shapes – instead of needing to rewrite or overwrite code is what is meant by
extension; while keeping the existing code from needing constant revisions, is being
closed for modification. Like the house example earlier, you should constantly be
building out, not renovating what exists already.

Sources:

A
simple example of the Open/Closed Principle

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

“a change [or changes] made to the
internal structure of software to make it easier to understand and cheaper to
modify without changing observable behavior.”

In
reality, the process may involve:

• new
  code, but it must not change the behavior of the original code;
• ensuring
  the system works before and after each refactor, including original unit tests;
• creating
  unit tests to verify our refactoring has not changed system behavior;
• changes
  that individually are minute, but combined lead to a healthier program;
• eliminating
  duplicate code, potentially changing variable names, and more.

It is not
simply cleaning up code, but rather reorganizing it in order to make it easier
to trace and understand, as well as add functionality to in the future.

              For our purposes, this may be a very
important concept to learn but it may be some time before we get to implement
it, unless we’re coding or maintaining an entire program for our capstone; however,
it is important to understand when to do so. According to my sources, the best
time to do so is before you add new features to an existing program, or right
after you’ve already shipped it. For the former, it makes these new features much
easier to add when the program is much more readable and makes the program better
for having made the changes. As for the latter, it makes a lot of sense to
snoop around for ways to reorganize code after you’ve spent so much time on it,
and in a mad dash to finish it towards the end no doubt. Years’ worth of work
is no doubt going to have some inconsistencies that fell through the cracks in
the course of development.

              As for implementing these changes, there are several methods, including Red-Green-Refactor, Abstraction, Simplifying Methods, as well as many others we won’t cover. In R-G-R, red means stop and determine what to develop – usually with a new test that fails, getting this new development to pass tests (green), and finally refactoring to optimize. Abstraction is used to address duplicate code and can be done by restructuring hierarchies using the Pull-Up [pulling up code into a superclass to be shared more effectively] or Push-Down [pushing down code to more subclasses from a superclass] method. Finally, Simplifying Methods is an effort to simplify older code by consolidation and reducing interclass complexity. Hopefully this helps develop an understand of refactoring, in fact, I had to do quite a lot of refactoring to this blog to get it down to size!

Sources:

Refactoring – Martin Fowler
Refactoring – Agile Alliance
Code Refactoring Best Practices: When (and When Not) to Do It

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

KISS
(Keep it Simple, Stupid) is potentially one of the most culturally pervasive concepts
used in Computer Science, the other being maybe blockchain – the difference of
course is that people actually understand what KISS is, everyone who says they
understand blockchain is lying. Of course, KISS did not originate in Computer
Science, and instead was popularized at Lockheed Skunk Works by noted
tangential war criminal and engineer Kelly Johnson. While it may be difficult and
seemingly sacrilegious to try to explain something so self-explanatory that is
what I hope to do, flying in the face of the concept of simplicity to stretch
four words into four hundred.

              It begins with, put kindly, making
distinctions about the semantics of the scant few words in this phrase; put
more bluntly, being pedantic. This examination is important, and the linked
article does a great job of highlighting first the distinctions between ‘simple’
and ‘easy’, which could be mistaken as synonyms, and contrasts it with ‘complex’.
His conclusion is this, a simple system is defined by what it is not, which is one
with too many parts which are interconnected – with the latter being worse in
software development.

              This all sounds wonderful on paper,
and about the same on a computer screen, but sometimes complexity is
inevitable. So, it is advised that you make things as simple as possible, until
you can’t, at which point you are vigilant in handling that necessary
complexity. For instance, I could try all sorts of methods to navigate a 2D
array in some mock-up code, but I don’t need to introduce recursion or anything
outrageous to shorten a method body if a simple nested loop will do.

              This idea of simplifying through pruning
code is expressed in the next sections of this post, stressing the importance
of cleaning up dead or underutilized code so that no resources are wasted maintaining
or reintegrating useless code. Additionally, YAGNI (yay more acronyms) states
more or less the same thing, encouraging programmers to implement the essentials,
that will actually be presently utilized, and skip the bells, whistles, and
maybes. Code with bunches of maybe methods require time and resources to
maintain and if they aren’t actively being utilized, then they’re a waste of
both.

              From here on, the blog introduces
many more concepts that are possible to cover in just this blog post – although
I do hope to mention Lasagna Architecture in another post sometime later. Instead,
I think it is time to bring this post to a close. What is the take-away then?
Well its exactly what you thought it was from the first line. In conclusion, it
may be appealing to get a jump on features you may want to implement in the future,
but it is best to keep things as simple as possible and/or only as complex as
needed but no more.

Sources

KISS Principle Explained
KISS, A Design Principle

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Some advice for others who may be working on the same thing would be to try and collaborate or discuss potential orders between groups if one thing may depend on another. That would make it much simpler from the start if possible so there aren’t any clashes or time wasted on doing extra work that could have just been done by one group or team.

In the meantime, I did a little more research on the AMPATH system out of curiosity since we are going to be building onto their work. I found out that there are 500+ care sites in Kenya! It is interesting to think about the potential impact our work may make on how AMPATH carries out their process. Their initiative reminds me of what Enactus at Worcester State strives for when they work on projects to help people or organizations in the community “sustain their own success, connect them with universal health insurance, train next generation medical professionals, and research new breakthroughs and best practices.” Being able to help a healthcare organization is pretty meaningful, especially as a project through my capstone.

A way to tie our 348 course (Software Process Management) with our 448 (Capstone) course would be through now being able to use Travis CI and Heroku. It was interesting being able to experience using these in class and help our peers use it and now be able to use them in our capstone. I think the practice we got was nice because I found that my peers and I were more comfortable with following steps that were written out and explained to us instead of just “going for it.” I have also noticed that our 348 course helped us pay more attention to how we interact with others, which is very useful for the future when we will be working in teams of developers to create or update new technologies. One more thing which I found useful was seeing Travis CI load, and the race against time when it came to classmates pushing code at the same time; it made me push myself to be a little faster while at the same time not be sloppy about what I was putting into my code.

Overall, we discussed what we will do in these coming weeks as the semester comes to a close. The project we are planning on presenting will feature a search bar which we plan to implement by then. I am excited to see what we end up with in terms of helping AMPATH and their healthcare system!

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

I found that the pattern is interesting because it emphasized the importance of how the things built for customers can still be beautiful but must always be useful. If it strays away from being useful, then it no longer counts as the craft.

I also found it to be thought-provoking because it brought up how people are truly in charge of how a problem gets solved. No one can force you to code something a certain way if they do not know a way to solve it on their own, which is why your role exists in the first place.

The pattern has caused me to change the way I think about my intended profession because your work can still reflect you in terms of creativity. As a person, I think I am more on the creative side and incorporating more ideas into creating something for people sounds pretty cool. If I had to follow a super rigorous structure, I may feel limited in what I can do to produce work that makes me happier.

The one thing I have to disagree with in the pattern is the part where it mentions that someone is suddenly no longer “part of the craft” if they deviate a little further. Who sets these boundaries? I do not want people to feel like they are not “enough” to be considered a real craftsman or whichever term it is referred it as just because they were being extra.

Overall, I appreciated the action section which encouraged people to reflect on what projects they worked on or situations they may have found themselves in where they chose creativity over usefulness. At the moments where I have personally done so, I had felt more proud of my work, because I knew it was uniquely mine.

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.