shadowmatter
Joined 16 years ago
Joined 16 years ago
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 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.
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.
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
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?
That said, at least they adopted a Unicode encoding, and helped it establish mindshare.
Currently: Movin' money at Square
Previously: Backend developer at Airbnb, mobile developer at Khan Academy, lead developer on Burner, SWE at Google