The UI somehow reminds me the Tableau https://www.tableau.com/new-features/10.0 but much more keyboard friendly by leveraging *inx command line. BTW, Tableau is a $6B industry.
I too agree with putting up a screencast or a free lite version.
Looks v interesting and tempting to buy, but lack of documentation, videos and trial put's me off. You don't even say how much it is?? Just a broken app store link, that doesn't work on iPad.
If you add Postgres data source I would probably buy sight unseen. If you add a simple form builder that can call Postgres functions (Not direct to table) for basic CRUD I would most definitly buy and happy to pay $200+.
Thanks! Is there a particular database you're interested in? I have about 5 on my to-do list, for the near future, but the order of implementation is still flexible.
Good news: that's at the top of my list already! I'm also planning to have some way to easily save/reuse data sources (like connection strings) to accompany this, because you're not going to want to type in a connection string more than once.
Looks really interesting and really pleased to see it's a native app and not javascript in a web frame, thanks for taking the time to start this. The price is quite high though - do you have a demo?
I'm mostly interested in rich data retrieval/query building UI, and Plot.ly seems focused more on the second part of the problem, where your datasets are already prepared.
It's a native Mac app, but the backend and frontend are pretty separate, so it's not out of the question. That said, it's not a high priority at this point, and it seems like it would be a ton of work, especially for just one person (me).
A secondary concern is that, because it takes advantage of the Mac's built-in frameworks, there are some things which look rather difficult to me on other platforms. I can probably find a replacement for MapKit, and maybe QuickLook. The features of Spotlight I'm using seem to have no analog on any other platform. GCD is open-source and there seem to be some forks that have ports but I'm not sure what the status is.
Overall, I'd rather provide a great experience on one platform than a mediocre experience on several. To do cross-platform well, even if you're using a cross-platform UI framework, you really need at least one person dedicated to each platform. I would not be able to do justice to a Windows version at all.
Now, if anybody out there is interested in investing so I can hire a team of people to help me do this, I'm all ears. :-)
I wrote it myself. One of my key features has always been that everything is streaming (unless it's algorithmically impossible, like Sort), and I couldn't find any Mac charting widget that supported streaming input.
That's why its feature set is rather minimalist. I'm not opposed to using a third-party charting library, if there's a good one that supports what I need, but at the time I wrote that, there wasn't.
Check out Handsontable or Ag-grid. This is a market you can address and sell immediately too. Lots of us are keen to build internal tools that do spreadsheet in the front end and server on the back end. If you can build a turnkey aoliti2for the web (with an API), that's easily monetizable.
I think $30 is fair, considering the work I put into it. What price would you be willing to pay for this?
For a demo version, in what way would you expect it to be limited? I've considered making a demo version (or making it free with IAPs), but databases would be the first thing to go. Would that still be sufficient for you to evaluate it?
How do these work? Does it drop a secret file on your computer somewhere that says "installed at timestamp X"? Does each download include "downloaded at timestamp X" as part of the app (so the user can just download it again)? Does it send some piece of data back to the server saying "person X started the trial at time Y"?
I'm leaning towards a partially-featured free version that works for all time, but I'm willing to be convinced otherwise.
- some kind of hashing/crypto. Something like a hash of <email>:<version1>:<yoursecrethash> and check against the customers keyfile. Advantage: the file doesn't need to be secret, customer will have to sign up and get a keyfile by mail. (Of course those who want to hack will just find and nop out the relevant assembly instructions)
- check online for valid license (can be also be patched out easily unless you really put some effort into it)
- of course there is hardware keys which again can be easily circumvented unless you put some effort into the implementation
I'm leaning towards a partially-featured free version that works for all time, but I'm willing to be convinced otherwise.
Disadvantages on time limited:
People will find a way to reset all settings, reinstall and use it for another 14 days.
Disadvantages on feature limited:
Those who only need the limited feature set has it forever - those who need the extended features won't get a chance to test them.
I'm leaning towards full featured, time limited. Those who want to hack it will havk it anyway.
The safest way is to create a version with features literally stripped out, not just hidden behind a boolean. (Rolling your own DRM is akin to rolling your own cryptography, it probably won't be very effective to malicious actors)
This won't stop someone buying your app, cracking and releasing it, but it means they will have to spend at least $30 to do so.
Checking a secret file is probably the easiest option. Of course anything is hackable, but the again it's probably easier for someone to just hack the full version of your app, depending on how you protect that.
If you're serious about licensing your app outside of the app store (the app store doesn't allow custom licensing systems), I'd love to chat about what your needs are. I'm the founder of an app licensing API called Keygen[0] that supports feature-licenses. :)
It has data source operations for listing Contacts, Calendars, and Calendar Events.
One of the main drivers for this project was that a lot of my data was trapped in these custom data stores, and I wanted to be able to access everything from the same place. (Why can't I grep my calendar events?)
It only reads these when you explicitly use these operations, and it never writes to them.
I saw the welcome screen offering to let me read the manual. I like manuals, but I figured I'd poke around first.
I clicked on each of the samples, but none of them really appealed to me. The closest was the "Hot Cities" one.
I then tried to load a file to look at.
I hit enter and got a new operation, typed file and saw "Load File", but couldn't figure out how to enter the filename. :(
I did lots of enter and tab and such, but finally gave up and opened the manual.
After reading through it, I discovered that I was supposed to use - to select an argument and = to enter a value for it. Still not quite used to that, but I'll say you really need some sort of intro tooltip to help people figure that out.
So, I entered the filename, and it gave me the little orange minus flag. Clicked it and saw it didn't have authorization. Clicked the Help question icon and read that I had to predefine a list of folders it could access. I haven't purchased too many Mac Store apps, maybe this is some limitation of that, but I've never had an app before that couldn't access a file without my first telling it where it was allowed to look. Is that really necessary?
So I added a data directory to the allowed list and then I saw the contents of my file. Yay!
This file is a dump of a Kafka topic. It has a line per record, each record has a JSON key, a tab character, and then a JSON value.
So, I went to add the second operation to my pipeline. The first few tries, I kept overriding my Load File operation, but then I got the hang of using the down arrow to get a new one. I have an outstanding question on how to insert one between two steps, but I haven't needed to do it yet so I haven't experimented.
I first tried to use Split String to break up the key and value fields, but found I couldn't enter a tab character either via \t or by pasting it. I saw a note that said not to use Split String for CSV or TSV, so I next tried the TSV operation.
TSV was able to break it up into two fields, but I don't have any control over specifying the keys for the fields, it just automatically eats the first row of data and uses it as the key name. :(
So I poked around looking for a way to fix that, saw the option to change key names, but that wouldn't get my first row of data back, so I opened the file in Vim and gave it a header.
Came back to Strukt and reloaded. I then tried to add a Parse JSON operator. First tried to point it at the "key" field, got nothing back, so I tried the "value" field. Still nothing. Hitting the Play button takes 1.85s but returns zero rows. No indication of what went wrong.
That is where I stopped cause I have work to do.
Sorry that this is kinda a negative review. Don't let it get you down, there is a lot of promise in the concept and interface. Feel free to poke me for further info if you need it.
I'm coming from the world of Pentaho Data Integration and command line utilities, and I love playing with data apps.
> I first tried to use Split String to break up the key and value fields, but found I couldn't enter a tab character either via \t or by pasting it. I saw a note that said not to use Split String for CSV or TSV, so I next tried the TSV operation.
That's strange. You should be able to paste a tab character in a flag value. You can also type it directly, using the Mac way to enter tab characters in text fields: option-tab.
Thanks! First-time user feedback is incredibly valuable, and hard to come by.
> After reading through it, I discovered that I was supposed to use - to select an argument and = to enter a value for it.
You can also double-click the right part of an operation. I agree, though, on-boarding is one of my weaknesses right now.
> I haven't purchased too many Mac Store apps, maybe this is some limitation of that, but I've never had an app before that couldn't access a file without my first telling it where it was allowed to look. Is that really necessary?
I'm having a little trouble unpacking the triple-negative here, but basically, yes. The Mac App Store requires sandboxing, and the sandbox prevents the app from accessing a file until the user shows some intent to access it -- like by drag-n-drop, or a system Open File panel.
There are some exceptions, like public files in /System, or if an app has the "com.apple.security.assets.music.read-only" entitlement then it can read your ~/Music folder. In the general case, though, an app can only access files once it's been given explicit permission.
(Oh, and in case you didn't try this: you can drag-n-drop a file onto the Strukt icon in the dock, or into an existing pipeline window, and it'll add the appropriate "Load File" operation, and also automatically add that to the list of authorized files. I do try to save you a step, where I can.)
> I have an outstanding question on how to insert one between two steps, but I haven't needed to do it yet so I haven't experimented.
You can use control-O (like Emacs -- or Mac text fields) for this. It's also in the Edit menu, though one thing I've learned recently is that nobody looks in the Edit menu, so I'm working on some alternative methods that are more discoverable.
> TSV was able to break it up into two fields, but I don't have any control over specifying the keys for the fields, it just automatically eats the first row of data and uses it as the key name. :(
Good point. CSV/TSV don't actually mandate that the first line contains headers (even though it often is), so those operations should let you bypass that functionality.
One hacky workaround, for now (which I admit there's no way you would have guessed): you can use "Literal Value" with string="foo<tab>bar" where="before" to prepend a line to your data, before the Parse TSV operation.
> I then tried to add a Parse JSON operator. First tried to point it at the "key" field, got nothing back, so I tried the "value" field. Still nothing.
Hmm, it looks like my JSON parser is expecting an object at the top-level, and doesn't seem to work with an array, or anything else. It should really be more lenient.
I do want to have native JSON support (not just strings, or atoms) someday. If you have a sample file you can share with the structure you've got, I can make sure it works well. I'm not familiar with Kafka but "JSON-in-TSV" sounds like exactly the sort of thing I should support.
> Sorry that this is kinda a negative review. Don't let it get you down, there is a lot of promise in the concept and interface.
I don't take it as negative at all. You took a chance on a new app, and even when it failed for you, you took the time to write down exactly what I need to do to make it better! I wish everybody did that. This is my favorite comment so far, because it's loaded with actionable feedback.
>Your connection is not private
>
>Attackers might be trying to steal your information from www.freerobotcollective.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
I'm not having this issue. Is it possible you're running a proxy on your laptop (like charlesproxy) and forgot to disable it or add SSL proxying for www.freerobotcollective.com
It has a "Load URL" operation, which can be used to GET resources. (You want arbitrary verbs, I assume?)
It has a "Parse JSON" operation, though some people here have run into some limitations of that. Next week I will have better JSON support!
It doesn't really support XML parsing yet. It can get data from HTML tables and lists. There's a lot of possible ways to convert a tree (XML) into a table, and many are not useful, so I'm going to have to give this some thought. If you have an example of an XML document or API response that you'll want to parse, that would be super helpful.
Handling and manipulating data in an obfuscated web environment (Electron) is not fun. Native will undoubtedly offer better memory handling and performance.
Why do you consider electron to be an "obfuscated" web environment? I would argue that electron provides you with much better control than you'd get in a traditional web environment/browser.
> Native will undoubtedly offer better memory handling and performance.
True, but that seems to be a tradeoff that people are ready to make these days. For a lot of organizations, it is just too convenient to build cross-platform desktop apps using the web development skillset.
Although I must admit that, as a React Native contributor, I hoped for something like RN to take off on desktops in addition to mobile. It would provide far more control over the performance than electron because you'd be able to write native code alongside your JS, avoid overhead of the DOM and CSS, and even tune the JS VM for your application.
Elsewhere the (singlehanded) author explains his reliance upon Mac frameworks and his lack of resources necessary to develop on other platforms. I believe every tradesman has a right to choose his preferred tools and platforms to support.
While I agree that, "every tradesman has a right to choose his preferred tools and platforms to support," that attitude is hard kept if you're selling closed source software for a platform with only five percent market share.
Quite amusingly, about four or five days ago a similar program (Tad, ”a tabular data viewer”) was presented on HackerNews, and if I remember correctly the top-ranking comment was a complaint about it being an Electron app. Ironically it seems nigh impossible to satisfy both camps.
There are a myriad of options available to gain platform agnosticism and nowhere did I, or even the original commentator, state that Electron was the only viable path.
Ironically, you should read the comments from your own example as they descend into debate regarding these very options:
