eiriklv

I'd like to go even more back to the fundamentals. Hopefully finishing SICP, building a JavaScript interpreter/compiler and other fun experiments to get a better understanding of the foundation that we're building everything on top of today.

Did the same thing. Then I went even further and bought a maxed out 2011 17" MBP.

This is a good read [0]. Been using this approach in several larger applications for a while (with great success).

By decoupling the selection of state from the actual state structure (using relative selectors) + defining a public interface for your features (your app will basically consist of smaller apps - fractally) you can achieve what you're after.

[0] http://jaysoo.ca/2016/02/28/organizing-redux-application/

At least with the AMD 67X0 models of the MBP the problem isn't the chip itself, but the solder connection (or lack thereof). Same issue as the XBOX 360 RROD. So just replacing from lead free solder to lead solder does the trick.

That's just the price of diagnostics. If you read further you'll see that the full repair price is £169 + shipping. But yes, that confused me at first as well. They replace the GPU and use lead solder.

If the GPU fails and you want to fix it this seems to be the only "permanent" solution: http://www.ebay.com/itm/Apple-Macbook-Pro-A1297-820-2914-B-1...

The 17" MBP is such a beautiful and usable machine. I've been using a rMBP from 2012 until recently, but when Apple announced the new 2016 MBP I went and got a mint maxed out late 2011 17" instead. Just to give it a try really. I now love everything about it (especially the keyboard and the screen). Serviceability and the fact that you can run a 4TB RAID 0 or a 2TB RAID 1 is a huge bonus as well.

Regardless of the justifications Apple may have to continue on their current path, it personally (and very subjectively) makes me sad. They used to be a tent pole in my digital life, but now I feel we've lost touch with each other...

An alternative thought model of Redux could be represented like this:

  function createStore(reducer) {
    let actions = [];
    let subscribers = [];

    return {
      getState() {
        return actions.reduce(reducer, undefined);
      },
      subscribe(subscriber) {
        subscribers.push(subscriber);
      },
      dispatch(action) {
        actions.push(action);
        subscribers.forEach(subscriber => subscriber());
      }
    };
  }

If you start out by digging into how Array.reduce works you're 90% there, which is where the name "Redux" comes from.

Redux can come off as a bit intimidating, but fortunately builds entirely on old ideas and concepts like publish/subscribe, reduce/fold and pure functions that takes a value + an event and returns a new value (reducer function).

Without the middleware support Redux pretty much boils down to this:

  function createStore(reducer) {
    let state = undefined;
    let subscribers = [];

    return {
      getState() {
        return state;
      },
      subscribe(subscriber) {
        subscribers.push(subscriber);
      },
      dispatch(action) {
        state = reducer(state, action);
        subscribers.forEach(subscriber => subscriber());
      }
    };
  }

The advantage of Redux will start to show itself first when your app grows larger and you start doing things like consuming many different views/derivatives of the same state (using selectors) spread across your application.

Redux (core) doesn't actually solve the other big complexity culprit of big web applications though - asynchronous flow and side effects. For that you'll have to look into middlewares like redux-thunk or redux-saga, depending on your needs.

I'd suggest that instead of focusing on specific implementations such as Redux it's a good idea to take a look at those concepts + patterns like CQRS to get an understanding of why you'd want these things in the first place.

It's usually a good idea to feel the pain it alleviates before diving in at the deep end.

I get the feeling that the terms "easy" and "simple" are being mixed up here. MobX is a lot more complex than Redux (core), as it tries to do a lot more things that are braided together as a package. In Redux you choose to bring in that complexity (reselect, redux-saga, etc) if necessary. "Easy" is subjective, "simple" is not.

(cross-post from https://news.ycombinator.com/item?id=12886968)

Take a step back and focus on JavaScript the language. Really learn how things work. Then take a step even further back. Learn more about data structures, about abstractions and how to think declaratively vs. imperatively. Rinse and repeat for the rest of the stack.

That way you'll have a solid foundation to build on top of. At some point you'll start to see patterns, and that all the "new" things are just incrementally improved materializations of patterns and concepts that have existed since way before the web was even thought of.

Spend most of your learning/experimenting time on fundamentals (timeless). Learn actual implementations and specifics when you need to, just in time. Avoid learning specifics (lib/fw) just in case.

Source: My own personal experience + the very insightful experience of teaching classes in JavaScript and React the last two years.

Take a step back and focus on JavaScript the language. Really learn how things work. Then take a step even further back. Learn more about data structures, about abstractions and how to think declaratively vs. imperatively. Rinse and repeat for the rest of the stack.

That way you'll have a solid foundation to build on top of. At some point you'll start to see patterns, and that all the "new" things are just incrementally improved materializations of patterns and concepts that have existed since way before the web was even thought of.

Spend most of your learning/experimenting time on fundamentals (timeless). Learn actual implementations and specifics when you need to, just in time. Avoid learning specifics (lib/fw) just in case.

Source: My own personal experience + the very insightful experience of teaching classes in JavaScript and React the last two years.

The idea behind redux-saga, to push all effects to the edge (handled by a runtime), only handling descriptions of the actual effects doesn't have to be limited to redux/redux-saga either. You can leverage generators + a runtime to build all kinds of applications like this [0] (you can sort of do this without generators too, but it's a bit more quirky when you cannot control/pause the execution [1]). Easy testing (no more mocks/stubs in the traditional sense - only data/descriptions) and predictability are just some of the benefits.

