There are actually quite a few resources out there for a novice programmer to learn about data types like strings, integers, floats, and more. The wikipedia page, as an example, covers a broad spectrum of potential meanings. Just about any book or tutorial focused on a particular programming language will start off by listing the types supported by that language. This makes sense, since they are the fundamental building block of being able to do pretty much anything in that language.

Even though I’ve developed software for a number of years now, there’s one question that has always been in the back of my mind and I haven’t had the time or patience to really answer, until now: What is a binary executable anyways? For this example, I wrote a brutally simple Rust program that includes a function “sum” to add two integers together, and am invoking it from main(): fn main() { println!

This year, my journey to learn Rust (and actively use it in a few side projects) has been a treasure trove of learning experiences. Lately, I’ve been finding myself trying to wrap my head around not just new syntax, but entirely new software programming paradigms that I simply haven’t been exposed to before. In my career thus far, I’ve mainly used two languages professionally: Python, and Go. It turns out this forms a pretty interesting story arc, since these two languages paint a wide spectrum of approaches to enabling the developer to be expressive and productive while managing the runtime tradeoffs of doing so.

Before jumping into any programming language, you often hear about its “heavy hitters” - the features that usually make the highlight reel when someone “in the know” is trying to summarize the strong points of the language. In 2015, as I was learning Go, I would often hear things like concurrency support, channels, concurrency support, and Interfaces. Also concurrency support. With Rust, thus far the highlights have included things like strong support for generics, lower-level control, and an emphasis on memory safety manifested in the unavoidable ownership model.

Lately I’ve been working on graphics programming in Rust, as a continuation of my first steps with the language. As part of this work, I created a type I created called Vec3f, to hold cartesian coordinates for a given vector: #[derive(Copy, Clone, Debug)] struct Vec3f { x: f32, y: f32, z: f32 } In the natural course of this work, I needed to add certain methods for this type to allow me to perform calculations like cross product, and dot/scalar product.

This year I’ve been picking up Rust as not only a new learning opportunity but also in service to a few side-projects I’ve been getting involved with. Like a lot of developers, I learn by doing. After spending a few weeks reading the Rust book and watching videos, I looked for some easy project ideas that I could use to explore the language that goes further than a simple “Hello World” which often doesn’t actually give you much breadth at all.

This blog post will focus on a topic I don’t usually dive into (Javascript and related tooling), but I felt like others might benefit from the solution to a problem I encountered while doing local development for antidote-web, the web front-end that powers NRE Labs. A quick aside on the architecture for the front-end code for the Antidote platform - the antidote-web project is the lynchpin for everything. It’s where the general structure of the front-end app is managed.

Lately I’ve been looking at some tools to make it easier to package containerized applications as lightweight virtual machines, to get the best of both worlds: the developer experience of a Dockerfile with the added protection of a hypervisor. As part of this process, I’ve been digging into Juniper’s containerized routing stack called cRPD, and trying to get that into a virtual form factor, so that I can effectively have a Linux router that happens to use the Junos routing stack.

In the last post I wrote about my journey from Python to Go as my primary language, and how I am now exploring Rust. This will be the first in a series of posts on Rust, mostly written from this perspective. I realize not everyone is going to Rust from Go, but that’s my perspective, and it will be impossible to keep this perspective from showing through and making comparisons between Rust and Go or Python.

Early this year I wrote about returning to first principles. I think this desire to dive deeper is a natural continuation of my goal of becoming a more well-rounded technologist. While it’s good to know and exploit your strengths, I think it’s also healthy to try and fill gaps where you see them, and I feel this is an area that warrants some focus for me. One way that I’ll be working towards this focus in 2020 is learning Rust.

I feel very strongly (and have for some time) that fundamentals are really important in a technical career. I didn’t start my career with a traditional CS degree, and while there were some fundamental knowledge to be picked up along the way, much of my education and early work experience bypassed a lot of the lower-level fundamentals and placed heavy emphasis on operating technology. This feeling of pulling levers and pushing buttons, rather than actually building things, in large part was responsible for me shifting back into software development full-time.

In the previous posts, I covered the basics of connecting to NATS in Go and the different ways subscribers can request information is sent to them. In this post, I’d like to build on those concepts by exploring how to structure your NATS-powered Go code so that things are clean and DRY. I’ll also show that trying to make things too DRY can be problematic; as with everything, moderation is a good idea.

Publish/subscribe messaging platforms like NATS allow us to build highly event-driven software systems, where we can build software to constantly listen for relevant messages and take action accordingly. This is what makes EDI projects like StackStorm (a project I’ve worked on and written about before) - and others like it- so powerful. Another advantage of pub/sub systems is that publishers don’t have to know or care if anyone is listening. Whenever information needs to be sent, it’s sent.

I am doing some prototyping for a project and part of this includes becoming more familiar with the NATS project, including its Go client (since all of the components in my project that will be talking to NATS are written in Go). In short, I have a bunch of little services that need to talk to each other, and a message broker like NATS fits the bill. One thing that drew me to NATS specifically is that it is unapologetically - nay, proudly - simple.

I awoke yesterday to a very crisp Tuesday morning in Portland, Oregon. I had just poured myself a nice glass of Stumptown Nitro cold brew coffee, and wandered upstairs to my office for an 8AM conference call. I joined the meeting, and started going through my usual routine - part of which includes looking at the day’s NRE Labs stats. Here’s what I saw: Well, that kind of sucks.

When deploying an application to Kubernetes, you almost certainly will want to create a Service to represent that application. Rather than relying on direct connectivity to Pods, which may be ephemeral, Services by contrast are long-living resources that sit on top of one or more Pods. They are also the bare minimum for allowing those pods to communicate outside the cluster. While Services are a nice abstraction so we don’t have to worry about individual Pods, they are also fairly dumb.

I have a predominantly technical background. You can show me all the slide decks you want but until I can get my hands on it, it’s not real to me. This has greatly influenced what I’m focusing on now that I’m doing more than just technical work - how to reduce the barrier to entry for people to become acquainted with a project or product. As a result, I’ve been getting more involved with Tungsten Fabric (formerly OpenContrail).

When I got started in networking, my education (like so many network engineers) was all about Cisco. All my networking courses in college, as well as my early networking jobs all used Cisco curricula and equipment, and valued Cisco certifications like the CCNA/CCNP/CCIE above all. It wasn’t until I had already been in the industry for about three years or so before I even got my hands on a Juniper device, and by that time, my IOS habits had taken root in my muscles, which made the new set/delete style of Junos configurations even more strange.

I’ve been passionate about the idea of proactively testing network infrastructure for some time. I revived and added to these ideas in my last post. In that post’s video, I lay out three types of network testing in my presentation: Config-Centric - Verify my network is configured correctly State-Centric - Verify the network has the operational state I expect Application-Centric - Verify my applications can use the network in the way I expect In the same way a software developer might write tests in Python or Go that describe and effect desired behavior, the network engineer now has a growing set of tools they can use to make assertions about what “should be” and constantly be made aware of deviations.

In December 2015 I had the distinct honor to be selected to attend a NASA Social event that coincided with the OA-4 launch, an ISS resupply mission. NASA runs these events occasionally to give the world some insight into what goes on at various locations pertaining to the space industry. There’s a lot of really cool work going on, and I’m happy to finally have a chance to publish my experience on this amazing trip.