Category Archives: Week-14

Inversion of Control

Inversion of control is a software principle that asserts a program can benefit in terms of testability and usability if the management of an application’s flow is transferred to a different part of the program. I.O.C’s framework takes the management of an application’s implementation away from the developer. When interactions require custom business logic, the I.O.C framework will use the code provided by the developer. This is the “inversion” point of the inversion of control design principle. The most common application for Inversion of control is Java servers faces. I.O.C frameworks implement low-level and problem-prone activities, it allows the developer to focus on custom business logic instead of tedious tasks.  The one thing about inversion of control is that it can confuse what qualifies as an I.O.C and what doesn’t. Some examples of inversion of control are event-based user interfaces, shared cache, and comprehension framework—the range of development changes that qualify as I.O.C contributes to the term. I.O.C is a principle, not a design pattern- the implementation depends on the developer. I.O.C just provides high-level guidelines. Inversion of control and dependency injection are usually used interchangeably. Dependency injection is one implementation of I.O.C., it’s a technique that allows objects to be separated from other objects that they depend on.

Dependency injection suggests that instead of making an instance of class b into class a using the new operation, the object of class b should be placed into class a using one of these methods constructor injection, setter injection, and interface injection. Another example of implementation in I.O.C is the spring framework. That contains instances and manages the lifecycle of the objects in the program. The user in the configuration file provides information that relates to what objects and dependencies are used by the application like Java code. The benefits of Inversion of control are that it makes the application easier to test and maintain, reduces the amount of application code, and decreases the coupling between classes. Inversion of control helps make your code more readable because of the absence of some components. At the end of the day, I.O.C is a design pattern that is very useful for software development and lets us know when action needs to be taken when something happens in our system.

https://www.theserverside.com/definition/inversion-of-control-IoC

https://www.educative.io/answers/what-is-inversion-of-control

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

From Learning to Doing

This week I was searching for an article to write about and I stumbled upon an article from Codecademy sharing the story of Juan Paredes, a Full-Stack Engineer from Mexico. The article is an interview of sorts where Juan has responded to prompts related to his journey from a Call Center Supervisor to a Full-Stack Engineer.

Juan covers how exactly he got into software engineering. When first moving to Mexicali, Mexico he got a job as a call center specialist. After 3 years Juan was promoted to Operations supervisor where at this point he decided to expand on his love for computers and wanted to start learning how to code through a free course on Codecademy.

After completing the free course, Juan decided to pay for a subscription and before Juan was completed with his first paid course, he was able to find an entry-level developer position. After figuring out that software engineering is what he truly wants to do, he also started attending the Mexicali Institute of Technology and is currently studying to obtain a degree in Software Engineering.

Juan also talks about how limited time and a pay cut made things temporarily more difficult but between his passion and determination, Juan continues to learn and progress.

When the article was created, Juan had just found a job with better pay and benefits than his first position and continues to progress forward in the software field.

Juan finishes off his remarks by recognizing the importance of organization and being open to learning new things as traits that will carry you far in the field. With organization, one can more easily find how to and be able to implement changes and by keeping an open mind you may learn things that while not valuable at the present, could become of great use in days, weeks, or months later on.

After reading this article I wanted to share and reflect upon it since I could relate to Juan. I too discovered my interest in programming through another medium of computers, however mine was video games. I started my journey by wanting to learn how to script in Lua for Garry’s mod addons and after that, I gradually kept learning more about coding. I never saw it as more than a hobby at the time, but here I am today almost finished with my Bachelor’s in Computer Science and preparing to join the workforce soon. Juan’s story serves as a reminder that through determination and perseverance, I can learn and do whatever I want within the extensive computer science field after obtaining my degree. It may take time, but in the end, the hard work will pay off regardless of how hard it may be or how much I would want to give up.

Article Link: https://www.codecademy.com/resources/blog/from-call-center-sales-representative-to-full-stack-engineer/

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

Suggested Standards for (basic) REST API Calls

In the past few weeks, we’ve finished the CS-343 semester focusing on designing/implementing REST API calls and interacting with back- and front-ends. During one of our classes, I recall a discussion about the fact that there are no unified across-industry “best practices” for writing API’s. Specific API structures and rules are common within teams but can vary from organization to organization, however there are some general habits and strategies. So I decided to do some searching and focused on a blog post on the website for Swagger, the REST API view/interaction software we’ve been using in class: Best Practices in API Design.

