Hydra: Rendezvous-Enabled Text Editing
Tokerat writes "It's incredible what some people dream up. A recent post on MacSlash brought this little gem to my attention, and I have a feeling some of you fellow /.ers will be screaming to get your hands on this: Hydra is a Rendezvous-enabled text editor, which allows several people to edit a text document at the same time. Imagine doing some extreme programming with this, with one person writing code and another following the first and correcting their mistakes & making optimizations simultaneously? It already works with Apple's Project Builder, supports syntax coloring, and the ability to manage access on a per-document basis. Future improvements will include support for RTF and much tighter integration with Project Builder. It looks to me like these guys are really on to something here."
Imagine doing some extreme programming with this, with one person writing code and another following the first and correcting their mistakes & making optimizations simultaneously?
What..? Optimisations are SUPPOSED to be done only when the code has been thoroughly checked and tested, not 'on the fly'!
Oh dear. No wonder most software is crap these days when people adopt that attitute to 'extreme programming'.
Having someone change my code after the fact is bad enough, at least then they can tell (if they're paying attention) what I was trying to do.
Having them change it *WHILE* I was working on it would be horrid. Collaborative projects are one thing, but the example given I don't think is a case I'd like to see anytime soon!
-- If it ain't broke - overclock it more.
Why don't we have this in my office? Being locked out of text doccuments that I share with a half dozen other network users for the better part of a day has cost me a lot of productivity..
dreaming of a mac-equipped office.....
Of course, this also means the two programmers have to be on the same
LAN segment. Rendezvous doesn't route.
Doug Alcorn
Hydra appears to have been developed by a group called "Global Software Engineering." Apple isn't taking credit for anything here, except for their idiot-proof implementation of zeroconf as Rendezvous, and their rapid development tools.
Can you name any modern computer company that INVENTED, not just built off of, any technology?
Depending on how you look at it, not many have.
Imagine doing some extreme programming with this, with one person writing code and another following the first and correcting their mistakes & making optimizations simultaneously? Oh, great, not only would the moron be breathing down my neck while I was typing, he'd be changing my code to! What a recipe for disaster, even when ignoring my revulsion to the idiocy that is Extreme Programming. Someone should not be making changes to your code while you are writing it. That's what a peer-review is for: when you have time to study at it in its entirely and understand the whole scope and logic of it. Second-guessing what you "think" he meant in a code fragment is a piece-o-crap wait to be written. And premature optimization has been proven to be very, very bad time and again! *shudder*
Anonymous Cowards suck.
Why wouldn't an app written in Java using *either* Rendevous not be cross platform?
:D
Apple has released the source to Rendevous already; Tibco has not
GPL Deconstructed
To use an analogy, just about everything done via USB can be done via legacy ports. However, USB makes it easier. That's what rendezvous brings to this process.
To be truly useful for multi-user editing, wouldn't it be helpful to have some sort of version control built in?
What kind of undo facility does it have? Does it keep a history journal of which user makes edits so that edits can be rolled back?
How about a way to lock parts of the document?
This sounds like it could drive a programmer insane. Can you imagine trying to not only keep track of what you're doing in real time but also all the other developers in the project? You might as well get rid of version control and such. Oops my new function doesn't work because Dick Hayde over there changed something in that function over there while I was working on this function.
Having a shared view with other programmers that can IM you and add notes to the code (just in the view, not the actually source) would be useful. Having them live edit the same document as you are is just crazy. If you want others to be able to view your work as you code then try vnc or something like that.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
In reply to your concern (as well as various other, like the fart-smelling guy), there's nothing about this that makes it so you *can't* sit next to each other. Case in point, I share an office with another guy, and we quite often lean over and help each other out with stuff (our desks are side-by-side, I could reach out and hit him if I wanted to). We've even done some hours+ pair programming sessions. If we could both have been working on the program at the same time, it would *definetly* have sped things up. Of course, in order to do that, we would both need to get Macs :-)
How'd he invent it?
... but the techniques have been around for quite some time.
Seems to me he RECOGNIZED that XP existed, and perhaps documented it
The application uses multicast DNS to FIND the service, but then reverts to unicast for actual USE of the service. It'd be quite silly to send all of that information all over the network.
I think you're confusing multicast with broadcast (Which, admittedly, a number of dumb switches tends to do as well. And of course, a hubbed network treats them the same as well). Multicast traffic only goes to those hosts that have actually joined the multicast group. In this particular case, that'd be anyone who's collaborating on a given editing process. Multicast would be a rather good way to go for this sort of project. In fact, a couple of multicast tools (wb for "whiteboard", nt for text editing) were created for just that purpose. And the great thing about doing something that way is that you could be working on a file in California, I could be working on it in Virginia, and twenty other people could be working on it elsewhere, and I'm only sending out a single copy of my packets, and only to the twenty-one people who actually are working on it as well.
If they're not using multicast for Hydra, it's a shame, because multicast would really be a great way to perform this type of operation.
Think of it more like...'live' CVS. Think of it also not in terms of just programming, but other text editing- like, say, a book. According to the Jabber guys, this sort of stuff is incredibly handy for legal documents, which are heavily co-authored.
If you've got six guys in a meeting room, six laptops, and one doc, you can quickly say "okay, bob, edit section 6. Jane, section 3" etc..nobody needs to worry about re-syncing copies of the doc, or CVS servers, or any of that...and people can even watch as the guy edits his particular section. Maybe they notice something amiss, and mention it- "okay, can you rewrite that phrase?" While Bob continues writing, Jane corrects the one phrase...etc. Each team member can work with any number of other people(including zero, ie, on their own.)
While it's fun to joke about people trading insults and deleteing other's writing, that's moot- if you don't have good team dynamics and people are hostile/uncooperative/ego-tripping, that's a people problem, not a technology problem. You can't solve people problems with technology. Well, you can, but it's often far more time-consuming. What takes a sysadmin an hour or two(configure proxy to block porno sites) can often be solved by a 1 minute phone call to HR("Bob is swamping the line browsing porno" HR to Bob: "Surf porn sites again, and you're fired.")
Please help metamoderate.
Exactly, two people editting the same document at the same time is a recipe for disaster. I don't mind collaborating, but you can bet that I want some tools that will allow me to keep a revision history of any editting done. The last thing I would want is some hoser editting out the last 4 hours of my work.
screen does, though. the "small tools" philosophy way of doing things that both vi and screen adhere to says vi is the text editor and screen is the terminal handler. so you can do this kind of collaboration using your editor, your mail client, your web browser... anything that runs from a console. and your editor can stick to adding editing features.
It took all of 10 seconds to use Apple Remote Desktop to copy the Application to 24 machines in the room.
/Network/Applications directory that mounts from a server (using NFS configured from netinfo) on all the clients. You should only have had to drop the .app in there and it would have taken 0 seconds.
Your admin should be shot.
You should have a
...in real time doesn't mean the rest of us are also incapable.
I personally have never had a problem with pair programming. A lot of the time it's like having a second pair of eyes and two extra brain hemespheres, depending who you are working with...
Pair-Programming obviously isn't for you.
I've even found pair programming to be beneficial when sitting with someone who's either learning, or lacks experience as it forces me to explain coherantly what I'm doing and why I'm doing it, which I find helps give me perspective.
Like I said, Pair-Programming obviously isn't for you.
"Communism is like having one [local] phone company " - Lenny Bruce
Nope. GNUstep.
Three of us used Hydra extensively this weekend, preparing editorial material for the next issue of our fanzine, Plokta. It's certainly much more than a demo, as some have suggested. We found it very straightforward and effective to use, and much simpler than any collaborative editing tool I've previously encountered. We were working in a single room on a wireless LAN. Hydra is a relatively simple text editor, with syntax colouring for a range of languages (as it has HTML, it satisfies my limited requirements in a text editor, too). Document owners can choose to share them (and whether to control user access to shares), and LAN users can see a list of all shared documents and ask to join those they're interested in working on. Once shared, text created by each participant is separately coloured. Participants are handily identified with iChat icons and the position of their cursor is noted. It works as advertised; it's possible to work fully interactively and edit simultaneously, which takes some getting used to. When editing editorial text, we would have found it helpful for deleted text to be indicated with strikethrough rather than just deleted. Otherwise Hydra was extremely handy. It both sped up and simplified the process of writing and re-writing material, and version control risks were eliminated. When material was ready to be imported to the laid out document, it could be cut-and-pasted from Hydra, rather than the usual process of saving a copy to the server and then opening on the machine on which the layout was being done. Only other drawback; those of the team not using Mac OS X were disenfranchised (it's taking advantage of Cocoa), and we just can't afford to buy those PowerBooks fast enough. We've also done a test session over the Internet; sharing documents (through our various firewalls) is slightly more fiddly. Once participants and documents are identified, the program remains as easy and straightforward as on Rendezvous. Our wishlist item; that this collaboration system is fully incorporated in Apple's rumoured forthcoming OS X native word processor. Bottom line; it's very useful indeed, and it's free.