ryanto

- for 6 and 9 handed, yes they can solve any 2 player scenario you give it. you solve to some expected loss (like 1%), so it's not a perfect solve. you can solve lower, but it takes longer. in theory there are multiway hands that are unsolvable.

- human players adapt to GTO by leaving the game. you are not beating a solver. solvers by their very design are unexploitable.

- sites can catch players that use solvers if they care to. in my experience there are sites that care and others that dont, depends on the market. regs know who is cheating.

Wow, this is amazing, great read too. I have a few "test spots" I like to use with solvers and yours nailed them.

>A more modern approach instead “re-solves” each spot to a limited search depth and uses a neural network as an approximation function at the depth cutoff.

This sounds very interesting, I'd love to hear more about it. A few years ago a wrote a solver that worked by reducing the entire game tree. It was slow, and couldn't do preflop. It sounds like these re-solves allow preflop solves with needing a massive tree?

oh i'm not worried about it. they have been so generous with the resets these last few weeks.

you should give openai a try. ive been really happy with them these last few weeks

Hey looks cool. I tried to run this on a small oss library and here's what happened:

  $ codex-security scan .
  [00:00] Preparing scan
  [00:00] Authentication: stored Codex credentials.
  [00:01] Preparing scan
  [00:42] Running scan
  [00:42] Preflight: worker delegation supported (up to 8 worker slots).
  [41:03] Running scan
  codex-security: This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber program: https://chatgpt.com/cyber
  codex-security: Partial output was kept at /Users/ryan/.codex/state/plugins/codex-security/scans/framework/codex-security-framework-z7eNfr.

