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.
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.
It’s been almost six months since we released Log4j 2.5, and we have a bunch of neat things added since then. The biggest change is that now you can operate Log4j in a garbage-free mode during steady state logging. Sounds a bit jargony? The basic idea here is that once your application is initialized and doing its thing (the steady state), logging no longer contributes towards memory pressure, thus you have more control over memory allocation and gargabe collection. Various Java performance gurus point out that logging tends to add a lot of overhead to applications, and one major reason is due to garbage generated by the logging framework. The less garbage objects generated by the framework, the less time your application needs to spend collecting said garbage.
A friend of mine is trying to find motivation to write more often, so he asked if I could help motivate him. I suggested keeping a blog which led me to remember that I used to have one on Github. Here I am recreating this Jekyll-based site (the old one is still in the git history, but I never really posted much).