Keeping conversations going on the Web

In his latest AltPlatform post, Brian Hendrickson discusses various “levels” of comment/conversation technologies available on the Web:

  • Level 1 – Crossing web site boundaries, Webmention, Mastodon.social
  • Level 2 – Hybrid network, publishing feeds but need a reader to follow them
  • Level 3 – Internal social networking (Slack, Rocket Chat)

I use Twitter and RSS readers to try to monitor areas I am interested, and items I want to read and comment on. What I would like is to be able to comment easily and keep a conversation going. If there are tools that can help me do that, I want to know about them!

 

How the Open Source Bridge River of News app works

Welcome to attendees of the 2017 Open Source Bridge conference in Portland, Oregon! If you followed the link from the Open Source Bridge River of News app, this post will explain the tools I used to create the app.

Tool list:

I wanted to create an app to be able to easily follow news about the conference (see my app at FullBlastNews.com for a more complex example of following multiple RSS feeds). To start, I reviewed the conference presenter list and made a list of the available Twitter handles and weblogURLs. Next, I created lists of the blogs and added it to my River5 installation. River5 is a “river of news” aggregator that allows you to follow multiple RSS or Atom feeds and display them as separate lists or rivers.

I also wanted to create a RSS feed of Twitter posts by the presenters and Twitter posts containing the text “osbridge”. To do this, I used the TwitRSS.me web service. The site allows users to create a URL search for a Twitter handle or a Twitter search. I then took these URLs and added them to separate text files to add to my River5 installation.

After adding the lists to River5, three files were created containing a list of items from the combined RSS feeds. I then used the riverBrowser toolkit single page app to display those files.

Requirements:

  • Linux server to run River5
  • Web hosting for the single page

I will be at the Open Source Bridge conference – feel free to reach out if you would like to talk about RSS apps, develop something new, or get some help on setting up your own app (tweet me at @AndySylvester99)!

 

Getting started with Tone.js – Day 1

I have been playing with the Tone.js Javascript library for creating Web Audio apps and the NexusUI library for creating user interfaces. I am going to work on creating an app for music composition using the concepts of Joseph Schillinger and his “Schillinger System of Musical Composition”. To get started, I have created a sample app available at http://andysylvester.com/files/tonejs_experiments/ which plays a set of tones based on a Schillinger resultant. The code for the app is also on Github. Check it out!

 

We have great tools to create – are we creating great things?

I have been following Doc Searls’ account of the podcasting conference at Columbia University this past weekend. It is fascinating stuff – I wish that Columbia would have made these presentations available online – maybe they will at some point. My takeaway is that there is a lot of diversity in podcasts (subjects/formats), that there is no controlling silo (although many bigger podcasters seem to worship at the Temple of iTunes…), that there are a lot of podcast gems out there but it can be hard to find them (discoverability), and that like Sturgeon’s Law says, there are a lot of low-quality (my euphemism) podcasts out there, but hopefully through experimentation, better podcasts will arise.

Code coverage resources (MC/DC)

Avionics software development requires different levels of code coverage based on the assurance level of the software, which is based on what kind of aircraft failure condition would result from a software anomaly. For Level A software (catastrophic failure),
the required code coverage includes modified condition/decision coverage (MC/DC). Here are several good resources explaining various aspects of this type of code coverage:

NASA – A Practical Tutorial on Modified Condition/Decision Coverage
FAA/CAST – What is a “Decision” in Application of Modified Condition/Decision
Coverage (MC/DC) and Decision Coverage (DC)?
FAA – An Investigation of Three Forms of the Modified Condition Decision Coverage (MCDC) Criterion

Personal data on software defects

Recently, I spent a week at a simulator facility supporting checkout of software changes. During the week, I created several prototype changes for new features. I had a number of issues, and decided to share some data on those issues.

1. Editing problems
I was asked to swap a parameter used in a calculation for another parameter. I was editing source code in a Subversion branch checkout. However, one of the files I had opened was from a trunk checkout of the same software baseline. This file had the main declaration of the new parameter. As a result, I was getting an “undefined parameter” linking error. I thought I had confirmed that all of the files I was using was in the branch checkout directory, but that was not the case. I had to get two of my peers to take a look at what I had done, one of them was able to successfully compile the code changes. That gave me the idea to recheck the location of the files, and I then saw the problem.

2. Compile errors – part 1
My next prototype was a significant modification of two functions. I had a set of redlined requirements, and decided to do a pair programming exercise with the flight control engineer who developed the requirement changes. We reviewed the code changes as we went, then started compiling and removing errors. Here is what I had:
a. Forgot to update function prototypes in include file
b. Two LOC had semicolons when they should have had no semicolons (function initial statements)
c. One incorrect variable declaration
It took about 5 minutes to correct those problems.

3. Compile errors – part 2
I got a set of draft requirements for a new algorithm from an engineer. The requirements were in a Word document, and included some pseudocode and actual code snippets. I created the initial prototype by myself, then reviewed it with the engineer. After our review, I then started compiling and removing errors. I cannot remember the early errors, but there was one that persisted. The compiler was telling me that there was a problem with a character on two line, but did not directly identify the character. The problem was when I copy/pasted the code snippets, the minus sign in two equations was not a dash, but some other character. I deleted that text and retyped the minus signs, and that corrected the final problem.

Summary
1. When in a hurry, take time to review your changes.
2. When copy/pasting from a Word document, be sure to check equation text.
3. Pair programming can be a useful development method.