As a remote worker, it would be really cool to have something running locally that had access to my Zoom logs/meeting transcripts, Slack, email, calendar, etc.
Then take that and have it summarized what I did all day on the computer.
The point of many tasks like this is in the doing. Writing throughout the day what you are working and planning has an effect on your focus and productivity, in and of itself.
Automating this kind of thing is automating your own defeat.
I use Manictime for this. It keeps track of active applications, you can add tags and it can take screenshots at defined intervals. https://www.manictime.com/
No, IIRC Apple Intelligence does not make such claims. It can keep context within interactions and know about information in some of your silos. Recall has a much bolder feature set in that it wants to beware on everything you see on your screen.
Unless you get them very young, eating the leaves is reminiscent of chewing sandpaper. Now you have me wondering if it would be palatable juiced, maybe as part of a smoothie.
I have English ivy around my house, which isn't quite as invasive as kudzu, but still a major nuisance.
Roundup does basically nothing. The leaves are thick and waxy and so don't absorb herbicide effectively. Supposedly, applying a more concentrated formula on a weekly basis for a month can work, but I don't like the idea of spraying that much glyphosate.
If you have to use poison you can use way less by pruning and putting a dab of glyphosate on the stump. Even dishsoap straight to the vascular system will kill many plants.
I just mow it so I can see the vines and then pull them up and cut them. Over the course of the summer, I cleared a significant part of my land. Now that autumn weather has finally arrived, I should be able to get it all.
You can use ammonium sulfate as a surfactant to cut through English ivy with glyphosate. It works great, and in theory you don't have to use as much Roundup that way either.
This is the only way I was ever able to kill English ivy in the back yard of my old house. I bought glyphosate concentrate, some disposable plastic cups, and a disposable foam paintbrush. I painted it on every damned leaf in the yard.
It works. It may take several applications to do so, but it works.
Top tip. Rubber gloves with some woollen gloves over the top. Soak the woollen gloves in glyphosate and then you can lovingly stroke the plants you want to kill. It’s a bit quicker
I understand your sentiment and share to some extent, but the reason this came into being wasn’t vanity. Having large shrubs or weed areas leads to pests and the spread of disease, while large trees become deadly during storms. In the AmericanSouth and MidWest, seasonal tornadoes make this latter threat far worse. Homeowners then become incentivized to clear their yards of both hazards. Kudzu and English Ivy kill the trees and make them more likely to come down. Once people clear a lawn, the only way to make it look good is by getting that rich green and uniform golf course like appearance brought to you by Bayer.
It wraps all around trees and other desirable plants, and has shoots under ground that can extend many feet away. Digging it up is the only solution but even that is exceedingly difficult. I’ve learned to live with it.
I don't think the folks that say this usually mean "never done before" in the way that you are saying.
"never done before" in my experience usually translates to "this combination of things doesn't have precedence internally [to the team or company], so I have to figure out how to glue all of these parts I don't understand together".
Back in those days, a mixed bag depending on what was available at the venue and dependent on what the responsible LEC could provision (hence the need for some specialist engineers to be involved). Stadiums in particular are usually quite well equipped from a telco perspective. Could be anything from N x T-1s or DS-3s to fiber ATM to more esoteric stuff like SMDS and point-to-point microwave. Once IP became the de facto transport I'm guessing there was more stuff like MetroE and frame relay, and these days I imagine they just plug in some multiGbps fiber and ride IP back to the mothership.
I might be in the minority here, but IMO that snippet does not look nicer and looks pretty ugly. You've got like 3 things going on all jumbled together.
I would not want to encounter that line of code in the wild, or 3 months after writing it, and attempt to parse what it's doing.
I like the way this pattern trends, but one downside is that it mixes HTTP concerns into the service layer. E.g. the service layer needs to know exactly which HTTP error code this responds to when returning an error.
If the service layer is used for something other than a web server, e.g. a handler for a queue, we've now got a kinda funky abstraction.
I notice that the HTTP Request and ResponseWriter is also mixed into the service layer, which is another thing I would probably move one step closer to the actual HTTP server and away from the logic that interacts with the database.
In the past I've used `Temporary()` or `Permanent()` along with some other additional fields to help map to HTTP status codes at the HTTP server's handler layer.
As soon as you have your services suddenly hooked up to something else - chron (or hangfire or whatever) jobs or a message bus - it gets a bit weird because your service layer thinks you're still responding to an HTTP request and whoever works on the service now has to think about HTTP as well which is pretty fucking bizarre to begin with.
And your unit tests for a business logic service method are gonna look at HTTP errors? It feels dirty, but not in a fun tap-your-nose way.
It's really not hard to just return errors relating to what actually happened (can't find user by id, user is blocked from logging in, whatever) and have the app's ingress points (API controllers, message handlers, job runners) decide how to surface that in a way that makes sense for the specific interface.
I've done interfaces where centered around the kind of error that happened, which is typically standard across apps and translates well into status codes for http or grpc.
Eg "NotFound()" "InvalidParameter()" "Unknown()".
That said these could all just be sentinel errors with the normal unwrapping in the stdlib these days.
I agree with you in general, and I've never written code in this style.
But at the same time, converting between error and result domains is tedious and error-prone. As much as we believe separating concerns is a good thing, it's pretty likely that service layer code will never ever be used outside a HTTP service context, so... so what?
I probably still wouldn't design like this in my own stuff, but I'm not convinced it's actually so terrible.
I guess it really depends on what kind of stuff we work on. It's very common for service layers in systems that I work on to be shared between various ingress points (HTTP, GRPC, Kafka handler, etc).
For any non-trivial app, there would ideally be a set of domain error types/codes that the various application layers know about, rather than concerning themselves with HTTP statuses.
I didn't discuss that in the article, because I felt like it was a bit tangential. Perhaps it was a mistake to omit that detail.
Then take that and have it summarized what I did all day on the computer.
reply