MacBook, defective by design banner

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


descrip:

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 www.myfreakinfirst-andlast-name.com

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

FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike, always wear white.

As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.

x

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, March 31, 2016

This iPhone SE seems eerily familiar

Got my iPhone SE this morning at the Store. You know, even though I sold my 5S six months ago while it was still worth something and used a very old phone in the meanwhile, the SE is underwhelming. I got 64 gigs, so I know I'm going to like it more than my 16 gig 5S, but, well...

I plopped it into my old, beat-up Speck CandyShell Card case and felt like all I got was a new 5S.

The screen is smaller than both the Lumia 640 and HTC 8XT I've been using the last few months. There's not (duh) nearly as much screen real estate as the iPad mini I was using for my iOS fix in the evenings at home, and though I like the SE's easy one-handed use, I'm starting to wonder if I shouldn't've gotten a phablet. The SE is fast, but, honestly, the 5S wasn't a slouch at most day to day activities. And it took great pictures as it was. Idk. What's the practical improvement of the SE over the 5S?

I'll enjoy the higher-res (and Live) pictures at times, I know I'll like Apple Pay, and the increased battery life over the 5S will be nice. I also know I wouldn't want to spend more than the $500 plus tax I laid out today. But, really, it's essentially the same phone I bought new two and a half years ago plus Apple Pay. I suppose I'm having a touch of buyers' remorse -- Gazelle has used 16 gig Sprint 6S's for the same as I just paid for the SE.

Can't help but wonder if we didn't hit Peak iPhone with the 6S and 6S Plus. Or, for some users, at the 5S.

Labels:


posted by ruffin at 3/31/2016 04:38:00 PM
Wednesday, March 30, 2016

Interesting quote from the appbot blog:

97% of Google Play reviews go unanswered! What better way to turn 1 star app reviews into 5 star reviews, get valuable feedback and make a user happy than to actually reply to them and solve their issue?

I keep hearing that the ability to respond to reviews is one of the pieces that needs to be fixed in the iTunes App Store (for iOS), and I still buy that the ability to reply would be wonderful, but that's a heck of a number.

Why might it be so low?

  1. Face it, tons of apps are abandoned.
  2. If you reply to half of the reviews, you're well above average.
    • That is, even The Good Ones aren't offsetting the empties that quickly.
  3. Good reviews probably don't need answering.
    • I know I get tired of, "Thanks!" replies in comments.
  4. Replying to reviews takes time.

It's that last one that I wonder most about. Even the most adamant iOS indie developers probably aren't going to reply nearly as often as they believe they would. They might reply when they see something they feel is insanely unfair -- replying could be an effective way to vent, and, if composed carefully, the vent could be productive -- but I doubt it'll be used as often as folks believe.

I still think it's important to be able to reply, however. When I'm eyeballing a three star app, and am about to tank the purchase, my mind could be easily swayed by a developer that's engaged and can explain why, eg, what appeared to be a bug wasn't. Simple engagement, a "proof of life", almost, would go a long ways, if the replies are carefully written.

Still, 97%? Ouch. Abandonware.


Speaking of abandonware... I think I started an abandonware post mortem for BlogGo a while back. Will probably do one for WorkBurst too. It seems like these two folks did everything right, yet their well-marketed apps seem to have tanked. Why?

I mean, anything showing an "introductory price" nearly two years after its last update, and with only five reviews of that version, is probably D-E-D dead.

Not so limited an introductory price

The fate of these apps is both kind of sad -- and scary -- to possible app developers. I'll talk more later with abandonware post mortems, but, to tie it into today, I'm not sure either app producer would spend a lot of time replying to negative reviews today, even if they could.

Still, 97%? Wow.

Labels: , , ,


posted by ruffin at 3/30/2016 10:51:00 AM
Tuesday, March 29, 2016

Just in case it ever disappears from StackOverflow, I want to quickly capture my favorite Skeet comment from StackOverflow:

We might see some abuse. We might also see some much simpler code where we just want a tuple, basically. Not everything needs to be an object with complex behaviour. Sometimes "just the data" is the Right Thing. IMO, of course. โ€“ Jon Skeet Feb 10 '09 at 23:18

insert alt text

What I really like about Skeet's comment here is that he shows he's [likely] always considering the anti-pattern. Too many developers hear rules from people they respect and start spouting them as gospel without 1.) checking to see if they really are the best way to approach a problem, and 2.) without continually double-checking that decision when they run into new, real-world problems that challenge the rule.

Say what you will about returning anonymous types, there's an argument for it. I love to use anonymous types as return objects for controller actions, when it's appropriate and you don't need a viewmodel (or already have one to reuse (which is essentially the same thing)). I've also, on my personal projects, caught myself using Tuples with more frequency than I'd expect. Is there a case to use anonymous types further up the line? Perhaps! If there's a repository method that's always producing read-only data, perhaps!

It's not whether the answer's right. There often isn't a kneejerk Right Thing To Do. It's that you consider every reasonable answer before deciding on today's solution.

That is, stop the cargo culting. Your fellow coders will, eventually, thank you for it, because a deliberate culture makes everyone a better coder.

