Slashdot Mirror

"Machines will need to make ethical decisions, and we will be responsible for those decisions," argues Mike Loukides, O'Reilly Media's vice president of content strategy: We are surrounded by systems that make ethical decisions: systems approving loans, trading stocks, forwarding news articles, recommending jail sentences, and much more. They act for us or against us, but almost always without our consent or even our knowledge. In recent articles, I've suggested the ethics of artificial intelligence itself needs to be automated. But my suggestion ignores the reality that ethics has already been automated... The sheer number of decisions that need to be made means that we can't expect humans to make those decisions. Every time data moves from one site to another, from one context to another, from one intent to another, there is an action that requires some kind of ethical decision...

Ethical problems arise when a company's interest in profit comes before the interests of the users. We see this all the time: in recommendations designed to maximize ad revenue via "engagement"; in recommendations that steer customers to Amazon's own products, rather than other products on their platform. The customer's interest must always come before the company's. That applies to recommendations in a news feed or on a shopping site, but also how the customer's data is used and where it's shipped. Facebook believes deeply that "bringing the world closer together" is a social good but, as Mary Gray said on Twitter, when we say that something is a "social good," we need to ask: "good for whom?" Good for advertisers? Stockholders? Or for the people who are being brought together? The answers aren't all the same, and depend deeply on who's connected and how....

It's time to start building the systems that will truly assist us to manage our data.
The article argues that spam filters provide a surprisingly good set of first design principles. They work in the background without interfering with users, but always allow users to revoke their decisions, and proactively seek out user input in ambiguous or unclear situations.

But in the real world beyond our inboxes, "machines are already making ethical decisions, and often doing so badly. Spam detection is the exception, not the rule."

"Machines will need to make ethical decisions, and we will be responsible for those decisions," argues Mike Loukides, O'Reilly Media's vice president of content strategy: We are surrounded by systems that make ethical decisions: systems approving loans, trading stocks, forwarding news articles, recommending jail sentences, and much more. They act for us or against us, but almost always without our consent or even our knowledge. In recent articles, I've suggested the ethics of artificial intelligence itself needs to be automated. But my suggestion ignores the reality that ethics has already been automated... The sheer number of decisions that need to be made means that we can't expect humans to make those decisions. Every time data moves from one site to another, from one context to another, from one intent to another, there is an action that requires some kind of ethical decision...

Ethical problems arise when a company's interest in profit comes before the interests of the users. We see this all the time: in recommendations designed to maximize ad revenue via "engagement"; in recommendations that steer customers to Amazon's own products, rather than other products on their platform. The customer's interest must always come before the company's. That applies to recommendations in a news feed or on a shopping site, but also how the customer's data is used and where it's shipped. Facebook believes deeply that "bringing the world closer together" is a social good but, as Mary Gray said on Twitter, when we say that something is a "social good," we need to ask: "good for whom?" Good for advertisers? Stockholders? Or for the people who are being brought together? The answers aren't all the same, and depend deeply on who's connected and how....

It's time to start building the systems that will truly assist us to manage our data.
The article argues that spam filters provide a surprisingly good set of first design principles. They work in the background without interfering with users, but always allow users to revoke their decisions, and proactively seek out user input in ambiguous or unclear situations.

But in the real world beyond our inboxes, "machines are already making ethical decisions, and often doing so badly. Spam detection is the exception, not the rule."

"Machines will need to make ethical decisions, and we will be responsible for those decisions," argues Mike Loukides, O'Reilly Media's vice president of content strategy: We are surrounded by systems that make ethical decisions: systems approving loans, trading stocks, forwarding news articles, recommending jail sentences, and much more. They act for us or against us, but almost always without our consent or even our knowledge. In recent articles, I've suggested the ethics of artificial intelligence itself needs to be automated. But my suggestion ignores the reality that ethics has already been automated... The sheer number of decisions that need to be made means that we can't expect humans to make those decisions. Every time data moves from one site to another, from one context to another, from one intent to another, there is an action that requires some kind of ethical decision...

Ethical problems arise when a company's interest in profit comes before the interests of the users. We see this all the time: in recommendations designed to maximize ad revenue via "engagement"; in recommendations that steer customers to Amazon's own products, rather than other products on their platform. The customer's interest must always come before the company's. That applies to recommendations in a news feed or on a shopping site, but also how the customer's data is used and where it's shipped. Facebook believes deeply that "bringing the world closer together" is a social good but, as Mary Gray said on Twitter, when we say that something is a "social good," we need to ask: "good for whom?" Good for advertisers? Stockholders? Or for the people who are being brought together? The answers aren't all the same, and depend deeply on who's connected and how....

It's time to start building the systems that will truly assist us to manage our data.
The article argues that spam filters provide a surprisingly good set of first design principles. They work in the background without interfering with users, but always allow users to revoke their decisions, and proactively seek out user input in ambiguous or unclear situations.

But in the real world beyond our inboxes, "machines are already making ethical decisions, and often doing so badly. Spam detection is the exception, not the rule."

Reader schwit1 shares a report: When you're browsing online, who sets the prices? An algorithm, most likely. A study from 2015 showed that a third of all items on Amazon [PDF] had prices set by an algorithm, and chances are that percentage has only risen. A new study shows how easy it would be for price-setting algorithms to learn to collude with each other and keep prices at a disadvantage for customers.

This sort of collusion would stem from a certain type of algorithm, the researchers say. Reinforcement algorithms learn through trial and error. In the simplest terms, a walking robot would take a step, fall, and try again. These algorithms have often been used to teach algorithms to win games like Go.

"From the antitrust standpoint," say professors Emilio Calvano, Giacomo Calzolari, and others from the University of Bologna in Italy, "the concern is that these autonomous pricing algorithms may independently discover that if they are to make the highest possible profit, they should avoid price wars. That is, they may learn to collude even if they have not been specifically instructed to do so, and even if they do not communicate with one another."

An anonymous reader shares an article from O'Reilly Media's VP of content strategy: It's high time to build the internet that we wanted all along: a network designed to respect privacy, a network designed to be secure, and a network designed to impose reasonable controls on behavior. And a network with few barriers to entry -- in particular, the certainty of ISP extortion as new services pay to get into the "fast lane." Is it time to start over from scratch, with new protocols that were designed with security, privacy, and maybe even accountability in mind? Is it time to pull the plug on the abusive old internet, with its entrenched monopolistic carriers, its pervasive advertising, and its spam? Could we start over again?

That would be painful, but not impossible... In his deliciously weird novel Someone Comes To Town, Someone Leaves Town, Cory Doctorow writes about an alternative network built from open WiFi access points. It sounds similar to Google's Project Fi, but built and maintained by a hacker underground. Could Doctorow's vision be our future backboneless backbone? A network of completely distributed municipal networks, with long haul segments over some public network, but with low-level protocols designed for security? We'd have to invent some new technology to build that new network, but that's already started.
The article cites the increasing popularity of peer-to-peer functionality everywhere from Bitcoin and Blockchain to the Beaker browser, the Federated Wiki, and even proposals for new file-sharing protocols like IPFS and Upspin. "Can we build a network that can't be monopolized by monopolists? Yes, we can..."

"It's time to build the network we want, and not just curse the network we have."

