Software Development

There are 92 posts filed in Software Development (this is page 7 of 10).

If you want to hurry, slow down

The title of this could have been “If you want to go faster, slow down”, but I liked this one better. The reason for this post is a set of events that happened to me recently, where multiple immediate actions fell in my lap. As I tried to take case of these actions, I made mistakes along the way, which slowed me down. As I was trying to solve one of these actions, other things changed which I did not know about until some time later. If I had known, I could have taken other steps to address the action. As it was, those people were hurrying as well.

What is the takeaway here? If someone presents you with a request for immediate action, slow down and think about it. Ask some clarifying questions. See if the deadline is really as dire as the person thinks it is. By taking these actions (slowing down), you have a better chance of finishing faster (the goal of hurrying). I will try to remember this when (not if) this happens to me again!

Some thoughts on first-run experience for software apps

In the past two days, I installed three digital audio workstation applications on my Windows laptop (Ardour, LMMC, Reaper). In each case, I just downloaded the latest version, did the install, then started the app. For Ardour and Reaper, both of them wanted me to select an audio input device (well, I didn’t have one!). I just clicked on something to get to the main app. For Ardour, I had to quit and try again, since the thing I clicked did not meet the app’s expectations. Only LMMC was able to start without some dialog popping up. For all three apps, I was then faced with a screen filled with various subwindows and a menu bar. What to do now?

Now, I will admit that these types of programs are complex, and require the user to know a little something about what they want to do, or how to use them. But when you compare this with many smartphone apps, there are usually some choices you can make from just looking at the screen to get started. Sure, each of the programs has some “getting started” resource (Ardour, LMMC, Reaper), but it might be nice for the app to have some built-in starter setup or task accessible from a menu (or something!). Just my two cents…

How should developers build apps?

Earlier this week, I read a post titled “Build Libraries, Not Apps“, where the author (Nicolás Ortega Froysa) puts forth an idea that software developers should create the main part of their applications as libraries, then create APIs so that other developers can create alternate user interfaces in other clients if desired. I can see that being an appealing goal for developers who want their application to be used in lots of other settings. However, I do not think that most applications are designed to have alternate user interfaces. For myself, I think of the user interface that I want my application to have, and then create it, and then create the logic that powers that interface. It is not a design goal for me to support an API. Froysa mentions different ways that Unix/Linux applications can interact with libraries (GUI, text interface, command line interface). To me, if a design goal of the application is to support multiple clients, or provide services to other applications, then including an API makes sense.

Install notes on 1999.io and MyWord Editor

I am working with Ron Chester to set up some instances of the 1999.io and MyWord Editor blogging tools, and have some test installs working on my Digital Ocean instance. I did have to make a tweak to one of the files in the nodestorage app, will be filing a Github issue on this. However, I did want to capture a few points that I re-learned in doing this again:

  • Install separate instances of nodestorage for each app (using different ports), otherwise you will mess up one of the tool outputs.
  • The Twitter API setup at apps.twitter.com has changed a little bit, what used to be called consumer secret and API secret are now part of the API secrets at the top of the page with the secrets info.

If you want to try the installs, go to the following URLs:

Read: Tools are more valuable when they are connected

Read Tools Valuable On Their Own, More Valuable When Connected by Ton Zijlstra

Jerome Velociter has an interesting riff on how Diaspora, Mastodon and similar decentralised and federated tools are failing their true potential (ht Frank Meeuwsen).
He says that these decentralised federated applications are trying to mimic the existing platforms too much.
They are attempts at reb…