Technologies:
Python (sync and async, Django and non-django), C, Java, Typescript, some C++, past in Rails.
AWS, Docker, Pulumi, Linux, a little GCP.
Résumé/CV:
10 years doing tech, past six in SRE roles (one FAANG, one startup). Lots of scalability and automation work in these roles, working with SWEs. GitHub is sheenobu.
A continuation is a function that, when called, jumps back to a specific part of the program that was frozen (meaning current memory, the call stack, the line number). So it can't really be stored. If your game state was stored in a db, you'd still have to load it memory to perform operations on it. Those operations, if using continuations, would then stick around in memory while waiting the continuation to be resumed. If it's a multi-player game, then you'd be in real trouble as your continuation could end up with stale data.
Game state has to be propagated from the server to the client so the player knows what is happening where-as continuations as used in this article are more about avoiding this propagation (the hidden field in the example is replaced by dispatch-table tag which acts as a session id / location in the dispatch-table for finding the continuation function)
If someone builds a container that is designed like this:
FROM debian
RUN do-x
RUN install python2
and then someone changes do-x, if I understand, the layers below it get invalidated and all of a sudden install python2 fails. This is very bad design but very easy to replicate.
Thank you for the sympathy. If we are talking about the same product then it was most likely backed by 3 different storage services over its lifespan, 2013/2014 was a third party product that had some replication/fail-over baked in, 2016-2019 on my team with no failover plans due to "deprecated, dont bother putting anything important here", then 2019 onward with "fully replicated and automatic failover capable and also less cost-per-GB to replicate but less flexible for the existing use cases".
I think I know specifically what you are talking about. The actual files an engineer could upload to populate their folder was not multi-region for a long time. The servers were, because they were stateless and that was easy to multi-region, but the actual data wasn't until we replaced the storage service.
There is nix, the language/package manager which can be used standalone; nixpkgs, the ports or homebrew like repo of packages that can be built/run on many systems including macOS; and nixos, the Linux+Nix distro that puts it all together.
I thought of Nix while reading this thread and I'm wondering what makes it unique here? As a daily NixOS user I get that it is better but I don't know the specifics. the nixpkgs rpeo is superficially similar to homebrew (lots of people submitting packages, running on github, automation around commits).
Running a JVM application in a container is not all that different to running a Go application in a container. But the design of the JVM runtime and its tooling is vastly different than Go. The JVM is more complex but it can do more things. Go is simpler and can get you to a working product quicker.
If someone asks me to build something and they tell me it will run in docker/kubernetes, have the standard containerized CI pipelines, and communicate with other services over some standard protocol like HTTP; doing it on the JVM is doable and probably easier than ever but I would just think about all the cool JVM features I wouldn't get to use (hot code deploy, runtime modularity tools, all the neat bytecode hacks, even spring which everyone but me seems to hate).
If I don't get to use those features then I would rather grab a language like Go, since it doesn't front load so many runtime complexities. (and if this was 10-15 years ago maybe I'd say "Go doesn't front load so many complexities AND performance penalties")
Go can do encapsulation and polymorphism. Go doesn't do inheritance, of course. Channels can also help simulate message passing and actor-style code. What's missing?
IMO, If you compare Go to an OOP language that runs in a VM there are some things that will fall short but the industry has worked around it. It's not cool to have a beefy Smalltalk or Java VM, with the dynamic runtimes that let you auto-export objects as remote endpoints... you have small binaries exporting HTTP or RPC services running in containers and interfacing with service discovery and fabric systems. The "object orientation" is now at an abstraction sitting above the running binary.
I love NixOS but does it not update too often? Or is it the ability to pin to specific package versions in isolation that would make it a selling point to CentOS (for Reasons) users?
Semi related: Is headset mode worth using for voice chats? Enabling it seems to cause noise and "incoming call" voice messages. I'm not sure if it's bad support for my specific hardware type (LE Bose QC35 II) or just bad HFP support in general.
No. The go files just have "package emailnormalizer" within the go files, so that is the name that you use to reference it, even if the import url is different.
OSGi (Open Services Gateway initiative) [1] provides this for the JVM by modularizing the ClassLoader [2]. If a module is upgraded but classes from the previous version are still referenced by other modules, both modules will run.
An OSGi "service" is not an actor but, like OTP with servers+supervisors, is the logical unit with which you build your systems. "bundles" (Java JARs with additional metadata) then act as the equivalent "application" that contain the services.
Outside of it being Java, I have strong opinions (positive and negative) that I've decided not to include.
Caveat: I'm not a security researcher just have a basic knowledge of the terms and techniques you would find in a beginner exploit tutorial.
These types of exploits are usually specially crafted files that trick the code responsible for parsing and displaying the video file into running whatever the creator wants. The terms "buffer overflow/underflow+" and "shellcode" might help narrow down a definition for you. Below is an overly simplistic version .
The video might contain, inside of it, a specially written computer program that sends the IP address of the current computer to whatever location the attacker wants. (This is the shellcode). This code could be really simple.
The video could also have parts in it that do not make sense. the video player code makes assumptions about the video that the video purposefully violates. When the video is processed by the computer, the video player code misunderstands what it needs to do and will accidently treat the video as code. (this is the buffer overflow). Since parts of the video are actually special shellcode, the computer has been tricked into running code hidden inside the video.
You are right about the input requests being too complex. From this microservices presentation[0], they do use machine learning to generate recommendations which are then curated further by the stylists, specifically for this reason.
But I've always wondered about the grouping and parity between stylist and customer. IIRC, they say it in the presentation but they do not say how much bucketing happens. Is Person of archetype-A grouped with 100 other people and given to Stylist A? 1000 other people? Or do they only do additional curation if you reject so many items and write so many input request words?
Also, is there a good track record for such a request like "I need a pair gold earrings" working? and working specifically because of human curation and not pattern matching on color and item description?
Remote: Preferred!
Willing to relocate: No
Technologies: Python (sync and async, Django and non-django), C, Java, Typescript, some C++, past in Rails. AWS, Docker, Pulumi, Linux, a little GCP.
Résumé/CV: 10 years doing tech, past six in SRE roles (one FAANG, one startup). Lots of scalability and automation work in these roles, working with SWEs. GitHub is sheenobu.
Email: [email protected]