Live data from Hacker News

CSVJSON – Self Rise of an Online Tool

medium.com

31–36 of 36 posts

Re: CSVJSON – Self Rise of an Online Tool

#31

from 15000 quality page views you should expect at least $15 of revenue ($1 CPM) even higher numbers from developers (valuable users). Check out something like https://carbonads.net/ and it might at least pay for your hosting. It's invite only though, so you might have to ask for an invitation.

Personally I hate it when ads get in my way. Like anyone else, I do like money though. So I'm struggling with trying to monetize this. I don't want to annoy developers. This being said, I will consider trying carbonads. Thanks for the tip.

Have you thought about a long term sponsor? It may interest a toolmaker in the ETL space by offering to host a respectful ad yourself with a link and no tracking. You won't get rich but it's probably much better than using an ad network.

Re: CSVJSON – Self Rise of an Online Tool

#33

Earlier quoted context omitted.

Yes, that is a good idea. However I chose to upload it in order to allow sharing the conversion via a unique generated URL.

Why not use location.hash and URL shortener? That way no upload is needed.

What's the maximum length of a URL?

Hint: a lot smaller than almost all the CSV files I've had to deal with.

To the grandparent: you might want to make it more explicit that you're actually retaining the uploaded data and not just using it to generate the result page.

Re: CSVJSON – Self Rise of an Online Tool

#34
post #31

Earlier quoted context omitted.

Personally I hate it when ads get in my way. Like anyone else, I do like money though. So I'm struggling with trying to monetize this. I don't want to annoy developers. This being said, I will consider trying carbonads. Thanks for the tip.

Have you thought about a long term sponsor? It may interest a toolmaker in the ETL space by offering to host a respectful ad yourself with a link and no tracking. You won't get rich but it's probably much better than using an ad network.

I am open to this. Just haven't actively looked for one yet.

Re: CSVJSON – Self Rise of an Online Tool

#35

Earlier quoted context omitted.

Not sure if you parsed my comment incorrectly or you meant to reply to someone else :)

Somehow missed the 'java/scala part'. Either way, why do 2 data format transforms as one lib? It makes more sense to parse JSON into memory in one step then format it as CSV in a separate step. Ie, what about the 'Single Responsibility Principle'?

1) The parsing and converting are done with separate methods. Thus single responsibility.

2) It's a very small library. Less than 200 lines (including comments). There's no reason to put this in 2 jars, classes or packages. Have you looked at the code at all?

3) The method call to parse JSON is in the method that converts the CSV, but it's trivial to move it out and run it explicitly. Simply remove the call to parse and explicitly run it separate.

4) Client wanted the ability to filter out JSON data they didn't want in the CSV. Thus, it's a little more complicated than a call to something like JSON.parse() in Scala/Java.

5) Code does what it needed to do and made the client happy.

If you think you can do it better while keeping the code in Java/Scala, send a pull request to my repo and we'll discuss :)

Re: CSVJSON – Self Rise of an Online Tool

#36

The funny thing is, very capable libraries already exist to handle CSV parsing. I know because I authored jquery-csv, te first RFC complete CSV parser implementation in vanilla JS. The transform is ridiculously simple and data can be fully loaded and processed client-side using the HTML5 File API. As soon as JS gets the :: function bind operator I plan to reimplement it as a pure async function.

Wow, I wish I had found your library when I wrote this. Looks like you published it around the same time I wrote it. I especially like the idea of client-side loading using the HTML5 file API. Things to consider for the future.

Unfortunately. I made the mistake of hosting it on Google Code rather than GitHub. Everything has since been moved and it's gradually gaining traction again.

The HTML5 part was very appealing to me because I wanted to build a client-side tool to load/save/edit database imports/exports.

It unlocks a lot of potential for fully-featured client-side applications that work more like desktop apps.

The bad part about it is, browser vendors, specifically MS, have been dragging their feet when it comes to fully supporting the File APIs.

Post reply on HN