| // === Arrays | |
| var [a, b] = [1, 2]; | |
| console.log(a, b); | |
| //=> 1 2 | |
| // Use from functions, only select from pattern | |
| var foo = () => [1, 2, 3]; |
Look at the following image...
...it shows an object being tested.
You can't see inside the object. All you can do is send it messages. This is an important point to make because we should be "testing the interface, and NOT the implementation" - doing so will allow us to change the implementation without causing our tests to break.
As configured in my dotfiles.
start new:
tmux
start new with session name:
| 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 |
```mermaid
sequenceDiagram
participant dotcom
participant iframe
participant viewscreen
dotcom->>iframe: loads html w/ iframe url
iframe->>viewscreen: request template
viewscreen->>iframe: html & javascript
iframe->>dotcom: iframe ready
Article by Faruk Ateş, [originally on KuraFire.net][original] which is currently down
One of the most commonly overlooked and under-refined elements of a website is its pagination controls. In many cases, these are treated as an afterthought. I rarely come across a website that has decent pagination, and it always makes me wonder why so few manage to get it right. After all, I'd say that pagination is pretty easy to get right. Alas, that doesn't seem the case, so after encouragement from Chris Messina on Flickr I decided to write my Pagination 101, hopefully it'll give you some clues as to what makes good pagination.
Before going into analyzing good and bad pagination, I want to explain just what I consider to be pagination: Pagination is any kind of control system that lets the user browse through pages of search results, archives, or any other kind of continued content. Search results are the o
| { | |
| "AL": "Alabama", | |
| "AK": "Alaska", | |
| "AS": "American Samoa", | |
| "AZ": "Arizona", | |
| "AR": "Arkansas", | |
| "CA": "California", | |
| "CO": "Colorado", | |
| "CT": "Connecticut", | |
| "DE": "Delaware", |
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <title>Box Shadow</title> | |
| <style> | |
| .box { | |
| height: 150px; | |
| width: 300px; | |
| margin: 20px; |
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
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.