Parable of the Thing

There is a Thing. It doesn't really matter what it does. The Thing does a thing, and that thing can be useful. Or at least amusing.

Unlike certain Things, I like this Thing. The idea for the Thing came from a man who wanted a Thing for himself, and who wanted to sell the Thing. He was thinking of a freemium model, where you get the free version on the App Store (he was thinking an iThing, not an Android Thing, but a mobile Thing not a web thing) and pay a buck or so for more Thingyness in your life.

Who wouldn't want a Thing, right?

I hadn't played with this Thing before, and was apprehensive at first, but as soon as I worked out how to talk to the Thing, I found it very useful, developing two separate uses almost immediately. Because free access to the Thing is how we attract an audience, that's not a problem. For my uses, tying a Thing to a Widget or Sneech does everything I need it to, and so I say "Thing, do your thing" on occasion, and Thing and I are happy.

But, for the man to get his Thing going for the whole world, there are some requirements.

Having the Thing do his thing on a phone, waking up every few minutes and saying "Fellas, I'm ready to get up and do my thing", getting into it, and then going back is very wasteful of the phone's resources. It's almost as if it's only purpose is to suck the battery of the phone, which is not a thing a Thing is intended to do.

And/or, I am not an iPhone developer. I don't have iGear. I don't know an iPhone developer, at least none who are willing to work within the Thing's budget. Take your pick.

So, we stand up a server. Which takes money. Perhaps not a lot of money, but eventually, money.

Then, the app part of the Thing is simply "Thing, this is what you do." This might happen once in the lifetime of the user-Thing relationship, if the user knows what the Thing needs to do. So, that's one show of an ad. So that's not a moneymaker.

Then, as it's on the server, we need to tell the user the Thing did his thing. With Twilio and SMS, the choice that forces the least use of other services, we're at, roughly  3/4 of a penny for every SMS. This is small, but this is a charge every time the Thing does his thing, so we're losing money every time the Thing moves for free people, and for the paying customers, after Things 133 times, it's all cost.

So, I like this Thing and I'll use this Thing, but it won't show up on a phone near you. But I might put the code up on GitHub sometime, so there's that.

On Market Research: Programmers Are Not People

"I have an idea for an app. This web service does A, B and C, but I really want it to do D."

You sit across the table from me. This is your idea, and you are excited by it. Maybe not as much as you were when you thought it up two weeks ago, but excited enough to meet with me on a Saturday.

I like the idea myself. I've always found getting through the OAuth barrier to the data itself not worth the time, but I broke through the day before the meeting and have done enough to know that it's finding out what the API has available that's the main issue. Your excitement is infectious, and I've caught it.

Then you ask a question. You ask the question.

"Do you think people will pay $1 for this?"

There is one thing you need to know at this point.



People have been running away from the command-line and toward windowing systems, web browsers and phone apps for over 30 years.

I have six terminal windows open right now, simply because I've been slacking off and don't need more right now.

People want tools to make their lives simpler.

I write tools to help me manage my complexity, to keep necessary complexity complex but hide details until they become important.

People have several thousand emails in their inbox.

I have several dozen folders and have my tools automatically sort my mail so that only the most blessed things actually stay in the inbox, and learned the intricacies of IMAP so, when the options available in Thunderbird and other ways do not allow me to do exactly what I want to, I write my own tools that give me exactly, precisely what I want.

People have phones which alert them whenever anyone sends them anything.

I have prioritized a few people in my life — parents, wife, children, boss, coworkers, friends — and anyone else who wants my time and attention will get it when I feel like granting it, and not a moment before.

People consider creating a PowerPoint stack as effective computer education.

I am offended by that thought.

I look at the developments of the last few years and am excited. The Internet of Things doesn't mean the rich have another channel to the bedrooms of the poor, it means I can control the bits of my house like I can control the electrons in a computer. Quantified Self doesn't mean that I'm a cog in the Big Data machine, it means I have a backdoor into the complex system of my body. Streaming and Cord Cutting mean I spend more time watching videos people made of the amazing things they learned to do, how they do them and how you can too than I spend watching actors pretend to be doctors, lawyers and policemen.

I figured out how to do that task for myself and run it every ten minutes. I enjoyed the process more than I enjoy watching Monty Python, and Monty Python is the bomb.

People use Windows and Mac because they don't want the hassle of real computing.

