Menu

Colin Devroe

Reverse Engineer. Blogger.

Follow: @c2dev2, RSS, JSON, Micro.blog.

'

Attending September’s NEPA.js meetup

On September 12th, NEPA.js held its September meetup. Anthony Altieri presented on beacons – the typically small Bluetooth devices that “chirp” some very basic information multiple times per second allowing app developers to understand the proximity of a user. This allows for things like understanding where a shopper is in a retail space.

His overview of the devices, the spec, some of the software, and the differences between iOS and Android, and iBeacon and Eddystone – was a really nice introduction into the space. He did a great job.

I learned a lot during his presentation. Thanks to him for putting it together.

If you haven’t yet been to a NEPA.js and you live in our area – I implore you to check one out. It is consistently attended, always fun, and isn’t always focused solely on JavaScript. But even if it was, it is worth your time.

A unique color for every address in the world

A recent, yet-to-be-announced client project had me designing a mobile app interface that dealt a lot with showing locations and events that are happening at certain locations (how is that for vague? sorry).

While I utilized the brand’s colors to represent certain sections of the app I wanted the app to have tons of colors in order to portray a sense of fun throughout the app. But how could I incorporate pinks and yellows and bright greens without the overall brand disappearing?

After toying with a few design ideas I had an idea to create a unique color for every address in the world. This would result in two benefits; first, each location was then branded as a color, and second, every user would see that location as the same color. If I were a user of the app here in the US and I flew to Spain and looked at a location for an event  there, I would see the same exact colors representing that address as the person that lived in Spain and created that event.

Since I wasn’t to be the developer of the mobile application I wanted to avoid the possible pushback this idea might receive from that team. I didn’t want to add burden to the other people on the project by showing a design mockup and a set of requirements and then walking away. I wanted it to have zero overhead for the developers.

One of the solutions I discarded was generating a random color each time an event location was added to the service and then store the color for that address in a database. While this solution is relatively simple to implement it was no good. It adds more work for the developers and they have to maintain the datastore indefinitely. Several other ideas with the same caveats came to mind and I quickly tossed them into the bin.

Once I eliminated all of the ways I didn’t want to solve this problem – the solution came pretty quickly.

Since every address is already unique, I just needed to find a way to represent an address that could be turned into a color. In other words, I wanted the address itself to represent a unique color. And I wanted to do it in realtime as the application’s UI loaded.

So I jumped into JavaScript and began working it out. Here is what I settled on:

This solution allows for just over 16.5 million colors. Far more than this app will likely require during its lifespan.

Here is a demo of the process and if you view the source you can see the code at work. It is fairly simple to follow.

Oh, there was an issue that I ran into with this solution that was fun to solve. If the background color that was generated was too dark the text became hard to read. So digging around I found a way to determine the luminosity of the background color and thus change the text to something a bit lighter in those instances. That too is shown in the demo.

I was then able to repurpose this demo code and give production-ready code to the developer that is going to ship in the app. When that ships I’ll write more about it.

Colin Walker: “Should replies be posts?”

Colin Walker, in a post on whether or not replies to other posts (or, comments) should be their own posts:

There has to be a line, a point where a comment is just that and not a reply. It’s a question of semantics but not everyone’s answer to “what is a comment and where does it belong?” will be the same.

I struggle with this a lot.

It is likely the point I should have made in my post regarding Micro.blog becoming a commenting service (and the fact that I don’t like that). I don’t want to reply on my blog to every reply to my posts on M.b because then I would have dozens and dozens of posts on my blog that would be very tough for readers to follow contextually. I believe the commenting mechanism that has been around for decades, even un-threaded, is far more useful than dozens of desperate posts stitched together loosely with a link that says “in reply to”.

Webmention attempts to bridge that gap between post and reply but that also is tough to follow along if the thread gets unwieldy.

However, I also don’t want to reply to every reply on my posts directly on M.b either (though, I do from time-to-time) as that isn’t much better than using any other silo like Twitter or Facebook. Should M.b go away, all of those conversations would be lost.

