If you've been using Visual Studio, but bounce in and out of SQL Server Management Studio, and all of a sudden hitting F5 is opening up a file selection dialog asking where you want to save your *.rpt file, I think I know what happened.

Did you just search for something?

Argh, annoying.

Labels: noteToSelf, SQL Server

No, no, I'm not nearly ready for app review. Instead, I'm relaying (via Michael Tsai) a fairly interesting post from (buried lede...) an indie development newsletter. (Aside: Have you noticed that email newsletters are picking back up some steam?)

After building the app in just 3 months, I had to enjoy 3 more months of App Rejections before finally releasing it to the Apple Store.

It's an almost humorous self-prep case-study so that you know once you're done with an app, you're not done.

Unless you're on the Windows App Store, or at least the old Windows Phone 8 app store, which almost immediately approved my app when it had a show-stopping bug on launch once deployed on any device but mine, which was fun.

Which is to say, the Windows Phone app store reviewer didn't even open my app before approving it. Wow. Or maybe immediately crashing looked like a feature? ;^)

Labels: app store, indie, review, windows phone

Well, that was fun. I went all the way around my elbow to get to my nose on UWP TextBox scrollbars. I figured out how to set it in XAML pretty quickly, but for some reason spaced on getting it working programmatically.

In XAML, things looked like this:

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <TextBox
        AcceptsReturn="True"
        ScrollViewer.VerticalScrollBarVisibility="Auto"
        ScrollViewer.HorizontalScrollBarVisibility="Auto"
        Name="txt"></TextBox>
</Grid>

