Given that mobile products seem somewhat more likely to succeed than printed newspapers, this seems a strange decision at best.
The material seems to raise as many questions as it answers. Assuming that the code printed in the book works (no downloadable code archive is offered), readers will probably be left pondering questions such as: Is create: function() some sort of constructor? Why isn't a new color passed through the call this.colorChanged()? Why is oldValue apparently not used? Where is setColor() defined? While it is a good idea to entice the reader to try a new technology by showing its capabilities, if that reader is expected to understand the example code presented, then it should be fully explained; otherwise, it should not be presented. As an alternative, the author could have limited the discussion to what functionality Enyo provides to the programmer, without listing source code in print or on jsFiddle. This would have provided the reader with greater motivation to invest the time and effort in learning what can be a challenging subject.
As a result of these early problems, this first chapter does not get the book off to a promising start. The second chapter, "Core Concepts," is perhaps the one that should have begun the book, because it describes many of the core ideas critical to Enyo: kinds, encapsulation, published properties, events, signals, inheritance, constructors, and statics. However, the pace is too fast for beginners, and more examples are needed to explain the concepts, step-by-step. By the bottom of page 11, countless readers will likely be bewildered with the terse discussion of getter and setter functions, "changed" functions, construction, and passed values (which are properties or not). Also, readers will again encounter the aforesaid problem of the red dot character breaking the example code on jsFiddle. (Further instances in the book will not be documented here.) The third chapter continues the discussion, focusing on components, menu and form controls, and functions, as well as some components for animation and making web requests. All of the information looks correct. The only puzzling aspect is why break tags are used (on page 22) instead of a CSS display: block; declaration.
User interface is addressed in the next two chapters, the first of which presents layout components commonly needed for Enyo apps — scrollers, repeaters, fittables, lists, and panels. The second one explores CSS styling of an Enyo app, performance considerations of apps on handheld devices, debugging, common mistakes, jsFiddle, internationalization, and localization. With these chapters, the narrative in the book becomes noticeably more comprehensible.
The penultimate chapter — essentially comprising two pages — delineates some options that the Enyo developer has for deploying a newly-built app to any one of the supported platforms. This chapter, like all the earlier ones, ends with a summary that is so brief, and applicable to so few pages, that each one seems pointless. Why do publishers feel obligated to include these useless chapter summaries in almost every technical book? The final chapter is a one-page conclusion, in which the author encourages readers to learn more and become involved in the Enyo community.
This book is more of an introduction, although no reason is provided as to why it was not instead made a more extensive treatment of the subject. Upon completing the book, the average reader will probably conclude that she did not absorb enough knowledge of the Enyo core to begin immediately developing apps using this framework, and the best course of action might be to start over again on page 1, or perhaps seek out a second source, before optionally returning to this one for a second run-through. The material could have been structured so all information is presented sequentially — so the reader does not encounter concepts yet unseen — with more step-by-step explanations.
Rather than presenting the reader with code snippets that have no relation to one another, it would have been much more interesting and motivating if the author had devised and explained code that incrementally builds into a nontrivial app. Furthermore, the example source code should have been made available on the publisher's website, so readers could avoid typing it from the text or extracting it from jsFiddle if they wished to try it in their local development environments.
In terms of typography, the font size of this book is a bit too small, especially for extended reading, and for people with subpar vision. This is even more true for the code snippets, which are in an even smaller font. In many of the lines of prose, the words are too close to one another — a problem exhibited in a few other recent O'Reilly titles. Did the production team feel it necessary to further compress a 74-page book?! In fact, proper names, such as those of components, are oftentimes broken between two lines in the text — sometimes nonsensically, e.g., "FittableR" followed by "owsLayout" (page 32). The book contains several errata: "This is [not] to say" (page viii), "such as [a] local installation" (viii), "url" (27), "we might modify add" (34), "woud" (35), "one [of] the most" (35), and "allow you [to] easily debug" (56). For such a slender volume, the production quality seems to have received less attention than it deserved.
Overall, this offering does not reach O'Reilly's usual high standards. It's a shame, because it seems like such a promising topic — one that could be more thoroughly explored in a larger volume. Perhaps this feedback, and that of other readers, could be folded into a second edition. This is a real possibility, given that the author notes in his conclusion that he considers the book an active project, and intends to keep it up-to-date with the changes to Enyo itself. In the meantime, this is a promising start that can give readers a taste of Enyo's potential for building modern web apps for desktop and mobile platforms.
Michael Ross is a freelance web developer and writer."
My sister and brother-in-law are self employed, and run a small business with a storefront. It was broken into about a year ago, and since then they have reinforced physical security; bars on the doors and windows, better locks, etc. Unfortunately, their store was broken into, and vandalized again last week in spite of the added security measures. Being technically savvy, I'm trying to come up with inexpensive ways to add deterrence, monitoring, and alerting to their business. They run an extremely lean lifestyle and profit margin, so the solution needs to be almost free. They do have an internet connection at the store, so motion detection, web cameras, arduino devices, and the like are certainly an option. Ideally I would like a rock solid alerting method. Something like an email or text to a laptop at home, or a dedicated prepaid phone, but without the pitfalls of such a solution(ie random wrong numbers, solicitors, email spam, etc). I'd also prefer not to poke holes in their firewall at the shop if at all possible. I was considering an email with some sort of long code or hash in the body, and then could white list that on the receiving end to key off of. The goal is to never have a false alarm based on the transmission/reception method. I know the physical triggers will have to be fine tuned, but I don't ever want them woken up at night due to some random male enhancement email.
"The algorithm was seeded with the fifty largest cities. After that, manual changes took into account compact shapes, equal populations, metro areas divided by state lines, and drainage basins. In certain areas, divisions are based on census tract lines... The suggested names of the new states are taken mainly from geographical features."
The new 50 states would be equally potent in terms of voting, but how many would be red? I made this layered GIF of Romney vs. Obama by county to try and figure things out."
While Facebook and Twitter have always been more prominent forums for political satire, consumers have flocked to Amazon’s review section before. In October, the user comment section of an Avery Dennison Corp. binder listed on the e- commerce site became the subject of a similar outbreak. Reviewers used Amazon to make light of a comment made by then- Republican presidential nominee Mitt Romney during a debate. Amazon’s conditions of use posted on its website say that the Seattle-based company reserves the right to remove or edit reviews, which it doesn’t regularly examine. So far the reviews have not been removed.
Harvey: Stealth Wear started as an experiment using the fabrics I was researching for the OFF Pocket. I did research on thermal surveillance and was very interested in where it was going and at some point realized that metalised fabrics work as a shield against thermal imagining cameras. I was able to get access to a thermal camera and started testing swatches of fabric. When I realized that it worked well enough, I got in touch with my friend Johanna Bloomfield and she came up with the hoodie design. Everything was pretty much still an experiment at this point. Then we showed the hoodie to Andrew Green from PRIMITIVE. He loved it and decided to include it and make it a major part of this upcoming show. Originally this show was to be based on work from CV Dazzle and a few other counter surveillance art projects. This whole idea of stealth wear line was very emergent.
He then concludes, "If you're a Free software developer, user and/or supporter and buying into these claims, I don't know how else to put it other than this: you're being duped. Consider what supporting those who employ such tactics means for Free software."
Our own Bruce Perens said that on Slashdot — "Working for free to make Mark Shuttleworth richer just isn’t very smart."