Category Archives: Week 3

CSS Grid: A Better Layout System

Whenever I find myself working on a website, one of the more time-consuming aspects of development is often the CSS (cascading style sheet) code which controls the layout of the site. While CSS properties often have names which are self-explanatory the various formatting tools in CSS can oftentimes be confusing to me.

In the past, using the float property and various div classes to control different sections of the website was my go-to when building webpages for practice. This has since been proceeded by a number of new layout systems now baked into CSS functionalities as more recent versions of CSS have worked to better support modern web-development concepts. As I am looking to improve and modernize my web-development skills to prepare for contract work in the future, it was important that I start looking into the newer layout systems provided by CSS.

The newest layout system introduced by CSS, CSS Grid, is a fairly recent invention. I was looking for a good reference to introduce me to the idea, and I found a great resource on the website css-tricks.com (https://css-tricks.com/snippets/css/complete-guide-grid/), which focuses on providing relevant information regarding various CSS standards and techniques. The article provides a complete introduction to the idea of Grid, starting with it’s various properties (display: grid to begin using the layout, various grid-template properties and grid-column/grid-row to control the particular layout of content) and moving further to discuss more specific techniques associated with Grid. I felt that the information about defining gutters (spaces between grid items) was extremely helpful, as gutters vs. borders in web design has been a hard topic for me to wrap my head around for a while, and this page put it into a really easily-understandable format in my opinion.

CSS grid is absolutely what I would use for a modern website design if I were making a site for someone in 2020. Although there exist frameworks such as Bootstrap and Skeleton, a lot of the inner-workings of the page and its layout can be obstructed in a way, and I feel like Grid makes it easy enough to make a great layout without relying on an external framework. Keeping things simple in web-design has always made for a more manageable website in my experience. I would certainly recommend this article to anyone looking to explore CSS Grid as a layout option for a website, the plentiful examples and images make concepts easy to visualize, and the explanations provide a good level of information without seeming overwhelming to someone unfamiliar with the topic.

With CSS grid, I think web-development (in terms of front-end) has become much more accessible, and building a functional and aesthetically pleasing website has become far easier than in the past when reliance on outdated layout formats made things a lot more difficult.

Site Referenced: CSS-Tricks.com

Great resource for learning more about CSS grid!

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

S.O.L.I.D Principles

 This week on my CS Journey, I want to talk about the SOLID design principles. I am sure that you have heard the term many times, however, let us look at the principles in detail. The reason I picked this topic is as a Computer science major student we write many programs and having a strong principle will enable us to write effective object-oriented code. 

To start of SOLID is an acronym where each letter represents a software design principle. 

S – for Single Responsibility Principle

O – for Open/Closed Principle

L – for Liskov Substitution Principle

I – for Interface Segregation Principle

D – for Dependency Inversion Principle

 

Each principle overlaps here and there. The Single Responsibility Principle states that in a well-designed application, each class should have only one single responsibility. essentially meaning a class should only have one job. I think this is a very good concept to use because when you are working with complex programs and the class has more than one responsibility it will become a nightmare. The open-closed principle states that classes should be open for extension but closed for modification. For example, I learned that if you want to add a new feature to your program you should do it by extending it rather than modifying it which minimizes the risk of failures. Next, the Liskov Substitution Principle which explains that an object of a superclass can be replaced with objects of its subclasses without causing problems to the application. This means that a child class should never change the characteristics of its parent class.

 

The  Interface Segregation Principle is the fourth SOLID design principle that states no clients should not be forced to depend on methods they don’t use.  In other words, interfaces shouldn’t include too many functionalities since the interfaces are difficult to maintain and change over time, so it is best to avoid. Lastly, the Dependency Inversion Principle states that the High-level modules or classes should not depend on low-level modules/classes and both should depend upon abstractions because a change in one class can break another class which is very risky.

 

Overall, the blog I read talked about each principle in detail using various examples such as UML diagrams, Java programs, and other diagrams that helped me to understand each concept. I learned a lot from the blog, and I think that these concepts are all key to writing a good solid code. In the future, I will be using the principles to write effective object-oriented code. 

 

 

Here is the blog I Used:

https://raygun.com/blog/solid-design-principles/

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

Design Patterns

This week I would like to talk about the design patterns. I would like to give a little intro to design pattern. As you have probably experienced by now, writing correct computer programs can sometimes be quite a challenge. Design patterns are not language specific either. Good design patterns are implementable in most programming languages, depending on the capabilities of the language of course. They also speed up the development process by providing tested and proven development paradigms.

Effective software design requires considering issues that may not become visible until later in the implementation process. Reusing design patterns helps to prevent subtle issues that can cause major problems later. It also improves code readability for programmers and architects familiar with the patterns. In addition, patterns allow developers to communicate using well-known, well understood names for software interactions.

Correctly using a design pattern is very important. Implement it in the wrong way and it can create more problems than it solves.

In my CS-343 class we worked a little with design patterns and how they work. It is uncommon to introduce design patterns and not explain who the Gang of Four are. The Gang of Four are the authors of the book, “Design Patterns: Elements of Reusable Object-Oriented Software”: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The Gang of four design patterns are divided into 3 fundamental groups:

Creational Patterns provide ways to instantiate single objects or groups of related objects.

Structural Patterns provide a manner to define relationships between classes or objects.

Behavioral Patterns define manners of communication between classes and objects.

My favorite book about design principles is “Head First Design Patterns” by Kathy Sierra; Elisabeth Robson; Bert Bates; Eric Freeman. It is one the best for the introduction to this topic. I suggest the first chapter which gives you an understanding of the design patterns. In this chapter, you will learn why (and how) you can exploit the wisdom and lessons learned by other developers who have been down the same design problem road and survived the trip. Before we are done, we will look at the use and benefits of design patterns, look at some key OO design principles, and walk through an example of how one pattern works. The best way to use patterns is to load your brain with them and then recognize places in your designs and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

SOLID Design Principles

Hello everyone and welcome back.

 This week I will be exploring three of the five design principles of OOP; Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov’ Substituion Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP).

