I realized today that it’s been ten years since I dedicated an entire post to complaining about enterprise software. In that ten years not much has changed, unfortunately. Enterprise software is still crap, and it’s still more of a hassle than it’s worth. It’s best to avoid whenever possible, so when you find yourself evaluating software or services for your company, here’s a few easy markers to identify the products you should let pass by.

1. Enterprise software doesn’t want to tell you how much it costs.
2. Enterprise software often doesn’t even list what it does, instead it want’s to partner with you to provide solutions.
3. Enterprise software doesn’t provide you technical documentation until after you’ve paid. And even then, it’s lacking.
4. Instead of real documentation, the marketing department of enterprise software vendors will write “whitepapers”, which are entirely useless.
5. The user-facing part of enterprise software is almost always complete garbage.

This last point is important because it gets to the crux of what enterprise software is: software wherein the person who pays for it is not the person who uses it. Payment for these solutions is handled by managers who are several steps removed from the daily process of having to put the software in place and use it as intended. What the managers need is a way to justify the exorbitant fees enterprise software vendors charge, so the vender’s sites are full of marketing jargon and various scenarios, hoping to inspire one manager to convince another manager that the price is worth it.

It’s not.

There’s almost always a better way to go about solving whatever problem an organization seeks out a vendor to solve. My personal preference is to solve it in house with open source software and custom development. That way, the money you would have spent on the garbage solution from an enterprise software vendor is spent investing in your own organization. Invest in yourself, solve your own problems, don’t compound your problems by buying someone else’s.

I bought my first Mac in 2004, a white plastic iBook G4. It was slow, the screen resolution was terrible, but wow did I love Mac OS X. After several years of loading every Linux and BSD variant I could find on the PC I bought in ‘99, I finally found a stable Unix-based operating system with a logical and beautiful user interface. The Mac was exactly what I wanted in a computer. I desperately wanted to use it at work, but working in a secure military environment, that wasn’t going to happen.

After I got out of the Navy in ‘06 I got my first civilian job on a six-month contract in Iowa. I was issued another PC, but after poking around a bit I found an old Mac that wasn’t being used, so I adopted it made it work for me. One of the lead engineers saw it once and made the off-hand comment that I should “get that piece of crap off my desk”. I ignored him and carried on. My coworkers were having a LAN party one day after work, and invited me along to play some networked game. I brought my personal MacBook with me, and quickly realized that everyone else had custom built gaming PCs, and that my little laptop couldn’t keep up.

When I found stable employment in Des Moines, I was, again, issued a PC. A Dell laptop this time. Again I found an unused Mac in a closet somewhere, a PowerMac G4, booted it up and used it as my main workstation. After a few years, and knowing my boundaries, I found it possible to work under the radar and bring my personal Mac to work, by now a MacBook Pro, and typically just dropped the Dell in a drawer. From time to time there’d be something I’d need to do with the Dell, and it’d wind up back on my desk for a bit. I remember once a coworker, who would eventually be promoted to my manager, walking by my cubicle and mocking me loudly saying “typical Mac user, Mac in front of him, PC on the side to get real work done.” I didn’t like that guy.

Over the years Macs have become more mainstream and I’ve noticed that they’ve become more accepted at the different places I’ve worked. One thing seems to not change though, whoever is in charge of taking care of employee’s computers always wants Windows PCs. I imagine because they are easier to manage en masse. Even at my latest company meeting, the team was discussing some feature rollout to the PCs, and it came up that I used a Mac¹. I quipped that I was pretty sure that by now my using a Mac is a condition of my continued employment. (It’s not.) I further quipped that they could have my Mac… when they pried it from my cold, dead hand.

For my entire working life outside the military, I’ve been the outlier who uses a Mac. By now I’ve been using it exclusively for so many years that I’d be completely lost in Windows. The Mac has a carefully chosen set of tools that mold perfectly to how my mind works. Things are where I expect them to be, they do what I expect them to do. As an information worker, I care deeply about the tools I use. I spend so much of my life using it, I want the experience to at least be somewhat enjoyable. I couldn’t imagine working anywhere that forced me to use a PC, if they did, I’d use it to start sending out my resume immediately.

Via a post I saw today from Chris Bowler, via a newsletter by Sarah Bray, discussing an article written by James Somers, wherein he describes the writing process of John McPhee¹, and how he uses a good dictionary to go from last draft to finished work. The emphasis here is on a good dictionary, namely the 1913 Webster’s Unabridged. I won’t attempt to describe how wonderful the dictionary is here, James did a fantastic job of that on his blog five years ago. I will however say that I think his installation instructions for getting the dictionary usable on your Mac are out of date. Here’s the easy way to do it.

