Sometimes I see complaints about sites like Fiverr, where graphic design folk complain about how the sites depreciate their own work. I'm usually not that sympathetic. What I'm looking for when I use Fiverr is something that really shouldn't take more than a few hours to do, at worst -- usually an app icon. And I want someone who can do that in an hour, rather than the hours on hours it'd take me to Gimp my way to inferior, but probably useable, results.

That's not the market of most graphic designers I see complaining. I was never in their potential market. If I ever have an app "take off", I might be. I might want a custom icon set, and better app icons that require some in-depth conversation and being on the same aesthetic page. Right now, not so much.

See, many of these folks won't even consider my "value proposal": I need a single app icon. Can you make that for me? Even at their normal rates, the overhead of getting a new customer spun up in a serious way often makes that a money-losing proposition. And who wants the wasted overhead getting on the same page with a customer just to make a single icon? Not only are they out of my budget when I'm tossing darts at the board and seeing what sticks, I'm not a big enough fish for them to care about.

But I got a sort of "turnabout is fair play" on StackOverflow Careers this morning. Check this out:

Wow. Just wow. I mean, that's less than $11 US per hour.

It's obvious this is for a programming sweat shop. One coder doesn't work 24 hours a day, seven days a week. They want a team. And cheap. Which means it's also pretty obvious to me, at least in my experience, that they aren't looking for great code, and will settle for code that seems to function, forget maintainability. Because even if you're willing to hire anyone semi-competent, as long as they're at this rate, you're not hiring someone competitive. I mean, good programmers can still find global, remote jobs that pay much better than this.

But let's also take a second to recognize that this is, in part -- at least as long as I'm working contracts remotely -- my competition. Wow. I'm not saying I couldn't make ends meet at $11 a hour, but that's sure nothing close to what I'm able to charge now. This is globalism. Like graphic designers looking at Fiverr, even though Powerfont Pty. Ltd. was never a potential customer (or employer) of mine, wow. That anyone had the gall to post such a low rate for a "senior" .NET MVC programmer is a body blow.

My biggest practical asset, it turns out, at least implicitly, may be my geography.

Labels: business, globalism, stackoverflow

Saw a question on StackOverflow this morning that mentioned ESLint was merging with another JavaScript linter, JSCS, or at least their teams were.

I added a quick comment:

An opinion question as written (the one you link to does a good job hitting a grey area: "Show me the way code is handled differently in each"), but here's an interesting, related tidbit: It appears ESLint isn't merging with so much as aqui-volunteering (?) JSCS's team.

... the first goal of the combined ESLint/JSCS team is to make the transition to ESLint easy for JSCS users.

They've planned to add features from JSCS that ESLint doesn't have now, but it seems the JSCS codebase isn't merging with ESLint, but is likely going to wither on the vine. Makes sense, but still interesting!

_{Aside: I like aqui-volunteering. See what I did there? (Sorry.)}

One comment from the ESLint project's announcement about the merger bugged me, however...

With the new combined ESLint/JSCS team, you can expect a lot more from ESLint in the future. We now have some of the brightest people in the world working on making ESLint the best possible tool for JavaScript syntax analysis. I’m personally very excited about ESLint’s future and tackling some of the more difficult problems like making autofix possible for every rule and incorporating type information into our analysis. We can go a lot further, faster, when we’re all working on the same tool. [emph mine]

Ah, the mythical volunteer month strikes again. If only all that were true.

I still don't know what more coders really buys you. If you take the time to create clearly defined interfaces between every chunk of work, you can gain nearly 2x production from double the coders. And I think there's something to careful use of pair programming, which provides three sets of advantages:

1. Great architectural review.
2. Bug spotting that ids lots of low-hanging fruit/duh moments.
3. Shared familiarity with code.

The third is one of the most important. Forcing coders to share what they were doing and thinking with someone else gives you the first and second, but also means that your cyborg -- and all code is full of cyborgs, some strange melding of code and the style of the person(s) writing it -- is more spread out, reducing the impact whenever some of the meatware decides to move on.

But does it work here?

But when it comes to great JavaScript linting, I'm not sure more is better. You've still got one guy working on a linter as a side project that, afaict, is every bit as useful, if not moreso, in standardizing code and enforcing best practices than the work of the 371 (to date) at ESLint. (In case you're new to the blog, that's JSLint.)

I mean, tell me which code you'd rather maintain:

or...

And I should point out the JSLint repo has no folders, and you really only need that single jslint.js file. Occam's code, folk. Make code so simple to use that it'd make William proud. ;^)

