dhcp-script=/etc/detect_new_device.sh
Reference:
dhcp-script=/etc/detect_new_device.sh
Reference:
/** | |
* This software is in the public domain. Where that dedication is not recognized, | |
* you are granted a perpetual, irrevokable license to copy and modify this file | |
* as you see fit. | |
* | |
* Requires SDL 2.0.4. | |
* Devices that do not support Metal are not handled currently. | |
**/ | |
#import <UIKit/UIKit.h> |
Some thoughts on using node-postgres in a web application
This is the approach I've been using for the past year or so. I'm sure I'll change and it will change as I grow & am exposed to more ideas, but it's worked alright for me so far.
I would definitely use a single pool of clients throughout the application. node-postgres ships with a pool implementation that has always met my needs, but it's also fine to just use the require('pg').Client
prototype and implement your own pool if you know what you're doing & have some custom requirements on the pool.
Using pg.connect
is the way to go in a web environment.
PostgreSQL server can only handle 1 query at a time per conenction. That means if you have 1 global new pg.Client()
connected to your backend your entire app is bottleknecked based on how fast postgres can respond to queries. It literally will line everything up, queuing each query. Yeah, it's async and so that's alright...but wouldn't you rather multiply your throughput by 10x? Use pg.connect
set the pg.defaults.poolSize
to something sane (we do 25-100, not sure the right number yet).
new pg.Client
is for when you know what you're doing. When you need a single long lived client for some reason or need to very carefully control the life-cycle. A good example of this is when using LISTEN/NOTIFY
. The listening client needs to be around and connected and not shared so it can properly handle NOTIFY
messages. Other example would be when opening up a 1-off client to kill some hung stuff or in command line scripts.
var logEvents = function(el) { | |
Object.getOwnPropertyNames(el).join(" ").match(/\bon\S+/g).forEach(function(n){el[n]=function(e){console.log(e.type,e)}}); | |
} |
// Just before switching jobs: | |
// Add one of these. | |
// Preferably into the same commit where you do a large merge. | |
// | |
// This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
// and then it quickly escalated into more and more evil suggestions. | |
// I've tried to capture interesting suggestions here. | |
// | |
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |
{ | |
"Statement": [ | |
{ | |
"Action": [ | |
"route53:ChangeResourceRecordSets", | |
"route53:GetHostedZone", | |
"route53:ListResourceRecordSets" | |
], | |
"Effect": "Allow", | |
"Resource": [ |
{ | |
"Statement": [ | |
{ | |
"Action": [ | |
"route53:ChangeResourceRecordSets", | |
"route53:GetHostedZone", | |
"route53:ListResourceRecordSets" | |
], | |
"Effect": "Allow", | |
"Resource": [ |
class AppDelegate | |
def application(application, didFinishLaunchingWithOptions:launchOptions) | |
alert = UIAlertView.new | |
alert.message = t('start') | |
alert.show | |
true | |
end | |
def t(key) | |
NSBundle.mainBundle.localizedStringForKey(key, value:nil, table:nil) |