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.
Thursday, January 31, 2013
Wednesday, January 30, 2013
AWS as a Twitter Alternative
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.
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.
Labels:
Amazon Web Services,
S3,
twitter
Tuesday, January 29, 2013
Beautiful Software You Can't See
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.
Author: Joe Moreno
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.
Author: Joe Moreno
Monday, January 21, 2013
Twitter is Down
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.
The interesting part is how fragmented the Twitter conversations became as others quickly stepped into to fill the Twitter void.
http://threads2.scripting.com/2013/january/outageTheater
http://news.ycombinator.com/item?id=5094389
http://news.ycombinator.com/item?id=5093964
http://status.twitter.com/post/41136790651/twitter-site-issue
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.
The interesting part is how fragmented the Twitter conversations became as others quickly stepped into to fill the Twitter void.
http://threads2.scripting.com/2013/january/outageTheater
http://news.ycombinator.com/item?id=5094389
http://news.ycombinator.com/item?id=5093964
http://status.twitter.com/post/41136790651/twitter-site-issue
Labels:
twitter
Sunday, January 20, 2013
Why Have I Forsaken RSS?
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?
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?
Thursday, January 17, 2013
Being an American
How often do we natural born Americas take our citizenship for granted? Probably as often as we take simply being born for granted. It just happened. We didn't earn it, it was given to us.
This afternoon I crossed paths with Roni who hails from Iraq. I didn't know him before today. He was so excited about passing his exam and becoming an American citizen today that he couldn't contain himself. As he rang me up at the cash register he told me how nervous he was about today's exam and now that he'd passed he was having a big party, tonight, to celebrate his first day as an American.
Even though I had literally sworn my life to support and defend the Constitution and follow the Code of Conduct ("I am prepared to give my life in their defense.") I still take my citizenship, health, and life for granted. I need to remind myself of this more often.
This afternoon I crossed paths with Roni who hails from Iraq. I didn't know him before today. He was so excited about passing his exam and becoming an American citizen today that he couldn't contain himself. As he rang me up at the cash register he told me how nervous he was about today's exam and now that he'd passed he was having a big party, tonight, to celebrate his first day as an American.
Even though I had literally sworn my life to support and defend the Constitution and follow the Code of Conduct ("I am prepared to give my life in their defense.") I still take my citizenship, health, and life for granted. I need to remind myself of this more often.
Roni became one of America's newest citizens, today. For most, it's given; for Roni, it was earned. |
Labels:
Life
Sunday, January 6, 2013
Volunteering at the San Francisco Food Bank
The day before the game my alma mater's alumni association decided to team up with midshipmen to help out at the San Francisco Food Bank which covers two counties. The San Francisco Food Bank feeds the programs and the programs feed the people.
We spent the afternoon packing apples. A "ton" of apples. Actually, we packed nearly twelve tons. The apples were delivered to the food bank in large boxes which we sorted out (the good from the bad) into thirty pound boxes. These apples were supposedly less than ideal from large grocery stores but I have to admit that they were in great shape. I personally packed more than a thousand individual apples and only rejected about half a dozen.
Each year approximately 130,000 volunteer hours are donated to the food bank which is the equivalent of about 55 staff members. The thirty pound boxes that we packed would go from our hands into people's stomachs in about 48 – 72 hours.
Most of us were volunteers along with some high school students who received class credit. Last, but not least, were some scofflaws doing their community service to work off their unpaid parking tickets – they were easy to spot since they seemed the least thrilled to be there.
I'd love to do this volunteering again. It's definitely not backbreaking work yet it still makes a difference.
Friday, January 4, 2013
Happy Birthday Apple?
When I saw this piece Happy Birthday to Apple earlier today I was reminded of a large meeting I was in with Steve Jobs back in aught-two when someone in the room congratulated him for founding Apple 25 years earlier, in 1977. Steve's response to the well-wisher was that Apple was really founded the previous year, in 1976. Steve commented how hard he and Woz had worked in 1976. To Steve, that first year was, naturally, a much bigger deal.
One thing that I noticed during my time at Apple was that Steve's responses were rarely what you'd expect. Sometimes, he'd point out the obvious and other times his answers were opaque. But, regardless of his answer it was usually a positive learning experience.
Once, after going over the iPhone sales figures with both my boss and his boss we concluded that there just weren't enough customers with Cingular/AT&T to reach the iPhone market share numbers that Steve had recently announced, in January 2007. I briefly laid out Cingular's/AT&T's customer base to Steve and then I asked him how Apple planned to achieve the forecasted iPhone market share. Steve's direct, yet pleasant response, which we had overlooked was that Apple would also be selling the iPhone in Japan to make up the difference. We were humbled amateurs in the presence of greatness.
In that same meeting a coworker asked Steve which companies he admired most. Steve took a surprisingly long time to think about his answer. It seemed like a solid sixty seconds of silence. While he contemplated his response I speculated on his answer. Would he say Google, Amazon, Nike, etc? As he slowly shook his head he responded, "I don't know. I'd have to think about that." This lead to even more speculation as to why he didn't have a concrete answer.
I've seen raw footage of Steve's interviews where he would pause for a long time knowing full well that the dead air would be edited out. He was also not shy during a taped interview to stop and ask for a retake. After all, why not do everything possible to look your best?
Later, in that same meeting about companies he admired, Steve spoke about company culture and how proud he was that Apple was a "California company." Hmm, I thought, what makes a company a California company? I figured that it was the same thing that makes a financial company a "Wall Street company" or an advertising company a "Madison Avenue company."
The right company in the right place makes a world of difference. Location, location, location, along with superb execution.
The right company in the right place makes a world of difference. Location, location, location, along with superb execution.
Labels:
Apple,
Steve Jobs
Subscribe to:
Posts (Atom)