Category Archives: Week 7

TECHNICAL DEBT

As I was preparing for my exams, I came across the term/topic technical debt as one of the topics under the review topics and this term was seen in one of the class activities. I decided to research on the topic, write a blog post to broaden my understanding for the exams. I came across this blog post that talks about technical debt and chose this blog because the concept has been broken down into topics explaining the term in-depth.

The term technical debt has been described in this blog as well as the good and bad reasons for technical debt. It also explains and gives examples on the various types of technical debt such as Planned Technical debt, unintentional technical debt, unavoidable technical debt, software entropy. It also explains some identifications of technical debt in a project and various ways on how technical debt can be avoided and managed. A youtube video is provided explaining the term as well.

In this blog I learned that although the term may sound like a financial term, it is defined as the deviation of an application from any nonfunctional requirements. Simply, it is a code you have to work on tomorrow because you took a shortcut to deliver it/software today. Technical debt just like in financial terms can have interests which is the difficulty to implement changes and thus needs to be addressed in order to prevent software entropy and risks that may relate to the source code. Teams may delay better coding and certain pieces which are understood by them to impede future development, however, interests may cumulate if these pieces, mediocre codes and known bugs that were left are not resolved.

Technical debts can be identified when code smells are too subtle than logic errors and when there are higher levels of complexities with technologies overlapping each other. Other warnings signs include product bugs that will cause an entire system crash and issues with coding styles.

I learned in Planned technical debt that organizations make an informed decision to generate technical debt knowing and understanding the risks and cost while Unintentional technical debt occurs as a result of poor practices, inexperience with new coding techniques and rollout issues. Unavoidable technical debt is created due to changes in the business and technology that present better solutions hence, making old code obsolete.

One way of managing technical debt is to assess debts and to acknowledge that technical debts exists and share discovery with stakeholders, explaining the importance of paying off technical debt earlier. Technical debt can also be managed by using Agile methodologies that can ensure that teams are working on technical debt.

I hope others find this blog educative as well.

https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/

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

RESTful API from another Perspective

A topic that I chose to learn more about for this week is ‘REST API Design’ as listed in our course syllabus. The source that I had used to supplement my learning was a conference talk on REST API called Never RESTing – RESTful API Best Practices using ASP.NET Web API – Spencer Schneidenbach. This source will be linked at the bottom of this post; however, I would like to mention that I enjoyed this conference talk as I found it both informative and insightful.

In the talk, Schneidenbach goes over his experiences and gives insight into building and designing RESTful API’s. He breaks down building/designing restful api into four activities, design, implementation, document, and maintenance; although he mentions that practically all four of these activities or a culmination of the two activities would be performed at once when working on api, he tries to separate the four activities in his talk. Throughout the talk he also brings up other topics such as explaining what REST and api’s are; however, I would rather discuss segments what I found informative or insightful from his talk.

One of the things he brings up when designing api is that ‘restful api != good api’; and this claim that an api that solely follows the constraints imposed for REST API does not solely make that api good; rather he argues that when building api we should be doing what makes sense and ‘throw out the rest’. I really resonated from this statement, as it made the designing process more practical in that when building api we must be flexible and logical with our decisions; and that theoretical rigid constraints are not what always works in real environments.

In conjunction to this statement, he also mentioned two prime rules he kept in mind which were, KISS and be consistent. KISS meant to keep things simple, but an element of KISS that I found insightful, was asking who we are keeping things simple for. He argues that when designing we should always keep in mind the user experience or the consumer who will be using the api. I thought this was interesting perspective to think of how to keep things simple for a consumer to use the api when designing it; in addition to this rule, he also added to not be creative and just provide enough that is necessary and no more or less, which I agreed with. For the consistency principle, it was straightforward strategy to keep things consistent with accepted best practices; however, I also enjoyed his second comment ‘be consistent, but be flexible when it makes sense’. This comment reiterated a theme in design that there is no silver bullet in designing api, and that although there are solid principles that we should follow, we need to be have some sense to find a balance with what our consumers require and want.

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

Creating Chords from Sine Waves in Python

This week as part of my independent study I worked on feature extraction in Python. I have been using Python for Engineers as a reference, and it describes basic digital signal processing. As an exercise, I expanded on the code found in that chapter.

It’s a non-trivial task to create a sine wave in code (although compared to the most complex aspects of DSP, it’s a cakewalk). A sine wave will create the purest tone possible, as it creates a constant oscillation. This oscillation is what you perceive as a pitch. The equation for a sine wave is given as:

y(t) = A sin(2πft + φ)

where A is amplitude, f is the frequency, t is time, and φ is the phase in radians. We can ignore phase because this simply indicates where the wave starts at t=0, and this doesn’t matter to our ear. We hear the same oscillation regardless of where it starts.

