Category Archives: Week 7

Gluing functions together in F#

Often when writing a function, we want it to be generic enough that it can operate in different ways for different inputs. Different languages will provide different ways to do this. Object-oriented solutions might include interfaces and polymorphism. Procedural languages might suggest template specialization or function pointers.

I’m going to talk about how functional programming languages use first-class functions to solve this problem in a satisfying way without any pointer syntax. Here’s some F#:

let rec filter fn lst =
    match lst with
        | [] -> []
        | head::tail -> 
            if fn head then [head] @ filter fn tail
            else filter fn tail

We’re defining a function named filter here which takes a boolean function and a list. The filter function will pass each element of the list to the function and eventually return a list of the elements for which the boolean function returns true. Let’s look at the result of passing some simple arguments.

let numbers = [0; 1; 2; 3; 4; 5; 6; 7; 8; 9]

let isEven i = 
    i % 2 = 0

filter isEven numbers
[0; 2; 4; 6; 8]

Usually when we see functions in the argument lists of other functions, we expect them to be glorified values. But in this case, isEven is not returning some value that gets glued to a parameter of filter. When a language has first-class functions, it’s perfectly fine to have functions themselves be the inputs or outputs of other functions. Here, isEven is itself an argument, and it operates on the head of each sub-list as we recursively cut our list down to one with zero elements.

In functional programming languages, it’s harder to write programs that aren’t reusable. If we want our filter to cut out any numbers that aren’t part of the Fibonacci sequence, we just write another boolean function and pass it instead.

let rec isFibHelper n x y = 
    if n = x then true 
    else if (y < 0) || (x > n) then false
    else isFibHelper n y (x+y)

let isFib n =
    if n < 0 then false
    else isFibHelper n 0 1

filter isFib numbers
[0; 1; 2; 3; 5; 8]

filter isFib (filter isEven numbers)
[0; 2; 8]

Because filter operates on a list, to filter a list of some other type we can just steal some documentation code for another boolean function.

let strings = ["abc"; "DEF"; "gHi"; "jkl"]

open System

let allLower s =
    s |> String.forall Char.IsLower

filter allLower strings
["abc"; "jkl"]

Functional programming is all about composition and modularity. You start with tiny Lego pieces and need to attach them until you have a gigantic ninja castle. In its most dogmatic form, that means sacrificing creature comforts like loops and mutable data that we use to quickly slap together solutions that can never be reused.

If you learned to write procedures or call constructors, I recommend giving one of these languages a try. It even makes recursion fun, so what’s not to like?

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

The Great Observer Pattern

The Observer Pattern is a design pattern that allows objects to react to changes in another object’s data while maintaining loose coupling. Loose coupling, for a reminder, is a system in which components are weakly associated with each other.  The pattern as described in Ilyana’s blog “The Observer Pattern” is a pattern that can decide at runtime whether to receive data from the subject-object.

                The blog goes on to say that it is not uncommon for object-oriented programming to run into a situation where you have an object in your code that collects/outputs data and other objects that care about that data. Some objects might care about certain data that the programmer might throw at them, such as measurements or certain temperatures. These objects are the observers. The observers do not care what class gives them the data, only that they receive the data as it changes. Signs that your code might need to be refactored to utilize the Observer Pattern include an object that is dependent on another object or a change to one object that requires a change to many others.

                The Observer Pattern defines a one-to-many relationship between a set of objects. The Observer Pattern defined one subject’s relationship with its many observers. The Observer Pattern will separate the subject from its observers while still allowing the observer to react to changes in the subject’s data. The observers provide a method that allows the subject to inform them of the updates. This pattern allows for loose coupling once again between subjects and observers. As explained in the blog they can interact but don’t know that each other exists, they basically know nothing about each other.

                The pattern is usually implemented using an abstract subject class and an abstract observer class, which a concrete subject and some concrete observers inherit. This pattern would be very useful if I ever needed the objects to receive an update when one object changes. It’s very intriguing to hear the terminology they use within the blog. The subject acts as a publisher which sends out the information and the observer, which acts like a subscriber, basically takes in the information it wants to receive. Obviously with I can see the subject sending information that the observer might not want to receive or have on them. Non the less it’s a very interesting pattern that shows the process of what a loose coupling might look like in a coding environment.

Link to Blog “The Observer Pattern” by Ilyana: https://ilyana.dev/blog/2020-08-07-observer-pattern/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Getting a Grasp on GRASP

