InRhythmU

Jan 04 2023

Creating An Effective Proxy Using Node And Express

Overview

Engineers are often faced with the challenge of pulling together multi-website/application projects, without full cross-platform permissions. Utilizing both a Node and an Express proxy, can pull together two websites/applications in a formal and cohesive format.

The aforementioned situation comes up more often than one would think, whether it be a question of host permissions or compatibility, it can undoubtedly pull up a number of possible roadblocks. There are several reasons a developer might not be able to run a site or app in their local environment; perhaps it’s complex to set up or involves a number of permissions. Regardless of the reason, Node and Express can present a novel way to solve the problem.

In Matt Billard’s Lightning Talk session, we will be uncovering the the primary strategies for Creating An Effective Proxy Using Node And Express:

Overview
The Architecture
How It Works
“Gotchas” To Avoid
Live Demonstrations
Closing Thoughts

The Architecture

The browser makes a request to the Node Express proxy server where the following three scenarios crop up:

If the user requested an HTML page, we need to combine the page from website 1 and 2. The proxy first asks website 1 and then website 2 for its HTML. It then modifies the two HTML files, combines them, and returns the result to the browser. (Details on how this works below.)
The HTML page will then request the CSS, JavaScript, and other assets it requires. These requests will again go through the proxy which will pass on the requests. If website 1 has the asset, great, the proxy will return it to the browser.
If website 1 does not have the asset, the proxy will then ask website 2 and return it to the browser.

In the example below, when using the InRhythm.com website as the target into which an engineer can inject some local code (in this case a basic Create React App project); the final result is an actual screenshot of the 2 websites living together in the same browser window.

How It Works

As mentioned above, website 1 and 2’s HTML are combined. This involves a few steps. Webpages can’t have 2 doctype, html, head, or body tags, so the use of some regex to strip those, will be required. Now that website 2’s HTML is ready, a coder can inject it before website 1’s closing </body> tag.

The above code shows the modifications to website 1’s HTML.

It shows a few things:

Many websites have full ‘absolute URLs’ for their links. They look like this: https://www.inrhythm.com/who-we-are/. The problem is if the user clicks on this, they’ll be taken away from our proxy and go to the target website. One can solve this by removing all www.something.com pieces while retaining the language the after the slash.
Injecting the CSS as discussed above, removes backgrounds and allows clicks to pass through website 2 to website 1. (Keep in mind this will probably be slightly different depending on the two sites a coder is combining.)
Injecting the HTML from website 2 must be modified before closing the </body> tag.

“Gotchas” To Avoid

It can take a variety of trial and errors in order to develop a proxy to one’s exact specifications. Some of the most common occurrences, a coder may find themselves troubleshooting are:

Websites usually compress or “Gzip” their content. Normally this is a great thing. It means less data is transferred and websites load more quickly. However, when in need of a proxy, it can become quite troublesome for ease of use. An engineer can’t parse, manipulate, and modify HTML if it looks like gibberish. The solution is actually quite simple: as it turns out, there’s a header one can send with their request to ask the server not to Gzip anything.

When using a proxy, all requests are going to have the header “host” set to “localhost.” Now this is probably not a problem for most sites, but to the target server, this doesn’t look like a very normal request, and indeed, one will find some websites responded abnormally and will return pages that looked nothing like expected. The solution cab be found in modifying one of the headers of the request.

Due to needing to modify requests quite a bit, this may result in some possible browser abnormalities. The solution to this problem is to delete the ‘content-length’ header before the proxy sends the browser any final response. This will stop the browser from truncating the response and removing all the hard work needed to customize one’s proxy.

When combining sites that use https, the proxy might complain that the SSL certificates don’t match what it’s expecting. Turns out it’s rather easy to relax this with the following code:

Live Demonstrations

Matt Billard has crafted an intuitive demonstration to help guide you through these principles in practicum:

Be sure to follow Billard’s entire Lightning Talk to view this impressive demonstration in real time.

Closing Thoughts

The Node.js framework Express allows an engineer to create web servers and APIs with minimal setup. Using Express in a Node.js application to create an API Proxy to request data from another API and return it to a consumer, is a vital skill to add to one’s skills toolkit. Using Express middleware to help optimize the API Proxy, will allow a coder to raise the bar and improve performance for returning data from the underlying API.

To develop and learn from Billard’s signature “Code Collider” proxy, feel free to download the direct code from GitHub.

Happy coding!

To learn more about Creating An Effective Proxy Using Node And Express, along with some live test samples, and to experience Matt Billard’s full Lightning Talk session, watch here.

Dec 20 2022

