Takipi – Java debugging reinvented

http://www.takipi.com/

by nivstein • 13 years ago

72 38 13 years ago

takipi.com

DaveLond2• 13 years ago

This looks interesting, but the lack of any pricing information makes me nervous - am I missing it?

nivstein12• 13 years ago

Takipi is in open beta, so it is currently free.

DaveLond2• 13 years ago

A not unattractive price point, I find. When are you planning to start charging for it?

erans• 13 years ago

It looks like a really interesting approach for live debugging...

buddym• 13 years ago

What people sometimes fail to realize is that proper testing disciplines can mitigate practically all bugs in production. I haven't seriously used a debugger in 2 years, methinks. So giving developers "X-ray vision" to their servers in production, however innovative, is not a real solution.

mecameron• 13 years ago

Since even you admit testing does not eliminate all bugs, there are still cases when defects make it into production. Novel cases do happen, and some can be quite difficult to understand. I can see how this tool could be useful in those situations.

microtonal• 13 years ago

Even if you were the team of mythical coders that foresees every possible corner case and is never under time pressure, you'll probably rely on millions of lines of code written by other organisations, that do contain bugs.

eroslaw• 13 years ago

Applications fail; it's a real life fact. The most talented teams face bugs, even in applications which undergo extensive testing. Not to mention scenarios which are very hard to anticipate and simulate, mainly ones related to fast scaling.

Uchikoma• 13 years ago

As you are down voted I wonder: I have the same experience here. Very few serious problems (1/year) that come from developer bugs. Others seem to have much more, e.g. when people ask me if the devs here have pager duty (which they haven't).

I also wonder if we test too much (ca. 85% path coverage, 15k unit tests (3x rewritten), automatic selenium tests, explorative manual tests, automatic API tests, developer acceptance tests).

lmm• 13 years ago

It certainly sounds like you're testing too much.

The most efficient use of resources is almost always proportionate allocation between code and other things. So if only a small proportion of your serious problems are code errors then you're either testing too much or not doing enough at other levels of the stack.

The real questions of course are whether your defect rate and the rate at which you introduce new features are where you want them to be.

im_dario• 13 years ago

If you never face bugs in a project then you are missing something.

Obviously, proper testing is needed always.

namdnay• 13 years ago

How well would this handle Spring code (in full autowired, horrible stack trace glory)?

nivstein12• 13 years ago

When you install Takipi, you are asked to enter your top packages (e.g. "com.mycompany;org.foobar.common"). Code outside of the filter will not be shown to you when viewing stack traces. In addition, if, for an example, an exception is thrown by Spring AND caught by Spring, you will not receive an event for that case.

yareally2• 13 years ago

Any plans to support Android in the near future?

nivstein12• 13 years ago

Takipi is mainly designed for production/staging debugging, and thus targets servers and development environments.

yareally2• 13 years ago

Sorry, to clarify, I meant support us developers making apps on the PC for Android (not using your tool directly on Android) :)

farmdawgnation• 13 years ago

This seems pretty legit. I really like the personality you gave the site with its design.

Do you have any plans to support GitHub repositories as a location to pull source from in the event we don't really want to deploy a jar with our source in it?

nivstein12• 13 years ago

This is actually a feature which is currently under consideration.

sgt• 13 years ago

I know it works on the JVM level, but we use Glassfish a lot in production and I'm interested in finding out exactly how practical it is to use Takipi with Glassfish?

nivstein12• 13 years ago

Very practical :) Takipi fully supports Glassfish, as well as all other major web servers and containers.

steve_barham• 13 years ago

I want to test this product, and I'm in a position where I could spend real money on a purchase or subscription to this service in the event that it does what we need.

Unfortunately, as soon as I see that data is sent off-site, I immediately discard this as a product which my organisation can use.

Reasons

1. I am an engineer, working in a highly regulated environment. Regulated environments excel at buying things, or subscribing to things - we have whole teams of people that are delighted to spend money on our behalf. They also tend to have immense amounts of process overhead, whenever you interact with third parties on subjects relating to intellectual property or the confidentiality of client data.

Your assurances on encryption, confidentiality, etc. are irrelevant to me; you could have invented a perfect cryptosystem, but regulations would still prohibit me from exporting data outside of our organisation.

2. I don't want to build reliance on something which is outside of my control. This might be the greatest tool ever built, but if I'm building monitoring systems for production systems, I need to have confidence that they are available, irrespective of your schedule for upgrading / supporting / maintaining your product.

Why should a tool fail, just because the people that built the tool are no longer around?

Short takeaway - my suggestion is that you consider those of us who are not fortunate enough to work in unregulated industries, and produce a self-hosted version of your application (as GitHub do) which can be run on our own infrastructure. There's revenue there which is being ignored. You might feel that centralising your service means that crackers can't steal your tool and use it for free. I would argue that the people that actually care about running this locally are the sort of people that will be paying you, handsomely, for it.

nivstein12• 13 years ago

Hi Steve. These are some valid points you're making. We are currently considering an on-premises solution for precisely this situation you are describing.

shunter• 13 years ago

This is something we'd run as a small pilot as well, and we do work with SaaS, but any SaaS option we use has to be verified through our internal security department.

This makes quick trials basically impossible for SaaS based services.

An internally hosted solution would let me do a pilot and demonstrate benefits internally. If this becomes an option, I'd give this a try.

efsavage• 13 years ago

My gut tells me that SaaS is the wrong play here. Offering a hosted option is nice, but half of my projects will flat-out not use any third-party service as part of the dev environment, it all has to be self-hosted, and many of the other half are reluctant to do so. I think you might find more opportunities by offering it as a self-hosted app/appliance.

avisk• 13 years ago

If I understand correctly does the takipi daemon, upload all the debug info. collected from our server to the takipi server via Internet. Then I use app.takipi.com to access the same?

nivstein12• 13 years ago

Takipi's agent records information which is relevant to the issues which are detected (exceptions, latency problems, custom conditions set by the developer). The data and source code are then encrypted with your secret 256-bit AES key and stored by Takipi. This data is in turn decrypted in your browser and viewed by you at app.takipi.com.

SanderMak2• 13 years ago

Are you guys planning to offer this as a Heroku add-on?

nivstein12• 13 years ago

We are currently in the process of adding a Heroku add-on :)

SanderMak2• 13 years ago

Cooling, looking forward to try it on my Play 2 app running on Heroku!

blibble• 13 years ago

I wonder what the overhead is like?

nivstein12• 13 years ago

Both the RAM and CPU overhead are configurable by you. The default values are max 5% CPU, and max 5% RAM.

mokplan• 13 years ago

Cool one! Good luck guys!

rsanders• 13 years ago

Is anybody using this for Clojure? I'm very interested in how usable it is for that.

Clojure runs on the JVM using JVM bytecodes, but that doesn't mean Takipi will be able to show me anything but mangled gibberish.

nivstein12• 13 years ago

Takipi lets you attach your own source code to the project, so you will see your original source code when viewing exceptions and other events, instead of decompiled Java. Support for prettier stack traces is in the planning.

Takipi – Java debugging reinvented

Related Stories