[–] 30 points 2 weeks ago* (3 children)

There's a old joke about this from Jack Parr, told on the Tonight Show:

An English lady, while visiting Germany, was looking for a room to rent. She found a suitable one owned by a local schoolmaster. After returning home, she remembered she hadn’t seen a "W.C." (water closet/bathroom) on the property. She wrote a letter to the schoolmaster asking where the W.C. was located.

The schoolmaster, not knowing much English, was puzzled by the initials "W.C." He took the letter to the parish priest, and together they concluded that the lady must be asking about the local Wayside Chapel.

The schoolmaster wrote the following reply:

Dear Madam,

I take great pleasure in informing you that the W.C. is situated nine miles from the house, in the center of a beautiful grove of pine trees. It is capable of holding 250 people and is open to the public on Sundays and Thursdays.

As a large crowd is expected during the summer months, I advise you to arrive early. This may prove an unfortunate inconvenience to you if you are in the habit of going regularly. Rest assured, however, that there is plenty of standing room.

Many people bring their lunch and make a day of it, while others arrive at the last minute and can only find standing room. A special feature is the organ music, which accompanies all proceedings. The acoustics are excellent, and even the most delicate sounds can be heard by everyone.

It may also interest you to know that my daughter was married in the W.C., as it was there that she met her husband. I can still remember the rush for seats. There were ten people in every seat that day!

My wife is very delicate, so she cannot go regularly. It has been over six months since she last went, which is naturally a great trial for her.

I shall be delighted to reserve the best seat for you, where you can be seen by everyone.

Yours faithfully,

