mhodgson's comments

If AWS can't even figure out not to build their status dashboard on their own infrastructure then I think all hope might be lost.

Is it the case that 'Docker for Windows Server 2016' can only run Windows containers and 'Docker for Windows' can only run Linux containers? If so, is there any plan for a solution that can run both side by side?

The reason I ask is because it would be useful, especially on dev machines, to be able to run existing full .NET apps in containers alongside linux containers with Postgres, Redis, etc.

Looks like a nice entrant to the space. React is very well suited to this problem space and they clearly understand many of the pitfalls and problems.

A few questions/concerns:

1. It doesn't look like the undo/redo state is global to the page. The built in undo/redo stack in browsers is global to the page so this is the expectation users will have. If you use multiple instances of Draft.js in your page they will each have their own stack, which is less than ideal. I realize having a singleton to manage this across all editor instances is more difficult in the React/Flux paradigm, but it would be much better from a user experience perspective. Related to this:

2. I don't think you can nest Draft.js instances. There are a number of simple cases where you might want to do this (e.g. custom block with image + caption). To support this in the future it seems you would need to account for it in the selection and undo/redo stack state handling.

3. The data format has a lot of repetition in how it stores inline styles[1]. I'm interested to know why they chose to represent the data this way instead of using indices. For instance, you can represent a inline bold style with a json object like so: {type: 'BOLD', startOffset: 5, endOffset: 10}. The format they chose to use is easier to render directly, but more difficult to parse visually and less space efficient (except in the case of styles that only cover a few characters).

Finally, it seems most modern WYSIWYG editors mentioned in the comments here were at least partially influenced by the original Medium post "Why ContentEditable is Terrible"[2]. It would be great for the community to standardize on a data model/format that could be used in all of these editors. There are enough commonalities (blocks, elements, etc.) that I believe we could create a common document spec that would be usable in all of these popular editors. The benefit of this would be having a common spec to build additional libraries for diffing, server rendering, native mobile editing, and so on.

[1] http://facebook.github.io/draft-js/docs/advanced-topics-inli... [2] https://medium.com/medium-eng/why-contenteditable-is-terribl...

Once you understand how git works under the hood it's actually fairly easy to predict that performance will be poor. A simple checkout involves accessing 100s if not 1000s of objects. Also, you can't fetch these all at once because the objects you need to fetch are determined based on a nested tree. So you have to query the tree all the way down, getting each nested tree or blob based on the previous tree's contents. So ultimately you're doing 100s-1000s of queries for any given git command. Each query is fast, but even at 1-2 ms per query it adds up quickly.

I'm not sure I follow. Our use case required the ability to easily update blobs (in this case formatted written text) without having to rewrite history every time. I don't immutable ref ids addresses that particular requirement...

You could certainly try. I believe the core contributors moved away from the idea of pluggable backends once they realized the performance limitations. It still works great for some use cases, but I think the folks at GitHub quickly realized it wouldn't work for them.

Happy to help. The license is MIT (just added).

In terms of duplicating objects, I believe that if you do choose to store objects from many repos in the same table, they will NOT be duplicated and you will get your space savings. Don't take my word for it though.

We actually did use this code in production for a period of time. In the end we realized that one of the main features of Git, immutability, didn't suit our needs well and we designed a versioning system based closely on Git, but built on Postgres directly. The main benefit of this is using primary keys as the object ids, instead of hashes of the content. This means we can change the content without changing the object's id (which in normal Git then means changing the tree, commit, and every parent commit).

Good luck!

Also, note that some of the code will need updating since it was written specifically with Ruby bindings in mind. Should be easy to spot and update/remove the rb_* method calls.

Lucky for you I actually did exactly this over a year ago. We're not using it anymore so I'll just open source it for you: https://gist.github.com/mhodgson/d29bbd35e1a8db5e0800

Please note that I also don't know much C, but this implementation does work. Also included is a Postgres version of the Ref DB backend (so nothing hits the filesystem). There are a few bits that are not implemented since we didn't have use for the reflog and those parts are technically optional.

Would probably be good to get another set of eyes on this from someone much more familiar with C.

Hope this helps!

Looks interesting. How does is compare with Cube? http://square.github.io/cube/

I'm fairly certain this doesn't work with current versions of Chrome. The experimental support for the -sass-debug-info that this method uses was removed in favor of real sourcemaps landing in sass version 3.3.0.

You can try using the alpha release of sass 3.3.0 to get real sourcemaps but I haven't had any luck getting it to work with rails. It also will not work with compass 0.13.alpha, you have to downgrade to 0.12.2.

What, exactly, do you think is average about Steve Jobs?

Wow, works great. Now I can follow people without having to actually listen to them.