dovf writes: Just got an email from O'Reilly Media that as of today, they are no longer selling individual books or videos online -- rather, they are encouraging people to sign up for Safari. They are continuing to publish books and videos, "and you'll still be able to buy them at Amazon and other retailers." They also make it clear that we will not lose access to already-purchased content, updates to such content, etc. More details can be found in the FAQ. No mention, though, of whether the content sold at these other retailers will remain DRM-free... From the FAQ: "You can buy all of the books (ebooks and print) at shop.oreilly.com from Amazon and other digital and bricks-and-mortar retailers. We're no longer selling individual books and videos via shop.oreilly.com -- but we are definitely continuing to publish books and videos on the topics you need to know. And of course, every O'Reilly book and video (including O'Reilly conference sessions) is available instantly on Safari." The only mention of "DRM" in the FAQ is in regard to what happens to the digital content you have in your account at members.oreilly.com. According to O'Reilly, "Your DRM-free ebooks and videos are safe and sound, and you'll continue to have free lifetime access to download them anytime, anywhere."

An anonymous reader shares a press release: This week, O'Reilly Media stopped retailing books directly on our ecommerce store. You might say "what!?" Or you might say "what's the big deal?" Before I explain our business strategy here, there are two important things to note: We are absolutely continuing to publish the top-quality books that are important to the communities we serve.
1. We still sell them through Amazon or your favorite retailer.
2. So why the change? It's clear that we're in the midst of a fundamental shift in how people get and use their content.
Subscription services like Spotify and Netflix are the new norm, as people opt for paying for digital access rather than purchasing physical units one by one. We've already seen this in our own business -- the growth of membership on Safari far exceeds the individual units previously purchased on oreilly.com. That's one reason for the change.

An anonymous reader quotes OReilly.com's interview with the CEO of Affectiva, an emotion-measurement technology company that grew out of MIT's Media Lab. We can mine Twitter, for example, on text sentiment, but that only gets us so far. About 35-40% is conveyed in tone of voice -- how you say something -- and the remaining 50-60% is read through facial expressions and gestures you make. Technology that reads your emotional state, for example by combining facial and voice expressions, represents the emotion AI space. They are the subconscious, natural way we communicate emotion, which is nonverbal and which complements our language... Facial expressions and speech actually deal more with the subconscious, and are more unbiased and unfiltered expressions of emotion...

Rather than encoding specific rules that depict when a person is making a specific expression, we instead focus our attention on building intelligent algorithms that can be trained to recognize expressions. Through our partnerships across the globe, we have amassed an enormous emotional database from people driving cars, watching media content, etc. A portion of the data is then passed on to our labeling team, who are certified in the Facial Action Coding System...we have gathered 5,313,751 face videos, for a total of 38,944 hours of data, representing nearly two billion facial frames analyzed.
They got their start testing advertisements, and now are already working with a third of all Fortune 500 companies. ("We've seen that pet care and baby ads in the U.S. elicit more enjoyment than cereal ads -- which see the most enjoyment in Canada.") One company even combined their technology with Google Glass to help autistic children learn to recognize emotional cues.

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

97 Things Every Programmer Should Know was published seven years ago by O'Reilly Media, and was described as "pearls of wisdom for programmers collected from leading practitioners." Today an anonymous reader writes: All 97 are available online for free (and licensed under a Creative Commons Attribution 3), including an essay by "Uncle Bob" on taking personal responsibility and "Unix Tools Are Your Friend" by Athens-based professor Diomidis Spinellis, who writes that the Unix tool chest can be more useful than an IDE.

But the book's official site is also still accepting new submissions, and now points to 68 additional "edited contributions" (plus another seven "contributions in progress"), including "Be Stupid and Lazy" by Swiss-based Java programmer Mario Fusco, and "Decouple That UI" by tech trainer George Brooke.
"There is no overarching narrative," writes the site's editor Kevlin Henney (who also wrote the original book). "The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know...anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance..."

An anonymous reader writes: Andy Oram, who's been an editor at O'Reilly since 1992, has written a new free report about how open source software is everywhere in Brazil. The country's IT industry is booming in Brazil -- still Latin America's most vibrant economy -- with open source software popular in both startups and in cloud infrastructure. Oram attributes this partly to the government's support of open source software, which over the last 15 years has built public awareness about its power and potential. And says the Brazil now has a thriving open source community, and several free software movements. Even small towns have hacker spaces for collaboration and training, and the country has several free software movements.

On Friday, O'Reilly Media announced "Our Cyber Monday sale starts now." An anonymous reader writes: They're offering a 50% discount on every ebook they publish -- over 14,000 titles from O'Reilly, No Starch Press, Pearson, A Book Apart, Make, Packt, and 25 other book publishers. (And they're offering a 60 percent discount on orders over $100.) Just use the code CYBER16 when checking out to claim the discount. The sale continues through Tuesday morning at 5 a.m. PST.

These are all DRM-free ebooks (in multiple formats), and there's even some "early release" editions -- advance copies distributed before their official publication. The discount also applies to new titles like "Head First Python" as well as old-school classics like "Learning Perl". Right now their best-sellers are "Wicked Cool Shell Scripts", "Modern Linux Administration", and "You Don't Know JS: Up and Going" -- but again, the discount applies to any ebook that they sell, and they also still have their selection of free programming texts.
Tim O'Reilly was one of the first people interviewed by Slashdot -- more than 17 years ago.

On Friday, O'Reilly Media announced "Our Cyber Monday sale starts now." An anonymous reader writes: They're offering a 50% discount on every ebook they publish -- over 14,000 titles from O'Reilly, No Starch Press, Pearson, A Book Apart, Make, Packt, and 25 other book publishers. (And they're offering a 60 percent discount on orders over $100.) Just use the code CYBER16 when checking out to claim the discount. The sale continues through Tuesday morning at 5 a.m. PST.

These are all DRM-free ebooks (in multiple formats), and there's even some "early release" editions -- advance copies distributed before their official publication. The discount also applies to new titles like "Head First Python" as well as old-school classics like "Learning Perl". Right now their best-sellers are "Wicked Cool Shell Scripts", "Modern Linux Administration", and "You Don't Know JS: Up and Going" -- but again, the discount applies to any ebook that they sell, and they also still have their selection of free programming texts.
Tim O'Reilly was one of the first people interviewed by Slashdot -- more than 17 years ago.

An anonymous Slashdot reader writes: There's now a section on OReilly.com offering free ebooks about computer programming. There's four free Java ebooks and seven about Python, as well as an "Other" section which contains ebooks like C++ Today, Swift Pocket Reference, and Why Rust? But there's also some broader categories for Open Source and Software Architecture ebooks, as well as separate sections for their free ebooks about Data, Security, Web Development, and the Internet of Things.

An anonymous Slashdot reader writes: There's now a section on OReilly.com offering free ebooks about computer programming. There's four free Java ebooks and seven about Python, as well as an "Other" section which contains ebooks like C++ Today, Swift Pocket Reference, and Why Rust? But there's also some broader categories for Open Source and Software Architecture ebooks, as well as separate sections for their free ebooks about Data, Security, Web Development, and the Internet of Things.

An anonymous Slashdot reader writes: There's now a section on OReilly.com offering free ebooks about computer programming. There's four free Java ebooks and seven about Python, as well as an "Other" section which contains ebooks like C++ Today, Swift Pocket Reference, and Why Rust? But there's also some broader categories for Open Source and Software Architecture ebooks, as well as separate sections for their free ebooks about Data, Security, Web Development, and the Internet of Things.

An anonymous Slashdot reader writes: There's now a section on OReilly.com offering free ebooks about computer programming. There's four free Java ebooks and seven about Python, as well as an "Other" section which contains ebooks like C++ Today, Swift Pocket Reference, and Why Rust? But there's also some broader categories for Open Source and Software Architecture ebooks, as well as separate sections for their free ebooks about Data, Security, Web Development, and the Internet of Things.

An anonymous Slashdot reader writes: There's now a section on OReilly.com offering free ebooks about computer programming. There's four free Java ebooks and seven about Python, as well as an "Other" section which contains ebooks like C++ Today, Swift Pocket Reference, and Why Rust? But there's also some broader categories for Open Source and Software Architecture ebooks, as well as separate sections for their free ebooks about Data, Security, Web Development, and the Internet of Things.

Long-time Slashdot reader Esther Schindler points us to a new article at OReilly.com: Those of us who telecommute cannot quite fathom the reasons companies give for refusing to let people work from home. But even if you don't agree with their decision, they do have reasons -- and not all of them are, "Because we like to be idiots." In "5 reasons why the company you want to work for won't hire telecommuters", hiring managers share their sincere reasons to insist you work in the office -- and a few tips for how you might convince them otherwise.
The arguments against telecommuting range from "creativity happens in the hallway" to "the extra logistics aren't worth it," and the article suggests the best counterarguments include pointing out a past history of successfully telecommuting and allowing your employer to gradually transition you into a remote position. And if all else fails, just become a "rock star," because according to one tech placement company, "For the right talent and when a role has been open for a very long time, they tend to give in."

A few weeks ago you had a chance to ask author, entrepreneur, and software developer Jeff Atwood about founding Stack Overflow and the Stack Exchange Network, as well as his new endeavor, the Discourse open-source discussion platform. Below you will find his answers to your questions. Magic wand
by Anonymous Coward

If you had a magic wand to make one change in technology right now, what would it be?

Atwood: Users would not have to generate, remember, enter, or ever think about passwords again. Computers would automatically know who the user is through a combination of ambient biometrics plus physical possession of some kind of device. Like, say, a smartphone.

Passwords are the enemy. And the users, because we are the idiots put in charge of making up the passwords. But mostly, it's the *goddamn passwords*.



Why did you choose Microsoft Platform for SE?
by Sadsfae

I don't see many large, high profile sites running an entire Microsoft Windows stack nowadays (IIS/SQL Server, etc) but Stack Exchange is one of them.

What were the reasons behind choosing a full Microsoft stack versus any of the Open Source alternatives which seem much more prevalent, especially in start-ups and smaller businesses for web presence?

Atwood: Mostly, C# is what I knew and what I was skilled in -- and I'm a great fan of its primary architect Anders Hejsberg who also created Turbo Pascal and Delphi. Performance was a goal, too, and since C# is a compiled language it's *extremely* fast. I think you can see for yourself that Stack Overflow is absurdly fast. Having switched to Ruby with the Discourse project, I can also testify that Ruby .. is, uh ... not ... absurdly fast.

