21–30 of 39 posts
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?
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.
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 accepta…
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.
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.
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?
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…
Earlier quoted context omitted.
Takipi is in open beta, so it is currently free.
A not unattractive price point, I find. When are you planning to start charging for it?
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.
Obviously, proper testing is needed always.