Labels: , , ,


posted by ruffin at 3/29/2016 10:46:00 AM
Monday, March 28, 2016

From AppleInsider:

Netflix has been throttling video for AT&T and Verizon mobile subscribers for over five years, the streaming service has newly admitted, claiming it was in customers' best interests.

The company said it was trying to "protect consumers from exceeding mobile data caps," according to the Wall Street Journal. AT&T and Verizon wireless customers are still limited to streaming Netflix at 600 kilobits per second, which reduces video quality in the process.
...
Streaming two hours of Netflix video at HD quality could consume up to 6 gigabytes of bandwidth, easily blowing past many of the data caps imposed by U.S. carriers. [emph mfn]

It does surprise me how much people stream to their phones now. I mean, honestly, six gigs for a movie? That's a lot of cellular data. I was trying to figure out if I should buy the "Sprint" or "Other" model of iPhone SE (there are three models, apparently. The third is exclusively for China), and, well, the only difference for me, as I'm on a Sprint MNVO, seems to be that the Other model lacks one LTE band, so I can't get 100 Mbps.

Losing the "LTE Plus" band could be a big deal for many. In 2014, Sprint was insanely slow compared to the other major carriers, with under 5 Mbps for their LTE.

But at 100 Mbps? I'd blow through my RingPlus "free" monthly 500 megs in 500 / (100/8) = about 40 seconds. I don't think this matters a lot for me.


But by far the most interesting piece to me is AT&T's reaction.

AT&T's senior executive VP of external and legislative affairs, Jim Cicconi, claimed the carrier was "outraged" to learn Netflix was throttling its customers without their consent.

Oh, "outraged", is he? Seems like there are two possible reasons for this. Either he knew and needs to protect AT&T's rep with their customers (unlimited is unlimited!), or, more likely as the grandfathered unlimited plans disappear, he's counting the dollars lost to AT&T in overage fees from streaming.

(Disclosure, I guess -- I own trivial amounts of AT&T stock. And Apple & Amazon stock. Probably should put all that on the blog somewhere permanent, not that you care.)

Labels: , , ,


posted by ruffin at 3/28/2016 09:01:00 AM
Sunday, March 27, 2016

Enjoyed Jason Snell's description of precisely how an SE isn't a 6s inside on MacWorld, but I think I've found at least one important point I hadn't heard from the usual Mac media outlets when I tried to order this morning...

From PCMag:

The AT&T, T-Mobile, and Verizon units, as well as the unlocked unit, do not work well on Sprint or on Canadian carriers. These units are model A1662. It has the LTE bands for AT&T (2/4/5/17/29), T-Mobile (2/4/12), and Verizon (4/13), but not all of Sprint's bands. Sprint's high-speed Band 41, also known as Spark, is missing. While you will get some Sprint LTE signal on bands 25 and 26, it won't be the best speeds.
...
Sprint users and Canadians will get model A1723, but that won't solve all of Americans' problems. While A1723 has a wider range of LTE bands, including... 41 for Sprint Spark, it lacks band 13, so it won't work on Verizon's LTE network. It also lacks band 29, so it won't get the best possible speeds on AT&T. [emph mine -mfn]

Seems legit. PCMag provides a link at Apple listing iPhone SE models, and there is a pretty serious difference between Sprint (A1723) and the "Other" model (A1662). (There's also a China-only model, A1724.)

To break that down a little for service jumpers...


There are three models of iPhone SE:

  1. A1723 "Sprint" version
    1. Has band 41 for Sprint "LTE Plus"
    2. Doesn't work at all on Verizon LTE
    3. Poor speeds on AT&T.
  2. A1662 "Other" version
    1. Has LTE for AT&T, T-Mobile, & Verizon
    2. Missing band 41 for Sprint "LTE Plus"
    3. Limits Sprint users to possibly about 5 Mbps rather than ~100 Mbps.
  3. A1724 "China model"
    1. Exclusively for China, afaict.

Man, what a mess. I was trying to get an unlocked phone to use on a Sprint MVNO (RingPlus), and ran into the Catch-22 of wanting a Sprint SE (A1723), but not being able to order one via the Apple Store iOS app or online without either 1.) An existing Sprint account, or 2.) Creating a Sprint account. Don't have, don't want.

So I ordered SIM-free & a Sprint-style RingPlus SIM, but now, apparently, that could cost me some LTE speed. And if I do get a Sprint version, I can't carrier hop to Verizon or AT&T as effectively.

I'll probably show up at the local Apple Store on the 31st and ask for help.

Also from PCMag...

When I asked Apple about this, it pointed out that this is a lower-cost iPhone.

/sigh

It's a great phone at a great price, but not as straightforward a purchase as I'd've liked. By the time I had this sorted, I was already in the 4/1-4/5 delivery date range. Dang!

Labels:


posted by ruffin at 3/27/2016 09:02:00 AM
Friday, March 25, 2016

Caught this gem from the BBC via Michael Tsai's blog:

โ€œWe moved almost immediately after we got married so it came up practically as soon as I changed my name, buying plane tickets,โ€ she says. When Jennifer Null tries to buy a plane ticket, she gets an error message on most websites. The site will say she has left the surname field blank and ask her to try again.