My first introduction to these principles was in reading “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin. Prior to learning these concepts, my code was messy and not easily modified. I used to put way too many methods in classes, and my child classes were not fully compatible with the parent classes. I chose this topic because we all benefit when our code is adaptable, clear-cut and easy to maintain. I chose this blog because the author presents the information in a very direct format with great examples.

The purpose of these design principles is to make our code easier to maintain, change and understand. As software engineers, a lot of the code most of us will be working on will be code that others have written. There will be others who will be maintaining our code when we are no longer working on it. When we follow these design principles, not only do we improve our coding skills, but we help those who maintain the code we have written.

Single Responsibility Principle (SRP) means that a class should have only one purpose/task that it is responsible for. This makes code more maintainable by making software more comprehensible for future changes to be made. If a single class has multiple responsibilities, editing in the future will be more complicated because we will have to make additional changes to the classes that are dependent on it. You will have to update and recompile dependent classes that are not directly related to the change you needed to make.

Open-Closed Principle (OCP) means functions, classes and modules should be written such that others can add to them but not change the core elements. When we use this principle our code, our software will give less errors when requirements change. This makes our code more robust and reusable.

Liskov’s Substitution Principle states that every dependent class should be substitutable for their parent class without breaking functionality. Our validation rules on input parameters in subclasses should not be stricter than the input parameters on the parent. Using this principle increases maintainability of our software by making our class hierarchies easier to understand.

Through utilizing these design principles, I will be a better software engineer. I am more aware of ways to improve the legibility, and modifiability of my code. These design principles will help me stay away from poor coding practice.

Blog of Inspiration:

https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea#.xq7a6fvtk

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

Don’t Repeat Yourself

For this week’s post in the coding journey blog, we are going to talk about a principle in software coding knows as dry. I chose this topic for this specific week because it felt relevant to the classwork we did this past week with super classes, abstract classes and interfaces.

What dry means is don’t repeat yourself and this concept is very important for developing software. The actual principle is represented as “Every piece of knowledge or logic must have a single, unambiguous representation within a system.” Now take for example the classwork we were doing, and how there was a method in the superclass that we decided all the subclasses would also include through inheritance. Now in the subclasses, if we wanted that method to do a different version of the method such as fly or quack, then we would have to alter each and every subclass. Even if a subclass does not have the fly or quack method, we would have to add the method and have the code do nothing. Just by talking about this you can see how redundant this starts to become. Now you may be able to get by with this repetition if you’re working on a small project and don’t have much to check for. However, when it comes to larger projects this will certainly turn into a never ending nightmare. Your code breaks and you have to go through all this different code which is similar and figure out what is off. This just seems like a waste of time and effort. This is why the common notion is to use the principle of don’t repeat yourself which has the goal of reducing repetition of the same software over and over again.

The big problem with repeated code over time is that it will become very hard to maintain. If over time, there comes a big change to the code and the logic changes, then it will become a headache. All the places where the previous logic was used, needs to be altered and the big thing that will be wasted is time. If you want to create quality code, then you will also have to use quality time. It is thereby better from the get go to design code to not repeat the same unnecessary methods and logic in multiple places.

