MacBook, defective by design banner
Back-up your data and, when you bike, always wear white.

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

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!

Monday, January 16, 2017

One of the interesting things about the MLK, Jr. spread on the Apple front page?

Apple's tribute to MLK, Jr.

The markup.

<article id="mlk-takeover" class="gallery-container" data-analytics-region="hero">
  <figure class="mlk-hero">
   <div class="mlk-image"></div>
   <div class="slide-content">
   <div class="copy-inner">
    <h1 class="quote">“Commit yourself to the noble struggle for equal rights. You will make a greater person of yourself, a greater nation of your country, and a finer world to live in.”</h1>
    <span class="credit">Dr. Martin Luther King Jr.</span>

I wonder who else has had an data-analytics-region of "hero"?

Labels: ,

posted by ruffin at 1/16/2017 12:00:00 PM
Friday, January 13, 2017

Amazon EBS claims five nines. I'm not sure how you convert AFR to uptime (you can't, I think is the quick answer), but it's interesting to think about how long it takes to come back from a busted drive. And 4% seems low. Guess that's if they're in striped RAIDs and rotated out pretty regularly.

I've got giant folders called "AppsToInstall", one in DropBox (Mac) and in OneDrive (Windows) that makes it a lot quicker to go from hd death to coding, and most of my stuff is in some git repo in the cloud somewhere, but it's still more time than I should spend. Backups for home boxen are under-utilized.


posted by ruffin at 1/13/2017 03:07:00 PM
Tuesday, January 10, 2017

I've been listening to and reading from a number of reviews about the Apple AirPods, and they all seem pretty similar. The things are very well made, and do exactly what they're supposed to do.

But there are three recurring problems:

  1. The first everyone admits is a problem: There aren't good controls. Siri isn't a good enough stand-in for the lost volume and skip buttons.
  2. It seems like many are trying to talk themselves out of the second problem's mattering: Battery life could be better. That dental floss case is neat, but it's a hack at best. I realize AirPods are insanely small. That's cool, but battery life still stinks.
  3. The third is that, though AirPods apparently fall out of your ear less than the old wired EarPods, they do fall out: And, often elided, when they do fall out, BAM, they're on the ground.


I have dropped the buds a few times (one onto a subway platform, which was frightening, to say the least)...

Eeeeew. That's gross. You're putting it into your ear, man. ;^)

It seems there's a pretty obvious answer. From

You’ll be happy to know that the Beats Solo 3 features on board controls for music playback, volume, and Siri invocation. The left ear cup features all of the needed controls, along with a microphone for sending commands to Siri.

Guess what else?

Then there’s the 40 hours of battery life, 3 hours of battery life from a 5 minute charge, and that glorious long range connectivity. Lastly, the on board music and volume controls, Siri controls, and the ability to use these headphones like normal wired headphones is a definite win.

About the only negatives I've heard about the Solo3 is that 1.) They're big, and 2.) They're too bassy.

I like 1.). Big is good. I usually carry a pair of Hesh 2's, which I know most think are pretty crappy, but they're a lot better than what I used to tote around. They're about the same size as the Solo3. I put them into my bag's handle when I'm using the shoulder strap and take off.

The second, that the Solo3 is too bassy, makes me suspicious folks are trying to be audiophiles. I mean, it depends on the music you want to listen to, of course, but I bet there are a fair number of folk who are listening to pretty bass-friendly tracks via "neutral" headphones, and suffering for it.

Oh yeah, and though the Solo3 is $300 from Apple, guess what? Amazon has 'em for $220. That's $60 more than AirPods, but we're getting close.

airpods with blurb about mics

In fact I bet the biggest reason why you should prefer AirPods is that the fancy mics are head and shoulders above the one on the Solo3. But I haven't heard that many laud the mic. Maybe we're not making that many calls with headphones in?

In any event, I ran down to the Apple Store and tried the Solo3. They were paired to an iPod touch, but it was easy enough to unpair and use the W1 to magically pair to my iPhone. (It really was as easy as advertised to pair them up.) I played some Black Crowes. Not too shabby.