Instead, she has to call the airline company by phone to book a ticket โ€“ but thatโ€™s not the end of the process.

โ€œI've been asked why I'm calling and when I try to explain the situation, I've been told, โ€˜there's no way that's trueโ€™,โ€ she says.

Sorry to say I pulled a legitimate LOL as soon as I read her last name. Ouch.

But my reaction? Gosh, which websites and what horrible programmers? I mean, even if you're a two-equals coder (you should use three, natch) in JavaScript, the weakest place I could think of off-hand, null != "null", and you've got no problem.

And...

INSERT INTO Users (Name) VALUES ('Null') -- (as the result of a parameterized query)

... screwed up nobody ever. Which leads me to say...

This is not Little Bobby Tables.

bobby tables

This is stoopid.

We're all stoopid sometimes, but that's what this is. It's stoopid.

???


After a little more digging...

Seems I ran through the same steps in my head as the SO post the BBC includes, but the answer seemed obvious; this is the "worst case" I could think of going in...

The only reasonable workaround I can think of, short of fixing this bug in every damn version of ActionScript, is to test fields for "null" and escape them as CDATA values.

Well, duh. Though extend my sympathy for those who have a legacy system that still uses XML, not JSON. ;^)

What this really shows is...

  • There's waaaaaaay too much NIH syndrome in the enterprise
  • We're exceptionally bad at creating test cases
  • We need more imaginative coders.

If the name "Null" is still an issue three to six months from now, SHAME. No, ALL CAPS SHAME. FOR REAL. Horrible.

Wow. Seriously, I'm embarrassed for the profession. At worst, you needed to see why your client-side was "letting through" names that were empty so far that they got serialized to XML. Does nobody check the logs? Or are your logs so chatty you wouldn't see this error?

/facepalm

Labels: , ,


posted by ruffin at 3/25/2016 11:33:00 AM
Thursday, March 24, 2016

So that's a clever saying, I guess, but I really think the take-home lesson is that creating code is at least three different, clearly differentiated skills:

  1. The ability to write code from scratch that works reasonably well.
  2. The ability to constantly refactor that code into something that's increasingly maintainable.
  3. The ability to reverse engineer code that you're coming to cold.

In one, you have the ability to write something that works reasonably well the first time. That's an important skill, but a pretty straightforward and, relatively speaking, common one.

The second skillset, creating (and editing) maintainable code, is actually covered by two different abilities almost entirely that are too often conflated. One is the ability to write maintainable code. That's perhaps the toughest skill to find, and it's not one that's easy to find out in a quick interview session, if you're the type of company that likes to give programming questions. Because you can write maintainable code a few ways, but the best way is when you get to refactor what you've got. Write code that works, and get the time to make it code that is maintainable.

There are certainly ways to minimize the refactoring by using best practices the first time, and those are habits and skills that you can find in an interview pair programming session. But it's a lot better to find someone who naturally refactors into every more maintainable code than to find someone whose first cut is pretty good.

The second half of the second skill [sic] is the coder who can reverse engineer anything. Can you get into the mindset of the person who wrote this code? How long does it take to rethread your head and work with the code in front of you?

This reverse engineer is also insanely rare and important, because they're the folks who can inevitably pull your rear out of the fire when you've got code written by that first type of coder, the ones who can write code that works reasonably well the first time, but who might not be the type that writes maintainable code. If that coder is still on your team -- especially if they are good refactorers, in which case you should put them on the task as soon as is efficient most of the time -- great, but seemingly more often, that original coder is gone, and it's the reverse engineer that proves the most clever of all.

(In case the image didn't come out because you've got Twitter JavaScript turned off...

quote)

Labels: ,


posted by ruffin at 3/24/2016 08:07:00 PM
Tuesday, March 22, 2016

I hope it's not too much to tell Chrome that this strange scrollbar in my variable value popup isn't horribly useful, no matter what good idea produced it.

strange debug

EDIT: Turns out this is from making the font smaller in the tools. If you ctrl-minus in the tools, you'll make everything smaller, just like in the browser, which I often do to get more source on the page. Then this happens.

Ah, the lost (never found?) art of QA testing.

Labels: , ,


posted by ruffin at 3/22/2016 01:11:00 PM

Excellent summary of why a new iPhone SE isn't an iPhone 6s from Jason Snell on MacWorld. I'm going to unfairly break his paragraph into a list.

  • The display, while still a bright IPS screen, is more in line with the screen on the 5sโ€”
    • itโ€™s got a lower contrast ratio and
    • reduced viewing angle compared to the next-generation screens on the iPhone 6 and 6s.
  • And the Touch ID sensor is unchanged from the 5s, so itโ€™s slower than the new second-generation Touch ID sensor found on the iPhone 6s and 6s Plus.
  • The iPhone SEโ€™s 1.2-megapixel selfie camera is a match with the one found on the iPhone 6, not the upgraded 5-megapixel model found on the iPhone 6s.
  • And thereโ€™s no built-in barometer, so forget thinking of using the iPhone SE to track how many sets of stairs youโ€™ve climbed...

