This seems like another high tech solution looking for a problem. I'm not heavy agriculture savy but it seems to me the same could be solved by having 2 or 3 archimedes screws on the bin which could keep grain moving over time and preventing it from forming the clods.
The bot could also be radio controlled and it would still remove the need of a human going in.
Another pet peeve of mine is the robot-as-a-service part - can't we just buy stuff and keep it anymore?
> The bot could also be radio controlled and it would still remove the need of a human going in.
Yes. And it is radio controlled. To quote the article: "The Grain Weevil is a remote controlled specialized robot [...]" They also plan to make it autonomous but it is not yet.
It's more an issue of either having an uneven depth after loading the bin, especially if the farmers are storing it all winter to sell the next summer. To do this you need to closely monitor the temperature and use the ventilation fans to bring the grain down in temp gradually to prevent spoiling. In order for that ventilation fans to do their job well the grain has to be a consistent depth.
Virtually all systems will produce uneven depth as the bins are loaded. You usually either end up with an upward cone in the middle from the pile, or an inverted cone when you're using a bin spreader to distribute the grain around the bin. The other time you can have an issue is if you have a powered spreader and forget to turn it on and load the bin unevenly on one side, which could end up being a structural issue.
I agree robot as a service is annoying. It is a good fit though for robotics because your first version is likely to cost too much and break too soon. Selling that would make for unhappy customers. However investors like the high profit potential and that can lead to dark patterns.
Yep, that was my first thought as an outsider and of course it's already used in those bins, it's more heavy-duty, faster, probably more expensive to install but more effective than a small robot.
The first video perfectly illustrates how the majority of grain bins in Northern California are configured, mostly for storing rice and wheat. I grew up on our family farm and we have several grain bins. They contain a row of augers at the top, with the row width being the radius of the grain bin. The augers almost reach the floor and spin to "stir" the grain, and the entire row slowly rotates around the top. We called them "stirs" [sic] and they were installed 35 and 45 years ago, so it's definitely not a new concept. Very simple and very effective. Grain bins there also have large fans and heaters at the base, which we just called "dryers". Between the stirs and the dryers our area didn't have any suffocation or explosion incidents that I remember, but we knew those were risks and we were careful if we had to go inside full grain bins. It seems like more of an issue in the Midwest with corn and soybeans, and taller silos.
I think it’s as a service because it’s not needed often and only in situations where something goes wrong. The cost benefit may not work if you had to buy the thing.
Just be grateful they didn't promote it as being for search and rescue like every robot-solution-looking-for-a-problem that gets invented by academics.
And the good jazz musicians can play their instrument from the C version. Over time you learn to transpose on the fly. It's just 12 keys after all, and the melodies tend to be not that complicated anyway.
It looks like it works for previously opened files. Perhaps the author didn't want to load the whole tree into the browser, or maybe its a limitation on webhosted vscode?
I suspect that the author didn't want to eager-load all files because the API they're using is rate-limited -- 60 requests/hr when unauthenticated, or 5000/hr if you generate a unique OAuth token. Even that 5k could get burned through pretty quickly for a larger repo, assuming you have to make at least one request per file.
I don't really understand the composition API. Doesn't passing values by reference which can be modified anywhere downward the tree make your app difficult to reason and debug it?
If you meant more from a conceptual standpoint -- the usage patterns with Vue 3 is pretty nearly identical for most people. You just replace "data()" property with some "reactive()" state value in setup (or "ref()" for single values).
You CAN write things like generic hooks/"useXXX()" helpers, but you likely won't wind up with a ton of those.
Also, about the reference passing: it doesn't actually really work like that. If you pass a "ref()" or "reactive()" value as a prop to a child component, and you mutate it there, it doesn't propagate to the parent.
Vue will throw this warning:
[Vue warn]: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "someRef"
> I don't really understand [X]. Doesn't [Y] make your app difficult to reason and debug it?
It (passing mutable values around) does make it harder to understand the data-flow, yes.
But we programmers keep assuming our rules & protection & orderliness are helpful & necessary. And those patterns we opt in to keep getting codified, embraced. But along comes someone who breaks those rules, & it keeps turning out, a lot of the things we think we do to be orderly & safe & sensible are actually not that helpful at all, or have impeded really wonderful progress elsewhere.
I think of React. Until React came along, everyone doing web development knew, it was obviously correct, that we needed templating languages. We knew we needed content & code separate. We knew content was obviously a different beast than code & that content should have tools designed for content. As it turns out, mixing code & content actually works really well & that we had ruled out a wide space of possibilities that were really simple, powerful, & direct.
Relatedly, here, with shared-mutable-variables, I'd pitch that hopefully tools compensate for a lot. Hopefully it's possible to run the app & see who is modifying values, see who is being updated when values change. It's nice being able to have the code tell you, up front, easily, but also hopefully watching at runtime is possible, makes it easy to suss out what the connections & causalities are within a system.
I had a similar misunderstanding when I first saw it, but globally declaring reactive variables and passing them around isn't really what it's about. Take, for example: https://github.com/antfu/vueuse/blob/master/packages/core/us.... Any component that wants to use a reactive reference to mouse coordinates can `const { x, y } = useMouse()` in `setup`, but `x` and `y` will refer to different objects in each of those components (since the `ref()` is instantiated inside the call to `useMouse()`). The functionality is what's shared between components, not the state/references.
That said, if you want to use the composition api to share state you can, and you can pretty easily set up some structure to restrict mutability:
// useStore.ts
import { reactive, readonly } from 'vue'
export const useStore = () => {
const state = reactive({ count: 0 })
const increment = (val = 1) => state.count += val
return {
state: readonly(state), // Readonly so state can't be mutated directly...
increment, // ...only through the mutations provided, like Vuex
}
}
// store.ts
import { useStore } from './useStore'
export const store = useStore() // Now components can share this instance
// MyCounter.vue
import { store } from './store'
export default {
setup: () => ({
count: store.state.count,
onClick: () => store.increment(5),
}),
}
Or you can just keep using Vuex for sharing state and use the composition API for sharing self-contained bits of functionality. Or, if nothing else, using the `setup` method instead of the Options API just gives you much more control over how you organize your own code within a component.
Modifications in all JS frameworks are the same. Some interaction causes an event, that event is caught and changes some data, that data then triggers the render functions which show the new UI. This is often coded with event handlers linked to actions/mutations/reducers in some kind of state management library.
Vue (and some other frameworks) use a reactivity approach where the data is wrapped with a proxy that basically automates all this code. I find it much easier to reason about since it greatly reduces the complexity and you can focus on the actual data changes rather than all the plumbing to change the data.
No, because they all happen in the setup function, and when you export them at the bottom of setup you use them 100% identically as you would within mounted() etc,
I constantly read articles like these and keep thinking - if you lose this distraction, soon you'll find another one.
I noticed a few months ago that hackernews and reddit were sucking more and more time out of my life. So I installed impulse blocker, removed the apps from my smartphone, thinking I would get so much more free time. Guess what, I was wrong - I just spent my free time with other distractions, sometimes to a much worse net benefit. Not reading HN would mean to lose the thin grasp I've got on state-of-the art tech and all the panoplia of interesting content.
I've tried the folder before, as well as turning the screen gray (guess what, most apps don't have enough brightness contrast to be really usable while on grayscale), and nothing worked.
Maybe distractions can also be positive in your life - I surely enjoy watching a documentary to spend time, and the entertainment it gives you also brings something valuable to your life, while r/funny or facebook don't. Maybe the trick is to select when you wanna have trivial fun and stick to that.