Just some feedback, but it ran for over 40 minutes and during that time I had no idea what was happening, thought it was frozen or in a bad state. Also, it ate through 25% of my weekly credits :(

Incus uses LXC containers under the hood, which is better for development since the containers are made for running systems/os. Docker is best for running applications, but not that great for active development containers (imo).

With LXC any changes you make to the os/filesystem are persisted and there after the container boots up and shutsdown. So I don't have to worry about ephemeral storage or changes being lost. It feels more like a "computer" if that makes sense.

I run incus os, which is an operating system that is made for spinning up containers and VMs. Whenever I have to work on a JS project I launch a new container for development and then ssh into it from my laptop. You can also run incus on your computer without installing it as an operating system.

Containers still have some risk since they share the host kernel, but they're a pretty good choice for protection against the types of attacks we see in the JS ecosystem. I'll switch to VM's when we start seeing container escape exploits being published as npm packages :)

When I first started doing development this way it felt like I was being a bit too paranoid, but honestly it's so fast and easy it's not at all noticeable. I often have to work on projects that use outdated package managers and have hundreds of top-level dependencies, so it's worth the setup in my opinion.

Sorry to hear you got hacked.

I know we aren't supposed to rely on containers as a security boundary, but it sure is great hearing stories like this where the hack doesn't escape the container. The more obstacles the better I guess.

You can use pnpm, which forces you to approve the install scripts you want to run.

Looks awesome. Gotta say, the built in testing, websockets, and file system router are exciting to see.

Is anyone using bun in production? Would love to hear your experience.

I've been a long time Cypress user, but recently have been feeling those pain points you mentioned, the half-async-half-sync APIs are driving me mad :)

Im interested in Playwright, but wondering how you find the visual runner compared to Cypress? Are you able to run your tests in the browser and use a `debugger` or dev tools?

This is so cool!

From the blog post it says read-only replicas are created close to users and kept up to date with the latest data.

- How should I think about this in terms of CAP? If there's a write and I query a replica what happens?

- How are writes handled? Do they go to a single location or are they handled by various locations?

I'm excited to try this. It's so cool to see databases being distributed "on CDNs" for lack of a better term.

Great article!

I will say I've found that using prettier makes nested ternaries much more readable.

I couldn't imagine using them without prettier, but since every app I work on these days uses prettier nested ternaries aren't so bad.

yes, next will prerender everything. you should give it a try.

I think for css classes like ".profile-card" this approach makes a lot of sense. Tailwind has @apply, which is a great way to turn these utility classes into named css classes.

However, after a while your app will end up with classes like .profile-card--inner, .profile-card__wrapper, and .profile-card__inner__wrapper--horizontal. When that happens it's usually easier to use those utility classes directly in the HTML template. You'll end up with something like:

    <div class="flex items-center mb-4">
    </div>

It's quick to write and requires no context switching!

There's a lot of problems that slackbots can solve, but asking people what type of slackbot they would pay $10 a month for is not probably not going to generate a lot of viable business ideas.

Find out problems folks are having and from there narrow that list down to those that are easily solvable by slackbots.

> the amount your company pays you is primarily determined by how much they would have to pay someone else to do the same job.

This is true, but the thing you're missing is that there's not many folks out there that can add value for customers. That's why engineers who create value get paid so well, which is the articles point.

I've noticed that engineers that get paid the most tend to understand the technical and business trade-offs that come from decisions they make.

While the decision can be made by one person, I'm not sure this is true. There is a big switching cost for most team tools.

* There's going to be a lot of discussion and consensus building. Most of the team is going to have an opinion on the subject.

* Setting up new accounts for team members, teaching team members how to use the new tool, and change management all take time.

* Most teams have integrations within their chat apps, these will have to be switched or re-implemented to use new APIs.

I think it's fair to say that most team tools have good moats. The longer the team has used a tool the stronger the moat becomes.

It depends on the type of work you do. If you are putting together a handful of pages and only plan on spending a few hours writing CSS then probably no need for preprocessor.

On the other hand, if you're a front end developer or you find yourself working on CSS multiple times a week then you should absolutely use a preprocessor.

There are tradeoffs between the two approaches, but preprocessors do save you time so the added complexity can be worth it the more you work on styling.

Neat. I've always wondered if Uber's ride sharing had a weak moat. As a consumer there's little difference for me between taking an Uber, Lyft, or something else. This makes it easy to compete in the consumer ride sharing market.

If Uber is able to integrate with other apps this introduces a high switching cost for those apps... and that gives them a pretty solid moat. Excited to see how this API gets used.

As others have said it's very strange at first. My co-worker introduced it to me a little over a month ago and I remember thinking "how is this maintainable?". After a few hours it started to make sense and now I can't imagine going back to BEM.

Being able to design UIs without opening a single CSS file has made HTML pretty fun and I've found I'm much better at componentizing the right things.

I've found the best way to know if I'm going to work well with someone is to have previously worked with them before. Look for people you've enjoyed working with, be it a co-worker, classmate, someone you've worked on open source with.

Things that I think must exist between cofounders.

* You must like and trust each other.

* Make sure you are able to be candid with each other.

* Know each others weaknesses. Really another way of saying have realistic expectations.

If you have no prior work experience try working on a small one-off project to get a feel for each other's working styles.

Yes, all styles of programming have patterns because patterns are something humans are good at. If you want to learn more about functional programming I would recommend reading the following books.

* Learn you a Haskell by Miran Lipovaca

* Purely functional data structures by Chris Okasaki

Here are a few suggestions.

* List open source on your resume.

* During interviews talk about your open source accomplishments. Use open source as a way to show you have experience in software development. This is especially helpful with team based open source projects.

* If you are contributing to an open source project with a community be vocal in that space. Answer stack overflow questions, write blog posts, tweet, and get involved in other online areas where discussion takes place.

* Build a website for your open source project. HTML content is easier for most people to consume compared to a github repo with README.md.

* Speak at a conference or meetup. A great way to get started with this is to give a 5 minute lighting talk demo for the project at your local language meetup.

Doing these things will help you market yourself and your open source work. This usually opens the door to networking with people that have similar interests, which is a great way to further your career.

It depends, technical debt lets the team build features quickly today at the cost of slowing down future development.

Startups with a short runway probably don't have a future, so technical debt can be viewed as something with little downside that gets you to market faster. The tradeoff is that as your runway gets shorter debt makes it harder to try new things.

I'd say don't worry too much about technical debt before p/m fit. However, don't let anyone on your team use debt as an excuse for half-assing something that could deter finding market fit.

A problem with this is it adds useless commit history. If I make a significant change to some code, but then later on you remove some bad formatting/white spaces the latest commit messages for that code block is most likely "removed whitespace" and not something more meaningful.

That, and tasks that are left to be dealt with later are tasks that never get done.

Ruby has a linters, but this sort of problem is hard to solve with a linter in a dynamically typed language. It's even harder in a Rails environment since Rails adds many methods to your classes at run time.

This won't work because it is not refactor proof. What happens when your system changes and Model.bar needs to become a method that does computation.

Your suggestion violates the uniform access principle: http://en.wikipedia.org/wiki/Uniform_access_principle

The biggest problem with "class << self" syntax is that it is hard to read in classes that have more than a handful or so lines. At quick glance you might not be able to tell if "def xxx" is a class method or instance method. However, with "def self.xxx" it is more easily recognizable.

Btw, I think its a small nitpick. Plenty of great code bases use "class << self".

I think it is unfair to single Ruby out here and call it a "flaw". What you are describing is just bad code/design that can exist in any language.

Also, as far as Ruby is concerned your class's external API is only made up of methods. There are no attributes, model.foo is always a method. Because of this your long running or resource intensive methods need to be documented or have clear names if you are exposing them as public API. In other words: Model.foo shouldn't take 30seconds, but maybe Model.download_foo will.