I was heating up a Lean Cuisine dinner today, and part of the “dish” melted in the microwave. Now, I did not quite follow the instructions, which were to heat for 3.5 minutes, then stir, then heat for 1.5 minutes more (I just went for 5 minutes – I have cut back on that rigid following of instructions). It looks like there was some fluid trapped by the food, and the heating of that fluid resulted in the melting of the plastic dish. This is the first time this has happened to me – could be just a fluke – but made me wonder if I should be more careful in the future. Thoughts, anyone?
They don’t make them like they used to…
Ken Shirriff has restored an Apollo Guidance Computer (AGC), used in the Saturn V spacecraft. He recently published an article on how the power supplies still worked flawlessly after 50 years. Recently, two embedded computers that I work with burned up their power supplies, so this is really impressive to me! Ken has also written articles on creating a core rope simulator (the way software was programmed), writing software on the AGC to do bitcoin mining, and a more detailed discussion of core rope memory. Finally, he has references to a virtual AGC simulator, and to a great summary page on simulated AGC projects. Wow!
Computer music formats
I am trying to collect some information on music formatting languages/tools to assist me in doing some algorithmic music composition.
MusicXML – granddaddy of them all (used by Finale, Sibelius, many other music notation software applications)
Collection of formats – Interesting site with extensive collection of formats
Music JSON proposal – GitHub repo with a proposal for notating music in JSON
Using LilyPond as input to Tone.js – Will have to look at this some more…
Musescore – open source music notation program
VexFlow – open source music notation program that uses VexTab as a music notation language
OpenMusic – a visual music composition language, with applications available for Windows, Macintosh, and Linux.
JAMS – JSON Annotated Music Specification Github repo (other docs)
musicxml-interfaces – NPM library for parsing MusicXML to JSON
musicjson – NPM library for converting MusicXML to MusicJSON and back again
W3 Music Notation – community group
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.
Thoughts on losing weight
Like many adults, I have “a few too many pounds”. I have been on Weight Watchers twice, with not too much success. A few years ago, I was able to lose 20 pounds (at the rate of about a pound a week), but I was pretty disciplined about what I was eating. I haven’t been that disciplined since that time, and it shows. Recently, I am trying to eat a smaller amount at breakfast and lunch, with a regular dinner. So far, when I stick to that, I start making progress again. The thing is to keep on track with small meals – when I get off track, weight loss slows or reverses for me. I think the main thing is to hang in there – it’s a marathon, not a sprint – it’s ok to get off track as long as I get back on track….thanks for listening.
Owning your tools
In the engineering world, the phrase “make or buy” or “build or buy” is common. It represents a design choice/decision to purchase components/equipment/software for a project (buy) or create it yourself (make/build). Things that are considered include cost, ease of inclusion in the design, flexibility, and other attributes. For software users, a similar choice exists, which could be called “set up your own tools, or use services provided by others”. Things to consider are cost, ease of use, features, and portability and ownership of data, among other things.
I use River5 as a feed aggregator, and create single page apps to display combined feeds (Andy Sylvester’s Reading List). There is some friction to start (get a server if you don’t have one, install software, set up single page apps) and some friction for updates (have to FTP subscription list updates), but after the setup is complete, I have had almost no problems. I could have used some online service (Feedly, Flipboard, many others), but then I would be dependent on those services (could have outages, terms and conditions might change, other restrictions on the service might occur, the service could go out of business). Similarly, I use my own install of WordPress on the Bluehost hosting service. I control it, I decide when it gets upgrades, and I can keep backups and move it to another service if I want.
To me, the cost/inconvenience is worth it to own/control the tools I am using. Whatever you do, be mindful of the choices you make….
Building community
Ton Zijlstra commented on a post by Chris M about what would be a critical mass for a community. In Ton’s reply, he links back to a post, which links to a presentation on steps to consider in building/starting a community. I think the presentation contains some excellent material. I participate in a biweekly meeting of software engineers at my workplace (using the Lean Coffee format), and feel we have made some good progress in turning that into a community of practice. Reviewing this presentation, I can see some areas that we might be able to improve on. I hope to pass on some thoughts to the group leadership..
Please have a little respect for the past
I enjoy reading Philip Greenspun’s weblog, and he certainly has experience in aviation and software development. His recent post on visiting the Museum of Flight in Seattle throws quite a few digs at the US space program and people who have been a part of the effort. I worked at NASA and Lockheed in Houston from 1985-1997 on the Space Station program, and had the opportunity to work with a great group of people, both contractor and civil servant employees. Things were contentious at times (usually dealing with funding issues from Congress and the Administration), but we got the job done (flew Space Shuttles, came back from the Challenger accident, got the Space Station program back on track). I know that Philip likes to find fault with many things in the United States (and I agree with most of it), but I think he might want to stay with areas he has expertise in and not look for other ways to poke people in the eye.
Looking for some music tools to try
I am looking for a music production/DAW tool. I have done some playing around with the Web Audio API (see my series of articles on Theresa’s Sound World, and exploration of the Tone.js library), but found it difficult to use those tools for music composition. Some apps I am going to review (Windows versions) are:
My main interest is in algorithmic composition, so I am hoping to find a tool that can be scripted or programmed, or accept input files generated by a script or program. A tool I once looked at was Pyknon, a Python library for generating MIDI files, in conjunction with the book Music for Geeks and Nerds. If any of my three readers has any suggestions, let me know!
Using the tools at hand
Om Malik posted recently about his use of pen and paper, and what he likes about it. I am also a fan of making a task list on paper and crossing items off – it feels so good! Even if I do not complete everything on the list, getting everything down on paper feels good (see Getting Things Done Step 1 – Capture). However, there are times when other tools could and should be used. I have written about my use of Personal Kanban for organization, and I have dabbled with Google Tasks to replace my pen and paper list. The mistake I try to avoid is continuing to look for another tool when the one or ones I have at hand are “good enough”. I know of several people who always seem to be looking for another tool that will do the job better, when they could have used a tool they already have or that they are already familiar with. Use the tools you have at hand – see how that can make you more productive.