rwalker

Google seems to resolve several different things as "terminal.js" - which do you mean?

Or, a shorter answer to your question: no. :)

If you have any specific idioms you think we should add, let me know here or at robbyw@cueup.com

Deploying these fixes now - thanks for the feedback!

We figured this would be good for some Friday fun! Admittedly, a few of the problems are solvable by hand, and we wish there were more jokes about gnus, but overall we just hope you enjoy playing as much as we enjoyed building it.

One example that comes to mind: we have a networking layer that prioritizes some HTTP requests over others. For example, we seed our cache by firing off requests for the next 30 days, but at a low priority. There was a bug in this layer where request initiation could block the main thread while unrelated work was finishing.

Another example: we used the "HOOKSHOT_TAG" macro to tag objects related to rendering different days in Cue (today, yesterday, tomorrow). This makes the thread activity graph use different colors for time spent on those objects. This helped make obvious a few edge cases where some rendering/processing for a day that was not on screen was done before the day that was.

The trick is that we use the same original object at the same address in memory and overwrite what class it thinks it is (as opposed to wrapping it). So in a way it becomes a proxy to itself.

Seems to work fine since we're dropping in the exact same implementation instructions as would have been there otherwise, and using the same object too. That way, any ivar references still correspond to the same positions in memory.

Time Profiler is a sampling profiler, this one is instrumenting. They're both useful at different times - we find this one useful for

* Thread activity graphs with drill-in

* Seeing accurate counts of calls

* More precise per-call timings of messages

* Measurement of messages with highly variable performance

Sorry to hear it! About two weeks ago we closed the last of our known push bugs. There is one that's left where iOS itself will re-send an old push along with new notifications which is fixed by a phone restart. (this happens with all apps, not just ours)

If you have time, email me at robbyw@cueup.com - I'd love to talk about what things you wanted to see and let you know if any of them are on the roadmap.

Fair point! It's hard to assign numbers to perf for something like an entire application - a lot of the wins we found were places where the main screen was locked (causing app un-responsiveness) or where we were able to change the order of some actions to get the app to render quicker.

I'd say the app takes around 2-3x less time to load than when we started our most recent performance quest, largely due to issues we found using hookshot. We did find some performance critical inner loops in our rendering code where we were able to achieve something like 10x speed-ups.

Apple's profiler has significantly lower overhead than hookshot - which makes sense given the relative amounts of information collected. Our app runs noticeably slower when hookshot is enabled, but when it is disabled, hookshot introduces exactly 0 overhead. We only enable it when we're specifically debugging performance issues.

Robby from Cue here: we've found a ton of non-trivial performance wins for the Cue app by using this. Let me know if there are things we can do to make it useful for you too.

A lot of the inspiration for how to actually make this work came from Mike Ash's awesome NSBlog:

http://mikeash.com/pyblog/

Cue is hiring engineers in San Francisco.

Generalist: work on problems like "how to match a calendar entry to related email", or "extract all addresses, relative dates, signatures, and more from an email in under 1ms", or "scale a document analysis and indexing pipeline to handle billions of documents"

Mobile: iOS or Android or both. Work on problems like "create custom ui", "prioritize network requests in varying network conditions", or "design an efficient format for information retrieval on mobile devices"

We're a tight knit team - we work hard but always find time to duke it out in Smash Brothers Brawl or ping pong after lunch.

E-mail us at jobs+hn@cueup.com or try out our programming challenge at http://challenge.cueup.com.

Our sincere apologies for the confusion - our launch got jumped 48 hours by a press mixup and we've been working all night to get everything in place as quickly as possible.

Greplin search hasn't changed - it is still availalble as Cue Search - both in our app and on our website. Web access is hard to get to for the next few minutes - right now it's accessible at https://www.cueup.com/login (will be linked from cueup.com momentarily). In the iPhone app, the search functionality has been streamlined and is available as a tab.

We still care about search a lot. It's the foundation of all the new features, and it's critical to the long term goals of our service.

If you encounter any issues, as always, we're quick to respond at support@cueup.com

I think he was referring specifically to the painful nature of multiple accounts on the iPhone.

In the browser, we've had great luck with Google's multi-accounts feature:

http://www.google.com/support/accounts/bin/answer.py?answer=...

I completely understand what you're saying. In your metaphor, our system is more like this: all "porn" I access is logged (and this log is sent to my wife) and only she and I together can unlock the filter. More succinctly: no single person here has all the passwords.

http://en.wikipedia.org/wiki/Shamirs_Secret_Sharing

A couple things you mentioned here are great use cases of Greplin - to find that address you're getting a map for, to find phone numbers of the person you need to call, or to find out information about your upcoming sync'ed calendar event. Send me an email at robbyw at greplin dot com - I'd love to talk about if there is ever anything you wanted to find on your phone but couldn't.

We care deeply about user privacy and have systems in place to prevent anyone (including the founders) from looking at user data. You can find our privacy policy here: https://www.greplin.com/privacy

We did, but for basically anything over 1GB we found heap dumps to be prohibitively slow. Then, instead of failing for one request we'd basically end up killing the whole server.

We use IMAP IDLE: http://tools.ietf.org/html/rfc2177

We do use it in Tornado apps. We haven't seen any blocking issues so far as the time to write the tiny file is pretty small plus this happens on a small percentage of requests. It'd probably be worth looking in to an asynchronous model at some point though.

Have you installed both protocol buffers and the fast-python-pb module? Feel free to email me: robbyw@(the-company-mentioned-in-the-title).com

Good catch - updating now. It'll be under Apache 2.0. (edit: done)

in the sidebar now - thanks!

As for what it does, it allows you to store an interval in Lucene, so you could store 1792 - 1796 or you could store 140000 - 125235466734. It uses a similar algorithm as the one used to store numbers so that it doesn't have to store millions of terms in the second example.

(we're pretty surprised by the response too!)

Maybe we have a different hiring mindset than dschoon - we're equally happy with people who find the answers or create the answers. In a production system, we certainly wouldn't want hand-rolled primeness checking. But in a programming challenge, we think it's fun to write it for yourself.

This was intentional - we had to tie break the longest palindrome and we didn't want a quick diff to be able to see what we changed.

Phone call no longer required.

For what it's worth - it's just a Twilio app - we thought it would add to the fun.

San Francisco, CA. Greplin (http://www.greplin.com/jobs)

We need superstar hackers to solve some really hard problems.

Keep terabytes of data in sync. Extract relevant information from large data sets with intelligent indexing, machine learning, and NLP. Display results extremely fast on the web and mobile phones.

We use Python + Twisted, JavaScript + Node.js, Objective C, Java, PHP, and/or whatever you're an expert in. It's early so you'll have a huge impact.

Investors include YCombinator, Bret Taylor (Facebook), Paul Buchheit (Gmail, AdSense), and Ron Conway (everything).

jobs@greplin.com

(no telecommuting at this point)

I'm not sure exactly what files get pulled in by the compiler, but it will remove any dead code (meaning 100% of any extra files) and output a single minimized file.

It (like the rest of the Closure Library) is designed to be used with the Closure Compiler:

http://code.google.com/closure/compiler/

The general philosophy is: for development, loading lots of files is ok and in some cases easier to debug. For production, the compiler will often strip out much more code than just minification would.