AsciiDoctor and moving to GitLab

A lot of my current projects require writing technical documentation, and it made me think quite carefully about the best practices here. I’ve found out that there are few principles which make me the most effective.

  • Documentation as Code is the most important one. It has the advantages like:

    • The source of documentation could be version controlled with the well-known and mature VCS like Git;

    • New changes could be pre-approved before submitting (e.g. as pull requests);

    • Proper VCS could give quite rich functionality (e.g. git blame to find the author of the changes and the reason for them).

  • Text Includes is another important principle as it allows to:

    • Re-use the documentation fragments (e.g. headers/footers);

    • Include live code snippets (copy-pasted snippets could easily get out of sync).

  • Rich Formatting is a must-have for the user-friendly documentation:

    • Automatically generated ToC;

    • Offline syntax highlight of the source code. It allows to include properly formatted code into the generated documents (PDF, HTML etc);

    • Tables with headers, alignments and merged cells.

Not all markup systems could satisfy those principles (like wide-spread Markdown), therefore I’ve decided to use Asciidoctor (also know as AsciiDoc). I use it for few months already, and could confirm that it is quite mature and reliable format to use.

However, I’ve discovered that not all systems properly support it. In particular, I’d like to refer this GitHub issue: Asciidoctor: support include directives for other asciidoc files. It’s already 3 years old, got a significant number of follow-ups, but looks like it’ll be never addressed (as some core developers left the team after GitHub has been acquired by Microsoft).

And that makes me start the process of leaving GitHub, and switching to GitLab - feature-wise the latter is much more superioir to former (at least, the features I consider important like proper Asciidoctor support). Surely, GitHub has polished UI and huge community, but as a software developer I’m looking into other areas, not design and social communications. The moving process is gradual and ad-hoc - I’m going to move the project only I need to introduce some changes in it (and luckily, GitLab has the nice feature of exporting from other systems including GitHub).

I’d highly recommend to check out AsciiDoc, its quick reference gives the nice overview of its capabilities. And if you decide to use AsciiDoc for your internal projects, I’d like to recommend GitLab too (and even if you don’t use AsciiDoc, GitLab has the quite extensive feature list you may like).

Comments

Post a Comment

Popular posts from this blog

Web application framework comparison by memory consumption

Memory consumption is slightly specific to my area of software development now, but I did some research recently and maybe these results can be useful for others. Of course, I know that precious comparison is very difficult to carry out, but actually I needed only overall picture. And let me admit that results are pretty interesting and even frustrated (at least for me). As a basis I took so-starving project, and measured initial RSS (Resident Set Size) of the each process (local development webservers). Platform: x86_64 Linux (latest Ubuntu with all updates). As a reference, here is the RSS of the interpreters in interactive console mode: Interpreter Version RSS (kB) stackless python 2.6.4 3916 ruby (via irb) 1.8.7 4664 python 2.7.1 5624 php 5.3.5 6924 v8 (via node.js shell) 2.5.9.9 8796 One more reference - the most simplest WSGI app ( example  in the Python documentation). It's RSS: 7336 Kb , so I assume it's almost impossible to consume l
Read more

Trac Ticket Workflow

Trac is the wiki and issue tracking system that is the most used for my software development projects. Let me share few hints about its ticket workflow, especially about the statuses, the roles of the participants, and let me give an example of the workflow config. But if you are interested in other things like Trac plugins, source browser, customizing, etc, let me know. All the information given below regards the workflow described at the end of the article. The original Trac workflow is missed vital features like the support for ticket verifying, or the required ticket statuses range, so I do not use it in my projects. The description of the main statuses: new - the ticket has been created; in-progress - the developer has began to work with the ticket; fixed - the ticket is fixed (the problem issued in the ticket is solved); verified - the ticket is verified (tester or PM has verified that the ticket is fixed correctly); closed - the ticket is closed (it's not
Read more

Shellcode detection using libemu

Shellcode can be seen as a list of instructions that has been developed in a manner that allows it to be injected in an application during runtime. Each security researcher face the shellcodes during their work, and in this article I'll show how to detect shellcodes using Python (via libemu Python binding). Few words about libemu : libemu is a small library written in C offering basic x86 emulation and shellcode detection using GetPC heuristics. Intended use is within network intrusion/prevention detections and honeypots. The information on the site is not actual in some places, so I'll give direct and clear instruction how to get and install libemu. Clone the git repository: $ git clone git://git.carnivore.it/libemu.git Firstly, configure, make and install libemu itself (without binding): $ autoreconf -v -i $ ./configure --prefix=/opt/libemu $ make $ sudo make install If you set up prefix as shown above, you have to add the library path to /etc/ld.so.conf file
Read more