For this week’s blog post I have found an article on REST API Design. REST or RESTful API design (Representational State Transfer) is designed to use and take advantage of existing protocols. Even though REST API can be used for almost any protocol, normally you will see this design in HTTP web APIs. This design was defined by Dr. Roy Fielding and became notable due to its layer of flexibility. REST can use and execute multiple types of calls, due to the data not being tied to any methods or resources. For your API to be considered “RESTful”, it will need to follow each of the six key constraints. The first thing that it will need is a Client-Server. This is the idea of separating the client and the server from each other and makes it so work can be done independently from each other. For example, I should be able to work on my server without it effecting the mobile client. Secondly your API will need to be stateless. MuleSoft, the company where the article is from, says on stateless API, “REST APIs are stateless, meaning that calls can be made independently of one another, and each call contains all of the data necessary to complete itself successfully. A REST API should not rely on data being stored on the server or sessions to determine what to do with a call, but rather solely rely on the data that is provided in that call itself.” (MuleSoft). For example, I should be able to grab and orders information from an order database by calling its order ID rather than all the information itself due to the APIs design. The third thing that it will need is cache. Cache in computing, is a piece of hardware or software that will store data for future use. For example, an autofill password you would use on Google Chrome. For your API to be truly RESTful it will need to have a way to store cacheable data. This will strongly help your API due to less interaction with it and you will be able to retrieve data quickly for your clients. The fourth thing you will need a Uniform interface. This means having an interface that is not coupled with the API layer. This allows the client to easily navigate the API without knowing the backend. The fifth concept for RESTful API is a layered system. According to MuleSoft, they say on Layered System, “As the name implies, a layered system is a system comprised of layers, with each layer having a specific functionality and responsibility” (MuleSoft). Lastly you will need to be able to code on demand. The concept for this idea is that Code on Demand will allow code or applets to be transmitted via the API. This concept is not widely used due to API being coded in multiple different languages and has been raising security questions.

https://www.mulesoft.com/resources/api/what-is-rest-api-design

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

This week I took a look at the pattern “Reading List”. According to this pattern, you should keep a list of books that you intend to read. By making a list of the books you have read and the are going to read, you give yourself an easy way to reflect on your own patterns of studying. As you read you will probably come across more books in the references or bibliography sections. You can add those books to your list as well. Your reading list should also be somewhere online and publicly available. Others may benefit from it or you may benefit from their suggestions.

Despite always being assigned at least one book for every CS course I have taken, I have never (at least until now) considered really using a book to learn about programming or computer science. It seems like a no-brainer to use the internet for anything computer related. Modern search engines allow you to ask extremely specific questions and get almost exactly what you are looking for. Maybe this is because as a student I always know what I need to learn.

As the author points out, it is hard to know where you need to go next or what you need to learn next. I am a student, so I always have a professor who provides a curriculum to follow and assignments to complete. I always know what I need to learn. This is all going to change now because I am graduating in a few weeks. I will have to take the initiative to set my own course of study if I want to improve as a programmer. Without any direction I should probably turn to books.

It is probably time I start reading more books about software development, especially if that is the field I am going to go into. Reading the “Apprenticeship Patterns” book has made me realize books do have a lot to offer aspiring programmers. They are a good way of forcing material in front of you. Because books are restricted by their physical form, authors have to put a lot of material in the book to make it worthwhile. You don’t have to figure out what to learn next; books are carefully curated sections of study, at least textbooks are. It’s about time I start my own reading list too, starting with all the books I neglected to read in the past few years.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I read the section “Learn How You Fail” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The quote beginning of the section is what stood out to me the most. It says, “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.” The section talked about how sooner or later you may face failures but the right thing to do is push forward at the boundaries and learn to overlook the mistakes you have faced. In our field, we face many failures but that is not holding us back to accomplish the goals we have set for ourselves. The author mainly talked about becoming conscious of the things that trip you but allow yourself the choice of working to fix the problems that are cutting the losses.

