AssertJ is a Java library that provides a fluent interface for assertions, which makes it easy to convey intent within test code. AssertJ gives readable error messages, soft assertions and improved collections and exception support. Many of our teams choose AssertJ as their default assertion library instead of JUnit combined with Java Hamcrest.
Enzyme has become the defacto standard for unit testing React UI components. Unlike many other snapshot-based testing utilities, Enzyme enables you to test without doing on-device rendering, which results in faster and more granular testing. This is a contributing factor in our ability to massively reduce the amount of functional testing we find we have to do in React applications. In many of our projects it’s used within a unit testing framework such as Jest.
Since it was first introduced in the Radar, we’ve seen a steady adoption of GraphQL, particularly as a remote interface for a Backend for Frontend (BFF). As they gain more experience, our teams have reached consensus on Apollo, a GraphQL client, as the preferred way to access GraphQL data from a React application. Although the Apollo project also provides a server framework and a GraphQL gateway, the Apollo client simplifies the problem of binding UI components to data served by any GraphQL backend. Notably, Apollo is used by Amazon AWS in their recent launch of the new AWS AppSync service.
CSS is the preferred choice for laying out web pages, even when it did not provide much explicit support for creating layouts. Flexbox helped with simpler, one-dimensional layouts, but developers usually reached for libraries and toolkits for more complex layouts. CSS Grid Layout is a two-dimensional grid-based layout system that provides a mechanism to divide available space for layout into columns and rows using a set of predictable sizing behaviors. Grid does not require any libraries and plays well with Flexbox and other CSS display elements. However, since IE11 is only partially supported, it ignores users who still depend on a Microsoft browser on Windows 7.
The Hyperledger project has grown into a broader collaboration and now contains a series of subprojects. It supports Blockchain implementations for different purposes; for example, Burrow is dedicated to build a permissioned Ethereum and Indy is more focused on digital identity. Among these platforms, Fabric is the most mature one. Most of time when people talk about adopting Hyperledger they are actually thinking about Hyperledger Fabric. However, the programming abstraction of chaincode is relatively low level given it manipulates the state of the ledger directly. Moreover, it always takes a lot of time to set up infrastructure before writing the first line of blockchain code. Hyperledger Composer, which builds on top of Fabric, accelerates the process of turning ideas into software. Composer provides DSLs to model business assets, define access control and build a business network. By using Composer you could quickly validate your idea through a browser without setting up any infrastructure. Just remember that the Composer itself isn't Blockchain — you still need to deploy it on Fabric.
Security is the cornerstone of the blockchain economy. In the last issue of the Radar, we highlighted the importance of testing and auditing smart contracts dependencies. OpenZeppelin is a framework to help build secure smart contracts in Solidity. The team behind OpenZeppelin summed up a series of pitfalls and best practices around smart contracts' security and embedded these experiences into the source code. The framework is well reviewed and validated by the open source community. We recommend the use of OpenZeppelin instead of writing your own implementation of the ERC20/ERC721 token. OpenZeppelin is also integrated with Truffle.
Historically, Google's Android documentation examples lacked architecture and structure. This changes with the release of Android Architecture Components, a set of opinionated libraries that help developers create Android applications with better architecture. They address longstanding pain points of Android development: handling lifecycles; pagination; SQLite databases; and data persistence over configuration changes. The libraries don't need to be used together — you can pick the ones you need most and integrate them into your existing project.
A multi-app strategy is really controversial, particularly at a time when fewer and fewer users are downloading new apps. Instead of introducing a new app and struggling with the download numbers, multiteams have to deliver functionality via a single app that is already widely installed, which creates an architectural challenge. Atlas and BeeHive are modularization solutions for Android and iOS apps, respectively. Atlas and BeeHive enable multiteams working on physically isolated modules to reassemble or dynamically load these modules from a facade app. Both are Alibaba open source projects, since Alibaba encountered the same problem of dwindling downloads and single-app architectural challenges.
Our first rule of thumb in selecting a rules engine is normally: you don't need a rules engine. We've seen too many people tying themselves to a hard-to-test black-box rules engine for spurious reasons, when custom code would have been a better solution. That said, we've had success using Clara rules for scenarios where a rules engine does make sense. We like that it uses simple Clojure code to express and evaluate the rules, which means they are amenable to refactoring, testing and source control. Rather than chasing the illusion that business people should directly manipulate the rules, it drives collaboration between the business experts and developers.
Flutter is a cross-platform framework that enables you to write native mobile apps in Dart. It benefits from Dart and can be compiled into native code and communicates with the target platform without bridge and context switching — something that can cause performance bottlenecks in frameworks such as React Native or Weex. Flutter’s hot-reload feature is impressive and provides superfast visual feedback when editing code. Currently Flutter is still in beta, but we’ll continue keeping an eye on it to see how its ecosystem matures.
The ability to compile the Go programming language to bare metal targets has raised interest among developers in using the language for embedded systems. Gobot is a framework for robotics, physical computing, and the Internet of Things, written in the Go programming language and supporting a variety of platforms. We've used the framework for experimental robotic projects where real-time response hasn't been a requirement, and we’ve created open source software drivers with Gobot. Gobot HTTP APIs enable simple hardware integration with mobile devices to create richer applications.
PyTorch is a complete rewrite of the Torch machine learning framework from Lua to Python. Although quite new and immature compared to Tensorflow, programmers find PyTorch much easier to work with. Because of its object-orientation and native Python implementation, models can be expressed more clearly and succinctly and debugged during execution. Although many of these frameworks have emerged recently, PyTorch has the backing of Facebook and broad range of partner organisations, including NVIDIA, which should ensure continuing support for CUDA architectures. ThoughtWorks teams find PyTorch useful for experimenting and developing models but still rely on TensorFlow’s performance for production-scale training and classification.
Rasa is a new entrant in the area of chatbots. Instead of using a simple decision tree it uses neural networks to map intent and internal state to a response. Rasa integrates with natural language processing solutions such as spaCy; and, unlike other solutions we've featured in the Radar, Rasa is open source software and can be self-hosted, which makes it a viable solution when ownership of data is of concern. Our experiences with using Rasa Stack for an internal application have been positive.
Reactor is a library for building non-blocking applications on the JVM — version 8 and above — based on the Reactive Streams specification. Reactive programming emphasizes moving from imperative logic to asynchronous, non-blocking and functional style code, especially when dealing with external resources. Reactor implements the reactive stream specification and provides two publisher APIs — Flux (0 to N elements) and Mono (0 or 1 element) — to effectively model push-based stream processing. Reactor project is well suited for microservices architecture and offers back pressure–ready network engines for HTTP, WebSockets, TCP and UDP traffic.
RIBs — which is short for router, interactor and builder — is a cross-platform architecture mobile framework from Uber. The key idea of RIBs is to decouple business logic from the view tree, and thus ensure the app is driven by business logic. This is actually an application of Clean Architecture in mobile application development. By applying consistent architecture patterns across native Android and iOS, RIBs provides clear statement management and good testability. We advise putting business logic in the back-end service rather than leak it into the view, so if you do have a complicated mobile application, RIBs can help manage this complexity.
We’re in favor of asynchronous and reactive styles of programming especially for network I/O-bound distributed systems. Reactive libraries often sit on top of a lower level nonblocking communication framework such as Netty. Recently SwiftNIO, an open source nonblocking networking framework from Apple, has grabbed our attention. SwiftNIO is similar to Netty but written in Swift. It’s currently supported on MacOS and Ubuntu and implements HTTP as a higher-level protocol. We’re excited to see the usage of this framework and integration of it into higher-level application frameworks and other protocols.
In the last issue we featured PyTorch, a deep-learning modeling framework that allows an imperative programming style. Now TensorFlow Eager Execution provides this imperative style in TensorFlow by enabling execution of modeling statements outside of the context of a session. This improvement could provide the ease of debugging and finer-grained model control of PyTorch with the widespread popularity and performance of TensorFlow models. The feature is still quite new so we’re anxious to see how it performs and how it’ll be received by the TensorFlow community.
TensorFlow Lite is the designated successor of TensorFlow Mobile, which we mentioned in our previous Radar. Like Mobile it is a lightweight solution tuned and optimized for mobile devices (Android and iOS). We expect the standard use case to be the deployment of pretrained models into mobile apps but TensorFlow Lite also supports on-device learning which opens further areas of application.
We’re trying out troposphere as a way of defining the infrastructure as code on AWS for our projects where AWS CloudFormation is used instead of Terraform. troposphere is a Python library that allows us to write Python code to generate CloudFormation JSON descriptions. What we like about troposphere is that it facilitates catching JSON errors early, applying type checking, and unit testing and DRY composition of AWS resources.
Truffle is a development framework that brings a modern web development experience to the Ethereum platform. It takes over the job of smart contract compiling, library linking and deployment, as well as dealing with artifacts in different blockchain networks. One of the reasons we love Truffle is that it encourages people to write tests for their smart contracts. You need to take tests really seriously as smart contract programming is often related to money. With its built-in testing framework and integration with TestRPC, Truffle makes it possible to write the contract in a TDD way. We expect to see more technologies similar to Truffle to promote continuous integration in the blockchain area.