shadowmatter

Even in lowly Java, they later added to Optional the orElseThrow() method since the name of the get() method did not connote the impact of unwrapping an empty Optional.

When I worked at Khan Academy, Charlie was an intern, and for a few months we worked together on building the KA app for Android. I can vouch that he was a damn good developer then, and I'm sure he's a much better one now.

Yeah, but it's the rank and file employees who will now think "I'm not there to defend myself against being fired if I take maternity/paternity leave" who will suffer most. The ones who won't be getting a severance larger than you can ever imagine.

Every other theory listed here is far more likely, but I would try changing your loop from using System.currentTimeMillis() to using System.nanoTime(). It's a higher-resolution time source that has no relation to wall clock time but is more appropriate for timings. Classes like Stopwatch from Google's Guava use it.

Agreed. Joda had the right abstractions (instants, durations, etc) but the class hierarchy for them was unnecessarily complex. A lot of this complexity comes from opting for the abstractions to be either mutable or immutable.

For example, `ReadableInstant` [1] in Joda implements 3 interfaces and has 7 subclasses. And really, what is the difference between `AbstractDateTime` and `BaseDateTime`? Whereas `Instant` from java.time [2] is an immutable value type and I haven't found it lacking in any respect.

On the whole java.time has struck me as extremely well designed (after coming from Python and previous date and time libraries in Java) and I think it would behoove other languages to liberally copy its design.

[1] https://www.joda.org/joda-time/apidocs/org/joda/time/Readabl...

[2] https://docs.oracle.com/javase/8/docs/api/java/time/Instant....

I have a horrible memory when it comes to the detail of books, movies, etc. (But thankfully I can remember what I've coded, or else I'd probably be out of a job.)

I mostly read non-fiction. To improve my recall over the past 7 years, I type up notes as I read. It's made the process of reading much slower, but it has helped when I've needed to recall some example or detail or framework of a book.

I did this (selfishly) for myself, but decided to upload my notes at https://github.com/mgp/book-notes. (Shameless plug I suppose?) The README explains exactly how I take the notes – but essentially there's no shortcut. I have my text editor open and simply type notes as I read.

Oops! My mistake – you are absolutely correct. Lombok was just so pervasively used in our services, I assumed it came included as part of the Dropwizard toolbox.

I used it extensively while writing Java code at Airbnb. (It came included with Dropwizard, which we used for writing services.)

Some people are uncomfortable with the extensive bytecode manipulation that it does. While Lombok provides annotations, it is not your normal annotation processor. From http://notatube.blogspot.com/2010/11/project-lombok-trick-ex...:

> Project Lombok hooks itself into the compilation process as an annotation processor. But Lombok is not your normal annotation processor... The trick is that Lombok modifies the AST. It turns out that changes made to the AST in the Annotation Processing phase will be visible to the Analyse and Generate phase. Thus, changing the AST will change the generated class file.

That said, we never encountered any Lombok-related problems when running services in the cloud or locally. And the Lombok plugin for IntelliJ is good enough in that the auto-complete will "see" the Lombok-modified version of the file. For example, using the @Value annotation creates an immutable value type, which among other things a) makes every field private and final, and b) generates a getter method for each now-private field. With the Lombok plugin, IntelliJ auto-complete will a) not auto-complete the composed fields which are now private, and b) auto-complete the generated getter methods.

I highly recommend looking past the voodoo bytecode manipulation and using Lombok. The @Value annotation alone is worth the price of admission and made me a more productive programmer.

I appreciate how the characters in the example are named Bart and Lisa.

Retrofit has support for RxJava, both of which are mentioned on the list. If Retrofit deserializes your JSON response payload as type T, then upon making a request it will return an Observable<T> that will either emit the result (if the request succeeds) or emit an Exception (if it fails).

Most Android applications that rely on both Retrofit and RxJava use them together in this manner.

As for too many requests pending, I'm not sure if OkHttp (which Retrofit uses for making requests and is again on that list) is configurable in that regard. If you want to handle it at the application level, you could maybe model the request queue to the network layer as an Observable<Request> and use RxJava's backpressure operators.

For more information on functional reactive programming (which I would call promises or CompletableFuture done better), see http://reactivex.io/

And for more information on RxJava, see https://github.com/ReactiveX/RxJava

But explicitly spelling out to your wealthy competitor all the ways in which you kick its ass likely improves your chances of being acquired.

I'm not going to lie, I didn't like this post as much as I wanted to.

The author says that Google is making the same mistakes that LiveNinja made over a year ago. And that LiveNinja has learned a lot and iterated since then. At this point, I'm ready to believe that LiveNinja is the more mature product. That if I have a need, I should probably go to LiveNinja. I'm ready to be sold... But then the author does nothing. He don't actually tell me WHY LiveNinja is better. Instead, he mentions Google Answers, Buzz, and Wave.

Why not drop the ad hominem, and sell to your potential customers instead?

From http://docs.oracle.com/javase/7/docs/api/java/nio/charset/Ch...: "The native character encoding of the Java programming language is UTF-16."

That said, at least they adopted a Unicode encoding, and helped it establish mindshare.

As another year ex-Googler, I'd say this is BS. Everything that superseded the "gconfig" days was pretty amazing, and IIRC the team behind it in NY did quite well for themselves. Steve Yegge wrote GROK, which is an internal tool, and I'm pretty sure no one around here looks down on him: http://www.youtube.com/watch?v=KTJs-0EInW8