So naturally I thought I should be able to do something like this in code... (To be clear, the following doesn't work, though, in my defense, it apparently used to in Silverlight)

// ... where `this` is, obviously, the TextBox. We're in the constructor right now.
this.HorizontalScrollBarVisibility = ScrollBarVisibility.Visible;
this.VerticalScrollBarVisibility = ScrollBarVisibility.Visible;

Or, maybe, at worst, this:

this.ScrollBarVisibility.HorizontalScrollBarVisibility = ScrollBarVisibility.Visible;
this.ScrollBarVisibility.VerticalScrollBarVisibility = ScrollBarVisibility.Visible;

Nope, no dice at all.

Hey me, it turns out that's the wrong idiom, you idiot! After going all the way through putting the stupid TextBox into its own ScrollViewer, and then managing scrolling by coordinating SizeChanged events in the TextBox (wait, whaaa?), I stumbled onto this MSDN page, which I'm suspicious I'd found before, which had the secret incantation for UWP TextBoxen:

TL;DR -- Here's the answer...

ScrollViewer.SetVerticalScrollBarVisibility(this, ScrollBarVisibility.Auto);
ScrollViewer.SetHorizontalScrollBarVisibility(this, ScrollBarVisibility.Auto);

That's a weird idiom for me, though it's essentially the same thing you do when you set rows and columns for Grids...

TextBox txtMd = new TextBox();
Grid.SetRow(txtMd, 1);
Grid.SetRowSpan(txtMd, 2);
Grid.SetColumnSpan(txtMd, 1);
grid.Children.Add(txtMd);

I'd expect each SetRow and SetRowSpan to be methods on the individual grid instantiations rather than a static method on Grid proper.

And it's not like the start of the text on the MSDN page helped a ton... It starts by making you think you have to manage this all yourself. Maybe it changed later? Nah, I'm sure I missed the answer a half-inch below.

A multi-line TextBox will continue to grow vertically as text is entered unless it’s constrained by its Height or MaxHeight property, or by a parent container. You should test that a multi-line TextBox doesn’t grow beyond its visible area, and constrain its growth if it does.

Oh well. Live and learn. Man, I made that tougher than it shoulda been.

Labels: c#, howto, noteToSelf, uwp

I don't know, seems like another QA fail at Apple, doesn't it?

From Six Colors:

Last night my iMac’s Ethernet port stopped working. Turns out it seems to have been because of a bad, silent security software update from Apple. Just delightful.

More info here and on this MacRumors thread—the update seems to have been pulled and the fix appears to be to reinstall /System/Library/Extensions/AppleKextExcludeList.kext from a backup.

Who is in charge of QA at Apple again? (Past posts on Apple QA (and other) fails here with lots of overlap and perhaps one or two additional posts on QA here).

Labels: apple fail, qa

From today's New York Times Afternoon Update email:

Whoa! Seems there was another party or two involved at some point before we started worrying about how poorly the Republican nominee plays with the Speaker of the House.

Can't tell if this is a horribly smart plant by some Trump PR folk trying to Force our way into thinking the GOP can't help but win the election or if the Republicans are so worried about Trump they're putting him in the same set as, "Hillary won. What the heck do we do now?"

(No, I haven't read the article. When you're a newspaper, you have to make sure the reader can stop at any natural stopping place (a paragraph, for instance) and have a reasonably good idea of what's going on. I forget the term -- spiraling composition?)

Labels: Other Stuff

I didn't realize that Sublime Text 2 overrode some settings when you went into distraction free mode, though I did notice my line numbers were, unfortunately, gone.

Well, that's what up. A few settings are overridden if you've set them, and you have to change them back from Preferences >>> Settings-More >>> Distraction Free:

Certain settings will be applied when in Distraction Free Mode. The default settings (located in Packages/Default/Distraction Free.sublime-settings) are:

{
    "line_numbers": false,
    "gutter": false,
    "draw_centered": true,
    "wrap_width": 80,
    "word_wrap": true,
    "scroll_past_end": true
}

So now I have this in my distraction free prefs:

{
    "word_wrap": false,
    "line_numbers": true,
    "gutter": true
}

There. That's better. Though I'll probably eventually override draw_centered too. ;^)

Labels: noteToSelf, sublime text

Put simply, this is why you would rather use Linode than Heroku:

Syslog drains allow you to forward your Heroku logs to an external syslog server for long-term archiving.

Really? I have to support another service just to keep hold of my logs?? For realz?

I was thinking today during my walk that using Heroku is like a drinking game. You learn how to play a little and then BAM, any time you see a certain action performed in the future, DRINK -- or, in this case, PAY!!!

Do you know how you hold onto your logs on Linode? That's right, folks, you write them to a file. If you want to spin up MySQL? Do it, right there on the same server. It's your own box, man. Do whatever you want.

I know Heroku is thinking that you'll have seventeen dynos all running together and you'll want to conglomerate all those logs into a single file on some other service, but still... I don't want to have to have a second service to replace writing to and reading files.

Labels: business, heroku, linode

Labels: ads, amazon, business, music, spotify

Labels: apple, business, iphone

Quick quote from High Performing Agile Teams: An Introduction on the Quality is Speed blog:

The parts of Agile I hate are the parts that ignore this essence. High performing teams are the goal. Not practices. Not user stories. Not estimation. Not Scrum. Not the manifesto. Not TDD. Too often the practices become the goal while we lose sight of the real goal: high performing teams.

Yes, thank you.

In other news...

Questions like this make me sad....please don't connect directly to your databases from your mobile apps, folks: https://t.co/FNKf8qDA18

— Greg Shackles (@gshackles) February 21, 2016

The question in question [sic] is bad news on a couple of fronts, but the one Shackles doesn't like is this bit:

SqlConnection con = new SqlConnection(@"server=MOON\SQLEXPRESS;"
    + "Initial Catalog=Moon;Integrated Security=True");

Ooops!

Had a similar thing happen to me recently creating the image upload service for my Markdown editor. It was surprisingly easy to set up the call to the API in C#, but it quickly occurred to me that it was also really easy for someone to Fiddler what I was sending, grab the API keys, and use my account to upload as much jive as they wanted.

I contacted Mashape to see if there wasn't some way to put a cap on my account, thinking I could just cross that bridge if I ever came to it. I mean, what's the point of limiting exploitation potential if nobody's going to buy the danged app to start with? (I'm an inveterate optimist, as you can see.) Then if I ever, say, hit $20 in a day (which would mean something like 21,250 image uploads in 24 hours), I'd quickly write an API, through it into the cloud, change the API keys, release a new build, and be done with a little egg on my face.