A Comprehensive Introduction To Swift Package Manager

Introduction

The Swift Package Manager (SwiftPM) is Apple’s tool for managing package dependencies for Swift application development. SwiftPM has been an integrated part of Swift since v3.0.

So, what are Packages? Packages contain reusable code or other resources stored in repositories that your application needs to provide a feature or function. Some examples include, but are not limited to, the fonts and color scheme for your app, a library that provides access to a web resource, a file with images required by your application. Other examples are the APIs and Frameworks that add functionality to your app and simplify your coding tasks.

Let’s work together and breakdown a high-level overview of basic SwiftPM usage and its associated features.

What Do Package Managers Bring To The Table?

Package Managers give developers a way to control which packages and which versions of those packages that the project will consume.

Other features include:

Allows easy use of light-weight, reusable libraries
Reduces code duplication
Supports development best practices by simplifying and supporting modular coding (easy module/package creation)

While it is possible to manually manage dependencies in a project, it isn’t practical for anything but the smallest of applications. Best practices fall on the side of using a package manager to handle this function automatically.

SwiftPM supports Swift 3+ and XCode 8+. Since Swift 5 and Xcode 11, SwiftPM has had cross-platform support for iOS, macOS, and tvOS.

Are There SwiftPM Alternatives?

There are two mainstream alternatives, CocoaPods and Carthage. Both are third-party tools requiring installation and much configuration before use.

CocoaPods

CocoaPods (2011) – Supports Swift 5+ and Xcode 3.11+ – Mature and stable. A centralized, easy-to-use command-line tool for package dependency management and integration into the application. CocoaPods is written in Ruby.

However, Cocoapods lacks direct control over project configuration and is basically a blackbox. CocoaPods also experiences random build failures that can’t be explained. Resolving these often involves removing and reinstalling CocoaPod dependencies from the project, clearing caches, and completely rebuilding the entire project. These steps can add a significant amount of time to the development process, especially on large projects.

Each CocoaPod dependency must have a “Podspec” file to define the metadata for that dependency. These files are typically uploaded to a different repository from the dependency itself. A “Podfile” within the app project will include a reference to this repository, and CocoaPods will use the information in this Podfile to fetch and install all of the dependencies for the app project.

Carthage

Carthage (2014) – A decentralized command-line tool for dependency management. Developers have full project control and must manually provide all package and dependency information. Carthage pulls the packages the developer specifies.Configuration requires much more manual work than CocoaPods and is somewhat complicated.

Using SwiftPM

SwiftPM has many advantages over Carthage and CocoaPods. Foremost, SwiftPM is a native Apple tool integrated into Swift. Other advantages include a quick and simple configuration, easier control over packages and their sub-dependencies, and a GUI built into Xcode for managing package configurations. Each package’s metadata is defined in a “Package.swift” file, which resides in the same repository as the package source files.

Package Resolution

With the Package dependencies configured in the SwiftPM GUI, Xcode will download the packages and resolve dependencies at build time with no further developer interaction.

When setting dependencies, you have the following options:

By Version: Next Version, Up to next minor, Range, or a specific commit
Branch (Specify)
Commit(Specify)

Adding A Package To Your Project

Swift Packages> Add Package Dependency
On the “Choose Package Repository” dialog, enter the desired Repository.
Click Next.
On the “Choose Package Options” dialog, set the dependency rules (Versions, Branches, Commits).
Click Next. Xcode now fetches the dependency.
On the “Add Package to YourPrjName dialog,” ensure that the relevant packages are checked and the proper Target is selected in the Add to Target cell.
Click Finish.

Your package now appears in the Navigator under Swift Package Dependencies. Note that SwiftPM can reference both local and remote packages.

Create A Module And Add A Local Package With SwiftPM

SwiftPM simplifies the process of modularizing your code and adding it as a package to a local or external repository. This section will briefly describe the process of creating a module and adding it to a local repository.

Identify a self-contained portion of code or another resource that is suitable for use in a module.
Create a new file: Files > New Package. Name the package accordingly and add it to your application using the same dialog.
Copy the code or resource to the new file.
Delete the existing code or resource from the app
Add the new package to the Application Target. In “Application Project Settings,” add the new package under Frameworks and Libraries.
In the Package code, define the platforms and versions where this Package works.
In the Application’s code files, import the new package into every file where its code or where its resources are used.

If desired, you could upload the new Package to an external repository for use by developers outside your organization.

Additionally, SwiftPM will allow you to create and use binary packages. Binary packages permit developers to distribute libraries and frameworks without also distributing their source code.

Package Distribution

