• Skip to main content
  • Skip to footer

InRhythm

Your partners in accelerated digital transformation

  • Who We Are
  • Our Work
  • Practices & Products
  • Learning & Growth
  • Culture & Careers
  • Blog
  • Contact Us

software development

Nov 01 2022

An Introduction To SwiftUI Animations

Overview

Since the very beginning of iOS, animations have been a key part of the user experience. Animation is a brilliant way to wow users, and make an app look and feel unique. Practically speaking, animation can grab a user’s attention, and allow them to focus on what’s most important. It can help users intuitively understand how to navigate an app or alert them to important changes.

SwiftUI takes care of all the complexity in making effects by automatically animating any transitions that may happen. Done are the days of writing complicated code for a singular animated transition – the framework comes with enough built-in effects that can perform different animations.

In Joshua Buchanan’s Lightning Talk session, we will breaking down the following topics:

  • Overview
  • Why Have Animations?
  • SwiftUI Animation Options
  • How To Add Animations With SwiftUI
  • Live Demonstration
  • Closing Thoughts

Why Have Animations?

Animations are an easy way to show users the functionality hidden behind a beautiful wrapper.

Animations are quite an important part of any application because it draws users’ attention. An animation is simply a collection of images that are repeated at high speed, but animations can set your application apart.

Mobile app animations occupy an important place in the design of the whole user experience of an app. They are great for communicating a message and creating a feeling by not limiting the method with static images or texts. The dynamism that in-app animations inherently have makes the user journey more vivid and delightful. Thanks to that, an animated app can achieve higher user engagement rates.

SwiftUI Animation Options

Animations on SwiftUI have a variety of options built into its starting interface. These options allow for a number of different transitions to take place swiftly and automatically. 

There are a number of varying involvement regarding these options, from basic to advanced – each piece brings a unique visual perspective to life.

The primary basic animation options available to a mobile developer utilizing SwiftUI for their mobile application are:

  • Enable
  • Offset
  • Color
  • Scale

The most popular of these advanced options being:

Repeat Count / Reverse

Duration Options (Speed)

Curve Options

How To Add Animations With SwiftUI

SwiftUI has built-in support for animations with its animation() modifier. To use this modifier, place it after any other modifiers for your views, tell it what kind of animation you want, and also make sure you attach it to a particular value so the animation triggers only when that specific value changes.

SwiftUI animates the effects that many built-in view modifiers produce, like those that set a scale or opacity value. You can animate other values by making your custom views conform to the Animatable protocol, and telling SwiftUI about the value you want to animate.

When an animated state change results in adding or removing a view to or from the view hierarchy, you can tell SwiftUI how to transition the view into or out of place using built-in transitions that AnyTransition defines, like slide or scale. You can also create custom transitions.

Live Demonstration

Joshua Buchanan has crafted an intuitive test to demonstrate real time code and their animated results via SwiftUI:

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

Closing Thoughts

In SwiftUI, Animation is nothing but the change of the state from start to finish with different curves and velocities. The syntax is mostly easy to understand and quick to implement. Animating is quite easy with the use of different implicit animation like easeIn, easeOut, linear, spring, and interpolating spring. A developer can create awesome animations with just a few lines of code in SwiftUI.

Happy coding!

To learn more about the implementation of SwiftUI Animations and to experience Joshua Buchanan’s full Lightning Talk session, watch here. 

Written by Kaela Coppinger · Categorized: Code Lounge, Design UX/UI, DevOps, Learning and Development, Product Development · Tagged: coding, INRHYTHMU, Mobile Development, software development, SwiftUI, ux

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. 

Written by Kaela Coppinger · Categorized: Cloud Engineering, Design UX/UI, DevOps, InRhythmU, Learning and Development, Product Development, Software Engineering, Web Engineering · Tagged: devops, INRHYTHMU, learning and growth, SDET, software development, software engineering, ux, web engineering

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. 

Written by Kaela Coppinger · Categorized: DevOps, InRhythmU, Java Engineering, Product Development · Tagged: best practices, devops, HTTP, INRHYTHMU, Java 11, JavaScript, learning and growth, software development, Web Development

May 19 2017

When to Pair Program

Follow Jack on twitter @JacopoTarantino for other related topics.

Lots of companies embrace pair programming as a way to increase programmer productivity (loosely defined here as delivering “value” which can have many forms, but is generally interpreted as writing more code per day) but is it really that great? I’ve wondered why we should pair program and when is the right time to embrace it as a strategy.

Pair programming, as I know it, came into popular culture as a facet of XP (extreme programming), a development framework that enforces practices that generally improve software quality and responsiveness. The idea is a new incarnation of the old adage “two minds are better than one”. Either way, the idea is right: two people have different histories, cultures, and experiences, and for those reasons they think about things in different ways. When two people work on a problem together they almost always come out with a better solution that if one worked on it alone. So how does this relate to programming?

The Good

Pair programming does reduce bugs

