mherrmann

Re your question on saving costs: If you run it on a single Linux VPS, then I suspect you can get the costs down to 5-10$ per month.

One thing I find interesting is the growth chart: It's linear. But given that the app clearly has some traction, and is viral in nature, how come it isn't exponential?

I think it does matter. Let's assume Musk paid $12B. How much have you paid? Isn't it then actually reasonable to say that he contributed more than you to the country, even if his tax percentage is lower than yours?

I agree with the first half, but strongly disagree with the second half of what you wrote. Ideas matter immensely. If you work on the wrong thing, perfect execution is not going to get you anywhere. If you work on the right thing, then even with mediocre execution will bring you at least some success.

Does this mean that all .io domains will cease to exist?

Author here. Thank you for sharing. I'll be happy to answer any questions.

It depends on the individual part of Chromium. Some teams seem to be much more open to contributions than others. (I believe to recall that this is also what someone at Viasat told me at some point, but I'm not sure).

Also, for example the browser name appears in a lot of places. It is very hard to fully extract it into a single configurable option.

Congratulations! And thank you for the great write-up. I work with the Chromium code base a lot, and it can indeed be daunting. I use Sublime Text, which treats the code as plain text, apart from syntax highlighting. But it's also possible with at least VS Code to get some more intelligence, such as going to the definition or declaration of a function, etc.

People who have now become interested in creating their own Chromium-based browser may want to take a look at my article: https://omaha-consulting.com/how-to-fork-chromium. It gives a high-level view of what goes into maintaining a Chromium fork.

I understand that a lot of science and technology goes into modern farming, and that it's much better than it used to be. You did not address one of the main downsides I mentioned, which is that it still seems to be extremely reliant on the weather.

You're telling me I have no clue. I don't disagree. But what would be much more interesting is for you to address the points I made.

Having watched Clarkson's Farm, I can't help but feel that farming is extremely antiquated. The sensitivity to unexpected weather and the low profit margins despite the high investments of time and money seem terrible. I can't see us as an advanced species doing this in 100 years, except for specialty experiences.

Yup. But the rest of the functionality is missing, I think.

Cool. The link to "Risks" in the README is broken.

What I would love: `ell -r` automatically, and an alias `fix` that proposes a fix, including making changes to a file. For example, say I have a typo in main.cc and do `gcc main.cc`. When I run `fix`, I want ell to propose a fix in the file with a diff. If I accept, it should make that change. Then it should propose running `gcc` again - and run it for me if I accept.

In 10 years of using Python mostly full-time, I have not yet had a project where pip and vent were not enough.

The example is terrible. It's understandable that OP wants to keep it as short as possible. But it is made so simple that it fails to convey the point. You would obviously not want to use the DeadlineSetter class here. It doesn't even ever access its "entity_type" field.

All code bases I have seen in the past 15 years have too little DRY, not too much. Yes, every technique we use has pros and cons and we need to decide in each case whether DRY is worth it. But I worry that people will come away from the article (or even just the headline) with the feeling that "ah, I don't need to DRY". I've been in the situation too many times where somebody copy-pasted and I later had to make it DRY to achieve consistent behavior. Let's err on the side of DRY.

In the example, the right-hand side could either be left as-is. Or it could extract a function:

  def set_task_deadline(task_deadline):
    _ensure_is_in_future(task_deadline)
  
  def set_payment_deadline(payment_deadline):
    _ensure_is_in_future(payment_deadline)
  
  def _ensure_is_in_future(deadline):
    if deadline <= datetime.now():
      raise ValueError(“Date must be in the future”)

This is much better than the straw man example employed by the author.

What are your requirements? Performance, development speed, native look and feel, ... Which languages are you familiar with? Do you have a preference with regards to the language?

Unreasonably shameless plug for my open source Python library Helium [1], so you don't need a test generator.

1: https://github.com/mherrmann/helium

https://winstall.app. There's also winget.run, but it's no longer updated.

Lower your expectations with regards to finding a remote position. I know you came here for comfort, but it seems to me that you are better served by hard truths. Working remotely, you are competing with the whole world. People in lower-income countries will be cheaper and not necessarily worse than you. Use your location as an advantage.

I have no specific sympathy for Altman one way or the other, but:

Why is Worldcoin a grift?

And I believe his argument for it not being open is safety.

winget.run is no longer updated. Try https://winstall.app

So close!

> the choice of a native Arm browser on Windows is effectively just Edge

This is incorrect. Brave also has native Arm support, including Widevine.

Thank you for the kind words and understanding. I'm happy to hear you liked it!

I rephrased my comment to make it clearer that it's a GUI tool, thanks.

Shameless plug for my more modern, GUI alternative to Midnight Commander, https://fman.io.

TL; DR: ten years ago, Raspberry Pis and Android phones were a handful times faster. Nowadays, they are around 100 times faster. Pretty impressive, considering they fit in our pockets.

It's in Table 3.

The relevant data for the claim of the headline is in Table 3. On all the tasks with enough data, bots were both faster and more accurate than humans.

The CSS structure of a web site is an implementation detail and on a global average, CSS selectors break much more often than user-visible labels.

I don't get why people still use XPaths, CSS selectors or HTML IDs to identify elements, even when they are "recorded". Please please please just use my https://github.com/mherrmann/selenium-python-helium instead. It makes so much more sense.