I have to ask how do you like the pine book pro?

I have one of their phones but the software at the time was really under developed so it mostly sat for a few years

I ended up figuring out im averaging about 120w on my desktop which isn’t bad at all.

A web browser, a code editor and some docker containers or binaries. Nothing incredibly strenuous. Like I’m not gaming.

Definitely will look into the MacBooks power consumption. The logic checks out for sure. I have to measure my current laptops too.

Thank you! Appreciate it

🌶️🥵Many people consume Facebook meta company’s tech stack wholesale, don’t know how to actually traditionally program their way out of a paper bag, and web dev and devops caused a massive layoff (250k people) at the end of 2022, start of 2023 because it was all vaporware. They consume the same software in droves if the other guy uses it.

There is an entire subculture around it that is just a bunch of medium.com writers, YouTubers and twitter handles just trying to get the clicks for their ad money. Some of these guys have never written valid software or done anything noteworthy. If you meet them head on you’d find they have enormous egos and can’t find a counter argument when presented with reason.

I’ll even add on that there are many programmers who don’t know how to code outside a web app.

Why is something like [react, graphql, react ssr, devops, tailwind, unit tests, containers] vaporware?

• there are other frameworks even with component libraries that are easier to read the code for large codebases, better maintained, and have cohesive full stack solutions, and even faster to develop in, to name one quasarJS or even just plain ecmascript
• if you look at the anatomy of these enterprises using these solutions they’ve evolved to have micro front ends requiring armies of workers.
• devops is a sales term, the actual implementation of it is so contextual that you’d probably find you don’t need a full time job for it half the time and most are relatively easy to setup inside of a business quarter
• not everything is Facebook scale: unless you’re padding your resume why did some of these get adopted? How complicated does your app need to be? Did you really need to transpile JavaScript for it?
• unit tests were code to test your code that you’re going to have to functionally test anyways: you’re telling me that you have to write your code…twice? How the hell did this ever get justified to mangers? Why did the culture not evolve into literal automated smoke tests of the actual builds, instead of testing whether a function that is probably type annotated is going to fire anyways???
• docker/containers suck ass: great that they solved a problem but created a whole new one. we moved to python and JS which were JIT without artifacts and suddenly everything needs a generalized build system to run it. C lang variants and Rust lang compile to a binary you can just run… Ship the small ass binary not an entire container to run your shitty web app

You know the stuff I don’t hear about?

• Javascript and Python were steps in the evolution but never the end goal. I’d even say the same of java. There are new solutions but JavaScript in the browser especially should be replaced.
• eye appeal is buy appeal
• that eye appeal shouldn’t always mean you need to use a library or framework; vanilla apps work okay too.
• binaries/artifacts/installer packages > containers
• automated testing of the actual end product
• well written logging to the point someone can tell what the application was doing without seeing code
• using all these compsci algorithms to actually write new products and searches from scratch instead of being a framework baby: do you actually need ELK or Splunk for your search? Really?
• you probably don’t need MySQL for a lot of projects, I bet you an async library with sqlite would be the same for many of these projects.
• small teams with feature rich apps using SSR, the value of an SSR web app
• the value of a SPA
• the value of traditional desktop software and not using REST APIs

Thanks for weighing in. Yeah! This is basically what I am thinking I’ll have to do. I just tried Github actions and runners with a very small internal app and I liked it. I’ve never worked closely in AWS but I’ve gotten trained in/used Azure a few times and it’s basically the same thing on my end.

Robust tests, larger conditional workflows in github actions, and some sort of staggered rollout I think are the conclusion I’m arriving at.

Godspeed. I hope the transition goes well. If you need to baby step towards it, I felt like docker swarm was easier to approach but kubernetes is far more standard. I recommend budgeting training into the rollout if your shop can afford it. For CI/CD I recently had a great experience with github and github actions but I had a coworker setup on-premise gitlab in the past too.

Somewhat of a tangent - My experience with alembic of over four years is that it is leagues better than manual SQL dealings, and also very easy to understand what you’re looking at. But I have to say that when I used sequelize in NodeJS, it has an autosync and autoupgrade schema that made alembic look silly.

In regards to my own post I think for now what I’m mostly seeing is that for each new deployment - is going to have to have an internal smoke test, then staggered rollout of updates.

Reading what you wrote here - I think this is confirming my looming suspicion. Which is that there is no standard today for upgrading docker containers. Since upgrades happen app to app. For example if I have a docker-compose deployment and service A is lemmy, and service B is postgres the app in this case service A will have to have its own logic for handling upgrades or code migrations.

In other words, the upgrade process can depend on how the software developer writes the software; independent of docker/k8s/vm’s or whatever deployment strategy you are running.

I think what I was hoping for was that I’d ask if there was a newer smooth standardized way to do software upgrades besides A/B testing or staggered rollouts but I’m not really seeing that.

I’m not super familiar with Lemmy’s codebase but it looks like they’re using diesel ORM here and have migration handling on a case by case basis for some major changes. https://github.com/LemmyNet/lemmy/blob/main/src/code_migrations.rs**___****___****___**

Maybe try some of these - I found this awesome list in my research https://github.com/VPashkov/awesome-nim#gui

Thank you so much for posting. It’s really nice to hear from someone with experience first hand.

I have a lineage phone I keep on dial and I was using graphene OS for a minute but

The thing is that I live by my phone. Passwords, banking, pretty much the entirety of my actual life daily. I think graphene OS is great! But I also don’t have time or a the ability to have an AI review the codebase to validate that what I’m putting on my phone is safe. The truth is that these are unpaid strangers making a great product who’s work Im not a subject matter expert in. Android is a large codebase. I’m friends with a guy who works on it full time and even he feels lost sometimes. So I reversed my phone back to stock Android for my daily driver.

If I’m doing better financially in a few months I’ll likely buy another pixel phone or try fair phone with graphene. I just can’t justify the purchase right now and my phone works fine.

Just a reminder if you like these projects, donate to them!. I dropped about $1000 on open source stuff over the last year to include joplin, EFF, vueJS, graphene, lineage, and quasarJS. Every one of them does great work.