- There are some situations that are difficult to distinguish mechanically, so I now consider all of those cases problematic, even when they are not obviously wrong.
- You should be coding for readability and error resistance.
- The place to express yourself in programming is in the quality of your ideas, and the efficiency of execution. The role of style is the same as in literature. A great writer doesn't express himself by putting the spaces before his commas instead of after, or by putting extra spaces inside his parentheses.
- Many people think they have good reasons for doing things badly.
- [The purpose of JSLint is not to make you feel good about inadequate coding standards.](http://tech.groups.y
/*jslint regexp: true, maxerr: 50, indent: 2 */ | |
(function (global) { | |
"use strict"; | |
function URLUtils(url, baseURL) { | |
var m = String(url).replace(/^\s+|\s+$/g, "").match(/^([^:\/?#]+:)?(?:\/\/(?:([^:@\/?#]*)(?::([^:@\/?#]*))?@)?(([^:\/?#]*)(?::(\d*))?))?([^?#]*)(\?[^#]*)?(#[\s\S]*)?/); | |
if (!m) { | |
throw new RangeError(); | |
} |
<!doctype html> | |
<!-- http://taylor.fausak.me/2015/01/27/ios-8-web-apps/ --> | |
<html> | |
<head> | |
<title>iOS 8 web app</title> | |
<!-- CONFIGURATION --> |
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="utf-8"> | |
<title></title> | |
<link rel="stylesheet" href="../libs/mocha.css" type="text/css" media="screen" title="no title" charset="utf-8"> | |
</head> | |
<body> | |
<div id="mocha"></div> | |
<script src="../libs/mocha.js" type="text/javascript" charset="utf-8"></script> |
The postMessage()
API is an HTML5 extension that permits string
message-passing between frames that don't share the same origin. It
is available in all modern browsers. It is not supported in IE6 and
IE7.
postMessage is generally considered very secure as long as the programmer is careful to check the origin and source of an arriving
<!-- standard viewport tag to set the viewport to the device's width | |
, Android 2.3 devices need this so 100% width works properly and | |
doesn't allow children to blow up the viewport width--> | |
<meta name="viewport" id="vp" content="initial-scale=1.0,user-scalable=no,maximum-scale=1,width=device-width" /> | |
<!-- width=device-width causes the iPhone 5 to letterbox the app, so | |
we want to exclude it for iPhone 5 to allow full screen apps --> | |
<meta name="viewport" id="vp" content="initial-scale=1.0,user-scalable=no,maximum-scale=1" media="(device-height: 568px)" /> | |
<!-- provide the splash screens for iPhone 5 and previous --> | |
<link href="assets/splashs/splash_1096.png" rel="apple-touch-startup-image" media="(device-height: 568px)"> | |
<link href="assets/splashs/splash_iphone_2x.png" rel="apple-touch-startup-image" sizes="640x960" media="(device-height: 480px)"> |
I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.
From Require.js - Why AMD:
The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"
I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.
from datetime import datetime | |
from sqlalchemy import Column, Integer, DateTime, ForeignKey | |
from sqlalchemy.orm import relationship | |
from sqlalchemy.ext.declarative import declared_attr | |
from flask_security import current_user | |
class AuditMixin(object): | |
created_at = Column(DateTime, default=datetime.now) | |
updated_at = Column(DateTime, default=datetime.now, onupdate=datetime.now) |
// 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, |
W3C Introduction to Web Components - explainer/overview of the technologies