You can use SwiftPM to distribute resources, in addition to frameworks and libraries. SwiftPM also has built-in support for Apple’s DocC Documentation format, which makes it easy to build robust interactive documentation files and tutorials.

The Future

SwiftPM is a mature product still under active development to improve and add new features. Usage stats currently show it being about equal in popularity with CocoaPods. However, since SwiftPM is a native tool that requires no additional work to begin using, its future is more sure than that of CocoaPods or Carthage.

Happy coding!

To learn more about Swift Package Manager as well as its influence in mobile development and to experience Andrew Balmer’s full Lightning Talk session, watch here.

Dec 20 2022

State Management: Redux vs. MobX

Redux was developed in 2015 by Abramhov and Clark based on concepts used in Facebook’s Flux architecture. MobX also began in 2015 and was originally called Mooservable by the dev team. It became MobX with the 2.0 release on 26 Feb 2016.

There are three parts to state management:

The State, which is the source of truth for your application’s State.
The View, which is a rendering of the current State.
The Action, which is something that triggers a State change.

Bare Javascript passes State via property trees. A function needing State obtains the information via property drilling. Depending on a function’s layer depth, property drilling can introduce significant overhead.

Using State Management introduces a structured workflow in the application and makes obtaining the application State trivial.

Redux

Overview

Redux manages application state in a centralized repository. There is a single state in the application and it is immutable. It can’t be modified by the application. This is similar to how State is managed in Flux. Redux is designed to be a predictable container for application state.

Redux combines Flux and Functional Programming and uses an immutable State as a single, predictable, source of truth in the application stored in a Javascript object.

Implementation

Using Redux requires a considerable amount of ramp-up work. There is a great deal of boilerplate code, configuration, and to take advantage of some capabilities, developers must follow explicit coding patterns.

Workflow

There are three main workflow components:

The UI: The UI passes the user’s activity, or their Action, to the Event Handler.
The Event or Action Handler/Dispatcher: The Event Handler’s Dispatcher then notifies the Store of the Action.
The Store with Reducers and the State: The Store clones a copy of the current State for the Reducers to act on based on the user’s Action. On completion, the Store passes the new state to the UI. The updated State will trigger a refresh of any component accessing that State.

The State’s Reducers are responsible for updating the State of the Store. They are pure functions that analyze the Store’s recursive data structure. They do not mutate the current state, nor do they make external API calls. Using a combining function, they recombine the results.of their recursive processing into their constituent parts, thereby building a return value.

MobX

Overview

MobX was created in ES5 Javascript and follows Functional Reactive Programming patterns and prevents an inconsistent State by automatically performing all derivations. MobX’s main difference from Javascript and Redux are that State is not immutable and your application can automatically store different observable data types into different MobX Stores.

MobX uses abstraction to hide much of the background operation and reduce the boilerplate code requirement. MobX directly modifies its current state(s) without cloning beforehand.

Implementation

MobX is implicit by nature, and requires little boilerplate code. After implementing State storage in the desired data structure (plain, arrays, objects, etc.), set those properties that will change over time to observable for MobX tracking.

Workflow

There are four main workflow components:

Actions
Observable State
Derivations (Computed Values)
Reactions (or Side Effects)

Events invoke Actions. Those actions can originate with the user or the application, and are the only thing that can modify the Observable State. MobX propagates any changes to the Observable State to all Derivations and Reactions.

Deciding On A State Manager

Types of Derivations could be computation, serialization, rendering, etc. and example Rendering side-effects are I/O activity, DOM updating, network activity. etc.

Application Architecture – Is the architecture Flux/Functional Reactive Programming (Redux) or more OOP (MobX)?
Ramp-up – Time until productive
Boilerplate – Redux requires extensive boilerplate setup, MobX has very little boilerplate
Learning Curve – Steeper: Redux requires developers to follow explicit coding patterns to access capabilities. Flatter: MobX is more implicit and doesn’t require extra tooling. Setup is adding a class and setting Observers, Actions, and Compute Values.
State Stores – Redux usually maintains a single immutable State even though it is possible to set up multiple Stores in Redux. It is a cumbersome process. MobX makes it much simpler to have multiple Stores and it uses changeable States.
Purity – Redux uses pure functions and does not allow State modification. MobX allows mutable States.
Scalability – Redux’s pure functions make code scaling much simpler and predictable. MobX’s workflow does not include many pure functions, making testing not as straightforward, and as the application grows it becomes more difficult to determine what exactly should an output be, given an input.
Performance – Redux can suffer performance degradation from very frequent updates to its single State Store. MobX, on the other hand, with support for multiple Stores can better support frequent State updates, such as real-time updates on market pricing for a trading platform.
Community Support and Tools – Redux has a much larger community and more widely tested tools. MobX has a smaller community and fewer tools.
Debugging – Redux has a single source of truth and uses a pure Store making its output predictable and repeatable. Redux has better debugging tools, including ReduxDevTools and the Time Traveling Debugger (provides State history). MobX with its implicit nature, multiple States, and code abstraction can be very difficult to troubleshoot and determine the proper output from a given input. All State updates happen behind the scenes and do not offer any history. MobX also suffers from fewer robust tools

