Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
CloudFlare is an awesome reverse cache proxy and CDN that provides DNS, free HTTPS (TLS) support, best-in-class performance settings (gzip, SDCH, HTTP/2, sane Cache-Control
and E-Tag
headers, etc.), minification, etc.
- Make sure you have registered a domain name.
- Sign up for CloudFlare and create an account for your domain.
- In your domain registrar's admin panel, point the nameservers to CloudFlare's (refer to this awesome list of links for instructions for various registrars).
- From the CloudFlare settings for that domain, enable HTTPS/SSL and set up a Page Rule to force HTTPS redirects. (If you want to get fancy, you can also enable automatic minification for text-based assets [HTML/CSS/JS/SVG/etc.], which is a pretty cool feature if you don't want already have a build step for minification.)
- If you
#!/bin/bash | |
echo "\n\n--- Killing Stupid Adobe Auto Load Crap ---\n\n" | |
launchctl unload -w /Library/LaunchAgents/com.adobe.AdobeCreativeCloud.plist | |
launchctl unload -w /Library/LaunchAgents/com.adobe.AAM.Updater-1.0.plist | |
echo "\n\n--- Done! ---\n\n" |
'padding-line-between-statements': [2, | |
// Always require blank lines after directive (like 'use-strict'), except between directives | |
{blankLine: 'always', prev: 'directive', next: '*'}, | |
{blankLine: 'any', prev: 'directive', next: 'directive'}, | |
// Always require blank lines after import, except between imports | |
{blankLine: 'always', prev: 'import', next: '*'}, | |
{blankLine: 'any', prev: 'import', next: 'import'}, | |
// Always require blank lines before and after every sequence of variable declarations and export | |
{blankLine: 'always', prev: '*', next: ['const', 'let', 'var', 'export']}, | |
{blankLine: 'always', prev: ['const', 'let', 'var', 'export'], next: '*'}, |
/* | |
* This react hook tracks page visibility using browser page visibility api. | |
* Reference: https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API | |
* | |
* Use: const pageVisibilityStatus = usePageVisibility(); | |
* Return type: boolean | |
*/ | |
import { useState, useEffect } from 'react'; |
this is a rough draft and may be updated with more examples
GitHub was kind enough to grant me swift access to the Copilot test phase despite me @'ing them several hundred times about ICE. I would like to examine it not in terms of productivity, but security. How risky is it to allow an AI to write some or all of your code?
Ultimately, a human being must take responsibility for every line of code that is committed. AI should not be used for "responsibility washing." However, Copilot is a tool, and workers need their tools to be reliable. A carpenter doesn't have to
const separator = ', '; | |
const dvType = SpreadsheetApp.DataValidationCriteria.VALUE_IN_RANGE; | |
function onEdit(e) { | |
if (e.value != null && e.oldValue != null && e.value !== "") { | |
var dataValidation = e.range.getDataValidation(); | |
if(dataValidation != null && dataValidation.getCriteriaType() == dvType && | |
e.value.indexOf(separator) < 0 && e.oldValue.indexOf(e.value) < 0) { | |
e.range.setValue(e.oldValue + separator + e.value); | |
} |
/* wide */ | |
.wide .markdown-preview-sizer { | |
max-width: unset !important; | |
} | |
.life-calendar p a.internal-link { | |
display: inline-block; | |
} |