I am a serial reader, but only in the sense that I can't read concurrently. I'm really just here to scope out what other people like.
This link opens in a pop-up window
When Pentagon bioterror operative Roberto Diaz was sent to investigate a suspected biochemical attack, he found something far worse: a …
The future is blue. Endless blue...except for a few small places that float across the hot, drowned world left behind …
A fast-paced, thrilling horror novel that follows a group of heroines to die for, from the brilliant New York Times …
It has a dark past—one in which a number of humans were killed. A past that caused it to christen …
Data is fundamental to the modern world. From economic development, to healthcare, to education and public policy, we rely on …
My name is Kvothe.
I have stolen princesses back from sleeping barrow kings. I burned down the town of Trebon. …
WINNER OF THE 2017 PULITZER PRIZE GENERAL NON-FICTION
From Harvard sociologist and MacArthur “Genius” Matthew Desmond, a landmark work of …
A former Wall Street quant sounds an alarm on the mathematical models that pervade modern life and threaten to rip …
Kind of a black mirror + humor with just enough domain knowledge to make it clever.
"Red Rising thrilled readers and announced the presence of a talented new author. Golden Son …
Fun series.
Brandon Sanderson debutó en 2006 ante los lectores en castellano con Elantris, una novela de fantasía épica que marcó un …
"Hollis Henry worked for global marketing magnate Hubertus Bigend once before. She never meant to repeat the experience, but she's …
Even bad code can function. But if code isn’t clean, it can bring a development …
Lots of SOLID advice (sorry, had to) , though I do think that the fact that it's written for early 00s java limits it in that it doesn't really address functional map/filter/reduce (select/where/accumulate) type stuff that more modern versions of java and pretty much all other languages allow for.
Main takeaways:
1. Names are important.
2. Functions/classes should be small
3. Comments on something that's not a public API are out of date the moment they're written. Just go crazy with privately named functions.
4. Refactor a lot
5. Inversion of Control / Dependency injection is neat - But really this was written at a time when the DI configuration step was terrible to write. I think .Net core handles this stuff really well now, and I'm sure the java frameworks do just fine.
6. Functions with a lot of arguments are terrible, maybe even evil
I don't know that …
Lots of SOLID advice (sorry, had to) , though I do think that the fact that it's written for early 00s java limits it in that it doesn't really address functional map/filter/reduce (select/where/accumulate) type stuff that more modern versions of java and pretty much all other languages allow for.
Main takeaways:
1. Names are important.
2. Functions/classes should be small
3. Comments on something that's not a public API are out of date the moment they're written. Just go crazy with privately named functions.
4. Refactor a lot
5. Inversion of Control / Dependency injection is neat - But really this was written at a time when the DI configuration step was terrible to write. I think .Net core handles this stuff really well now, and I'm sure the java frameworks do just fine.
6. Functions with a lot of arguments are terrible, maybe even evil
I don't know that I'd follow this to a tee. Conceptually I think the rules are fine, although I'm not sure I love excessive private function use with forgoing function arguments for private attributes. I understand that within an object, private attributes are fine things to go side affect crazy on, but I think that with web controller type request/response stuff, that sometimes it's just a little more straightforward and testable to have the endpoint method own the scope of the variables and just output the right thing without mutating the state of the object. Obviously the services it calls would still be injected into private attributes. Maybe in other contexts/application types it would totally make sense to keep it a bit more heavily OOP and encapsulated and all that good stuff.
Overall I think it's a good book and a great starting point for thinking about code styles, readability and consistency.