Then I tried some Metric -- you know, serious techno-pop. HEL-lo. The bass sounded great. Seriously, it blows (not surprisingly) my [corded] Heshes' away. The sound reminded me of when I've got the stereo blasting pretty loudly at home, EQ towards the bassy bias I tend to prefer.

So you might not like that "sound signature", but if you do... these things are freaking incredible for electro-dance/pop/EBM music. Nice. So let's cut out the audiophile complaint. At worst, it's not a blanket complaint. These give some nice sound. As The Verge says:


Yes, they used all caps. Yes, when I'm programming, that's what I'm listening to.

I'll still give the Solo3s a ding for still being $60 more than the AirPods, even "IRL", and a similar price as some pretty well-made headphones, which these plastic-y beasts apparently aren't, but the only other serious flaw I see (other than wondering about mic quality) is this one, also from

If you’re keeping track at home, charging Apple’s range of new 2016 products requires: a Lightning connector for the iPhone 7, a USB-C plug for the MacBook Pro, and a MicroUSB cable for the Beats Solo 3s. Top marks to Apple for not making me miss the wired connection for conveying sound, but that should have carried over to a more unified setup with charging cables too.


Labels: , ,

posted by ruffin at 1/10/2017 11:24:00 PM
Wednesday, January 04, 2017

Why isn't "Flash on Silent" working like you expected if you're using "LED Flash for Alerts" in the iPhone's Accessibility settings?

It's because you're coming at it backwards.

What iOS Flash on Silent really means

It's not "Flash on Silent [only]", which is useful for dopes that can hear.

It's "Flash on Silent [even though your switch is telling your phone to be quiet]"!

Make sense?

If you're deaf, the flash is the sound.

If you have your ringer switched to silent, there shouldn't be a flash. The sound is off.

If you set "Flash on Silent", your iPhone will "ring" even though it's supposed to be quiet.

That is to say, "Flash on Silent" is equivalent to a setting that'd say "Ring on Silent".

It also appears that setting "LED Flash for Alerts" off overrides the ability to flash on silent. That's too bad for hearing folk, where the flash only on silent would be awesome. You must have LED Flash for Alerts on for the Flash on Silent to have any effect (afaict).

I hope that makes more sense. Don't worry, everyone got this wrong coming at it from the land of the hearing enabled.


posted by ruffin at 1/04/2017 05:23:00 PM

Today, I ran across a clickbaitily titled post called Just Say No to More End-to-End Tests posted at the Google Testing Blog, written back on April 22, 2015, detailing a fictional end-to-end (e2e) testing run. The scenario was very clearly fictionalized, but you can forgive most of it, as they're simply trying to illustrate a few points.

Here's their "analysis" of the test, which apparently took over a week to complete and had some serious errors with the testing apparatus as well.

What Went Well 

  • Customer-impacting bugs were identified and fixed before they reached the customer.

What Went Wrong 

  • The team completed their coding milestone a week late (and worked a lot of overtime). 
  • Finding the root cause for a failing end-to-end test is painful and can take a long time. 
  • Partner failures and lab failures ruined the test results on multiple days. 
  • Many smaller bugs were hidden behind bigger bugs. 
  • End-to-end tests were flaky at times. 
  • Developers had to wait until the following day to know if a fix worked or not. 
Although end-to-end tests do a better job of simulating real user scenarios, this advantage quickly becomes outweighed by all the disadvantages of the end-to-end feedback loop:








Isolates Failures


Simulates a Real User


The author uses this cluster of an e2e test to argue for a preponderance of unit and integration tests...

Integration Tests

Unit tests do have one major disadvantage: even if the units work well in isolation, you do not know if they work well together. But even then, you do not necessarily need end-to-end tests. For that, you can use an integration test. An integration test takes a small group of units, often two units, and tests their behavior as a whole, verifying that they coherently work together.