Take a look a the code for creating a sine wave. Some of the details aren’t as important, but you can see the book for a description. The line that actually creates the sine wave values is:

sine_wave = [np.sin(2 * np.pi * frequency * x/sampling_rate) for x in range(num_samples)]

If you aren’t familiar with list comprehension in Python, this is just using the sine wave equation above, substituting time, t, as a specified number of samples divided by the sampling rate. The result is a list of values representing a sine wave. In reality, this is all an audio file is, with some additional encoding (and usually more interesting oscillations than a sine wave).

So what if we wanted to do this for a chord of multiple sine waves? Maybe using more list comprehension? Sure.

# Note Frequencies
a4 = 440
c5 = 523.25
e5 = 659.25
chord = [a4, c5, e5]

sine_waves = [[np.sin(2 * np.pi * freq * x/sampling_rate) for x in range(num_samples)] for freq in chord]

This is doing the same as above, only it’s doing it for each frequency in a list of frequencies. But that’s the easy part. The original code just multiplies the samples by the amplitude, then converts them to hexadecimal values and writes it to the file:

for s in sine_wave:
    wav_file.writeframes(struct.pack('h', int(s*amplitude)))

But we can’t simply do that for each sine wave in succession, or we’d get different sine waves playing one after another. That’s an arpeggio, not a chord!

So we have to get a little creative. But not too creative. If you think of each sine wave playing from a separate speaker, what you hear is the sum of the air pressure from each speaker. A single speaker is the same story: it’s just playing the sum of the three sine waves. So then, iterating through each index, we can add the amplitudes of each individual sine wave. I also had to reduce it enough to store the value as a short int, by dividing by two. 

# Only write samples to the end of the shortest sine wave
shortest_sample_len = min([len(j) for j in sine_waves]) 
for i in range(shortest_sample_len): 
    current_frequencies = [wave[i] for wave in sine_waves]
    value = sum(current_frequencies) / 2
    wav_file.writeframes(struct.pack('h', int(value*amplitude)))
Output of the sums of the sin waves before multiplying by amplitude

Python for Engineers goes on to describe how to use a Fast Fourier Transform to get the frequencies from the wave file with a single sine wave. But the code works just as well for the sine wave chord! This is because the FFT is an array that treats each index as a frequency, and the value at that index is the frequency’s amplitude. This means that regardless of the number of tones in a sample, the FFT can be plotted and will reveal outliers: those indices with a much higher amplitude. These are the frequencies in the audio file.

One last thing to keep in mind is that since the indices are used to represent the frequencies, they will be whole numbers. For example, c5 = 523.25hz will show up as a spike at indices 523 and 524, which 523 having the larger value of the two.

Output of finding the frequencies of the chord created above

Full code for creating a chord in Python is posted here.

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.

Sweep the Floor

In the craft tradition, newcomers start as apprentices to a master craftsman. They start by contributing to the simpler tasks, and as they learn and become more skilled, they slowly graduate to larger, more complex tasks.

—Pete McBreen

Sweep the floor pattern shows that an apprentice can work very closely with experienced professional people of any industry, but they cannot be equal with them since the first day they start working on the company. First contributions to the company by an apprentice are usually small and simple tasks, because the team you are part of, doesn’t know where you fit better, nor do you. As bad as this may sound, “sweeping the floor” is a very good start, because you show to your superiors that you can do small things with high quality, and in the future, you can do greater things with the same quality.

What got my attention is Paul’s experience in a software company. He was aware that he couldn’t write code at a certain time, so he accepted to contribute to the company differently, by even sweeping the floor for real. He was only 17 when he first started, but slowly he started doing more technical assignments, like updating the content of the website or working on the backup. These tasks helped him a lot to gain the trust of the team. Since he was able to do the small tasks right, later Paul would be the same passionate person to do something huge in the company. But let’s not forget that it doesn’t matter how small or big your assignment is if you do something with passion and get the best out of it. As it says on the pattern: If no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in the dirt. Every role is important, and no one should be ashamed of their job!

In my opinion, being an apprentice is very useful after you graduate. Courses you have taken during college, will not be everything you will need when you become an apprentice. Being able to start from the dirt, will help you understand step by step how things work in the company. Not everybody is ready to start from the dirt though, especially people who have some experience in the field. However, depending on your commitment to learning everything, in the future, you might be able to do great things on your own. As a conclusion, take the opportunity to Sweep the Floor, and make sure you prove to yourself and to the team that you’re worth doing something greater every day. 

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

Practice, Practice, Practice: No, not that Dave Thomas