The topic I wanted to cover this week is GRASP. GRASP stands for General Responsibility Assignment Software Patterns. I read a blog post by Kamil Grzybek called “GRASP – General Responsibility Assignment Software Patterns Explained”. He does mention his post is inspired and based on Craig Larman’s book “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development”.

Grzybek explains GRASP is a lesser-known set of rules that can be used in object-oriented programming and there are 9 patterns to follow within GRASP. The nine patterns are the following.

1. Information Expert
2. Creator
3. Controller
4. Low Coupling
5. High Cohesion
6. Indirection
7. Polymorphism
8. Pure Fabrication
9. Protected Variations

Grzybek goes through each pattern, explaining them, and gives some code from Larman’s book to help give the reader a better understanding of the uses of the principles.  The information expert is to assign the responsibility to the class that has the information needed to fulfill it. The creator pattern decides which class should create an object. A class needs to have at least one of the following responsibilities to be a creator, contain or compositely aggregates of the object, records the object, closely uses the object, or initializes data for the object. The controller pattern is to assign the responsibility of controlling a system operation to an object that represents the overall system or use case scenario. Low coupling is a pattern where responsibilities are assigned with the idea of reducing the impact of change by lowering coupling. The high cohesion pattern is used to keep objects focused and easy to use and understand by making sure all responsibilities of an element are related. Indirection is used to avoid coupling by making an intermediate object between two components. Polymorphism is how alternative types of classes are handled by using polymorphi operations. Pure fabrication is making a new class when it is hard to figure out where responsibility should be placed. The last pattern-protected variations is to create stable interfaces around points of variation or instability.

I chose this topic because I thought learning more patterns that could improve my code would be beneficial to me. SOLID and GRASP are the first two sets of rules I have learned about but there are plenty more that Grzybek mentions at the end of his post so perhaps one day I will learn about those too.  I did find GRASP to be a bit more confusing than SOLID to understand but I am glad I had a chance to read about it. The main conclusion I took away from this post is the management of responsibilities in software is crucial to creating a high-quality architecture and code that can easily be changed. Grzybek ends his post with the words “the only thing that is certain is change. So be prepared”, which really emphasizes his point that software must be flexible. I will have to keep this in mind when developing code in the future.

Link: http://www.kamilgrzybek.com/design/grasp-explained/

From the blog CS@Worcester – Ryan Klenk&#039;s Blog by Ryan Klenk and used with permission of the author. All other rights reserved by the author.

Getting better and better

As we have been Progressing through the weeks and we work on the pogils as well as the homework I find myself slowly getting the hang of the work flow as well as utilizing VSCode, I for once understand what is going on in the classes and am eager to continue to learn as it finally is being pieced together in my head. the biggest part would probably have to be the feedback that I receive and probably mostly everyone else gets as well its not some random jargon about how something is wrong but it seems like a guiding hand to get you to the solution that you aren’t to far from. the biggest take away I have gotten as organizing the UML diagrams on the Homework really connected the dots on how these classes and models work together better than it ever has , I can understand paths a little better than I did before.

I only hope I continue to understand the work I continue to do, and im eager to see what work I can get done.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective:

This sprint ran more smoothly than Sprint 1 did. As a result of having obtained a more detailed specification by coordinating with the goals laid out by Dr. Burge from Nassau Community College and having obtained a better understanding of the individual skill-sets of our team members, we were able to produce an OpenAPI specification that defined 8 of the 9 requested endpoint definitions. The yaml file containing these definitions was then used to write, build, and test these endpoints in our back-end container. These methods were then tested internally within the container by using the Visual Studio Code environment to launch HTTP requests from 2 files (guest.http and qs.http). “Swagger UI” was used as a VSCode extension to facilitate this process.

It was easier this sprint to distribute work among the team, because the Open-API spec was available shortly after the start of the sprint, enabling back-end code to be written and unit tested. As testing progressed, we would modify the spec as we made changes to the back-end code to fix bugs.

Although we did a better job at keeping the Git-lab Epics and Issues boards properly in place than in the prior sprint, this may have been the weakest area of our efforts. Our intention is to improve the ongoing modification of this Scrum material as we progress to sprint 3.

We improved our use and efficiency of GIT to Git-Lab coordination, were able to build semantic versioning, checked the structure of the Open-API definition with Swagger Preview, and started looking into using a secure key. This key will be coordinated as a priority in the sprint 3 effort through communication with the IAM team.

