philcockfield's comments

philcockfield | 7 years ago | on: Ask HN: How do you become the best at something?

>> But my insecurities force me to constantly try and productize my learning.

I wouldn't frame the impulse to "productize" something necessarily as buckling to an insecurity.

Deep learning (no pun) is so often the result of recontextualising what you've studied into some new form of your own making. If that's a "product" of sorts, then all the better for advancing your other goal of "building an incredible company."

philcockfield | 7 years ago | on: Do You Really Know CORS?

LocalStorage is so much more preferable than cookies, I agree, however as SSR ("server-side-rendering") of heavy client-side JS apps becomes more prevalent, suddenly cookies are back in business.

If the initial SSR needs some initial client-state to complete its work before sending the HTML payload, it can see the cookie, but not localStorage.

philcockfield | 8 years ago | on: Building a Text Editor for a Digital-First Newsroom

I really like Slate....but the ability to do collaborative editing is relatively new.

Have you done anything with collaborative editing with Slate? If so, how are you finding it?

philcockfield | 9 years ago | on: Are RethinkDB and Horizon abandoned?

Hi Slava, any update on the "full announcement and details" that you mentioned? Thanks!

philcockfield | 12 years ago | on: Show HN: Respondly – Team Inbox for Email and Twitter. Our new MeteorJS App

Thanks for taking a look, and the kind words.

Here was the design criteria we were holding in mind when deciding on the technical stack to employ for Respondly. To support the "team collaboration" story we knew it was going to be a heavily JS based "native like" UI experience. So basically a rich single-page app that used push-state and web-sockets a lot.

Meteor is nice in that it folds a number of technologies into the stack that when combined are extremely powerful, not least of which being Mongo on the server AND the client, which helps a lot in reducing the amount of code you typically have to write for dealing with invalidating shared data when it changes between users. It achieves this by having the Mongo API replicated on the client in JS, which is really a thin proxy to the DB on the server. So your coding against Mongo as though it were actually in the browser, and Meteor handles the data syncing in the background. It sounds a little magical, but it shakes out to be a really helpful abstraction to sit behind.

The real kicker for us, though, is that we can lean on the hard-core architectural work MeteorDG has done to ensure a real-time, web-sockets based system of this kind can scale readily when there are ton of connected clients.

By avoiding rolling that sort of architectural plumbing ourselves we've been able to focus more on the feature set.