A History of CodeProject
CodeProject was originally designed and built as a place to share source code and documentation in the form of an article. Articles would contain the description and documentation of the source code, with the source code itself housed in static, downloadable zip files. The author (or, rarely, authors) were the only ones able to update the documentation and code, and while some authors were diligent about updating their code to include bug fixes, some weren't.
This was sub-optimal for a couple of reasons. Firstly, with thousands of developers downloading code, tweaking it, fixing bugs, adding missing functionality and updating to cater for new frameworks and operating systems, it was not always the case that code would be updated. There was no formal mechanism to allow an author to be notified (other than the discussion board for the article) that updates had been made, and no formal manner in which updated code could be passed to the author.
Secondly, thousands of members downloading and modifying code samples meant thousands of disconnected copies and versions of the code. Even if a member updated the code and passed it to the author there was no sensible way for the member to merge back changes the author had made (or had included from others).
What we wanted - and have wanted to do since the dawn of time - is elevate articles to the status of Projects (hence the name "CodeProject" - get it?) and provide a more seamless method of interacting with code and with those collaborating on the code.
A History of Workspaces
Workspaces started from the frustration inherent in trying to host Redmine and Git. We'd wanted to move to Git for years and years and we also found ourselves installing Redmine task tracking far more often than sanity suggested was sensible. And it was painful. Beyond words. As developers well down the path of expecting to be hand-fed the ease of use of a Mac and the ease of install of a Windows app we railed against command lines and config files and generating SSH keys and stuff that seemed so last century.
So we did what any red-blooded developer would do and set out to build a system that would make it easy to launch applications. The applications we wanted to use. We wanted the applications to work together, to share a user management system, to work within a single UI and, most importantly, to be single click deployable.
And build it we did.
Workspaces is a platform and framework that allows us to host individual applications within a single UI. Instead of having to check your Git repo in one place and your tasks in another (for instance) you can access all those applications from one place.
We currently have three applications that can run in Workspaces: ::GitMachine: our Git server for managing source code;, ::Tasks, our task tracking system; and ::Docs, our documentation application. More are in the pipeline.
Workspaces uses the CodeProject membership system to manage your logons and authentication, and once you're logged in you can create as many workspaces as you wish.
What's a Workspace?
A Workspace is a place to work on a project. It has a title, description, an owner, and contains a write-up of the project using ::Docs. The workspace itself contains one or more instances of the available applications. For instance, your project might have a single ::GitMachine instance (i.e. a single Git repository) and a single ::Tasks instance (i.e. a single Task Tracker). You may instead want to have a dozen Git repos (i.e. a dozen ::GitMachine instances) and no task trackers. Or whatever combo makes sense. There are no limits.
The owner of the workspace can share the workspace with as many people as they wish, and each person can be assigned a role in order to control access to modifying and updating the workspace.
The CodeProject.com workspace (above) contains two ::Tasks instances and a single ::GitMachine instance. The workspace's homepage shows contains application "widgets" that provide a summary of the content in the application. These widgets can be moved around and resized. Clicking on the header of a widget opens that widget's application.
If you're a Premium Member you can make your Workspaces private, meaning only those you've shared the workspaces with can view it. Premium Members can also manage (if invited to) others' private workspaces. Non-premium members can (if invited) view and interact with private workspaces, but they cannot manage them.
Workspaces and CodeProject
On the one hand we have a code sharing site where the connection between posted code and download (and updated) code is a manual - and tenuous - one. On the other hand we have a flexible platform whose core offering at launch is a Git source code control system with task tracking. It was a match made in heaven, really.
Each article on CodeProject.com has a corresponding workspace that contains a ::GitMachine instance to store the code, a ::Tasks instance to handle the Bugs and Suggestions tab for the article, and a ::Docs instance to display the article's content within the workspace. The workspace applications are synchronised with the CodeProject article so as you update one, the other will automatically be updated.
The upshot of this is that if you're a CodeProject author you already have a workspace.
Types of Workspaces
There are 4 types of Workspaces that you will come across as a CodeProject member: A standard workspace that is yours and that you build and work on; a workspace that is shared with you and which you participate in; a workspace that represents one of your CodeProject articles; and a workspace that is a fork of another's article workspace created when you download the code for an article.
When you visit https://workspaces.codeproject.com (assuming you're logged in) you'll be redirected to your dashboard which will list your workspaces. The first section contains your workspaces: workspaces that you have manually created and to which you've added instances of ::GitMachine and/or ::Tasks and ::Docs. These workspaces are fully flexible and you can do with them as you wish: share them, add new applications, take them private (assuming you have a Premium Membership).
Similar to your standard workspaces are workspaces that others have shared with you. Depending on the role that was assigned you, you may be restricted to only viewing content in these workspaces, or you may have been given admin rights in which case you can manage a shared workspace as if it were your own. If the workspace is private then you'll need a Premium Account in order to be able to manage it.
Your CodeProject Articles
As mentioned, each article on CodeProject.com has a dedicated workspace that tracks all code uploads to that article and stores those uploads as commits in the Git repository. The article's text is also contained in a ::Docs instance, and the "Bugs and Suggestions" tab for each article is powered by the ::Tasks instance from the article's workspace.
Your ::Workspaces dashboard lists all of your article's workspaces on the right hand side. These workspaces are special in that you cannot add or remove applications from the workspace. These workspaces are also intimately tied to their article so modifying the article's workspace will result in a modification to the article itself.
Specifically: If you update the text in the ::Docs application for an article's workspace, you will also be updating the article's text on CodeProject.com. If you make a commit to the Git repo in the GitMachine instance of the workspace, you will also be updating the article's downloadable zip files.
It's seamless and there's nothing an author needs to actually do to accomplish this or maintain it. It just works.
The final type of workspace you're likely to encounter is the article download workspace.
When you download code from a CodeProject article you don't just download the code: you are also forking the workspace and getting a snapshot copy of the entire workspace to play with as your own. This workspace contains a copy of the code at the time you downloaded the article so you always have a history of what you downloaded. Not just the name and location of what you downloaded, but the actual code you downloaded.
This provides you a few nice things:
- A history of all your downloads.
- A stable copy of the code you downloaded that you can work against. You need your team all working against the same set of code rather than having each of them downloading from a (potentially) changing source. Of course it's easy enough to upgrade this snapshot of a download to the latest version of the original authors code if updates are available.
- Your own copy of the code that you can connect to using your favourite Git client. Visual Studio 2013 and Visual Studio 2012 Update 2 both have built in support for Git, as does Apple's XCode, as well as many other IDEs.
OK, but now what?
There are three main workflows we see associated with ::Workspaces.
- You create a workspace, invite some collaborators and build magic. That's the principle behind ::Workspaces and is what we'd love to see lots of.
- You use ::Workspaces to manage your articles. You can update your article's code directly using a Git client, you can manage the tasks, suggestions and bugs associated with your article using the ::Tasks instance, and if you wish you can update your article's text using ::Docs (if you wish to stay in the ::Workspaces environment).
- You use ::Workspaces to explore code you've downloaded. At CodeProject we perfer to load code directly into an IDE instead of fussing around with ZIP files. Workspaces gives you this. Download some code (which creates your own fork) then connect to your fork, read over the code, compile it, play with it and eventually build on it. Then the magic happens: you issue a pull request and you start contributing back to the community.
::Workspaces is continually evolving and we need your input and suggestions. It was built by us for us. However, we want it to be useful for you too. Send us your suggestions, your feedback, and help us build something magic.