kentbrew

The Problem

Standard practices say no non-root process gets to talk to the Internet on a port less than 1024. How, then, could I get Node talking on port 80 on EC2? (I wanted it to go as fast as possible and use the smallest possible share of my teeny tiny little micro-instance's resources, so proxying through nginx or Apache seemed suboptimal.)

The temptingly easy but ultimately wrong solution:

Alter the port the script talks to from 8000 to 80:

}).listen(80);

ryanflorence

@events =

  events: {}

  on: (topic, handler, context = this) ->
    (@events[topic] or= []).push {handler, context}

  trigger: (topic, args...) ->
    return unless @events[topic]?
    handler.apply(context, args) for {handler, context} in @events[topic]

asfaltboy

/*
 * Copyright (C) 2015 Pavel Savshenko
 * Copyright (C) 2011 Google Inc.  All rights reserved.
 * Copyright (C) 2007, 2008 Apple Inc.  All rights reserved.
 * Copyright (C) 2008 Matt Lilek <webkit@mattlilek.com>
 * Copyright (C) 2009 Joseph Pecoraro
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:

germain-gg

var getCaretOffsetWithin = function(node) {

	var treeWalker = createTreeWalker(node);
	var sel = window.getSelection();

	var pos = {
		start: 0,
		end: 0
	};

kiding

<!-- 
  When an input element gets focused, iOS Safari tries to put it in the center by scrolling (and zooming.)
  Zooming can be easily disabled using a meta tag, but the scrolling hasn't been quite easy.

  The main quirk (I think) is that iOS Safari changes viewport when scrolling; i.e., toolbars shrink.
  Since the viewport _should_ change, it thinks the input _will_ move, so it _should_ scroll, always.
  Even times when it doesn't need to scroll—the input is fixed, all we need is the keyboard—
  the window always scrolls _up and down_ resulting in some janky animation.

  However, iOS Safari doesn't scroll when the input **has opacity of 0 or is completely clipped.**