This isn’t a new issue nor is it exclusive to M.b. If I replied on my own blog to other people’s posts on their own blogs (like I am in this post to Colin Walker’s blog) then one side of the conversation could disappear at any time. I can only control my side of the equation. But at least if I have my own blog I have control of that one side.

I think it is good that these topics are being discussed again. The same debates have been swirling since blogging began, they swelled again when the indieweb movement began to take shape, and I think they are happening again as a result of M.b’s growing community. I do not believe there is one single answer to many them. You have to do what is right and sustainable for you.

For now, here are my personal rules for replying to posts. These will most definitely change over time.

  • If I want to say a quick “congrats” or “excellent post” or something of that nature I will leave a reply directly on their blog. If they do not have commenting turned on I will attempt to email. If they do not have email publicly available I’ll say nothing at all.
  • If I have something substantive to add to the conversation, or if I would like my “followers” to see the post I will quote the post on my blog with my additions to the conversation. Like this post.
  • If I simply want to direct people to the content I will use my new repost tag that I’ve been experimenting with. I’ve seen others use the “a post I liked” type post. That could work too.
  • If people reply using M.b, Twitter, or Facebook I will not reply on those services*. But I may reply on my own blog.
  • If I would like to keep my reply private I will attempt to email.

As an aside: I know some of you do not want to leave a public comment. I love getting reader emails. I get a fair number of them. And some of them have been excellent conversations. So please don’t hesitate.

* I no longer have a Twitter or Facebook account. I do have a M.b account but I’m beginning to wonder if I need one as I have my own fully functional weblog. If I didn’t and I wanted a microblog and didn’t want to use Twitter, I could see having an account. If I wanted a more fully featured blog I still believe WordPress is the best tool for that. Also, I’m sure as the M.b community grows it could mean that my content would be discovered by more people. I think M.b may end up being a thriving, well run, community and service. It is why I backed Manton’s efforts via Kickstarter. But, if I have my own blog, and if I really don’t care much about my content being discovered, then I see little reason to syndicate to it. For the time being I’m still going to as I want to see how the service matures.

Presenting at the August 2017 Lehigh Valley Tech Meetup

The Lehigh Valley Tech Meetup is an excellent community in the Lehigh Valley that meets monthly at the Ben Franklin Technology Partners incubator within the Lehigh University Mountaintop campus. The community around the meetup is excellent and the building is amazing*.

While the tail-end of my presentation walked through my experience building my first iOS app Summit, the majority of my presentation was focused on helping early stage companies think about their go to market strategies.

I’m currently advising several companies, a few of which are businesses built around mobile apps, and have heard about 11 other start-up pitches this year so far. And during that time I’ve noticed a trend. Entrepreneurs that are attempting to build a business around an app sometimes underestimate the amount of thought that should go into the marketing and sales strategy for the app. It is as if some feel that apps are less thought and work than products that you can touch. So during my presentation at LVTech I hoped to convey that the same “boring” (yet, tried and true) business practices that apply to products also apply to software.

A few questions I urged those thinking about building a business around an app were:

  • Does your idea service a large enough segment of the market? We hear the “scratch your own itch” mantra a lot. However, it won’t always lead to finding hundreds, thousands, or tens of thousands of customers.
  • How will you reach those customers?
  • Are there ways to expand your idea into other products or services that can be sold to the same segment?
  • How will you sell or package your idea?
  • What will the price be? (free, one-time payment, subscription, service contracts)
  • What channels can you leverage to sell your idea? (App Store, retail, online, conferences, distributorships, via a sales force)

By considering these, and may other questions, you can determine if your idea has enough layers to support an entire business or if you just have an app idea**.

I also briefly discussed three misconceptions I’ve been seeing over the last year dealing with very early stage start-ups. These misconceptions were:

  • Press-based launch strategies: some thing that by being covered by press will be enough to get them to profitability. They have no other strategy. On the contrary, getting press coverage early on will give you very muddy analytics which will make decision marking very difficult. Very seldom are the tech audience your real customers.
  • How long until profitablilty: More and more entrepreneurs begin with the plan of losing money for 3 or more years. I believe this stems from press coverage of other companies getting large rounds of funding. Most businesses should strive for profitability within the first quarter or year of business.
  • ”I’m not technical, I need a technical co-founder”: Don’t be this person. Anyone can learn to code. Geeks are not smarter than you. They’re just interested and relentless. Be the same.

