I chose the blog post, “Designing for the Unexpected” by Cathy Dutton because it addresses how one can create designs that can combat unexpected content changes. The blog shows us strategies that we can use so we don’t get stuck in situations like this. On my own time, I have been learning how to create in the web design space so that was one of the main factors when choosing this blog. This is what led me to choose this blog post, so I can learn how to not make mistakes and so I can follow the strategies laid out to design in the most efficient way possible.

In the blog, Dutton explores strategies for creating adaptable web designs that accommodate unforeseen content changes and evolving device landscapes. She reflected on the evolution from fixed-width designs to responsive layouts, emphasizing the necessity of planning for flexibility from the outset. Dutton recounts her early experiences with web design, and  highlights the challenges of transitioning to responsive design, noting that it requires comprehensive planning during the design phase rather than being an afterthought. To implement responsive designs, Dutton initially utilized percentage-based layouts with native CSS and utility classes, later incorporating Sass for reusable code and more semantic markup. Media queries played a crucial role in this process, allowing designs to adapt at specific breakpoints to maintain readability across different screen sizes. However, she observed that this method often necessitated complex markup, posing challenges for content management, especially for users without extensive HTML knowledge. Dutton introduces the concept of intrinsic design, a term coined by Jen Simmons, which leverages new and existing CSS features to create layouts that respond organically to content and available space. This approach employs the ‘fr’ unit to distribute space flexibly without compromising content legibility, enabling designs to adapt dynamically to varying content and container sizes. Intrinsic design moves beyond predefined breakpoints, fostering components that are inherently responsive. The article also discusses the limitations of relying solely on frameworks like Bootstrap for responsive design. Dutton emphasizes the importance of designing for diverse user contexts, acknowledging that users interact with websites across various environments and devices. By adopting flexible design principles and focusing on content adaptability, designers can create resilient and future-proof web experiences that cater to unforeseen changes and diverse user needs. The blog advocates for a shift towards intrinsic design methodologies that prioritize content flexibility and responsiveness. By embracing CSS advancements and moving beyond rigid frameworks, designers can craft web experiences that gracefully adapt to the unpredictable nature of content and device evolution.

From the blog, I was able to learn the best strategies when it comes to designing an adaptable web interface. Going forward, I plan to incorporate these strategies as I continue to learn more about designing web pages. After reading, I feel like I will be able to increase my learning in this area as well as be able to share these strategies with my peers.

https://alistapart.com/article/designing-for-the-unexpected/

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

I’m very unfamiliar with REST API’s but throughout most of our classes I’ve learned that they are very important especially in moving forward with development as a career. Since I was not very familiar with the topic I wanted to look up the basics of the API’s functionality, this is the site that gave me that information https://www.redhat.com/en/topics/api/what-is-a-rest-api. This site is basically documentation describing an API, REST API and REST all in their own individual categories.

The documentation covers the basics of REST such as the client-server architecture and communication, the representation of the requester and endpoints and the format the data is actually transferred through and the guidelines of the REST functionality as well. This post also covers the topic of what an API has to include to be considered a RESTful API, disregarding the aforementioned topics it covers the specifics of how the resources that are used by the client and modified on the server should react. Cacheable data that is transferred between both the client and server is also a topic brought up which I think is actually the most important since any data lost between actions would result in a broken / useless API.

Since I’m very uninformed on the topic of REST and I haven’t setup any personal development environments to work with such a thing, so I won’t be putting much of this newly gained knowledge to use as of this moment, but learning about it for future reference will definitely help me in the long run. I’ll most likely setup the development environments needed and study up more on the internals and all of the languages that work best for this type of development since understanding server and client architecture does not only represent working with REST. It also represents working with pretty much any application that multiple of your clients will use depending on what they ask for. This also gets more into the request part of the communication which I have never really looked into in depth, so being able to see how it functions will also help my understanding of most other server-client / client-server communication.

Honestly when we first discussed REST in our classes I still didn’t really understand the entire process of what exactly was happening. Reading through this post again though, definitely clarified some of the topics we went over and more, especially more into the back-end side of the API. Going forward I will continue to research more into REST, it seems very interesting to me and again, will be very helpful in understanding more about architecture in bigger programs.

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

Hi class,

For this blog post I decided to choose the topic code review. Code review is one of the topics that we went over this course and furthermore, could be very beneficial for all of us to learn even more how code review is executed.

For my resource of code review I listened to a GOTO Conference talk in Berlin and here is the link to the video: https://www.youtube.com/watch?v=ly86Wq_E18o&t=142s. The video is of a man named Alejandro Lujan, who has been a software developer for more than 20 years. Alejandro goes on to state he knew code review, but not to the extent from when he got his most recent job at Shopify. It was here at Shopify his aspect of code review vastly improved. (I chose a video format because I like listening to the speaker better; I can understand said topic more with a personal connection.) 

