Category Archives: Week 4

Sweep The Floor

This post will be about the “Sweep The Floor” apprenticeship pattern from the book, Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This pattern is about finding your place on your team, contributing to the teams work to earn their trust and respect, and growing as a developer. The pattern suggests taking on the undesirable peripheral tasks when joining a new team/project. This will help you learn more about the project, development as a whole, and will keep you away from the core of the project. These tasks are often overlooked in education so this can help you fill in the gaps of education while working on something low risk. This does not mean lack in quality though. keep good quality, as bad quality on these portions of the project can become troublesome later on.

There are some problems with this pattern mentioned by the authors that I agree with. One is that you may become the guy who they use to do such dirty work, lacking in opportunity to work on more challenging tasks. Another problem is that you may become intimidated by anything that isn’t the easy yet boring work. Although you learn from this work, there becomes a point where you start to plateau from lack of challenge. The authors solution for these problems are to advocate for yourself and look for every opportunity where you can show them you are capable of contributing to higher tier work. Showing them enthusiasm and skill should make them realize that you are ready and capable to move on to more skillful tasks.

I found this useful because everyone has this starting point where they’re at their first job in a profession and need to gain the trust of their team members. Showing them that you are there to contribute can go a long way and nothing shows that better than when you do the tasks that no one wants to do. Although I already had an idea of this, the book really gave me a solid idea of what to expect to do at my first job as a developer and how to get my team to welcome me.

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.

Apprenticeship Patterns Blog Post #2

The second apprenticeship pattern from the textbook that I would like to discuss is the one described as “Unleashing your Enthusiasm.” For the most part, the book is trying to say that some students learning software development are not up to speed with knowing all they need to know yet but have great enthusiasm towards the subject. This often times holds them back in succeeding and learning primarily because of others with countering attributes. Many people have more knowledge of software development but much less enthusiasm toward it, and these people sometimes will hinder the success of the less knowledgable enthusiastic learners. The book primarily describes examples of this hindering with the different members of groups having less enthusiasm and not appreciating the ideas of the others. Groups in software development tend to think normally and about finishing their sprints and nothing else. The extra enthusiasm and ideas from the member of the team is often seen as just an annoyance to the other members when they are in a rush to finish their work. The book describes ways of getting around this by talking to people you trust about your ideas and edging them to give their feedback. Suppressing your enthusiasm and ideas is the worst thing you can do because you could have small amounts of knowledge and lose your enthusiasm entirely. Do not let your possibly great ideas go never proposed. It is your job to energize your team and not let them fall into the lapse of simply doing the work to do it.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

While there were certainly many important concepts presented in the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman and the subsequent chapter introductions, I felt that the increasing level of conceptual involvement made the earliest sections far more fruitful in regards to spurring introspection. It cannot be overstated how well the logical flow of concept presentation is and how the breakdown into sections (Context, Problem, Solution, and Action) allows the reader to take the somewhat abstract elegant concepts and ground them in personal and actionable terms.

An example of how this played out: as I read the introduction to Chapter 2 – Emptying the Cup – I found myself having just digested a well-crafted opening but somewhat hazy about how the previous material would be of substantial use to me. To my pleasant surprise the authors had anticipated this and conveniently delivered me a whole section titled, “Context”. The section read:

“You are just starting out and have only a shallow understanding of how one or two programming languages.”

Indeed, it was so! The “Problem” section then provided what occupational or educational stumbling block I may be facing, followed by a tremendous helping of sagely advice to overcome the aforementioned problem, peppered with technical examples and some relatable anecdotes from the authors themselves. It concluded with a section appropriately titled. “Action,” which provided the hard-hitting actionable steps that, deep down, every person facing a self-improvement regimen knows will create an amount of existential friction surpassed only by its constructive value. Due to all of the above I found myself absolutely loving this book and can imagine it becoming a staple source of wisdom and motivation to come.

Speaking of existential friction, my favorite quote from the assigned reading was actually not in the assigned content but rather the “Audience” section before it. The quote reads, “[E]ven people with a decade or more of experience—particularly those who may be struggling to navigate their careers—will find inspiration and perspective to counter the siren call of promotion to management,” spoke to me because at my last job I spent many a night fighting with inept management only to open my phone on my lunch break and gaze in despair at my Quora feed littered with horror stories of talented principal engineers being given the axe because they had become too expensive to employ, wondering if they should have relinquished their craft and made the jump to management instead. For full disclosure this not some Marxist indictment of the labor aristocracy; I have been both the employee and the manager in my life and may one day find myself on the managerial side of the coin because I genuinely do believe that I am a strong mediator and leader. But the introverted tinkerer within me grasps firmly at any notion that it is possible to succeed largely based on the merit of my toiling and not the bureaucracy of corporate telephone; if this book is to be believed then it seems the inner tinkerer may have a leg to stand on.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

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.