DEV Community: Stephen Hara

Intro to the Terminal: Public Draft Available!

Stephen Hara — Tue, 27 Aug 2024 15:29:21 +0000

I'd like to announce that the public draft of my ebook, A Gentle Introduction to the Terminal, is now available!

It has some WIP pages that I still need to mark more clearly, but there's still, I think, quite a bit of good stuff for folks new to the terminal and the command line in general!

If you have comments or other feedback, please leave a comment here, or drop me a DM/mention on Bluesky or Twitter!

No-Spoiler FF14 Progress Checks

Stephen Hara — Tue, 16 Jul 2024 08:43:27 +0000

As I've been playing the new FF14 expansion, I wanted to see if I could check my progress without spoilers. As it turns out, you can do it pretty easily with a bit of Javascript and JQuery!

First, open this page, which has a list of all the quests in the new expansion.

Second, open up the developer tools for your browser. You can right-click and find the option that way, or maybe the shortcut Ctrl+Shift+C works like it does for mine.

Next, open the console tab of the developer tools. This will open a little prompt you can use as a Javascript REPL!

We're going to build a JQuery selector to find the elements we want. JQuery is a Javascript library that allows you to filter HTML elements on a web page based on class, ID, element type, and more.

Ultimately, my approach uses the current quest name as the "search query". We can find the position of the quest name in the list of elements and divide that by the total number of quests in Dawntrail to get a percentage of our progress.

By inspecting the HTML, we can find a few clues to help us craft a good query. The first is that the quests all appear in HTML tables, so we can probably use tr and td as starting points.

The summary of the page mentions there are 100 quests, so to check how our query is coming along, we can make sure there are 100 elements in our result. Let's try this:
$('tr').size()

Not quite right, as this returns 111, meaning we captured 11 more elements than we expect. But looking at the tables, there's an extra row on each of them that might be causing problems.

To keep the header of each table from being captured, we can use a pseudo-class - 2 of them, in fact!

> $('tr:not(:first-child)').size()

And that gives us 100! The pseudo-classes are :not and :first-child. :not takes another selector, including pseudo-classes, as an argument and filters them out of the results.

:first-child takes the first matching element of a group from the same parent. It's easier to understand with some examples, so I'd recommend checking the MDN page for more. https://developer.mozilla.org/en-US/docs/Web/CSS/:first-child

Combined, tr:not(:first-child) means "when a node has multiple tr children, capture all of them except the first one". In terms of the quest table rows, this means we skip the header and only end up with the quest rows!

Within each tr row is a group of td cells: they include the quest name, the "type", level, quest giver, any unlocks, and any rewards.

Quite convenient that once again, we only want to pick out the quest name - we can use :first-child again!

> $('tr:not(:first-child) > td:first-child').size()

Again, we get 100, meaning we didn't lose anything with this addition. The last thing we need is to pick out the quest name. We can't do this directly from these td elements, but each element has an a tag.

We can capture these anchor elements in our selector:

> $('tr:not(:first-child) > td:first-child > a').size()

And then we can use the JQuery function index(selector) to find the index of a matching selector. In this case, we'll use an attribute selector on the title attribute.

Putting this together, we can do something like:

> $('tr:not(:first-child) > td:first-child > a').index($('[title="A Saga in Stone"]'))

This gives us 3, which is a classic off-by-one error. Since index looks at it like an array, we can add 1 to give us the position instead of the 0-based index.

> $('tr:not(:first-child) > td:first-child > a').index($('[title="A Saga in Stone"]')) + 1
4

Meaning if you're on the quest "A Saga in Stone", you're on the 4th quest of the Dawntrail quest line!

Easy Approximations with Monte Carlo Simulations

Stephen Hara — Tue, 25 Jun 2024 07:43:22 +0000

Hi there! Today, I was writing a different blog post, but it started getting pretty long, so I decided to pivot and talk about something a little simpler: Monte Carlo simulations!

