JeanMertz

I love the work you are doing in Bevy. I often filter the PR list based on your handle just to see what big graphics/performance work you are cooking up.

I unfortunately do agree with you on the BSN syntax, I guess it's a matter of tradeoffs, but I don't think backward breaking changes are off the table for the foreseeable future, so curious what can be done to improve the syntax in the next couple of releases.

Although what I really look forward to is auto-formatting of the syntax, I care about the feel and look of the syntax, but I care even more about consistency across my code base.

I have my LLM/gaming PC tucked in a rack in my basement:

- 100ft DisplayPort + USB cables going to my home office's monitor - 100ft HDMI cable going to the TV on the wall in my home office - 30ft HDMI + USB cables going to my receiver in the upstairs gaming/tv room

Works great. I can control/game from any of the three screens, and I also have Moonlight to sometimes control the PC remotely either in the house (bedroom) or externally via Tailscale.

I have an old Steam Link lying around, but I never have a use for it anymore, so while I can understand that there is an audience for Steam Machine, if you are capable, and have a dedicated gaming machine, a couple of long active/fiber HDMI+USB cables is all you really need.

For what it's worth, this is exactly why I am working on Jean-Pierre[0], pitched as:

> A command-line toolkit to support you in your daily work as a software programmer. Built to integrate into your existing workflow, providing a flexible and powerful pair-programming experience with LLMs.

The team behind DCD[1] are funding my work, as we see a lot of potential in a local-first, open-source, CLI-driven programming assistant for developers. This is obviously a crowded field, and growing more crowded by the day, but we think there's still a lot of room for improvement in this area.

We're still working on a lot of the fundamentals, but are moving closer to supporting agentic workflows similar to Claude Code, but built around your existing workflows, editors and tools, using the Unix philosophy of DOTADIW.

We're not at a state where we want to promote it heavily, as we're introducing breaking changes to the file format almost daily, but once we're a bit further along, we hope people find it as useful as we have in the past couple of months, integrating it into our existing terminal configurations, editors and local shell scripts.

[0]: https://github.com/dcdpr/jp [1]: https://contract.design

  Location: CEST TZ
  Remote: Yes, exclusively.
  Willing to relocate: No
  Technologies: Rust (4y), Golang (5y), Ruby (5y)
  Résumé/CV: https://jeanmertz.com/career
  Email: [email protected]
  Call: https://cal.com/jeanmertz

I am a senior software engineer focused on the combination of high-level abstract APIs and low-level performance-driven systems. I am an avid learner and an excellent communicator. I am a pragmatic ethical engineer with a knack for software architecture, an eye for user experience and a capacity to lead.

Even though GP meant to highlight compiler error messages, I also have to take my hat off for the library/application error-handling story in Rust.

Using a crate such as thiserror[1] combined with displaydoc[2] makes handling errors in a structured manner a great experience. I love how the error handling story has evolved over the last couple of years in Rust, and it really feels like we're entering into the final stretch of fine-tuning to get the best possible experience.

And yes, anyhow[3] is also great, it serves a different purpose, but I frequently reach for all three crates.

[1]: https://crates.io/crates/thiserror [2]: https://crates.io/crates/displaydoc [3]: https://crates.io/crates/anyhow

Résumé/CV: https://jeanmertz.com/career

  Location: The Netherlands
  Remote: Yes
  Willing to relocate: No
  Technologies: Go, Ruby, Rust (see résumé)
  Availability: Full-time/part-time/contract, January 1st 2020
  Email: [email protected]

I am a senior software engineer focused on the combination of high-level abstract APIs and low-level performance-driven systems. I am an avid learner and an excellent communicator. I am a pragmatic ethical engineer with a knack for software architecture, an eye for user experience and a capacity to lead.

Clippy has an (off by default) lint to warn/deny using multiple versions of the same crate.

We've been discussing potential solutions, and came up with three avenues, listing their pros and cons. We're leaning towards a "Sandbox accounts in production" approach at the moment, but recognize that none of the solutions are free, and whatever we decide on will have a big impact going forward.

Production-like environment

  + Clear, separate environment
  + No impact on production data / users (events, emails)
  + Not a problem if we mess up data without cleaning up afterwards
  + Runs the same code as on production
  + Requires very little changes to existing code

  - non-production code can (and will be!) deployed, making it no longer "production-like"
  - data needs to be kept in sync, to be usable by clients
  - every service needs to run both a production instance, and a production-like instance
  - all external services need to work with this production-like setup (payments, emails, etc...)
  - higher ongoing maintenance overhead
  - requires "manual agreements" on how to manage/manipulate this environment

