Hi all. I pushed a PR[1] for the split. I went down this road because I think the docs should closely follow the code, therefore it makes sense that they should live on `master`. The website will be put onto a different branch TBC.
The PR is, *ahem*, huge due to the nature of the change. I don't really expect someone to review it (and don't think it needs to TBH) but more to reach a consensus here then merge it. Best. [1] https://github.com/apache/brooklyn-docs/pull/222 On Mon, 16 Oct 2017 at 10:48 Duncan Godwin <duncan.god...@cloudsoftcorp.com> wrote: > +1 > > I think this format of docs is a massive improvement on the previous, > really great work! Splitting it is also a good idea. > > I'm not a massive fan of putting the docs and website on different > branches, I think this can obscure things. For the short term this might be > a reasonable way to proceed but I think longer term if this split is to be > kept, we should have separate repos or some other mechanism. > > Many thanks > > Duncan > > On 16 October 2017 at 10:25, Richard Downer <rich...@apache.org> wrote: > > > All, > > > > As a co-conspirator on this I am obviously +1 to it :-) But it would be > > good to hear some more POVs on this. > > > > Thomas and I (mostly Thomas) have come up with a solution which we > believe > > has "feature parity" with the current docs solution, except for some > cases > > where we believe the feature is not significant (or actually an > > anti-feature). This solution provides something which is easier to > > navigate, easier to turn into PDF, and it does all these using > > off-the-shelf tools and no bespoke code (no more Ruby-based Jekyll > > plugins!) > > > > The new solution does look different, in that it is not a slave to our > > current website design, but its styling does incorporate the key design > > elements (typography, colour scheme). It is not tightly integrated with > the > > website as the current docs is, but we do not consider this to be a major > > issue. In my personal opinion, having such tight integration turned into > an > > anti-feature, as it caused conflicts between the version-related and > > non-version-related pages. (For an example, browse for earlier versions > of > > the Brooklyn documentation - suddenly there are changes to the website > > styling and the illusion of close integration is lost). > > > > I am in favour of proceeding with this change and seeing how it goes - if > > it does not work out, then we can revert back. Any documentation changes > in > > the affected period should be easily backportable to the old-style > website. > > > > In addition to Thomas's branch which forks the existing brooklyn-docs and > > deletes the website, I have an alternative fork which deletes the docs, > > where work on the website-only tools and content can be done. With the > docs > > removed there's a lot of scope to remove lots of code from the tooling. > In > > the future we would maybe want to look at further changes to the website, > > such as upgrading to a newer version of Jekyll and investigating newer > > Jekyll plugins, with the aim of removing all our bespoke code. > > > > Richard. > > > > > > On 15 October 2017 at 17:20, Thomas Bouron <thomas.bouron@cloudsoftcorp. > > com> > > wrote: > > > > > Hi all. > > > > > > I just pushed the last set of commits to my fork for the docs[1]. This > > now > > > contains the docs generated by gitbook and a build script[2] to > generate > > > the javadoc at the right place (i.e. misc/javadoc). The last commit[3] > > > updates the README to include the updated release instructions. With > > this, > > > I think we are now ready to go. > > > > > > In terms of next steps, Richard suggested to have the codebase for > > website > > > and docs in 2 separate branches. This is how GitHub pages works for > > example > > > and it makes sense to me. Unless someone is against this, I will > create 2 > > > branches on the git repo, `website` and `docs` and open a PR again > `docs` > > > on Monday. > > > > > > Best. > > > > > > [1] https://github.com/tbouron/brooklyn-docs/tree/experiment/gitbook > > > [2] > > > https://github.com/tbouron/brooklyn-docs/blob/experiment/ > > > gitbook/javadoc/build.sh > > > [3] > > > https://github.com/tbouron/brooklyn-docs/commit/ > > > e931560888ce51625e56e6202ead757f9d876090 > > > > > > On Fri, 13 Oct 2017 at 13:02 Thomas Bouron > <thomas.bouron@cloudsoftcorp. > > > com> > > > wrote: > > > > > > > Hi Alex, all. > > > > > > > > For the past few days, I worked with Richard on this doc spike. Here > > is a > > > > short summary of what we have done: > > > > - add collapse/expandable sections on the left menu > > > > - add documentation versioning (version dropdown, top left) > > > > - improve PDF output > > > > - fix all internal links > > > > - use brooklyn styling > > > > > > > > One thing left is to use YAML examples from the Brooklyn codebase. > > There > > > > is a plugin to do exactly that (which supports to import only a > snippet > > > > from a file) > > > > Unfortunately, most of the doc examples exist only in the docs repo > > > > therefore I think we should resolve this later on, as an incremental > > > change. > > > > > > > > I published the new version on the same URL as before[1], hope you > will > > > > like it. Spoiler alert: I do :) > > > > > > > > PS: I created a gitbook plugin[2] to auto-generate menus on pages > like > > > > this one[3]. However, I had a chat with a maintainer (founder?) of > > > Gitbook > > > > who told me[4] that version 4 will include, out of the box, most > > plugins > > > we > > > > currently use! They have a preview[5] of what is does. > > > > > > > > Best. > > > > > > > > [1] https://tbouron.github.io/brooklyn-docs > > > > [2] https://github.com/tbouron/gitbook-plugin-partial-summary > > > > [3] https://tbouron.github.io/brooklyn-docs/start/ > > > > [4] > > > > https://gitbook-community.slack.com/archives/C0B5XG0GK/ > > p1507893620000134 > > > > [5] https://betadocs.gitbook.com/features > > > > > > > > On Tue, 10 Oct 2017 at 12:20 Alex Heneveld < > > > > alex.henev...@cloudsoftcorp.com> wrote: > > > > > > > >> > > > >> Thomas- > > > >> > > > >> Had a deeper look -- gitbook has moved things forward a lot. Sounds > > like > > > >> it will let us throw away a lot of our home-grown docs-building and > > > >> toc-building code and have good search. Look forward to seeing how > it > > > >> shapes up with styling and guide-v-website integration. > > > >> > > > >> Best > > > >> Alex > > > >> > > > >> > > > >> On 09/10/2017 09:54, Thomas Bouron wrote: > > > >> > Thanks Mark. > > > >> > > > > >> > Regarding maintenance, it will be as easy as the current version. > > > >> Updating > > > >> > docs means updating markdown files. Adding/moving pages requires > to > > > >> modify > > > >> > the `SUMMARY.md` but that's it. > > > >> > One really cool thing is that Gitbook is a node app: really simple > > to > > > >> > install/run compare to our current solution which runs only on an > > old > > > >> > version of ruby => no more pain of using different versions of > ruby > > on > > > >> your > > > >> > environment. > > > >> > > > > >> > In terms of feature gaps, Gitbook provides the same or more > features > > > >> than > > > >> > Jekyll out the box: > > > >> > - search! That is a big one, not available with Jekyll > > > >> > - include of external files > > > >> > - syntax highlighting > > > >> > - plugins system > > > >> > - custom theme > > > >> > > > > >> > Best. > > > >> > > > > >> > On Sat, 7 Oct 2017, 17:10 Mark McKenna, <m4rkmcke...@apache.org> > > > wrote: > > > >> > > > > >> >> Thomas this looks really clean great work. > > > >> >> > > > >> >> How much work do you think it will take to maintain vs our > current > > > >> >> solution? > > > >> >> What do you see as being the current feature gaps? > > > >> >> > > > >> >> M > > > >> >> > > > >> >> On Fri, 6 Oct 2017 at 14:55 Thomas Bouron < > > > >> thomas.bou...@cloudsoftcorp.com > > > >> >> wrote: > > > >> >> > > > >> >>> Hi Richard. > > > >> >>> > > > >> >>> Of course, I pushed it to my fork on the branch > > > >> `experiment/gitbook`[1] > > > >> >>> Glad you like it :) > > > >> >>> > > > >> >>> Best. > > > >> >>> > > > >> >>> [1] https://github.com/tbouron/brooklyn-docs/tree/experiment/ > > > gitbook > > > >> >>> > > > >> >>> On Fri, 6 Oct 2017 at 13:53 Andrea Turli <and...@cloudsoft.io> > > > wrote: > > > >> >>> > > > >> >>>> +1 Thomas, didn't know Gitbook at all (that's why I suggested > > > >> >>> readthedocs) > > > >> >>>> but looks pretty good! > > > >> >>>> > > > >> >>>> Il 06/ott/2017 15:37, "Richard Downer" <rich...@apache.org> ha > > > >> >> scritto: > > > >> >>>> Hi Thomas, > > > >> >>>> > > > >> >>>> I withdraw my previous comments - I looked at ReadTheDocs last > > year > > > >> and > > > >> >>> was > > > >> >>>> pessimistic, but it seems that GitBook this year is a different > > > story > > > >> >> :-) > > > >> >>>> This is worth pursuing IMO. What did you need to do to get this > > > >> >> working? > > > >> >>>> Did you have to do any work on the brooklyn-docs source - if so > > > could > > > >> >> you > > > >> >>>> share a link to your repo? > > > >> >>>> > > > >> >>>> Thanks > > > >> >>>> Richard. > > > >> >>>> > > > >> >>>> > > > >> >>>> On 6 October 2017 at 13:18, Thomas Bouron > > > >> <thomas.bouron@cloudsoftcorp. > > > >> >>> com > > > >> >>>> wrote: > > > >> >>>> > > > >> >>>>> Hi All. > > > >> >>>>> > > > >> >>>>> A demo is worth a thousand words so here is a gitbook > adaptation > > > of > > > >> >> our > > > >> >>>>> current documentation[1] (and only documentation) > > > >> >>>>> This took me only a couple of hours. There are still things to > > > >> >>>>> fix/update/remove like unsupported liquid tags but for the > most > > > >> part, > > > >> >>> it > > > >> >>>>> works like a charm. > > > >> >>>>> Search is available from the search field on the top left and > > > >> PDF[2], > > > >> >>>>> epub[3] amd mobi[4] versions are also available. > > > >> >>>>> The build took only 10 sec + 10 more per offline version. > > > >> >>>>> > > > >> >>>>> The table of content mirrors exactly what we currently have, > > > except > > > >> >>> that > > > >> >>>> I > > > >> >>>>> have limited it to only 2 sub-levels. It means that some pages > > are > > > >> >>>> missing > > > >> >>>>> but I think it demonstrates that our current menu organisation > > > could > > > >> >> be > > > >> >>>>> vastly improved. > > > >> >>>>> > > > >> >>>>> Couple of thoughts on Alex's points: > > > >> >>>>> > > > >> >>>>>> * for the examples, import source code that is actually used > in > > > >> >> tests > > > >> >>>>> (!!!) > > > >> >>>>> > > > >> >>>>> Indeed, an overhaul does not solve it, nor our current > > framework. > > > >> But > > > >> >>>> both > > > >> >>>>> can implement it. > > > >> >>>>> > > > >> >>>>>> * check links > > > >> >>>>> Gitbook checks internal links at compile time and refuses to > > build > > > >> if > > > >> >>>>> something is wrong. AFAIK, there is nothing in the Gitbook > world > > > to > > > >> >>> check > > > >> >>>>> the validity of external links like the Jekyll plugin does. > > There > > > >> are > > > >> >>>>> probably external tools that we can integrate in our build > > > pipeline > > > >> >> to > > > >> >>>>> cover this. However, it seems that even if we have this tool, > we > > > >> >> don't > > > >> >>>> use > > > >> >>>>> it when pushing the website (as I get a lot of errors locally) > > > >> >>>>> Realistically, we will always have broken links, things move > > > around > > > >> >> all > > > >> >>>> the > > > >> >>>>> time. Checking external links is a nice-to-have but far from > > > being a > > > >> >>>>> perfect solution. In any case, I don't see this point as > > important > > > >> as > > > >> >>> you > > > >> >>>>> do. > > > >> >>>>> > > > >> >>>>>> * think through user flow > > > >> >>>>> The clear Gitbook menu exposes this pretty well IMO and better > > > >> >> compared > > > >> >>>> to > > > >> >>>>> the current version so that's a win. > > > >> >>>>> > > > >> >>>>> Best. > > > >> >>>>> > > > >> >>>>> [1] https://tbouron.github.io/brooklyn-docs/ > > > >> >>>>> [2] https://tbouron.github.io/brooklyn-docs/brooklyn.pdf > > > >> >>>>> [3] https://tbouron.github.io/brooklyn-docs/brooklyn.epub > > > >> >>>>> [4] https://tbouron.github.io/brooklyn-docs/brooklyn.mobi > > > >> >>>>> > > > >> >>>>> > > > >> >>>>> On Thu, 5 Oct 2017 at 12:47 Richard Downer < > rich...@apache.org> > > > >> >> wrote: > > > >> >>>>>> Thank you for the research you have done Thomas. I've had > > similar > > > >> >>>>> thoughts > > > >> >>>>>> myself. The original goal of our web+docs was to integrate > them > > > in > > > >> >>> such > > > >> >>>> a > > > >> >>>>>> way that we had a versioned user guide that integrated > > perfectly > > > >> >> with > > > >> >>>> the > > > >> >>>>>> main website. At the time, Markdown tools were relatively > > > immature, > > > >> >>>> with > > > >> >>>>>> Jekyll leading the pack (and being the fashionable choice), > and > > > >> >> very > > > >> >>>>> little > > > >> >>>>>> in the way of viable apps for generating books with structure > > and > > > >> >>>> tables > > > >> >>>>> of > > > >> >>>>>> contents. We did the best we could with the tools we had, but > > > they > > > >> >>>> needed > > > >> >>>>>> significant extensions (via Jekyll plugins and build > > scripting). > > > >> >>> Those > > > >> >>>>>> plugins and scripts have turned into something fairly hairy - > > IMO > > > >> >> we > > > >> >>>>>> shouldn't need to have to write this much code[1] to > generate a > > > >> >>> static > > > >> >>>>> site > > > >> >>>>>> and manual. With hindsight, I would not have argued in favour > > of > > > >> >> this > > > >> >>>>>> model. If I do write my book[2] I will most likely be writing > > it > > > in > > > >> >>>>>> ReStructuredText and processing it with Sphinx (and no > > additional > > > >> >>>>>> scripting/tooling!). > > > >> >>>>>> > > > >> >>>>>> That said, when I have looked at changing Brooklyn's > > > documentation > > > >> >>>>> system, > > > >> >>>>>> it has not looked easy. With our home-grown TOC generating > > code, > > > >> >>> we're > > > >> >>>>> not > > > >> >>>>>> off-the-shelf compatible with other systems. Moving to > another > > > >> >>> system, > > > >> >>>>> even > > > >> >>>>>> if it is Markdown-based, would still involve a lot of manual > > work > > > >> >>>>> changing > > > >> >>>>>> our document metadata to the new system, and adapting to > > replace > > > >> >> the > > > >> >>>>> Jekyll > > > >> >>>>>> plugins and the content that uses them (e.g. syntax > > highlighting, > > > >> >>> file > > > >> >>>>>> inclusion). Unless you have discovered something I didn't, > > > Thomas, > > > >> >>> then > > > >> >>>> I > > > >> >>>>>> fear this will be a lot of work, mostly manual. > > > >> >>>>>> > > > >> >>>>>> In short, yes I like the idea of replacing our home-grown and > > > >> >>>>>> home-maintained code with an existing and supported app, but > > no I > > > >> >>> don't > > > >> >>>>>> think the effort of a big-bang migration justifies the > results > > > *at > > > >> >>> this > > > >> >>>>>> time*. > > > >> >>>>>> > > > >> >>>>>> Some things I would support: > > > >> >>>>>> > > > >> >>>>>> - Continued incremental improvements to both the website and > > the > > > >> >> user > > > >> >>>>>> guide. IMO we have more problems with the content than with > the > > > >> >>>> tooling, > > > >> >>>>>> and we can still make a lot of improvements to the usability > of > > > our > > > >> >>>> docs > > > >> >>>>>> and website without tooling changes. > > > >> >>>>>> > > > >> >>>>>> - Breaking the tight integration between website and user > > guide. > > > >> >>> "Fork" > > > >> >>>>> the > > > >> >>>>>> existing infrastructure but then have two build systems > > tailored > > > >> >> for > > > >> >>>>> their > > > >> >>>>>> purpose rather than one that tried to meet two different > needs. > > > >> >> Would > > > >> >>>>> allow > > > >> >>>>>> the existing stuff to continue to work while opening the door > > to > > > >> >>>>> replacing > > > >> >>>>>> the guide tooling and redeveloping the website, independently > > of > > > >> >> each > > > >> >>>>>> other, at a future date. > > > >> >>>>>> > > > >> >>>>>> - Evaluating how other systems use metadata to describe the > > book > > > >> >>>>> structure, > > > >> >>>>>> and gradually adding support for this to our own tools and > > > >> >> migrating > > > >> >>>>>> content. Then at a later date, when the content is > > > >> >> nearly-compatible > > > >> >>>> with > > > >> >>>>>> GitBook or some other system, it'll be easier to do the > > > migration. > > > >> >>>>>> > > > >> >>>>>> What do you think? Will following an incremental approach > like > > > this > > > >> >>>> allow > > > >> >>>>>> us to make improvements gradually rather than a "big bang" > > > >> >>> replacement > > > >> >>>> of > > > >> >>>>>> tooling? > > > >> >>>>>> > > > >> >>>>>> Richard. > > > >> >>>>>> > > > >> >>>>>> [1] > > > >> >> https://gist.github.com/rdowner/a09a268b37904a03c452797e7afe56ca > > > >> >>>> but > > > >> >>>>>> consider the COCOMO figures with appropriate cynicism > > > >> >>>>>> [2] > > > >> >>>>>> > > > >> >>>>>> > > > >> >> https://lists.apache.org/thread.html/ > > 6f19475bbc0570a3b9e3d1ae1b75b2 > > > >> >>>>> b8ee4b2485b3b41d085c342dff@%3Cdev.brooklyn.apache.org%3E > > > >> >>>>>> On 5 October 2017 at 11:23, Thomas Bouron > > > >> >>> <thomas.bouron@cloudsoftcorp. > > > >> >>>>> com > > > >> >>>>>> wrote: > > > >> >>>>>> > > > >> >>>>>>> Hi all. > > > >> >>>>>>> > > > >> >>>>>>> It's been a couple of weeks that I started to look at how to > > > >> >>> improve > > > >> >>>>> and > > > >> >>>>>>> simplify the Brookyln website[1]. As I said on the Brooklyn > > 1.0 > > > >> >>>>>> thread[2], > > > >> >>>>>>> I think we need to sort this out before releasing 1.0. > > > >> >>>>>>> > > > >> >>>>>>> I have looked for a framework / library to handle both the > > > >> >> website > > > >> >>>> and > > > >> >>>>>>> documentation the same way we do it right now. To determine > > what > > > >> >>> was > > > >> >>>>> the > > > >> >>>>>>> best fit, I based my analysis on the following criteria: > > > >> >>>>>>> - Able to take markdown files and generate HTML from them. > > > >> >>>>>>> - Keep the folder structure intact (currently, pages that > > seems > > > >> >> in > > > >> >>>> the > > > >> >>>>>> same > > > >> >>>>>>> logical group - take pages in the download section[3] menu - > > > jump > > > >> >>>> into > > > >> >>>>> a > > > >> >>>>>>> different folder/category/section which is very confusing) > > > >> >>>>>>> - Be skinnable > > > >> >>>>>>> - Able to handle versions for documentation. > > > >> >>>>>>> - Able to generate PDF version of documentation. > > > >> >>>>>>> - Be as "stock" as possible to limit maintenance and pain > > during > > > >> >>>>> upgrade > > > >> >>>>>>> (our current website still uses Jekyll 2.x). > > > >> >>>>>>> > > > >> >>>>>>> 2 contenders clearly jumped out from this: > > > >> >>>>>>> - Jekyll[4] > > > >> >>>>>>> - Gitbook[5] > > > >> >>>>>>> > > > >> >>>>>>> ---- > > > >> >>>>>>> Jekyll > > > >> >>>>>>> > > > >> >>>>>>> With the version 3, Jekyll now has a concept of > collections[6] > > > >> >>> which > > > >> >>>>> can > > > >> >>>>>>> generate pages from markdown files and keep the folder > > > structure. > > > >> >>>>>>> The menu can be generated based on this folder structure > (with > > > >> >>> depth > > > >> >>>>>>> limitation for example) in combination of some clever liquid > > > tags > > > >> >>> and > > > >> >>>>>>> `include`. However, it will be hard to control the order of > > > items > > > >> >>>>>> appearing > > > >> >>>>>>> on the menu. Another easy solution would be maintain list of > > > >> >> links > > > >> >>>> for > > > >> >>>>>> the > > > >> >>>>>>> menu to be generated. > > > >> >>>>>>> There are plugins to generate PDF[7], which happens during > > > >> >> compile > > > >> >>>>> time. > > > >> >>>>>>> Finally, Jekyll is highly skinnable with built-in or custom > > > >> >> themes. > > > >> >>>>>>> ---- > > > >> >>>>>>> Gitbook > > > >> >>>>>>> > > > >> >>>>>>> Gitbook, in its open source version, handles out of the box > > doc > > > >> >>>>>> versioning, > > > >> >>>>>>> PDF generation at runtime (so it seems) HTML pages > generation > > > >> >> from > > > >> >>>>>>> markdown. The menu is built-in feature, based on a simple > > > >> >> markdown > > > >> >>>> list > > > >> >>>>>> of > > > >> >>>>>>> links[8]. This means we need to maintain it but there is a > > good > > > >> >>>> chance > > > >> >>>>> we > > > >> >>>>>>> will have to do this with Jekyll as well. Finally, Gitbook > is > > > >> >> also > > > >> >>>>> easily > > > >> >>>>>>> skinnable[9]. > > > >> >>>>>>> > > > >> >>>>>>> ---- > > > >> >>>>>>> Both frameworks offer mostly the same features. However, > > Jekyll > > > >> >> is > > > >> >>>>> easier > > > >> >>>>>>> to build a website that looks like a "corporate" one whereas > > > with > > > >> >>>>>> Gitbook, > > > >> >>>>>>> you are "stuck" with the design principals it was created, > > i.e. > > > >> >>> serve > > > >> >>>>>>> documentation only. But for this very purpose, it is > extremely > > > >> >> good > > > >> >>>> and > > > >> >>>>>>> easy. > > > >> >>>>>>> > > > >> >>>>>>> Our website is the combination of both a "corporate website" > > > >> >> (i.e. > > > >> >>>>> about, > > > >> >>>>>>> getting started, community, etc - few pages that describe > the > > > >> >>>> project) > > > >> >>>>>> and > > > >> >>>>>>> a documentation. > > > >> >>>>>>> > > > >> >>>>>>> Which leads me to my proposal: separate the website from the > > > >> >>>>>> documentation, > > > >> >>>>>>> at least in terms of how we build it. What I mean by this > is: > > > >> >>>>>>> - Use Jekyll (or even nothing) for the website, except the > > > >> >>>>> documentation > > > >> >>>>>>> part. This will let us build a nice theme (based on > Bootstrap > > 4 > > > >> >> for > > > >> >>>>>>> example) without to worry about complicated plugins and > custom > > > >> >> code > > > >> >>>> for > > > >> >>>>>> the > > > >> >>>>>>> documentation. > > > >> >>>>>>> - Use Gitbook for the documentation alone, applying/adapting > > the > > > >> >>>> theme > > > >> >>>>> we > > > >> >>>>>>> will create from the point above. > > > >> >>>>>>> > > > >> >>>>>>> Best. > > > >> >>>>>>> > > > >> >>>>>>> [1] https://brooklyn.apache.org/ > > > >> >>>>>>> [2] > > > >> >>>>>>> https://lists.apache.org/thread.html/ > > > >> >>> dae4468aa7ef77af9dc8aca24b8434 > > > >> >>>>>>> e9782efbd50fa876618cccf980@%3Cdev.brooklyn.apache.org%3E > > > >> >>>>>>> [3] https://brooklyn.apache.org/download/index.html > > > >> >>>>>>> [4] https://jekyllrb.com/ > > > >> >>>>>>> [5] https://github.com/GitbookIO/gitbook > > > >> >>>>>>> [6] https://jekyllrb.com/docs/collections/ > > > >> >>>>>>> [7] http://abemedia.co.uk/jekyll-pdf/ > > > >> >>>>>>> [8] https://toolchain.gitbook.com/pages.html > > > >> >>>>>>> [9] https://toolchain.gitbook.com/themes/ > > > >> >>>>>>> -- > > > >> >>>>>>> > > > >> >>>>>>> Thomas Bouron • Senior Software Engineer @ Cloudsoft > > Corporation > > > >> >> • > > > >> >>>>>>> https://cloudsoft.io/ > > > >> >>>>>>> Github: https://github.com/tbouron > > > >> >>>>>>> Twitter: https://twitter.com/eltibouron > > > >> >>>>>>> > > > >> >>>>> -- > > > >> >>>>> > > > >> >>>>> Thomas Bouron • Senior Software Engineer @ Cloudsoft > > Corporation • > > > >> >>>>> https://cloudsoft.io/ > > > >> >>>>> Github: https://github.com/tbouron > > > >> >>>>> Twitter: https://twitter.com/eltibouron > > > >> >>>>> > > > >> >>> -- > > > >> >>> > > > >> >>> Thomas Bouron • Senior Software Engineer @ Cloudsoft > Corporation • > > > >> >>> https://cloudsoft.io/ > > > >> >>> Github: https://github.com/tbouron > > > >> >>> Twitter: https://twitter.com/eltibouron > > > >> >>> > > > >> > > > >> -- > > > > > > > > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation • > > > > https://cloudsoft.io/ > > > > Github: https://github.com/tbouron > > > > Twitter: https://twitter.com/eltibouron > > > > > > > -- > > > > > > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation • > > > https://cloudsoft.io/ > > > Github: https://github.com/tbouron > > > Twitter: https://twitter.com/eltibouron > > > > > > -- Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation • https://cloudsoft.io/ Github: https://github.com/tbouron Twitter: https://twitter.com/eltibouron