I like Nicholas at ESLint. Seems like a really good guy -- and ESLint seems like a good, well thought-out tool. It just seems like overkill -- harder to maintain, more to learn to use proficiently, more likely to change from installation to installation, which means less standardized code -- and there's nothing that bugs me like over-engineering. One example: Autofixing? Why not just use Typescript from the start? Seems too much for a linter. Teach me how to write good code. Don't automate the fishing.

Here's a less biased example: Looks how excited this guy on SO is that ESLint makes it exceptionally easy to create new rules.. To me, that's cringeworthy -- No, no no, I don't want everyone on the team creating new rules! But if quickly creating custom rules is your use case, well, ESLint might be what you're looking to find.

(Though, admittedly, I have suggested to others that they hack JSLint directly, since it's just JavaScript, which might be even worse.)

Anyhow, just an interesting [to me] cultural contrast between two popular and useful linting projects.

Labels: coding, cyborg, ESLint, JSLint, style

1. Open regedit

2. Goto - HKEY_CURRENT_USER\SOFTWARE\Alps\Apoint\Gesture

3. Edit 2TapShow set value to 1

4. Edit 2TapSupport set value to 1

5. Edit 2TapSetting set value to decimal 13 (hexadecimal d)

6. Do the same for HKEY_LOCAL_MACHINE\SOFTWARE\Alps\Apoint\Gesture

7. Restart machine

EDIT 20160926: Looks like the Anniversary Update for Windows 10 broke that setting. When I opened RegEdit, all of the values above were zeroes again, so I'm hopeful, though still a little annoyed it broke on an update. ?? (Another update: No dice. These settings don't seem to work now. ARGH.)

EDIT 20170121: Sorry for all the spam on this post, but I went through the whole bit, both HKEY_LOCAL_MACHINE and HKEY_LOCAL_USER, and it is working again. Oh, thank heavens. I had my ThinkPad Compact USB keyboard die this week, so I was back to using the stock "buttons" on the Y700, and they stink... so... badly... Being able to two-finger-tap to right-click makes the box usable again.

EDIT 20180612: This now seems to be done via the control panel for trackpads again. (I get there with "Control Panel" from Windows menu search, Mouse, Change mouse settings, Touch Pad tab, "Click to change the Touch Pad Settings" link, but there's got to be a more direct route.) Select "2-Finger tapping, turn on the "shortcut menu" option, and profit.

Labels: hardware, lenovo, noteToSelf

Step 1: [Go to gmail.com] in Chrome and click the Protocol Handler icon  in your browser's address bar. 

Labels: chrome, email, noteToSelf

Idk. Most of the time, even the "real" reviewers that get items for free or less than full price often seem to give inflated grades. Even when they put in some serious time making sure the review has good production values, I'm not sure they always use the product representatively. There seems to be a real crunch on time, as if they had too many items to review, and they miss too many important things about products you only get from being a daily user for at least a week or so.

You might be one of the good ones (there's no reason a priori that they can't exist -- if you've got a good bell curve, count me impressed), but in my unscientific-yet-increasingly-vast experience, compensated reviewers do not leave reviews as useful or as honest as the best reviews from actual purchasers, and it's those first not-quite-earned 4-5 star reviews that really drive sales. It's an ugly business, overall.

Labels: amazon, corruption, reviews

Gruber weighs in on the rumored iTunes reboot:

What do you see when you open the Spotify or Pandora apps? Just the streaming music you have access to. That makes them less complicated, by definition. “Everything you see is in the cloud, and you have access to it because you are a subscriber” is easy to understand. “Some of this is in the cloud, some of this you own” is more complicated.

He's joining a reasonably long list of Apple pundits with the request to split Apple Music into its own app, the most recent I can think of offhand was Jared Sinclair, whose step two of four ways to reorg Music was, "Bye, Bye, iPod - Break out all the legacy iPod features into another app."

The worst part is that, sort of like the Big Jennifer Null stuff I've mentioned recently, the iTunes confusion really was preventable.

Gruber leaves the door open on the preventable part, saying,

Maybe there’s a way to design “all your music in one app” that is completely clear, convenient, and obvious.

The four sets of Apple Music

Well, the idea Apple had was bang on. It shouldn't matter where your music lives, you should be able to sync it all. There are really only four sets of music files from iTunes' perspective:

1. Files that you brought to Apple music (no DRM)
2. Files Apple thinks it's matched from 1.) on another of your devices (no DRM)
3. Files Apple didn't match from 1.) and allows you to copy to your other devices via their cloud (no DRM)
   • This is really another version of 1, just copied to a new device.
4. Files you've only ever gotten from an Apple Music subscription (DRM)

Apple should keep 1.) around like those files are gold. Never let the user whack those without going through some sort of "locked button with cover" removal process. As Jason Snell points out, there's a real UI issue here, but also a serious functional one. "Remove download" should never throw your original files in the trash. Warn that those are files that you brought to Apple Music, and that deleting them will irrevocably remove the originals. And even then, after they're deleted, make sure users can redownload matched versions at the worst, if they were matched, without DRM, until their subscription lapses. Better is to immediately create a backup of that original file, though I realize there are cases where the user might really rather that original disappear immediately.

Files from 2.) should similarly always be downloaded without DRM. There should also be the possibility of saying, "That's a bad match; give me my original file." Maybe in version two you let the user pick from other possible matches, and then you cloud source the right matches after you get a better idea what goes where.

