So far we’ve dealt with design smells and played with the Duck factory. Which is a great segue into our next topic, Design Patterns, one of which is the Factory Pattern. Design patterns allow us to look at our code, usually as the need for changes arise and utlize the benefits of a design pattern. With our Duck Factory exercises this is where we began. We created duck objects and added them to a pond. As the number of types of ducks changed so did their behaviors. Does a rubber duck quack? Can a cement duck float? Does decoy duck fly? Our initial Factory design pattern worked fine until we our duck types changed and it became evident that the design pattern needed to evolve. Out first iteration took the factory design pattern and migrated to an Abstract Factory pattern. Now our ducks could inherit behaviors from interfaces. But should a decoy duck be inheriting quack behaviors? The Abstract Factory design pattern is really just a transitional pattern to the Strategy Pattern. As we moved our code around it became clear that we were making things a little more complicated than they needed to be. We were starting to introduce some needless design smells. The advantage of the Strategy Pattern is it favors encapsulation. The “Strategy” is to define a set of algorithms, encapsulate each one and make them interchangeable. This allows the algorithms to vary independently from the clients that use them. In the case of our Duck Factory and the ducks (and duck sub-classes) use the encapsulated behaviors (and sub-behaviors) to fly, quack, squeak, and in the case of cement duck sink. We covered 3 other design patterns and next week I’ll touch on those. Until then happy coding! #CS@Worcester #CS343

