tsergiu

By "internal feedback" do you mean feedback when a user is logged into an account?

We allow you to do fine-grained censoring of any DOM element by adding class="do-not-track". So if there's a field, or an entire page, that you do not want captured, you can easily mask all of it.

Passwords fields are always censored, and there's no way to disable that.

We also have limited session lengths (up to 30 days), unless a user leaves feedback or a member of the team explicitly saves a moment.

You can learn more here: https://moment.help.guide/v1/user-manual/time-travel/privacy

Why is it not possible to embed the NFC tag in a destructible medium? Like those annoying stickers that you cannot peel without ripping?

If you use that, then the only way to move the NFC tag to another item would be to cut it out of the original item (including the original adhesive). But this attack also works against the technique in the article.

Regarding the orientation, I understand that it is nondeterministic in the original, but what prevents an attacker from copying it deterministically? Is it just that technology is not good enough to manipulate such small pieces of metal? How long will this limitation persist?

What prevents somebody from scanning it and reconstructing the position of the metal pieces?

Perhaps a better solution is to create a small chip powered by electric induction. The chip would have an embedded private key and solve challenge-response queries issued by the scanning device.

I'm not sure how that compares in cost though.

Edit: it looks like these already exist and cost less than 10 cents a piece. They are called NFC tags.

Adding an explainer now

We tried for years to do things like this, and in the end an approach using typescript is way, way better than anything else I've seen attempted.

In my latest project[1], we set up the types for the API. The server and client are both bound by those types, meaning that one cannot change without the other. This fixes an entire class of bugs where backend code gets updated without the corresponding front-end code changing or vice-versa. It also has the nice side-effect that all of the possible return values (including errors) are nicely documented in one file, and that the errors are very consistent. On the frontend we have a "typed fetch" which returns typed results from the API.

We are also using this for typed access to localStorage, another source of many bugs in past projects, where random keys end up being scattered and causing nondeterministic behavior on different devices.

You can see how our API type system is implemented here:

- common types for both client and server: https://github.com/stoarca/presupplied/blob/master/images/ps...

- client's typed fetch: https://github.com/stoarca/presupplied/blob/master/images/ps...

- server's typed endpoint definitions: https://github.com/stoarca/presupplied/blob/master/images/ps...

[1]: We are working on https://app.presupplied.com, a digital home-schooling curriculum to teach 3-year-olds to read. Planning to expand to math, writing, and programming.

I am skeptical of reports published by the cities. There is incentive for the reports to skew positive, since otherwise individuals can lose elections/jobs/contracts.

So I looked back at the 2014-2016 reports from Flint, Michigan to see if they correctly predicted the water crisis.

They did, but only very subtly.

In 2014, there was a single violation of too many total trihalomethanes: https://www.cityofflint.com/wp-content/uploads/2014/01/CCR-2...

In 2016, there were no declared violations, even though the 90th percentile sample of lead concentration (20 ppb) was over the 15 ppb limit: https://www.cityofflint.com/wp-content/uploads/City-of-Flint...

Also note that while in the US the lead concentration limit is 15 ppb, Canada has recently reduced its limit from 10 ppb to 5 ppb. Nearly every US city I've looked at exceeds 5 ppb.

Almost every date picker I've used is terrible. If you are reading this and are responsible for adding a datepicker, please, please, please do at least the following:

1. There should be a textbox allowing me to type a human-readable date/time (e.g. "monday 5pm" or "july 7, 2015").

2. The textbox should be selected and ready to type into as soon as the datepicker is opened

3. There should be a short list of previously-typed dates because often, for a given date in the UI, the same date is used multiple times in quick succession

4. There should be a typical month view with days of the week visible, in case I'm on mobile

5. The current date should be highlighted on the month view.

6. I should be able to pick the month and the year in at most two taps each (i.e. dropdown for each), no matter how far back in time I need to go.

Shameless plug: we recently implemented an exceptional date picker on momentcrm.com because of how frustrated we were with the default browser experience.

In my opinion the syntax of layerci is relatively simple as someone coming from docker, and does basically boil down to "give us the commands you use to deploy"

