> The quake caused further damage to a U.S. weapons testing facility outside Ridgecrest, the Naval Air Weapons Station China Lake, although details were sparse early Saturday. “NAWS China Lake is not mission capable until further notice; however, security protocols remain in effect,” the naval base said on its Facebook page after the latest temblor. The installation is the Navy’s largest single landholding, sprawling over 1.1 million acres, an area larger than Rhode Island.
Anyone can sell software built from GPL code, but if/when they do so, they are obligated to provide source code for that software to anyone receiving a copy, and those users are permitted to redistribute both the software and the source code as long as they also adhere to the GPL.
Set you address as located in California. They are required by state law to allow you to unsubscribe via the web, and they enable that feature only if you say you live in the state.
That doesn't necessarily help when logs are sampled. Eg, for high volume services or endpoints, only 1 in X,000 requests might be logged, and you have no theoretical guarantee that you would ever catch any one individual request in your logs.
You need to install the Oculus software to use the Rift, but there is no requirement to have or link to a Facebook account, and afaik, never will be. To run software from outside the Oculus store, you simply go into the Oculus settings and flip a switch enabling external applications.
More OCP hardware (or designs that will eventually be contributed to OCP), in many different SKUs depending on use case. This page lists most of the current-gen hardware that I am aware of:
Facebook's entire blob storage and data warehouse (multi-exabyte) is run completely on OCP storage hardware built by ODMs, of which Quanta is included. Anyone telling you that we don't use OCP is grossly misinformed.
Source: I was on the blob storage team when we migrated all of our data from OCP's gen1 storage design [1] to the new gen2 storage design [2].
We likely won't even have an internal post-mortem for at least a couple weeks. There's no way you can possibly expect a full breakdown of what went wrong at this scale less than 24 hours after it gets resolved.
Generally speaking, the bootcamp process has a wide variety of different "classes" to take, covering a broad range of the Facebook stack, and no one engineer is ever expected to learn everything. So in this case, an embedded engineer would likely attend primarily backend focused classes, and would then choose from backend or embedded systems teams to work with, while someone interested in mobile or web frontend technologies would each have completely different experiences from everyone else. And ultimately, your experience coming into Facebook has far less to do with which classes or technologies you learn in bootcamp than what you're personally interested in. If you're interested in mobile, but only have experience in backend applications, that's fine – that's exactly what bootcamp is there for! We want to help you learn the technology or context that you're interested in so that you can find a role or team that you'll be happy to work on.
All engineering hires go through bootcamp, period. The only engineering hires that don't go through team selection are domain experts hired for a specific team/role ahead of time.
The possibility is there, but we haven't pursued any specific integrations yet. For obvious reasons, we would most likely work on Nuclide integration first, and something like VSCode support would probably need to come from the community. As Bowler is primarily providing the API framework, most integrations will likely just be plugins that make calls to the Bowler API, or execute the bowler CLI, with appropriate queries.
This sounds like exactly the sort of transforms and codemods that Bowler was designed to handle. Furthermore, we plan to support more linter-style features, and would like to have it integrated with tools like Flake8 or Phabricator, so that it can simultaneously find lints, and immediately suggest modifications to resolve those lints.
I haven't actually used RedBaron, but from glancing at the docs, it would look like there are two primary differences:
1) RedBaron uses a procedural API that modifies state continuously as you call methods on the class, whereas Bowler allows you expressive a series of queries/transforms up front, and then execute those all at once on your entire codebase. This also allows Bowler to provide a fluent API, so that you can chain all method calls from each other.
2) RedBaron uses a custom AST implementation, which still lists "Python 3.7 support" on its roadmap. Building on "fissix" (a backport of lib2to3) means that Bowler had day one support for Python 3.7 syntax, and already supports the provisional Python 3.8 syntax. This means your refactoring tools will never prevent you from adopting new versions of Python as soon as they are released.
No, it would not catch that, because it's not tracing elements through the AST. It would be possible to do some amount of tracing, but it would be impossible to catch and modify all variants of that, since Python is an extremely dynamic language. Imagine something like:
attr = "foo" if conditionA else "bar"
obj = A() if conditionB else B()
if hasattr(obj, attr):
...
Because of this, Bowler is focused on being more practical, and leans on the expectation that an engineer will be in the loop and validate the resulting diff, run unit tests, etc.
For something that simple, I would agree, but the demo is barely scratching the surface. I'd like to make a more in-depth version showing a more complicated transform, such as changing a function signature and having it update the callers across multiple files.
It was not built for the 2 to 3 migration, as there are plenty of great tools already out there for that, like 2to3 itself or futurize. It was built more for cases where we want to make changes to things like function or method signatures, and update both the definition and all call sites, across our entire codebase. It's still a very rudimentary tool at this point, but it was designed in a way that allows us to check in and reuse many components of the codemod, so that we can extract longer term value from these tools.
Notably, or notoriously, our previous codemod project just used regexes, which could result in ballooning complexity, especially when needing to modify code that might include type annotations. Bowler was designed specifically to allow refactoring against more complicated subjects, such as function signature changes, where you lose all predictability in formatting at both the definition and call site.
Author here: I created Bowler as a "hackamonth" project when I joined Facebook's internal Python Foundation team. We've already used it for a bunch of random codemods that touch a large number of source files throughout our codebase.
You can still add local tracks to playlists and sync those playlists to your phone. I have plenty of albums that don't exist in Spotify's cloud that I bring with me on my phone as "downloaded" playlists.