Hacker News new | past | comments | ask | show | jobs | submit | dataviz1000's comments login

> But doctors never definitively diagnosed Johnson with celiac disease. His doctors wanted to do a biopsy to get a definite answer, but that would require eating gluten again, something Johnson wasn’t willing to chance.

How about this for an app idea? Does this already exist?

Use the app to record all the food consumed. Use AI to read restaurant menus, cereal boxes, ect. Give the user a survey every 1 hour. Make eating A/B testing strategies, for example, have the user not eat dairy for a day, then not eat gluten, ect.. Do some calculations and figure out what foods cause what symptoms.


I've had this web app about 15-20 years ago, until the tech got obselete. It was popular, yet little bit more simpler Now I saw that somebody made similiar app...but without proper execution.. If you make one, please don't focus on automating photo taking and that stuff, but the simple ui + simple results

Ingredients lists are not enough.

I was a private yacht chef for 7 years. They would hire anyone off the street to work on a $35,000,000 private yacht without checking references or a background check. I had unprecedented access to CEO's of Fortune 100 companies and phone numbers of a couple billionaires on my phone. I thought about writing a spy novel where a bunch of college students got entry level jobs on a yacht and used the access to plant bugs. The plot is they get caught and have to escape the Caribbean while being chased.

You have my preorder. Post your keybase in your profile and let’s get the ball rolling.

1. A group of EECS graduates get jobs as deckhands and stewardesses on mega yachts in order to bug the yachts to glean information for trading securities.

2. They install computers in the electronics cave below the wheelhouses because nobody knows what most of the electronics there do in the first place.

Today there are hundreds of mega yachts in Fort Lauderdale, Florida with thousands of unscreened workers maintaining the yachts before they leave in November for a season of cruising and charters in the Caribbean.

3. They get caught by Russian mafia while in Martinique or St. Lucia.

4. They MacGyver their way out of the Caribbean while being chased by thugs with unlimited resources.

I'll get around to writing it one of these days.


Visiting Ft Lauderdale as students on spring break and chatting with barflies gives one of them the germ of the idea....

Perhaps, someone in the MIT ocean engineering program doing a semester at sea on the Corwith Cramer breaks bad. Back in the day they would lure crew by using ladies of the night to entice a victim into a Shanghai Tunnel [0] where they would be abducted. Our protagonist working on submersible project on the Corwith Cramer gets seduced by a yacht crew member while having a drink at the Leeside Pub or the Captain Kidd bar in Woods Hole. It wouldn't be the first time.

Personally, I had planned to spend a season working in a restaurant in Miami Beach and was evacuated from the inter-coastal because of hurricane Irma. The only bed I could find was in a crew house in Fort Lauderdale. All the windows were boarded with plywood and they had several kegs and dozens of bottles on the table as we waited out the storm with a party. Fortunately the storm tracked the West Coast. Someone asked what I did and I said I was a chef. They suggested I become a private yacht chef. Two weeks later I was cooking on a private sailing yacht in the Bahamas.

Probably more interesting if a storm blows the protagonist into a situation.

[0] https://en.wikipedia.org/wiki/Shanghaiing


Location: Chiang Mai, Thailand today, Kuala Lumpur, Malaysia tomorrow. I'll return home to the United States soon.

Remote: Yes

Willing to relocate: Yes

Technologies: TypeScript, JavaScript, PHP, Python, FastAPI, Redis, MongoDB, PostgreSQL, TimescaleDB, MySQL, React, React Native, NestJS, AngularJS, Backbone, Playwright, Drupal, Express, jQuery, D3.js, visx, GraphQL, browser extensions, and AWS

Résumé/CV: N/A

Email: [HN username]@gmail.com

I build browser automation agents that run in Node.js frameworks such as Playwright, browser extensions (Chrome Extensions), and Electron Applications. While traveling the world during the past year working on many personal projects, I built an IPC/RPC framework for consistent communication between JavaScript runtime execution contexts with a strongly typed interface which solves a very specific problem. Browser automation requires orchestrating several different JavaScript processes using many different messaging APIs, such as WebSockets, postMessage, fetch, MessageChannel, sockets, etc. If you are at Microsoft, there are reasons you would be very interested in my current project.


violets are blue


[dead]


The last time I worked earning money was 2.5 years ago. Not sure what I'm doing that is fraudulent. Can you please explain?


I think they assumed you worked. Which tbh wasn't a bad assumption given the article.


Falsely accusing people of fraud is libel and it is illegal.

Thank God we have due process in the United States!!!


This is perfectly legal and the government of Thailand is well aware of this practice (I believe it is only allowed for air entries). The US and the Schengen zone both have limits on stays within a six month period which effectively eliminates this practice and the Thai government could do the same if they wanted to stop this.


