I've been reading these to my boy H., who was five and a half when we finished this one. And although I think I may like The Prisoner of Azkaban betteI've been reading these to my boy H., who was five and a half when we finished this one. And although I think I may like The Prisoner of Azkaban better, this was the first one where H. and I got all sad together, there at the end....more
Longer review coming later at some point, and/but/so short version: I skimmed some parts, I read and re-read some parts, I may have missed some other Longer review coming later at some point, and/but/so short version: I skimmed some parts, I read and re-read some parts, I may have missed some other parts all together, but all in all it was good....more
I just finished up reading Practical Data Analysis by Hector Cuesta (Packt Publishing, 2013) and overall, it was a pretty good overview and recommendsI just finished up reading Practical Data Analysis by Hector Cuesta (Packt Publishing, 2013) and overall, it was a pretty good overview and recommends some good tools. I would say that the book is a good place for someone to get started if they have no real experience performing these kinds of analyses, and though Cuesta doesn't go deep into the math behind it all, he isn't afraid to use the technical names for different formulae, which should make it easy for you to do your own follow-up research. [1]
Jeff Leek's provides the lens through which I read this book. [2] That being said, I found myself doing a lot of comparing and contrasting between the two. For example, they both use practical, reasonably small "real world" sample problems to highlight specific analytical techniques and/or features of their chosen toolkits. However, whereas Leek's course focused exclusively on using , Cuesta assembles his own all-star team of tools using Python [3] and . Perhaps it goes without saying, but there are pros and cons to each approach (e.g., Leek's "pure R" vs. Cuesta's "Python plus D3.js"), and I felt that it was best to consider them together.
Cuesta's approach with this book is to present a sample scenario in each chapter that introduces a class of problem, a solution to that problem, and his recommended toolkit. For example, chapter six creates a stock price simulation, introducing simple simulation problems (especially for apparently stochastic data), time series data and Monte Carlo methods, and then how to simulate the data using Python and visualizing it in D3.js. Although the book is not strictly a "cookbook", the chapters very much feel like macro-level "recipes". There's quite a bit of code and some decent discussion around the concepts that govern the analytical model, and (true to the "practical" in the title) the emphasis is on the "how" and not the "why".
While I did not read the entire book cover-to-cover, I would definitely recommend it to anyone that wants an introduction to some basic data analysis techniques and tools. You'll get more out of this book if you have some base to compare it to -- e.g., some experience in R (academic or otherwise); and you'll get the most out of this book if you also have a solid foundation in the mathematics and/or statistics that underlie these analytical approaches.
Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.
------
[1] As an aside, this seems to be par for the course for the “technical” data analysis books, blog posts, and that I’ve encountered. That is to say, “the math” is touched on, but if you don’t already have a background in linear algebra (or whatever) then you’re going to wind up taking it on faith that support vector machines do what you need them to do.
[2] I wrote about my experience in Jeff Leek’s class in April of 2013. (See: .)
[3] Both the Python standard library and a collection of libraries like mlpy and matplotlib....more
Full review coming soon but short version: super detailed look at the elements that go in to browser performance; this isn't about concatenating your Full review coming soon but short version: super detailed look at the elements that go in to browser performance; this isn't about concatenating your JavaScript, it's about latency and what causes it (and how to deal with it)....more
Packt Publishing recently released Jasmine JavaScript Testing by Paulo Ragonha (), and I just wrapped up reading it this morning. I’ve readPackt Publishing recently released Jasmine JavaScript Testing by Paulo Ragonha (), and I just wrapped up reading it this morning. I’ve read a few books on JavaScript unit testing [1] and at least one other that was dedicated to , [2] and this one is a strong entry.
If you’re unfamiliar with Jasmine, Ragonha will give you a solid foundation of the testing framework by the end of the second chapter. Less than 40 pages in and you’ll understand Jasmine’s approach to testing, as well as how to stand up a basic test suite. His coverage of the core functions and the collection of built-in matchers is concise and accurate. He builds on this foundation by demonstrating Jasmine’s abilities in testing everything from asynchronous code (Sinon.js!) to MVC components (Backbone.js!) to AMD modules (Require.js!).
Despite the title, Jasmine JavaScript Testing isn’t merely about the testing framework, or even just about testing. What Ragonha gives us is a book about how to write better code, using testability as the measurement of success. What is strongest about this book is how he uses a refactoring project as a frame-of-reference for telling the testability story. He’s not just talking about using Jasmine for writing tests; he’s talking about how to use it alongside the other tools and patterns that will make you a better front-end developer.
If you’re just getting started with testing JavaScript for the front-end, or if you want to see some good real-world examples, then I would definitely recommend this one.
Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.
[1] There was Mark Ethan Trostler’s Testable JavaScript; and then there’s Nicholas Zakas’ Maintainable JavaScript which, while not technically about testing, has at least the one chapter about it.
Borderline four stars... and I think when it's completed and fully edited, it just might be. (Disclosure: I read an early access edition; O'Reilly [1]Borderline four stars... and I think when it's completed and fully edited, it just might be. (Disclosure: I read an early access edition; O'Reilly [1] has been doing that a lot lately...)
Elliott's book fits neatly into that category of JavaScript books that are about praxis -- books that are not about specific libraries or language features or programming paradigms, but about doing "real development" on "real teams". It is close kin with Nicholas Zakas' Maintainable JavaScript, and (to an only slightly lesser extent) Addy Osmani's Learning JavaScript Design Patterns. And like ...Design Patterns, I found myself thinking once or twice: This book is like that in that it is an excellent and timely example of "how to do it the right way" and/but it also feels like it might be looking too microscopically at specific libraries or techniques? and consequently is it going to feel dated in 6-12 months? [2]
If you're already fairly well-read in the "JavaScript praxis book" arena, then most of this is going to be review. Elliott covers functions as first-class objects and functional style JavaScript (see also Functional JavaScript, others); style and linting (see also Maintainable JavaScript, others); different approaches to the module pattern and separation of concerns (see also: Learning JavaScript Design Patterns, others); and some other subjects. [3] The one subject I saw in here that I hadn't seen anywhere else was on internationalization -- which is something that I was very glad to see and is one of the reasons that I'll be recommending this one to people looking to build "professional" applications.
The other thing I wanted to point out here was that Elliott goes back and forth between programming JavaScript for the browser and programming JavaScript for Node, and the transitions aren't always clear. I expect this will get cleaned up a bit as they work it through editing for the final printed version. In either case, I am glad that he gives coverage to both in the same book, rather than marginalizing one or the other to a ghetto chapter.
----
Footnotes:
[1]: To be fair: almost all of the technical book publishers that I know of are doing this lately -- i.e., releasing and and the like.
[2]: I go back and forth on this bit of critique. If you're "all theory" then you're potentially losing out on providing some value because you're discussion is too far away from the real problems; but if you're too close to "the real thing" then you're just talking about that specific situation or tool-chain and it winds up being about addressing that problem with that tool, and not really "that class of problem". Elliott is somewhere in the middle here, listing only slightly toward "too specific" and only in a couple of places.
[3]: The PDF I have of this book has a little more, and some slightly different content than the version I read on my Kindle. Again: "Early Access Editions" and all that......more
As a developer who loves JavaScript, I am naturally curious about CoffeeScript. Now, I may be a bit late to the game, but I had decided after hearing As a developer who loves JavaScript, I am naturally curious about CoffeeScript. Now, I may be a bit late to the game, but I had decided after hearing all that ballyhoo (both laudatory and deprecatory) for the past couple years that it was worth at least a little academic exploration. Now I'd and but no academic excursion is satisfactory without a good book.
And that's where MacCaw's Little Book on CoffeeScript comes in.
It's short (62 pages!) and gets right to the point. And MacCaw is (by and large) eloquent about the subject, if a bit... provocative at times.
So...
Loved: I wanted to learn a couple of things about CoffeeScript and MacCaw gave us exactly that, and with no ceremony. "This is CoffeeScript. Yes, this is all there is to it. And we're done."
However: there were a few statements in the book that made me bristle a bit. Example:
The typeof operator is probably the biggest design flaw of JavaScript...
Hmm... I suspect that most folks would describe the leaky and dangerous global namespace JavaScript's biggest design flaw. But OK.
And there are a couple of other off-hand statements like this (e.g., about "classes" in JavaScript, about mixins) but for the most part, these are minor and do not detract from the crux of the book.
And the crux of the book is about CoffeeScript. And by the end of it, you'll know enough about that little language to form your own opinion of it. And that opinion is probably something like:
I would rate this one as a pretty solid introduction to AngularJS, covering the framework's philosophy, the core APIs, and getting into a few (but notI would rate this one as a pretty solid introduction to AngularJS, covering the framework's philosophy, the core APIs, and getting into a few (but not all) of the nuts-and-bolts. By the time you get to the end of it, you should be able to build a non-trivial app in Angular -- though the jury's out on exactly how non-trivial that will be. Green and Seshadri have a clear and straightforward approach to presenting the material (no tricks!) and it (mostly) helps that they're both so deeply involved in the framework's development.
I had quite a few "ah-ha" moments while reading this one, enough to get me better engaged with "the Angular Way" and to see some mistakes and pitfalls I was making in my own apps. Unfortunately, despite how clear Green and Seshadri are throughout the text, there are still a few concepts that don't quite ring totally clear. In particular: (1) there is a whole chapter on directives and yet at the end of it, I was not sure that I understood them that much more than when I started [1]; (2) whither filters?; (3) I have a sneaking suspicion that they slyly snuck in a few of the kinda/sorta undocumented features of the core Angular libraries without really mentioning it. [2]
Overall, the book is well-structured, with clearly titled chapters, making it easy to jump around and cherry-pick what you need out of it. If you're new to Angular, I highly recommend this book and urge you to (at a minimum) read the first four chapters.
----
[1]: That being said: you can tell just how important Green and Seshadri think directives are, and also just how complicated they think they are. Directives are introduced pretty early on, and then they get their own chapter, and then there's another more detailed (and arguably more useful) illustrative example in the "Cheatsheet and Recipes" chapter. (Which, by the way, would have been better titled as "Case Studies" -- but I digress.) Anyway: I'm thinking that directives are just one of those things that's critical to "the Angular Way" but is also fairly complex (incidentally or otherwise?) and you just need to find your own "ah-ha" moment.
[2]: I say kinda/sorta because the Angular documentation (you may have noticed) is broken down into an "API Reference" and a "Developer Guide" and it isn't always clear which features are documented where. Or why something is documented in one but not the other (or else why it's in both...) So maybe I'm being a little unfair when I say "snuck in" and "undocumented" but... well: that's how it felt....more
Not nearly as cheeseball as I expected. Not nearly as sexist as I expected. John Carter is actually a (mostly) decent guy. And this novel holds up welNot nearly as cheeseball as I expected. Not nearly as sexist as I expected. John Carter is actually a (mostly) decent guy. And this novel holds up well;I can see why it's a classic of the genre....more
Despite the fact that there's no real reason to be apologetic, I also haven't yet reached the point in my career as a software developer where I've stDespite the fact that there's no real reason to be apologetic, I also haven't yet reached the point in my career as a software developer where I've stopped apologizing for the fact that I have no "real" Computer 카지노싸이트 Background.[^1] And/but that's exactly what draws me to books like Understanding Computation by Tom Stuart (O'Reilly, 2013). Stuart describes the books as for:
...programmers who are curious about programming languages and the theory of computation, especially those who don’t have a formal background in mathematics or computer science.
In other words, people like me. The people that Eric Miraglia described as the "liberal arts majors drafted into web-developer service during the dotcom boom".[^2] Yes: the liberal artsy non-computer science degree holders that wound up doing computer sciencey type software work just the same. Smart people that nevertheless are exploring some of these concepts for the first time.
For a taste of what I mean, observe the following quote:
In the end, syntax is only concerned with the surface appearance of programs, not with their meanings.
If that made you smile just a little bit, because you want to peel the onion layers away and get at the semantic questions underneath... then this book is for you.
Now before we go any further -- a couple words on what this book is not. This is not a book about software engineering. "Big O notation" does not make an appearance here in the text, not once. It isn't that we aren't concerned with "clean code" or efficiency or scalability or any of that -- but those are just implementation details that are not particularly interesting when you're otherwise diving into language semantics and finite automata.
Instead, the kind of questions this book poses are more like:
- What is a computer? - How do you create one? - How does a computer compute? - How would you go about designing a language? - Are there limits to computation? What are they?
These are fascinating questions, and reading this book was one of the first times where I really understood what separates "computer science" from "software engineering". The book is a fascinating read, even if it occasionally lapses into sentences like this:
The NFA class automatically takes account of free moves — we can see that when our NFA is started in state 3, it’s already possible for it to be in state 2 or 3 before it has read any input — so we won’t need to do anything special in NFASimulation to support them.
Awesome, but a little opaque.[^3] And/but, there's quite a bit of this; for a "simple" book about foundational computer science thinking, there's a lot of complicated material. ("But this is why you're here, right? To dip your toes into this particular pool?") It's often challenging, but also rewarding. (And there's plenty of humor along the way, if you're paying attention.)
A year from now, when I'm settling in to re-read this one, I probably won't remember the details about pushdown automata or what formalisms define a "universal Turing machine". However, I'm going to remember the in-depth discussions of static typing vs. dynamism and the trade-offs between them. I'll remember that we went through some engrossing exercises where we built up integers and arithmetic operators from scratch (even if I don't remember the details). I'll remember the flirtatious foray into language design. I'll remember The Halting Problem and most of the gory details around the limits of computation. And another thing I'll remember, statements like this:
The purpose of an expression is to be evaluated to produce another expression; a statement, on the other hand, is evaluated to make some change to the state of the abstract machine.
If you're "doing software" and you don't have a degree in computer science, I'm going to urge you to read this book. Even if you can't follow everything, you'll walk away with a lot of insight. (I'm particularly fond of the first and last thirds.) And if you do have a CS degree... Well, it's still worth skimming.
[^1]: The "full disclosure" footnote: I was briefly declared as a computer science major while in college. I performed... serviceably in an intro class (Common Lisp!) and in an "intro to AI" class (more Lisp!) but got ground to a frustrating halt in "Programming and Data Structures". I blamed Dr. Hunter, but I think I just wasn't ready to think that way. Call me a late bloomer. Call me a self-learner. Call me a frustrating bastard.
[^2]: That quote can be attributed to Miraglia's foreword to the second edition of Nicholas Zakas' Professional JavaScript for Web Developers (2nd ed.). The book is in its third edition now -- and I highly recommend that edition -- and/but: come on, that's a fantastic quote, and is the reason that the two editions will co-habitate on my bookshelf for as long as the bindings hold together.
[^3]: Partly my own fault for doing so much of the reading as my too-late-night bedtime reading.
---
A version of this review also appears on my blog: ...more
Real review at some point but, short version: Taleb describes systems that get stronger from volatility and mistreatment ("to a point"), and compares Real review at some point but, short version: Taleb describes systems that get stronger from volatility and mistreatment ("to a point"), and compares them with our tendency to plan and predict and generally design systems that break down when things don't go according to plan. There is a lot of insightful stuff in here, and some excellent unconventional thinking, and/but his writing style is a bit glib and can get in the way of his point being made. Sometimes....more
If you've been programming in Grails for a year (give or take) and are ready to go deeper than the tutorials and docs usually take you, then Burt BeckIf you've been programming in Grails for a year (give or take) and are ready to go deeper than the tutorials and docs usually take you, then Burt Beckwith's book -- Programming Grails (O'Reilly, 2013) -- is going to feel like just what the doctor ordered. If asked to sum it up as a pithy one-liner, I'd describe it as a guided tour of the framework's guts by one of the field's seasoned experts. He goes beyond the basics, and dives headlong into those dark corners for (as he puts it) "developers who want to dig deeper into the architecture and understand more about how Grails works its magic".
If Beckwith's name is familiar, then you've probably been around the Grails block once or twice. He curates the blog series and at least half the time seems to be the author of the accepted answer to that Grails question you found on StackOverflow. In other words: this is a guy that knows his way around the the framework.
Having worked in, with, around, over, under, and through Grails over the past couple of years, this book was exactly what I was looking for at this point in my relationship with the framework. Beckwith is specifically targeting developers that have gone past simply snapping together applications along the happy-path; this one is for the developers that find themselves regularly battling with some dark and thorny corner or rough edge of the framework. Beckwith does a fantastic job of introducing these "hidden" and "magical" parts of Grails, and breaking them down into easily-digestible sections. It's like a series of miniature epiphanies -- one right after the other. (The opening chapter on Groovy alone is worth the price of admission.)
There were a couple of things that could have made this one better. Most of them were small to the point of being ridiculous (e.g., I could have used a more specific definition for the purpose behind BootStrap.groovy), while others were arguably out of scope (e.g., an in-depth discussion of Groovy's metaclasses is... probably more appropriate for a book dedicated to Groovy). Then there was the chapter on plugin development which -- although I learned something on almost every page -- I found myself wondering: (1) why not discuss how to run with inline plugins right from start? (2) why wait so long to mention settings.groovy? (3) why not a better example of CLI tests?
(As you can see: even my "legitimate gripes" are little more than nit-picks. But I suppose the nit-picks add up?)
Would I recommend this one? In heartbeat. I'll continue to recommend Grails in Action as the best place to start (with the caveat: "as soon as the second edition comes out..."), but Programming Grails is required reading for anyone with six months or more of non-trivial Grails development under their belt....more
**spoiler alert** Those last couple of chapters are a bit rough for an almost-five-year-old, what with the Time-Turner and the ambiguous outcomes. ("D**spoiler alert** Those last couple of chapters are a bit rough for an almost-five-year-old, what with the Time-Turner and the ambiguous outcomes. ("Daddy, but Sirius was good?" "Yes." "So why is he hiding?" "Because he was convicted of breaking the law and there is no evidence to absolve him." "What does absolve mean?")...more
Loading...