Individual temporary environments

  + all the pros of the "Production-like environment"
  + even more isolated, higher guarantee of your expected state of the environment

  - requires a lot of CI/operational changes
  - requires ongoing maintenance to keep working
  - requires "operational" knowledge to make new changes work with this setup
  - requires more syncing of data
  - higher costs of running

Sandbox accounts with special "capability" flags, in production

  + All test-data is scoped to a (sandbox) user account, single "source of truth" on wether some piece of data is test-data
  + One single environment to maintain, no divergence
  + Data is always the same as production
  + Whatever code runs on production, is what you test
  + Because you want to test your changes, you automatically make sure your new code works with sandbox accounts / capability flags
  + You deploy your pre-production changes behind a capability flag, for testing
  + A preference page allows you to enable/disable certain capabilities to enable real/fake PSP environments, pre-release functionality, etc...

  - Much more complex to realise
  - Only works (well) for user-scoped test-data
  - Might result in higher learning curve to ship a feature that works with sandbox+capability flags
  - Production data can be changed accidentally, there's nothing but our own code between test and production data
  - Other systems need to be able to handle (and/or ignore) test data
  - Only suitable to the specific use-case of testing user-flows, not for testing f.e. if a library upgrade broke anything

We booted a fresh GKE 1.4 cluster yesterday to migrate from our old 1.3 cluster.

Looking at the machine, it looks like this is a fork(?) of CoreOS:

  $ grep core /etc/passwd
  core:x:5000:5000::/home/core:/bin/bash

  $ cat /etc/os-release
  BUILD_ID=8820.0.0
  NAME="Container-VM Image"
  GOOGLE_CRASH_ID=Lakitu
  VERSION_ID=55
  BUG_REPORT_URL=https://crbug.com/new
  PRETTY_NAME="Google Container-VM Image"
  VERSION=55
  GOOGLE_METRICS_PRODUCT_ID=26
  HOME_URL="https://cloud.google.com/compute/docs/containers/vm-image/"
  ID=gci

  $ toolbox
  Spawning container core-debian-jessie-backports on /var/lib/toolbox/core-debian-jessie-backports.
  Press ^] three times within 1s to kill container.

If not a direct fork, it certainly uses the same base Chromium OS (which is no surprise) and uses some of the same toolsets that CoreOS uses.

Not sure if you are serious, but while Azure is from Microsoft, it is definitely not Windows only. In fact, most of the products coming out of the "new" Microsoft pipeline aren't in any way tied to Windows.

Kudos to them, and awesome to see people working to get Kubernetes to work on Azure.

Whoops, that shouldn't happen. The team is unable to reproduce this though. Could you share the link where you tried to sign up?

If you want, you can send me an email (see other comment) and we'll get this sorted.

Good point. Our current "onboarding process" for publishers is a bit too heavy-weight to allow "just anyone" – even you ;-) to join Blendle right now.

This is definitely something we're investigating though. And in The Netherlands, there's already a collective of journalists who created a non-profit umbrella organisation to represent freelance writers, who have been onboarded into our system.

Also, the Blendle Button that I linked to above is it's own product, with a much less heavy-weight onboarding setup. We've already seen great success using the button on a German site like http://uebermedien.de/abo/ (in this case, a flat-fee subscription button). So that's definitely something we'd like to roll out to as much freelance publishers as possible.

They "disappear", as in, they won't show up at the front of your timeline. They can still be accessed and/or searched for.

We also have selected curators who can promote articles worthy of your time, and a daily mail that highlights the articles we believe are interesting to you.

Gaming the system is something we're always watching out for. This is indeed something that we'll continue addressing as we learn.

We would certainly _like_ it if you upvoted, but you'll get access either way :-)

This is indeed an annoyance that we noticed as well. Send me a message at jean [at] blendle.com and I'll get this sorted.

