Accepting The Worst

There’s an exhilarating freedom and motivation in having nothing to lose. History is full of amazing tales of underdog ingenuity. Likewise, stereotypes abound of the mighty falling flat, trying desperately to protect what they’ve got.

But even more insidious than actively trying to protect what you have, is frequent fretting about how to do so in your mind. It’s so easy to fall into an endless churn of worries about how your precious gains could vanish tomorrow.

This is known as loss aversion. It’s the default routing of our evolutionary brains, and it can lead to unnecessary stress, lost opportunities, and poor decision-making. But it doesn’t have to be your destiny – it is indeed possible to reroute.

The stoic practice of negative visualization is one way to do this. If you imagine, clearly and frequently, the worst case scenario, you can work on coming to terms with its consequences. Usually they’re far less dire than your worries would lead you to believe.

I’ve employed this technique from the get-go with everything I hold dear in my life. As an example, here’s how I’ve applied this to the thought that a terrible end could prematurely doom Basecamp.

[…]

We’re not running Intel, and I don’t want to have Grove’s “only the paranoid survive” as my modus operandi. I want to retain the underdog sense of having nothing to lose, even when conventional thought might say I (and the company) have everything to lose.

That’s the tranquil freedom of the stoic way.

As we get ready to officially launch, I’ve been thinking about exactly this same topic. And I’ve learned this: when you recognize what you are thankful for, you also realize that you have so much you could lose.

I think the biggest sense of fear comes from the feeling that if you deviate from a path that you have to an end that you hold dear, that you may never get around to getting back on the path. It leads to a fixation on the path, and worse still a fixation on the end.

That fixation is what I have been trying to remove myself from, and which I think I have managed to remove myself from. I’m focusing on making Data McFly great, and not on ways it may fail.

And the feedback from the community has helped stay on that path, as we get suggestions on ways to make things work in ways that work well for everyone.

This article provides some hints. Focus on the unchangeable, both about the path and end. The skills, the relationships, the learnings.

Source: https://signalvnoise.com/posts/3804-accepting-the-worst

The results of the chromebook experiment

My Chromebook experiment actually worked out great at the conference. My main dev IDE was CodeAnywhere which worked well for coding.

It won’t be able to replace my MacBook full time, but it can do the job nicely in a pinch.

The Chromebook I used was an Acer C720P, and when I first got it, I didn’t picture using the touchscreen all that much, but it’s managed to come in handy several times since then and is definitely a feature I’ve been enjoying.

Recommended Reading: The Customer Support Handbook

How do you hire the best support team? What’s the best use of social media for support and service? Should we apologize for the inconvenience? The web’s leading experts are ready to share our answers and experience with everyone, plus share stories and radical advice for building your own exceptional customer experience. In The Customer Support Handbook, leaders in customer support bring their stories of brand failures, triumphs and best practices for support on the web. Finally, all you need to create your own amazing support team in one handy-dandy manual.

If you’re a CEO Or Founder: This book is your primer on the future of customer support – not just offering transactional service but intentionally striving to make your company’s customer service the new gold standard. Learn about the importance of engaging your customer support team with your product development, how to really measure customer happiness, and why you should be investing in your support staff as your top rung employees.

If you’re a customer support professional: This book is your validation, your reminder that what you do for a living is an important part of product development and the future of the web. Learn tips and tricks for offering the best customer support possible, including example replies for tough questions, recommendations on better language and tone to use in social media, and advice on handling difficult customers.

“Customer service is no longer just a job but a bonafide career path, and this book is your undergraduate degree.” – Richard White, Founder and CEO of UserVoice

This book came up in a conversation a couple weeks ago at the AWS re:Invent conference, I recommended it to a couple people and they loved it.

Sarah Hatter has been involved in customer support for years and has taken her experience and placed it in book form so everyone can learn from it. We’ve been using this book as we build our support system and have it on the reading list for everyone involved in Data McFly infrastructure to read.

Source: http://amzn.to/1ve5rvL

Writing-first Design

A quick way to measure a designer’s maturity is to watch what they do at the beginning of a project. Inexperienced designers are often smitten by the allure of new tools and quick results, so they’ll jump in to Photoshop or Sketch and start messing with layouts and style explorations. Seasoned designers know this can be distracting, so they might start by doing research or drawing in a paper sketchbook instead.

Sketching is great, but before I start sketching, I start writing. Writing first has lots of advantages, regardless of the project you’re working on.

We’re big fans of the guys over at 37 Signals, and this post was share worthy as it’s something we do ourselves when we start a new project or task.

Source: https://signalvnoise.com/posts/3801-writing-first-design

Are you an App or a Database?

As we get ready to launch, we recently ran into an interesting and slightly minor, but also slightly major choice…

Deciding whether our data containers were going to be called Databases, Apps, or whatever other name we could come up with. We even considered calling them Pods, but don’t tell anyone that.

