Wonder if people will use this to post bullshified apps to Github to impress potential employers
Show HN: Java Bullshifier
21–30 of 84 posts
Re: Show HN: Java Bullshifier
#22Do you have a De-bullshifier for existing Java codebases?
Re: Show HN: Java Bullshifier
#23Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool ( http://www.overops.com ). Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack. Using Java Bullshifier, we're able to generate random applications with call stack…
How did you design this ? Do you have an interest in porting this to other languages ?
Re: Show HN: Java Bullshifier
#24Features: Generates TONS OF CODE!!
I love it.
Re: Show HN: Java Bullshifier
#25I'm glad to learn that entire businesses exist thanks to the fact that Java has overly verbose exception outputs which are designed to hide the information you are seeking between 200 lines of call stack prints.
As an experienced Java developer I love long Java stacktraces and I miss them in most languages. In 90% cases stacktrace allows to find a bug without any debugging, because it's just very obvious where it is.
Of course if someone doesn't care about exceptions, it's just a bad style. Exception in the production log is like red light and alarm sound, BUG-BUG-BUG. I saw projects, which throw stacktrace after stacktrace, gigabytes of stacktraces (and then archived those teralogs and noone ever watched them). But those projects have much more problems, verbose logs is the least of them.
Yes, with heavy framework usage, especially when those frameworks generate proxy classes and wrappers and god knows what, it's often 2-3 lines of useful information between 90 lines of not-so-useful library or even autogenerated code. But only developer can judge it, environment should preserve anything.
Re: Show HN: Java Bullshifier
#26Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool ( http://www.overops.com ). Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack. Using Java Bullshifier, we're able to generate random applications with call stack…
How did you design this ? Do you have an interest in porting this to other languages ?
Hey, at the moment we're only interested in JVM languages, so Java was the best fit for this project. We'll be adding .NET support for OverOps in the future so that might be something we'll be looking at for Bullshifier as well.
There are a bit more details about the design on our blog: http://blog.takipi.com/java-bullshifier-generate-massive-ran...
And the full source code is available on Github: https://github.com/takipi/java-bullshifier
Basically, the tool is built with Groovy (many projects use it as a scripting language for Java), and there are 4 sections to each randomly generated class:
1. Variable definition, with random types, random names, and values.
2. A section that throws exceptions, or prints to the log, according to the config settings for the rate of events. This also includes a “suicide” function that stops the execution of the program.
3. Calls the next method.
4. Random code that never runs.
There are some advanced config settings described in the Github README.md
Re: Show HN: Java Bullshifier
#27Do you have a De-bullshifier for existing Java codebases?
Working on it as we speak ;)
Re: Show HN: Java Bullshifier
#28Kind of off topic, but this reminds me of my internship this summer. What sucks about Spring is the horrible error messages. If there is something wrong in the XML configuration, or dependency configuration, it doesn't actually tell you that. Instead, it shows a deep stack trace with some strange exception that doesn't relate to the problem at all.
Re: Show HN: Java Bullshifier
#29Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool ( http://www.overops.com ). Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack. Using Java Bullshifier, we're able to generate random applications with call stack…
I've been wanting to build a generic version of this type of tool for quite some time.
When I'm waiting several minutes for our app server to startup, I often ponder what life would be like if we had chosen language X or another stack for our application.
I've primarily worked on JRE-based stacks for some time and once a project reaches a certain size developer happiness begins to decline due to large compilation times, app startup times, etc. Even incremental compiling or hot-reloading of classes seems unreliable at a certain app size (either due to memory or some other reason).
It would be neat if there were a tool to generate large and complex apps with various stacks to get a feeling what the developer experience would be like 1-2 years down the road once the app reaches a critical mass.
Re: Show HN: Java Bullshifier
#30Earlier quoted context omitted.
We've actually thought of using a random pool of Star Wars related names, will have to wait for the next version. Pull requests are welcome though :P
If you have the time (probably not :) ), there was a really cool project that took names from GitHub and generated random names using Markov Chains... maybe use the same for the class names :) .
Cool, sounds similar to the site on the other comment here: http://projects.haykranen.nl/java/