Sourcegraph engineer here. I'd be interested to know what you were searching for and what your expectation for top result was. We already do things like boost class name matches higher than functions (GitHub's new search does the same) amongst other possible signals.
There is also plz.review which more closely mirrors gerrit (ui flow, keyboard driven, etc). Plus I found the cli more pleasing to use than graphites. But glad there are finally options in this space!
- Mark Brooker :: https://brooker.co.za/blog long time lead engineer @ AWS blogging technical info on distributed systems
- Chris Wellons :: https://nullprogram.com/ lots of interesting explorations in code
Also surprised by all these articles. But your point made me realise that most people didn't do accounting in high school like I did (also a South African). I wonder what some other uncommon high school curriculums from other parts of the world are.
In retrospect I wish what we learnt in High School was more focussed on personal finance than essentially constantly doing double entry data capture.
It's not compulsory, but it's available at GCSE and A Level; also in General Knowledge A Level I think.
Granted they have a bit of a reputation for being 'lesser' subjects. I don't really agree that everyone needs to be taught this though, most Britons don't have to 'do taxes', and aren't running companies. It should probably form a part of trades' apprenticeship training (and for all I know it does) due to the higher prevalence of self-employment (and thus running a business, and self-assessing tax even if not incorporated).
No accounting in the French general high school curriculum. And I can’t see it being introduced (it would be seen as an unacceptable intrusion of capitalism in education).
This is tricky but when you reframe it it's clear the heuristic you mention is the correct one. The value of a test is giving signal to a developer that the code they wrote is correct. If a test is flaky due to the test or the code, the signal the test provides has now become negative. The parent mentions filing it on the team that owns the test. This sounds correct and the onus is then on that team. At larger companies this process is automated. You may enjoy the flake detection section in this blog post https://dropbox.tech/infrastructure/athena-our-automated-bui...
FB is company D or E. FB you could have a linux laptop though, and could install linux on the mac. Not officially supported, but lots of people installed linux.
I was an h1b holder working in Silicon Valley. My wife not being able to work was the main reason why we left after 2 years. Kind of silly to go through that whole song and dance of getting a skilled person to move across the world only to treat the spouse as if the only purpose they have is home keeping.
We (I work at Sourcegraph) actually started off with a similar model to kythe: https://srclib.org/ This project existed before kythe was published, but was based on the ideas talked about pre-dating kythe. If I remember correctly Steve Yegge had some blogpost about solving the MxN problem, which turned into him doing grok at Google.
We ended up switching away from that model for a few reasons:
- At the time it was very costly to essentially index the whole OSS world, when most commit indexes would never be read.
- It was slow to index a codebase for a commit, and most of the work was wasted since a developer would often only look at a handful of files.
- Getting incremental indexing working usually required pretty deep integration into the build tool, so was a lot of work per language which didn't scale.
- A lot of tools using an "indexed" model end up only indexing the master/trunk branch, and you don't get your code intelligence features for PRs/etc.
At some point LSP came onto the scene. We were early adopters making a bet that this would take off. It has, and the list of community created LSP servers is large: https://langserver.org/ It also allowed us to switch from an upfront indexing model, to a model which just encodes user intent. So the underlying LSP server can be as lazy as it wants to be with respect to how it responds to the user == increased perf and reduced resources.
Things like cross-repo references doesn't come with LSP. Many LSP servers assume the user sets the build up correctly. There are also quite a few more assumptions LSP authors make which don't easily translate into an automated server environment. So we have done quite a bit of work to smooth that over / contributed some LSP servers for popular languages.
Seems like you are digging in so you might have more questions. I'll try keep track of this thread, but also feel free to email me keegan at sourcegraph.com or file issues/questions on our repo.
Thanks for the clarification. The approach makes sense. I am actually impressed by the lack of NIH syndrome, it is rare to see open source software integrated so effectively. That is
a +1 for protocol standardization
I can understand the "daily standup" being very useful to you as the manager. I'm interested if the engineers find it useful though. Personally, in both remote and local contexts I haven't found much value in them.
