Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Submission + - Google sells out of Nexus 4 again (google.com)

Submitted by rabenja
rabenja writes: I had decided to replace my phone (Galaxy S Vibrant) with the Nexus 4. The first batch sold out in no time and I received an email that I just saw at 1:20 pm PST that the Nexus 4 would be available again for sale at 12:00 pm PST. I clicked the link provided and saw that it was already sold out again...
Science

Submission + - Brain's 'reading centres' are culturally universal (nature.com)

Submitted by
ananyo
ananyo writes: "Learning to read Chinese might seem daunting to Westerners used to an alphabetic script, but brain scans of French and Chinese native speakers show that people harness the same brain centres for reading across cultures.
Reading involves two neural systems: one that recognizes the shape of the word and a second that asseses the physical movements used to make the marks on a page. But it has been unclear whether the brain networks responsible for reading are universal or culturally distinct. Previous studies have suggested that alphabetic writing systems (such as French) and logographic ones (such as Chinese, in which single characters represent entire words) writing systems might engage different networks in the brain.
The researchers found that both Chinese and French people use the visual and gestural systems while reading their native language, but with different emphases that reflect the different demands of each language (paper).
Understanding how the brain decodes symbols during reading — using both visual and motor centres — might also inform learning strategies for general literacy. Harnessing the gestural system more in education might, for example, help young children with reading."
Books

Submission + - 4.99 O'Reilly ebooks (oreilly.com)

Submitted by mnooning
mnooning writes: At the risk of sounding like a shill, someone recently submitted a story titled "O'Reilly Discounts Every eBook By 50%". Well, the price dropped again. I just bought eight ebooks for $4.99 each. You need to register with O'Reilly, then register the paper books you purchased through them in the "Register Print Books" tab, under "Your Account".

Over the past 12 years I purchased a host of paper books from them. Many did not have an ebook copy at the time. If you bought the paper book and want the ebook, go to "Your Account", then "Print Books", which will show your registered books. You will see the upgrade offers beside the books you registered.

I registered the First Edition of Google Hacks, but they let me download the Third Edition's ebook. The Advanced Perl Programming ebook is the 2nd Edition, even though I bought and registered the original edition.
Blackberry

Submission + - The new BlackBerry debacle (bgr.com)

Submitted by redkemper
redkemper writes: We all know BlackBerry is collapsing in America, so the new Kantar Worldpanel data showing its market share slipping below 2% in the United States is no shocker. Research In Motion’s performance in its second major market — the United Kingdom — is also pretty much as expected. Its UK market share slipped from 19% to 8% between the three months ending in October 2011 and the autumn of 2012. But what really pops out in the new Kantar data is BlackBerry’s performance in Brazil and the Mediterranean region, two crucially important markets for RIM...
Security

Submission + - Cookie-stealing Yahoo.com Exploit on Sale for $700 (krebsonsecurity.com)

Submitted by tsu doh nimh
tsu doh nimh writes: A zero-day vulnerability in yahoo.com that lets attackers hijack Yahoo! email accounts and redirect users to malicious Web sites offers a fascinating glimpse into the underground market for large-scale exploits. Krebsonsecurity.com writes that the exploit, being sold for $700 by an Egyptian hacker on an exclusive cybercrime forum, targets a “cross-site scripting” (XSS) weakness in yahoo.com that lets attackers steal cookies from Yahoo! Webmail users. Such a flaw would let attackers send or read email from the victim’s account.
Microsoft

Submission + - Recycling a single software UI makes Windows 8 a productivity eating "monster" (useit.com)

Submitted by rtfa-troll
rtfa-troll writes: Usability expert Jakob Nielsen has a detailed posting on Windows 8 Metro UI (sometimes called "Modern"). The article goes through the design mistakes which "strangles [the user's] productivity" and talks about the "Error-Prone Gestures" with "swipe ambiguity" included in Windows and discovered with only a limited level of usability testing. He then goes on to say that, whilst it is possible that 'Windows 9 will be "Metro Done Right"', "Windows 8 is Mr. Hyde: a monster that terrorizes poor office workers" and that the fundamental unsolvable problem is "the idea of recycling a single software UI for two very different classes of hardware devices." The saddest part of the article? Jakob is a well respected academic and when he previously criticised usability in iPad apps, one year later most of those apps had improved based on that feedback; reaction from Android was similar. In his criticism of Windows 8 he actually had to include a section "I Don't Hate Microsoft" through fear of being accused of being a "fanboy or a Microsoft hater". Will Microsoft listen or is it stuck in the echo chamber of it's online reputation managers?
Book Reviews

