I also like their products very much. I installed a few of them in my sockets. Some people argue that it's not safe to put in your sockets walls and the 16A limit is realistically lower before they can overheat and cause fire. That scared me a little bit but I think most of the reports are from bad wiring like using thin wires or not tightening the clamps enough
I have a Shelly pro 1PM in my Breaker box for the car charger. It gets to 80 degrees Celsius easily at 16A. I have two other gripes with it:
1: the slots/clamps are small which makes fitting 4mm2 wires a chore already. 6mm3 is impossible.
2: the overcurrent protection is very trigger happy. Due to solar panels in the street that voltage can vary significantly. Apparently the charger doesn’t always keep up exactly resulting in a current of 16.0001A which is more than the limit of 16 and poof, off it goes. Not sure whether this is an actual fault in the charger or some rounding error.
One thing to check out: ruby-lsp gets around this by using a custom gemfile, which enhances the project with the lsp's dependencies. That means you can use the gem, with bundler, without adding anything to the "official" project gemfile.
You could probably accomplish something similar, and possibly inject some rack middleware to add the view, or even mount it as a rails engine.
> NOTE: starting with v0.7.0, it is no longer recommended to add the ruby-lsp to the bundle. The gem will generate a custom bundle in .ruby-lsp/Gemfile which is used to identify the versions of dependencies that should be used for the application (e.g.: the correct RuboCop version).
After watching your (very enjoyable) talk in the other thread, schacon, one thing struck me - there _is_ a way to work on multiple branches at the same time: worktrees.
What's the advantage of a tool like this over that?
It's a good question, I was just working on a blog post - both because worktrees are very cool and also because I think we have a nice alternative to a similar issue.
With worktrees you can have different branches in different working directories and work on them at the same time. But practically, there is very little difference to just cloning the repo twice and working on different branches in the two checkouts.
The way we're doing it, the branches are both in the same working directory at the same time.
This can have a couple of advantages - one is if you have an annoying bugfix and you need it in order to keep working on your feature, you can have them both applied but you don't have to commit one into the history of the other. You cannot do this with worktrees.
Another is trying out multiple branches together. If they don't conflict, you can essentially get the result of a multi-way merge without creating any merge artifacts. Say you merge three work in progress branches to test them together, then keep working on each independently. Also, in this case, you _know_ that you can merge them in any order and the result will work because you've actually worked on the merged tree.
> With worktrees you can have different branches in different working directories and work on them at the same time. But practically, there is very little difference to just cloning the repo twice and working on different branches in the two checkouts.
With clones you have to fetch everything N times. You have to gc everything N times. You have to do `git config --local` N times if the config matters/affects all clones. If you need a local branch in two clones you need to synch. between them. The repository needs to be managed, which means that every clone needs to be managed. With a worktree there is nothing extra to manage.
And when you’re done you remove it via the subcommand and it’s gone.
Reminded me of a product called Rational ClearCase:
> It uses the MultiVersion File System (MVFS) which is a virtual file system that displays specific versions of data stored. In particular, it supports dynamic views which can show an arbitrary combination of local and remote files
Yeah, this sounds very much like a 'view' in clearcase.
It's a good feature especially with big monorepos where it is helpful to pick and choose a known good version of specific module or subset of files without polluting the history.
Tracking good versions of every single file with huge number of files changing was a pain though.
I haven't used ClearCase, but from the description, I don't think it's much like a view. It's closer to IntelliJ's changelists, but without many of the limitations.
It's effectively a way to take changes you're making and pretend like you did them in worktrees without having to switch back and forth.
Or maybe, to work on several branches, achieve the merged state you want, then split the work up into reviewable branches that can be merged in any order to achieve that final state.
Typical use case for worktree(s) is to work on feature/hotfix branch without touching the current master/wip branch.
So, in the context of worktrees I read _"The way we're doing it, the branches are both in the same working directory at the same time"_ as having both the branch's files (not changes) available in the same worktree.
Thanks for clarifying that it is similar to changelists.
Don't worktrees require more work to actually run your code because of multiple working directories?
If you're using an IDE, you'll probably need to create a project for each working directory. Or maybe you can change the path within the IDE's project.
If you're running a local web server, it will need to be configured for each working directory, again either multiple instances or one where you keep updating the path.
For compiled languages, the builds will take longer. When you create a new worktree, you may have to do a full build. Even if you have incremental builds, as you pull in upstream changes, you'll have to do N incremental builds instead of 1 incremental build.
It's not the end of the world, but it's a bit of hassle and extra computation that isn't needed with just one working copy.
Maybe I don't understand how gitbutler works, but the main reason I use worktrees is actually to keep my IDE and incremental builds getting confused when I switch branches, on branches that have lots of differences. It works really well, and I can fix stuff on old versions of our app in a jiffy.
I wouldn't use gitbutler for what I use worktrees, and I wouldn't use worktrees for what I think gitbutler is aiming at.
Since we write out our virtual branch artifacts into refs/gitbutler/X, you could actually pretty easily setup worktrees from each of them to do this type of work on. Perhaps setup a post-commit hook to update any active worktrees automatically too. Might be an interesting way to effectively work on several worktrees from a single working directory.
Yet another front-end I think needs it. I am looking at both Sublime and JetBrains because I use both. Notepad from Windows by Microsoft will support Neovim before both at this point (I was shocked to find that it supports tabs, and lets me keep unsaved files open just like ST).
I used to do professional rigging - if there's a human on the equipment, we'd commonly use a safety factor of 8 when choosing ropes/span sets. So... 800% more than calculated values.
Thank you for your comment. I love learning this kind of thing. When did you decide to replace supplies like that? For example, was it when you saw visible wear and tear or was it after a certain number of uses?
salary covers 40 hours a week, if I'm competently doing my job and you want to dictate what I do the other 16 hours a day you better be paying me for it – the notion that a salary covers this is complete nonsense
People undoubtedly have different hours and schedules... but the point still stands: if you want to dictate what I use my time for despite my otherwise competent work then you should have to pay me for it. Non-competes don't even stand up in this regard.
I believe op is referring to the deal between the copyright holder and the public - the public grants exclusive use of the content to encourage creativity, in exchange, the work will eventually become public. In extending the duration a work is protected, the deal is being modified.
Sounds like Mike found a good feature that would encourage companies to purchase a license. I have a tremendous admiration for the business he's built.
