In the ancient days of social media (circa 2008) people frequently said, "I don't get it." Back then, people didn't realize that social media was simply taking our spoken conversations about nothing and moving them online. But, as more and more people got involved an interesting crowdsourcing phenomenon began to unfold.
I first observed this crowdsourcing solution in the fall of 2008 when Guy Kawasaki forgot his MacBook power supply.
At the time, I was at home about 40 minutes away and I could have easily made it to Coronado by the top of the hour. After thinking about it for five minutes I responded to Guy's tweet but it was too late. Jerry Jones had sealed the deal. However, I did get an honorable mention from Guy (back then, my Twitter username was @JoeLeo.)
About two years later, I explicitly and successfully tried crowdsourcing to figure out the name of song. It's amazing when it works.
What struck me, today, is that crowdsourcing via social media still works. So much so that we simply take it for granted.
Last week, I reminisced about telephone landlines. I was imagining a home phone solution where my cell phone would link to a ringer so that I could hear it ring throughout the house without carrying it from room to room.
A college buddy quietly observed my tweet and found what I had described when he was shopping at Costco, today. We joked that he was my personal social shopper. He found several models, but the Panasonic KX-TG155 seemed to foot the bill as he passed along a photo of the collateral.
Everything in the universe has a life cycle. And I mean that literally, not in a metaphysical sense. It doesn't matter if it's the trees, birds, stars, planets, or people; they come into existence, exist, and then go out of existence. This is even true for dogs.
This afternoon I said goodbye to Cocoa, my beagle buddy for nearly 12 years. It's the first time that I ever experienced this, so I wondered how I'd know when it would be time. This past week he'd been having trouble keeping food down so he was prescribed some meds several days ago. Unfortunately, that didn't help. Another trip to the vet, yesterday, and some x-rays revealed large masses in his abdomen that were squeezing out his healthy organs. The vet pointed them out on the x-rays and her words were very grim and unexpected when she said that he'd have only days left since he wasn't eating. Last night, I made it a point to take some self-portraits and videos of him and me.
After a long night, last night, of seeing him trying to sleep while being uncomfortable we took him in this morning for some fluids and pain meds while making arrangements for his final vet visit tomorrow. The vet made it clear that he'd seem more like himself after the fluids and pain meds, but not to misinterpret that as a sign of things getting better.
After returning home, this morning, he and I curled up on the bed for a couple hours. That entire time he only moved once. His breathing was labored and more and more frequently he'd stop breathing for 10 – 12 seconds. I'd watch his chest wondering if that was his last breath. He'd become more and more finicky about what he'd eat over the past week but, yesterday, he gobbled down some rotisserie chicken without vomiting. Unfortunately, that didn't work today. He just looked at the chicken without any interest. The prospect of him not eating or drinking all day foreshadowed what would be a long, painful night.
After making a phone call to the vet his final appointment for tomorrow was moved to 4:00 PM today. I posted and tweeted the pending visit and then went offline, shutting down my iPhone and leaving it at home. It would be almost six hours until I was ready to go back online.
Having never gone through this I was pleased to see that the vet's office had a "comfort room." This small room was made up like a living room with a comfy couch, large ottoman, and a music player. There was a CD in the music player and when I hit play I heard the most gentle, soothing, appropriate piano music for the moment. There was a large curtain covering the window and, as I had correctly suspected, behind the curtain was a door to the parking lot which I parked next to. A private entrance out of the comfort room made a world of difference when leaving.
The vet came in and took Cocoa into the back to give him a sedative to put him, literally, to sleep. She brought him back into the comfort room and we just pet him for about ten minutes. When the vet saw that the sedative hadn't taken effect – he was clearly fighting it – she took him into the back for another dose. That did the trick. About six or seven minutes later Cocoa was sedated. Actually, it seemed more like he was paralyzed as the tip of his tongue hung out of his mouth while his eyes remained opened and blinked occasionally.
The vet tech used hair clippers to shear off a small patch of fur on his rear leg and then the vet stuck in a catheter needle and administered two drugs. As the vet had foretold, Cocoa's eyes didn't close as life left his body. After the vet confirmed that his heart had stopped she apologized as if she had been personally attached to this dog and this was an exceptionally rare event for her. The unexpected caring was extremely comforting.
Was it the right decision? Was it the right time? Certainly. But that doesn't make it any easier and I still can't imagine how empty this house will be without him. The heartbreaking part is that this little guy looked up to me for his daily needs and there was no way that I could make him understand what was going on. And, the sad coincidence of all this is that six years ago, today, my father passed away. But, ironically, I think it'll be easier to have a single day to remember dad and dog.
You don't have to write computer code for very long before realizing that you're going to spend a lot of time inside a text editor. And, a good chunk of that time is going to be spent debugging.
In many disciplines, there are only a few fundamentals. In boxing, there are only four basic punches: jab, cross, hook, and upper cut. In computer execution, like DNA, there are only two states (zero or one; or A-T or C-G, respectively). It's amazing what can be created with just two possible states mixed up in endless combinations.
In computer science, most programs continuously do three basic things:
1. Declare (foo = bar or NSTimestamp now = new NSTimestamp());
2. Test (if now > later then a=b or if snow > 6 then school = "closed")
3. Jump (GOTO 500 or JMP SIGNON)
Which begs a question that I've been pondering. Centuries from now, will computer programming still involve editing text? After all, programming is just a static form of communications between man and machine (pardon the sexism, I'm going for alliteration).
For many millennia, humans have primarily communicated statically, through writing. There are obviously other forms of communications, such as speaking and non-verbal communications (just stare at a stranger for a long time to communicate "I am creepy.") But other than writing (to include images), it's not really fixed (without the aid of technology, e.g. video).
So, just like building a house has always involved assembling small things like bricks and boards, will coding still involve text editing in the 23th Century?
At Microsoft, perfection is achieved when there's nothing more to add; while Apple believes that perfection is achieved when there's nothing more to take away.
Two completely different philosophies held by two highly respected and industry dominating competitors. Microsoft is a marketing company (you don't get 90+% of the desktop market without marketing your way there) while Apple is a product company (build great products and profit will ensue).
It's not having a great idea that will make a great company; rather it's having great execution.
I've noticed on my iOS Facebook apps that, under the chat feature, they display how recently it's been since my friends have been active on Facebook. In other words, the last time they accessed their Facebook account (minutes, hours, etc). This could easily lead to some animosity if you send a message to someone and later saw that your friend had accessed Facebook but didn't read or acknowledge your message. You might think, "Hey! Why is so-and-so ignoring me?"
It took a lot of searching to figure out how to turn off this time tracker (which, in this day and age, means more than half an hour on Google followed by some experimentation). It turns out there isn't a specific setting on either Facebook's website or in the iOS apps to turn this off. The only solution is to completely log out of your Facebook apps on your iOS devices. Since this isn't very practical it looks like iOS users are stuck with this creepy feature that broadcasts how long it's been since they last looked at their Facebook account.
Fortunately, this time tracking feature doesn't seem to be an issue when on the desktop or Blackberry. I wonder what the Android user experience is.
Dots Last week, I discovered an interesting Gmail trick that allows you to place a dot (.) anywhere in a Gmail e-mail address (before the @). In other words, e-mails sent to the following e-mail addresses will all be received in the same account: joemoreno@gmail.com joe.moreno@gmail.com j.o.e.moreno@gmail.com Pluses There's an older trick that many Gmail users know about which is to place a plus sign (+) after your Gmail username and before the @. It's a perfect solution when you sign up for a service and you're worried about the company spamming you. With the +CompanyName@ it's easy to filter out specific e-mails. E-mails send to the following addresses all end up in the same account. joemoreno+Walmart@gmail.com joemoreno+Geico@gmail.com joemoreno+Meetup@gmail.com The dots trick doesn't work for your e-mail addresses that use Google Apps for hosting e-mail (i.e. johndoe@example.com). It only works with e-mail addresses that end with @gmail.com. But, the pluses trick does work with Google Apps accounts as well with Apple e-mail addresses ending in @mac.com, @me.com, and @icloud.com. The best part is that this behavior works right out of the box – there's nothing to configure with Gmail or Apple.
I originally drafted this piece on August 17, 2012 but didn't publish it until speaking with Dave Winer, today.
After yesterday's API announcement from Twitter, do we really need an open alternative? Probably not. Your average Twitter user doesn't care and won't notice, but here's the litmus test - it's one that App.net is currently going through. Let's build it and see if they come.
A tweet is, at most, 160 charters of text. That's 140 charters prefaced by a username. Of course it can be longer when we start adding in metadata. But, my point is that it's just short messages full of text characters. The big challenge is that Twitter is a system that's both a static blog and a dynamic communications system. It's one of the first main stream systems to serve those two purposes, similar to Usenet.
You only need to look at a couple Amazon web services to see that they've not only implemented a scalable infrastructure for a Twitter alternative, but they documented the API so thoroughly that any third party could reimplement the API and decouple themselves from AWS, if they wanted to.
How Would It Work?
If I were to implement a simple Twitter alternative it would behave like RSS with push notifications. They key is that you'd have to be able to read, post, mention, and follow via a web browser without needing to set up your own server. This is not as hard as it seems thanks to JavaScript. If we can make this work while running inside of a web browser, then building a desktop app or server to augment the basic service would be simple.
Overview
Notification is the easy part. Simply use AWS SNS to post updates to followers who are subscribing (following you). SNS updates would be posted to each follower's SQS queue.
The hard part is where and how to store static tweets. Originally, I proposed storing them as linked lists in DNS TXT records. Dave Winer pointed out that, although DNS could scale like this in theory, it probably couldn't in reality. He said that we already had the scalable solution with AWS S3. So, my proposal is to store each tweet as either standalone text or as an HTML webpage in an S3 bucket. Each S3 object contains the entire tweet with a link to the previous tweet and the next tweet. Any third party app could access these tweets and the links and meta-data could be nicely stored in the the S3 object HTML headers. (S3 HTML headers begin with x-amz-meta- and they're beautiful for associating meta-data with S3 objects.)
The Rules
1. Users would sign up for SNS and SQS.
Users, in this context, would be users of the service who could be the developers. They, in turn, could build apps that abstract this so the layperson user wouldn't need to sign up for SNS or SQS.
2. If you want to follow someone, you subscribe to their SNS notification and use your SQS as the endpoint for message delivery.
3. If you want to message (@) someone, you post to their queue.
AWS already has APIs to handle permissions so each user can block followers.
4. User's AWS credentials can be stored in their own web browser database. This eliminates the need for a third party database server that could be compromised.
________
January 30, 2013: This is still a work in progress with some unanswered questions, but, since it was tweeted about, yesterday, I dug it out of my drafts folder and published it.
There was some discussion, yesterday, asking: What's the most beautiful software?
Most of the answers were front-end consumer or knowledge worker systems such as the original Macintosh or VisiCalc. One thing that these systems all had in common is they were revolutionary end-user solutions that you could see or touch, which got me thinking: What about software you can't see?
As a software developer, I'm partial to some middleware systems. My personal favorite is Enterprise Objects Framework (EOF), but it's very abstract, making it hard to convey its importance as one of the first database-to-object-oriented mapping systems.
Two better examples of software that you can't see or touch, which relates to consumers, are Carbon and Rosetta. These two pieces of software effectively breathe new life into Apple in 1997 and 2005, respectively.
Carbon
Carbon allowed software that was written for the original Macintosh OS (sometimes referred to as Blue Box or Classic) to be compatible with Apple's new operating system, Mac OS X. Developers only needed to recompile their Classic app under Carbon and it would run, natively, on Mac OS X with minimal tweaks. Software that was no longer supported and not recompiled under Carbon would still work, nearly seamlessly in Mac OS X, by launching Classic which was, effectively, the virtualization of one OS (Classic) within another OS (Mac OS X). An elegant solution.
If you were a Mac developer and you wanted to survive the turn of the 21st Century then you'd recompile your apps under Carbon. Hence, "all life is based on Carbon."
Rosetta
While Carbon allowed developers to transition from Mac OS 9 (Classic) to Mac OS X (Unix), Rosetta allowed developers to transition from a PowerPC (PPC) hardware architecture to an Intel CPU. Steve Jobs gave a brilliant keynote during the 2005 WWDC by failing to mention, throughout the first half of his presentation, that he had been running his demos on an Intel based Macintosh until he finally said, "We've been running on an Intel system all morning."
Rosetta was Apple's solution that allowed PPC binaries (executable applications) to run seamlessly on Intel based Macs. What made this software so beautiful was that it was undetectable to users when Rosetta was running. Switching to Intel not only reduced power consumption, which was key, but it also allowed Windows to run either natively or virtualized, instead of emulated, on Apple's Macs.
Unseen, yet truly beautiful software.
And, in case you're wondering, my favorite software nowadays is ForeFlight for the iPad which has revolutionized cockpit resource management (CRM) for the single pilot.
Yup, Twitter is down. I can't recall the last time I've seen an outage like this. Although it was very frequent back in 2008 – 2010, it has been extremely stable the past couple years.
While Twitter's not 100% down, it's mostly down. It's been having fits and starts all afternoon. I guess that's like being mostly-dead, which is slightly-alive. It really depends how you're accessing Twitter (web, client, api, etc) and from where.
For years, I had been using Safari's RSS reader since that was my primary web browser. At least that was true until this past summer when Apple removed RSS from Safari. I was on vacation at the time so I only took a quick cursory look around the Mac App Store for a replacement. The best option that I found was Cappuccino, but it really didn't answer the mail for me.
Since then, I took a look at RSS readers but none were as convenient for me as Safari's native RSS functionality. Firefox has a built-in reader and Google Reader is quite popular, but each requires the extra step of opening a different app or visiting a website. Changing my habits, after years of getting news the same way, is going to take a little work.
Without explicitly realizing it I found that I was now getting all of my news updates via Flipboard on my iPad. Flipboard is nice in that you can point it at websites, Twitter, or RSS feeds using its search feed. The other beauty of Flipboard is that it presents news more like a newspaper or magazine rather than in a list format like most RSS readers. The downside is that Flipboard only runs on my iOS devices, so I still didn't have an desktop solution.
So, now I'm wondering if this will be the progressive evolution of RSS? In the same way that most programmers no longer code in machine language or assembly, will RSS evolve primarily into a middleware layer, that's still important like a CPU's registers, instead of a feature designed for the average end-useing consumer?
About two years later, I explicitly and successfully tried crowdsourcing to figure out the name of song. It's amazing when it works.
