MacBook, defective by design banner

Put the knife down and take a green herb, dude.


One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for

Using 89% of the same design the blog had in 2001.

Back-up your data and, when you bike, always wear white.

MarkUpDown is the best Markdown editor for professionals on Windows 10.

It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support.

Features you won't find anywhere else include...

You've wasted more than $15 of your time looking for a great Markdown editor.

Stop looking. MarkUpDown is the app you're looking for.

Learn more or head over to the 'Store now!

Thursday, September 14, 2017

Are these popover page previews on Wikipedia new? I got some checking out a discussion on Mike & Mike [sic], but didn't see them on other pages, and now they're gone on the original too.

They're pretty neat. A little intrusive at times, and seems a lot like what macOS does with Safari previews. But certainly easier to manage than the web of wikipedia tabs I usually end up opening during a research rabbit hole.


posted by ruffin at 9/14/2017 09:27:00 AM
Thursday, August 24, 2017

From Video purports to show testing of Apple 'iPhone 8' with rear-mounted Touch ID:

A video published on Tuesday allegedly shows Apple's "iPhone 8" in quality control testing —with a rear-mounted Touch ID sensor, despite most recent rumors discounting that possibility.

Picture from AppleInsider video of Touch ID on back of iPhone

If you've been watching the rumor mills this year, you'd know Apple's had this option of last resort in their back pocket for a long time. What's important to learn is how much otherwise risky innovation this sort of back-up planning enables.

And if you have been not just watching, but watching closely, you've seen a pretty interesting narrative grow around this year's iPhone rumors. I actually do believe Apple was, until the last moment, trying to embed Touch ID in the screen. I'd also buy the rumor that at least one team at Apple was sweating bricks, worried the in-screen Touch ID was going to get the cut, and were scurrying to get it to work at scale.

The reason they could wait until the last minute was precisely because they had Touch ID on the back of the phone ready to go. If the only other option they were left with was retina scanning, Apple Pay could've been in trouble. Can you imagine if iRetinaScan 1.0 had a flaw? Now what happens to Apple Pay for those who shelled out for your latest phone? Do they simply lose access to Apple Pay, now that you couldn't keep it secure? If you thought AntennaGate was a big deal, wait until Retina-Apple-Pay-Gate.

I'm not saying Apple is excited about back of the phone Touch ID (if it's really going to be used -- I suppose even if this video is legit, Apple could spin up a few mock lines without releasing that design), but it's better than nothing. Now you can include retina scan as the primary access point but not bet the farm on it working.

I've been letting an idea for a post stew for a while about how Apple has been remaking hardware to fit in previously designed shells. The original iMac is a good example, as it went through a number of iterations before the shell changed.

Starting with the latest iPod touch refresh, however, I think we hit a new gear with hardware design. And with the iPhone 7S or 8 or whatever it'll become, now we're no longer putting, say, last generation's innards into a previously released case, but ensuring that we can use either option 1 or option 2 with the next generation's shell. We saw, for example, two winners in the latest MacBook Pro. The touch bar MacBook Pro and the MacBook Pro Escape are two completely different animals, as I mentioned last December. Who knows how many other designs were created for the same basic aluminum laptop that didn't get chosen.

My budding claim is that Apple's MO is now to finish the outer shell well before a final decision has been made on what precisely is going inside. And to swap the choice on insides at the last minute is no longer a big deal, giving Apple lots more room to experiment within a generation.

These different design needs are, to steal from Rumsfeld again, known unknowns. If you know you're down to 5 either-or decisions for insides, you can build an exterior that anticipates every combination of them. If there's no back of the phone Touch ID, there's probably a tiny bit of space between the silicon and case that goes unused, or is now used by a battery with a slightly different design. If there is a back of the phone Touch ID, the changes to the rest of the hardware aren't just minimal, they're already completely anticipated.

I'm going to bet this sort of "planning for known unknowns" is exactly what Apple's doing, and doing better than anyone.

Labels: , , ,

posted by ruffin at 8/24/2017 07:11:00 PM
Tuesday, August 15, 2017

Ran into this question about diffing blocks of text on StackOverflow yesterday after KDiff3 and WinMerge both went crazy trying to diff a file where I'd simply mostly just grouped and, therefore, rearranged lots of methods. Seems like an easy issue, but as that question points out...

Is there a diff-like algorithm that handles moving block of lines? - Stack Overflow:

But it falls down when blocks of text are moved within the file.