Would I give that up for an extra $250 in my pocket? Yes, yes I would. And plan to. ;^)

Labels: ,


posted by ruffin at 3/22/2016 10:09:00 AM

The Apple in 40 years video is cute, just as you'd expect. So far, much of the praise has included saying the Newton bit was clever (see what they did with the stylus there?)...

newton scribbled out

That's cute. But the real self-deprecation came a little later.

beach ball

Humorous and traumatizing. ;^)

Labels:


posted by ruffin at 3/22/2016 09:54:00 AM
Monday, March 21, 2016



Getting ready to listen in on the Apple keynote in a few hours, and was a little surprised to see what's at the end of this:

Requirements: Live streaming uses Appleโ€™s HTTP Live Streaming (HLS) technology. HLS requires an iPhone, iPad, or iPod touch with Safari on iOS 7.0 or later, a Mac with Safari 6.0.5 or later on OS X v10.8.5 or later, or a PC with Microsoft Edge on Windows 10

I remember once having an iPod touch up at work to watch one, as I couldn't watch on a Windows box at all.

If you were wondering if Safari on Windows was dead, well, first, you shouldn't've been. It is. But here's your second or third confirmation.

Second, still seems strange this doesn't happen in iTunes or QuickTime only. They're not just okaying watching on Windows, but suggesting you do it on Microsoft's new browser.

Guessing there's some talk between the two behind the scenes on this one.

PS -- I know this one. It's Sia. Crazy album cover though.

Labels: , , , ,


posted by ruffin at 3/21/2016 10:36:00 AM
Thursday, March 17, 2016

Richard Clarke interviewed with NPR, and seemingly everyone has seen the moneyball quote. It's worth reading, so I won't skip it, though my interest lies elsewhere...

CLARKE: No, David. If I were in the job now, I would have simply told the FBI to call Fort Meade, the headquarters of the National Security Agency, and NSA would have solved this problem for them. [The FBI is] not as interested in solving the problem as they are in getting a legal precedent.

So good. Now let's move on to the way he thinks. I really like to use this model. When someone oversimplifies a question, and tries to prevent something as a simple binary, as in, "Should Apple be forced to unlock an iPhone?", it's useful to show that we're ready on a spectrum or sliding scale between A and B. If you can put the question in a larger context, its faux simplicity falls away.

RICHARD CLARKE: ... Under the Obama administration, for example, we've said we're not going to torture people. You know, we could, at the far extreme to make the FBI's job easier, put ankle bracelets on everybody so that we'd know where everybody was all the time. That's a ridiculous example, but my point is encryption and privacy are larger issues than fighting terrorism.

GREENE: But can you just explain why you would compare, you know, a company helping the government design a way to unlock an iPhone to something extreme as torture and ankle bracelets? I mean, that sounds like a very extreme jump.

CLARKE: No, the point I'm trying to make is there are limits. And what this is is a case where the federal government, using a 1789 law, is trying to compel speech. And courts have ruled in the past, appropriately, that the government cannot compel speech. What the FBI and the Justice Department are trying to do is to make code writers at Apple - to make them write code that they do not want to write that will make their systems less secure. [emphasis mine]

Now we can discuss how "grey" unlocking the phone is. There's stuff that's not particularly controversial: Law enforcement should be able stop a masked man leaving a house through the window with a large bag to ask what's in there. Then there's stuff that's not confrontation in the opposite direction: We shouldn't make everyone wear GPS equipped ankle bracelets so that law enforcement can find anyone, any time, regardless of past history or probable cause.* Or that we shouldn't use extreme torture (let's face it, some of the "non-torture" means of interrogating are still, at least colloquially, torturous.)

It's a chart.

Crime likely?
Imposition Level

Low
Med
High
High
Question masked man in window: YES
Search suspected masked man's home: Maybe
Torture burglar: NO
Low
Cameras at your bank: YES
Ability to GPS locate your phone: Maybe
Ankle bracelets for everyone!: NO

The iPhone unlocking is somewhere in the grid, somewhere between a burglar in a window and torturing the burglar, but where? And since the OS compromise could apply to anyone, doesn't this topic fall between bank cameras and ankle bracelets too? Which cells on the table are closest? Is there another axis we're missing (privacy)? Those are more interesting questions.

As I said, I love to reason like this. It's one of my favorite rhetorical tropes. I remember visiting a friend, and he thought that his milk had turned. His wife said, "But it's before the expiration date! It's fine." In the split second he took to reply, I butted in with, "Well, even if you keep a new carton closed and put it outside in the sun for a day, it's going to turn, regardless of date." Now we had two ends of the spectrum: Perfectly preserved milk good until the date, and poorly preserved milk that could conceivably turn before.

I wasn't trying to suggest anyone had treated the milk poorly, which is what the NPR interviewer tried to suggest to Clarke, I imagine to "BAM!" kick the interview "up a notch".

Hopefully that wasn't the interviewer's goal, but otherwise, Clarke is right back in the situation I often find myself, with someone who misses the rhetorical move and ends up annoyed that I dared suggest they don't know how to keep their milk cool. "Man, that's a very extreme jump!" No kidding. /le sigh