You mean a button like on this page? (It's in Dutch, scroll a bit down)

https://www.vn.nl/het-debat-21/

We hear you. And we're working on it. This is only the first step of which many more will follow in the coming months.

It's pretty hectic at the office, but TIME will be available shortly!

update: here it is: https://blendle.com/issue/time/bnl-time-20160321

What we've found at Blendle, is that it's not the regular newspaper articles that sell best, but in fact it's the bigger opinion pieces, and more importantly the more in-depth background articles.

Please remember that these background articles often require months of research and journalists going abroad. These types of in-depth articles are hard to get on most blogs and/or free news sites.

Without these in-depth articles, our news consumption would be very shallow. This is what triggers people to pay for articles on Blendle, they want to be informed, they want to know more about a subject and/or event that recently happened. They probably already _know_ that it happened and what the end result was, but now they are interested in _why_ it happened and _how_ the end result came to be.

Related, this[0] Monday Note is interesting as well:

Last November, in a rather blunt way, I expressed my reservations regarding Blendle’s model (see The New York Times and Springer Are Wrong About Blendle[1]). My concerns ranged from the abundance of free content available on the web (especially in English), to the damage inflicted on the “cross-subsidy model” in which baseball coverage pays for the Kabul bureau, to the risk associated with the “unbundling” of news (and its impact of publishers’ ARPU).

To their credit, Blendle’s co-founders Alexander Klöpping and Marten Blankesteijn seized on my questioning and engaged me in an ongoing discussion focusing on business models that could ensure the survival of quality journalism. This could be a crucial factor in Blendle’s fate: this company has been created by journalists who fervently defend quality journalism and believe that great editorial must be paid for. In spite of my initial reluctance, the more I explored its model, the more I came to believe it should be tested and carefully analyzed, essentially because it is much more sophisticated and carries more potential that a first look might lead one to believe.

[0]: http://www.mondaynote.com/2015/10/05/blendle-is-up-to-someth...

[1]: http://www.mondaynote.com/2014/11/02/the-new-york-times-and-...

Once the beta launches, the privacy statement can easily be accessed in English. But for now, here's how it starts:

===

Blendle takes your privacy very seriously, and will process and use your information carefully. We keep it safe, and hidden from third parties. Since we don't have any ads, there's no need for us to collect data to sell ads.

To use Blendle, all you need is a valid email address. Of course we (no one else, mind you) are interested in getting to know you a little better in order to make your Blendle experience even more amazing. For example: our head honcho Alexander lives in Amsterdam, but was born in Oss. So what we'd like to do, is show him news articles from Oss and Amsterdam newspapers in his Blendle article list first. There are many other ways to tailor Blendle to what you want based on your information, but of course we'll only use your info to do so if you're totally okay with it.

Most companies have privacy statements of countless A4-sized pages, written in a way neither you nor we can understand. We think that's ridiculous, which is why we've asked our lawyer to use as much normal language in the text below as possible. Using a down-to-earth writing style is pretty tough for lawyers, but he did a pretty good job.

...

Interesting questions.

Re: Do you require users to purchase a certain number of credits up front after the trial?

The "trial" is really $2,50 that we give you upon signup. You get another $2,50 after your first "top up". We show the prices in your own currency, so no "credits", but top-ups start at $5, and go up from there. You can choose to auto-topup when your wallet drops below $0.

Re: I see you offer refunds if you don't like the story. What prevents a person from just reading all they like and then asking for a refund?

The refund mechanism is an important tool to generate trust with the reader. We don't want you to feel "nickel-and-dimed" and if publisher promised a certain article through the heading and intro, but didn't live up to those expectations after reading the article, we encourage you to refund, and tell the publishers why you asked a refund (through a dialog), so publishers can learn as well.

We have certain mechanisms in place to prevent abuse of this system, but we're lenient, and in general we see only about 10% of purchases are refunded this way.

Re: Is it possible to copy and paste text from the articles to share on social media? (I assume you have a share mechanism, but this is more specific).

You can. Again, it's built on a mutual-trust system. So far it has worked out great, if we ever notice the balance tipping, we'll have to tweak the system.

Re: Once I pay for the article, does it stay in my account forever, or could it be pulled by the publisher?

It does stay in your account. We don't have any mechanism to actually remove articles from our platform. Highly occasionally, we remove the content of an article, because it was published by accident (f.e. a newspaper delivering next days newspaper too early, and it containing the score of a pre-recorded contest).

Our founder, Alexander, just announced this on Business Insider's IGNITION event.

You can add yourself to our beta invite list at https://launch.blendle.com. We're really looking forward to next year!

Let me know if you have any questions.