The decision was made to call our databases Apps, and we’ll explain this choice below.


Technically, a Data McFly App is a realtime database, but it’s more than just a database. Every App you create inside Data McFly has it’s own database and its own RESTful API, as well as it’s own authentication module.

Therefore, calling it an App was more fitting than simple calling it a Database.

Also, inside each App, you can have numerous Collections. Collections are App-wide namespaces and exist to help you organize your application’s data.

Finally, all data is stored as JSON data inside a collection.

I trust this choice of names works for everyone, and we are available if you have any questions as we near our final steps towards public launch.

Coding in the cloud: a week with a chromebook

I do most of my development work on Macs, but I recently challenged myself to take a chromebook with me on a recent conference trip.

So here I was with a chromebook, my iPad and my iPhone. And I had to be able to do work. I mostly wanted to work off my chromebook.

I’ve always been a proponent of the web platform, and I decided to “go native” on the web to find out if it could really hold up as a primary machine for a highly technical heavy user.

TL;DR: Using a Chromebook as a development machine, even without installing Linux, is possible and even pleasant. There are trade-offs, but there are also a few benefits you can’t get anywhere else.

Developing in the Cloud

When I say that I’m using a Chromebook, what I really mean is that I’m using web applications as my development tools. There’s nothing stopping anyone on any OS from using the same tools and gaining most if not all of the same benefits. In fact, if you’re on Windows trying to build with Node, Ruby, etc. the web tools might be better than what you’re using today.

I looked at several IDEs for ChromeOS, and narrowed it down to three main services:

I had a set of specific requirements for this experiment too:

  • Can I connect to my git repos?
  • Can I connect to my own servers via SSH or SFTP?
  • Cost

All three can do this but differently.

Cloud 9 IDE

Cloud 9 has been around for a long time. Their IDE is a native-quality development experience, and in many ways better than native with its integrated terminal experience.

On the other hand, the environments they provide (even on a premium account) aren’t so beefy. I quickly ran out of space with no way to upgrade it. Additionally, you can only expose one application to the outside web, making it hard to test a complex web application.

Cloud 9 does have an ace in the hole, though: you can actually connect the IDE to any server using SSH and a little install script. Right now my development environment is actually a DigitalOcean droplet using Cloud 9 as the front-end.

Pros: Amazing and configurable IDE, connect to any box, workspace state is persisted.

Cons: Wimpy provided containers, can only expose one port at a time if you’re not running your own box.

Nitrous.io

Nitrous.io was my environment of choice until a month or two ago. It was the first fully viable solution, providing a dedicated VM and an IDE on top that was good enough to make me not miss Sublime (most of the time).

Pros: highly configurable VMs (beefy box!), team features (such as box snapshots), real-time collaboration features, easy package install for most common things, can expose multiple ports on a box.

Cons: IDE doesn’t see frequent updates, state is lost on reload

Codeanywhere

Codeanywhere is one of the better choices, and they have an iPad and iPhone app that carries over your setup from the browser. You can set up your own box for development, or you can connect to servers via SFTP or FTP.

Pros: easy to set up, works from browser or from iOS devices seamlessly.

Cons: price can be a factor, but it’s manageable.

In the end, I did most of my work using Codeanywhere, it’s actually a good toss up between Codeanywhere and Cloude 9, so either of those work well.

Other Apps

Of course, there are times when you have to do a lot more than just development. Here’s a fast rundown of the various tools and extensions I use on a regular basis:

Developer Tools

  • Postman is a fantastic extension for making HTTP requests and checking APIs.
  • Text is a good lightweight text editor for viewing and editing local files.
  • Zed is an interesting text editor that lets you edit files on remote machines.

Business Tools

  • GMail for mail, Google Drive for docs, Hangouts for video chat and IM. Of course.
  • Slack for team chat. Strongly recommended.
  • Feedly for feed reading.
  • TweetDeck for the Twitters.
  • Zendesk for customer support.
  • Trello for project management.
  • IRCCloud for always-on IRC chat.
  • Draft is a great tool for, well, drafting Markdown text. I’m using it right now, in fact.

Entertainment

  • Netflix, Hulu, Prime Video, etc. all work great on Chrome OS.
  • Put.io is fantastic for perfectly legal downloading and streaming of files via BitTorrent.

What Rocks

Crash Plan. If someone grabbed my Chromebook and threw it out a window, I could be up and running on a new one in less than five minutes. Chrome OS syncs everything, even what you have installed and task bar positions. This comes in useful if you like playing in the dev channel but need to reset to beta/stable when bugs inevitably crop up.

Every Computer. Related to the above, I can pop open an incognito tab on anyone’s computer, log into Cloud 9 or Codeanywhere, and get to work quickly. I’ve used this in real life both while visiting family and on public computers when emergencies arise.

The Interface. When everything’s just a browser tab, multi-tasking is actually super-pleasant. I find tabs and pinned tabs to be a better way of contextualizing my workspace than app switching ever was.

