| //this foo function is really saying, | |
| //"Hey, I am expecting about 3 arguments but give me what you can" | |
| function foo(a, b, c){ | |
| console.log(a,b,c); | |
| } | |
| //lets ask foo to take more and less parameters than expected | |
| foo("anArg"); // logs in console => anArg undefined undefined |
It's easy to trip up on the meaning of this in JavaScript. The behavior is very different from other languages, which means we have to throw most preconceptions and intuition out the window.
The best way to think of this in JS is as a hidden function argument which is passed in a slightly awkward way. Instead of the normal passing of arguments:
fn(arg1, arg2, arg3)Both command sourcing (CS) and event sourcing (ES) rely on determinism for correctness.
The correctness condition for ES is the determinism (purity) of the function State -> Event -> State. Given that this function is deterministic, aka it always maps the same inputs to the same ouputs, we can rely on it to reconstitute state at any point in time. Determinism is typically achieved by ensuring that the Event has all required information to make the state transition, ie no side effects. The Event then is a sort of "closure" of all pertinent information about the event.
The correctness condition for CS is the determinism of the function State -> Command -> Event. Herein lies one of the distinctions between command sourcing and event sourcing - a program can control its output, but it not its input. Since one can't control the input, aka command, one can't in general, enrich it with all required information to make the above function deterministic. A consequence of this is that you can't simply replay a
Repost from:
http://yangweilim.com/blog/2015/11/18/clojure-thread-first-vs-thread-last-macros/
In this post, I am going to show you {when|how} to use Clojure marcos, ->> aka thread-last and -> aka thread-first. In some case, -> and ->> may perform the same operation if you do not pay enough attention. So I will also show you what's the difference between them. Note that doc -> and docs ->> din't make sense for me at first, so if same thing happened to you I hope that this post will make it clear.
If I am coding a function in Clojure, I would not think to write in macro firstly(maybe I am still new to it?). Macros like -> and ->> only come in my mind when it comes to refactoring. They are not neccessary in our program but they will make it elegant.
To explain how both of these macros work, let's us solve a quiz together.
[Write a function which calculates factorials.](http://www.4clojure.com/prob
| /* | |
| * UPDATE: Looked at the blame, turns out the negative bottom is actually for ensuring layout doesn't change during transitions. | |
| * Still don't know how that works completely, but it has nothing to do with hiding (top: window.height pushes view out of viewport). | |
| * | |
| * I was just looking at Navigator implementation and noticed this line: | |
| * https://github.com/facebook/react-native/blob/master/Libraries/CustomComponents/Navigator/Navigator.js#L110-L113 | |
| * | |
| */ | |
| import React, { | |
| Component, |
Warning: These views are highly oppinated and might have some slightly incorrect facts. My experience with typescript was about 2 weeks in Node and a week in angular2.
TypeScript is implementing their own take on JavaScript. Some of the things they are writing will likely never make it in an official ES* spec either.
Technologies that have competing spec / community driven development have a history of failing; take: Flash, SilverLight, CoffeeScript, the list goes on. If you have a large code base, picking TypeScript is something your going to be living with for a long time. I can take a bet in 3 years JavaScript will still be around without a doubt.
Its also worth noting that they have built some things like module system and as soon as the spec came out they ditched it and started using that. Have fun updating!
| { fontWeight: '100' }, // Thin | |
| { fontWeight: '200' }, // Ultra Light | |
| { fontWeight: '300' }, // Light | |
| { fontWeight: '400' }, // Regular | |
| { fontWeight: '500' }, // Medium | |
| { fontWeight: '600' }, // Semibold | |
| { fontWeight: '700' }, // Bold | |
| { fontWeight: '800' }, // Heavy | |
| { fontWeight: '900' }, // Black |
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
When programmers talk about typing, most of the time they aren't talking about the odious task of pressing keys on a keyboard (watch any programmer and look to see how much of their time they spend actually typing out code. What you'll see instead is a lot of frowning and staring at the screen with an expression of great consternation as you can see them think "why the hell didn't my code do what I thought?"). Instead they're talking about the types of variables. Now you're probably familiar with the idea that there are numbers and strings and