The only downside of the .NET environment is, honestly, the SQL Server licensing costs which can be quite extreme at scale. There is movement to make .NET more open source. Plus the long running mono effort.

The main weakness of .NET is that it's not great for open source projects, though that has changed a bit over the last few years. It never really made sense to open source Stack Overflow -- ask yourself, how many Stack Overflow clones have flourished? Why is that? As a closed source project, the performance, great language design, and scaling of C# worked for us.

I made different choices for Discourse which *was* designed to be an open source project, a tool that is widely applicable to many communities, from day zero.



History of StackExchange
by unencode200x

A question on the history of Stack Exchange. What was the original idea that drove you to make StackExchange and how has it evolved or added since?

Atwood: Do you remember a site called Experts-Exchange? No? That means we succeeded at our original goal.

The basic concept was to do a 100% community driven Q&A that had elements of:

- Wikipedia (all the articles are always up to date and not dead tombstones from six years ago).
- Reddit (voting up the good information and voting down the bad information).
- Blogs (ownership, curation, and responsibility for content that has your name on it).
- Videogames (the Xbox 360 Achievements system, points, and ways of encouraging and incentivizing positive community behavior that are fun).

Where everything we build together is creative commons, and belongs to all of us, since you guys and gals are the ones doing all the work in the system!



Reputation mechanisms & scientific quality
by Anonymous Coward

Jeff, have you thought about how to use reputation mechanisms to improve the quality of published scientific results? I'm asking in the context of John P. A. Ioannidis' famous paper.

