War against "bikes"
I work in a software development company mainly in the field of logistics. I have been working for 3 years, I went through several projects and learned about those that came before me. And it just so happened that for each project, its own internal wiki was established, 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 in this project was gradually forgotten. A new project started and the bicycle production line 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 help it - the opinion of the junior developer `s is rarely taken into account. But again, as time went on, I grew up a bit on the stairs, and I had another one added to all my duties - the UI expert. What it is. This is the role of 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), and consulting other projects, as well as the preparation of analytical reviews on their requirements. All these reviews were included in a special section of one of the project wikis, and every two weeks a wikikast was compiled with an overview of the most interesting articles.
This activity turned out to be more than useful to the company, I gained "points" and at some point with the help of the bosses' support the war against bicycles was launched. It was decided to make a single data warehouse, where all accumulated and found information would be stored and accumulated. The front was deployed in two directions: a single wiki and an internal blog.
The first step was to move from the set of separate wiki to one, where there would be sections for each project, a general section for information about the company, an examination section (UI, server side and others), a section for QA commands, as well as a section with various Useful tips and library components of the internal maven repository. When it was decided that such a wiki is necessary, there was a question in choosing the 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. Resolve these disputes was possible thanks to such a resource as WikiMatrix . What is this resource. It contains information about about 50 different engines and it is possible to compare interesting engines for you. 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 is collected here, it is possible to look at the available implementations and ask the experts for advice.
')
After long comparisons, we decided to stop at DokuWiki . This engine liked both its default capabilities and the ability to expand.
At a certain point, there was a political question about moving from an 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 described various tools for convenient relocation.
The creation of a wiki bore fruit, but the main disadvantage of the wiki is the lack of communication. But communication and brainstorming are the main tools in solving problems. Therefore, it was also decided to raise and their internal blog. Again, there was a question of choosing the engine. One option was even to use the plugin for DokuWiki. But the already beloved design of Habr has had its effect - the LiveStreet engine was chosen. In the pros of this engine and as already mentioned, a convenient and familiar design, again a set of regularly replenishing plug-ins, detailed guides and help on the site itself. All this undoubtedly made this engine our favorite. I will give a list of the main features from the developer's site:
What is published in our internal blog. Here are all the news on projects, on changes in the company itself, reviews of examinations, reviews of new technologies (for example, a very large blog on maven is kept), Help! Blog, where questions are asked, and of course there are personal blogs of everyone.
An important fact was to get people interested in them to visit this blog regularly. For this a daily digest is compiled and thrown into the general newsletter, containing all new articles. Thus, after a week of using the blog, a third of the employees had already been registered at
blog, and half of them are actively writing.
What we have in the end. As a result, we have a single wiki in which the entire development path of the project is entered, starting from drawing up a technical task and ending with the writing of 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 schedule of employment, I believe that our company has built a good intranet that will increase both the efficiency of each employee and the company as a whole.
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 help it - the opinion of the junior developer `s is rarely taken into account. But again, as time went on, I grew up a bit on the stairs, and I had another one added to all my duties - the UI expert. What it is. This is the role of 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), and consulting other projects, as well as the preparation of analytical reviews on their requirements. All these reviews were included in a special section of one of the project wikis, and every two weeks a wikikast was compiled with an overview of the most interesting articles.
This activity turned out to be more than useful to the company, I gained "points" and at some point with the help of the bosses' support the war against bicycles was launched. It was decided to make a single data warehouse, where all accumulated and found information would be stored and accumulated. The front was deployed in two directions: a single wiki and an internal blog.
Wiki
The first step was to move from the set of separate wiki to one, where there would be sections for each project, a general section for information about the company, an examination section (UI, server side and others), a section for QA commands, as well as a section with various Useful tips and library components of the internal maven repository. When it was decided that such a wiki is necessary, there was a question in choosing the 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. Resolve these disputes was possible thanks to such a resource as WikiMatrix . What is this resource. It contains information about about 50 different engines and it is possible to compare interesting engines for you. 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 is collected here, it is possible to look at the available implementations and ask the experts for advice.
')
After long comparisons, we decided to stop at DokuWiki . This engine liked both its default capabilities and the ability to expand.
Main characteristics
- Work with text files - no database support required
- Simple syntax is supplemented with markup buttons that facilitate editing.
- Extensive markup capabilities, support for HTML, PHP can be included.
- Editing the page in parts
- Automatically save a draft when editing a page
- Automatic creation of a table of contents for a page and a list of all wiki pages
- Unlimited page change history (customizable)
- Ability to upload files, images may be reflected in the text.
- Setting permissions (read, write, create pages, download files, delete pages) for categories of users and users separately for individual pages and namespaces
- Supports sending recent changes via RSS
- Pages are divided by namespace.
- Links inside the wiki and to external resources (InterWiki technology)
- Ease of navigation
- Full-text search by own means, page indexing
- Quick search by page name (by AJAX technology)
- Multi-language wiki interface and text support (but not page names)
- Spam protection with blacklist and captcha
- All settings, except for the first run, are performed using a localized web interface.
- A large number of plugins that extend the basic functionality
- OpenSearch support (eng.)
- There is a certain set of ready-made appearance templates. Self-editing is welcome. (all pages are written using php)
Some plugins used
At a certain point, there was a political question about moving from an 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 described various tools for convenient relocation.
Blog
The creation of a wiki bore fruit, but the main disadvantage of the wiki is the lack of communication. But communication and brainstorming are the main tools in solving problems. Therefore, it was also decided to raise and their internal blog. Again, there was a question of choosing the engine. One option was even to use the plugin for DokuWiki. But the already beloved design of Habr has had its effect - the LiveStreet engine was chosen. In the pros of this engine and as already mentioned, a convenient and familiar design, again a set of regularly replenishing plug-ins, detailed guides and help on the site itself. All this undoubtedly made this engine our favorite. I will give a list of the main features from the developer's site:
Main features
- Using UTF-8
- Personal blogging
- The ability to create collective blogs
- Rating system of blogs, topics, comments, users
- Voting system for blogs, topics, comments, users
- Functional comments on Ajax with the ability to navigate
- Full-text site search using Sphinx
- Ability to add topics to favorites
- Auto Tagging
- Collective internal mail
- Access Control System (ACL) to various network capabilities (blog creation, possibility of voting, etc.)
- The ability to create a closed site
- Invites system
- Topics Links
- Topics-polls
- Administer your blogs
- Appointment of blog moderators
- Email Notification Settings
- Time limit for voting for topics and comments
- Ability to screen links from search engines
What is published in our internal blog. Here are all the news on projects, on changes in the company itself, reviews of examinations, reviews of new technologies (for example, a very large blog on maven is kept), Help! Blog, where questions are asked, and of course there are personal blogs of everyone.
An important fact was to get people interested in them to visit this blog regularly. For this a daily digest is compiled and thrown into the general newsletter, containing all new articles. Thus, after a week of using the blog, a third of the employees had already been registered at
blog, and half of them are actively writing.
Results
What we have in the end. As a result, we have a single wiki in which the entire development path of the project is entered, starting from drawing up a technical task and ending with the writing of 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 schedule of employment, I believe that our company has built a good intranet that will increase both the efficiency of each employee and the company as a whole.
Source: https://habr.com/ru/post/288194/
All Articles