NAHWheatCracker

I have some Raspberry Pis that I self host stuff on. Gitlab on one, Runtipi on another, and pi-hole + Nginx + a game I made on a third. Some of it is publicly accessible on my own domains, but the only traffic I actually get is from myself.

I connect my Pis to my WiFi router and I've struggled with the adapters, so a POE switch might be interesting. I should containerize stuff, but I enjoy running it directly as well. I need to figure out backups some day.

The biggest issue I've had is that I've lost 3 SD cards in 6 years. Twice due to power failure, and once to heavy disk writes. I can't stand randomly losing stuff and having to re-setup a pi, so I switched to booting from USB SSDs. I haven't had an issue since. The cost is a bit obnoxious since I don't trust a cheap drives, but the perceived peace of mind is nice.

Has anyone else had this issues with losing SD cards while self hosting on Pis?

> “The income needed to comfortably afford a home is up 80% since 2020, while median income has risen 23% in that time,” the report states. That equates to $47,000 more than four years ago.

It's the second paragraph in the article.

My brother in law borrowed Oppenheimer on DVD from his local library for free. You might try that out if you want to save some bucks.

Microservices is probably their most popular video, but all their videos are genius.

I'm partial to I Have Delivered Value... But At What Cost? https://m.youtube.com/watch?v=DYvhC_RdIwQ

I guess it depends on your opinions of what's productive, but bitcoin mining is obvious.

How quickly does heat naturally increase in a house that's been cooled like that?

I've only lived in apartments, but I guess it gets back to equilibrium with outside temperature in a few hours once AC is turned off. I guess a couple hours of cheap cooling in the middle of the day might save an hour of expensive cooling later, if it's timed right. I'm interested if there have been any studies or maths to back it up and quantify the effectiveness.

Thanks, 2:51. Very clean UI for mobile. I'll bookmark and do a puzzle every morning with my wordles.

My most recent invoice from Jetbrains was $109. In the previous 4 years, it was $96. I have the 40% continuity discount since I first purchased a license in 2015. I have the "IntelliJ IDEA Ultimate" license, FWIW.

I don't see myself switching to another IDE. $109 is a drop in the bucket. I also use VSCode, mostly for non-code text editing. Relearning and configuring keybinds would be enough to keep me on Jetbrains unless they absolutely screw the pooch.

You might have a point, but if the frameworks didn't exist, couldn't employers commoditize around knowledge of the base HTML?

In my view, frameworks are the result of someone realizing that an abstraction is easier to work with. Just like we don't write in machine code or assembly code much anymore. This seems like a simpler explanation than a conspiracy by "employers" to commoditize software development.

FWIW, I moved away from bufio.Scanner and now I just do one os.ReadFile() call to get the whole thing as bytes and wrote a little function to break it into lines. I'm not using strings anymore and I eeked out a bit of performance for all three days.

I have been using bufio.Scanner.Text() for reading my input files, but I suppose most of what I've done could use bufio.Scanner.Bytes().

I'm not sure what you're suggesting, the input in Advent of Code is usually meant to be treated as ASCII text, so strings are quite natural.

I'm doing Advent on Discord with a former coworker this year.

This morning we compared the performance of his solution in Rust to my solution in Go. His was running 2-4x faster than mine but we couldn't figure out why and it seemed so straight forward that we assumed Rust was just that much faster.

I had assumed strings.Split would return sub-slices of the original string until I read this post. Sure enough, I rewrite it using strings.Index and manually creating sub-slices and now it's comparable, albeit less readable.

Looking at the standard library source doesn't make it clear to me why this even works. strings.Split is appending sub-slices of the input string to the return value. I don't understand where the allocations are coming from, but I'm just not knowledgeable enough about go slices.

I've been working on a game over the past year in Go using https://github.com/g3n/engine. I picked Go because I like the language and wanted to learn it. I picked g3n-engine because I wanted to work in 3d after making a few 2d games in the past.