One of the most important things to do when you face failure is to accept it and investment of time and effort to make a small improvement. Allow yourself some time and the “goal is to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead you to failure.” I liked the example the author provided regarding Ade. Ade keeps a set of private wikis listing all his current skill set and limitations, this enables him to pick challenges to push outwards and to stop wasting effort on the wrong things which can lead to failures. This is a great example of something that I need to do for myself. Especially keeping a diary or a blog is helpful as I mentioned in the previous blog post that talked about the “Record What You Learn” apprenticeship pattern. This pattern was very true to me. Leaning from failures is important and you cannot excel at everything but accepting these limitations and learning from the failures or mistakes forces you to acknowledge them and focus on improving them so you do not make the same mistakes again.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern might be one of the most important ones in the book because it is something that can be applied to any aspect of life, especially for software development. You need to practice your craft and work on improving it by practicing it each and every day or at least the times when you can in an environment without interruptions or deadlines to help you focus. Software architects need to make mistakes to learn and they need to practice in order to learn. The mindset for this type of approach is to always be ready to perform and be as prepared as you can. If you don’t take action on what you need to know, then you will just be stagnant and stuck in the same place. The pattern doesn’t only talk about practice to improve, but talks about practicing in the best way. You need to try and practice in the best way possible by getting periodic feedback or getting more analysis on your mistakes. Practice will be come permanent in the wrong if you don’t constantly focus on way to improve the way you practice to learn in a more efficient way. This is why it says to practice in a relaxed environment so when you make mistakes you are comfortable with making mistakes and not burdened by it.

I think the biggest takeaway and thing I would add to this pattern is that the only way to learn is by doing and not focusing immensely on theoretical. Anyone can learn the theoretic aspect of software in a short period of time, but there takes more effort and practice to learn the practical aspect since you learn by doing. If someone were to learn all the rules and basics of a sport, but not practice actually playing the sport, then they will not be good at the sport. This is very similar to developing software, since you need to learn the theoretical aspect, but in order to be good you need to keep on practicing and learning. It is essential to always be prepared and up to date with how to learn and the most efficient way to learn a specific software. Overall, the end goal is improvement and to learn to adapt and adjust as time goes on for the most out of your software journey.

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.

The section “Familiar Tools”, found in chapter six in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on the tools a craftsman uses. Focusing and familiarizing oneself with a particular set of tools will help increase productivity since there won’t be any need to go over the functions or specifics of said tools. This also allows one to more accurately know how long a task will take using these sets of tools. However, overreliance on one set is discouraged as there will likely be other tools that are either better suited to a particular task or are an outright upgrade. There are also situations where one will have to either choose your familiar tools and personal efficiency or less familiar tools and the overall team’s efficiency. Regardless, familiar toolsets will become obsolete and have to be replaced over the course of a software developer’s career.

The concept of having to swap familiar toolsets overtime is something I’m experiencing in real time despite my relatively small experience. For example, the first program that I used to develop and edit code in was BlueJ. It’s a fairly simple IDE that focuses entirely on the Java language and is mainly used for educational purposes. I got comfortable with it pretty quickly but then I had to learn C language which lead me to switch to Code::Blocks if I’m remembering correctly. The IDE I’ve been using for over a year now is IntelliJ which I mainly use to code in Java. I used all these different IDEs over the course of around three to four years and in the case where IntelliJ becomes obsolete or I need to code in a different language, like Python for example, I’d have to change IDEs again. This process is going to repeat again and again for as long as I use IDEs; though it doesn’t mean that I lose out sticking with one IDE for a period of time. Like the book states, I’ll be saving a significant amount of time coding in Java since I’m already familiar with IntelliJ and I’ll also have a frame of reference when estimating how long a task will take to get done.

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

            The learning pattern “Record What You Learn” from the Apprenticeship Patterns book is mostly self-explanatory from the title. The main concern of someone who gains a lot of knowledge quickly, such as a new software developer, or, in my case, a software development student, is retaining that knowledge. The chapter describes some good ways to track this learning, like with a wiki or a blog (hey!). Having to relearn or continuously practice concepts or bits of skill is time consuming and wasteful, especially if you don’t have something to quickly reference. This is a solution to that problem.

            Recording and retaining my learning has definitely been a problem in the past, although I’m trying to get better at it. At the start of my sophomore year, I realized I had forgotten a solid chunk of the programming skills that I had learned at the end of my freshman year. I had to work a lot over that summer, so I didn’t have a ton of time to practice these skills through personal projects or places like LeetCode. Getting back into the swing of things, especially as difficulty was ramping up, was a struggle. Luckily, I haven’t hit a patch like that since, but there have been plenty of times that I found smaller, but still useful concepts, escaping me.

            Some things in this department might be like remembering some concepts, but forgetting the implementation, or even just one key part of implementation. This is exactly where a wiki/blog would be super useful. I find I usually follow my own train of thought best, as I assume is the same for everyone, so having something to reference in my own writing, in a way that I find is useful in understanding a topic, is best as well. Just in recent memory, I had some trouble trying to remember how to create a custom comparator for two objects. I had just done it last week, at which point I had to look it up. It was excusable the first time, but just a pain the second time. So, even after a week, I still face these troubles. I definitely need to get better as recording my learning, so this learning pattern is a great point of emphasis for me.

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