I was able to set up a fork of the NEST Android application with the intention of doing system testing of the REST API. By using Android Studio, my prior knowledge of Android development with Java, and the help of a guiding YouTube video, along with general help from stackoverflow.com community, I was able to write 6 classes in an isolated namespace to the project. This code uses an android library call Volley to facilitate REST API development. This code launches an activity from the main NEST activity which allows the user to make requests to the remote back-end MongoDB database, and returns responses, which are then displayed in a scroll-able text view component.

The layout used by this activity used a relatively new UI component called a Constraint Layout, which improves the efficiency and maintainability of its XML code with the support of a sophisticated design tool allowing “drag and drop” of components, allowing them to effectively present a user interface which will scale properly over the hundreds of different android devices, all with different screen resolutions, aspect ratios, and device sizes.

The system testing was burdened by the fact that calls from Android were producing a Timeout Error on every attempt. With the help of Dr. Wurst, I am in a better position to get these calls working by the first week of the upcoming sprint.

I was impressed with this sprint, because our team accomplished the 2 main goals of this classroom effort, the first being to improve the skill-set of the team members in a “real world” development effort, and secondly, to help with the general progress of the LibreFoodPantry work to produce a product to help those less fortunate than ourselves.

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

The Deep End

Chapter Two’s is themed around growing your knowledge. The pattern “Confront Your Ignorance” follows this theme and focuses on working with projects that are outside of your expertise. When you feel as if each project you are working on is like the previous one, it means you are applying your existing knowledge. There is truly little chance to grow as a developer when you work strictly within the areas you are knowledgeable about. The ideal scenario is one where you are working outside of your area of expertise to maximize the amount of new experience you engage with.

In the future, I will be more willing to work on projects where I dive into a topic that I do not fully understand. I also feel that the action for this pattern, to map your projects in a timeline, is a useful way to track your personal development over time. A timeline is a terrific way to see if your learning has stagnated and it is time to jump into something new. This method is also a great way to see where you want to take your professional career and give you an opportunity to map into the future.

I found it interesting how large of a risk the author suggests taking regarding a project outside of your knowledge. It is suggested to work on projects where the possibility of failure to complete them is high. In a private setting, I would gladly challenge myself by deep-diving into a project that I do not feel confident I can complete. In a professional setting, I personally am a bit too risk-averse to immediately want to take on a task where the chance of failure is greater than my chance of success. However, I appreciate that it is a gamble where if I do succeed it will boost my portfolio and whether I succeed or fail I will walk away with more knowledge than I started with. I believe it is human nature to be frightened of failure. This pattern is a great reminder that the journey that led to failure was along the way a great learning experience and the following attempt will be a success based on what you had learned.

From the blog CS@Worcester – Jared&#039;s Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Week 7: Be The Worst

For this week’s pattern, I chose ‘Be the Worst’ from Chapter 4. I initially chose it because it caught my eye and I was going in order of chapters with the patterns I chose. I thought it would describe in detail to be the worst of your team but it was actually the opposite. The context is after unleashing your enthusiasm, which I assume was a pattern before this one, you take every opportunity to learn new skills. As a result, you outgrow your team and possibly your entire development organization. This was much different from what I originally thought this would be about, I thought this would be to think yourself as the worst to get better as a software craftsman. It kind of follows that pattern of thinking though, basically surrounding yourself with better developers. This in turn, will motivate you to be a better developer and have room to grow as a developer. I thought this was an interesting point, I mean this is something that I sometimes think about and is actually something I’m experiencing right now. I’m in a team that I feel like are all better developers than me which in turn makes me want to be a better developer because sometimes I feel so lost when in team discussions. This pattern really stuck with me because I related to it a lot. I just need to find the motivation to be a better developer, I need an extra push because just a team of strong developers won’t push me hard enough to find that drive to be better than I was yesterday. The pattern also mentions Breakable Toys and Reflecting as You Work as patterns to go back to because they are particularly important if you are the worst on your team, which I am. I guess I’m gonna check those out after this pattern, maybe even write about them. Honestly though, I feel like this pattern kind of reinforces impostor syndrome, which I found out is pretty common amongst developers and probably is common in STEM related jobs, but at least with this book, it puts out a solution for you to follow.

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

Sweep the Floor

