SBT in Action:The simple Scala built tool (Anglais) Broché – 28 mai 2015
|Neuf à partir de||Occasion à partir de|
- Choisissez parmi 17 000 points de collecte en France
- Les membres du programme Amazon Prime bénéficient de livraison gratuites illimitées
- Trouvez votre point de collecte et ajoutez-le à votre carnet d’adresses
- Sélectionnez cette adresse lors de votre commande
Les clients ayant acheté cet article ont également acheté
Description du produit
Présentation de l'éditeur
Simple Build Tool: sbt. The idea of a high quality build tool for Scala is indeed simple, but sbt itself is richly-featured and powerful. Documentation for sbt is sparse, and the blogs, tutorials, and other bits scattered across the web demand a comprehensive, accurate picture of how to build Scala projects effectively and efficiently. This book will help transform ugly, complex builds into a streamlined, automated, and repeatable process.
SBT in Action is first and foremost a tutorial about effectively building Scala projects. It introduces the sbt tool with a simple project that establishes the fundamentals of running commands and tasks. Next, it shows how to use the peripheral libraries in sbt to make common tasks simpler. This includes an I/O library to deal with files and how to parse user input in a meaningful fashion. Finally, it covers how to deploy software effectively. RETAIL SELLING POINTS
Comprehensive and detailed guide
Fills in the gaps of information on sbt
Shows how to tame unwieldy complex builds
This book assumes readers are comfortable reading and writing Scala code. No experience with sbt required.
ABOUT THE TECHNOLOGY
Known as the de-facto Scala build tool, sbt is used to build other pieces of software. It uses Scala as its lingua franca, which means that all settings and files are typesafe by default, providing a level of safety in builds that is uncommon.
Biographie de l'auteur
Josh Suereth is a Senior Software Engineer at Typesafe and the author of Scala in Depth. He is the author of several open source Scala projects, including the Scala automated resource management library, the PGP sbt plugin. Matthew Farwell is a Senior Software developer at Nexthink. He is the author of Scalastyle, the style checker for Scala and is a contributor to JUnit and the Eclipse Scala IDE.
Aucun appareil Kindle n'est requis. Téléchargez l'une des applis Kindle gratuites et commencez à lire les livres Kindle sur votre smartphone, tablette ou ordinateur.
Pour obtenir l'appli gratuite, saisissez votre numéro de téléphone mobile.
Détails sur le produit
Si vous vendez ce produit, souhaitez-vous suggérer des mises à jour par l'intermédiaire du support vendeur ?
Commentaires en ligne
Commentaires client les plus utiles sur Amazon.com (beta) (Peut contenir des commentaires issus du programme Early Reviewer Rewards)
I'm still reading this book (I'm only on Chapter 3) but I'm compelled to write this because the book has numerous mistakes that could seriously impair its use as a tool for learning sbt. Many of the errors are easy to spot and correct on the fly. Other errors are fundamental to the learning process and really get in the way.
The kinds of errors that proliferate are errors in sequence and errors in the names of things.
An example of an error in sequence: early in chapter 3, the book communicates that the "build.sbt" file we got to at the end chapter 2 included initializing the organization setting. In fact, chapter 2 makes no mention of this setting whatsoever.
Another sequence error: Chapter 3 also talks about using settings to define the value of other settings. But the examples it gives for doing this can't be typed in and used because they assume the existence of a project that is not defined until later in the project (or perhaps at all, as I said I'm still reading).
Errors in the names of things: The book is completely riddled with these errors. The book leads you through creating a makeVersionProperties task. Later it tells you to use the makePropertiesFile task. The book leads you through creating a gitHeadCommitSha task. Later it tells you to use the gitHeadCommit task. These differences in names break the build. They are easy to fix. But they slow you down. And the fact that they are easy to fix begs the question ... WHY didn't the authors find and fix them before publication?
General inconsistencies. For example, the book says to use sbt version 0.13.5. Then its examples (at least some of them) show using sbt 0.13.7 instead. The differences between 0.13.5 and 0.13.7 are significant enough that they impact how you must or are allowed to write the build (specifically, I'm talking about whether blank lines are required between settings).
Worst by far though is that the examples in the book describe an sbt build that does not work as written. The book tells you to add the following line:
resourceGenerators in Compile += makePropertiesFile
As I mentioned, makePropertiesFile is the wrong name, it should be makeVersionProperties. But even when you fix that the build still doesn't work, and unlike the other examples I have mentioned this is a real head scratcher for someone not familiar with sbt (in other words, the intended audience of this book). I had to search online for how to fix this issue to learn that the line should actually be:
resourceGenerators in Compile += makeVersionProperties.taskValue
This was very confusing.
Aside from the preceding the book doesn't seem to know who its audience is. I am a software developer as I imagine will be every other person who reads this book. Yet the book inexplicably shies away from explaining things in terms software developers should all understand. Instead of uniformly using the word "type" in the sense universally understood by programmers, it sometimes calls the type the "shape" and in other cases the "keyhole" of a setting.
And it uses what I found to be a pretty clumsy spreadsheet analogy to explain the concept of settings in sbt. While the analogy is not itself "wrong", it kept making me ask the question, "Why are they using this analogy? Why describe scopes as tabs in a spreadsheet?" Instead of having the explanatory power the authors hoped for, this only obscured the meaning for me as I kept re-reading and trying to understand what I could be missing that made them choose this analogy. And it is easier for me to think in terms of types, scopes, and so on than in the terms of spreadsheets anyway. I had to continually translate from the spreadsheet analogy to what they really meant to say.
The book is informative. It could have been a great book, and it may become a great book in future editions but for now my advice has to be: wait for the second edition unless you are OK with putting a lot of effort into wrapping your head around what the authors are trying to say. I say this as someone who IS willing to make the effort ... I'm a Scala enthusiast and I expect to be an sbt enthusiast by the end of the book, but the mistakes are like stop signs that prevent me from building up a good chunk of momentum. For me it's worth the effort. It won't be for everyone.
I'll update this review when I'm finished the book