I decided to once again choose patterns that cover related issues, this one being about passion. This is something that I find myself struggling with on and off between projects, where I have moments of excitement starting a project and successfully implementing a function, but often encounter issues that can stifle this passion. Beyond this I simply have times where I lose the drive to work on personal projects and struggle to find the desire to continue working with software design of any sort. Thus for this post post I chose to focus on the Nurture Your Passion pattern.

There are a few key points mentioned to help with this issue. The first mentioned is that you might just have to put any current work you are struggling with aside if possible to focus on another aspect that interests you. This can be in the form of a different part of the system you are currently working on or even just a breakable toy that will help you learn and grow, rather than stifling this advancement. Additionally, you should try to find a community that you can participate in. More often than not there are others in similar situations, and if you look online you can find discussion boards or even whole websites that have a variety of programmers discussing with each other. Getting different perspectives on the craft from others can reveal new insights to you, reigniting your interest in what you do. Furthermore there are even online study groups if you need particular help with specific issues. Beyond this you can also try reading some of the classic, well-regarded books in your free time. This will allow you to learn in a very low risk environment, removing the immediate stress of having to have functional code and allowing you to enjoy the intricacies of whatever is discussed in the book. Finally, if you are in a professional setting, you have to set work environment standards ahead of time. This can mean setting a hard time for when you stop working to ensure any toxic conversations are steered towards a productive topic.

While I am not in a professional setting yet, this information has helped me. I have never really thought about having to set standards for myself going into a job and will keep that in mind for the future. Many of these tips, as always, sound like they will be very helpful in the future and i have nothing to disagree with.

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch03s04.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Something that I am sure many others who have pursued a career in computer science have encountered is failure. Throughout my attempts at coding, I have found that a vast majority of my time is spent trying to fix my own failed programs. This was, and can still be, a pretty large barrier to my enjoyment of programming, as simply trying to fix your own broken code over and over give the impression that you are not really making progress. To get a different perspective on this issue I chose to cover the Learn How You Fail pattern for this week.

This pattern gives a few key ideas to keep in mind when you feel like you find yourself stuck in a rut of failure. Firstly you should try not to focus on the disappointment of your failure, but focus on determining what happened that caused this failure. Work back through what you did to get to the point of failure and determine exactly what you did that caused this, then make note of the cause. If you can record these issues you will be able to determine your own strengths and weaknesses. This may lead you to realize that you have to put in a large amount of effort for seemingly small gains, but this will allow you to set accordingly realistic limitations on your goals. Accepting these limitations is also important, as it allows you to determine where you should and should not spend your time, which may require you to drop some projects for now. This will allow you to focus on any other issues you are encountering, and you can always return to the previous issue later.

So far I have found that failure is something that goes hand-in-hand with software design, especially when learning something new. Personally, I have always taken the very straightforward hit your head against the brick wall until it breaks method with failure, often  spending a long time solving small issues. After reading this pattern I have realized I should be recording what I am doing wrong each time, and that would certainly save me some time in the long run. Though I am still early in my career I found this pattern to be useful yet again and had nothing to disagree with.

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s09.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.