Submission + - Book Review: Version Control with Git, 2nd Edition (oreilly.com)

Submitted by
kfogel
kfogel writes: "First, the main thing: two thumbs up, and maybe a tentacle too, on Version Control with Git, 2nd Edition by Jon Loeliger and Matthew McCullough (O'Reilly Media, 2012). If you are a working programmer who wants to learn more about Git, particularly a programmer familiar with a Unix-based development environment, then this is the book for you, hands down (tentacles down too, please).

But there's a catch. You have to read the book straight through, from front to back. If you try to skip around, or just read the parts you feel you need, you'll probably be frustrated, because — exaggerating, but only slightly — every part of the book is linked to every other part. Perhaps if you're already expert in Git and merely want a quick reminder about something, it would work, but in that case you're more likely to do a web search anyway. For the rest of us, taking the medicine straight and for the full course is the only way. To some degree, this may have been forced on the authors by Git's inherent complexity and the interdependency of its basic concepts, but it does make this book unusual among technical guides. A common first use case, cloning a repository from somewhere else, isn't even covered until Chapter 12, because understanding what cloning really means requires so much background.

Like most readers, I'm an everyday user of Git but not at all an expert. Even this everyday use is enough to make me appreciate the scale of the task faced by the authors. On more than one occasion, frustrated by some idiosyncrasy, I've cursed that Git is a terrific engine surrounded by a cloud of bad decisions. The authors might not put it quite so strongly, but they clearly recognize Git's inconsistencies (the footnote on p. 47 is one vicarious acknowledgement) and they gamely enter the ring anyway. As with wrestling a bear, the question is not "Did they win?" but "How long did they last?"

For the most part, they more than hold their own. You can sometimes sense their struggle over how to present the information, and one of the book's weaknesses is a tendency to fall too quickly into implementation-driven presentation after a basic concept has been introduced. The explanation of cloning on p. 197 is one example: the jump from the basics to Git-specific terminology and repository details is abrupt, and forces the reader to either mentally cache terms and references in hope of later resolution, or to go back and look up a technical detail that was introduced many pages ago and is suddenly relevant again[1]. On the other hand, it is one of the virtues of the book that these checks can almost always be cashed: the authors accumulate unusual amounts of presentational debt as they go (in some cases unnecessarily), but if you're willing to maintain the ledger in your head, it all gets repaid in the end. Your questions will generally be answered[2], just not in the order nor at the time you had them. This isn't a book you can read for relaxation; give it your whole mind and you shall receive enlightenment in due proportion.

The book begins with a few relatively light chapters on the history of Git and on basic installation and local usage, all of which are good, but in a sense its real start is Chapters 4-6, which cover basic concepts, the Git "index" (staging area), and commits. These chapters, especially Chapter 4, are essentially a design overview of Git, and they go deep enough that you could probably re-implement much of Git based just on them. It requires a leap of faith to believe that all this material will be needed throughout the rest of the book, but it will, and you shouldn't move on until you feel secure with everything there.

From that point on, the book is at its best, giving in-depth explanations of well-bounded areas of Git's functionality. The chapter on git diff tells you everything you need to know, starting with an excellent overview and then presenting the details in a well-thought-out order, including an especially good annotated running example starting on p. 112. Similarly, the branching and merging chapters ensure that you will come out understanding how branches are central to Git and how to handle them, and the explanations build well on earlier material about Git's internal structure, how commit objects are stored, etc. (Somewhere around p. 227 my eyes finally glazed over in the material about manipulating tracking branches: I thought "if I ever need this, I know where to find it". Everyone will probably have that reaction at various points in the book, and the authors seem to have segregated some material with that in mind.) The chapter-level discussions on how to use Git with Subversion repositories, on the git stash command, on using GitHub, and especially on different strategies for assembling multi-source projects using Git, are all well done and don't shirk on examples nor on technical detail. Given the huge topic space the authors had to choose from, their prioritizations are intelligently made and obviously reflective of long experience using Git.

