
Show HN: God mode in production code – a new way to debug in Scala - chookrl
http://www.takipi.com/scala.html
======
mpeg
I'd give my firstborn for a debugger/profiler like this in .NET

~~~
kstenson
Closest I know of is IntelliTrace: [http://msdn.microsoft.com/en-
us/library/vstudio/dd264915.asp...](http://msdn.microsoft.com/en-
us/library/vstudio/dd264915.aspx)

~~~
j_s
Which requires Visual Studio Ultimate, listed at $13300/seat.

[https://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Editio...](https://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Editions_feature_grid)

[http://www.microsoftstore.com/store/msusa/en_US/pdp/productI...](http://www.microsoftstore.com/store/msusa/en_US/pdp/productID.254640300)

~~~
Retric
That may be the list price, but my company pays around 2k/year for a MSDN
ultimate subscription for each developer. Which includes licenses that don't
expire for, Visual Studio Ultimate, every version of Windows, Office, SQL
Server, etc.

~~~
binarycrusader
Renewal prices are much lower; I can't believe the amount Microsoft wants to
charge for the initial purchase though.

I don't know of many small shop software developers that would be willing or
able to pay the $13K list price Microsoft wants for Visual Studio Ultimate.

What's really sad about that is that they bundled improved debugging with a
whole bunch of other things that aren't useful to smaller businesses.

------
saryant
I've been tracking down a NullPointerError in Play's new JSON inception
handling. Eclipse's debugger has gotten me nowhere, I look forward to seeing
how this one works!

------
spuz
This looks simliar to Chronon which is a similar debugging tool that works on
Java (though not other JVM languages) applications.

~~~
nivstein
Unlike Chronon, Takipi is built for monitoring your JVM in production,
imposing minimal and predictable overhead.

~~~
LinaLauneBaer
Chronon is also built for monitoring your JVM in production. At least that is
what they say on their website:

<http://chrononsystems.com/solutions/production>

------
elvinj
I know that at least from my experience debugging our apps in production did
become harder as we scaled out in terms of servers, users and code. I do
wonder if its something that should be handled at the code level (by being
more defensive, taking a more immutable approach) or by having better
debugging tools. Anyone knows if this supports Ruby?

~~~
wereHamster
Or by using a better type system. Or by using the type system that's available
in the language. Because it's all too easy to ignore the types and for example
call `get` on a Scala Option value, or `fromJust` on a Haskell Maybe. Both
will throw an exception at runtime if the Option/Maybe is empty.

~~~
taeric
Of course, the retort there is as much "write simpler programs" as it is "use
the type system." I've seen and been a part of many a tangled knot in a type
system that, while ostensibly safe, was so much more involved to do the simple
things that I think it caused more bugs.

~~~
wereHamster
I'm not saying strongly typed languages are bugfree. But they eliminate whole
classes of bugs. The OP was asking about programming techniques to improve
code quality or tools to help with debugging. Well, a type system is such a
technique/tool that checks for bugs at compile time.

~~~
taeric
Indeed. Apologies for what was too trite of a response. I can't explain why,
but I have been getting heavily lured by the dynamic typing of lisp, lately. I
blame that I am finally watching the SICP lectures online. :)

------
gurdo
There's a very strong founding team around this company. I don't do Java too
much these days, but if I were, I'd definitely use Takipi.

------
shpxnvz
Signup is broken right now, so maybe someone else can answer. From the website
it appears that the debugger is a SaaS app that connects to the agent on your
production box from their servers... is this the case?

~~~
nivstein
The product consists of a slim JVM agent which connects and offloads the heavy
crunching to Takipi's backend.

~~~
shpxnvz
Given the nature of JVM agents, this means that the Tikipi backend, should it
choose, may access all the data in the production application. Correct?

ETA - Thanks, missed that page on the site.

~~~
nivstein
The moment you sign-up for Takipi a secret AES-256 key is generated for you
(and never stored by Takipi in any way or form, and you manually enter it on
your machine when installing the agent). This key is used to encrypt every
piece of application data which leaves the machine. The source code is also
encrypted similarly. The source code and the data are only decrypted in your
browser when viewing the details of the event.

You can read more about security at Takipi here:
<http://www.takipi.com/features.html?nav=security>

~~~
sillysaurus
This makes no sense whatsoever. Their application is doing the encrypting.
That means their application can do whatever it wants, including making it
trivially easy to reverse the encryption.

I get that the intentions are good, but https would provide exactly the same
trust guarantees, and ultimately it bothers me that they would try to mislead
people into a false sense of security like this. If their application is
encrypting data which is sent to their servers, then that means their severs
have complete access to your data. (Whether they choose to make use of this
power is up to them. They certainly have it, though.)

Encrypting the data prevents it from being leaked if their servers are hacked
and their database stolen, which is good. But acting like they have no power
to access your data is absurd.

~~~
baboo
They are probably either lying or incompetent.

If they really had no access, then their server cannot do any "analysis"
beyond storing it, and the app could as well just store it locally, or with
Amazon S3 or whatever storage system the website already uses.

Obviously not everything is encrypted, or otherwise they don't realize that
there is no reason for them to provide a simple storage service, considering
most websites already have some way to store data.

Or maybe they want to hold the data hostage.

~~~
sillysaurus
No, there's no reason to go looking for conspiracies. Nor do I think their
intent was malicious. I think they genuinely believed that this was
beneficial. We should support them if they change their presentation from "we
can't access your data" to "we're not evil, so if you trust that, then use
us." We should let their actions speak for themselves.

------
trailfox
Wow. Wish I could deploy this sort of tooling behind a firewall.

~~~
nivstein
The agent only requires outbound HTTPS over port 443, and fully supports
proxies.

~~~
obilgic
I guess he is talking about private deployment for his company like github
enterprise(github:firewall)

~~~
trailfox
Bingo :)

