Category Archives: Week 4

UNIFIED MODELING LANGUAGE(UML)

Since we have been using and seeing a lot of UML diagrams in class and in previous assignments, I decided to look for some resources on UML diagrams to broaden my knowledge and understanding. I finally settled on this resource because it gives simplified tutorials on UML diagrams making it easy to understand especially for beginners. Each part is broken down into various topics and subtopics. Page gives useful resources on UML as well.

This resource gives a clear and simplified definition of UML diagram. It has various topics that explains the roles of UML diagrams and goals of UML in Object Oriented Design. It explains the building blocks of UML diagrams which are Things, Relationship and Diagrams. It gives detailed explanations about nine kinds of UML diagrams or format uml diagrams, the three types of UML modeling and UML notations. It also gives sample examples of UML diagrams when explaining some concepts which makes it easy to understand when reading. Page also talks about the 2 broad categories-Structured and Behavioral with each divided into subcategories

In this tutorial, I learned that UML diagram is not a programming language and relates to Object Oriented Design. Initially I thought it was only a pictorial language to build software system, but this page makes it clear that it uses non-software systems as well. UML diagrams are also made for different users, not just developers to understand a software and non-software system. I must say that through UML diagrams in class, I was able to really understand the way a program is structured as well as relationships between the classes, interfaces etc. even before looking at the codes.

In the architecture part of the tutorial, I learned about the roles that UML diagrams plays in different perspectives of a system. These are the design, implementation, process, and deployment. Looking at these perspectives, all the diagrams that I have seen support this. These diagrams make clear of classes, interfaces etc., assembled in a physical state giving an idea about the flow a system/program has. Another important thing that I learned is that UML diagrams helps support the representation of physical nodes of a system that forms the hardware.

I learned that UML notations are very important to make a model that is very meaningful and is something that should be emphasized from the beginning. Some of these notations are Class, Object, Interface, Collaborations, Actor Notations, among others. I learned that the only difference between the Class and Object notations is that name is underlined in Object notations but has same structure and components as the Class Notation. I got confused when I saw a diagram of Active Class Notation as it looked similar to Class notation but I learned that the differences is that Active Class has solid borders and are used to describe concurrent behavior of a system.

I hope others find this source useful

https://www.tutorialspoint.com/uml/uml_standard_diagrams.htm

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

Simple Factory Pattern

Last week I gave you a small introduction in design pattern and explained their benefits in codes. Today I want to talk about one of this design patterns. The Factory Pattern. The reason why I choose this pattern is because I had to use it in one of my projects in java. The Simple Factory is not actually a Design Pattern; it is more of a programming idiom. But it is commonly used, so we will give it a Headfirst Pattern Honorable Mention. Just because Simple Factory is not a REAL pattern does not mean we should not check out how it is put together.

So, what is a simple factory pattern? The Factory Method Pattern defines an interface for creating an object but let us subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. As with every factory, the Factory Method Pattern gives us a way to encapsulate the instantiations of concrete types. As in the official definition, you will often hear developers say that the Factory Method lets subclasses decide which class to instantiate. They say “decide” not because the pattern allows subclasses themselves to decide at runtime, but because the creator class is written without knowledge of the actual products that will be created, which is decided purely by the choice of the subclass that is used.

When to use the Factory Design Pattern in Java?

Static Factory methods are common in frameworks where library code needs to create objects of types which may be sub classed by applications using the framework.        

Some or all concrete products can be created in multiple ways, or we want to leave open the option that in the future there may be new ways to create the concrete product.

Factory method is used when Products do not need to know how they are created.

We can use factory pattern where we have to create an object of any one of sub-classes depending on the data provided

There are a lot of examples about the Factory Design online. A lot of website gives a good explanation. I decided to choose the Headfirst Design Patterns by Elisabeth Robson; Kathy Sierra; Bert Bates; Eric Freeman. The chapter four shows talk about this pattern and shows a very good explanation and an example also. Another website that it helped me to understand it better was javarevisited. Again, it explains it with details and examples how it works.

https://javarevisited.blogspot.com/2011/12/factory-design-pattern-java-example.html#:~:text=Factory%20design%20pattern%20is%20used,just%20change%20in%20one%20class.

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

You Ain’t Gonna Need It

Hi everyone and welcome to the week 4 of the coding journey blog. For this week’s post I will be talking about a principle called YAGNI which is an abbreviation for you ain’t gonna need it. Now this may seem like a simple topic, but it is very important concept that often gets overlooked in the early stages of programming.

You ain’t gonna need it is one of the key principles to extreme programming and the XP co-founder has states that you should always implement things when you actually need them, never when you just foresee that you need them. The basic concept behind this principle is to do the simplest amount of work that would also get the program to work. The goal is to cut down drastically on unnecessary work, and as a result of this there will be higher productivity rates as well as a more simple to understand code. Efficiency is key when it comes to programming. A software can have many lines of code and functions, but this will be an issue if there are much simpler ways to implement those same functions with a lot less work. The process will take a lot longer with more features and down the line make it much more difficult to maintain.

