edisonywh

```
#!/bin/sh
echo "\nRunning rubocop 🚓 💨 💨 💨\n"

declare -a ERRORS=()

for file in $(git diff --cached --name-only | grep -E '.rb')
do
	ERRORS+=("$(rubocop $file | grep -e 'C:' -e 'E:')")
done

VojtaStavik

import UIKit

class ViewController: UIViewController, UITableViewDelegate, UITableViewDataSource {

  @IBOutlet weak var tableView: UITableView!

  override func viewDidLoad() {
    super.viewDidLoad()
    NSLayoutConstraint.activate([
      tableView.topAnchor.constraint(equalTo: view.topAnchor),

kirs

# Cleans up branches like:
# if Shopify.rails_next?
#   # Rails 5 login
# else 
#   # Rails 4 login
# end
module RuboCop
  module Cop
    module ShopifyRails
      class RailsNextUnless < Cop

Francesco149

this has been rewritten yet again as most workarounds aren't required anymore since wine 3+

example video of the final result: https://www.youtube.com/watch?v=zkqzQoeOGfU

with touchscreen: https://www.youtube.com/watch?v=GcIrlorWmaQ

performance is indistinguishable from windows. there might be a very slight ~25ms sound latency which is easily compensated with +25 local offset

tested on

Rich-Harris

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.

Francesco149

outdated, someone else is updating the list now -> https://gist.github.com/Fobxx/107e2bad2bf7312cd49431c696aac912

joewiz

On Tue Oct 27, 2015, history.state.gov began buckling under load, intermittently issuing 500 errors. Nginx's error log was sprinkled with the following errors:

2015/10/27 21:48:36 [crit] 2475#0: accept4() failed (24: Too many open files)

2015/10/27 21:48:36 [alert] 2475#0: *7163915 socket() failed (24: Too many open files) while connecting to upstream...

An article at http://www.cyberciti.biz/faq/linux-unix-nginx-too-many-open-files/ provided directions that mostly worked. Below are the steps we followed. The steps that diverged from the article's directions are marked with an *.

1. * Instead of using su to run ulimit on the nginx account, use ps aux | grep nginx to locate nginx's process IDs. Then query each process's file handle limits using cat /proc/pid/limits (where pid is the process id retrieved from ps). (Note: sudo may be necessary on your system for the cat command here, depending on your system.)
2. Added fs.file-max = 70000 to /etc/sysctl.conf

xjamundx

This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.

In that post I talked about 3 main reasons for moving from require.js to webpack:

1. Common JS support
2. NPM support
3. a healthy loader/plugin ecosystem.

Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.

hanula

aa.je
ae.je
ae.gg
ae.ht
af.je
af.cx
af.gg
af.gl
af.ht
ah.je

brianmacarthur

var express = require('express');
var cookieParser = require('cookie-parser');
var session = require('express-session');
var flash = require('express-flash');
var handlebars = require('express-handlebars')

var app = express();
var sessionStore = new session.MemoryStore;

// View Engines