Skip to content

Instantly share code, notes, and snippets.

Marco Rogers polotek

Block or report user

Report or block polotek

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile

Design Doc Title


List stakeholders for project/feature.

Role Person
Dev Owner
Other Dev 1 (Engine)

Keybase proof

I hereby claim:

  • I am polotek on github.
  • I am polotek ( on keybase.
  • I have a public key ASAbNgm_MHa7hpanU4BJsVfUrOrDQgmbgyGq8ZXRop-b0Ao

To claim this, I am signing this object:

View gist:7d0a9238d2f913fc7c5dd9bf51db2a62
JSON._dateReviver = function (k,v) {
if (v.length !== 24 || typeof v !== 'string') return v
try {return new Date(v)}
catch(e) {return v}
JSON.parseWithDates = function (obj) {
return JSON.parse(obj, JSON._dateReviver);
polotek /
Last active Apr 20, 2016 — forked from fancyremarker/
Example: db-launch script to launch the Aptible postgresql database image
# A script for creating aptible postgres databases in containers
container=$(head -c 32 /dev/urandom | md5);
image="${@: -1}";
# Create a data volume
def format_number(num):
numstr = str(num)
chunks = []
while numstr:
numstr, newchunk = numstr[:-3], numstr[-3:]
return ','.join(chunks[::-1])
polotek /
Last active Jun 14, 2016
What's wrong with the npm workflow?

Sara Chipps started this awesome thread about bundler vs. npm. You should check it out cause it's highly entertaining.

But I do want to get more info on the workflow problems people experience with npm. It has always been the simplest thing to me. But I'm also fully aware that perceptions are relative. Most ruby folks are totally fine with bundler even though it gives me constant headaches. But the bundler issues are well documented. This seems to be less true for npm. I want to gather some info about people's experiences. I promise I'll try to refrain from the canned "you're doing it wrong" response.

Also, we've already established that npm is network hungry and could do a better job of maintaining an offline cache. Nobody's arguing that. But I'm less concerned about feature requests here. I'm interested in where npm breaks for you.

Here's Ryan Florence.

polotek / gist:9985338
Created Apr 4, 2014
Single page apps and "fast switching"
View gist:9985338
"broad question: how does fast load work? site is a one page app, switches categories similarly, but no URL relation."

Today I had a brief debate on twitter about AMD vs CommonJS, It's a debate worth having for sure. But I had to bail out of this one. The thing that annoyed me is that the first argument that people bring up to disquality AMD is "the syntax is too complex". I disagree with this. There are lots of reasons to prefer CommonJS over AMD, but the module authoring syntax is not a very good one. There was also a related statement that AMD authoring introduces more "cognitive overhead". This is absolutely true. But I don't consider this to be synonymous with "complexity" by any means.

So I thought I'd explore some comparable examples. Here's a simple one that was offered up by someone else in the thread. This was on twitter so I can forgive erring on the side of brevity.


define('myThing', ['some', 'deps'], function (some, deps) {
  //my code
  return myThing;
polotek /
Last active Jan 2, 2016
My talk proposal for JSConf US 2014 or anyone else who wants to hear it.

We're all building a client-side framework. And they're all different implementations of the same stuff. A while back I tweeted this.

"When it comes down to it, everybody is building variants of the same MVCish framework. We should be talking about the shared patterns."

I want to explore the shared patterns that we all use to build our front-end apps. Patterns like the following.

  • Representing a list of data items. Updating the view when the list updates.
  • Rendering nested views.
  • Data binding, e.g. automatic UI updates
  • Controlling when and how the UI gets re-rendered on data updates
You can’t perform that action at this time.