Breaking Toys

The Breakable Toys pattern talks about a familiar lesson in life, which is that you can learn from your mistakes and failures because they are bound to happen. The pattern suggests that you create something similar to what you are doing in your job/work and use it as a playground to see what will work and what won’t and expand on the things that interest you and learn from what you create or fail to create. The one thing they suggest making and that a lot of developers make is a wiki because they simple to make and expand upon over time to show what you have learned and what you are capable of.
This pattern seems very useful and something that I might implement very early into my career because it sounds fun and interesting. The ability to create something and build on is something that is very important especially in the world of computer science where new things are always being made/optimized. I think this pattern makes me feel like the ability to grow and work on what interests you is an extremely important quality to have in software development. I now understand why our professors wanted us to make a professional blog and use it later in our professional careers since it will demonstrate our interests and progress made in learning more about the different aspects of computer science and software development.
The one thing that I really like about this pattern is the creativity aspect because it makes learning more fun since you are adding and making things more refined because you want what you create to look or work better. The best projects, not only in computer science courses, were the ones that allowed us to create whatever we wanted and pursue what we were interested in. Treating a job like this can turn it from a boring and exhausting job to a hobby that you enjoy and get paid to do. I really like this pattern and wish I knew about it earlier because I most likely applied it to my computer science courses as well to make them easier and more fun.

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

THE DEEP END

What is life without risks? Standing still without challenges, or without the will to change a small part of your life is not living your life to the fullest, and that is exactly what I feel. Reading this part of the book made me realize how it’s hard for me to change small things about … Continue reading THE DEEP END →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

Just like the title says this week I have read the pattern “Expose Your Ignorance” from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This pattern describes how any aspiring developer should put aside their ego and be able to tell other about not knowing something and ask questions. It is about being able to admit that we do not know something and to start learning even if it means showing others your “ignorance”.

As always with this book and its chapters this hits close to home when it come to me and my work experience, as well as school in that matter. I found it interesting because it really shows me that it is not only me who can struggle with this particular pattern. My boss always tells me and my teammates during any meeting or code review: “you owe me at least two questions”, and this is the part that is described well in this chapter as well. The author says: “The most obvious way to expose your ignorance is to ask questions.”. I agree wholeheartedly with this statement, we have to be able to ask questions even if it shows our ignorance on the subject, but the sooner something like that is out there the sooner we can work and fixing the problem as well as better working with the team, since they will know that we might need some help.

The only part of this pattern that I do not agree with all the way is the same one I just mentioned. In my opinion there is a place and time to ask questions to expose one’s ignorance, but there are also times when holding them back until later is the right decision. One such time is when working directly with a customer, a particularly tough or difficult one. Or when having a meeting with a lot of higher ups at a company and your development team. Question on the subject are usually good but ignorant questions can have some unforeseen consequences in these situations. Overall, I agree with this pattern and the idea about having a list of things you do not understand and to update it periodically is in my opinion a very good idea.

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.

The White Belt

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees 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.

Kindred Spirits: Programming inspired by Anne of Green Gables

When reading the kindred spirits apprenticeship pattern, I was immediately reminded of my first real programming class, CS140, wherein I met some of the friendly faces I would spend the next two years becoming a programmer with. A few of these faces were a part of my group in that class’s lab and with them we challenged each other in the subject and helped fill each other’s blind spots. While this is hardly unique, I’m sure, it exemplifies what the pattern is all about: finding peers who you can learn and grow with. Now with those two years nearly behind us and the end (of our education) is in sight, those same friends have been amazing resources.

As new learners, we tend to go in all different directions, not favoring any set method because we have yet to find the path of least resistance or best practices. Subsequently, we create puzzles pieces with our bits of knowledge that we all can combine to get a clear picture of a language, framework, et cetera. I have found as well, that what was often very useful was the ability to politely disagree – read: bicker like an old couple – with your peer and push back and forth on each other to really challenge one’s knowledge or understanding of something. It was through this back and forth that many of the solutions we were so desperately searching for came about; which is something the pattern even addresses, stating that it is imperative to avoid group think and challenge each other.

I remember distinctly have an erratic mass of code segments and illustrations of a particular data structure, the exact one I cannot remember, all over the board in the Science and Technology center study rooms. Data Structures, our major’s trial by fire, has crushed fledgling programmers of far greater skill than me. I can say with no doubt, that had it not been for these brain-storming sessions I would not have passed that class or even completely the projects thoroughly in the way that I eventually did. As I look forward to internships and even jobs after graduation, I hope to keep those around me who I have learned so much from and find new kindred spirits to take on this next chapter of my programming career.

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.

Record what you learn

“You should not also underestimate the power of writing itself…You can lose your larger sense of purpose. But writing lets you step back and think through a problem. Even the angriest rant forces the writer to achieve a degree of thoughtfulness.”

—Atul Gawande, Better

Record what you learn has the purpose to make everyone able to memorize things for a very long time. Using this pattern, it’s not just about writing down notes in a paper and then forget about it. It is about writing down the information you need to learn and read it continuously to keep that information stored in your brain. Keeping a record of your lessons to a blog or personal wiki, it is not a bad idea at all. You decide whom you’re going to share it with, or not share it at all. As long as you write down your notes and get back to them to read or even to make improvements, your brain will be in the perfect shape of memorizing things.

This pattern made me realize that taking notes and writing the most important parts of the lesson is not the end of the learning process. Most of the time when I have to learn something new, I write pages and pages that never end, read them, and then I write a summary without looking at the notes. The problem with this is that after I am done with that lesson, I don’t really go back and read those notes, nor the summary. I wonder if I still have those notes?!

I found this pattern very useful and interesting in my career. Starting from today, I will keep track of my writings, add more details to them, and stick the date they get written, so that when I go back, I would find very organized writing that would make me go back to it over and over again. There is no better thing as reading constantly and memorizing useful information. Another important part of this pattern is that when you go back to read you realize how much things have evolved for a specific topic, and you ask yourself if you should update the original or not? In my opinion, the same as everything nowadays gets updated, writings need an update as well. As a conclusion, keep a record of your writings, the same way you keep a record of bank transactions…

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.