[x]Blackmoor Vituperative

Saturday, 2024-01-20

Color scheme for Minimal Theme for Obsidian

Filed under: Programming,Software,Writing — bblackmoor @ 13:11

I have created a color scheme for Minimal Theme for Obsidian. I mainly use Obsidian on my Boox Tab Ultra tablet, which is an e-ink device. My intention is to create a very high contrast theme that is easily legible on an e-ink device like the Boox, while also being attractive enough for desktop or color tablet use.

The theme is nowhere near as colorful as most themes. If you like everything to be a different color, this theme is probably not your cup of tea.

This is written as a CSS snippet, but my hope is that the author of Minimal will eventually allow this theme to be added to the core Minimal color schemes. Obsidian really needs a clear, readable color scheme for e-ink devices. That’s what I want, in any case.

I have posted the CSS file to my github page. If pasted into the theme.css file in Minimal (between gruvbox and macos), the code looks like this…

.theme-light.minimal-kalos-greyscale-light{--color-red-rgb:145,28,28;--color-orange-rgb:145,28,28;--color-yellow-rgb:145,28,28;--color-green-rgb:21,83,83;--color-cyan-rgb:21,83,83;--color-blue-rgb:21,83,83;--color-purple-rgb:126,32,126;--color-pink-rgb:126,32,126;--color-red:#911c1c;--color-orange:#911c1c;--color-yellow:#911c1c;--color-green:#155353;--color-cyan:#155353;--color-blue:#155353;--color-purple:#7e207e;--color-pink:#7e207e}.theme-dark.minimal-kalos-greyscale-dark{--color-red-rgb:253,245,245;--color-orange-rgb:253,245,245;--color-yellow-rgb:253,245,245;--color-green-rgb:235,250,250;--color-cyan-rgb:235,250,250;--color-blue-rgb:235,250,250;--color-purple-rgb:252,245,252;--color-pink-rgb:252,245,252;--color-red:#fdf5f5;--color-orange:#fdf5f5;--color-yellow:#fdf5f5;--color-green:#ebfafa;--color-cyan:#ebfafa;--color-blue:#ebfafa;--color-purple:#fcf5fc;--color-pink:#fcf5fc}.theme-light.minimal-kalos-greyscale-light{--base-h:0;--base-s:0;--base-l:100%;--accent-h:240;--accent-s:60%;--accent-l:10%;--bg1:#fbfbfe;--bg2:#f8f8fd;--bg3:rgba(255,255,255,.5);--ui1:#0a0a29;--ui2:#18185f;--ui3:#000;--tx1:#000;--tx2:#222;--tx3:#3d3d3d;--hl1:rgba(105,105,217,.5);--hl2:rgba(169,169,233,.5)}.theme-dark.minimal-kalos-greyscale-dark,.theme-light.minimal-kalos-greyscale-light.minimal-light-contrast .mod-left-split,.theme-light.minimal-kalos-greyscale-light.minimal-light-contrast .titlebar,.theme-light.minimal-kalos-greyscale-light.minimal-light-contrast .workspace-drawer.mod-left,.theme-light.minimal-kalos-greyscale-light.minimal-light-contrast .workspace-ribbon.mod-left:not(.is-collapsed),.theme-light.minimal-kalos-greyscale-light.minimal-light-contrast.minimal-status-off .status-bar{--base-h:0;--base-s:0;--base-l:0;--accent-h:240;--accent-s:100%;--accent-l:100%;--bg1:#050514;--bg2:#0a0a29;--bg3:rgba(0,0,0,.5);--ui1:#fbfbfe;--ui2:#18185f;--ui3:#fff;--tx1:#fff;--tx2:#fdfdfd;--tx3:#fafafa;--hl1:rgba(105,105,217,.5);--hl2:rgba(169,169,233,.5)}.theme-dark.minimal-kalos-greyscale-dark.minimal-dark-black{--ui1:#000}

Monday, 2023-01-23

Efficiently Dockerize platform-agnostic apps with Node.js

Filed under: Cloud Computing,Programming — bblackmoor @ 15:52

This is pretty interesting. It had not occurred to me to use node.js to automate containerization. Neat stuff.

Personally, I am more interested in Golang and Rust, but this is a good thing to have in one’s toolbox.

https://www.codeproject.com/Articles/1240084/Efficiently-Dockerize-Platform-Agnostic-apps-with

Wednesday, 2023-01-18

The struggle against profitable complexity

Filed under: Cloud Computing,Philosophy,Programming,Technology,The Internet,Work — bblackmoor @ 09:27

“The struggle between profitless simplicity and profitable complexity is eternal in the world of software.”
https://world.hey.com/dhh/they-re-rebuilding-the-death-star-of-complexity-4fb5d08d

I started my career in programming during heydays of Java Enterprise Edition (J2EE). This was late 90s/early 00s, and there was a rich ecosystem of enterprise vendors hawking application servers, monitoring tools, and boxes upon boxes of other fancy solutions. These tools were difficult to learn, expensive to license, and required an a…

David Heinemeier Hansson, Creator of Ruby on Rails

Interesting article about containers, cloud, etc., by the fellow who created Ruby On Rails.

Wednesday, 2022-03-16

Rust and energy consumption

Filed under: Programming,Society — bblackmoor @ 16:41

I find this interesting. Go has been on my short list of “next things to play with” for a little while, but I am adding Rust above it.

A recent post on the AWS Open Source blog announced that AWS “is investing in the sustainability of Rust, a language we believe should be used to build sustainable and secure solutions.”

It was written by the chair of the Rust foundation (and leader of AWS’s Rust team) with a Principal Engineer at AWS, and reminds us that Rust “combines the performance and resource efficiency of systems programming languages like C with the memory safety of languages like Java.”

But there’s another reason they’re promoting Rust:

https://developers.slashdot.org/story/22/02/20/0143226/is-it-more-energy-efficient-to-program-in-rust

Monday, 2020-06-15

GitHub to replace “master” with alternative term

Filed under: Programming,Society,Technology — bblackmoor @ 10:37

Interesting. I am curious what people who primarily speak other langues use in the place of “master/slave”, “blacklist/whitelist”.

GitHub is working on replacing the term “master” on its service with a neutral term like “main” to avoid any unnecessary references to slavery, its CEO said on Friday.

The code-hosting portal is just the latest in a long line of tech companies and open source projects that have expressed support for removing terms that may be offensive to developers in the black community.

This includes dropping terms like “master” and “slave” for alternatives like “main/default/primary” and “secondary;” but also terms like “blacklist” and “whitelist” for “allow list” and “deny/exclude list.”

GitHub to replace ‘master’ with alternative term to avoid slavery references“, ZDNet

Monday, 2019-12-09

AWS vs. the non relational database

Filed under: Programming,The Internet — bblackmoor @ 17:09

Currently taking a course on AWS, in preparation for the AWS Certified Solutions Architect Associate exam. Interesting stuff. Possibly the tangent that is most interesting to me at this moment is the concept of a “non-relational database”. Of course I have heard of that — Mongo, Redis, etc. But I have never had the time (or really cared enough) to investigate them. I might try rewriting one of my simpler web sites to use a non-relational database (Amazon DynamoDB, specifically). I think it might be a fun exercise.

Monday, 2014-03-03

Ruminations on web design and system administration

Filed under: Programming,Work — bblackmoor @ 10:18

Now that the Kickstarter is over, I can go back to talking about other things. For example, how happy I am that I am no longer working in web design. The work I would like to do, in decreasing order of preference, is:

  • system administration
  • database administration
  • back-end programming (i.e., not Javascript)
  • project management
  • front end programming (i.e., Javascript)
  • web design

There are reasons why web design is at the bottom of the list. The biggest one is that the people who pay to have that done are too often operating under the false assumption that they know how to do it, and that they just need someone else to do the grunt work of actually using the software. Oatmeal has a pretty funny cartoon on what that’s like for a web designer.

That’s an exaggeration, of course. I am lucky that back when I did web design as my primary profession, I very rarely had clients quite that clueless. A more frequent occurrence was the “we need to Do Something” problem. Smashing Magazine has a pretty decent article on that, but if you have been a user of YahooGroups or FaceBook for any length of time, you have seen that phenomenon in action.

System administration is at the top of the list for even better reasons. For one thing, I simply enjoy it. I like making things work. It’s like working on a car and getting it to run smoothly, but you don’t bang your knuckles or get your hands dirty. Also, success is generally objective: if the system works, that’s success. None of the “that color is too aggressive” type feedback you get when doing web design (I actually had a client say that phrase to me). Of course, there are some subjective measurements of success, even in system administration. For example, you can continue throwing time and money at a database server to increase performance, and the point at which the performance is good enough is a subjective call. Even so, generally speaking, the line between “working” and “not working” is pretty clear. I like that.

Wednesday, 2013-11-20

Peer Review Lessons from Open Source

Filed under: Programming — bblackmoor @ 09:43

I recently found an article in the Nov/Dec 2012 issue of IEEE Software that sounded interesting, “Contemporary Peer Review in Action: Lessons from Open Source Development“. (Rigby, P., Cleary, B., Painchaud, F., Storey, M., & German, D. (n.d). Contemporary Peer Review in Action: Lessons from Open Source Development. Ieee Software, 29(6), 56-61.)

The authors examined the peer reviews of approximately 100,000 open source projects, including Apache httpd server, Subversion, Linux, FreeBSD, KDE, and Gnome. They compared these to more formal methods of software inspection and quality control, traditional used in complex, proprietary (non-open source) projects.

The open source reviews are minimal, and reviewers self-select what sections they will review. This results in people reviewing sections of code they are most competent to review (or at least, most interested in reviewing). The formal code inspections for proprietary projects are cumbersome, and the reviewers are assigned their sections, meaning they are often unfamiliar with the code they are reviewing. The peer reviews are completed more efficiently and are more likely to catch inobvious errors, but they lack traceability.

As a result of their research an analysis, the authors have five lessons that they have taken from open source projects which can benefit proprietary projects.

  1. Asynchronous reviews: Asynchronous reviews support team discussions of defect solutions and find the same number of defects as co-located meetings in less time. They also enable developers and passive listeners to learn from the discussion.
  2. Frequent reviews: The earlier a defect is found, the better. OSS developers conduct all-but-continuous, asynchronous reviews that function as a form of asynchronous pair programming.
  3. Incremental reviews: Reviews should be of changes that are small, independent, and complete.
  4. Invested, experienced reviewers: Invested experts and codevelopers should conduct reviews because they already understand the context in which a change is being made.
  5. Empower expert reviewers: Let expert developers self-select changes they’re interested in and competent to review. Assign reviews that nobody selects.

The authors go on to make three specific recommendations:

  1. Light-weight review tools: Tools can increase traceability for managers and help integrate reviews with the existing development environment.
  2. Nonintrusive metrics: Mine the information trail left by asynchronous reviews to extract light-weight metrics that don’t disrupt developer workflow.
  3. Implementing a review process: Large, formal organizations might benefit from more frequent reviews and more overlap in developers’ work to produce invested reviewers. However, this style of review will likely be more amenable to agile organizations that are looking for a way to run large, distributed software projects.

To be honest, I don’t have enough experience to have an informed opinion on these recommendations as they pertain to complex, proprietary projects. Virtually all of the projects I have worked on have been distributed, open-source projects, and nearly all of those had less peer review than I think they should have. That being said, the author’s recommendations and the “lessons” on which they’ve based them seem reasonable to me, and do not contradict with my own experience.

Wednesday, 2013-11-13

Remembering Xanadu

Filed under: Programming,The Internet,Work — bblackmoor @ 23:05
Xanadu

I was reminded recently of an interesting article from the June 1995 issue of Wired magazine. I subscribed to Wired back then: this was during the early days of the internet, while the 1990s tech bubble was inflating like gangbusters. The article is “The Curse of Xanadu“, by Gary Wolf.

It was the most radical computer dream of the hacker era. Ted Nelson’s Xanadu project was supposed to be the universal, democratic hypertext library that would help human life evolve into an entirely new form. Instead, it sucked Nelson and his intrepid band of true believers into what became the longest-running vaporware project in the history of computing – a 30-year saga of rabid prototyping and heart-slashing despair. The amazing epic tragedy.

The article begins with a brief description of the mind behind Xanadu, Ted Nelson. He is described as a very smart man with many ideas, but who has difficulty finishing his projects. Later in the article, we learn that Nelson has an extreme case of Attention Deficit Disorder.

The article then goes on to describe the goals of the Xanada project, which Nelson began working on in 1965:

Xanadu was meant to be a universal library, a worldwide hypertext publishing tool, a system to resolve copyright disputes, and a meritocratic forum for discussion and debate. By putting all information within reach of all people, Xanadu was meant to eliminate scientific ignorance and cure political misunderstandings. And, on the very hackerish assumption that global catastrophes are caused by ignorance, stupidity, and communication failures, Xanadu was supposed to save the world.

Yet Nelson, who invented the concept of hypertext, is not a programmer. He is a visionary. He is also appearently immensely persuasive. He convinced people to spend millions of dollars on Xanada (long before the tech bubble made that irrational behaviour seem normal), and years working on it. And it does seem that Nelson was a true visionary. In 1969, he already foresaw that technology would “overthrow” conventional publishing, and that paper would be replaced by the screen (in his mind, it already had). But he was limited by the technology of his day. “Even [in 1995], the technology to implement a worldwide Xanadu network does not exist.” In the 1970s, “[the] notion of a worldwide network of billions of quickly accessible and interlinked documents was absurd, and only Nelson’s ignorance of advanced software permitted him to pursue this fantasy.”

In the early 1970s, Nelson worked with a group of young hackers called the RESISTORS, in addition to a couple of programmers he had hired. During this period, the first real work on Xanadu was accomplished: a file access invention called the “enfilade”. What the enfilade is or exactly what it does is a mystery: unlike another famous iconoclast, Richard Stallman, Ted Nelson did not believe that “information wants to be free”. The nature of Xanadu’s enflilade, what it does, and how it is implemented is a mystery: everyone who has worked on the project has been sworn to secrecy.

In 1974, Nelson met programmer and hacker Roger Gregory. According to the article, if Nelson is the father of Xanadu, Roger Gregory is its mother. “Gregory had exactly the skills Nelson lacked: an intimate knowledge of hardware, a good amount of programming talent, and an obsessive interest in making machines work. […] through all the project’s painful deaths and rebirths, Gregory’s commitment to Nelson’s dream of a universal hypertext library never waned.” Gregory’s tale is a sad one: it’s difficult to see his involvement in Xanadu as anything other than a tragic waste of his life.

As the years go by and the 1970s become the 1980s, Nelson continued to work on Xanadu, and Xanadu continued not to be completed. By the late 1980s, the project team had dwindled and support for it was difficult to find. Nelson and Gregory would not admit failure, although Gregory struggled with thoughts of suicide. However, in 1988 Xanadu was rescued by John Walker, the founder of Autodesk. It seemed that Xanadu would at last have the benefit of serious commercial development. “In 1964,” Walker said in a 1988 press release, “Xanadu was a dream in a single mind. In 1980, it was the shared goal of a small group of brilliant technologists. By 1989, it will be a product. And by 1995, it will begin to change the world.”

It turned out that was easier said than done.

I find it interesting that one of the technical obstacles to Xanadu’s development was due to its profoundly non-free approach to the information it would make available.

The key to the Xanadu copyright and royalty scheme was that literal copying was forbidden in the Xanadu system. When a user wanted to quote a portion of document, that portion was transcluded. With fee for every reading.

Transclusion was extremely challenging to the programmers, for it meant that there could be no redundancy in the grand Xanadu library. Every text could exist only as an original.

In my opinion, this philosophy of restricting information is a key reason that Xanadu failed.

By the early 1990’s, control of the project shifted away from Gregory and the original development team, and all of the existing code was discarded. This also made Walker’s 18-month timeline explicitly unattainable.

John Walker, in retrospect, blames the failure of Xanadu on the unrealistic goals of the (new) development team.

John Walker, Xanadu’s most powerful protector, later wrote that during the Autodesk years, the Xanadu team had “hyper-warped into the techno-hubris zone.” Walker marveled at the programmers’ apparent belief that they could create “in its entirety, a system that can store all the information in every form, present and future, for quadrillions of individuals over billions of years.” Rather than push their product into the marketplace quickly, where it could compete, adapt, or die, the Xanadu programmers intended to produce their revolution ab initio.

“When this process fails,” wrote Walker in his collection of documents from and about Autodesk, “and it always does, that doesn’t seem to weaken the belief in a design process which, in reality, is as bogus as astrology. It’s always a bad manager, problems with tools, etc. – precisely the unpredictable factors which make a priori design impossible in the first place.”

In 1992, just before the release of Mosaic and the popularization of the World Wide Web, Autodesk crashed and burned, and the pipeline of funding that kept the Xanadu project going came to an end. Ownership of Xanadu reverted to Ted Nelson, Roger Gregory, and a few other long-time supporters.

A glint of hope appeared. Kinko’s (remember Kinko’s?) was interested in funding the project for their own use. But Nelson chose this time to attempt to seize control of the project. The programmers who had been subjected to Nelson’s attention-deficit management style resisted. Again, Nelson’s desire for control was destructive to the accomplishment of his dream. “By the time the battle was over, Kinko’s senior management had stopped returning phone calls, most of Autodesk’s transitional funding had been spent on lawyers fees, and the Xanadu team had managed to acquire ownership of a company that had no value.”

There was a brief respite from an insurance company, but that too soon ended in failure. After not being paid for six months, the last few developers took the hardware and quit. “With the computers gone, Xanadu was more than dead. It was dead and dismembered.”

As of 1995 (the date of the article), Nelson was in Japan, still pushing his idea of “transclusion”, still hostile to the very freedom and chaos that has made the World Wide Web the enormous success it is. I think he’s a perfect example of how someone can be both brilliant and utterly clueless.

In 2007, Project Xanadu released XanaduSpace 1.0. There is a video on YouTube of Ted Nelson demonstrating XanaduSpace. As far as I know, that was the end of the project.

Some other links that you might also find of interest:

http://xanadu.com/

http://xanadu.com.au/

http://www.wired.com/wired/archive/3.09/rants.html

http://www.xanadu.com.au/ararat

http://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/

http://web.archive.org/web/20090413174805/http://calliq.googlepages.com/”Xanadu Products Due Next Year”

https://archive.org/details/possiplexvideo

Thursday, 2012-03-22

It’s called Basecamp

Filed under: Programming — bblackmoor @ 22:44

What do you call a project management tool that doesn’t have any way to set task status, doesn’t have any way to set task prerequisites or dependencies, doesn’t have any form of time tracking, doesn’t have a way to set task priority, doesn’t have a way to move a task from one category to another, doesn’t have Gantt charts, and quite simply doesn’t have any of the fundamentally essential features of a project management system?

It’s called Basecamp. And they charge money for this garbage, believe it or not. Even more astonishing, people actually pay for it.

Next Page »