colemannerd

Marfa is an amazing little town. I was there 3 months ago; while it is out of the way, even as a visitor, everyone is nice and genuinely there to provide an amazing artistic experience. If you ever want to experience the actual weird, southwestern, cowboy country, go to Marfa. And have a drink outside this public radio station. It's quite a nice getaway.

Thank you mike!

Please be careful. I'd love to adopt Dagger, but the UI in comparison to GHA, is just not a value add. I'd hate for y'all to go the AI route that Arc did... and lose all your users. There is A LOT to CICD, which can be profitable. I think there's still a lot more features needed before it's compelling and I would worry Agentic AI will lead you to a hyper-configurable, muddled message.

Thank you so much! I’ll be watching

Are migrations still specified in json?

default values! Since type hints are *hints*, it is difficult to set default values for complicated types. For instance, if you have lists, dicts, sets in the type signature, without a library like pydantic, it is difficult and non-standard. This becomes even more problematic when you start doing more complicated data structures. The configuration in this library starts to show the problems. https://koxudaxi.github.io/datamodel-code-generator/custom_t...

The issue very much is a lack of a standard for the entire language; rather than it not being possible.

We've migrated our pyenv poetry application - that's pretty complex with data pipeline flows and apis. The only issue we had was loading .env files - we had done some custom env var scripting as a workaround to an AWS issue and that was hard to migrate over. However, once that was done (and was due to bad implementation initially outside of poetry), moving from poetry to uv was rock solid. No issues and it just worked. I was surprised.

I would really encourage you to think more on this. Good enough for you... is not really the goal. We want standard tools that help with packages and virtual environments that can scale to an organization of 2 python devs... all the way up to hundreds or thousands of devs. Otherwise, it fragments the ecosystem and encourages bugs and difficult documentation that prevents the language from continuing to evolve effectively.

I think this is a great take. I'm on board on the HCL hate - it really reminds me of shoe-horning a templating solution into a complex, code level concern - but just removing YAML is not enough. My one caveat to this is a lot of the "platform engineering" products out there right now seem to want to abstract away all concerns behind a UI, which is just replacing YAML with UI problems. What we really need are open-source, cross-language sdks that allow self serving by developers using the tools they already know, but with additional configuration being able to color that settings by more specialized folks in their areas. For instance, an sdk that lets developers say ram is light, medium, heavy, etc. in whatever language they operate in; followed by a review of the sdk and some additional configuration layered on by the ops folks who monitor the entire company's spend and define what light/medium/heavy is. Too many of the platform engineering "solutions" seem to be about vendor lock-in.

It feels like you've determined there's nothing wrong with pyenv, pip, and virtualenv so any issues brought up, you will reject.

If that's not the case, here's the issue - someone used pyenv and did not exactly specify the python type - I believe we were on 3.9 and prod was 3.9.11 and the current python version was 3.9.12. There was a downstream package that had an OS dependency - I believe it was pandas - that conflicted and needed to be updated locally to work with 3.9.12. This broke and raised an error in production that was not reproducible locally - and when you deploy on AWS, reproducing can be a pain in the butt. I'm sure if the data scientist had used perfect pyenv, virtualenv, and pip commands; we would have caught this. However, they're very complicated - especially for people who focus on math - so requiring full knowledge of these tools is unrealistic for most data scientists.

I've personally seen the issues the article mentions with pyenv and virtual envs first hand when relying on pip.

BUT importantly... it REALLY does not work well for lots of teams. For me, this setup has caused production outages multiple times across multiple teams. Maybe the root python ecosystem should learn and adopt from other ecosystems that have figured out complex deployment in a much easier way.

I REALLY want to use mojo...but they still don't have basic backwards compatibility features like lambda done. I worry mojo won't get off the ground because they're too focused on hardware performance and aren't building enough features to justify the switch... to get that hardware performance.

I wish there were fixes to devcontainers before doing adding copilot. I really want declarative, repeatable builds that are easily used in both Codespaces AND Actions. I know all of the functionality is theoretically there in devcontainers.json, it is so manual to configure and confusing, that anytime I've done it, I use it for 2 weeks and then just go back to developing on local because I don't have time to keep that up. ESPECIALLY if you're deploying to AWS cloud and also, want to use alternative package managers like poetry, uv, yarn, jsr, etc.

I love Ruff and I am so excited to see python ecosystem developers tackling some really big and core table stakes problems with python. Especially now that it is being used beyond scripting and has become foundational to lots of apps.

I highly doubt they work as well as an engineer believes. If there are no absolutely no user requested changes - even something as simple as support a new browser type or device type - then maybe. Otherwise, I've seen this viewpoint kill multiple companies because it lead to uncontrollable technical debt.

Tremendous work!

Just use the design of the old G5 Tower, but a bit smaller! And in Silver, Space Grey, and Jet Black.

Jaclaz, yes, you are right, there are quite a few companies in this field. Every company has its own approach. For example, Curb does not make device detection, but shows you statistics on the circuit level (you need to connect it to every circuit breaker), Neurio detects only devices which consume more than 400W, etc.

In our case, we are focusing on reliable device detection of major home appliances (we detect home appliances which consume more than 100W). We detect devices by our algorithms and users can teach the system via training mode for more precise recognition. Beside this, we support 3-phase electrical networks (for both grid and grid+solar) and we support 220V/50Hz networks (so Ecoisme works in both Europe and US).

Yep, Ecoisme isn't a robot which turns off lights in your home ;) Ecoisme provides you with statistics of energy usage for every major home appliance and specify you clear steps how you can reduce your energy consumption. Also Ecoisme can be integrated with IoT devices in your home and then it will be possible to control them remotely.

Azaras, thank you for your comment! You need only one device per home to detect all major appliances, this is the main feature of our system. Will you be at the CES? It would be great to have a chat there :) Our booth at the CES is 51841 Sands.

Hi LisaDziuba! Yes, Ecoisme will be integrated with IoT devices and smart home platforms like Apple Home Kit, Samsung Smart Things, etc.

Hey Loevborg! Thank you for your interest in our product! Yes, Ecoisme will be integrated with connected home appliances and you will be able to turn off these home appliances remotely.

We use different approach to device recognition: we detect devices by our algorithms and users can teach the system via training mode for more precise recognition. We can show you how our algorithms works at CES'2017! Our booth there is #51841 Sands

Could you also show the vote count near each video? Could you maybe allow sorting the videos of each day by vote count? This is so close to being perfect...

I hope this becomes the default way to build npm projects... and then npm install becomes yarn :-) Exactly reproducible builds is a godsend to the js community.

and the point of the article is that they're light and provide no where near the optionality and features of AWS.

I feel the biggest disappointment in Sierra that this review didn't really harp on is the lack of new features for non-iOS users. There's not that much in this update and the end user features that are available right now are solely focused on iPhone users. As an android user, I can't use siri on a day to day basis, I can't do automatic unlock with my watch, etc. You'd suspect that most mac users have iPhones, but that's not been my experience since most developers use mac but also use android.

Your assessment is correct. It takes much longer to just run the app for the first time. The savings come in when you want to redeploy the app in multiple environments, test it, and develop new features on it. That's when all of these steps make sense - although, hopefully you'll be able to remove steps 1 & 2 when everything is a docker / Kubernetes workload.

Absolutely! You only have to use 10 year old technology for that support.