The war against the "bicycles"

    I work for a software company mainly in the field of logistics. I have been working for 3 years, went through several projects and found out about those that were before me. And it so happened that each project had its own internal wiki, which at the end of the project was archived and stored in this form on the server. Time passed, people left and came, and the experience gained on this project was gradually forgotten. A new project began and the conveyor for the production of bicycles was launched again.

    I think a similar situation existed not only in our company, but also exists in many others. Personally, this situation did not suit me for a long time, but unfortunately I could not do anything - the opinion of junior developers is rarely taken into account. But again, time passed, I grew a little up the stairs, and I have added to all the duties one more - UI expert. What it is. This is the role of an expert analyst in the field of technology to create user interfaces. My responsibilities include both a review of existing technologies (RIA, Swing and js frameworks), as well as consulting other projects, as well as compiling analytical reviews on their requirements. All these reviews were entered into a special section of one of the project wikis and a wikicast was compiled every two weeks with an overview of the most interesting articles.

    This activity turned out to be more than useful for the company, I scored “points” and at some point, with the support of my superiors, the war against bicycles was launched. It was decided to make a single data warehouse, where all the accumulated and found information would be kept and accumulated. The front was deployed in two directions: a single wiki and an internal blog.

    Wiki


    The first step was to move from a set of disparate wikis to one, where there would be sections for each project, a general section for company information, a section for examinations (UI, server side, etc.), a section for QA teams, and a section with various Useful tips and the maven internal repository component library. When it was decided that such a wiki was necessary, the question arose of choosing an engine. There was a lot of controversy: how pages should be stored - in the form of files or records in the database, which markup to choose, and many others. These disputes were resolved thanks to a resource such as WikiMatrix. What is this resource. It contains information about about 50 different engines and it is possible to compare the engines you are interested in. In the comparison table you can find such items as: General Features (Version, Last Release Date, License, Development status ....), System Requirements, Datastorage, Development / Support, Syntax Features and many others. In addition, information about all the news related to these engines flows here, there is an opportunity to see the available implementations and ask the experts for opinions.

    After long comparisons, we decided to stop at DokuWiki . This engine liked both its default capabilities and the ability to expand.

    Main characteristics


    • Working with text files - no database support required
    • Simple syntax complemented by layout buttons that make editing easy
    • Extensive markup capabilities, support for HTML, PHP can be included.
    • Page editing in parts
    • Automatically save draft when editing page
    • Automatically create a table of contents for a page and a list of all Wiki pages
    • Unlimited page change history (customizable)
    • The ability to download files, images can be reflected in the text
    • Setting access rights (reading, writing, creating pages, downloading files, deleting pages) for categories of users and users separately for individual pages and namespaces
    • Support for sending the latest changes via RSS
    • Pages are divided by namespaces
    • Links within the Wiki and to external resources (InterWiki technology)
    • Ease of navigation
    • In-house full-text search, page indexing
    • Quick search by page names (by AJAX technology)
    • Multi-language support for wiki interface and text (but not page names)
    • Spam protection with blacklisted words and captcha
    • All settings except the first launch are done using the localized web interface
    • A large number of plugins that extend the basic functionality
    • OpenSearch Support
    • There is a certain set of ready-made appearance templates. Self-editing of the appearance is welcome. (all pages are written using php)
    (Used material from Wikipedia )

    Some used plugins




    At some point, the political question arose of moving from the old wiki. The main problem is that interrupting such a volume of text with your hands is not an easy task. And it was nice to know when it turned out that the DokuWiki developers had already taken care of this in the Tips and Tricks section , where one of the items describes various tools for a convenient move.

    The blog


    Creating a wiki has paid off, but the main drawback of a wiki is the lack of communication. But communication and brainstorming are the main tools for solving problems. Therefore, it was also decided to raise your internal blog. Again, the question arose of choosing an engine. One option was even to use the plugin for DokuWiki. But the already beloved design of Habr had an impact - the LiveStreet engine was chosen . The advantages of this engine and, as already mentioned, a convenient and familiar design, are again a set of regularly replenishing plugins, detailed manuals and help on the site itself. All this undoubtedly made this engine our favorite. Here is a list of the main features from the developer's site:

    Key features


    • Using UTF-8
    • Personal blogging
    • The ability to create collective blogs
    • Rating system for blogs, topics, comments, users
    • The voting system for blogs, topics, comments, users
    • Functional Comments on Ajax with Navigation
    • Full-text site search using Sphinx
    • Ability to add topics to favorites
    • Auto-tagging
    • Collective internal mail
    • Access control system (ACL) for various network features (creating a blog, voting, etc.)
    • Ability to create a closed site
    • Invite system
    • Topics Links
    • Survey Topics
    • Administer Your Blogs
    • Designate Blog Moderators
    • Email notification settings
    • Time limit for voting for topics and comments
    • Ability to escape links from search engines


    What is published in our internal blog. All news on projects, on changes in the company itself, reviews of examinations, reviews of new technologies (for example, a very large maven blog), Help! Blog are asked here, where sore questions are asked, and of course there are personal blogs of everyone.

    An important fact was to interest people so that they began to visit this blog regularly. For this, a digest containing all new articles is compiled and thrown into the general mailing list daily. Thus, after a week of using the blog, a third of the employees were already registered on the
    blog, and half of them actively wrote.

    Summary


    What do we have in the end. As a result, we have a single wiki, which enters the entire path of project development, from drafting technical specifications to writing user manuals. There is a blog where daily coverage of new events, technologies and burning topics. Adding to this a single maven repository and server for maintaining a busy schedule, I believe that our company has built a good intranet that will increase the efficiency of each employee and the entire company as a whole.

    Also popular now: