lazaroclapp

Interestingly, there are basically two kinds of programs I am sometimes happy to see guided tours embedded in:

* Creation programs (image/video editors, 3D rendering... hell, even a slides program or an IDE). Doesn't mean I won't dismiss them sometimes anyways, but these are tools that often I do want to get an initial idea how to use, that I have allotted some time to play around with, and that are sufficiently complex that a tutorial is justified. These are also places were I can spend 2-5 minutes learning the basics of the tool, because whatever I am about to do with it is going to take the next few hours anyways.

* Videogames (i.e. the tutorial). For very similar reasons to the above ;)

Also, this is always on first install. Getting a tutorial on update for an authoring tool (and to a lesser extent a game) is far less likely to be welcome.

Actually, the technical advisory is even more pertinent to the HN crowd: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion....

And there is apparently already a discussion thread for it: https://news.ycombinator.com/item?id=40843778

Not sure if there is an official announcement to link here vs the toot, either way a very well deserved award and a success story for fundamental PL research influencing industry practice and vice versa.

The easy answer when bringing up something like IntelliJ is that we very much intend to go beyond the IDE (local edit-build-debug loop) and beyond an specific programming language (or set of related languages in the case of IntelliJ). But it is generally true that we aren't the first or only company to think about multiple parts of the development workflow. You could point to, say, Jetbrains Space as a better example of something from them in the same space (pun not intended).

We want to build an integrated development platform that goes from locally writing code, to code review, to continuous monitoring of code quality, to enabling automated dependency upgrades and migrations, to compiler optimizations guided by usage data and constraints. That doesn't mean that every tool in the platform will be something we build from scratch, though, we are looking to integrate with existing developer tools along a number of supported "golden paths", besides making our tooling available a la carte for others.

For linting, specifically. It's easy to add linting frameworks and checks, for most languages, but there are a few things we need to be considered when a diagnostic is surfaced locally: - Is it a suggestion or an actual error? - Is there an automated fix available? - Is the right set of checks turned on for the right subset of the code?

Then there is also the aspect of visibility and observability. Here is an example of an issue for which a lint was readily available, but ignored: https://imgur.com/a/wWqa0Wg. We believe that's common and not a matter of human error, but a direct consequence of the tooling not surfacing the issue in the right ways or providing an easy path to fix it once the code is already in the codebase.

Or, consider code refactoring. Many IDEs support code refactoring with full AST information, but for large codebases it can hit limits fairly easily: for a large monorepo, it might not scale in the sense of being able to keep all code indexed in memory within the same session; for a set of microrepos, it can struggle to perform refactorings across repo boundaries. One approach here is to build a powerful refactoring engine and expose it via integrations to the IDE (including IntelliJ!), code review system, and some sort of global management UI.

For each of the questions above you can find potential solutions, both from companies and in open-source, and yet, companies that can afford it benefit from having a "dev platform" team integrating, customizing, and maintaining various such tools benefit from that investment. I'd argue there isn't currently a clear go to answer for "Developer Platform as a service", particularly one that doesn't care to tie you to a particular language or stack.

A cliche, perhaps, but build times and land times have always been a top priority of developers, particularly as tooling, specially code analysis, grows more complex. Developer tooling should be as blazingly fast as we can make it! (And obviously we aren't the only ones aiming for that, but it's good to have it as an explicit top priority!)

Well, an IDE is not fundamentally out of scope, but for the foreseeable future the plan there is more along the lines of plugins for common IDEs (e.g. VSCode, Jetbrains) and integrations with existing code review and code hosting services (GitHub, GitLab, etc.).

We want to integrate with a few reasonable permutations of a development environment and overlay stuff like dead code deletion and refactoring (Already got a tool for that! More to come soon, but that's not the full business for us, just the first feature), static analysis (see NullAway/NilAway for examples that go beyond basic linting), tools for managing compatibility between dependencies and fixing flaky tests, and LLM-based code transformation and code review tools. At some point or another we have talked about how we'd rebuild each and every step of the development process (up to including version control), but for now there are easier and more urgent problems we think we can solve than that or building a new IDE :)

Hi, everyone! We are some of the authors behind Uber’s OSS developer tools, which have appeared in HN previously, including: Piranha (automated stale flag cleanup and code refactoring), NullAway/NilAway (NPE/nil panic static detection), OkBuck, etc.

While we think all those tools are great (they are not going away and there are hopefully more to come both from us and from the team remaining at Uber!), we believe that the main thing a developer platform team brings to a company is an integrated experience. We started Gitar to provide that same experience across multiple companies, including those which do not (yet) have a large developer platform team!

We have plenty of ideas (starting with some interesting tooling around code refactoring!), but also happy to hear about the challenges you all see at various scale companies related to developer experience and tooling.

No worries, that's how I understood it too :) Just adding a bit more context on why we feel the approach does beat "grep panic" for people checking out this thread.

We'd be interested in the general characteristics of the most common ones you are seeing. If you have a chance to file a couple issues (and haven't done so yet): https://github.com/uber-go/nilaway/issues

We definitely have gotten some useful reports there already since the blog post!

We are aware of a number of sources of false positives and actively trying to drive them down (prioritizing the patterns that are common in our codebase, but very much interested in making the tool useful to others too!).

Some sources of false positives are fundamental (any non-trivial type system will forbid some programs which are otherwise safe in ways that can't be proven statically), others need complex in-development features for the tool to understand (e.g. contracts, such as "foo(...) returns nil iff its third argument is nil"), and some are just a matter of adding a library model or similar small change and we just haven't run into it ourselves.

Actually, if we were running into cases where we aren't logging a panic which is actually happening in production, then the first thing to note is that we need to improve our observability. The issue might or might not be recoverable, but it should be logged. If nothing else, it should show up as a service crash somewhere within those logs, which is also something that service owners monitor and get alerts on.

The advantage of NilAway is not just detecting nil panic crashes after the fact (as you note, we should always be able to detect those eventually, once they happen!), but detecting them early enough that they don't make it to users. If the tool had been online when that panic was first introduced, it would have been fixed before ever showing up in the logs (Presumably, at least! The tool is not currently blocking, and developers can mistake a real warning for a false positive, which also exist due to a number of reasons both fundamental and just related to features still being added)

But, on the big picture, this is the same general argument as: "Why do you want a statically typed language if a dynamically typed one will also inform you of the mismatch at runtime and crash?" "Well, because you want to know about the issue before it crashes."

Beyond not making it all the way to prod, there is also a big benefit of detecting issues early on the development lifecycle, simply in terms of the effort required to address them: 'while typing the code' beats 'while compiling and testing locally' beats 'at code review time' beats 'during the deployment flow or in staging' beats 'after the fact, from logs/alerts in production', which itself beats 'after the fact, from user complains after a major outage'. NilAway currently works on the code review stage for most internal users, but it is also fast enough to run during local builds (currently that requires all pre-existing warnings in the code to either be resolved or marked for suppression, though, which is why this mode is less common).

Native Spanish speaker here (ES-MX, specifically, if it matters). I think this is one of the cases where a solid general rule breaks down in the specifics.

You are correct about the difference between "ser" (to be, permanently/over an indeterminate time) and "estar" (to be in a particular state right now). But "No soy feliz" sounds perfectly idiomatic to me, even for a relatively transient state of sadness. ("No estoy feliz" doesn't sound wrong to me either, but feels just slightly less natural than "No soy feliz" even in a context like "No soy feliz ahorita", with an explicit "right now").

As a note: "No estoy contento" (Also "I am not happy", or maybe "I am not in a good mood") is definitely "estoy", rather than "soy". No clue why "No soy feliz" does feel idiomatic.

> Isn't this pretty much the description of every company?

For the most part, sure. But that's the parent's point, I think. Central banks are not companies, they are part of the public financial infrastructure of a nation (or, in the EU case, group of nations).

While admittedly not as nice as having it built into the type system from day one, there are a number of tools one can integrate into their build to add various degrees of null safety to Java.

Disclaimer: I am one of the maintainers of one such tool, namely https://github.com/uber/NullAway

It certainly won't help with verbosity (in fact, it does the opposite to at least a small degree :)), but it can dramatically reduce the number of actual NPEs when running your Java code.

Obviously I am not saying this is a reason to not use Kotlin. But, when, e.g. based on the things mentioned elsewhere in this comment section, you are deciding to stick with Java for a particular codebase, it doesn't mean static null checking is not an orthogonal option to consider.

Since this can make you think your cursor is in a different position in the page than it actually is, couldn't it potentially be used to mislead you to click outside the page as well? Possibly not into browser chrome[1], but what about on a iframe?

Place button A the user wants to interact with at position (X,Y), place iframe button B at position (X+W,Y), with as little a border as possible with the rest of the page, then offset fake cursor by -W. User will try to mouse over button A, mistakenly mouse over button B, and click it in the time it takes to register that the mouse pointer just jumped from the edge of one button to the edge of the other...

[1] Though I can see the trick below maybe working for some browser's permission request "tooltip" UIs...

Independently of that, an exceedingly large number of countries require visas from Chinese citizens. See https://en.m.wikipedia.org/wiki/Visa_requirements_for_Chines...

This squares ok with geopolitical reasons, but not economic ones (although they certainly influence that map now and in the future).

If this were the only criteria, then Chinese passports would be accepted visa-free in a lot more countries than they currently are. Not saying that travel bans will remain in place once the current pandemic ends (which might take a while still), but "high spend potential" is not the sole determinant for this kind of polices when outside of a worldwide health emergency.

Presumably, Germany would have little trouble compelling at least one root CA to sign any TLS certificates they wanted. Just a cursory search shows that Google Chrome, on Linux, trusts, e.g.

> CN = D-TRUST Root CA 3 2013 > O = D-Trust GmbH > C = DE

There is certificate transparency and pinning and so on, and they would be caught (probably, maybe) if they abused this carelessly and at scale, but in practice, for a small number of targets, it would be trivial to wait for users to connect to a less secured TLS site or even a plain-HTTP site (plenty still exist), and then use a browser exploit as the stage 1, followed by whatever escalation of privilege exploit and rootkit is needed. TLS is really good at preventing always-on dragnet surveillance of everyone's internet traffic, but not a counter measure against targeted nation state level attacks.

Just as an extra note: there are manual testing steps (and automated end-to-end test, and internal alpha test, etc), independent of whether the diff was Piranha- or developer-authored, but all those happen for the continuous delivery internal version of the app, which is after the diff has been landed to master, but before a release is sent to app stores. We would count an issue discovered there as an outage having made past "our tests", even though it could well be caught before it gets to any external users.

> When you set a feature flag, normally you should put a deadline on it, after this deadline, you should either choose to keep it, or remove it or you can extend the deadline.

This is actually a feature we did identify as important to have in order to increase Piranha's effectiveness, and it is being added to our internal flag tracking, but it doesn't negate the need for the tool. An expiration date makes it easier for the tool to know when to run on a given feature (rather than using heuristics based on % rollout and days without changing the experiment), it still means that Piranha: a) reduces manual effort by auto-generating the (candidate) removal patch, and b) acts as the reminder portion for the expiration, so it's more actionable than just adding a task.

