I haven't used this program specifically but I'm using an OK one (called "Take a break") and credit it with letting me look at screens again.
A few years ago my eyes would dry out within a few minutes of using a screen. I tried eye drops, resting my eyes, taking longer breaks, etc... which didn't work.
I did some research and there's something called the 20-20-20 rule which means looking at something at least 20 feet away for 20 seconds every 20 minutes. I found this app and it fixed my issues. Turns out the issue is your eye not changing what it's focusing on.
Highly recommend trying it even if you're not actively experiencing issues.
Your app looks a lot nicer than the one I'm using so I'll give it a try!
Thank you! My journey has been pretty much the same - extremely dry and irritated eyes after screen use and then 20-20-20 solved it so I decided to build this app :)
Does anyone have a similar solution for drawing graphs / charts in a Node environment without a browser dependency? Last time I explored this I couldn't find any good solutions.
Unfortunately not for nested inline nodes, like spans of text with formatting. For a lot of uses, that will be OK - but for rendering say, markdown text, Satori won't work.
The upstream layout engine handles flexbox layout, and it's unclear if Facebook needs inline layout or if Vercel would pick it up and close the gap:
https://github.com/facebook/yoga
Then again, for the main purpose Satori is advertised for - generating URL unfurl previews - Dropflow looks like it might be the answer.
Thanks. I've tried using Satori but I'm curious if you've used it to draw graphs specifically. E.g. Satori expects JSX / doesn't support HTML strings from d3-node with dangerouslySetInnerHTML.
I was curious how Igalia was funded and this was a surprisingly good interview on how they’re structured, how they work with the major browser companies, etc… Apparently many Apple, Google, Firefox engineers left to work for them.
Since they are apparently "powerful" enough to decide major direction of WebKit development as evidenced by OP's article, what exactly is their relationship with Apple in this regard? Like who has the final say and who do the day-to-day decisions?
I'm always curious about the politics and power structure/dynamics of these major open source projects, especially the ones backed up by large companies.
To be clear WebKit is made up of multiple ports. These ports are maintained by their own groups and Igalia maintains WebKitGTK/WPE where this change is happening. It does not affect the Apple ports of WebKit.
To answer your question though. WebKit is Apple's project and they do the majority of contributions. Igalia is the second largest contributor and collaborates with Apple regularly. Within the GTK/WPE ports Igalia controls them.
I’ve never used this. Instead, the best thing my wife and I did was create a “bills” and “play” account. My recurring bills come out of the bills account and everything is paid automatically. My discretionary funds go in the “play” account and I feel free to spend that until it’s gone. This is handled with automatic deposits.
Later I added savings accounts to the list but the first two are the cornerstone of my budgeting.
The nicest thing about YNAB (which is budgeting in general -- YNAB just did it in a way that I stuck with it) is that it gives me permission for guilt free purchases.
No need to think about it; the budget's right there, so I can spend it without second guessing myself.
I used YNAB before but much prefer LunchMoney[1] (the thing that got me to switch initially was better multi-currency support, since I generally make money in one currency, hold it in another, and spend it in a third). My referral link[2] will get you 1 month free ;)
Came here to say this exact thing. We aren't perfect, but YNAB has really helped my wife and me to get our finances more in hand. It's probably the best money I've ever spent on software.
Second to YNAB. I’m sad they’ve raised the price, but 99% of our budget and finance strife is gone due 100% to YNAB. Plus the deal to have free budgets for your older kids? Very nice.
I think you're actually misunderstanding what david38 and Retric are discussing. They're saying they're in agreement and that the US and Central America are similar, but not "equally bad".
I actually think you're all misunderstanding what you're discussing.
No, I won't expand as to why, I just wanted to continue this alleged misunderstanding train.
I saw a few posts discuss using the Wiktionary dump directly vs. the freeDictionary API, which is difficult to do because the raw wiki text isn't immediately usable. I actually created and open sourced a project several years ago that I never publicized that lexes and parses the Wiktionary dump:
Specifically it can understand and execute 21 different wiki text templates (e.g. "cog", "borrow", "gloss", "prefix", "qualifier”), e.g. {{inh|es|la|gelātus}}:
And eventually parse it into this structure, which has a list of all definitions (distinguished into nouns, adjectives, verbs, adverbs, etc...), etymology, links, and descendants for a given word:
Further parts of the pipeline turned different relationships into edges that I could stick into a graph database and do certain graph queries. This allowed me to do certain queries like find French, Spanish, and English words that share a Latin root.
I ended up parallelizing this specific query using Apache Beam and then dumping the results into Firestore so they could be queried via a web app. Here's an example for the Spanish word: helado
Under the "Cognates" section, it knows that it comes from the Latin root "gelatus" from which English has borrowed the word "gelato".
I originally started this project when I was learning Spanish. If you just look up the definition of helado (ice cream) it doesn't necessarily help you learn it. But I found that if I could relate it to languages I already knew (e.g. English and French), it was easier to remember. In this case helado is related to gelato, but you won't find that in e.g. Google Translate or SpanishDict.
Ultimately, I found that while the Wiktionary data is amazing, it’s also a bit of a quagmire for finding cognates. I would miss certain etymologies where you had to follow a descendant tree 2 or 3 levels deep. Or a definition would just mention a word it was related to. But if I expanded the query to include these instances, then it significantly increased the amount of non-cognates that showed up in the results.
So I created a useful set of tools (which I never wrote about until now), but I realized the end result of a web UI that showed the relationships between words would require a significant investment in data quality that likely wasn’t possible without changing Wiktionary itself / community investment.
Thanks! Yeah I've seen a few similar projects (particularly written Java which I wasn't excited about). That looks like a nice project. It's written in Python and says it can take from an hour to several days depending on the computer and they don't recommend running it on a Mac.
I don't have up-to-date benchmarks but my project is written in Go and everything was designed to be as highly parallel as possible, broken up into multiple pipeline steps (splitting the Wiktionary dump, lexing, parsing, resolving, etc...) with a high emphasis on performance so I would assume it's faster but would need to do a head-to-head test.
I just want to plug Playwright by Microsoft as I've been using it over the past month and have had a really great experience with it: https://playwright.dev
It's built by the founders of Puppeteer which came out of the Chrome team. Some things I like about it:
1. It's reliable and implements auto-waiting as described in the article. You can use modern async/await syntax and it ensures elements are a) attached to the DOM, visible, stable (not animating), can receive events, and are enabled: https://playwright.dev/docs/actionability
2. It's fast — It creates multiple processes and runs tests in parallel, unlike e.g. Cypress.
3. It's cross-browser — supports Chrome, Safari, and Firefox out-of-the-box.
4. The tracing tools are incredible, you can step through the entire test execution and get a live DOM that you can inspect with your browser's existing developer tools, see all console.logs, etc...
5. The developers and community are incredibly responsive. This is one of the biggest ones — issues are quickly responded to and addressed often by the founders, pull requests are welcomed and Slack is highly active and respectful.
My prior experience with end-to-end tests was that they were highly buggy and unreliable and so Playwright was a welcome surprise and inspired me to fully test all the variations of our checkout flow.
I just want to plug Playwright by Microsoft as I've been using it over the past month and have had a really great experience with it: https://playwright.dev
It's built by the founders of Puppeteer which came out of the Chrome team. Some things I like about it:
1. It's reliable and implements auto-waiting as described in the article. You can use modern async/await syntax and it ensures elements are a) attached to the DOM, visible, stable (not animating), can receive events, and are enabled: https://playwright.dev/docs/actionability
2. It's fast — It creates multiple processes and runs tests in parallel, unlike e.g. Cypress.
3. It's cross-browser — supports Chrome, Safari, and Firefox out-of-the-box.
4. The tracing tools are incredible, you can step through the entire test execution and get a live DOM that you can inspect with your browser's existing developer tools, see all console.logs, etc...
5. The developers and community are incredibly responsive. This is one of the biggest ones — issues are quickly responded to and addressed often by the founders, pull requests are welcomed and Slack is highly active and respectful.
My prior experience with end-to-end tests was that they were highly buggy and unreliable and so Playwright was a welcome surprise and inspired me to fully test all the variations of our checkout flow.
I did, but only very briefly. I originally wasn't looking for an E2E tool but was evaluating another tool for a different problem (Nx) which included Cypress as part of its opinionated defaults.
Cypress was a surprisingly nice experience as well and led me to research other modern e2e tools. Most of the points above can be compared against Cypress — Playwright supports parallel execution of tests within the same file on the same machine, which Cypress doesn't, and so is much faster. Cypress doesn't use modern async / await syntax. Due to its architecture, Playwright can test across tabs, work with iframes easily, which Cypress can't.
The UI for Cypress's developer tools is nice, but... as I said, Playwright's tracing UI is really excellent and the documentation is also really well done. This is also a personal thing, but I trust tools that came out of browser teams (Chrome) to emulate browsers in a more efficient way, e.g. spinning up cheap, isolated browser contexts in Chrome, the details of waiting for an element to be ready, etc...
