Category Archives: Week 10

Apprenticeship Patterns: Motivation

For this first blog post I chose a pattern that focuses on something I have struggled with on and off almost every semester, this being motivation. I am usually very gung-ho when beginning any sort of programming class, or personal project, but eventually I find that I just get completely buried. This can be for a variety of reasons, being other schoolwork or simply getting lost trying to solve increasingly more complex issues, but it happens consistently enough to be concerning. After reading this however, I do have some ideas for ways to try and cope with this should, or more accurately when, I get stuck in this rut once again.

Personally, I found this pattern to be very helpful, as it resonated quite well with me. I have been getting frustrated with a lot of my recent work, as it is all in relatively new languages I only have a vague grasp on, but I now realize what these are. As stated in the pattern, you have to set aside what you are comfortable with in order to grow, and these states of remaining in your comfort zone are classified as Golden Locks. I just have to understand that a part of the journey to becoming a master in this craft is resisting the urge to remain where I am, in terms of my knowledge. Beyond this, all of the examples used in the pattern felt very relevant and did a sufficient job at helping me relate to what the author was trying to convey.

I would certainly like to say that this pattern will have some effect on the way I think about software engineering. I have realized and acknowledge my issue with my motivation, being that I am simply on the road to mastery and must keep in mind that everything I am struggling through is just a part of that process. I cannot just retreat back into only really caring about Java, I have to continue working with these new languages as I encounter opportunities to learn them, otherwise my career, and most likely my passion, will stagnate. Maybe this is due to a lack of experience, but I did not find myself disagreeing with anything said in this pattern really, it was a good read!

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch03s03.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

            In the “Sweep the Floor” learning pattern of the Apprenticeship Patterns book focuses on the transition when joining a team. Being the newbie is not an easy task, especially when unsure of your skills, so finding your place and claiming suitable work can be a struggle at times. Since I will hopefully be joining a software development team in the coming years, or even next year as an intern, getting accustomed to working on a team and proving my value while not finding myself in too deep on work that I am not ready for will be a somewhat tricky line to toe. This pattern focuses just on that.

            The idea of sweeping the floor, while not meant to be taken literally, can be a literal task. It means to take the tasks that need to be done but no one wants to do. This can either be menial tasks or simply tasks that are painfully boring or something. Although not attractive, this can be a way to start making progress on a team and pay your dues. It can help gain the trust of the team if the tasks are done well, oftentimes because they can be important sub-tasks which free up the way for higher-level developers to make more meaningful progress, so they’re still quite important.

            Having the humility to take on tasks like this is not something I’m worried about; I do not come into the field with a large ego. I knew nothing about computer science before I started my major. I’m not afraid of having to build from the ground up. I’m actually quite eager to. Others’ evaluation of my work will be the most valuable to me, a concept which is alluded to in many other learning patterns within the book. I think this is a great idea and helps carve out a position on a team which can only stand to grow.

            It’s also important to consider the downsides that the pattern mentions as well. Becoming the one that other developers dump the meaningless/annoying tasks on is clearly not the goal, so making sure to not get complacent and expressing an eagerness without overstepping bounds is essential. Nevertheless, I love this idea and plan on going through with it once I join a software development team.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

The Long Road

 When working on an open-source project, get in the habit of downloading the latest version of the code (preferably from their source control system) so you can review its history and track future developments. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. Not only will it give you a better understanding of the projects; Also make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for the Git distributed source control system written by Linus Torvalds, or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally make use of data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools your own. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something very important. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

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

What is Gradle?

Today I will be writing about Gradle and the article “What is Gradle?” on the Gradle, inc website. Gradle, as explained by the company, is a build automation tool that is open source. Gradle can build almost any type of software due to its flexibility. Gradle build scripts have three phases, initialization, configuration, and execution. First, it sets up the environment. Then it constructs a task DAG or Directed Acyclic Graph to decide which tasks need to be ran in which order then executes these tasks. Gradle runs on JVM and depends on the user to have JDK installed in order for it to be used. This is a plus for people have have used the Java platform because you can use standard Java APIs in the build logic. This article is everything you need to understand what Gradle is and how it works. It first gives an overview, split into a summary and five subheadings explaining more into depth on how it functions. After the overview it gives “Five things you need to know about Gradle” which discusses key factors that makes it different than other build automation tools. I selected this topic because we have been using Gradle in class, but I never fully understood its use and how it works. This article answered exactly that. The article is by Gradle inc, so there wont be a more accurate article on what it is and its functionalities. I personally found this article easy to read. As mentioned in my prior blog posts, I like when the reading is split up into subsections and headings. This makes it easier to keep track of what the article is talking about and keeps the information organized. There is not more than 4-5 sentences per subsection which keeps it to the point. Also, the diagrams provided do an excellent job on displaying what the subsection is trying to convey to the reader. For example, their diagram of the DAG that Gradle makes to determine the order of task to be completed is split into two parts. One shows an abstract model for a general view, then it gives an example for a standard java build. By giving the abstract and the practical example, it gives you two diagrams in which you can make a connection to better understand what they are trying to explain. Overall, I recommend this article. I had learned a lot about the tool and will be more confident using it in the future now that I understand its use and how it works.