We then did about 10 minutes or so of questions and answers. The questions I got were really great and I appreciate all those in attendance helping me with the answers to the questions I didn’t have much experience in.

Thanks to Tim Lytle for the invitation to speak and to Ben Franklin Technology Partners for the continued support.

* I worked in this same building for years while at Viddler. But when I worked there the back half of the building didn’t exist. In fact, Viddler started in Jordan Hall – the building just beside the new building. And now, they are extending it even further. The building is an amazing place to work and have a meetup of this kind. I’m jealous that our incubator in Scranton feels so dated when compared to this building. Especially comparing the meeting spaces.

** It it totally fine to “just have an app idea”. I do. And I’m loving working on it. But it is also good to have the proper perspective about your app idea.

Summit – The Adventurous Step Counter

This evening, at a presentation at the Lehigh Valley Tech Meetup, I’m opening up public beta access to my new iOS app, Summit – The Adventurous Step Counter.

I’ve stitched together a temporary web site for the app as well as a mailing list that will allow you to get access to the final few beta builds prior to public release. If you have an iPhone please consider signing up and giving it a spin. I’d be very grateful for your feedback.

Thanks to the 13 private beta testers who have already tested the app and provided feedback. You can expect a brand-new build of the app coming in September.

What is Summit?

Summit is a free, iOS-only app that uses your step count to virtually hike up tall peaks like Mount Everest in Nepal, learn about amazing landmarks like Diamond Head in Oahu, and even take a leisurely stroll down famous streets like Lombard Street in San Francisco. As you make progress on your journey you’re provided new information at each goal.

At the time of public release there will be 5 summits and new summits will be added each month thereafter.

Here are some screenshots of the app as it is currently:

When I started on Summit I did not know how to develop an iOS app. It has been really fun to learn Swift, Xcode, iTunes Connect and Test Flight, and the myriad other things I was able to learn in order to get this app as far as I have.

I still have a bit of work to do, but I’d love your feedback along the way as I finish the app up for release.

My personal blogging tips

I’ve been writing things down on my own blog for a few decades. I wish more people did too. If you’d like to have a personal blog but struggle finding things to write about, here are a few tips that may help.

  • Don’t post about what you will do, post about what you’ve already done – In other words, I try to avoid the “I should blog more” posts and just get on with blogging more. Also, I like posting photos and status messages sometime after they’ve happened.
  • Find a theme – Niche blogs do extremely well. So stay on topic. Personal blogs do less well but they should still have a theme and that theme should be you.
  • Create reasons to post – My What I saw series and observations series give me a reason to write. Should I feel writer’s block I can fall back to one of the series.
  • Have a schedule – I try to post one or two posts per day prior to 9am. Some are scheduled in advance some aren’t. Everything else that happens is completely random.
  • Be totally fine with missing the schedule – Sometimes I don’t blog for a few days or weeks due to time off away from the computer or just being focused on something else. And I’m totally ok with that.
  • Don’t post test posts – Create a staging or a local development environment to test your site’s features. It is really easy to do.
  • Try not to care about stats – Stats are useful for a number of reasons but obsessing over them won’t help you at all. Check them once a month to see how you’re doing.
  • Create an inspiration list – In your notebook or notes app write down some topics you’d like to write about someday. Make it long. Like, 50 items. Don’t worry too much about what should be on it just start writing the list down. When you can’t think of anything to write about look at that list and simply pick any one at all and check it off.
  • Subscribe to a bunch of blogs that interest you – More than likely the conversations started by others will give you more than enough to write about.
  • Perfect is the enemy of good – Just hit publish.
  • Have fun! – I’ve thoroughly enjoyed blogging all these years and I don’t imagine I’ll be stopping any time soon.

If you have a neglected blog or are just starting one – jump in! Oh, and don’t forget to email me the URL.

Attending the August NEPA.js Meet up

The NEPA.js Meet up is really hitting its stride. Each meet up is pretty well supported – even in the summer – and the camaraderie and general feeling around each event is pretty great. Also, the Slack channel is pretty active.

