

Takipi – Java debugging reinvented - nivstein
http://www.takipi.com/

======
steve_barham
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.

~~~
nivstein
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.

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

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

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

~~~
nivstein
Nothing is final, but we should remain in beta at least until the end of the
year.

~~~
hga
I'm afraid I have to agree with brazzy; you're asking people to invest a fair
amount of time, and potentially come to depend on a tool that they have no
idea if they will be able to afford once you start charging money.

------
farmdawgnation
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?

~~~
nivstein
This is actually a feature which is currently under consideration.

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

~~~
nivstein
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.

------
rsanders
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.

~~~
nivstein
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.

------
avisk
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?

~~~
nivstein
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.

------
sgt
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?

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

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

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

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

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

------
yareally
Any plans to support Android in the near future?

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

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

~~~
nivstein
I'm sorry, Android development is currently not supported.

------
blibble
I wonder what the overhead is like?

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

------
mokplan
Cool one! Good luck guys!

------
buddym
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.

~~~
Uchikoma
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
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.