I first learned about the Monte Carlo method of calculating answers to probabilistic situations in university as part of a class on numerical methods. To quickly summarize: given some scenario with non-trivial but easily understood base probabilities, rather than going through the complicated process of determining the concrete answer of any particular question, in a Monte Carlo simulation you instead make a large number of observations based on the known probabilities to answer the question.

In that class, we used it to estimate integrals for a function over a specified range. Building up to that can be done in a few high-level steps:

First, we need to be able to calculate the function;
Then, we need to take randomized samples within the range;
Last, we need to accumulate a large number of samples and average them, then multiply that by the range

The average of all those samples will be the integral over the range. Let's build a Monte Carlo simulation for the square function: $f(x) = x^2$

First, let's make our function.

function square(x) {
  return x * x;
}

Simple enough! Let's also try to call it a number of times:

for (var i = 0; i <= 10; i++) {
  console.log(i, square(i));
}

// results in...
0 0
1 1
2 4
3 9
4 16
5 25
6 36
7 49
8 64
9 81
10 100

Cool! Next, how can we take randomized samples? We'll need to use the Math.random() function in JS to get a random number between 0 and 1. Since we'll likely want to use a different range - say, -10 to 10 - we have to do a little bit of finagling and math.

We can use the random number as a measure of how far into the range we want to sample. Then, we multiply the random number by the total range, and add the lower limit of our range to that result, and that will give us the value for "x" we sample.

for (var i = 0; i <= 10; i++) {
  const lowerLimit = -10;
  const upperLimit = 10;
  const range = (upperLimit - lowerLimit);
  const sample = lowerLimit + (Math.random() * range);
  console.log(sample, square(sample));
}

// example output
0.2442285408573639 0.059647580169317066
3.845802381476089 14.790195957367157
-0.5799238892346903 0.33631171730508935
8.47264325104629 71.78568365950024
8.705075937763862 75.77834708223538
-1.4103879134353559 1.9891940663645369
-5.962861318180601 35.555715099854496
-7.21220376021984 52.01588307892919
-5.478958693659344 30.0189883668253
-7.5575637333194035 57.11676958318472
2.1570867021239906 4.653023040480154

Great! We're almost there. Now we just need to add up all the samples, average, and multiply:

// set some of our variables up here
var sum = 0;
const sampleCount = 100000;
const lowerLimit = -10;
const upperLimit = 10;
const range = (upperLimit - lowerLimit);

for (var i = 0; i <= sampleCount; i++) {
  // get the sample location...
  const sample = lowerLimit + (Math.random() * range);
  // and add the sample result to the rolling sum
  sum += square(sample);
}

// make a rectangle (as described below)
const result = range * (sum/sampleCount);

// technically 2000/3 but #fractionsincode
const expectedAnswer = 666.6666667;
// find out how wrong the estimate is
const error = Math.abs(expectedAnswer - result);
// make it a percentage for clearer presentation
const errorPercent = error/expectedAnswer * 100;

// some pretty output
console.log(`Approximate area under the curve for range [${lowerLimit}, ${upperLimit}]: ${result}`)
console.log(`Error of ${error} (${errorPercent}%)`)

// here's a couple of runs
Approximate area under the curve for range [-10, 10]: 667.6623214481579
Error of 0.9956547481579037 (0.14934821221621816%)

Approximate area under the curve for range [-10, 10]: 666.6071783517447
Error of 0.05948834825528593 (0.008923252237846726%)

Approximate area under the curve for range [-10, 10]: 663.6055831735898
Error of 3.0610835264101297 (0.45916252893856135%)

And that's pretty much it! As you can see, it's not perfect, but it's not too wrong if you just need to get an estimate. Plus, it's pretty simple!

Summary

Monte Carlo simulation is a great way to explore problem spaces. I've previously used it to simulate leveling gathering jobs in Final Fantasy 14 as I talked about in a blog post a couple years ago. Unfortunately the code is missing and I'm not sure where it is, but once I find it I'll update that post!

If you enjoyed this post, why not subscribe to my newsletter?

Appendix: Why Multiply By the Range?

