daviesgeek

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 )

Ok I’ll check it out!

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 do wish they’d add better support for the mac with a key. I know it’s a little separate, but I’d really like to lock down my max with my yubikey(s).

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)

+1 for notion

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’d love to see this be able to handle larger blocks of code. I have a particularly bad poorly bit of code I’d love to print out and keep around XD

I really wish that you guys would open up remote positions! I would absolutely love working for you guys, but can't/won't make the commute

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.

Thanks, that's really helpful. I'll check out the links you sent!

This was a really fascinating read. Enjoyed it thoroughly

I agree. I’d love to read an article about this!

All fair points and totally valid.

My concern is the facade/promise of type security.

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)

I would also recommend Hugo as well. I just switched over to it from Jekyll and it's really quite nice. It takes a little bit to get used to the theme structure, but once you have it down, it's pretty easy to keep track of.

Disqus is also a great way to have comments on a static blog. I use Disqus and haven't really had any issues at all with it.

I'm about a month in to Bullet Journaling and I'm really liking it for a number of reasons.

First, it's a piece of paper that's always there. No waiting for apps to load, no Internet lag time; it's always there.

Secondly, I can organize as I choose. I like note taking apps for desktop/mobile, but the hardest thing for me is being able to organize and write notes as I chose, not as the program dictates. If I decide I don' like a certain way of organization, nothing's stopping me from changing it.

Thirdly, I've seen a huge increase in completion of tasks, since they actually get written down somewhere! I used to use reminders on my phone, but unless I set a notification (a reminder for the reminder?), it got neglected and never finished. Also, I could never get myself into the habit of checking my reminders list every day. I'm sure that reminders or other to-do list apps work very well for other people, but for me personally, I never found the to-do list apps to work very well.

As for migration, I think it's actually been really useful for my workflow. I'm the type of person who doesn't like to see outstanding tasks, so my goal for every day is to not migrate tasks. Also, migration keeps all those tasks fresh in your mind, which I've found to be very helpful.

All that said, I'll have to see what I think about it in a few months and whether my perspective on it has changed.

I would love feedback and PRs from anyone willing to take a look at this! It's based on Restangular (https://github.com/mgonto/restangular), just without the Angular part and I changed a lot of the things I didn't like about the way Restangular works.