The post discusses some general best practices on creating consistent, well-designed API’s by focusing on three key characteristics: 

  1. Being easy to read, understand and work with
  2. Being hard to misuse, and in turn more intuitive for users
  3. Completeness and Conciseness – something which the post acknowledges frequently happens over time as developers build on top of existing APIs

Alongside some other basics on CRUD operations and how they correlate to standard REST API calls (get, post etc.), the post also dives into practices for writing effective call response messages. The codes for responses should follow the HTTP standards, where client-side errors return 400-level (4xx) codes versus server-side errors return 500-level and successful calls return 200-level. 

Arguably most important is providing thorough and clear explanations in response messages. For error responses, this entails providing detailed messages describing the error that occurred and suggestions/tips to address and debug it. As a part of this, it’s worth considering putting an example of a successful call to show proper syntax and passed parameters – handholding users will pay off with smoother API interactions long term. To reinforce this, the blog post recommends providing examples for all possible GET responses to demonstrate successful data access calls.

While specific implementations will vary by project/system, these are some good strategies and habits to keep in mind. The importance of providing examples for each individual GET response really sticks out and hits home for me. I can imagine with more complex systems and calls that may contain various request, query or other parameters it could quickly become confusing for users to navigate and access information they need. It seems worthwhile to also provide an example of a successful call in the error response for some specific situations, such as an Error 400 – Malformed Requested → providing an example successful request. 

Below, you’ll also find a link to a “glossary” of REST API parameters with explanations on their purpose and uses – a resource I also recently came across and have been finding valuable. If you have any other suggested “best practices” to keep in mind when designing REST API calls, please let me know in a reply or E-Mail.

  1. Blog Post: https://swagger.io/resources/articles/best-practices-in-api-design/
  2. Parameter Glossary: https://rapidapi.com/blog/api-glossary/parameters/

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Inversion of control

Inversion of control is a software principle that asserts a program can benefit in terms of testability and usability if the management of an application’s flow is transferred to a different part of the program. I.O.C’s framework takes the management of an application’s implementation away from the developer. When there are interactions that require custom business logic, the I.O.C framework will use the code provided by the developer. This is the “inversion” point of the inversion of control design principle. The most common application for Inversion of control is Java servers faces. I.O.C frameworks implement low-level and problem-prone activities, it allows the developer to focus on custom business logic instead of tedious tasks.  The one thing about inversion of control is that it can confuse what qualifies as an I.O.C and what doesn’t. Some examples of inversion of control are the use of event-based user interfaces, the use of shared cache, and the use of comprehension framework. The range of development changes that qualify as I.O.C contributes to the term. I.O.C is a principle, not a design pattern- the implementation depends on the developer. I.O.C just provides high-level guidelines. Inversion of control and dependency injection are usually used interchangeably. Dependency injection is one implementation of I.O.C., it’s a technique that allows objects to be separated from other objects that they depend on.

Dependency injection suggests that instead of making an instance of class b into class a using the new operation, the object of class b should be placed into class a using one of these methods constructor injection, setter injection, and interface injection. Another example of implementation in I.O.C is the spring framework. That contains instances and manages the lifecycle of the objects in the program. The user in the configuration file provides information that relates to what objects and dependencies are used by the application like Java code. The benefits of Inversion of control are that it makes the application easier to test and maintain, reduces the amount of application code, and also decreases the coupling between classes.

https://www.theserverside.com/definition/inversion-of-control-IoC

https://www.educative.io/answers/what-is-inversion-of-control

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

Blog #7

The pattern I read for this week was “Draw Your Own Map”. It was about how to create your own career path and not worry about what others think of it. This was a great pattern to read because it is so true. Everyone is living their own life in their own situation, and no two people are exactly alike. It was interesting to look at the different ways I can create my own career map, and be prepared for the future. This pattern started making me think about my own map now that my college days are coming to an end.

This pattern taught me to not take my current map too seriously as it can always change, and the map I have right now might not necessarily be the same map I have next year, and I am free to change it however and whenever I see fit. I have always worried about the big goals, and this pattern has also taught me to focus on the little goals that will build up to create the big goals. This can even make the big goals seem simpler as the little goals will build into the big ones. 

