Our team is currently tasked with creating an offline password-encryption service for the Ampath application.  After consulting with the people at Ampath, we made the decision to devote this sprint to creating test-applications that utilize the 3 encryption-libaries we discussed with them.  Unfortunately, our meetings were interrupted again this sprint; 2 of our 4 meetings were cancelled due to snow.  The days that we did meet, we spent a majority of our time coding and discussing our progress.

I was tasked with creating a test-application that utilizes the encryption libary bcryptjs .  Bcryptjs uses salt and an adaptive function to improve security and its implementation purely in JavaScript provides resistance to brute-force attacks.  I was the team member who suggested bcryptjs, when we compiled options to discuss with the Ampath people, so it felt natural for me to be the one writing the test application.

I did run into some trouble, though –  all of the resources and APIs for bcryptjs are tailored to JavaScript, rather than TypeScript.  This has been quite an impediment for me as I am not proficient in JavaScript, so I have had to learn a bit of JavaScript at the same time as I develop this test-application.  We are using WebCharm to work on development for the application, and WebCharm has a tool to compile TypeScript to JavaScript, and I have been looking into whether it is possible to compile JavaSvcript to TypeSript.  As I mentioned earlier, 2 of our 4 meetings were cancelled due to snow and I was without power for 3 days of the sprint, so I was not able to troubeshoot and push through this problem in time.  The issue of being unfamiliar with JavaScript, as well as installation and compilation errors, has also been afflicting my teammates – nobody was able to produce a working test-application by the end of the sprint.  Spring break is coming up and, while we are not required to work toward sprint goals during break, I intend to try and get myself up to speed with Angular, JavaScript, and bcryptjs so that, upon our return to school, I will be ready to make a meaningful contribution toward meeting this goal for the Ampath organization.

It definitely felt like all the teams had much more direction during this sprint.  We have begun implementation and feel more familiar with the application itself.  Our team has been using our in-class meetings more efficiently and I think we all have more of an idea of each other’s working-pace.  I feel a bit worried about the fact that my teammates and I feel unsure of ourselves within JavaScript, because I think it will be hard for us to have to learn JavaScript at the same time as we work on the Ampath application.  I’m hoping that Spring break will allow us to gather ourselves and come back more productive than ever.  I have still enjoyed working on the application, so far, and I hope that we can make some sort of meaningful contribution(s).

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

This week, I will be writing a reflection on the “Craft over Art” pattern.  This pattern addresses developers facing the problem of wanting to create something special for the client, but there already exists a proven solution at your disposal.  I chose to reflect on this pattern because I think it’s a pattern that all developers can relate to, at some point in there career, and I liked the quote that Oshineye and Hoover provided to distinguish craft from art: “I would describe programming as a craft, which is a kind of art, but not a fine art.  Craft means making useful objects with perhaps decorative touches.  Fine art means making things purely for their beauty” – (Richard Stallman).

The first piece of advice they provide is that, as a developer, you need to do your best work in ways that place the interests of your customers over your desire to display skill.  This is an act of balance because the things built by software developers must be useful but they may or may not be beautiful.  Creating something that is beautiful but useless is not being a craftsman; because a craftsman always values utility above all else. The general rule of thumb in software development, according to Oshineye and Hoover, is to sacrifice beauty in exchange for utility whenever necessary (which is often).  Your focus should always be to deliver value to the customer, first and foremost.

The second piece of advice they provide is that, as a developer who considers themself a craftsman, you should produce quality work regardless of your personal interests/feelings.  This ensures that the customer is being delivered a piece of software that provides immediate value to them.  This is the part of the pattern that I most agreed with because this is already the kind of work ethic that I bring into both my school and work-life.

Utilizing this pattern means to find the balance between your customer’s desire for an immediate solution and your standards as a software craftsmen.  As a craftsman, you should have an understanding that utility and beauty are not opposed and that it is crucial to hold onto the balance with your customer, even in stressful situations.  If a stressful situation causes you to make a mistake, you are also responsible for knowing how to refactor and repair – often times from the ground up.  Oshineye and Hoover provide another useful quote to conclude the pattern: “it is by fixing things that we often get to understand how they work” – (Sennet).  I found this pattern to be quite useful and, from this point forward, I will carry this concept of balance with me as I move forward as a developer.

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