------
koker
Going to give it a go on our servers. We have a relentless Heisenbug we've
been chasing down lately, which only happens in production.

------
protomyth
Many of the Smalltalks allow hooking to a running image to do live debugging.

~~~
seanmcdirmid
No they don't. They just allow for fix and continue; they give you no insight
into why a problem occurred because they provide no history.

~~~
protomyth
uhm... that's not universally true - I worked with some folks that had the
history when they did it. Not sure if it was vendor provided or home grown,
but it was the call history and call stack.

~~~
seanmcdirmid
Call stack is provided in most debuggers these days. Are you honestly saying
you saw something comparable to the linked article in some Smalltalk system?
If so, I would be very interested in some kind of reference.

~~~
protomyth
It was a VMWare debug image and it had all that information although it was
not as fancy. It did have a good amount of custom code.

------
zaptheimpaler
This looks awesome! Is there anything like this for local code though? The
IntelliJ/Eclipse debuggers don't seem as well designed as this one.

~~~
nivstein
Takipi may be installed locally; the same installation process will work.
However, it does not provide live debugging like in your IDE, but rather a
post-event drill-down (a "time travelling debugger"), as it is designed for
testing/staging/deployment environments.

------
orenbarzilai
What about python?

~~~
spatz
From the FAQ:

    
    
      Which languages do you support?
    
      Takipi works at the JVM level. This means we support all languages running on the Java Virtual Machine. These include - Java, Scala, Groovy, Clojure, etc.. Click here to learn more about viewing Scala code in Takipi.
      We plan to support more software VMs such as CPython and Ruby MRI in the future.

------
eli_gottlieb
You've released? MAZAL TOV! I've been stalking you guys for a while now.

~~~
irisshoor
Thanks, you're welcome to take Takipi for a test drive and let us know what
you think :)

------
drorweiss
Looks great!

------
szeevim
likes the monsters

------
stasix
looks promising.

------
vovafeldman
Looks cool!

------
bizkeep2
US-based?

------
baboo
"to log and send data to Takipi's analysis servers" ???!!!

Is this for real?

I'm surely going to send all my private code, data and who knows what else to
your servers! I have been waiting for this since forever, and I'm glad to have
this opportunity now!

And... it slows everything by 5% constantly?!? To basically take a core dump
for later analysis? (in case it's not obvious, such a thing should have no
overhead whatsoever when fatal exceptions are not thrown)

Lol, is it 1st April again?

~~~
hmottestad
You know, preferably it should actually make your servers run 5% faster :)

Seriously though. Did you really expect a tool that continuously monitors your
app and can produce stunning and relevant information about states leading up
to a crash to have no effect on performance?

------
zer0gravity
Tesla said that he could simulate the behaviour of his contraptions to the
smalles detail in his head and without exception, they ran that way once he
built them for real.

I think that a good programmer should be able to do this with his programms,
and without flattering myself I can say that in 99% of the cases when an error
happened, the answer occured to me almost instantly or after a few moments of
thinking and trying to simulate what happened in my head. I have to confess
that these were instances when the whole code was mine. Working on code you
don't really understand is a major mistake. But this is another issue..

Sure it remains the 1%.. but my point is that developing the thinking
abbilities instead of debugging tools is a far better alternative.

~~~
lmm
Tesla was a genius; he often bemoaned the way Edison would perform a hundred
experiments to discover something which was (to him) obvious if he just
thought about it for a bit. But you know what? Edison succeeded where Tesla
failed, and a good part of that can be attributed to reducing the art of
inventing to an almost mechanical process, leaving his intellect free to
concentrate on more important matters.

It's the same with debugging. I've worked with many programmers who took your
attitude; some of them were more talented than I. But I fixed bugs faster than
them, and got more done, because I let the tools take care of figuring out
what was happening in a program to cause a bug, leaving me more time to think
about other things.

~~~
zer0gravity
I'm not shunning tools. I'm just stating that taking time to really understand
the overall architecture, and allowing yourself some time to think at the
problem before jumping into debugging can take you very far.

Now, depends what you understand by success, but for me success !=
productivity, and I would say it has more to do with the real long term value
you deliver...