The thing to note is that, even on a steady state where flags are removed as soon as they go stale, enough new experiments are being created every day that reducing the time spent cleaning them up is valuable.

Also, you definitely don't want to block someone from fixing a crash because they have pending expired flags, so all you can really do with any expiration policy is to remind them. With Piranha, you are reminding them and reducing the friction to solve the issue. After all, the diff is right there for them to review and click 'land' on.

As for the hardcoded flag value in your example above? What does that accomplish? It looks to me like you'd only be shipping dead code, since there is no runtime way of re-enabling the `RIDES_NEW_FEATURE` behavior (which is the main difference between "rolled 100%" vs "Piranha-removed"). It also makes harder to remove the related code later, since the semantic information about it being part of the feature is lost. If it's just about having the old code available, then version control does that already, no? What am I missing?

Most of the existing Android codebase is Java. There is some Kotlin code, and PiranhaKotlin is certainly in the roadmap somewhere but, especially when the goal is removing older features, Java makes the lion share of the use case for such a tool right now.

We used Google's Error Prone framework. Pros: you get full compiler symbol/type information, in addition to the AST. Cons: you need to build the code to process it (Error Prone runs as a javac plugin), and if you want to do things efficiently then you are restricted to basically a single AST traversal. It's very use-case dependent whether you are better off just using e.g. javaparser.

Piranha co-author here. I'd say you trust it a bit more than we do, then ;) As the paper and blog post mention, we use Piranha to create diffs/PRs against the original author of the code. Developers are expected to code-review the changes before they are ever landed. As used within Uber, Piranha won't ever auto-land code deletions.

That still saves the time of: a) remembering that the flag is stale and must be removed, b) actually removing the code and putting the diff up. Piranha diffs for a single flag are also generally small enough to fully read them during code review.

We do have comprehensive unit tests for both the Piranha tool and the target codebase(s), and the majority (65%) of diffs generated by Piranha are landed without changes (and the most common change in those that are changed is to delete extra lines that Piranha couldn't prove as stale). Thus far we haven't had an outage caused by a Piranha deletion, but certainly there have been incorrect diffs generated and caught either by CI or manual reviewers, requiring us to update the tool. We would not recommend landing diffs generated by Piranha - or other stale code removal tools - to master without any reviews right now :)

> The way Uber brands them suggests that they're suitable for use in production environments, but so far that hasn't been the case with anything they open sourced outside a narrow envelope that resembles their own operating model.

Not a contradiction. Many of these tools are suitable for use in production, almost by definition, since they are being used in production, at Uber. They might or might not work in your environment out of the box. But they are certainly often likely a better starting point than an empty editor, even when they do not. Most of the ones I am familiar with, are happy to get PRs generalizing them to more varied environments.

> they're nothing more than interesting repos amongst a sea of interesting repos.

As someone who has open-sourced on GitHub: research prototypes hacked together for a research paper deadline in grad school, class projects, for-fun hacks, and also production tooling I built as a paid engineer, I'd say there is a big difference! :) And there would still be a big difference even if the later were somehow never touched again after the first "we are open-sourcing this!" commit.