Source: https://docs.gradle.org/current/userguide/what_is_gradle.html

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

The Single Responsibility Principle

One of the topics of this class that I don’t know much about is SOLID. Most of the programming I have done has been very small projects that do not necessitate the use of very many design principles. This is not to say they should be applied but they add quite a bit of extra work to something that doesn’t require very many lines otherwise.

Because of my lack of experience with it, I chose to learn a little more about SOLID starting with the “S” – Single Responsibility Principle. I found an article from stackify.com to explain it further.

The principle is self-explanatory. Uncle Bob describes it as “A class should have one, and only one, reason to change.” This is important because it makes your software easier to implement and prevents unexpected side-effects of future changes.

When a class has multiple responsibilities, these responsibilities are no longer independent of each other. If one responsibility needs to change, the more often the class needs to be changed. This may not seem like a big deal but if some things depend on the changed class you may need to update dependencies of recompile dependent classes. To avoid having to change many components to make a single change, give each class only one responsibility.

It also makes your code easier to understand. If there is a problem somewhere it is easier to isolate the problem.

While each class should have one responsibility, this shouldn’t be taken too far by, for example, making each class have only one function.

The article also provides some real-world examples showing the Single Responsibility Principle in action.

I am often guilty of violating this principle. For a project I once made a Pokémon battle simulator. Looking back now I really broke this principle with that one. I had a class to make Pokemon objects and another to do everything else. Because it was for a database course, I connected to the database and had a battle method all in that class.

For the final project I will have to make sure I do my best to stick to the SOLID principles and not get caught in just making the code work. Because it is a group project, I need to be sure the code is easy to understand to others and not just myself. The Single Responsibility Principle is a big part of that.

SOLID Design Principles Explained: The Single Responsibility Principle

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

5 Design Patterns Every Engineer Should Know

As I was browsing YouTube, a video appeared in my recommended videos titled “5 Design Patterns Every Engineer Should Know” from someone named Jack Herrington. Thinking it would be good review I clicked on the video. I wanted to see if were familiar with the five patterns in the video.

The video discusses patterns from the “OG” design pattern book: Design Patterns by the “Gang of Four”. The five patterns are the Singleton Pattern, the Façade Pattern, the Bridge/Adapter Pattern, the Strategy Pattern, and the Observer Pattern. He explains all of these in order as he goes through the video.

Of these, the only one I was unfamiliar with was the Observer Pattern. He explained it simply as there being a publisher and a subscriber with the subscriber listening for events from the publisher.

Something from the video I found interesting was a compiler as an example of the façade pattern. Often you can’t access all the parts of a compiler and it is abstracted to be usable to you as a consumer of that product.

Below the video in the comments, someone mentioned the Head First Design Patterns book. I remember looking at this book in class before and it reminded me to go find it and look at it further. Unlike the Gang of Four book it is written in Java so I have a bit of an easier time understanding what is going on in the book.

This video was helpful as a reminder that there are many design patterns and many resources to help learn them. The final project includes using design patterns so I will look back at these resources to identify what patterns will be helpful in the situations I encounter as I work on the project.

 It was also a helpful reminder that design patterns are not necessary everywhere. Many people in the comments posted about knowing when to use design patterns. There are tradeoffs and consequences to using certain design patterns and it is important to take these into account when choosing to use a pattern in a situation. For example, using the singleton pattern makes life simple. Using it for something like a database driver makes accessing data easy, but it also makes your system inflexible. Whoever is the consumer that is using the database driver also has to have that on their computer to be able to access the database.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

YAGNI Design Principle & Redundancy

Photo by Nataliya Vaitkevich on Pexels.com

Oftentimes, when programming in an object-oriented language, I have the issue of unintended redundancies. I write things to be too verbose; long variable names (studentClassId, carManufacturerName), with unnecessary complications, methods and variables that could easily be removed from my code without losing anything. My reasoning in these cases is always ‘this will make my code easier to read’, or ‘specificity is always a good thing’, but more often than not, this results in messy code with complicated loops and if-statements, where a simpler approach would be much easier to work with in the long run. Over time, larger projects can get to be a huge issue, the more convoluted the code becomes, the harder it is to look at and understand after a few days.

A good example of this problem would be to imagine a simple program which simulates various cars. Instead of having a central car class which handles the definition of a car, (wheels, doors, engine etc), I might have a car class which has instances of wheel, door, and engine classes, which have their own instances of ‘wheelTireType’ (which can be one of three types of wheels), and also similarly needless complication for the doors and engine.

While being specific can be a good practice some of the time, I tend to take it overboard sometimes and end up making classes like ‘carDoorType’ when I could have just as easily had an integer ‘numberOfDoors’ variable and gotten the same effect without introducing an extra, functionally useless class.

When reading an excerpt from Google’s testing blog, I found the principle of YAGNI (“You Aren’t Gonna Need It”) to be of interest. The idea is that you should keep an eye out for unnecessary code and remove it/refactor your code without the unneeded parts. The blog post gives a good list of “code smells” associated with the YAGNI design principle, including code which never executes (“Just in case” code), code which is only executed by tests, and is never used in the actual running of the program, and variables which are redundant.

Out of all of these issues, I definitely struggle the most with redundancy, and recognize that it is something I need to work on overall. Many times while writing Java code, I have created methods and classes simply out of the belief that I “may” need them later on and that this saves me time spent creating these classes later. While this makes sense at the time, coming back to the code later I just end up with a lot of unused classes which end up getting deleted anyway, negating any time savings.

I suspect that going back to some old projects and attempting to refactor them with the YAGNI design principle in mind would be a good way to practice. While it seems rather self-explanatory at first, I think that approaching projects with the intent of preventing redundancy will produce considerable improvements in any future designs going forward.

Site Referenced: https://testing.googleblog.com/2017/08/code-health-eliminate-yagni-smells.html

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

What’s the difference between JavaScript and Java?

 What is Javascript?

It’s a scripting language that runs in a browser, and Javascript can do almost anything on a Web page:

HTML can be manipulated, providing a tool to change HTML at runtime. Events can be attached and executed, in line with the idea of event-oriented programming. The data verification function verifies the validity of the form of data when submitting the form. The operation of the client’s browser: forward, backward, refresh, jump, open a new window, print, etc. Cookies can be created and used.

What is Java?

Java is a programming language introduced by Sun. It is an interpreted language with syntax rules similar to C++. Java is also a cross-platform programming language. The program written in Java language is called “Applet” (small application program). After compiling it into class files by the compiler, it is stored in the WWW page and marked on the HTML file accordingly. As long as the client software of Java is installed, the client can run the “Applet” directly on the network. Java is well suited to enterprise networks and Internet environments and is now one of the most popular and influential programming languages on the Internet. Java has many remarkable advantages, such as simplicity, object-oriented, distributed, interpretability, reliability, security, structural neutrality, portability, high performance, multithreading, and dynamism. Java dispenses with C++ features that do more harm than good and many that are rarely used. Java can run on any microprocessor, and programs developed in Java can be transmitted over the network and run on any client.

Different data types

Java has eight data types: byte, short, int, long, float, double, char, and Boolean, while JavaScript has three data types: number, String, and Boolean.

In addition, there are differences in Java and Javascript variables.

They are positioned differently

Unlike Java, which is a completely object-oriented programming language that requires you to design objects before you can write in Java, JavaScript is an object-oriented scripting language that provides developers with built-in objects, making it easier and less time-consuming.

Link in different ways

Unlike Java, which USES static linking, where object references must be made at compile time and the compiler needs to implement strong type checking, JavaScript USES dynamic linking, where object references can be checked at run time.

Different USES

The most essential difference between them is their usage. At present, Java is widely used in PC terminal, mobile terminal, Internet, data center, and so on, while JavaScript is mainly used to embed text into HTML pages, read and write HTML elements, control cookies, and so on.

Java and JavaScript have different strengths and different specialties. The Java arena is programming, while JavaScript’s heart is in Web pages, where it can do almost anything.

Sourses:

https://www.upwork.com/resources/java-vs-javascript-what-is-the-difference?gclid=Cj0KCQiAwMP9BRCzARIsAPWTJ_G1ymcXEZzbxXRSv4C38P8hTynhLvbfWVea1UEjHNZfbiRwSMScx9kaAgftEALw_wcB

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

The Power of Functional Programming