I get it if it's just a friend of mine who misses it, but an interviewer? Your one job was to listen, man. Okay, okay, that and keep the interviewee on track. Which he was doing exceptionally well by himself.

(Luckily both my friend & friend-in-law are excellent mathematicians, and immediately understood the logical grid I was setting out. ;^D)


* Though this one is probably less controversial than we think, at least if we carry around cellphones that are powered on.

Labels: , , ,


posted by ruffin at 3/17/2016 10:21:00 AM
Wednesday, March 16, 2016

I'm a little late to the party, but I had a quick reaction when rereading "Apple's Elephant in the Room":

We now know from Craig Federighi and Eddy Cue on John Gruberโ€™s podcast that many of these features were essentially unused by anyone who wasn't a developer.

Look, unhappy early adopters is a big deal. Remember when we started noticing more and more people were bringing Mac laptops to dev conferences? There was a cache, a buzz that started catching on.

Remember who started all this mess anyway? Marco Arment, a developer. Remember where his post got reported? Everywhere. Mac news sites, Mac podcasts (The Talk Show, anyone?), everywhere.

Developers are canaries. Developers told Apple that we like Bluetooth keyboards on our Apple TVs. We like Bluetooth keyboards with our iPads. And guess what Apple built? The "Smart Keyboard".

Don't sleep on developers' favorite features.

Labels: , , ,


posted by ruffin at 3/16/2016 11:45:00 AM
Tuesday, March 15, 2016

Say what you will about the Apple nilhists, dude, at least it's an ethos.

Dubset will use a technology called MixBank to analyze a remix or DJ mix file, identify existing recordings within the file, pay the necessary rights holders, and distribute the mix through Apple Music and other streaming services. The process can take about 15 minutes for a 60-minute recording.

...

The rise in popularity of the EDM genre has resulted in an increasing number of user-generated remixes, mash-ups, and DJ mixes of popular songs, and this partnership will help bring those underground tracks to Apple Music and potentially "all 400 distributors worldwide" in the future, said White.

I find that I listen to more EDM and EBM than I would expect when I code (though I'm listening to Man In Black - Johnny Cash right now). This is actually a pretty major point in Apple Music's favor as I slowly make my way into the world of streaming, thanks to the gateway drug of Amazon Music & my Prime account.

Labels:


posted by ruffin at 3/15/2016 10:21:00 AM

I've got an MVC app using Entity Framework that has some complex relationships in a notifications module. I've got different queries to get parameters related to existing vs. new subscriptions to events that potentially produce notifications.

For the existing subscriptions, I created a view, and then did a SQL to EF to create an entity based on that view. Beautiful, straightforward, no problems.

For the new ones, just for fun, I decided that I'd do it all in EF. What a freaking mess. Here's the flowerbox from the repository method, reformatted a touch for width:

// NOTE: I wanted to see how difficult this would be outside of creating a
// view like I did for GetParameterSubscriptionMatrixesBySubscriptionId. I
// think the lesson is that creating a view is smarter.
//
// "LINQ LEFT JOIN on Nullable<int>"
// http://stackoverflow.com/a/28949184/1028230
//
// Populating an entity from a custom join
// http://stackoverflow.com/questions/5325797/
//
// And, tangentially, Overriding Equals and GetHashCode for entity equality.
// http://stackoverflow.com/a/508157/1028230 

That's right, three SO questions plus an insanely nasty query, where I'm still, admittedly, embarrassingly, also appending a Distinct on the collection before sending the entities back as a List. There's some strange left joining going on as a result of the workaround to allo a join on a nullable int that I haven't been able to quickly remove.

Let's list those SO questions again, just to linkify them more easily.

Nasty. EF is broken. It's enough different from SQL that it's a new, often inferior, (& never, that I recall, superior) paradigm. Better not to support this, and to force you to use SQL for these tasks.

Do you hire for SQL competency? Then put as much logic as you can in your code's database.

Labels: , ,


posted by ruffin at 3/15/2016 09:31:00 AM


Over one meeeeilion helped!!! (Think Dr. Evil, natch. Or McDonald's burgers. Or something.)

I've always got Andrew's account to keep this in perspective (~5 million for him atm), and who knows how they get this number, but that's cool, I guess. I feel badly how many of these are older answers (I'm not as active now that "my work is done"), but that's pretty cool.

Labels:


posted by ruffin at 3/15/2016 09:02:00 AM
Monday, March 14, 2016

Daring Fireball, quoting the NY Post:

Master keys for every elevator in the city, major construction sites, subways and skyscrapers are being freely sold online, despite a city law that makes it illegal for unauthorized persons to possess them.

A New Jersey-based lock company is peddling an unlimited supply of New York Cityโ€™s โ€œ1620โ€ fire service keys on eBay at $15.50 for two.

Access to the Big Apple keys is sharply restricted. Itโ€™s unlawful for anyone other than firefighters, law-enforcement personnel, elevator contractors or inspectors and building owners to have them.

But a Post reporter bought two keys to the city with no questions asked from UltimateSecurityDevices.com, an online arm of Northeast Lock Corp. in Clifton, NJ.

Gruber's response:

This is, effectively, what the Department of Justice wants for the iPhone.

Here's the part that I think is widely underreported/argued/claimed, and it's painful to see Gruber skip over it: Networked devices aren't like physical ones in that there's not absolute geographical protection. If you want to break into my elevator, you at also have to be there. If you want to break into Director Comey's car trunk, you have to be beside his car. And I bet there's at least one camera on you.

I can't break into a NY elevator or Directory Comey's car trunk from overseas. But folks can break into your PC or phone more easily overseas than they can in your driveway.

Your "back door", if you have one, is accessible to anyone on the network, not just the guys who drive to your neighborhood. Joel Spolsky talks about barriers to entry. Actually having to get there is one of the biggest.

This is why I wrote, "A better neighborhood for our personal data". We have one small street, geographically speaking, with a billion-plus people all living there, their personal data exposed to any other unscrupulous schmoe living on our single street. A locksmith once told me that a lock keeps an honest man honest. A billion men aren't all going to be honest, man.


PS Google: Beetee Dub, I didn't write about better neighborhoods for our data in 2002, okay? Why can't Google index blogspot correctly? I've consistently seen search issues (or items that would pop up in blogger's interface when searching, but not on Google) with my blog. I mean, it is at least marginally in Google's own interest to support blogspot well, right? Right? /sheesh

