![\"Jorge](\"https://internetross.space/uploads/2023/3f903ee582.png\")
\n “The code can always get worse.”
\n“…there is no abrupt failure threshold associated with software quality…”
\nFrom: There’s No Limit to How Bad Code Can Get
\nA useful reminder about the endless, bottomless pit that a software project can become. The pit is not a barren void, it’s a gorgeous geological wonder of morphologies.
\n", "date_published": "2026-09-17T07:31:01-07:00", "url": "https://softlydeveloping.micro.blog/2026/09/17/the-code-can-always-get.html" }, { "id": "http://softlydeveloping.micro.blog/2026/06/16/morning-forage.html", "title": "morning forage 20260616", "content_html": "Dillo browser’s directory of bookmarks\nIs it Time to Regulate React?\nUbiquitous language worst case. Same name, different article.
\n", "date_published": "2026-06-16T06:42:28-07:00", "url": "https://softlydeveloping.micro.blog/2026/06/16/morning-forage.html" }, { "id": "http://softlydeveloping.micro.blog/2026/04/01/end-products-habiting-difference.html", "title": "End products, habiting difference", "content_html": "It’s Wednesday evening. Incandescence lazes out from the rectangle in the southeast corner of my home work station. Zen Master Bon Seong, a fiery bushel on screen, a big circle face in the biggest square. He is using the figurative Zen Stick to short-circuit our cognition. He is fond of saying things like “You are stardust” or “What is I?”.
\nJeff breathes hot air through the broom on his face. Those bits go through audio processing and seem to emanate from nowhere around the work station. “The infinite expansion of the same thing” is uttered. We’re discussing how people can interpret the same phenomena differently. As we say: “The whole world is made by mind alone.” And: “The whole world is a single flower.” As the Heart Sutra says: “form is emptiness, emptiness is form”. You cough. I’m startled. I freeze. I think you have COVID. I think I’m going to get it. Then get long COVID. Someone else sees you cough, they think it’s a sneeze and continue on. Perhaps it is.
\nThe dharma talk continues. There’s nothing wrong with our kaleidoscope of perspectives. They are regular. This is the human mind being itself, resting in its station, but painting a tale on snake, coloring it’s ridiculous karma all over “the small box” that is our little piece of understanding of the universe.
\nGosh, we’re talking about boxes from within boxes. Our thinking creates this separate, enclosed being. (Consciousness bound by a skin sack? Not today, the microbiome field transforms you. (Sigh. No help lugging our sacks and their biomic nerve fields closer together. We have decades of men making the Bay car-friendly, but I can’t get across conveniently. I can’t get to Berkeley from Potrero without spending as much time commuting as the duration sitting meditation with the other sacks for Wednesday night dharma talks.)) The problem is getting attached to difference. Not understanding our “universal substance” – what we say as a convenience. That’s why Zen is about returning to before thinking, accessing the truth before difference. So maybe instead: you cough, then I hand you a tissue.
\nI don’t want this post to be about the negatives of the human mind’s proclivity to be a multiversal agent. It’s not really a negative, is it? It’s a matter of fact about our minds as atoms floating in space. Space dust. So, instead: let’s relish in the generative creativities that difference making unleashes when multiple human minds are applied to a problem of interpretation.
\nZen students say: “All things return to the one.” Once again, I have returned to software. One of my favorite ones for organizing and observing life’s exposures, like Scrabble tiles. Despite the one, I’m thinking about difference. The way the one refracts and playfully escapes. Our turn here will be akin to Jewish monotheism – a personal return to spiritual foundations – a spiritual tradition where the only official doctrine claims one god but there’s no consensus about what that means.
\n\n\nAn often-cited medieval midrash asserts that each of the Israelites at Mount Sinai heart God’s revelation differently according to their own capacity to understand it. They each had their own individual experience of the Divine. – Sarah Hurwitz, Here All Along
\n
\n\nA long time passed but the Buddha did not open his mouth to say a single word. He then reached down, picked up a flower and, without a word, held the flower aloft. Nobody in the assembly understood what the Buddha meant by this action. Only Mahakasyapa, sitting at the far back, smiled. – Gye Mun Sunim JDPS, The Birth of Zen
\n
But not everyone smiled!
\nThis “problem” of software:
\nThe epistemological endeavor to solve challenges in the world, happening out there, with(in) reason.\nThen squeezing all that into binary logics and electrical pulses.\nHolding a shared thought among humans – sometimes only the wispy thrust of a thought – and making it instructions for the computer.
\nZen Master Seung Sahn used to say you have to “digest your mind meal." He meant your understanding.\nMaking software is a kind of digestion of understanding.\nPushing thought stuff through a cheese cloth named Divine.\nA streetcar named Desire.
\nThe software process is messy, from beginning to middle to end.
\nAs a Zen student, I must declare: Where does the one return? Software’s interpretive act is a mix up, a Deleuzian differencing that flies a-face a unifying core concept. Software is never completed, and is not easily located anywhere in particular. Is it those words on the screen, dormant? You could print them. Is it the code as it runs, sonic or electrical (im)pulses amidst fibers, plastics, and metals. Is it what the mouse clicked? When was it conceived? Was it the idea?
\nNot the cleanest of lines, but lines in flight.
\n\n\nI want to argue here that the distinction between the software system and its development–that is, between the process and product–is another “point of opacity” of software engineering since, albeit necessary, it cannot be kept up at all times. – Federica Frabetti, Software Theory
\n
Software is subversive to hard-dick narratives. It’s feminist, it’s counter-cultural in its essence. That’s why the gate-keepers are relentless trying to wrest it away from the hacker collective with a trademark.
\nThe wisp of generative artificial intelligence hallucinatory resonance is hardly surprising.\nIt’s a re-run run amok.\nWhere does the one return inside your stolen nebula of documents?\nNo citations, indeed.\nWhere is your mind, Algorithm?
\nMessy. Material. Just as digestion is wont to be, from mouth mashing through shitting.\nThe physical body process is mostly obscured by our containment sacks. But it leaks. It’s hacked.
\nThe metaphor is apt. The world is messy as it is, and software is in it, made from it, made for it. This is why the end product of the software process inspires programmers of acrimonious humor, sometimes of low emotional intelligence, or of self-deprecatedness, or simply exasperated, exhausted… these programmers must declare that which comes from the butt. “This code is crap.” “Who wrote this shit code?”
\nIt’s generally a pessimistic view to call code crap. I’d offer compost to lift us out of the sour sap to a corresponding brownish, molten tree sappy substance. A brighter horizon. Effluent cream - a regenerative solar punk version. Or something like “the best with what we had.” We need less snark in the industry, more heart, don’t you think?
\nThankfully (we can breath a sigh) there are loving defenders of our end products out there. (Com)posters on the Net. Rachel Kroll is one, synonymously online as rachelbythebay. She emancipates some lines (of code) and litigates her own “crap code” through a simulated trial judged by such an exasperated panel, and then performs my favorite type of “if I knew now what I knew then” refactor blogging with a procedural splunk. It’s a beautiful example of husbanding thought stuff a second time through.
\nRegarding playful escapings of difference.
\nLike verbalized language, programming languages provide multiplicities for getting thoughts out. In English spoken about town, adults will be overheard in conversation to utter variations on simple themes such as bipedal reversal, for example, with such enriched phrases as “they retraced their steps”, or “they went back”, or “they returned to”. Similarly, the general purpose Ruby programming language invented by Yukihiro “Matz” Matsumoto toward the end of the last century was composed with a syntax of including many lexical pathways to express its computer instructions. Of course, while these variations may not be imbued with the rich cultural context of spoken English idioms, they demonstrate what I’ve always found to be a never gets old trait of modern programming languages used in heterogeneous postmodern programming environments: there is creative choice!
\nLike English speakers, Ruby programmers will follow contextual precedence and are bounded by syntax constraints. And when going about telling a computer to execute a simple command, they can still do so in ways that delight and surprise us.
\nLet’s say a Rubyist wants to reverse a word. In programming parlance we refer to that word as a “string” which represents any sequence of characters including letters, numbers, or symbols. Such a rubyist might reach for an implementation using “primitive,” “imperative” syntax constructs like a while loop, indexed lookups, and string concatenation. These expressions are common across different programming languages. Additionally, they yield more control and flexibility back to the programmer. To wit:
counter_index = original_word.length\n # create empty string to contain new reversed word\n reversed_word = "" \n # start processing reversal\n while counter_index > 0\n # decrement the counter\n counter_index = counter_index - 1\n current_letter = original_word[counter_index]\n # add letter to the result\n reversed_word << current_letter\n end\nSo that’s one option. But looping over a string is such an everyday procedure that Ruby provides conveniences to do this with less code. In place of a while loop, index references, esoteric symbols like <<, the Ruby language includes higher order methods: a bit of logic slurped behind a human-readable name. Like each_char, which means “loop over each character”. And prepend, add something to the beginning of a string. Under the hood, Ruby implements these methods with its own primitives, likely similar to what we’ve written above. Let’s try reversal using the each_char method and see how it fits:
reversed_word = ""\noriginal_word.each_char do |letter|\n # optional debuggers\n # puts letter\n # puts reversed\n reversed_word.prepend(letter)\nend\nThis code is considered easier to read by many programmers because the method names makes the code’s intent obvious. Less code to mash in the mouth also means less information to pack into the brain’s working memory.
\nAbove we see Ruby’s do block syntax in action. It creates a syntactical wrapper that logically bounds each letter in a semantically associative workspace. Somewhat different than the unhinged free jazz of a while loop block with throw-away variables.
Generally, declarative methods for strings can play nice together. They can be “chained” together and called sequentially. This makes it easy for a Rubyist to write concisely and fit a complete reversal procedure into one line. No need for instantiating a variable. Just push the word through multiple operations down an assembly line. Programmers verbalize this into one lining:
\noriginal_word\n .chars\n .each_with_object("") { |index, reversed_word| reversed_word.prepend(index) }\n .join\nIt’s subtle, but there’s actually some extra processing in the above statement by transforming the original word string back and forth from an array to feed the each_with_object. It’s conceptually funky, but since the complicatedness is hidden behind the alluring veil of each_with_object, the statement is still pleasantly terse.
Of course, who even has all this time on their hands to f*** around. Let’s just make Ruby do all the work for us:
\noriginal_word.reverse\nWell, in reality, that quotidien commercial workplace, we often have more time. Because we need to build software to last. Which mean it’s uncommon to see these concise computational lines of code registered into a higher order architecture of collaborators. Our reversal code becomes a member of a reversing machine – a Ruby object – that can receive messages for requests with commands like reverse_my_word:
class WordReverseMachine\n def initialize(word)\n @word = word\n end\n\n def reverse_my_word\n @word.reverse\n end\nend\n\n# Somewhere else in my system...\nWordReverseMachine.new(word).reverse_my_word\nAlthough, maybe my WordReverserMachine shouldn’t be so opinionated in how it reverses things. Perhaps I want to borrow a reverse engine from other distant cyberscapes. Let’s allow our machine to swap engines as needed:
class WordReverseMachine\n def initialize(word, reverse_engine)\n @word = word\n @reverse_engine = reverse_engine\n end\n\n def reverse_my_word\n if reverse_engine? \n [@reverse_engine.new](http://reverse_engine.new)(@word)\n else \n word.reverse_my_word\n end\n end\n\n def reverse_engine?\n @reverser.nil?\n end\nend\n\n# Somewhere else in my sytem...\nWordReverseMachine.new(word).reverse_my_word\nReversing a word is a simplistic task, which is why languages like Ruby come with a reverse method on all String objects out of the box. And yet, programmers can dream wildly different expressions as demonstrated above.
Let’s take a look at the diversity of expression that unfolds from interpreting a task in a more culturally rich and relevant problem space. This is one is from an actual mess in the wild – unruly realism – where the task at hand is to look at all the products currently on sale in a restaurant website product inventory database that are not assigned to any particular menu.
\nOk: so imagine this shop management software lets managers add products, but wait till later to figure out what menus those products go in. After all, does a croissant go in Breakfast or Pastries? It may not be obvious at first. Splitting up the administration of products this way creates efficiency for product inventory management and menu design. Which allows for more general flexibility and adaptability of a restaurant’s ordering experience. It lets a shop not use menus at all, or have some products in menus and some just floating on their own as standalone products.
\nThese requirements imply that software developers working with this database will need to care about querying for products in a few different ways. Let’s play with a use case where a restaurant manager wants to display a website menu with products that are both in menus as well as a section for all other products. For example, there might be menus for Breakfast, Lunch, Dinner, and then a general list of other products under an…“Other” heading.
\nThe software that supports this shop management software implements this data model for relating products to menus: Marketplace Products have many Marketplace Tags, and these two data types are associated with each other through a bridge table of Marketplace Product Tags. This is a fairly typical way of modeling a tagging system in a Ruby on Rails project with a relational database. Here’s what the model definitions might look like in Rails code leveraging ActiveRecord as an ORM:
# Product Model\nclass Marketplace::Product\n\thas_many :tags, through: :product_tags, inverse_of: :products\nend\n\n# Tag Model\nclass Marketplace::Tag\n\thas_many :product_tags, inverse_of: :tag, dependent: :destroy\n has_many :products, through: :product_tags, inverse_of: :tags\n\tscope :menu_tag, -> { where(is_menu: true) }\n\tscope :not_menu, -> { where(is_menu: false) }\nend\nOk: so menus, or groups of products, are formed by products sharing a Marketplace Tag where a special boolean field called is_menu is set to true on that tag.
For our case, where this restaurant’s ordering page lists both products in menus and the rest beneath an “Other” heading, querying the right content for our others is the tricky part. This system allows shop managers to tag products freely. There is no restricted set of tags, or other constraints for product and tag associations. Therefore we’ll need to join across three different tables, marketplace_products, marketplace_products_tags, and marketplace_tags, and then collect any Marketplace Products where none of their associated marketplace_tags have an is_menu flag set to TRUE.
Lets start the beautiful differencing!
\nWith the help of my fellow coders at Zinc Coop with whom I workshopped this problem, I’ve cooked three ways to query our postgres database for products without a menu tag with both postgres-flavored SQL and ActiveRecord ORM. (More ways left to be discovered.)
\nEven if you’ve got a mature ORM like ActiveRecord at hand, it can be pragmatic to express your query in SQL so the selection logic you enshrine in code is blatantly evident. What if, for our initial cook, we code with oneness. Get the data with a single select statement. Not necessarily bravado, or premature consideration for performance characteristics just yet. Let’s see what we can do with that generative single origin select start point.
Mario Kart starting line count down anticipation…
\n select\n mp.*\n from\n marketplace_products mp\n full join marketplace_product_tags mpt on mpt.product_id = mp.id\n full join marketplace_tags mt on mt.id = mpt.tag_id\n where\n mp.marketplace_id = '#{id}'\n group by\n mp.id\n having not\n 't' = any(array_agg(mt.is_menu));\nThe cleverness on the last line creates a collection of boolean markers for each Marketplace Product – t or f – representing whether the corresponding Marketplace Tag is a menu tag. The resulting row would look like {f, f, t, f}. Moving out left from the aggregate function, a filter computation is applied against the collection for any existence of a TRUE/t flag. The lispy parentheticals are sleek!
Thought: while the above option foregoes a subquery, I find the combination of group by and having clauses with the aggregating semantics notionally similar to a subquery insofar as we are selecting over a secondary “view” into the data.
It’s dawning on us: getting all the products without menu tags is not complex, although it may have seemed tricky at the jump. We’re only narrowing the product result set based on a single condition, it’s just that the condition happens to live a distance away. Let’s try again without the single select cleverness and consider nested queries:
\nselect\n mp.*\nfrom\n marketplace_products mp\nwhere\n\t\t mp.marketplace_id = '#{id}' AND\n mp.id not in(\n select\n mp.id from marketplace_products mp\n inner join marketplace_product_tags mpt on mpt.product_id = mp.id\n inner join marketplace_tags mt on mt.id = mpt.tag_id\n where\n mt.is_menu = true);\nBecause we now know that this query is shallow, both wide across only a few tables, and deep with only a single subquery, let’s see if Active Record’s query interface can provide similar conveniences like we achieved above with Ruby in our toy string reversal fractals. As it turns out, we can one-line all that SQL!:
\nMarketplace::Product.where.not(id: joins(:tags).merge(Tag.where(is_menu: true)))\nThis is slick, but might not be easy to come by without our previous work or deep knowledge of ActiveRecord. Our subquery version is informative for getting a mental handle on this terseness. We can reverse engineer. Notice how the entire subquery is captured in the outer parens pair. Now: the need for merge and passing in the Tag model as the argument is a bit elusive because we might expect to be able to simply joins(:tags).where(is_menu: true). But this would error because Active Record would think we were applying the where clause to Product instead of Tag, despite chaining on the join. merge is a logical separator that let’s us filter across these two relations with more discreet semantics.
Refine. Refine.
\nWe can utilize the is_menu scope on our Tag class, hiding our where(is_menu: true) filter behind a shorthand that minimizes keystrokes:
Marketplace::Product.where.not(id: joins(:tags).merge(Tag.is_menu))\nRuby on Rails scopes are a brevity blessing. You can imagine where this might be going. Adding a scope for without_menu_tag on Product will make querying and displaying results on our restaurant odering page a triviality. Dropping into the view layer we can grab the data and splat it into components with human-readable phrasing:
<h1>Other</h1>\n<div class="grid lg:grid-cols-3 gap-3">\n <%- marketplace.products.without_menu_tag.each do |product| %>\n <%= render Marketplace::Menu::ProductComponent.new(product:, cart:) %>\n <%- end %>\n</div>\nThe without_menu_tag scope can play well with other chainable scopes for quick prototyping and iteration for restaurant managers.
<h1>Other</h1>\n<div class="grid lg:grid-cols-3 gap-3">\n <%- marketplace.products.unarchived.without_menu_tag.sort_alpha.each do |product| %>\n <%= render Marketplace::Menu::ProductComponent.new(product:, cart:) %>\n <%- end %>\n</div>\nHow shitty is that?
\n\n\n", "date_published": "2026-04-01T08:38:05-07:00", "url": "https://softlydeveloping.micro.blog/2026/04/01/end-products-habiting-difference.html" }, { "id": "http://softlydeveloping.micro.blog/2026/04/01/rutabagas-vol-notes-from-the.html", "title": "Rutabagas vol. 4: Notes from the other week", "content_html": "Mind meal tests your mind: do you go for the bait? If you check the Ten Gates, the ten kong-ans, does hungry mind, desire mind, not-enough-mind appear? If so, you must eat your mind meal. You must completely digest your understanding. Then finishing your mind meal is possible. Then you get enough-mind, no-hindrance mind, no I-myme mind. Enough-mind does not go for the bait, so everything is clear and you can perceive any situation in your life and kong-an clearly, and save all beings. – A DOG’S “WOOOF WOOF” IS BETTER THAN ZEN MASTER JOJU, Only Don’t Know by Zen Master Seung Sahn
\n
\n\n", "date_published": "2026-04-01T08:34:20-07:00", "url": "https://softlydeveloping.micro.blog/2026/04/01/rutabagas-vol-notes-from-the.html" }, { "id": "http://softlydeveloping.micro.blog/2026/03/31/senior-engineering-make-things-happen.html", "content_html": "Well, I don’t want to generalize but for me, certainly I feel like fiction and non-fiction feel like they’re the same thing a lot of the time because as you said, for me, my experience of the world incorporates a lot of fiction and if I were to try and tell somebody what it feels like to be me, the most authentic thing to do would be to also tell them about the many fantasies I have in my head and that I’m brewing up all the time, sometimes without my own control or without consciously trying to do it. But they’re always there like a parallel stream of thought that’s happening in my head.
\n
Senior engineering: make things happen in the margin.
\n", "date_published": "2026-03-31T20:46:12-07:00", "url": "https://softlydeveloping.micro.blog/2026/03/31/senior-engineering-make-things-happen.html" }, { "id": "http://softlydeveloping.micro.blog/2026/03/09/morning-forage.html", "title": "morning forage 202603091628", "content_html": "At the start of 2025 I embarked on a rewrite of HistoryPin.org for Shift Collective, an Exygy Client and important place on the web where communities self-determine their stories. After being impressed with Cursor’s ability to create a meaningful contribution summary gleaned from the git commit history for SF’s Our415.org code, I let Cursor loose again. Strung together, these terse paragraphs form a pretty reasonable narrativization of my work on the rewrite. Although some categories of features are bundled a little funky – like “Development Workflow & Maintenance.” PR descriptions collapse together to the point of omission, spurred by my instruction to “briefly summarize.” Then there’s hardly mention of the test harnessing I established with pytest, FactoryBoy, and playwright. That said, the breadth and depth of my impression on the project still feels substantial. In 9 months I drove the rewrite from greenfield to the wholesome organized entropy of near feature parity, and am proud of what I achieved with no (significant) previous experience in greenfield projects of this scope, the Django framework, or python programming. Infra, schema, frontend, backend, test harness, devx – these parts were me and I was these parts.
\nYou’ve been instrumental in building out a comprehensive collection customization system. You added support for nested collections with an is_nestable field and updated forms to create collections within existing ones, leveraging query parameters for navigation. You implemented collection banner functionality including video URLs and image uploads using Django’s form utilities, along with sponsor logos with ManyToMany relationships and dropzone file uploads. You also added background color customization and visibility toggling for various collection fields, with proper permissions management for paid features.
You implemented a complete account deletion system with proper cascade deletion starting from the user level, including form templating and view logic to handle both self-deletion and superuser deletion scenarios. You also worked on username logic for members, ensuring proper username creation through Google social login adapters and migrating routes to use member primary keys instead of usernames.
\nYou built out member search capabilities by refactoring code to support a MembersDiscovery view with query parameter handling similar to collection searching. You implemented collection theme searching with support for multiple theme selections using comma-separated query parameters, including proper database indexing with Gin indexes for array operations. You also added location searching support to the DiscoverCollectionView with Google Place ID integration and location autocomplete functionality.
You made significant improvements to form handling patterns by refactoring complex relationship management during form submission, moving more logic to model form handlers to avoid overlapping operations between views and forms. You implemented tag support for collections using Django Taggit, enabling thematic tag filters and creating reusable TagCombobox components. You also added proper permissions management for paid features, ensuring correct access controls for members and collection owners.
Your work included several database optimizations including adding indexes on featured columns for Collections and Members, implementing Gin indexes for array searching, and optimizing deletion queries using cascades. You also worked on image handling improvements, fixing conditions that allowed setting empty pin images and implementing proper image optimization.
You implemented responsive design patterns using CSS queries and inline JavaScript to manage UI state, particularly for collection customization forms. You created reusable components like the TagCombobox that can be used for both Pins and Collections. You also worked on template refactoring to separate page containers from list rendering logic, making the codebase more maintainable.
You contributed to development experience improvements by adding seeds to database reset processes, creating new ADRs (Architecture Decision Records) addressing testing and form logic, and implementing script loading optimizations with defer and DOMContentLoaded to prevent blocking the critical path.
You worked on paid feature integration by refactoring the Donation Block toggling to use generic relationships, removing confusing admin configurations in favor of seed scripts, and implementing CSS-based show/hide functionality for donation input fields based on toggle states.
\nYour contributions emphasized better separation of concerns and reusable component design. You refactored paid features to use generic relations, created more maintainable form handling patterns, and implemented proper permission checks by comparing evaluated object IDs. You also worked on template organization to make paginated lists more flexible and reusable.
\nOverall, your contributions demonstrate a strong focus on user experience, data management, search functionality, and maintainable architecture. You’ve been particularly effective at building complex features like collection customization and search/discovery systems while maintaining code quality and implementing proper security measures.
\n", "date_published": "2025-10-22T15:25:25-07:00", "url": "https://softlydeveloping.micro.blog/2025/10/22/a-detailed-summary-of-technical.html", "tags": ["habiting the net"] }, { "id": "http://softlydeveloping.micro.blog/2025/10/22/142146.html", "title": "A detailed summary of technical work I delivered for San Francisco's public benefits portal Our415.org", "content_html": "In the fall of 2024 I joined the Consulting division of Exygy, an agency that delivers web tech solutions for civic and non-profit organizations. My very first assignment was getting a project of the Deparment of Youth and Families – Our415.org – launch-ready. Having a direct impact on families in SF was a very rad proposition, being a resident myself. Bringing a project home that’s close to home.
\nIn short time I completed a gaggle of technical work on Our415.org’s legacy React codebase, which had been forked from a similar benefits portal called the SF Service Guide. While pondering how I might proudly tell the tale of my work for the city to would-be interested parties like my mom or recruiters, I realized I might enlist the help of an LLM. Might Claude be able to make sense of all those commits? I don’t remember the exact instructions I put in the prompt, something like “go to
What surprised me most about these commits-cum-words, is the volume of accumulated work that is reflected back. It’s a lesson in the sheer mass of meaningful impressions a senior software engineer can have on a project’s formation in short time. And, perhaps, equally revelatory of how much we downplay our steady stream of achievements during a project’s speed-run to launch. To me this feels like a valuable narrativization of the private lives and material impact of senior engineers that is often relegated to archive, work diaries, 1:1 notes, as stakeholders and end-users merely avail themselves to the gestalt of these parts in production. To shouting the minutiae from the rooftops!
\nYou were a key contributor to modernizing the development process. You implemented pre-commit hooks using Husky and lint-staged to catch lint errors before CI, significantly reducing build failures. You established Jest testing infrastructure with React Testing Library, migrating existing tests and setting up a proper testing foundation. You also configured Dependabot for automated dependency management and updated the target branch to development for better workflow integration.
Your work focused heavily on bundle size reduction and dependency optimization. You reduced the lodash dependency burden by approximately 50% by switching to modular lodash functions instead of loading the entire bundle. You used tools like npx knip to identify and remove unused dependencies and components, including ShelterTech auth code, unused Homepage components, and WeGlot translation service code that wasn’t being used.
You addressed several critical bugs in the search and mapping functionality. You fixed incorrect marker location labels by properly moving marker label computation logic into the new transform. You resolved incorrect map markers on pages > 1 by establishing a new TransformedSearchHit view type/model that provides a canonical representation of search data with proper typing. You also removed algorithmic sorting of search results by urgency that was specific to SF Service Guide and not needed for the MVP.
You implemented significant navigation improvements including a new header navigation system and secondary navigation bar for listing pages. You created a SecondaryNavigationLayout component with BackNavigation functionality that uses smart routing. You also decoupled SiteSearch from Navigation and established conventions for wrapping route-level page components with secondary nav bars, including distinct mobile and desktop layouts.
You improved data handling by adding proper null case handling for service.long_description and implementing optional lookups for missing image data to prevent page failures. You updated the homepage query to fetch calendar_event data and fixed date/time rendering issues. You also refactored Event/Opp card components to accommodate new calendar_event data from Strapi.
Your contributions emphasized better component architecture and separation of concerns. You extracted the SearchResult component from SearchResults to reduce complexity and colliding terminology. You removed whitelabeling and tenant code, renaming whiteLabel to websiteConfig for clearer naming conventions. You also cleaned up old test cruft and established better naming conventions for search and map-related variables.
You worked on translation functionality by fixing Google Translate language switching issues and removing unused WeGlot translation service code. You also removed algorithmic sorting that was specific to certain tenants and not needed for the current implementation.
\nYou contributed to developer experience improvements by adding VSCode gitignore directives and creating pull request templates. You also worked on removing technical debt and unused code that was causing confusion and maintenance overhead.
\nYou updated the production build workflow with Strapi keys and worked on various fixes that required backend coordination, such as updating frontend queries to match deployed backend changes.
\nOverall, your contributions demonstrate a strong focus on code quality, performance optimization, user experience improvements, and maintainable architecture. You’ve been particularly effective at identifying and addressing technical debt while implementing modern development practices and fixing complex bugs in the search and mapping functionality.
\n", "date_published": "2025-10-22T14:21:46-07:00", "url": "https://softlydeveloping.micro.blog/2025/10/22/142146.html", "tags": ["habiting the net"] }, { "id": "http://softlydeveloping.micro.blog/2024/04/16/how-to-read-a-hacker.html", "title": "How to read A Hacker Manifesto", "content_html": "McKenzie Warks' A Hacker Manifesto is so bergizi (this wonderful lexical utterance meaning nutrient stuffed in standard Indonesian). So I skipped to the end notes, sue me; reading ass backwards might be the trick here. Or, if your prefer to expect the unexpected, spin a bottle to choose an entry point. Once you make progress, make sure to reprint and scatter the individuated sections that you’ve read and then affix them to posts along Triton’s surface.
\n“A free yet not merely random productivity”: this sentence gets me thinking about open source collaborations.
\n![\"End](\"https://internetross.space/uploads/2023/bateson-end-note-hacker-manifesto.jpg\")
\n",
"date_published": "2024-04-16T14:45:51-07:00",
"url": "https://softlydeveloping.micro.blog/2024/04/16/how-to-read-a-hacker.html",
"tags": ["poetry"]
},
{
"id": "http://softlydeveloping.micro.blog/2023/12/22/my-sparse-margin-note-couplet.html",
"title": "My sparse margin note couplet from Jon Bentley's Programming Pearls, also bit of a book review, and a whole ass",
"content_html": "![\"comic](\"https://internetross.space/uploads/2023/batman-year-one-im-fine.png\" "\\"batman-year-one-im-fine.png\\"")
\n![\"keyboard](\"https://internetross.space/uploads/2023/programming-pearls.png\" "\\"programming-pearls.png\\"")
\nIn 2015 I bought this book. \n7, or 8 years ago. \nYear one into my software career. \nThis book is canon. \nI've had little use for its studies of algorithms. # thus far, see below \nI don't think Bentley would be offended. \nFirst sentence: "Computer programming has many faces." \nI’m sure I glanced at its pages before entering the corporate interview gauntlet to get in the vigilante mood. To shake out the shoulders, find some relaxment, whilst staring down a twenty two minute treadmill run or pile of laundry Sunday evening. You must to armor up for the algos in the kingdom of men.
\nWhile Bentley’s pearls are the type of polished wisdom earned through real life experience we get on the job, this book never became the vade mecum for my quotidian affairs. Is it for others? What comes after Part I was too metallic for an early-career front-end Rails dev.
\nYet, the book can be pragmatic for all ages – see 3.2 Form-Letter Programming!. The fantastic headings are pedagogically caring. It is sensually satiated with geeked thoroughness. The cases are actually well-situated within the real-world: Bentley spoils you with further readings and sidebars, journalistic first-hand-accounts that remind you of how the metal has been worked over by a person’s hands.
\nIt reminds you that software is not lonely, which is important.
\nBut beware: there’s a modest amount of myth-making for his contemporaries and mentors. And yet, they are the most honest plagiarisms. Yes/and: he’s humbler than many. (Perhaps it is worth another pass now that I have more years in the rear view).
\nI am a visual learner and thinker: logical word-problems were always a pain. In recent years I tend to reach for Bhargava’s Grokking Algorithms for a refresher on binary search or walking trees. It has cute pictures. It’s stacked next to other faves like Land of Lisp and Why’s (Poignant) Guide to Ruby.
\nHmmm (thinking emoji, I will not look you in the eye as I cock my head buried in thoughts). After all, the solstice konmari of my bookshelf – which I thought would elicit a reflection on some forgotten paper taking up space – has become the discovery of lost treasure. And yet, I’m still tickled by the scant amount of notes taken. I can’t read without a pen. Perhaps we’re time-traveling, then.
\nIt's year one. \nYoung Rails dev. \nHe makes only two liner notes in a book considered staple grocery. \nI don't remember if I even read the whole thing. \nI bet I got through Part 1's wider lens, then started to gloss over.\nOne note is an exaggerated check mark next to this principle listed on p29 (Second Edition, published 2000):
\n> Rework repeated code into arrays. A long stretch of similar code is often best expressed by the simplest of data structures, the array.
\nWith “the array” also underlined from the outer left edge of the “t” to the outer right edge of the last “a.”
\nThis one has stuck. Arrays, especially maps, can be more durable when staring down change. Before long any thoughtful software developer will realize that the components of a software system will become ordered and/or multiple.
\nThere is no lonely software.
\nData, whether as scalar, “bags” of properties, even subroutines and processes, even the manual lever pulling human tasks must be sequenced, serial, bound, reversed, indexed, sorted. The maintenance cost of housing data in ordered collections is generally low.
\n[<anything>, <anything>] \nWhole ass languages, like Clojure, were designed to favor ordered, associative arrays. As I learned after finding Hickey’s seminal talk Simple Made Easy. Richly simple and luxurious as Hockney’s bathers.
\n![\"hockney's](\"https://internetross.space/uploads/2023/hockney-sunbather.jpg\" "\\"hockney-sunbather.jpg\\"")
\nA second mark: a vertical line next to the opener for section 12.2 One Solution. This was (yet another moment in my lifetime) I learned that we never have to go it alone when staring down the void of what we’re building next:
\n> As soon as we settled on the problem to be solved, I ran to my nearest copy of Knuth’s Seminumerical Algorithms (having copies of Knuth’s three volumes both at home and at work has been well worth the investment).
\nThis has also stuck, reified after seasons.
\n", "date_published": "2023-12-22T19:53:23-07:00", "url": "https://softlydeveloping.micro.blog/2023/12/22/my-sparse-margin-note-couplet.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/12/15/rutabagas-vol-the-softest-ware.html", "title": "Rutabagas Vol. 3: The Softest Ware: Is", "content_html": "What are probably appropriate attacks on assigning calamity to the hand-wavy concept of “human error”. Lorin strengthens his theory that human error probably doesn’t exist by considering complex, fault-tolerant systems like Amazon S3 incapable of receiving “human error” as apology or eulogy when there’s a hard drive failure.
\nWHAT. Secret guerrilla human rights interventions by the artist collective GALA Committee on Melrose fucking Place.
\n> For three years, as the denizens of the Melrose Place apartment complex loved, lost, and betrayed one another, the GALA Committee smuggled subversive leftist art onto the set, experimenting with the relationship between art, artist, and spectator. The collective hid its work in plain sight and operated in secrecy. Outside of a select few insiders, no one—including Aaron Spelling, Melrose’s legendary executive producer—knew what it was doing.
\n> It’s a little bit shitposty, but it’s 100% true. People think cache invalidation is hard because it has no right answer, so it’s a question of iterating until you get a right-enough answer.
\n> People think naming things is hard because it’s about communicating with each other.
\n> People don’t even think about managing dependencies. It’s invisible. It’s about cooperating across time and organizations to do maintenance chores. It’s so hard and so unglamorous that people can’t even see it.
\nWhat’s important to observe here is (the appropriate, warranted, overlooked) framing of these software problems as social problems, not logical puzzles or struggles with language and framework semantics. Even cache invalidation, despite being a requirement in nearly any useful application that nearly every developer must address, escapes a general solution – meaning developers must continuously arrive at socially acceptable, technically sufficient solutions – but not total – as the seasons change and the desires of forces and actors in the system change. There is always more than one person at large in negotiating the solution, if even only a developer and a single someone using the software.
\n\nHandling background jobs is a common requirement in software development, especially in scenarios where certain tasks need to be executed asynchronously or in the background to avoid blocking the main application thread. There are various ways to handle background jobs, and the choice often depends on the specific requirements and the technology stack being used. Here are some common approaches:\n\nTask Queues:\n\nMessage Queues: Use message queuing systems like RabbitMQ, Apache Kafka, or Redis to enqueue and dequeue tasks. Popular libraries for this approach include Celery (Python), Sidekiq (Ruby), and Resque (Ruby).\nJob Queues: Platforms like AWS Simple Queue Service (SQS) or Google Cloud Tasks can be utilized to manage queues of tasks.\nAsynchronous Programming:\n\nAsync/Await: In languages that support asynchronous programming (e.g., Python with asyncio, JavaScript with Node.js), you can use async/await to perform tasks concurrently without blocking the main thread.\nMultithreading/Multiprocessing: Use threads or processes to run background tasks concurrently with the main application. Be cautious with shared resources and synchronization.\nBackground Job Processing Frameworks:\n\nDelayed Job Processing: Libraries like Sidekiq, Delayed Job (Ruby), or Hangfire (.NET) allow you to schedule and execute background jobs at a specified time or after a certain delay.\nJob Scheduler: Tools like cron (Unix/Linux) or Windows Task Scheduler (Windows) can be used to schedule recurring background jobs.\nServerless Computing:\n\nFunctions as a Service (FaaS): Platforms like AWS Lambda, Azure Functions, or Google Cloud Functions enable you to run individual functions in the cloud without managing the underlying infrastructure.\nDatabase-backed Queues:\n\nDatabase Queues: Store tasks in a database table and have worker processes periodically check for and process these tasks. This approach can use a library like Active Job (Ruby on Rails) or Hangfire (C#).\nContainer Orchestration:\n\nKubernetes: Container orchestration platforms like Kubernetes can be used to deploy and manage background job processing containers.\nJob Management Services:\n\nJob Management Platforms: Use specialized services like Jenkins, CircleCI, or GitLab CI/CD for scheduling and executing background jobs.\nWebhooks and Event-Driven Architectures:\n\nEvent-Driven: Design your system as an event-driven architecture, where background tasks are triggered by events. Webhooks can be used to notify the system of events.\nChoose the approach that aligns with your application's architecture, scalability requirements, and the specific nature of the background tasks you need to handle. Keep in mind factors such as reliability, scalability, and ease of maintenance when making your decision.\nQuoting Nauru’s seminal vintage paper (1985, the year my brother was born):
\n> The fundamental task of software development is not writing out the syntax that will execute a program. The task is to build a mental model of that complex system, make sense of it, and manage it over time.
\n> So anyway this post is both a big “thank you” to the many nerds who are chill and easygoing and joyful, and an exhortation to others to free yourself of contemptuous, competitive attitudes, and re-embrace the intellectual curiosity that presumably once brought you into programming in the first place.
\n", "date_published": "2023-12-15T11:12:28-07:00", "url": "https://softlydeveloping.micro.blog/2023/12/15/rutabagas-vol-the-softest-ware.html", "tags": ["rutabagas"] }, { "id": "http://softlydeveloping.micro.blog/2023/11/28/rutabagas-vol-japan-transform-museums.html", "title": "Rutabagas: Vol. 2: Japan transform , museums saving the web, c apitalism makes software bad again, and more", "content_html": "![\"postcard](\"https://internetross.space/uploads/2023/postcard-finnaire-sud-aviation-caravelle-1970s-sfo-museum.jpg\" "\\"postcard-finnaire-Sud-Aviation-Caravelle-1970s-sfo-museum.jpg\\"")
\nVIBES.
\nI read this post a few days ago and have since wandered through the hyperlinks to his other stuff. It’s clear that for some time Cope has been baking thoughts about the cultural heritage sector and its responsibility - “relationship” - to engage with emerging “virtualization” technologies and the techno-capitalist system.
\n(As I’m learning: he’s been committed to the web writ large, you can see it through numerous cyber- and hyper- textual projects playing freely in the “network of patient documents”; his own delightful euphemism. In these projects he goes deep for the web’s inherent nature of democratic, atemporal revisiting and recall." “That access to recall is what makes the Network special to me.” At first blush, these are not impossible conservationisms. As he says: “The point is not that our relationship with technology should end with the web.”
\nReminds me of Avdi Grimm’s discussion of conservation:
\n> “Healthy growth starts where it is, and both builds on and repurposes what came before. No clean slates, but also no bans on knocking down walls.”
\nCope has chosen not to wave the white flag, and fends off the grievings, misgivings, and saudade of laments starting a decade ago.
\n> We managed to build a lot of cool shit on the back of 56Kb modems. We built a lot of cool shit – including entire communities – on top of a technical infrastructure that is a pale shadow of what we have available to us today. We know how to do this.
\n)
\nCope is saying: The (open) web is good, actually. Which is what Cory Doctorow picked up and so it found it’s way into my inbox.
\nIn Cope’s newer account at hand from the 2023 Museum Computer Network conference, we get these thoughts reapplied to emerging virtualization technologies, VR, AR, particularly the “so called ‘metaverse’” (the name scare-quoted out of exasperation, maybe?). He wants to remind us that we’re not done with the web yet.
\nAt the outset, Cope moves quickly to invoke a reminder about the museum’s networked power - it’s webiness; at the same time its implication in the network of patient documents:
\n> …the practice of revisiting is the bedrock of the humanities. Revisiting is what distinguishes entertainment from culture.
\nThe decade+-long struggle continues. We must understand how our bargains with techno-capital hegemony (apps, ad-driven social networks) deepens the threat against ideas (I’d add emotions, evolutions, revolutions) flourishing outside the corporate fence. What Cope describes as “time to warm up to ideas.”
\nI’m game. And Oh! The cultural heritage sector seems a perfect backdrop to wrestle with the threats of new tech. The material threats are lived: even pragmatically, the museum can not, may not, should not be able to afford the costs of bug-eye headsets and visors. The larger scheme is almost dialectic, smooth: the plunder and seizure of open-access-egress recall power while the cats keep entertaining my eyeballs. While Facebook’s controlled metering of power to content creators (colonial policemen) transforms cultural value from something that moves freely across past and future, geography; that’s cheap, abundant; that’s allowed to take root…organically (for lack of a better term): transforms into something judged too quickly, cast away, spent, ephemeral. (Remember, DIGITAL != EPHEMERAL). Prepping us for some greedy end, like recording everything we see because Cambridge Analytica and genocide, and… He says:
\n> Namely that if you publish something online – whether it’s a selfie, a “hot take”, an essay or a multi-year project; anything really – and it is not immediately successful or viral then it was a waste of time and effort. It was not worth doing.
\n> Which is insane. It is insane because that’s not how ideas take root.
\n> It takes people time to warm up to ideas, especially new or challenging ideas, if only because we are busy just juggling the ideas and beliefs we already hold with the complexities of our lives in relation to one another.
\n> It is also hard not to understand this idea as a deliberate of attempt to gaslight the web and everything that makes the web important.
\nLater..
\n> We would do well to understand the web not just as a notch in the linear progression of technological advancement but, in historical terms, as an unexpected gift with the ability to change the order of things; a gift that merits being protected, preserved and promoted both internally and externally.
\nOn time-traveling temporality, from back in www.aaronland.info/weblog/20…
\n> The web gave us the ability to return to a thing outside the shared (or master) narrative at a time of one’s own choosing. Of shifting time in the service of one’s own interest or in the service of simply coming to an understanding of one’s own interests.
\nJapan’s haiku poets lost for words as climate crisis disrupts seasons
\nShip/Show/Ask: More often than not web dev shops I’ve worked in are weighted toward the “Ask” strategy because of blanket policies. So even in cases where a team had reached a degree of trust that would allow for releasing with “Ship” or “Show” there were mechanical bulwarks in place. For example, physical restrictions to self-merge a Github Pull Request.
\nIt’s amazing what a small amount of imagination + green can do to the built world. In Japan, the Federation of Landscape Contractors holds a contest each year for best-looking garden on the back of a pickup truck. Some winners.
\nHaving worked tangentially to direct patient care in the health tech biz building industrial pharmacy software, these insights about how bad healthcare software can be resonate. Paper: You want my password or a dead patient?. Good summary with pull quotes from Fred Herbert from a short draft paper.
\nOriginally posted as a micro website at https://ross-rutabagas.neocities.org/. Rutabagas are now sprouting here when the time is right. Volume 1 includes “found dates” – but later volumes will be less temporally registered (I think).
(Why “Rutabagas”? This was Zee’s fault when he extemporaneously blurted “Ross' Rutabagas” as a fake shop name to stand in for an example during a Zinc Coop ensemble sesh.)
\n10/06/23 - [r/Jazz]\n Nat King Cole Appreciation Post & [r/Jazz]\n Nat King Cole Piano Recordings
\nWhen you need to deep dive into the influential piano playing of\n Nat King Cole that influenced greats like Oscar Peterson.
\n10/02/23 - Make\n the Golf Course a Public Sex Forest!: An excerpt by Anna Aguiar\n Kosicki
\n<p>Discovered via Sophie Lewis’ <a href="https://www.patreon.com/posts/repro-utopian-11-89509663">Patreon</a>.\nBook ordered!</p>\n09/25/23 - Block\n the Bots that Feed “AI” Models by Scraping Your Website by Neil\n Clarke
09/25/23 - The Unreal\n Writer by Joanne McNeil
\n\t\tDiscovered via my mastodon feed, shared by Betsy Haibel:
\n\n\n“This is happening with Octavia Butler in real time. Her daring and the moral\n complexity of her characters is swept away in recent assessments to\n create a coherent legacy—that of an earth mother tote bag\n caricature-icon. This is reading authors as flap copy, accessing the\n top layer of the writing, and refusing to convene with the messy\n human elements in the work. What are their books—any books—even for,\n other than for us to approach as humans, wandering around with their\n words and experience the extraordinary workings of another human’s\n mind?
\nThe snobbery against science fiction in the past and today’s\n cartoon icons of some of its weirdest authors comes from the same\n root: an establishment that doesn’t know how to read or appreciate\n it. The establishment needs the work digestible as buzzy fragments.\n The feral elements in what are now science fiction classics—the\n originality and experimentation—isn’t legible to them; which means\n even the most famous authors, when you encounter the work on your\n own, are likely to surprise you. Their mysteries as authors remain\n mysteries and to a more generous reader—that mystery is exactly what\n hooks you.”
\n
09/24/23 - Apple\n fucked us on right to repair (again): “Parts-pairing” is a scam\n by Cory Doctorow
09/24/23 - 🎧 Bizarre\n and Dangerous Utopian Ideology Has Quietly Taken Hold of Tech\n World by Kelly Hayes
> But night software is not like that. It’s not written for the day job. It’s not written to see the light of day at all. It’s not written to be looked at and scrutinized by anybody. It’s intimate and personal, it’s messy and buggy. To take a look is to transgress.
\nBoundary cross. Sex.
\nFrom a small heap software that helps make software. By way of Devine Lu Linvega
\n", "date_published": "2023-11-20T22:18:04-07:00", "url": "https://softlydeveloping.micro.blog/2023/11/20/but-night-software-is-not.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/11/20/dei-grieving-and-ai-skepticism.html", "title": "DEI Grieving and AI Skepticism", "content_html": "IYKYK DEI in tech is all but dead. If you’re an outsider, it’s important to understand that employee-led efforts to make workplaces less racist – which began in earnest at the onset of the Obama years – have been steadily blotted out since Trump. The Tech aristocracy has decided to abandon DEI budgets along with other workplace perks. As @betsythemuffin notes (in the thread I’ll be referencing below):
\n> DEI is seen by a sizable chunk of the funder class as an allowable luxury to keep the peons happy.
\nIt has been tragically hard to swallow this defeat. @betsythemuffin again:
\n>Regret that we didn’t do more to build material power when we had the chance.
\nAnd yet, as the movement has regrouped and recentered to reposition the struggle, some have begun to take note of a problematic adaptation in the techy left’s rhetoric. @danilo started a thread on Mastodon that points out a new-born form of absolutist skepticism for emerging technologies – notably AI (of course). Regardless of why the left slips into what @glyph calls a problem of “semasiology” around the term “AI”, point is, the hurt seems to be cutting so deep that the movement has retreated into an unproductive preservationism.
\n> The abject and understandably heartbreaking defeat of DEI-type progress in tech has moved most leftist critique of the space into a technological conservatism built on denialist, magical thinking.
\n> You can’t successfully advocate for a dead end when the other side is investing in roads that lead to helpful places.
\n> You can’t win against technologies people find useful by pretending they aren’t useful.
\nCheck out the rest of the conversation. There are smart people in here thinking through this “AI” moment. The underlying question seems to be how we can continue the fight without completely disavowing what might be practical revolutions borne out by this albeit early phase of “AI” that is “finally bearing serious fruit.”
\nIf you’re wondering on what side of the line I fall, my major beef with the LLMs is their wanton extractive consumption of human labor without citation or, god forbid, recompense. Of course, a time honored tradition of slave traders and capitalists. Here is Marc Andreesen with a recent plea written to the US copyright office, hopeful we can just all ignore this blatant theft for the common good of the funder class. This is class warfare:
\n> Imposing the cost of actual or potential copyright liability on the creators of AI models will either kill or significantly hamper their development.
\nI hold that citation is feminist since it combats the authoritative mansplain that obscures collaboration, hardens selfhood, and hoards ideas. Ergo I consider the de-linkified, referent vacuum of effluvium produced by ChatGPT et al as patriarchal in its presentation of “knowledge” and preoccupation with mastery. I’m scare quoting because philosophically I’m confused about what this content even is, so unhinged. Although I recognize that the interplay of this text with the reader and their investigative context does produce meaning.
\nUPDATE (minutes after the writing the above): heh, Danilo actually expounds generously about the left’s false critique of AI in a long-form piece on his blog.
\n", "date_published": "2023-11-20T21:32:12-07:00", "url": "https://softlydeveloping.micro.blog/2023/11/20/dei-grieving-and-ai-skepticism.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/11/10/lament-for-tafteria-sailing-the.html", "title": "Lament for Tafteria: sailing the Apollo's docs", "content_html": "![\"The](\"https://internetross.space/uploads/2023/the-hospital-ship-martin-bax.png\" "\\"the-hospital-ship-martin-bax.png\\"")
\nDocumentation, naming things. Hard. Let’s see this hardness compound at the intersection of these two phenomena in the real world.
\nI’m casually scanning the Apollo docs, reading up on subscriptions because my wife is writing graphql client code at work. (I had vague memories of how we worked with distributed event streaming at my last job. NestJS + Kafka. We had consolidated apis into a graphql layer, but worked with Kafka event streams through Nest with the kafka-js lib as a bridge. Point is, I wanted a light refreshment of how this stuff works.).
It’s a frustrating moment to jump between these two pieces of the documentation. (This is supposed to be a mature framework (sobbing, why can’t we have nice things)). From 2. Initialize a GraphQLWsLink to Enabling subscriptions.
\nThe former section, which walks us through client setup, provides a callout with a detour into the server docs for grabbing the connection url we need for configuring and instantiating our web socket linkage.
\n> Replace the value of the url option with your GraphQL server’s subscription-specific WebSocket endpoint. If you’re using Apollo Server, see Setting a subscription endpoint.
\nIf we are using Apollo’s server, then we must pass a url property when creating and instantiating the GraphQLWsLink object .
const wsLink = new GraphQLWsLink(createClient({\n url: 'ws://localhost:4000/subscriptions',\n}));\nHOWEVER, once we hyperlink to the server docs one simply cannot find – throughout the entire web document – a mention of “endpoint.” We’re dropped into a section called “Enabliing subscriptions” – instruction for setting up the server side bits.
\nLet down. Expectations missed. Problematic asymmetry, lack of consistency!
\nRepletely kerfuffled, my synapses delivering a reminiscence of Tom Benner’s big bird bound Naming Things, and his chapter on Consistency. (This so happens to be one of my favorite dogmas of Better Naming™️.) Well, the Apollo docs demonstrate a similar symptom of bad naming, just like the kinds of bad examples we oft find in code. Join me in considering disparate, hyperlinked documents as analogs to components of a software program that exchange messages. Readers of these texts suffer the bad naming with familiar symptoms: frustration. Capitalists lose the most with anemic productivity.
\nIf the hyperlink is a documentation document-as-component api/interface, us readers should be allowed to charismatically move back and forth without being flung out from our flow state like starships intercepted in warp. Perhaps the doc could send me to a subsection of “Enabling Subscriptions” titled/anchored with “Server endpoint” (or the like). My instinct is that there’s a deeper scoop here.
\nOf course, there’s an imperfect system to blame. When Trevor Scheer removed all mention of “endpoint” in the docs update preparing users for Apollo Server version 3 back in 2021 – Apollo Server would no longer include inherent support for websocket protocols – how closely did he collaborate with Stephen Barlow who initially committed the instructions referencing endpoints a year or so before. Do the people matter? (They do.) And from under whatever constraints they perform these literary efforts. We can wonder, imagine, daydream about the socio-technical system that produces docs for clients and servers, and how the basic capabilities of the web link them together. The bounded contexts. The challenges of producing universal languages, ubiquitous terms across what likely are two disparate teams.
\nThere are some leaky abstractions, but it’s not a total system failure.
\nI’m reading Bax.
\nDispatches, bulletins, papers, pinned up, spewed about The Hospital Ship.
\nPage 15: A chronic shortage of pins to fix up the reports, so that in consequence they blrew away and anyone in the stern of the ship could reach out a hand and collect bulletins from the air as they drifted by in an endless paper-chase over the stern of the boat and on into the sea.\n
\nPage 98: Did the programmers hope to attract some reply? The Hopeful did not know what replay to make so they transmitted their call signal only, but there was no response.
Euan wants to blame Tafteria, too bad.
\n", "date_published": "2023-11-10T13:26:04-07:00", "url": "https://softlydeveloping.micro.blog/2023/11/10/lament-for-tafteria-sailing-the.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/10/31/clojure-was-small-typescript-is.html", "title": "Clojure was small, TypeScript is big (thinking w/ Dan Vanderkam)", "content_html": "![\"Midnight](\"https://internetross.space/uploads/2023/midnight-endless-summer.jpg\" "\\"midnight-endless-summer.jpg\\"")
\nThe dangers of premature optimization are well understood among software engineers who’ve been frustrated by the secondary effects of code that end up compounding maintenance cost. (Does this principle play out in other milieu?).
\nNonetheless, there are times when optimizations are demonstrably beneficial but are difficult to implement because of system-wide or social dynamics that can’t or won’t accept the optimizations. Here I’m thinking with Dan Vanderkam’s post from back in September: The Saga of the Closure Compiler, and Why TypeScript Won.
\nSkipping gingerly back through through recent web and computing history, Dan discusses the now obvious demise of Google’s Closure compiler, which at the time enjoyed merits of technical achievements in optimization. During it’s development in the early aughts, the hardware of the time demanded Closure’s designers focus on minification. Dan argues that contemporary typed projects, like Typescript, won’t succeed beyond the range of Closure’s niche usage on advancements in performance. Typescript must be built with consideration ever-increasingly diversifying ecosystem of tool chains and environments within which it can and will be run. Such as right alongside plain ole dynamically-typed JS in mixed types/non-typed codebases. Despite the heroic campaigns of developers to slap types on everything – see the DefinitelyTyped repo – the JavaScript multi-verse offers no real guarantees that imports will be typed or not. TypeScripts declared horizon of
> Be a cross-platform development tool
\nmust be joined by
\n> Emit clean, idiomatic, recognizable JavaScript code
\nand further qualified by the non-goal of
\n> Aggressively optimize the runtime performance of programs. Instead, emit idiomatic JavaScript code that plays well with the performance characteristics of runtime platforms.
\nI wonder how many TypeScript developers have looked at the TypeScript Design Goals? Not to call out/in, just curious.
\nI wonder, the Midnight’s 2016 Endless Summer. Saxophone crying out from the other room.
\n", "date_published": "2023-10-31T11:42:32-07:00", "url": "https://softlydeveloping.micro.blog/2023/10/31/clojure-was-small-typescript-is.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/10/30/language-ergonomic-studies-possession-ruby.html", "title": "Language ergonomic studies: Possession: Ruby, JavaScript, D/s, Mycology", "content_html": "![](\"https://internetross.space/uploads/2023/flair-anniston.png\")
\nThere exist happy little clouds of coincidence when studying new languages. And not just across the computer ones, mind you!
\nRuby and Indonesian share a frugal brevity and disinterest in flairs of punctuation when managing possession.
\nItu bukuku.\nvs
\nThat's my book.\nAnd…
\nme = Person.find(my_user_id)\nmy_books = me.books\nvs
\nconst me = await prisma.user.findUnique({ \n\twhere: { \n\t\tid: 99, \n\t}, \n\tinclude: { \n\t\tbooks: true \n\t} \n});\nmyBooks = me.books;\nWell, Rails AR query syntax vs Prisma (NodeJS). (Also, did I do a useful interpretation of linguistic possession in a soft coding expression??)
\nThis isn’t YAOFJS (Yet Another Opprobrium for JS). I don’t have a quarrel with English, either. Although I find it often fairly dull when it’s not rescued by the reticulations of regional and immigrant (forced or free) anastomosis of the tongue and mouth (and whatever other maneuvers contribut to nudging the Queen’s own verbage (I’ve forgotten if there is anything before a body without organs, how is it done???)) that take root in everyday speech.
\nOnly a mere 30 pages (of 250) into Make the Golf Course a Public Sex Forest and you run headlong into Raechel Anne Jolie’s musings on D/s, mushrooms, and mouths. There’s probably something here to dwell on with respect to power, colonialism, oral sex, entangelment, Dulcinea Pitagora’s “subspace” in BDSM play (ohhh, wonderful that this term wasn’t entirely pre-figured by Roddenberry’s universe expanse), etc…
\nCue Butler’s Xenogenesis, ringing in my ears.
\n", "date_published": "2023-10-30T12:40:21-07:00", "url": "https://softlydeveloping.micro.blog/2023/10/30/language-ergonomic-studies-possession-ruby.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/10/25/language-ergonomic-studies-brevity-fetish.html", "title": "Language ergonomic studies: Brevity fetish with Ruby", "content_html": "Matz giving us many ways to do things.
\n> I want to make Ruby users free. I want to give them the freedom to choose. People are different.
\nFrom:
\n🔗 The Philosophy of Ruby: A Conversation with Yukihiro Matsumoto, Part I
\ndef two_lowest(numbers)\n numbers.min(2).sum\nend\nEnumerable methods that can receive an operator as symbol. Glacial autumn breeze whipped up from the 101. I don’t have a brevity fetish, like I know many of you do. Or the tendency to place the one-liner upon the highest of pedestal. It’s the obvious natural-language-style readability of the Ruby here that is simply remarkable.
\nAchieving this is possible in JavaScript with more fanfare. But, alas, the maintenance cost of dressing up our array in Ruby’s fast casual couture.
\nclass NumberArray {\n constructor(numbers) {\n this.value = numbers;\n }\n\n min(n) {\n\tfunction compareNumbers(a, b) {\n\t return a - b\n }\n this.value = this.value.sort(compareNumbers).slice(0, n);\n return this;\n }\n\n sum() {\n\tfunction add(a, b) {\n return a + b\n\t}\n return this.value.reduce(add, 0);\n }\n}\n\nfunction twoLowest(numbers) {\n return new NumberArray(numbers).min(2).sum();\n}\n\nHave you noticed that comprehension arrives more quickly when reading comparison pieces that juxtapose the syntaxes, rules, and shibboleths of two programming languages. Steve Hicks' article What JavaScript Tests Could Learn From RSpec is one such example.
\nMy preference when writing tests is to keep re-assigning and re-using variables to a minimum. Localize them as close to the assertions as possible. Beware of cross-contamination. Pollination. Sexual interops.
\nRecreating a lazy-evaluated let-style block in JS, Hicks performs some clever scoping gymnastics which makes me nervous. The declarations of calculator, first, and second feel visually and temporally far-flung from usage.
describe("Calculator", () => {\n let calculator\n beforeEach(() => { calculator = new Calculator() })\n\n describe(".multiply", () => {\n let first, second\n function getResult() {\n return calculator.multiply(first, second)\n }\n\n describe("when the first value is negative", () => {\n beforeEach(() => { first = -1 })\n\n describe("when the second value is negative", () => {\n beforeEach(() => { second = -3 })\n\n it("returns a positive number", () => {\n expect(getResult()).toEqual(3)\n })\n })\n\n describe("when the second value is positive", () => {\n beforeEach(() => { second = 3 })\n\n it("returns a negative number", () => {\n expect(getResult()).toEqual(-3)\n })\n })\n })\n })\n})\nThis doesn’t really bother me though:
\nlet sharedVar;\n\nbefore(() => {\n sharedVar = ...\n})\n\ndescribe(() => {\n it(() => {\n sharedVar = ...\n })\n})\nIs rspec let better than JS let?
Even rspec maintainers caution us, Hicks notes. Convenience always carries a caveat in programming. This is a substantial pillar of the “readability” discussion: durability of convenience.
\n> Note: let can enhance readability when used sparingly (1,2, or maybe 3 declarations) in any given example group, but that can quickly degrade with overuse. YMMV.
\nCool find: givens. Shoutout to the translators, the transcribers, the interpreters.
\n", "date_published": "2023-10-25T11:57:43-07:00", "url": "https://softlydeveloping.micro.blog/2023/10/25/rspec-vs-js-let-vs.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/07/04/with-annemarie-willis-professor-of.html", "title": "With Anne-Marie Willis, professor of design theory at the German University in Cairo.", "content_html": "Another world is possible. But what of worlding? How to world?
\nWhen a Farley’s barista is a strong current; wow the level of shine escaping her mouth. And I loved it. The slightest tickle of maple syrup was a great recommendation!
\nPer usual I sent myself something to read and didn’t cite the source so I’ve been having that weird kind of drifty, but tethered, Pong ball experience. Was it mentioned by someone in a Paper in Systems discussion? Maybe a content of the fediverse’s systems thinkers briefly held in place by my thumb.
\nAs I like to say (with often different verses), I do software development because it’s a phenomenological wonder of people, text, code, time travel, non-determinism – and always pluckily avoids fitting neatly into capitalist fetish.
\nLike, software projects (already “bad” (incomplete, inaccurate) lexicon) of any substantial scope are only delivered on time accidentally.
\nFrederica Frabetti supports this axiomatic chiste of software, noting in her book Software Theory:
\n> “The central problem of software development is thus the impossibility of following a sure path in which a system is completely and exhaustively specified before it can be realized.”
\nand
\n> “Stability is something that happens to the system, rather than being scheduled and worked towards.”
\nLook how software was virtually helpless to build complex systems that are designed to become eventually consistent.
\nFor me, software is philosophical-ing. An ontological milieu. Therefore Willis' essay is soooo good for those of us who are philosophical-ing, but not academically trained – and who can drift into this kind of theoretical reasoning easily, especially in an essay like Ontological Designing which onboards us you into hardcore theory with a ton of grace. Willis doesn’t need to spend her initial breaths on defining “ontological” and and Heidegger’s “being”, and (re)introducing us to the failure of the Western metaphysical tradition. But she is generous; and that’s likely the point. A broader appeal.
\nWhich, in turn, helps the mind Pong around during an essay about pervasive push and pull.
\nI’m reading this essay about how we effect social change but also thinking through the systems reasoning and how it vibrates into software ontology. Well, there are references to IT infrastructure and other “equipment” of our present epoch – though they do not supersede other kinds of equipment. For Willis, our contemporary technologies can function both as examples of any designed material, as well as juxtapose with the immaterial (organizational structures, administrative systems, etc…) to demonstrate how they are equivalent as objects/outcomes of the ontological design circularity/looping, bi-directional reach – Heidegger’s grabbing Cartesian dualism by the shoulders and shaking them.\n(“Ontological designing refuses such one dimensional understandings of (human) being-in-the-world, which are worn-out fragments of enlightenment thinking and Christian morality sloppily stitched together.") As Willis notes, Heidegger themself reaches for the simple household jug to work with in his pursuit of how things, thing.
\n> “The jug gathers and unites these.”
\nThese being: water, wine, sky, earth. Gathered/outpoured.
\nBut she talks about tech in a way that tickles, for sure. Especially it’s excess as it frenetically infinite loops rather than unlocks potential:\n> Rather than inducing us into a world of multiple creative possibilities (as software advertisers would have it), [computers] design us as users into their horizons of possibility – which by the very nature of horizons (in Gadamer’s sense) always have a limit. In fact, the proliferation of options within even a basic operating system or software application becomes a tyranny of choice, a maze of seemingly endless possibilities, a dazzling instrumentation for its own sake, all means with no end in sight.”
\nMaybe free software never will be truly free.
\n![\"\"](\"https://internetross.space/uploads/2023/farley-mug.webp\")
\n",
"date_published": "2023-07-04T15:03:38-07:00",
"url": "https://softlydeveloping.micro.blog/2023/07/04/with-annemarie-willis-professor-of.html",
"tags": ["speculative nonfiction"]
},
{
"id": "http://softlydeveloping.micro.blog/2023/06/08/naur-goodies-years-after-jesus.html",
"title": "Naur, goodies, 1985 years after Jesus Christ",
"content_html": "There are so many goodies in Naur, 1985. Filter, some():
\nThank you ceejbot for further distillations.
\n", "date_published": "2023-06-08T09:29:54-07:00", "url": "https://softlydeveloping.micro.blog/2023/06/08/naur-goodies-years-after-jesus.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/06/08/naur-the-optimist-years-after.html", "title": "Naur, the optimist, 1985 years after Jesus Christ", "content_html": "The year is 1985. Certain kinds of optimism abound in programming circles. From Peter Naur’s Programming as Theory Building:
\n\"It may be noted that the need for revival of an entirely dead program probably will rarely arise, since it is hardly conceivable that the revival would be assigned to new programmers without at least some knowledge of the theory had by the original team.\"\n
The infamous “shit mouse” bug that I pushed to production in 2018 – which subsequently became an iconic team joke with its own concomitant laptop sticker swag – was the direct result of software abandoned in the wake of absconding team members. Picking up dust-laden software seems like a common occurrence these days, no?
\nIn their reading-with of Naur, Ceejbot offers a valuable remediation technique for deleterious knowledge vacancies. It’s one that I personally strive for in everyday software practice: gross amounts of maintainer documentation.
\n> Don’t waste time documenting what can be seen through simple reading. Document why that function exists and what purpose it serves in the software. When might I call it? Does it have side effects? Is there anything important about the inputs and outputs that I might not be able to deduce by reading the source of the function? All of those things are clues about the thinking of the original author of the function that can help their successor figure out what that author’s theory of the program was.
\nand
\n> …the program exists to solve a problem, some “affair of the world” that Naur refers to. What was that problem? Is there a concise statement of that problem anywhere? What approach did you take to solving that problem statement? What tradeoffs did you make and why? What values did you hold as you made those tradeoffs? Why did you organize the source code in that particular way? What belongs where?
\n", "date_published": "2023-06-08T08:56:20-07:00", "url": "https://softlydeveloping.micro.blog/2023/06/08/naur-the-optimist-years-after.html", "tags": ["speculative nonfiction"] }, { "id": "http://softlydeveloping.micro.blog/2023/06/06/power-moves.html", "title": "Power Moves", "content_html": "During her novel workshop on estate planning, Sarah Deluca of Move Money Shift Power poses the question:
\nIs holding onto control after your death something you want?
\nIf part of our life’s work is to strengthen connection, relinquish power, share power, redistribute, does a Trust actually violate the moves we’ve been making at the speed of small “t” trust? Individualistic posthumous scheming is not the invention of communities, but of corrupted powerfuls. It would seem.
\nA few days later I found myself in the next Paper in Systems discussion led by Dawn Ahukanna and Shauna Gordon-McKeon. On the table was Shauna’s essay Interpretive Labor: Bridging the Gap Between Map and Territory. Wherein you’ll find a rich investigation – and then interrogation – of the lopsided power distribution between those that labor to imagine, construct models, maps, and those that sit with the effects of the implementation – who interpret, navigate, bridge the chasm between theory and material outcomes.
\nI was called in. Software engineers do wield an outsized power from behind the desk. Although the tower isn’t deathly bleached, because 1) we do some interpretive labor at the seam between business requirements and software building (system design, theory of, code/text writing), and 2) failures reverberate back to us pretty hard (midnight pages) – at least more acutely than through the beauracratic layers. (Do the capitalists get to feel much of anything?) Nonetheless, we probably aren’t the ones screaming during the scream test. What do we do with this power?
\n\n