Testing Pyramid

Even with both unit tests and integration tests, you probably still will want a small number of end-to-end tests to verify the system as a whole. To find the right balance between all three test types, the best visual aid to use is the testing pyramid. Here is a simplified version of the testing pyramid from the opening keynote of the 2014 Google Test Automation Conference:

As a good first guess, Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. The exact mix will be different for each team, but in general, it should retain that pyramid shape.

That's a lot of info to digest.

Here's the problem: "Simulates a Real User" isn't a single point. Their chart really isn't a scorecard, though that's how it's presented.

My quick list of critiques:

  1. How many jobs have given you permission to create good unit tests?
  2. Of those jobs, how many programmers actually created worthwhile, real-world, success & fail case tests?
  3. Of the two unit tests you have left from the filters of 1 & 2, how many jobs then also factored creating integration tests into your schedule?
  4. Did you use TDD? Because otherwise the tests you made in 1-3 are crap. No, honestly. No Scottishness at all.

Look, more typical situations in my experience are that you either have lip-service unit tests [only] or that you have no testing at all.

Guess what's most valuable if you have to pull teeth to convince management that testing is important? In my experience, it's an "end to end" test. You'll get the most return on your testing resource dollar with smoke tests.

I do like to call it a smoke test, and I've had pretty good results using Selenium to automate a browser using C#. Which browser? Well, you get your biggest bang for the buck by just using one. It'd be great to test in IE, Firefox, Edge, Chrome, and even macOS & iOS Safari, but each time is a diminishing return. The first test in whatever browser is going to catch 75% of what's wrong.

I recommend using either 1.) The lowest common denominator for browser functionality, usually IE, or 2.) Whatever's the easiest to get to behave for your tests. Timing can be a pain in Selenium.

Recently, I've used Selenium's Chrome web driver. That's dangerous. Chrome seems the most fault tolerant of the browsers, and on a developer's phat box, you can add slow downs to browser incompatibilities as problems that are often hard to notice.

But one browser, going through an automated master set of user stories, will quickly ensure that the 80% of your website that's your real bread and butter works and wasn't screwed up by whatever whizbang gizmo your latest release just pushed out the door.

If there is an error, sure, it can be hard to immediately identify the exact cause, which the Testing Blog seems to think is the end of the world. And perhaps a unit test to cover each error you do discover and track down will be useful. Do that.

