hire_charts

The trick to making an open office plan work is to use the lack of walls to increase the square footage per employee. On top of that, it really helps to have "break-out" spaces or quiet rooms, where you can go to get some work done away from the bustle.

The problem is that it's easy to fall into the trap of cutting costs as part of transitioning to an open plan. You really can't have it both ways -- either you increase productivity and pay more in square-footage, or you cram everyone into a much smaller space at the cost of productivity and happiness.

The author does not state that React components are literally redrawn like Windows views. He simply recognizes a pattern and makes a pretty apt comparison.

> React by itself doesn’t actually solve how to propagate changes

In my experience, it really doesn't solve the problem all that well for a sufficiently complex app. I'm willing to give the author the benefit of the doubt on that point.

By that argument, you lose energy when gasoline evaporates during transportation. In both cases (electricity and gasoline) loss is marginal and can be mitigated by striking a balance between centralization and transport/power line distance.

Personally, I haven't -- is there a way that the benefits of these tools could be translated into a ruby-based environment? Are such solutions already available? Would be interested to know more.

Just because some IDEs push the boundary when it comes to dynamic languages doesn't mean it still isn't a downside. By that I mean, on other languages it's not even a problem you have to solve. The solutions to 'go to definition' or 'rename all references' are trivial in languages like the C-variants.

This is definitely the downside of ruby's dynamic/duck typing.

On the flip side, the limitations of ruby forces its devs to adjust the way they write code. Knowing that I may need to use ⌘-shift-f (find in project) to look up method definitions changes some of my conventions, and because operations like refactor-rename (which I use all the time in C#) are very tedious, it forces me to think a bit harder up front when designing a class's API surface.

I'm not arguing that it's better than having good tooling -- just that the lack of tooling adds some interesting constraints that, in some ways, force us to write simpler code.

What's happening here is that it's not just "free access with ads or pay for access." It's "free access if you came from google, so that google can index our pages, but otherwise pay for access so that we can put the same content behind a paywall." It's less a business model and more an SEO trick that Google puts up with under certain conditions.

I support subscription content. But you can't have your cake and eat it too -- in other words, you can't put content behind a paywall and also have it publicly indexed by search engines.

Remove the trick where it's okay for Google searches to circumvent the paywall and this extension becomes useless.

Somehow in college I was able to get up, walk through my apartment, turn off my alarm, walk all the way back, and crawl back into bed, all without waking up. (Or, at least, without remembering later.)

The solution, for me, has been getting into a routine where I can consistently fall asleep earlier. Much easier to do now that I'm not pulling late nights all the time.