To learn more about State Management and to experience Eric Marcatoma’s full Lightning Talk session, watch here.

Sep 21 2022

How To Write A Great Test Case

Overview

A test case is exactly what it sounds like: a test scenario measuring functionality across a set of actions or conditions to verify the expected result. They apply to any software application, can use manual testing or an automated test, and can make use of test case management tools.

Most digital-first business leaders know the value of software testing. Some value high-quality software more than others and might demand more test coverage to ultimately satisfy customers. So, how do they achieve that goal?

They test more, and test more efficiently. That means writing test cases that cover a broad spectrum of software functionality. It also means writing test cases clearly and efficiently, as a poor test can prove more damaging than helpful.

A key thing to remember when it comes to writing test cases is that they are intended to test a basic variable or task such as whether or not a discount code applies to the right product on an e-commerce web page. This allows a software tester more flexibility in how to test code and features.

In Nathan Barrett’s Lightning Talk session, we will be breaking down the following topics:

What Is A Test Case?
What Makes A Good Test Case?
Live Demonstration
Closing Thoughts

What Is A Test Case?

At a high level, to “test” means to establish the quality, performance, or reliability of a software application. A test case is a repeatable series of specific actions designed to either verify success or provoke failure in a given product, system, or process.

A test case gives detailed information about testing strategy, testing process, preconditions, and expected output. These are executed during the testing process to check whether the software application is performing the task for which it was developed for or not. A passed test case functions like a receipt verifying the correct functionality of the subject of the test.

To write the test case, we must have the requirements to derive the inputs, and the test scenarios must be written so that we do not miss out on any features for testing. Then we should have the test case template to maintain the uniformity, or every test engineer follows the same approach to prepare the test document.

Test cases serve as final verification of functionality before releasing it to the direct product users.

What Makes A Good Test Case?

Writing test cases varies depending on what the test case is measuring or testing. This is also a situation where sharing test assets across dev and test teams can accelerate software testing. But it all starts with knowing how to write a test case effectively and efficiently.

Test cases have a few integral parts that should always be present in fields, as well as some “nice to have” elements that can only work to enhance presented results.

Required Elements:

Summary
- Concise, direct encapsulation of the purpose of the test case
Prerequisites
- What needs to be in place prior to starting the test?
- Bad Prerequisites: captured in test steps, not present, overly specific
- Good Prerequisites: concise/descriptive, lays out all set-up prior to testing, includes information to learn more if desired
Test Steps
- The meat of the test case
- Good test steps: each step is a specific atomic action performed by the user that contains an expected result, call out divergent paths where necessary, cites which test data when laid out in prerequisites needs to be applied
- Really great test steps should treat the user like they know “nothing” and communicate everything from start to finish
Expected Results
- How do we know that the test hasn’t failed?
- Bad Expected Results: Page loads correctly, view looks good, app behaves as expected
- Good Expected Results: Landing page loads after spinner with user’s account details present, view renders with all appropriate configurations (title, subtitle, description, etc.), toggle changes state when tapped (enabled→disabled)

Preferred Additional Elements:

Artifacts
- Screenshots, files, builds, configurations, etc.
Test Data
- Accounts, items, addresses, etc.
- What information is needed during the test?
- Pre-rendered prerequisite fulfillment
Historical Context
- Previous failures, previous user journeys, development history, etc.
- Has this feature been “flakey” in the past?
- What are previous failure points?
- How critical is this feature?

The very practice of writing test cases helps prepare the testing team by ensuring good test coverage across the application, but writing test cases has an even broader impact on quality assurance and user experience.

Live Demonstration

Nathan Barrett has crafted an intuitive test of specificity to help guide testers to understand how they should be structuring their cases:

Be sure to follow Nathan’s entire Lightning Talk to follow along with these steps in real time.

Closing Thoughts

Test cases help guide the tester through a sequence of steps to validate whether a software application is free of bugs, and working as required by the end-user. A well-written test case should allow any tester to understand and execute the test.

