Category Archives: CS343

Let’s talk about adapters

This week I will be touching base on a structural design pattern called the adapter pattern. This pattern has two different versions, the class adapter – which implements the adapter using inheritance and can only be used in C++, and the object adapter – which uses composition to reference an instance of the wrapped class within the adapter. For the purpose of this blog post, I will be speaking only of the object adapter pattern.

Structural design patters are supposed to simplify your design, the adapter pattern in particular makes doing so easy as pie. The adapter pattern reuses old interfaces and provides different interfaces to its subject in order to make things work after they’ve been designed, even if the previous interfaces were incompatible. So what can this pattern do? Let’s break it down a bit:

– Change the interface of an existing object.
– Provide a different interface to its subject.
– Make things work after they’ve been designed.
– Reuse old interfaces.

The adapter pattern addresses incompatible interfaces and lets classes work together that previously could not due to incompatibility by converting the interface of a class into another interface that the clients expect. This conversion process allows software to exchange and make use of information. When you are dealing with different interfaces with similar behaviors, it is best to use this design pattern to help develop a clearer, more easily understandable code. A brief list of some of the benefits of using adapter patterns are:

– It is a low-cost solution.
– It is easy to understand.
– Incompatible code can communicate with each other.
– It makes things work after they’re designed.
– Helps to reuse existing code.

Information gathered for this blog post:
https://stacktraceguru.com/adapter-design-pattern
https://www.geeksforgeeks.org/adapter-pattern/
https://www.java2novice.com/java-design-patterns/adapter-pattern/
https://sourcemaking.com/design_patterns/adapter

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Facade Design Pattern

This week on my CS Journey, I want to talk about the design patterns, Especially the Facade design pattern. In class, we also learned about other designs which are helpful. However, I wanted to focus on the Facade design pattern. To start of Facade is a structural design pattern that adds an interface to an existing system to hide its complexities. In other words, it provides a simple interface that can be used to manipulate more complex logic behind the scenes, that are hidden from the main user. According to the Gang of Four, the Facade pattern intends to “Provide a unified interface to a set of interfaces in a subsystem” From the blog I used it provided a diagram that I think is helpful to understand the design pattern. In the diagram, we can see that Facade is acting as an interface for the complex Subsystems that are hidden from the main clients. 



Now let’s take a look at a real-life example. A good example that I found was When a computer starts up, it involves the work of CPU, memory, hard drive, and other subsystems. To make it easy to use for users we can add a Facade that wraps the complexity of the task and provide one simple interface instead. This applies to the Facade design pattern because it hides the complexities of the system and provides an easy interface to the users. 

 

One of the liabilities is that a Facade might provide limited functionality in comparison to working with the subsystem directly. Does not prevent applications from using subsystems classes if they need to. Also, it can increase the number of wrapper classes. Another liability is that Facade can perform way too many tasks. One of the benefits is that it reduces compilation dependencies is vital in large software systems. Overall, The Facade design pattern is helpful when dealing with the complex system because It enables us to use the complex system much more easily.

 

There are a lot of examples, diagrams, and Java Codes, readings and a link to a GitHub resource that are provided in the blog I used. I would suggest you to take a look at the website because it goes into further detail about the facade design pattern, including various examples using diagrams and also this reference contains a lot of information that is broken down into easy steps which are user friendly.

 

Source : https://www.baeldung.com/java-facade-pattern

















From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

YAGNI

Welcome back!

This week in Coding Kitchen, we explore one of the key principles of Extreme Programming, YAGNI (You Ain’t Gonna Need It). This principle states that some capability we think our software will need in the future should not be built now because “you aren’t gonna need it“, or as XP co-founder Ron Jeffries put it, “Always implement things when you actually need them, never when you just foresee that you need them.”

The YAGNI principle is to be used in conjunction with other practices, such as continuous integration, continuous refactoring and continuous automated unit testing. Without the additional use of any of these other practices, your code could go into Technical Debt, which means it could become disorganized and need to be reworked. Using the YAGNI principle saves you time by helping you to avoid writing code that you do not end up needing and by making your code better because you did not have to fill it with guesses that turned out to be wrong.