However they also have the advantage that they can run deployments on arbitrary runtimes. It looks like reploy only works if my app fits in the runtimes that were preconfigured by you. Because of that, I can run not just my dev deployment, but something very close to my prod deployment as well (we've had multiple bugs that only show up in prod due to our build process).

And finally, their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well. The speedups are typically in the triple digits compared to a reasonably well-optimized build.

I think the differences are major enough that I wouldn't exactly characterize the end results as similar.

Full disclosure: I know the founder

Crowdsourcing works in cases where lots of customers are interested in the same set of attributes to extract.

But by definition, customers interested in long-tail attributes (i.e. virtually all of them) don't have others to source those from.

Training a new model for each category is already possible today, but doesn't achieve the goal (mass-specialization).

The problem is that when you pre-train a model, you can only solve for the lowest common denominator of what every customer might want.

In ecommerce, for example, you might pre-train to get price, product name, reviews, and a few other things that are general to all ecommerce. But you won't pre-train it to get the mAh rating of batteries, because that's not common to the vast majority of customers (even within ecommerce). It turns out that most customers need at least a few of these long-tail properties that are different than what almost every other customer wants, even if most of the properties they need are common.

And so the challenge is to dynamically train a model that generalizes to all "battery sites" based on the (very limited) input from a customer making a few clicks on a single "battery site".

I'm the founder of parsehub.

We are doing well and are independently owned.

I think there are 3 things that contribute to this:

1. It is very easy to make a prototype that looks "magical" but very hard to build something that works in real applications. There are an enormous amount of quirks that a browser allows, and each site you encounter will use a different set of those quirks. Sites also tend to be unreliable, so whatever you build has to be very resistant to errors.

2. There is a technological wall that every company in this space reaches where it is not yet possible to mass-specialize for different websites. So even if you're able to build a tool that works very well on any individual website, the technology is not there yet to be able to generalize the instructions across websites in the same category. So if a customer wants to scrape 1000 websites, they still have to build custom instructions for each website (5-10x reduction in labor vs scripting) when what they really want/is economically viable for them is to build a single set of instructions that will work for all similar websites (10000x reduction in labor vs scripting). This is something that we're working on for the next version of parsehub, but is still a couple years away from launch.

3. Many of the YC startups you hear about have raised funding from investors and have short term pressures to exit.

The combination of the three makes it very tempting to give up and sell.

We used to use Intercom and were frustrated that they charged us a random amount every month.

They also don't have tools for lead gen or making calls to customers. It was a big pain having our calls go through skype. We'd have to take manual notes on the call and there was no good way to schedule follow ups so we ended up using a mish-mash of systems to do this.

Shameless plug: In the end, we started a competing product, MomentCRM, which has simple, predictable pricing, and spans the entire lifecycle of your user. No more data silos or "integration engineers"! I'm one of the founders, and I will move mountains to make sure you're happy if you decide to try it :)

We're a small team from Toronto, Canada that's also behind ParseHub.

Our goal was to launch quickly and iterate, so the public-facing portion of the site is somewhat barebones at this stage. We'll be sure to add legal info shortly.

Thanks for the feedback, we'll work on the mobile version of the pricing page to make it less confusing.

We don't have bots yet, but they are coming in the near future. If you leave your email (just start a conversation on our site), I can follow up with you when they're ready.

No, we sell our chat at cost in order to expose customers to the other parts of our platform, which we think are far better (and directly translate to more revenue for our customers) than other, siloed platforms.

We expect to make money on our chat-only customers when they migrate other parts of their workflow to our platform.

Aside from that, we are still experimenting with pricing, but of course will grandfather the pricing that early users sign up with.

Hey HN!

We built Moment because we found that there weren't any other platforms that make user data easy to manage. Each type of user data was in its own silo.

We'd have email/chat in Intercom/Drift, revenue data in Stripe/Chartmogul, demo and sales calls booked via calendly and tied to Google calendar, then the calls themselves would happen over Skype/Hangouts and disappear into the ether. Some support reps would take notes in Evernote, so they wouldn't be available to other reps. For analytics we'd use things like Hotjar, which was again siloed away from the rest of our user data.

Moment is designed to be the single source of truth for all of your interactions with your customers; no data silos. And of course, you can use just a part of it if you don't want to adopt it for all of the use cases above.

I'd be happy to answer any questions.

Thanks so much for the feedback!

I think, based on other feedback we received, at least a subset of our target audience (recent graduates who are too busy to plan stuff) wants a way to be able to stay healthy without the boredom that comes with going to the gym.

I think the near-term plan is to give users the option to pick their desired intensity level. My personal bias also leans towards doing more intense activities, and I'd like the service to be one that I'd use.

The choice of two adventures is to prevent the "what if I don't like that week's adventure" argument. Currently, if too few people sign up for an adventure, we pad the rest of the group with personal friends :)

Almost every person we talked to gave us the feedback that they want to see the experiences of others. Will be adding that shortly.

The option to pay for a single adventure is a good idea.

Thanks again!

Our aim is to provide a variety of events.

They vary from high intensity: climbing, biking, trapeze, archery, hiking, various sports, etc.

To mild intensity: yoga, horseback riding, walks, camping, scavenger hunts, etc.

To low intensity: board/card games, pottery, art classes, concerts, galleries, museums, bird-watching, etc.

We hope to get feedback from the first batch of customers on how to improve these.

I'll be adding these examples to the site shortly.

Hey all,

I've always been frustrated by the amount of hassle involved in researching and planning interesting things to do on weekends. So much so, that most weekends I end up staying inside.

It's also become harder to make new friends since graduating from university.

I figured other people might have the same experience, and this is the lowest-friction solution we could come up with: Just a 1-character response to an email and we take care of all the rest!

I'd really appreciate any feedback you have.

Shameless plug, check out https://parsehub.com

Full disclosure: I'm one of the co-founders of ParseHub.

