Category Archives: CS-343

Javascript

On this post I decided I need to catch up on learning javascript for my homework assignments, having no real prior experience I needed more than just the simple basics but rather things I must know to succeed and not be confused. Which lead me to this article below.

https://dev.to/deen_john/resources-to-master-javascript-3d0p

I have honestly not done any web development aside from a brief exposure to html in high school, and while I did get some experience with javascript I didn’t experience enough to retain any memory of it. So this article above has not only the fundamentals in forms of multiple links and tutorials, it also contains a plethora of actual content in the article on each subject that is brought up. Often searching for articles on javascript it would be just a repository of links, but this is structured with other links prior to an example given as well as an explanation.

Right off the bat the type system was interesting to learn about, considering that the types are not actually different but the syntax is quite different as well as coercion being even a thing is interesting. That you could multiply a string and a number and get a number due to implicit conversion.

Another interesting thing I learned is that every value that isn’t a primitive value is an object. So variable1 = 500; is a primitive value so it’s simply just a number value. If it doesn’t contain a primitive value of any kind it will need to be defined as an empty object with {} after the name declaration. There is no item declaration type like int or short or double. There is just var name = (primitive value) or {empty object}.

There was also another interesting thing that I didn’t expect was that null is used as an object and that undefined is generally there to show that a value has been declared and not assigned a value.

I also learned about truthy and falsy, and in specific I was surprised to learn that the Or operator didn’t quite work like I expected. Generally, when using Or there are three conditions I would expect and one I wouldn’t worry about. The first operand is true, the second operand is true, neither operands are true and lastly both operands are true. With the first, second and fourth resulting in a TRUE, I was surprised to learn that javascript only cares if the first operands is “truthy” otherwise it returns the second.

This article helped me a lot and will at least give me a head start and not be confused when I try using Or and expecting a positive result and not just the second operand. It seems unintuitive in some regards but it may just seem that way due to me being so used to the other operators for such a long time.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Blog # 4 Design Patterns (Accidental and Intentional)

During my career as a software engineer, design patterns were heavily used by some clients, and were not used at all by others. I was exposed to them early on by a developer at UNISYS while developing a Windows based control system for NTSB. At that time, there were class library extensions in the marketplace which were commonly used to enhance UI and database access development. We had the opportunity to code our own classes using their framework, as week as modify their code. In order to use their code in a proper way, you had to really understand it, which involved studying the extended class library code and documentation. While doing so, I became familiar with 4 design patterns they had heavily used. These were Singleton, Observer, Iterator and Builder patterns

My architecture class has shown me 3 new patterns I am very impress with. The memento, strategy, and the facade pattern. The class focused on the strategy pattern primarily, with some concentration on the Singleton. Memento and Façade patterns.

I will focus on the benefits of the strategy pattern for this blog entry because I found it to be eye opening. It is very powerful and useful, yet I hadn’t known of it specifically prior to the class. It turns out I had used this pattern many times without knowing it.

Many project I have worked on had objected oriented class libraries, where a solid grasp of OOP programming skills were necessary in the mid-to late 90’s and early aughts. Interface based technology grew into the class libraries and class library extensions, where interfaces became a really useful tool. There were times I coded directly from an interface (when trying to implement a specific API, or to a specification requiring a specific interface), and other time would purely use the Object hierarchy. There were times I had probably used the strategy pattern BY ACCIDENT! By knowingly combining interfaces and OOP with the use of the strategy pattern, a much better design can be constructed where you get the best use of both technologies.

I find the best way to concisely describe the power of this pattern is to quote from the “Better Programming” website [1]

Advantages of the Strategy pattern

1. It’s easy to switch between different algorithms (strategies) in run-time because you are using polymorphism in the interfaces.

2. Clean code results, because you avoid using conditional-infested code (not complex)

3. More clean code, because you separate the concerns into classes (a class to each strategy).

I wish I had had a clearer understanding of this pattern years ago. The example in the Homework using Duck classes was particularly easy to follow, and really showed the symbiosis of interface oriented and object-oriented methodologies in clear way, stressing the benefits of coding to separation of concerns in a well-structured project.

Design Patterns are broken up into Creational, Structural and Behavioral classifications as a way to direct the designer to the appropriate top-level category.

References:

1. http://www.betterprogramming.pub – Carlos Cabarello.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Microservices vs Monolithic

Microservices seem to be a very popular concept in software design, and it is one I have trouble fully understanding. Because of this, I wanted to spend some time developing my understanding. Chris Richardson’s “Introduction to Microservices” is the first article in a series of seven discussing microservices; it compares microservices architecture to monolithic architecture, and it is where I began looking.

Monolithic architecture typically involves one application at its core built to handle a multitude of tasks. This application may branch out into APIs, adapters, or UIs that allow the application to access objects outside of its scope. This application, along with its more modular pieces, is packaged and deployed as a single monolith.

This approach to software design has some inherent problems. Applications tend to grow in size, scope, and lines of code over time. In a monolithic application, code can easily become too large and too complex to efficiently deal with. The resulting applications are often too complicated for a single developer to understand, which also complicates further development. Larger applications also suffer from longer start-up times. Continuous deployment becomes difficult since the entire project needs to be redeployed. It’s difficult to scale monolithic applications as well as employ new frameworks or languages.

Many of the issues monolithic architecture is prone to can be solved by instead adopting microservices architecture. Microservices architecture involves splitting an application into connected but smaller services. These services are typically dedicated to a single feature or functionality and are usually each run in an individual Docker container or VM.

Using microservices architecture comes with a number of benefits. Splitting a complicated, monolithic application into smaller pieces makes that application significantly less complicated. It becomes easier for individual developers to understand the services, thus making development faster. This also allows a team of developers to focus on a single service. Teams can become more familiar with the service they are working on, and maintenance becomes more manageable. Splitting an application into microservices also makes that application easier to scale.

Despite its benefits, microservices architecture is not without its drawbacks. Splitting an application into microservices can introduce a new complexity. These services need to talk to each other, so a mechanism to send and receive these messages must be put in place. It is also more complicated to test an application that uses microservices. A test class for a monolithic application would only need to start that application, but a test class for a microservices application would have to know which services it needs to work.

I chose this article because I appreciated how thorough the information was. I plan on reading the remaining six articles in Richardson’s series. I had not thought about how connecting microservices together might complicate a project. I will be thinking about the pros and cons of microservices as I continue into my career.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The Art of Refactoring

This week I am going to over a post from the CodeGuru. The post starts by talking about the importance of refactoring, what it is and why we refactor. They define refactoring as the process of restructuring or improving the internal structure of code while keeping the functionality of the code and not changing its external behavior. The article then goes on to talk about when the pros and cons of refactoring and why sometimes it is not best to refactor.

Refactoring code can help prevent bugs but if done improperly, refactoring code can also create bugs in your code so that is why it is important to be careful when refactoring code. In the article, it talks about how it is a good habit to analyze your code before refactoring code. If after analyzing your code, you find that you have to refactor most of your code, they caution you against refactoring the program because you may end up creating more work for yourself. Instead, they recommend that it may be better to start over from scratch. Another practice they implore coders to follow is you should not refactor code if you don’t have the tests or plan to create the tests for that code. This is because, without the tests, you may not have sufficient information about whether or not your code has changed the behavior of the program. Another good practice they recommend is you should wait until you deliver the product and use the time in between tasks to refactor code. Software development can be a very time-sensitive industry so some good practices that we should have as programmers are we should be mindful of the time we have before deadlines and be able to analyze whether a task can reasonably be done in the allotted amount of time. We should also establish clear and achievable goals and refactor code in between tasks and before adding new features to the program so that we can avoid technical debt.

I chose this post to review this week because I think it is a very important topic not just in this class but in programming in general. One of the reasons why I chose this topic, in particular, is because in class we often toss the term around in class, we know what it is and how to do it, but we never really talk about how to do it well or what are some good practices that we should follow. Personally, I have been following some of these practices all along such as gauging my time before deadlines and making objectives along the way, but I also have a really bad habit of deviating from those objectives. There were so many times in my undergraduate career where right before an assignment is due, I ended up refactoring the program from start to finish or redoing the entire assignment from scratch. Now that I know good refactoring habits, I can avoid this in the future.

https://www.codeguru.com/csharp/best-practices-for-code-refactoring/

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

SOLID

The SOLID principle helps in reducing tight coupling, which means a group of classes are highly dependent on one another which we should avoid in our code. The opposite, which is loosely coupled classes that minimize changes in our code, helps in making code more reusable, maintainable, flexible, and stable.

This principle is an acronym of the five principles which is given here below:

  • Single Responsibility Principle: This principle states that “a class should have only one reason to change” whoch means every class should have a single responsibility or single job or single purpose. Let’s take an example of the developing software, the task is divided into different members doing different things as front end designes to design, the tester does testing and back end developer takes care of back end development part then we can say that everyone has a single job or responsibility.
  • Open/Closed Principle: This principle states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” which means we should be able to extend a class behavior, without modifying it. Let’s for example, suppose developer A needs to release an update for a library or framework and developer B wants some modification or add some feature on that then developer B is allowed to extend the exiting class created by developer A vt developer B is not supposed to modify the class directly.
  • Liskov’s Substitution Principle: The principle was introduced by Barbara Liskov in 1987 and according to this principle “Derived or child classes must be substitutable for their base or parent classes”. This principle ensures that any class that is the child of a parent class should be usable in place of its parent class should be sable in place of its parent without any unexpected behavior.
  • Intterface Segregation Principle: This principle is the first principle that applies to Interfaces instead of classes in SOLID and it is similar to the single responsibility principle. It states that “do not force any client to implement an interface which is irrelevant to them“. Here your main goal is to focus on avoiding fat interface and give preference to many small client-specific interfaces. You should prefer many client interfaces rather than one general interface and each interface should have a specific responsibility.
  • Dependency Inversion Principle: Before we discuss this topic keep in mind that Dependency Inversion and Dependency Injection both are different concepts. Most people get confused about it and consider both are the same. Now two key points are here to keep in mind about this principle.
  • High-level modules/classes should not depend on low-level modules/classes. Both should depend upon abstractions.
  • Abstractions should not depend upon details. Details should depend upon abstractions.

I chose this topic because, after learning a little more about design patterns, front end, back end, I was curious to learn about SOLID principles and, also I wanted to understand more about it and how it reinforces the need for design patterns in Software.

SOLID Principle in Programming: Understand With Real Life Examples – GeeksforGeeks

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Week-11

 

Hello
blog (mood-status: feeling Good), writing this blog after thanksgiving
dinner and eating well like pretty good with a plate of food alongside
hanging the family. But anyway, on writing about this week-11. To be
truthful here, I writing this because I am falling behind on blogs when
there is nothing to talk about, besides kept being busy with other
courses like HWs and projects, etc. (You get the point. Well, if you are
a student) 

I decided to go on the Syllabus to look at the course topics.

I found the subject of Modeling along with Unified Modeling Language (UML) & C4 Model.

Unified Modeling Language

Large
Companies’ applications that execute core business applications and
keep a company going can more than some code modules. It can structure
in a way that enables:

  • scalability
  • security 
  • robust execution under stressful conditions. 


Their structure is that maintenance programmers can find and fix a bug
that shows up after moving on to other projects. These programs can
design to work perfectly in many areas, and business functionality is
not the only one. A well-designed architecture benefits any program, and
not only the largest ones as singled out. It mentioned large
applications first because the structure deals with complexity, so the
benefits of the network compound as the application size grows large. 


Another use of a structure that enables code reuse was design time.
Ultimately, companies build up models of parts, each unit representing
an implementation stored in code modules. At coding time, the developer
can as promptly import the code module into the application. When
another application needs the same functionality, the designer can
quickly import its module from the library.

The C4 model

The
C4 model made by Simon Brown designates on UML and the 4+1
architectural view model. It breaks down software into smaller units for
modeling. Like the quick methodology, the C4 model requires fast,
efficient sharing and constant updates of software architecture in
software development.

The
C4 model (shown as a map). The Maps can build on a different scale. By
changing scales, like for example; The town map with streets and
buildings. Having the C4 model changes the level of a diagram to
describe software architecture. Using the abstraction-first approach, C4
conducts modeling top-down from system context to lower levels.

  • Person (Element) – users or roles of a software system
  • Software
    system (topmost level in abstractions) – the value of existing systems
    or systems under development and the interaction between those systems
  • Container
    (Element) – the internals of software systems, usually applications or
    solutions for data storage. A different concept to containers in Docker.
    It mainly refers to software that is single deployed.
  • Component (Abstraction element) – The containers of modules or a set of interfaces grouped as a functional unit.
  • Relations – dependencies or data flow between abstraction elements.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Week-11

 

Hello
blog (mood-status: feeling Good), writing this blog after thanksgiving
dinner and eating well like pretty good with a plate of food alongside
hanging the family. But anyway, on writing about this week-11. To be
truthful here, I writing this because I am falling behind on blogs when
there is nothing to talk about, besides kept being busy with other
courses like HWs and projects, etc. (You get the point. Well, if you are
a student) 

I decided to go on the Syllabus to look at the course topics.

I found the subject of Modeling along with Unified Modeling Language (UML) & C4 Model.

Unified Modeling Language

Large
Companies’ applications that execute core business applications and
keep a company going can more than some code modules. It can structure
in a way that enables:

  • scalability
  • security 
  • robust execution under stressful conditions. 


Their structure is that maintenance programmers can find and fix a bug
that shows up after moving on to other projects. These programs can
design to work perfectly in many areas, and business functionality is
not the only one. A well-designed architecture benefits any program, and
not only the largest ones as singled out. It mentioned large
applications first because the structure deals with complexity, so the
benefits of the network compound as the application size grows large. 


Another use of a structure that enables code reuse was design time.
Ultimately, companies build up models of parts, each unit representing
an implementation stored in code modules. At coding time, the developer
can as promptly import the code module into the application. When
another application needs the same functionality, the designer can
quickly import its module from the library.

The C4 model

The
C4 model made by Simon Brown designates on UML and the 4+1
architectural view model. It breaks down software into smaller units for
modeling. Like the quick methodology, the C4 model requires fast,
efficient sharing and constant updates of software architecture in
software development.

The
C4 model (shown as a map). The Maps can build on a different scale. By
changing scales, like for example; The town map with streets and
buildings. Having the C4 model changes the level of a diagram to
describe software architecture. Using the abstraction-first approach, C4
conducts modeling top-down from system context to lower levels.

  • Person (Element) – users or roles of a software system
  • Software
    system (topmost level in abstractions) – the value of existing systems
    or systems under development and the interaction between those systems
  • Container
    (Element) – the internals of software systems, usually applications or
    solutions for data storage. A different concept to containers in Docker.
    It mainly refers to software that is single deployed.
  • Component (Abstraction element) – The containers of modules or a set of interfaces grouped as a functional unit.
  • Relations – dependencies or data flow between abstraction elements.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Week-11

 

Hello
blog (mood-status: feeling Good), writing this blog after thanksgiving
dinner and eating well like pretty good with a plate of food alongside
hanging the family. But anyway, on writing about this week-11. To be
truthful here, I writing this because I am falling behind on blogs when
there is nothing to talk about, besides kept being busy with other
courses like HWs and projects, etc. (You get the point. Well, if you are
a student) 

I decided to go on the Syllabus to look at the course topics.

I found the subject of Modeling along with Unified Modeling Language (UML) & C4 Model.

Unified Modeling Language

Large
Companies’ applications that execute core business applications and
keep a company going can more than some code modules. It can structure
in a way that enables:

  • scalability
  • security 
  • robust execution under stressful conditions. 


Their structure is that maintenance programmers can find and fix a bug
that shows up after moving on to other projects. These programs can
design to work perfectly in many areas, and business functionality is
not the only one. A well-designed architecture benefits any program, and
not only the largest ones as singled out. It mentioned large
applications first because the structure deals with complexity, so the
benefits of the network compound as the application size grows large. 


Another use of a structure that enables code reuse was design time.
Ultimately, companies build up models of parts, each unit representing
an implementation stored in code modules. At coding time, the developer
can as promptly import the code module into the application. When
another application needs the same functionality, the designer can
quickly import its module from the library.

The C4 model

The
C4 model made by Simon Brown designates on UML and the 4+1
architectural view model. It breaks down software into smaller units for
modeling. Like the quick methodology, the C4 model requires fast,
efficient sharing and constant updates of software architecture in
software development.

The
C4 model (shown as a map). The Maps can build on a different scale. By
changing scales, like for example; The town map with streets and
buildings. Having the C4 model changes the level of a diagram to
describe software architecture. Using the abstraction-first approach, C4
conducts modeling top-down from system context to lower levels.

  • Person (Element) – users or roles of a software system
  • Software
    system (topmost level in abstractions) – the value of existing systems
    or systems under development and the interaction between those systems
  • Container
    (Element) – the internals of software systems, usually applications or
    solutions for data storage. A different concept to containers in Docker.
    It mainly refers to software that is single deployed.
  • Component (Abstraction element) – The containers of modules or a set of interfaces grouped as a functional unit.
  • Relations – dependencies or data flow between abstraction elements.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Week-11

 

