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
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.
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.
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.
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)
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.
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.