Hello everyone, we are back and doing it again this semester. Tech Worth Talking About returns with posts about two courses, CS443 – Software Quality Assurance and Testing as well as CS448 – Software Development Capstone. CS443 will focus more on strategies and tools for automating code testing as well as how testing incorporates into the overall development process. This goes far beyond simply debugging.
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:
Being easy to read, understand and work with
Being hard to misuse, and in turn more intuitive for users
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.
Integrative softwares and tools like Dev Containers and GitPod can be invaluable for development teams/tasks, commonly used for its benefits in ensuring portability and uniformity in team based development environments – amongst others. However setting these tools up to be ready to begin working can be time consuming; furthermore, development projects often require running several hardware-intensive applications simultaneously which can cause delays due to hardware constraints and inconsistencies across teammates. These factors can quickly eat into time allocated for team/project work and create a weak link in a team if one (or more) teammates are falling behind trying to get set up.
Recently, this is something that I’ve experienced and observed frequently in class as we incorporate more toolkits and work on more intensive projects. With Dr. Wurst’s suggestion of implementing GitPod as a way of addressing these difficulties, I decided to do some reading into what GitPod is and other solutions.
Coder is another cloud-based developer environment which is an alternative to GitPod with some key differences. In Coder vs. GitPod: Which is Better for Your Team? Computer Science professionals Ben Potter and Mark Milligan consider the pros and cons of both with a focus on helping readers choose the best fit for their development teams. GitPod targets individuals and small teams with SaaS offerings focusing on an easy start and integration with several IDEs and containers, making it a great fit for web application development. Plus, with their current offering of 50 hours free monthly (and modestly affordable packages if this isn’t enough) there’s minimal price barrier.
On the other hand, Coder is oriented towards large-scale teams and organizations/enterprises, offering a self-hosted solution for on-premises or public cloud deployment. It prioritizes security and flexibility, allowing workspaces to be operated on a variety of infrastructures like Docker and other VMs. Being business-focused, Coder also provides several enterprise related features like single-sign-on, audit logs, usage metrics and more while supporting several IDE’s and containers, VM’s, etc.
It’s important to keep in mind that the original post was hosted on the Coder blog medium and may be biased as such, though the authors seem to try to take a fair stance and highlight the cases where GitPod would likely be more applicable than Coder. This comparison helped me get a better understanding of some of the capabilities and advantages of tools like GitPod/Coder. Plus, learning about Coder as an alternative to GitPod focused on large-scale enterprises that may be geographically spread out is awesome as an individual who intends on entering the CS field after graduating this coming Spring.
Over the past few weeks, our in-class activities as well as our last assignment for CS-343 have required running Docker in conjunction with a Dev Container in VSCode. While I was able to follow the instructions given and complete our assignments using these tools, I struggled getting started and navigating through some of the components for in-class activities at times, impeding my ability to work efficiently and keep up with my team. To make things worse, I didn’t have much of an understanding of what each component did and why it’s being used. So, I decided to do some research on these topics, particularly the relevance, benefits and drawbacks of using Dev Containers and how they are connected to VSCode and Docker.
In my search, I found Getting Started With Dev Containers, a blog post by CS professional Dave Storey which clarifies a lot, beginning with addressing why Dev Containers are used. Setting up development environments can be a lengthy and tedious process depending on prerequisites, dependencies or other implementations. Dev Containers utilize the power of containerization – bundling all files, SDKs etc. needed to run an application for several benefits like lower overhead, portability, consistency, and more.
There are some general advantages and disadvantages of using Dev Containers to be aware of. For starters, they guarantee a consistent development environment regardless of the hardware/operating system being used as long as it can run the container. Similarly, there’s guaranteed consistency across toolsets that each teammate is using, so everyone is familiar and there is no communication or project friction caused by inconsistent setups or toolkits. It’s also quick and easy to integrate a new member to a team/project by instantly setting them up with the same development environment in use by the rest of the team. Dev Containers are reusable and adaptable for other projects, providing long term value by saving time on project set-up.
While there’s lots of advantages, there are also drawbacks that should be considered when strategizing projects and contemplating the use of Dev Containers. There’s an upfront time/cost barrier in setting up the container and its configurations – though available templates make this process easier. To this point, you need to have a basic understanding of Docker and general containerization to set up and maximize benefits from Dev Containers. And, when dependencies and other components become deprecated, maintenance needs to be done to make sure that Dev Containers are up-to-date and usable as they are (usually) not part of main code repositories.
This helped to clarify things based on what we’ve worked with in class. Dev Containers are using VSCode like an IDE/server which communicates with Git and runs our code in the Docker container. Our implementation in class lets everyone deal with the same tools and environments to leverage these mentioned benefits for group learning projects as well as individual assignments.
In today’s world, businesses, organizations, and other entities that software and web developers consider “clients” heavily rely on being able to efficiently collect, access, and otherwise manage data for their day-to-day operations. For many, losing access to databases or similar outages hinders their ability to continue operations. In Data Redundancy: Meaning and Importance, author Charlotte White discusses data redundancy and some basic strategies and implementations to address these vulnerabilities.
Data Redundancy goes beyond simply having backups of existing data (although they’re an important component), it’s a proactive plan to prevent data loss and maintain smooth operations in the case of a server shutdown, hardware malfunction, or other major disruptive issue. It’s crucial for ensuring the continuity of business operations as website downtime often leads to financial losses especially for new websites or those with low traffic. Outages can also impact search engine rankings, as uptime is a factor commonly considered by search algorithms. Furthermore, failure to do so resulting in data loss can result in crashes/issues in other systems, loss of customer information, business details, and other critical and/or confidential information which is essential for an organization’s success and reputation.
How Redundancy Works: Effective redundancy designs reduce dependency on any single copy of data or data center. They commonly implement a 3-2-1 rule of backups, which means having three copies of data in two different locations, one of which is offline storage. Redundancy strategies should also consider factors like hardware redundancy; many servers use hard disk drives (HDDs) to store data which can fail due to simple wear and tear. Some hosting companies use RAID (Redundant Array of Independent Disks) and un-RAID solutions to mirror data from HDDs to other storage devices, minimizing the impact of HDD failures.
Recently in CS343, we’ve been looking at software architectures and strategies for organizing systems that could be realistically implemented to address clients’ needs. In particular, we’ve been considering the differences and strengths/weaknesses between a simpler architecture such as the Monolith versus a more complex architecture such as the MicroServices model, with several intercommunicating systems.
Most of the scenarios we discussed involved the ease of pushing out updates, but I was left wondering about the repercussions and ways to manage the possibility and reality of a database or system going totally offline. For businesses involved in eCommerce, uptime is money in terms of sales as well as maintaining search engine optimization. Given how damaging a disruption like this could be, data redundancy plans are an important consideration when planning and setting up a website or system. Understanding the value of D.R. and how they are implemented is an asset in planning and designing software systems and projects, and generally beneficial for computer science students and professionals.
An age-old discussion in the computer science and Object-Oriented Programming world is whether/when to implement interfaces or inherit through abstract classes. In these first few weeks of CS-343 we’ve been working on several activities discussing some of the strengths, weaknesses, and differences between interfaces and abstract classes. In the past I’ve worked on some mid-modest sized projects which include both and can think of a few great examples of using each, but I found that I still struggled to understand some of the basic conceptual differences. So while I had a solid grasp on some effective use cases, I didn’t have a very clear idea on how to choose one/the other when in design stages where a lot less may be known about the project and how it may take shape later on.
Interfaces or Abstract Classes is a blog post from 2017 that I came across through web searching which explains some of the key conceptual and strategic differences between abstract classes and interfaces. Author Suhas Chatekar begins by discussing some of the most common responses he has received when asking this question in interviews. Abstract classes are typically preferred if there are suspected to be changes/additions needed later on. Interfaces are considered best when there are likely to be many different definitions for the same inherited methods, or as a possible alternative or substitute in multiple-inheritance in languages which do not support it (like Java/C#).
Often it’s difficult to verbalize these differences, but this pretty well summarized my understanding. However, these philosophies focus on using interfaces to get around a syntax/language obstacle rather than as a best-case tool and are what Chatekar dubs “futuristic”, in that they rely on a programmer to know how the program is going to turn out longer term at the beginning which is simply unrealistic on a large scale project. Instead, he suggests an approach of considering interfaces as establishing a “can-do” relationship versus abstract classes creating a “is-a” relationship.
In the past and in CS-343, I’ve heard these terms thrown around and attached sometimes, but this post helped me to better understand the value in this approach and line of thinking for project planning. Commonly project components and requirements shift over the course of a project as unexpected needs are identified and addressed which cannot necessarily be planned for, so a futuristic interface-versus-abstract decision process seems likely to fail or be significantly less effective than a simplified approach focused on anticipated “is-a” and “can-do” relationships. One of my first and favorite interface/inheritance example projects simulated a Chess game using Java with a ChessPiece abstract class as well as a PieceAction interface; Regardless of later complications, each piece “is-a” ChessPiece, and “can-do” all PieceAction’s. This approach helps plan for future project events and needs in a more present state of mind, especially in long term projects that may include both.
AutoHotkey (AHK) is a powerful and versatile free, open source software and scripting language for Windows operating systems exclusively. It provides an environment where users can create custom scripts to automate repetitive and/or menial tasks, create custom GUI’s, manipulate windows, files and applications, and create custom hotkeys, macros, and key-rebinds. Users can quickly create and tailor scripts toward specific tasks they face to significantly improve their overall efficiency and minimize errors. In essence, AHK can be used to automate and otherwise enhance users’ ability to perform software development and other processes from start to finish.
Upon downloading AHK, the main Dashboard GUI has several useful features to help users get started and in general as they create scripts, including a compiler, link to Help Files, Settings, and a Window Spy tool to extract application window data. Using Window Spy, users can easily identify and access a window’s “ahk id” to hook into and directly input to that window using AHK methods, such as ControlClick, which sends mouse inputs to a given client at a specified x-y mouse coordinate. Conveniently, the Window Spy tool also provides functionality to easily identify the on-screen/client x-y coordinates of a given mouse position. There are similar functions for directly inputting strings (rather than clicks).
One of the most intriguing features of AHK which led me to pursue learning it on a deeper level is its capacity to directly interact with application client windows and any separate application GUI’s (including mouse and key inputs, minimizing/maximizing, setting window focus, and more) without focusing on them and interrupting other active processes. This is extremely beneficial for testing, data collection/recording and more – for example testing may be run in the background with the results recorded to an output file whilst the user is actively working on other tasks independently. Furthermore, AHK scripts can easily be set to repeat at a specified time period; the previously mentioned background testing/recording can be called upon to execute every X minutes with zero input from the user or interference on their tasks. Increased convenience and efficiency with less human error or interaction!
Some other functions in AHK which I have read or seen videos about and hope to start implementing soon include PixelSearch and ImageSearch. PixelSearch is a versatile tool of the form:
Searching for a specified hexadecimal ColorID within the specified screen space and returning output variables containing the coordinates of the first found pixel of that color. The outputs can easily then be used in other functions, and this method synergizes well with other tools that may identify certain occurrences with a color highlight or other marker. The ImageSearch function works similarly, but takes an Image input (easily generated with the Window Spy tool) and searches for an occurrence of the input within the search coordinate range. An interesting component of both PixelSearch and ImageSearch is the Variation parameter visible above near the end of the PixelSearch skeleton. This variable allows variance in the color/image which is being searched for to increase the likelihood of finding the target even if minor screen/image shifts have occurred, which can be common depending on the application or instance.
There are countless other features and functions in AHK which I have not yet gotten a chance to learn about. If you or a friend/colleague have experience with AHK functions, feel free to reach out with questions/discussion/advice to my email at jelbirt@worcester.edu !
Welcome to Tech. Worth Talking About (TWTA), a blog discussing exciting and impactful tools and innovations in the technology world, as well as some ideas on how to implement them in real situations to solve problems. Stay tuned for these posts and more!