google search results crap out

Labels: , , ,


posted by ruffin at 3/14/2016 11:43:00 AM
Thursday, March 10, 2016

I've been using Amazon Prime a bit more recently, since it's a "free" [with Prime, which I have] and ad-less streaming service. It hit me today, after listening through a few albums by bands I like that I already own that streaming isn't just replacement revenue for selling music the old fashioned way (albums & mp3s, which I guess are also "old fashioned" now), but when folks don't upload all their stuff to the cloud, an additional revenue stream for bands.

It's easier to add the cloud album to my account than to upload my own copy, so there goes a fraction of a penny with each "spin" the bands would've never gotten if I'd listened my own tracks in iTunes.

I'm not saying this is a new revenue stream, just that it's completely different. Apple Music in particular does its best to convince you that, as Eddie Cue said, I think, "Your music is just your music," but that's not the case at all, at least not for artists. Each channel -- CDs, vinyl, digital sales, radio, licensed use in commercials/movies/TV, streaming services -- is a different business proposition, and none of them seem particularly mutually exclusive.

I wonder if Apple Music makes a distinction while streaming. "This track was uploaded/purchased from the iTMS. NO ROYALTIES FOR YOU!!" I bet not.

You're welcome for the $0.02, Chris Robinson Brotherhood.

Labels: , ,


posted by ruffin at 3/10/2016 04:58:00 PM
Tuesday, March 08, 2016

RealMac's Dan Counsell has a newsletter now (This Curated service is getting some business), and in today's edition, he's got a link to a Medium post called, "Lessons Learned Launching A Side Project in 48 Hours":

The result was BugRex.comโ€Šโ€”โ€Šan on-demand chat for people who need technical help. Itโ€™s operated almost 24 hours a day by professional developers around the world, whichโ€™ll help you for up to 20 minutes for 10 USD.

So far, weโ€™ve had a few hundred chats and five completed sales. In this post I want to share the lessons we learned.

I was interested up until about the "five completed sales". The screenshot they have shows that they released no later than 13 August of last year (screenshot shows August 11), and the Medium post went up on 20 Feb.

So $50 over six months? Um, I can think of better places to put 16+ working hours. I'm guessing perhaps I've got the timeline off, but $50 is not gangbusters for having to risk getting kicked out of the programming zone at any moment to do what StackOverflow does for free.*

But let's keep reading.

We knew that there were two solutions out there already, HackHands and Codementor.io. However, theyโ€™re both quite pricey, starting on $1 per minute, which rules out a lot of students and young people.

And you have fairly established competition? (An example thread they included from reddit added another, and the one I was thinking of, fiverr.) This sounds bad.

I mean, maybe they end up growing this into something, and maybe their Medium post is part of a new marketing effort. It's also awfully useful to fail a few times to learn how not to not to [sic] succeed. But wow, this sounds like a bad idea, overall. Low risk, but bad idea.

I mean, how

There was one interesting lesson:

Lesson learned: Itโ€™s better to be personal an ask for feedback than pitching your product on Reddit. Just look at the different engagement in the /programming and /coding subreddits in the image above: 64 votes and 81 comment versus nothing at all.

That was legitimately interesting.

Anyhow, I guess it's worth a read, but I think the real lesson here isn't that you can start up a company (did they even incorporate?) and have an mvp in 48 hours, but that it's educational to fail fast. So far, my own side projects have failed much more slowly than that [to be clear, a bad thing]!


* Don't get me wrong; there's an opportunity to provide something better than StackOverflow. I hate it when I ask answerable, but perhaps niche questions and I get crickets. Adding a bounty often helps, but I'm betting there are more folks that'd answer for $10 in their downtime than for 100 SO points.