The primary driver for pair programming is to increase quality and decrease bugs. When done well, it does that spectacularly. One study found that pairing reduced bugs in production by 15%!

Pairing does increase code quality

Many of the benefits of pair programming are not actually technical; they’re social. When working with a peer, it’s normal to feel encouraged to do your best, ensuring your coding is clean and avoiding any technical debt that you’ll “fix later”.  When pairing, we tend to do things just a little bit cleaner, make algorithms just a little bit easier to read, name variables a little bit more sensibly. We actually write our unit tests to 100% coverage! With two sets of eyes, the quality is always higher.

The Gotchas

Pair programming does not eliminate bugs.

As much as we’d love for pairing to just eliminate all bugs, it’s just not the reality. Bugs still happen. There are generally a lot fewer of them, but perfect code would require perfect programmers.

Pair programming does not fix bad product direction.

Good projects need very strong product direction. And to be clear, the responsibility for this direction is on everyone, not just “product people”. It begins with asking questions and making informed decisions about work to be done. Then the team needs to thoroughly discuss the work, breaking it down as much as possible to understand the full scope. If this isn’t done properly, deadlines are missed, everyone is stressed, work that should take minutes takes days… Pair programming can’t fix that. Nothing is more important than good product direction.

Pair programming costs a lot.

Like, a lot. One study found that pairing increases the cost of software by 100%. While that seems like a predictable number (1+1=2), it’s actually highly variable. If pairing is used effectively, I would say it strictly costs the amount of time put in, minus the value added. It could be a single-digit percentage. On the other hand, if pairing is done poorly, you’re paying about 300% more. That’s 100% for putting another salaried employee on the same project, 100% for that that employee not adding any value, and 100% for the opportunity cost of other work they could have been doing. Make sure you’re doing it for the right reasons and utilizing the right resources.

You have to do pair programming right for it to mean anything.

Pair programming is a tool meant to help make a difficult problem more digestible. Pair programming done correctly generally means one person is writing code and the other is directing the work. Directing in this case means providing feedback about best practices and constructive criticism. It also means researching those best practices when you don’t know them off the top of your head and taking the time to think deeply about possible edge cases and hangups relevant to the work at hand. Pairs should communicate thoroughly, share all relevant information about their work, and swap duties as often as possible. It’s taxing to think about problems in both a creative and technical way, so it’s better to distribute that work. That’s one big reason that pair programming is such an effective tool.

So when are we supposed to pair program?

Pair program when there is a *very* difficult problem at hand.

If you have a problem you cannot reasonably break a big problem down into smaller parts,  that’s the kind of thing that should be attacked by multiple programmers. An 8-point story should generally never exist in your organization if you’re doing normal web work. Features can almost always be broken down into “front-end” and “back-end” stories. Whole-page mockups can be broken down into component parts. Design and QA phases can also be separated out into their own stories. But a really tough problem is just a really tough problem. Trying to add a new feature to a language is a really tough problem. Trying to figure out how to reduce the latency on database calls is a really tough problem. These are examples of problems that require both creative and technical thinking.

Pair program when 2 programmers are at completely different skill levels.

Pair programming is a remarkably good way to teach junior programmers. Getting to participate live while a more senior programmer talks about how and why they’re doing something is invaluable experience. So is writing code while a more senior programmer coerces better practices on the fly. In my time as a programmer, pairing with somebody significantly more senior than me has been some of the most difficult and most rewarding work I’ve ever done.

Pair program when 2 programmers have completely different skill sets.

If you choose not to break down a story into easily divisible parts, having 2 programmers with complementary skill sets can be very rewarding for both the programmers and the codebase. Pairing programmers who generally only work front-end or back-end can get an end-to-end feature out the door, or you might have a Postgres expert pairing with a Scala expert to make your database calls more efficient. When these 2 people work together live, they absorb a lot of knowledge about each other’s domain and ensure there’s no aspect of the project that’s neglected.

Pair program when you’re both new to a language or framework.

Sometimes you wind up in a situation where nobody is an expert. Even if you’re working on a trivial feature and just wandered into a very difficult problem (see above). This is an excellent opportunity! You end up with two programmers working through a difficult problem and contributing their individual skills to build a better product, helping each other learn, and with a redundancy in the skill growth of your programmers. This is important because the skills in your organization should never be concentrated in one person. Having programmers pair on new languages and/or frameworks ensures that there are a minimum of two people who can work on this in the future.

This post is another one by InRhythm’s own Jack Tarantino. For the full post, check out the original “when to pair program” on his website.

Written by Jack Tarantino · Categorized: Agile & Lean, Learning and Development, Product Development · Tagged: agile, best practices, pair programming, Programming, software development

Footer

Interested in learning more?
Connect with Us
InRhythm

110 William St
Suite 2601
New York, NY 10038

1 800 683 7813
get@inrhythm.com

Copyright © 2023 · InRhythm on Genesis Framework · WordPress · Log in

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT