Hoverbear

It's a common pattern: a database developer at a startup is probably on the Product subteam of the Engineering team at their company. In a department store, shoes are a subcategory of clothing, while your favorite thermos is probably in the travel department.

In any Github organization, there are teams within teams within teams. In any large department store there are categories deeply nested. In any recipe book, there are many ways to classify food.

So how can we model them?

Not long ago, Microsoft started iterating more heavily on their long-existing "Windows Subsystem for Linux" feature. The feature has existed for some time, but recently has it become much more usable for everyday Linux development work.

In this post, we'll investigate some ways to get the most out of WSL. I won't present anything new here, just providing a single place for how I or someone else could get things set up.

When designing an API for your crate one topic which can come is how to handle optional arguments. Let's explore our Options in Rust!

Recently there has been quite a bit of talk about WebAssembly, a new format for code for the web. It is a compile target for languages like C and Rust that enables us to write, and run, code from these languages in our browser.

In the interest of learning more about this technology (and to avoid writing more Javascript) let's explore together and get our hands dirty!

Disclaimer: WebAssembly is stabilized, but most implementations are not. The information contained here may become out of date or be incorrect, despite working at the time of writing.

In this post we'll be discussing one way to set up your machine for Rust development. There are different ways, particularly related to the text editor, so feel free to skip what is irrelevant to you. We'll focus on:

• Setting up Rust via Rustup.
• Valuable tools like clippy and rustfmt.
• Configuring VS Code for Rust.
• Debugging with the command line and inside of VS Code.
• Using different compile targets.

Everything we do should be functional on both Linux and MacOS, on Windows your mileage may vary. I, unfortunately, don't have a Windows instance to test on.

Recently there has been a lot of progress in the Rust language towards a robust asynchronous stack. In this article we'll take a look at what these things are, take a tour of what's available, play with some examples, and talk about how the pieces fit together.

We'll get started with the futures crate to start, move on to futures_cpupool, and then eventually to tokio. We will assume you have some knowledge of programming, and have at least thought about trying Rust before.

In Rust, function signatures tell a story. Just from glancing at the signature of a function an experienced Rust user can tell much of the functions behaivor.

In this article we'll explore some signatures and talk about how to read them and extract information from them. While exploring, you can find many great function signature examples in the Rust API docs. You can play around on the Playpen.

This article assumes some knowledge of Rust, glossing over a bit of the book should be quite sufficient if you are lacking that but have programmed before.

One of my favorite features of Rust is iterators. They are a fast, safe, 'lazy' way of working with data structures, streams, and other more creative applications.

You can play along on http://play.rust-lang.org/ and by browsing here. This article is not a subtitute for the documentation or experience.

Using the setup from my last two posts, let's play with some QoS parameters and observe the results.

The documentation for OpenWRT's QoS is rather lacking, please feel encouraged to improve it as you go!

In my last post, we explored how to set up a OpenWRT VM in VirtualBox.

Let's give it some clients! Since the router is using a intnets we need to configure some machines to use that as their primary way to connect to the internet.

Since Vagrant has support for multi-machine configurations and gives us minimal builds of machines, we'll use this for our clients.

For my CSC 467 project I'm studying the configuration and performance of various QoS parameters in OpenWRT.

The plan is to set up an OpenWRT router in VirtualBox and orcestrate some Vagrant boxes to create a VM network.

At Simbioses Lab, we've been recently looking at the federated authentication DACS as well as Keycloak. I've previously written about Keycloak, so let's take a look at DACS.

I was reading about the Docopt project the other day and really liked the standardized approach to --help prompts and argument parsing that it offers.

Luckly, there is a Rust Package to play with!

A really 'cute' problem popped up in our Data Structures & Algorithms homework and I wanted to write about it.

If you're in the class this will obviously ruin the fun, so read it later, after you're done!

An initialization system's main interface with the user is through it's configuration scripts and service files. Let's take a look at what this looks like for systemd and OpenRC.

With systemd, daemon configuration is handled by .toml configuration files. With OpenRC, this task is performed by shell scripts.

Whipped up an OpenRC script for Ghost. Feel free to use it for yourself.

Things to be aware of:

• The script was designed for Funtoo.
• The script expects Ghost to be in $GHOST_ROOT.
• The script runs Ghost as $GHOST_USER:$GHOST_GROUP.
• The script exports the $NODE_ENV to production.

In this post, we'll look at how runlevels work in two major init systems, systemd and OpenRC. If you're interested in trying out systemd, I'd suggest using an Arch Linux Live ISO. For those interested in trying OpenRC, check out Funtoo. Both of these will work great in your favorite virtualization solution.

One of my projects over the upcoming semester is to explore the Linux boot process and the job of the init (initialization) system. The init system is considered PID 1 and is responsible for a significant portion of userspace functionality. Common init systems on Linux are OpenRC and systemd. One of the key parts of an init system is to spawn new processes, like in command shell.

Executing child processes may be useful to any number of programs, but common applications include:

• Shells
• Init systems
• Launchers
• Interfacing with command line applications

One common monadic structure is the Option (or Maybe in Haskell and other languages) type. This can be seen as an encapsulation type. Consider a function which may fail to produce a meaningful value for certain inputs. For example,

fn main () {
  // Parses a string into an integer.
  from_str::<int>("4"); // A valid input.
  from_str::<int>("Potato"); // Definitely invalid.
}

While using Keycloak you may need to make authenticated requests between various services. How can this be accomplished with Immutant?

You may want to check this link to learn how to use Immutant with Keycloak.

In my past two posts, we took a surface level look at Immutant then took a look at deploying immutant applications to the Wildfly application server. This time, we'll take a look at how to integrate Keycloak with an Immutant app, again using Docker heavily.

If you haven't read the previous few articles, it might be useful to give them a quick glance over.

Currently, the tutorial on deploying to Wildfly with Immutant 2 is not written. Furthermore,the JBoss documentation isn't particularly tailored towards Clojure applications.

So, let's take a look at how to do this using the convenient dockerfiles provided by the JBoss project. We'll use Docker to simplify deployment and setup of Wildfly, but instructions for a non-docker application should be similar.

Create a basic Immutant application.

Starting from a lein new app learning command, set up your project like so:

Problem

You need a base image of Arch Linux that you're sure is a-okay.

Immutant is suite of Clojure libraries that is part of the JBossAS/Wildfly ecosystem. Great, fantastic! Clojure is a lisp that runs on the JVM, the CLR, and compiles to Javascript. Lets get started!

Some links we'll need:

• Immutant - The framework.
• Clojure - The language.
• Leiningen - The package manager.

I've been exploring the handy async over the last few days in the lab. One of my projects is a MongoDB API Adapter in Node.js and I was pleased by a novel way of handling control flow.

async.auto() is a function offered by the libary which allows you to declare a set of tasks and their dependencies, then the library determines the best way to compose the initialization.