Functional JavaScript for modern Rails

Rails 7 and 8 have been the most exciting developments for us Rails developers to come along since Rails was first released almost twenty years ago. I’ve been lucky to work on Hotwire-architected applications for a while now and I really enjoy the clean simplicity and productivity benefits of server rendering with minimum JavaScript on the front end, enabled by the Hotwire stack.

However, Stimulus.js, the “modest JavaScript framework for the HTML you already have”, forces us to use JavaScript classes. My main issue with them is that they go against the grain of JavaScript itself. They are syntactic sugar over the language’s actual design which is geared towards functional programming and composition of prototypical objects. Therefore to properly use classes you have to master “original” JavaScript and a whole extra layer of needless complexity when the original is more expressive and fun anyway.

I tried writing wrappers around the syntactic sugar to use Stimulus.js without classes, but it got very messy and convoluted and just didn’t feel right.

So this summer I started working on a library that takes the same approach for HTML as Stimulus.js but allows us to write our controller code using functional or whatever JavaScript paradigm we want, rather than forcing us into classes. I called it ATV for Actions, Targets, and Values—the core components of Stimulus.js.

Here is a page showing ATV in action: https://www.sbrew.com/atv_by_example, and here is the GitHub home page: https://github.com/timbreitkreutz/atv.js.

I’d love to hear your thoughts or suggestions!  Especially if you are an old-timey JavaScript programmer like me.

Human Generated Story

 In this world of everythingGPT, we are now surrounded by artificially created nonsense.

Inspired by the one-word-story game, Human Generated Story is a multi-player web game that allows you to invite your (human) friends and create some fun nonsense without the help of any machines or their learning.

Have fun!

https://sbrew.com/stories/random

Headcount Fallacy

(DISCLAIMER:  I’m not presenting original ideas here. I apologize for any missing attributions and welcome any/all suggestions to appropriately attribute any ideas)

Do you want to maximize productivity of your software development team? Most people* would say yes, if they have anything to do with a software development team. If you say yes, another question to ask is “can I increase my team productivity more by 1) adding more programmers or 2) by improving training, tools, facilities, work environment, face-to-face time, development lifecycle process, and other intrinsic motivators.” If your organization’s instinct is to respond with 1) then you are falling into the headcount fallacy. 

To give an example, say you have a distributed team of 8 people working on a software product. If their mean salary is $100,000, that means you have a budget of $800,000. Assume your company spends $10,000 per team member per year on equipment, training, travel for team building and offsite work sessions, etc. Say your business wants to increase its rate of feature development by, say, 20%.

Plan A would be to hire four more team members for a team size of 12.  This would increase the annual budget by $440,000. With a team of 12, and no other changes, a 20% increase might be possible†, especially if your company hasn’t succumbed to the headcount fallacy to get where it is today.

Plan B would be to hire 2 more team members for a team size of 10, but use the extra $220,000 each year (increasing budget to $32,000/mo each)  for better equipment, training, vacations, some face-to-face offsite meetings, etc. Unless your team already has the best equipment, training, and productivity enhancing accouterments already, this would almost certainly have a bigger than 20% increase impact on productivity. Certainly it would improve team performance more than adding 4 more folks who are immediately stretched to the limit.

The above scenario is oversimplified to make a point (we are ignoring full costs of employing people, for example), but if you consider costs of turnover in your staff, the scale tips much more towards Plan B, since you are lowering your risk of losing hard-to-replace staff (both their skills and tribal knowledge).

For ideas on how to spend extra dollars on team productivity instead of headcount for a development team, I suggest reading Dan Pink’s book Drive‡. It shows the motivators for information workers. For other teams the ways to increase productivity and reduce turnover will probably be different but the same headcount fallacy applies to all kinds of work.

* I have had discussions with managers in the past where they did not agree with this goal. Instead, their focus was on individual productivity.  If that’s the case for you, then skip the rest of this post :)

† https://en.wikipedia.org/wiki/The_Mythical_Man-Month)

‡ https://www.danpink.com/books/drive/

Slicing the Pie

Just stumbled across this fascinating video--A number of years ago I tried to set up a similar scheme, but Mike Moyer seems to have done a great job of adding risk weighting factors and anticipating all the possible scenarios.


http://slicingpie.com/slicing-pie-at-the-international-startup-festival-in-montreal/

Play more sports!

PlayCity matches you with nearby people who want to play the same sports you do. We are in beta and we are looking for test users for our iOS app. You will also require an active Facebook account. 
Please email support@wannaplay.ca with your Apple ID if you'd like to be included in our beta group. Thanks!

Stop Writing Bugs

Recently I watched Douglas Crockford's New Developer's Conference 2014 talk. (Is there a more up-to-date version out there?)

It reminded me of something: most of the great programmers I've admired over the years were the ones that seemed obsessed with not writing bugs. Crockford's talk starts with the motivation for JSLint (I run all my JS code through this great tool)... help the world avoid bugs.

It seems like such a basic tenet but many programmers and even more managers/owners don't seem to value this hygiene factor enough.

Many of the other principles I strive to work by are inextricably linked to bug avoidance:

* DRY:  Needless duplication and redundancy increases the chances of writing a bug
* KIS: Simple, elegant designs lead to fewer (or at least easier to find) bugs
* Only build what you need: If you focus on minimum viable products, minimum viable implementations, etc., you are much less likely to add bugs.
* Test oriented/driven development: As a last resort, most of us also need a thorough test harness and coverage to help us avoid writing bugs.

(On a side note, I was inspired by Crockford's talk to try writing some JS without using "this" -- I updated the http://sbrew.com/puzzle page to avoid "this" and use the object creation technique Crockford described).

Affordable and improved alternative to deadmanswitch and pingdom

Now in public beta:  wdt.io (Watch Dog Timer) -- a new utility to monitor your systems!