5,056 karma · joined February 1, 2011
For example, despite being much smaller than the Earth, Ganymede is projected to harbor more liquid water than all of Earth's oceans combined.
(Whether this adds up to 30% depends heavily on what you start counting as a "body")
That doesn't mean that there aren't also legitimate archeologists who might be excited about these prospects, but the lack of their mention is...suspicious.
This may work for small projects or open source projects that generally receive high-quality PRs, but this sounds truly infeasible for large teams or organizations.
There are a couple reasons why the code review process occurs before merging. First, it helps keep the canonical version of the codebase in a "correct" state. This is, ironically, an extension of the "not rocket science" principle that the article mentions. Without this invariant, any checkout of the codebase might contain what is essentially "WIP" code that will waste other engineers' time if they have to interact with it. Second, the social pressure of blocking someone else's work is an important and necessary force for motivating code review. The idea that folks will go back and review code that's already been merged is akin to "will add tests in a followup PR". It's a pleasant lie we tell ourselves, but it rarely comes true.
Relatedly, the article also seems to suggest that the code REVIEWER should be providing the changes necessary after code review. This is problematic for so many reasons: first, it places an even higher burden on code reviewers' time which no one wants; second, it encourages poor code hygiene if someone else is just going to fix up your crappy work later on; third, it robs junior engineers of what is perhaps their most valuable learning experience: getting feedback from more experienced engineers and acting upon it.
(there are other issues here; the general thesis of the article leans heavily towards making code easier to _write_ rather than _read_, which again I think it just not appropriate for a codebase with a significant lifetime or number of contributors)
I suspect that Google's RCS is proprietary as a blunt instrument to prevent carriers from trying to either (a) undermine e2ee in some weasely way or (b) have the ability to pick and choose the pieces of the implementation they want to support. You either get the whole thing, with e2ee that you don't control, or nothing.
Sadly the lesson from Google, Apple, and Whatsapp here appears to be "cooperating with telecom carriers is a fool's errand".
1. Open incognito window in Chrome
2. Visit https://t.co/4fs609qwWt -> 5s delay
3. Open a second tab in the same window -> no delay
4. Close window, start a new incognito session
5. Visit https://t.co/4fs609qwWt -> 5s delay returnsI get the sense that its advances are probably too low-level for most app developers to care, but that's kind of precisely why I'd love a comment elucidating them a bit.
Edit: For example, the Fuchsia docs list the primary talking points as secure, updatable, inclusive, and pragmatic. How well does it live up to those principles? Will they bring practical benefits? What's exciting/new about what's being done here?
I guess we could wish that the hornets never arrived here, but the life of a government is solving thousands of problems like these. If not the hornets, it would be something else. The uplifting moment is that this was a successful containment. Money well-spent :)
Especially considering the definitely-not-a-sock-puppet post by jimboykin [1], an account that was created immediately after this thread and has but a single post on HN.
The reason is that game devs are able to optimize their games specifically for the GPUs in the console hardware. Google is presumably betting that if they get enough market share, devs will start to optimize for _their_ hardware, and reap similar rewards.
Yes, I suppose it was kind of nice when the internet was only available to the tech-savvy, to those who didn't mind maintaining a second job as a Unix administrator. But for people who just wanted to _write_, it was not welcoming.
Yes, you can go to wordpress.com and sign up for your own blog, but then you're just on the wordpress platform, and subject to their whims. If your plan works, then wordpress.com becomes so big that they're the bad guys now.
Facebook, Medium, and others are here because we, the tech world, didn't give the rest of the world any other options. We didn't settle on a standard, containerized server platform that was simple enough for users to drag "Wordpress.server" onto "SomeHostingProvider.com" and get a working server. The tech ceiling was _always_ too high, and it was our own hubris that we weren't willing to build a more welcoming environment.
Almost all of these pieces date from after the unification of Japan under the Tokugawa shogunate (c. 1600). From 1600 to 1850 Japan experienced a stable period marked by very little real armed conflict. During this time, the samurai transitioned from soldiers to what were effectively mid-level bureaucrats. However, unlike most bureaucrats, they managed to retain all of the trappings of a martial lifestyle, including ornate armor, beautiful swords, and the occasional mortal duel. It was during this time of relative peace that these (sometimes ridiculous) fashion pieces developed, somewhat complicated by the tradition of incorporating pieces of much, much older helmets into the "core" of the helmets (one of the helmets in the OP has a core dating from the 14th century, but was significantly embellished later on).
†This is generally true of what arms and armor have survived from around the world. The stuff that was actually used rusted away long ago; the highest chance for survival was to have been so valuable that no one dared to actually take it onto a battlefield.
> The default driver on the distribution we support is broken.
They do test the default driver on the distributions they support. The tests show that the driver is unacceptably unstable. It may work better on other distros/versions, but they don't have time to test those. They're happy for others to help out in testing these unsupported combinations, however:
> Again, if someone wants to spend the time to test thoroughly to narrow down the blacklist, we will accept patches.
It's certainly not elegant that we build a proper security model from within a browser rather than an OS, but it might be the only practical approach (short of some large-scale migration to iOS/Android/Fuschia etc, which seems...unlikely.)
Remember, interviewing is volunteer work, not something that will advance your career. The results of the interviews and committee deliberation are confidential, so there's no way to gain a reputation for being a "great interviewer".
- A Google interviewer's (and I would assume any interviewer's) primary goal is to come out of the interview with enough confidence to give a positive or negative score. If they sit down to write feedback and have to give a neutral score, the interview wasn't productive. This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions.
- Doing interviews at Google is volunteer work. You are not interacting with a professional interviewer, you're interacting with someone whose day job is being an engineer. They don't have an evil agenda; they are doing this because they want to help Google hire the best candidates, and by inference make sure their future coworkers are good people to work with.
- Interviewers overwhelmingly _want_ their candidates to succeed. It's a true joy when I have a candidate who glides through a question (or finds a solution that was even better than mine). When candidates struggle, it's not a pleasant experience for the interviewer either.
- In the end, the point of technical interviews is to avoid the terrible experience that is working with an incompetent or uncooperative teammate. Interviewers are trying to find people that (a) can work well with others and (b) can get the work done.
- The system is _highly_ prejudiced towards suppressing false positives. This is the right decision, but it comes at the cost of a high rate of false negatives. Were myself or any of my colleagues to re-interview for our jobs, I would expect about a 60% hire rate. This is not even taking into account the constant ebb and flow of hiring demand. Sometimes there just isn't any headcount. And sometimes you just happen to get questions that you don't click with. This is also the reason that recruiters are so eager to bring you back to interview 6 months later.
- Recruiters and interviewers have very different incentives. Recruiters want to maximize the number of people they get hired; interviewers want to hire people they want to work with. This can lead to behavior that seems schizophrenic from the outside: the recruitment side of the pipeline constantly pestering people to interview, but once the candidate enters the interviewing pipeline the process is slow, deliberate, and careful.
So yeah, go use a proper functional language (many of which compile to JS!). Complaining that an imperative language isn't a soundly-typed functional language is tautologically true I guess, but who cares?
It's kind of you to gift the article with some genuinely thoughtful conclusions, but you're doing all the work there, not the original.
As the grandparent says, it's easy to poke holes in something, especially when disregarding important requirements that influenced its design. The fact that the OP can't point to any implementation of the "right" way to do things is telling.
This is a tradeoff -- continuing to support already-confusing differences is not worth the loss of the ease-of-use gain referenced in the grandparent.
> Matthew Hyland, [...] said he considered those all made-up names, some of which he deleted from the map
Unfortunately all place names are made-up names. If everyone suddenly agrees to start calling a place by a new name, who is Google to argue? But what if people can't agree and some start calling it by a new name and others don't? And of course you can't just poll every resident for their opinion, so you're stuck with relying on other signals...like local advertising and publications.
Appeals to authority are also of dubious value. There may be an "official" map somewhere, but if it doesn't reflect the day-to-day usage of the space, is it very useful? Prescriptivist maps generally enjoy about as much success as prescriptivist linguistics -- pretty to look at, but not what you want in your back pocket.
However, the implicit companion assumption that a resume with lots of clojure experience will have those skills is not something I've seen any evidence for. Many Clojure-focused candidates are unproductively dogmatic and are at risk of wasting everyone's time by trying to rearchitect our codebase because it doesn't meet their particular taste. In general, if a candidate is an adherent to a niche programming language they need to be able to explain to me when its use would be appropriate and inappropriate. If their answer is "this language and/or dogma is always better" then you're adorable but you need some more experience before I'm going to hire you.
It's also important to point out that, while my core requirements are the same for both jQuery and Clojurey candidates (ability to function in a large, complex codebase & ability to manage your own code's complexity), the specific skillsets are very different. Most clojure enthusiasts are actively bad front-end engineers. Which is fine! But many positions require engineers to at least be able to dabble in UI work, and if I get the sense that you would find it beneath you to do so, its probably going to mean better luck somewhere else unless I have a very specific position to fill.
- Followup to the above: because so much of the "work" involved with UI code involves interacting with another API, usage of that API tends to spread itself through the entire codebase like cancer. You can create a careful separation of concerns, but it takes a lot of upfront work, verbose boilerplate code, and constant vigilance -- if you're just handed an existing UI codebase you won't have that luxury.
- UI code is highly stateful and highly mutable. A core skill in UI programming is managing your app's enormous state profile. Single-path, whole-world rendering techniques like React/other shadow DOM techniques really help here.
- UI is highly temporal. It needs to change over time. Testing anything to do with time is an enormous headache. Animations can force you to temporarily separate your underlying state from its representation, which is a testing nightmare. But just in general, writing unit tests that involve time passing is infuriating and fragile (even if you can control time passing via a mocked clock object).
- A lot of core functionality in UI involves different pieces handing off to each other -- one window transitions to another window, etc. To test that properly you need integration tests, but now your integration tests also need to interact with the underlying OS/browser (because you can't separate any of that stuff out). So your integration tests are in general way flakier than you can get on UI-less systems that really only need to worry about faking out a DB of some kind.
This all boils down to the fact one group is trying to add a number of new entries to the list of censurable topics. It's fine to disagree with that, but then you have to state a) what topics you think shouldn't be added to the list and b). why. When people walk around loudly complaining about how they can't say anything anymore without being specific as to what they want to say, it suggests that perhaps they know that those positions are not really defensible.
[EDIT: To explain things a little more. Societies must limit some forms of speech because some speech limits who can be a member of a society. "We should murder all Asian people" is not compatible with a society that contains Asian people. And no, it is not fair to expect Asian people to have to constantly defend their humanity to others who have nothing to lose in the argument. Much as it's nice to think about abstractly entertaining every possible idea, when some of those ideas actively push out or dehumanize members, the society is forced to choose between accepting debate on the idea or excluding those members. So yes, if you want to complain about how SV society shuns people for not wanting to experiment on human embryos or whatever, go ahead. But assuming that all ideas should be up for debate is ignoring the fact that some ideas are incompatible with your fellow society members. And you get to choose between debating those ideas or having those people in your society as equals. You do have a choice, but you can't have both.]