Code / Technology / How-Tos

Azure monitor.

Commitment tiers.

Dedicated clusters.

Inability to revert.

Sampling Rate - bugs?

What I learned in boating school is…what I learned in boating school is…what I learned in boating school is…

* A little practice, everyday, over a long period of time is much better than a ton of practice, over a week.

* Don’t get overwhelmed by the amount of content online. Everyone has some guaranteed way to study; find what works for you and stick with it.

* Read the information; type the details; hand write what it means in your own words.

* While consistency is key, that doesn’t mean you can always sit down, focus, and get the job done (especially with work, a social life, hobbies, etc.). It’s okay to to chalk some topics up to “not today”. Just as long as its not too often.

* Doing something physical makes it a ton easier to focus on whatever you need to focus on.

* Some work can be done with a boring movie on in the background; other works require the soundtrack to Interstellar echoing through the cavernous halls of galactic cathedrals so that you can save humanity from existance.

* Read each question closely and don’t forget that your first answer is probably not your best answer.

* Find the pattern, understand the pattern, hand-write the pattern, apply the pattern. Repeat.

Over a year ago, my team and I set out to develop a new version of our application; a distributed set of Dockerized microservices to provide customers with a high availability and sleek web application for high speed data transfer. Throughout this process, I’ve learned quite a few lessons. I want to start sharing some of these lessons here to not only reflect on these lessons in the future, but share any tidbits I picked up for others.

Today, I want to talk about Ruby benchmarking. This stuff is so useful! And I honestly wish this was one of the first things I learned how to do in Ruby. So here’s Ruby benchmarking in a few short lines.

First, Ruby has a benchmarking library built into its standard library, which ya gotta love. No need to import some random library. You can start by throwing this on the top of the file you want to test:

	require 'benchmark'

Easy as pie, right? Alright, now lets say we wanna test this snippet of code:

	Array(1..100).map{ |num| num ** 2 }

Lets slap a Benchmark.measure around it:

	Benchmark.measure {
		num_of_tests.times do {
			Array(1..100).map{ |num| num ** 2 }

This Benchmark.measure call will return four values in seconds:

  1. The amount of time spent executing the code that you wrote: (Benchmark.measure.user)
  2. The amount of time spent executing kernel code: (Benchmark.measure.system)
  3. The sum of the two totals above, or the sum of the kernel and the user process execution time: (
  4. The is final number is what I spend the most of my time looking at which is the elapsed real time: (Benchmark.measure.real)

To print these values you could do:

	puts Benchmark.measure {
		num_of_tests.times do {
			Array(1..100).map{ |num| num ** 2 }

or you could access a specific value with:

	stats = Benchmark.measure {
		num_of_tests.times do {
			Array(1..100).map{ |num| num ** 2 }
	puts stats.real

This would output something like: 87.810000. You can come up with all sorts of statistics on individual runs if you’d like given you have the num_of_tests and a few different measurements for total time.

And that’s a quick rundown on Ruby’s benchmark library! Efficient, easy, and a game changer for developers. I only wish I knew about it sooner!

After coming across digital gardens online, I decided I wanted to build one myself. I began this process by researching personal websites and digital gardens that I found interesting, dynamic, or unique. A ton of my inspiration goes out to these developers, so thank you!

Here’s a small sample of these pages:

So, I come across this concept of a digital garden. Mind you, I’m not actively developing a website at this point. But this idea wasn’t something that appeared and disappeared in passing. It burrowed into my brain.

A great quote from Maggie Appleton’s fantastic article:

The point of the garden is that’s it’s a personal playspace. You organise the garden around the ideas and mediums that are particular to you.

This is more about making something all by myself containing whatever I want in whatever format I want. The beauty here is the dynamic nature (see what I did there) of the garden and the fact that it isn’t a continuos feed of curated content, but rather an ever-changing, and very raw, work in progress. The goal here isn’t pristine styling and perfect content; it’s about growth, over time, above all else.

After perusing numerous digital gardens and working up the courage to begin my own, I struck out with a clear design in mind.

  1. Let’s host on Github pages, because who wants to pay money to run a server.
  2. Let’s buy a domain name, because who wants Github in their domain name (sorry, not sorry Github).
  3. Let’s use Jekyll. A clear favorite of digital gardeners (is that a term? I’m not sure), Jekyll allows developers to exist between the worlds of templated Bootstrap and static blogs like Wordpress. It’s the perfect technology for a digital garden and has been a joy to learn.
  4. Let’s use SCSS, because organizing CSS let’s me think better.
  5. Let’s have some fun and figure out the rest along the way.

Last year, my brother and I concocted an elaborate plan for my Dad’s 60th birthday: create a murder mystery night to rival all murder mystery nights which could provide entertainment to all thirty members of our extended family. Leave it to the two of us to blow this thing way out of proportion.

A few sync up meetings, a bunch of professional character drawings, a handful of real life props, more than a dozen character skill checks, and a dedicated Python server and Twilio gateway later and we ended up with something fantastic. It was a fun project and something I may open source someday soon.

Players walked around a pre-arranged home with clue cards hidden and placed around an estate. These cards have four digit event codes which provided the player with a basic description of the scene. User’s could then either roll a real die at the event location or let the computer automatically roll for them. Based on the roll of the user and a predefined modifier which they handpicked via strengths and weaknesses before playing, players can receive a variety of responses which give tips on other characters in the game, point out critical evidence, or lead to other event codes with more information. There is also some somewhat complex endgame gates set in place which determine the outcome of the game based on the player’s decisions throughout the night.

At it’s core, it’s a Flask application with a static website and several API endpoints. It’s operates off of a CSV of prompts which are loaded into memory for fast lookup. I leverage Flask sessions to manage the character throughout their experience.

It was a really fun project and a fun little hack that I really enjoyed.

doctor jeweler rich_widow