There are a lot of problems that can occur if you try to implement a feature early when it is not necessary at the moment. There are three things that could happen which include having the wrong feature, having the right feature but it is built wrong or the most ideal option is having the right feature that is built right. Now with these results of the features there is also the outcome of costs. The different costs include cost of building, cost of delay, cost of carry and cost of repair. The cost of building is all the effort spent on analyzing, programming and testing a feature. The cost of delay is the lost opportunity to build and release another feature now. The cost of carry is the complexity added by the feature to code, which makes the software harder to modify and debug. The cost of repair is the effort spent on modifying a feature because it is not exactly what you need now. Now these concepts are the input and output as they go hand in hand. If you make the wrong feature then you have to pay the cost of building, carry and delay. If you make the right feature but it’s built wrong then you have to pay cost of repair, carry and delay. Now with the best option if you make the right feature and it is built right then you just pay cost of carry and delay.

In my personal case, I plan to follow the YAGNI principle in all my future projects because it help simplify projects and saves time. It improves my productivity and prevents unnecessary work and problems.

Check out these additional resources: https://medium.com/better-programming/yagni-you-aint-gonna-need-it-f9a178cd8e1

YAGNI

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.

Thoughts on YAGNI

The link at the very bottom is an article focusing on a design philosophy YAGNI which is one of the topics we’re supposed to cover in class, though we haven’t gotten to it yet as of my writing this. The name is an acronym of “You Ain’t Gonna Need It” which is basically means if the situation doesn’t immediately call for something to be done, then don’t bother with it. The acronym’s meaning is also the main reason why I chose to write about this topic; it sounded funny to me. The article goes on to describe four “costs” that YAGNI mitigates. The first is the cost of build which is the time and effort spent on analyzing, programming, and testing something. The second is cost of delay which is the cost of pushing back other priorities in order to work on what is deemed more important. The third is cost of carry, the complexity that something brings to software and how that modifying and debugging more difficult. And the last is cost of repair which is self-explanatory. By only working on what is immediately important, the chances of wasting time or changing the program are reduced significantly.

What I find interesting about YAGNI is that in a way, it’s telling people to wing it. The biggest reason for that is because in everyday life, sometimes plans change because of unforeseen circumstances. Let’s take for example someone meticulously planning out a program while taking multiple scenarios into consideration and designing different components to compensate. But it later turns out that many of these scenarios are either unlikely or are taken care of by other things outside of the program that this person didn’t even know about. That in turn causes cost of carry because of all the components complicating the core program, cost of build from the time and effort wasted on designing and implementing these components. These are a lot of headaches that are solved by just being lazy and that’s kind of funny to me.

Something else I noticed is that YAGNI is a really simple design philosophy, to the point where it isn’t strictly constrained to software design. Another example I’ll bring up is how when I was younger, I would waste time writing essays by agonizing over small minute details. And a piece of advice I would often get is to write out my first draft no matter how horrible and worry about fixing the details when the time comes. That isn’t to say that drafting out an outline isn’t important; this applies both to essay writing and software design. The truth is that there should be a balance between YAGNI and other design principles which the article does acknowledge even though it does downplay it.

Link: https://martinfowler.com/bliki/Yagni.html

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

Dig Deeper

This pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye is probably the scariest thing I read in this book so far. It describes how in order to be a good “craftsman” in software development one should be able to dig deeper into the knowledge about the problems they are working on. It shows you how one must try and be able to find more information about things in order not to be just a person who puts some code together and is what the book calls “programming by coincidence”.

This is a very interesting and intriguing pattern in my opinion but at the same time makes me feel as one of the people who just happened to code but do not know what they are talking about. It might just be my own feeling at the moment but nevertheless it is there. In my professional work I have always worked on very custom project and not very often things were reused which lead, at least in my case, to constantly only gaining surface knowledge of certain subjects. It is not easy to admit that I am probably not as knowledgeable as some of my colleagues, but I think this pattern is showing me how I might be able to fix this problem.

I am very much in agreement with what this pattern is describing, and in my own opinion a living example, even though I am constantly reading some new materials about my chosen field I still feel it is not enough and I should dig deeper to be able to stand out . Knowledge about a subject is always precious but just like the pattern describes if it is not deep enough it will not be really useful, and it might become a problem later on. One thing I definitely understand from this pattern and I like to think that I’m doing right is reading of the documentation and specifications, even though it might not be enough I think that this at least is somewhat redeeming for me.