"Think different"?

These slides look to be from the same deck. I wonder if there are more yet to come.

I like the idea.

Note that if there is a lot of text traffic on a given number, carriers like AT&T, Verizon, et al will block texts to and from that number until the traffic subsides. What's worse is that if you send a message to that number from the Twilio dashboard, its status will be "sent," but you will not actually receive it. Apparently in the world of SMS, "sent" simply means the message has been delivered to the destination carrier, and it is not a delivery receipt like with iMessage or BBM.

Twilio suggests that, to reduce this risk, you load balance across a collection of such numbers, or purchase a short code, which isn't cheap: http://www.twilio.com/sms/shortcodes

> I think my co-founders are idiots, that they fouled up their side of the deal, but I feel as though I've invested too much time and energy to bail now.

You've got to let go of this attitude. If you cling to it, then you will never leave, even if your co-founders are idiots and the business is a failure. What you need to do is quit as soon as possible. Only then can you start on a better endeavor and improve your quality of life.

I once heard someone say, "Give up on crap." It may sound juvenile, and it goes against the rosy, feel-good "Never give up" pep talks that we're used to and almost expect to hear. But I've found it to be a much better guide in life decisions. Go with it.

Youtube pre-Google was still Python, from the way several Youtubers have told it to be. Maybe an initial prototype was PHP, but not what was running when it was purchased.

And trust me, there is no way Google ever would have said "rewrite it in Python." They would have said "rewrite it in Java," like every other frontend they run (Gmail, Calendar, Docs, etc).

It's been awhile since I've read it, but I remember reading something along those lines in "Drive: The Surprising Truth About What Motivates Us" (http://www.amazon.com/Drive-Surprising-Truth-About-Motivates...). The thesis is that our motivation to do things is along a spectrum of intrinsic (for the love of the work) vs extrinsic (e.g. money). Generally the former yields better results. Some studies even showed that paying people to do things they love can be detrimental, because you're now adding an extrinsic motivator to something that they are intrinsically motivated to do, thereby making what they love feel like "work."

"John, I'm just been told that Groupon is announcing my termination tomorrow. If you could put me in touch with a PR person that's familiar with Battletoads, I'd be very appreciative."

I have word that #45 may have the solution in this issue: https://code.google.com/p/chromium/issues/detail?id=175341

Good list. My only thoughts:

Prefer itertools.izip instead of zip to avoid materializing a new list.

Appending the comma operator to the print statement suppresses the newline character and appends a space instead, which is how print 1, "world" works.

The only tip I'd add is using mapping keys in string formatting operations:

    >>> d = {'cow': 'moo'}
    >>> print 'the cow says %(cow)s' % d
    the cow says moo

Python wasn't phased out of consumer-facing applications because it was never in. Google has a lot of machines, but those machines receive a lot of traffic. Efficiency matters, and byte-for-byte, cycle-for-cycle, Java is more efficient than Python.

Don't ask me why Google didn't throw lots of resources at making Python more efficient like they did with JS and V8. I often wonder that myself.

Speaking as an ex-Googler, when I left, Python was largely relegated to glue code, scripts, internal projects, and App Engine -- consumer-facing frontends were written in Java, and backends in C++. He probably wanted to move to a company where Python was more pervasive, and he felt like he could have more of an impact, given that he _is_ the BDFL.

Here I was thinking that there's no way anyone would call anyone else a child molester on a mailing list, and then you go ahead and liken managers to terrorists. Suddenly his story has more credibility.

They're on Rackspace:

http://techcrunch.com/2012/09/18/patent-complaint-filed-agai...

https://github.com/blog/493-github-is-moving-to-rackspace

Agree that this only matters to 10% of the population. And yes, I'm totally oversimplifying it by creating only two categories. As to whether the distinction really exists, I personally believe that it does -- and the best anecdote I have is looking back on my reasons to leave Google. When I joined I wanted to work on hard/interesting problems, and when I left I wanted to work on interesting/impactful products.

I think there's a faction of engineers who want to work on interesting (which can be hard) problems, and those who want to work on interesting products.

I believe this is demonstrated clearly by the jobs pages for both Apple and Google. From Apple:

* Every detail matters… It matters all of the time. That’s how we do things at Apple. The result is some of the best-loved products in the world.

* Simplicity isn’t simple... It means rethinking every customer experience until the clutter has fallen away — until all that remains is what’s essential, useful, and beautiful. That might be a new product feature that delights even die-hard fans.

From Google, specifically an interview with Google employees about work there:

* ”... love to work on challenging projects”

* ”... love being faced with problems that were not ever solved before”

* ”... you hear people talking about algorithms and coding and programming languages”

* ”... it was just a pleasure being interviewed by smart people and being given a lot of puzzling questions”

I discussed this in a blog post I wrote which you can find here: http://mgp.github.com/2012/02/13/problems-and-products.html

I used to work at Google, and I joined there during a period when I wanted to work on interesting (i.e. hard) problems. I left to work on interesting products.

"A lie can travel halfway around the world while the truth is putting on its shoes." - Mark Twain (attributed)

Grubwithus occasionally has special dinners with noted authors, entrepreneurs, and personalities of any age. I'm sure if a dinner were focused around you, it would sell out really quickly. You had an exit that dwarfs anything praised around here...

Don't be shy!