First, download the compiled dictionary text. I downloaded it from a GitHub account, but who knows for how long that’ll be available, so I’m hosting the download here². Webster.s.1913.dictionary.zip

Next, unzip the downloaded file and find the file named “Webster’s 1913.dictionary”. Click on the Finder’s “Go” menu and hold down the ⌥Option key to show the hidden “Library” folder. Click on Library, and find the “Dictionaries” folder. Open it, and drag and drop the new dictionary folder into it.

Now when you open the macOS Dictionary app, you can go into the settings (either by pressing ⌘, or by clicking on “Dictionary” then “Preferences…” in the menu bar), scroll down a bit till you find “Webster’s 1913”, click the check box next to it and drag it to the top of the list. Uncheck the “New Oxford American Dictionary”. Now when you click on a word in a good Mac app, then click just a tad bit harder³, you’ll get the definition from the new and improved Webster’s. It’ll also show up in Spotlight searches, and anywhere else the system-wide dictionary is used.

Now you have a far richer and more useful dictionary. A useful resource if you happen to currently be, or soon will be, a college student who needs to write often, and in volume.

“We are all stories in the end, just make it a good one eh?”

Christians, shaman, poets, and authors all know one thing… what we believe shapes who we are, and the stories we tell ourselves shape those beliefs. Our lives are a self-fulfilling prophecy. We become who we believe we will become, because we take actions that are logically attuned to the story we’ve told ourselves about our life. Storytellers hold power, not because of wealth or authority, but because the stories they tell shape our understanding of the world around us. In turn, how we understand the world and our place in it guides our decisions and shapes our world to be more like what we believe it to be.

I believe this will be the last I muck about with the design of the site for the foreseeable future. After being disappointed by the available themes, and further disappointed by my own design ability, I went back to basics. And by basics I mean that I found a few sites that I like the look of and copied large chunks of HTML and CSS to build a custom Jekyll theme.

Readers of Brent Simmons’ Inessential site will probably recognize the fonts and general layout. I’ve added navigation at the top, minimized the layout to bare HTML5 tags, and setup some color here and there. I’ve also set up a bit of responsiveness for media, and syntax highlighting for code blocks. My hope is that this will be a good baseline for any future work I put into the site, but attribution must be made first.

I enjoy the simplicity of the design, and how clean and readable it is now. I especially like that there is no Javascript in use. Nothing but pure HTML and CSS. No tracking, no stats, nothing dynamic or fancy. It’s just you, me, and the text.

PS. Brent was kind enough to give his blessing to the new design, for which I’m greatly appreciative.

I spent some time over the past couple nights adopting a new theme for the old digs here at jb. I found the beautiful Chalk theme by Nielsen Ramon and adopted my site to use it, including, finally, a working tags system. I’m quite happy with the tags, but I’m less happy with the bundled deployment system the theme shipped with.

The theme depended on NodeJS to build and deploy to GitHub for reasons that I’m sure made complete sense to the developer but I simply don’t care about. The documentation says to run npm run publish to build and push the site, doing so runs a script that does quite a bit of mucking about with the structure of the site.

# Checkout gh-pages branch.
if [ `git branch | grep gh-pages` ]
then
  git branch -D gh-pages
fi
git checkout -b gh-pages

First thing we do is create a new branch and check it out. So far so good, I guess.

# Build site.
yarn install --modules-folder ./_assets/yarn
bundle exec jekyll build

I’m not familier with yarn, but the site says that it provides “fast, reliable, and secure dependency management”. Ok, fair enough, but what dependencies could my little blog possibly have? Apparently, the package.json file it lists what yarn is downloading:

  "dependencies": {
    "jquery": "^3.2.1",
    "npm": "^6.0.1",
    "retinajs": "^2.1.1",
    "svgxuse": "^1.2.4",
    "webfontloader": "^1.6.28",
    "zooming": "^2.0.0"
  }

Eh… ok. Why do I need NodeJS for this again? So, Yarn installs a bunch of Javascript and then Jekyll builds the site. Moving on…

