I recommend you get off Authy - they don't have a browser extension or a desktop client, and surprise they don't have a way to export your codes either. I had to send them a GDPR data request, and then Claude decrypted the csv file they sent. I now use Ente and it's so nice having 2fa inside a browser extension. I can also export the secrets at will.
Keepass is also a good alternative to Authy, caveat being you need some way to sync the db file between devices.
I personally use Keepass for 2FA, Bitwarden for passwords. It's worked great for me so far, and I expect to stay with this setup for the foreseeable future.
Claude will refuse to visit sites with robots.txt, make a graphic spoof of an iOS game, or even fill out an employee survey on my behalf. ChatGPT is always happy to oblige, no questions asked.
I can respect the guardrails - I also can see why OpenAI may not have much control over their models - but I need an AI who will do whatever I ask and not play judge and jury.
I was surprised to find that Barnes n Nobles has a decent selection of quality toys for infants to toddlers. Toys have their own section at my store. I used to buy toy/book gifts at Target but the options are so much more limited.
We have post-its with file names on a wall in the office. You take one down if you edit the file, and put it back up when you're done. Easy.
Though I wish I was entirely kidding. ~12 years ago or so we did that if one of two parallel development teams had to modify a message of the network protocol to avoid incompatibilities and merge problems.
Mind you, these were SVN merges. I can't even verbalize my feelings about SVN merges but by a mixture of laughing and groaning in pain, like if you stubbed your toe in a painful, but entirely funny way.
What is this eternal meme about merges in svn being harder than in other tools? Git used literally the same merge algorithm, even if that has changed a bit since then, and merge conflicts are not something a tool can't just magically make disappear. If you want concurrent edits (the c in cvs), conflicts come in the same package. Various algortihms can supply their own dose of magic, but they're more similar than different (minus a few special cases such as rerere in git).
My interpretation within that company: You know this new idea of "If it's painful, do it more"? People in that company didn't do that in the SVN days or earlier, because merges were painful. Thus, merges filled a sprint if they had to be done. This made sense if you came from CSV or nothing, tbh.
Git in turn made branches easier, causing merges to be more prevalent and developers overall learned to merge more, merge more often.
That doesn't make any sense to me. Why would you merge more often if it takes less time to create a new branch?
What types of merges are we talking about? Surely it must be where you merge in changes from a main branch to your local branch, which in the case of long-lived branches will be the more common merge. Creating new branches isn't even part of that workflow.
Keeping it when tech can't keep up is genuinely a good hack for any kind of engineering. Physical lock out tag out on industrial machines for instance. Passing paper notes/wooden blocks in air traffic control towers to see who's responsible for what even if computers go down.
You joke, but when I was doing my start-up we made good money on the side from monitoring websites to detect when the designers had pushed regressions to the live site. We would keep track of change requests that were filed and resolved, then scripts would monitor the sites to see if any earlier changes had been backed out. (Getting the designers to use version control was considered to be in the "too hard" bucket. This was back in the mid 2000s.)
That's a single point of failure. If you email code changes around and use an email client that copies everything offline, then the history of your code base is distributed across all of your developers' laptops.
Yea this! How many devs say "it doesn't do what i expect" did not try to write up a plan of action before it just YOLO'd some new features? We have to learn to use this new tool, but how to do that is still changing all the time.
There's a huge caveat i don't see often, which is that it depends on your language for programming. IE. AI is reallllly good at writing Next.js/Typescript apps, but not so much Ruby on Rails. YMMV
I agree with this. People who are writing Python, Javascript, or Typescript tell me that they get great results. I've had good results using LLMs to flesh out complex SQL queries, but when I write Elixir code, what I get out of the LLM often doesn't even compile even when given function and type specs in the prompt. As the writer says, maybe I should be using an agent, but I'd rather understand the limits of the lower-level tools before adding other layers that I may not have access to.
My hunch is that to exploit LLMs one should lean on data driven code more. LLMs seem to have a very easy time to generate data literals. Then it's far less of an issue to write in a niche language.
Not familiar with Elixir but I assume it's really good at expressing data driven code, since it's functional and has pattern matching.
I think for some languages like Clojure and Elixir, it's just so easy to get to the level of abstraction you need to write your business logic that everyone does so. So the code does not have any commonalty with each other. Even when using the same framework/library.
But for Python, JS, etc,... it's the same down to earth abstraction that everyone is dealing with, like the same open a file, parse a csv, connect to the database patterns.
Everyone posting should be considerate of your language/stack. It's pretty likely that Cursor doesn't work equally for every language. I'm working on a Next.js/Typescript/Solidity monorepo with multiple apps and packages and it handles pretty much anything I throw at it. I know I can squeeze more out because I have only been really using it heavily for the past month or so.
reply