Author Archives: iisbor

Breakable Toys Pattern

For my first blog post of the semester (Yeah, it’s a little late), I browsed over the various patterns and right away, the Breakable Toys pattern stuck out to me. Mainly, because the name was very intriguing but also straight forward. I had a feeling that it was the idea of creating projects or things that will allow you to step out of your comfort zone, and more importantly, allow you to mess up without repercussions, and I was just about right!
From my other interest, most notably in gaming, I have also come to a similar conclusion, that is is very important to learn from error and mistakes! Even before reading about the pattern, I had use my observations from gaming and applied it to programming and coding.

Specifically, I had made my own breakable toy! My project was rather simple, but it allowed me to work on things I have never worked on before. In pursuit of developing a web based rock, paper, scissor-like game, I created a safe space for me to expand my horizons, and though I could have easily done it during a different school project, I was much more capable of learning since I had no fear of negative consequences for going out of my comfort zone. I learned about HTML/CSS, node.js, and sockets, and since it was my own area, I had no fear about breaking things or taking the time to figure things out. I think I learned a lot from the experience, and the pattern is very very true.

If I had never taken the chance to make a breakable toy, I think my understanding would still be very limited to the things I learned in school, and though that is not a bad thing, the process of making a breakable toy taught me things that would never be normally taught. Or at least, I don’t think I was really taught it. The biggest thing I learned, on top of more familiarity with JavaScript, was the importance of documentation. During the project, I couldn’t just ask an instructor for how to do something, so I was forced to learn how to sift through documentation, which is invaluable.

Overall, though this is the first pattern I have dived deep into, I think that the breakable toy is something essential. Sometimes, you really do you have to mess up to learn, and I believe this to be true with not just coding, but everything in life!

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

A welcome back with Apprenticeship Patterns!

With the start of the semester, it is once again time to start up my blog post again! This semester will be filled with mostly patters from “Apprenticeship Patterns – Guidance for the apprising software craftsman”

In particular, I have read over the first chapter as well as the introductions for the remaining chapters, and I was honestly surprised by how abstract it was. Fully expecting a more concrete, “Here is how you do things,” I was instead met with philosophical concepts and an exceptional push to strive forward that reminds me, or more aptly, is identical to improvements within the various artforms. These chapters and introductions were starkly reminiscent of the advice I received when I started to learn how to write and draw, and right away, I realized that coding allows the same avenue of creativity and expression that painting or writing a story allows.

It fully changed my outlook on coding and programming! For one reason or another, it is much easier to hand wave programming as “work” or even something that needs to be done, but now I understand that is now the case. The break up into apprentice, journeyman, and master was something that resonated quickly. It almost seems obvious after the fact, and it makes complete sense. Along with the break up, I really enjoyed the short story of the Zen master and the young philosopher. It was very similar to something that I have encountered before.

When I was first learning how to draw, it was very easy for me to question everything because of my curiosity and thirst for improvement, but in doing so, I would slow things down. Rather than focusing on the true task of drawing, I would instead procrastinate by searching for more references, or other things that I “needed.” By the time I was really ready to start drawing and actually improving, an hour would have passed and I’d maybe get only a handful of lines on my paper. If I had pushed ahead and tried to fill up my paper, I’d have done so much more, but I instead wasted my time with unnecessary things.

This isn’t identical to the story of the Zen Master and the Young Philosopher, but to me, it I get the same thoughts reading it. The Young Philosopher was never properly able to learn from the Zen Master since he was blinded by his own ideas, and in the same vein, I never truly improved since I was so busy preparing things that I “needed.”

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

Anti-patterns!

We’ve talked about design patterns, but what about anti-patterns? What even are anti-patterns? Well, anti-patterns are the exact opposite of design patterns! If design patterns are things that we want to do and stay conscious of when we code, anti-patterns are the things we do NOT want to do! These are the little devils on our shoulders, tempting us to produce code that will not be easy to update and maintain! These are the whispers in our ears telling us to take the shortcut, or quickly jam it out! These are anti-patterns!

For some people, it is important to know what things we should do, such as in design patterns, but for others, it is also just as important to know what not to do! In my case, I am one of those people! I learn often from trial and error, so spotting anti-patterns, I realized that, hey! Maybe I don’t have to keep trying different things over and over again. I started looking into a few different anti-patterns, and to my full expectation… Yep! I should’ve looked into these earlier! A few anti-patterns were things that I only learned after the fact, after lots of error, trial, and honestly, guesswork!

