If workers are 5x more productive and wages are flat after inflation, why are profits also flat (after inflation and population growth)? This isn't a case of the corporate oligarchs taking a larger share, this is the pie not growing as fast as that 5x productivity improvement would imply.
Sure, but how do we used to share the increase in productivity ? How do we share it now ? How should we share it ?
;
My feeling is workers had been the "loser" those last 30 years in how are shared the productivity gain.
Ethically I find it wrong.
Economically this did not seemed to offer more growth or positive outcome...
To help clarify why this is a big deal, I'd like to share why I've been so excited about this project...
[tl;dr] - This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.
Static documentation is a lie waiting to happen. Once docs are even slightly out of date, people lose trust and eventually abandon them.
On the engineering side of the dev/design process, this is easy to work around. We generate documentation from code and structured comments, which allows us to trust our docs as an up-to-date point of truth.
If you're building a design system that both engineers and designers will work with, there's no real solution to keeping sketch symbols and React components in sync. You're essentially stuck maintaining "static documentation" for designers in the form of a sketch file.
More often than not, things get busy, or someone forgets to commit a change to the sketch file, and the sketch symbols fall behind the code used in production.
Developers start to receive mocks that don't match the "standard" components they're using. Designers start to wonder why fidelity is lost by the time features make it to production. The design system falls apart.
`sketch-reactapp` will help us deal with the static documentation problem the same way we deal with it on the engineering side of things: generate from source.
This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.
That seems like it has some value for super large teams. I guess the thing I'm having a hard time wrapping my head around is the workflow for a tool like this. My current understanding is that you'd need:
1.) Design your thing in Sketch
2.) Code your thing in a text editor
3.) Port your code over to this new tool to see it rendered in Sketch?
Like I said. There's some value there (accounting for the changes between 1 & 2), but the workflow feels weird. Maybe someone from AirBnB design can jump in and enlighten me.
Yeah this confused me as well, but some other comments here clarify the situation: there's one sketch file that is the "design system" (containing the "components"), then a bunch of other sketch files for the actual pages of the site or screens of the app... it's only this "components" file that is generated from code. Sketch is used for the design of the pages/screens/etc, but they are pulling the components from the "design system" file.
As with most misunderstandings/disagreements/arguments in the programming world, this confusion arises from people in different contexts using a tool for one purpose, but not realizing that other people are in different situations trying to achieve different goals with those same tools.
(Specifically, if you are an agency or freelance designer/developer, and you are building a bunch of different sites, then this tool does not serve any useful purpose... but if you have an underlying "design system" and a large company with lots of different products all sharing the same basic design, and a large team to go with it,then this starts to make a lot more sense.)
I work on the design system side. In size of Airbnb, you need some kind of design system, since the product fairly large, its changing every week, it's built for 4-6 platforms at the same time by dozens different teams and designers. Without a system the product design and therefore the product becomes chaotic and inconsistent over time.
I do think that design systems can be helpful for smaller, or even 1 person teams as well. It helps you to apply meaningful constrains for your design and reuse common components across the product to shorten development times.
Where the React-Sketchapp comes in is help us to keep the system up to date for designers, and in the future build other tools that can help the design workflow.
I've also had the experience of getting "suspicious looks" while walking in suburbia.
I was once stopped and questioned by a police cruiser because I was walking on a well lit street at night in my Ohio hometown. The officer was reluctant to accept that anyone would walk for the sake of walking - and yes, I've read "The Pedestrian" by Ray Bradbury [1]. Truth can be as strange as fiction.
After living in NYC for 10 years, walking has become such a natural part of life that I completely forgot how unusual it was in suburban Ohio.
I can't help but think that the lack of walking goes beyond negative health effects; I feel like it erodes civil society to a certain degree. When you drive door to door, you rarely interact with strangers. Given my experience, I don't think "paranoia" is too harsh of a word to describe what car-focused settlement patterns can do to people.
Comic Sans does serve one good purpose; it's a dyslexia-friendly typeface. It's nice that Comic Neue preserves some of the letter "hints" (ie. the "b" and "d" glyphs have slightly different bottom terminals).
Although if you're trying to optimize specifically for dyslexia, you'd be better off with something like OpenDyslexic [1].
Amazing. Under "other states", I noticed a few minor engagements in "CA". I wondered if I had read that right - California?
This ended up bringing me to an article[1] about California's involvement in the Civil War, a state that I had previously written off as uninvolved in the conflict. Not only was there a significant union fort in what is now Los Angeles, but they had camels(!?) for desert operations.
While very well executed, the basic idea of delivering a document that doesn't make sense without javascript just seems wrong to me.
I've always thought the real promise of responsive design is "mobile first", delivering a basic document that works on its own, then enhancing layout/resolution for larger viewports and browser capabilities using CSS. This approach basically does the opposite.
I'm not sure what mobile first has to do with javascript dependencies. The reality is that all modern browsers (and web sites in general) expect a working, modern javascript engine.
With that said, if you disable JS on the author's page it still renders content fine.
I've seen these blimps in NYC, Boston, and Chicago to name a few places that are notably far from Akron and Miami. I've always wondered - I'd love to know if the blimps are flown from their base locations to other cities, or if they're somehow trucked in and inflated on location.
The fact that they're considering zeppelins leads me to believe that the normal procedure is to fly them to events, which seems crazy given how slow they appear to be...
I've seen them flying over the city I live in a few times. Bloomington, IL, US - it's between Chicago and St. Louis right on the main Interstate 55. So I would say they normally fly them wherever they are going.
As far as speed goes, they can keep a constant AIR speed, they don't get caught in traffic jams or anything like that.
From the FAQ: The usual cruising speed is thirty-five miles per hour in a zero wind condition; all-out top speed is fifty-three miles per hour on the GZ20. As to cruising range: the ship can carry enough fuel to fly for twenty- four hours, although it rarely does so. When traveling cross-country the blimps fly wherever they go, and the crews try for an eight-hour day, or about 300 air miles.
They do indeed fly them. I grew up in west-central Ohio and every year about 1.5 weeks before the Indianapolis 500 we'd see the blimp fly over, headed west towards Indianapolis.
I agree that it's a bad tool in many ways, but even if the language (and environments) were beautiful, the problem at hand is often the way that people use it.
In this case, a poor craftsman uses his tools to do the things that the browser already does for you.
I've seen some JS that reinvents lots of what the browser rendering engine should handle (recalculating & reflowing heights of elements every time something was added or subtracted from the DOM, for example). Expand this kind of thinking to an entire project, and you start to find yourself in the kind of mess described in the slides.
If/when Dart replaces JS, some of the enforced structure may help prevent badly organized or buggy code, but it won't fix poor assumptions of what concerns scripting should and should not handle.
In the last 10 years, the federal minimum wage has not risen, effectively reducing the minimum wage by about $1 due to inflation.
The richest 500 people in the world grew their wealth by $1.2 trillion in 2019, a 25% increase over a period of one year.
The minority build their wealth on the labor and taxes of the majority, but sure, adjusting the tax code is "stealing".