eKIK

I have an Ecotank and my parents have one too (data set size of 2 :). I've had it for 4-5 years now and it's superb for my simple use case (occasional low cost printing at home).

I did initially run into clogged heads too, until I scheduled a test print every month which uses all colors. That way no single color stays unused for too long, and it's been working like a charm ever since.

If the heads are already "degraded" there are two (or more?) cleaning programs available from within the official printer driver settings dialog. They did resolve my initial issues.

Epson could definitely do a better job of informing users though by slapping a big warning on the thing saying "you need to print something every X days to avoid issues".

Dw, there's quite a lot of push back against AI in some of the communities I hang around in. It's just rarely seldom visible here on HN.

It's usually not about the price, but more about the fact that a few megacorps and countries "own" the ability to work this way. This leads to some very real risks that I'm pretty sure will materialize at some point in time, including but not limited to:

- Geopolitical pressure - if some ass-hat of a president hypothetically were to decide "nuh uh - we don't like Spain, they're not being nice to us!", they could forbid AI companies to deliver their services to that specific country.

- Price hikes - if you can deliver "$100 worth of value" per hour, but "$1000 worth of value" per hour with the help of AI, then provider companies could still charge up to $899 per hour of usage and it'd still make "business sense" for you to use them since you're still creating more value with them than without them.

- Reduction in quality - I believe people who were senior developers _before_ starting to use AI assisted coding are still usually capable of producing high quality output. However every single person I know who "started coding" with tools like Claude Code produce horrible horrible software, esp. from a security p.o.v. Most of them just build "internal tools" for themselves, and I highly encourage that. However others have pursued developing and selling more ambitious software...just to get bitten by the fact that it's much more to software development than getting semi-correct output from an AI agent.

- A massive workload on some open source projects. We've all heard about projects closing down their bug bounty programs, declining AI generated PRs etc.

- The loss of the joy - some people enjoy it, some people don't.

We're definitely still in the early days of AI assisted / AI driven coding, and no one really knows how it'll develop...but don't mistake the bubble that is HN for universal positivity and acclaim of AI in the coding space :).

I consider myself to be an (occasional) user of AI services like the ones OpenAI and others provide. I've learned how to consume the services reasonably effectively, and make good use of them, but that's about it. I am not an AI engineer.

Similarly I know how to call cryptography libraries to get my passwords hashed using a suitable cipher before storing them. I don't understand the deep math behind why a certain cipher is secure, but that's fine. I can still make good use of cryptographic functions. I'm not a cryptography engineer either :).

My take on it is that if you should call yourself any kind of "XYZ Engineer", you should be able to understand the inner workings of XYZ.

This reading list is most likely (mostly) for those who want to get a really deep understanding and eventuellt work on contributing to the "foundational systems" (for a lack of a better word) one day.

Hope that helps.

We've used Nexus OSS just the way you describe and it worked great.

We simply set it up as a kind of "passthrough cache", so if it didn't have the package it fetched it from pypi, and stored it to be used the next time someone wanted to install the same package.

Apart from being nice to pypi, we also got a bit of a decrease in CI runtime, because it fetched packages from the local cache 99% of the time.

In the EU this is actually the case since 2016. There's this regulation called eIDAS (electronic IDentification, Authentication and trust Services).

Article 26 (linked below) describes the requirements for an electronic signature to be legally binding.

https://www.eid.as/#article26 https://en.m.wikipedia.org/wiki/EIDAS

I'm one of the co-founders of Hotjar, so a fair bit of the original code was mine. Most of it has obviously been replaced by others after all these years.

I'm equally, if not more, proud of an extremely bad Dig Dug clone I made in Amos Pro as a kid though :). That's what eventually caused me to pursue a career in software development.

100% agree with you that there's a lot of improvements to be done for a lot of the software we developers use on a daily basis. It's the term DX / Developer Experience in itself I dislike strongly. My sibling poster @swyx did a great job explaing my main gripe with using abbreviations like this.

I also hadn't had any coffee in way too long, so I have to admit I was a bit grumpy at the time of writing the comment :)

While Astro has a lot of impressive features I found that it was the "developer experience" (god I hate that term) that was superior compared to everything I've tried before.

With Hugo and Jekyll I always needed to go revisit the docs whenever I hadn't worked with it for a while. I never got to the "oh, I get this tool now" phase, where the content generation could just flow without issues.

Publii was cool, but trying to shoehorn everything into fitting in the "Blog" model never quite worked out for me. Also being forced to work in a new IDE wasn't to my liking either.

Here are some of the things I love about Astro:

- The docs are great. You can read through them all really quickly. I tend to prefer systems that are simple to grok, and Astro is just that.

- The lightweight Astro components (https://docs.astro.build/en/core-concepts/astro-components/) were great for me, because they delivered on being able to create reusable pieces of code very easily (without having to touch React).

- Being able to generate part of your site from markdown and part of it from precisely crafted HTML is a great way to be able to handle both repetitive and unique content.

- The Astro themes (https://astro.build/themes/) are a great way to start. Find something that's somewhat similar to what you want to build and study how they did it.

This is obviously very subjective, but for me Astro was the first SSG that I really enjoy using, and that I didn't feel like I had to fight against.

I don't think you're too cynical at all - I think you're exactly right! It's often much more sensible to use the "tried and true" stuff most of the time.

In my particular case I don't plan to have my company grow much at all - we're staying small. I think Pulumi is a sensible "bet" for me, because it does what I need right now really well. Sure, there's a bit of a risk, but worst case scenario I would spend a day or two to migrate what I have back to Terraform.

I would definitely not have made the call to "let's just switch everything to Pulumi" if I was still working at a larger company. As you said, a large talent pool / community is a huge deal when you have the option to hire people who can spend time learning a particular tool or language.

It's a very interesting point.

I've been part of managing rather large Terraform infrastructures (1000+ resources) for a couple of years, but I'm a Pulumi n00b with only about a month of experience.

The infrastructure I'm managing right now with Pulumi is much smaller, only around 130-140 different resources.

For me it ultimately came down to developer productivity. I'm much better at convincing Pulumi to do what I want compared to how it was with Terraform. This also makes me a much happier and less frustrated developer :).

My priorities might very well be different if I were to manage much larger infrastructures (infra cost would be more important for example).

+1 from me on the "awful half-baked language" (HCL).

I just recently wrote an article about my experience, including issues and workarounds, when migrating from Terraform to Pulumi: https://blog.ekik.org/my-experience-migrating-my-infrastruct...

Hope it's OK that I'm sharing it here. I think it's relevant because there seems to be quite a lot of interest around Pulumi, and how one would go about moving from Terraform to Pulumi.

Hi, I'm Erik, the author of the article.

The title of the post is "I co-founded one of the biggest behavioural analytics companies in the world." I have NO affiliation with Firebase at all, and I'm sorry if the poster tricked you by using an incorrect title.

I'm delighted for all potential US customers to get such a nice deal thrown their way - nice one Braintree! Too bad the offer doesn't extend to Europe, but I can appreciate the complexity in setting up something like this world wide.

I'm currently in the process of going live with two sites using Braintree, and everything has been great so far. Excellent Python API, documentation and extremely quick, knowledgeable and friendly support.

My previous payment provider experience has been with Cleverbridge, Digital River and Paymill...and so far Braintree has managed to surpass them in every single way. YMMV but for my use case Braintree has been a great fit.

Keep up the good work!