

Squash - vital101
http://squash.io/

======
lbarrow
This product reinforces a mindset that I find harmful.

Where I work, teams of developers are responsible for products -- we all own
the quality and robustness of our product's code. If the application is
broken, why would you only email the person or pair who wrote the particular
line of code that excepted? Am I supposed to pretend broken code is not my
problem unless I personally wrote it?

Development is a collaborative activity. If a product is broken, the whole
team needs to know, so the whole team can fix it.

~~~
Zelphyr
I don't disagree. However, it seems like the idea with Squash is to give the
person who is most familiar with that code the chance to fix it quickly.

Fixing a bug early in development is my problem. Fixing a bug in production is
all of our problem. I think Squash encourages the former in order to mitigate
the latter.

~~~
jordoh
There are a couple assumptions here that seem like they could be pretty
faulty:

1\. Whoever touched a line of code last is most familiar with that line of
code. I just moved a method to a different module, so following this
assumption I am now the person most familiar with every line contained in that
method.

2\. The line of code triggering the exception is actually at fault. I just
changed a value in a configuration file and it triggered an exception off in
some code that creates a network connection - code I've never touched.

How faulty these assumptions are probably varies pretty wildly from
organization to organization.

~~~
ithcy2
In your first example: you are not necessarily "the person most familiar", and
I don't think that's the assumption. You are, however, likely (to some degree)
to know who should be contacted to resolve the real problem.

In your second: If you changed a value in a configuration file and it
triggered an exception somewhere, many people would say you _are_ at fault for
not testing your change.

Most places I've worked there's a simple rule: whoever last touched the code
that broke is responsible for getting it fixed. That isn't meant to be taken
literally in that I must actually make the code change myself. It means that
it can be assumed that if I'm touching some code, I'd better be familiar with
the code I'm touching. If that means I delegate the fix to the original
author, then great: It's still getting fixed. If I can delegate to someone
who's better suited to make the code change, that's OK too. If not, I make the
fix. In any case, If I'm changing a line of code, you can assume that I'll
know _what action to take_ if that change breaks something. If I don't, I
shouldn't be allowed to make the change in the first place.

~~~
DougBTX
_In your second: If you changed a value in a configuration file and it
triggered an exception somewhere, many people would say you are at fault for
not testing your change._

Exactly. However, the exception will likely be thrown from somewhere in the
network stack, not from a config file, so whoever last modified the error
checking code in the network stack will get an email instead.

------
jmileham
This has a big (but easy to fix) security flaw. Don't deploy this publicly
without changing the secret token or else you are effectively publishing your
app code for analysis by attackers.

