2
points
beder
Joined 128 karma
I'm a mathematician-turned-Googler, and I write games in my spare time.
- I agree, and even moreso, it's easy to see the (low!) cost of throwing away an implementation. I've had the AI coder produce something that works and technically meets the spec, but I don't like it for some reason and it's not really workable for me to massage it into a better style.
So I look up at the token usage, see that it cost 47 cents, and just `git reset --hard`, and try again with an improved prompt. If I had hand-written that code, it would have been much harder to do.
- A very pedantic point, but merge keys are not part of the YAML spec [1]! Merge keys are a custom type [2], which may optionally be applied during the construction phase of loading. I definitely wouldn't say that merge keys are integral to anchors.
(Also, as a personal bias, merge keys are really bad because they are ambiguous, and I haven't implemented them in my C++ yaml library (yaml-cpp) because of that.)
- At one point at Google, there was a huge chunk of code that was hard to understand, probably at the wrong place in the network stack, and stubbornly hard to change. And it kept growing, despite our efforts. We renamed it "[Foo]Sorcery" (this was about 10 years ago); people stopped trying to add to it, and periodically someone would come in and remove parts of it, all thanks (I think) to the goofy (and somewhat scary) name.
- 2 points
- Agreed, Dennett hit all of the high points of the who-am-I philosophy in a really entertaining story. It also reminded me of a great Greg Egan story, Learning To Be Me:
https://philosophy.williams.edu/files/Egan-Learning-to-Be-Me...
This is focused on just one aspect of the philosophical dilemma, and both Dennett and Egan touch on the horror of it in delightful ways.
- Here’s an example for chess: I found that I was repeating the same lines and the same ideas over and over during matches. One of the key points in the book is to simply observe what you’re doing without judgment. I realized that I’d fixate (especially under time pressure) on an idea that didn’t work.
I tried working on this with deliberate practice on cycling through different areas of the board. There’s a mental feeling (not too different from the physical feeling of swinging a racket) of working through a line, and then moving to another area and trying a different line.
- The author mentions “The Inner Game of Tennis” as an example of how to train in images and feelings, not words, and I highly recommend it to basically anyone, not just tennis players.
If you’re doing anything that you might hear “don’t overthink it”, then it’s for you. It was recommended to me by a friend who played competitive Foosball; I read it as an instructional about playing chess; and later, after starting to play tennis, I read it again, and I think it’s equally applicable to all of those.
- I was on board for points 1 and 2, but completely disagree with 3:
> The components might look wrong when rendered. Tests are very bad at this. We don't want to go down the esoteric and labor-intensive path of automated image capture and image diffing.
This is the main reason we have tests for our (Angular) typescript all; all the tests roughly look like:
1. set up component with fake data
2. take screenshot and compare with golden
3. (maybe) interact with component and verify change
These are super easy to write, and also easy to review: most review comments are on the screenshots anyways. And since the goldens are checked in, it’s easy to see what different parts of the app look like without starting it up.
- She was claiming something more fundamental (and less sophisticated) than that. Nigel Boston and Andrew Granville wrote a review [1] of her book that distills some of the problems with her argument. A sample quote:
> In fact, her central theme is that non-Euclidean geometry, and indeed any mathematics related to non-Euclidean geometry, is nonsense.
- I wrote a semantics doc to try to help on the documentation front:
https://google.github.io/dagger/semantics/
It's not intended as a tutorial, so perhaps it won't quite meet your needs, but if you're curious how all the pieces fit together, it may help.
- (Disclosure: I work on Dagger in my 20% at Google.)
What's more, Dagger gives you (compile-time) insights into the graph of dependencies.
For example, we've hooked up our internal code-search tool to give you Dagger cross-references, so if you (e.g.) click on a parameter to an @Inject constructor, you'll see the place that provides that object.
Also, if you click on the @Component, you'll see a visualization of the entire graph.
We're working on surfacing these hooks in the open source repo, which would allow IDEs like Eclipse to gain this functionality as well.
- This is an incredibly interesting area of mathematics, and it's disappointing that it's dying out. When I was an undergrad, I wanted to go into this field, but I was dissuaded by my advisor because of the direction it was going (fewer active researchers means fewer PhD positions, and ultimately, fewer academic jobs).
I'm glad that there's an effort to consolidate and simplify the proof, since as they say, it could end up effectively lost forever.
- 44 points
- In that case, you should divide by "expected", so you get a percentage difference for each day. (Normalizing by total for the year doesn't make sense, since imagine that there were 300 days per month instead of 30 - your numbers would be divided by 10 again, but the data you want to visualize would stay the same.)
- A few comments on the stats themselves:
1. It looks like the total number of tickets in 2009 and 2010 is about 10% that of 2011. I'm guessing that there weren't actually ten times as many tickets given in 2011, so either the data is incomplete (as the author suggested), or there was a typo. If the data is incomplete, I'd suggest normalizing to the 2011 totals; otherwise, the 3-year average doesn't make much sense.
2. The scale of the "normalized" difference graphs (showing "Actual - Expected"). The formula given is
(actual - expected) / total * 1000 = normalized number
If this is the case, then since the scale goes to about +/- 5, the differences are very small (less than 1% away from what you'd expect!). But from eyeballing the data, that doesn't seem right.
In any case, a better scale might be to expect the data to be normally distributed, and scale the differences to # of standard deviations. (See, e.g., http://en.wikipedia.org/wiki/Normal_distribution#Standard_de...)
- There's plenty of discussion relating to the article he references at http://news.ycombinator.com/item?id=4455225, and much of the same applies here.
1. He's not comparing apples-to-apples between `std::list` and his intrusive linked list; the proper analogue would be to unlink a node from its iterator, for which the running time is still O(1).
2. The main (only?) reason to use intrusive lists is for the single indirection (which helps both memory and speed). In his example for how using std::list would crash his server because of the O(N) node removal, he's just not storing the right data for each connection (again, use an iterator).
3. He looked at boost's intrusive list, but I'm guessing he didn't actually try it out. The examples are pretty good, and it's much easier than it "looks". (That is, boost libraries can look intimidating when you first look at them because they're so template-heavy.)
4. It may even be that a vector, plus an auxiliary data structure for lookup, may be faster.
- > On his LinkedIn page, Mr. Milner lists his occupation as “hacker,” and under the category called “Specialties,” his entry reads, “I know more than I want to about Wi-Fi.”
While I don't know for sure which use of the word "hacker" Milner intends, the author of this article ought to have added a line like, "Software engineers use the word 'hacker' in a positive, non-malicious sense...", since this is effectively taking his words out of context.
- @ghempton, if you're still reading these comments, it's likely you're passing a iOS 4 or 5 message without checking to see if the message is received.
I ran into this recently with a number of simple startup checks, e.g., if the device is a high-res ([UIScreen scale]) or if it's an iPhone vs. iPad ([UIDevice userInterfaceIdiom]).
- There is a touch arcade thread that people occasionally visit, but most of our contact with our users is through email. We're planning to add a direct email link in our "about" page in the game (we already have a link to our website), so hopefully that will make it easier for people to contact us.
(We readily admit that we're pretty bad at forming a community. This is a spare-time thing for both of us, and neither of us uses twitter, facebook, or really any social service, much personally, so we feel a little like fish out of water when it comes to the social aspect of the game. We have a level editor, but no way for people to share levels outside of the game itself, and no way for people to talk about levels they make. We're getting there...)
- I understand that, and it's happened to me a few times also.
But I still feel like the first response, if it's possible, should be an email. We're just a couple of guys, and both our website and our game's credits make it clear that we're not a major faceless company.
I suppose people are conditioned by large companies ignoring them, so I hope that the proliferation of indie developers in the App Store can recondition people to actually send emails.
We love getting direct email from people, and we respond to every single one. I think people are sometimes surprised to get a personal reply; hopefully that won't be such a surprise if enough developers do it.
So I think the lesson here is wrong too - when the manager said
> These tasks aren’t business priorities and had no impact on customers and other teams
that didn't mean they were worthless tasks - just that they weren't business priorities and had no impact on customers or other teams. Which is probably true(ish - I would have phrased it very differently if I were their manager).
Improving the release process is great, and helps the team a ton - and indirectly helps customers by enabling the team to ship faster. This is incredibly valuable! And at the right scale, it can be a staff job: at my Large Tech Company, I know several people that have been promoted to staff SWE for this kind of work, but it's for systems that hundreds of SWEs work on. I also know people that have been promoted to senior SWE for this kind of work - these are systems that tens of SWEs work on. It sounds like this example was more like that - this person was doing a good senior SWE job, and the manager didn't see any reason to course correct given that they had given no signal they wanted to get promoted.