Hacker News new | past | comments | ask | show | jobs | submit login

I think you need to make the experience more concrete.

On the visceral side: put up some example videos of use. If you can't do it to the level of polish you like, get someone else to do it for you as an unofficial one. IntelliJ is already slow, and I'm worried about event-recording debuggers being only useful for small programs -- larger ones eat up too much RAM and cpu overhead to be tractable.

On the power side: show some sophisticated use cases using real libraries and real problems to fix. What stuff can I find out directly that I can't easily do in IntelliJ?

Can I directly query the DB? Can I use those queries' results in regression tests?

When I read the page, I thought "Oh, like the valgrind family of tools for Java, nice." So perhaps some pre-baked validations using the tech you've built could be useful.




Yep, I think video would be a perfect fit.

About performance impact and program size: BugJail can be used also with hardcore programs, like databases and compilers, where event based record-and-replay debuggers typically struggle. There's still significant performance hit, around "twice as slow", but it won't be orders of magnitude slower.

Also, BugJail is tested with large applications. For example one test is startup sequence of Eclipse, on 5 year old box with 32GB. The result is ~700 million rows in database, in ~30 seconds. It does consume all memory, and your workstation will scream for mercy, but it gets there :)

Direct DB query is not available in current beta, but it is partially implemented in dev version: it shows the results, but there is no navigation from the query results to CallTree, Source code view etc. So: coming, but not yet.

I hope I answered your questions at least partially? It's 7AM in the morning, after one of the hottest days in Australian history, and a surprise appearance in HN front page, so I might not be quite the sharpest tool at the moment :)


From what I understand, some time sequence databases use some sophisticated compression techniques. Are you there already or is that on the roadmap?

I think it would be kinda cool in a way to go back to dual-machine debugging but I’m not sure everyone else would agree with me.


There's fair bit of compression already, but actually I haven't done that much industrial spying into time-series databases, good idea, thanks.

Also, I've tested dual machine debugging with BugJail, as part of spike towards CI/QA/SIT/UAT/Pre-Prod use. It works okey-ish but the (crappy 1GB) network became bottleneck and it was slower than single box.


If 1GB wired doesn't work well, WiFi will be worthless. Compression is a really good idea


My "Fair bit of compression" was massively simplified: there isn't one true canonical "compression", but dozen different places and ways where and how to compress.

BugJail does compression around storage layer, but nothing before the network hop from capturing agent to processing server.

And fully agreed of course; when BugJail graduates to CI/QA/SIT/UAT/PreProd use, it will need compression before the network hop. But that is some time away. Currently the agent and server run in same box, and compression between them has negative net effect (compression uses more CPU than what shifting around less data saves).


statsd might be a good example there. Local coalescing before reporting upstream.

Basically they didn’t make the client smart, they made a proxy and spam loopback.


> If you can't do it to the level of polish you like, get someone else to do it for you as an unofficial one.

Yes, have one (or several) customer(s) write a blog (that you can help proof-read, add links to documentation, your example database, your reference guide...) on one or two features. "here's how I did it before with eclipse/intellij, how it was long and painful and manual and involved and xxxx. Now with bugjail I can do this with xxx and xxx". A blog I can read and you can polish bit by bit, asynchronously. Video can be hard to follow, copy-paste, with good and clear simple English, or you could caption but then again, lots of energy to spend!".

Maybe offer some incentive to this (those) customers of some kind (5 year free support, a number of enhancement tickets...).

The best way to demonstrate (I feel) is sometimes a happy customer with complex but satisfied needs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: