Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment Re:Dubious story, dubious subject... (Score 5, Insightful) 92

Well, there are a few "interesting" gems there. Though it's mostly business fluff. From TFA:

Such companies as Facebook (FB) and Google also have special teams that review the lines of code written by developers. It’s these people who get to decide when a new feature is ready to make its way to their websites. Not LinkedIn. It has one, huge stash of code that everyone works on, and algorithms do the code reviewing. “Humans have largely been removed from the process,” Scott says. “Humans slow you down.”

Uh, Okay. Automated code review? Um, where to begin? I think there an obvious misunderstanding on the part of the author of the article. Surely Google, FB, et. al., do CI and all sorts of automated testing. They just *also* use humans.

Incidentally, Google clearly has more products, thus more specialties and codebases. FB also, to a lesser extent. I dont think the Google Search team is the same as the Google Maps team or the Android team.

LinkedIn is a website, they have an API, messaging, maybe some mobile apps? It's not trivial, but it's probably not very close to the technical complexity of FB, and no where near the technical complexity of Google.

LinkedIn initiated Project Inversion to fix its issues and has since evolved into one of the poster children for continuous development

...by stopping all continuous dev so they could rebuild from scratch...

I think TFA misses the point in a very "PHB way" sadly. They took the time to make the devs happy and give ownership of features to devs. The result was the devs created an environment that was productive and could be continuously updated with less fuss.

To me, this is the poster child for creating a dev focused culture, and taking the time to do things the right way. Which, sadly, is the exact opposite of the conclusion of TFA and the LinkedIn PHB.

Submission + - Statistical error labels 4700 K-3rd students ineligible for 'Gifted' programs (nytimes.com)

alostpacket writes: The New York times reports that statistical scoring by the standardized testing company Pearson incorrectly disqualified over 4700 students from a chance to enter gifted / advanced programs in New York City schools. Only students who score in the 90th percentile or above are eligible for these programs. Those in the 97th or above are eligible for 5 of the best programs. "According to Pearson, three mistakes were made. Students’ ages, which are used to calculate their percentile ranking against students of similar age, were recorded in years and months, but should also have counted days to be precise. Incorrect scoring tables were used. And the formula used to combine the two test parts into one percentile ranking contained an error." No mention of enlisting the help of the gifted children was made in the Times article, but it also contained a now-corrected error. This submission likely also contains an erro

Comment Re:No "Unknown sources" and pay to "adb install" (Score 1) 82

why is SD card access a boolean decision? And why are all permissions granted permanently to apps?

Fair questions, but how would you have designed it? Think carefully about the edge cases and user experience for both questions. I think it also helps to keep in mind lessons learned from incessant dialogs. Users are now desensitized and trained to click OK, despite not having read the message.

Comment Re:Always give them a chance (Score 3, Interesting) 82

You know, I got that same feeling when the article said this was from "Russian security firm Doctor Web" and the malware dates back to October 2012.

They may be legit, but I did a double take on the name and country of the company, as well as the date.

Looks like it comes from TFA, which is next to useless for actual helpful information. No mention of what ad networks, or what apps theses were found in. They even blur the website name of where they encountered an ad. The Next Web article seems to be copy-pasta from the AV 'article' (probably better described as a press release). I clicked around their site and their links are broken and redirect to a scary 404 page that gives me instructions on how to recover Windows. Pot, kettle, anyone?

But sure enough, they sell Android antivirus software.

(Full disclosure: I sell an app meant to teach new users about Android permissions, but also give the text of the guide away -- still, take what I say with a grain of salt, like anyone else).

Java

Red Hat 'Fedora-izes' JBoss With New WildFly Java Application Server 40

darthcamaro writes "The JBoss Application Server is no more. Just like Red Hat killed Red Hat Linux in 2003 to make way for Fedora, the same is now happening with JBoss and the new WildFly project. 'There was of course the application server, there are a number of JBoss commercial products, there was the community site, etc., so when you asked someone "What is JBoss?" the answer was varied,' Jason Andersen, director, product line management, at Red Hat, explained. 'What we wanted to do was cement the idea that JBoss is a portfolio of middleware products and not just the application server.'"

Comment Re:Big Android Problem (Score 2) 176

This is something I have been hoping to get time to write for awhile, more of a Wiki with statistics of how apps creep in their permission usage. Basically a community informational tool. Unfortunately I haven't had the time, nor much server coding experience. (If anyone is interested in contributing please feel free to contact me through my website).

And while your cynical take on the "developer first market" is not far off the mark, I think we should remember that there is a social contract between dev and user. I write a program and you pay me to buy it, or look at ads to use it. This part isn't really one sided at all. The problem is actually that permissions are granted before the user has a real chance to evaluate the application. This puts the users on the defensive.

I think if the social contract between dev and user was something agreed to at the time a feature was used, that would be better. It would put both dev and user on equal ground. If an app dev needs that permissions (for technical or business reasons), and they are denied it, they can shut down the app gracefully. If a user wants to deny some overreaching, they can also do so. With this case, either side can walk away at any time.

However, when the OS starts spoofing data (like the IMEI) in place of things (ala the rejected cyanogen patch), it breaks that contract both figuratively, and possibly literally. (For example if the user has agreed to TOS, and is now breaking them). I worry as a user that if we ever hope to have a system by which we retain control over permissions, we cannot break the contract, it will start a arms race (akin to ad blocking on websites).

What we need is to give users better tools to push back against permission creep, and for devs to have opportunities to cut back to what they really need.

Comment Re:Balance it (Score 2) 176

It's not a contest -- the fact that iOS handles it well is a good thing. But it doesnt change the fact that what tepples said was also correct (though seems deprecated AFAICT). This was unfortunately the problem with that permission. It had very legitimate uses, and very nefarious ones too.

Nevertheless, you brought up the comparison to iOS. So kindly spare us the "only on slashdot" stuff when it was you who seemed to be spoiling for a brand fight.

Comment Re:Pause while in call (Score 1) 176

Games should not need it. Any time the host activity is paused the games should pause any background processing. Media players, especially music players do play in the background, even with the screen off though. So for them, it is a must.

The permission is too coarse though. They need to separate state and identity. Unfortunately they've dug a backwards compatibility hole pretty deeply though at this point.

Slashdot Top Deals

Progress means replacing a theory that is wrong with one more subtly wrong.

Working...