Rust, WebSockets, and Yew

Almost two decades ago when I wrote my book Advanced Java Game Programming, I ended it with three chapters on the subject of multiplayer network communications over Hypertext Transfer Protocol (HTTP).  The final chapter demonstrated a browser-based chat applet in which 2D characters would move about in response to player clicks on the screen.  I described how to use what I called "HTTP Pulling", now known as HTTP Long Polling, to receive messages from the server through the firewall.

The modern replacement for HTTP Long Polling is WebSockets which is now supported in all major browsers.  Last weekend I was able to write my first browser-based application in the Rust programming language by using the Rust-based front-end framework Yew.  Today I was pleased to be able to successfully implement a browser-based chat application using WebSockets and Yew by following the instructions in the online tutorial Let’s Build a WebSockets Project With Rust and Yew 0.19 by Johnny Tordgeman.

 

The Rust Book

Tonight I finished reading The Rust Programming Language, informally known as "The Rust Book", by Steve Klabnik and Carol Nichols with contributions from the Rust Community.  The print copy published by No Starch Press covers the 2018 Edition of Rust.  There is also a free online version which is updated continuously.

I had started reading the Rust book last year and made it three-quarters of the way through.  This year I restarted from the beginning so I could refresh on the fundamentals.  It helped me understand a couple of Rust game programming books that I was reading simultaneously.

The book is well written with many code examples which are described in detail.  The authors ease the readers into the subject but then rapidly advance to more complicated topics in later chapters.  I assume that this is because they wanted to cover the entire programming language in just over five hundred pages.

I searched the Web to see if there is a second edition of the book coming out that covers the 2021 Edition of the Rust programming language.  Apparently there is not so I might start reading the online version for the updates and to review the material.  To help take me to the next level, I ordered from the same publisher Rust for Rustaceans: Idiomatic Programming for Experienced Developers by Jon Gjengset.

Retirement Calculator

Back in 1999 when the stock market was doing well, I wrote a browser-based retirement calculator application using the Java Servlet framework.  Since a Java Servlet renders the Hypertext Markup Language (HTML) server-side, the application stopped working when I stopped using the Java application server.  Since the application does not fetch or store data using a back-end server, I could have re-written the calculator as a JavaScript-based application and simply hosted it on a website fronted by a Content Delivery Network (CDN).

Now in 2022 when the stock market is not doing so well, I converted the application to my new favorite programming language Rust using the front-end framework Yew.  Yew compiles the Rust code to WebAssembly (Wasm) which then runs in the browser just like JavaScript.  You can view the converted source code and play with an online demonstration hosted on one of my websites deployed using Amazon Web Services (AWS) Amplify Hosting.

 

Rust and WebAssembly

My New Year's resolution this year was to learn the new Rust programming language.  I wrote a Hello, World! program in Rust many years ago and started reading the Rust book last year but now I am really getting into it.  You can follow my efforts on my new GitHub account.

My older open source Java code is hosted on SourceForge.net.  Many of my applications are Java game applets.  Now that Web browsers no longer support applets, I am exploring WebAssembly which can run both in browsers and in servers.

Today I was able to deploy a game that runs in the browser by following the instructions in the book Game Development with Rust & WebAssembly by Eric Smith.  I wrote the code in Rust, compiled it to WebAssembly, and then wrapped it in a thin layer of JavaScript so that it can run in a webpage.  You can play the game online at my GameSpawn website.

Specialist Pools

If a software development team gets to be too large, you might be able to refactor a monolithic application into microservices.  You can then split the team into smaller teams, each dedicated to its own microservice.  Within the smaller team, you can have specialists, each focused on a different technology such as front-end, back-end, automated testing, or DevSecOps.

If you instead decide to keep the larger team dedicated to a single codebase, you might be able to split the team into Specialist Pools.  Each pool of specialists is focused on a single technology and each has its own Specialist Lead.  Since not all feature development stories require work in all technologies, members of the specialist pool can be assigned as needed where needed.

At regular increments of some number of months, one member of each pool can be rotated to another pool.  This permits the developer to get breadth across the technologies while at the same time conserving the depth of knowledge within the remaining members of the pool.  If more than one developer from a pool is volunteering to rotate, the one who has been in the pool the longest might be given preference.

Babel Tower Programming

In the ancient story of the Tower of Babel, all of Humanity is unified in a common language.  They begin to construct a great tower which, in some variations of the story from other civilizations, might save them from possible extinction from another Divine Flood sent by an angry God.  Construction of the tower is abandoned when God disrupts the ability of Humanity to communicate by dividing their shared language into many.

Babel Tower Programming is what I call a form of Polyglot Programming in which the use of multiple computer programming languages impedes rather than promotes progress.  An example might be using one programming language for front-end development and a separate for the back-end when the same language could be used for both.  One sign that you are experiencing the impedance of Babel Tower Programming is when software developers are choosing their feature development tasks based primarily on which programming language will be used.

The solution, which I call the Incantation of Nudimmud, is to adopt a policy which requires that any new software features be developed in a common programming language.  Legacy code developed in the abandoned programming languages can be gradually phased out using techniques such as the Strangler Fig Pattern.  As Babel Tower Programming is a form of Technical Debt, the decision to move to a single language usually requires some cost analysis and both bottom-up and top-down support.

 

Head First Agile

I just finished reading from cover to cover the book Head First Agile: A Brain-Friendly Guide to Agile Principles, Ideas, and Real-World Practices. Even before I finished reading it, I started recommending this book to my co-workers. I tell them that they can get almost everything they need to get started in Scrum by reading just the first four chapters.

I own a number of books in the Head First series. Like the For Dummies series, the "Head First" books provide fun introductions to a variety of topics. Unlike the "For Dummies" series, you do not have to explain that you are not trying to insult someone when you recommend one of their books.

Role, Goal, and Dole

In agile software development, a user story traditionally follows this template:

As a [person in a role], I want [some software feature (the goal)] so that I can [achieve some benefit to the user or business].

Some years ago I came up with an easy to remember rhyming mnemonic for this, "role, goal, and dole", where I use dole as a synonym for benefit. The user story template then becomes:

As a [person in a role], I want [some goal], so that I can [achieve some dole].

2021-09-25 Update

Recently I have learned that some are suggesting using Who, What, and Why as the user story template inputs. I like this better as there is some ambiguity in the distinction between "goal" and "dole".

Jigsaw Puzzles

For most of my career as a software developer, I have used statically typed programming languages such as Pascal, Ada, Java, and TypeScript.  Recently, however, I briefly dabbled in using the dynamically typed languages JavaScript and Python.  Debugging all of the run-time errors in the dynamically typed code reminded me of my earliest years of programming in BASIC in which I would have to spend time searching for misplaced commas.

When I switched from JavaScript back to TypeScript, I sensed an increase in my productivity and my confidence in the correctness of my code.  To explain to a layman the difference between programming in a dynamically typed language as compared to a statically typed language, I came up with the following analogy.  It is the difference between assembling a jigsaw puzzle in which all of the tiles are square versus one in which the pieces are of a variety of different shapes that can only interlock in the correct way.