That's a great point. I'd happily pay full price for a technical book if it meant the authors received more. Technical authors hardly receive fair compensation for the hours they put in already.
Could someone speak to the various credentials of the authors here?
I think this landing page would be substantially improved if there was further detail about the professional history of each of the authors. Perhaps a few words about any notable Go related projects that they've been a part of.
nice detective work. LinkedIn probably covers most of what you need to know. We're also behind projects like Skynet and SkyDNS. I've been using Go in high volume production applications since 2010.
I am happy to vouch for William who has been driving the Miami meet ups. He knows his Go and is able to deconstruct rather tricky subjects and present them in a way that's easy to understand. You should check out his blog to see what I mean. Better yet, if you are in Miami, come to the meet-up.
The quality of their books is decent, but O'Reilly books are typically clearer to read and more focused. I might buy this book today, simply because there is currently no O'Reilly book on Go (not even early access).
I wish someone would provide an early access book on Rust (even if it is a bit of a moving target).
Have you picked up any O'Reilly books recently? The quality is completely variable from title to title. Of the last 3 O'Reilly books I've purchased, 2 were absolute shit.
I've noticed that Manning's MEAP process works to keep errors out and quality high.
Node In Action is probably the most beautiful JS example code I've ever seen in a book.
I see no harm in doing so. I have a ton of books in digital formats, just never thought about buying a physical copy before. The only reason I did so this time is because I have some travelling upcoming, so it's ideal to read on the plane.
I believe in all digital books. It lacks that real feeling of a book i.e. having paper/something physical, but for tech books it's nice to have them digital for a couple of reasons:
1. Copying code from the book to an editor is MUCH easier.
2. Books take up physical space and it's hard to be mobile when you have to pack/unpack and move heavy things that you aren't going to be constantly using. I define things that I constantly use that are like my computer, laptop, kettle.
3. Cmd/Ctrl + F - I can't live without it even with a digital index.
Am I the only person who initially left the site when I saw the mobile-esque navigation bar? Why make me go through another step, just to see the menu?
I know this might seem like a stupid question, but how does he keep count of his Redbull consumption? Just good 'ol fashioned counting?
Shopify have a beer tap which I'm guessing they use to update their 'Pints of beers consumed' counter and a sensor on their pinball machine which they update on their website [1].
No table of contents? Anything meaty in the book? I've got some web scraping that I need to do this week, for example. Was going to use Python and BeautifulSoup but since it's throw away code, I could possibly use Go. I don't want to reinvent the wheel though.
Glad to see this book is being brought back to life. It was originally supposed to be written by Evan Shaw, who I believe work(ed/s) for Iron.io, but it became abandonware. Demand for the book was quite high so I'm glad Manning has found authors that want to actually finish it.
The last comment from Evan[0] on this topic is a little unclear what the cause of the cancelation was. He also never posted the retrospective he said he would.
"What if we made a web page which appears to have large sections with no content, but then when the user scrolls down so that the entire screen is empty, we fill the screen with content, some of which is already above the top of the screen? That would be great."
For me that wasn't even the worst part. What is the contrast ratio here? Looks light light-grey on off-white or something. I mean, ok, "they" say: 'Don't use black text on white background'. But "they" also say: 'Being able to actually see the text helps readability'.
And are those chapters available as single-page links -- or just in that cramped div/iframe with scrollbars?
I know this is harsh, but after seeing quite a few designs on the front page of hn, this has the prize for detracting from the user experience.
Every time I visit a webpage that uses animations and weird UI behavior this[1] comes to mind.
There are some cases where animation is nice, but I find the page very distracting and unpleasant to read.
edit: Did anyone else try to scroll through the iPad-esque reader in the "Choose a Chapter" section? It seems very slow.
Whenever I see a "In Action" title, I read it "Inaction" and feel like it's a title that much closer reflects the realty of programming on a daily basis. :-)
If they already were seasoned developers in other languages who made the jump to Go early on, they can arguably become experts in such a short time-span.
The two sample pages are essentially useless. For a technical book, I'm not interested in seeing how well the author writes chapter intros. I want to see some actual technical content.
While I have been impressed by several of the books from this outfit there certainly is nothing at that web page that would interest me in buying the book. They should take it down until it actually provides some information. It might be great, but who knows.
55 comments
[ 4.5 ms ] story [ 108 ms ] threadI think this landing page would be substantially improved if there was further detail about the professional history of each of the authors. Perhaps a few words about any notable Go related projects that they've been a part of.
https://www.linkedin.com/in/brianketelsen
http://www.linkedin.com/in/erikstmartin
Can't find for William Kennedy, so here's his blog: http://www.goinggo.net/
I wish someone would provide an early access book on Rust (even if it is a bit of a moving target).
I've noticed that Manning's MEAP process works to keep errors out and quality high.
Node In Action is probably the most beautiful JS example code I've ever seen in a book.
Also, libraries. I read a lot of technical books when I was a kid, but I certainly couldn't have afforded to shell out the $80-100 for each of them.
1. Copying code from the book to an editor is MUCH easier. 2. Books take up physical space and it's hard to be mobile when you have to pack/unpack and move heavy things that you aren't going to be constantly using. I define things that I constantly use that are like my computer, laptop, kettle. 3. Cmd/Ctrl + F - I can't live without it even with a digital index.
Shopify have a beer tap which I'm guessing they use to update their 'Pints of beers consumed' counter and a sensor on their pinball machine which they update on their website [1].
[1]: http://www.shopify.com/careers
They taste so much better and have a nice kick.
I don't think you'd be doing yourself any favors using go for a throwaway scraper.
[0] https://groups.google.com/d/msg/golang-nuts/7R4lN2P2EY4/2oS8...
But being interested by this book I'm still going to bear with this bad UX ...
Maybe it shows that all these talks about UX are a bit overrated ...
And are those chapters available as single-page links -- or just in that cramped div/iframe with scrollbars?
I know this is harsh, but after seeing quite a few designs on the front page of hn, this has the prize for detracting from the user experience.
edit: Did anyone else try to scroll through the iPad-esque reader in the "Choose a Chapter" section? It seems very slow.
1: http://motherfuckingwebsite.com/
It was invented in 2007! There aren't any seasoned developers yet!