But, again, unless you're doing TDD, to ask developers to write useful unit tests ahead of time almost never covers what your users are actually going to do and doesn't prevent bugs your own developers and QA are going to catch anyway. To get useful unit tests, you're going to have to spend even more time getting developers to code review others' unit tests, and you barely had time to green light unit tests to begin with. (How do I know that? If you had plenty of time, you'd be using TDD.)

And if you've gotten so far down the line that you can't tell if an error is coming from the front or back end, as in the Testing Blog's worst-case scenario, well, you have worse problems.

My suggestion if you're losing days looking for bugs your e2e tests turn up, and more days with your test lab going down?

Forget the users; your development process is broken. It's time to start arguing for TDD.

Update: Interesting to look at the slide linked in the quote, above:

Google Testing Cone Slide

And the notes address what I'm saying exactly (and argue against it):

Automated API tests are the best bang for the buck wrt tests that are easy to write and stable and a reliable signal. Integration Tests are always valuable; but we need to ration the number of integration tests one writes as they can be more difficult to debug and have a high noise factor due to all the moving pieces Automated component testing allows one to test a particular component (server) in isolation. you mock everything else out and ensure this component behaves as intended

As evident; the cone needs to be inverted in a lot of teams and companies. There is too much focus on Automated UI testing. At Google; we realized that half a decade back and have been putting in the required effort in the Integration testing and unit testing layer.

Interesting. I'm going to guess Google's coders do a much better job writing tests. If you want to convince me, talk more about how tests are written, and less about how they're better than automated UI testing if you have no testing now.

But wow, look at some later slides:

Push on Amber

  • Daily pushes to prod

  • Stable top of tree

  • Smarter regression testing

  • Critical tests cannot be bypassed

Comments to that slide:

In an ideal world; we should push on green; but we live in a practical world. I want baby carriers with beer holders; but they don’t make them. so I improvise and use my denim back pocket as my beer holder.

Not great. I've heard what's important when coding is to know which bugs to ship, but which bugs in tests to ignore? What are we doing? Later on...

How tests have become a nightmare. due to flakiness. stability.
I remember when I joined a team about 7 years back; I was excited; to be in server world @ Google. had been on client stuff before. When I asked around folks told me they had 1000s of end2end automated tests. I was like w00t! Turns out only 100s of them were providing real enough signal. some were flaky; some were broken forever.

EXACTLY. I think the Testing Blog grossing oversimplified the take-home from this fellow's presentation. I'll job bombarding pixels now.

Labels: , , , ,

posted by ruffin at 1/04/2017 01:23:00 PM
Monday, January 02, 2017

Argh. Fun day of setting up LocalDB.

First, you have to have it installed. Unfortunately, our friend is busted, and one of the more promising links from MSDN is busted too.

If I'm remembering correctly, the new location seems to be here:

But the real sticking point for me is that the default connection string for LocalDB from the Web App Template in Visual Studio 2015U3 -- at least if you've installed LocalDB from SQL Server Express 2016 -- doesn't work. The real pain was that I trusted the template, but SQL Server Management Studio was working with LocalDB just fine.

Here are the steps I used to create the solution...


  • From the File menu, select New > Project.

  • From the left pane, select Templates > Visual C# > Web.

  • Select the ASP.NET Core Web Application (.NET Core) project template.

  • Enter ContosoUniversity as the name and click OK.

    New Project dialog

Now if I did everything correctly (yes, I took the default name instead of changing it to ContosoUniversity, for instance), here's the appsettings.json file's connection string that came out of that template...

"DefaultConnection": "Server=(localdb)\\\\mssqllocaldb;Database=aspnet-WebApplication2-ac2d2954-804a-4157-821e-f0e494fdb334;Trusted_Connection=True;MultipleActiveResultSets=true",

... and here's what actually works...

"DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=BoodaPow;Trusted_Connection=True;MultipleActiveResultSets=true"

It's just an extra backslash, as far as I can tell. Not sure how I could've introduced that, but perhaps I did?

I ended up getting the correct format from here, which is the github repo for the completed Contoso U example I referenced earlier.

Enjoy. Your C:\Users\YourUserName\ folder is now full of mdf & tdf files, just like you wanted.

Labels: , ,

posted by ruffin at 1/02/2017 03:34:00 PM

This is apparently becoming something of a yearly tradition.

Not sure why they can't tell me what boxes these are... would make things lots easier. But I lost a hard drive, so I'll end up wanting to do this at some point anyhow.

Labels: , ,

posted by ruffin at 1/02/2017 01:02:00 PM

Where is the "ASP.NET Core Web Application" template in Visual Studio? It'll show up once you've installed the ".NET Core tools preview for Visual Studio".

Makes sense. ;^)

It's never fun when a hard drive dies.

Labels: , ,

posted by ruffin at 1/02/2017 09:09:00 AM
Friday, December 30, 2016

So here's a tough question: When you're creating your marketing, what do you do about competition?

I'll admit, I'm not in a position where it really matters yet. Other than dabbling in AdWords, I haven't really marketed. I'm probably going to start contacting review sites and folks that have written Markdown editor comparisons soon, but telling people why my widget is better than all the other widgets of the world isn't what's holding me back from internet fame. Though part of me does wonder if that isn't part of your press kit.

But at some point, isn't it a good thing to tell folks why you're better than your competition? We see that on TV all the freakin' time.

Tide vs. Gain project