Files from 3.) are pretty simple. You didn't match 'em, so you let folks copy them anywhere they are logged into iTunes. It's pretty much what Dropbox does.

For the fourth, well, the only real gotcha is when they really do match something from 1.), and Apple mismatched it. But then you've already got both files. If someone tries to delete their original because it's now "duplicated", you should send them through that "locked button cover" process, and possibly have a, "duplicate match" reason there. Then you should delete the file from 4, not 1.

Note that there's another category that we're going to ignore to make things simpler -- things that should be matches that aren't matched. I'd provide a mechanism to say when something's mismatched, but if there isn't a match found and should've been, having the original file from 1.) on another machine isn't too bad. That is, there's Category 5: Things Apple should've matched with AACs they have on file and didn't. Instead of providing a way to say so in order that you get more 2.), just leave them in Category 3 until you get everything else straight. That often happens now, and it's fine.

When your Apple Music subscription lapses, you should probably also be given a final download session (that could take weeks to finish), possibly even on more than one device. "Your Apple Music subscription has ended. Would you like to download your matched and/or original files that are currently missing on this Mac/PC?"

Notice that the first three categories make up iTunes Match.

iTunes Match should've let Apple know that they weren't doing a great job of providing its eponymous function -- matching -- and they really needed to make sure they could get 1.), 2.), & 3.) right before going whole hog into a unified Apple Music. But it's still just a database management problem. They "simply" should have been much more defensive with Apple Music for when matching failed. If your user doesn't have a file three places, don't delete it.

But as long as you have a space for a flag on each file to say which it is -- an unDRM'd original*, an unDRM'd "likely match", or a DRM'd file that's never been matched -- you don't have this trouble.

It takes some great QA, but it's a straightforward, at worst tedious, process. I could make such a system without the issues Apple's seen in, let's say, six months, and I could recommend a good five or so folks that could as well.

• "UnDRM'd" could also included files purchased before iTunes removed DRM.

Labels: apple fail, Apple Music, coding, fail, gruber, iTunes, qa, rdbms

So here I am, happily streaming songs from Prime via Amazon Music, when I hear a song from Garbage I know (#1 Crush*). I know this isn't in my favorites playlist on iTunes. Why not?

I check, and sure enough, it's a B-side, and I haven't shelled out for the Garbage 20th Anniversary Super Deluxe edition. ;^) So let's see if I can just buy the single file to "add" to my plain wayne version of Garbage (the album).

Search a little, and...

Nothing. I tried a few other options, and still nothing. Lots of crush, not so much crush from Garbage. That's interesting.

Surely (Shirley?) they have the song, right?

Yes they do. And now I'm previewing it. (See it, down there at #18?)

This is as bad as the "Big Jennifer Null" problem I blogged about a while back. THIS IS NOT LITTLE BOBBY TABLES. It'd be bad enough if it was, as even "real" SQL injection should be caught by anyone worth their salt these days. But not being able to search for special characters? No, past that, not being to able to find a title that contains special characters? That's just sad. Unforgivably sad.

It's not difficult to search for a string that begins with "#", dang it. Grow up, Apple. I'm dying to fix this. Please let me fix this. As I said before about J-Null, this isn't Little Bobby Tables. This is stoooopid.

Insult to injury? When I started writing this, iTunes decided it'd take 23.7% of my CPU. I'd noticed Garbage had a new release, and was on that page, doing nothing. Not playing any music on a page without even a rotating photo carousel (thanks a lot, Draper) takes 23.7% of my CPU.

Fail, Apple. That's a huge fail.

* Ha, I can't even make an affiliate link to #1 Crush.

Pro tip: Do not search for "Hooper Mix" on the affiliate link tool for the iTunes Music Store. Borderline NSFW. Thanks again, Apple.

Labels: apple fail, coding, fail, iTunes, SQL