They developed a lot of systems using OT, even going so far as doing collaborative autocad. There are papers on that if you search for CoMaya and CoAutoCAD. The complexity, especially of the last one, is mind boggling though.
I was also wondering about the difference between patch theory and this. I wonder if one of the reasons for operational transformation is that it is more feasible in semi-realtime environments, for example because transforming the operations is (computationally) easier than doing a merge on the data itself.
I can't speak for Google's system, but with the system I had envisioned "merge" time would have been proportional to the amount of patches diverged, which would always have been tiny. The common case is that you go to apply another user's patch and it applies cleanly. You have to be ready for conflicts but they will generally be rare, even if your latency is fairly large. Remember you actually have to be stomping directly on top of another user's work for the patch to have a problem; possible, certainly, would occur in practice, but not normal.
(Careful design of the patch commutation algorithms could further reduce the problems you face, this and "pasting in a huge swathe of text" being the two basic "huge" operations available to a user in realtime. Imagine one user highlights a huge swathe of text and deletes it while another is trying to add a character or two. Normally this could be a conflict, but depending on how you represent the delete, you might be able to make it so the delete simply eats all further edits to the deleted text. In fact in my system this was actually a major problem due to some other issues (in my system you could limit your visible scope down to, say, a specific "chapter" and then I have a UI problem if that entire chapter gets deleted), but this wouldn't affect Google Wave anywhere near as badly, unless it also has narrowing available.)
I hope for the same. The Bespin project by Mozilla is also interesting in this space, they've built a text engine based on canvas. They target code editing but at least they're solving a (very important) part of the same problem.
I have been seriously considering going the Bespin/canvas way myself. I wrote http://bulletxt.zetabee.com/demo using a bunch of textarea tags but having seen how well Bespin works, I think it would be much better to code it on canvas. It would work much better across all the different browsers.
One important thing to consider before going down that route -- the font metrics in the Canvas API are extremely impoverished, so it will be very difficult to do much more than a simple text editor. In particular, there's no support for constraints, wrapping, etc. You can only ask for the width of a given string. This is particularly nasty if you want to do, e.g., asian languages that are hard to segment. The browser desperately needs real font metrics, segmentation, etc.
You're right. Though I could do what Google is doing. They're not doing direct font-on-Canvas, which would be pretty cool actually. They're creating/editing divs/spans on the fly. I already do that with textareas but the problem is textareas work differently on different browsers where different events get fired for similar actions. So technically, I'm doing almost the same thing they're doing at a basic level (pressing enter in middle of a sentence creates a new textarea below the current one and move the text after the cursor into the new textarea).
What I was wondering if I should do or not is create my own cursor management. The benefit of that will be better control over copy-paste, drag-drop etc. I am trying to build an undo system for Bulletxt and in some browsers, you can just drag-drop text in the same text-area without firing any keypress/up/down events. Then I have to hook on to the onupdated/onchanged events which may not offer enough granularity if you make multiple drag-drop actions. Additionally if you drag text from one textarea and drop it into the other, I can't always tell what the source was in all the browsers. Writing my own layout-engine would definitely solve that issue. Plus undo would be very easy because every mouse-click/keyboard would be an event that can be undone.
I know it's a joke, but the truth is that this is exactly the kind of bug that unit tests won't find. The unit tests would have simulated a bunch of gyro settings, with and without a single gyro failure (but not two gyro failures, as that was an accepted design limitation).
Running the gyros with the torpedo still on the boat, however, would not have been tested because the designers didn't think of it. If they had thought of it, the failure wouldn't have happened in the first place.
Testing can verify that your software works within the space of behavior that you already know about. It can't make up for your failure to understand the problem fully.
It's the unknown and unanticipated failure modes that cause the worst problems. Predicted failure modes at least have code to deal with them, even if it's buggy. Unit tests reduce the bugs, but non-existant code for unanticipated failures, while it doesn't have bugs, doesn't solve the problem.
Testing can verify that your software works within the space of behavior that you already know about. It can't make up for your failure to understand the problem fully.
Thinking about correctly testing software is generally one of the best ways to improve your understanding of the problem.
I quite often find bugs during unit testing simply because I'm forced to think about how the software will break, rather than thinking about how it will (or should) work.
I think of it as being quite similar to waiting overnight to proof-read your own paper. You need to be in the context of the reader, not the writer, or your brain will skim over most mistakes.
Sure, writing tests can find design bugs. But that's not really the question at hand here. The specifics are that we have a clear and obvious requirement ("torpedo should self-destruct if it turns a full 360 degrees") that turns about to be missing an important point ("EXCEPT IF IT IS ON THE BOAT").
No amount of testing the former will lead you to realize the latter. Sure, you might happen to come to the realization while writing the test, but you might do so over breakfast too.
I'm not saying "don't do testing". I'm trying to point out that it has limits. The fact that you've written tests and they pass doesn't get you off the hook for design bugs.
I think his point is that the test itself isn't the useful bit. The useful part is that thinking about what to test can uncover bugs.
This is what FMEA (Failure Modes Effects Analysis) does: you assume failures of every part of the system, rank their likelihood and the end effect and see how your design handles it. A good FMEA assumes everything will fail and analyzes the impact. Unfortunately, comprehensive FMEA is expensive and time consuming so it's usually only done for critical subsystems.
No amount of testing the former will lead you to realize the latter. Sure, you might happen to come to the realization while writing the test, but you might do so over breakfast too.
You're a bit more likely to do it during a time you've set aside to fully consider potential failure scenarios.
I guess I can't argue with that, as it's essentially unfalsifiable. But it's worth pointing out that writing a unit test, which is the subject that started this discussion, is definitely not a time when you're "fully considering potential failure scenarios". Unit tests are narrow and focused, and aimed at verifying features.
What you're talking about is something I'd call white box QA. Which is valuable, though it's essentially just an extension of design, and has the same limits.
My broad point still stands: you can't "process" your way out of this with extra testing. Some bugs are just inherent, and stem from the fact that we're human.
Unit tests are narrow and focused, and aimed at verifying features. What you're talking about is something I'd call white box QA. Which is valuable, though it's essentially just an extension of design, and has the same limits.
It seems like most negative arguments regarding "unit tests" start by defining them as a small subset of what can be usefully tested, and then arguing against the value of testing such an incomplete subset.
I don't see the point of drawing such an arbitrary line. I leverage "unit" tests to automatically test units of code as completely as possible (not just 'verify features'), and I expect the same of tests that others write.
Written as a joke, but in my line of work (embedded systems) this is a big problem. Because most of a product's operation may depend on external inputs, it can be impossible to write a suite of unit tests that are useful without also building and automating hardware to generate the external stimuli.
We've come up with some creative responses to this, but nothing remotely like what's possible when you're just moving data around and not, e.g., testing the hardware's ability to start a 300hp diesel engine at it's low-temperature limit.
I don't know if this is already done. But the second point really begs for an entrepreneur to solve this. A simple model for payment for web apps, you could support one off sales, subscriptions models etc. Make an API for developers and handle all the credit-card processing stuff.
- They're sending 100.000 invites starting from today
- They'll ask some of the invited users to nominate others to also receive early invites
So they're probably not giving all of them away today, not everyone will get invites to share and if you do they won't be direct invites but nominations.
According to the Google Australia team, they won't be releasing the invites until tonight so that they will be up to handle the influx of users.
http://twitter.com/twephanie
Also, here's my email, if the nominations/invites exist: johngunderman[at]gmail.com Thanks :)
I think the title (and article) is a little over the top. The audit trail is a nice feature but the rest is just sharing files?
The real problems are in annotating these drawings collaboratively, merging separate parts and layers of buildings and in general managing the actual flow of information in a design process instead of merely the drawings. Solutions with versioning IFC files, IFD libraries and solving the problems in this area are far more important (and complicated unfortunately). Think like: Which parts of the building were modified in the last version by the architects and how does that influence the building costs? Is the old construction still valid and if not which parts cause conflicts, etc...
EDIT: I forgot to mention that the innovation that woobius does on the user interface side is really great and that they managed to get featured on techcrunch is also great to get more attention to this topic, so all the good to them!
Hi, I'm the founder of Woobius. Firstly, thanks for your kind words on the user interface. We are fortunate to have Cliff Rowley who been a key driving force behind it.
With respect to the body of your comment. The reason Woobius is useful to architects and engineers is that it fits into their existing workflow - e.g. they produce a 2D drawing that forms part of their legal documentation. While this process is (for all intent and purposes), basic, it's often neglected. Being practicing architects ourselves, we realised that by making this easy and efficient, our collaboration cost can be dramatically reduced.
I believe that once we have achieved this first step, we can start to tackle the more complex issue of allowing collaborative annotation on drawings themselves. Hopefully, by which time we would be in position to annotate a 3D model even!
Hi, thanks for your response. I think I just expressed my hopes so I understand it's just a start. I am currently researching annotating / versioning 3d building models however I feel greatly restricted by all the format wars in 3d / CAD land (collada, csg vs brep, autodesk land, ifc (2x3/2x4) and on and on. Does anyone have thoughts on this subject?
They developed a lot of systems using OT, even going so far as doing collaborative autocad. There are papers on that if you search for CoMaya and CoAutoCAD. The complexity, especially of the last one, is mind boggling though.