Our second sprint mainly consisted of reviewing the source code of the Ampath application.  The first of our 4 meetings was uneventful, because only 2 of our 5 members were present.  During the other 3 meetings, we worked with one of the other development teams to review the services within the application, reviewed the ReST API, and discussed how we might be able to utilize them in our own work.  Our team then accepted the task of implementing offline encryption for the application, and got in contact with some of the people at Ampath to get their input on their preferred encryption libraries.

Our team members collaborated well with one another and the other development team we worked with.  We were able to gain more of an understanding of how the Ampath application works, through our reviews, and we were able to begin planning our course of action as we head into the coming sprints.  We devoted a majority of this sprint to review and planning, so we have yet to start working on any kind implementation.  We hope to begin coding once we have some more structure and concrete direction, in the next sprint.

Toward the end of the sprint, we began working on the offline encryption task and we found 3 suitable libraries that we could use in our implementation.  We wanted input from the Ampath people before we chose a library to begin working with, so we sent them the 3 that we selected.  In their response, they commented on the fact that the encryption library ‘forge’ seems to be the most popular on GitHub, but stated that we could use whichever one we think would work best.  We will likely make our decision in the next meeting.  In our correspondence with the people at Ampath, we were also provided the main ReST API calls that are used within the application.  This will be extremely useful in the future when we have to begin sending and retrieving medical data in the implementation of the other offline features.

It was, once again, a fairly straight forward sprint.  I think that all of the development teams could use a bit more direction right now, but the coming sprints will certainly be more productive now that we are more familiar with our team members and the application itself.  I have so far been enjoying the Scrum development cycle and I look forward to beginning implementation.

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

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.

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

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.

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

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.

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

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:

• Functionality Testing
• Usability Testing
• Interface Testing
• Compatability Testing
• Performance Testing
• Security Testing

Functionality Testing
Testing links, forms, cookies, browser optimization, databases, etc.

• Links – Test for external and internal links, links used to send email/messages from users; Check for unlinked pages, broken links, etc.
• Forms – Test for validations on each field, default values, wrong inputs, options to create/view/delete/modify forms, etc.
• Cookies – Test for enabled/disable options, encryption, session cookies storing session information after they end, deletion of cookies, etc.
• Browser Optimization – Test for syntax errors, crawlability, etc.
• Databases – Test for data integrity, errors while you edit/delete/modify databases, correct execution of queries,  etc.

Usability Testing
Testing navigation, conent, user assistance, etc.

• Navigation – Test for ease of use, consistency, etc.
• Content – Check for spelling errors, broken in-text links, proper format of text and images, etc.
• User assistance – Check for all links on sitemap, test search options and help files, etc.

Interface Testing
Testing the application server and database server interfaces.

• Check that interactions between servers are executed properly, what happens if a user interrupts one of these interactions, what happens if a connection to the server is reset during an interaction, etc.

Compatibility Testing

• Testing the compatibility of the program to different browsers, operating systems, mobile operating systems, and printers.

Performance Testing

• Testing the performance of the application on different internet connections with different amounts of traffic.

Security Testing
Testing the web security of the application.

• Test for internal pages opening without being logged in, reaction to invalid login inputs, effective CAPTCHA, all transactions/errors/security breach attempts should get logged in log files somewhere on the web server, etc.

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

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:

class Program
{
static void Main(string[] args)
{
User user = new User(1);
}
}
class User
{
IDAL dal;
public User(int IDALtype)
{
if(IDALtype == 1)
{
dal = new MySQLDAL();
}
else
{
dal = new SqlServerDAL();
}
}

class Program
{
static void Main(string[] args)
{
User user = new User(new MySQLDAL());
}
}
class User
{
IDAL dal;
public User(IDAL IDALtype)
{
dal = IDALtype;
}
}

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

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.

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