While this pattern is excellent advice, as the title suggests, I could not help but get distracted by the quotes and advice offered by Dave Thomas. Of course, it was nothing substantive that he was saying just that I could not get the Wendy’s founder, also Dave Thomas, out of my head. As for the actual substance of this particular section, it falls into the category of things I am trying to do more consistently in my academic life. Despite being kind of nerdy romanticized, and potentially misapplied, karate jargon; it is effective enough in conveying the idea of lessons, or more accurately patterns, that should be practiced often. Obviously, the linchpin of these lessons is that they are done in private where you can fail gracefully, a common concept in many of these patterns.

Regarding how I apply these patterns, I use a site called codewars where these exercises are also called kata but are done in a web IDE and can be checked for functionality within seconds. As well, all the solutions done by users can be searched, so one can “compare notes” with other users and see what, often insanely truncated, solutions others reached. This fulfills the dojo aspect of these coding exercises as well. If ever you were looking to apply a pattern most directly, this is it – and I hope other students will use this resource. While I don’t believe the site allows users to create their own kata like the pattern says, they do have a suggestion section in the forums. After long hours of honing your skills you could dream something up to really test yourself and others.

This pattern is related to a favorite of mind, Breakable Toys; and not unreasonably so, many of these exercise are incredibly difficult and I have found myself dropping them into my own IDE to finish off at my own pace apart from the web IDE. As mentioned previously, the school and work schedule I maintain makes it a little difficult to keep up with these exercises, or completely them consistently enough. However, I believe that have read this pattern, being set to graduate, and barreling towards my graduation and subsequent career, I do not want to neglect any practice I can get.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Be The Worst

I love this apprenticeship pattern. It immediately caught my attention, and although I knew exactly what it was getting at by reading the title, it’s a great reminder.

We’ve probably all heard the phrase “if you’re the smartest person in the room, you’re in the wrong room”. That’s what this pattern is describing. As the worst on a team, you will have an occasion to rise to, riding on the coattails of your teammates and becoming better for it. This means harder work. It requires the ability to apply many other patterns described in the book to succeed efficiently.

The above quote is a bit harsh, though, and isn’t mentioned in the book. It’s not that one should be openly criticizing their coworkers or consider themselves the smartest person in the room, despite every programmer’s periodic God complex. Besides, it’s difficult to ascertain who exactly is the smartest, or best developer, or best employee. There are many metrics and a team is full of people with different strengths and weaknesses. The individuals are less important than the group: this pattern is probably best implemented by looking at teams as a whole. Are your skills lower than those of the group as a whole? This could be caused by a lot of great developers not working well together. This, too, will slow your progress down. This, too, is a reason to change.

I have mixed feelings about this sentiment. It’s patently true that working with people significantly above your skill level will help you improve if you’re willing to put the work in. But it would be a real shame to leave a close, efficient team just because you’re no longer worse than all of them.

But that is an important part of growth: knowing when to move on. Finally ending my college career makes me consider all the things I could have done, or could do if I finished a second concentration or major. Or what I missed for general education credits, extra curricular activities, and social experiences by cramming the entire degree into three years and not taking my time to enjoy it. It’s nearing the time to move on, though. Despite a connection to classmates and professors, it would not be wise to stay longer. This doesn’t mean professional or academic relationships have to end, but the majority of my time will soon be spent improving in my chosen career, with new challenges, on a new team.

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.

Breakable Toys

This week I decided to write about the Breakable Toys pattern because the last pattern that I wrote about mentioned this pattern, and it was in the See Also section of the last pattern as well. From the title, I have gathered that this pattern is about just random coding projects that have no consequences and the programmer can just experiment with the code and try out new things.

After reading the Context section i discovered that this pattern involves failure and learning from those failures in order to become a better developer. The problem of this pattern basically says that you work in a field that doesn’t allow for failure, but your individual growth depends on failure. This makes sense because there isn’t a lot of room for mistakes in a real work environment because mistakes can lead to much bigger issues.

The solution to this problem is as I mentioned earlier with slight differences. Rather than coding just random projects, you should code projects that “are similar in toolset” (Oshineye, Hoover). The authors recommend using Wikis as your breakable toy. They say this because of their simplicity. They also mention that they can be great for learning HTTP and REST which I thought was interesting because our Capstone involves both HTTP and REST, so maybe I should start working on a wiki on the side. Another breakable toy idea that they suggested that one of their ex-colleagues used is creating games. This is a cool tool because it is a fun way to learn how to code because at the end you are given a product that you can play with way after the fact. Realistically, you could just look up Tetris on the internet, but it is much cooler if you are playing something of your own creation. Lastly, they mention how this pattern is similar to Be The Worst which is actually what I plan on writing about for my next blog.

