I’ve also left you with a new look to get used to.

****************************************************
I recently got invited to Google Voice and have been playing around with the SMS and my Peek. So far, I have been able to hand out one number to friends and family to text me. I don’t have to text them first and I’m not limited to 25 people.

Let me give you an overview of how the texting system works with Peek.

When a text is sent out with the Peek, it is processed in the Peek systems, then sent to 3Jam, then sent to the carrier & cell phone. When the text is coming from the cell phone, it follows this line in reverse. As you may or may not know, each Peek is provided with 25 virtual numbers. As you text a number, one of these virtual numbers is attached to that mobile number.

Example:
Peek Text to 2125557000
Text sent to 3Jam
3Jam assigns number 4243541000 to 2125557000
Message on the receiving end shows it came from 4243547000

If you text under 25 people then, there is nothing to worry about. Each person you text can add the phone number assigned to them to their address book to text you. If you text over 25, the number starts to revolve. You are limited to these 25 different numbers and you have to text them first. Also, the people that you text cannot share the virtual number they see amongst themselves – it is assigned to that person and that person only. You also cannot text Peek-to-Peek.

Google Voice

Google Voice changes this. It changes this to ONE number, your friends/family can share this number, and you can text Peek-to-Peek. The only limitation is that they have to text your Google Voice number first.

To get started using Google Voice, you’ll need to wait for an invitation. You can sign up for and invitation here: https://services.google.com/fb/forms/googlevoiceinvite/

Once you receive your invite, please follow the setup wizard on the site to get started. You do have to enter an existing phone that you use. If you want this for your Peek only, you can choose not forward message to your phone by going to Settings > Phones, and uncheck the phone. Also, go to Settings > Voicemail & SMS, make sure SMS Forwarding is selected to forward SMS messages to your email address.

Great! You’re almost ready. Next you’ll need to send a text from your Peek to your Google Voice. 3Jam will assign a number to Google Voice. You will see this number come up in Google Voice once the text is received.

Next, have people text your Google Voice number. You only need to give them your Google Voice number. When Google Voice receives the text, it will forward it to your email address. Pay attention to the From field.

In the From field you will see an email address in this format: 12125551234.14243541000.tyldksal1@txt.voice.google.com

Here’s the break down:
12125551234 – your Google Voice Number
14243541000 – number the message was sent from. If from a Peek, this number is a number from 3Jam
tyldksal1 – unique ID Google Voice assigned to the number the message came from. Works similar to how 3Jam works for Peek. Only you’re not limit to 25 but people, but they have to text your Google Voice first.

Now, to send a reply to them on your Peek you have to type in that entire email address: 12125551234.14243541000.tyldksal1@txt.voice.google.com

Messy right? Thank goodness for an address book.

When you send a message from your Peek in the above manner, the same text-message traveling routine written above applies, however, now after leaving (from Peek device) or before hitting (to Peek device) 3Jam it goes to Google Voice. Google Voice parses that To field apart: Your number, Text number to send SMS too, Google Voice Id assigned to the Text number. The message gets routed to your account (your number), then Google Voice sends the text message out from your account as a text message to the Text number. You can see texts you send from your Peek on Google Voice because of this.

The texting Peek-to-Peek is capable because Google Voice routes the text as a text to the number you specified (along with its ID). On the Peek it will show as a text. When you or the other Peekster receive a text from another Peekster, the text category of the message stops at Google Voice, and then forwards the text to your or the other Peekster’s email account as an email message, if they use your Google Voice number only. If they send a text message from their Peek in that messy format, [your google voice number].[your number 3Jam assigned to your voice number].[google voice id assigned to your 3Jam number]@txt.voice.google.com, the message will go to from Device > Peek > 3Jam > Google Voice > 3Jam > Peek > Device (sent as text the whole way). It’s a lot of hoops to go through but Peek-to-Peek texting works using Google Voice.

To summarize:
After setting up Google Voice, go to Settings > Phones, uncheck phone
Next go to Settings > Voicemail & SMS, SMS forwarding – make sure your email address is used for forwarding
This email address should be on your Peek

Text your Google voice number from your Peek – 3Jam will assign a number to this number, Google Voice will assign an Id to this 3Jam number

If you want texts to be sent to your Peek as a text, not through your email box, then people will have to text to your full Google Voice SMS number: [your google voice number].[your number 3Jam assigned].[google voice id assigned to your 3Jam number]@txt.voice.google.com

Give your Google Voice number to people to text to – they have to text you first before you can respond

Reply back to their text on your Peek in this format: [your google voice number].[their number].[google voice id assigned to their number]@txt.voice.google.com – message goes through as text, works for Peek-to-Peek texting

And that’s basically it! Last time I checked, Google Voice does not support short numbers (55555). When they do, you to can vote for your favorite American Idol from your Peek!

Enjoy texting on the Peek with Google Voice!

Peek is a big chunk of this traffic

Trend #2 – Hardware is getting cheaper and cheaper, so why pay 2-10x more to use Amazon AWS. Check out this article, petabytes on a budget. Frankly all this infrastructure as a service is built for the rawest of start-ups who need to pay as they go. Buying your own is sooooo much cheaper, as soon as you have any revenue you should do it.

Trend 3 – Everything has an API. When we started Peek in early 2008 here was the landscape:
-Hotmail was closed off, no POP
-Yahoo was closed off, no POP
-Facebook was closed off
-AOL was not open for mobile access

Now, everything has an API. Facebook streams, Twitter, Hotmail opened POP, Google made love to Jabber, and so on. And we can go get it all!

Trend 4 – The cloud pwns data. Everything that used to be hidden behind a firewall or stuck on a PC is now stored on the Internet. Apps for people like to-do lists, calendars, mint for finances, etc to B2B apps like Basecamp for project mgmt, freshbooks for finance, zendesk for customer care.

Trend 5 – Nobody cares about privacy of their data??? Everybody posts everything everywhere. Companies like Mint have people’s most sensitive financial data and credit card numbers stored somewhere, and frankly nobody cares.

Mint Knows You Better Than Your Own Mom!

I love it. Secretly I never really liked Sidekicks. I’ve always hated that pop-up screen-a-ma-jig thingy, but more so as soon as I heard Paris Hilton had one, it made me gag. The Sidekick was built for and marketed to the snooty elite, Peek was built for Average Joe. We are NWA to their Rodeo Drive shoppistas, El Che to their Bourgeoisie, Hulk Hogan to their Mr. Perfect, etc.

Peek, a man of the people!

Peek vs the Sidekick, the next revolutionary battle… no holds barred!!!

http://www.drownout.com/blogdrwn/2009/10/sidekick_all_your_database_are.html#000874

October 10, 2009
Sidekick: all your database are belong to us

The cloud is looking pretty flakey lately, between Gmail outages and today’s striking Sidekick data loss.

The genius of Danger’s pre-iPhone superphone was partly the cloud: everything on the device was *always* synced to some stuff in the cloud — the call list, the emails, text, pictures, apps you downloaded, everything. You can even log into a web page and see all the stuff on your phone anytime. Way before anyone else even thought of this, they had the “iTunes for your phone” thing down.

An early casualty was the Paris Hilton incident when someone used her dog’s name to guess her password and start browsing her call list.

Worse, apparently, somebody hit “drop table” in the SQL terminal, because they blew away all the data in the whole cloud in the last day or two.

The consequence is that the “master” — which is the cloud copy — is gone, and if your device resets or battery drains, it will sync back to the blank server. Ouchie momma.

Peek doesn’t work this way, partly because all that 2-way data synching is insanely network intensive and partly because your device is “where” your stuff should be. It’s a client and has its data on it.

Of course, one aspect that Sidekick, Blackberry and Peek all share is the reliance on a master application up in the cloud for making the whole thing work well. Blackberry and Peek both use that app to gather and deliver mails quickly and in a mobile-ready way. Since Windows and iPhone and other smartphone apps don’t work that way, they use WAY more data and pound the heck out of networks. And the relatively wimpy storage/processors on the devices get chewed up doing the transactions. By avoiding this, we are able to make the Peek device itself much lighter-weight and cheap. Hurray for us.

Posted by amol at October 10, 2009 10:12 PM

1. 99.9% uptime (roughly 1 hour per month downtime). We track all of our outages.

2. Peek-Time – the average time for email from when the email hits your inbox to when it is available on your Peek. The goal is ~0 minutes for customers on push mail, it is ~5 minutes for customers where we have to poll.

3. Capacity – we aim to constantly keep 2x capacity in the system. Many of our tasks happen in batches so we compare completion time vs the next scheduled job. We also watch CPU, memory, connections & disk to keep 2X.

