Author Archives: iisbor

Restful APIs!

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!

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!

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)

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?!?!)

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.