I sorta forgot that you need to multiply by the range when I started working on this post, and it wasn't quite clear to me why the initial answers were wrong, so I figure it might be helpful to re-hash my re-learning. For posterity!

Let's start with a very crude sketch of our function, $x^2$:

When we do the sampling process, we end up getting the height of the function at a bunch of random spots on the x-axis:

When we then divide by the number of samples, we get the estimated average height of the function across the range. In order to get the estimated area, we need to turn it into a rectangle, so we multiply it by the range - or, the length of the desired rectangle.

Some Books to Upskill Communication For Software Engineers

Stephen Hara — Mon, 17 Jun 2024 14:21:39 +0000

(Full disclosure: This post includes affiliate links which, if you click through and purchase the product, will earn me a small commission. This helps support my writing so I can keep writing helpful posts like this!)

When we write code and build software, we're not just communicating to the computer the instructions we want it to perform. We're also communicating various intents to our future selves and our team members:

What the system should do now, as the code available to be executed
What the system should do in the future, as code hidden behind feature flags and other forms of prevented execution
How we want the code to grow with the system, as architectures and design patterns

Ultimately, we are doing an awful lot of communicating in our work as developers. And "work on communication" is pretty common advice, but it's hard to find specifics. So I'd like to share 3 books I found incredibly helpful for my growth and improving my communication skills!

The Science of Effective Communication

The Science of Effective Communication by Ian Tuhovsky is a general book on communication and how it's used to build and maintain connections of all kinds. It goes over virtually all aspects of communication, from the first chapter about listening to the last chapter about interview skills.

In between, it addresses how to keep conversations alive; how to handle discussions with high emotions; persuasion and why you shouldn't feel bad about trying to be a little persuasive; complaining; communicating with non-native speakers and hearing-impaired speakers; and a whole lot more.

Software developers spend a lot of time talking to other people: our team, our manager, their manager, the product manager, HR, recruiters, clients, and on and on. This book is full of actionable tips and ways to think about thoughtful conversations so you can improve your career, improve your relationships be it business or personal, and carry yourself with more confidence.

Writing for Busy Readers

Writing for Busy Readers by Todd Rogers and Jessica Lasky-fink is specifically about writing and communicating through text and accompanying media. The advice is based on studies and real successful work by the authors in increasing outcomes for clients like schools, political parties, and enterprises.

The main conceit of the book is that readers in today's world are really busy. What that means is you need to reduce the barriers of understanding your writing as much as possible, with strategies like using simple language, using layout and formatting effectively, and make your intended outcomes easy for the reader.

The easiest way for software developers to increase our impact and visibility is by writing. It leaves a permanent mark on the organization that says "I contributed to our body of knowledge or systems of value". Whether it be design docs, proposals, code documents, or just a Slack message asking for thoughts, writing is a critical skill to develop for developers.

The authors also offer several free resources on the book's website, so you can get a lot of benefit before buying the book as well.

Docs for Developers

Docs for Developers by Jared Bhatti, Sarah Corleissen, Jen Lambourne, David Nunez, Heidi Waterhouse is more specifically about writing documentation, but documentation is an incredible exercise in effective communication. You can't know what the right documentation to write is without knowing what your reader needs, and that's a foundation of communication.

Much like software products, documentation requires planning, drafting and revision, and evolution and maintenance. The book goes through these steps from the perspective of a fictional cuddly dog-to-human translation service called Corg.ly. It covers the pre-work, the work itself, and the continuous aspects of documentation, as well as how to include code and visual content, publishing, organization, and more.

One of the more important takeaways from this book for me was the idea that there are different kinds of documentation: tutorials, API references, glossaries, etc. It's more helpful to decide on one for each piece of documentation than to try and do multiple things with one piece. Similar to the idea of separation of concerns. There's a great talk by Daniele Procida that has the same idea, but presented differently.

Summary

Communication is an integral part of our work as software developers, and we should strive to improve our skills in communication as much as we should strive to improve our technical skills. I thought these books were all tremendously helpful, and I think if you haven't read them, you'd be doing yourself a great favor if you did!