They're not doing this, but a lot of people abuse the system to enter on a tourist visa and then do work while there, which isn't legal.


I don't understand. Do they change countries when their tourist visa is about to expire? And work under a tourist visa (thus fraud)?


I’m visiting Chiang Mai Thailand and China is flooding the roads with cheap EVs, BYD, Hozon. There is charging infrastructure everywhere. I don’t know how the United States is going to compete.


So far it would seem that the U. S. is tackling that competition with tariffs. OTOH, I’m not sure what it would take to get a (for example) BYD to pass crash testing, and if it would still be price-competitive.


BYD cars already get top crash ratings in European tests. For example: https://youtu.be/7ThTci70350?si=8-gTWRr1_jTdZam0.


> BYD cars already get top crash ratings in European tests

I see it coming up in the top 10 for 2023, but not 2024 [1]. Just not released yet?

[1] https://www.euroncap.com/en/ratings-rewards/electric-vehicle...


It's so frustrating that rather than treat the climate crisis as an actual crisis, we've instead decided to heavily tax EV buyers in order to support domestic manufacturers that have been dragging their feet for decades.


[flagged]


> Tariffs of 100% on China EVs is a nuclear weapon to prevent them from gaining any ground here

Doesn't matter if Chinese manufacturers enjoy economies of scale from supplying Europe, South and Southeast Asia, Africa and South America. If American automakers are constrained to America and grow complacent, the compounding effects of learning curves and R&D advantage due to greater total profits will leave us with a fleet of Ladas.

At the end of the day we have to compete. Other than Tesla, we are uncompetitive in the mass market. The tariffs are meant to give us a safe harbor. But they don't automatically deliver us an edge.


A Global Times article says that China has 3,000,000 public EV chargers[0]

US Department of Energy data has the number for the USA and Canada combined as 66,650[1]

This might not be Apples to Apples as the USA numbers might be "sites" and the china number might be "chargers", but I don't think there's anywhere close to an average of 45 chargers per site to make up the difference.

[0] https://www.globaltimes.cn/page/202406/1314382.shtml

[1]https://afdc.energy.gov/fuels/electricity-locations


It is also very easy to develop systematic automated ways to do this with tools like Playwright and Nut.js.


Ok, how would you use Playwright and Nut.js to discover the OP’s “splinter”? Note I’m specifically asking about discovery, not testing for it once you already know what to look for.


I've actually been thinking lately about property based testing for UIs. In this particularly case, there should be an invariant for each entry in a radio button list that the selectable area covers the entire bounding box from button to the end of the label. There are many such invariants you could imagine - every paragraph of text should be selectable by a click and drag, menu drop downs shouldn't hide as long as the mouse is within its area etc. Build up a big enough suite of these tests and you could quite easily integrate them in Storybook or beyond. Probably not something you want to run on every save, but an asynchronous process running somewhere recreating this "sanding" activity would be a worth way of saving time and improving quality.


If I understand you correctly, you mean to build up one test suite, and apply it to many diverse applications?

I'm afraid that will be pretty hard to accomplish, given that such requirements are not easy to distill from the user interface itself, and impossible to obtain from the codebase (which, by definition, would contain bugs that you'd like to catch).

Perhaps LLMs or a "user interface foundation model" might come in handy to find these implicit requirements, and run tests on the application.


Not sure I’m proposing a single test suite, although some of these invariants are very likely applicable to multiple components or sites. I’m just saying that property based testing ought to be applicable to UIs, but it’s not the sort of thing we’ve experiment with because executing the tests is slow. That’s probably fixable in a practical way that’s still more efficient than human QA for a large class of bugs (including both the back button and non-convex hitbox issues mentioned in the article).


Obviously this won't catch everything human QA can, but where an invariant can be expressed (navigating then going back should result in being in the right place, as mentioned in the article) it seems good to try and capture it.


I build browser automation systems with either Playwright or Chrome Extensions. The biggest issue with automating 3rd party websites is knowing when the 3rd party developer pushes changes which break the automation. The way I dealt with that is run a headless browser in the cloud which checks the behavior of the automated site periodically sending emails and sms messages when it breaks.

If you don't already have this feature for your system, I would recommend it.


IO between humans and websites can be broken down to only a few fundamental pieces (or elements I should say). This is actually where AI has a lot of opportunity to add value as it has the capability of significantly reducing the possibilty of breakage between changes.


That's a great suggestion! Essentially a cron job to check for website changes before your automation runs and possibly breaks.

What does this check look like for you? Do you just diff the html to see if there are any changes?


