|
Android has been declared as the most stable mobile operating system in a new report from Crittercism, a company specialising in app analysis and management. The firm looked at statistics generated by more than a billion iOS and Android applications, finding that Android KitKat’s 0.7 percent crash rate was some way below the 1.6 percent crash rate detected on iOS 7.1. Best of a bad lot?
|
|
|
|
|
A better title for them would be, "Android is a more stable OS than iOS". Because, it doesn't mention anything other than iOS.
I know it's just one user's opinion, but my last Android crashed more often in one day than my Windows Phone ever has. And technically my Windows Phone hasn't crashed. One particular app crashes periodically. The system hasn't become unstable yet.
|
|
|
|
|
I have to agree - my Lumia 1020 has been rock solid. I haven't rebooted it in ages, and it's never crashed on me (so far).
My wife's iPhone on the other hand bogs down after a week or so and needs to be rebooted. Apps crash on a regular basis too - the ones that come with iOS, not downloaded ones.
I'm surprised Windows phone hasn't caught on more to be honest; is it a "MS isn't cool" thing? Bad marketing? (It IS bad marketing).
|
|
|
|
|
My iPhone 4s, which I've updated to each new OS update, has never crashed.
|
|
|
|
|
without even reading the article... I don't believe it. 
Windows Phone > iOS > Android
|
|
|
|
|
CoffeeScript is an open source project that provides a new syntax for JavaScript. I have to say that I have a lot of respect for CoffeeScript and it got a lot of things right. "It’s just JavaScript". Sort of.
|
|
|
|
|
The “golden rule” of CoffeeScript is “It’s just JavaScript”.
That means it will never be adopted and if accurate, means there's no reason for it at all.
|
|
|
|
|
There are three categories of questions that all technical job applications should be prepared to answer. Context has been given where necessary, and for the technical questions, links leads to helpful resources or answers. Extra-special secret answer: your parachute is plaid
|
|
|
|
|
Before courts, laws, and complex social systems, we had promises—the assurance that something will be done. Promises are still one of the most important tools we have to help us navigate social encounters. "Mr. Scott. Have you always multiplied your repair estimates by a factor of four?"
|
|
|
|
|
Google is planning to “spy” on its employees for the next 100 years in order to find the secret recipe of keeping them happy and more engaged for a longer period of time, Google’s Senior Vice President of People Operations Laszlo Bock revealed in Harvard Business Review. I'd say step 1 should be: Stop tracking them
|
|
|
|
|
Does it reveal how it intends to keep them alive that long?
|
|
|
|
|
Well, they are employing "Mr. Singularity[^]". Maybe he's got something up his sleeve?
TTFN - Kent
|
|
|
|
|
And then in 2006, we delivered our first 100 percent agile project. It wasn’t all peaches and cream. We struggled to let go of things RUP had taughted us over the years. But nothing resists positive reinforcement, and soon after we would have reinvented the way we build software to fully embrace the agile manifesto. Seems good advice with everything
|
|
|
|
|
Collaboration among developers helps them stay innovative while also advancing the company's business objectives. So link arms, and agree on the best brace style
|
|
|
|
|
Kent Sharkey wrote: Collaboration among developers helps them stay innovative while also advancing the company's business objectives.
Interesting. I first took that to mean developers inside an organization, to which I would say, what total BS. But the article is talking about developers collaborating with other companies, and to that I would have to agree with the article's main points.
But others may disagree with even my "interal collaboration is BS" opinion - I tend to fly solo and in my own airspace, and I enter a "collaborative space" only when someone clearly demonstrates their ability to think, which is rare. Or, more precisely, someone that I feel is on par with my skills or has greater skills, and I'm not talking about just technical skills, but also completely different domain knowledge. Even then, I find people get stuck in their own paradigms of thought. And that's fine, if you can convince me that a different way of thinking is better than what I've figured out in my +30 years in this absurd industry.
Marc
|
|
|
|
|
Marc Clifton wrote: Or, more precisely, someone that I feel is on par with my skills or has greater skills, and I'm not talking about just technical skills, but also completely different domain knowledge.
If you want the other to have greater skills than you to collaborate, you should also take the other position about half of the time. You may provide insights to others by now instead of the other way around.
Wout
|
|
|
|
|
wout de zeeuw wrote: If you want the other to have greater skills than you to collaborate, you should also take the other position about half of the time.
I agree -- the difference for me is "collaboration" vs. "mentoring". I quite enjoy mentoring and do so quite frequently, but creating a commercial product can be put at risk when collaboration is mistaken for mentoring. I'm a good example of that -- about a year and a half ago my client started mentoring me in Ruby on Rails. There were a lot of mistakes I ended up making in the production code base, none of which were an issue (source control to the rescue!) but it took about a year of mentoring before I was able to fill the role of a collaborator. Even now, with the business domain itself, it's still 50/50. The technology was relatively easy to learn, but the business domain has years and years of knowledge that is captured only in a few people's heads.
Marc
|
|
|
|
|
I generally agree about collaborative/open work spaces. The only times I've felt them to be a net benefit has been when the primary bottleneck in my productivity has been the transfer of domain knowledge. Even then the environment, especially when multiple conversations start running at once, drives my stress levels up greatly leaving me much more exhausted at the end of the day. It's still tolerable for occasional practice, but I strongly suspect that trying to work in that sort of environment on a daily basis would burn me out out to kill the nominal knowledge xfer benefit.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Kent Sharkey wrote: So link arms, and agree on the best brace style
Or agree that the brace style doesn't matter as long as the style is consistent within the same source file.
There is no tangible benefit to using any particular brace style. This has been studied.
The book "Coding Standards" states with regard to bracket style - "I don't care". The authors are long-time C and C++ experts. Two of them are on the C++ standards committee.
A paper I have somewhere about C coding rules was a study of a number of projects over years, and found that out of 400 coding rules, only 10 of them had any effect on reducing the number of bugs. The rest were consistency for consistencies sake. There should be a tangible benefit to justify a rule. Often, such rules are just made because people like what they do. That's not a good justification for a coding standard.
|
|
|
|
|
All true, but it's the trivialities (like brace style) are what wars have been fought over for decades.
TTFN - Kent
|
|
|
|
|
I see it more as a social thing. When you're working with a team, you will have to converge to a limited set of visions, of which coding standards is a very superficial one. If a team member can't deal with a coding standard, then he sure won't be able to deal with deeper differences of opinion. Also I do prefer a code base to have a coherent feel, of which the coding standard is the first most visible no the surface.
Wout
|
|
|
|
|
Lenovo is recalling certain ThinkPad battery packs that could be a fire hazard due to overheating, which could ultimately also lead to computer damage. "I am the God of Hell fire and I bring you fire, I'll take you to burn"
|
|
|
|
|
Both Microsoft and Google have long worked on getting users answers without having to click through a number of websites. At Google, the current result of this is the Knowledge Graph and at Bing, it’s the company’s entity engine (previously referred to internally as Satori). "It's these expressions I never give that keep me searching for a heart of gold"
|
|
|
|
|
Quote: I understand why people might look at new practices with skepticism. The enthusiastic adoption of a new practice by one group creates tension with others who do not adopt the practice. The adopters can make the non-adopters feel slighted and invalidated; as if everything they had ever done in the past was wrong. The adopters, in their enthusiasm, may claim that adoption is a new requirement of professionalism. The non-adopters may claim that the adopters are fanatics who are detached from reality and ignorant of the past.
The Corruption of Agile[^]
|
|
|
|
|
Duncan Edwards Jones wrote:
The non-adopters may claim that the adopters are fanatics
who are detached from reality and ignorant of the past.
Which is nearly always true. As we've learned from the past.
You'll never get very far if all you do is follow instructions.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
