rcsorensen

Trello's hiring for a bunch of different roles, Front and Back-End (node), Internal Tools Developer, and Site Reliability Engineer are all listed at https://trello.com/jobs . Anywhere in the US.

Trello | New York, NY or REMOTE

Trello ( https://trello.com ) is a visual collaboration tool that creates a shared perspective on any project.

We're a remote-friendly, venture-backed startup headquartered in NYC.

We're growing quickly, not the kind of quickly where you're hiring just for headcount numbers, we're hiring for quality. We're currently 92 employees total. Joining us at this stage empowers you to help define our future processes, what it means to be on the team, and lends itself to lots of exciting career growth.

We’ve got four roles open right now that might be of special interest to the HN crowd:

Site Reliability Engineer – you’ll work on keeping everything running efficiently as we scale the infrastructure supporting over 10 million Trello users on the way to our goal of 100 million users. ( https://trello.com/jobs/site-reliability-engineer )

Developer Advocate – it will be your mission to make it easy and fun to build on top of our API and new Power-Ups platform. ( https://trello.com/jobs/developer-advocate )

Growth Engineer – you'll be working to build features and run experiments to improve acquisition, engagement, retention, revenue, and virality. ( https://trello.com/jobs/growth-engineer )

IT Specialist (NYC) – own and manage our cloud based infrastructure tools for collaboration across the company and support our local and distributed employees for all things IT related. ( https://trello.com/jobs/it-specialist )

Some other jobs and some of our perks can be seen at https://trello.com/jobs .

Links to article and book referenced in parent:

http://www.nydailynews.com/opinion/build-big-bill-article-1....

https://www.amazon.com/dp/B0040JHNR0/

Site appears down.

http://webcache.googleusercontent.com/search?q=cache:raHl4fa...

The handshake agreement presented here makes me very happy.

Were many revisions done on it, or was it pretty clear to write?

Yes.

In the final analysis this question is equivalent to "Is it difficult to make a site that can have any piece of it fail to load or be removed at any time?" since website developers have no control over what may or may not make it onto the list of an adblocker.

If this interests you, there is also https://cdn.polyfill.io/v1/docs/ (https://github.com/Financial-Times/polyfill-service), backed by FT.

It looks like this is related to 'bot detection' services from http://www.whiteops.com/ , as White Ops is listed as the contact on tagsrvcs.com.

The html served back includes a script tag having

  require(['http://static01.nyt.com/bi/js/tagx/tagx.js'], function () {


  http://static01.nyt.com/bi/js/tagx/tagx.js

loads

  http://s.tagsrvcs.com/2/818492/analytics.js?<bunch of query params>

which defines an 'encryption key' that is later used to 'encrypt' POST parameters back to tagsrvcs, but looks a lot like a page load identifer, including using it to namespace 'postbacks' later on.

  tagsrvs.com/.../analytics.js

loads http://s.tagsrvcs.com/2/4.10.0/loaded.js

  tagsrvcs.com/../loaded.js

'postsback' to urls like http://s.tagsrvcs.com/2/4.10.0/818492/L0an5rrDUnnex1s8dQ4fGu...

(Note the 'L0an5rr...' which is the same as the 'encryption key' returned before in the 'analytics.js' file)

This collects some fun things like WebRTC addresses, scripts loaded on the page, and much much more, and sends them out as they become available or more events happen.

If you'd like to investigate this information yourself, the best place to set a breakpoint is in 'loaded.js', inside the function 'e.prototype.emitAsCORSXHR' which is responsible for 'encrypting' the payload before transmission.

Something of a story at http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is...

Perl is dynamic enough to support this.

See http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual/... and http://search.cpan.org/~ether/Moose-2.1403/lib/Moose/Manual....

Competing type systems, competing Object systems, and enough internal run-time rewriting to do whatever it is you want.

See also http://search.cpan.org/~smueller/Filter-Simple-0.91/lib/Filt... for a simple rewriting filter, and the Acme namespace for all kinds of fancy experiments.

The title is burying the lede.

Facebook is talking here about "Relay", a framework around React that handles pulling together all the data needs for a deeply nested component tree, from fetching, to optimistic updates, through error handling and pagination.

As a heads up, this isn't a really useful response, and triggers some red flags while evaluating services.

It's probably worth spending some time on figuring out how to explain to a prospective customer that is familiar with the marketplace what makes the product different.

Perhaps `dang can bump this back to the front page on Monday.

Mou isn't abandoned. The creator has recently started an IndieGoGo project to fund 1.0.

https://www.indiegogo.com/projects/mou-1-0-markdown-editor-o...

What's the cost?

How are the tunnels set up?

This looks very much like it could be a thin pricing layer over a hacked botnet, which wouldn't be right to support at all.

See the following:

https://github.com/grugq/PORTALofPi

https://www.portalmasq.com/portal-defcon.pdf

I would love it. Markdown would be the bee's knees there, if you can reverse it.

I wish I could take my upvote on this article back.

This is not an open source filepicker.

This is an open source library that interfaces with a closed source service, and doesn't provide any general capabilities.

I'd love to see some https://keybase.io/ integration. There's some nice overlap with the federation concept, even if the "one-account-per-physical-person" story isn't as compelling.

Some of the reasons you'd want to use Bower:

* Your external libraries have dependencies, and having dependencies managed for you is a good thing.

* The external components you're using include both JS and CSS, and need to be served separately.

* Because you love your users, and want to concatenate your javascript and CSS to single files before serving it out to your users.

* Because you're including components that expose SASS mixins you want to use inside your existing code.

The hosted vs serving your own libraries is a complicated topic, but the basic answer comes down to "the less requests your clients have to make, the faster things will be".

Of subsequent data fetches. Not the first page load. Using JSON fetches to update documents also gives you the ability to not throw away the DOM/CSS and maintain the execution context.

If you use the right technology, you can give a usable application out of the gate without waiting and use JSON data fetches for every subsequent request.

I'm suggesting the hybrid approach here, exemplified by the Rendr and React.

Give the full html of the first page, load the JS necessary. You get the best of both worlds.

On the first request, the client receives a rendered html page, gets to read the page, then JS functionality is attached.

On any subsequent pages, you do a simple JSON request and update the DOM.

The approaches come together without sacrificing anything. You get to write a single code base using JS (with a node.js backend doing string manipulation so it doesn't even need a DOM), the user gets a page without having to wait for external resource loads, and all page transitions past that are a simple data-fetch away.

Sure!

And now your poor little mobile user has to wait for the page to download, then to execute javascript, then to wait for the API response, then wait for the DOM to update.

Or you could put it in the HTML, and then they just have to wait for the page to download.

Like `ssorallen says, slow CPUs and limited battery life is an issue. In addition, latency on mobile networks is rough and should be avoided for your users whenever possible.

You have two choices when taking an SPA approach:

1) Give your users a webpage that is usable, readable, and navigable as soon as they get it.

2) Give your users the skeleton of a webpage that they then have to accept the latency of javascript parsing and execution, and then the latency of data fetches.

we have the ability to do #1.

Sending the framework of a page to your users and expecting them to do all the heavy lifting and slow loading of constructing the page and fetching the data is still rather unfriendly if you can afford a server to construct it.

If you love your users, give them HTML and let the Javascript enhance it.

Projects like Facebook's React ( http://facebook.github.io/react/docs/top-level-api.html#reac... ) and Rendr (https://github.com/rendrjs/rendr/) let you use server rendering as well as the single page technologies on the client side.

In case you were unaware, there's a very popular and lovely promises library for javascript named q.

https://github.com/kriskowal/q

Gmail's "Actions" API.

https://developers.google.com/gmail/actions/reference/one-cl...

.halfStyle:before includes positioning like: "position:absolute; top: 0; left:0;" which puts the :before element on top of the existing element.

"width: 50%" says it's only half as wide.

The possibly fancy thing being used here is the use of "attr(data-content)" which use the data-content attribute of the element to fill the pseudo-element's content.

Thanks for this. Procfile support has been a thorn in my side with pow for ages.

Edit: Invoker doesn't seem to support the pow use case -- local configuration, not global. Inspired by the topic, I found https://github.com/riywo/anypow , which has a wrapper for non-rack applications, and can be used to make pow play nice with Procfiles.

Have you considered taking people who have passed challenges (and are excited about them) on as volunteer assistants for the challenges?