Labels: ,


posted by ruffin at 3/08/2016 02:20:00 PM
Monday, March 07, 2016

One thing I've constantly wondered about with ORMs is why they use different mental models than SQL, the thing they're almost always abstracting. We hire for SQL proficiency, but then immediately throw it away with complex edge case stuff. You know, like LEFT OUTER JOINs. /sarcasm

From MSDN:

The first step in producing a left outer join of two collections is to perform an inner join by using a group join....

The second step is to include each element of the first (left) collection in the result set even if that element has no matches in the right collection. This is accomplished by calling DefaultIfEmpty on each sequence of matching elements from the group join.

Yes, you heard that right. To perform a left outer join, you perform an inner join into a join table, then fill that join table in with default (null?) values if there's no inner join match.

Wth? Their example:

var query = from person in people
    join pet in pets on person equals pet.Owner into gj
    from subpet in gj.DefaultIfEmpty()
    select new { 
        person.FirstName, 
        PetName = (subpet == null ? String.Empty : subpet.Name) 
    };

I'm tempted just to write a view and use that instead. This is stupid. The syntax really should be...

var query = from person in people
    left outer join pet in pets 
        on person equals pet.Owner
    select new { 
        person.FirstName, 
        PetName = subpet.Name ?? string.Empty
    };

I don't get it. I wonder how hard it'd be to write an extension that does that...

Labels: , , ,


posted by ruffin at 3/07/2016 11:34:00 AM
Saturday, March 05, 2016

I'm testing WebView.InvokeScript in my UWP app, and think I've found my favorite test script...

Array.prototype.forEach.call(document.querySelectorAll("img"), 
    function (n) { n.src = "https://tafttest.com/200x200.png"; });

Here's the image that quick script puts into every img tag on the page.

insert alt text

This is from a service that produces any sized image of Taft you want, within reason. You just type in the dimensions you want (eg, https://tafttest.com/200x200.png), and up it comes.

It's like a gigantic hat. It's funny. Probably doesn't have to be Taft, but it's funny. Though not as funny as the one it'll give you if you grab a landscape...

insert alt text

insert alt text

I kind of like this one better, but I'm not sure of the copyright, unfortunately. ;^)

Array.prototype.forEach.call(document.querySelectorAll("img"), 
    function (n) { n.src = 
        "http://taftswag.weebly.com/uploads/6/0/6/4/60646335/3178534_orig.jpeg"; 
    });

swag

Again, funny.

swaggy T

Not funny? That a suggested further search is "Kittens with guns". What's wrong with the internet?

More about the Taft Test here.

Labels: ,


posted by ruffin at 3/05/2016 07:18:00 PM
Friday, March 04, 2016

John Gruber on Om Malik on ads in Instagram:

UPDATE: My best guess, and a few readers have made the same guess, is that I donโ€™t see ads on Instagram because I donโ€™t have a Facebook account.

Strikes me as an odd missed use case, unless it's more happy-path-only QA testing we've unfortunately come to expect from Apple too often lately.

I mean, honestly, picture viewing can be used are just like any other set of data points. If he's viewed pictures by anyone else who is Facebooked in, you've got a good starting place. If he's in his own Facebookless circle of schmoes, just drop in adverts for Coke or something similarly universal-ish.

Weird. Can you really inhabit a set for which Facebook has no targeted ads? Did they really not have any concept of untargeted ads to serve up for the null set? Hard to believe.

Labels: , , , ,


posted by ruffin at 3/04/2016 04:53:00 PM

Heard Manton Reece, probably on the Timetable podcast, talk about how you, as a contractor, can never hit eight billable hours in a day. So that's obviously wrong, but you get his point, similar to when I talked about being suspicious of contractor hours. Eight hours working doesn't ever mean eight billable hours. There's always some overhead, like going off the clock to blog this.

What's recently occurred to me, though, was where in the day I most naturally put in long stretches of hours. As I've become a full-time indie contractor, I'm also doing more on what I'll euphemistically call "the domestic front". I usually end up running some "domestic" errand in the afternoon that ends with me, back at home, after running around town. And at that point, I don't usually start back up coding. I eat, catch up on email, read some stuff, maybe collect some gold & elixir ;^), and basically become household-man for the night.

When I worked full-time for someone, my domestic slate was clear-er. I knew that going in to contracting, because one of my goals with contracting was making sure I was precisely able to be more domestic. But when I worked for someone, I routinely had less on my plate, and more times to fall into Spolsky's Zone.

We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

...

The other trouble is that it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers -- ESPECIALLY interruptions by coworkers -- all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you're in a noisy bullpen environment like the type that caffinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.

(Sidenote: That last point, of course, is why you want to hire programmers who naturally wear headphones when coding.)

The lost night

The domestic front is going great, but, long story less long, what I've noticed is that I don't work blocks of hours into the night as often now. I've recently regained one night a week without any serious commitments, and I'm working routinely that night until seven or eight. Every other day, I'm done at 4 or 5, with maybe some decompression hacking on my own stuff (because I'm too bushed to work confidently on anyone's billable projects) from 9-midnight.

I had no idea so many of my long blocks of work happened after traditional quitting time, but in retrospect, it makes perfect sense. My most productive time is after I've spun things up after lunch, gotten my questions answered, and entered that relaxed zone of increasingly quiet time at work after 5. Or, perhaps more realistically, 4:45. Anywhere I've worked, though, the calm after 6 or 7 is blissful.

Anyhow, I used to wonder why I wasn't getting in what felt like my normal hours, and then the obvious finally hit me, as I found myself in the shared office space after dark for the second or third week in a row. It's nighttime.

If I want to seriously bill, I need to get my nighttimes back. That's where my 8+ hours of daily productive, no-guilt, billable work time went. But that's also exactly what I'm trading to reduce domestic debt. I just don't think I realized how 1-to-1 the nighttime tradeoff to billable hours really was.

Labels: ,


posted by ruffin at 3/04/2016 10:45:00 AM
Thursday, March 03, 2016

The reason I haven't used 1Password yet, though its auto-generated passwords have to be safer than what I'm using, is that you've...

  1. Got a single point of failure for all your passwords, and,
  2. Will transport those passwords through the cloud.

Looks like 1Password just started showing the issues with 1.)... From a wrap-up on Michael Tsai's site:

