Wait, what happened to 5.1? 2022, that’s what—welcome to CodeTogether 2022.1, our biggest release of the year! Jokes aside, this really is a gargantuan release with many enhancements to the core coding and collaboration experience.
Here’s a brief overview of the goodness you’ll find:
We’re always interested in improving the core coding experience, and there are few features more central to this than content assist. In this release, suggestions appear instantaneously for all remote editors, with improved proposal ordering, just like for the host in their local IDE.
Here’s a very extensive example recorded in an IntelliJ guest, connected to an Eclipse host:
Content Assist Ordering in CodeTogether 2022.1 vs 5.0
And that’s not all with content assist, we also fixed the following bugs:
From the very start, we’ve striven to make the collaborative coding experience intuitive, with seamless shifting of control from one driver to the next. However, in a strict-pairing programming environment, a pair or mob may desire more explicit control over who gets to drive the session, and when. To this end, when you host a session, you can now choose whether you’d like to use our new Explicitly assigned driver mode where the current driver must explicitly grant the driver role to the next driver. Unlike the dynamic mode, simply editing code, opening files, making selections, etc. will not make you the driver, even if none of the other participants are active at that moment. Please see our Session Basics documentation for more details.
Selecting strong-style pairing when starting a session
Example of a strong-style coding session
We’ve added a third, presentation mode, in which only the host can drive the session and make changes to files. Guests can browse the workspace and open other files, but will not be able to change any files in the session, nor will they disrupt any of the other participants in the session.
In addition to the new mode, we’ve made several changes to the collaborative experience that will make it even easier to work together in a CodeTogether session.
We’ve moved from a Room concept to Virtual Cursors, as many first-time users found the idea of “rooms” confusing. If you’ve been with us for a while, don’t worry—virtual cursors work in exactly the same way as rooms did, albeit with an improved UI in the CodeTogether view. If you want to code with a group, simply share a virtual cursor with them as opposed to joining the same room.
In a related change, when you host a session you can choose whether guests who join will start by sharing your cursor, or get their own cursor. You can also leave this decision to them.
When you join a session from an IDE, a dialog will visualize the connection status and progress, guests can see their initial cursor mode and even choose a mode if allowed by the host.
This also addresses a long standing issue we’ve had where sessions hosting large projects/workspaces could not be joined from an IDE. CodeTogether will now ensure that required workspace metadata like the resource tree is loaded before you join the session, with clearly displayed progress. This prevents the crash that would occasionally occur in prior versions.
In the dynamic driver mode, we’ve significantly improved intelligence behind automated driver assignment. Actions beyond editing code, like use of content assist and interaction with IDE dialogs, will now also be taken into account when evaluating driver activity, and a driver is less likely to lose the driver role when they stop typing. As a result, Dynamic Driver Mode now behaves in a much more predictable and intuitive manner.
Even when you’re not a driver, we allow you to break away from the driver to run your own analysis or even make edits (if session permissions allow). CodeTogether will intelligently allow you enough time to make changes or browse code, bringing you back to the driver when appropriate. The time allocated for changes/browsing will be dynamically extended with continued activity on your part.
Controls that allow you to choose another driver, start watching another participant or start coding independently have been overhauled. The state you are currently in is more clearly indicated and easy to change. You will find these controls in the editor border area for IntelliJ & Eclipse, in the status bar and toolbar for VS Code, and in the menu bar for browser clients.
A feature asked for often, when a driver scrolls in a file, followers’ editors will follow to ensure they display the same code. The driver no longer needs to explicitly change his cursor location or make a selection for the followers’ editors to sync.
More details on each of these enhancements can be found in our Session Basics documentation.
Do you want your sessions to go beyond the 60 minute / 3 guest limitation of the Free plan? Well, then get a single subscription to CodeTogether Pro, at a mere $4/month, and you can host sessions of unlimited length with up to 50 guests! Please see our Pricing page for details. CodeTogether Pro has been available since last month, but we didn’t have a release to tell you about it—now you know!
CodeTogether now supports multi-server on-premises deployments! A CodeTogether Locator server and multiple edge servers can be set up to provide service redundancy, load balancing and scalability, or they can be geographically distributed to reduce latency within regions. The CodeTogether locator is also connected to a database which will persist audit logs, metrics and server configuration data.
Please see our Pricing page for details; our sales team will be happy to set you up with a license you can use to try a multi-server deployment yourselves. For setup instructions, please see our On-Premises documentation.
We continue to improve the On-Premises Dashboard.
In this release, you’ll find:
And, for multi-server deployments:
In case you missed our detailed post on it here, CodeTogether users, both of our SaaS and on-premises distributions, were not at any risk from any of the Log4J vulnerabilities disclosed in December last year. With this release, however, we have also removed the unused Log4J JAR that was present in our on-premises distribution.
For advanced functionality, CodeTogether must have access to proposed APIs in VS Code. Due to changes in VS Code 1.63, the setting to allow CodeTogether to use these APIs would not be persisted and users would be repeatedly asked to enable access. A fix for this was already released in version 5.0.3 to the VS Code Marketplace and this is now fixed in our on-premises builds as well.
Note: If you are working with VS Code over WSL, you need to install CodeTogether both Locally and in the WSL environment for the proposed API access to be permanently enabled.
Changes in Windows 11 impacted CodeTogether’s ability to detect shared ports on all IDEs. This release changes to use alternate APIs depending on the version of Windows the IDE is running on.
We’re going to be working on improving the core coding functionality, making sure guests’ experiences in a CodeTogether session continue to coalesce with a local IDE dev experience. Please take a look at our issues tracker and vote for issues you believe will make a big difference to your CodeTogether experience, and feel free to create new feature requests as well. As always, you can chat with us live on Gitter, or drop us a note on Twitter.
To learn more about CodeTogether, read our documentation or check out our videos on YouTube.
Work with a team? Start your 30 day trial of CodeTogether Teams*
*Includes up to 32 participants and unlimited session durations.
