One way to do that would be to monitor SMSes for 2FA codes. This can be easily done on Android and iOS. The app can run the payments flow in a phanthomjs esque environment and read off 2FA values from the SMS inbox, and bam! Payment done. Also, there are other options for authorizing recurring payments but at fixed amt, and paper work can't be avoided.
In that case, you could provide the user with a on-device one-click authenticate button (via notification/email, reminding her/him to approve the payment) that'd push the credentials out to your phantom-js instance. I am not sure what RBI complaince mandates, but one might be a strongbox.io away from implementing such a scheme server-side as well, if legal. A lot of care must go into securing such systems, no doubt. And there might be simpler alternatives that I simply cannot think of.
Thank you so much for the pointer to the git-scm-book (in the context of asciidoc/pdf output etc). Sadly the pdf-version, isn't exactly well laid out. It suffers from similar issues that a lot of html-to-pdf-based tools (although I assume it's sgml-to-pdf in this case?) -- horrible breaks, and it also "feels" wrong wrt. some spacing/etc. Generally standard LaTeX will look (much) better than this without tweaking, IMNHO.
On the other hand, they also have an epub style sheet, and it appears (a little oddly) that the layout of the epub is better than the pdf.
FWIW most "heavily optimized" custom LaTeX styles I've come across tend to feel like being slapped in the face with MS Word -- and I think I've yet to encounter any that actually improve on the "standard" styles in any meaningful way (with possible exception of the APA style, which is ugly, but as it has to conform to APA, it's ugly by design. And looks better than most other APA conforming styles I've seen).
Still, having a starting point makes the job much easier -- so this is a great resource.
My supervisor has been writing a book (for many years now) and he has a heavily customized LaTeX style that actually works quite well for his book. He has a lot of special needs for formatting so none of the default styles really worked for him. It's actually a pretty well done dynamics textbook. I've been looking forward to the actual final published text.
You should ask him if he's considered publishing the styles under a Free/open license. Even if parts of it is very specialized, I'd surprised if it couldn't work as an interesting starting point for other projects.
Well, I did not realize Github has had AsciiDoctor integration for two years now (I've been doing most of my scientific work in GitLab during that time). I retract that comment and regret the error. Hopefully they add it to Github pages some time soon.
To be honest, there was never really any conscious decision to pick Markdown over AsciiDoc. It was just serendipity that when I was looking to convert a bunch of my existing Markdown notes to papers, John happened to add (at Martin Fenner's urging) pretty robust support for citations to Pandoc. Being able to use an existing .bst files and Natbib author/year syntax with existing Bibtex database files, while also using CSL to format to everything else was pretty key. The syntax only worked in Markdown at the time, so I went with that. This project just simply grew into an experiment on how to get the least hack-y looking source document for what I needed.
Basically, I had a bunch of existing Markdown stuff typed with both my phone and my computer using NValt (already using the double-backtick math syntax as a hack), and I was looking for a way to reuse all that. If I had to do conversions or had to start from scratch, I would have just started another LaTeX Document, and then this project wouldn't be here.
As an aside aside: I personally think that one shortcoming of AsciiDoc is that Markdown ended up having a more mature application ecosystem outside of the most general purpose text-editing tools. I'm thinking of something like Scrivener/Ulysses which is really great for project writing and has robust markdown support while writing. I've also recently found out that TeXpad "mysteriously" formats Markdown syntax in the editor, and builds an in-editor TOC of it. This is in addition to with rendering support in basically every note-taking tool. Sadly AsciiDoc doesn't seem to have experienced a similar growth spurt in terms of popularity amongst developers, and as a result have a bit more friction to use.
Yeah. Unfortunately asciidoc isn't as popular as markdown and the ecosystem is small. I never paid much attention to asciidoc until I read this blog post - https://medium.com/@chacon/living-the-future-of-technical-wr... and realized that I have experienced many of the same frustrations with markdown. I tried out asciidoc and became a convert :)
I think that's because you are promoting the Gitlab Enterprise edition. It is very easy to miss the third blurb which promotes the free repos. Compare this to bitbucket.org front page (Free private repos are upfront). Github.com frontpage is not as clear but they don't need to
I think what Gitlab.com needs is a template like this
- Free Private Repos - Host it on Gitlab.com
- Need to host it on your servers? Get our open source edition
- Need enterprise support/features? Get our enterprise edition and host it on your servers
Btw do you offer enterprise features on gitlab.com? It was not very clear
Also your pricing page needs to be clear about the different versions. There are at least 3 different Gitlab products (free gitlab.com, gitlab ce, gitlab ee) but the information is easy to miss.
In your homepage, the three blurbs (download and install.., pricing for spport.., signup for gitlab.com..) feel like 3 product features rather than 3 different products.
2. Gitlab.com as a product name is very confusing. When I first checked out gitlab.com my thought was "I'm already on gitlab.com, what's this other gitlab.com" :)
So I have changed it to Gitlab Hosted to make it more clear
Other Potential Improvements
This section - https://cloudup.com/c4vipl-QFBU tries to do everything. Explain features, introduce 3 different products and has a lot of text that could be removed
I would suggest making the entire block about features but in a layered way. i.e first introduce common features and then differentiate the products.
Some text could be removed - Subscriptions blurb can be replaced by "See our enterprise pricing page for subscriptions" or something similar. The way it is laid out now, it seems it is separate from Github Enterprise.
The current feature text blurb is too much text and too little text at the same time :) Too much because it is just
long lines of text. Too little because none of your features are explained elegantly. There is also a "much more" syndrome :)
Just see - https://about.gitlab.com/features/ - Powerful Code review - "Merge requests with line-by-line comments, CI and issue tracker integrations and much more" with a giant image. Text doesn't say much and ends with an ambiguous "much more" and the image is intimidating unless you are familiar with Gitlab.
wkhtmltopdf and phantomjs both worked similarly, currently I'm using phantomjs.
And I'm not splitting pdf but splitting html generation work load, and then create individual pdfs from those html chunks. Then they will be joined together (using pdfunite). I found this much faster then joining html and generating large pdf.
Shouldn't be a problem with Pushpin. There's no major resource overhead in having lots of channels, and since channels exist on demand there's no extra administrative work either. Just assert unique channels at hold time, and publish to those unique channels.
What features of librato did you not find in Datadog? I'm a current librato customer and I from what I see datadog is better in most aspects. Also the datadog integrations are awesome. The collecd integration is just ok