In an article posted by Martin Fowler, he uses an example about selling insurance for the shipping business. His example states that an insurance company’s software system is broken into two components, pricing and sales and that the dependencies cannot usefully build sales software until the relevant pricing software is completed. His example also states that while the company works on updating the pricing component to add support for risks from storms, they consider working on a feature they will not need for another six months for piracy pricing. By adding on this additional feature now, Fowler declares that doing so would incur three classes of presumptive features, and four kinds of costs that occur by neglecting YAGNI for them.

1) Wrong feature — Cost of building, cost of carry + cost of delay
2) Right feature, built wrong — Cost of repair, cost of carry + cost of delay
3) Right feature, built right — Cost of carry + cost of delay

I chose this article because this particular example given by Fowler highlights the benefits of using YAGNI and why neglecting to do so would inherently cause many issues and become costly. As a future software engineer, I would prefer having to write less code that is easier to understand rather than have lines of useless, possibly obsolete code. I found Fowlers explanation of YAGNI and his further explanation of the many ways applying this principle could cause problems in comparison to the very few ways it could be of benefit easy to understand and useful. Having knowledge of this principle as a programmer will make writing and editing code in my future professional endeavors much more time and cost effective.

Inspiration and information gathered for this blog post :

https://dzone.com/articles/martin-fowlerbliki-yagni-youre-not-gonna-need-it

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Introduction

Hello, my name is John Simolaris and I’m currently a student at Worcester State University. Throughout my blog I will share various tools, tips and information I gain along the way to becoming a Software Engineer. In my personal life, I enjoy fixing up old power wheels, strength training, and researching various topics such as neurochemistry, philosphy, poetry, art, pure mathematics, childhood development, etc. Professionally, I am interested in learning software design and penetration testing. From now until the end of 2020, I will be posting about my findings in:

  • Design Principles
    • Object Oriented Programming
      • Abstraction
      • Encapsulation
      • Polymorphism
      • Inheritance
  • SOLID
    • Single Responsibility Principle (SRP)
    • Open-Closed Principle (OCP)
    • Liskov Substitution Principle (LSP)
    • Interface Segregation Principle (ISP)
    • Dependency Inversion Principle (DIP)
  • DRY (Don’t Repeat Yourself)
  • YAGNI (You Ain’t Gonna Need It)
  • GRASP (General Responsibility Assignment Software Patterns)
    • Controller
    • Creator
    • High Cohesion
    • Indirection
    • Information Expert
    • Low Coupling
    • Polymorphism
    • Protected Variations
    • Pure Fabrication
  • “Encapsulate what varies.”
  • “Program to an interface, not an implementation.”
  • “Favor composition over inheritance.”
  • “Strive for loosely coupled designs between objects that interact”
  • Principle of Least Knowledge (AKA Law of Demeter)
  • Inversion of Control
  • Design Patterns
    • Creational
    • Structural
    • Behavioral
    • Concurrency
  • Refactoring
  • Smells
    • Code Smells
    • Design Smells
  • Software Architectures
    • Architectural Patterns
    • Architectural Styles
  • REST API Design
  • Software Frameworks
  • Documentation
  • Modeling
    • Unified Modeling Language (UML)
    • C4 Model
  • Anti-Patterns
  • Implementation of Web Systems
    • Front end
    • Back end
    • Data persistence layer

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Progress and Pain

I have not been able to dedicate as much time as I would like to this angular web app project, and I have a lot to learn. I was also not able to incorporate the google sheets api to do the things I really wanted to do. However, what I have done I’ve found engaging and interesting.

I made the decision to simulate a data server in angular. This made data manipulation fairly easy. It took the stress off of figuring out the back-end and allowed me to focus on the other aspects of angular: the structure, services / components, and HTML / CSS. Utilizing several tutorials and guides, I am fairly confident now in creating buttons and forms that accept user input and pass that input into a list. The list is clickable and displays details. It also routes to another page complete with its own URL.

