HN user
I feel ya. I wrote a script to reformat my bank's CSV export to make it easier to work with for OnTrack [0]. I imagine it wouldn't take too much work to write a script that reformats and combines multiple sources.
0: https://github.com/inoda/ontrack/blob/master/lib/csv_helper....
The problem with this is that you don't want your free dyno to stay awake all the time because free dyno hours are capped. This tool let's you set a window to pause the requests.
In their contribution guidelines: "To add a new entry, edit the README.md file through Github's web interface or a text editor, and send a Pull Request."
Awesome list!
I've been getting more interested in self-hosted software recently and have created a few projects in the space.
Budgeting/expense tracking: https://github.com/inoda/ontrack
Journaling: https://github.com/inoda/journal
Keeping free Heroku dynos awake: https://github.com/inoda/heroku-pinger (which I use for my personal instances of the above applications)
This isn't for 24/7 uptime. And it also doesn't depend on Heroku scheduler. That's just one option for getting this up and running quickly.
Yep! This works around that by having a window where the requests are paused.
Why is this the case? This stays within Heroku's limits for free tiers. They cap free dyno hours anyways so if you need your app awake all the time you have no choice but to pay.
The problem with this is that you don't want your free dyno to stay awake all the time because free dyno hours are capped. This tool let's you set a window to pause the requests.
That's good feedback - I've added installation instructions to the readme!
Any pains listed that you identify with or are these non-issues for you?
Yeah that's a good point. I thought the data encryption made it "safe enough". I also wanted to strike a balance between nice security features and ease of use.
I am definitely no expert at security. What hosting would you recommend?
If anybody is curious what this was written with, here is the repo: https://github.com/inoda/private_journal
This is too fitting for this thread...a rap song about the woes of actually finishing a side project:
This had me rolling
A hilarious rap about how neglected CSS can be: https://www.youtube.com/watch?v=0yXJ4t6Ax1U
Users (our app users) would have created their own templates and used them for sending envelopes.
I'd like to add a little more to this - our main frustration isn't necessarily because of these technical difficulties. Communicating implementation details and 3rd party integrations can be challenging, especially if one side of the convo is not super technical. That is totally understandable, and probably inevitable.
The main reason this felt so...sucky for lack of a better term, is that we had multiple discussions about our use case and were told that this would be supported (again, this turns out not to be true? not a huge deal, it happens), and were asked to pay $20,000 upfront of which we got $0 back once realizing the original promises were not true.
As OP pointed out, 20k for a huge company like DS might not seem like much, but for a small start up like us it is. Just from a consumer perspective, this seems like a crappy way to conduct business.
1. We want the application user to sign a contract.
2. We request an embedded signing url from DS (we provide authentication creds, as well as redirect url as params - what we get back is a "special" url on DS. E.g. it is docusign.com/blahblahblah)
3. We redirect the user to the special DS url.
4. If the user signs, or refuses to sign or w/e, the user will get redirected back to our application via the redirect url we provided in our request on step #2. If the user instead decides to refresh the page, they for some reason are broken out of the signing page, and can now do whatever they want in the account as they are logged into DS's site for some reason.
HelloSign's embedded signing happens in a iframe, through their JS client. The user is never directed to HelloSign's site unless you choose to to an un-embedded workflow.
View 1 is on the DS domain. We have no control once the user is in there aside from giving the redirect URL.
View 1 comes from us (see my reply to your comment below). As for your 2nd question - that is the crux of the problem we had.
Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.
No, their embedded view is hosted on their site. The functionality is directing to them to a page on their site, with a redirect URL to our app after they are "done" there. This allows DS to be embedded into app-side workflows.
You have definitely struck my curiosity - which version of this integration I outlined did you guys implement?
1. Embedded views + user creation w/o requiring email confirmation
2. Embedded views with 1 API User
I don't want to assume anything here, but I think you either didn't build exactly what we were trying to, you are on the legacy version of their API, or you have that embedded view refresh bug I outlined live in prod.
I was on this project and can speak a bit more on the technical details here.
A couple of high level goals:
1. We wanted to use their embedded flows, to keep the experience within our application as much as possible.
2. We wanted to avoid having to create a DS user for every user in our application that turned on this feature. We were looking for using 1 “API user” to make requests, handling data scoping ourselves within the application.
The actual issue in more detail:
1. Go to an embedded page, authenticated as the “API user” (which looks like you’re sandboxed within DS to the embedded page)
2. Refresh the page
3. You now can click around the entire account - viewing any data that belongs to the API user (in our case, all of the data).
At this point (as the OP called out), we realized we had no choice but to create DS users. But we still wanted to hide this process from our users, keeping DS as embedded as possible. The issue was their “regular” user creation flow involves a email going out to the user to confirm - obviously this is unideal if our goal was to wrap DS and hide it’s existence as much as possible from users.
DocuSign offered a workaround for this, which involved basically getting shifted to a legacy version of the API, with no hard promise of it not being sunsetted. By then, we had had such a poor experience with non-answers from their team that we called it quits.
I hope this clarifies some of the technical problems we were trying to solve for.
Edit - I'm sure DocuSign can solve for some use cases. Obviously, they have a large user base and I'm sure most of them are at least satisfied, if not happy. But if you're trying to wrap an e-sign provider within your application, I would recommend HelloSign 1000x. HelloSign's API is a first class citizen whereas DocuSign's felt more like an afterthought.
Thank you so much!
Thank you for the feedback! I keep getting comments that some visuals would go a long way. I also think it'd be fun to do, so it's pretty tempting. I do agree that the focus should be on song quality though.
"Can’t tell when my app even breaks, Loading gif all in your face"
That cuts deep.