amk_

The breakup of the React package into a bunch of smaller modules really puts packages that treat React as a peer dependency in a pickle. I have a component module using createClass that works fine and exports a transpiled bundle in package.json. I guess now we'll have to switch to create-react-class, or maintain some kind of "backports" release series for people that are still using older React versions but want bugfixes.

Anyone have experience with this sort of thing?

I use and recommend this syntax, but you do have to have babel-preset-stage-2 to enable the class properties transform.

https://babeljs.io/docs/plugins/transform-class-properties/

Cool service. Couple questions:

- Can I save things offline?

- Where did you license all those hand-drawn survival diagrams?

This would be a great party game. Generate a name, then have a pitch contest.

The tags you are describing are useful for planning but they become noise for developers in their day-to-day interactions with the board. Maybe you could use a custom field on your cards or a bracket [3] notation for effort? You could replace the impact tag by stack-ranking your cards in your Inbox/Icebox project.

In general, I prefer to use tags to highlight actionable things like "this is a high priority bug" or "this is ready to deploy" or "this is blocked" more than categorization, which can be better accomplished with separate boards. If your system has the concept of "epics" to group issues, that's a plus as well.

PS you might want to take a look at this article if you're having difficulty prioritizing things: https://medium.com/startup-grind/ruthless-prioritization-e42...

These are the concepts I associate with Kanban:

- Sprints/Cycles:

A period of time, usually 2 weeks, where the scope of work is fixed.

- In Progress List

A column of things actively being worked on.

- Backlog w/Work-in-Progress Limit:

The backlog is a prioritized list of everything you are going to tackle in the current cycle.

Some people would argue that if you don't have a work-in-progress limit, you aren't really doing Kanban (maybe you'd call it a Scrum board or something else instead). Estimate-aware tools like Pivotal Tracker and JIRA enforce this by having you set a "point velocity" for your team and requiring story point estimates for every feature. The cycle backlog automatically overflows into the next cycle when you exceed the velocity.

- Icebox:

An unprioritized list of features from which you draw to create the backlog at the start of a cycle. Pivotal calls it the Icebox; in GitHub/GitLab it's the main issues list; in JIRA it's wherever you set up your board to "pull" issues. In less-structured tools like Trello you have to decide where to keep this list; you might make a separate board to keep track of things needing validation, needing designs, etc. and pull them into the backlog periodically.

The general idea of Agile is to keep this list short.

- Done/Ready

A place to keep delivered tasks.

    --------

From personal experience there a few things that help keep a Kanban system under control:

- Specific, deliverable tasks. Tasks should be deliverable as a chunk. Group subtasks into things that are delivered together (reviewed, tested, deployed). A card should never be resurrected from the Done pile once it's there. Use epics, tags, or labels to keep track of related cards if needed.

- Tasks should have clear acceptance criteria so they can be reviewed swiftly and developers can move onto the next item on the backlog. Fuzzy criteria lead to back-and-forth and context-switching which hurt productivity.

-- Automated testing, code coverage checkers, and linting speed up review.

-- Feature flags make it easy to break up large projects into independently-mergeable chunks, which improves task transparency.

- Track bugs in a separate project/column than your Icebox, but make sure they are added to the in-progress column when addressed. Make it easy for non-devs at your company to add bugs to the list and aggressively dedupe.

- Have some way of indicating task state beyond using columns for everything. Every tool provides tags; some have options more tailored at dev teams. Here are some things that you might want to track:

  -- Review wanted
  -- Accepted/Rejected
  -- Blocked (ideally, with a link to the blocker)
  -- Needs design
  -- Bug vs Feature
  -- Story points/weight
  -- Priority (for bugs)

- Prefer tools that let you easily assign tasks right from the board view, especially to yourself. GitHub-based tools are really bad at this for some reason and require lots of clicks to assign people. Asana and Pivotal are good at this.

I suggest at least playing around with Pivotal Tracker to get a sense of what a very opinionated Agile/Kanban process looks like. You could keep using it or take some of the lessons back to Trello, Asana, JIRA, etc.

There are a couple of good books on the Hun-Roman relationship if you want to learn more about that era:

The End of Empire is a more casual read: https://www.amazon.com/End-Empire-Attila-Fall-Rome/dp/039333...

The Huns by EA Thompson is older but as far as I know one of the canonical works: https://www.amazon.com/Huns-Thompson/dp/0631214437%3FSubscri...

Another fun fact: Attila (aka King Etzel) assists the protagonist Kriemhild, widow of Siegfried, in the medieval saga "The Song of the Niebelungs"

The split one is the Ergonomic model, that's probably what they're talking about. I just switched to the same one from a fairly nice mechanical keyboard and it feels a lot better.

This seems more like a stackoverflow type question, but...

Set the "main" option in the library's package.json to a bundle or index file that exports the public interfaces to your library. Don't expose every source file.

Have you looked at the Quill delta format?

https://quilljs.com/guides/designing-the-delta-format/

The techniques in the conclusions and appendix starting about page 200 are useful in any language

Quite relevant given the meta-topic - "The Structure of Scientific Revolutions" by Thomas Kuhn. It's where the term "paradigm shift" comes from.

Yep, the tricky part is just rewriting your HTML so that it includes the right file. However, it looks look my comment was incorrect and most frameworks have considered that issue. Neutrino and create-react-app use html-webpack-plugin.

https://github.com/facebookincubator/create-react-app/blob/m...

Maybe I'm not explaining myself clearly.

You can use an environment variable to point to a CDN host and use it as a prefix in your code. But you also need to make sure the CDN assets get expired. One approach is to use the stats plugin for Webpack, parse the manifest, and write a helper so that the right files get included in the HTML.

Here is an example of how the webpack-rails gem does it: https://github.com/mipearson/webpack-rails/blob/master/lib/w...

And here is an explanation of why you would want to do that instead of using ETag headers on constant filenames: http://stackoverflow.com/questions/26272271/why-digest-are-u...

EDIT:

In fact after looking into it, Neutrino does use html-webpack-plugin which does exactly that by templating index.html: https://www.npmjs.com/package/html-webpack-template Which is cool!

Yes, you can put the CDN host in an env var, but the link rewriting and asset digesting still needs to be done by the bundler.

One thing that seems to be missing from these SPA app utilities is an automatic way of pointing your root HTML file at an expirable root JS file. In development it's ok to point at `application.js` but in production NGINX/S3/Apache/Cloudfront should be serving something like md5-digest-of-app-bundle.js such that when the bundle content changes you invalidate the cache. If you're using a CDN you'll also need to have a prefix step to change the root url for assets.

Seriously, that plus a hard OFF switch on the front.

https://en.wikipedia.org/wiki/Server_Side_Includes

    <!--#include virtual="../snippet.html" -->

Most servers that you would get for a shared host (ie Apache, NGINX) support this.

An app really becomes an app instead of a view layer for a CRUD API once you start adding in business logic, permissions, unstable networks, etc. I'd love to see a Redux example app that handles those things as cleanly as it handles simple cases.

That's the OS, too.

Yeah, I find it so strange that the Google Authenticator setup includes a step to download a recommended 3rd-party scanner scanner, given that GA is pretty much the most important app security-wise you can install on the phone.

Yes, I read the article through Readability and it actually stripped out the Do and Don't headers

It's not globally editable, it saves your changes locally.

I used TW as a research notebook for a while. The tagging + search worked pretty nicely for organization and the plugins for Latex were handy for adding math.

In fact you can just take a look here (might kill this link in a few days, fyi):

https://alexkrolick.github.io/research-notebook/index.html

EDIT: Here's a helpful "citation" macro for making notes on papers: https://alexkrolick.github.io/research-notebook/index.html#m...

There is: https://en.wikipedia.org/wiki/MHTML

Docx is basically a zipped container for XML + embedded images. What if there was a .mz (zipped markdown) format that markdown editors would treat as a single file for the document + embedded materials?

In 4000 BC?

They teach you this stuff in product design classes.

TRIZ is a way of breaking down an engineering design problem into the thing you want to change, and the thing you can't change (a "contradiction"), then resolving it. A "TRIZ Matrix" is a reference tool that suggests ways of resolving conflicts between common design parameters (strength, weight, durability, manufacturing tolerance, etc.) based on a number of principles that have been validated over the years, like "nesting" or "prior action". Over the years, 40 standard principles (and 39 parameters) have emerged. They all have somewhat cryptic, consultant-handbooky names but make sense when you see some examples[1].

E.g., you have a beam and you want to make it stronger, but can't make it any thicker. You consult your matrix for "strength" vs "area" and get some suggestions such as "use composite materials". Or, applying the principle more generally, you try to extract techniques from the patent library or publications that resolve the problem.

[1]: https://www.triz.co.uk/files/triz_40_inventive_principles_wi...