Python relative imports in AWS Lambda fail with attempted relative import with no known parent package
In AWS Lambda if I attempt an explicit relative import like this
.
├── lambda_file.py
└── example.py
| 'use strict'; | |
| exports.handler = (event, context, callback) => { | |
| // Get request and request headers | |
| const request = event.Records[0].cf.request; | |
| const headers = request.headers; | |
| // Configure authentication | |
| const authUser = 'user'; | |
| const authPass = 'pass'; |
| #!/usr/bin/env bash | |
| set -e | |
| # Formats any *.tf files according to the hashicorp convention | |
| files=$(git diff --cached --name-only) | |
| for f in $files | |
| do | |
| if [ -e "$f" ] && [[ $f == *.tf ]]; then | |
| #terraform validate `dirname $f` | |
| terraform fmt $f |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParentHello, visitors! If you want an updated version of this styleguide in repo form with tons of real-life examples… check out Trellisheets! https://github.com/trello/trellisheets
“I perfectly understand our CSS. I never have any issues with cascading rules. I never have to use !important or inline styles. Even though somebody else wrote this bit of CSS, I know exactly how it works and how to extend it. Fixes are easy! I have a hard time breaking our CSS. I know exactly where to put new CSS. We use all of our CSS and it’s pretty small overall. When I delete a template, I know the exact corresponding CSS file and I can delete it all at once. Nothing gets left behind.”
You often hear updog saying stuff like this. Who’s updog? Not much, who is up with you?
| { | |
| "name": "my-app", | |
| "version": "1.0.0", | |
| "description": "My test app", | |
| "main": "src/js/index.js", | |
| "scripts": { | |
| "jshint:dist": "jshint src/js/*.js", | |
| "jshint": "npm run jshint:dist", | |
| "jscs": "jscs src/*.js", | |
| "browserify": "browserify -s Validating -o ./dist/js/build.js ./lib/index.js", |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
| /** | |
| * Description: | |
| * removes white space from text. useful for html values that cannot have spaces | |
| * Usage: | |
| * {{some_text | nospace}} | |
| */ | |
| app.filter('nospace', function () { | |
| return function (value) { | |
| return (!value) ? '' : value.replace(/ /g, ''); |