Well, Mashape never got back to me, so in an abundance of caution, I wrote the cloud service. Kinda a pain, atc. I eventually settled on a system of requesting an access key, creating a trivial hash that creates the key, giving the key a sunset time, then matching that key to upload requests. If someone hits more than X in period Y, they're shut down. If the whole system receives more than Z in Y, everything shuts down.

So I have my own rate limiter, and my API key, like the database connection in the bad SO question, is reasonably hidden. I mean, there's still a chance my cloud gets hacked and the code gets out, but that's a lot more difficult than grabbing Fiddler and sniffing API keys, even if they're SSL'd (which they weren't, initially).

Kinda painful how quickly a small feature addition because a pain, but at least I've got a nice cloud-based API presence now. On the down-side, I'm back to thinking I need to figure out how to move my entire website over to Linode eventually, as it's sooooo much cheaper to admin it all yourself.

PS -- How in the world did Redis get so popular for small-time hosted app services? I mean, if you have a distributed system, I get it, but if you want an in-memory key-value store for a single box, why would you bother? Just keep a dictionary in memory, right?

Labels: api, coding, images, markdown, style

MacRumors recently ran a story titled, Justice Department Calls Apple's Privacy Case Stance a 'Marketing Strategy', which seems pretty interesting on its face. Is Apple's denial to crack an iPhone simply to save face?

There has been a sort of conspiracy theory side to this that's well represented by Marco Arment's post on the topic:

It’s their excuse to establish precedent and permanent backdoors for themselves so they can illegally spy on anyone’s data whenever they please. They’re shamelessly using a horrible tragedy to get themselves more power.

And I gotta admit, when I first read it, I thought I bought it. But when you read through the government's motion to compel, you really don't see any of this. They say they don't have any problem with Apple having a clean room where they created fbiOS, and they can destroy fbiOS as soon as the phone's contents are extracted.

Which means part of this is a sort of developer's misunderstanding, both on Arment and Apple's parts, potentially. If you write this fbiOS that allows you to try as many passcodes as you'd like without fear of the OS wiping the phone once, and you know the FBI is going to be back asking for you to do it again, why would you destroy it? Wouldn't it take time to write it the right way again? Simple business math tells you to keep it all around for the next time.

And there's the only place where we have a backdoor problem. The backdoor fbiOS is going to live at Apple, and if it leaks, well, it's everywhere. Apple's going to have to play cat-and-mouse with its own fbiOS at some point if it leaks.

What's strange to me is that the FBI needs Apple to do this. I have to assume they'll compensate Apple for the time it takes to crack the phone, but why don't they already have this expertise in house? I realize iPhone-as-black-box is much tougher to crack than it would be for Apple, but it's scary that the FBI can't get into these things. Imagine what another nation state could do with their data. Our intelligence is pretty obviously going in blind.

More interesting to me, perhaps, is how the government flips the EULA that infects shrinkwrapping everywhere [that shrinkwrap still exists, which is, I guess, almost nowhere now]. If you say this software is yours, and you're going to control it to the point that you can change its features at any time, well, then it's still yours, capiche?

Apple designed, manufactured and sold the SUBJECT DEVICE, and wrote and owns the software that runs the phone -- which software is preventing the search for evidence authorized by the warrant. Indeed, Apple has positioned itself to be essential to gaining access to the SUBJECT DEVICE or any other Apple device, and has marketed its products on this basis.
...
Apple has designed the phone and software updates so that Apple's continued involvement and connection is required.

Ouch. Clever.

I still hate how badly the current FBI director doesn't understand the Internet [in his public comments], but Apple's losing this one, folks.

Labels: apple, encryption, privacy

Thank you very much:

There are cases where the local cache used by IntelliSense becomes stale. Refreshing the cache is easy but not necessarily obvious. There are two ways to refresh the cache: 1) Go to Edit -> IntelliSense -> Refresh Local Cache and 2) Hit Ctrl+Shift+R