[https://github.com/SquareSquash/web/blob/master/config/initi...](https://github.com/SquareSquash/web/blob/master/config/initializers/secret_token.rb#L21)

More broadly, if you're writing an open source rails app _please_ don't commit
a hard-coded secret_token into the repo or session fixation attacks are
trivial.

~~~
TylerE
Why has the Rails team not fixed this?

Seems like a sane default would be to have a special token (used in the auto-
gened config) that generates a new random key, and then writes it to a 2nd
config file (which is in the default gitignore)

~~~
Xylakant
Because it's not a problem for private applications. You actually do want the
key in your VCS in most cases since it should be stable across deploys. Rails
will log out every user and throw an error for each active session when the
key changes because it suspects that the session has been tampered with.

The handling for OS applications is a little more difficult and I must admit
that I know a couple of mediocre and no good solution to it.

~~~
Rygu
I have to disagree. An application connected to a network is never "private"
unless you configured a strict firewall and are sure that other running
services don't contain exploits. Besides, if an employee leaves the company,
this "private" app is now known to an outsider.

Also, just because something needs to be "stable across deploys" doesn't mean
it needs to be in VCS. Are your application's third party passwords and API
keys all stored in its version history? We picked a solution where the
deployment tool configures the sensitive pieces of the application.

~~~
Xylakant
Private was meant as "the source is kept private". In this case it's less of a
problem since only people with access to the source get to see the source. In
any mid-size team those probably have access to the servers anyways, so they
have access to the secret in any case, so they're implicitly trusted. You're
certainly right that there are other ways to store the secret and if you read
my posts in this thread you'll see that I'm aware of that, however, keeping
the secret in the VCS is a simple solution that works without any further
magic. If your requirements dictate that you can't do that, chance it, but
that doesn't mean it's not a working solution for many other people. And
that's the reason things are as they currently are and I don't expect them to
change soon.

To answer your second question: depending on the case, I store 3rd party
passwords and API-keys in the repo. If an employee leaves the company I'll
have to change those anyways since he probably had access if he had access to
the project at all.

------
udp
I can't watch the video right now, and as a result I have no idea what this
actually _is_ (despite being able to read about all the features).

Fewer e-mails sounds good, but it doesn't mean much to me if I don't know what
the product is.

~~~
JonnieCache
It's self evidently an exception logger with built in static analysis. If you
can't tell that from the lengthy description then the product probably isn't
aimed at you.

It's definitely one of those simple "why didn't I think of that?!?" type
ideas. Well done to the team responsible.

~~~
fduran
Not so evident; "exception" is mentioned once deep down. Zero mentions of
"log", "logger", I thought at first it was a debugger ("bug" is mentioned 9
times, the first header is "Say goodbye to bugs").

They should have a once sentence description involving exceptions under "Say
hello to Squash."

~~~
JonnieCache
You're right, from a marketing point of view it could be clearer. It's not as
opaque as a lot of landing pages you see though. All it needs is that
descriptive strapline, the rest of the info is there.

------
sync
Also see: <https://github.com/SquareSquash/web>

Interesting FAQ full of the developer preemptively defending design decisions.

~~~
mickeyben
Thanks for pointing this out. Definitely worth reading.

------
hcm
Another open-source alternative is Sentry (<https://getsentry.com/>), which
supports multiple languages and frameworks. A hosted version is also
available.

The Ruby support in Sentry currently isn't quite as good as the Python
support, but it's not bad at all, and constantly improving.

~~~
bruth
I second using Sentry, and it has UDP support. Maybe a few Ruby devs can just
improve the Sentry Ruby client?

~~~
marc_omorain
I third using Sentry. I love it. David has been making huge improvements in
the Ruby client in recent weeks.

------
PanMan
Interesting: With the whole 'marketing' page I expected a hosted service (and
was looking for the pricing page), not an opensource project. Looks great!

------
joelthelion
>Squash uses git blame to figure out whose fault it was

Questionnable assumption, to say the least.

Still, not a bad idea. You could also send a file to the people who
contributed most of the culprit file.

~~~
Xylakant
You need to start somewhere and with someone and the assumption that the
person who last changed the line has at least some knowledge about the problem
is better than spamming everyone.

------
dasil003
I'm surprised at all the criticism over the blame mechanism. It's clear the
goal here is to avoid the diffusion of responsibility that occurs when dozens
of people are getting the same exception emails. And in any case, what kind of
developer worth his salt is offended by blamed for a bug? I mean sure if
someone is being an asshole about it, or if they jumped to the conclusion that
it was you when you had nothing to do with it, but if git blame algorithm
flags you then what is there to be offended about? Surely we all accept that
good software can not be created by tiptoeing around the facts and occurrences
of the software development process?

This looks like fantastic software, it's the most exciting thing I've come
across in several weeks or maybe even months, and I'm looking forward to
trying it out.

~~~
void-star
agreed. Squash is finely tuned with a set of features to fill in gaps found in
another very popular commercial tool in the same vein.

tl;dr: don't knock it till you try it!

------
gmack
This is all fine and dandy, but there's too much emphasis on finding the
"engineer at fault" and blaming.

~~~
JackDanger
In practice the tool doesn't have any blame feel to it. When I commit code
that causes problems Squash correctly identifies me and lets me know what to
fix. And when I was mistakenly chosen I'm still a good candidate for triaging
the bug and sending it off to the appropriate developer.

------
xlevus
The only thing that instantly tells me what squash actually is is in the
<title> tag. Which chrome truncates to ~30 characters.

Is it a pest control system that doesn't send me emails?

------
lwf
The focus on finding "who's at fault" is going to immediately put people on
the defensive, I'd imagine.

~~~
riscfuture2
It's more about finding one person to give responsibility to (or who can
delegate responsibility). Emailing a whole team means a whole team ignores the
emails.

------
andrew93101
If this lives up to even half of its potential, it will be fantastic.

Also, routing exceptions using git blame isn't about placing blame on
individuals for defects, it's about automatically managing and routing the
massive quantity of exceptions that can occur in a large rails app with many
users and many developers.

------
gfodor
First you have a bug in your javascript somewhere. I use a real mouse and if I
scroll to the bottom of the page via the scroll wheel it jerks me back up a
few pixels.

Second, as others have mentioned, I loaded this page, scanned for a few
seconds, and still really had no idea wtf Squash was.

Finally, this phrase: "Squash uses git blame to figure out whose fault it was"
is really terrible. This assumes that someone is at "fault" for introducing a
bug. Not all software organizations embrace this concept and instead consider
bugs being introduced as a team-wide or process failure, and do not make a
point to assign blame to defects to individuals. Be careful not to shoehorn
your own views of methodology into your marketing.

~~~
riscfuture2
Fixed up the marketing page.

It isn't about blame, it's about finding one person (and only one person) who
is likely to be able to fix the bug or at least know who to delegate the bug
to. The workflow is around reducing signal to noise, so that if you get an
email from Squash, it's something you need to take action on. Either fix the
bug or find someone who can. That's why it always tries to find one person to
give responsibility to.

------
instakill
The name, seeing a word like Symbolication and having just watched an Onion
video made me think this was a joke at first, even while watching the video.

------
jjbohn
All the breath & pops in the microphone is really annoying. You should re-
record the audio using a pop filter or something?

------
torrenegra
Have you considered using a professional voice over for the screencast? It
will help you look more trustworthy.

~~~
No1
Yes, and bringing on a non-technical cofounder who can do marketing for you.
What's better, 50% interest with a big market share or 100% of none? How are
you ever going to be on the front page of TechCrunch?

Seriously, this is an open-source project. Why in the world would he use a
professional voice over? That's just weird. If anything, the home page is too
polished. People seem to be mistaking it for a well-funded commercial
endeavor.

------
northband
Nice app - a great alternative to some of the popular hosted services. Great
work guys.

~~~
larrybolt
Could you please name a few of those hosted services? Because Squash seems
currently to be written for Ruby specific apps, however PHP, Django, Nodejs
apps could use such a service too.

~~~
beastmcbeast
Bugsnag (<https://bugsnag.com>) supports Rails, PHP, Python/Django, Nodejs,
Android, iOS and Unity. Caveat: I'm a founder there.

------
dropdownmenu
Just as a heads up, I cannot scroll to the bottom of your page. I keep
bouncing as I hit the bottom and end up with 'Start using Squash' being cut in
half. Screen res: 2560x1440

------
danielpal
Looks good, I just wished it integrated with Github instead of having it's own
UI. Github already has all the functionality the squash UI webserver has.

------
markprovan
Nice, going to give this a try, along with errbit!
(<https://github.com/errbit/errbit>)

~~~
sgrove
Yes, very curious why the effort didn't go into an existing solution like
errbit? Off the top of my head, errbit is rails/mongodb, which isn't a great
combo for scaling out to the size of, say, Airbrake, but then Squash itself is
written in rails.

The code in Errbit is quite reasonable, and the team is great as well - would
love to hear the rationale!

~~~
lobster_johnson
We have been using Errbit for about six months. We are reasonably happy with
it. On the plus side, it does the job; that is, it allows me to do _my_ job.
The UI is reasonably clean, and it reports every exception to our Campfire
room.

On the minus side, Errbit is somewhat buggy, and very slow. If it gets any
load at all (say, above 2-3 exceptions per second), it becomes near-
unresponsive. A casual look at what it's doing seems to indicate MongoDB
traffic. We are running Errbit on a small VM, but the slowness is way beyond
what can be explained by the VM. So on the rare occasion we get an exception
storm it's pretty much impossible to access Errbit.

It's also terrible at merging identical exceptions. Not sure why, haven't look
at the code, not bothered enough to do so.

~~~
sgrove
We had similar problems as well, but I do miss the user experience.
Performance-wise it's just not there though.

------
jawspeak
So this is open sourced by Tim at Square. We're hiring (-:
<https://squareup.com>

------
webbruce
In that video, what extras does he have installed on his Terminal? Anyone?

~~~
janus
zsh with a custom theme probably

~~~
anteht
Looks like it. A good starting point for those that feel like trying zsh out
should check out oh-my-zsh (<https://github.com/robbyrussell/oh-my-zsh>).

------
mapleoin
_Symbolication_ is the ugliest word I've heard this year. It sounds like
disembowel and embolism put together.

Also it looks like they found a font to abuse in exactly the same way that
Comic Sans kills aesthetics, but with a different name and a slight update.

~~~
d0m
To be fair, it's still early 2013 ;-)