# Delete and move files.
find . -maxdepth 1 ! -name '_site' ! -name '.git' ! -name '.gitignore' -exec rm -rf {} \;
mv _site/* .
rm -R _site/

Now things are getting interesting. This deletes everything except the git directory, the .gitignore file, and the site Jekyll just built. Then it moves everything out of the _site directory into the root and deletes that directory as well.

# Push to gh-pages.
git add -fA
git commit --allow-empty -m "$(git log -1 --pretty=%B) [ci skip]"
git push -f -q origin gh-pages

# Move back to previous branch.
git checkout -
yarn install --modules-folder ./_assets/yarn

Add, commit, and push the changes to Github under the gh-pages branch, then checkout whatever you had previously and reinstall all the javascript. When I tried this my site went offline. I think this script might be out of date. GitHub requires sites that won’t build in Jekyll to be in the master branch, and if you want to use a custom domain name you have to add a CNAME file with the domain name you want to use.

To work around this I setup a separate repository just for the source of the site and moved the built site into the master branch of the main repository. But, when I pulled everything down on my MacBook, the site wouldn’t compile, with Jekyll complaining about not being able to find Jquery. It was at this point I knew that I had gone down a terrible rabbit hole.

Luckily, I was able to get the site built once, so I had all the “compiled” code to work with. All I needed to do was use those files to build my own Jekyll theme with static assets and none of this Javascript build nonesene. Apparently the original theme was trying to do something fancy with the assets by dynamically renaming them and adding assets selectively to the compiled site. I don’t care about any of that.

Jekyll uses the liquid templating system, so it’s trivial to go through the site and add tags to pull in the content you need during build time. Using the theme as shipped caused me to need three different package managers to build a static site. That’s just not right. What’s so wrong with HTML, CSS, and just a little bit of Javascript?

I don’t know Nielsen, and I’m sure he had good reasons to build the theme like he did. I do think it’s beautiful and I’m thankful that he released it as open source so I could use it. For me though, I don’t need all those layers in my life. I just want an easy way to write and publish my site, and have it look and feel like something I care to have my name on.

It used to be you could learn how to build a web site by right-clicking and selecting “view source”. But now, everything easy is hard again.

It seems undeniable that, given an infinite timescale, Apple will eventually simplify their two most popular systems into a single platform. Merging MacOS and iOS would, theoretically anyway, provide the users with the best of both worlds, and developers would finally have a single platform to target instead of two. This concept seems to run counter to what Apple executives have said in the past about the Mac, specifically that “the Mac keeps going forever”, but the interview that statement comes from is five years old now, which… in silicon valley terms, really is forever ago.

Since then we’ve seen some interesting ideas come to market, like Microsoft’s Surface Studio, a desktop computer with a 27” 4k touchscreen and stylus , and an odd dial that can sit either on the desk or directly on the screen. Samsung is hooking their Galaxy phones up to a keyboard, monitor, and mouse to use the phone as a desktop computer through the DeX dock. Outside of Apple, touchscreens on mobile computers are nearly ubiquitous, from Windows 10 PCs to convertible Chromebooks. Inside of Apple though, we’ve seen almost no crossing of the streams… almost.

The iPad Pro is a computer unlike any other. Incredibly powerful, but hamstrung by limited software and user interaction capabilities. Geek Bench scores are impressive, but you can’t hook up a thumb drive. It looks like a good device for free-form drawing and artistic work, but outside of basic static sties you can’t use it for web development. More than anything, iOS’s reimagining of an operating system for the modern, mobile world eschews decades of proven user experience work that’s gone into the MacOS user interface. MacOS is consistent, discoverable, and reliable. A good Mac app behaves similarly to the other apps that run on the Mac. Copy & paste, undo & redo, and standard keyboard shortcuts function the same across well-designed 3rd party apps and Apple’s own bundled apps. At least they did, until Mojave.

Mojave introduced four new bundled applications to the Mac. Home, News, Stocks, & Voice Memos were ported directly over from iOS using an as-yet-unnamed unified development framework popularly referred to as Marzipan. Apparently the framework is only half-baked, because the apps themselves do not at all act like they belong on the platform. Keyboard shortcuts are missing, UI elements are entirely out of place, it’s a mess. On a recent episode of The Talk Show, Jason Snell and John Gruber discuss the future of these apps, and Snell suggests that what makes a “Mac app” might be changing to meld around what these new iOS apps on the Mac become once the framework is more stable. Niether Jason nor John are slouches when it comes to discussing the Mac, but in this particular case I think Jason is wrong.

What makes a good Mac app is not an indiscernable feel or look to the application. A good Mac app behaves the way that the Mac has taught people to expect applications to behave since 1984. That’s how an application looks and feels like it belongs on the Mac, when things are where they are expected to be, and the application responds as expected when the user interacts with it. If Apple wants to bring iOS apps to the Mac, I certainly hope they have more in store than this. These iOS apps are going to have to learn to behave how the users of the platform expect them to behave, not the other way around.

In many ways, I think Apple found themselves at this crossroads almost on accident. In fact, I think the “macification” of the iPad is to its detriment. iOS was never meant to be used the way the iPad Pro is advertised. Features like multitasking and windowing seem like they were wedged into the OS when Apple found themselves with a less popular platform than they’d hoped. Apple thought that the iPad was the future of computing… what if they’re wrong?

Apple stubbornly wants the iPad to be the future of computing, so they’ve been focusing on making it more capable for power users, adding more and more hardware power and confusing the pure simplicity of iOS with undiscoverable features and unfulfilled promises. What if, in the next couple years, Apple decides to right the ship and build a truly good MacBook/iOS hybrid?

What about an ARM mac with a detachable touchscreen? Or one that folds over on itself? What if Apple learned all the best lessons from Microsoft’s experiments with their Surface lineup and did it right with the Mac? What about an iMac you can draw on? I’d love to be able to create my OmniGraffle drawings on my Mac with a huge canvas and an Apple Pencil. I’d love to be able to use touch on my Mac to interact with the UI when appropriate, and use the trackpad and keyboard when not. Let the Mac grow the way the users actually want it to grow and let the iPad go back to being just the best tablet on the market. Apple could simplify iOS again, and concentrate on making the Mac the best tool for getting things done.

I’ve never been 100% happy with this site. On the one hand, Jekyll lets me have full control of my content, and I never have to worry about losing any of it or having anything locked inside a database on a server somewhere. On the other hand, things like adding media is more complicated than I’d like. I’ve written scripts to help, of course, but I’d really rather have the best of both worlds.

I’ve considered creating an application to manage this for me. Like MarsEdit for Jekyll and GitHub Pages. A text editor with a git client and an understanding of Jekyll site structure. It could even let the user sign up for GitHub and setup the repository. I thought I might setup my old Paragraphs app to do this for me… I could tear out the site rendering code and replace it with a wrapper around a libgit2. But, the text editor in Paragraphs needs a lot of work, and there would be multiple parts of the app that would need considerable rework to get it to an even barely functional state. The other option would be to create a new app from scratch, but at this point if you aren’t creating an iOS app in Swift when starting anew what are you even doing with your life? Problem is I don’t know either Swift or iOS development. My skills in this area are basically outdated.

A search for “Jekyll” in the Mac App Store finds one result, for a “markup viewer” app with dubious usefulness. A quick Duck search finds a couple people with the same idea, one that setup a web GUI, which is not at all what I’m talking about, and one that started something five years ago and never finished it. From what I can tell, the app that I want doesn’t exist. Too bad Ulysses and IA Writer added support for Medium into their apps instead of GitHub pages.

So should I build this app or not? It’s basically a text editor that you can drop media on, hit publish, and have it push the site to GitHub. The same thing I have now, but automated, simple, and beautiful. Is there a market for this style of app? Would GitHub allow it? Could I learn the skills required to create it in a reasonable time? iOS development is supposed to be easier than macOS… but I’m not sure that applies when you’re carrying so much baggage around from the old style of development.

In the end, I’m not sure it’d be worth the effort for me. I’ve already got a beautiful text editor, and my scripts and workflows make it simple for me to create and publish new posts. I think I’ve talked myself out of building this app myself, but darned if I wouldn’t love for someone else to build it.

The recent hubbub about Apple’s earnings guidance has “analysts” and pundits talking a lot about China and the global economic situation. I’m sure there’s something to all that, but my take is simpler… the new iPhones are priced too high.

I’m not ready to spend a thousand bucks on a new phone, even though the X-series looks very nice. I’ve talked to several other people who feel the same way I do, one just this morning, even though we are both still running the 6S. Personally, at this price, I’ll keep running my phone till it doesn’t work anymore.

Of course, if Apple came out with a real successor to the iPhone SE, maybe an X-series SE at a similar price point as the previous SE, I’d be very interested in that. But, we’ll see how the next year or so plays out.

CPG Gray and Myke Hurley have been talking about assigning a theme to a year on their Cortex podcast, in lieu of new year’s resolutions. I quite like this idea, and I’ve decided to adopt it. I’ve decided that my personal theme for 2019 is finishing.

Over the years I’ve started, made significant progress, and then dropped several projects once they got to a state I considered “good enough”. I care about the projects too much to drop them completely, but I’ve lacked the motivation to drive them the final mile to completion.

I’ve waffled a bit on adopting this theme because there is something to be said for leaving things behind that don’t work, but after considering it for a while it actually fits perfectly. It’s time to make a decision. This year, I’ll either finish the project, or leave it behind forever.

So, what kind of projects?

• This site
• My old Mac apps
• The NaNoWriMo Manuscript
• Basement living spaces (trim, new carpet, etc…)
• Landscaping
• Running a marathon

A lot of this falls under the heading of “one of these days…”; adopting finishing as my theme of the year is mentally preparing myself for the fact that the day has come. Posting here is just further motivation not to publicly embarrass myself by not following through. This time next year, we’ll see how much I was actually able to get done, and what got left behind.