Alejandro’s first couple months at Shopify was not what he expected. The code reviews were a lot more “harsh and intense” than what he was accustomed to. Alejandro took the code reviews very personally, thinking he is a bad coder and maybe the team does not like him. After pondering these thoughts for a couple of months, he looked at the work he was contributing and the comments were not about him, but rather his work. He quickly realized the code review at Shopify was not simply just a code review and then Alejandro went on an arch to fully understand code review.

Through the following months, he realized that great code reviews are symptoms and contributing cause of highly effective teams. From here there are two sets of people in the equation, the author(s) and the reviewer(s). From here, he would state that there are four important aspects to code review which are building the right thing to achieve an objective, building it correctly, fast, and together.

For building the right thing to achieve an objective. He goes on that from the very early stages of coding, you should show proofs; this will ensure you are on the correct path and if not, it’s an early change to fix. 

Building it correctly involves utilizing GitHub and all the features it has. Alejandro states you must label work correctly. For instance rather than using a PR use a draft PR on GitHub. Along with this, GitHub has a feature stacked PR; several PRs are reliant on each other. He states that wanting a deeper code review, this is a must rather than have all PR’s in one. He also acknowledges it’s possible to create too many small stacked PRs but still has yet to encounter this. Stacked PRs are a powerful technique and should be implemented in code reviews to help team projects. Lastly, to ensure your commits are easy and understandable.

For building it fast he states by doing the above, it’ll be faster in the long run rather than sprinting to try to get the code done all in one commit without any peer review prior. Showing proofs/feedback and using stacked PR’s on GitHub; taking it one step at a time to achieve the goal.

Building it together means you need to have a team oriented mentality. How can WE improve this thing, not how can I improve this thing. Along with this, you should provide actionable feedback to other teams, rather than “this is not great” provide a direction of how things can get better. Alejandro also acknowledges that too many people in a meeting/code review could not always be beneficial. You as the author need to question if it would be beneficial to have the feedback of everyone and have a 10 person conversation in GitHub, or rather to include two people only who are skilled in said task. If it’s more beneficial to only have a few people, make sure the results of the conversation are reflected on the PR.

Alejandro then goes on to wrap up his talk with five takeaways:

1. Keep PRs small
2. Share drafts early
3. Focus on the work, not the person
4. Offer actionable feedback
5. Pick the right people

From understanding and implementing these takeaways, the code review will be a lot more deeper in the understanding of why something is being changed and also the importance of a great code review. 

My personal comments about this is that as a developer you are always learning and will never be “done” in terms of learning. Furthermore, as a developer you must be willing to adapt quickly. Alejandro had twenty years under his belt and then coming to a new job seemingly had his world flipped upside down, but rather than being timid, he adapted. Along with this, at the beginning he was talking about taking his coworkers comments personally, which was not the case at all then after realizing this, he strived forward. I think this is a great story and has taught me that to be in this field, you must be adaptive and code review is simply not “code review” but rather steps and processes compiled to make code review.

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.

This week’s post will cover a powerful and popular frontend tool, Node.js, that enables developers to execute JavaScript code outside the browser. By allowing JavaScript to run on the server side, Node.js has transformed the way developers approach web development, enabling full-stack JavaScript applications. The blog by Matthew Clark highlights the common uses for Node.js, for example, Node.js is often used for building real-time applications, such as chat apps and collaborative tools. Additionally, Node.js is a popular choice for developing REST APIs and microservices, enabling efficient handling of API requests and data exchanges between client and server. Another common use case is single-page applications (SPAs). These applications rely on seamless interactions between the frontend and backend, and Node.js allows developers to use JavaScript across the entire stack.

The V8 Javascript engine compiles JavaScript into machine code, ensuring fast execution, making speed one of the primary advantages of Node. The speed of a platform is crucial to creating an enjoyable user experience. No one enjoys a slow program. Additionally, Node can handle large volumes of simultaneous connections efficiently. Arguably the most important advantage is scalability. Node.js is designed to scale horizontally, allowing applications to handle increasing workloads by adding additional resources without significant architectural changes. Developers can use JavaScript on both the client and server sides, reducing context switching and improving productivity. This consistency simplifies debugging and maintenance.

Node is used by major companies like Netflix and PayPal. Netflix is particular uses Node.js to improve application performance, specifically for the server-side rendering of their video streaming platform. Its lightweight nature has helped Netflix handle millions of user requests with reduced startup time and increased efficiency. PayPal made the switch to Node to unify their frontend and backend development. This shift resulted in a significant reduction in development time and improved application response times.

One drawback to this tool is the asynchronous programming model, this model relies heavily on callbacks and promises. While this enhances performance, it can increase the complexity of debugging and code maintenance.

I chose this topic of research because it’s one of the most popular connection tools for frontend and backend development, and for good reason. One other tool that I came across during my research was Deno, a modern runtime for JavaScript and TypeScript, created by Ryan Dahl, the original developer of Node. Unlike Node, Deno is secure out of the box. It runs scripts in a sandboxed environment, requiring explicit permission to access files, networks, or the environment. Additionally, Deno has native TypeScript support and doesn’t require additional package managers.

Blog Post: https://dev.to/mattclark1025/why-node-js-for-web-development-in-2020-2ebc

From the blog CS@Worcester – Computer Science Through a Senior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Clean code is an important aspect of a software developer’s skill set. It means writing code that works well, and is easy to read, understand, and maintain. Three key principles of writing clean code are conciseness, reusability, and a clear flow of execution. Each principle in its own way contributes to the ease with which the software development process proceeds and the reliability of the end product.

1. Striking the Right Balance Between Conciseness and Clarity:

Finding the right balance between writing concise and clear code is very important. Concise code can make the codebase easier to read and it reduces the amount of time spent writing it. However, being too concise can make the code difficult to understand. The goal is to keep the code brief but also easy to read and understand without losing its purpose or logic.

2. Reusability

Another important principle of clean code is reusability. Writing code that can be reused in different parts of an application or across different projects saves time and reduces redundancy. Reusable code leads to a more modular structure, which makes the codebase easier to maintain and enhances its flexibility. It not only speeds up development but also makes it easier to fix bugs and make future updates.

3. Explicit Flow of Execution

A clear flow of execution is one of the critical characteristics of the code that guarantees its readability and ease of maintenance. A not well structured code leads to a condition where it is difficult to maintain a project. A logical and straightforward flow of code is easy to perceive by a developer, which is necessary for the code support during the whole life cycle.

4. The Single Responsibility Principle (SRP)

Every module or class should have only one responsibility. This decreases complexity, thereby making the code base manageable. Testing  and debugging, with development and improvements for future maintenance, are all greatly simplified, hence, the software becomes easier to use and much more understandable.

Conclusion

The balance between conciseness, reusability, clear execution, and following the Single Responsibility Principle will definitely allow developers to write clean code, benefiting the whole process of software development. Clean code is not simply error avoidance, but also it improves collaboration inside the team, makes life easier for new developers, and significantly increases the speed of code reviews. This will definitely result in efficient, maintainable software with easy adaptation to changes. Keeping these principles in mind allows me and other peers to create software that is functional, yet high quality and user-friendly. Even though we have done Clean code in Software process management class, reading this article helps as a reminder for writing code as best possible and also comes with examples which I did not include not to make this blog post too lengthy, but I suggest everyone to go and read it.

Citations:

https://www.freecodecamp.org/news/how-to-write-clean-code/

From the blog CS@Worcester – Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

Link to blog: https://medium.com/js-dojo/how-is-vue-js-making-the-javascript-world-a-better-place-b3dc39ba4fe7

It’s the end of the semester, and the last thing we covered in class was a bit of front-end structure and how things work. Of course, there’s your HTML and CSS, and I understood that. But we were using Vue in our examples, and I got curious. I’ve heard of Vue before but never used it, so I was interested in its purpose. Such curiosity led me to Fotis Adamakis’ blog post How is Vue.js making the Javascript world a better place. We’ll be discussing the contents of this article today.

Adamakis’ blog post is quite in-depth compared to past articles we have covered. He believes Vue is quite beginner-friendly, as learning how it works and beginning to write code could only take a couple of days to a week (as long as you have some knowledge of Javascript, HTML, and CSS). Adamakis dives into some interesting parts about Javascript frameworks and how Vue approaches them.

Routing can be a potential challenge when it comes to tasks such as custom scroll behavior, nested route view mapping, and more. Vue has its own Router, and it configures the routes before any components are rendered. 

Vue’s approach to the architecture of a site supports component-building. To be more efficient, it includes single-file components. This is a beneficial feature of Vue, as it can contain HTML, CSS, and Javascript all in a single file. Adamakis also mentions Vue’s high satisfaction rating, with the majority of developers wanting to use it again! 

Adamakis mentions that Vue is great for testing too, as it has built-in support for Mocha and Jest unit testing or end-to-end testing with Cypress or Nightwatch. 

Adamakis concludes by stating that he feels Vue has combined all great parts of other Javascript frameworks into one, being easy to use with great documentation.

I selected this resource because it educates me more on why Vue is so popular and what it does well. It also has example videos to highlight the reasons and is well-written and easy to understand.

I found this to be a solid article for learning more about Vue and why it’s preferred. I also learned how Vue’s state management works. It’s interesting that with Vue, you can incorporate HTML, CSS, and Javascript into a single file. Perhaps it’s beneficial for the simplicity or organization of different web pages/parts of a page? Having all of the pieces of a component on one file is probably quite helpful. I hope to apply this to new web pages I might try and build (I would like to get more into building websites!).

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.