You need to sign in or sign up before continuing.
Take a photo of a barcode or cover
books_are_nice_and_enjoyable's Reviews (257)
adventurous
dark
tense
adventurous
The first part of the book is quite similar in many aspects to the initial sections of The Fellowship of the Ring, so if you like Tolkien you'll probably like this one as well. A very engaging narrative.
Hard to rate. If you're working at a publicly-facing-IT-service-as-a-core-business-company like Slack or Google there are probably a lot of useful ideas here (though hopefully Slack guys should be aware of some of them already..), and in some sense the book is also interesting simply on account of the fact that you get some insight into how companies like these approach problems like the ones covered in the book. In general, if you're not working extensively with distributed systems much of the book's content will simply not feel relevant to you.
The authors seem to have a very skewed perspective on many things and it makes the coverage feel less relevant to people not part of 'their' own environment; incident response times measured in seconds is all fine and nice and it may matter a lot to a company like Facebook. But in many successful companies, where IT services is not 'the core business', aiming for that kind of service level would just be idiotic because the value derived from that kind of responsiveness would be totally out of proportion with how much effort it would require and with what could otherwise be delivered using the same resources. It's so far from the reality of how things might be done that it risks making the coverage appear utterly irrelevant.
Some good ideas and interesting notions are included in the book, but it was hard for me to get all that excited about the coverage. The authors work for Honeycomb and although they did talk to some people who did not there were definitely many other people they did not talk to prior to writing the book, and you can definitely tell they didn't if you decide to read along.
The authors seem to have a very skewed perspective on many things and it makes the coverage feel less relevant to people not part of 'their' own environment; incident response times measured in seconds is all fine and nice and it may matter a lot to a company like Facebook. But in many successful companies, where IT services is not 'the core business', aiming for that kind of service level would just be idiotic because the value derived from that kind of responsiveness would be totally out of proportion with how much effort it would require and with what could otherwise be delivered using the same resources. It's so far from the reality of how things might be done that it risks making the coverage appear utterly irrelevant.
Some good ideas and interesting notions are included in the book, but it was hard for me to get all that excited about the coverage. The authors work for Honeycomb and although they did talk to some people who did not there were definitely many other people they did not talk to prior to writing the book, and you can definitely tell they didn't if you decide to read along.
I decided to start out with this book, instead of reading Jordan in the order the books were originally published; I figured this approach just made more sense.
It's an enjoyable and engaging book. Moiraine, Siuan and Tam are definitely all characters I'd like to follow in future books as well.
It's an enjoyable and engaging book. Moiraine, Siuan and Tam are definitely all characters I'd like to follow in future books as well.
adventurous
lighthearted
relaxing
Funny and engaging. An enjoyable little book.
SQL Cookbook: Query Solutions and Techniques for All SQL Users
Robert de Graaf, Anthony Molinaro
Not terrible, but also not particularly great.
This book is significantly longer than it needed to be in order to cover the material included and the registered page count of the book is not correct - my version of the book has 814 pages. The book is 'too long' on account of the fact that examples and query outputs take up much more space than is really needed. The authors will in most cases include 10-15 output rows in query output examples, despite 2 or 3 output (/and input!) rows being in most contexts really all that would be required in order to illustrate the specific point/example of interest. A related problem is that almost all topics in the book include coverage of a significant number of different solution structures, linked to a variety of different database engines/servers (DB2, Oracle, Microsoft SQL Server, MySQL, PostgreSQL); this is good if you want to be able to solve problem X regardless of which database engine you're using, but it also means that if you're using a specific type of database for most of your work, a lot of the coverage in this book will not actually be relevant to you.
A major takeaway from this book is that you can do much more with SQL than most people probably think you can; a problem also illustrated in the coverage, however, is that in many contexts the book also makes you ask yourself the very natural question: '...but why would you ever want to use SQL to solve this particular problem?' The authors as far as I recall never ask this question, but it seems highly relevant to me. In many contexts their solutions had me thinking, 'yes, you could solve that problem like that, but in many contexts that would be an awful waste of time and you wouldn't last long in your position if those kinds of solutions are the ones you're aiming for'.
This book is significantly longer than it needed to be in order to cover the material included and the registered page count of the book is not correct - my version of the book has 814 pages. The book is 'too long' on account of the fact that examples and query outputs take up much more space than is really needed. The authors will in most cases include 10-15 output rows in query output examples, despite 2 or 3 output (/and input!) rows being in most contexts really all that would be required in order to illustrate the specific point/example of interest. A related problem is that almost all topics in the book include coverage of a significant number of different solution structures, linked to a variety of different database engines/servers (DB2, Oracle, Microsoft SQL Server, MySQL, PostgreSQL); this is good if you want to be able to solve problem X regardless of which database engine you're using, but it also means that if you're using a specific type of database for most of your work, a lot of the coverage in this book will not actually be relevant to you.
A major takeaway from this book is that you can do much more with SQL than most people probably think you can; a problem also illustrated in the coverage, however, is that in many contexts the book also makes you ask yourself the very natural question: '...but why would you ever want to use SQL to solve this particular problem?' The authors as far as I recall never ask this question, but it seems highly relevant to me. In many contexts their solutions had me thinking, 'yes, you could solve that problem like that, but in many contexts that would be an awful waste of time and you wouldn't last long in your position if those kinds of solutions are the ones you're aiming for'.