There are times that the Intellisense for SQL Server Management Studio gets horribly out of sync with what's in the database now, especially when you're creating new databases and/or scads of tables with SQL. I'm not sure why that'd be, as you'd think the Intellisense within a SQL client would be able to keep up with changes made by that same client, for heavens sake, but it often-to-usually doesn't.

Wish I'd known about this cache refreshing sooner.

Labels: noteToSelf, SQL Server

From PCMag, but it's certainly not the only one (I caught it on the CBS Evening News last night. I know, I'm an old soul.)

Hollywood Presbyterian Medical Center has paid the ransom demanded by hackers after being under seige for more than a week.

The hospital paid 40 bitcoin ($17,000) to regain control of its computer network, Allen Stefanek, the hospital's president and CEO, said in a statement. Earlier reports put the ransom amount at about $3.4 million, but that was "false," according to Stefanek.

Staff began noticing "significant IT issues" on Friday, when the hospital declared an internal emergency. In the days since, computer-based tasks were carried out via pen and paper, hundreds of patients were diverted to nearby hospitals, and the Radiation and Oncology departments were temporarily shut down.

As I posted in a Disqus comment there...

It's time to ensure that patient information is not exposed on the Internet. I don't care if the answer is hospitals keeping their own intranet completely separate, moving data via physical device (my preference) or if we somehow come together to pay for a second, wholly physically-distinct "securenet", we've got to stop allowing companies to be so lazy with data and not hold them accountable for the poorly foresight.

The is the difference I don't think even James Comey, current head of the FBI, seems to understand when he parallels encrypted data with locked car trunks you can't open. When it's on the Internet, you've commoditized geography. Anyone who gets on the Internet, anywhere, can knock on your Internet networked data's door.

Come on, folks. It's past time to move our personal data to a better neighborhood.

Labels: encryption, hack, privacy

SSL Endpoint is only useful for custom domains. All default appname.herokuapp.com domains are already SSL-enabled and can be accessed by using https, for example, https://appname.herokuapp.com.

Labels: heroku, linode, linux

Image from Wikipedia's collection

At the beginning of this year, we officially turned off Flash support for VHS, the New York Times video player.
...
For live support in HTML5, we investigated moving to MPEG-Dash by integrating with ShakaPlayer or Dash.js, but then HLS.js was released. HLS.js allowed us to use HLS in any browser that supports MediaSource Extensions. HLS.js integration with VHS was smooth and took less than a week. [emph mine, of course]

Labels: flash, video

Labels: business, feedly, indie, support

Labels: coding, style, version control

One of the serious disadvantages of having alpha software is that you need to already start dogfooding it. So if you're, say, writing a Markdown editor, you need to start using it to write you blog posts.

This is great until you find that you'd like to make a change to the app's behavior, which turns a quick 15-30 minute blog post into 15-30 minutes of blogging plus 90 minutes of feature refactoring.

Oh well. That's what you've got to do. I didn't like the way I was inserting quoted text or, rather, marking up a block of text as a quote, so I rewrote it for this post. Fun times. But wow, it's nicer. I like having elegant white space in my files, and now the app will ensure you have two newlines before and after a blockquote in your markdown. Simple enough, if it wasn't for insane UWP TextBox newline management. I completely rewrote how I was handling that so that I could access SelectedText, SelectionLength, and SelectionStart, etc with new properties in a subclass of TextBox instead of post-processing the wacky, non-platform native newlines in code outside of the TextBox.

And though this blog's "main" topic is related, let's move on...

Was checking out Rachel Andrew's free chapter from her book, The Profitable Side Project (hint #1: A Markdown editor probably isn't going to lead to Hats of Cash), which quoted this MVP (minimum viable product) definition from Jon Radoff from 2010:

The goal of a startup is to find the sweet-spot where minimum product and viable product meet

