1. Thoughts on Google’s Acquisition of Nest

    January 14, 2014

    I don’t currently own a Nest product and now that Nest has been purchased by Google I almost certainly will never own a Nest product. Here are my reasons for coming to that conclusion.1

    1. Google has a bad track record of maintaining products: There really isn’t a lot to say here. The record of Google’s long-term maintenance of acquired products is a charnel house of badly maintained and abandoned software and services. While this isn’t a huge problem with software and services, it is a huge issue to me when we’re talking about an expensive piece of hardware that sits at the core of my home’s climate control system.

    2. This purchase is almost certainly not about the product itself: My buddy John Welch made an interesting point on App.net. There is a very good chance that this purchase is more about Nest’s portfolio of patents relating to learning hardware than it is about cornering the thermostat market. Additionally, bringing Tony Fadell into the fold gives Google something that it desperately needs: someone who actually has a clue about consumer hardware design.

    3. Google’s consumer support is atrocious: Well, Google’s enterprise support ain’t no great shakes either but let’s focus on what’s important. Everyone reading this blog has heard stories of Google’s horrific “look it up on the web / here’s a Google Group if your lucky” method of “support”. While that model is (barely) acceptable in the world of software and services it is absolutely untenable in the world of consumer hardware. This is even worse when you consider that the Nest thermostat is a device meant to connect to a system that most consumers have absolutely no experience with and, if installed improperly can theoretically destroy a system that costs thousands of dollars to replace.

      From what I’ve seen Nest has done an admirable job of making the process of tying a Nest thermostat into an existing HVAC system as consumer friendly as possible, but I’ve also read numerous tales of woe from tech luminaries unable to get a Nest thermostat to work with their system. This shit ain’t simple2

    4. I just don’t trust Google: I’ve listed this last, because the previous three points are actually sufficient for me remove Nest devices from consideration but honestly if the previous issues didn’t exist, this would be enough. I simply don’t trust Google to not put it’s all-consuming desire for data above my privacy. In some instances this isn’t an issue to me but when applied to a device that sits in my house tracking my coming and going it crosses the creepy line.


    1. Note that tribal loyalty to Apple is not among these reasons. 

    2. I have a fairly extensive, if not precisely licensed, level of experience with home electrical systems. This stuff is more complicated than the average tech pundit knows. 


  2. Will The Real iPad Please Stand Up

    November 02, 2013

    The iPad Air is now on sale and making its way into the hands of the blogoratti and the Retina iPad mini will be arriving later this month. Unfortunately this fact heralds the oncoming blitz of self-indulgent tech bloggers smugly proclaiming either the iPad Air or the Retina mini to be the “real” iPad.

    This is fucking stupid.

    I know that the default narrative in tech punditry is that there can only be one of any given thing in a category but that is a stupid narrative and it needs to stop. Proudly proclaiming that the “real” iPad has arrived, as many did after the announcement of the iPad mini last year only makes you look like an idiot. Playing the same game this year with the iPad Air is just fucktarded.

    After the initial iPad announcement in 2010 I wrote a post explaining my rationale for purchasing an iPad. In that post I posited that the iPad shouldn’t be looked at as a laptop replacement, but as a laptop alternative. The relevance of that concept as applied to the iPad Air vs. iPad mini debate is that the “correct” choice for any given person is going to be determined by their existing ecosystem of devices.

    For example, prior to the iPad my computing setup consisted of an iMac and an iPhone. The original iPad filled my need for a highly functional portable computer that didn’t force me to replicate my existing OS X environment. That need will now be met by the iPad Air.

    The contrary example would be someone who already was using a laptop; perhaps in conjunction with a desktop machine, perhaps not. For that person the original iPad would not have made as much sense and the iPad mini would have been a more likely purchase. Now that the iPad mini is in every respect other than size identical to it’s larger sibling that decision makes even more sense.

    In both cases the choice of which iPad is the “real” iPad is based on personal needs. The pundits proclaiming one iPad “realer” than the other are simply projecting their particular situation onto the general public…again


  3. Editorial Workflows: New Post

    September 09, 2013

    In my previous post about Editorial workflows I demonstrated some simple workflows that didn’t rely on any Python scripting. In this post I’d like to follow up with one of the more complicated Python-based workflows that I’m using for The Angry Drunk.

    Since my first post last week there have been a few interesting developments in the world of Editorial. First, just a few hours after I published my post, Federico Viticci announced that he was expanding his Siracusa-class review of Editorial into an eBook. I haven’t had a chance to explore the book yet but if the review is anything to go by, the book should be well worth the price.

    Second, the developer of Editorial, Ole Zorn announced a searchable workflow archive.. This is awesome news for those of us interested in developing workflows.

    Now on to the workflow.

    The workflow I’m going to discuss there is Create New Post. This workflow creates a new Markdown document at the root of Editorial’s local storage with a title and headers based on user input.

    This workflow, in its unaltered form, is probably useless to anyone but me. However it could easily be adapted to work with any blogging system that is powered by specifically formatted text files. This workflow is inspired by, and heavily influenced by Gabe Weatherhead’s Create New Time Stamped Files workflows. Here’s how it works:

    First the user is prompted to select from a list of post types. The selection is converted to lowercase and saved to a variable postType. Then the user is prompted for a post title, which is saved to the postTitle variable. Next comes a conditional block. If the postType variable is link the user is prompted for a linked-list URL. Of course this is also saved to a variable. Finally the user is prompted to chose a post status from a list, which is converted to lower case and saved to the postStatus variable.

    Next a Python script is run.

    #coding: utf-8
    import workflow
    import editor
    import datetime
    
    #gather variables
    post_title = workflow.get_variable('postTitle')
    post_type = workflow.get_variable('postType')
    post_eurl = workflow.get_variable('eurl')
    post_status = workflow.get_variable('postStatus')
    
    #generate filename
    file_name = datetime.datetime.now().strftime('%Y-%m-%d')+'-'+post_title.lower().replace(' ','-')+'.md'
    
    #generate post title and date
    post_title_case = post_title.title()
    post_date = datetime.datetime.now().strftime('%Y-%m-%d %H:%M')
    
    #generate post metadata
    if post_type == 'link':
        post_header = 'Title: '+post_title_case+'\nAuthor: The Angry Drunk\nDate: '+post_date+'\nPostType: '+post_type+'\neurl: '+post_eurl+'\nStatus: '+post_status+'\n\n\n'
    else:
        post_header = 'Title: '+post_title_case+'\nAuthor: The Angry Drunk\nDate: '+post_date+'\nPostType: '+post_type+'\nStatus: '+post_status+'\n\n\n'
    
    #generate a file with the generated file name and content
    editor.set_file_contents(file_name,post_header)
    
    #return the filename to the workflow.
    workflow.set_output(file_name)
    

    The script begins by importing the workflow, editor, and datetime python modules. workflow and editor contain functionality for integration with Editorial workflows and the editor itself. datetime is self-explanatory.

    The script then gathers the variables from the workflow via workflow.get_variable() and assigns them to internal variables. Then the script takes the post title, appends the current date, replaces all spaces with dashes and adds “.md” to the end. This code doesn’t check that the resulting filename is valid on a given OS but it will do for most simple titles.

    Next the script uses the post title and today’s date to generate the Post Title and Post Date fields used in my Pelican setup. At this point an if/else block generates the header text, including an external link if the post type is “link”.

    Then the script uses the editor.set_file_contents() statement to create a file at the root of the local storage1 with the specified filename and contents. The file name is also exported to the output of the action for the next step in the workflow.

    Finally, the workflow opens the file that was just created. I enabled the “pause” setting on this action because without it, the workflow often was trying to open the file before it was completely created. The pause setting avoids that issue.


    1. I could write the file directly to Dropbox storage, but that precludes the workflow from functioning while offline. 


  4. Editorial Workflows: Links, Images & Footnotes

    September 05, 2013

    For the past week or so I’ve been playing with the new darling of the iOS text editor world, Editorial. I won’t try to explain Editorial or review it. If you want to know more you should read the canonical review of the app from Frederico Viticci at Macstories.net.

    What I, along with pretty much everyone else, have found the most intriguing about Editorial is its powerful Workflows automation system, including the ability to run Python code. In the spirit of giving back I’m going to share a few of the workflows that I’ve built to assist in posting to The Angry Drunk. First up are a trio of workflows that don’t require any Python code.

    Disclaimer time: I’m sure that there are ways to accomplish these tasks more efficiently, feel free to prove your superiority in the comments.

    The first workflow is Insert Markdown Link. This workflow basically does what it says on the box. When invoked it will prompt the user for the anchor text, the reference id and the link URL, which will be auto-filled with the current contents of the clipboard. Let’s walk through how that works.

    The first conditional block is one that I am adding to all my workflows that act on an open document. It checks the filename of the current document and if it’s empty, stops the workflow.

    The next six actions display a text-entry dialog asking for the anchor text, reference id, and URL. As mentioned before, the URL text-entry box is pre-populated with the contents of the clipboard — presumably you will have copied a URL from some other location. I could have added some fancy logic to check the clipboard and not prompt for the URL if one is present, but this is quick, easy, and simple. After each bit of text is captured it is saved to a variable.

    The next four actions generate the Markdown code for a reference link. [anchorText][referenceText] and [referenceText]: url. Each of these is saved to a variable.

    The rest of the workflow places the generated text in the appropriate locations. First the selected text is replaced with the first bit of generated text (for the purposes of this workflow “selected text” can also mean just the caret position if nothing is selected). Next a variable is set that captures the current selection/position. Then the caret is moved to the end of the document and the second bit of text is inserted. Finally the caret is moved back to the position captured before. Easy, peasy.

    The next workflow in Insert Markdown Image. Again, this workflow does just what it says. Here’s how:

    This workflow also opens with a block to check if an actual document is open. Then, like the Insert Markdown Link workflow, this workflow prompts the user for three bits of text: the image name, the image URL, and any alt text. Also like the link workflow the image URL prompt is pre-populated with the contents of the clipboard. Again the text is saved to a set of variables.

    Next is a conditional block that checks if the altText variable is empty. If it is, text in the form ![imageName](imageURL) is generated and inserted at the current caret position. If there is alt text, then the generated text takes the form [imageName](imageURL "altText"). That’s it.

    The final workflow is the creatively1 named Insert Footnote. My blogging system, [Pelican][pelican] will generate Daring Fireball style footnotes using the code [^index] \ [^index]: footnote text so this workflow will generate notes in that style.

    The workflow starts out with our standard check for an open document.

    Next a variable is set with the current time-stamp, to the second. Feel free to edit that to work with whatever scheme you may use. Since I’m displaying footnotes on my main page, the indexes need to be unique. Time to the second meets that requirement, even if it is unwieldy.

    Then the user is prompted for the footnote text. This will look something like this:

    footnote

    Next the same trick used in the Insert Markdown Link workflow replaces the current selection with the footnote index code, moves the caret to the end of the document, inserts the footnote text code and moves the caret back to the original location. Bang, you gots a footnote.

    All three of these workflows were used while writing this post — as well as a few that I’ll detail in the next few posts.

    Have fun.


    1. Hey look at me writing a footnote…