Haha yeah. People are so accustomed to short TLDs that ‘smith.technology’ just intuitively feels kinda wrong, and it still feels that way to me, even as a tech person who knows it is perfectly valid.

You’re thinking like “smith dot technology dot what?”

Another reason is brand identity.

Using ‘.tech’ or ‘.flights’ or .sports’ for your site feels too “on the nose” and gives vibes of like browsing some directory where things are categorised and sorted. Even worse it implies there are other sites under the same category, and those other sites may be competitors, and this dilutes strength of brand.

lt also suggests strongly what the business does, and while that might seem desirable at first it actually isn’t from a corporate perspective because it means the company becomes tied to their business area and can’t expand and grow out of it into other things.

I think this is a major part of why descriptive TLDs continue to be less preferred over ‘meaningless’ two letter TLDs, because companies want the focus to be on the main part of the domain, not the TLD.

Thanks. I’ve been keeping my eye on colour ereaders, and the tech has improved so rapidly in the last couple of years I do wonder if I just hang on for another year then the colour reproduction could be even better.

Can’t wait forever of course, that defeats the whole purpose, but it might pay to wait just a little.

I’ve had two kindles so far, but my next e-reader won’t be from Amazon.

I’m trying to move my tech life away from closed ecosystems as much as possible, So I’ll probably go for a kobo or boox.

For me the dream would be a really large colour ereader around 10 inches, where you can view even the densest manga or comics comfortably without zooming or scrolling. I think that’s what I’m holding out for.

UK here and they are turned on.

Thanks a lot, Brexit :(

I had so many good times on forums back in the day.

The personal nature of them was great for being social and making friends, but it was also good for the quality of the content for and user behaviour too.

When everyone recognises you and remembers your past behaviour, people put effort into creating a good reputation for themselves and making quality posts. It’s like living in a small village versus living in a city.

The thought of being banned back then genuinely filled people with dread, because even if you could evade it (which many people couldn’t as VPNs were barely a thing) you’d lose your whole post history and personal connection with people, and users did cherish those things.

The worrying truth is that we are all going to be subject to these sorts of false correlations and biases and there will be very little we can do about it.

You go to buy car insurance, and find that your premium has gone up 200% for no reason. Why? Because the AI said so. Maybe soneone with your name was in a crash. Maybe you parked overnight at the same GPS location where an accident happened. Who knows what data actually underlies that decision or how it was made, but it was. And even the insurance company themselves doesn’t know how it ended up that way.

If a tree falls in the woods…

That’s the strategy, yes

“I think the existing, altruistic, free version of Reddit will continue to exist and grow and thrive just the way it has,” Huffman said.

There’s nothing ‘altruistic’ about reddit

Haha yep. Not the support process you want. Glad you managed to let them eat some humble pie at least.

The support process you want is this: “We’ll make you a channel on our Slack, if you’ve got any issues you can talk with our devs direct!” - yes please!

Any company that hides their documentation has an awful product that they are actually embarrassed about, from a tech perspective. They are hiding it because they are afraid to show it.

I’ve seen this so many times, and it’s a big red flag.

These companies work on the basis of selling their product the old-fashioned way, directly to management with sales-people and business presentations and firm handshakes, and then once you’re sold then developers (which management doesn’t care about by the way) have to do the odious task of getting everything working against their terrible and illogical API. And when you need help implementing, then your single point of contact is one grumpy-ass old dev working in a basement somewhere (because they don’t care about their own devs either) and he’s terribly overstretched due to the number of other customers he’s also trying to help, because their implementation is so shitty.

Conversely, public documentation is a great sign that companies took a developer-led approach to designing their solution, that it will be easy to implement, that they respect the devs within their own company, and they will also respect yours.

When I am asked to evaluate potential solutions for a problem, Public docs is like the number one thing I care about! It’s just that significant.

Side story - I once worked with one of these shitty vendors, and learned from a tech guy I’d made friends with that the whole company was basically out of office on a company-paid beach holiday - EXCEPT for the dev team. Management, sales, marketing, finance, they all got a company trip, but the tech peeps had to stay at home. Tells you everything you need to know about their management attitude towards tech.

You’re right of course and that should be on Microsoft to better implement their driver loading. But yes.

If I send you on stage at the Olympic Games opening ceremony with a sealed envelope

And I say “This contains your script, just open it and read it”

And then when you open it, the script is blank

You’re gonna freak out

You, SubjectNameHere, must be the pride of SubjectHometownHere

It’s good practice to run the deployment pipeline on a different server from the application host(s) so that the deployment instances can be kept private, unlike the public app hosts, and therefore can be better protected from external bad actors. It is also good practice because this separation of concerns means the deployment pipeline survives even if the app servers need to be torn down and reprovisioned.

Of course you will need some kind of agent running on the app servers to be able to receive the files, but that might be as simple as an SSH session for file transfer.

Yes, exactly that.

That’s probably okay! =) There’s some level of pragmatism, depending on the sort of project you’re working on.

If it’s a big app with lots of users, you should use automation because it helps reliability.

If there are lots of developers, you should use automation because it helps keep everyone organised and avoids human mistakes.

But if it’s a small thing with a few devs, or especially a personal project, it might be easier to do without :)

Sure, but having a hands-off pipeline for it which runs automatically is where the value is at.

Means that there’s predictability and control in what is being done, and once the pipeline is built it’s as easy as a single button press to release.

How many times when doing it manually have you been like “Oh shit, I just FTPd the WRONG STUFF up to production!” - I know I have. Or even worse you do that and don’t notice you did it.

Automation takes a lot of the risk out.

I’m sure there’s nothing wrong with the program at all =)

Modern webapp deployment approach is typically to have an automated continuous build and deployment pipeline triggered from source control, which deploys into a staging environment for testing, and then promotes the same precise tested artifacts to production. Probably all in the cloud too.

Compared to that, manually FTPing the files up to the server seems ridiculously antiquated, to the extent that newbies in the biz can’t even believe we ever did it that way. But it’s genuinely what we were all doing not so long ago.