At least some people do know what makes a teacher effective (or claim to). While it's distressingly unknown in the wider education community, the research I'd heard of essentially boiled down to this: About 50% of overall student achievement could be attributed to "classroom management"; that is, the teacher's ability to keep the students engaged, involved, paying attention, and doing what the teacher wants them to be doing at any given moment. And there are a number of specific skills (some might call them "tricks"), which can be taught, that can help teachers get better at doing that.
The teacher does need to know *enough* about the subject to not be leading the students astray, confusing them, be able to answer questions, etc. But beyond that (and perhaps more than that), it's classroom management that really matters.
What you can do is find yourself, create an account, then "correct" your personal info until it's meaningless and no longer identifies you. (This seemed to work on MyLife, and might also work on Spokeo and others, but I haven't tried yet.)
1. The SEC is not the IRS. The SEC is concerned with transparency for investors; the IRS is concerned with collecting revenue for the Federal government. They also have different accounting and reporting rules: a company could report different net income numbers under their interpretation of each.
2. The regular SEC-required audits are performed by an "independent" auditor hired directly by the company, who anyway only signs a small one-page letter attesting that they have found that the attached financial statements conform to generally-accepted accounting principals. They don't exactly release their detailed findings to the SEC.
3. I'm sure the IRS won't find anything that is a surprise to Google - such schemes don't happen by accident, and they are not well-publicized by the company, to put it mildly. The IRS is looking for tax evasion and fraud, not arithmetic errors. Since some such schemes are legal, the IRS will be looking into the detailed interpretation of tax laws, about which they may not agree with Google's tax attorneys, as well as anything material that may have been "overlooked" or otherwise omitted from Google's tax return.
^ Irrelevant tangent. Web developers most frequently need to deliver flexible, stable, usable systems for non-developers to interact with. That's where CMS's come in. The utility of asynchronous functional multiprogramming is...debatable in such a scenario.
Drupal is totally open-source (with an extremely active and involved community) and almost entirely developer-driven, so there is no "buying", other than the kool-aid:). It also appears to be on a steady growth curve, picking up both more sites and bigger ones quite rapidly, with no signs of fly-by-night-ness that I can tell - on the contrary, it's been around for over 10 years, and despite already being well known I think it's picking up momentum faster than most similar systems. And while some systems focus on only one problem, Drupal is more flexible. There may be a tendency for it to be the tool to apply to all problems, but at least it can be used for many things without needing to learn another system.
Plus, the whole POINT of frameworks and CMS's is to solve the ROUTINE problems for you so you CAN focus on the interesting ones...
I guess one reason is there aren't many posts for "Latest book about (WordPress|Joomla|ExpressionEngine|SilverStripe|Concrete5|Plone|etc)" here. And while Drupal is arguably the most interesting of those open-source CMS's from a developer standpoint, it's still the CMS which is "pushed" much more frequently than others here (or that's my impression at least), and... it's a CMS. Aren't those only for dummy non-developers?
But Drupal is the most open, collaborative, and developer-driven CMS/CMF I know of, so it ought to be one of the most interesting ones to look at here on Slashdot.
It's more of a bandwidth and latency issue, which is more of a problem on mobile wireless devices than on typical modern wired broadband connections.
I suspect YOUR pages don't have many of these performance issues (though avoiding CSS is downright backward, unless all your pages really ARE just plain text rendered however the browser defaults make it end up). But that kind of usage is far from typical. People today want visually-rich, content-heavy, interactive web applications, not just simple pages with a little text and not much else. And most web content doesn't have the luxury of being hand-crafted by performance-minded HTML experts.
For instance, lots of people tend to upload big (as in both large dimensions and poorly-compressed) images, often hundreds of KB or even several MB, to a web page (which isn't often set up to automatically scale images on upload), then set the HTML img tag dimensions to something much smaller (sometimes even tiny thumbnail size). One of the things Silk does is re-scale the image to that smaller size in advance (optimally re-compressing it at the same time), and only send that tiny thumbnail to the end user. It probably takes screen resolution into account so that no image delivered to the mobile device would ever be larger than its maximum resolution. (If you zoom in to see only a part of a large image up close, it probably sends just the tile you're looking at.)
It does similar things with videos. One might think re-processing videos would take too long, but with the massive processing power of EC2, it becomes feasible to do such things quickly enough to be worthwhile - that is, faster for the end user than just delivering the original form of the video.
Other components of a typical web page may be linked as many separate uncompressed files, each of which is larger than it needs to be and must be requested separately (often in series, due to browser limits on the number of simultaneous connections to a given server). Silk likely combines and compresses those files (and maybe minifies in the case of HTML/JS/CSS, such as stripping out comments and whitespace, or even omitting irrelevant files, such as IE- or print-only stylesheets, or JS files that don't contain any code that is executed on the page), then transmits them using SPDY, which can be much faster than HTTP (but which most web servers, and browsers, don't understand).
There may also be a lot of content that's not initially visible (either scrolled off screen or hidden by various means with CSS). It's possible that Silk could preferentially send the visible assets (images etc.) first, then stream in the rest gradually in preparation for scrolling/zooming or interacting with the page, rather than just sending them in the order they show up in the HTML. The browser would eventually get all the assets, but it would get the visible stuff first. (I'm not sure about that, just speculating.)
Some complex Javascript could be pre-processed and optimized for both performance and code size before being sent to the browser. (For instance, it could omit code that is never called.)
It might also pre-fetch and pre-process (in the cloud) a variety of pages linked from the current page, so they are ready to send quickly from the EC2 cache as soon as you click on the link, and maybe even pre-send certain assets to the phone so they're already waiting on the device itself before you've even opened the page that needs them. And it keeps open persistent connections to popular sites so that it can fetch content from them more quickly than usual (doesn't have to do new DNS lookup or negotiate a new HTTP connection every time).
Further, it caches many common components from popular sites (images, videos, Flash, etc., maybe even CSS/JS) as shared assets, so you can get those quickly even if you've never visited the site before, so long as someone else has.
They claim to have paid great attention to not serving up "someone else's" customized content by mistake, though I'm still very concerned over the decision to form a man-in-the-middle for HTTPS connections.
...after roughly 15 posts everyone has a completely different idea.
Hear, hear!
The reason is that everyone is partly right, but not completely, and not completely wrong either.
In the US, as in the rest of the world apparently, "IT" is a generic umbrella term in the business world for "stuff having to do with computers". However, academically an "IT" degree is usually a lower-level degree (often a 2-year degree, or a 4-year degree from a less-prestigious state school or "technical/vocational college") which provides training for ordinary systems and desktop administration and the like, and is quite distinct from Computer Science (which is very mathematical) and Software or Computer Engineering (which, being offered by the engineering department, typically require engineering core courses and at least try for typical engineering rigor). (Some 2-year schools do offer "computer programming" or "software development" majors which provide a fair amount of object-oriented programming, database development, etc., but not the more mathematical/algorithmic/theoretical grounding of CS, nor exposure to a variety of language paradigms.) Further, within the overall IT hierarchy in business, there tends to be a split between "IT" as routine administration tasks and "development". The latter is where CS grads tend to congregate (in addition to pure software or game development companies, "solving big problems" for Google, Microsoft etc., and academia).
As others have stated, while a CS degree is the accepted preparation for any programming/software development job (as until recently it was just about the only major dealing with the topic), it's not necessarily the most direct academic preparation for most of those jobs. CS per se is much more mathematical and theoretical, and is most useful for solving difficult, core algorithmic problems, not necessarily building usable systems (which Software Engineering tends to deal with more), or just implementing systems in code (Programming/Software Development). But it still teaches core principles and how to think and solve problems, so it's usually good preparation for a wider array of tech/development jobs, once combined with a few years of real-world experience.
As to the original question, working an "IT" job (taking this in the sense of "IT vs development job within the overall IT hierarchy" isn't necessary bad, so long as you can apply software development tasks to it (and better yet, actual software engineering and/or CS-style problem-solving). As others have pointed out, if you can do a lot of scripting and automation, that would look fine. Also, I think doing server or database administration is far better than desktop administration or end-user phone support, which indeed would be better to avoid. It's also highly advisable to do more programming stuff in your off-work time: contribute to open-source projects, create your own projects, etc.
Enlightened employers will understand that with the economy, maybe getting the "ideal" job isn't as easy as it should be, but they won't understand if you don't do everything you can to make use of your skills - the ones you plan to use in a "real" development job - in the meantime. They typically look for people who are passionate about solving software problems, so if you appear content to just answer end-user desktop questions, that's a sign you aren't who they are looking for.
Mark Hamill was pretty good in the original. Then he had an awful car accident, which lead to some physical scars (explained by the Wampa attack), but I also think his acting was never as good after that. Though I also think he didn't grow well with the role, not knowing quite what to do beyond the naive farm boy.
They try to get the computers do do that automatically. They DO have human search quality reviewers who manually do this kind of ranking in an effort to verify how well site rank performs and highlight areas for improvement.
90% of the suggestions to "replace" Dropbox expose ignorance about why Dropbox is so popular. - Automatic, almost immediate synchronization of shared files across multiple devices of varying types (which in the process are backed up to "the cloud") - Automatic versioning of shared files - Easy sharing of files on the public internet (via a clickable link to a publicly-accessible url) - Fast synchronization and file upload/download (sometimes, due to de-duplication, where if it finds the signature already in their system, it doesn't need to store or transfer another copy of the file at all) - Dead easy for users and IT (only need to install their app, then use is essentially transparent and automatic) - Cheap (most smaller organizations may be fine with plans ranging form free to $20/month) - as opposed to how many hours of developer time setting up a custom solution? Especially across many users/devices/device types?
On the other hand, some of the security/privacy/etc. concerns are real: - Dropbox (the company) has access to your encryption keys used to secure content on the server. Thus there are various potential scenarios for your information being accessed by others or made public in some way - GLOBAL de-duplication across the entire system means your files might be identified as identical to someone else's files. At the least others could infer that an uploaded file had previously been uploaded to the system by another user (potentially leading to a court order to produce the information of all users that had uploaded a file matching that signature). Another remote possibility is two different files that generate the same signature. One user's file would be lost (ie, never uploaded to the server), while the other user(s) would be granted access to a file not belonging to them. - various TOS concerns, etc.
So people want a system as easy and transparent to use, and as useful and functional as Dropbox, but where they can keep their own server encryption keys to themselves, not mix their data up with others through global de-duplication (even potentially), perhaps host on their own servers for full access control, etc.
(Another feature that might be useful, which I haven't seen in Dropbox or any of the usual alternatives, would be automatic LOCAL file encryption on each device, to help provide security in case a laptop is stolen, for instance.)
Of course if all you need is SOME of Dropbox's functionality, particularly if your users are all technical, then there are plenty of other solutions already (such as existing version control systems).
And a butt-ugly tech demo, as well. It may have been "advanced" for the time, but it certainly wasn't any more realistic or better looking than lots of more-primitive games (at least how they used it, maybe the problem was with the artists, not the technology). But at any rate, I didn't think it was a very impressive demo even.
Linked lists. Recursion. Calling by reference. Strong typing. Explicit declaration (or at least the need of it). There are some ways around those, but these hacks are even going to warp their minds worse than not learning those things would.
What on earth makes you think you can't write a linked list, use recursion or call by reference in Javascript? You can even use strong typing and explicit declaration through programming practice (though if you omit them, it won't complain, so you can't enforce their use.)
The problem with this theory is that in California at least, the idiot voters have spent the last 35 years making every other option besides essentially imploding the government impossible by a series of moronic initiative Constitutional Amendments.
Without a thorough ground-up rewrite of the state Constitution, California is doomed to permanent and continual bankruptcy and ineffectiveness. And for once, it's through no fault of the legislators or governor. (Not that the legislators or governor are necessarily that wonderful, but even if they were, there's nothing much they could do to fix the situation.)
* Amazon doesn't need California police since they're not in California. * Since Amazon's warehouses are not in California, so California's firefighters will not be the ones to protect them.
Except that this is likely wrong. When Amazon collects money on behalf of "affiliates" who provide the product being sold as well as the fulfillment service, and those affiliates ARE located in the state, then yes, Amazon appears to have a physical presence (some 25,000 physical presences) in the state. And those affiliates are protected by California police and firefighters, do use California roads, etc.
Regardless, all this is just squabbling over who is responsible for collecting the tax that's already owed. It's far more practical to ask online businesses to do it than rely on 30 million residents to properly remember and report every online purchase they've made.
After all the states that have a sales tax do this (and they will, in time), Amazon won't have any US affiliates left. Look who's laughing now!
Besides, as I'm sure others will point out, this is not a new tax, and the state governments are not IMPOSING anything, other than the requirement that online retailers collect the existing tax, instead of relying on the honor of purchasers to themselves report and pay the tax that they already owe (but typically aren't paying).
Online retailers will say they shouldn't be burdened with the complexity, but what they really want is an unfair price advantage over in-state retailers (and what individuals want is a convenient way to not pay the taxes that they owe, then complain about how the government they are avoiding paying taxes to doesn't do enough for them).
The constitutionality is a bit ambiguous, but so long as Amazon continues to use in-state affiliates to supply and fulfill orders, I don't think they have much of a legal leg to stand on, hence their last-ditch threat to eliminate such affiliates. (If Amazon thought they could win in court under existing conditions, they wouldn't be threatening this.) Without the affiliates (or any offices or warehouses), Amazon might have more of a case that they shouldn't be required to collect the tax on the state's behalf.
The reason this is an increasing issue is not just due to the sorry state of the economy (and hence of tax revenues), but because an increasing proportion of purchases now take place online, leading to a decline in sales tax revenues even as overall sales increase. This is happening, in California at least, at the same time that, due to the infinite "wisdom" of the voters over the years, property taxes (particularly commercial property) have gone from the major source of funding to a negligible stream of money, and any new taxes require a 2/3 majority of voters to approve (it's far easier to borrow 2 future tax dollars in the form of bonds than it is to raise a current tax dollar in California...) This means that new taxes are unlikely while old taxes are declining. If people want to still have a functioning state government and services like drivable roads, education, disaster preparedness, law enforcement, and health care, revenues WILL have to increase. And without new taxes, the main way to do this is to collect more of the taxes already owed.
This isn't really about native apps vs web apps, but rather what technology to use to build the front end appearance and behavior of actual apps. Apps that use HTML/CSS/Javascript for this task, instead of Java or Objective C or whatever, are thus known as "hybrid" mobile apps.
In other words, PhoeGap etc. allow one to build a front-end interface in HTML5/CSS/Javascript, then package that up as an actual native application for various platforms (leveraging the platform's web browser under the hood). The frameworks usually allow you to take advantage of various native APIs that aren't normally accessible through a web browser (ie, that a normal web app can't use) and store data locally (ie, run the app offline), while reusing the same code across various platforms (and possibly as an actual web application version, as well).
The amount of "platform-native" programming required to implement the app on various platforms is thus minimal.
Also, some of the performance concerns are not as much of a problem as you might imagine, due to hardware-accelerated CSS3 transitions, etc. on various platforms. (Others actually convert Javascript to native code, obviating some of the potential performance issues.)
One approach might be to write a regular web app first, targeted at "modern" smartphones (primarily iPhone and Android), then convert that to a PhoeGap application that can be targeted as a native app for those platforms (and more, such as Blackberry and Windows Phone 7).
The problem with this theory is that most associates degrees from an accredited state school with transferable credits will also require a substantial subset of the very same GE courses that the state university would require for a bachelor's.
Many of them, however, will offer *certificates* without the GE requirements - just not a degree. So you could get an associate-level certificate in Computer Software Development with Java or whatever. (Sound like that wouldn't help get a job as much as a BS? You're right, it won't.) Or, yes, a non-accredited technical school will as well.
Slashdot Mirror
At least some people do know what makes a teacher effective (or claim to). While it's distressingly unknown in the wider education community, the research I'd heard of essentially boiled down to this: About 50% of overall student achievement could be attributed to "classroom management"; that is, the teacher's ability to keep the students engaged, involved, paying attention, and doing what the teacher wants them to be doing at any given moment. And there are a number of specific skills (some might call them "tricks"), which can be taught, that can help teachers get better at doing that.
The teacher does need to know *enough* about the subject to not be leading the students astray, confusing them, be able to answer questions, etc. But beyond that (and perhaps more than that), it's classroom management that really matters.
I thought "1984" was translated into many languages, but they must have never got around to Italian.
What you can do is find yourself, create an account, then "correct" your personal info until it's meaningless and no longer identifies you. (This seemed to work on MyLife, and might also work on Spokeo and others, but I haven't tried yet.)
1. The SEC is not the IRS. The SEC is concerned with transparency for investors; the IRS is concerned with collecting revenue for the Federal government. They also have different accounting and reporting rules: a company could report different net income numbers under their interpretation of each.
2. The regular SEC-required audits are performed by an "independent" auditor hired directly by the company, who anyway only signs a small one-page letter attesting that they have found that the attached financial statements conform to generally-accepted accounting principals. They don't exactly release their detailed findings to the SEC.
3. I'm sure the IRS won't find anything that is a surprise to Google - such schemes don't happen by accident, and they are not well-publicized by the company, to put it mildly. The IRS is looking for tax evasion and fraud, not arithmetic errors. Since some such schemes are legal, the IRS will be looking into the detailed interpretation of tax laws, about which they may not agree with Google's tax attorneys, as well as anything material that may have been "overlooked" or otherwise omitted from Google's tax return.
^ Irrelevant tangent. Web developers most frequently need to deliver flexible, stable, usable systems for non-developers to interact with. That's where CMS's come in. The utility of asynchronous functional multiprogramming is...debatable in such a scenario.
Drupal is totally open-source (with an extremely active and involved community) and almost entirely developer-driven, so there is no "buying", other than the kool-aid :). It also appears to be on a steady growth curve, picking up both more sites and bigger ones quite rapidly, with no signs of fly-by-night-ness that I can tell - on the contrary, it's been around for over 10 years, and despite already being well known I think it's picking up momentum faster than most similar systems. And while some systems focus on only one problem, Drupal is more flexible. There may be a tendency for it to be the tool to apply to all problems, but at least it can be used for many things without needing to learn another system.
Plus, the whole POINT of frameworks and CMS's is to solve the ROUTINE problems for you so you CAN focus on the interesting ones...
I guess one reason is there aren't many posts for "Latest book about (WordPress|Joomla|ExpressionEngine|SilverStripe|Concrete5|Plone|etc)" here. And while Drupal is arguably the most interesting of those open-source CMS's from a developer standpoint, it's still the CMS which is "pushed" much more frequently than others here (or that's my impression at least), and... it's a CMS. Aren't those only for dummy non-developers?
But Drupal is the most open, collaborative, and developer-driven CMS/CMF I know of, so it ought to be one of the most interesting ones to look at here on Slashdot.
It's more of a bandwidth and latency issue, which is more of a problem on mobile wireless devices than on typical modern wired broadband connections.
I suspect YOUR pages don't have many of these performance issues (though avoiding CSS is downright backward, unless all your pages really ARE just plain text rendered however the browser defaults make it end up). But that kind of usage is far from typical. People today want visually-rich, content-heavy, interactive web applications, not just simple pages with a little text and not much else. And most web content doesn't have the luxury of being hand-crafted by performance-minded HTML experts.
For instance, lots of people tend to upload big (as in both large dimensions and poorly-compressed) images, often hundreds of KB or even several MB, to a web page (which isn't often set up to automatically scale images on upload), then set the HTML img tag dimensions to something much smaller (sometimes even tiny thumbnail size). One of the things Silk does is re-scale the image to that smaller size in advance (optimally re-compressing it at the same time), and only send that tiny thumbnail to the end user. It probably takes screen resolution into account so that no image delivered to the mobile device would ever be larger than its maximum resolution. (If you zoom in to see only a part of a large image up close, it probably sends just the tile you're looking at.)
It does similar things with videos. One might think re-processing videos would take too long, but with the massive processing power of EC2, it becomes feasible to do such things quickly enough to be worthwhile - that is, faster for the end user than just delivering the original form of the video.
Other components of a typical web page may be linked as many separate uncompressed files, each of which is larger than it needs to be and must be requested separately (often in series, due to browser limits on the number of simultaneous connections to a given server). Silk likely combines and compresses those files (and maybe minifies in the case of HTML/JS/CSS, such as stripping out comments and whitespace, or even omitting irrelevant files, such as IE- or print-only stylesheets, or JS files that don't contain any code that is executed on the page), then transmits them using SPDY, which can be much faster than HTTP (but which most web servers, and browsers, don't understand).
There may also be a lot of content that's not initially visible (either scrolled off screen or hidden by various means with CSS). It's possible that Silk could preferentially send the visible assets (images etc.) first, then stream in the rest gradually in preparation for scrolling/zooming or interacting with the page, rather than just sending them in the order they show up in the HTML. The browser would eventually get all the assets, but it would get the visible stuff first. (I'm not sure about that, just speculating.)
Some complex Javascript could be pre-processed and optimized for both performance and code size before being sent to the browser. (For instance, it could omit code that is never called.)
It might also pre-fetch and pre-process (in the cloud) a variety of pages linked from the current page, so they are ready to send quickly from the EC2 cache as soon as you click on the link, and maybe even pre-send certain assets to the phone so they're already waiting on the device itself before you've even opened the page that needs them. And it keeps open persistent connections to popular sites so that it can fetch content from them more quickly than usual (doesn't have to do new DNS lookup or negotiate a new HTTP connection every time).
Further, it caches many common components from popular sites (images, videos, Flash, etc., maybe even CSS/JS) as shared assets, so you can get those quickly even if you've never visited the site before, so long as someone else has.
They claim to have paid great attention to not serving up "someone else's" customized content by mistake, though I'm still very concerned over the decision to form a man-in-the-middle for HTTPS connections.
No, that's not how it works at all.
...after roughly 15 posts everyone has a completely different idea.
Hear, hear!
The reason is that everyone is partly right, but not completely, and not completely wrong either.
In the US, as in the rest of the world apparently, "IT" is a generic umbrella term in the business world for "stuff having to do with computers". However, academically an "IT" degree is usually a lower-level degree (often a 2-year degree, or a 4-year degree from a less-prestigious state school or "technical/vocational college") which provides training for ordinary systems and desktop administration and the like, and is quite distinct from Computer Science (which is very mathematical) and Software or Computer Engineering (which, being offered by the engineering department, typically require engineering core courses and at least try for typical engineering rigor). (Some 2-year schools do offer "computer programming" or "software development" majors which provide a fair amount of object-oriented programming, database development, etc., but not the more mathematical/algorithmic/theoretical grounding of CS, nor exposure to a variety of language paradigms.) Further, within the overall IT hierarchy in business, there tends to be a split between "IT" as routine administration tasks and "development". The latter is where CS grads tend to congregate (in addition to pure software or game development companies, "solving big problems" for Google, Microsoft etc., and academia).
As others have stated, while a CS degree is the accepted preparation for any programming/software development job (as until recently it was just about the only major dealing with the topic), it's not necessarily the most direct academic preparation for most of those jobs. CS per se is much more mathematical and theoretical, and is most useful for solving difficult, core algorithmic problems, not necessarily building usable systems (which Software Engineering tends to deal with more), or just implementing systems in code (Programming/Software Development). But it still teaches core principles and how to think and solve problems, so it's usually good preparation for a wider array of tech/development jobs, once combined with a few years of real-world experience.
As to the original question, working an "IT" job (taking this in the sense of "IT vs development job within the overall IT hierarchy" isn't necessary bad, so long as you can apply software development tasks to it (and better yet, actual software engineering and/or CS-style problem-solving). As others have pointed out, if you can do a lot of scripting and automation, that would look fine. Also, I think doing server or database administration is far better than desktop administration or end-user phone support, which indeed would be better to avoid. It's also highly advisable to do more programming stuff in your off-work time: contribute to open-source projects, create your own projects, etc.
Enlightened employers will understand that with the economy, maybe getting the "ideal" job isn't as easy as it should be, but they won't understand if you don't do everything you can to make use of your skills - the ones you plan to use in a "real" development job - in the meantime. They typically look for people who are passionate about solving software problems, so if you appear content to just answer end-user desktop questions, that's a sign you aren't who they are looking for.
Agreed: the more mystical the cylons got, the more I lost interest.
Mark Hamill was pretty good in the original. Then he had an awful car accident, which lead to some physical scars (explained by the Wampa attack), but I also think his acting was never as good after that. Though I also think he didn't grow well with the role, not knowing quite what to do beyond the naive farm boy.
It's usually a matter of having dates for college attendance and/or a job history going back far enough to give an idea of age.
So if you trim off the older jobs and remove educational dates, people might not guess how old you are.
Also sounds a little like Apple's failed OpenDoc, from a slightly different angle.
They try to get the computers do do that automatically. They DO have human search quality reviewers who manually do this kind of ranking in an effort to verify how well site rank performs and highlight areas for improvement.
90% of the suggestions to "replace" Dropbox expose ignorance about why Dropbox is so popular.
- Automatic, almost immediate synchronization of shared files across multiple devices of varying types (which in the process are backed up to "the cloud")
- Automatic versioning of shared files
- Easy sharing of files on the public internet (via a clickable link to a publicly-accessible url)
- Fast synchronization and file upload/download (sometimes, due to de-duplication, where if it finds the signature already in their system, it doesn't need to store or transfer another copy of the file at all)
- Dead easy for users and IT (only need to install their app, then use is essentially transparent and automatic)
- Cheap (most smaller organizations may be fine with plans ranging form free to $20/month) - as opposed to how many hours of developer time setting up a custom solution? Especially across many users/devices/device types?
On the other hand, some of the security/privacy/etc. concerns are real:
- Dropbox (the company) has access to your encryption keys used to secure content on the server. Thus there are various potential scenarios for your information being accessed by others or made public in some way
- GLOBAL de-duplication across the entire system means your files might be identified as identical to someone else's files. At the least others could infer that an uploaded file had previously been uploaded to the system by another user (potentially leading to a court order to produce the information of all users that had uploaded a file matching that signature). Another remote possibility is two different files that generate the same signature. One user's file would be lost (ie, never uploaded to the server), while the other user(s) would be granted access to a file not belonging to them.
- various TOS concerns, etc.
So people want a system as easy and transparent to use, and as useful and functional as Dropbox, but where they can keep their own server encryption keys to themselves, not mix their data up with others through global de-duplication (even potentially), perhaps host on their own servers for full access control, etc.
(Another feature that might be useful, which I haven't seen in Dropbox or any of the usual alternatives, would be automatic LOCAL file encryption on each device, to help provide security in case a laptop is stolen, for instance.)
Of course if all you need is SOME of Dropbox's functionality, particularly if your users are all technical, then there are plenty of other solutions already (such as existing version control systems).
United states unemployment rate is 9.2, which is lower than that of the European Union, and only 2 points above the world wide unemployement rate.
Just thinking you might what to actually check your facts before making wild allegations.
But those European countries have far better "safety nets" to support the unemployed than we do.
It sounds like something between Excel and OpenDoc (http://en.wikipedia.org/wiki/OpenDoc, http://c2.com/cgi/wiki?OpenDoc).
And a butt-ugly tech demo, as well. It may have been "advanced" for the time, but it certainly wasn't any more realistic or better looking than lots of more-primitive games (at least how they used it, maybe the problem was with the artists, not the technology). But at any rate, I didn't think it was a very impressive demo even.
Linked lists. Recursion. Calling by reference. Strong typing. Explicit declaration (or at least the need of it). There are some ways around those, but these hacks are even going to warp their minds worse than not learning those things would.
What on earth makes you think you can't write a linked list, use recursion or call by reference in Javascript? You can even use strong typing and explicit declaration through programming practice (though if you omit them, it won't complain, so you can't enforce their use.)
No, I think he means "functional". Haven't you heard Douglas Crockford's quote that Javascript is "Lisp in C's Clothing"?
(http://www.crockford.com/javascript/javascript.html)
The problem with this theory is that in California at least, the idiot voters have spent the last 35 years making every other option besides essentially imploding the government impossible by a series of moronic initiative Constitutional Amendments.
Without a thorough ground-up rewrite of the state Constitution, California is doomed to permanent and continual bankruptcy and ineffectiveness. And for once, it's through no fault of the legislators or governor. (Not that the legislators or governor are necessarily that wonderful, but even if they were, there's nothing much they could do to fix the situation.)
* Amazon doesn't need California police since they're not in California.
* Since Amazon's warehouses are not in California, so California's firefighters will not be the ones to protect them.
Except that this is likely wrong. When Amazon collects money on behalf of "affiliates" who provide the product being sold as well as the fulfillment service, and those affiliates ARE located in the state, then yes, Amazon appears to have a physical presence (some 25,000 physical presences) in the state. And those affiliates are protected by California police and firefighters, do use California roads, etc.
Regardless, all this is just squabbling over who is responsible for collecting the tax that's already owed. It's far more practical to ask online businesses to do it than rely on 30 million residents to properly remember and report every online purchase they've made.
After all the states that have a sales tax do this (and they will, in time), Amazon won't have any US affiliates left. Look who's laughing now!
Besides, as I'm sure others will point out, this is not a new tax, and the state governments are not IMPOSING anything, other than the requirement that online retailers collect the existing tax, instead of relying on the honor of purchasers to themselves report and pay the tax that they already owe (but typically aren't paying).
Online retailers will say they shouldn't be burdened with the complexity, but what they really want is an unfair price advantage over in-state retailers (and what individuals want is a convenient way to not pay the taxes that they owe, then complain about how the government they are avoiding paying taxes to doesn't do enough for them).
The constitutionality is a bit ambiguous, but so long as Amazon continues to use in-state affiliates to supply and fulfill orders, I don't think they have much of a legal leg to stand on, hence their last-ditch threat to eliminate such affiliates. (If Amazon thought they could win in court under existing conditions, they wouldn't be threatening this.) Without the affiliates (or any offices or warehouses), Amazon might have more of a case that they shouldn't be required to collect the tax on the state's behalf.
The reason this is an increasing issue is not just due to the sorry state of the economy (and hence of tax revenues), but because an increasing proportion of purchases now take place online, leading to a decline in sales tax revenues even as overall sales increase. This is happening, in California at least, at the same time that, due to the infinite "wisdom" of the voters over the years, property taxes (particularly commercial property) have gone from the major source of funding to a negligible stream of money, and any new taxes require a 2/3 majority of voters to approve (it's far easier to borrow 2 future tax dollars in the form of bonds than it is to raise a current tax dollar in California...) This means that new taxes are unlikely while old taxes are declining. If people want to still have a functioning state government and services like drivable roads, education, disaster preparedness, law enforcement, and health care, revenues WILL have to increase. And without new taxes, the main way to do this is to collect more of the taxes already owed.
This isn't really about native apps vs web apps, but rather what technology to use to build the front end appearance and behavior of actual apps. Apps that use HTML/CSS/Javascript for this task, instead of Java or Objective C or whatever, are thus known as "hybrid" mobile apps.
In other words, PhoeGap etc. allow one to build a front-end interface in HTML5/CSS/Javascript, then package that up as an actual native application for various platforms (leveraging the platform's web browser under the hood). The frameworks usually allow you to take advantage of various native APIs that aren't normally accessible through a web browser (ie, that a normal web app can't use) and store data locally (ie, run the app offline), while reusing the same code across various platforms (and possibly as an actual web application version, as well).
The amount of "platform-native" programming required to implement the app on various platforms is thus minimal.
Also, some of the performance concerns are not as much of a problem as you might imagine, due to hardware-accelerated CSS3 transitions, etc. on various platforms. (Others actually convert Javascript to native code, obviating some of the potential performance issues.)
One approach might be to write a regular web app first, targeted at "modern" smartphones (primarily iPhone and Android), then convert that to a PhoeGap application that can be targeted as a native app for those platforms (and more, such as Blackberry and Windows Phone 7).
For more about this, see:
http://www.technologyreview.com/computing/37831/
http://www.appmobi.com/index.php?q=node/95
http://www.amazon.com/Developing-Hybrid-Applications-iPhone-JavaScript/dp/0321604164
The problem with this theory is that most associates degrees from an accredited state school with transferable credits will also require a substantial subset of the very same GE courses that the state university would require for a bachelor's.
Many of them, however, will offer *certificates* without the GE requirements - just not a degree. So you could get an associate-level certificate in Computer Software Development with Java or whatever. (Sound like that wouldn't help get a job as much as a BS? You're right, it won't.) Or, yes, a non-accredited technical school will as well.