I do not have anything that I disagree with in this pattern as it all seems to be given as options for you, and not anything said as a fact. Your map should be your own, and nobody can tell you if it is wrong or not as nobody is the same. I think this pattern did a great job at making sure that, in the end, this is only for yourself, and it will be different from everyone else. There might be times when your map intersects with others, but it will never be the exact same. This pattern is very important for anyone to read no matter what your career choice is. Everyone should draw their own career map with whatever goals they have to go through their path. In the end, your career map should be unique to you, it can change as many times as you need throughout your life, and it should include all your goals you wish to achieve.

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

Record What You Learn

Ive grown to have struggled with my communication skills. I would propose that it comes from feelings of inadequacy. Growing up I spoke solely Khmer at home and going into school there was a short time of transition from one language to another. Fast-forward a decade or two the tides have turned, and I now struggle with Khmer.  What I recognize is the common factor within developing language and communication is one’s ability to write in each language. For one key factor as introduced in the Record What You Learn pattern, it says “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.” During my earlier stages of life, I don’t think I would ever have been able to understand this idea so much so that it would have led me to loathe writing in its entirety.

Though, as a graduating student, like many things, I have learned to love and develop a healthier relationship with things that may feel adverse. Like an opposing force school has been, I have learned to pull rather push against such a struggle. As I begin to make a shift, I wish to utilize writing more in any way that would serve me. As of now I see writing as a way to develop my language skills both natural language and coding/computer language, continue to use it as a way to develop ideas, and have it be part of my lifelong existence.

More specifically writing such as the writing in this blog has been an empowering way to process thinking and how to think. Of the many ideas that this blog has helped me develop, with the subject matter being the patterns in the reading, I’m learning to reflect on myself and record those reflections in way that crafts my “larger sense of purpose”. For example, recognizing that I like talking up all these ideas but never act on them, and starting to transition into learning how to take action and start making these ideas come true. The role in which writing has played has served as an oath to grow to my higher self, a mastered self. If I am true to myself these writings must be treated as a nursery to my ideas and the visions of the future that I have.

It is not only myself that I serve, but also for those that may have struggled as I did.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Apprenticeship pattern: Familiar Tools [featuring the Concrete Skills pattern]

Since beginning this undergrad program (really, the CS transfer program at my previous school) and starting my internship, I’ve found myself working in several different environments with several different tools. I’ve been able to scrape by in most of them, but haven’t stuck around with any one of them for long enough to become really familiar with it. I can specialize template classes and manage pointers in C++, but I don’t know how to use most of the standard library. I’ve grown from using a couple of Linux commands in a Manjaro VM to writing increasingly useful Bash scripts, but I’m not rapidly adding Linux commands to my toolbox. I’ve programmed in at least 10 different languages in the last year, but I’m not happy with my proficiency in a single one of them.

I think that this means that I need to start making use of the related Familiar Tools and Concrete Skills patterns, or at my own dot product reinterpretation of the two. The Familiar Tools pattern is all about developing consistency with a tool that you already trust yourself with, and Concrete Skills is about developing a proficiency foundation to build on. I have some foundation, but it’s split across a bunch of different technologies, and I need to rebuild it starting from a single tool that can become familiar to me.

The tool that I’d like to become familiar with is Rust. I share a lot of the general and technical priorities of that project. It’s great that it’s flexible and able to progress and fix mistakes without being paralyzed by a need to forever remain backwards-compatible. More importantly, I want to eventually work mostly with statically typed languages, and I love that it lets you opt into fewer levels of abstraction. For example, how cool is it that you can inline assembly in the same language that considers C-style undefined behavior to be a design failure?

Now that my formal education is ending, I’m going to use some of my spare time to develop my concrete skills in Rust by working on small projects. Hopefully, one of those will be working through Sedgewick & Wayne’s Algorithms again in Rust, some will be collaborative projects on fun things that I can’t yet get paid to do, and some will be projects where I figure out how to integrate a Rust backend with other tools that I need to learn more about anyway such as web APIs and AWS CloudFormation and Timestream.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Blog #6

The pattern I read for this week was “A Different Road”. It was about how sometimes the career you think you will have now can change, and you want to take a different path in life. Even if the change occurs, you will still take what you have learned through this path and apply it to the rest of your life. I really enjoyed this pattern because it has always been a worry of mine to suddenly want to go down another career path.  This pattern did an amazing job on that topic. It was interesting to read the views given through the pattern that were very useful to settle my worries.