Obvious, it seems, but I think it's worth looking at "minimum" and "viable" on their own terms as independent characteristics of a product, and know that mvp isn't some concept that exists on its own. It is the intersection of these two sets, as his Venn diagram depicts:

I think Apple's completely lost the ability to do this, btw. Read through Michael Tsai's run-down of recently reported problems with Apple Music combined with his run-down of Mossberg's post and reactions to see what I mean. Apple's stopped making viable software, and has grossly overemphasized minimum.

This bit from Jason Snell that Tsai points out is my "favorite", insomuch as a report of a horrible user experience can be a favorite:

First iTunes threw up a dialog box saying that the amount of iTunes credit had changed, so I would need to click OK and try my purchase again. (It’s a free app, so this entire experience is already pointless, but whatever.) I clicked OK and the Free button was now inactive. I typed Command-R to see if that would reload the iTunes page—no normal user would do it, but it worked because the App Store and iTunes is more or less a disguised web page—and then was able to click Free and download the app.

At some point in this process, the song I was listening to finished and another song began to play. It was a randomly selected track from my entire music library. The act of viewing the App Store had destroyed my music shuffle.

I really do think this is, as I've mentioned before (with all "Apple Fails" I remember to tag here), bad QA work at Apple. Nobody seems to be testing the edge cases. And when QA drops back this far, you won't get viable software.

At best, Apple is getting its dogfooding completely wrong. It's really sad how far quality has dropped in the race to be minimum everywhere. They've substituted Jobs', "We'll only support doing it our way, and we don't care who is inconvenienced," which allowed Apple to drop support for legacy techs and hardware at the drop of a hat for, "We simply won't care who is inconvenienced."

Folks, it has to be viable first... as Radoff says, that means a product that will "get people to fall in love with you". It's not something "crappy" that "nobody wants to use". The "Apple Way" used to mean they'd do it right -- loveably well -- no matter what. Man, I loved using MacWrite on OS 7 and 8. OS 8.1 was a great OS, even though it was so old you couldn't help looking at it and wondering when you'd have to put it down. But using it was great. That love isn't there with Apple software now for too many of us.

Anyhow, back to work before I start fixing bugs on my app again...

Labels: apple, apple fail, indie, qa, testing

I replied to a comment on 9to5mac that was embedded in a thread about Phil Schiller on the iPhone's paltry starting storage of 16 gigs. Here are a couple of bits:

Schiller will tell you ‘You can get iCloud storage which most people use these days’

As if mobile data is free and available everywhere

... followed by...

As if mobile data is free and available everywhere

It isn’t? I think it depends on where you live. In North America, South Africa and Australia, it seems to commonly have limited monthly usage and is paid per traffic transferred. In most other places, there are no transfer limits and you basically pay a flat monthly fee for a certain level of speed limit.

I'm not sure what places that comments is trying to say have these pie on the sky unlimited plans... I got the feeling that wasn't true in the UK and France, but could be conflating with overseas temporary SIMs. But this seemed to feed in fairly well with an older post of mine that said Apple wants you to stream tons, because it keeps iPhone use expensive.

I said more along those lines on 9to5, and figured I'd put that text here as well.

There's a close relationship between keeping iPhones as status items and linking them to expensive phone plans. I used mine with Ting, which is exceptionally low cost, but Apple would rather we kept shelling out for more expensive plans from the big four. Music streaming, cloud document storage, and, increasingly, video (esp cord cutters who have even cut the home Internet cord) mean iPhones users desire phatter data plans.

If people with money keep using iPhones, people will keep buying iPhones to look like they have plenty of money. Plans with lots of data is part of the cachet. Apple's going to continue to design phones to be used by those with enough expendable cash they keep expensive plans.

In other news, this is the first post made by my new Markdown editor. It's not even alpha yet, but we're getting close.

Labels: apple, business, iphone, wireless

What do you think Stanford's annual operating budget is? ... It's 750 million dollars. Michigan's is over a billion. These are Fortune 500 companies disguised by another name, and a lot of myth.

Labels: business, Jobs, Other Stuff