A thought occurs to me while trying to learn and use Kivy on Android, via Buildozer: if you are going to have something, be it a configuration script, a build tool, a language, etc., it would perhaps be nice to leverage things which already have well known and well documented semantics.

Thus rather than the buildozer.spec file using heaven only knows what format, use something more standard like JSON or even XML (e.g. how does one break up a long line value?). I know the new cool kids would laugh, but I'd rather have it be based on e.g. Make for Pete's sake. Similarly, rather than making up your own event system, how about find one that is more already long lived and well documented (e.g. what aspects of the event system are synchronous vs. asynchronous, exactly)?

(There's a zillion other things about Kivy and Buildozer that are just terrible, terrible UX, but I'm restraining my whining to this for now, and attempting to draw some sort of constructive lesson from it other than just, "how about you just not suck in the first place?" E.g. if you are going to write a command line tool, what if you made sure the docs matched how it behaved? Gosh. Or that you maybe caught internal errors in a standard way and reported them cleanly rather than letting the stuff leak out like olestra all over my console? Also, has nobody ever heard of showing % progress even in a command line tool? Etc.)

I would just like to go on record as saying that just about every UI I've ever seen for managing web browsing history has been a transparent piece of junk wrt actual UX. I completely cannot fathom how all browsers everywhere (that I've used, and I've used quite a few) get it so blatantly, clearly, stunningly, obviously, terribly wrong. As if the people working on the browsers have never used it themselves.

Having said that, of course UI and UX are hard. Especially when you have some gazillions of users that you have to not piss off with arbitrary changes, even if the changes are for the better. At least, if you are in it to make money.

Some things I would like to see as possible improvements:

• History pull-down/pop-up menus are truncated these days (Chrome, Firefox). I miss the days when it was a scrolling thing. Maybe that was hell for some use cases? I don't get it, personally.
• Full histories in Chrome do not show a useful page title for Google Search interactions. How the hell can that possibly have ever come to be? Utter bare faced insanity.
• Tabbing is hell when it comes to histories. This to me is probably the most can't win thing of it all. Firefox's "Recently Closed Tabs" confuses me. I think I just want everything inlined in my history. Did they have a separate thing because their history menu doesn't scroll? Dunno. Maybe Chrome's "recently closed" vs. "recently visited" is the best thing I've seen so far?

Related is when I start typing an address into the address/search text field. I want the completions to show the root URL of a site first even if I never visited it directly, and then the various sub pages I actually visted.

"Error confinement and recovery are much harder in the virtual worlds of software than in the real world of physical objects."

From Great Principles of Computating.

C++: So close, and yet so far away?

"Here, we will only briefly mention other ways of breaking the C++ type system. These problems are well known and have well-known solutions, so we will not address them here. Misuse of unions and casts can lead to type and memory violations (so follow the rules that prevent that [Stroustrup,2015]). For example, use a variant class rather than a plain union. Out-of-range access and access through a null pointer can lead to type and memory errors (so follow the rules that prevent that). In particular, use array_view and not_null from the Guideline Support Library (GSL) [Sutter, 2015b]. To minimize range errors, we also recommend using a make_array() function that returns an owner> to allocate an array on the free store, rather than using new or malloc() directly. The aim of the Code Guidelines is to eliminate a large range of errors by mutually supportive rules. No one rule can by itself prevent a large class of errors: ban one misuse and others will become popular (this is often referred to as “playing whack-a-mole”). Thus, our ideal is a large set of mutually supportive rules that together deliver type and memory safety guarantees."

"Unfortunately, multicast does not scale socially (a tragedy of the commons) and rarely succeeds across organizational domains, whereas flooding only succeeds when the signal/noise ratio is high." I want somebody with deep pockets to start a sibling internet on which multicast is guaranteed to be supported, no holds barred.

"I should also note that the above is not yet fully RESTful, at least how I use the term. All I have done is described the service interfaces, which is no more than any RPC. In order to make it RESTful, I would need to add hypertext to introduce and define the service, describe how to perform the mapping using forms and/or link templates, and provide code to combine the visualizations in useful ways. I could even go further and define these relationships as a standard, much like Atom has standardized a normal set of HTTP relationships with expected semantics, but I have bigger fish to fry right now."

3.7 Limitations

Each architectural style promotes a certain type of interaction among components. When components are distributed across a wide-area network, use or misuse of the network drives application usability. By characterizing styles by their influence on architectural properties, and particularly on the network-based application performance of a distributed hypermedia system, we gain the ability to better choose a software design that is appropriate for the application. There are, however, a couple limitations with the chosen classification.

The first limitation is that the evaluation is specific to the needs of distributed hypermedia. For example, many of the good qualities of the pipe-and-filter style disappear if the communication is fine-grained control messages, and are not applicable at all if the communication requires user interactivity. Likewise, layered caching only adds to latency, without any benefit, if none of the responses to client requests are cacheable. This type of distinction does not appear in the classification, and is only addressed informally in the discussion of each style. I believe this limitation can be overcome by creating separate classification tables for each type of communication problem. Example problem areas would include, among others, large grain data retrieval, remote information monitoring, search, remote control systems, and distributed processing.

A second limitation is with the grouping of architectural properties. In some cases, it is better to identify the specific aspects of, for example, understandability and verifiability induced by an architectural style, rather than lumping them together under the rubric of simplicity. This is particularly the case for styles which might improve verifiability at the expense of understandability. However, the more abstract notion of a property also has value as a single metric, since we do not want to make the classification so specific that no two styles impact the same category. One solution would be a classification that presented both the specific properties and a summary property.