A blog about programming mostly.

For almost two years, I’ve been using GitHub Pages to host my blog. This tool handles a lot of things for you behind the scene: it builds your site and deploys it to a web server. GitHub implements this as a great example of continuous delivery, the marriage of continuous integration with continuous deployment. GitHub also lets you use your own custom domain name, but it doesn’t support TLS connections over them. Thus, I had to take matters into my own hands and go back to self hosting.

All developers have attempted to debug their programs by printing lifecycle and state information to the console. This concept, sometimes known as printf debugging, can be far more powerful of a tool than one might first expect. The essence of this debugging technique is the concept of logging, where developers add relevant information about the state of the running program to a log. The use of logging is vital to both developers and operators, and it is important to understand how and why to use logging from both perspectives.

Microservice architecture is the latest fad in software development, and as such it comes with numerous conflicting definitions. To help clear up this confusion, we’ll discuss what microservices are, how they relate to older development architecture patterns, and why and when they are useful. In the enterprise world, service oriented architecture was the established paradigm in software development, and this typically incorporated the SOAP standard and web services. Some concepts from SOA, such as loose coupling and domain-driven design, translate well into microservices, but other concepts such as global transactions and global data consistency do not scale well in such an architecture. One major pain point in SOA that microservices helps to address are monolithic applications and the pains behind deploying new versions of them. Another problem stems from incompatible implementations of SOAP being widely used which tend to nullify the benefits of using a web services standard for loose coupling. Expensive proprietary software is also a large downside to typical SOA style development which has not yet reappeared to a similar extent in microservices. Data scalability and schema evolution are another hard issue in monolithic architectures which tend to be more manageable in a microservices architecture.

Applying the reactive manifesto to microservice architecture is a difficult problem to solve. One of the more difficult facets of this type of architecture is designing secure microservices. One common way to secure microservices is by using JSON web tokens to securely share authentication information between services and clients. This standard is great as the authentication information can be encoded directly in the token instead of needing to be queried from a central location on every service call. For example, upon logging in to an SSO page, the authentication service can create a JWT using a private RSA key to sign the token, and this JWT is returned to the client. The client can then use this JWT on subsequent calls, and the integrity of this token can be checked against the public RSA key of the authentication service. As a neat side effect, microservices do not need to be proxied by an authentication gateway as the authentication information is now self-contained and verifiable in a distributed fashion.

I’ve come across a small annoyance with SSH when waiting for a server to boot. For instance, while starting a Karaf container, rebooting a Linux VM, or waiting for an AWS instance to come online, I don’t like having to continually retry to connect to the server. Instead, I’ve been using a small little Bash function for a while now to continually retry to connect to the server. What’s neat about how this works is that if you get disconnected, it will continue to retry. However, if you disconnect manually, it will stop retrying because SSH exits with a successful status when you disconnect properly. The following function can be used with any implementation of SSH, but I recommend using OpenSSH.

The front end side of web development has been rapidly changing for years now with tons of frameworks, tools, and tiny npm libraries. A lot of this has been due to limitations in the JavaScript programming language and its standard API present in web browsers, but plenty of frameworks exist now for implementing a rich web application using an MVC or MVC-like architecture. The rise of single page applications where the entire site is dynamically loaded and modified through JavaScript has made the need for stricter architectural patterns a modern requirement of web development.

Reactor 3.x is a Java library for writing reactive applications using the Reactive Streams standard. Reactor Core provides a reactive streams implementation similar in style to RxJava 2. Because it is based on standard reactive streams, Reactor can easily integrate with any other reactive streams library (particularly RxJava 2). There are adapters available for RxJava 1 and the CompleteableFuture API as well as conversions for the new JDK 9 Flow reactive stream interfaces. Reactor also provides an IPC API for implementing reactive streams systems for general networking and off-JVM communication. The main implementation of the IPC API is Reactor Netty which provides TCP, UDP, and HTTP DSLs. There are other modules in the works, but Reactor 3.x is still under heavy development.

Microservice architecture is amongst the latest in best practices in software architecture. Essentially, microservices are small, independent applications that provide REST APIs for communication. These applications are akin to the Unix philosophy of small programs: each program does one thing and does it well. Each application should work on its own and be independently deployable, thus making each microservice independently maintainable. One simple way to check if a service is a microservice is if it is easily described in a single, simple sentence.

I have tagged version 1.0.7 of psgrep(1), the simple little shell script to search through your processes, with a focus on GitHub-related updates. This includes a cleaner README, a GitHub pages site, and updated bug reporting links for using GitHub. This officially marks the migration of the psgrep repository, once again, to a new host. Note that this has been mirrored on GitHub since version 1.0.6 for use with package managers, and now I’ve also added release notes for all the historical versions going back to 1.0.3 all the way from 2007! Oh wow has it been that long? This project has gone through multiple source code management systems including Subversion, Mercurial, and Git, across at least two or three different hosts. I can imagine that Git is here to stay for a while, but they say that about everything.