From this website , here are some notable anti-patterns that I have found! Some of them are definitely more ‘fun’ than others, and I’m sure you’ve even heard of them, but others are a bit less known, but just as important!

Golden Hammer
The Golden Hammer for example is something that I find really important! It is really tempting to find a solution for one problem and try to apply it to another, but that is a trap! Although a solution might work in one or two instances, to try and use that same solution for all problems is a big no, no! Each problem should be addressed on a case by case basis, and to think that there is a one sized fits all solution is not good! I’ve definitely fallen into this trap before, and eventually had to go back and rework my code, so just don’t do it all together! Spend a bit of extra time to think about the problem at hand, and resolve it accordingly!

Spaghetti Code
Spaghetti code is another anti-pattern that is crucial to know about! Though, it is also pretty well known! Spaghetti code is essentially when code becomes so coupled with each other and connected, that it is practically impossible to unravel. It usually starts small, but over time, it builds up and up and up, until it is a complete mess that even the original creator doesn’t know what is going on! It is crucial to realize that spaghetti code is something that happens over time, so try to keep focus and try not to take the quick and easy way out! It’ll only make things worse for the future!

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

Restful APIs!

Since we’ve been doing a lot of work with REST APIs, I thought I would look into them more and see what kind of other uses for them there are! Some things that I was interested in, was to look and see if I could brainstorm any uses for them, and through a few different websites

Here, here, and here

I found that REST APIs can be used in a variety of different ways! Some of them are things that I wouldn’t think about, while others are more in line with what I expect.

For example, there’s more obvious situations where you can use REST APIs in Twitter’s case that allows people to read certain data. This allows people to do more extensive research with Twitter and create other interesting data points that such as in-depth analysis.

Then, there are other cases that might not be as obvious. REST APIs can also be used in cases like Spotify. I wouldn’t have thought about it in such a way, but pulling information such as song artist and shuffle systems can be developed with REST APIs as well. On first thought, I was curious to see how Spotify would use REST APIs, but it does make a lot of sense when you think about it.

To break it down in it’s basic form, Spotify uses a variety of different endpoints to return all kinds of different information. Some are more obvious, like artist, alum, and tracks, but there are also endpoints for markets and even playlist!

Honestly, I think it’s really clever to set it up that way, and it makes it very easy for third party developers to work on these types of systems. Since many websites use REST as a foundation, if you’re familiar with how REST APIs are set up in one form or another, you can probably quickly learn it in other situations as well. It is certainly much easier to get a hang of than if every single API was different from one another, but I think that goes without saying.

Overall, I think that if I wanted to use REST APIs for my own project, I’d have some difficulties. There’s not a lot of things that I have that can use REST API, so I’ll have to think of a whole new project to make. For basic start, I’d probably make something with a lot of different data or categories, since I think REST APIs are best at that!

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

Get a (rewriting) hat!

For this week, well, I’ve become very interested in refactoring! Despite it being something that every coder must do no matter what, if I can make my life just that bit easier for future me, I want to do that! So, I did some more research and browsed the web to discover this website by MarnixKlooster! And… though the website is a bit clunky to use, it holds a lot of very good information!

One thing that stuck out to me is the concept of a refactoring hat! It is the idea that if you’re refactoring your code and you feel tempted to change the meaning of the code, don’t! So get that hat and remember to keep things intact when you start cleaning up!

For me, this was something that felt very important, since I often have a distinct issue where as I’m going back on old code, I realize that I could do something an entirely different way because of a new perspective. This often makes the code a bit better, but at the same time, I often change the functionality of it, so not only do I have to edit that one portion, but all the portions of my code! It isn’t that my code is too coupled together or that it’s rigid, but because my intent changed and this is hopefully where my refactoring hat comes in!

As noted in the website, a good way to recognize if you’re changing the intent of the code is to make sure that you are not rewriting Unit Test. If you’re refactoring and your Unit Test seems to still work without any changes, then that means you’re on the right track! But if you refactor and find that there are things you need to change in your Unit Test, you better put your hat on more securely because you’re past the point of refactoring!

This is essentially the concept of Rewriting vs Refactoring! To paraphrase MarnixKlooster, refactoring is cleaning things up, so you have more wiggle room when designing your code. In essence, making more design space! While Rewriting is creating code that meets new specifications and implements algorithms and data structures that are more efficient than the previous ones.

Though both of these seem similar, they are very different! From my understanding, Refactoring is like cleaning up your room, you know, sweeping it, mopping it, etc! But Rewriting is rearranging your room entirely! Move your bed, your table, add a new desk, all the little bits and bobs! Though they do seem similar, they are very different!

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

Refactoring code!

For this week, I considered a topic that I was more familiar with instead of something completely new, but all the same, I still looked into it further since there were a few things that I had no idea about!

Before our more recent classes where we learned about the Singleton and Simple Factory pattern, I knew about the concepts of refactoring, but in a different light. Rather than using these patterns and methods to make my code more efficient through a pattern of sorts, I consider refactoring as something more akin to making my code more readable and more efficient by breaking down useless portions of code. This isn’t exactly wrong, but it’s not completely right either!

Mainly, because though these approaches were important, they could be done even better! I main thing that I was missing in my own refactoring was obviously the design smells that we have recently went over now. Intuitively, I understood a few of the smells already, but now that I have a better grasp of many of them, it is clear that my older refactoring efforts were missing plenty of things!

For example, I used to clean up code and make it easier to understand by breaking them into chunks, which is good, but at the same time, I would also condense other areas since they seemed to ‘fit.’ It is clear now that I should NOT do that, but you live and you learn!

I think that the biggest resource that I found so far, is this website! Though it is basic and even a bit barebones, it gives a pretty good introduction to refactoring. It makes sure to consider things such as cleaning up dirty code from inexperience, a refactoring process, the design/code smells, and techniques to refactor as well as show off a few different design patterns!

One thing that might be helpful is that the website contains many different images to help break concepts down and even code examples! I know for me, it helps tremendously when I can look at some code and see exactly what is happening! Though I do understand the concepts a lot of the time, I find that I learn things a lot more quickly if I can look at the source and break things down myself! The website even has plenty of different coding languages too, so if say, Java isn’t your best, you can look at the different patterns in C#, Python, etc!

Overall though, I think that learning about a more refined structure to refactor code and implement these various design patterns will help me tremendously! I know that there have been times where I have gone to look at my old code and I’m sitting there lost, confused, and asking “Who did that!” Hopefully, with this in mind, I’ll have a better understanding of how to proceed with my older code past and future!

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

You ain’t going to need it? (YAGNI)

For this week, I browsed a few of the different design principles, and though many of them are incredibly relevant and important, one stuck out to me in particular!

YAGNI! You ain’t going to need it!

Now, someone might wonder why that stuck out to me? Well, it’s because of I often tend to have the thoughts to ‘future proof’ things! And, this is in direct contrast with YAGNI. Not only do I try to future proof things in coding, but I tend to do in in a variety of different fields.

Building a new computer? Let’s shell out a few extra dollars to make sure I can upgrade my storage in the future.
Making a new base in Minecraft? I’ll clear out this space so I have room to expand!
Buying groceries? Let’s just pick up this ingredient in case I might need it!

When has that helped me? Well, actually pretty often! But… In the grand scheme of things, the ratio is probably quite small. If I had to put a number to it, I’d say… It’s probably…

1/10

Potentially even less! So why the heck am I still stuck with this idea of future proofing! No idea! But anyways, to get back on topic, YAGNI seemed useful in not just my coding, but everywhere, so I started to look more into it! In my search for a grander understanding, I discovered this post by Martin Fowler. And boy, oh boy, did Martin teach me a lot of things!

Firstly, it makes sense! The concept of future proofing, or preparing for something that you will eventually need seems sound, right? But, things change! Especially when it comes to specifications and needs. Things might seem set in stone one day, but in the next, something might have changed and the requirements become different! Any and all investment and work you put into that ‘feature’ will be wasted, so don’t think about it until you need it!

In my own cases, I can definitely say if I just had a more YAGNI approach, I’d save myself countless hours and at least a small pile of money! Plans are plans are a reason! Just because I think I’ll want it later, doesn’t mean I’ll actually want it when the time comes!

That computer I future proofed? Never did it!
That space I cleared out for an expansion in Minecraft? Never expanded it!
That one ingredient I picked up? Never used it!