Another strength is the well-placed tips throughout the book. These are sometimes indented and marked with the (oddly ominous, or is that just me?) O'Reilly paw print tip graphic, and sometimes given inline. Somehow the tips always seem to land right where you're most likely to be thinking "I wish there were a way to do X"; again, this must be due to the author's experience using Git in the real world, and readers who use Git on a daily basis will appreciate it. The explanation of --assume-unchanged on p. 382 appeared almost telepathically just as I was about to ask how to do that, for example. Furthermore, everything they saved for the "Advanced Manipulations" and "Tips, Tricks, and Techniques" chapters is likely to be useful at some point. Even if you don't remember the details of every tip, you'll remember that it was there, and know to go looking for it later when you need it (so it might be good to get an electronic copy of the book).

If there's a serious complaint to be made, it's that with a bit more attention the mental burden on the reader could have been reduced in many places. To pick a random example, in the "Branches" chapter on p. 90, the term "topic branch" is defined for the first time, but it was already used in passing on p. 68 (with what seems to be an assumption that the reader already knew the term) and again on pp. 80-81 (this time compounding the confusion with an example branch named "topic"). There are many similar instances of avoidable presentational debt; usually they are only distractions rather than genuine impediments to understanding, but they make the book more work than it needs to be. There are also sometimes ambiguous or not-quite-precise-enough statements that will cause the alert reader — which is the only kind this book really serves — to pause and have to work out what the authors must have meant (a couple of examples: "Git does not track file or directory names" on p. 34, or the business about patch line counts at the top of p. 359). Again, these can usually be resolved quickly, or ignored, without damage to overall understanding, but things would go a little bit more smoothly had they been worded differently.

Starting around p. 244 is a philosophical section that I found less satisfying than the technical material. It makes sense to discuss the distinction between committing and publishing, the idea that there are multiple valid histories, and the idea that the "central" repository is purely a social construct. But at some point the discussion starts to veer into being a different book, one about patterns for using Git to manage multi-developer projects and about software development generally, before eventually veering back. Such material could be helpful, but then it might have been better to offer a shallower overview of more patterns, rather than a tentative dive into the "Maintainer/Developer" pattern, which is privileged here beyond its actual prominence in software development. (This is perhaps a consequence of the flagship Git project, the Linux kernel, happening to use that pattern — but Linux is unusual in many ways, not just that one.)

The discussion of forking and of the term "fork", first from p. 259 and reiterated from p. 392, is confusing in several ways. It first uses the term as though it has no historical baggage, then later takes that historical baggage for granted, then finally describes the baggage but misunderstands it by failing to distinguish clearly between a social fork (a group of developers trying to persuade users and other developers to abandon one version and join another), which is a major event, and a feature fork (that is, a branch that happens to be in another repository), which is a non-event and which is all that sites like GitHub mean by forking. The two concepts are very different; to conflate them just because the word "fork" is now used for both is thinking with words, and doesn't help the reader understand what's going on. I raise this example in particular because I was surprised that the authors who had written so eloquently about the significance of social conventions elsewhere would give such an unsatisfactory explanation of this one.

Somewhat surprisingly, the authors don't review or even mention the many sources of online help about Git, such as the #git IRC channel at Freenode, the user discussion groups, wikis, etc. While most users can probably find those things quickly with a web search, it would have been good to point out their existence and maybe make some recommendations. Also, the book only covers installation of Git on GNU/Linux and MS Windows systems, with no explicit instructions for Mac OS X, the *BSD family, etc (however, the authors acknowledge this and rightly point out that the differences among Unix variants are not likely to be a showstopper for anyone).

But this is all carping. The book's weaknesses are minor, its strengths major. Any book on so complicated a topic is bound to cause disagreements about presentation strategy and even about philosophical questions. The authors write well, they must have done cubic parsecs of command testing to make sure their examples were correct, they respect the reader enough to dive deeply into technical details when the details are called for, and they take care to describe the practical scenarios in which a given feature is most likely to be useful. Its occasional organizational issues notwithstanding, this book is exactly what is needed by the everyday Git user who wants to know more — and is willing to put in the effort required to get there. I will be using my copy for a long time.

