I type the program arguments into an Excel sheet. I write a short description of what I am trying to accomplish. I send the description and the Excel sheet to a person that has access rights to the ticketing system. Repeat three times. The next day she reads my emails and submits the three tickets.
The three tickets get assigned to three persons in a country where work used to be cheaper than here. They type the program arguments from the Excel sheet into the scripts that will run the programs. They mark the tickets resolved. Corporate metrics show exemplary ticket handling response times.
Next week another ticket gets resolved and a tester gets access rights to the system. She runs a test case for my use case. It doesn’t work. I request access to the log files from the server admin. Next day I have the logs and find out that the second script failed to trigger the third script due to file access rights. No problem, that is easy to fix.
I write a short description of what I am trying to accomplish. I send the description with an Excel sheet to a person that has access rights to the ticketing system. I realize that this is state of the art in Enterprise DevOps in 2016.
In the fall of 2010 we at Sysart organized a small conference at Helsinki and Oulu. Daniel Wellner and I did our presentation on how to keep the domain model unambiguous. Jimmy Nilsson was the featured guest and talked about building a domain model.
In his presentation Jimmy said something that caught my ear: “The user should be able to save invalid data“. The concept is explained in chapter 7 of his book Applying Domain-Driven Design and Patterns. The book says: “All States, Even When in Error, Should be Savable”. The idea is simple but not widely applied – when a user cannot complete all the required information the application should still allow saving the partial work he or she has done.
The concept stuck in my mind. Every now and then a situation comes up where this idea seems to fit. Think of a doctor entering a diagnosis into a patient care application. A diagnosis entry form might contain a dozen fields. It would seem useful that the doctor could enter just the most important data while with the patient, save the entry and complete it later. But applications tend to be too eager and demand everything to be completely valid on first save.
Then I stumbled upon StaffPad. StaffPad is an application for writing music. Writing music. Not typing, not mousing around. Writing music the old-fashioned way, with a pen. As a songwriter I was immediately intrigued. Could this application make notating random ideas into a computer feasible for me? I always preferred pen and paper because I disliked the input methods in all the music applications I tried.
The pen works really well for entering notes, rests and other symbols. But what happens when StaffPad does not recognise your writing? It applies Jimmy’s advice and saves the unrecognized strokes as part of the page. If you print the score, the mystery symbols are not discarded, they get printed too. A human can read and play the scribbles assuming your handwriting is legible. The only thing StaffPad cannot do is play the notes because the meaning of the unrecognized strokes is a mystery to the application.
This is good, but StaffPad takes it a step further. Sometimes the user wants to express something that can not be codified in the domain model. Western musical notation has a huge amount of symbols and it is not feasible to implement all of them in an application. StaffPad has a clever way around this problem: an extra layer (think Photoshop layers) on top of the notation where you can draw whatever you like. A scribble layer. You can jot down obscure electric guitar performance symbols or draw a picture of your favorite game character. The layer is domain-aware – it intelligently attaches to bars, and is formatted into each musicians parts on printouts.
Is this idea of a separate unstructured layer placed on top of the model presentation useful in other applications? I sure would like to annotate source code with small drawings in my IDE and have them follow the source anywhere it goes. Do you know applications that implement a similar idea?
This is part two in the adventure where I’m experimenting with using my DAW on a tablet with only a touch interface. See here for part one: Samplitude on a tablet – part I
I believe I have found the most productive combination of toolbar buttons. I have also updated the Thinkpad tablet to Windows 10 and everything still works smoothly.
This is the set of toolbar buttons I settled on. These actions are optimized for recording and arranging song ideas, not mixing. There are 18 buttons:
- toggle drawmode – shows/hides track control panes
- show/hide track editor – edit a single tracks properties, access to plugins
- show/hide mixer
- group objects
- ungroup objects
- toggle snap
- split object
- remove range
- lock all audio – Prevents accidental moving of objects. With a keyboard I use shortcuts to toggle the Lock/Unlock state of individual objects. With touch it is easier to have a single global lock.
- cut – Normally I ctrl+drag objects to copy them but cut/copy/paste works better with touch.
- toggle metronome
The Windows task bar is back at the bottom of the screen and hidden. Swiping up from the bottom shows the task bar and gives access to the touch keyboard.
If you use multiple time signatures like I often do, I recommend setting the project time signature to 1/4 or 1/8 and NOT adding any signature changes. This makes it easier to move song sections and parts around.