Hello
blog (mood-status: feeling Good), writing this blog after thanksgiving
dinner and eating well like pretty good with a plate of food alongside
hanging the family. But anyway, on writing about this week-11. To be
truthful here, I writing this because I am falling behind on blogs when
there is nothing to talk about, besides kept being busy with other
courses like HWs and projects, etc. (You get the point. Well, if you are
a student) 

I decided to go on the Syllabus to look at the course topics.

I found the subject of Modeling along with Unified Modeling Language (UML) & C4 Model.

Unified Modeling Language

Large
Companies’ applications that execute core business applications and
keep a company going can more than some code modules. It can structure
in a way that enables:

  • scalability
  • security 
  • robust execution under stressful conditions. 


Their structure is that maintenance programmers can find and fix a bug
that shows up after moving on to other projects. These programs can
design to work perfectly in many areas, and business functionality is
not the only one. A well-designed architecture benefits any program, and
not only the largest ones as singled out. It mentioned large
applications first because the structure deals with complexity, so the
benefits of the network compound as the application size grows large. 


Another use of a structure that enables code reuse was design time.
Ultimately, companies build up models of parts, each unit representing
an implementation stored in code modules. At coding time, the developer
can as promptly import the code module into the application. When
another application needs the same functionality, the designer can
quickly import its module from the library.

The C4 model

The
C4 model made by Simon Brown designates on UML and the 4+1
architectural view model. It breaks down software into smaller units for
modeling. Like the quick methodology, the C4 model requires fast,
efficient sharing and constant updates of software architecture in
software development.

The
C4 model (shown as a map). The Maps can build on a different scale. By
changing scales, like for example; The town map with streets and
buildings. Having the C4 model changes the level of a diagram to
describe software architecture. Using the abstraction-first approach, C4
conducts modeling top-down from system context to lower levels.

  • Person (Element) – users or roles of a software system
  • Software
    system (topmost level in abstractions) – the value of existing systems
    or systems under development and the interaction between those systems
  • Container
    (Element) – the internals of software systems, usually applications or
    solutions for data storage. A different concept to containers in Docker.
    It mainly refers to software that is single deployed.
  • Component (Abstraction element) – The containers of modules or a set of interfaces grouped as a functional unit.
  • Relations – dependencies or data flow between abstraction elements.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Week-11

 

Hello
blog (mood-status: feeling Good), writing this blog after thanksgiving
dinner and eating well like pretty good with a plate of food alongside
hanging the family. But anyway, on writing about this week-11. To be
truthful here, I writing this because I am falling behind on blogs when
there is nothing to talk about, besides kept being busy with other
courses like HWs and projects, etc. (You get the point. Well, if you are
a student) 

I decided to go on the Syllabus to look at the course topics.

I found the subject of Modeling along with Unified Modeling Language (UML) & C4 Model.

Unified Modeling Language

Large
Companies’ applications that execute core business applications and
keep a company going can more than some code modules. It can structure
in a way that enables:

  • scalability
  • security 
  • robust execution under stressful conditions. 


Their structure is that maintenance programmers can find and fix a bug
that shows up after moving on to other projects. These programs can
design to work perfectly in many areas, and business functionality is
not the only one. A well-designed architecture benefits any program, and
not only the largest ones as singled out. It mentioned large
applications first because the structure deals with complexity, so the
benefits of the network compound as the application size grows large. 


Another use of a structure that enables code reuse was design time.
Ultimately, companies build up models of parts, each unit representing
an implementation stored in code modules. At coding time, the developer
can as promptly import the code module into the application. When
another application needs the same functionality, the designer can
quickly import its module from the library.

The C4 model

The
C4 model made by Simon Brown designates on UML and the 4+1
architectural view model. It breaks down software into smaller units for
modeling. Like the quick methodology, the C4 model requires fast,
efficient sharing and constant updates of software architecture in
software development.

The
C4 model (shown as a map). The Maps can build on a different scale. By
changing scales, like for example; The town map with streets and
buildings. Having the C4 model changes the level of a diagram to
describe software architecture. Using the abstraction-first approach, C4
conducts modeling top-down from system context to lower levels.

  • Person (Element) – users or roles of a software system
  • Software
    system (topmost level in abstractions) – the value of existing systems
    or systems under development and the interaction between those systems
  • Container
    (Element) – the internals of software systems, usually applications or
    solutions for data storage. A different concept to containers in Docker.
    It mainly refers to software that is single deployed.
  • Component (Abstraction element) – The containers of modules or a set of interfaces grouped as a functional unit.
  • Relations – dependencies or data flow between abstraction elements.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.