The issue with diffing html is selectors are autogenerated with any update to a website's code. Often website which combat scraping will autogenerate different HTML. First thing is to screen caption a website for comparison. Second, it is possible to determine all the visible elements on a page. With Playwright, inject event listeners to all elements on a page and start automated clicking. If the agent fills out forms, then make sure that all fields are available to populate. There are a lot of heuristics.


Are you doing screenshot comparison with Playwright? If so, how? Based on my research this looks to be a missing feature but I could be incorrect.


Playwright has screenshot comparison built in, including screenshotting a single element, blanking specific elements, and comparing the textual aspects of elements without a visual comparison. You can even apply a specific stylesheet for comparisons.

Everything I can see in this demo can be done with Playwright on its own or with some very basic infrastructure e.g. from Azure to run the tests (automations). I can't see what it is adding. Is it doing some bot-detection countermeasures?

Checking if the page behaviour has changed is pretty easy in Playwright because its primary purpose is testing, so just write some tests to assert the behaviour you expect before you use it.

We use Playwright to both automate and scrape the site of a public organisation we are obliged to use, as another public body. They do have some bot detection because we get an email when we run the scripts, asking us to confirm our account hasn't been compromised, but so far we have not been blocked. If they ever do block us we will need to hire someone to do manual data entry, but the automation has already paid for itself many times over in a couple of years.


Some ideas. First, are you saving the cookies and adding them when Playwright bootstraps? [0] Second, are you using the same IP address? Or better use a server running from your office or someone's house. Those are the big ones. The first prevents you from having to continuously login.

It is a game of cat and mouse. It is impossible to stop someone determined to circumvent bot protections.

[0] https://playwright.dev/docs/api/class-browsercontext#browser...


I'm a little late to conversation.

As a chef for 17 years, here is the advice I was given when I asked someone at age 16 what I should do to become a chef. He said I should get a job as a dishwasher. His reasoning is I needed to learn to appreciate and respect the restaurant's dishwasher because, in his words, 'when shit hits the fan and everything goes wrong, it is the dishwasher who will save your ass.'

At 17, I walked into one of the best restaurants in the California and told them I was looking for a job as a dishwasher and why. I was very lucky because it lead to working in the best restaurants in the world. It took another 5 years, age 22, before I learned the power of telling an employee out loud I can't succeed without them. They didn't even want a raise, they only wanted me to say those words.


>when shit hits the fan and everything goes wrong, it is the dishwasher who will save your ass

I'm 100% sure I have already read this exact phrase before.



If you open up the code Playwright codebase you will discover that it is literally Puppeteer with the copyright message header in the base files belonging to Google. It is a fork.


That is a huge oversimplification, if I ever saw one. If you look at the early commits, you can see that it isn't just a simple fork. For starters, the initial commit[1] is already using Typescript. As far as I am aware puppeteer is not and is written in vanilla JavaScript.

The license notice you mention is indeed there [2], but also isn't surprising they wouldn't reinvent the wheel for those things they wrote earlier and that simply work. Even if they didn't directly use code, Microsoft would be silly to not add it given their previous involvement with puppeteer.

Even if it was originally a fork, they are such different products at this point that at best you could say that playwright started out as a fork (Which, again, it did not as far as I can tell).

[1] https://github.com/microsoft/playwright/commit/9ba375c063448...

[2] https://github.com/microsoft/playwright/blob/3d2b5e680147577...


I'm not convinced. It looks like v0.10.0 contains ~half of Google's Puppeteer code and even in the latest release[0]the core package references Google's copyright several hundred times. Conceptually, the core, the bridge between a node server and the injected Chrome DevTools Protocol scripts are the same. Looks like Playwright started as a fork and evolved as a wrapper that eventually included APIs for Python and Java around Puppeteer. At the core there is a ton of code still used from Puppeteer.

[0] https://github.com/microsoft/playwright/tree/48627ad48405583...


As I said, even if playwright started out a fork, classifying it as just that these days is a pretty big oversimplification.

It isn't just a "wrapper around puppeteer" either but a complete test automation framework bringing you the whole set of runner, assertion library and a bunch of supporting tools in the surrounding ecosystem.

Where puppeteer still mainly is a library and just that. With which there in principle is nothing wrong, but at this stage of development does make them distinctly different products.


> at this stage of development does make them distinctly different products

I agree with that.

The base concept is the same, there is a map between element handles on the server and elements in the browser contexts which are synced over channels with websockets. The user creates an element handle in the sever and the element gets wrapped inside the browser context with a unique id. Any events emitted by the element, are sent over websockets to the server.

At one point, I had used this code to inject a script into browser contexts with a Chrome Extension which communicated with a server over websockets to automate browsers with the Chrome Extension installed.


Did you read the New York Times today? [0]

[0] https://www.nytimes.com/2024/07/21/opinion/biden-west-wing-a...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: