Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
| s3cmd setacl s3://bucket/path/to/file --acl-public | |
| s3cmd info s3://bucket/path/to/file | |
| s3cmd setacl s3://bucket/path/to/file --acl-private |
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.offsetParent
Picking the right architecture = Picking the right battles + Managing trade-offs
| Mute these words in your settings here: https://twitter.com/settings/muted_keywords | |
| ActivityTweet | |
| generic_activity_highlights | |
| generic_activity_momentsbreaking | |
| RankedOrganicTweet | |
| suggest_activity | |
| suggest_activity_feed | |
| suggest_activity_highlights | |
| suggest_activity_tweet |
I was poking around trying to figure out all the packages I have access to publish and got curious. So I write this little script to determine the download stats for all the packages I have publish access to.
Feel free to try it yourself. Just change the username passed to getUserDownloadStats.
By default, the stats are sorted by their average daily downloads (descending). That should give you an idea of the most "popular" package of a given user relative to how long that package has been around.
You can use it with npx like so:
