ericclemmons

New management. There was a reorg (coup) where tech is actively excluded, yet still the target of blame.

I'm redoing that whole stack, as it was a prototype to get buy-in to "fix" the Webpack API for most cases.

For an eslint-style plugin system I'd recommend webpack-blocks.

In Node, I consistently reach for Knex, which is less of an ORM (like Bookshelf) and more like a query builder.

This simplifies binding, mapping, and most queries.

There have been rare situations to use ".raw", but the escape hatch id there.

As a hiring manager, I used to want to see a profile that competed with my own (at the time).

Now I've learned that (1) burnout is real, (2) work CAN be intellectually stimulating enough to not create that OSS desire, and (3) eventually your job ends at 5 and life takes over.

With that said, I WISH more developers opened issues on the projects they've used.

All too often I've seen people drop one dependency for another due to an edge-case.

Even a simple issue explaining the problem, providing a test case or sample code would be great as an indicator to how a developer approaches problems and seeks help.

As a parent, appropriate is determined by my children's ability to yield the knowledge correctly.

Take swears for instance. Until they know better, there's more risk of them using swears at the wrong time.

What's exciting to me, having tested graph.cool and others, they are fantastic at providing an API in a format that works quite well (GraphQL) and handing the admin for me.

I don't want to build admin anymore.

Frankly, I'll spend more money at the service with the best admin UX.

It's like MixPanel for analytics. I can perform complex queries and analysis with minimal friction, which makes it worth the cost.

"Owning" isn't a selling point for me, when all of the services make it possible to dump the data.

Outside of work hours, as long as it doesn't compete it's yours.

Once kids are in bed, it's Overwatch time.

I've struggled with helping people out of this rut.

On the tech side, people come to me with solutions they want to see live, and spend 10x the time there than describing the root problem.

Equally important is asking "why not" to alternative scenarios, as it fleshed out the scope of the root problem, often vetting the initial solution or finding a better one.

If you want a pretty terse way of defining a GraphQL API, Apollo works very well (with mocking, too).

The UX is top notch. Not only is the UI polished, but big details like mentioning someone and an invite link appearing is awesome. Or force-pinging someone on DnD because of an emergency.

Slack is seriously user-centric, all the way down to how they run their Twitter.

Release blog post: https://zeit.co/blog/next

Requiring developers to move is what scares me away...

I was able to rebuild a week's worth of Redux work in MobX within a day. And that's having never used it before.

What's crazy is how MobX is able to update React child components without updating the parent first. It knows which properties are accessed in each component, and ensures only the ones that rely on the changed data are updated.

I'd say give it a shot the next time you have a component with internal state. Not having to worry about the reducer or how the component gets updated is refreshing.

Each time we make a dashboard, we model it after GitHub's status page.

This looks fantastic, simple to implement, and, heck, could be hidden behind a feature flag or auth :)

Great work!

It's interesting that the author states that the majority of traffic cams from Reddit.

When I browse r/javascript, r/react, r/programming, etc. its practically a ghost town: 0 comments on nearly everything and only a dozen posts a day.

I agree that this convention is useful.

We have dozens of Node projects at my office, and you can tell the age of them by whether the start script is "grunt", "gulp", "npm run dev" or "npm start".

Using [per-env][0], we've begun replacing all setup and all starts for every environment to be "npm install" and "npm start".

[0]: https://github.com/ericclemmons/per-env

I'm guilty of this. I was in a 1.5 hour meeting that started out relevant, but then the conversation devolved into tons of specifics on how the reports were gathered and created, and I went straight to the phone.

It seems the greatest burden on the organizer is the same as a presenter: how do you present the information in an impactful, terse way with the least "noise" so that attendees are inclined not to seek distractions?

One thing I know for sure, sitting on a single slide for 5 full minutes feels like a slog.

I haven't seen the short, but every bird clip reminds me of my favorite: Kiwi! (2006) > https://m.youtube.com/watch?v=sdUUx5FdySs

We provide 3rd party widgets to sites and originally built them all to leverage jQuery, which has been on 100% of them so far.

However, we prefer React components. Within a week, we were able to convert the jQuery widgets into React components and bundle with Preact.

What's funny is that it ended up being a smaller bundle due to complex logic it took to make jQuery render and update the DOM from existing state. (React's bread and butter)

Be careful with these, especially on mobile.

I've often encountered a project with a "Docs" link that got hidden or blocked by it.

This is how I learned (and wrote) JS around then. (I don't know when this originally existed, but I discovered it after switching from Prodigy.net to AOL):

http://www.webmonkey.com/2010/02/Advanced_JavaScript_Tutoria...

I'm glad this feature is in, but it's only useful for my PRs.

For example, there was a recent PR where the owner was modeling the UI for a feature with stubbed calls, while I was setting up the backend.

Once my work was done, he wrapped up the rest, and I was no longer needed.

We used notifications to informally say "you're still needed for this!" vs it being part of my daily hit list.

Having worked on a project recently where we chose jQuery (because it was already on the page and we didn't want to delay page load), what I missed about React was the luxury of re-rendering the view from state.

Doing so with jQuery blows away the DOM (causing inputs to lose focus), so we ended up with the usual jQuery soup referencing the DOM for state.