The Action section basically just tells the programmer to create a very simple wiki, and add features into it as you continue with your career. I like this method because there are no repercussions if you mess up and you can learn from these mistakes. I think that I will actually use this pattern in the future, and my internship has kind of done this for me too. The projects that are assigned to me are projects that they use in their day to day life, but I have freedom to make mistakes and learn from them.

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.

Apprenticeship Patterns: Learn How You Fail

Failure is an acceptance of what you are capably of. Not in a means of saying that you can not but in terms of stating that being aware of what you are missing. This prevents the boundaries that you are creating, such as giving up for being stuck at only one thing that you already know.

Failures are a big part in order to be successful. I have experienced it many time when learning my first programming language. I even decided to change my major to Business. 

At first it seemed really interesting and i was curious to learn more about how functions, objects and data works n java. I practiced and started ding the same problems again and agin until i had an idea of what the code was doing. But when I had a similar problem but it it was conned in different way I was lost. I ended up belly passing.

I then met one of my class mates, she was a minor and had better experienced then me in programming. She was really good at explaining. She taught me an easy was to adopt new skills. She told me which text editor to use, how to consume your time,being tim efficient, and which programming language is easier to understand.

“Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and a constant searching for new solutions.”


Atul Gawande, Better.

I applied those skill. I was still failing but was making progress, i was understanding what Mistakes I was doing. I was only missing out minor mistakes or I was sometimes rushing. But pointing out my mistakes I was ale to prevent myself to stop giving up on programming, 

Now as a senior I am not afraid to take th risk. I take failed as a new learning experience wirer I am able to apply my understanding in much more effiecnt way.

That is what the author is trying to tell. Many people see fair as a negative condition. However, It is a part of being successful. 

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

Apprenticeship Pattern Review 6: Concrete Skills

As I near the end of my college career I am giving more thought daily to what exactly I need to put forth to land my first job as a Software Engineer. Will companies value the fact that I am very creative minded and enjoy collaborating on projects or is are they only looking for the cold hard skills that I have gained over my years of study. The Concrete Skills pattern from Apprenticeship Patterns highlights the fact that, while soft skills are important, the ability to apply knowledge in order to provide value to the companies you are applying to is paramount. Why should a company take a risk on a candidate who doesn’t show that they have the skills the company needs when they can hire someone who does.

This pattern is all about identifying exactly what skills the job you want is looking for and gaining the skill. What may be even more important than learning the skill is building a project using that skill in order to prove your adequacy. While the ability to learn quickly is a great skill, having the foundational skills companies are looking for is important when searching for landing a job. It is important to research which skills are relevant to the positions you are applying for rather than trying to learn everything, since that is an impossible task.

I have recently started my job search and more and more I’m realizing the benefits of having projects that prove my competence in relevant skills for the jobs I am applying to. This pattern has made me realize that it would be a great idea to ask people in my network who are further on in their careers about what skills they put forward that helped them land a job. I can then use this list of skills I gather to slowly pad out my resume with projects that prove that I can provide value to the companies I am applying to. Since I am in my last semester I am pretty packed with coursework, but I am going to set out to learn at least one relevant skill every weekend. By the end of the school year my GitLab will be a place where all of my skills are shown off with well crafted, yet small in scope projects. Concrete Skills is a pattern that every software developer should read and implement because of the huge benefit that it gives you in your career as a Software Craftsman.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Template Design Pattern

For my blog this week I choose to write to about the template design pattern. Picked it because I was recently learning about what design patterns were. So I was google and and came along a list of different ones and I liked the template design pattern because it seemed to be useful and fairly simple so I picked it.

The article first talks about how the template design pattern is used for the base of an algorithm where the steps always happen in the same order and sometimes some or none of them are the same most of the time. Then they talked about an example of an algorithm to build a house were the steps are always first to build the foundation then to build the pillars. Next to build the walls and last to build the windows. They also said that these have to built in the same order every time. Then they started talking about the first class which was an abstract template with the first method being a method to build the house which its self called all of the other steps in the process which were abstract methods. They also said the since the method to build the house was the algorithm to build the house it should be final so it cant be changed. They also you leave the step methods unimplemented or not if they are mostly going to be the same. Then for each type of house you create a new class to build it extending the template class while overriding the unimplemented methods or any methods you need to change.

This design pattern helps with the repetition of having to type the algorithm over and over for each subsequent class you make. It also lets you make reuse so of the steps if they never change. It does have some disadvantages though like how you cant change the order of the main algorithm and that you have to override most of the methods everything. So even if several of the implementations use the same step you still have to rewrite them anyway. I learned a lot from this article first of all I learned a completely new type of design pattern. I think this pattern is very useful especially with algorithms as they said. I also learned just by looking at the list on the website that were far more types of design patterns then I originally thought.

Template Method Design Pattern in Java

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