To put this into perspective on a personal level, in the past I most certainly used repetitive code and wasted a lot of time. It may have seemed like the easier option sometimes, but as I dove deeper into my projects it became more difficult to figure out the solution for bugs and tracing the code for error. In the future, I know it is the best option to optimize the best way for the code to work without repetition in order to help myself and others down the line.

To read up on more sources, check out these links here: https://medium.com/code-thoughts/dont-repeat-yourself-caa413910753

https://dzone.com/articles/software-design-principles-dry-and-kiss#:~:text=DRY%20stand%20for%20%22Don’t,unambiguous%20representation%20within%20a%20system.%22

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

CODE SMELLS

After the class activity on smells, I was interested in knowing more about it and how it relates to programming. The term was quite interesting, so I chose this topic because I wanted to know more. After several searches, I finally settled on this blog that talks about code smells and makes it easy to understand.

In this blog, I like the fact that it relates code smells to the everyday smell that we know, typically body odor. Initially I was thinking of code smell as a bug but this blog made it clear that it isn’t a bug. Blog talks about the downside of having code smells which are causing technical debt and affecting the maintainability of software system. It also gives some links to some series that explains more about code smells, giving examples, code snippets and how to identify and solve smells in a code. It talks about various code smells which are Method-level, Class-level and General-level code smells. Each type of code smells mentioned explains and give an overview/points on what to look out for in codes/programs to identify a specific kind of code smell. This blog also talks about some stereotypes of code smells that I found interesting and relevant.  

In this blog, I learned that code smell is a piece of code that we perceive as incorrect but do not fix right away. That being said, code smells in software programs will produce output but may affect the quality of the program if not taken care of.

In method-level code smell, I learned that there are certain things that one must check in methods to identify smells. These include the method not being used, taking too many parameters, doing too many or little things, having too many branches or loops. I always thought that methods can have as much parameters as it can but little did I know that too many parameters in a method could affect a software system and needs to be corrected. In the future I will not include methods that I do not use in my program.

I learned in Class-level code smells that the name of a class and programming interface should reflect its purpose. Also, when a class does too much or too little work, class unnecessarily exposes its internal details, inherits a base class but only some of its inherited behavior is needed, design of a class is overly complex are indications of code smells.

As I was reading through the series in this blog, I found very educative term which is factory method. I learned that factory method is a method, typically static, that returns an instance of a class and uses a constructor publicly or private. When too much work is required to get new instances when using constructors, it is always encouraged to resort to factory methods, although there are other cases where one could use factory methods.

I hope this blog is helpful to others as well.

https://blog.jetbrains.com/dotnet/2018/06/18/sharpen-sense-code-smell/

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

Expose Your Ignorance

Just like the title says this week I have read the pattern “Expose Your Ignorance” from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This pattern describes how any aspiring developer should put aside their ego and be able to tell other about not knowing something and ask questions. It is about being able to admit that we do not know something and to start learning even if it means showing others your “ignorance”.

As always with this book and its chapters this hits close to home when it come to me and my work experience, as well as school in that matter. I found it interesting because it really shows me that it is not only me who can struggle with this particular pattern. My boss always tells me and my teammates during any meeting or code review: “you owe me at least two questions”, and this is the part that is described well in this chapter as well. The author says: “The most obvious way to expose your ignorance is to ask questions.”. I agree wholeheartedly with this statement, we have to be able to ask questions even if it shows our ignorance on the subject, but the sooner something like that is out there the sooner we can work and fixing the problem as well as better working with the team, since they will know that we might need some help.

The only part of this pattern that I do not agree with all the way is the same one I just mentioned. In my opinion there is a place and time to ask questions to expose one’s ignorance, but there are also times when holding them back until later is the right decision. One such time is when working directly with a customer, a particularly tough or difficult one. Or when having a meeting with a lot of higher ups at a company and your development team. Question on the subject are usually good but ignorant questions can have some unforeseen consequences in these situations. Overall, I agree with this pattern and the idea about having a list of things you do not understand and to update it periodically is in my opinion a very good idea.

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.

Apprenticeship Patterns: Be The Worst

“Be the lions tail rather than the foxs head!”

I enjoyed doing the reading. It is protrayed well enough to understand the basic concept of how ones should emerge in the field of computer science.


Three things that I caught attention towards were: learning new skills, taking risks and surronding yourself with people who knows more then you.

There is a say that, hustle like a broke and live like a master.
What I have reviewed is that thinking that you are the weakest member of the team will make you eager to learn and work hard. In order to be the best version of yourself, you have to take risks.
There is no easy way. That is where your patience is tested.
If you fail, you learn, if you didn’t you are always one step closer.

