I've been slowly building a website full of daily puzzle games (https://regularly.co/). I built the first game for my wife (https://regularly.co/countable) which she plays every day. Floored is my personal favourite, I find it deceptively challenging
These are fun. I think Kingly would be better if solutions were unique. I was confused at first when I ended up in a situation with ambiguity and realized the puzzle just had multiple solutions (Sunday, June 29)
> I was confused at first when I ended up in a situation with ambiguity and realized the puzzle just had multiple solutions
You're right, Kingly is the newest out of the bunch and the least satisfying to solve because of that. It's getting a big rewrite under the hood this week, so should be much more fun to play to make it more deducable and less random
Full disclosure: I developed this app during Christmas '22 with the idea of offering only one challenging new puzzle/level each day. I believe that the focus on the level of difficulty makes a huge difference.
I find the bundling of stack + startup success to be quite a peculiar sell. I wouldn't have considered the two that strongly linked - but I may not be the wrong audience for it.
It is unusual, perhaps, but as Redwood has evolved, it's been natural for us to really offer support for startups using our tools. Redwood is a more complex, more integrated, and more aligned with long term maintainability than most of the alternatives, which means our market focus is on projects that need that kind of tooling. And who needs that tooling most? Startups! Plus, I do a lot of angel investing and so helping startups is of great interest to me, so I can combine my great loves!
Many RedwoodJS contributors have startup experience and we applied much of that in delivering features that often get lost in the rapid MVP pace where you have a small team and iterate fast ... only to face those decisions later. And it's not a surprise that these feature get left out early on: they take time and money -- two things startups have to manage from the get go.
Testing, logging, webhook support, setting up authentication, involving your designers more with Storybook, seeding data, mocking data, deploying, GraphQL best practices.
These are all common solvable problems that RedwoodJS has already thought of so you can focus on building a product.
Engineers often build products that "scratch their own itch." What I've found is that this product tends to attract users that are almost exactly like them! (My data is anecdotal, but I have done several user interviews, and the similarities are uncanny!)
I think a large portion of the early creators and contributors of RedwoodJS are people that were interested in building startups.
I disagree, I've never heard of them so it doesn't give me that confidence. In fact it hurts the brand, it signals that this is not mature enough to be used by Fortune 500 and from the description of its underlying choises, it is a Rube Goldberg machine, one that pulls you in with perceived productivity hacks only to end up with navigating the dozen of libraries wired up in ways to get the developer to not think about them because the battle tested and mature paths are boring and lacking in novelty.
I've been down this path before, where claims of productivity gains to get you an MVP is true to a certain degree, only to have a giant web of wiring that creates implicit and explicit cognitive load, in my opinion, its like taking out a loan for an increasing cost of capital from rising interest and equity , where eventually, you can't hire, you can't debug, you can't reverse due to sunk cost since you've bet your horses on the shiny new trendy thing where you depend on other's opinions and their understanding of the problem which will offer no real benefits to your specific, specialized contexts. This is in fact the problem with many full stack or opinionated frameworks, it ignores the last mile problem.
As I grow older, I realize now the wisdom of choosing boring tech, when I was younger it was quite frustrating but now I see that PostgreSQL + Server side rendered language + Progressive interactivity is still strong for a reason and it is not Luddism or gerontocracy, it is stability from time tested collective experience of all minds. PHP is still going strong to this date.
At the end of the day, all tech stack, architectural decisions are economically constrained by time, capital and labor supply. An overly complex arrangement, especially one that focuses on novelty over what has worked and widely used, increases risks due to unknowns. Specific issues and challenges can be addressed in bite sizes, rarely do they require ripping out the established paths, instead of throwing in a dozen of new, complex dependency and opinion ridden web of tech that is highly novel & guarantees implicit volatile technical debt with false gains that require far more trouble than its worth.
Have you ever tried to print a Notion document? It feels like they made the "Export to PDF" in a weekend. It's hugely underpowered and under-featured.
It feels like Notion's demographic just dont need to share documents as documents. Notion would likely have put more effort into that feature if they did.
> It feels like they made the "Export to PDF" in a weekend
Ah well, I built it in my first week or so as part of a hiring trial process, back when the company was 16 people in a remodeled auto body shop. Before that, the “PDF Export” feature just opened the browser print dialog.
One fun thing about working at a startup is that you solve a problem for 90% of your users, but after a while of user growth and demographic shift, that remaining 10% ends up being bigger than the original 90% was in raw numbers.
You are right. I’ve been in Notion heavy companies almost since its launch, and I’m not sure I ever tried to print a page ever.
Sharing has been done in two ways as far as I remember: straight making the page public when it was open information, or using Notion as a common draft and reformatting the text in Docs (+ adding headers etc.) before sending it to the partner.
I think instinctively anything “serious”, like a legal contract for instance, goes into Docs, even if Notion or another tool is used as a first step for collaboration.
I am not a big fan of notion, but printing a document (even as a pdf) is an increasingly niche usecase in an increasingly digital-only world and I can totally understand if they don't put in much effort into it.
One of my clients wants it for everything (typically text, stats, and graphs), and typically views it as just an "add a button" sort of feature, when it winds up being a "reimplement the layout in a different language" sort of thing. (leaving apart the thing where basically they want a gigantic lovecrafian horror of an excel file translated to the web)
PDFs have the ability to be a fixed, baked reference of a document. Even if it's not printed, it's something that people want.
> PDFs have the ability to be a fixed, baked reference of a document
I completely agree. Having the ability to look at what a dynamic document looked like at a particular moment in time (and be able to archive it), is a very important feature. In a dynamic document like Notion, people will still want to know what the data/doc looked like when decisions are made. Page-based layouts make this much easier.
What you're talking about is a failure in the "addressability" section of the digital media rubric. It's not page-based layouts that make this easy. That's entirely orthogonal. (This new Pageless feature of Google Docs, for example, doesn't make it any better or worse at satisfying the use case you're referring to than it was before.)
I’m thinking specifically as using PDFs as an archival format to snapshot the state of a document at a moment in time. PDFs are inherently page-based (well, at least in the way they are commonly used in business, I know they could be any dimension, but that’s still a “page”).
It isn’t just the ability to have temporal addressability (if I’m using the word the same way as you). I don’t really care if I can time machine back to see how a notion document looked two weeks ago. I need the ability to archive that document, save it outside of notion, send it to my client, etc. You can do this with many different formats, and could also export JSON objects if necessary.
However, when it comes to mixing layout and data, PDF is a pretty good format that has good existing tooling.
So, it’s not entirely orthogonal… it’s not just about recording state in time. You have to be able to share it in a meaningful format — independent of the original application.
A full single-file archival HTML file would really get you pretty far in the regard (embedded CSS, no JS, data/base64 images). You might even convince me that JS is okay if needed to render the page, but a static dom would be better.
All the things you said about PDF are true. You can say other true things, like that it's true that PDF gives these nice archival properties and that at the same time it's true that PDF begins with the letter P. Nevertheless, it doesn't make sense to conclude that what you want from an archive format is for it to begin with the letter P. That PDF simulates physical pages (versus not) is similarly beside the point.
Sure, but the particular PDF I emailed you is immutable (by me). It's sitting in my Sent folder and your Inbox folder in our respective email clients, and we can both be sure what it said.
Notion could implement a feature like "permalink to the content as it was at this point in time". Maybe they already have. But for me to be sure that's an immutable record, I at least have to trust Notion.
I don't see where checksums come into it - either I trust Notion to tell me I'm getting the same document we agreed on, or I need to be able to download the document in a readable form and compute the hash on my client. In which case we're back at PDF again.
Could also just be a temporary thing for now. Wasn’t long ago when signing things over the internet wasn’t a thing. People adapt slowly to changing technological advancement. Businesses can take even longer to adapt (requires then to fail + a new generation to bring along new ways with them and supplant the old way).
I haven't actually printed a document in years, but I export PDFs pretty regularly. When sharing documents with enterprise customers, it's far more reliable to share a PDF than to share a link to a document which is often restricted due to access rules on my side or firewall rules on their side.
Submitting assignments as pdf’s is extremely common at Universities. It feels like literally everything needs to be a pdf.
Also, when sending something to a client, it’s way more professional to send them a pdf document as an attachment they can open right in their browser instead of some obscure google docs / notion link.
I don't recall the past time I tried to print any document. And given that I don't own a printer and haven't been to the office in years, it must've been a while.
That's the point though. If you frequently have to convert documents to PDF or print them then you shouldn't be using Notion. Not having to worry about these use cases gives these news apps a huge amount of flexibility to evolve their UX. Otherwise every single document editor will continue to look and work like Word, as they have done for the last 30 years.
I remember reading that employment numbers is often a case big Corps make when they warrant dodging tax. “We employe X thousand people who contribute Y to the tax base so we really do pay tax”.
It gets worse when you think about how few people technology companies really employ when compared to more traditional companies (Alphabet employs 130k, Walmart 2.2 million). They have annual profits of 40billion and ~4billion (2019) respectively. It’s bonkers that employing people is a good enough reason to warrant not paying tax.
To add to that - they essentially appropriate taxes workers pay as their own taxes - as if they owned the work that worker put their life into. This is insanely evil.
No. They appropriate the employment taxes that they themselves are paying. Most folks aren't aware that employees in the US only pay half of the income tax for their employment. The company pays the other half. And those taxes usually aren't counted in these dramatic "blah company paid zero taxes" headlines. They also usually don't include real property taxes, sales taxes, etc.
Also to note, the US (now) has somewhat competitive corporate tax rates compared to its peer countries. However, most countries have a lower (or much lower) corporate tax rate than the US has. We shouldn't be comparing corporate tax rates with personal income tax rates... we should be comparing corporate tax rates amongst similar countries.
The lack of understanding of the tax rules by folks writing these dramatic headlines is really irritating.
Isn't an employment contract a worker entering an agreement to give work to an employer? Why is it evil for a corporation to own the work a worker is paid to do?
I am sorry, I probably didn't word it too well. My point is that corporation may say that the tax a worker pays is actually their tax and they use that to justify why they pay next to no tax themselves.
For example it is said that Amazon pays little tax in comparison to their profits and politicians use the argument that Amazon provide jobs and the workers pays tax, as if it was the Amazon who pays those taxes.
Shifting the blame on the victim. One reason that workers pay so much tax is because corporations don't. Corporations then enjoy multi billion profits and workers barely can get by.
Was there ever a technical reason why swarm never won out in the market? I've still got a couple of multi-node swarms that work great and are WAY easier to configure than k8s. I never really understood why it didn't take off.
I do ask the same question for all those other systems, or the meta-question: "How is it that the bloated monstrosity of Kubernetes somehow became the de-facto container orchestration tool?"
Is this just sysadmins buying themselves job security?
On the contrary, nobody was thinking of the sysadmins (until we injected the notion of Operators rather late).
Devs chose K8s, I think the evangelism phrase was “developer dopamine”. It felt like the Rails of DIY infra, where devs could inherit an opinioned pattern for doing n>1.
There’s still decades of resentment of devs being gated by IT.
Is that so? My experience is the opposite: devs don't want to learn Kubernetes YAML, they just want to git push and have someone else take care of deployment.
As someone who doesn't want to be a sysadmin, but wants to deploy applications to the cloud, the options are fairly limited. Kubernetes handles updates and scaling, networking between services, has managed offerings from all the major cloud providers, has an enormous ecosystem surrounding it, with many tools providing out of the box support for it.
I could use docker swarm, or nomad, but I have to manage infrastructure, write my own integrations, manage the underlying hardware.
Or I can run az aks create and be off to the races
Sure, at this point it's a self-fulfilling prophecy: K8s is almost the only game in town because...it's almost the only game in town.
But how did it get to that point? How did something so big and unwieldy that even billion-dollar cloud providers can't do upgrades on it properly (*cough* looking at you, EKS) become the go-to standard for running apps in containers?
Kubernetes had necessary features first, was more stable, and had many more options that enabled other teams to hang more features off the runtime. Flexibility on networking runtime and rbac both made a huge difference.
That and, unfortunately, the cloud vendors could fully deploy k8s for free because swarm was a hybrid enterprise product.
I'd also like to know more about this, since for smaller to medium sized deployments (think 1-100 nodes, maybe running between 1-1000 containers) Docker Swarm does seem like a pretty reasonable solution, especially with tools like Portainer ( https://www.portainer.io/ ) for a web based UI to manage it.
I guess some of the reasons for the popularity of Kubernetes could be:
- Kubernetes had Google as a big name behind it, so there was a lot of development resources put into it and eventually, lots of learning resources available, in addition to overall publicity; for example, i don't think anything like this exists for Docker Swarm https://www.katacoda.com/courses/kubernetes
- in addition to the marketing and PR, it got picked up as a solution for many managed offerings by cloud hosts (managed Docker Swarm has almost none), a bit like what happened with serverless and AWS Lambda
- Kubernetes allows for CRDs, has a pretty good API and has a large ecosystem built around it, to help manage its complexity (even distros like K3s and MicroK8s could be mentioned), as well as many to implement additional functionality (Istio + Kiali come to mind)
- this further snowballed into turn-key offerings like Rancher and OpenShift that had financial incentives behind them, the idea of building a new distro that vendor locks clients into a particular company's offering, resources, support etc.
- almost everyone (oftentimes incorrectly) believes that they need to be able to scale a lot and therefore chased the hype
- FOMO further motivated a whole bunch of developers to use Kubernetes for their projects, instead of looking at the alternatives like Docker Swarm or Nomad
- however, knowing Kubernetes can help to be more easily onboarded and to work with deployments in many different companies (except for when it isn't), the skills carry over nicely
Of course, some of these may be my subjective views and not at all accurate.
Personally, i think something between Docker Swarm, Nomad and K3s would be the sweet spot for containerized app deployments and orchestration, but personally i just like the Docker Compose manifests more than i do Kubernetes' and it feels like the popularity of Helm (or Kustomize) supports this line of reasoning.
Ideally we wouldn't even need containers and something like FreeBSD jails with a user friendly API around it would be sufficient. But the popularity that Docker gained seems to highlight that perhaps something was missing from those older technologies.
> the popularity that Docker gained seems to highlight that perhaps something was missing from those older technologies.
I would put money on it being the Dockerfile and the developer UX around that.
I don't honestly find it any more slick to use than e.g. FreeBSD jails, but I've lived in unix for long enough that that's because I was re-using lots of knowledge I already had.
There's a comparison here to the fact that I'm perfectly comfortable writing SysV rc scripts (though BSD rc scripts are vastly more pleasant to put together) but I've watched enough people struggle their way to something that only mostly worked that I can see why for many people writing a systemd unit file instead is a vast improvement.
I think people really undervalue the base design of k8s that is responsible for the existence of CRDs and other related pluggability (even before TPR became CRDs).
Pretty much every other option was more closed and with no extensibility, plus docker swarm was plagued (at least from my PoV) with stories of instability... and I dunno about others, but I and various people I talked with were burned with running docker in production, something that k8s nicely repackaged removing a lot of the things that were problematic.
All this went into giving some serious base beyond marketing and PR - the closest I've seen from other players is classic Rancher and Nomad, and especially the latter seems much less capable.
I used it extensively at a job for deploying production replicas for developers and full-integration testing (the plan was to eventually deploy prod the same way). It was SO nice to use. If you could use docker-compose, then docker-swarm was a natural next step.
I can't remember the details (it's been a few years), but the biggest hangup I had was the default network "mesh" wasn't stable. But I was able to work around that by using a different implementation (i think it was the network mesh that came out of k8s at the time. Used etcd).
I didn't catch that, and it looks like their comment was edited after I first saw it to make my comment. Thanks for responding to let me know instead of just downvoting like others.
I've become a particular fan of oat milk over the past couple of years. It's one of the more difficult milk substitutes to find in at restaurants the UK (coffee places usually fair better), almond and soy are relatively common. There are varieties that also froth up really well that barristas now use.
I'm a particular fan of the price point. Being from the UK I can assume that any almond milk I drink would be made from almonds from another country, it's same with the coconut oil I use for cooking. So I am willing to accept some price inflation in order to remove dairy. But oat milk tastes much nicer and would probably get whittled down to a generic price point that beats any other milk substitute because it can be grown locally (almost anywhere in fact) and cheaply.
I don't think its locality that makes oat milk cheap. Oats are cheap. Nuts tend to be expensive, even domestically grown ones.
Oats you can plant and harvest in a season, entirely mechanically. An almond tree, you have to wait years before it starts producing, a few more years to hit peak production, and harvesting isn't nearly so automated.
Not OP, the reasons for eliminating diary are so many - cholesterol, hormones( most notably estrogen), IGF1 which is cancer promoting, antibiotics, casein morphine( which makes milk products addicting), the dairy industry is extremely cruel and the huge environmental impact due to all the resources needed to bring up a cow
I find this list highly amusing. You’ve listed quite a few barely-supported-by-evidence reasons, but you’ve missed the two big reasons that are big deals to a lot of people: lactose intolerance and allergy.
Most adults worldwide are lactose intolerant, although symptoms and the amount of lactose needed to trigger symptoms vary. And allergies to milk aren’t particularly rare.
In Scandinavia, most cafes seem to offer lactose-free milk, which is a great option for lactose-intolerant people. It’s also amusing, since Scandinavia has the lowest incidence of lactose intolerance anywhere. For milk allergies, oat milk is obviously a better choice.
FWIW, I think that foods like ice cream should always use lactose-free or at least lactose-reduced milk. It’s nutritionally identical but sweeter, so ice cream and such can be made with less sugar.
I didn't say your claims were wrong. I said that they were poorly supported and that you ignore the two much larger reasons that large numbers of people avoid dairy.
I read the abstract. It suggests that circulating levels of IGF-1 may be related to cancer. It does not say that drinking IGF-1 is related to cancer or that milk contains absorbable IGF-1. In fact, I found one study that determined that IGF-1 in milk is broken down during digestion and that mechanism by which various dairy products might impact blood IGF-1 levels are unknown.
So I maintain my claim that all the reasons you listed are poorly supported. In contrast, the fact that most people do not have the lactase persistence trait and end up lactose intolerant as adults is very well supported indeed. Similarly, I know people who have done genuine lab tests and determined that they have bona fide IgE-mediated milk allergies. Apparently some people also have non-IgE-mediated immune reactions to milk. Of all of these, among adults, lactose intolerance is far and away the most common issue with dairy products.
If you want to drink milk or eat cheese that is cruelty-free, there are quite a few purveyors in Northern California that have cows that are very happy indeed. If you ever want to feel jealous of a cow's living conditions, just drive near any of the dairies in Point Reyes. Some of them offer tours, and others will let you just drop by and say hi to the cows. I'm sure there are plenty of places like this outside Northern CA, too. Obviously, you'll pay a bit more for this milk, although, the cheese doesn't seem to carry much, if any premium. I suspect the latter is related to the reduced costs of being a Class B dairy that produces cheese in house.
If you want to drink milk or cheese that is cruelty-free, you drink a plant based milk and eat plant based cheeses.
Just because there are a couple of cows that might look like they are living the dream cow life (for 4 years out of 20, because they don't produce enough milk to be economically viable and kept alive after that) and still the calves have to murdered early on to get all that milk (it is originally made for calve consumption, not people).
That might be the most common reason globally, but not necessarily in the UK where only 5% are intolerant. Many of those can tolerate small amounts such as you'd put in tea/coffee.
For men over 45, there is a correlation between milk and BPH (enlarged prostate and difficulty in urination). Farmers inject hormones (and other things), and the animal produces its own. All of these excrete into the milk causing irritation to the prostate and the resulting enlargement causes difficulty in urination. Same problem with whey protein powders and cheese. BUT! If the item is cooked, then there does not seem to be an effect. [1]