All programs should always be designed with performance and the user experience in mind. The properties explored above are the primary stepping stones to understanding the beneficial prerequisites to writing a good test case for any type of application. Be sure to explore, have fun, and match up the components that work best for your project!

Happy coding!

To learn more about How To Conduct A Great Test Case as well as its importance in the software development process and to experience Nathan Barrett’s full Lightning Talk session, watch here.

Sep 16 2022

A Comprehensive Guide To Java’s New HTTP Client

Overview

The Hypertext Transfer Protocol (HTTP) is the foundation of the World Wide Web, and is used to load web pages using hypertext links. HTTP is an application layer protocol designed to transfer information between networked devices and runs on top of other layers of the network protocol stack. A typical flow over HTTP involves a client machine making a message request to a server, which then sends a response message.

Java is a general-purpose, class-based, object-oriented programming language designed for having lesser implementation dependencies. It is a computing platform for application development. Java is fast, secure, and reliable, therefore, it is widely used by everyone from the newest to most advanced web developers.

In Daniel Fuentes’ Lightning Talk session, we will breaking down the following topics:

What Is HTTP?
Improvements In HTTP 2.0
How HTTP 2.0 Impacts Java
Live Demonstrations
Closing Thoughts

The new HTTP 2.0 Client was released in Java 11. This new client is used to request HTTP resources over the network. It supports HTTP/1.1 and HTTP/2.0, both synchronous and asynchronous programming models, handles request and response bodies as well as reactive-streams, and follows the familiar builder pattern.

What Is HTTP?

HTTP is an application layer protocol designed to transfer information between networked devices. HTTP runs on top of other layers of the network protocol stack.

HTTP is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance, text, layout description, images, videos, scripts, and more.

Clients and servers communicate by exchanging individual messages (as opposed to a stream of data). The messages sent by the client, usually a Web browser, are called requests and the messages sent by the server as an answer are called responses.

The typical flow over HTTP involves a client machine making a request to a server, which then sends a response message.

HTTP was invented alongside HTML to load web pages using links (hypertext). It was a part of the first interactive, text-based web browser: the original World Wide Web. Today, the protocol remains one of the primary means of using the Internet.

Improvements In HTTP 2.0

HTTP 2.0 is based on streams and binary frames, in comparison to the text-only request models of its previous iteration. Unlike text-only interfaces, streams can be multiplexed asynchronously over one TCP (Transmission Control Protocol) connection. Comparatively, HTTP 2.0 reduces latency, therefore enhancing its performance.

How HTTP 2.0 Impacts Java

Java was commonly built upon the HttpURLConnection class – which had an original launch in 1999 when HTTP 1.0 was still a fresh protocol. With a backbone built from outdated technology, it was never able to update properly in response to the rapidly changing nature of web protocols.

Its steady incompatibility and lack of ease in use, led developers to opt out of Java’s direct class and instead employ third party solutions (ie. Apache, Netty, Eclipse, Google, etc.).

With the new updated Java 11 developer toolkit, came a number of operational changes – but namely, the adoption of HTTP 2.0. In order to meet the demand of an environment consistently in motion, Java made these longevity changes:

Eliminating the need for 3rd party client dependencies
Building in a backwards compatibility with HTTP 1.0 for remaining servers that may have not yet made the switch to HTTP 2.0
Instating an asynchronous support network for multiple HTTP requests
Vastly improving performance with the addition of Header compression and Single Connections for multiple requests

Live Demonstrations

Daniel Fuentes has crafted an intuitive demonstration to help guide you through this new Java HTTP in practicum:

Be sure to follow Daniel’s entire Lightning Talk to view this impressive demonstration in real time.

Closing Thoughts

All programs should always be designed with performance and the user experience in mind. The properties explored above are the primary stepping stones to exploring the basic components needed to test HTTP 2.0 in order to improve your application. Be sure to explore, have fun, and match up the components that work best for your project!

Happy coding!

To learn more about Java’s Updated HTTP Server as well as its influence in web development and to experience Daniel Fuentes’ full Lightning Talk session, watch here.

InRhythmU

Overview

The Architecture

How It Works

“Gotchas” To Avoid

Live Demonstrations

Closing Thoughts

Introduction

What Do Package Managers Bring To The Table?

Are There SwiftPM Alternatives?

CocoaPods

Carthage

Using SwiftPM

Package Resolution

Adding A Package To Your Project

Create A Module And Add A Local Package With SwiftPM

Package Distribution

The Future

Redux

Overview

Implementation

Workflow

MobX

Overview

Implementation

Workflow

Deciding On A State Manager

Footer

Interested in learning more?