Looking at the Software development companies. They took risks, worked hard and learned from others. That is how they are able to stand out in the Tech world.
To be a good developer you have to collaborate with great developers. It is not their time need it’s the skills that you need to learn. Surrounding yourself and being among them will give you motivation and positive energy to grow into the Software Development field.

This strategy can be applied in any field. maintain and give you the motivation to grow and not give up.

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

Android Activities and Fragments: Getting Them Straight

AndroidX has brought a few changes to the Android framework, but the general architecture remains the same. Likewise, the few years since I’ve first learned Android has completely changed how I feel about Android. At this point, I am developing the basic architecture of my independent study app.

There are a lot of conflicting opinions about Activities and Fragments in the Android Developer community. A few years ago with my limited Android experience, I did not completely understand. I likely don’t completely understand now. However, I have better tools and more programming experience to see how they should be used, as well as to make my own decisions on how to use them.

At first, I found myself paralyzed with confusion on how Google wants its developers to use Activities and Fragments. As an example of how programming concepts translate well to other technologies, learning Angular helped me understand the difference. Activities are a single “thing” that a user does, and can be thought of as a web page. A Fragment should be used for a modular UI component, and function as Components do in Angular.

This isn’t a perfect analogy, as the frameworks are very different, but this is a good way to proceed when deciding how to structure your app. Google’s Introduction to App Architecture guide is a great explanation, and the most important thing to remember is to maintain a separation of concerns. In the end, Activities and Fragments aren’t a significant part of your app. They contain your app. They are something your app uses to work within the Android framework, and your business logic should be elsewhere because Android will pause or stop any Fragments or Activities it needs to if, for example, memory is running low. There is no guarantee they will maintain state unless you take additional steps to ensure it does so.

In researching opinions on how to use them, some people mentioned that they’ve seen developers decide on having a single Activity, and adding all features with Fragments. This is a tempting solution, but that might result in complex logic to control navigation. Furthermore, Fragments are meant to communicate through their parent Activity. In a large app, this would likely result in many implemented interfaces and complicated callbacks. Bloated Activities a big NO.

Likewise, others mentioned only using Activities and not adding complexity with Fragments. This seems a bit more reasonable, but restricts reusability of the Fragments in the UI. Only one Activity can run at a time. The beauty of Fragments is they can easily be dropped into a layout and reused. If they are designed to interact through their parent Activity, two Fragments can be shown at the same time on a larger tablet, even if they must be shown on different screens on a phone. Creating Activities only would mean either creating new Activities with repeated code for a tablet, or reusing the phone UI at the expense of user experience.

I’ll reiterate: separation of concerns. In Android, or any framework, understand the philosophy behind a class and component before deciding to try to simplify things. It’s likely that they were designed to prevent the problems you will run into.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Concrete Skills

I have furthered my reading in Chapter 2 of the Apprenticeship Patterns this time about Concrete Skills. With all the romanticism of being an Apprentice and obtaining the ability to learn quickly this chapter really tells the other side of that. It does pay to bring a level of enthusiasm for learning to a team but in order to be hired on a team you need a point of persuasion. This is when concrete skills come into play. Examples described in this chapter are things like a basic knowledge of various industry popular languages, frameworks, and a well developed understanding of your native language. Having these basic, or concrete skills, allow you to show some sort of way that you can benefit a team indirectly with basic tasks before you learn how to directly help.

This chapter addresses something I often think about. Some questions that run through my head, “What are the basic skills I need for getting my first job?”, “Am I expected to know what they are developing and how to contribute, or will they teach me?”. The truth is you can’t know about a development project before you are part of it. How things are done and what the scope is, will have to be learned as you go. Then my first question of what it is I need to know beforehand becomes more clear. My concrete skills need to be further developed, I need to explore more now at this stage in my career. 

I often feel the pull to my familiar skills when presented with a project. I need to use Java because that’s what I know, I need to use this IDE, I need to use this Database. However, it’s interesting as I read this book I see my development toward these goals presented in each chapter. The reading helps solidify my exploration into the unknown. The start of this semester I thought I would only use my most used IDE and the database I was used to using. As the semester got going I began to use a new IDE that seemed to better fit my interests after I took the step to get familiar with it. I also took the chance to learn about a new database application that better fit the needs of the project rather than catering to my familiarity. My next goal is to learn a basic understanding of a few more popular languages.

Developing these concrete skills is just as important as unleashing your enthusiasm for learning. Both are beneficial for a team but concrete skills will give you a practical use upon hiring.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.