Making games is so much more challenging and rewarding than almost all of the work I've done for pay. There's always so much more to learn that doesn't feel like just relearning how to do the same thing except with a different framework of the week.

Management that sees 3 options an picks the objectively worst outcome is absolutely the problem.

I'm not sure if you could ever see management as the problem.

> refactoring is something that comes with any new work. You don't have to justify it, but include it in your estimates.

Sometimes it's too much work to do ad hoc. Oftentimes people won't go out of their way to refactor. Having the fair discussion can make it real and important.

If the team can't talk about refactoring, it's an unhealthy team. Managers who want to act like maintenance of a project isn't something that should ever be their concern don't deserve a paycheck.

> But honestly, it is engineers job to find that hard to reach balance

This attitude is bullshit. It's everyone's job. High level balance is more of a concern for management. Low level balance is the more of a concern for engineers. High and low level balances can work for or against each other. Management that just pushes their responsibilities down the hierarchy aren't pulling their weight.

> When you’re having to pitch the work to someone, you’ve often already failed the pitch.

Damn that stings and it's so true.

> But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary

I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary.

Project managers are the ones that don't see this kind of work and it's benefits. They're the ones that I find it hard to build trust with.

I worked at a health insurance company 6 years ago where they brought in a group from Pivotal for a week and we worked with them to see how they ran a Scrum team.

I was amazed. The Scrum master wasn't just some busy body manager who only ran stand-ups, he was constantly floating around throughout the day helping people out. We had 4 developers and 4 consultants, so we mostly paired up and that was super productive. Pivotal tracker was better than Jira. They had a strong focus on getting something working and collaborating. It was eye-opening.

Unfortunately, the company was picking 4 random employee developers from across the organization each week. Most of the organization was contractors, including everyone on my team aside from me. My team used Jira and had no option to use something else. Back on my team, the contractor Scrum master and contractor product owner continued to run the team incredibly ineffectively.

I can't tell if those few consultants I worked with were representative of Pivotal as a whole, but I will say that that week was a bright spot in an otherwise dismal part of my career.

It's often not a matter of verbalizing if the decision makers don't want to believe what you're saying.

You have to be working with people who are more interested in finding the best outcome for the organization/team/people than the most convenient decision for personal or political reasons.

I've been quite frustrated that the term "technical debt" is so misused. It feels like project managers immediately assume technical debt means "the developer wants to play around". I only use it when it means "the features you want can't be implemented, correctly, and under the time constraints".

For what it's worth, I shy away from the term and talk more about approaches and outcomes. It's still baffling when I give a project manager the options:

1. Rewrite and have a working prototype in 2 weeks and solid product in two months. We will be able to use better tech, learn some new things, and the product will match the feature needs.

2. Refactor this month and get the feature you want in a couple months after that. We won't learn as much, but we'll have a cleaner technical product and we'll get some features.

3. Try to implement the feature now. It will be late, broken, and other features will break. We will spend all of next quarter patching it. We won't learn anything new. It will slow us down on the next feature.

It's always #3.

I've run into this at work and I handle by always add timedeltas in UTC or just design everything to work in UTC.

Unfortunately, some people dislike the former because it's 3 lines of code (convert to UTC, add delta, convert to local). I've had the same data scientist reject 3 MRs fixing this sort of issue in his code. At least it only causes a once per year error or a blip that no one notices.

Always using UTC doesn't work always depending on requirements. The worst was interacting with an API that required precisely every hour of the following day to be sent without good documentation.

Unfortunately, you're right and I don't really have anyone to turn to within the organization.

My manager was wrangled into this by the project manager. I explained the situation and his response was "I agree with you, but you have to do whatever the project manager says".

While that isn't word for word, I'm not paraphrasing.

In this case, I think the manager cares less about the success of the project and more about their own success.

Cynically, he made me the scapegoat for his unreasonable project plan and execution.

Less cynically, he knows he could find another engineer to pick it up next quarter. I'm not that critical.

I don't think being fired could every be construed as a pure win, but it has accelerated my plans of looking elsewhere.