(The irony of the above image? Both Gain and Tide are Procter and Gamble products. /sigh Still, it's a clever project someone performed in their dorm -- "If you leave two free containers of detergent, which do folks pick?" This is what happens when you search for "product comparison" images "with reuse", I suppose.)

Finding vs. exposing market fit

One of the things you need to do before you start making an application is to gauge product-market fit. I'll admit my fit measurement was a little spotty. I use Windows quite a bit, and was upset that the Markdown editor that I'd traditionally used hadn't been updated in months to maybe over a year when I started, and its live preview window was broken (as in no display at all) in Windows 10. But that same app had apparently sold enough units that its developer had rewritten the whole schmear at one point, hoping for even better future sales.

If I could get somewhere close to what that app interpreted as "enough cash that I should rewrite what I'm already doing to make real cash", I'd be pretty happy, even if that second level cash they'd hoped for wasn't there. That is, if I could create an asset that's good enough to bring in several thousand dollars a year -- plus is easily reusable for any number of apps and extensions -- that'd worth a few months' of time, right?

I did survey the state of Markdown editors before starting. It's actually, as far as I can tell, a much more crowded field on macOS. I'm not really sure why. I could guess it's because Markdown's inventor, John Gruber, runs an insanely popular Mac new blog, and there's spill-over. Or maybe having an elegant shorthand for HTML appeals to the same aesthetic as macOS. But at the same time, GitHub and StackOverflow's web interfaces both support Markdown entry, and there's nothing especially Mac-specific about either of those, even if you pretend that a disproportion number of programmers still use Macs (do they?). And every time I turned around, people publishing to the web, from readmes to blogs, were praising Markdown, releasing tutorials, and writing "Intro to Markdown" posts.

If you could get anything close to a Mac-sized following for Markdown on Windows (so even a much lower percentage of total users, just with a similar total number of users) and sell to the folks that actually depend on a decent editor to get their work done, I figured you'd be doing fairly well.

The state of Markdown editors on Windows is pretty sad. The one I used, as I mentioned, seems abandoned. The Windows Store is full of Markdown editors, but they're usually freeware and, honestly, bad. I've found a few crossplatform apps that are okay-ish, but don't feel like something I'd use if my publishing life depended on them.

Then I found an editor that has a pretty neat website and boasts a ton of features, from tables to fully customized themes to automatic outlining. And I tried its demo. Ugly, difficult to use, poor UI, and so buggy that I felt it was unusable.

Cheeky comparisons

But how do you get the fact that your competition stinks (in many ways) across to people looking for an app? Simply be good and let people find you? That's classy, but also almost certainly doesn't maximize profit.

Yet isn't it too cheeky to make a flowchart detailing what's broken?


MultiMarkdown Table Support

Some free app


The old abandoned app

Paid only, but, um, abandoned without working live preview on Win10

Allegedly feature-rich, well advertised app

Unusably buggy


Heck yes!

With names, that seems like it'd be in really bad taste. But part of my selling point is that you're wasting your time just trying out these other apps. If it takes 15-30 minutes to read through a marketing site, download, install, and test out an app just to find out it's crud, that's offensive. Our most valuable asset is usually time. I'd like to think MarkUpDown is worth the money already just in the time it'll save you from searching up a competent editor.

Setting a classy example

At the same time, look how friendly Daniel Jalkut was to John Saddington when Desk came out for macOS.

From On the Shoulders of Giants – John Saddington:

I saw this tweet this morning via Daniel Jalkut and my heart skipped a beat:

MarsEdit has a new competitor in @deskpm. Lots of 5-star reviews, looks like they got some important things right!

— Daniel Jalkut (@danielpunkass) November 12, 2014

For those that are unaware, Daniel is behind the most-famous MarsEdit app (he acquired in back in 2007) and has made it the “king” of desktop publishing apps. It is a robust and more than capable offering and if Desk isn’t the right fit for you then you should definitely check it out!

The thing that was so amazing, though, was that he didn’t come out “guns blazing” and tear me and my small indie app a new one. He could have, if he had wanted to, and totally laid me out but he choose to really tweet a very encouraging set of tweets:

@DeskPM @adamspelbring I sincerely miss the days when there were more competitors, so I am always inspired to see newcomers on the scene.

— Daniel Jalkut (@danielpunkass) November 12, 2014

I can also say that when I met John Saddington at the Release Notes conference, it became clear that post wasn't simply posturing. I asked him about the bugs I was seeing in Desk MD when posting to blogger, as I was looking to a write a similar app myself. That is, I was looking for anything -- why did he decide to ship with those bugs, what sort of reaction did he expect from users (and what was the "right" thing for me to do as a user in that situation), etc.

Saddington not only took the time to explain why he had some bugs, what he felt was fair for customers like me to say ("When you're hitting that much trouble, and I know you are, ask for a refund!"), what his priority list was then in general and for Desk, but also told me, "Hey, if you do write your own, let me know. I'll totally recommend it for Blogger. Supporting Blogger drives me crazy," or something similarly as impressively helpful (I'm pretty sure John's a Wordpress user). If I'd written MarkUpDown for Mac with Blogger extensions and had started by, as he says,

So I'm a little loathe to lambast anyone, if only because of the example these folks have set before me. Argh.

Perhaps I should just reasonably fairly review what's out there. (I say "reasonably" just because I know I'll be a little biased towards MarkUpDown. If there's something I don't like about it, I change it. And I grossly undervalue things that don't matter to me [like most reviewers, I'd assume], like, eg, dark themes.) Then at least I can honestly say what's not working and at least rationally argue for why MarkUpDown is better. /shrug

