Category Archives: cs-wsu

Comparing REST and SOAP API

APIs are what allow different applications to communicate with one another, making the intricate web we have access to today possible. Because the present world basically runs on the web, it is important to understand how the API system operates.

REST and SOAP API are the two main standardized types of APIs, and while the two work towards the same goal, that is, application-to-application communication, they operate differently.

Simple Object Access Protocol or SOAP API was developed by Microsoft in the late 90s. It was designed to be highly extensible so that future created functionalities could be added depending on the task for the API would be used.

Because of this extensible design, SOAP needed to be highly standardized, which is both an advantage and disadvantage. On one side, services written using SOAP API are very easy to error handle. SOAP is able to implement a built-in error handling system that even gives code suggestions for automated solutions, making it especially useful for users who do not own the web service.

However, on the other hand, while SOAP is compatible with any programming language, it was designed to rely solely on XML for messaging services. Though much of the process of writing the XML file can be automated or at least heavily simplified by the IDE using the Web Services Description Language (WSDL), this tool can only be used by NET languages (such as C# or F#). Other languages like JavaScript have to write each XML structure separately for each task, something programmers would rather not do.

Because of the more complicated nature of SOAP API, programmers later developed a simpler API system called REST.

Representational State Transfer or REST API operates using URL instead of XML to make requests. These requests are made through four basic methods: PUT, POST, GET, DELETE.

REST API is simpler than SOAP because it has the ability to use smaller messaging formats. It is also easier and often cheaper to use as it does not require the expensive tools to interact with web services that SOAP often utilizes. REST is also often faster than SOAP because it does not require extensive processing and can utilize the cache system.

Overall, the general consensus is that both systems are good at what they do and have their advantages and disadvantages. Programmers select which API to used based on multiple factors such as the language used, the environment, and requirements for the system or project.

In terms of my personal experience with APIs, I partook in an internship last summer which involved using Slack API and Python bolt — which are based on JSON-RPC — to send commands from a Slack channel to a raspberry pi. It was a simple program, but it helped me learn more about how APIs work and their important role in facilitating application-to-application communication.

For the future, I hope to look more into XML files/structures and familiarize myself with HTTP to learn more about using other APIs like REST or SOAP.

Source: https://blog.postman.com/rest-api-examples/

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Exploring Agile Methodologies: Extreme Programming

The purpose of the Agile Manifesto is to help development teams work more efficiently and sustainably. Within the manifesto, four key values and 12 principles are outline.

Though the Agile Manifesto was created to help make software development more efficient, most of the agile methods can be applied to any work situation. However, the XP method is one of the rarer methods geared specifically towards software development, which is why it caught my attention to learn more as a Computer Science major concentrating in Software Development.

The XP method was developed by Kent Beck in the 90s and is based mainly on five agile values: communication, respect, simplicity, courage, and feedback. These values support three greater principles: humanity, economics, and mutual benefit.

Humanity refers to fact that computer software is created by humans. Therefore, to efficiently create working software, it is important to take into account human needs, strengths and weaknesses through a healthy work environment and a supportive community.

Economics refers to being able to evaluate the risks and needs of the team and the collective project, weighing both the business values and technical concerns.

Mutual benefit refers to avoiding solutions that benefit one party at the cost of another. How this works exactly depends on the specific problem/solution.

In addition to these general principles, the XP method also details specific strategies for coding and managing projects, emphasizing communication and teamwork. The two strategies I believe to be most effective are “pair programming” and “informative workspaces”.

In pair programming, developers code in groups of two sitting at one computer. This strategy allows them to work together through direct communication and teamwork, producing code with fewer defects while also making the process more engaging.

I believe that pair programming has great potential, especially when the two people working together have good synergy and are good at communicating. However, while the strategy is highly effective for code production when pairs are compatible, it becomes a hindrance to progress when pairs are not.

The informative workspaces strategy is meant to make team progress and work details easily accessible. Whether through physical notes, charts, or dashboards, the workspace used by developers should display information that lets anyone know at a glance, the project progress.

I think informative workspaces is a great idea as it makes communication so much more efficient. Instead of having to ask a team where they are at before I can follow up with more specific questions, I can just go find out myself. Having such information also helps project management as it allows teams to know what parts of the project need special attention.

Teamwork is often difficult — and I say this from personal experience — but with a proper strategy like the XP method, working together on a project becomes not only easier, but also more enjoyable. For my capstone project next semester, I hope to apply some of these strategies to build on my teamwork skills.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Encapsulation | One of the Four Pillars of Object-Oriented Programming

There are four pillars in Object-Oriented Programming (OOP), one of which is ‘encapsulation’, which refers to the good practice of hiding the inner works of an object and its implementation details, where access is only possible through public methods. As one of the pillars of OOP, it is beneficial to me as a learning programmer to understand about the purpose of ‘encapsulation’ and how it can be effectively applied.

I realized during one of my classes — when we were reviewing these four pillars — that while I knew the principle by name, I had never learned encapsulation in detail nor how to best implement it into my code. Looking back at code I had written in the past, it was clear that I did not always follow this practice (i.e. using dangerous global variables as attributes in my objects).

The blog “The four pillars of object-oriented programming — part 1 — encapsulation”, written by Bas Dijkstra, helped better illustrate for me what encapsulation is supposed to do.

Firstly, encapsulation is all about making attributes private. By doing so, an object’s attribute is protected from being accidentally — or maliciously — altered. Instead of accessing the attribute directly, the value can and should be returned through a public method within the object, essentially making the attribute ‘read-only’.

By doing this, a programmer gains more security and control over the code, reducing the amount of unwanted behavior in the system as a whole.

Secondly, good encapsulation is the product of good design. In another blog, “Encapsulation in Functional Programming”, by Mark Seemann, which I found by looking deeper into the strategies of implementing encapsulation into code, talks about creating a ‘contract’ for each class. The contract outline three properties of a class:

  1. Preconditions — what are the minimal requirements for the object to function?
  2. Invariants — which attributes of the object do not/cannot change?
  3. Post-conditions — what are the boundaries/rules of the object after it is created?

Though the article focuses more heavily on encapsulation for functional programming, the design strategy also benefits OOP. Having these properties outlined in the contract of a class helps the programmer understand not only what needs to be encapsulated, but also how it can be encapsulated.

In addition, because of the nature of encapsulation and the amount of control it provides a programmer over the code, testing for such classes that follow the principle becomes much simpler and easier to do .

While a simple principle, encapsulation is a powerful and practical strategy that makes code secure and easy to manage by hiding the inner works of a class behind public methods.

Sources:

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Launch

Welcome into David Castillo first blog post. Currently I’ll be using this blog post mainly for CS-343 course. This will be the start to something new that I will keep updating in the future.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Testing 1…2…3

Hello there! Welcome to the blog! (^-^)

My name is Namson Nguyen. I love baking, playing the piano/violin, and learning new languages and their respective cultures.

However, the purpose of this blog is not to talk about myself, but rather, as a Junior majoring in Computer Science, it is to discover more about the huge realm of technology, as well as to hone my self-researching skills — an essential tool in the professional world. Through the course of my college years, I hope to share with you my favorite reads and fun discoveries, summarizing what I’ve learned as well as my own personal thoughts (excluding those about pastries, français, and the fiddle of course!).

So I hope you’ll follow along with me on my journey as a student in this rapidly advancing technological world. There’s a lot to learn and a lot to see in the next few years and a whole lot more after that.

Cheers!

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Week 1 (Introduction)

Hello, my name is Elias Boone. I am a Senior at Worcester State University, and my major is in Computer Science with a Software Concentration and a minor in Music. Since this will be my last year at Worcester State, I am taking time with this class to eventually figure out what topic I should focus on for the Capstone class next semester given my interests and background.

For this first week, nothing much has happened other than the few preparations I have made for this class and with my schedule. I have had this professor before in some of my previous class in my major, but all of my classmates are completely new people that I will have to adjust to for next week. I am a little bit nervous about this class since we will be going over lots of technical programming topics. While I am very fluent with the programming language Java, I am not very good with the other programming languages, so I will have to gain an understanding of some of the other programming languages that may be in this course. Other than that, I will have to wait and see how this class goes as the semester begins!

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

Whats Next?

I have had this unhealthy assumption in my mind that CS is just preparing us to just sit at our desk all day and write code for hours upon hours(at least in the industry context). Although, in the cases where this may be true, for those that are in that position, there may be a good chance that they are doing what they enjoy. I don’t see this being the entire case for me. Knowing this, a couple questions and thoughts come to mind; in exploring different roles one can play in the tech industry, where may my own opportunities lie? Can I recognize what I am learning in relation to that, maybe even evaluate how/what I am learning to where I might see myself? Can I map out my career?

I think it is important to ask such questions while taking these CS courses. While asking such questions during the courses I can recognize where my strengths may lie and discover possible passions/interest. I am prone to overthinking(especially with complex ideas) and such practices allow me to step back a little. Going off previously stated questions, there is something about the front-end that is quite alluring to me. Which leads me to an article that I found titled “Exploring the front-end of project management”

Although it doesn’t talk about specific front-end development tools, (a topic in which I would like to look more into) and more so on what comprises the front-end and the role of management, it is a exploration into the front-end, or defined in the paper as the “earliest stages of a project”.  I think that the article is still relevant as we can recognize that the POGIL group work style of the class allows students to be able to work in groups, the prevalence of different roles is to almost simulate the professional setting in which on may work. This style teaches students to be able to work well with others and communicate very complex ideas. I personally find a lot of enjoyment in working in groups and struggling and learning together, specifically; exploring and playing with the different roles from manager to presenter, working through unexpected situations through analysis and modification, and sharing finding with the entire class. From my brief research, the front-end to me seems to be where I can explore not only different roles but explore even more broad experience from different aspects of the tech industry.

On a different note, I made an observation in my last post about the nature of the learning that is done in CS and how topics can connect. I described that connection of topics as niches. I wanted to make a correction and niches may not be the right word. Perhaps, layers, at least in the context of this class I could argue that front-end being a layer in software development is more suitable. If anyone gets what I am trying to say and can find a better way to word it, please let me know.

https://doi.org/10.1080/21573727.2013.775942

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.

Thoughts on Front-End Development

I often find it hard to relate back to other courses and easily forget about what I have previously learned. Luckily, my memory is not as bad as I think it is and it eventually comes back to me, especially in the case where I have to come back to a skill/technique regularly. I find that with Computer Science the evolution of knowledge is one that is clear yet has a depth of knowledge that intertwines one course with the next.

On one hand, you can have a course that is so specific in a niche of CS that it may be hard to see its relevance in another CS course on the other hand you may have a course that is seemingly so broad that it is hard to pinpoint how it may carry over.

I think that with any specific area of interest, as one continues with their education, the degree to which prior knowledge is necessary and relevant to learning a new topic only increases the further you progress.

All this is to say that last semester I took a cloud computing course and I remember that course being broad in its application of cloud computing. I wanted to look into the use of cloud computing in the context of software design and architecture. Secondly, after only getting a taste of front-end development in this course I wanted more and I wanted to solidify my understanding of the back-end and front-end in an attempt to satisfy a goal of mine described in a previous blog post.

Overall I’m not seeing any major differences between implementing software through the cloud vs other options other than the vast benefits that cloud computing can offer. Benefits of cloud computing range from storage, server, database, software networking, intelligence, and analytics. The blog begins with describing what cloud computing is then goes into detail about what front-end and back-end cloud architecture is along with cloud based delivery.

I was then led to another blog about specifically front-end development as I was not satisfied with what the previous blog provided. This blog hooked me with its first line saying “Front-end developers need to design sites that are engaging enough to nudge the target audience toward a conversion.” I find this idea to be very interesting because it starts to dive into the purpose of front-end development.  In my next post I will discuss where I may see myself in the future and what role I might want to play in the tech industry. There is a point in the blog in which the duties of a front-end developer are laid out leading to an intrigue and wonder about whether this is a niche in CS where I may see myself, in front-end development I feel it might be a role in which I can use a variety of skills/techniques in order to develop myself.

https://www.clariontech.com/blog/cloud-computing-architecture-what-is-front-end-and-back-end

https://webflow.com/blog/front-end-development

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

Smells and Senses

I want to focus this blog post not on something that I’m interested in but rather something I think that I should know. I decided to put some more research into design smells, this topic seemed valuable because I have this perception that understanding and looking at code is not a skill that I have yet to developed. I wish to improve upon this, so I found this presentation on code refactoring and design smells that is pretty in depth and it goes into a little more detail about what we had discussed in class. In the class activity we connected technical uses of the word to technical definitions based on our understanding of the common definition. This activity provided a basis for understanding different smells. This led me to find a higher-level presentation on design smells and grasp some level of understanding of what was being discussed. In the video the speaker Sandi Metz suggests that when you can identify a code smell you can then refactor the code to better suite future use. What refactoring is, is the ability to rearrange code without changing its behavior. The ability to look at code and associate information is exactly what I am looking for.

There were a couple of ideas that stood out to me. The presenter offered an analogy that stood out to me that  refactoring is kind of like a recipe. Sandi then provides a valuable resource that maps specific code smells to a reference in Martin Fowlers book , a refactoring recipe that is “curative”  to that code smell. This leads me to another suggestion that it is okay at some level to “own your code smell” if it is working and won’t change in the future. This reference to Martin Fowlers books immediately reminded me of his very informative blog. The book itself seems very interesting to me and could potentially offer a wealth of valuable knowledge that could vastly improve my abilities.

As an avid home cook this analogy spoke to my soul, all this talk of smells and recipes sparked an understanding of code that I was not familiar with. In my journey as a home cook, I have been exploring the ability to make food more creatively as instructed by a transformative cookbook that I have been reading. There is an idea that I have been working on that suggests not following a recipe and relying on your senses and being actively involved to create a wonderful dish. I find that this relates heavily to my journey in becoming a software developer, taking information from outside resources and interpreting it in a practical way all while relying on my senses and built intuition.

Click to access smellstorefactorings.pdf

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.

Intentions and Goals Part 2: Defining Needs

Setting goals allows me to take things one at a time and move over those self-imposed barriers effortlessly, but it is the learning and the love of the process that don’t even allow me to put those barriers there in the first place.
Now on to one of the actual goals, I have been wanting to use what I am learning as a computer science major to implement into my current workplace. I think that it has been a great opportunity to work there and they have provided a good environment for self-development similar to that of being in school. As a token of appreciation, it would mean a lot to me to be able to leave something useful behind. That something useful would be in the form of Software. In the past year or so I have had a level of engagement in my courses that I haven’t had in a while and that is most likely due to recognizing the practical application of what I’m being taught. This has led me to be vigilant at my workplace and observe problems that can be solved with software. After figuring out what the problems are and defining those issues
For a while, I have been stuck on what to do now after defining the problems from the software development class, and based on the topic of my last two blog posts it is clear to me that figuring out suitable architecture is important to a well-developed software system. To do this, I need to understand the important requirements of the users involved. Currently, I am under the impression that microservices architecture would be most suitable as many of its defining characteristics would fulfill the requirements of the business. Within this process of developing software, I am learning that there is a lot of picking and choosing systems that are specific to the needs of the business. Although it can still be overwhelming, I am relieved that there are already many preexisting systems and that picking and choosing make it a little easier instead of having to completely create something from scratch. On the aspect of picking already developed systems, the topic of API comes into mind I found this useful article outlining different APIs and their use cases and how some are still in use today and fit specific needs. The article points to the idea that even though some APIs might seemingly be outdated that they still have a use case that only requires such an API and nothing more.

I understand that I still have a lot to look out and plenty to learn but recognizing that there is a direct application to what I am learning provides some great motivation and hope that will allow me to continue to get over whatever barriers may be in the way whether self-imposed or not.

https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/

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.