zachflower

Funnily enough, that was my computer science capstone project back in 2010!

I don’t know if our project sponsor ever got the company off the ground, but the basic idea was an automated system to scare geese off of golf courses without also activating in the middle of someone’s backswing.

Looks like it's just misconfigured. The non-https is still around: http://bugmenot.com

Oooo I like this! I’ll have to steal it.

Thanks for the tip!

Ah, I see. Thanks for clarifying!

I'm so sorry, I'm not 100% sure I understand this comment.

Would you mind explaining what you mean by asking others to adjust for your sake in the context of mobile web accessibility? I'm having trouble connecting it to the content of the article. I'm not the writer, but would love to better understand your point of view here.

Good catch. Fixed!

This is great, thank you!

I’ve been living in backend-land for so long I’ve never actually used the <picture> tag. I will have to take a stab at it and see how the legacy browsers treat it, because if I don’t have to use GIFs, I won’t.

As for the @media tags, I do utilize them to a degree, just to make everything render nicely on mobile and to support dark-mode. But (to put it cheekily) I’m more concerned with backwards compatibility than forwards compatibility :p

> Externally linked sources introduce a backward-compatibility problem of their own. E.g, I recall early versions of IE only supporting inline JS. So, if you want to support as much as possible as far back as possible, inlining is the way to go.

That was part of the reason for inlining the CSS. The other part (which I didn’t explain in the post) actually came about because of Mosaic.

Even though it didn’t support CSS, it was aware of link tags and added a button to the top of the window for each one (literally linking to the referenced file). I couldn’t dig up a way to disable that within the code, so I went with the commented-out inline method to get the experience I was looking for.

I'm inclined to agree. Without any evidence or context, these arguments rarely serve any purpose, and are most often driven by strongly-held opinions rather than objective analysis.

First of all, congrats! Whether you accept it or not, it's always an honor to be recognized.

I did a technical review for a small O'Reilly e-book, so my experience is probably a "lite" version of the process, but it mostly consisted of general fact checking and verifying the completeness of the content. The process was pretty straightforward: they sent me the book, I read it a few times, added relevant comments to the document, and sent it back.

Overall a positive and interesting experience that I would definitely do again.

It is surprisingly easy for us to rebrand into different industries. We did a test with the golf course industry a little while ago and it only took a few hours to go from idea to working product.

What is happening there is that we were able to get some geolocation data back from your IP, but a standard "City, State" format isn't available (for whatever reason).

That being said, you are absolutely right. It is very confusing. In the event that happens in the future, we will leave that field blank so users (such as yourself) can manually enter a location.

As for the "i.e." versus "e.g.," I was honestly not aware of the difference. You've prompted me to Google it, and the results are super interesting! Thanks for pointing it out! I'll make sure to get that updated.

I think what is happening there is that we were able to get some geolocation data back from your IP, but a standard City, State format isn't available (for whatever reason).

You are right, though, that is very confusing. In the event that happens in the future, we will need to leave that field blank so users (such as yourself) can manually enter a location.

Our pricing structure is the biggest point of debate among us, however we are testing different models across a few different marketing platforms and will stick with what performs the best in the long run.

As for sentiment analysis, we were performing a rudimentary analysis on all non-rated mentions (Twitter, Facebook, etc.), however the algorithm we were using was providing too many wrong sentiments, so we removed it for the time being. We are currently evaluating new algorithms and APIs, and may bring it back in if we can find one that can comfortably handle sarcasm (a favorite of the review sites) and mentions with no sentiment attached to it (the phrase "I am eating at <restaurant name>" is neither positive, nor negative).

For the current version, we link directly to the review on the original site, however we are currently working on integrations with all of our review sites to allow our users to reply directly through our interface.

Thanks for the notice, Sujan. I didn't realize the MongoDB library we are using wasn't suppressing those types of errors out in production. Fortunately, all the data stored there is just crawl data, as we are careful to silo sensitive data.

Great catch! We fixed that early on in the live reviews, but clearly didn't update the screenshot.

Thanks!

Thanks!

Telling our users the tools we use doesn't provide any benefit to them. That being said, we are huge fans of ST2, and this seemed like a better alternative to screaming about it from the rooftops :)

We aggregate all of our reviews and mentions through a combination of web scraping, API integrations, and manual scraping.

While there are several review site management services out there that offer services that sweep bad reviews under the rug, we believe that excellent customer service is what makes a good business great. We run our business with that mindset, and encourage our users to do the same.

Currently, when a negative review comes in, we notify the user and provide advice on how to properly handle it. In the future, we will be incorporating some more advanced sentiment analysis to notify users of negative mentions on sites that don't offer a star-rating system (Twitter, Facebook, etc).

My co-founder's parents own a restaurant. Being the technical person of the family, he has always been responsible for managing the restaurant's online presence.

Checking and updating the large list of review sites and social networks took more time than he had, so Bistro was originally created as a way for him to keep a pulse on his family's restaurant's online reputation.

We recently opted to open up the restaurant searching outside of the target area to ensure we found the restaurant we were looking for (Google wasn't always returning accurate matches within the city selected), however it sounds like it is providing a confusing user experience.

Removing the city selection is something we've talked about, since it is less necessary, but it sounds like something we should move forward with.

Nice catch. Definitely a typo, we're only a few months old, but I'll have that set dynamically from now on.