If you’re within an hour or so of Scranton I’d recommend joining the meet up group, jumping into the Slack channels from time-to-time, and attending at least a few events per year. If you need help with any of these things send me an email.

Also, within the past few weeks we’ve seen a new group spin out of the NEPA.js group. A more general meet-and-work-on-stuff type of group created by Den Temple. This event fills the gaps for when there isn’t a NEPA.js group event.

This month’s presentation was by Ted Mielczarek. Ted works at Mozilla on build and automation tools for Mozilla’s primary product Firefox. He has, though, dabbled in a variety of other things at Mozilla like crash reporting and the gamepad web API. It was his experience building this API that spurred this month’s topic; Web APIs.

I remember jumping onto the web in the 90s and being blown away when I was able to put animated GIFs of X-Wing fighters on my personal Star Wars fan page. Today, web browsers support a variety of Web APIs that make the open web a true software development platform. There are APIs to control audio and video, to connect to MIDI-enabled devices, to connect to Bluetooth, VR and – of course – to allow for game controller input. There are lots of others too.

Ted did a great job showing demos of many of these APIs. Just enough for us to get the idea that the web has matured into a powerful platform upon which just about anything can be made.

Thanks to Ted for the work he put into creating the presentation and to all the attendees for helping the NEPA.js community thrive.

Following Twitter accounts via RSS

I haven’t missed Twitter that much since deleting my account. The first week or two I missed Moments – but once that subsided I realized that Moments are generally a waste of time. Realtime reporting of most newsworthy events result in ill-informed, unsubstantiated tweets. I’m at a point now where I’d much prefer to get the real story after-the-fact rather than realtime.

There are instances where realtime reporting can be incredibly useful, such as when there is a fire, a traffic accident, or a natural disaster happening. Those tweets can save lives. But, in general, I’m perfectly OK with reading up on the news once or twice daily to see what really happened.

I do miss certain Twitter accounts. Especially those that do not have a blog or web site counterpart that I can follow along through another medium. And since Twitter is still web and developer hostile (meaning their API is far too limited and they don’t support open web distribution technologies like RSS) I’ve missed out on a lot of great content from those Twitter accounts.

So today I went searching around for some RSS feed generators that would use what little access to Twitter they have (presumably the limited API or HTML scraping or both) to create an RSS feed from accounts or hashtags or lists. And there are a number of services out there, some of which you have to pay for, others that toss in some ads, or others that are severely limited.

Then I found Publicate. I’m using Publicate’s Twitter RSS Feed Generator to create a few feeds based on some Twitter accounts I miss the most. You simply type in the URL you want to create a feed from, give them your email address*, and they provide a feed URL. So far it seems to be working. I’ve created a new collection in Feedly to store these feeds. Hopefully I’ll get the tweets I wanted to see most and I won’t have to deal with the drivel and hate I’ve seen on Twitter over the last 18 months. Or even Twitter itself!

* I certainly don’t mind my email address being a form of payment to a company. So I gave it to them. But, if you’re a bit of a hacker it is quite easy to dismiss the overlay, read the page’s source, and grab the feed URL without giving Publicate your email address. I want this tool to stick around so if my email address helps them to keep it up-and-running so be it.

Snapchat is a party, LinkedIn is a business lunch

Colin Walker, like me, struggles with what should be syndicated to networks and what should be brought back into the blog context. He makes this specific point about replies:

Social replies like on Twitter or Facebook don’t, in my opinion, need to be owned – they belong in the context of the social network and that particular conversation.

I suggest reading his entire post so that you get a clearer picture of his struggle.

As you may know I’ve decided to leave social networking altogether and so I don’t have this struggle any more. However, one analogy came to mind when I was reading Colin’s post.

When Snapchat arrived on the scene many in the blogosphere thought it was crazy to have such an ephemeral medium sucking up so much oxygen. I didn’t see it that way. Perhaps I didn’t love Snapchat but I didn’t see it as bad simply because you couldn’t save what you posted there. It reminded me of going to a local pub. If you drop in at a pub for a pint and rattle off some diatribe about your favorite sports team to the other pub-goers – does that really need to be saved somewhere? If I’m having a random conversation about a movie I saw recently while sitting around a campfire with a friend, does that belong in the Internet Archive?