I completely agree with you, except that I'm currently going through a situation.

The project manager has made a plan that a feature would be done by the end of the year. Two data scientists have been the only people working on it for the whole quarter. They said it's not going to be ready and they haven't even gotten it working on their local machines. The project manager turns to me and I concur with the data scientists. We had less than two weeks left when we talked, since everyone is taking time off for the holiday. I said I'm not going to work on it until it's ready and he's making out like I'm insubordinate and responsible. I honestly think I'm going to be fired.

It could be a good thing. Maybe I can work somewhere where this sort of thing isn't tolerated. I think a great many workplaces are like this though. Pushing back, even a bit, can paint a target.

I don't think they are expected to have technical merit, but Carmack at least has that going for him.

Damn this sounds similar to a project manager I'm working with, except he doesn't have any of the technical/engineering merit.

I've never been in an environment where Scrum was used to create real pressure.

I've been in environments where it creates fake pressure. Standups where you have to say something for fear that you'll be axed if you say nothing. Questions about whether a ticket is going to get done by Friday. I call these fake pressure because it becomes obvious that there is no teeth to them. People get away with doing nothing and making up a few sentences at standup. People say a ticket is going to be done, but it roles over through two or three sprints.

It's always been a sham for me. You can't point at the Agile Manifesto and say that we're focused on process over interactions. You can't point out that we need a Product Owner who is focused communicating the needs of real users. You can't point out that standups should be for the team's benefit and not status updates to project managers who are barely involved.

Still, I'm a firm believer that the Agile Manifesto makes some good points. I believe that there are elements of Scrum that are really beneficial if implement well. I believe all of it is subverted by management that wants a semblance of control/power. Most of the workers don't care whether it's subverted, they're just there to be paid while doing as little work as possible.

So, who's left to change it? A few righteous agitators? Who are they going to agitate? The managers who have control aren't going to give up the reins. The hoi polloi will ignore anything that takes extra effort.

Saying the scrum master needs to be accountable is true. Everyone should be accountable for something. However, there's simply no way for that to happen in many environments.

I've had scrum masters that were basically just required to gather status updates and report them back to the CTO. I've had contractor scrum masters that were hired because Scrum said they had to have that role but they ignored the part of Scrum that said there was a product owner role. I've had scrum masters that were just engineering managers who ignored their engineering manager roles to be the one who screen shared the Jira during standups, including one who was a Director of Engineering.

All of those scrum masters were installed by the people in power not to be held accountable for anything. Most of those scrum masters, like all the other workers, just want to get by with doing as little as possible while being paid.

I recently had an experience where a project manager was basically demanding a yes/no answer in what felt to me like a power move.

PM: Are we good to go live on Wednesday? (it's Monday)

Me: Feature X isn't fully ready yet. Data science needs to address a bug that I found 2 weeks ago. If they fix the bug, I'll prepare a release for Wednesday. Alternatively, we can go live without feature X.

PM: Feature X is required. Data science says they'll have the bug fix ready. So are we good to go live Wednesday?

Me: If data science implements the bug fix, I'll release on Wednesday. (I don't trust data science to be ready, but I'm not going to say that)

PM: Okay, so we're good to go live?

<two or three more cycles>

Context is very relevant. Yes/no questions often aren't yes/no. I didn't even include the full conversation where I tried to clarify what he means "go live" or whether the customer had signed off. In the end, customers hadn't signed off and he hadn't coordinated with other teams. The release has been put off for at least a month.

I think this is somewhat different than a yes/no informational question. In this case, it wasn't even a yes/no question, it was a yes/yes question, he wanted me to take responsibility.

I agree that a lot of engineers would be put off if they had to do this.

The problem I see is managers - project, product, and engineering - who think engineers shouldn't be doing this stuff. Whether the engineers are product-minded isn't considered. Sometimes a PM sees the engineer interacting with users as a sort of intrusion on their domain. Other times an EM thinks they're saving cycles by keeping engineers away from the "non-productive" work of interacting with users.