This pattern is also somewhat problematic for reasons that sometimes getting more knowledge about subject is just plain boring and monotone, I know it sounds as an excuse, but I never heard about anybody excited to read some standards and specifications. Yes, it has to be done and it should be, but it is definitely not enjoyable.

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.

Practice, Practice, Practice

For this weeks assignment, I decided to write about the “Practice, Practice, Practice” pattern in the book. This one looked interesting to me because I thought to myself, “Obviously, you have to practice, what could they possibly have written for this” To my surprise they actually had a method that I wasn’t expecting.

The article starts off with a context and a problem like all of the sections do and basically the problem is that a programmer doesn’t have room to make mistakes in their daily job, and they can’t learn because of that. This problem makes sense because messing up in your daily job is too stressful. You aren’t given any room to actually learn from those mistakes.

The solution part, like all the patterns, is the longest part because this is where everything is explained. This section leads off by describing the ideal world as being like a school almost. Programmers can be given random assignments and receive feedback on said assignments, and they can get more assignments as they progress. However, we don’t live in that ideal world, so programmers “must fall back on their own resources to achieve the same effect.” (Oshineye, Hoover).

The next part is what really intrigued me. They relate coding to martial arts by saying the katas are a great way to practice. Katas are basically opponent less exercises to take away the stress from the fighter so they can just learn. In programming terms, this basically means just performing exercises on your own to help you learn without the pressure of being fired. I love that someone made an actual coding dojo in Paris because it is such a good idea. It gives people the chance to code stress free, and there are other people there to review the code that is being produced, and help those who are struggling.

The action section tells the reader to find a problem in one of their books that they should struggle with and they should keep doing it and keep note of how their solutions change each time they perform the exercise. This is a great way to learn because it gives the programmer a chance to learn how to better their code and come up with better, more efficient solutions.

Overall, I really enjoyed this section. Like I mentioned before, I didn’t know how they made practice a whole pattern, but it was very interesting. The whole martial arts metaphor worked really well because coding and martial arts apparently have a lot of similarities. I plan on using this method in my future.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Android Audio Recording and Playback, and an Animation False Start

This week, I spent a lot of time with animations in Android. And yet, I still could not get transitions to work to my liking. After reading Android’s docs, I resorted to a few different videos and tutorials, some of which seemed straightforward but were using methods of Android past.

The goal was to animate the title of a single audio file in a list, to move to the top of the screen and become a heading for details about that file. Animations are easy enough if you’re transitioning between Activities. But it appears that having a RecyclerView in a Fragment to list audio files adds some complications. I did successfully animate between the screens, but the first item in the RecyclerView’s list was animated, and it abruptly changed to the correct title when the motion ended. The issue is that this transition animation requires two elements to have a shared “transitionName”. Because I am using Card objects to display each of the audio files, only one Card can use that transitionName and be animated.

The solution is to set the name in the RecyclerView’s ViewHolder, so that when objects are bound to a specific card, they can get a unique transitionName. This can then be applied to the Fragment’s View before the animation begins. Attempts to do this caused some problems due to Android’s Lifecycle. Many a blog post have been written on this subject, but I’d like to discuss it in the near future to gain a stronger understanding.

All of this is to say: I want to efficiently getting from point A to point B by realizing which subjects and features are most important. Understanding the Android Lifecycle is clearly more important than an animation, and apparently prerequisite knowledge. And recording and playback are at the heart of the app itself. So my progress in animation is stashed in Git and ready for me to continue once I accomplish these other tasks.

Luckily, getting audio to record and play back was a much more enjoyable process. This might be due to my greater interest in the feature, but I was able to break down the problem and troubleshoot issues much easier.

I erroneously believed that my simple spike project would easily translate to my app. Android’s guide to MediaRecorder and MediaPlayer made it simple to get something quickly up and running. However, using their code directly would create a nightmare of an Activity, which neither properly separate concerns nor follow basic OOP principles. Furthermore, I needed the recording to begin immediately upon opening a new “RecordActivity”. This caused some issues with Android’s lifecycle, so I took to opportunity to explore that. The problem came from trying to start recording in onCreate(), which did not provide enough time to load the MediaRecorder into memory. The solution was to start recording on the onResume() event. However, this may be called more than once in the life of an Activity, so I simply check if the MediaRecorder is currently recording, and start recording if it isn’t.

I spent a bit too much time trying to find the recorded audio files in phone’s physical storage. It seems they do not appear, and I haven’t found a good explanation for this. Luckily, Android Studio’s Device File Explorer did reveal that the files were saved and properly recorded audio.

From there, implementing audio playback as a Service (which in Android is essentially an Activity without a UI) was rather smooth. This also allows playback to be initiated from anywhere in the app by passing the file name in a single line of code.

I have always been a function-over-form kind of guy. I made significant progress on the app this week in the function department. Hopefully the form will come in time.

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.

The Long Road