Footnotes

[1] One of my favorite instances of this happened with the term "fast-forward". It was introduced on p. 140, discussed a little but with no mention of a "safety check", then not used again until page 202, which says: "If present, the plus sign indicates that the normal fast-forward safety check will not be performed during the transfer." If your memory is as bad as mine, you might at that point have felt like you were suddenly reading the owner's manual for an early digital wristwatch circa 1976.

[2] Though not absolutely always: one of the few completely dangling references in the book is to "smudge/clean filters" on p. 294. At first I thought it must be a general computer science term that I didn't know, but it appears to be Git-specific terminology. Happy Googling.

[3] (This is relegated to a floating footnote because it's probably not relevant to most readers.) The book discusses other version control systems a bit, for historical perspective, and is not as factually careful about them as it is about Git. I've been a developer on both CVS and Subversion, so the various incorrect assertions, especially about Subversion, jumped out at me (pp. 2-3, p. 120, pp. 319-320). Again, this shouldn't matter for the intended audience. Don't come to this book to learn about Subversion; definitely come to it to learn about Git.

[4] As long as we're having floating footnotes, here's a footnote about a footnote: on p. 337, why not just say "Voltaire"?

[5] Finally, I categorically deny accusations that I gave a positive review solely because at least one of the authors is a fellow Emacs fanatic (p. 359, footnote). But it didn't hurt."
Privacy

Submission + - Washington, D.C. Police affirm citizens' right to record police officers 1

Submitted by dcsmith
dcsmith writes: Washington D.C. Metropolitan Police Department Chief Cathy Lanier says that "A bystander has the same right to take photographs or make recordings as a member of the media", and backs it up with a General Order to her Department



The Metropolitan Police Department (MPD) recognizes that members of the general public have a First Amendment right to video record, photograph, and/or audio record MPD members while MPD members are conducting official business or while acting in an official capacity in any public space, unless such recordings interfere with police activity.
Apple

Submission + - What It's Like to Get Chewed Out by Steve Jobs 1

Submitted by
Hugh Pickens writes
Hugh Pickens writes writes: "Jay Yarow writes in the SF Chronicle that in 2008, when Apple launched MobileMe, its own advanced email system, there were syncing issues, emails were being lost, and the Wall Street Journal's legendary tech guru, Walt Mossberg, said he couldn't recommend the service because it had "too many flaws." In response to the flop, Steve Jobs assembled the team that worked on the service in the auditorium Apple uses on its campus to do demos of small products for the press and asked the team what MobileMe was supposed to do. Someone answered and Jobs said to that person and everyone else, "So why the fuck doesn't it do that?" Jobs continued, "You've tarnished Apple's reputation ... You should hate each other for having let each other down ... Mossberg, our friend, is no longer writing good things about us." And Jobs named a new executive right there to run MobileMe and disbanded most of the team that built the original service. "Is any company as closely identified with its leader quite as much as Apple is? So, how can anyone not imagine that, along the way, he'll get mad, he'll micromanage, and he'll have his idiosyncratic versions of inspiration?" writes Chris Matyszczyk. "Some of it must work, right?""
Programming

Submission + - Why The New Guy Can't Code 4

Submitted by theodp
theodp writes: 'We've all lived the nightmare,' writes Jon Evans. 'A new developer shows up at work, and you try to be welcoming, but he can't seem to get up to speed; the questions he asks reveal basic ignorance; and his work, when it finally emerges, is so kludgey that it ultimately must be rewritten from scratch by more competent people.' Evans takes a stab at explaining why the new guy can't code when his interviewers and HR swear that they only hire above-average/A-level/top-1% people. Evans fingers the technical interview as the culprit, saying the skills required to pass today's industry-standard software interview are not those required to be a good software developer. Instead, Evans suggests: 'Don't interview anyone who hasn't accomplished anything. Ever. Certificates and degrees are not accomplishments; I mean real-world projects with real-world users. There is no excuse for software developers who don't have a site, app, or service they can point to and say, 'I did this, all by myself!' in a world where Google App Engine and Amazon Web Services have free service tiers, and it costs all of $25 to register as an Android developer and publish an app on the Android Market.'

Slashdot Top Deals

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Close