GormanFletcher
I'm a fan of how Vue's composition API executes exactly once during a component lifetime (during `setup()`), whereas React hooks get set up again on every render. I find it I find Vue's approach easier to mentally model, and thus easier to write correct code (especially when doing something complicated where state changes / effect executions trigger each other). Since `setup()` is only run once, I can also do things like store non-reactive state in closure variables without wrapping those variables in hooks.
Pruning is a key thing I appreciate about Yjs, because it's not just a performance optimization - it's a privacy feature. Users often expect that if they delete something from a document, it's gone unless they have explicitly turned on document revisioning. A CRDT without pruning leaves every accidental paste or poorly phrased remark in the permanent record.
https://wasabi.com/paygo-pricing-faq/#minimum-storage-durati...
That detail isn't mentioned anywhere on their pricing page or cost comparison calculator: https://wasabi.com/cloud-storage-pricing/
I don't find that pricing objectionable on its own, but I'm wary of shopping with a vendor that advertises price as their main selling point, but buries such a potentially costly pricing detail.
Another local theater took the lockdown as an opportunity to do outdoor socially-distanced showings of previous blockbusters, like The Dark Knight. Plenty of attendees there, too.
I'd be happy to have more showings like that.
If you don't care about spreadsheets specifically -- if you're just looking for scriptable access to your financials -- Lunch Money (https://lunchmoney.app) has a public API. They'll also be opening the beta of rollover budgeting any day now, which has me excited!
So for the dust filter, maybe selecting a material that's only rated for high temperatures in short bursts. Or one that needs frequent, labor-intensive replacements in that dangerous environment. Or test that your filter survives at high temperatures, and test the filtration efficacy, but forget to test the efficacy at high temperatures.
If you're storing future datetimes that semantically represent wall clock time, you need to store the locale time plus the full time zone (such as America/New_York) so that your program does the right thing in response to any common regulatory changes that happen after you store the value. Storing the time zone abbreviation (e.g., EST) is inadvisable, as computers sometimes care whether you asked for EST vs EDT. Storing the time offset (e.g., -500) is incorrect, as it has the same pitfalls as storing UTC - you're precomputing the locale's expected time offset at storage time, and your data won't automatically be corrected if time regulations change.
If you're storing historical timestamps, UTC is fine because you can safely convert it to whatever time zone you want to display, knowing that changes to time zone / DST regulations tend not to affect the past.
The attacker has offered to not publish if they are paid. Their word probably isn't worth much, but $1,000 seems like an affordable sum for a business to gamble on them being honest about it. And if Newsblur doesn't fix their security problems they'll be targeted again either way.
As someone who has a decade of data in Newsblur, if there's any chance that an affordable ransom will keep my data from spreading further I want Samuel to take it.
Just be aware that they make it practical to tell that something is happening around you, but with spoken word you'll usually have to pause to tell what is happening around you. I.e., I can't understand what someone is saying to me if a narrator is already speaking into my ear.
The DevOps mantra is that you shouldn't be trying to manage deployments at all, except in aggregate. They should be seamless enough to become non-events that happen frequently and with maximal automation. Time spent doing deploys becomes irrelevant since it's a hands-off, low-risk process.
The DevOps philosophy advocates that the process of developing code and infra to that point produces many benefits to the business: first-order benefits to code and infra quality since you're demanding more from them, and second-order benefits to the business that come from releasing many times per day and going from ticket to prod quickly.
Under this philosophy, 125k annual deployments predicts the engineering department likely is exemplary rather than disastrous, since only an exemplary engineering department should be able to pull this off without frequent/severe mistakes damaging the business.
Every smartwatch I've tried in the years since the buy-out just reminds me how much I miss my Pebbles.
Supported on all major Android browsers:
- Progressive Web Apps can be added to your home screen - Web Push lets web apps receive push notifications (Brave's implementation is broken, but they try to support the feature)
Experimental APIs supported by Chrome for Android:
- Web Share Target API, which lets homescreen'd web apps receive shares from other apps (the share pane makes no distinction between sharing to a web app or a native app) - Contacts APIs to read the user's contacts list
I think PWA's competitiveness will get a lot better once other browsers adopt the Web Share Target (or something like it), but I'm skeptical that they'll really take off as long as Apple continues hold off on implementing features that would make PWAs competitive with native apps.
I started out majoring in Computer Engineering, an embedded systems oriented curriculum. They started us with assembler, then C, and worked our way up. I switched over to Computer Science, which came from the other direction: Java, then C, then assembler.
I learned in myself and saw in my peers that both ways can work great, just for different people.
I struggled to understand how to apply C's pointers and memory management in homework without the context of how that fit into solving a problem in a program, because we hadn't yet written code that really did anything, just one-off tiny functions that demonstrated a mechanic without any purpose. Class tests felt like writing an essay about the applicability of the 4x2 Lego brick without having ever assembled a Lego set. I needed top-down learning to grasp the "why" before I could tackle the "how".
Some peers expressed the same difficulty as me, but others commented that they found their Computer Science courses challenging until they dug deep enough to understand the underpinnings of the computer. They struggled with their Java courses, but got much more confident once they progressed to C and then assembler, because all the unexplained high-level incantations suddenly started making sense.
Over my career, and in my hobbies, which of these approaches I need has come to vary depending on the task. When I'm learning a new way to do an old thing, I jump straight for the bottom-up information. If I'm learning something totally new, I still need to go top-down.
I'm sorely tempted to build my own library/playlist management front-end on top of Spotify's API. They're the only streaming service I've found with an official streaming/remote control API, and with upcoming lossless support (albeit only CD-quality), their library with a tailor-made UI seems like the best trade-off I'm going to get in a music service.