When I started programming, I was hoping to be a professional programmer within a year. Maybe two. I pictured myself as an expert, and studied the minutia of Python. If I memorized the documentation, I’d be an expert, wouldn’t I?

This apprenticeship pattern describes why that line of thinking is false. Becoming an expert is a lifelong experience, and the expert realizes there is always more to learn. It warns against taking the best, highest-paying job as soon as possible. Instead, value learning and accept the role of an apprentice.

I beat myself up for not pursuing my interest in programming when I was a child. I asked a cousin how he programmed video games when I was 10 years old, but didn’t write my first line of code for 5 years. Even then, I found the task daunting. Obsessing over details slowed me down. I didn’t completely dive into bigger projects until my 20’s.

The best learning experience I’ve had was an internship. I had freedom to try new things, make mistakes, and overcome challenges. I built a large project on my own, which my team loved. At a larger company, I would have likely worked on a much smaller piece of a huge puzzle. The experience of starting on my own will pay dividends for my entire career.

Similarly, while returning to college after a few years of programming was frustrating, it was helpful. I had thought CS-101 would be a complete waste of time. Instead, it was a chance to dive deeper into subjects I was already familiar with and gain exposure to concepts I hadn’t. It provided a foundation, which is the essence of this pattern.

This section of the book says there is no one so far ahead that you cannot catch up if you think decades ahead. This idea is an extreme relief to those of us who started a bit late. It’s tempting to compare ourselves to the teenage CEOs of the world and take shortcuts to catch up tomorrow. But I plan to write software for the rest of my career, so this pattern is a reminder to take my time, enjoy the process, and understand that consistent, continual effort will get my skills where I’d like them to be.

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.

Apprenticeship Pattern Review 3: Confront Your Ignorance

“Confront Your Ignorance” is another pattern that struck a chord with me from the Apprenticeship Patterns book. I chose to talk about this pattern now because of its strong relationship with the “Expose Your Ignorance” pattern which I talked about in a recent post. As a developer who is relatively early in their journey, I realize that there is some skill or tool that I should know that I may be unfamiliar with almost daily.

Confronting your ignorance is all about taking the list of skills and tools that one creates when exposing their ignorance and setting aside time to learn that skill. The approach with which one learns a given skill or tool is unique to the individual. The main goal of this pattern is to be able to confidently say that you understand how to implement a given skill or effectively use a tool after confronting that gap in your skill set. It is important to reflect often and decide, once you have reached satisfactory knowledge in an area, whether you should switch topics or delve deeper into the current one. If a developer does a great job of exposing their ignorance without ever confronting it they can never take the step to being a software craftsman. They will find comfort in their ignorance and rely on others to fill in the gaps. Conversely, if a developer always confronts their ignorance without exposing it, it creates a work environment where everyone pretends to have a skill and then learns it in hiding to appear adequate. This would be a bad application of this pattern and should be avoided as much as possible.

For myself, I find that my learning and application of a skill tend to go hand in hand. I find myself confronting my ignorance at the same time as trying to deliver a product which tends to end in frustration and a sense of failure. In employing this pattern I can save myself the frustration by setting aside time to toy with a tool and learn a skill. Inevitable failures when learning how to use a tool no longer equate to failures in being able to deliver a product. After reading “Confront Your Ignorance” I will immediately start to employ this pattern in daily life. I will expose my ignorance and then give myself the time to fill those gaps in my skill set.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Dig Deeper Pattern

This pattern focuses on being able to decompose problems entirely and understand each part thoroughly. Many times, in the work force, people will only have enough approximate knowledge to help them get through their days, but when problems arise, they become useless. It is extremely important to be able to take all parts of a problem and truly understand them. To be able to decompose these large problems, it is important to study and understand every part that goes into it. While doing this however, it is important not to become too narrowly focused on one idea.

I connected with this pattern a lot due to the fact that many times when working on a project, I will run into an issue that I can provide a “hacky” fix to by reading it online, but I never acquire the knowledge of that topic specifically. I often times make the excuse that school causes timelines and completion of projects that are often unreasonable to be able to fully delve into the project. However, I need to start taking these problems apart piece by piece in order to start fully learning anything I come into contact with. If I am able to start with small sections of material, eventually there will be overlaps in knowledge that will build on top of each other until the projects that I’m faced with, now appear to be far easier. It is often overwhelming to start off researching into an entire idea of a project but being able to take small slices of it will make it far more manageable.

I enjoyed in this pattern how they discussed that often times there is a more knowledgeable person in order to fill in the gaps that you may have. In the workforce this can be a co-worker or a higher-up, but often times it is the teacher in school. Being able to create the knowledge for oneself is far superior in the long run than consistently going to the person that may have a better understanding. In order for anyone to reach that status of knowledge, they all took their time to break down and understand individual components of any problem they run into.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.