Anyhow, marketing is fun.

In other news, here's an interesting list of dev podcasts in the running for some sort of award.

There are a number of JavaScript 'casts. Guess I should check out more of them.

Worth looking around at the others too.

Labels: , , ,

posted by ruffin at 12/30/2016 06:15:00 PM
Wednesday, December 28, 2016

I've said before that I'd essentially given up on having a MacBook (Pro or otherwise) as my main development rig. I think that's smart. The Lenovo Y700 I bagged in April has the same processor as the entry-level 15" MacBook Pro, and that MacBook is both a little large and way too expensive -- $2400 minimum buy-in for the 15", where I spent $850 for the same processor, same SSD size, more RAM, and maybe even a better graphics card. I got worse size, battery, keyboard, and trackpad, but I also have $1550.

Yet my Lenovo 100S, a cheapo plastic ultrabook, still gets more use than I would've thought, usually as "the laptop I carry when I'm not carrying a laptop". I bought it sort of on a lark when it was on sale for $150. Horribly underpowered, only two gigs of RAM, 32 bit processor, horrible keyboard, 32 gig "hard drive".

But it does have two great things:

  1. Great battery life -- 8 hours or more
  2. It's extremely small

As I've said before, it's my knock-off MacBook Air -- or, more recently, 12" MacBook. It's great to have a light computer that doesn't feel like it needs a laptop bag to comfortable schleping around.

Now look, it's crazy to think about comparing the 100S to a computer nine times as expensive. I agree. Mostly. But check this out:

size and weight stats for Lenovo 100S and 12" MacBook

The MacBook is almost half an inch less "skinnier", has two-tenths-inch less depth, is .15" shorter at its tallest, and weighs around 80g less.

That is to say, the 12" MacBook is smaller, has a better battery, keyboard, trackpad, screen, and processor -- surprisingly, it has faster single core performance than my 2012 Mac mini does on Geekbench, iirc. Again, not sure that makes it worth 9x the other, but that's, as the English say, an impressive piece of kit.

If the MacBook gets a boost in March, give or take, and at least holds its price (Touch Bar or no), it's going to be harder to resist.

Labels: , , , , ,

posted by ruffin at 12/28/2016 07:54: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
* that hardware vendor review site I forget about is here * 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 my own and do not necessarily reflect the views of any employer, past or present, or other entity.