Suppose you have the following two files, a.txt and b.txt (imagine that they're both hundreds of lines long rather than just 6):

a.txt   b.txt
-----   -----
1       4
2       5
3       6
4       1
5       2
6       3

diff a.txt b.txt shows this:

$ diff a.txt b.txt 
< 1
< 2
< 3
> 1
> 2
> 3

That really is painful, when it should be a reasonably easy process.

Now I've tried to write my own diff engine before in my usual bullheaded, straight-ahead style, not worrying about efficiency until after something's working. It's not easy. But what you can say is that if you take it as your primary mission to find block movements, it's a lot easier. Enter wikEd diff Online Tool - Cacycle, "The Only JavaScript Diff Library for Visual Inline Text Comparisons With Block Move Highlighting and Character/Word-Based Resolution".

Results are pretty good, both for the simplest case from the SO question, to real-world code.

wikEd example using example from SO question

(The green highlight is for grouping a block, but by default it ignores/doesn't highlight any moved blocks, which is nice when you're diffing code like I mentioned before...)

Now I have to resist the desire to put this into a full-fledged UWP app whose goal is to be a diff tool. There are smarter things to write on my own time. Please realize this, self.

Labels: , ,

posted by ruffin at 8/15/2017 10:02:00 AM
Sunday, July 30, 2017

There's a reason John Gruber's initial spec for Markdown didn't approach the level of complexity the CommonMark people wanted: You end up with exceptionally wordy jive like what we find for list items.


And let M be the marker 1., and N = 2. Then rule #1 says that the following is an ordered list item with start number 1, and the same contents as Ls:

[example removed -mfn]

The most important thing to notice is that the position of the text after the list marker determines how much indentation is needed in subsequent blocks in the list item. If the list marker takes up two spaces, and there are three spaces between the list marker and the next non-whitespace character, then blocks must be indented five spaces in order to fall under the list item.

Phew. That was fun, wasn't it?

I was in the CommonMark spec today for two reasons. First, I fairly recently (well, months ago) swapped my main Markdown engine to the .NET CommonMark renderer (don't worry; table support and other features are done outside of CommonMark). Second, I wanted to know why only two of the following were creating nested lists, though my old renderer would create nested lists from all three.

1. Testing ye olde bullet points
    2. Still testing
    3. Testing

1. Testing ye olde bullet points
    * Still testing
    * Testing

1. Testing ye olde bullet points
    1. Still Testing
    2. Testing

Curious? You've probably guessed, but here's the rendered HTML, first as HTML, then the HTML source.

  1. Testing ye olde bullet points 2. Still testing 3. Testing
  1. Testing ye olde bullet points
    • Still testing
    • Testing
  1. Testing ye olde bullet points
    1. Still Testing
    2. Testing
<li>Testing ye olde bullet points
2. Still testing
3. Testing</li>
<li>Testing ye olde bullet points
<li>Still testing</li>
<li>Testing ye olde bullet points
<li>Still Testing</li>

See what happened there? If your nested list starts with a 2., as in the first example, though that'd be a bulleted list without the nest...

2. See? It's still...
4. a list.
  1. See? It's still...
  2. a list.

... it's not when nested.

Note that CommonMark is paying attention to the starting number of your ordered list. See how the list, above, starts with 2., though the next bullet is a 3., even though I used 4. in the raw Markdown?

Why is the nesting ignored in the first example? The spec tells us:


Since it is well established Markdown practice to allow lists to interrupt paragraphs inside list items, the principle of uniformity requires us to allow this outside list items as well. (reStructuredText takes a different approach, requiring blank lines before lists even inside other list items.)

In order to solve of unwanted lists in paragraphs with hard-wrapped numerals, we allow only lists starting with 1 to interrupt paragraphs. Thus,

The number of windows in my house is
14.  The number of doors is 6.
<p>The number of windows in my house is
14.  The number of doors is 6.</p>

We may still get an unintended result in cases like

The number of windows in my house is
1.  The number of doors is 6.
<p>The number of windows in my house is</p>
<li>The number of doors is 6.</li>

but this rule should prevent most spurious list captures. [emphasis mine -mfn]

Make sense? 1. is special. If your nest doesn't start with 1., CommonMark thinks you're in the same "paragraph", give or take. You're not going to get that nest.

Which means MarkUpDown needs to capture when someone has a bullet from a numbered list, hits return, gets the next number automatically inserted...

1. They enter this first bullet.
2. Hit return and get a two. Then hit tab...

... which leaves them with...

1. They enter this first bullet.
    2. Hit return and get a two. Then hit tab...

... which doesn't render as a nested list. What they likely want is...

1. They enter this first bullet.
    1. Hit return and get a two. Then hit tab...

I'd hoped to get in automatic renumbering of ordered lists anyhow, but we'll start with this simpler change first... if it looks nested, we're going to reset the number to 1.

I realize this is a pretty boring post if you're not a Markdown aficionado. I've got some more interesting drafts around here somewhars. I'll try to find time to post them, but this one bugged me enough to write up.

Labels: , ,

posted by ruffin at 7/30/2017 10:36:00 PM
Friday, July 14, 2017

From AppleInsider, reporting on a Wall Street Journal article:

Citing Hollywood studio sources, The Wall Street Journal on Sunday said Apple's share for selling and renting movies, as well as other video content, has dropped to between 20 percent and 35 percent, down from over 50 percent as recently as 2012.

The steep decline comes as competitors Amazon and Comcast enjoy market share gains on the back of aggressive industry moves.


Interestingly, the loss of market share is not uniform across genres, the report said. For example, iTunes is a top distributor of independent movies, as Apple promotes and signs exclusive deals for films made outside of the traditional movie studio system, sources said.

Anyone who is surprised by this, raise their hand.

The more interesting question is why Apple cares. I understand they've successfully made the transistion from selling DRM'd media files to selling streaming subscriptions with music. But what's different between music and video?

Apple doesn't make music. They sell subscriptions to listen to everyone's music, not music they produce. I realize they tried to become a cable provider and didn't quite make it, but this Netflix approach they're trying with Planet of the Apps? I'm not a huge fan. Signing independent movies might be a smart move, but why even bother with video subscriptions? What does Apple really want to look like in 15 years?

Apple doesn't tend to have its finger on the pulse of what's popular. I think back to the proverbially skeuomorphic iOSes before 7. And Ping. There's nothing about Apple that says they're great at following the wave. They were fortunate enough to get in front of the wave thrice, but they've never caught one.

I wish they'd stop trying.

Labels: , ,

posted by ruffin at 7/14/2017 11:18:00 PM
Friday, May 05, 2017

JavaScript transpilation is a neat trick, but in practice you may seem to simply trade one multifaceted, shifting platform -- what works crossbrowser -- for another -- here, a set of constantly changing hipster libraries.

There are simple solutions to the shifting , each with one major flaw:

  • Target a "lowest common denominator" or "limiting reagent" browser (ie, IE[x]) with "native" JavaScript.
    • This stinks because even IE11's tools are much worse than Chrome's DevTools.
    • Yet if you don't live in your "worst" browser, you're going to miss issues. No, you are. Every time.
  • Pick one set of transpiled technologies & practices, and, within reason, stop.
    • You're still going to have to test in browsers
    • You'll still be responsible for debugging third-party code.
    • You'll disappoint your hipster programmers.

Interpreted incorrectly, transpilation gives the impression that you're developing for an environment like a server: a controlled, homogenous system. You're not. It's not node. And I've yet to see a practical advantage beyond very specific, situated uses -- JSX compilation for React, for example -- provided transpilation. It's all still very familiar zeroes and ones.

Labels: , , ,

posted by ruffin at 5/05/2017 09:48:00 AM
Saturday, March 25, 2017

From The Guilty Secret of Distracted Parenting:

And [my children] might point out that when we did sit down, I surreptitiously read the newspaper at the breakfast table. And I pulled a book out of my bag at the playground if I thought I could get away with it. Speaking of old technologies, at our day care center there was one father — a big-shot professor — who was so brave that he did the worktime while wearing his Walkman (remember those?).

And for that matter, may I call as my witness Abraham Lincoln, who is reported to have walked up and down the street in Springfield, Ill., in the mid-1800s, pulling his young sons in a wagon while reading a book (and as the story goes, he went right on reading when a child fell out of the wagon).

I tweeted about a parent I overhead a few weeks back with the gall to tell their give-or-take six year-old, "When I'm on my phone, you DO NOT do that!" We are more distracted as a society, but I enjoy the way this NY Times piece reminds us it's not like this is a new thing. I used to always carry around a paperback until, well, until I could carry the books around even more conveniently on my phone.

What's more important to realize, perhaps, is just how many "distractions" of the 80s (and before) aren't considered distractions today. Talking to someone else, regarding the birds flying, checking out cars on the street... the things we used to do to give our brains a break before would often be considered contemplative and "authentic" engagments today.

Why is that? I think there's some small part of the distinction that's linked to feeling "productive". Phone distractions are measurable. Your digital distractions have metrics. Children, birds, conversations are all unique experiences. You can't, much as Instagram & Facebook tries, share breakfast with others with your network online, not really, not, to borrow a term, losslessly. Distractions that aren't swipeable are in a newly reconfigured set of experiences of unmeasurables.

We no longer value the unmeasurable enough. Before, the unmeasurables were valid pursuits on their own merits. We only had to justify their value to ourselves. Now, unable to "share" them fully as digital copies (and have their worth rubber-stamped by our virtual selves), we undervalue them -- while at the same time lamenting their loss as we search for a new term that could reinvigorate their value in a society no longer predisposed to appreciate them.

I should go to sleep. ;^)

Labels: ,

posted by ruffin at 3/25/2017 01:52:00 AM

Support freedom
All posts can be accessed here:

Just the last year o' posts:

URLs I want to remember:
* Atari 2600 programming on your Mac
* joel on software (tip pt)
* Professional links: resume, github, paltry StackOverflow * Regular Expression Introduction (copy)
* The hex editor whose name I forget
* JSONLint to pretty-ify JSON
* Using CommonDialog in VB 6 * Free zip utils
* git repo mapped drive setup * Regex Tester
* Read the bits about the zone * Find column in sql server db by name
* Giant ASCII Textifier in Stick Figures (in Ivrit) * Quick intro to Javascript
* Don't [over-]sweat "micro-optimization" * Parsing str's in VB6
* .ToString("yyyy-MM-dd HH:mm:ss.fff", CultureInfo.InvariantCulture); (src) * Break on a Lenovo T430: Fn+Alt+B
email if ya gotta, RSS if ya wanna RSS, (◔_◔), ¢, & Δ if you're keypadless

Powered by Blogger Curmudgeon Gamer badge
The postings on this site are [usually] my own and do not necessarily reflect the views of any employer, past or present, or other entity.