I use Linux because I want, I need, I revel in, I'm drunk with the power that I get from real computing. And I know that, as things go, I am barely scratching the surface of what's possible, and I know people who take it far beyond what I am.

Do I think people will want this app? I think people will want to learn to program, to find out how things work and how to make it work for them.

And I am wrong.

For purposes of this conversation, I am not People, I am  Kang or Kodos, orbiting the Earth in my flying saucer, To Serve Man in my left tentacle while I blink my one yellow eyeball and ponder the subjugation of Springfield. I don't want to be that person. I don't want to be trapped in a bubble-helmet, wondering what those meat-sacks want.

To switch references, what I do have are a very particular set of skills, skills I have acquired over a very long career. Skills that make me necessary for people like you. Making this work? Finding all the data? Plugging in everything? It's what I do.

But I love what I do. I don't really understand why people don't do what I do. And that's a good thing. You want me at this keyboard, you need me at this keyboard. I don't understand why you don't pick up a keyboard and occupy a standing desk. Why would I do anything else?

But don't ask me about what people would do. I'm the last person to know.

Why I Am Ambivalent Toward Developing A News Aggregator Tool

I am involved with a project that combines Internet of Things and Quantified Self. Because I'm first and foremost a web/server guy, I'm joining in at the web/server level, and as the team is working on the hardware prototype, there isn't much for me to work with yet.

Because of this, and because the project leader is using the shotgun approach to find funding, including creating a news aggregator in the field the product will service. As we're OMG so pre-alpha right now, I'm not going to get too far into details about what we are and what we're doing, but I will engage the concept head on. (The project manager has received the full rant already.)

In the late 1990s, a standard for an XML format was developed called RSS. This can mean Really Simple Syndication, and in essence, if you put out a blog, it was an XML list of the last 10 or so posts. They added in payloads, pointing to the location of media files, and that, connected to the iPod, was the genesis and fundamental technology for podcasts.

Keeping track of the lists became a job of Aggregators, and another XML format called OPML was created to allow the transfer of collections of RSS feeds from one aggregator to another. These allowed you to find all the RSS feeds you want, group them into different subjects, and take in all the news you care to.

Then Google came in and created Google Reader, which is the best, most solid, most usable RSS aggregator mankind has ever known.

They closed it in July, 2013.

There are other aggregators -- I use Feedly -- but the excitement is largely past. Instead, now there are Curators: sites that find links other people put up about a topic, defined narrowly or broadly. Boing Boing is a curator site that's about "the weird, wonderful and wicked things to be found in technology and culture", which is essentially everything the curators of BB find interesting. More narrowly, there are sites like Slashdot ("News for Nerds"), LifeHacker (small changes you can make to supercharge your life), io9 (Science Fiction and how the modern world is like Science Fiction), Jalopnik (Cars), Ben Greenfield Fitness (exercise, diet and other things leading to fat loss, muscle gain and enhanced endurance), I Heart Guitar (guitars and amps and pedals, mostly gear-centered) and so on. Often, they have podcasts or vlogs associated, as well as written content.

The key here is these are curated: there are people who read all the sites and get all the news about a subject, filter and digest the results, and create content explaining the information involved in the link. They have writers, and the writers have interests and opinions and color. I Heart Guitar and Stratoblogster cover different things because I Heart Guitar and Stratoblogster have different personalities and interests.

Additionally, there's "deep and narrow" and domains of interest. I Heart Guitar is not going to tell you about the reissue of an obscure 70s folk-rock record, and Aquarium Drunkard is not going to tell you about the new mini Tube Screamer pedal, and neither is going to tell you about what Justin Bieber is doing this week. (I'm sure there's a curated site that'd tell you, but since I don't care about pop music, I'm not sure what it is.)

A site curated for music fans would contain announcements for upcoming tours and albums, and "lifestyle" interviews with entertainers. This is Rolling Stone. A site curated for musicians and people who want to be musicians would contain reviews of instruments and gear, instructional material about how to play songs and styles, and interviews with musicians and producers focused on how they play and who they listen to. Guitar Player, Guitar World, Acoustic Guitar, etc. You don't see questions about guitars, amps and string gauges in Rolling Stone, and you don't see interviews without them in Guitar World and Guitar Player.

So, for the domain-specific part to work, you need a sense of which corner of the audience you're going for, and you need someone, maybe a few someones, who spend a good fraction of their waking moments reading about it, digesting it, and creating content from it. I has to be a curator, not an aggregator. I will not spend more time than I have already creating "Like Feedly, but just for this!" I am not going to try to succeed where Google failed. Creating that is a waste of your time, of the audience's time, and finally of my time.

If you introduce me to that person, the person who will be spending 40+ hours a week learning everything there is about the topic and creating copious amounts of content, from text to images to maybe video, I'd be glad to help you stand up a WordPress site and enable that person to be the Cory Doctorow of his field. For an hourly rate.

But I cannot work on that AND work on our IoT/QS project.

I can work on that OR our project.

I'd much rather work on our project.

On the Uselessness of Campus Tech Support, or "Go Away, Kid. You Bother Me."

In time, this story will be one I think about and laugh.

I am not there yet.

There is a student-led group whose charter is to find interesting people with interesting stories, coach them a bit, and have them tell those stories to a larger audience. If you think you know what I'm talking about, you're probably right. And I'm their web/tech guy. In general, this is a bit of a "fixer" role: "You want to tell the world about something? You want an image on the web page? Got it. Done."

I went to our website before a meeting two weeks ago, preparing to fix some of our donor pages and set a link for ticket sales, and found it wouldn't load. Both on my Windows 7 laptop and my Android phone. I went to the admin console on the hosts' site and that worked, but the page wouldn't load. Nor could I connect via FTP. Traceroutes went so far, then died out. And, while traceroute was further than other people took it, there were other people in the group who could not connect to our website.

I called tech support, and the engineer said "works for me".

I turned off my phone's wifi and connected via 3G, and it came up just fine.

And I felt so stupid, because I should've tried that first.

And I felt powerless, because now this meant I had to engage campus Tech Support.