It seems to me one fix for this (horrible) problem might be an online reputation mechanism where scientists could rate the reproducibility of published results. Thoughts? (thanks for inventing Stack Exchange - you've done the world a big favor).

Atwood: It certainly seems applicable. The Stack engine works best for systems of data, fact, and science -- or at least a "tome of knowledge" -- where you can actually verify an answer (or five answers) as plausibly correct. You can see which topics do best on the Stack engine in the Stack Exchange directory, with a massive, Jupiter sized Stack Overflow right at the top.

There's always more than one way to do it, of course, but when you start getting dozens or hundreds of "answers" you don't have Q&A, you have a discussion with no clear answers, just opinions.



User Reputation, Moderating, and Discourse
by T.E.D.

I think its probably inarguable that the biggest innovation StackOverflow brought to the web was the centrality of reputation and user moderation to its design. Sure, our own /. had done something similar years before, and it was hardly the first either, but no website I know of had before taken it to its logical conclusion in quite the way SO does. This effectively "crowdsourced" a lot of traditional website administrative activities, which turned out to be an incredibly powerful idea. Practically all the functionality of SO is built around the concept.

So when I saw you were tackling online message boards, I expected the same kind of thing. But browsing around a typical Discourse thread, I'm not seeing that at all. Sure, users can "heart" posts, but all that does is bump a small counter next to the heart. There is no way to tell at a glance which posts users found the best and/or worst. Higher rated posts don't sort to the top, or get bigger or anything. As a result, I don't even see that feature used much. Certainly its nothing like SO, where post voting is the central activity. It also seems like moderation on Discourse is designed to be done by administrators, not users. I don't see any facility for users getting moderation privs as they gain reputation. Compared to SO, Discourse seems kind of, well, like a big step backwards in interactivity.

I'm sure I'm missing something here. What is it? Or did you really decide SO's centering of its design around users and their opinion on posts was a mistake, or perhaps just not a good fit for a more generalized discussion board?

Atwood: Sorting a conversation by votes is a pretty effective way to destroy conversation. How can you follow the logical flow of back and forth, chronological dialog when the ground is constantly shifting underneath you as posts get voted up or down? You can't.

Stack is a system of technical Q&A, where opinions are fascinating, and all, but they are completely trumped by facts, data, and science. Stack only tolerates the minimum amount of discussion necessary to get the best questions and the best answers. The goal isn't for people to talk to each other, the goal is for people to *answer the damn question*. Ideally with the aforementioned facts, data, and science, so our peers can objectively decide if the answer is correct and works.

Discourse, on the other hand, is explicitly a system of discussion and opinion. There is no right and wrong. You can't tell me my opinion that Wolverine is the coolest X-Man is wrong. Long after people have forgotten what exactly was said, they will remember how you made them feel. That's what the like (heart) action is about, and why it is featured so prominently: empathy. Discourse is a system of empathy.

We do have user trust levels in Discourse, it's just less obvious, because we're playing a different kind of game. Compare that with Stack, where your reputation number and badge counts appear prominently next to your name every time you post. Trust me, people *do* notice when you like their post. And if they see your post got 20 likes whereas their post only got two, or none, they absolutely notice that too. Discourse is more of a collaborative game, where Stack is an explicitly competitive game, and that's why the score is so prominent. The best way to motivate a programmer is to tell them someone else did it better. Don't try to race sheep, don't try to herd race horses.

There may not be re-ordering by votes in Discourse, as there is in Stack Overflow, but there is a summary mode for topics when they reach 50 or more replies. If you'd like to see this in action, visit a longer topic and press the "Summarize Topic" button at the top near the estimated read time, or as I like to call it, the TL;DR button. Then you'll see only the "best" 10 percent of that long topic. That factors in a lot of data from each post such as likes, incoming and outgoing links to the post, the number of times it has been read, total read time (we track actual on-screen read time for all posts in Discourse), number of times it has been bookmarked, number of replies, and so on. You can also expand context above (in reply to) and below (replies) for each post as needed. Or you can expand the collapsed gaps as needed. Try it, you just need a long topic with over 50 replies to see it in action.



Cargo cult programming and Stack Overflow
by Anonymous Coward

I don't mean to minimize StackOverflow's contribution to the online knowledge base, because it's a great tool when used properly. I'm a systems guy and Server Fault is often more useful than vendor support for looking up strange error messages and possible troubleshooting routes. But, there are a lot of low skill programmers and sysadmins out there who lean on these tools way too much. How do you feel about these properties contributing to the crappy cargo cult programming and sysadmin work we see in our field?

Atwood: Stack is a system of peer education at its core. The key insight is realizing that crappy programmers hurt all of us, and it's our job to learn from each other so that we have less terrible code and terrible coders to deal with in the future. Even if that terrible coder is us!

The best way to learn a topic is to teach it to someone else. That is the skill at the heart of the Stack engine. It works at three levels:

1. Selfish. I need the answer to this question or I may get fired. Give me the answer. This is ideally handled through a good search result. They get what they need.

2. Self Improvement. I want to get reputation and prove to my peers that I know what I am doing. The more I learn, the better I am at my job, the more skilled I am, and the more job satisfaction / money / prestige I can gain.

3. Advancement of our craft. Programming, physics, and math will be here long after we are all dead. It's an honor to help move science forward together as much as we can together in our lifetime, so that future programmers, physicists, and mathematicians can stand on our shoulders and do amazing, incredible things for the future of humanity.

It's fine for people to play the game at level one, because they are also helping others learn and work their way up the skill ladder. If someone is learning, and someone is teaching, we all win.



Rampant closure of questions
by WaffleMonster

From time to time I search stackoverflow for easy answers and I would say about 20% of the time the question has been closed even though it is the reason I went to stackoverflow in the first place. In most of these instances a useful answer was also provided before closure. So my question to you is simply what gives.

The most common reason for closure I run into is that the people closing it don't have any domain clue what is being asked and appear to assume if they don't understand nobody else does either.

Another common reason for closure is the "duplicate" question meme in which nuance is overlooked and questions are marked as duplicates because the people doing the marking failed to understand or appreciate the difference. This is very annoying.

Less common but equally annoying issues are closure due to chatter about domain specific algorithms not being "programming questions" or even more amusing someone posting a question that is more specifically addressed by one of a hundred different stack exchanges even though it is still on topic.

Atwood: Remember that Stack is for questions that can be explicitly answered, *not* discussion. It's not a place for "what's the best way to.." opinion sinkholes. Humans love this kind of stuff because they are social animals, and there's nothing wrong with wanting to have a discussion -- you just need to have that discussion elsewhere, because you can't have it on Stack Overflow.

We're strict about this because we've seen what happens when systems are not explicit about their goals. This way lies madness. This way lies Yahoo Answers. In Stack's case the goal is *learning*. And I do not mean accidental, random, meandering, oh-hey-check-out-this-crazy-thing-I-saw-on-Reddit learning, but highly efficient, directed learning where you are a classroom, not a social club.

Duplicates are a hard problem, for sure. That's the one place I felt we didn't make a ton of progress in my four years there, unfortunately. Human beings have the incredibly annoying habit of asking the same questions using completely and utterly different words. They're really good at it. And it is true that over time there are more and more questions and answers on Stack Overflow, so the minefield of "is this a duplicate of...?" is only getting bigger over time. It is a super hard problem. If you have specific ideas of how to handle duplicates better, don't hesitate to ask or search some of the existing topics there.

Remember, Stack Overflow is governed by programmers just like you, you are a citizen of its community just like me, and you get a say in what happens there. You could even be elected a moderator by participating in the yearly elections. So if you don't like the way things work, it's like any other democracy -- make your voice heard, vote, campaign, or run for office.



Relevance of old answers
by Scottingham

As SO ages, some of the offered solutions are no longer valid. Are there currently plans to automate some way of validating old answers automatically? This problem seems to be a larger problem with forums in general. Do you have any musings regarding aging forums?

Atwood: Anyone, even anonymous users, can suggest an edit to any question or answer on any Stack Exchange site. It is like Wikipedia in that regard. Once two other users with sufficient reputation approve the edit it goes through. Alternately, if you earn enough reputation, you can make direct edits yourself.

If you see information that's out of date, edit it to make it more up to date! Be the change you want to see, and all that.



Signal To Noise: Trolls
by Anonymous Coward

In reading your work for years and seeing your various contributions, it seems like you are fascinated with filtering out the most useful information. In many of your blog posts the insight is not yours but rather a conglomeration of chosen useful quotes and sources. I very much appreciate this. My question for you is how do you handle critical feedback vs trolls when dealing with communities. For example, the down button is often a disagree button rather than a negative point. How do you deal with mixed opinions?

To use a real life personal example, TEF noted how he felt you were suggesting that people shouldn't play around to learn. Yet, the way he said it was clearly inflammatory. How do you separate the legitimate concern and critical feedback from the troll who doesn't want to listen to your response?

Atwood: There is a reason we don't have a "dislike" or "downvote" in Discourse. How can an opinion be wrong? It can be rude, offensive, misinformed, misguided, or just plumb crazy -- but it can't be objectively *wrong*. Often the way you judge posts in Discourse is by their *lack* of likes. If nobody feels strongly enough about your reply to push the heart button on it, and 'co-sign' it with their name in public, that says something.

As for separating legitimate criticism from trolling, I don't know that actual trolls, by the strict definition of the word troll, are that common. I think bad faith makes itself quite clear in the tone and delivery of the criticism. Are you saying this in the hope that we can both learn something from the interaction, or are you saying it because you want to hurt or shame or denigrate or discredit me? Truth alone, as it turns out, isn't the whole truth. How you say something matters.

Bad faith is especially visible to the audience, who has no stake in the argument, and can be surprisingly objective in judging authenticity. One of the most striking things about the early days of Stack Overflow was seeing how people would not upvote cruelty. They wouldn't necessarily downvote it, mind you, but overt cruelty and meanness in an answer was never an effective way to get upvotes and reputation even if the technical information was sound. The best way to win an argument isn't to convince the other person, necessarily -- good luck with that -- but to convince everyone who is watching. And you will never convince an audience watching you be cruel to another person.

In life, being cruel to others may achieve some short term goals, but it is *never* a winning long term strategy. And I think that is exactly how it should be.



How do you have a good debate online?
by AmiMoJo

It seems like the internet is mostly a terrible place to have debates. Many forums quickly become echo chambers for people who want to be as offensive as possible just to prove that they can exercise their free speech rights. Other times debates are derailed by cheap tactics like being deliberately offensive to derail the arguments and bog everyone down in accusations that they are "SJWs". Ad-hominems and obvious logical fallacies seem to be the norm.

How do you plan to avoid this happening? So far no-one seems to have found a way.

Atwood: We have a few tricks up our sleeve at Discourse. We try to teach communities not just how the software works, but how human beings should work, with stuff like our Universal Rules of Civilized Discourse which is prominently featured in every install of Discourse and of course Creative Commons licensed.

I believe in the “Just in Time" theory of human behavior where we try to reach you at the exact moment you start typing your first post with the TL;DR version of those rules. And the most important rule of all for empathy is a simple one: hey, there's another person on the other side of that screen. Not just an abstract name, an avatar, a collection of pixels, but a real live human being, just like you.

I don't know if we can weaponize empathy but I'd sure like to try. Not every space has to be open to everyone, unless you work for Facebook or Twitter. Sometimes the point of having your own community is being able to close the door on people who demonstrate that they can't behave themselves in your house. Live with wolves, and you learn to howl.



Stackoverflow in hindsight
by jez9999

In hindsight, would you have reduced the scope of on-topic questions for Stackoverflow to where it's at today when you started the site knowing what you do now, and do you think it would've made the site less popular?

Atwood: Much of the strictness of Stack Overflow evolved as a side effect of the reputation system. Once you have a reputation score, you want to protect that score, and nothing devalues your own reputation more than seeing some other programmer get 300 reputation points from a humorous answer containing nothing but an XKCD comic. Anyone can post an XKCD comic; that takes no particular competence or knowledge. So the evolution in strictness -- peer reputation should come from expression of *skill*, not funny anecdotes -- was largely driven by the community, not by anyone employed at Stack Overflow.

Even knowing what I already knew, which is that putting a number next to someone's name will cause them to do whatever it takes to make that number go up -- I didn't anticipate how strong this effect would be. But ultimately I agree with it, and I think systems should trend to slightly increasing strictness over time as they grow bigger. Big cities have different problems than small cities, and they need more structure.

No, working your company's trade show or conference booth isn't your job. But sooner or later, an awful lot of people (including me) get tagged for booth duty whether we want it or not. Fine. At least we can learn a little about how to do it well, which is why Andy Saks, of Spark Presentations, is offering us some useful tips on how to do well at trade shoms and conferences.

While Andy's focus is on corporate displays and presentations, everything he says also applies to FOSS projects that exhibit at anything from regional Linux conferences to multinational expos like OSCON and LINUXCON. And one last thought before we turn this over to Andy, who we recorded from Skype at an extremely low frame rate to make this a narrated slide show (with accompanying transcript, as usual): If you're working in a typical corporation, trade shows are often your best way to meet your own company's executives, espcially at casual after-show gatherings. You might also meet execs from other companies and be open to conversations about changing jobs, but this is not something you want to talk about with your bosses or their bosses, but is best kept quiet until or unless you have a firm offer in hand.

Brady Forrest is co-author of The Hardware Startup: Building Your Product, Business, and Brand. He has extensive experience building both products and startups, including staffing, financing, and marketing. If you are thinking or dreaming about doing a startup, you should not only watch the video to "meet" Brady, but read the transcript for more info than the video covers.

Michael Ross writes In recent years, JavaScript has enjoyed a dramatic renaissance as it has been transformed from a browser scripting tool primarily used for special effects and form validation on web pages, to a substantial client-side programming language. Similarly, on the server side, after years as the target of criticism, the PHP computer programming language is seeing a revival, partly due to the addition of new capabilities, such as namespaces, traits, generators, closures, and components, among other improvements. PHP enthusiasts and detractors alike can learn more about these changes from the book Modern PHP: New Features and Good Practices, authored by Josh Lockhart. Keep reading for the rest of Michael's review. Modern PHP: New Features and Good Practices author Josh Lockhart pages 268 publisher O'Reilly Media rating 8/10 reviewer Michael Ross ISBN 978-1491905012 summary Solid advice on some state-of-the-art PHP tools and techniques. Programmers familiar with the language and its community may recognize the author's name, because he is the creator of PHP The Right Way, a website which he describes as "an easy-to-read, quick reference for PHP popular coding standards, links to authoritative tutorials around the Web and what the contributors consider to be best practices at the present time," in 21 different languages.

Yet rest assured that the book under review is not merely a dead-tree version of the website. Instead, the book covers the more recent advancements within the language, while the website covers best practices and standards. This should be borne in mind, otherwise the reader may be baffled by the absence from the book of certain topics on the website essential to the language, such as SPL, PEAR, and PHPDoc. Moreover, of the topics shared between the book and the website, the information is generally organized quite differently, with more example code in the book.

This title was published on 1 March 2015, under the ISBN 978-1491905012, by O'Reilly Media, who kindly provided me with a review copy. Its material is presented in 268 pages, organized into 13 chapters (The New PHP; Features; Standards; Components; Good Practices; Posting; Provisioning; Tuning; Deployment; Testing; Profiling; HHVM and Hack; Community), which are grouped into three parts (Language Features; Good Practices; Deployment, Testing, and Tuning) — as well as two appendices (Installing PHP; Local Development Environments) and an index. The publisher's page does not offer much of interest. However, all of the example code is available from the book's GitHub repository. There are differences between the GitHub code and what is printed in the book, e.g., a baffling require 'vendor/autoload.php'; in the first example code file. The author claims that the reader does not need to know PHP, but at least "a basic understanding of [] fundamental programming concepts" (page xiv). However, anyone without at least intermediate skills and experience with PHP could conceivably struggle with these more advanced subjects.

The first chapter is only a brief overview of the history of PHP, its current state, and some possible future changes to the language's engine. The real content starts in the second chapter, in which the author gives the reader a fast-paced introduction to his seven favorite major new features in PHP: namespaces, class interfaces, traits, generators, closures, Zend OPcache, and the built-in HTTP server. In some regards, the coverage is a bit too fast-paced, as some topics and questions likely in the reader's mind are not addressed — for instance, namespace case-sensitivity and techniques for ensuring that a chosen namespace is globally unique (page 9). For each topic, its purpose and advantages are explained, and sometimes illustrated with code examples, although none are extensive.

The second part of the book opens with a chapter on some of the new standards in the PHP ecosystem that are intended to move the common development process from a reliance upon one isolated framework, with an idiosyncratic coding style, to distributed components that can interoperate through the use of interfaces, industry-wide coding standards, and the use of autoloaders for finding and loading classes, interfaces, and traits at runtime. Components are covered in more detail in the subsequent chapter, as is Composer, for installing components and managing dependencies. The fifth chapter is a lengthy but information-packed exposition of numerous best practices regarding input data sanitization, password handling, dates and times, and safe database queries, among other topics. Some of the advice can be found in other PHP books and online, but all of this is neatly explained, updated with the newer PHP versions, and worthwhile as a refresher.

Deployment, testing, and tuning are the broad subject areas of the third and final part of the book. The author discusses the options for hosting your PHP applications, as well as provisioning any self-managed web server and tuning a server for optimal performance. All of the instructions assume you are using Linux and nginx, and thus would be of less value to those using Windows or Apache, for instance. The material on application deployment is relatively brief, and focuses on use of the Capistrano tool. Testing is often neglected in real-world projects, but certainly not in this book, as the author explains unit and functional testing, illustrated through the use of PHPUnit. This is followed by information on how to use a development or production profiler to analyze the performance of your application, with detailed coverage of Xdebug and XHProf, among other tools. The next two chapters dive into topics related to the (possible) future of PHP — specifically, Facebook's HHVM PHP interpreter and their Hack derivative language. The final chapter briefly discusses the PHP community. The two appendices explain how to install PHP on Linux or OS X for commandline use, and how to set up a local development environment. The author mentions a free edition of Zend Server, but the vendor page mentions no such pricing.

Despite its technical subject matter, this book is not a difficult read. The author's writing style is usually light and friendly, especially in the preface. In a few places, the phrasing is a bit too terse, which might prove momentarily confusing to some readers, e.g., "Function and constant aliases work the same as [those of] classes" (page 11). The text has some errata (aside from the two, as of this writing, already reported): "curl" (pages 15, 220, and 222; should read "cURL"), "a an argument" (page 33), "Prepared statement [to] fetch" (pages 99 and 100), "with [the] php://filter strategy" (page 110), "2 Gb" (page 129; should read "2 GB"), "the the" (page 154), "path to a the code" (page 176), and "Wordpress" (page 190; should read "WordPress").

One weakness with the book is that for several of the topics — including some critical ones — there is not enough detailed information provided that would allow one to begin immediately applying that technique or resource to one's own coding, but instead just enough information to whet one's appetite to learn more (presumably from another book or a website). Secondly, some of the narrative — particularly near the end of the book, when discussing various tools — would be of less value to anyone not developing analytics environment. Beware that some of the tools require numerous dependencies. For instance, do you have Composer, Git, MongoDB, and its PHP extension installed? If not, then you won't be using XHGUI. Also, some of the installation and configuration steps are quite lengthy, with no details provided for troubleshooting issues that might arise. Lastly, despite the promise that any reader with only basic programming knowledge will be able to fully understand the book, such a reader would likely find much of its contents mystifying without further preparation from other sources.

Nonetheless, the book has much to offer, despite its slender size. Numerous resources are recommended — most if not all apparently vetted by the author, who clearly has considerable experience in this arena. Some valuable techniques are presented, such as those instances in the text where the author shows how to use iteration on large data sets to minimize memory usage. In addition, the example code demonstrates that the author has made the effort to produce quality code that can serve as a model to others. Modern PHP does a fine job overall of explaining and advocating the newer capabilities of PHP that would attract developers to choose the language for building state-of-the-art websites and web applications.

Michael Ross is a freelance web developer and writer.

You can purchase Modern PHP: New Features and Good Practices from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.

Michael Ross writes In recent years, JavaScript has enjoyed a dramatic renaissance as it has been transformed from a browser scripting tool primarily used for special effects and form validation on web pages, to a substantial client-side programming language. Similarly, on the server side, after years as the target of criticism, the PHP computer programming language is seeing a revival, partly due to the addition of new capabilities, such as namespaces, traits, generators, closures, and components, among other improvements. PHP enthusiasts and detractors alike can learn more about these changes from the book Modern PHP: New Features and Good Practices, authored by Josh Lockhart. Keep reading for the rest of Michael's review. Modern PHP: New Features and Good Practices author Josh Lockhart pages 268 publisher O'Reilly Media rating 8/10 reviewer Michael Ross ISBN 978-1491905012 summary Solid advice on some state-of-the-art PHP tools and techniques. Programmers familiar with the language and its community may recognize the author's name, because he is the creator of PHP The Right Way, a website which he describes as "an easy-to-read, quick reference for PHP popular coding standards, links to authoritative tutorials around the Web and what the contributors consider to be best practices at the present time," in 21 different languages.

Yet rest assured that the book under review is not merely a dead-tree version of the website. Instead, the book covers the more recent advancements within the language, while the website covers best practices and standards. This should be borne in mind, otherwise the reader may be baffled by the absence from the book of certain topics on the website essential to the language, such as SPL, PEAR, and PHPDoc. Moreover, of the topics shared between the book and the website, the information is generally organized quite differently, with more example code in the book.

This title was published on 1 March 2015, under the ISBN 978-1491905012, by O'Reilly Media, who kindly provided me with a review copy. Its material is presented in 268 pages, organized into 13 chapters (The New PHP; Features; Standards; Components; Good Practices; Posting; Provisioning; Tuning; Deployment; Testing; Profiling; HHVM and Hack; Community), which are grouped into three parts (Language Features; Good Practices; Deployment, Testing, and Tuning) — as well as two appendices (Installing PHP; Local Development Environments) and an index. The publisher's page does not offer much of interest. However, all of the example code is available from the book's GitHub repository. There are differences between the GitHub code and what is printed in the book, e.g., a baffling require 'vendor/autoload.php'; in the first example code file. The author claims that the reader does not need to know PHP, but at least "a basic understanding of [] fundamental programming concepts" (page xiv). However, anyone without at least intermediate skills and experience with PHP could conceivably struggle with these more advanced subjects.

The first chapter is only a brief overview of the history of PHP, its current state, and some possible future changes to the language's engine. The real content starts in the second chapter, in which the author gives the reader a fast-paced introduction to his seven favorite major new features in PHP: namespaces, class interfaces, traits, generators, closures, Zend OPcache, and the built-in HTTP server. In some regards, the coverage is a bit too fast-paced, as some topics and questions likely in the reader's mind are not addressed — for instance, namespace case-sensitivity and techniques for ensuring that a chosen namespace is globally unique (page 9). For each topic, its purpose and advantages are explained, and sometimes illustrated with code examples, although none are extensive.

The second part of the book opens with a chapter on some of the new standards in the PHP ecosystem that are intended to move the common development process from a reliance upon one isolated framework, with an idiosyncratic coding style, to distributed components that can interoperate through the use of interfaces, industry-wide coding standards, and the use of autoloaders for finding and loading classes, interfaces, and traits at runtime. Components are covered in more detail in the subsequent chapter, as is Composer, for installing components and managing dependencies. The fifth chapter is a lengthy but information-packed exposition of numerous best practices regarding input data sanitization, password handling, dates and times, and safe database queries, among other topics. Some of the advice can be found in other PHP books and online, but all of this is neatly explained, updated with the newer PHP versions, and worthwhile as a refresher.

Deployment, testing, and tuning are the broad subject areas of the third and final part of the book. The author discusses the options for hosting your PHP applications, as well as provisioning any self-managed web server and tuning a server for optimal performance. All of the instructions assume you are using Linux and nginx, and thus would be of less value to those using Windows or Apache, for instance. The material on application deployment is relatively brief, and focuses on use of the Capistrano tool. Testing is often neglected in real-world projects, but certainly not in this book, as the author explains unit and functional testing, illustrated through the use of PHPUnit. This is followed by information on how to use a development or production profiler to analyze the performance of your application, with detailed coverage of Xdebug and XHProf, among other tools. The next two chapters dive into topics related to the (possible) future of PHP — specifically, Facebook's HHVM PHP interpreter and their Hack derivative language. The final chapter briefly discusses the PHP community. The two appendices explain how to install PHP on Linux or OS X for commandline use, and how to set up a local development environment. The author mentions a free edition of Zend Server, but the vendor page mentions no such pricing.

Despite its technical subject matter, this book is not a difficult read. The author's writing style is usually light and friendly, especially in the preface. In a few places, the phrasing is a bit too terse, which might prove momentarily confusing to some readers, e.g., "Function and constant aliases work the same as [those of] classes" (page 11). The text has some errata (aside from the two, as of this writing, already reported): "curl" (pages 15, 220, and 222; should read "cURL"), "a an argument" (page 33), "Prepared statement [to] fetch" (pages 99 and 100), "with [the] php://filter strategy" (page 110), "2 Gb" (page 129; should read "2 GB"), "the the" (page 154), "path to a the code" (page 176), and "Wordpress" (page 190; should read "WordPress").

One weakness with the book is that for several of the topics — including some critical ones — there is not enough detailed information provided that would allow one to begin immediately applying that technique or resource to one's own coding, but instead just enough information to whet one's appetite to learn more (presumably from another book or a website). Secondly, some of the narrative — particularly near the end of the book, when discussing various tools — would be of less value to anyone not developing analytics environment. Beware that some of the tools require numerous dependencies. For instance, do you have Composer, Git, MongoDB, and its PHP extension installed? If not, then you won't be using XHGUI. Also, some of the installation and configuration steps are quite lengthy, with no details provided for troubleshooting issues that might arise. Lastly, despite the promise that any reader with only basic programming knowledge will be able to fully understand the book, such a reader would likely find much of its contents mystifying without further preparation from other sources.

Nonetheless, the book has much to offer, despite its slender size. Numerous resources are recommended — most if not all apparently vetted by the author, who clearly has considerable experience in this arena. Some valuable techniques are presented, such as those instances in the text where the author shows how to use iteration on large data sets to minimize memory usage. In addition, the example code demonstrates that the author has made the effort to produce quality code that can serve as a model to others. Modern PHP does a fine job overall of explaining and advocating the newer capabilities of PHP that would attract developers to choose the language for building state-of-the-art websites and web applications.

Michael Ross is a freelance web developer and writer.

You can purchase Modern PHP: New Features and Good Practices from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.

Presto Vivace writes: O'Reilly Radar has an article about how ubiquitous tracking and collection of data will fundamentally change how we live. Quoting: "This timeline — beginning for newborns at Year Zero — will be so intrinsic to life that it will quickly be taken for granted. Those without a timeline will be at a huge disadvantage. Those with a good one will have the tricks of a modern mentalist: perfect recall, suggestions for how to curry favor, ease maintaining friendships and influencing strangers, unthinkably higher Dunbar numbers — now, every interaction has a history. This isn’t just about lifelogging health data, like your Fitbit or Jawbone. It isn’t about financial data, like Mint. It isn’t just your social graph or photo feed. It isn’t about commuting data like Waze or Maps. It’s about all of these, together, along with the tools and user interfaces and agents to make sense of it."

Threatpost reports: Heatmiser, a U.K.-based manufacturer of digital thermostats, is contacting its customers today about a series of security issues that could expose a Wi-Fi-connected version of its product to takeover. Andrew Tierney, a "reverse-engineer by night," whose specialty is digging up bugs in embedded systems wrote on his blog, that he initially read about vulnerabilities in another one of the company's products, NetMonitor, and decided to poke around its product line further. This led him to discover a slew of issues in the company's Wi-Fi-enabled thermostats running firmware version 1.2. The issues range from simple security missteps to critical oversights.For example, when users go to connect the thermostat via a Windows utility, it uses default web credentials and PINs. ...Elsewhere, the thermostat leaks Wi-Fi credentials, like its password, username, Service Set Identifier (SSID) and so on, when its logged in. Related: O'Reilly Radar has an interesting conversation about what companies will vie for control of the internet-of-things ecosystem.

An anonymous reader writes Forget about some kid engineering a virulent microbe in their bedroom. As the assistant director of the Maurice Kanbar Center for Biomedical Engineering, Oliver Medvedik, puts it, "It's extremely difficult to 'improve' on the lethality of nature. The pathogens that already exist are more legitimate cause for worry.” If anything, you're better off putting energy into wrenching away your desire for McDonalds, and making sure the government doesn't impose draconian laws about DIY-bio. Here's a look at the grassroots future of biohacking and the problems with government overreach.

Today's interview guest is literally a household name: If you look at the shelves in nearly any programmer's house, developer shop or hackerspace, you'll probably see a stretch of books from O'Reilly Media (or O'Reilly & Associates, depending on how old the books are). Tim O'Reilly started out publishing a few technical manuals in the late '70s, branching from there into well-received technical reference and instructional books, notably ones covering open source languages and operating systems (how many people learned to install and run a new OS from Matt Walsh's Running Linux?), but neither Tim O'Reilly nor the company has gotten stuck in one place for long. As a publisher, he was early to make electronic editions available, in step with the increasing capabilities of electronic readers. Make Magazine (later spun off as part of Maker Media, which also produces Maker Faires around the world) started as an O'Reilly project; the company's conferences like OSCON, Fluent, and this year's Solid are just as much a manifestation of O'Reilly's proclivity for spreading knowledge as the books are, and those are only part of the picture, being joined with seminars, video presentations, and more. Tim O'Reilly is often hailed as a futurist and an activist (he was an early proponent of 3-D printing and hardware hacking, and a loud voice for patent reform) and he's got his eye on trends from global (how the Internet functions) to more personal -- like ways that physical goods can be produced, customized, and networked. So please go ahead and ask O'Reilly about what it's been like to be a publisher of paper books in an ever-more electronic world, as well as a visionary in the world of DIY and fabrication, or anything else on your mind. As usual, ask as many questions as you'd like, but please, one per post.

An anonymous reader writes "There is certainly no shortage of stories about AI systems that include the saying, 'like the brain'. This article takes a critical look at those claims and just what 'like the brain' means. The conclusion: while not a lie, the catch-phrase isn't very informative and may not mean much given our lack of understanding on how the brain works. From the article: 'Surely these claims can't all be true? After all, the brain is an incredibly complex and specific structure, forged in the relentless pressure of millions of years of evolution to be organized just so. We may have a lot of outstanding questions about how it works, but work a certain way it must. But here's the thing: this "like the brain" label usually isn't a lie — it's just not very informative. There are many ways a system can be like the brain, but only a fraction of these will prove important. We know so much that is true about the brain, but the defining issue in theoretical neuroscience today is, simply put, we don't know what matters when it comes to understanding how the brain computes. The debate is wide open, with plausible guesses about the fundamental unit, ranging from quantum phenomena all the way to regions spanning millimeters of brain tissue.'"

An anonymous reader writes "Looking to a day when modern infrastructure is network addressable, Glen Martin considers that, lacking only requisite content and relatively simple augmentation, most of what we need for smart cities already exists: 'Using smart phones, pedestrians could "wake up" the objects by accessing codes generally used by the city to identify street items that required repair. Each bit of infrastructure would make some kind of declamatory statement — sometimes gracious and welcoming, sometimes didactic, sometimes peevish. The "interlocutor" would then respond, and a brief exchange would ensue. The object would then invite the passerby to return for more conversation.'"

An anonymous reader writes "Speculating the future of human computer interaction, Tim O'Reilly contemplates how humans and things cooperate differently when things get smarter. He says, '[S]o many of the most interesting applications of the Internet of Things involve new ways of thinking about how humans and things cooperate differently when the things get smarter. It really ought to be called the Internet of Things and Humans ... is Uber an #IoT application? Most people would say it is not; it’s just a pair of smartphone apps connecting a passenger and driver. But imagine for a moment the consumer end of the Uber app as it is today, and on the other end, a self-driving car. You would immediately see that as #IoT. ... Long before we get to fully autonomous devices, there are many “halfway house” applications that are really Internet of Things applications in waiting, which use humans for one or more parts of the entire system. When you understand that the general pattern of #IoTH applications is not just sensor + network + actuator but various combinations of human + network + actuator or sensor + network, you will broaden the possibilities for interfaces and business models."

Michael Ross (599789) writes "Web designers and developers nowadays are familiar with the critical decision they face each time before building an application intended for mobile devices: whether to target a particular device operating system (e.g., iOS) and create the app using the language dictated by the OS (e.g., Objective-C), or try to build an operating system-agnostic app that runs on any device equipped with a modern web browser (primarily using HTML5, CSS3, and JavaScript), or try to do a combination of both (using a library such as PhoneGap). The second option offers many advantages, and is the approach explored in the book Mobile HTML5, authored by Estelle Weyl, an experienced front-end developer." Keep reading for the rest of Michael's review. Mobile HTML5 author Estelle Weyl pages 480 publisher O'Reilly Media rating 8/10 reviewer Michael Ross ISBN 978-1449311414 summary An extensive tutorial and reference on HTML5 and CSS3 This title was published on 14 November 2013 under the ISBN 978-1449311414, by O'Reilly Media (who graciously provided me with a review copy). The book's material, spanning 480 pages, is grouped into 14 chapters and an appendix, as well as an introduction in which the author presents the advantages of web apps versus native apps, a brief history of both categories (focusing on iPhone development), and an even briefer overview of the HTML5 APIs that are covered in depth in the chapters that follow. Prospective readers may want to first check the publisher's website, where they will find the table of contents, book details, author biography, and a list of errata (only eight as of this writing). In addition, the example code used in the book is available on the author's site. Oddly, the introduction does not specify the requisite knowledge that readers should possess to get the most out of the book. However, a solid understanding of HTML, CSS, and JavaScript would be most helpful; but prior exposure to HTML5 and CSS3 is unneeded, as is any knowledge of any JavaScript libraries, because the author intentionally eschews them in her presentation.

The first chapter, titled "Setting the Stage to Learn Mobile HTML5, CSS3, and JavaScript APIs," continues the discussion begun in the Introduction — largely focusing on the development and testing tools used throughout the book and needed by the reader if he desires to replicate the work described in the narrative. The author's sharp words against IE 6 will be especially appreciated by those designers and developers who have lost countless hours — from both their work schedules and possibly their lifespans — as a result of the rage-inducing layout quirks and other flaws of that demonic browser. Some readers may be confused by the author's instructions for accessing the developer tools in Google Chrome (View > Developer > Developer Tools); with the traditional menu bar now gone, the steps would be the menu icon > Tools > Developer tools.

The next two chapters provide fast-paced coverage of the HTML5 syntax and the new elements and attributes introduced in this latest version of the standard. There are only a few minor blemishes: The author sometimes backtracks, repeating information noted earlier, but worded somewhat differently. For instance, in the second chapter, readers are presented with the syntax of an HTML element (page 25), which is repeated ten pages later. More noticeably, the reader is told six times that the "title" element is required. In the next chapter, the discussion of the "details" and "summary" elements is quite repetitive. Incidentally, on page 76, the author mentions that the "iframe" element has a new attribute, "srcdoc," whose values should not include double quotes, which should be escaped with the """ entity; more accurately, they should be replaced entirely with that entity. Lastly, the explanation of the "sandbox" attribute values is inadequate; readers will need to consult other sources to understand the full meaning of those allowed values. Nevertheless, HTML authors of all levels of experience should be able to benefit from these two chapters.

Forms are an essential component of any dynamic website, and are covered in great detail in the fourth chapter, which explicates the many new features introduced in HTML5, such as validation and error messaging, which significantly reduce the prior reliance upon JavaScript for such functionality. The author does a fine job of explaining these promising new improvements to form elements. The only weakness is, again, redundant explanations — for instance, in the first three sections: "Attributes of <input>," "<input> Types and Attributes," and "New Values for <input> Type." A glaring example is found on page 96, where the second reader tip is echoed in the paragraph that follows it. Screenshots are provided showing the specialized keyboards displayed on the leading handheld devices for the email, URL, phone, number, search, and datetime input types. The chapter concludes with a discussion of form field validation (including use of the validity state object) and the remaining form-related elements, both new and old.

The next two chapters focus on the APIs introduced with HTML5 that were relatively well-defined at the time the book was written, beginning with those that implement SVG, canvas, audio, and video functionality within a webpage, and concluding with application cache, local storage, SQL database storage, geolocation, Web workers, microdata, and ARIA. Most of the narrative should be clear to the reader, although one problem is that sometimes the example code does not reflect the recommendations in the text. For instance, on page 136, the author notes that SVG image accessibility can be enhanced by using the "aria-label" attribute, and that the height and width need not be specified in the "embed" and "object" elements — and yet the code presented does not adhere to these guidelines. Also, on page 175, the author refers to forking code, but the code in question is not forked to a different project or revision; rather, she means different code is executed depending upon the chosen HTML5 database.

Chapters 7 through 10 focus on CSS3, including its unique selectors, color values, units of measurement, box model properties, gradients, shadows, transitions, and animations. It all begins with a review of CSS basics, including media queries and best practices — which makes this book even more viable as a single source for learning HTML and CSS coding. Media queries are touched upon only briefly, because they are covered in depth in a later chapter. Readers will likely find interesting the discussion of maximizing website performance by balancing the number of HTTP requests, the use of embedded styles, and the use of local storage of previously-downloaded CSS and JavaScript files. Oddly, there is inconsistency in the formatting of the example CSS code — for instance, three different formats on a single page (205). Nonetheless, the explanations are for the most part quite clear, aside from the "p:first-of-type" (on page 215). The many snippets of example markup and CSS clearly illustrate how cascading works, and how one can avoid overuse of IDs (and any use of !"important"). The coverage of pseudo-classes and pseudo-elements is quite thorough, with plenty of examples.

The last four chapters employ many of the topics covered earlier and apply them to responsive web design (RWD). Chapter 11 demonstrates how to use CSS 2 and CSS3 capabilities for building websites and web apps that can work and appear as best as possible on device viewports of any size — including those that have yet to be implemented. The information is valuable, marred only by a lack of CSS code showing how the examples were created (e.g., on page 343), prior to discussing the allowed property names and values, and their shorthand notation. Readers learn how to utilize multiple columns, border images, flexbox, @supports, and responsive images. That last topic is arguably the most unresolved aspect of RWD images, and perhaps that is the reason why the author does not discuss the emerging "srcset" attribute and "picture" element for handling the challenge of serving images whose file sizes are optimal for the device's viewport and connection speed. The last three chapters discuss various design and performance considerations one should bear in mind when developing for mobile devices. Most of the initial narrative is at a high level, while the later chapters get into the details of screen sizes, hardware, testing, battery life, and latency. Incidentally, the "meta" element on page 386 was probably not intended to be struck out. The book concludes with an appendix devoted to CSS selectors and specificity.

As with most technical books of this length, this one contains numerous errata: "on ithe Phone" (page xiii), "Chapters Chapter" (xxii), "a[n] OOCSS" (xxv), "that [the] Sources" (12), "never[-]used" (42), "developers that" (44; should read "developers who"), "spammers last millennium" (47; we wish!), "When [the] favicon" (51), "favico.ico" (ditto), "at [the] site" (ditto), "so [it] has" (66), "on [the] same" (77), "<detail>" (80; should read "<details>"), "Barn[e]s" (80), "])){" (95; should read "]){"), "seperate" (101), "override [the] default appearance" (102), "rangUnderflow" (121), "form control[']s value" (121), "requiredlist" (124, 125), "an list" (124), "pros of cons" (146), "first from" (149; should read "first frame"), "when [the] game" (168), "function [is] initially" (169), and "via [a] banner" (179). At this point, roughly halfway through the book, I stopped recording errata.

Most of the writing is clear and straightforward. However, some of the phrasing is a bit confusing, e.g., "is in the last call" (page 101). Other phrasing may come across as too flippant, e.g., "Duh!" (page 48). Some terms are used much earlier than when explained, e.g., "shadow DOM" (page 100). A few terms are used that can have various meanings depending upon the context, but in this book their intended meanings are not defined and likely would not be obvious to the average reader. For example, in Chapter 3, several times the author refers to the "outline" of a (presumably HTML) document and a "node" that one might create, but does not explain what is meant by those terms in these cases.

Most books that use some sort of example project to illustrate the ideas being presented, will weave it into the narrative when appropriate and/or as much as possible. The example project for this book, CubeeDoo, is mentioned countless times, but apparently not explained in its entirety, nor is discussed the stitching together of the code snippets into a complete application. As a consequence, the example project adds less instructional value to the book than could be expected given the amount of space devoted to it. Arguably, it would have been better to either make full use of the project as a teaching resource, or use a simpler application if the first option would have been overwhelming, or simply exclude it altogether from the text and, optionally, post it online for readers who wish to examine the code on their own.

In terms of the layout and presentation of the text, this book, like so many other O'Reilly Media titles, oftentimes has too little space between adjacent words, making it more difficult to read the text at a rapid pace and to quickly locate individual words known to be present on any given page (such as words found in the index). In some cases, attribute names are chopped off midway and continued on the next line, but without the standard hyphen to indicate word continuation (e.g., "ac / cesskey" on page 30). The same is occasionally done for JavaScript method names (e.g., "se / tAttribute" on page 39). Admittedly, for keywords such as element names and attributes, as well as JavaScript names, adding any hyphen might be even more misleading, as some readers might erroneously conclude that the hyphen is part of the name when not broken over two lines.

The book's primary problem is the repetition of information, not just within each chapter, but oftentimes even on the same page. This is true not only within the main text, but also in the reader tips, which sometimes present new and useful information, but far too often repeat the information found in the paragraph preceding the tip — sometimes an almost-verbatim repeat of the paragraph's last sentence. This is not of great consequence, and may be helpful to readers who miss an important point the first time it is presented. Some of it may be unavoidable, given the overlap among the various topics. But it certainly does add to the (nontrivial) length of the book.

Regardless, these are not overly important flaws. Suffused with the author's honest writing style — as well as her obvious experience and enthusiasm — Mobile HTML5 is a substantial and instructive treatment of the primary new techniques for building mobile-ready websites and web apps.

Michael Ross is a freelance web developer and writer.

You can purchase Mobile HTML5 from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

theodp (442580) writes "Over at Microsoft on the Issues, Microsoft continues to lament the computer programming skills gap of American kids, while simultaneously lobbying for more H-1B visas to fill that gap. Saying that states must do more to 'help students gain critical 21st century skills,' Microsoft credits itself and partner Code.org for getting 30,606,732 students to experience coding through the Hour of Code, claiming that K-12 kids have 'written 1,332,784,839 lines of code' (i.e., dragged-and-dropped puzzle pieces), So, if it's concerned about helping students gain programming skills, shouldn't Microsoft be donating fully-functional desktop versions of MS-Office to schools, which would allow kids to use Visual Basic for Applications (VBA)? While Microsoft's pledge to give 12 million copies of its Office software to schools was heralded by the White House and the press, a review of the 'fine print' at Microsoft suggests it's actually the online VBA-free version of Office 365 Education that the kids will be getting, unless their schools qualify for the Student Advantage program by purchasing Office for the faculty and staff. Since Microsoft supported President Obama's call for kids to 'Don't Just Play on Your Phone, Program It', shouldn't it give kids the chance to program MS-Office, too?"

An anonymous reader writes "This article at O'Reilly Programming suggests that PHP, a language known as much for its weaknesses as its strengths, has made steady progress over the past few years in fixing its problems. From the article: 'A few years ago, PHP had several large frameworks (e.g. CakePHP, CodeIgniter, and so on). Each framework was an island and provided its own implementation of features commonly found in other frameworks. Unfortunately, these insular implementations were likely not compatible with each other and forced developers to lock themselves in with a specific framework for a given project. Today the story is different. The new PHP community uses package management and component libraries to mix and match the best available tools. ... There are also exciting things happening with PHP under the hood, too. The PHP Zend Engine recently introduced memory usage optimizations. The memory usage in PHP 5.5 is far less than earlier versions.'"

An anonymous reader writes "Beyond your smartphone screen lies an infinitely more interesting world, if only you could get past the myopic app view you're currently bound to. Glen Martin ponders the existential unease lying at the root of the Internet of Things: 'We're already cyborgs: biological matrices augmented by wirelessly connected silicon arrays of various configurations. The problem is that we're pretty clunky as cyborgs go. We rely on screens and mobile devices to extend our powers beyond the biological. That leads to everything from atrophying social skills as face-to-face interactions decline to fatal encounters with garbage trucks as we wander, texting and oblivious, into traffic. So, if we're going to be cyborgs, argues Breseman, let's be competent, sophisticated cyborgs. For one thing, it's now in our ability to upgrade beyond the screen. For another, being better cyborgs may make us — paradoxically — more human.'"

An anonymous reader writes "Some folks would like you to think that 1995 was the year everybody was brought online and that, starting this year, we'll bring everything else along for the ride. If that seems far fetched to you, Glen Martin writes about how the Internet of Things has more in common with the age of steam than the digital revolution: 'Philadelphia's Centennial Exposition of 1876 was America's first World's Fair, and was ostensibly held to mark the nation's 100th birthday. But it heralded the future as much as it celebrated the past, showcasing the country's strongest suit: technology. ... While the Internet changed everything, says Stogdill, "its changes came in waves, with scientists and alpha geeks affected first, followed by the early adopters who clamored to try it. It wasn’t until the Internet was ubiquitous that every Kansas farm boy went online. That 1876 Kansas farm boy may not have foreseen every innovation the Industrial Revolution would bring, but he knew — whether he liked it or not — that his world was changing."'"

An anonymous reader writes "Using sensors to interface socially, the next generation of robots may not fit the classic idea of what a robot should be. Glen Martin writes: 'Equipped with two articulated arms, it can perform a multitude of tasks. It requires no application code to start up, and no expensive software to function. No specialists are required to program it; workers with minimal technical background can "teach" the robot right on the production line through a graphical user interface and arm manipulation.'"

davecb writes "Slaw was kind enough to post my fable on how to not have a problem with the NSA, Thank Goodness for the NSA, and a link to the more technical MAC paper. My challenge to the Slashdot community: what's the first big step to making this all come true?"

An anonymous reader writes "Recent reports of MathML's demise have been greatly exaggerated. Given the amount of marketing dollars companies like Apple, Google, and Microsoft have spent trying to convince a buying public to purchase their wares as educational tools, you'd think they'd deliver more than lip service by now. MathJax team member, Peter Krautzberger, has compiled a great overview of the current state of MathML, the standard for mathematical content in publishing work flows, technical writing, and math software: "20 years into the web, math and science are still second class citizens on the web. While MathML is part of HTML 5, its adoption has seen ups and downs but if you look closely you can see there is more light than shadow and a great opportunity to revolutionize educational, scientific and technical communication.""

An anonymous reader writes "Flow-based programming keeps resurfacing lately. FBP claims to make it easier for non-programmers to build applications by stringing together transformations built by expert programmers. Many projects have already been using similar approaches for a long time, with less (or different?) hype. Is it time to take a closer look at flow-based programming? 'Clean functions – functions without side effects – are effectively pure transformations. Something comes in, something goes out, and the results should be predictable. Functions that create side effects or rely on additional inputs (say, from a database) are more complicated to model, but it’s easier to train programmers to notice that complexity when it’s considered unusual. The difficulty, of course, is that decomposing programs into genuinely independent components in a fine-grained way is difficult. Many programmers have to re-orient themselves from orthodox object-oriented development, and shift to a world in which data structures are transparent but the behavior – the transformation – is not.'"

An anonymous reader writes "Going beyond the usual soundbites about Ada Lovelace, Amy Jollymore explores the life of the worlds first programmer: 'When I heard that Ada Lovelace Day was coming, I questioned myself, "What do I actually know about Ada Lovelace?" The sum total of my knowledge: Ada was the first woman programmer and the Department of Defense honored her contributions to computation in 1979 by naming its common programming language Ada.
A few Ada biographies later, I know Augusta Ada Lovelace to be an incredibly complex woman with a painful life story, one in which math, shame, and illness were continuously resurfacing themes. Despite all, Ada tirelessly pursued her passion for mathematics, making her contributions to computing undeniable and her genius all the more clear. Her accomplishments continue to serve as an inspiration to women throughout the world.'"

An anonymous reader writes "Questioning the W3C's stance on DRM, Simon St. Laurent asks 'What do we get for that DRM?' and has a thing or two to say about TBL's cop-out: 'I had a hard time finding anything to like in Tim Berners-Lee's meager excuse for the W3C's new focus on digital rights management (DRM). However, the piece that keeps me shaking my head and wondering is a question he asks but doesn't answer: If we, the programmers who design and build Web systems, are going to consider something which could be very onerous in many ways, what can we ask in return? Yes. What should we ask in return? And what should we expect to get? The W3C appears to have surrendered (or given?) its imprimatur to this work without asking for, well, anything in return. "Considerations to be discussed later" is rarely a powerful diplomatic pose.'"

An anonymous reader writes "Soured by his attempt to acquire a quote from healthcare.gov, James Turner compiled a short list of things developers can learn from the experience: 'The first highly visible component of the Affordable Health Care Act launched this week, in the form of the healthcare.gov site. Theoretically, it allows citizens, who live in any of the states that have chosen not to implement their own portal, to get quotes and sign up for coverage. I say theoretically because I've been trying to get a quote out of it since it launched on Tuesday, and I'm still trying. Every time I think I've gotten past the last glitch, a new one shows up further down the line. While it's easy to write it off as yet another example of how the government (under any administration) seems to be incapable of delivering large software projects, there are some specific lessons that developers can take away. 1) Load testing is your friend.'"

An anonymous reader writes "Simon St. Laurent reviews the options in the wake of recent NSA revelations. 'Security has to reboot. What has passed for strong security until now is going to be considered only casual security going forward. As I put it last week, the damage that has become visible over the past few months means that we need to start planning for a computing world with minimal trust.'"