And none of those things are built in. If you need to carry around a keyboard/mouse or gamepad you lose the main advantage of a phone- that you already have it in your pocket. If you're carrying around special equipment you may as well just buy a handheld device.
Upper management prefers this. I don't think this is anywhere near universal at the lower levels- they realize that the top 10% of developers save their asses. Then again, this is why I work for small companies and startups and not anything outside the tech industry- management at small places is smarter than that or fails quickly.
Its mostly people and talent, but the question of what you're doing is important too. Agile is great for things that are easily visible to customers- UI development or web pages, for example. It fails where you have other systems depending on you- a back end service can't change that quickly or have stability issues. Of course, you can do different methodologies for different parts of a complex system and use each where they make sense.
The problem is the whole Agile mindset says that you don't need to put in thought up front on requirements- they'll just refactor everything mid-project to accomodate changes. Its a wonderful way to make millions as a consulting company- you're never over time or over budget because it was never agreed what or when you'll deliver an end project in the first place.
The problem is you can't avoid mediocrity- most programmers are mediocre. And in more corporate environments the percentage of mediocre and bad goes up, as the really good programmers tend to gravitate towards pure software shops and startups. The trick is to give them parts that stretch their abilities but don't overwhelm them, which requires good management.
The problem with Android is limited controls. No keyboard/mouse, no dpad, no buttons, not a convenient form factor. It greatly limits the type of games it can play. It can soak up a good amount of the casual market, but there's a market for something more. You can make a phone with those controls built in, but Sony tried that with the Experia Play and didn't do too well.
You're going to be installing software that they don't know that has low level access to the hardware and could potentially harm it. Voiding the warranty makes sense to me- they can't be responsible for harm done by software they can't control. It doesn't apply to apps, because the apps don't allow direct hardware access except through the APIs Google has written and tested.
Except nobody's feet are exactly 1 foot. Nor is anyone's 1000 paces exactly 1 mile. If those were truly universal measurements, you'd have some point. As they're not, you don't. And in the long term we'd save money by being on the same system as literally every other country in the world by removing the possibility of tooling mistakes, idiocies like NASA Orbiter problem, and additional cost to companies trying to sell in the US of having to have both measurements in their workflows and computer systems.
I thought I had read elsewhere that the chemicals she used were from school. I can't confirm, but given the tiny amounts that isn't suspension or expulsion worthy- its worthy of a slap on the wrist for not getting permission.
I've done a bit of everything (firmware, mobile, back end systems, etc), but admittedly have never set up a distributed message queue. I did work at Amazon for 2 years, they didn't use Rabbit or AMQP for their middleware at that time. No idea if they do now or not. But I have friends who do that stuff and talk shop frequently, and they've never mentioned either. I wonder if its not quite as big as you think it is.
I think a detention for a day for stealing the supplies and not seeking supervision would have been appropriate. Criminal charges and expulsion definitely not. I like the other guy's idea of having her calculate the amount of heat generated and pressure built up by the reaction to see how dangerous it could have been if she had scaled up as part of her detention.
Never even heard of either of them. Of course there are a few stories of functional languages being used- they're just a sub single digit percentage of apps.
They can also be kidnapped, in an accident, or killed. They can also disappear to avoid debts and other obligations, rather than just wanting a new life. Stopping searching entirely sounds like a really bad idea. For those who did just want a new life, the cops don't have to tell anyone they found them.
When that language family accounts for 90% of all professional development (with the remainder going almost exclusively to Javascript, perl, and php not functional languages) that's perfectly ok. In 12 years I've never seen a functional language used anywhere I've worked. Heard rumors of it, but never seen one put into production. Even the rumors weren't about production, but some one off dev tool some guy wrote for his own use.
And are the unit tests bug free? Do they test every corner case possible? Please note that even 100% test coverage doesn't mean all corner cases are tested if you're using an exception based language.
There's a much smaller chain there- C++->machine code. Here we're talking about Language X->Javascript, then interpreting that Javascript in a VM in your browser. Oh, and add a possible JIT step in between. And factor in that there's multiple VMs (each browser has its own).
That sounds like a maintenance nightmare. The code you're writing and debugging is not the code actually running, making debugging require you to know a second language and be able to figure out where the bug is in both. No thanks, that sounds like a great way to waste lots of time. I hate Javascript, but until something else is native in the browser there is no alternative.
One of the nice things about MITX is that the homework and tests are the same they take at the actual school. No watering down. Of course the negative is that you don't have all the resources you would on campus (fellow students, office hours, etc), making it harder.
I don't know anyone taking MOOCs who give a crap about accreditation. We're all professionals in that or other fields taking them out of pure interest in knowledge. Accreditation isn't needed, and in fact isn't really wanted- we'd then have to pay, have to care about taking the test, doing work on time (not always easy with a full time job, family, etc). All for credit in some course in a field we have no desire to enter. No thanks.
What I think is needed is actual community building- local communities where we can actually communicate face to face with people currently in the class or who completed it recently, as reinforcement to keep going and to answer questions with better feedback than you get from forums. The first MITX course in EE had this going on well, but subsequent offerings have fallen down on the community feeling- partly because changes to the forum structure made it harder, partly because not being new fewer advanced students took it to help teach.
I'm a software engineer, with some training in electrical engineering. I'm currently taking one on civil engineering. Trust me, its still a challenge- it requires mastery of physics concepts I haven't touched since high school, and some I was never really taught that I have to learn concurrently.
That states that the IRS may require you to prove you have insurance. A letter from your insurance agency with a policy number or insurance card does that. It does not require or imply that the IRS has access to your medical records. Most likely it will just be a line on the 1040- do you have insurance, check yes or no. If yes, provide ID number and provider. If no, add $X to line Y.
But the NDK fully supports x86 as well as several flavors of ARM. So there's no reason for this to be the case, other than laziness (note that this only started around 1-1.5 years ago, older apps do have an excuse).
Slashdot Mirror
And none of those things are built in. If you need to carry around a keyboard/mouse or gamepad you lose the main advantage of a phone- that you already have it in your pocket. If you're carrying around special equipment you may as well just buy a handheld device.
Upper management prefers this. I don't think this is anywhere near universal at the lower levels- they realize that the top 10% of developers save their asses. Then again, this is why I work for small companies and startups and not anything outside the tech industry- management at small places is smarter than that or fails quickly.
Its mostly people and talent, but the question of what you're doing is important too. Agile is great for things that are easily visible to customers- UI development or web pages, for example. It fails where you have other systems depending on you- a back end service can't change that quickly or have stability issues. Of course, you can do different methodologies for different parts of a complex system and use each where they make sense.
The problem is the whole Agile mindset says that you don't need to put in thought up front on requirements- they'll just refactor everything mid-project to accomodate changes. Its a wonderful way to make millions as a consulting company- you're never over time or over budget because it was never agreed what or when you'll deliver an end project in the first place.
The problem is you can't avoid mediocrity- most programmers are mediocre. And in more corporate environments the percentage of mediocre and bad goes up, as the really good programmers tend to gravitate towards pure software shops and startups. The trick is to give them parts that stretch their abilities but don't overwhelm them, which requires good management.
The problem with Android is limited controls. No keyboard/mouse, no dpad, no buttons, not a convenient form factor. It greatly limits the type of games it can play. It can soak up a good amount of the casual market, but there's a market for something more. You can make a phone with those controls built in, but Sony tried that with the Experia Play and didn't do too well.
You're going to be installing software that they don't know that has low level access to the hardware and could potentially harm it. Voiding the warranty makes sense to me- they can't be responsible for harm done by software they can't control. It doesn't apply to apps, because the apps don't allow direct hardware access except through the APIs Google has written and tested.
Except nobody's feet are exactly 1 foot. Nor is anyone's 1000 paces exactly 1 mile. If those were truly universal measurements, you'd have some point. As they're not, you don't. And in the long term we'd save money by being on the same system as literally every other country in the world by removing the possibility of tooling mistakes, idiocies like NASA Orbiter problem, and additional cost to companies trying to sell in the US of having to have both measurements in their workflows and computer systems.
I've got an '01 Ford. MPH only, I'm pretty sure. A few years older than that, but not absurdly old to be on the road.
I thought I had read elsewhere that the chemicals she used were from school. I can't confirm, but given the tiny amounts that isn't suspension or expulsion worthy- its worthy of a slap on the wrist for not getting permission.
I've done a bit of everything (firmware, mobile, back end systems, etc), but admittedly have never set up a distributed message queue. I did work at Amazon for 2 years, they didn't use Rabbit or AMQP for their middleware at that time. No idea if they do now or not. But I have friends who do that stuff and talk shop frequently, and they've never mentioned either. I wonder if its not quite as big as you think it is.
I think a detention for a day for stealing the supplies and not seeking supervision would have been appropriate. Criminal charges and expulsion definitely not. I like the other guy's idea of having her calculate the amount of heat generated and pressure built up by the reaction to see how dangerous it could have been if she had scaled up as part of her detention.
Never even heard of either of them. Of course there are a few stories of functional languages being used- they're just a sub single digit percentage of apps.
They can also be kidnapped, in an accident, or killed. They can also disappear to avoid debts and other obligations, rather than just wanting a new life. Stopping searching entirely sounds like a really bad idea. For those who did just want a new life, the cops don't have to tell anyone they found them.
When that language family accounts for 90% of all professional development (with the remainder going almost exclusively to Javascript, perl, and php not functional languages) that's perfectly ok. In 12 years I've never seen a functional language used anywhere I've worked. Heard rumors of it, but never seen one put into production. Even the rumors weren't about production, but some one off dev tool some guy wrote for his own use.
And are the unit tests bug free? Do they test every corner case possible? Please note that even 100% test coverage doesn't mean all corner cases are tested if you're using an exception based language.
There's a much smaller chain there- C++->machine code. Here we're talking about Language X->Javascript, then interpreting that Javascript in a VM in your browser. Oh, and add a possible JIT step in between. And factor in that there's multiple VMs (each browser has its own).
That sounds like a maintenance nightmare. The code you're writing and debugging is not the code actually running, making debugging require you to know a second language and be able to figure out where the bug is in both. No thanks, that sounds like a great way to waste lots of time. I hate Javascript, but until something else is native in the browser there is no alternative.
One of the nice things about MITX is that the homework and tests are the same they take at the actual school. No watering down. Of course the negative is that you don't have all the resources you would on campus (fellow students, office hours, etc), making it harder.
Have you tried the MITX engineering classes? They were on par or above anything I took at a respected undergrad (UIUC).
I don't know anyone taking MOOCs who give a crap about accreditation. We're all professionals in that or other fields taking them out of pure interest in knowledge. Accreditation isn't needed, and in fact isn't really wanted- we'd then have to pay, have to care about taking the test, doing work on time (not always easy with a full time job, family, etc). All for credit in some course in a field we have no desire to enter. No thanks.
What I think is needed is actual community building- local communities where we can actually communicate face to face with people currently in the class or who completed it recently, as reinforcement to keep going and to answer questions with better feedback than you get from forums. The first MITX course in EE had this going on well, but subsequent offerings have fallen down on the community feeling- partly because changes to the forum structure made it harder, partly because not being new fewer advanced students took it to help teach.
I think intertia, power consumption, and lack of a value proposition are hurting atom far more than the NDK issue.
I'm a software engineer, with some training in electrical engineering. I'm currently taking one on civil engineering. Trust me, its still a challenge- it requires mastery of physics concepts I haven't touched since high school, and some I was never really taught that I have to learn concurrently.
That states that the IRS may require you to prove you have insurance. A letter from your insurance agency with a policy number or insurance card does that. It does not require or imply that the IRS has access to your medical records. Most likely it will just be a line on the 1040- do you have insurance, check yes or no. If yes, provide ID number and provider. If no, add $X to line Y.
But the NDK fully supports x86 as well as several flavors of ARM. So there's no reason for this to be the case, other than laziness (note that this only started around 1-1.5 years ago, older apps do have an excuse).