Software Development

There are 86 posts filed in Software Development (this is page 1 of 9).

Co/Recursive: Beautiful Code – Inside Greg Wilson’s Vision for Software Design –

Greg Wilson has been on a decades-long quest to transform how we teach and talk about software design. From getting rejections for using the term “beautiful code,” to empowering scientists through workshops on Python and Unix, Greg has pushed to bridge the gap between theory and practice.

Join us as Greg shares his failures and epiphanies along the way. You’ll hear how he revolutionized research computing by showing physicists the power of profilers. How he taught grad students the elegance of shell scripts. And how he’s crusaded to create a shared language to discuss software architecture with the nuance of true craftsmanship.

Greg’s captivating journey reveals that with perseverance and the right examples, we can elevate software design discussion to an art form. But that we’ve got a long way to go. You’ll come away enlightened and eager to level up your own understanding of software design.

The topic of text boxes

Recently, in another post on the subject of textcasting, Dave Winer made a comment about text boxes:

Every time you see a tiny little textbox that’s a sure clue they’re trying to own you, and hoping you don’t notice.

http://scripting.com/2024/02/01.html#a154043

I think this is a reach. In my opinion, the simplest reason to use a text box for text entry is that users are used to it and it is easy to implement (using Occam’s Razor here). Another explanation is that it is use of prior art, as Dave Winer has written about before (see here, here, and here). No sinister plan to “own” anyone here. Could text editors be better/have more features? Sure they could! Could writing apps cooperate with each other and have APIs? Sure they could! Should people be demanding these things? Sure…maybe….or maybe they could make those things happen…or maybe they could submit a feature request….

If the software is open source (Mastodon et al), someone could make their own changes. If the software is a service provided by a company that does not charge for the service (hmmm…Twitter, Facebook, Threads, Bluesky come to mind), it seems more difficult for users to request features and drive changes. If a group of users REALLLY wanted something and no other app seemed interested, maybe they could create their own product (thinking Kickstarter here). To me, it comes down to this: how bad do you want this?

Finally, another take on this sentence comes from Ken Smith:

Ken Smith comment on Dave Winer’s “text box” statement.

Based on Ken’s comment, I take this as “any antisocial behavior” in the blank – racism, anti-Semitism, discrimination, manipulation…the list can go on and on as Ken points out. This Quora thread has some good points about someone trying to “own” someone.

Who should be working together on Textcasting?

In recent posts, Dave Winer has been bringing up the “working together” mantra in regards to the Textcasting concept. This has been a difficult concept for me to grasp – working together with who? Today, Dave sheds a little more light on this:

When I say textcasting is “applying the philosophy of podcasting to text” — what I mean in practical terms is that my flow of ideas is available “where ever you get your text.” Choice in subscribing has to be that fluid, commonsense, and choice is something people feel entitled to, as they do with podcasts. I’ve been told people would never understand the philosophy of podcasting, but they do, they understand they’re entitled to choice in how to listen and thus producers are free to choose where to publish. Somehow text, which is so much easier to transmit than audio, is far less flexible. That’s a mistake I want to undo, but I can’t do it alone. I need to work with other people who have writing and reading tools, and people who have something to say and want all the features of writing to be at their disposal, and for it to be easy, inexpensive but not free of charge, and not owned by the titans of tech. (bold/italics emphasis by Andy Sylvester)

from http://scripting.com/2023/12/30.html#a160414

I think the key part of the highlighted text is “other people who have writing and reading tools” – that is, people who are involved in developing writing and reading tools, or the primary developers of reading and writing tools. Dave Winer did press Bluesky to add RSS feeds as a native feature in the Bluesky client, and this occurred on December 22. He has also developed some software to be able to post to WordPress, Mastodon, and Bluesky via a REST call, so I guess these three platforms are not the ones Dave wants to work with?

Two other concepts in this paragraph also deserve some review:

  • my flow of ideas is available “where ever you get your text.”
  • Choice in subscribing has to be that fluid, commonsense, and choice is something people feel entitled to, as they do with podcasts.

To me, this moves beyond the “feature list” as defined at Textcasting.org. The first bullet implies that a writer should be able to publish their writing such that it can be seen in any tool. Apps that create RSS feeds of content could be read in any RSS reader, so if all writing apps created RSS feeds of the output of their apps, a user could use a RSS reader app to read that content. However, I don’t think that is the direction that the first bullet is heading. My feeling is that the real message of this bullet is “my flow of ideas should be able to be posted on any social media network without me having to re-enter my ideas into some other editor or tool”. THAT would definitely require app developers to work together to make that happen. And why would they do that? I have been thinking about the struggle to get Twitter/X/Facebook/Threads to create RSS feeds. My simplistic thought is that if users could get the content using RSS feeds without going through the platform app/interface, the users would not be exposed to the ads that that the platform has, which is the primary means of support for those applications. From that standpoint, it does not make business sense for those applications to give the content placed in their apps away in that manner.

This brings me to the second bullet mentioned above. To me, this could be a description of the “pain” experienced by Mastodon users when trying to follow another Mastodon user on a Mastodon instance different from the one that hosts their accounts. Similarly, it could also describe the pain of trying to subscribe to a RSS feed. As I mentioned earlier, THAT would definitely require app developers to work together to make that (cross-app subscription and forwarding of content) happen. And why would they do that? I don’t know. As an aside, for many podcasting apps, their feed search feature is good enough to find a podcast feed from search terms, so I don’t think that is the use case being highlighted by the second bullet.

To return to the title of this post, I think the people that need to work together on textcasting are primarily developers. As the developers have applications, they should then evangelize their work to potential users. To me, this seems to be the approach that the Textcasting “movement” needs to follow.

Open letter to Dave Winer’s call to develop feed-based social media apps

On December 3, Dave Winer published a “call to develop” for a feed-based social media app (he mentioned Mastodon in his post, but could be any social media app out there in my opinion). Sounds great to me! I have a feed-based app using rssCloud for notification called MyStatusTool (link to Github repo and my install). It is implemented using Node.js, Express, and Embedded Javascript for templating. It inspired Colin Walker to develop a PHP implementation of the tool (Github repo, his install). We were able to use our tools to interop with each other (have a real-time conversation), and to follow other feeds using rssCloud for notification. I have tested my implementation with the rssCloud user feeds from FeedLand and WordPress.com in addition to Colin Walker’s MyStatusTool implementation, and verified the real-time performance (new posts showed up almost immediately).

Now, is MyStatusTool a fully-developed thing? Nope! It’s a bootstrap. It does use a number of Node packages developed by Dave Winer for feed generation and feed reading, and uses Andrew Shell’s rssCloud server for notification, so I think it falls into the “working together” category that Dave Winer wrote about in 2015: “When you have a choice, instead of re-inventing someone else’s work, use it.”

I am ready to work for interop with whatever Dave develops. I don’t have any illusion that MyStatusTool is the epiphany of feed-based social media tools, but I developed it to see if one could be developed, and it spawned another implementation, so I think that is pretty cool. Let’s get busy and see what happens!