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.
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.
> 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.
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/
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?
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
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."