From the blog Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Stinky Duck – We’ve been doing some fantastic exercises centered around design smells. These are the seven primary design smells: ● Rigidity ● Fragility ● Immobility ● Viscosity ● Needless Complexity ● Needless Repetition ● Opacity I’m not going to waste your time giving you the definitions. Where’s the fun in that, do a little research and find out why your code may smell a little funky. But I do want to talk about ducks. Not just any ducks, stinky ducks. Some of the exercises we’ve been doing have been centered around “The Duck Simulator”. What does a duck do? Well that depends on the duck, right? Mallard Ducks can fly, swim, and quack. But a Decoy Duck does not fly, does not quack, and does not swim. Though Decoy Duck can float. How do ducks relate to Object Oriented Programming? Let’s imagine a Duck as a JAVA class. In our first pass of designing a duck we made a Duck super class with sub-classes of each type of duck. What’s wrong with having a duck super-class and sub-classes for each type of duck? Look back at the seven smells. can you see it? What’s going to happen when we start adding more duck types? We’ll end up with a lot of repetitive code. What’s the quickest way to reduce repetitive code? What about using inheritance? Inheritance will help but now we’re overriding a bunch of methods for the different duck types. Decoy duck doesn’t need a quack method. We would have to override the quack method. In fact for every duck type we would have to override methods that are inherited from the super-class. You know, because they are inherited. We could look at our super class (Duck) and see where we can improve the code. Well look at that, all the duck types have something in common. They exhibit specific behaviors. They fly (or not) and quack (or not). We can take these behaviors and create interfaces. Our goal should be to make the super class fixed but extensible. Now if we keep adding new types of ducks (Ghost ducks and Rocket Ducks anyone?) we will be able to identify additional areas for clean up. See, our simple Duck went from a slight smell to a real funk quickly. The design smells can be reduced to a manageable level by following the prinicples of clean code. We’ll talk more about design smells and clean code next week. #CS@Worcester #CS343

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Let’s face it, there is no one perfect platform for hosting repositories. This isn’t a debate about whether Github is better than Gitlab. They both have their pluses and minuses. Recently, we had to move a repository from Gitlab to Github. Without using a migration utility we were able to successfully migrate by following a few steps which I will outline below. This is the approach that we utilized and worked for us using these tools: · Gitbash (https://gitforwindows.org/) · Notepad++ (https://notepad-plus-plus.org/downloads) At a high level the steps we followed are (*Note* this a high level overview see the steps below for the details): · Fork and Clone from Gitlab · Move, find and replace all pointers at the file system level · Create an empty repository on Github · Fork and clone the empty repository from Github into a new folder · Copy all the Gitlab project folder to the Github project folder · Push to the Github repository Read the below steps a couple of times. DO NOT just skim them (something I am guilty of doing frequently) but read through them and make sure to pay attention to the NOTES. Steps/Details: To demonstrate the steps taken I’ve created two folders GitLab and GitHub. We’ll start by working in the Gitlab folder first. From your Gitlab dashboard fork and clone the repository into the local GitLab folder. Navigate to the GitLab repository folder locally. The goal here is to go folder by folder and using Notepad++ replace all instances of gitlab with github. Take your time and do each folder individually. Not every file will have a reference to gitlab in it but Notepad++ has a handy replace all feature that will make this short work. As you are traversing the folders rename any folders that are named gitlab to github as well. Once you finish renaming everything open git-bash in the gitlab folder and copy everything to your github folder: CP is the bash copy command -avr translates to -a = preserve attributes, file modes, ownership, timestamps… -v = verbose output -r = copy directories recursively On Github create a new empty repository. Open a new git-bash window from the new github repository folder you copied everything into. To retain your Git history follow the instructions from Github to push an existing repository from the command line (make sure you are in the github repository folder) : NOTE: If you get this error: fatal: remote origin already exists Do not proceed with the git push. Run this from you git-bash session: git remote rm origin If you don’t receive any additional errors re-run the git remote add origin followed by the git push. At this point you have moved your repository to Github. Verify your app is working correctly and if you are getting any errors go back and double check to make sure you changed all the references from gitlab to github everywhere including folder names. #CS@Worcester #CS448

From the blog Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Stinky Duck – We’ve been doing some fantastic exercises centered around design smells. These are the seven primary design smells: ● Rigidity ● Fragility ● Immobility ● Viscosity ● Needless Complexity ● Needless Repetition ● Opacity I’m not going to waste your time giving you the definitions. Where’s the fun in that, do a little research and find out why your code may smell a little funky. But I do want to talk about ducks. Not just any ducks, stinky ducks. Some of the exercises we’ve been doing have been centered around “The Duck Simulator”. What does a duck do? Well that depends on the duck, right? Mallard Ducks can fly, swim, and quack. But a Decoy Duck does not fly, does not quack, and does not swim. Though Decoy Duck can float. How do ducks relate to Object Oriented Programming? Let’s imagine a Duck as a JAVA class. In our first pass of designing a duck we made a Duck super class with sub-classes of each type of duck. What’s wrong with having a duck super-class and sub-classes for each type of duck? Look back at the seven smells. can you see it? What’s going to happen when we start adding more duck types? We’ll end up with a lot of repetitive code. What’s the quickest way to reduce repetitive code? What about using inheritance? Inheritance will help but now we’re overriding a bunch of methods for the different duck types. Decoy duck doesn’t need a quack method. We would have to override the quack method. In fact for every duck type we would have to override methods that are inherited from the super-class. You know, because they are inherited. We could look at our super class (Duck) and see where we can improve the code. Well look at that, all the duck types have something in common. They exhibit specific behaviors. They fly (or not) and quack (or not). We can take these behaviors and create interfaces. Our goal should be to make the super class fixed but extensible. Now if we keep adding new types of ducks (Ghost ducks and Rocket Ducks anyone?) we will be able to identify additional areas for clean up. See, our simple Duck went from a slight smell to a real funk quickly. The design smells can be reduced to a manageable level by following the prinicples of clean code. We’ll talk more about design smells and clean code next week. #CS@Worcester #CS343

From the blog Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Let’s face it, there is no one perfect platform for hosting repositories. This isn’t a debate about whether Github is better than Gitlab. They both have their pluses and minuses. Recently, we had to move a repository from Gitlab to Github. Without using a migration utility we were able to successfully migrate by following a few steps which I will outline below. This is the approach that we utilized and worked for us using these tools: · Gitbash (https://gitforwindows.org/) · Notepad++ (https://notepad-plus-plus.org/downloads) At a high level the steps we followed are (*Note* this a high level overview see the steps below for the details): · Fork and Clone from Gitlab · Move, find and replace all pointers at the file system level · Create an empty repository on Github · Fork and clone the empty repository from Github into a new folder · Copy all the Gitlab project folder to the Github project folder · Push to the Github repository Read the below steps a couple of times. DO NOT just skim them (something I am guilty of doing frequently) but read through them and make sure to pay attention to the NOTES. Steps/Details: To demonstrate the steps taken I’ve created two folders GitLab and GitHub. We’ll start by working in the Gitlab folder first. From your Gitlab dashboard fork and clone the repository into the local GitLab folder. Navigate to the GitLab repository folder locally. The goal here is to go folder by folder and using Notepad++ replace all instances of gitlab with github. Take your time and do each folder individually. Not every file will have a reference to gitlab in it but Notepad++ has a handy replace all feature that will make this short work. As you are traversing the folders rename any folders that are named gitlab to github as well. Once you finish renaming everything open git-bash in the gitlab folder and copy everything to your github folder: CP is the bash copy command -avr translates to -a = preserve attributes, file modes, ownership, timestamps… -v = verbose output -r = copy directories recursively On Github create a new empty repository. Open a new git-bash window from the new github repository folder you copied everything into. To retain your Git history follow the instructions from Github to push an existing repository from the command line (make sure you are in the github repository folder) : NOTE: If you get this error: fatal: remote origin already exists Do not proceed with the git push. Run this from you git-bash session: git remote rm origin If you don’t receive any additional errors re-run the git remote add origin followed by the git push. At this point you have moved your repository to Github. Verify your app is working correctly and if you are getting any errors go back and double check to make sure you changed all the references from gitlab to github everywhere including folder names. #CS@Worcester #CS448

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Heroku a haiku: Constant deployment Integration on the fly Heroku for you Let’s talk about the devops cycle. It’s comprised of several different layers. We’re going to focus on Continuous Integration (CI), Continuous Delivery(CD), test automation, and configuration management. More importantly we are going to focus on connecting our Gitlab repository with Heroku. We’ll do this so we can get the CI/CD environment setup for our branch of the LibreFoodBank. So what do we need to accomplish this? We’ll need our repository on Github migrated to Gitlab. This has already been done and we will be working from a specific forked branch for our testing. We’ll need our Heroku account setup. This has already been setup for us. Since we are stepping into this project at this phase we should just need to follow some basic steps to link the two. Once we have confirmation that all the steps work correctly and are repeatable we will create working documentation for other teams to utilize. Here’s the high altitude overview of how we will accomplish this: Setup Gitlab account Generate a pair of SSH keys Setup staging and production environments in Heroku Setup tests Setup the CI environment on Gitlab Install and register Gitlab Runner Configure the pipelines and fire it up Again this is the 20000 foot look at how we are going to get where we need to be and we’ll be taking notes as we go! #CS@Worcester #CS448

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Heroku a haiku: Constant deployment Integration on the fly Heroku for you Let’s talk about the devops cycle. It’s comprised of several different layers. We’re going to focus on Continuous Integration (CI), Continuous Delivery(CD), test automation, and configuration management. More importantly we are going to focus on connecting our Gitlab repository with Heroku. We’ll do this so we can get the CI/CD environment setup for our branch of the LibreFoodBank. So what do we need to accomplish this? We’ll need our repository on Github migrated to Gitlab. This has already been done and we will be working from a specific forked branch for our testing. We’ll need our Heroku account setup. This has already been setup for us. Since we are stepping into this project at this phase we should just need to follow some basic steps to link the two. Once we have confirmation that all the steps work correctly and are repeatable we will create working documentation for other teams to utilize. Here’s the high altitude overview of how we will accomplish this: Setup Gitlab account Generate a pair of SSH keys Setup staging and production environments in Heroku Setup tests Setup the CI environment on Gitlab Install and register Gitlab Runner Configure the pipelines and fire it up Again this is the 20000 foot look at how we are going to get where we need to be and we’ll be taking notes as we go! #CS@Worcester #CS448

From the blog Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

What’s UML? Go ahead look it up, I’ll wait. No, not UMass Lowell it’s Unified Modeling Language. The current UML Standard, 2.0, has been around since 2005. With 14 different diagram standards UML allows individuals to work at a much higher level of abstraction. I’m familiar with UML from creating ERD diagrams while doing RDBMS work. As a developer it allows me to write pseudo-code quicker, cleaner and platform independent. From a developers stand point, let’s take a look at an example and break it down. I found the example below at https://medium.com/@smagid_allThings/uml-class-diagrams-tutorial-step-by-step-520fd83b300b I really enjoy the content at Medium.com, the articles, reviews and tutorials are all helpful and well written. This is a typical Class diagram representing 4 classes: Animal, Duck, Fish, Zebra. Notice how each of the four blocks are structured the same. Let’s focus on the Animal block. In the upper box notice that Animal is written with a bold font. This indicates that Animal is a concrete class. Abstract classes would be italicized. The next box down is where you define attributes. Public attributes are denoted using a + while private attributes use a -. Looking at our example this would translate into JAVA like this: public Int age; public String gender; The lower box is for methods or functions. The same convention is used for dentoing public or private methods. In the Animal class the example would translate to: public isMammal(){ }; public mate(){ }; Note the example is missing the return types for methods. The convention is to follow the paranthesis with a colon and list the return type. In our example isMammal would be +isMammal () : boolean Relationships between the classes are denoted using lines, arrows and diamonds. In our example the solid line with the white filled arrow indicates inheritance. The article/tutorial above has a great png showing the different relationship lines. The number of online resources for information related to drawing UML diagrams is staggering. For more information and to take a deeper dive into UML go to the source and check it out https://www.uml.org #CS@Worcester #CS343

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.