Github is the worst of the web GUIs I use regularly. Started bad and only got worse, luckily 99% of my gitting is via PC based tools. Maybe this is the kind of app where the GUI should be modeled on client side developer tools and not modern web UIs.
Historically I've thought the GitHub web UI was great - clean, usable, simple. Over the past couple of years it's started to get more and more feature bloat, to the point where it's becoming less usable.
Thinking back on it I've used Github nearly since the early 10s. Today I find myself wondering how the fuck I get a list of all issues for a project. For fifteen odd years I've been able to clear the search box of the "is:open" and "is:whateverfuckingelse" bits and just get a list.
Now? Whatever UI update they've just pushed isn't reflected in the documentation. I can't think of anything that's been improved since GH decided to reinvent text rendering (and poorly at that) and then double down on it.
Upon further inspection it sort of works if I log in. It behaves differently at least. Ugh.
I've only used Github desktop briefly so I can't say much about it, was commenting on the web UI. I suppose if I was using a lot of GitHub functionality vs. just using github.com as a repo things might be different and I'd give Github desktop another try.
Sorry, that's what I meant actually, the web UI. I said desktop to differentiate it from the mobile web UI, but I realize that was the wrong way to say it because they also have a desktop app.
No idea how the e-bike guys here did it but Schwinn had a bike for a while (my wife owned one) where the freewheeling was in the bottom bracket, it was called "FFS". It's pretty freaky and wasn't popular. You can see it in action starting at 0:30 here:
If I remember correctly, Liskov didn't talk about inheritance but subtyping in a more general way. Java, C++ and other, especially statically typed, compiled languages often use inheritance to model subtyping but Liskov/Wing weren't making any statements about inheritance specifically.
This is correct. I read her paper closely. One example I give is how SICP provides two implementations for complex numbers[1], the rectangular for and polar form.
(make-rectangular (real-part z) (imag-part z))
and
(make-polar (magnitude z) (angle z))
then on page 138 provides this interface that both satisfy
> use inheritance to model subtyping but Liskov/Wing weren't making any statements about inheritance specifically.
Right. Inheritance is just one mechanism to realize Subtyping. When done with proper contract guarantees (i.e. pre/post/inv clauses) it is a very powerful way to express semantic relationships through code reuse.
What she says makes sense: “It is about returning people to a state in which parting with things feels natural.”
That's the whole problem, if you're a hoarder it doesn't feel natural. Maybe you can step through the process and declutter but unless you change your brain you'll just re-accumulate.
I know someone whose mother “solves” clutter by giving things to family and friends, which is really outsourcing clutter because now your friends have the clutter problem and emotional blackmail to keep it.
When I met her, she was busy trying to gift something. In that moment I thought of the scene in Labyrinth, after Sarah eats the peach and ends up in the midden heap with the old lady who is telling Sarah to focus on her belongings. She was a lot.
Also PNW, Willamette Valley, I've had standard compost pile forever and for a few years I had a few chickens. It was amazing how well the poop worked and I had such absurd amounts of worms in my compost that I fed some back to the chickens.
The only problem is that it does take a while for the poop to turn into compost and with the constant addition of fresh poop it was hard to time. I have two piles and do a yearly changeover, that keeps it easy.
A hot heap captures more carbon, releases less methane and makes much compost, much faster, from same amount of base material ( less evaporates ).
Ideally takes 6 weeks to compost a whole heap - using hot methods.
Also kills fungi & pathogen and all weed seeds and readily ‘eats’ ( dissolves ) carcasses and meat and other nature that should be avoided in cold heaps.
Takes a bit more management and monitoring but is easily automated.
tl;dr air pump saves turning the heap, insulation keeps heat in, currently Raspi sensing methane, moisture and temp controlling water & air inputs has improved my home hot heap yields 80% and completely automated it - 100% labor free.
The 4 key factors for a hot heap are moisture, temperature and oxygen and green ( high nitrogen ) to brown ( high carbon ) ratio ( approx 2 green to 1 brown by weight ).
I have a 1 cubic metre heap ( the minimum to generate the necessary heat ) and I have an specialised product, a double wall insulated ‘hot’ bin which keeps it working even in winter.
A hot heap steams so water input is necessary.
Hot heaps need oxygen, which is the hard part - manually turning the heap.
The temperature rises to 70 degrees C after a week, which kills all but the extremophile hot heap bacteria which are aerobic rather than the cold heap anaerobic bacteria.
I added an air pump input to the bottom and I have a water hose and sprinkler the top.
I run the air every day for 10 minutes. And the water for when it feels dry.
Now it never smells and composts in 7 weeks instead of 12.
I have now bought a methane, moisture and temperature sensors, electric valve for water and so a RaspberryPi is graphing the sensor inputs and recording the heap water and oxygen timings.
Very importantly, I have a pile to collect greens ( veg and grass ) and a pile for browns ( leaves and cardboard ) so I can fill the hot bin in one go.
Our nomenclature for servos in machine controls is a little different, for example a traditional 3phase servo with a 3phase hall sensor is still called "servo" even if it doesn't have an optical encoder. With this setup you can commutate the motor and get smooth motion and variable speed control but not precise position control. We then add on a optical shaft encoder or a optical linear encoder for position control.
In the video he has what looks like a magnetic absolute encoder, I have honestly never seen that in industrial applications although I have seen "absolute" optical encoders that have a backup battery to store the home point, kind of weird imo.
I was surprised when I first encountered servos with just magnetic hall effect sensors but there are actually lots of applications where you want speed control but not accurate position control.
Absolute encoders can be really good for position critical applications that you don't want to re-home all the time. Linear stages, winches - if you don't want to re home it and it needs accurate position control you start looking at an absolute encoder.
Even for speed control, hall effect sensors are kind of a poor way to track position. What is nice about hall effect sensors is that you can use them as a signal to perform brushless commutation in your motor controller, and then also use them as a poor-man's encoder. Very useful if you don't need that much accuracy in your application, but you do need brushless motors for some reason. But one of the first things I would go to as a application engineer was recommend customers get an encoder mounted.
It seems like an absolute encoder would immediately lose its advantages if a reduction gear were used though? Then you would still need to rehome the number of revolutions.
Yeah, we have one application like that, a big gantry that would be a pain to home. Interestingly, the high res absolute encoder is also used to commutate the servo (it's sine) but the teaching of the commutation is a little nerve wracking. Maybe I'm getting old but the whole setup stresses me out
In my mind the main difference is steppers always taking full current, that's why we tend to switch to traditional servos past a certain size or use hybrid steppers like the MDrive
If you're micro-stepping a stepper then you're applying different currents to the coils. You can also microstep/openloop a BLDC just like a stepper and you can run a stepper with a closed loop controller just like it's bigger BLDC cousin.
Steppers had a niche in situations where you want to take discrete/accurate steps with very little control circuitry, e.g. printers, disk drivers etc. they're much simpler to work with vs. a closed loop bldc system, require no tuning, less software, etc.
I used to think this but you can actually drive steppers with FOC (if they have appropriate feedback) and modulate the current based on required torque. It’s open-loop steppers that don’t do this.
You can do this but it's very difficult; the high pole count means it requires extremely precise and high-speed feedback to get good torque control on a stepper motor.
Yeah ain’t that the truth. This is a problem I’ve been fighting at work lately with a trinamic based system. Trinamic should be good but I see it’s touchy to properly phase align a stepper.
I agree about missing RAII when switching away from C++ but it seems like defer cleans up after enclosing function exits while RAII cleans up when object goes out of scope, which is more fine-grained. Maybe I'm misunderstanding exactly when defer would clean up but it seems more like a safety feature. As people pile more stuff into the function the cleanup would be deferred more and more while RAII encapsulates the management right where you need it, e.g. exiting a loop or something.
defer-based cleanup also has the problem that, if the function plans to return a value it has to make sure to *not* defer its cleanup, and the caller then has to remember to clean it up. Destructor-based cleanup avoids these problems, but of course it's reasonable for languages (existing ones like C and even newer ones like Zig) to not want destructors, so defer is the next best thing.
Note that C++ destructors are also not ideal because they run solely based on scope. Unless RVO happens, returning a value from a function involves returning a new value (created via copy ctor or move ctor) and the dtor still runs on the value in the function scope. If the new value was created via copy ctor, that means it unnecessarily had to create a copy and then destroy the original instead of just using the original. If the new value was created via move ctor, that means the type has to be designed in such a way that a "moved-out" value is still valid to run the dtor on. It works much better in Rust where moving is not only the default but also does not leave "moved-out" husks behind, so your type does not need to encode a "moved-out" state or implement a copy ctor if it doesn't want to, and the dtor will run the fewest number of times it needs to.
I had the same thing with my dentist about one of my remaining wisdom teeth, we went back and forth for five years but it finally got bad enough to do something. I opted for a crown though and it's been good and not too bad out of pocket.