[0]: https://gist.github.com/eiriklv/a498112b3a73fc2b92975649924c...

[1]: https://gist.github.com/eiriklv/b6cc681447a0939365e1ba044fac...

For me it's about lessening the mental taxation that often comes with the added responsibility of owning things. Mostly from giving you more choices and more things to tend to or care about (even if subconscious). Having to decide what to wear, what to eat for dinner or what to buy at the grocery store might seem like trivial things, but when all of these small things are compounded they end up consuming a large part of your mental energy. Owning less things is just one effort to free up that mental energy to be able to use it elsewhere.

Edit: wording

Is there a way to enable casting to Chromecast with Firefox? I haven't found any viable solutions as of yet - but if there were I would jump to Firefox instantly.

I would get those too back when I was a sugar junkie. And I would get them a lot during the time I transitioned from running on sugar/carbs to running on fat.

I skip breakfast as well. I only eat one meal per day, which is the double dinner in the late evening - except for occasional "social eating". I also semi-regularly skip 2-3 days of eating to let the system repair itself (usually increases mental focus and well-being even more).

It took about 3 weeks to get over the withdrawal effect of sugar and what you might call detox (I was the biggest sugar junkie in the world - and had an attention span of 15 minutes tops). That stuff was rough. When the cravings stopped it took about a month or two before the benefits really started to show. After six months / a year it was second nature. Been doing it for 6+ years now. The benefits are so great that I would never consider going back.

It's important to note that you'll have to eat a fat-focused diet (paleo / keto). No sugar, low on carbs. Otherwise you won't get the benefit of not thinking about food, which is essential. After a certain amount of carbs your body will drop out of ketosis and you will get cravings - and that requires will, which drains resources. If you're successful at that your body will after a while get really good at leveraging fat as its main fuel, resulting in even keel energy.

I do this for mental clarity, focus and other health benefits, so I have no experience with the weight loss part. I've been 75kg since I was 17 (30 now) and my weight has never fluctuated more than 1-2kg, regardless of how much I eat. People would say that I eat a lot though. I also rarely exercise (at least hard).

Edit: typo

Nothing, as I fast during the workday usually (either 18/6 or 20/4). I drink lots of water though. Eat the equivalent of 2 dinners in the late evening (70-80energy% of fat is the target). It's pretty liberating not to think about food the entire workday. The only awkwardness is the social part - so I sometimes eat lunch just to join in if I'm working with a team, or for other social reasons.

Edit: Another benefit is that you don't get the after lunch crash.

What has happened to this post? This was posted 3 days ago [1], and suddenly it's posted 1h ago? The same with the comments. For a second there I was freaking out because of deja vu.

[1] - (see this for proof - https://hn.algolia.com/?query=fizzbuzz&sort=byPopularity&pre...)

Cal Newport's "So Good They Can't Ignore You" offers a lot of insight here.

Book - https://www.amazon.com/Good-They-Cant-Ignore-You/dp/14555091...

Talk - https://www.youtube.com/watch?v=IIMu1PGbG-0

Edit: Grammar / formatting

Downside of Secure Crypto: No Backdoors /s

This is my preferred approach as well - and it (anecdotally) works great, since you can then just manually inject any props/spies as needed like any other "dumb" component.

Edit: But he might be pointing to the testing of the actual HOCs/component decorating functions.

Yup - that's more or less what I've ended up with. Just wanted to hear you if you had a better solution at hand. It's pretty much an edge case example, as 99% of all this stuff fit perfectly into the HOC way of thinking. The remaining cases won't add any more context/complexity than using mixins do anyway.

Thanks for all your hard work!

Great post Dan. Just out of curiosity - what's your goto approach for replacing examples like the SetIntervalMixin (https://facebook.github.io/react/docs/reusable-components.ht...) with a HOC? I can't seem to find something that feels very elegant for these cases.

For threaded langs that might be true - but in js there are no race conditions in that sense, so console.logs are usually fine for debugging "out-of-order" stuff as well. This is ofc opinionated and based on preference, so YMMV.

You remove them when you've figured out what's wrong and fixed it

I would guess that this is as close as you get today: http://www.espruino.com/EspruinoBoard

I get your point though. The real hardcore stuff still has to be done close to the metal. But it's pretty amazing how far you can get with just JavaScript today, with everything from server, browser, native and even hardware. Abstractions are powerful.

Not exactly an attiny85, but it's getting close: https://tessel.io/ :-)

There has surfaced quite a few additional approaches now, and I'll try to incorporate all of them into the post.

fixed :-)