I work fairly regularly with the computing group on campus, mostly in the Big Iron corner of the department, and, when I can address an email to Larry and write "Hey, Larry? Our VM is down, and my boss wants it up", Larry is uniformly intelligent, prompt, professional and helpful, and my problems are uniformly respected and solved. (There is no actual "Larry", but the people who whose names I could use are good people who I don't want to include in a spittle-flecked rant such as this.)

But, when I submit a trouble ticket, I know I'm going to have a bad time.



For reasons I'll get to later, I say that Tech Support is batting .0030. I gave them a 90% chance of dropping the ticket without any interaction at all, and a 75% chance, if I get a reaction, of being turfed to someone inexplicable.

At the end of this process, this is what I can say:

• At home, over wifi, everything works just fine.
• On the phone, over 3G and 4G data networks, everything works just fine.
• At various places with wifi around town, everything works just fine.
• Over the wired campus network, everything works just fine.
• Using the primary campus VLAN, which uses the same DNS server, it doesn't work.
• Using the VLAN connecting to a large telephone company, everything works just fine. (I found this out very late, and this is why I consider this "solved" but not solved.)
• Using a VLAN created so that academics from other institutions can use our network with their credentials, it doesn't work.
• Replacing the DNS server provided via DHCP with Google DNS doesn't work.
• Flushing the DNS cache doesn't work.
• While I am 100% shut out, with my mobile gear, there are other people who are not, using similar gear.
• Last time I had reason to work on this on campus, around Thanksgiving, everything worked just fine.

I found this problem in a building dedicated to an engineering discipline, and rechecked and sent the trouble ticket in a building used by the Computer Science department, so of course, when I got turfed, they sent me to the deal with the agricultural colleges' tech support team. 

They told me to try to flush the DNS cache. Then, when they learned that I was trying to connect to a server hosted by a commercial entity with a personal laptop, they declared "We're not here for fixing your computer, we're here to fix university equipment. Go Away, Kid. You Bother Me."

This is reasonable. I get that. And, I get that right now, there are networking people who are working 12-hour days because they're short-staffed.

There are two reasons I object to that argument.

First is, as I explain above, the problem is localized to the campus' VLAN. When I try to connect with the same access points but with the phone company VLAN, it works. When I try to connect with the campus wired network, it works. This means the problem is not:

• Campus DNS
• The server
• My laptop
• Software on my laptop

What remains? 

Second is, there's a pattern of behavior, of using this excuse to get out of fixing their network.

Example 1: There was supposed to be wifi in my lab. There was no wifi in my lab. Trouble ticket. My netbook. "Go Away, Kid. You Bother Me." I tweet a picture of my netbook physically touching the antenna but with the local VLAN not showing. One of the nice guys named Larry saw it and talked to the networking people. A tech came out. I recall the access point having scorch marks on it when he replaced it, but I might be embellishing the story in my mind.

Example 2: My old Android phone could connect to wifi, but once the connection was up, nothing would happen. Trouble ticket. My smart phone. "Go Away, Kid. You Bother Me." I download full IP tools, and eventually determine that, by the netmask, the IP address they gave me was not on the same network as the gateway. I conjecture that they didn't change the netmask when they grew the size of the DHCP pool, and I sent in the solution. A week later, my phone worked on their network.

The pattern, to me, is clear. They don't want to listen to their users, and you have to narrowly define the issue, to the point of true solution — "The access point is dead", "The networking configuration is crazy wrong" — before they will act. In this case, it's further into the networking stack than I can even think through. Most of the time I see "This is the protocol; Give me this configuration data and it works like thing that works well, but when you get something wrong, it's like a brick wall", so when it gets so specific — no protocols going from this one machine (and maybe others) to this other machine (and maybe others) will work, but in general, all is okay" — I'm out of my depth. My suspicion is that there's an unroutable internal local machine related to the VLAN that shares an unroutable private address with an unroutable machine at the hosting company, but that doesn't quite hold water and I have no way of testing that.

I have a "solution": Never use the university VLAN. This goes with my second "solution": Never submit a trouble ticket. It isn't the first "solution" I've had to use because the campus Tech Support has been so unhelpful, but as I don't have a real solution, I don't have any idea what's going on with things, so even if they were listening, I wouldn't have anything to say.

I'm the fixer. I'm supposed to make things work, and I'm lost. I don't have a solution, and they wouldn't listen if I had one. I think that's what angers me the most.

Perl Implementations of anyPass() and allPass()

allPass() takes an array of code refs containing tests, and returns a function which takes a value, runs the tests on that value, returns false if any test fails, and returns true after all the tests.

anyPass() takes an array of code refs containing tests, and returns a function which takes a value, runs the tests on that value, returns true if any test passes, and returns false after all the tests.

Thanks to Michael Hurley of Ramdas.js for letting me borrow his names and ideas, and for everyone who told me how to make things better.

sub allPass {
    return 0 if !@_ ;
    my @f = @_ ;
    return sub {
        for my $t ( @f ) {
            my $r = &$t( @_ ) ;
            return 0 unless $r >= 1;
            }
        return 1 ;
        }
    }

sub anyPass {
    return 0 if !@_ ;
    my @f = @_ ;
    return sub {
        for my $t ( @f ) {
            my $r = &$t( @_ ) ;
            return 1 if $r >= 1 ;
            }
        return 0 ;
        }
    }

How I Post Code

/var/log/rant is my code blog. When I want to rant about code, I rant here. And, often, rants about code include code.

My old way of handling it is to use Blogger Syntax Highlighter, where I put in a PRE tag where name is "code" and class is the language in question. I have it set as defaulting to "python", so if I forget to remove it, it doesn't come off as Perl for Iron Man Perl if I'm blogging about something else. It is very powerful, but problematic in escaping characters, so I'm easing away from it.

My more standard way these days is to create a Gist on GitHub and including it in the code. This does mean that Javascript must be enabled. Because it's much simpler for me, I'll likely do this more and more.

So, if I'm talking about code but you don't see code, try allowing Javascript, and I'll try to remember to put direct links to the gists.

A Higher Order Idea stolen from Ramda.js

Start with Paul Bennett, who is a Perl guy I know from Google Plus. He pointed to a function in Ramda.js, which allows you to create a number of filters as anonymous functions, put them in an array, pass that array, and do that test in one line.

// Instead of 

if ( x > 10 && x % 2 --- 0 ) { console.log( 'Big and Even' ) }

var gt10 = function(x) { return x > 10 }
var even = R.allPredicates( [ gt10,even ] ) ;

if ( f( x ) ) { console.log( 'Big and Even' ) }

Now, imagine if we're testing several things, rather than just one.

I thought "Hey, there's so much I could do with this in Perl. I've been thinking about writing a mail filter that takes a function Higher Order Perl style, so could generate a function based on the config file and pass it into the middle of Mail::IMAPClient so I don't have to generate a menagerie of one-trick ponies. This, of course, is a fairly big idea to work with, and the allPredicates is small enough that, with a half-hour of working through Perl I mostly thought I knew, I came up with this. Fifteen lines of code. I am happy.