A coworker told me about this today and I genuinely thought he was just messing around, but nope, this is real I guess.
Copilot is SUCH an overloaded term, I have no idea even what it refers to anymore.
You'd be surprised at how many people don't have skills of reasoning ;P. AI is putting that at everyone's fingertips, whether they're capable of using it or not. Look at the whole of the internet, just because everyone has information, it doesn't mean everyone's smart now.
This is great. I’m gonna try it out but just looking at screenshots, this was really close to something I was going to try building not that long ago. I’m glad someone else did because I didn’t/don’t have the time right now (and don’t need another project for my ADD brain to hyper focus on )
You can but it’s key + pin OR password, not key + pin + password. I’ve tried a bunch of different setup configurations and can’t get it to work as a true 2FA like it should.
I did get it set up correctly at some point but an OS upgrade wiped the settings. I’ll have to try it again, but the path for setup isn’t as easy as it seems.
I couldn’t disagree more for service and infrastructure names.
> And I think this applies more broadly to projects and companies, too.
Customer facing names are fine, they should contain a bit of whimsy and cuteness. Obviously if you ship “payment-processor-gateway-v2” to the customer, that’s not a great name for a company, product, or feature. Projects also make sense (mostly), though they suffer from some of the same issues I’m about to outline.
However, for internal names like for services, adding cuteness is a horrible idea.
> A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing.
Descriptive names should help box in the scope of the service. If the payment processing service is also doing AI processing on user avatars, you might want to think about breaking that out into a separate service. With cute names, scope can grow infinitely because there’s no inherent description attached to the name. You may have “Athena” doing one thing but as things progress and the company/software grows, it’ll be taking on 17 other responsibilities. Instead if it’s named “backend” or “payment processor”, it’s clear in the name what it is and the scope of the project or service.
Then there’s the problem of an engineer’s mental overhead. Newcomers have to learn what all the cute whimsical names mean. You have to keep an internal dictionary and someone has to make sure it stays up to date. (Spoiler: It won’t ever be up to date.) I could have filled at least two pages with all the acronyms and whimsical names from one of my old jobs and it was always an ever changing landscape. If a service is named succinctly and clearly, the engineer doesn’t ever have to think about what that particular service is or does. I understand there’s going to be some edge cases where the name doesn’t cover everything, but that’s certainly better than the case where the name doesn’t cover any of the description of the service.
> It's impossible to predict with certainty how your software's requirements will evolve over time.
Then within the scope of the new requirements, changing the service’s name should be inherent in the discussion. IMO, this is a sign of some bad engineering processes. One shouldn’t be worrying about names in the future if you’ve named something correctly for the current scope. If it changes, address it then. Most modern languages will let you easily refactor a name. By those standards, you shouldn’t build the software, since it might change over time and we don’t want to make assumptions about whether we’ll still be using Mongo or if MYSQL makes a comeback. We can’t make those decisions because we can’t predict with certainty…you see the trap you can easily so easily fall into?
One thing that’s also a huge challenge is pronunciation. Someone will pronounce one of those cute names in a way that no one else has heard, it’ll take a minute to sort out, and, while it did get sorted, it took some time. Multiply that out over weeks, months, and years for every engineer and it can get costly. I understand that descriptive names can also be mispronounced, but since they’re common (to our industry), it’s easier to sort out.
I definitely do understand the sentiment behind adding some fun. I’m not here to kill the fun atmosphere of a new startup who wants to be cute about their names, but I’ve seen it play out very poorly over a long time when the company/projects/services/team grows and it’s not pretty.
Stick with descriptive names. You and everyone else will remember them easier and you’ll save time, giving you the time to go have some fun and grab a couple drinks with coworkers.
(I also published this here: https://memos.daviesgeek.com/m/4 for a little better formatting and to keep this comment around for myself)
So far I love the M1 for day to day dev. The biggest issue I’ve had is support for older software that never was compiled for M1. For instance, I have a contract right now with a company that uses a very old version of Postgres + PostGIS that I literally can’t build on an M1.
Besides that, I love the M1 laptops, the battery life and performance to cost ratio
I just got this as well. I’m appalled at the complete lack of thought put into this. I’ve had numerous emails & push notifications telling me I’m over my data cap; I don’t need injected content into my page in addition.
Definitely agree on the first, that's a good point. I probably should've been better about how I presented the data.
"TypeScript still compiles down to JavaScript. It has no way of actually checking types." That's my point. Maybe I should make it more obvious in the article :) I'm not complaining about the fact that TS has classes or types, it's that TS compiles down to a language that has neither.
I'd like to also point out that my main issue (that JS itself doesn't have types, so it's impossible for TS to 100% enforce it) still stands even after a year.
I wish I had the actual code since it was pretty fun to write and break the compiler but it was too long ago. I am still gonna see if I can figure it out again.
I think I was pretty clear that it was all just my opinion :) If you read the end of the post I said that maybe I'm just worrying over something that's a non-issue, so by all means, steer me in the right direction rather than critiquing the fact that I'm expressing my opinions ;)
I would love to see this work better on mobile. I'm not sure if it's just not working due to the rate limiting but it's not really working for me (Safari, iPhone 6, iOS 10)