I learned a lot about ngif and ngfor, which work in a pretty familiar fashion. I also learned about the “Slice” function, where you can iterate through a specific part of an array. I am hoping to add a function that will display my win / loss record, which can be done by just adding the values in the “Win” portion of the data, as it is represented by a 1. This is a work in progress but I think it will be doable.

I still think Tour of Heroes should be included in this class. It was such an eye-opening tutorial, and really let me dig deep into learning about services, components, routing, HTML, CSS, and more. While it’s a long tutorial, I think it would be better than Activity 12 for a teaching tool.

From the blog CS@Worcester – Alan Birdgulch's Blog by cjsteinbrecher and used with permission of the author. All other rights reserved by the author.

The end of a struggle…

The final week of the final project was a lot of fun and headache at the same time. My senioritis only got worse over last few days and my motivation to do any kind of schoolwork is at a lowest it ever been this semester. I have forced myself to do work and the project is pretty much done. Me and my group member still need to meet one final time to put finishing touches on everything and create a presentation, but I am not too worried about that.

The challenge this week was the backend code, to be more specific making it add new entries to the database we were using. The REST API we are asking to add things was having some problems with connecting to the database at first, connecting might be a wrong word to use here, the database was refusing the instruction and saying it is a read-only database. After some googling we have found the solution, the file with the database was in the wrong directory on the C:/ drive. It was somewhere where special permissions are required to modify it, making it read-only automatically. Solution: copy the file, move it to some new directory, adjust your connection path in the backend code. (thank you Stack Overflow).

The second challenge for this week came from the fact that me and my group member worked somewhat in parallel on our project(s) due to the conflicts in our schedules. Because of it we somewhat ended with two similar yet a little different project and the fun, and also a hard part, was to merge them into one working whole. We had a little bit different philosophy on how a certain aspects of the project should be done and making it all work together was challenging to say the least. Again, some quick google searches helped us tremendously and in my opinion the overall code should give us a good grade.

This project was a lot of fun and a lot oh headaches, but that is the way of software development, the end result might not always be a satisfying outcome but it is the journey that get us there that helps us learn and grow in this field. I came to a realization that I do not like working with databases or SQL, it seems a little to convoluted in my opinion and every little mistake might be a fatal one for a database. I will definitely stick to more modern programming languages and to working in the software development field.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Project, part 2…

Project for my databases and software architecture has been going well so far. But lately my luck has run out. In my last post about this project I have outlined the steps me and my group member took to design our website as well as make sure the back end of it is working correctly. That part won’t be a problem anymore in my opinion. All that is left in the backend is to make some extra triggers in the database and confirm that all the information is being passed correctly. Like I said I do not foresee any problem with that part.

The fun part or the rabbit hole as I like to call it is now implementing correctly the front end. I have a lot of knowledge base available, but the problem comes in the fact that I want to make certain things work the way I want them to and that might not be how they actually work. To begin with I have started with reading the Angular tutorials (everything can be found here) and trying to figure out how to do some simple programs and designs. Me and my group partner have been working somewhat separately at this point because of our conflicting schedules but we have a working version that, if we run out of time, will use. For me the biggest problem at this point is to have the layout working correctly, all the functions and their behavior are not a problem, but to have the components line up where I need them to be causes me no small amount of headache.

While trying to make this project look nicer on my own, I have met with my partner at a café so we could finally work together and try to figure out some of the problems we were having. One such problem turns out to be a database trigger, we need at least one to have somewhat good database design. The trigger, when we finally learned how to create one, is a simple one that assigns 0 to a column value for a new row in a table. It is nothing spectacular or advanced, but it works and to be honest this is for an introduction database class so in my opinion we do not need anything fancy. (again here is a tutorial for triggers).

As the school year approaches rather fast, I will be spending most of my days on the near future either on this project or on studying for final exams. I cannot wait to be finally done with this semester, as much as I have had fun and learned a lot, I’m starting to suffer from senioritis and my motivation wanes.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Projects, projects, projects…