The Schoolmaster

  • source
  • [–] 1 point 2 weeks ago (1 child)

    I'm not sure. The price of oil is the price of oil...except that Canada sells its oil to the USA at a discount because where else can we sell it.

    The fact that Canada sends almost all of our oil to the USA means that the USA buys less at the normal world price from other sources. This increases supply in the world market. If Canada shifts its sales to the world market, then the USA has to buy more from that world market at the higher price also balancing out the supply/demand on the world market.

    Net result would be that the USA will have to pay more for Canadian oil, because why would we sell it to them at a discount if we can sell it on the world market at the full price. This just means that we get more money for the same production.

    All that assumes that production stays the same. If that holds true then the net environmental impact is relatively neutral except for the pipeline itself.

    If the pipeline allows production to increase, then there's obviously a potential for greater environmental impact, although it's not really clear that greater supply would mean greater demand. But the Canadian oil is dirty to extract no that's bad.

    However, any amount of excess pipeline capacity away from the USA is a win for Canada economically and politically, as far as I'm concerned.

    If Brent crude drops below $40/barrel, that would probably mean that demand had dropped so much that the days of burning oil are coming to a close. I'm not going to complain about that.

  • source
  • parent
  • context
  • [–] 2 points 2 weeks ago

    Hard and fast rules are for beginner, but their code is going to be crap anyway.

    For everyone else, comments when it makes the most sense is all you need.

    I will say that following a few simple principles, when appropriate, like "Don't Repeat Yourself", and the "Single Responsibility Principle" tend to lead to smaller methods with clear intent that give better opportunities to name things appropriately.

    If I see well laid out code with one or two comments, I'm likely to actually read the comments. Otherwise I view comments as meaningless noise.

  • source
  • parent
  • context
  • [–] 1 point 2 weeks ago

    Comments are by definition not part of the code.

    And no, I never trust the author - even if it was me 6 months ago.

    Not to mention all the other programmers that might have fiddled with it. Not mention changes in the code since it was written, where the comments weren't updated.

    As a maintenance programmer with 35 years experience, the first thing I do is delete the comments. My experience says they get in the way and can't be trusted. Read the code, understand the code, and figure why it's doing what it's doing. Don't worry about what it might have been doing 10 revisions ago when the comments were last updated.

  • source
  • parent
  • context
  • [–] 2 points 2 weeks ago (2 children)

    What's the alternative? Write an inline sort routine 30 times?

    I'm not so sure the example is particularly good. Assuming the sort is just a one line call to a library routine, then the comment would be unnecessary. You call the API, then you sort the results and it should be obvious to any maintenance programmer why. Don't comment obvious stuff.

    If you are doing this 30 times, then put the API call and the sort in a subroutine called callApiAndSort().

    The suggestion was that a comment be used when the reason for the sort was not obvious. Not that every sort be commented to explain why. So there's no reason why you'd wrap every sort call in a custom subroutine either.

  • source
  • parent
  • context
  • [–] 0 points 3 weeks ago

    First of all, most of the cost of a system comes from maintenance after implementation. So the idea that "an engineer can read it 40% faster" isn't as trivial as you make it sound.

    Secondly, well laid out code that doesn't need to be commented is generally simpler to write, easier to test and easier for the original developer to conceptualize when he's writing it. I've seen lots of programmers get lost in the complexities of their own approach because they don't organize their code properly.

    Finally, my understanding is that modern compilers optimize lots of things automatically, probably better than an engineer would and on all of the code. Write your code for the human to read it, let the compiler do its thing, and optimize by hand only that tiny percentage of code that causes performance issues.

  • source
  • parent
  • context
  • New Articles Dump! (www.pragmaticcoding.ca)
     

    First off, I any of you have been waiting for me to get around to publishing parts 2 & 3 of my SnapCast series, I apologize for the delay. I've finally got my homelab to a state where I can start transitioning my wife over from some of the cloud services we've been using to my self-hosted alternatives. The final push on that was to get backups working properly. Anyways, time just disappeared on me.

    So here's those two articles:

    Part II

    Part III

    I've had a whole bunch of infrastructure type articles in progress for months now. I finally took the time to wrap a bunch of them up. Part of the issue is that so much of the content is inter-related that it feels wrong to publish a single article when a whole bunch of the information depends on understanding some other concept that is covered in a different article that hasn't been completed yet.

    What am I trying to accomplish here?

    As someone who has always considered himself primarily a programmer, I've also had to be "The IT Guy" for decades, and also "The Unix Guy". This meant that I ended up with a lot of practical experience with networking and data centre configuration and planning. I was in charge of configuring the rulebase on a CheckPoint FW1 firewall before some of you were born.

    At the same, I never really wanted to do this stuff, but somebody had to, and it had to be done right. But it was all "hands-on", and I would have killed myself before I'd go through the misery of getting something like a Cisco certification.

    On top of that, as a programmer I was quite a bit more involved with the business of the company than any of the networking guys we eventually ended hiring. This meant that my role morphed into being the guy that could help the network techies understand how their plumbing was going to be used by the business.

    I look at what it takes me to build a homelab, and I realize just how much I lean on the things I learned over decades of being "The IT Guy", and I wonder how hard it must be for people without that kind of a background.

    I've read through much of the FUTO article, and i can only think that even that is a hard slog for non-technical beginners. I thought that if I could share some of the things that I've learned about putting together a homelab over the past year or so, while trying to explain the underlying concepts involved, then it might help someone...and it keeps me busy and off the streets.

    Back to the article dump...

    Next is an article about DNS servers and, specifically, Technitium.

    Going hand-in-hand with that, is an article about how You Need a Public Domain.

    Finally, an article I've been sitting on forever that talks about the Lenovo M910Q Servers that I have been using in my Proxmox cluster.

    In case you're interested, I'm also working on articles about systemd, a Proxmox introduction, resilency and recovery, network security, accessing services, VPN integration and linux basics.

    As always, I'm interested in any feedback you may have, including stuff I got wrong or missed out, and whether there's any content you'd like to see. Thx.

    submitted 4 months ago* (last edited 4 months ago) by to c/selfhosted@lemmy.world
     

    For the past few years I’ve been building and maintaining website/blog at www.pragmaticcoding.ca. It has mostly about programming, and more specifically it’s ended up having a lot of content about JavaFX with Kotlin.

    Lately, I’ve been spending all of my time building out my own homelab and self-hosting the services that I need. I’ve got a little stack of M910Q’s running in a Proxmox cluster with an HP T740 running OPNSense.

    One of my big successes so far has been to replace my Google Home devices streaming music all over the house with a SnapCast network using RaspberryPi Zeros as the streaming clients. I've been working on documenting how to do this, and the result is a three part series that explains what SnapCast is, how it works and how to combine it with Mopidy to stream music around the house.

    I have to admit that this one got away from me. It was all one article until I noticed that Jekyll was estimating it at oven 1/2 hour to read, which is way, way too long. So it became three parts, which also gives me the opportunity to release it over time, and make sure that each part is nice and clean before I post it live. Part I is an introduction to SnapCast and explains how it works and how to set up a SnapCast server in Proxmox.

    If you're interested, take a read and let me know what you think.

     

    For the past few years I've been building and maintaining website/blog at www.pragmaticcoding.ca. It's mostly about programming, and more specifically it's ended up having a lot of content about JavaFX with Kotlin.

    Lately, I've been spending all of my time building out my own homelab and self-hosting the services that I need. I've got a little stack of M910Q's running in a Proxmox cluster with an HP T740 running OPNSense.

    Since I've been spending all - and I do mean all - of my time futzing about with this self-hosted stuff, I thought I'd try to add some content to my website to help people doing the same thing. My idea was to make it more "bloggish", talking about the tricky things I've had to master along the way as I implement various services.

    But I feel like there also needs to be some foundational content. Articles that explain concepts that a lot of people, especially people without professional networking experience, find difficult to grasp. So I've started working on those.

    While I think of myself as mostly a programmer, my career (now, thankfully over) had me as an "IT Guy" more often than not. I spent 24 years at the same mid-sized company with a tiny IT department and simply had to get involved with infrastructure stuff because there was nobody else to do it. It was very hands-on at first, but as we grew I was able be limit my involvement to planning and technical strategy.

    Since the mid 90's, we went from self-hosted physical servers, to colocated servers, to colocated virtual servers to cloud servers and services. So I feel like I have the insight to provide help.

    Anyways, this is the first article in this new section. I've seen a lot of people posting questions about how VLAN's work and I know that it's mystifying to many. So I wanted to push it out before I have the supporting framework put together on the website, and it's just sitting there as the first post that's not about programming.

    My goal is to provide practical, pragmatic advice. I'm not particularly worried if some particular facet of an article isn't 100% totally correct on some obscure technical level...as long as the article gives solid practical advice that readers can act on.

    Anyways, take a look and let me know if you think this kind of article might me of use to yourself or other people getting started on self-hosting.

    New Game: Letterage (thelemmy.club)
     

    A friend of mine has come up with a new on-line word game that seems to me to be pretty fun. I'll give the you the description from the announcement he sent out a few days ago:


    You start with a set of 7 letters. Make a word, ideally using some letters more than once. That’s how you score big: for example, COFFEE is worth 8 points, TEAMMATE is 12, but DONUT is just 5.

    The letters you play will be replaced with new ones from today’s predetermined sequence, until it runs out. Here is a short video.

    Your goal is to squeeze the highest score you can out of today’s challenge. You can also play it again, making different choices, to beat your earlier score.

    It’s free, fresh every day, and just enough of a mental workout to leave you smiling (or muttering about that one word you should have seen).


    I know, from the discussions that we've had as he was developing it, that he has spent a huge amount of time working on the algorithms to ensure that the letter sets that loaded up each day have a maximum amount of playability.

    The game runs in two modes: one with a short list of 30 letters, and one with the "regular' list of 60 letters. Personally, I find the shorter game a good fit for my attention span. If you didn't pick up on it from the description, the letter lists are updated each day, so you get two games a day, one short and one long.

    I think it's worth a try.

    https://letteragegame.com/

     

    I wanted one of these back in 1980 when I was 16. I remember that they were $1,200, but they might as well have been $1,200,000 as far as I was concerned.

    Many years later I had the $$$ to buy one, and this one is a beauty. Koa, with Bill Lawrence pickups.

    Look at all the knobs and switches!!!

    view more: next ›