For farmers in regions with intense sun like colorado, I would imagine that some kind of solar netting would ultimately be the best solution for mixed agriculture. If you could hang a net like 10 feet off the ground that has tiny solar panels linked together to block out 50% of the sun, that would probably create an ideal environment for growing certain berries and vegetables.
My understanding from comments on reddit is that part of the suit relies on tortious interference, basically that honey is damaging the relationships between content creators and vendors by masking the source of referrals and therefore making the vendor believe that the content creator is under-performing in their contract.
This thread has started with GP saying "cookie stuffing is illegal" and me replying "does this qualify as cookie stuffing?" I'm not claiming what they did is legal, I'm claiming it might be illegal, just not for "cookie stuffing". As far as I can see there is no evidence that this particular suit claims "cookie stuffing", so there is nothing in it that can add to the question whether this qualifies as "cookie stuffing" or not. Which was my only original question.
Does anywhere in America subsidize the cost of tearing down low density housing for the sake of building high density. It feels like property developers are more incentivesed to expand outward rather then upward
i think it depends on the area. I live in an area just South of downtown Dallas TX called Oakcliff. There's a really popular neighborhood about a mile from me called Bishop Arts. Over the last 5 years or so many blocks of 20 or so homes have been bought, demolished, and replaced with really gigantic apartment complexes. i guess that's good for density, sucks to be the people/community that already lived there though.
I've been working with a pretty specific data model now for about 8 years. One of the booleans that has turned into a trap for us is called
isFavorite = true|false
This was originally meant to indicate an item would be pinned to the end users dashboard. Turns out that over time the business unit wanted to allow users to pin items to more then just a dashboard. If we had known better we would have used a set like
favoriteLocations = Set<Locations>
but because this data was modeled across user devices in firmware and not just a central db, we were kinda stuck with adding more booleans for more locations to pin an item.
I understand that it could have been easier from the start by using a set. But at the time, it wasn't a requirement. Why would you use a set for a single entry?
Furthermore, you didn't need to keep using booleans. You could run a script that reads the boolean and update the new field in the row, and transition your code to use that.
I keep trying to get into rust but I always hit a brick wall when looking at examples and the code looks so complicated. Examples like this straight from the rust website just make my eyes glaze over
Something I like about Rust is that it gets very specific and explicit.
On first glance you're like wtf is going on, but you can derive backwards what is happening without having to look for a discussion on language behavior under the hood. Automagic is nice sometimes but I'm the kind of person that needs to say the each word of an acronym to process it.
Rust is like that in a way. You have a mutex on an option type, the option has a heap allocated future that contains data that can live for the lifetime of the program.
This is clear to me because I don't need to fill in blanks. My memory is terrible, I've forgotten so many things I've learned in the past. I could pick them back up quite quickly but I don't have the little facts ready to go. If i wanted to use that future, I know I need to check the mutex lock, check if the option contains a Some(), etc.
Sure this isn't for everyone, but I'm glad we have a tool like this gaining popularity. I have little interest in studying the arcane knowledge of C++ and sorting out what is current and what is obsolete, then arguing with a 30 year veteran that their technique is 20 years stale.
I'll grant you that is probably too complicated an example to appear early in the docs, but how often are you actually building multithreaded job dispatch systems from scratch (which appears to be what this example is doing), and how simple would it be in other languages?
Yes, but the Rust code is the kind of thing you'd write if you wanted to build that kind of thing yourself. I do think normal Rust can get too typey, but this is probably not the best example of that.
Having never used a lisp outside an AI class a quarter century ago, that isn't comprehensible to me, and I don't think it is just my lack of caffeine. The rust example makes more sense, but I've used rust for almost a decade at this point and c++ for over three. Familiarity matters.
But honestly only for a very short time. It took me two weeks of learning for Clojure to start looking completely natural to me. Surface syntax is such a trivially minor thing, which is why it seems ridiculous to me that the OP author even mentions things like "Swift uses switch rather than match, such familiarity" among other much more solid points.
Yeah, of course. If you show me Brainfuck or APL code I won't be able to make head or tails of it either. But familiarity should never stop one from learning new things, otherwise we miss out on a lot of simple, interesting and useful stuff :)
So it's the same but without type annotations? Meaning that the clojure IDE has a much harder time providing completion and that you need to write all sorts of tests to get the same guarantees as the rust compiler provides for free. Type systems aren't just about memory representation, they also tell the next programmer about the intent and performance characteristics of the code at hand.
As I understand, the idea an executor is to emulate an event queue using threadsafe (hopefully lock-free) queues. Since the language already has goroutines, channels and group waits, I don't think this is something that needs to be built in Go. I mean you can do your rate limiting and retry handling logic outside the language primitives. If you do have to make a task spawning executor, you can do that with channels as well. But it would just be a very thin wrapper.
The only tricky thing there is the BoxFuture and ‘static lifetime. Arc is pretty simple. Option is simple. Rust is just forcing you to acknowledge certain things and understand lifetimes explicitly before you can move data around. And static is close to a “plz make this lifetime error go away” thing cause it means it can live forever. But they are also fine, and often the right choice. This may seem contradictory but it will make sense if the Rust compiler hurts you enough times :)
This may demonstrate the intricacy of the type system but isn’t a very intuitive example… I feel like the Rust Book does a good job of explaining the different types in std. For one thing it shows these types in their most idiomatic use cases. Rust is my first real low level language and I learned a lot by reading the book.
And by reading it I mean I actually read the thing front to back before touching a keyboard. Then I started to experiment with some simple code and after a couple of months I had some actually programs that I use often. Obviously I rewrote them after a year but hey ho, it’s all a learning experience.
What this means is that the future field stores something that is a:
- Dynamically dispatched object (with a V-Table) that implements methods from the Future trait, and returns nothing () = void. (dyn Future<Output = ()>)
- That thing needs to be sendable between Threads (+ Send)
- And must potentially live forever (+ 'static)
- The dynamic dispatch stuff only works with heap allocations because the V-Table pointer is stored in the double wide smart-pointer. In this case we use a Box which means only one thing/thread can hold it at a time (unlike reference counted Rc/Arc).
- That allocation of the Heap allocation must not be moved around in memory. (Pin<...>)
- that thing might not be there (it can be Null), but replacing/taking/putting the thing will be secured by the mutex so that's a nice guarantee for multithreading (Option<...>)
- access to a thing is synchronised via a mutex (Mutex<...>)
So while it looks horrible at first sight, it is simply telling you a lot about the guarantees of that particular type.
Honestly that one I can read (I am just now in earnest trying to learn Rust). What I've been banging my head into is trying to get a suite of boilerplate libraries together to make basic things happen.
Got directed from slog to tokio-tracing for logging, so dove into setting up my basic "--log-level", "--log-format" CLI options I add to every non-trivial program in Rust and ran into...whatever is going on with configuring it (namely, tokio-subscriber seems to encode all the configuration information into types, so you can't just return a Subscriber or Subscriber builder from a function and then add it as a logger...the documentation gives no hint on what trait or type I'm meant to return here).
Not just you. Best case the tracing ecosystem is weird and the documentation is lacking, but all of the weirdness makes it very performant. Worst case it is weird and badly documented and over-engineered.
Since rustc uses tracing I really hope it's the first...
It's not just you, I watched yesterday [1] that Bun's author initially tried to use Rust but wasn't as productive. Then he switched to Zig and here they are, innovating JS/TS landscape.
Yeah this is a bad example for introductions for rust - namely that async rust is something I'd consider advanced.
However the type explicitness is, IMO, one of its strengths. It lets you build up types that e.g. in C++ we're not a given, had properties about the behavior buried in docs, etc.
They run in to async, but do they run in to the internals of how that code is executed?
The chapter that example is from includes the disclaimer:
> In this section, we'll cover the underlying structure of how Futures and asynchronous tasks are scheduled. If you're only interested in learning how to write higher-level code that uses existing Future types and aren't interested in the details of how Future types work, you can skip ahead to the async/await chapter.
I wonder if surfing will survive as well. I enjoyed watching it at night with my wife when all the other sports were done for the day, but it was really hard to follow the logic of how a ride was scored. They also had to pause for a couple of days for a storm, and some rounds the waves were clearly not wanting to play along and resulted in less impressive rides.
One thing I regret after moving into my new house was not getting a detailed list of drains installed in the property. I have lots of drainage issues and don't know if there is a drain there but inadequate for the amount of water we get, or just not installed at all.
A major lesson of home ownership is that it is a continual fight against water. Keeping water away from places you don't want it, and keeping water in and available in the areas you do want it.
This is absolutely true. I think half of the home renovation projects I've done in my life have been to either move water, or repair the damage from where water ended up where it shouldn't be. These are never the fun projects, but in terms of protecting your property, probably the most important ones.
Does the house have a sump pump? In our current house, which we bought with full knowledge of the issue, there was seepage and no sump pump, and we ended up having one installed (after negotiating down the sale price a bit after the inspection.) This involved jackhammering through the unfinished basement floor around the perimeter and installing a drainage pipe, then repouring that part of the floor w. inspection/cleaning ports into the pipe, along with a sump and pump in one corner. Works like a charm now.
There had been a drainage pipe but it was not working properly, probably being crushed or filled at some point by tree roots.
When I bought my house the previous homeowners legally had to declare whether or not there was a drain around the foundation. Very useful, it's the first thing we did and we never had any water breach the house.
Sorry, I should have clarified, I meant for drainage in the yard. We live in a development that's on a hill so 2 of our neighbors are on properties above us.
Yea, often these improvements are not well documented, you are right that it would have been easiest to ask the prior owners while they still owned it.
I just used a time based trick when I needed to push through behavior that apple didn't like. 20 days after submitting the app one of the buttons changed it's behavior to allow a "File Open" dialog to go directly to the users root directory.
I did the same in one of my apps. It's a private app, you need a login code to use it; Apple wanted to test all the features, so I put some fake screens in the app, those screens didn't even make API calls.
I set a timer for two weeks, after those the app started having its real behavior, with API calls and everything.
Seems pretty unreliable. At least I know a recent Google Play Console reviewer was located at the Google office in Lisbon. I wouldn't be surprised if Apple used reviewers outside Cupertino.
So I manage a fairly large ios project and never really took the time to properly validate compile times, so I just started playing around with it and found some nice little surprises.
let horizpadding = self.collectionView.frame.width - ((5*50)+(4*25))
Expression took 1299ms to type-check (limit: 500ms)
Now obviously this expression could have been simplified long ago as a single constant, but the values themselves were written to help others understand what that constant meant (5 elements that are 50px wide) + (4 gutters that are 25px wide)
reply