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.