Gistify just keeps getting better!

Gistify 1.2.0 is now in the App Store, and features some awesome drag and drop magic. Drag a snippet of text or an entire file onto the Gistify icon and a new gist will be created from your file. The format of the file will automatically be detected, and the resulting gist URL added to your clipboard just as usual. Amazing!

In addition to that big new feature, 1.2.0 features a number of bug fixes and performance improvements: for example, now Gistify will properly start up if you check the “Open at Startup” box, and you can copy and paste in the GitHub username/password fields (for the 1Password or LastPass users out there). Just small quality of life improvements generally.

Interested in giving Gistify a shot? Go download it now! Or if you’d like to demo it without paying the $1.99, just let me know and I’d be happy to set you up with a review copy.

My last post on RubyMotion generated quite a lot of interest, and I’ve been asked a few times for my opinion on the recent RubyMotion bugfixes (like correcting RM-3 and RM-32). I thought it sensible to revisit this issue a month later to discuss the changes the HipByte team has been making and what they mean for the future of the RubyMotion project.

I updated the code here based on my production experiences with it in a new post, Sidekiq + Houston: Production Ready. Check it out after reading this article.

Having not updated rapnd in a good long while, I was looking for well-supported, up-to-date solution for persisting long-running connections to Apple’s push notification service through a worker. I didn’t run into anything offhand, and also haven’t posted a helpful code snippet in awhile, so this is how I connected Houston and Sidekiq to Apple’s Push Notification service.

Based on recent bugfixes and refinements by the RubyMotion team, I’ve posted an update to this blog post. Check it out after reading this article.

I’m a big proponent of RubyMotion – a year and a month ago, I wrote an article titled “Why RubyMotion is Better Than Objective-C” and despite its divisiveness I still stand behind the points I made. Recently I’ve been doing a lot of OSX and iOS coding, coming out with a Mac app and working on a new iPhone app for a client. For both projects, though I initially evaluated RubyMotion, I ended up settling on using Objective-C. Given that my blog post is frequently cited as a reason to adopt RubyMotion, after more than a year of its use, I wanted to weigh in on why I believe it isn’t an appropriate choice for production applications.

I heard an argument recently that the data collected by PRISM was safe from abuse because if the government had the technical expertise to gather the data, it had the competency to secure it as well. While on the face of it this statement is flatly absurd, its derivatives can seem plausible:

• “The data is only used if a court approves.” (The fallacious assumption being that the government can reasonably control access to the PRISM data.)
• “The government is trying to protect us by safeguarding this information in one place.” (Of course, the idea that this centralized database’s existence has made said data more secure is preposterous.)
• “You had no assurance of privacy on the Internet anyway, so why should this bother you?” (Because while I can take reasonable steps to make my own data secure, once it’s in the government’s hands it’s their responsibility, and, as should be abundantly obvious, leaks happen.)

It’s easy to believe that a government agency capable of collecting this information and then keeping its existence a secret for so long must have a way of keeping it safe. Unfortunately, the access that was given to the NSA to take this information has no correlation to the skills necessary to secure it; and the very fact of PRISM’s existence will probably prove too enticing a target to remain secure for very long.

Essentially, the argument as I heard it can be expressed as a simple question: if the government is savvy enough to gather the data, surely they’re not incompetent enough to lose it? Unfortunately, big brother can indeed be both savvy and incompetent. I think this is the greatest danger to the data PRISM allows access to – not improper use or excessive domestic surveillance, but complete and outright theft.

Hot on the heels of my previous announcement, I’m proud to announce the release of Gistify version 1.1.0. And after submitting only four days ago – man, the Mac App store moves incredibly fast compared to the iOS App Store!

Anyhow, Gistify, the incredibly awesome Mac App that lets you gist quickly and easily, just got a whole lot better. Now you can sign in to your GitHub account to make gists, and set the visibility of your gists to either public or private Also the app screenshots are no longer quite so, well… drab, for lack of a better word.

If you haven’t downloaded Gistify yet, you should. While I’m slightly biased, I’ve been using it all the time and I think it’s an incredibly handy tool – after all, that’s why I released it. But if you’re not convinced yet, or you’re just interested in giving it a shot without paying the $2, let me know and I’ll be happy to hook you up.

Today I’m happy to announce the release of my very first Mac App: Gistify!

Gistify rather simply delivers the content of your clipboard to GitHub’s awesome Gist service. You can select the default format for all gists and override it on a gist-by-gist basis, and the resulting URL is appended to your clipboard so you can paste it wherever you like.

Simple? Yes indeed, but I desperately wanted it. I made this initial version rapidly to scratch an itch I had – and perplexingly there’s not an existing desktop app that seems to do this already. (There are competing apps that paste to other services, but for some reason none work properly that post to Gist.)

In terms of future plans, I already have a new version submitted for approval to Apple! Version 1.1.0 will allow you to sign in to GitHub and create gists under your username: additionally you can toggle the visibility of gists to either public or secret. And in development is version 1.2.0, which will introduce all kinds of new mind-blowing awesomeness.

So what are you waiting for? Get over to the Mac App store and buy Gistify!

(Oh, and if you like the icon, it’s by the super amazing Luke Beard.)

Today I released Huey version 2.0.0! Though it contains a number of small bug fixes, the biggest change is switching away from SSDP to using the Hue’s own bridge discovery protocol. This is both faster and more extensible – now when you make the initial request for the Hue bridge IP, it takes a fraction of the time SSDP did. And you can also manually specify the IP yourself, like so:

1
2
3

Huey.configure do |config|
  config.hue_ip = '123.456.789.012'
end

With some clever port forwarding on your router combined with this new option, Huey is now usable on servers outside your local network.

SSDP is still easily enabled if you prefer that over this new method, or find that the Hue bridge discovery API is problematic. Huey just keeps getting better, but let me know if you run into an issues with it at the repository. Happy Hueing!

The title of this post might be somewhat misleading: it’s probably pretty obvious to you why your startup is failing. The same reason any business fails – you’re spending more money than you make. For some tech startups, though, living in the red is (perplexingly) a desirable state of existence. Still, you can’t stay forever in an unprofitable limbo. Eventually investors start asking awkward questions like, “When will I see a return on my investment?” and “How can you possibly be spending so much of my money without making any in return?”

Shortly afterwards they stop giving you money and then you know it isn’t long until the end.

Maybe you’re there right now, or staring down the barrel of that gun. I’ve seen it before; I know what it looks like. You’re not alone. If you haven’t gone off the cliff yet, it’s not too late to save your tech startup. You will have to make some hard decisions, though. Whether or not you can do that will determine if your company is salvageable, or if you’ll be making one of those “What I Learned As An Ex-CEO” Hacker News posts that are all the rage these days. So how do you fix your failing startup? Good question! First, we have to understand why you’re failing at all. Afterwards, we can move on to fixing it.

Overengineering is a special subset of the generalized problem of “making bad choices.” Usually overengineering is the result of one of two specific bad choices: either adding too much unnecessary bloat to something relatively simple, or creating a customized solution when many out-of-the-box alternatives already exist. After running into these problems over and over again, I’m going to quantify and identify them so that you and your friends can avoid the perils of overengineering.