sghael

The convention should be to use 1337 as your seed, and disclose that in your publication.

Localytics | Boston | Front End, iOS, Android | ONSITE Localytics provides a mobile engagement platform for many of the world’s top app publishers including ESPN, Grindr, Periscope, and HBO. Our customers rely on us to keep their mobile users happy and engaged. We provide tools to drive great app experiences including push messaging, mobile analytics, predictive analytics, and individualized in-app experiences.

We are hiring front end engineers! We have a modern front end stack (ES6, React, Redux, Webpack) and a history of front end thought leadership and open source contributions.

We are also hiring mobile engineers with a focus on Android and iOS development. We build tools for our fellow mobile developers and write code that is deployed on billions of devices around the world.

To apply or learn more about either opportunity send an email to [email protected] Check out our engineering blog: eng.localytics.com

Also looking forward to the technical writeup.

Not sure if it's just me, but when touching the menu controller on the top left, the dom slide over to reveal... nothing. Also, general weirdness using the gear button to change selection between all/enqueues only/ratings only/reviews only. Selecting something other than all does nothing and doesn't persist.

I'm on Android 2.3.3. My Touch 4g slide. Stock browser.

The photo isn't store in a database. It's stored on S3. They are not backing up S3, so this concern is misplaced.

Could you give a little more detail on your setup? I'm curious how others are designing around these issues.

We're using C2DM at Ravid (http://getravid.com).

In fact, we open sourced our C2DM Ruby Gem: https://github.com/sghael/speedy_c2dm

This is Sandeep (co-founder of Ravid). My co-founder (keithba) and I found that sending private, asynchronous video messages on mobile devices is way more difficult than it should be. We created Ravid to solve this problem.

Note: US-only for now & requires a phone (so no tablets.)

The stack & tools:

  * Rails 3 (MRI) for our API servers.  
  * Worker nodes running Sinatra (JRuby) w/ Resque
  * Monit for monitoring services / Fabric for quick provisioning
  * The Android client is typical Java (using IntelliJ)
  * iPhone development w/ Monotouch! 
  * S3 for storage, and our public website using Jekyll
  * C2DM message delivery (our Gem: https://github.com/sghael/speedy_c2dm)

Lessons learned so far:

- Fragmentation on Android is a b. Especially when dealing with hardware stuff like cameras, expect to do a lot of device specific coding. Front-facing cameras are a perfect example. Gingerbread solves these problems in theory, but not in practice.

- Uploading video files over mobile connection is non-trivial (duh) - We've put a lot of work towards reliable and efficient uploads and downloads (intelligent packetization, retry logic, etc). We solve for the "elevator scenario". User sends a message, but steps into an elevator half way through delivery. Aside from Gmail, most mobile apps suck at this.

- On the positive side, 4G+ speeds are really impressive.

- Creating a portrait oriented camera application for Android is way harder than it should be (really poor API implementation around camera rotations). Contrast to iOS where it's super easy.

- UX matters - A friction-free UX required a lot of work. We had many alpha testers (both family and friends & paid services like usertesting.com/mobile) that helped us find the sticking points.

We'd love your feedback on anything!

Images are just signals as a function of 2D space. So you can use the 2d FFT: http://fourier.eng.hmc.edu/e101/lectures/Image_Processing/no...

Another idea to grok: a checkerboard pattern image where every other pixel row and column are alternating full black and full white represents the "highest frequency" image possible at that sample rate (pixel density). This is the 2d equivalent of an alternating sinusoid +1,-1,+1,-1, etc

That seems like a non-sequitur. Based on the article, LightSquare isn't an application of GPS. It's a wireless broadband network that just (unfortunately) happens to f with GPS signals.

Redundancy is insurance. By the nature of being there it's taken advantage of

wow, extremely slick. Are you using any specific UI/design framework to tools to create such a polished look/feel? Or totally coded from scratch?

actually 9 mom months. so 1 month with 9 moms working on it.

This is the first thing i thought as well. Build should be #1. The reading you do should directly support your building (finding help on HN or SO that help you solve the specific problem/bug at hand)

back now.

Sorry the server is on fire right now... got a tweet from smashing magazine. Working to bring it back up.

Great catch. Although, in my defense I'm always looking to save time so I just used out of the box settings on the wordpress "Platform" theme. If you're starting from scratch on your own site, dont make this mistake :)

I agree. My other thought was 'isn't there a staging server in there somewhere?' Something that is near identical to production, with fake production data, etc, that could surface the problem before a customer sees it.

btw, props to Fog Creek and OP for airing their dirty laundry. They take some heat, but in the end we all learn from it.

this is an interesting point (I've up-voted you).

But my gut feeling is that it doesn't matter. While I don't have any experimental data, I have to imagine this rendering penalty is in the noise of page/site performance. Asset packaging, gzip, using front end static server, etc are probably orders of magnitude more important for page rending speed than DOM traversal of CSS selectors.

I think its a better user experience to always show the number on a screen. Otherwise the user has to listen to the computerized voice recite the passcode, and they have to memorize it before punching it in.

This way, temporary memorization of passcode is avoided in both cases. The passcode is always rendered to pixels (computer screen or phone screen).

I'll soon be running on multiple (2 min) servers in different locations, for availability. Will probably stick to Linode. I use Webmin to monitor all processes and get realtime alerts if something amiss occurs.

Performance wise, there aren't many bottlenecks right now. Switching in Resque for my job queue (replacing Delayed Job) will make everything a little faster. If the queue ever starts to get large, I can quickly fire up another server as a dedicated worker.

I am leveraging AWS Cloudfront as a CDN for the widget JS, so the widget will load super fast for everyone. I offload all static assets when I can. Google CDN for JQuery.

The only immediate point of concern is the real-time API. That will soon have some throttling/limits on it to prevent abuse. I highly prefer people use the Post-back method to get notified of verifications (push is always better than poll).

As for proving reliability, I'm thinking of putting up public Pingdom reports for transparency.

Phone numbers are less disposable than email addresses (generally speaking), and thus you are less likely to have fraudulent/shady transactions occur on your site if the user is phone verified.

This may not be super important if all you want to do is prevent lowly Forum spam (ReCaptcha may be all you need in this case). But phone verification can be particularly useful when the cost of fraudulent transaction is high (like user purchasing goods on your site with a stolen credit card, etc).

As an aside, I saw Amazon and Craigslist now use phone verification for more critical parts of workflow. Which inspired me to build Phoneify as a JS widget than anyone could use.