bringking

If anyone wants to know what looking at an Animal or some objects on LSD is like, this is very close. It's like 95% understandable, but that last 5% really odd.

It was pretty important to work with the Project Managers and "scrum-masters" to decouple our release cycle from our sprint cycle. In our case, like yours, they were coupled together for no technical reason. It's hard to sum up all the changes we made to allow it to happen, but mostly it boiled down to a few technical decisions -

* Every PR is treated as "production" ready. This means if it isn't ready for user eyes, it gets feature flagged or dark shipped. Engineers have to assume their commit will go into prod right away. Feature flags become pretty important * Product Owners and QA validate code is "done" in lower environments (acceptance or staging, or even locally during PR phase). This helped us decouple code being in prod and "definition of done" in our sprints. * All API changes and migrations follow "expand and contract" models that makes the code shippable. e.g. even if we are building new features, we can ship our code at anytime cause the public api is only expanding. * More automated quality checks at PR time. Unit tests, integration tests, danger rules, etc. These vary from codebase to codebase. A key part of this is trusting the owners of that code or service. To a degree, if they are happy with their coverage, then they can ship. (Within limits of course. Not having unit tests at least would be a red flag)

Also, we still ship numerous times a day without a full automation test, we just make sure each release is really small (1-3) commits. The smaller the release the easier it is to manually QA it. So nothing fancy is needed, just smaller releases.

So to answer your question, we don't pick and choose work that is "low" impact or "high" impact, all code gets shipped the same and with the same cadence. It is our responsibility to ensure that when it goes to prod, it won't break anything

One of the hardest challenges I have had in my career is convincing our company to move to Continuous Delivery. 90% of the challenges weren't technical, but emotional. Shipping software comes with lots of feelings, fear, politics, etc. I had to personally work with various leaders across the org to help them through these feelings and perceived blockers.

We aren't 100% there yet, but we are shipping numerous times per day across 20 or so services and quality has gone _up_, not down

Oh sorry I should read better! Sorry

React 16 supports streaming! https://reactjs.org/blog/2017/09/26/react-v16.0.html#better-...

Things have recently changed, please try again if you are still interested!

Tucson, AZ and Denver, CO locations as well ;)

We hugged it to death

I prefer the even simpler Michael Pollan guide - “Eat food. Not too much. Mostly plants.”

It's just a beta and we are actively working on new features, so any feedback would be greatly appreciated!

On the plate next is time-travel state replacement, and in-browser NPM importing so you can require other components on the fly.

I am using Yahoo's fluxible app and it is quite good. Doesn't feel verbose at all in every day use.

I agree that it is unacceptable/irresponsible in a way to have a larger payload than is necessary, but I think that is a different issue. Something like selective importing only what you need from the framework vs. the whole shebang.

I am not sure why it's becoming popular to say "It’s unacceptable that the underlying framework is bigger than the application itself." If your domain specific implementation is smaller than the framework itself, it means the framework did exactly what it was supposed to do, it reduced the amount of work you had to do to implement your app.

Thanks, those look great. Good work. Looks a little leaner than fluxible as well, which is always a plus

Does Tuxedo have a plan for Isomorphic applications? I have been following the Yahoo fluxible project since it provides nice abstractions, but was designed for isomorphic apps out of the box.

whats up with the Chinese translations?

The UserAssist registry key was meant for tracking Explorer stats. EA is just reading a reg area that windows is already tracking. Also, you can turn it off. Source- http://www.aldeid.com/wiki/Windows-userassist-keys

Actually the UserAssist reg key is meant for windows explorer usage tracking and does the ROT13 encoding automatically. You can turn off the encoding or tracking in general. Source-http://www.aldeid.com/wiki/Windows-userassist-keys

Thanks for the article. I agree with most of this, however for empty arrays I find it best just to check length in the "falsy" way. Like -

if ( !array.length ) { //do something }

Seems succinct enough not to require a separate function.

nope back.

aaand it's down.

Great work. You even had some breakpoints for smaller widths, which was unexpected for this type of visualization.

I implemented the team hover color. Sent a PR

I have not laughed out loud at a HN post in quite a while. Thank you for that. When I scored the first time and it a said "such player", I laughed quite loudly in my quiet office.

You are certainly entitled to your opinion on her being annoying and fake, but your last statements are just un-called for. Women cannot think logically? Obviously she though logically enough to create an idea that struck a chord with enough people to raise over 250K? Hacker News shouldn't be the place for such blatant misogyny.

Sorry don't mean to negative, each implementation has it's own merits and times when it would be appropriate to use. Good job on building and sharing OP.

I still like this CSS implementation better, rather than a whole jQuery plugin. Works great on mobile as well.

http://jsbin.com/OTaYIFE/2/

I spiced it up a bit with a little animation. kind of hacky since I position the element over the input placeholder using absolute positioning.

http://jsbin.com/OTaYIFE/1/

Makes you appreciate how much layouts have improved with CSS. So much layout code in the javascript. And tables. Tables as far as the eye can see.

It seems to me that this will provide customer validation of questionable quality to the entrepreneur. You can't effectively gauge the viability of an idea by asking people to predict the future. When asked; "Would you use this awesome service?", most people will say "Absolutely"! However, when the time comes to pay for it/download it they will not actually do it. Great looking site, however I feel like the data generated will be less useful than talking to your customers about their past behavior.