4. Infrastructural costs – we aim to keep our cost per subscriber per month at a certain price point, and constantly drive it down.

We track/audit the first three weekly, we track costs monthly (when we get our bills). We’re constantly deriving projects to improve in each of these four areas.

Do any of you track different KPIs or use different overarching goals in your businesses?

The New Digs

The move got me a bit nostalgic and I started reminiscing about all the stuff we’ve done in there since we launched the Peek:

1. A full new product release – Peek Pronto – with tons of features.
2. Partnered with Xtify to add location tracking to the Peek allowing a developer (Mark Bowytz) to create www.peekmaps.com
3. Launched texting on the Peek
4. Once we found out texting was popular, re-launched texting partnered with 3Jam to make it ‘killer’
5. Added Facebook integration with PeekSocial
6. Launched in Radioshack
7. Had a whack of people in the community develop all kinds of stuff – including PeekFeeds & CharlesChilders Ent applications

Thats a pretty impressive ‘done’ list for a company of 20 people and a tech team of < 10 people. Tons more still to do though!

Lifetime Peek is Back!!!

Click here to buy – http://www.amazon.com/Peek-Messaging-Lifetime-Service-Included/dp/B002MXXBKY/ref=pd_ts_e_10?ie=UTF8&s=electronics

Or read here for more info – http://blog.getpeek.com/2009/09/lifetime/

“Shipping is a feature. A really important feature. Your product must have it.”

http://www.joelonsoftware.com/items/2009/09/23.html

Like Joel, I’m also reading Coders at Work. If you are in high-tech, you need to read this book. Some of the interviews are absolutely riveting. Seeing the stark contrast of coders who make products vs researchers who create theoretical work… and then the broad mix in-between… is pretty wild.

I have had the fortunate experience to work with some great coders in my life. The best I have ever worked with was a guy named Kevin Greer who works at a company called Redknee. He is somewhat folkloric-ally famous at the university we went to for building a compiler in Lisp. Kevin was a great coder because he balanced incredible architectural vision with raw coding output. In the pre-J2EE/framework era he built an incredible, telco grade framework used across the company in all of our products. Not only did he make this framework architecturally & theoretically brilliant, but he made it quickly, made it usable for 300+ coders and made it stable enough to be deployed with tier 1 wireless carriers globally. Plus he was a lot of fun to work with. Everything you could ever want in a coder.

Another great coder I’ve worked with is a guy named Vitaly Veksler. Vitaly is our primary developer here at Peek. He runs his own dev shop based in New York, www.webalgorithm.com. They are a small group of craftsmen developers who have been working with us since day 1, spending a lot of time onsite here helping us drive our technology forward. Vitaly is another classic example of pragmatic programming intertwined with architectural vision. Things need to be ‘clean’ so the program makes sense. Things also need to be able to scale without having to re-write everything. But more important than anything, the product needs to launch, it needs to ship on-time. Complexity kills that. Vitaly and his team balance that incredibly.

What I do find though is that the most architecturally savvy coders are usually the most productive. I actually know very few purely theoretical coders who get ’stuck’ in constant architectural re-writes of perfection. Good architects = good productive coders. I’ve never worked with the lab coat, theoretical, genius architect who produced incredible architecture who couldn’t produce tons of code with it.

And I find the converse true as well – not productive coders = bad architects. The least productive coders I know often fathom themselves good architects, but tend to suck at both. There is something to doing lots of coding that makes you want to be efficient about architecture. There’s also something to learning lots about architecture by shipping lots of products with different architectural patterns. Its called learning.

And, to throw in a tangent, that is why offshoring is a risky strategy. Offshore companies I have worked with have often created poor architectures and been far less productive. Team size tended to be 3-5x larger, therefore also requiring a lot more spend on management. The architecture and underlying technology choices tended to be poorer, leading to lots of bugs & software crashes, where you ultimately end up stuck in really long maintenance periods trying to fix things. In one scenario we were stuck with layer after layer of mis-used J2EE technology. 3-4 instances of basically the same beans, 2-3 DALs/persistence layers to the same table, it was a nightmare that made everything less productive. The worst case scenario all around.

I find from my anecdotal experience that the majority of the penultimate architecturally brilliant + pragmatically productive developers have been here. I am sure there are tons in other countries I just haven’t worked with, but right now I’ve had the ability to work with 5-10 amazing, world-class developers here, and 1 abroad (in India). And therefore they have hit the most important feature most often – shipping product.