The context of this pattern is that you are a new apprentice on a project. However, the problem is that you don’t know what your role is in this team. You don’t know how to contribute to the team and help them in any way necessary. The solution is to volunteer for simple, unglamorous, yet necessary tasks for the team. This way, you can earn team member’s trust, and you also get to show the team members how quality of work you can do. The tasks may be such as maintaining the build system, production support, responding to maintenance requests, bug fixing code review etc. The tasks can be anything, but it cannot have any high risks. Starting a core tasks and failing puts you into a bad side of a team, so it is better to start off with an easy tasks and actually finish it to have good relationship with everyone on the team. These short takes benefits the team, but it will also benefit your apprentice because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.

This pattern kind of reminded me of our group for the capstone project. When we first formed the group, I was assigned to the frontend part of the project. I was ready to do the first task from the GitLab issue board, but my main question was how can I convince the team that I can do this project together with the team and can actually make some contribution. In this computer science major, I feel as if I am always a step behind from everyone and have to add in extra effort to be on the same level as everyone else. So to show my skill, my first task was to connect two components and load one component only on click, which in my opinion is not an easy task but also not a hard task and I think I managed to do that, and the team seemed to love the way it turned out to be.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Familiar Tools”

For this week’s blog post, I decided to pick a topic that I think is very important and is something that we should remind ourselves time and time again. The topic I wanted to go over this week is on the topic of familiar tools or using things that we are familiar or comfortable with. How the author defines familiar tools in this section is a familiar tool is something that we can use without needing to look at the documentation. We have seen it enough times to know the ins and outs of whatever we are using. In the beginning of the chapter, it talks about how when we use familiar tools, it gives us peace of mind because we can give clients rough estimates or timelines of when they can expect something to be done. It is also because of this peace of mind that the author says that it may increase productivity. While there are advantages to using familiar tools, the author also cautions us to be careful. Using familiar tools may make us feel too comfortable and cause us to lean back on these tools and use them to try to solve every problem. So, the important reminder that author gives us at the end of the section is that we need to remember there will come a time in which our familiar tools will become obsolete and that we should not be unmovable. When the time comes, we need to be ready to adjust and throw away our familiar tools.

I found this section to be interesting because a while back, I was having this conversation with my team. We were talking about how when were learning introduction to programming, we were taught that our default branch on GitLab is master and when GitLab made the change to their naming convention from master to main, it threw everyone in the group off. Reading this chapter made me realize that everything we are learning now is mostly relevant now and that in a couple years, everything we learn may just become an artifact of the past. The principles may stay the same but the naming or software we may be completely different. Reading this chapter also reminded me of something that my R professor once told me. She once said something along the lines of, “Right now, we may be standing on solid ground but in a year from now or even in 6 months, the floor may disappear from beneath us.” When she told me this, she was referring to how our libraries may quickly become obsolete and when the time comes we should not be resilient to change.

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.

Unleash Your Enthusiasm

Back when I was a kid (actually until now), I have been really into playing video games. It could be the reason why I chose Computer Science in order to be able to create games, a popular reason just as many of my colleagues. I somehow was able to land a spot at Ho Chi Minh City University of Technology, a flagship in technology teaching and research activities in Vietnam, after the high school graduate exam.

By the start of the school year, I had nothing but excitement, my only experience was some rough foundations of Pascal taught in high school and I barely remember anything from it. On the other hand, my colleagues were students from the very top high schools with a program concentrating in what they desire, which were mostly computers and the others had extra programming courses outside the class. Besides, the program was designed for students who already had experience with programming since the syllabus of my programming introduction class is a C++ class consisting of both functional and OOP methods with two huge projects. As a result, I was totally “destroyed” in this intro class while my colleagues, having a hard time, but managed to get through it.

Since my excitement was demolished, I had a hard time thinking about my major choice. I did not have any problem doing the required calculus, linear algebra, physics classes but my computer introduction class was a disaster. I was not able to unleash my enthusiasm, I did not know what it was, what I did at that time was grinding myself painfully to be “better”. In my opinion, we tend to be afraid of discussing or expressing something we are not familiar with, and for my case, I cannot show my professor my problem because of it.

After a few years since then, I would say that the syllabus for that intro class was still overwhelming for new students. However, for students who already had their based knowledge before taking that “intro” class, it’s a good opportunity for them to review before going into the main courses. If only I knew how to inject my excitement into my work to ask my professor about my problem, my learning would have been much better, wouldn’t it?!

From the blog CS@Worcester – Vien&#039;s Blog by Vien Hua and used with permission of the author. All other rights reserved by the author.