Peripherals. I was worried this would be a pain, but it’s actually seamless. I work on an external monitor with a Logitech USB mouse most of the time. Plug-and-play holds up in Chrome OS.

What Sucks

Media. There are no decent graphic, sound, or video editing programs for Chrome OS. Most often I find myself missing Illustrator, but if you’re heavily reliant on any of the Adobe tools then you won’t be able to make a go of the Chromebook just yet, though Adobe has announced a Photoshop cloud setup for Chromebooks shortly. Also, a Chromebook obviously isn’t a gaming machine.

Connectivity. You do have to be connected to the internet all the time period to be productive on a Chromebook. Well, ok, you can install Ubuntu but that sort of defeats the purpose. While this isn’t a problem 99% of the time, that 1% of the time it can be pretty frustrating.

Wrapping Up

The biggest advantage of a cloud development environment is its ability to be wherever you are. My ability to be productive from anywhere on any machine with an internet connection has more than made up for the occasional frustration with a lack of some native tool.

YC without being in YC

Another older post, but one that is interesting to follow as we build Data McFly.

Why not just pretend we were in the program. When you’re in YC, going from zero product to a launched product in 10 weeks is the name of the game. When you’re not in YC, building something that fast feels overwhelming.

For the next 10 weeks, we tried to mimic each step. We wrote up our various ideas as if they were YC applications. I re-read a bunch of Paul Graham essays and got myself back in the mindset. Once we landed on an idea (it was an enterprise travel product), we gave ourselves 4 weeks to get to Prototype day, just like YC. We demoed weekly–to each other, other entrepreneurs, and our investors. It wasn’t as good as Tuesday night dinners, but it worked–our productivity shot up as we wanted to make significant progress each week. After that, the pressure was on to launch something. We held off working on a business deck stuff until our Demo Day approached.

I was amazed how simply adding some YC-like structure to those several months made everything we were doing feel better. Before that, we had been pretty lost. But once we pretended to be in YC, we were motivated because we had a schedule to hit.

When we started building Data McFly, we set a similar schedule and we are currently on track to keep it.

Paul Graham’s essays are also good reading. There is no set of YC secrets that he hides from the rest of the startup world. In fact, much of what he says in person simply reinforces the advice that he has already doled out through his essays. Having watched him for several years now, I also find that if he starts to give out new advice within a YC batch, you will soon find that idea better articulated in an essay a couple of months later. The same goes for many of the other YC partners who give their advice out for free in their blogs.

Another good resource from the Y Combinator crew is Start up School, which also hosts all their speaker series videos on youtube from their site so it’s good to set aside some time to watch some of them.

Source: http://blog.42floors.com/yc-without-being-in-yc/

Getting Real

When we decided to add a push notification system as a service to our system, we looked into types to offer.

We decided that the easiest system for the sake of browser support was to integrate Socket.IO as our web socket system of choice.

This lets us support web sockets, and if needed also lets us fallback on multiple other methods, such as Adobe Flash sockets, JSONP polling, and AJAX long
polling, while providing the same interface. Although it can be used as simply a wrapper for WebSocket, it provides many more features, including
broadcasting to multiple sockets, storing data associated with each client, and asynchronous I/O.

This works well for you, our future users, as it helps you build your applications quickly and enable real-time communications as part of it.

The Parts of Your Platform

The post we are linking to was published back in March, but it’s relevant to today and what we are building, hence why we are sharing it.

The simpler devices get, the more complex our jobs as developers becomes it seems.

We’ve been there ourselves, having been building various apps since the late nineties in various capacities, this is a feeling that is all too familiar.

Data McFly’s data services are stable, and have been around for a year for our own personal projects before deciding to launch it as a backend service for other developers.

Ignoring the cloud or web services because they are out of your comfort zone is no longer an option. The app economy is shifting. Adapt or die.

This is true, and we have been building our service to be easy to work with regardless of your development skills.

At launch, we plan to have adapters for:

  • PHP
  • Ruby
  • Node
  • Javascript (jQuery)
  • AngularJS
  • Python
  • iOS
  • Android

This lets us work with the majority of web apps, and since we are a REST API service, it also helps us be easy to adapt to other platforms as well.

In fact, thanks to our usage of our system over the past year, we’re already running on several of these platforms, as we’ve integrated heavily into several web and mobile apps.

And of course, any languages we miss, the community is welcome to write. 🙂

Source: http://carpeaqua.com/2014/03/26/the-parts-of-your-platform/

Welcome to Data McFly

Welcome to the first post of the Data Mcfly blog.

We’ve decided to use Camel, with a continuous deployment via Github to Heroku as the blog engine for the Data McFly blog.

What is Data McFly?

Data McFly is a soon-to-launch real-time cloud data-storage service designed to be easy to use via our REST API.

Stayed tuned for more as we start on an exciting adventure 🙂