This pattern taught me that it is ok to go down a different path than the one envisioned in the beginning because we are constantly changing as people, and we are not the same people today as we were yesterday. As I mentioned before, it was always a worry of mine to suddenly want to go through another career path after all the hard work I went through to go through this one. This shows how big the lesson that this pattern taught me truly is as I now am looking forward to whatever life has to bring me, and just hope that in the end, I am doing what I love as that is all that matters.

I do not feel like there was anything I disagreed with in this pattern. It brought up something that everyone thinks about at least once, and did not try to make a controversial take, instead left it to the reader to make whatever decision they think is right. That is a great way to deal with it because it does not give them a specific side on if you should stay or go, but instead lets the reader know that the decision is only for them to make. Whatever decision they come up with is the right one for them in the end. I think everyone should read this no matter your career path as career changes are universal and not only for software development. It might even help someone contemplating this dilemma come up with their decision.

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

Revisiting Construct Your Curriculum

In this penultimate blog post for school, I’d like to revisit the construct your curriculum chapter and talk more about a specific pattern in the chapter and further develop thoughts on it as I realize it was only briefly mentioned in said blog post. The specific pattern I would like to develop some of my thoughts on is the familiar tools pattern.

During this period of time, it seems to be quite advantageous to familiarize myself with the tools that I have been given, especially having a bit of an understanding of the job market, some foresight on my own abilities, and my general outlook on life and the world. Through a formal education I have been given more tools than I know what to do with; spending some time to clarify what those tools are, recognizing which tools may be most valuable to me, and gaining some practice with said tools, may support me in a way that is confidence inspiring and overall fulfilling.

When asked by those closest to me what was next for me after graduating college, despite some fears of rejection and judgement, I would respond with “I would like to spend some time getting my bearings”. Getting my bearings in a way that propels my career development and transitions me into a journeyman by utilizing my own reflections and acting upon them to eventually becoming masterful.

Setting Sights on Being a Journeyman

By no means do I see myself in the position to appoint myself to a journeyman, but I think it’s important to set a goal early on so that you have a clear vision of what you may be working towards. I wanted to revisit the intro as this is where journeyman is discussed.

Like my blog discussing the introduction I think that this is a fitting time to be considering such ideas. In the same way as the topics discussed in said blogpost, I believe that this not only applied to CS but can be applied broadly to life and career goals outside of CS. This idea is supported by the existence of apprenticeships in many other fields and careers.

There are two quotes from the journeyman paragraph in the intro in which I would like to explore more personally “This new focus is on the connections between practitioners, the communication channels within and outside the team.” And ends with a snippet on “Some of the patterns we will discuss are not appropriate for a journeyman, precisely because he has a greater responsibility to others who may see him as a mentor.” Seems crucial to keep this in mind and leads me into my next post.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Apprenticeship pattern: Craft over Art

Craft over Art is a pattern I’d like to start keeping in mind as I program. Because every functional specification can be implemented in more ways than any of us can imagine, I tend to think up the one best way that I can imagine how to solve a problem, and then continue solving the problems that come up on the way to that result.

There are two problems with this approach, both of which can be addressed by following the Craft over Art pattern. The first issue is that often, when trying to do a new thing, what I learn along the way indicates that there is some easier or more useful solution. When I treat programming as an art, these concerns are secondary to finishing the beautiful thing that I first set my mind on. In many cases, though, these realizations are a sign that it’s time to change plans in order to achieve some other goal that will be more useful or achieved more quickly.

The second problem with my process is that the best way I choose to set out on is often one of the artistically best solutions I can think of, not the way that most quickly results in a product with acceptable quality. As the author says, the professional goal of software development is to make useful things, not to write beautiful code.

I do think that, to some extent, writing programs in the most perfect way that you can is good exercise for developing mastery in an area of programming, as is continuing to learn and implement new ways to do things. After all, some problems really are suited to specific solutions, especially when some form of performance is important. For example, determining a superior route between nodes is a problem that should often be solved after considering the methods of graph theory. Sometimes, though, the stakes are low, and there really are no other concerns besides a solution’s approximate correctness and the speed with which it is implemented.

One of the main reasons that I like programming is because there is so much opportunity to be paid to work in a way that’s artistically fulfilling to me. But as an apprentice who wants to improve, I think that limiting this impulse to appropriate times is one of the most valuable skills that I can learn over the next few years.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.