Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Businesses Software

Corporate Software Development Wiki? 79

Posted by Cliff from the a-different-use-for-a-wiki dept.
gnujoshua asks: "My company would like to expand the use of its Wiki to include source code and API documentation. It would be nice to have auto-generated, syntax highlighted, and well documented source code, integrated nicely into the Wiki. Ideally, changes to source could be made right in the Wiki, barring permissions, and furthermore, it would be nice to see if it compiles against the library as well. What recommendations does Slashdot have for Wikis and scripts that could be used effectively to this end?"
This discussion has been archived. No new comments can be posted.

Corporate Software Development Wiki? More

Corporate Software Development Wiki?

Comments Filter:

  • Perl, of course! (Score:3, Funny)

    by QuantumFTL ( 197300 ) * on Monday February 27, 2006 @04:49PM (#14811492)
    Nothing is impossible with enough perl scripts!
  • Or at least the (pick one) CVS, SourceSafe, or Sourceforge? Why must it be Wiki when there is a perfectly good ecosystem of software that ALREADY DOES THIS JOB?!?!?!?
      • Actually an even better suggestion than any of mine. Mine all do version control- but Subversion adds an Appache Webserver to the mix, thus a client that can run on anything with a browser.
        • Of course, it also means you need to run an Apache webserver to set up the server. Not a hard thing if you have an IT department, but more than I want to do for my home projects. I have no need for a web browser, and am not going to lower my security by running an unnecessary service.
          • Original article in this Ask Slashdot seems to be for a large group, and brought up Wiki (Heck, just look at the title of the page, Corporate Software Development Wiki? would indicate a corporation, not a small time software engineer with no IT department). Wiki would need a webserver to run also.

            For behind-the-firewall-less-than-10-people, Sourcesafe for Windows or CVS is just fine and likely to be on any OS you're running anyway. I like SS because I do a lot of work in Windows on Microsoft tools, so it
            • Out of interest, why would you use Sourcesafe instead of Subversion?
              • Environment being programed for: large state agency with stupid piddling buracratic rules about what we can run on the machines, where every single desktop in the whole state is Windows XP Pro and the *required* IDE is Visual Studio 6 (with .NET coming up from behind- I think we've got two projects out of an application development department of 60 programmers that use .NET so far). Thus, SourceSafe becomes the "natural" thing that is already through the buracratic process to get it installed on the boxes,
                • It doesn't need to integrate as such. You install tortoisesvn and then in any explorer window it shows you what state any svn checkedout file is in, and you can commit, rollback etc. Same for any file (open,save,etc) dialog.
                  What more would you want?
                  • The object browser in Visual Studio isn't a typical explorer window- it doesn't actually show all the source code files, and it's not grouped by directories. Which is more a problem for Microsoft than it is for SVN, but that's what prevents true integration for any other source code control than SourceSafe. And then they go and botch it (hidden files don't check in and out properly if they disappear or reappear, and project/group files actually need you to exit out of the language and come back in to relo
          • Not quite... Subversion runs just fine without Apache using its own protocol. We have SVN running as a service on one of our app-servers, and use TortoiseSVN for the client-side. Smooth like butter.
          • If it's just for home, then don't allow connections from outside. When you install, tell it to listen on loopback device only (127.*)
    • Or at least the (pick one) CVS, SourceSafe, or Sourceforge? Why must it be Wiki when there is a perfectly good ecosystem of software that ALREADY DOES THIS JOB?!?!?!?

      All the options you listed are for engineers only. If only engineers are involved in your design and development process, that's fine. For us, wiki is a great way to document our software development so that it is accessible not just to software developers, but also to documentation developers and tech support. It's great for this purpose beca
      • Actually, on my project we're currently using SourceSafe for everybody from Project Management, to End Users. We find that it's not "Just for engineers" or even "just for source code" as it tracks changes in any text-based file format just fine, thus very useful for finding out just who made a change when. But we're not working in multiple platforms (4500 WinXP workstations in a large state organization) and we're not hiring non-engineers to work in engineering (you really have tech documenters who don't
        • We're not just using wiki for engineering. We use it for cross-displinary communication and documentation. Engineering is only a part of the software development "ecosystem," and other teams should be able to understand what the engineers are doing without having an in-depth knowledge of coding tools. Which is, essentially, what VSS, CVS, and Subversion are. Yes, you can use them creatively for other applications very well, but that is not the purpose for which those tools were created and designed, for sou
          • I consider any CS education that doesn't touch on the value of source code and documentation control to be *seriously* deficient- at my technical college we had it in MIS, CHET, Tech Writing, and SET degrees, because it's just so usefull- but that was admittedly 11 years ago.
          • Seriously, anyone who creates writing that changes over time would benefit by using a version control repository.

            Just look at the history feature of Wikipedia. It's arguably one of the most important features of the encyclopedia.

            If Microsoft Word used a version control repository, a vast majority of business tragedies would be ameliorated.

            How's that for a bold statement.
      • All the options you listed [CVS, SourceSafe and Sourceforge] are for engineers only. If only engineers are involved in your design and development process, that's fine. For us, wiki is a great way to document our software development so that it is accessible not just to software developers, but also to documentation developers and tech support.

        Version control is not just for programmers. It is applicable for almost all computer work, for keeping history, creating an audit trail, enable people to work toge

        • Version control is not just for programmers.

          Which is why MediaWiki, in use by countless people through the website en.wikipedia.org, supports version control for all articles.

  • I'd recommend starting with a generic Wiki (MediaWiki?), and then editing it to suit your purposes.
  • nDoc 1.3.1 has an XML output option. With a bit of work that could be used to populate a Wiki style website. I use nDoc with VS.Net 2002 and 2003, and I believe there is a beta version for working with VS.Net 2005. I'm not sure what other languages it support.

    -Rick

  • TWiki already uses RCS (Score:3, Informative)

    by mrm677 ( 456727 ) on Monday February 27, 2006 @05:01PM (#14811571)
    Interesting idea to integrate a Wiki with a version-control browser. I wouldn't want to use a Wiki as my editor however.
     
      TWiki [twiki.org] uses RCS as its backend. Thus if you use CVS for version control (which is based on RCS), modifying the Perl-based TWiki to talk with your CVS repository should be feasible.

    • TWiki [twiki.org] uses RCS as its backend.

      TWiki also includes some plug-ins that may be useful for the author of this article, such as the SyntaxHighlightingPlugin [twiki.org] (which uses enscript as a back-end).

      I am not sure that I would use a wiki for viewing source code because there are better tools for that (from viewcvs to gforge). But if you really want to, then TWiki [twiki.org] is probably the one that has the most useful features for a corporate environment.

    • Great, this is really helpful advice. I had been thinking more along these lines---I didn't actually want people to use the wiki as the editor, as some trolls have yelled at me for in these posts. But, I think this is the type of set-up I want. Where code, API docs, and everything is closer to all the other documentation. One giant "wiki", or something along those lines. Doxygen, CVS, and other tools are all compatible with this type of environment it seems, so I figured, one step closer to a nice community
  • Our motto is, "The software company with source code that anyone can edit".
  • I don't think this does exactly what you want, but it would be a good place to start.

    Trac [edgewall.com]: "Trac is an enhanced wiki and issue tracking system for software development projects."

    • We've been using Trac for at least half a year at the office and it's simply great.

      You can browse projects from a Subversion repository, syntax-hightlighted and everything. Keep track of tickets/milestones. And of course, you have the wiki.

      Our setup uses SVNManager [sourceforge.net] + Trac for everything related to source control/documentation.

    • If Trac isn't your cup of tea. You might take a look at GForge [gforge.org] It's the OSS version of Source Forge that you can run internally.

    • Long before Trac for Subversion, there was CVSTrac [cvstrac.org] for CVS. It's a little more austere, but offers the same features: integrated wiki, CVS change tracker, CVS browser, and trouble tickets. CVSTrac now can be compiled to support Subversion.

      FitNesse [fitnesse.org] combines a Wiki with an acceptance testing tool. Tables on Wiki pages hold test data and expected outputs; click the "test" button and FitNesse runs your application with the test data and checks the results against the expected values (similar to JUnit and

  • Google (Score:4, Informative)

    by GameMaster ( 148118 ) on Monday February 27, 2006 @05:07PM (#14811618)
    You know, I recommend Google. For instance it took me less than a minute searching on Google to find this http://qbnz.com/highlighter/ [qbnz.com]. It's called GeSHi, and, apparently, it is an open source library for generic syntax highlighting. Maybe you could put just a little bit of effort into looking for a solution before you try to get a community of thousands to spend their time doing it for you. A good first step would be to find your own answer to the other few problems you mentioned now that I've given you one for free.

    -GameMaster

    • Sure, anyone can google and read the over-hyped advertmation about the capability of a particular system. The Ask Slashdot really is expecting responses from people who are using/have tried such software. Most Ask Slashdot's can be answered with a little googling, however it's not always easy to solicit peoples experience there.
    • Isn't the whole point of Slashdot to provide readers a community with which to share experiences, ideas, and opinions?

      I don't know about you, but I can read these news articles in any number of other places on the web. I come to Slashdot to read what this community has to contribute to the topic. I use Google to find links to information about a product, but I'll still seek out opinions from people I trust.

    • Please don't comment on stories in which you have no interest. I'm enjoying the discussion, and learning a lot.

      -
      Cheney's company is building [nytimes.com] prisons [halliburton.com] for the U.S. government.
    • Thanks Game Master, how very narrow minded and pointed your reply was. I actually spent a full day doing research and came across a lot of solutions and ideas. But, when I posted to slashdot, I decided to broaden and simplify my language, in hopes of creating a post that might create interesting discussions and thoughtful responses. Instead of guiding it with specific examples of solutions I had come across. I understand, that you being a troll and all, it is inherent in your nature to be mocking and conden
  • What's the point, exactly? Why would you want to make a very valuable assett editable by anybody? This seems like a HUGE step backwards from having some kind of source control.
    • And why would they? It's not hard to restrict access to a wiki, either from within the code or using a firewall. No different than restricting access to subversion or equivalent. However, unlike subversion and other versioning control systems, a wiki makes it very easy to make excellent documentation.

      My recommendation is to use subversion and write a script that copies the source files to the wiki whenever someone commits changes, if such a script doesn't already exist.

      Better yet, modify the Wiki code (M
  • We run CVS for code, and I have TWiki set up (to experiment with collaboration on an internal wikipedia for engineering discussion). I'm thinking the easiest is to install a CVS Apache web interface (there's at least one I've used before) so that the TWiki entries could at least reference the CVS web pages if desired.
    I agree with other posts that using twiki to directly edit source code doesn't sound like a good idea..

  • The SyntaxHighlightingPlugin [twiki.org] supports over 50 languages.

    And they just released [twiki.org] a nice shiny version 4.0.0 of TWiki [twiki.org], which I can't wait to try out.

  • Trac? (Score:1)

    by j|m ( 144235 )
    Sounds like a job for Trac. http://www.edgewall.com/trac [edgewall.com] . Subversion + wiki + bug tracking.
  • Dokuwiki has a those features already. It's not a behemoth like MediaWiki, but it does a pretty good job. It's intention is to allow developers to document their work without having excessive overhead.
    • I heartily concur. I installed dokuwiki at my current workplace not long after I started working here, cos what there was of the office/company documentation (ie very little) was spread across a Windows fileserver in Word documents (ugh).

      The rest was in the heads of those who were then working there and it left when they did, leading to a lot of reverse-engineering. (Fun, fun fun)

      Jerry :)

  • Preface: Yes, I know they're not open source. Guess what? I don't care! It's great software!

    I highly reccomend Confluence [atlassian.com] as a Wiki for software development. Aside from being just about the perfect Wiki for any purpose, it's got great syntax highlighting and plugins for development. Not sure if it would let you edit directly from the web, but seriously, reconsider that requirement. I doubt anyone would actually use that anyway. It does have JUnit test reports built in too, so it's even better if you're

    • I work for a software company and we extensively use Confluence - highly recommended!
    • I don't know if I would be willing to trust Atlassian. On their page for the top ten features of JIRA here [atlassian.com]

      They have this as the first reason:
      JIRA has features that you just will not find in any other issue tracker:

      * Easily build and save highly-configurable filters (dynamic queries) across all issues in the system.
      Umm... SugarCRM, Bugzilla, SalesForce, and Remedy have this (to varying degrees)

      * Share filters with other users, or subscribe to them and get the results emailed to you periodically.
      In
      • First, I perfectly see your point and I agree with it...
        But you forgot one of the most important (don't know if it's listed on the atlassian website):

        Userfriendliness
        Bugzilla: maybe in version 10, but right now it is a royal pain, to the point of people developing alternative UIs for it.
        SugarCRM: somewhat, but like all these CRM tools it's really bloated.

        The great power of JIRA is more in the details, because on paper, bugzilla is really as good. But put both in the hands of some real users and you
    • We're evaluating Confluence and Jira for our company right now:

      Some positive aspects
      • Confluence has the ability to plug in your own company's authentication and authorization system, which many bigger companies have a need to do.
      • Confluence has a RTF format editor, which is quite nice compared to editing your text with markup directly, previewing, do some more editing, preview again, ...
      • Copying and pasting to/from Word works quite well (but it does not work 100 %).
      • You can quite easily connect Confluence to a

    • Sources are available to commercial licence only ... but it's available. Looks like OpenSource to me. Maybe they should not give non-commercial licenses ?

      http://www.atlassian.com/software/confluence/Con fluenceSourceDownloads.jspa


      AWx

      • Umm, they specifically say it's not open source! [atlassian.com]

        The only difference between open source and free software is the marketing philosophy, anyway. If something isn't free software, it's by definition not open source, either.

        • I'll define OpenSource by 3 points:

          • source code is available
          • source code can be modified
          • source code can be redistributed (under conditions)

          For a company, the point in OpenSource is not its low price. The point is having a safe route: if the underlying company/community disappears or the software support is abandonned or the "must-have" feature is still lacking and not planned at all or early enough, the company can assume the dev/maintanability/evolution by itself.
          So, from a company point of view (if

  • Use SVN and then use TRAC [edgewall.com].

    IT's a wiki!

    It's a source browser (with color highlighting)

    It's a ticket tracking system (can import bugzilla, or be turned off)

    It's a floor wax!

    It's a dessert topping

    (well, not the last two).

    But it's pretty awesome, INSANELY easy to set up, and pretty slick/easy to use.
  • Too damn many of you are missing the point of his question.

    He does not want to store all of his code in the wiki.

    He wants to set it up so that when a programmer CREATES a wikipage on a function, he can include source code FOR A SAMPLE INVOCATION of the function and have that code be nicely formatted, syntax-highlighted and so on without the programmer having to to do it all by hand.

    In other words:
    1. Write function "foo"
    2. Write Wikipage on "foo", detailing function parms, conditions, exceptions, etc.
    3. Write sample
  • if your language/setup of choice already has a repository browser, syntax highlighter and/or javadoc equiv., just link to them from the wiki. we use mediawiki at work, and link to the javadocs, CVSWeb, StatCVS, the Bugzilla report engine, etc.

    (btw, editing your project's source code from a web form for anything but the most trivial projects is a dumb idea. this is why we have IDEs and version control systems)
  • http://www.edgewall.com/trac/ [edgewall.com]

    From the "What is Trac" page:
    * An integrated system for managing software projects
    * An enhanced wiki
    * A flexible web-based issue tracker
    * An interface to the Subversion revision control system

    Seems like that would work well for your purposes. I'm not sure if it does syntax highlighting, but it wouldn't be too hard to add that functionality.
    • I'd have to agree Trac seems to be just what he's looking for. I've been very impressed with it when using packages that manage their development with it.

      And yes, it does syntax highlighting, and I think its the neatest syntax highlight setup I've seen in a while. It is very well done.

      ANother option, harder to setup, but likely more feature rich, would be Horde. Horde has a Wiki module, bug tracking (whups), SVN access (Chora), and more. That's generally been the setup I've used, but Trac is really mak

  • IMHO this sounds like a terrible idea. Are you going to try and get your developers to write their code inside the mozilla text edit box? It's much harder than using vi/emacs/textpad/MyFavEditor.

    Wouldn't it be much better to have your wiki link to something like ViewVC [viewvc.org] so you can see what the current code looks like.

    If this is because you're having trouble getting your developers to comment their code, it's not going to make it easier by commenting in Wiki.

    Anyway I'm a firm believer in documenting the reaso

  • I contracted at a company where we looked into doing what you have suggested in the context of a BI team. Basically, using a wiki to submit code changes is a candidate for the Too Hard basket.

    Instead, what we did was write a bunch of services that interrogated our various source code repositories (database schema, stored procs, code, cube specifications etc) and generate a page for every object we were interested in with links to related objects.

    Each page will contained autogenerated documentation (for

  • we use trac [edgewall.com] with Subversion [tigris.org] and generate documentation automatically with JavaDoc [sun.com] and phpDoc [phpdoc.org].
  • Don't reinvent the wheel. What you describe can be accomplished with Trac.

    Trac [edgewall.com] is a web-based software project management and bug/issue tracking system. It provides an interface to Subversion [tigris.org] and an integrated wiki. It uses Apache and mod_python, but it's really easy to install if you follow the instructions.

    You can see examples of it in use at PylonsHQ [pylonshq.com] and the Django [djangoproject.com] site, both of which are styled nicely. You can see a default install at PyDelicious [python-hosting.com].

    And no, it's not only Python sites that use it. Th

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close