As I have started to learn some about Javascript, I am very intrigued by the new territory and the strangeness that comes with it, at least for someone like myself, with most of my experience coming from object oriented programming languages like Java and C. As I now know, Javascript is a functional programming language, which has some fundamentally different structures and uses. For this reason, I have started to looked into the usefulness of functional programming, as languages like Javascript and Python are quickly on the rise. I found an article on Xiaoyun Yang’s personal blog entitled Why Functional Programming From A Developer Productivity Perspective which has helped me make some more sense of the intent and uses of functional programming. The article starts with basic info on FP, stating how object oriented programming came to popularity in the 80s with the use of GUIs and how, “it’s easier to program things that use a fixed number of operations for an unlimited number of operation,” but how now, “stateful programming is more of a liability” since, “there is an increasing emphasis on asynchronous, distributed, multi-core and cloud computing.” The article then dives into FP design patterns, which explain its usefulness. The intent is for functions to act as, “pipes for data to travel through,” with Higher Order Functions taking functions as input, and polymorphic function adding to reusability and versatility. The first pattern is the Loop Pattern. The emphasis is on abstraction. In the example, for loops are used for arrays of different types, and the goal is to get rid of the type by, “[parameterizing] the loop action as a function parameter and the initial value as a data parameter.” This provides for the reusability of the function in different contexts. The next pattern is Types. The article compares Scala being type-safe to Javascript. This means, “you can impose the argument type and return type when you first define your function in Scala.” This means for non-type-safe languages like Javascript, the onus is on the programmer to ensure clashing types do not lead to errors. While sometimes type inference in Javascript can be convenient, it can create problems when working with different types. The third pattern is Monads. This means that one can use monads instead of, “hard coding error handlers,” with a monad essentially being a wrapper. There are so many errors to worry about when handling user input, so this is advantageous. The last pattern is Monoid. An example is given for a function to find is any strings in array(s) are not empty. It shows that whatever order the arrays are given to the function, or wherever the unempty string exists, the function still works, preserving associativity and commutativity. Monoid laws help verify correctness. The article finishes by stating that FP promotes reusability and modularity through abstracting functions. This is all new to me and I hope this knowledge helps me soon, as the next language I intend to learn will be a FP language like Javascript or Python. It is essential to keep up with the fast-paced world of computer science.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Uses, Drawbacks, and Additions to JavaScript in 2020

Photo by cottonbro on Pexels.com

In web development, the development of web applications (software accessed through a web browser) and even game development, JavaScript is used to add interactivity and function to what would otherwise be static webpages, and to create software which runs entirely within users’ web browsers. And while JavaScript is undoubtedly useful in the contexts of web and software development, there are some aspects of the language which I feel are somewhat lacking compared to other programming languages.

For one, compared to its namesake Java, JavaScript is somewhat lacking in terms of its ability to create objects. While objects are a part of JavaScript, creating classes is very nonspecific compared to Java. For example, say I want to create an apple class in Java and in JavaScript, for Java, I would need to create a separate class file: 

public class Apple {
   String color;
   public Apple()
      {
       color = "red";
       System.out.println("I am a " + color + " apple!");
      }
}

Whereas with JavaScript, it would look something like this:

class Apple {
  constructor() {
   this.color = "red";
   console.log("I am a " + color + " apple!");
  }
}

While not being strongly typed does have advantages (flexibility of variables, ability to write code which returns a different type depending on context/necessity) I prefer the strong typing of languages such as Java and C#. Strong typing helps to make code more readable, without specifying the type of a variable before using it (ie: var fruit = “apple”;), it can be unclear what a variable is intended for at first glance (especially if there are many similar variables storing similar values). With strong typing, you are always clear on what type of data is meant to be stored inside of a particular variable, (int studentID is clearly only meant to store integer values, while String studentName is only meant to store String values).

JavaScript continues to grow and develop as a language, and new features are constantly being implemented. When reading about some of these new features being added to JavaScript this year, I found a blog post discussing some of the more interesting features which were implemented in 2020. The post served as a good introduction, and offered clear information about each of the new additions discussed.

Private & Static Fields

Something which was absent from JavaScript was the ability to use access modifiers for fields. This year, the ability to use private, or static fields was added to JavaScript; private fields will allow for greater security and the ability to ‘wall off’ access to certain fields, while static fields will allow for the creation of ‘class-scope’ attributes.

BigInt

Another complaint which I have had about JavaScript is the fact that JavaScript only has one number type. While the introduction of the BigInt type does not solve this issue, it does allow for larger numbers to be represented in JavaScript. It functions similarly to the Java ‘Long’ datatype, in that it can store very long number values.

While JavaScript is still missing some features which I enjoy from other languages, these recent additions make it more versatile than ever, and JavaScript continues to be the de-facto language for developing anything interactive on the internet.

Site Referenced: https://www.telerik.com/blogs/latest-features-javascript-ecmascript-2020

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