That said, we do try to maintain the things we open-source. Standards of support vary because individuals maintaining these projects, and their situations, vary. This is true for non-OSS internal tools too. In my experience, having gone through the Uber OSS process twice, and having started it a third time and decided against releasing (yet?), Uber does try to make reasonably sure that it's open-sourcing stuff that will be useful and is planned to be maintained. At the same time, they have to balance it with making it easy to open-source tools, otherwise too many useful things would remain internal only.

Also, note, some of these tools have exactly one developer internally as the maintainer, and not even as their full time job. For example, I am the sole internal maintainer[1] for https://github.com/uber/NullAway and also have 3-4 other projects internally on my plate, most of which are in earlier stages and need more frequent attention[2]. If and when said developer leaves, effort is made to find a new owner. This is not always successful, particularly if the tool has become non-critical internally. Sometimes, leaving owners retain admin rights on the repos and keep working on the tool (Manu, NullAway's original author, co-maintains it), but I don't think anyone is suggesting that that should be an obligation.

Finally, obviously, nothing here is the official Uber position on anything, just my own personal observations. This doesn't represent my employer, and so on. I am also pretty sure most of this is not even Uber specific :)

[1] Not the only internal contributor! Also, there is one external maintainer, as mentioned a few sentences later. But in terms of this being anyone's actual responsibility...

[2] Just to clarify, I think between Manu's interest, my own, and it being relatively critical tooling at Uber, NullAway is pretty well maintained. But I can understand why that isn't always a given for all projects.

> It's even a truism now that computer defence against a well funded nation state is hopeless.

This was arguably true (in the case of targeted attacks) even back then. That some civilian law enforcement agencies (and apparently the Secret Service) were clueless about SIGINT back then, doesn't mean that the same was ever really true for major spy agencies.

Here is 1945's Stuxnet, for example: https://en.wikipedia.org/wiki/The_Thing_(listening_device)

It's using the term as in definitions #2-3 (particularly 3b) here: https://www.merriam-webster.com/dictionary/colony, not #1. They mean colony as in "a colony of ants", not the political structure.

Sure. Definitely already a thing! I know plenty of people from the US who joined a company in the US with international offices and then transferred (temporarily or permanently) to an office somewhere else. Singapore comes to mind, but I am sure the case for Canada is even easier (given NAFTA and similar).

You could also just directly apply to a position that happens to be in Canada, e.g. https://careers.google.com/locations/toronto/?hl=en

By the way, you actually might not need any FAANG (or other Canadian employer) help: https://www.canada.ca/en/immigration-refugees-citizenship/se...

> How long is "reasonable" relative to iOS? I recently moved from Android to iOS mainly because of this.

4 years, basically.

Nexus 6 was supported for all security updates from launch in November 2014 to this month (November 2018). In terms of feature updates, it got up to Android 7.1.1, and I am not aware of any major app that wouldn't run on that today. Not exactly great, but certainly not a new phone per year. I believe Apple's policy is 5 years, rather than 4, with a reported risk of iOS updates purposefully making the original hardware performance worse (e.g. battery life).

Strictly as a geeky side note, if you have the time to spend DIYing your primary mobile OS (which, admittedly, very few people would prefer doing), there are pretty cool third-party Android distros and other OSes that will keep a Nexus 4 (2012, 6 years old) alive and well. Possibly a Galaxy Nexus (2011, 7 years old) too, but I am less sure about that...

Edit: To clarify, what I am saying is that, for most users, iOS' long term support is better than Android's. But, for Google phones and the like, it is only slightly better, not day-and-night better.

A microphone and some basic ML?

Sort of tongue in cheek, since I don't know the range of state of the art acoustic side-channel taps. I guess you'd also probably have power fluctuations and network timing channels to exploit.

Plus, a lot of different points at which to attempt to insert a second stage into the connected devices themselves, using all the tricks everyone else in this thread has mentioned.

Ok. But then, which Mac would you use as a build server? Mac servers no longer seem to exist, iMacs and Mac Pros are not stackable, you can't build iOS/OSX apps on a standard linux box, and laptops have the same issue as the Mini. That's why a Pro-focused Mac Mini, with even a mid-end desktop CPU and reasonable RAM would be ideal here, and a Mini with a modern laptop CPU would still be a vast improvement of the current situation.

No. But could they prove it with the standard FB app either? I mean, you are typing your user name and password on that phone, if you assume the manufacturer is outright malicious, then official API access doesn't really matter one way or the other. An API used to create a third party client is generally a good thing and doesn't actually change this (unless I am missing something here).

You could, however, with some trouble, check which data is going where on your own device, as long as that API isn't meant for direct connection between FB servers and those of a third party.