For folks looking for an alternative, check out http://www.parsehub.com

ParseHub is especially good at dealing with dynamic websites and multidimensional data (arbitrary relationships instead of just rows and columns).

Our team would be happy to help you migrate from Kimono. We're bootstrapped and profitable, so we don't have pressure to sell when an offer comes along. We also pledged to release the back-end code under a liberal open source license if we were ever in a position where we could no longer provide service.

Neither choice is great (the other ones that I've tried auto-convert \r\n to \n so it's impossible to test a \r\n string). I don't think there's anyone in particular that's at fault, \r\n causes a messy set of problems.

You can step through the FSM on Debuggex by using the sliders :)

Ah, you're likely on a Windows machine. Debuggex will terminate lines depending on your system. So you would need \s\s to match both \r and \n

Author of Debuggex here.

Debuggex actually has the /g flag always enabled (the example above happened to have just one match), and it works for JS [1]. Groups for JS are indeed quite tricky. However, they come for free if you implement state visualization, since you need your own regex engine to do that (and can use said engine for the position of groups).

[1]: https://www.debuggex.com/r/wSCkdE0_MNrysz4x

This overlay technique works beautifully for guided, interactive tutorials.

We've had great success using it in our tutorials to get users quickly up to speed with our product.

It works better than the similar "show bubble beside dom element" technique[1] for a few reasons:

1) With bubbles, you need real estate next to the element to display the help text. This often doesn't exist, especially e.g. inside a frame in a Firefox sidebar. By fading everything else out, it is easy to have the help text in a different location.

2) Bubbles are typically not as high contrast as the overlay, so they are a weaker mechanism for drawing attention.

3) With the overlay technique, you can highlight multiple elements at once, which is impossible with bubbles. This is critical when you need to explain how two things relate to each other, and something that seems to be missing in this library.

You can check out how we did our interactive tutorials at http://www.parsehub.com (they're within the extension).

[1] http://css-tricks.com/bubble-point-tooltips-with-css3-jquery...

One of the creators of debuggex here.

For javascript, debuggex conforms to the regular expression implementation in google chrome (which is mostly the same as all other browsers).

Specifically, a \n in your regex where group n doesn't exist is actually interpreted as the octal \00n.

If I recall correctly, \1(a) should match just "a" because all groups start out as being empty.

Parsing regular expressions is indeed complex, and we've got a massive suite of tests to make sure our engine works correctly (with respect to the chrome implementation, since that's what most people are using js regexes for).

Here at ParseHub, we're attacking the problem from another angle. Our tool lets users turn semistructured html (even the complicated, interactive kind) into structured data. The user does this by visually describing relationships in and across pages.

The key idea is to make it easy for another party to add the semantics on top of your data. This solves some fundamental issues that you and Cory Doctorow mentioned:

1) The economics equation for tagging now works out. The user that's doing the tagging has an immediate need (and payoff) for doing that tagging.

A corollary of this is that the parts of the web that are most valuable (in the sense that users need them the most) tend to get tagged first.

The following are responses to Cory's essay:

2.1) The person that's doing the tagging is also an end user, so there's an incentive to do the tagging honestly. That doesn't stop the underlying website from lying. But that's an issue with the web in general, and is mitigated by things like SEO penalties, reviews, etc.

2.2) Again, the tagger is the person who benefits from the tagging, so as long as the data is valuable enough, it will be tagged despite laze.

2.3) We haven't overcome human stupidity. Presumably since the person tagging the data needs it, it will be at a "good enough" level to be usable.

2.4) This one doesn't apply; the tagger is a different person.

2.5) 2.6) and 2.7) These are tougher, and we haven't started working on them yet. You have the same problems when trying to consolidate data from multiple sources. One possibility is to have several alternatives and allow searching to choose between them. That's how Bloomberg solves some of these problems, though it does result in fragmentation.

I'd love to talk to you about this some more. You can email me at serge@parsehub.com

Full disclosure: I'm one of the founders of http://www.parsehub.com

One of the founders of ParseHub here.

Not quite. Sikuli tries to figure out where things are by doing a visual match. This works very well for things like automating applications or sites where page elements are fixed (e.g. finding an option in a menu or using a search engine). But it works terribly when trying to overlay semantic structure on dynamically-generated data. For example, it has no way of knowing that a list of movies is split up on multiple pages, with each movie having multiple genres, a cast, and multiple reviews, each of which has a rating and an author.

There's also the additional drawback that it is hard to parallelize things in Sikuli (you would need heavyweight vms, and there are no obvious "breaks" in the flow). So doing something at scale is not feasible.

With ParseHub, one of the goals is to make it easy to express relationships (and we think we've done a really good job). We also automatically figure out how to split a job up across an entire fleet of servers.

Hope that offers some insight. Email me at serge@parsehub.com if you have any other questions.

Sorry for the delayed response. See my answer to a similar question in this thread: https://news.ycombinator.com/item?id=8356999

If you have any more questions or just want to chat, feel free to shoot me an email directly at serge@parsehub.com