So it appears 1Password is sending data to the browser extensions over the loopback interface in clear text and not only passwords but credit card data as well if you use it for checkout forms. If anyone is sniffing your loopback they can get any data passing between the two.

The reply from 1Password makes some sense...

Officially our view is โ€œif a malicious process with user privileges is running on the users machine when they use 1Password, there is little we can doโ€.

Fair enough, but, again, one mistake in their code means all of your danged passwords are out. If someone is sniffing your loopback, well, all your passwords and 1Password info is out.

If they make this sort of mistake in moving things around the cloud, it's no longer a local machine issue.

Use strong passwords, and keep your use of them to a minimum. Keep your laptops pretty clean and your home computers turned off when you're not using them. In short, be smart. Don't depend on a cloud service to be smart for you.

Labels: ,


posted by ruffin at 3/03/2016 10:00:00 PM

From "These are the 25 most popular [iOS? -mfn] apps in America", pubbed by qz.com. None have less than 15 million users a day. Only one requires a paid subscription to be useful (Netflix) and zero, I believe, aren't free to download. Ouch.

Combined with another qz.com post, "Most smartphone users download zero apps each month", and it makes you wonder why anyone would be an app developer.

The second link is directly from Michael Tsai's post on The Verge's "Life and Death in the App Store", and the first is a follow-on mentioned in the second.

Ouch.

Labels: , , ,


posted by ruffin at 3/03/2016 11:11:00 AM
Wednesday, March 02, 2016

I've been debugging a new MVC project in Chrome, and for some reason the Developer Tools keep closing without any sort of interaction from me.

I don't know that this is it, but one strange thing I noticed was a javascript file with this...

<script type="text/javascript" 
    src="http://localhost:49286/711d8a0271d342b784e495255cb5cba2/browserLink" 
    async="async"></script>

I haven't screwed around with the async flag before, so that looked minorly suspicious in the absence of anything obvious.

A little googling turned up this link on turning BrowserLink off:

In the most recent edition of Microsoftโ€™s epic saga, Things Which No One Asked For, weโ€™ve been given Browser Link. Without a doubt the most important thing you need to know about it is how to turn it off.

Well said. Follow the link to see it all, but basically there's a drop-down next to the little refresh looking circle beside the "play" button in Visual Studio's toolbar.

We'll see.

Labels: , ,


posted by ruffin at 3/02/2016 12:01:00 PM

Sometimes, experience does bite you, if only gently. I've still been using name attributes in links to create "hash" links (http://www.example.com/index.html#goHere). That's, um, reasonably close to wrong:

The use of <a name ...> is declared as obsolete in HTML5 CR, and it really reflects the shortcomings of early HTML versions. โ€“ Jukka K. Korpela Dec 13 '13 at 14:09

@JukkaK.Korpela I wasn't aware of that. Has just using IDs of elements (e.g. divs) replaced it? Or is there some other mechanism? โ€“ kfb Dec 13 '13 at 14:20

Using id attributes is the recommended way (and has been possible for a long time, all relevant browsers support it). โ€“ Jukka K. Korpela Dec 13 '13 at 14:28

I often look through html to find a good name attribute to link more directly to something I find interesting. Looks like that'll be lots easier now. Phew.

Labels: ,


posted by ruffin at 3/02/2016 09:35:00 AM
Tuesday, March 01, 2016

Stephen Hackett posts another Apple Fail to 512 Pixels:

Here's what the Erase sheet says:

Erasing "Time Machine" will destroy of all the data stored on it. Enter a name, choose a format.

In addition to the text being so brief it feels incomplete, it has two grammatical errors...

I emailed him that Apple's QA is to blame, with a laundry list of the stuff I've pubbed here and pushed to Twitter. Honestly, Apple, you've got to do better than this.

Labels: ,


posted by ruffin at 3/01/2016 10:09:00 PM

<< Older | Newer >>


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 etree.org 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.