Working on the Final Project for the Software Architecture class has been fun so far. During this initial week we had to figure out what are we going to do. I have paired with one of my classmates named Zac to work together. All we knew that the project was supposed to be done with the TypeScript and Angular framework. Well then what to do? We had no idea, at least at first, until we got the Databases class where again I have paired with Zac and we were supposed to do a project with databases and some SQL. That is where it hit us: “how about we combine both projects?”, what we meant is using Angular we can create a website that will connect and interact with a database through a REST API we learned about before. Genius I say, only problem was to figure out if that will be allowed, killing two birds with one stone, and guess what, it was ok.

So, with that in mind we went to work. First step was to figure
out what database do we want to use, since that will decide on what shape rest
of the project will take. That is where Zac came in, he is a very talented
musician and he quickly found a free database online that relates to music, it
had quite a few entries, but not too many so it will be fine working with it.

Great, a third the setup is done, step two create a
Wireframe and write a proposal for both classes. Huh, a what? Well apparently,
wireframe is a visual/conceptual design for a web app. Here is some
explanation. That helped us so we went to work. I tell you what trying to
design how a website will look is not that easy, me and Zac had to discuss few
things before we settled on something. Version one is not very impressive and
will most likely change but good enough for now. With it we had the conceptual
work done.

Now all that is left is to make it a reality. Well easier
said than done but that is why we are in school, to learn those kinds of things.
We have started with the basics; can we use Java to talk to a Database? Luckily
in that regard professor from Databases class helped. (here is the
article about it) Ok so we can talk, let’s see if me and my teammate can do
some simple queries with the REST API. YES, WE CAN! Ok we are in business. More
fun will come next, use what we receive from the database and make it work with
Angular, but I will talk about that later…….

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Final Project Update: Taking a different shape than planned

The final project for this class is taking on a different form than I initially planned. I had planned to use google sheets API in my project, and while I am not ruling out that possibility, I am running into some roadblocks. The API seems to require authentication that I can’t get to work quite right. I may end up using a different solution for a backend, but we will see.

I am also thinking that my front-end will end up looking not much like my wireframe. At this point I’m not sure I care. Figuring out HTML and CSS implementations for something that I’ve had no experience in for this project is very difficult, and I think I (like most people), will end up modeling my project off of something that already exists. As I posted last week, Tour of Heroes is a very appealing course and I am learning a lot by deep-diving into it. I would highly suggest implementing that into the course. It utilizes a lot of concepts that are useful in angular and in the project: buttons, pages, loops, and CSS stylings, and more.

The other roadblock I am running into is that the work this semester sure has been back-loaded. 5 classes, 3 projects and 4 exams to prepare for is a tough ask. As an adult student with a job and a mortgage, it sure gets stressful. I will definitely not pretend to be the most overworked student ever, and people have definitely overcome tougher obstacles. Yet even still, my despair is immeasurable.

From the blog CS@Worcester – Alan Birdgulch's Blog by cjsteinbrecher and used with permission of the author. All other rights reserved by the author.

Front End Decisions…Back End Decisions…Decisions.

Activity 12 was a good activity to start learning about Angular front-end development, especially with making REST API calls. However, lack of a strong HTML / CSS background may leave some people a bit behind when trying to build something a little more robust. The Tour of Heroes angular tutorial can be pretty useful for a really comprehensive, step by step guide on building a working front-end of a particular style. This could be useful with our upcoming final project to design a single-page web app. I think my plan, for now, will be to start simple, and build on the project as I have more time. I would be interested in eventually implementing the sort of “Second page” that Tour of Heroes has.

For front-end ideas, I did download Professor Wurst’s STEM-TV project and run it. While I appreciated the lecture he gave on the app, I do feel a POGIL style exercise may be beneficial for future classes to really get into the meat of it.

The back-end for my project has been something I’m wracking my brain over. I would like to try to utilize some of google sheets’ REST API features if possible. I am going to experiment with that line of thinking and see where it takes me. I have data that I have actually built myself based on games of Rocket League. I don’t think the data is particularly interesting, but it’s personal and fun.

From the blog CS@Worcester – Alan Birdgulch's Blog by cjsteinbrecher and used with permission of the author. All other rights reserved by the author.