If we view each site on the web as a real physical place then we begin to realize that some places are museums, some libraries, others local pubs, and still others are rowdy nightclubs. Each have their place to make up the human existence but not all need to be saved or syndicated or shared.

I simply do not view Facebook and LinkedIn and Twitter and Snapchat and Instagram the same as I do my blog. So I do not believe that all of the content that I post here should end up there and vice versa. Some things deserve to disappear. And there is a certain beauty in that. The same way I enjoy a good local pub rant.

Colin’s struggle is real – it isn’t easy to choose what gets saved and what doesn’t. What should go to one network and not another. Especially in the moment it is very difficult to know. And, it is complex for a single person to maintain that connective technology to allow that to happen in the first place.

I don’t envy his position. I don’t know what I would do if I were him. But, for me, not being on any social media currently has made my decision very easy. What I share here stays here. Everything else you’ll never see. And I’m totally cool with that.

Observations on using the iOS 11 Public Beta

The iOS 11 Public Beta is the first beta OS I’ve installed from Apple. I did so in part because I want to help improve the OS by providing feedback and analytic data, but also because I wanted to test my aforementioned app that I’m building, and lastly I’ve wanted driving mode since very early iOS days.

I waited until the second developer beta (which was the first public beta I believe) was released before I updated my iPad. And I waited until the next developer release (or, second public beta release) before I updated my iPhone. I waited in hopes that there would be a great enough improvement in these builds that I didn’t have to worry too much about my iPad or iPhone not working at all.

I thought I’d jot down some observations during my use:

  • So far the “biggest” problem I had was charging my iPad. During the first public beta the only way I was able to charge my iPad was by first plugging the lightning cable into the iPad first and then plugging that cable into a power outlet. Weird, I know. But the next public beta has seemingly fixed that.
  • While there are minor UI niggles that could be easily pointed out, I’m going to refrain since they seem to be cleaning up the loose ends very quickly. This last public beta build fixed a slew of issues.
  • Driving mode is beginning to work very, very well. I’ve had trouble starting a song via Siri via Apple Music after a podcast episode in Overcast is finished playing – but perhaps that will get fixed in an upcoming release. Overall, this feature is going to be a lifesaver.
  • The style and controls aesthetic are much better in my opinion. Previous releases of iOS attempted to be too “elegant” (unsure if this is the term I’m looking for) by being overly thin and translucent. This latest release of iOS brings some sanity to the UI. Also, as I get older I’m beginning to appreciate the larger text sizes throughout.
  • The new App Store should prove to be a huge improvement over the previous versions. It remains to be seen whether or not Apple’s team will keep up with the editorial (since they’ve yet to update any content in there) but I’m hoping they’ll do this part great when the time comes.
  • Though I use iCloud Drive, Dropbox, and other file sharing platforms I’ve not put the Files app to the test just yet. Perhaps I don’t see the need for it as much as others will. I’ll report back after I’ve used it more.
  • The Notes app is incredibly good at this point. I switched to it from Simplenote and I’m loving it.
  • iOS 11 shines on the iPad.
  • The new keyboard on the iPad is particularly cool. You essentially pull down slightly on a key as you type if you’d like the letter you’d usually get by holding down the shift key modifier. Great idea.
  • Oddly enough, the new multitasking capabilities on iPad don’t work as well yet for me as the old way. I’m sure I’ll figure it out and get used to it but the “dock” and dragging icons out of it, etc. does not work for me very well. It could also be that apps haven’t yet been released with support for that feature.
  • iOS 11 has “broken” a ton of my apps. Not beyond usability but I’m guessing that developers are scrambling to get new iOS 11 builds ready. Some of the oddities could be very difficult to fix.
  • coreML and ARKit are incredibly cool.

While I don’t yet recommend updating to iOS 11 Public Beta for most people – if you’re willing to deal with a few hiccups the driving mode feature may save your life. I can’t imagine going another day with out it. Apple can not get this version of iOS out soon enough in my opinion.