These have just been my experiences, but I am certain that at least some people can understand where I’m coming from. It really does seem to make sense to prepare for the future, right? But if you’re really preparing for the future, you better make sure you absolutely are going to use it! This is certainly a lot easier for real life things, but when it comes to coding and meeting specifications, that is just so much harder! You probably have about the same chance of looking into a crystal ball and reading your own future as you do thinking a feature will be needed! So…

Don’t do it! You ain’t going to need it!

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

Semantic Versioning (There’s a standard?!?!)

Through a bit of coincidence a friend and I were having a discussion on version control and how we went about naming our versions a few days ago, and I say coincidence, because it seems like we’ll also be working on Semantic Versioning sometime along the line in class.

Being the person that I am, I made my own rules without being influenced by anyone else. For me, I simply though that

Well… It’s my code, right? That means I can name things however I want, right? So if I said this is version 0.9, then it’s version 0.9! Or if this is version 2.0, then it’s 2.0!

In response, my friend informed me of a few soft rules, since he was more familiar with versioning through an internship opportunity than I was, and he shed some light on a few details. Like how versioning is not just a made up number that you assign to your project/code. Hearing this, I was honestly pretty confused, but I looked into it and discovered Semantic Versioning!

And wow, did that blow me away. Looking back at the way I approached things, I was no different from a headless chicken running around! Learning about Semantic Versioning, through this video, it is both so straightforward but also so useful. No longer will I have my versions be numbered willy-nilly, nor will I even forget my own versions and what happened in this update! It’ll finally make sense!

To break down Semantic Versioning, consider versions as three parts!

The Major version, so think 1.0.0
The Minor version, such as 0.1.0
And finally, patches, like so 0.0.1

Major versions are, well, major! These are versions that leap forward and have large changes! Making a major version usually implies that the code is changed in such a way that it will no longer work with older versions. These changes might be large architectural changes, or other large scale changes that usually break the existing structures or APIs.

Minor versions are NOT as massive (duh), but they come with plenty of other things compared to, say, patches! Minor versions could be added features, or updates to existing features, and most of the time, nothing should break. Functionality that existing before should still work, and further development of new features shouldn’t impact or break anything either (ideally).

Patches are like bandages! These are where the bug fixes are! If something is broken in an unintended way, that’s when patches come in, and they should be used to iron out problems that were not accounted for. It could be something minor like the output of some code is a 2 instead of a 1, or it could be a bit more major like a whole portion of the code crashes when run, but patches are for fixes!

As an example, I’ll run through a brief bit of versioning on a made up project! Let’s say… I’m making a program to print out a leaderboard. It connects to an online library to gather scores, and then displays it to whoever connects to it.

After long and grueling work, I did it! I finally completed it and so, I release…
Version 1.0.0
It’s done and completed, but then… It turns out, my leaderboard only prints out the WORST scores! Dang it, I flipped the list around by mistake! So off I go, fixing this bug. After everything is working again, my next version should be 1.0.1.
But then… I think to myself, wouldn’t it be cool if I added region support too? Then we could see where this score is from, and potentially even group regions by high scores!
So, after adding this new feature, my next version will be 1.1.0!
Pretty straightforward, right? It’s really clear what is going on too!
Let’s say another bug is introduce, bam, 1.1.1!
Then more features, 1.2.0
And finally another bug is squashed! 1.2.1
And… another bug ! 1.2.2
But… then wait, there’s another bug. 1.2.3
Things feel good and everything works, but I learn about a whole new library that does what I want it to do, and gives me more room for growth. So rework the whole program with this new library! The old stuff still works, but since I’m switching to a whole new system, this version will no longer work with the old one, and now, this is when I jump a major version.
We’re now on version 2.0.0!

I hope that example made sense! There is more to semantic versioning as well, but that is the quick break down. Introducing things like alpha/beta and also ^ and ~ adds some other intricacies, but for now… Let’s not think about them! Alphas/betas are optional for testing purposes, and to be honest, ^ and ~ are a bit out of my grasp. I don’t fully understand them yet! I’ll look into them more, and maybe I’ll have a future update post detailing what I’ve discovered!

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

Hello? This thing on?

Testing, testing! I hope this thing works!

Anyways, this is my blog! Although I have a few ideas on what I want to do with this thing, I’m a bit unsure still! Hopefully over the course of the next few weeks, I’ll find an interesting topic to run along with! For a few reasons, I’ll mostly focus on coding, but in the future, maybe I’ll explore other things outside of the computer science field!

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