I'm thinking web frameworks (like WordPress) and CRMs (like SalesForce). Easy to comprehend visualization of business data is a lot more valuable than visualization of internal program data structures. If you can populate structures from 3rd party sources then you could have a valuable product.
I can see how a business would be interested in visualization of contact growth or website structure.
I agree that must be true in an absolute sense, but part of the reason I'm making this is that I find visualization of internal program data to be valuable. I have other things I want to use this to help me build. But it's definitely a gamble whether I'll be able to convince many other developers that it's valuable :)
Thanks for the suggestion though. I do think it's interesting, but if I understand correctly, the volumes of data involved would require different sorts of visualization approaches, whereas I've spent lots of time specializing mine for high-level program state. For instance, the visualizations are specialized for common data structure types, and can be stepped backwards and forwards through, like in a stepping debugger. So if nothing else, I'd be very reluctant to pivot without really giving this a shot.
Let me know if I've missed anything about the kind of data you're thinking of—maybe it's more suitable than I think.
There are plenty of ORM libraries. I am familiar with python, so sqlalchemy etc for me, but most languages have ORM libraries now.
It could be as simple as some glue to pipe data from the 3rd party into native objects (via ORM) and then use your visualization efforts directly.
Your visualization looks smooth. It may require limiting visualization to certain fields, rather than every attribute as you would want debugging.
In my opinion, though, you've done the hard part.
And volume wise it seems you already have the ability to handle relatively large complex tree structures (I think your examples showed 500+ nodes). If you can hide/show sections dynamically then that should be sufficient for some very large structures.
I'm working on something similar, with similar motivation. I often need application-specific diagnostics and I haven't had a framework for building them. So I decided to make one.
I'm approaching LuaJIT diagnostics in a really similar way to you. I instrument the VM to snapshot key data structures (e.g. JIT code) and log them to a file. Then I make a UI that visualizes them as a graph. My snapshots are raw C data structures straight out of memory with only a subset of references crawled. The UI decodes the objects the same way as GDB i.e. using DWARF debug information.
LuaJIT example: https://github.com/raptorjit/raptorjit/pull/63#issuecomment-...
My main project for the tooling (early days): https://github.com/studio/studio
Anyway. Maybe our paths will cross further down the line. Looks to me like your work is more targeted, more polished, and that you are likely to find an excellent niche e.g. Redis as another commenter suggested. I am more interested in breadth i.e. object graphs are just one of many problems I am interested in and so I'm always looking for 80/20 solutions so that I can move on to the next thing.
End braindump. Once again - great work, and great presentation! Open an issue on the Studio repo if you want to share your work there some time btw :)
You are correct that for the moment I am attempting to be more targeted and find a good niche. My first priority is to generate some passive income so I can relax a little and work on things at a reasonable pace. From there, I have some more grand ideas for this project, though I will probably remain focused on abstractions of program state. I'm curious to see what other useful things you find to visualize—I liked the execution time/trace trees. I could definitely use that.
Thanks for the comment—feel free to shoot me an e-mail if you ever feel inclined: westoncb[at Google's email service].
Get something working and throw it out there. Then find out what actual paying customers want, then go from there.
Although that isn't cast iron advice as early take up customers tend to be less risk adverse (they are paying for an unknown software) and perhaps more technical than others, so you run the risk of making a very technical program based on their feedback, which then when you get popular alienates users because unless they were with you from the beginning, they have no idea what half the features do, because obviously you didn't document things well enough.
Or so has been my experience, but perhaps I am an odd case, still creating desktop applications and don't give trial versions. You pay the money you can have me contactable all day and get your features added. If you haven't paid any money, then I don't care. I'll take word of mouth sales every day of the week
Think you're on to something that this talk points out very well.
I highly recommend coming up with a small enough use case to ship sooner so that you can build something that users want and pay for. Also, if you can document the client/server API, other devs will write monitored data structures for you.
That's a cool idea. I've been working on something similar, but that takes kind of a different angle which I like. What I have at the moment is a way of specifying filters for which properties should be displayed or not.
Yes, small enough use case... unfortunately the smallest one I can think of is MASSIVE :P
I will document the API and probably open source the client before long. Clients pretty much just send serialized Operation objects as JSON. Operations are like add/remove to/from whatever location, using a shared addressing systems for all data structures.
Reminded me of a conversation with my friend over a year ago about using VR for data visualization. His son had sold a VR startup, another of his friend was working on DNA/RNA visualization with VR, and he was exploring dashboard data visualization with VR.
I'm glad people are pointing this out to me because I hadn't really given it any thought. My first instinct is that the data being visualized here is somewhat unique in how its structured—but if nothing else, once I get graph/state machine visuals in, I could see that probably being useful elsewhere.
With a lot of the dashboard kind of stuff though (which I admittedly haven't had so much exposure to), it seems like line graphs etc. are more appropriate from what I can tell.
As for monetizing, I'd like to sell it as a cheap utility for programmers or CS teachers (those would be two different products). If I can make enough to visit the dentist regularly and maybe just supplement with part-time grocery store work, I'll consider it a success. Of course I think it has the potential for more than that if properly executed on...
Your visualizations empower the livestreaming coder.
Also all of the YouTube channels that put up tens of programming videos every month. I'd love to watch coding tutorials and courses that use that kind of visualization.
I haven't seen too much livestreaming, but I'll check out Jonathan Blow's now!
> Is your display client using some sort of "open" protocol that you could hook other things?
Pretty much, except it's technically the server which does the rendering etc., and the clients send over information about data structures (as JSON 'operations' which say thing like add/remove to/from some position in a data structure). It probably would not be very hard to write a client which observes React programs and sends that info over.
I started working on it in 2014 and it's been on my mind ever since. I applied to YC with it a long time ago (was not accepted, and I can see so much wrong with the application I sent now...) I was laid off in November so I jumped back into the project and have been working on it since.
The main thing I'm planning on changing up now is: it's too general purpose—closer to a platform than a specific product. So next I'll focus on building one particular product on top of it: something kind of like Chrome's object browser (which you get when using console.log)—but showing dynamic structural changes in time (steppable/reversible), and being multi-language.
The other main issue is that, even though I'm trying to get it into user's hands as soon as possible, it has been a giant task for me to get even an alpha of this thing together on my own,—though I am damn close now. And my sister has been helping a bit recently.
Edit: direct link to video: https://youtu.be/KwZmAgAuIkY (looks much better full size!)