Hacker Newsnew | comments | show | ask | jobs | submit | login

Will you be adding support for recurring transactions for non indian credit cards?

reply


Hi, We plan to in the future. We haven't many people requesting it since most of them have majority of Indian customers which can not have recurring billing

reply


How will you reconcile recurring payments with 3D secure requirements?

reply


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.

reply


Not every bank sends 2FA codes via SMS. For example my debit card with SBI has a static password that I need to put in for every payment

reply


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.

reply


Just like cvv, we are not allowed to store the static passwords.

reply


We have a few tricks up our sleeve.

reply


The github wiki software supports asciidoc and many other formats - https://github.com/gollum/gollum

-----


Any others?

-----


As @jauco said try Asciidoctor - http://asciidoctor.org/

In addition to default asciidoctor style, there are other themes available - http://themes.asciidoctor.org/preview/ (See bottom right for theme switcher).

You can also take a look at Pro Git book styles - http://git-scm.com/book/en/v2 which was written in asciidoc - https://github.com/progit/progit2

-----


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.

-----


Next time I talk to him, I'll see about it. I don't talk to him that often now that I've finished my PhD.

-----


Github does render asciidoc using asciidoctor. What is missing in that that is possible in Markdown?

-----


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 :)

For live preview of asciidoc there are some options - http://asciidoctor.org/docs/editing-asciidoc-with-live-previ.... Among them Atom with live preview works really well.

-----


Just wanted to mention that GitLab supports asciidoc https://github.com/gitlabhq/gitlabhq/pull/7569

-----


Thanks for the heads-up. I'm going to bug our admin again to upgrade.

-----


Great! :)

-----


fyi asciidoctor allows using markdown syntax inside your asciidoc file.

citation: http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/...

-----


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.

-----


Thanks for the great feedback!

I've changed the homepage according to your feedback in https://gitlab.com/gitlab-com/www-gitlab-com/commit/3a09175f...

https://about.gitlab.com/gitlab-com/ mentions that it runs the enterprise edition in the middle box

The pricing page is a hard one, we'll look into that.

Any idea how we can make the three blurbs on the homepage feel more like different products?

-----


This is a HUGE improvement :D

-----


Thanks!

-----


Btw my suggestions were just a template. I'm flattered that you used them as is :)

1. For the blurbs - remove the icons and add headers. Something like this - https://cloudup.com/cGSjRmrWGkU

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.

Compare that to Pull requests section of stash "https://www.atlassian.com/software/stash?utm_source=bitbucke...

Images are not much help but they help in avoiding a wall of text and all the sub features are explained

The actual experience of using Bitbucket is not that great but they are doing a good job of explaining features :). Github enterprise also does something similar.

I think you should also move "Better than Github" to a different section like say "Why use GitLab?" Having it right at the top seems very defensive and a bit distracting.

One last thing - Link to some interesting projects using Gitlab and make it easy to find. You can even link to Gitlab.org somewhere. Looking around a repo gives a better feel for the product.

-----


Thanks for the great comments! We fixed the blurbs with https://gitlab.com/gitlab-com/www-gitlab-com/commit/8e24fc11... and the homepage is greatly improved because of it.

We'll try to improve the rest too and track it in issue https://gitlab.com/gitlab-com/www-gitlab-com/issues/271

Thank you very much for your kind comments.

-----


How is unicorn forking relevant in this context? Since they had memory usage problems with workers I assumed they were using resque(which uses forking)/delayed job

-----


Can you explain why using sidekiq involve a rewrite? AFAIK, using sidekiq you just have to make sure that your jobs are threadsafe not the whole app which is not very hard.

2 years ago, ruby was not COW friendly. So yeah, there was not much benefit to forking if you were using 1.9.3. Not sure how well does ruby 2.x fares in that respect

-----


You have to make all code threadsafe that execute from Job or you have to decouple Job code and App code.(which probably be required anyway because I'm not sure sidekiq supports old rubies)

So, in any case you have to rewrite as much as code that I rewrote in Go and decoupled from main App. (its not lot of code, I mentioned in talk)

-----


Did you try sidekiq?

Btw how are you generating the PDF from HTML and are able split a single HTML into multiple PDFs?

-----


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.

-----


Ok. Are you using phantomjs 1 or 2 ? Any reason to choose phantomjs or wkhtmltopdf? We are using wkhtmltopdf because it creates Table of Contents for PDFs and also clickable links

-----


PhantomJS 1. But nothing is tide to phantomjs, wkhtmltopdf should work as well.

(I'm planning to test with PhantomJS 2)

-----


This is fantastic! Thank you :)

For my use case, each client needs a separate channel which is short lived (they are generating a report which is unique and takes some time). Would pushpin have any problems with such a setup?

-----


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

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: