Some years back, I worked in home automation. During that time, I realized that the key is not retrofitting a home (that's an invitation for trouble or gimmickry) but to build a home with smart features in mind in the first place (ex: vent airflow and temperature sensors, actuators to adjust vents, etc.) Unfortunately, house builders were not really serious about the effort at the time and resorted to gimmickry anyway, when they could (calling a movie theater room with a single light and a touch panel controller 'home automation.')
What landed me the job was my "resume" - which was a side project where I automated a window shade controller and controlled it remotely through a linux machine. I cannibalized a worm gear out of an old VCR, connected it to a rotary window shade thing. Believe I used a segment of duct tape as a rudimentary U-joint. The motor was controlled by the parallel port and an H bridge, and a cron task would open the window shades in the morning and close them in the evening.
That was my first lesson in home automation: longevity. Home automation products, being new, aren't really tested for durability. My prototype certainly wasn't. At some point the contact switches I used for measuring rotation failed, and I came home to my venerable Linux machine twisting the window shades for hours.
Before you condemn American people for being unstable, you may want to step back and examine the relationship between medicare, medicaid, and substance abuse clinics in the states.
Short story is that some substance abuse clinics have started to diagnose abusers with mental disorders in proportions never seen before. Why? Possibly because state and federal funds will unquestionably reimburse for treating users - but the DSM IV diagnoses cost astronomically more than weaning drugs. This trend alone is responsible for pharmaceutical ramp-up, as drug prescriptions went up more than 100-fold in some places.
I use the 980x for my minecraft server - and - it's made a difference. I'm pretty sure the number of concurrent players can approach 100 without any lag or making the machine sweat. Software problems, on the other hand, are a different issue.
Mobile computing is on the rise, and gaming is a strong component of it. There is a toolkit that will let you program in LUA (fairly common in game engines these days) and it will generate programs for both iPhone / iPad and Android at the same time. Programming is simple and the new game engine employs physics and other gizmos.
Having access to and mutilating the environment are two completely different things. Treating developers as hostiles by server admins doesn't create the friendliest work environment.
There is a big difference between a bug and the reason why the bug occurred - having access to a production environment is paramount to understanding the underlying issue.
In most newspaper sites the headline / lede / seo field / first graf may is usually programmatically brought in as the META description for SEO purposes (unless specifically overridden). It's a fairly common assumption that this field would be pure text and overlooked in that it doesn't need sanitization. Of course, it's also a fairly common consequence that some silly editor eventually breaks the site by putting HTML code in fields they weren't meant to house. You'd be surprised how many (even big) media sites fail to sanitize these fields.
Onto my point: having HTML (or faulty HTML for that matter) inside a HEAD description field seems like a bug. Sure, you can replicate the error by copying the environment and fix it by stripping anything unexpected out. However - that may not be the root of the problem. Thus, developers end up putting bandaids on a system and treating symptoms rather than curing the problem.
When copying this environment to reproduce the issue, one might simply grab the part that's affected, ignoring the user - CMS preferences which would actually end up telling you what the problem was. What a developer SHOULD do instead is poke around the environment, notice that this was a common occurrence with particular users, talk to the editors in question and shadow them for awhile to understand why this sort of thing keeps repeating.
In many cases, I've seen editors take advantage of programming or security holes to produce far richer and personalized web content than the original design or system permitted. By treating this problem out of the production environment context, the editorial side is completely cut out of the feedback and has no say in the matter and their creative outlet disappears with no dialogue. This in turn breeds hostility and distrust between technology and content.
I can assure you that in reality there is minimal dialog between developers, designers, project managers - and - editors. In my past experience access to the production environment was the only means of lateral communication between abstract technology and persons who use it. In my cases, I've been able to provide editors with features they hesitated to request to circumvent problems while still tightening various holes. This, in turn, improved everyone's day.
Look at it from a philosophical view- you don't want developers to be "writin' them codes" in vacuum of non-editorial space. They need to be a bit more intimately involved with the entire publishing cycle from start to end and not be ticket-solving space cadets when it comes to solving problems.
Actually, they are. The new PHP contribution is NOT efficiency-related. Instead, they built privacy controls into PHP. However, the problem is that by default it's set to open.
This wouldn't be a question of data entry. In most cases, the data is already there. All you need is a way to connect it. For example, the U.S. Census Bureau has a list of neighborhoods and their polygonal borders.
Now, the CS students in your reference would simply apply a PIP (point-in-polygon) algorithm to see which neighborhood a particular lat, lon coordinate belongs to.
And since that's computationally intensive, the CS "students" would have to know a bit about optimization - including quad trees, and so forth. Bla.
While vi and a Web Browser is good enough for some, I'd take just the Web Browser. Rapid development needs to break out of the constant theoretical-writing-uploading/saving-previewing cycle and that's why I put together my "eval2" project for PHP.
While the example is ultra-simplistic, I use this every day for altering regex or otherwise previewing REAL data as I protoype code. Anyhow, the typical horse and buggy mentality backlash against this approach has been "well, I can just do php -a".
This is really simple: provide data feeds to the public -- from various government collection sources.
End of story. We don't need the government to spend months, or years even, building websites which dumb data down for us. Give us the raw data feeds and let us create mashups, interactive content and let people make their own judgment based on it. Sure, some sites might need heavy design (such as educational loan repayment sites, etc).
Apparently you can't make heads-or-tails of terminology either. You're thinking strict code execution, while I'm thinking conceptual division. In this case, I thought it was pretty obvious that I was referring to a CMS; I'll be sure to spell things out clearly next time.
And- just for the record, neat trick indeed. JavaScript can be and is executed server-side as well as client-side. The Dojo release build system works like that. See http://www.mozilla.org/rhino/
Being a practical type, I must confess that the learning curve with Dojo has been rather steep; having said that, once you get over the first major hump - it's literally all downhill from there. But, I'm not defending Dojo. Instead, I'm complimenting the book.
This book appears to solve the learning curve problem by starting with a practical tutorial and then going into guts.
IMO, the biggest problem with Dojo's userbase growth has been that Dojo seems to be both large and small at the same exact time, making it difficult to get oriented. One thing that developers should keep in mind is that Dojo is very scalable; performing a custom build will whittle it down from its 37+ MB source distribution (yes, graphics included) to however low you need it (in my case, couple of hundred kilobytes - smaller than some logo images out there).
In my case, I've completely embraced Dojo as a reliable way to quickly produce backend systems with it - and - more recently - front ends.
But that's just work. As for fun - without Dojo, I don't think that I would have put my open source project together or released it to the public. There are so many hours in a day and I don't have time to reinvent the wheel; Dojo was there for me.
For some amusing interaction between Dojo and PHP (not using the Zend framework..), see the videos / screenshots from http://eval2.sourceforge.net/
My 2c: The best way to answer some tougher programming questions is to prototype specific tasks. Part of this process requires that you have an always-ready environment that allows you to do so.
Your own prototyping tools would in this case simply be a ready environment which would permit you to just jump into code without worrying about prerequisites. Something as simple as a prepared template would do, or a tool like this one:
http://www.youtube.com/watch?v=Yfxrt2pc3pg
Having been around for some years on this technocratic Earth, and having experience programming in pretty much all the standard (and some exotic) languages, I can say this: no matter which programming language a person might use, that programming language ultimately executes in machine code. Having said that, the most efficient way of writing code is in assembly.
What drives the wedge between pragmatists and idealists is development time. I could probably optimize my projects at work by dumping PHP and writing CGI programs in assembly - but - at what cost? Rather than spend $10k on development time, it's a better utilization of resources to lease a dual Xeon server for an entire year to meet performance requirements of the system. Not efficient on code level, but absolutely makes sense on a business level. Similarly, I could have employed C for previous data acquisition projects but LabView and G code allowed the project to be completed in two weeks instead of two months. During that time difference, numerous graduate students managed to put the system to good work. Time does matter.
Even assembly is not straight forward. You must be aware of all opcodes for your code to be efficient, and that means knowing which hardware you're developing a program for. Who has that amount of time to learn engineering specs of processors? Even C and C++ compilers aren't entirely efficient when it comes to generating programs. For amusement, see this classic piece:
This guy spends hours optimizing a program so to reduce its executable size from 3998 bytes to 45 bytes. In this process, it's not just the storage size of the program but also the number of instructions the program goes through. A great achievement in its own right, but, not worth the trouble for larger programs. After all, isn't point of programs to basically do a job? In other words, it's more efficient to write the program once (even if it's inefficient) and leave it be -- rather than rewrite it continuously until it's absurdly efficient.
There is a reason why R.A.D. has been given an acronym and everything. I'm afraid that in this hodge-podge of processors, operating systems, hardware, etc, the wisest course of action is to shoot for completing a task if the outcome is correct. It's ridiculous to expect today's programmers to stick to a single language and learn it intimately: that's just not how things work in the real world.
Now, I'm not endorsing Vista's inefficiencies or anything - just talking about day-to-day programming.
There is absolutely no reason why an infrared remote controller couldn't be bidirectional. Added parts are fairly cheap - an extra photodiode. (I am skipping any other logic, microcontroller programming, and other dependencies). Therefore - you (well, the manufacturing-design engineers) could program a TV's firmware to 'authenticate' a particular remote controller. Assuming this authentication is done at a "safe" moment in time - when no one is looking - a code-hopping solution could be easily devised.
Of course - good luck getting a manufacturer to bother. We will be soon (on a historical scale anyway) approaching the first centennial of the invention and I would be surprised if by that time your DVD player could 'talk' to the TV natively - or any other devices for that matter. Consolidating all of these TV technologies into a cohesive solution hasn't happened yet.
How do you recognise good grave diggers if you're a business guy?
It's not as easy as it sounds. CV experience is only of limited use here, because great grave diggers don't always have the "official" experience to demonstrate that they're great. In fact, a lot of that CV experience can be misleading. Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone's a great grave digger.
I consider myself to be a pretty good grave digger. At the same time, I've spent a fair amount of time on the business side of the fence, filtering technical CVs for projects, interviewing people, etc. Thanks to this, I think I have a bit of experience in recognising good grave diggers, and I want to share it in this article, in the hope that it may help other "business guys" to recognise good grave diggers. And, who knows, perhaps some grave diggers who have the potential to be good but haven't really exploited this can also read this and realise what they need to do to become good (although, as I'll argue, that's definitely not accessible to all grave diggers!).
Ok, that's enough cutting and pasting. Seriously..this article is a bit sickening; it's all about dehumanizing the human being. Mark of a good programmer? Why not apply the phrenology test? Their skulls must have a particular shape in order for them to be "good."
I agree with you that it may be a desperate move; but, lets face it - this is nothing out of the ordinary. This sort of thing has been done time and time again. In order to protect its own market from cheap foreign knockoff souvenirs, they are enacting these regulations. USA does it on a daily basis.
Though, here is an amusing precedent for you. Look at the original Christian gospels; in Acts of the Apostles, Paul visits Ephesus so to try to convert the local heathens. The locals, who worship the (to us classical) Greek pantheon of gods and goddesses, don't reject Jesus and monotheism. They are just upset that by replacing their gods with a single God (and Jesus), the local silversmiths would lose out on their souvenir trade: selling statues of Diana. So religion and (nationalism) take back seat to economy.
Not to criticize your humor (which is funny), but, from a historian's point of view:
This cliché statement (..doomed to repeat..) relies on the supposition that progression of events is linear in history. In other words, it's the idea that there is a sequence of events that seemingly always leads to the nearly-same end result. Part of this statement also assumes that progression of events may be cyclical -- but -- it's arrogant to assume that this cliché applies to every situation. Often it does not.
In other words, why do we assume that the cost of digital storage is always going to remain that high respective to economy? We are looking at the horizon of solid state hard drives that are actually affordable by the general public. Ten years ago this SSD concept seemed inconceivable - neither profitable for industry nor affordable by the consumers. Technologies will change and somewhere (or somewhen) out there - there may be a niche for a company to make digital preservation profitable.
So the person (namely, article author) who yells [Why are we jumping on this technological bandwagon without thinking of the consequences???] is a classic case of a declensionist attitude (things are getting worse..). Standing opposite to that attitude is the progressive one (things are getting better) - but - I don't subscribe to it either. I think there is a healthy sinusoidal bounce between good and bad aspects of digital film storage and it's completely up to time to reveal the outcome.
I agree with some of the previous posters that have faulted programmers for "the state of today." My feeling is that the divide between knowledge of hardware and knowledge of software is far too wide. In my experience, I have witnessed many programmers who spent more time organizing the readability of their code than analyzing the actual effectiveness of it: i.e. whitespace use vs algorithm optimization (be it processor method + instruction or i/o improvement). The end result: bloaty-pooh.
I feel that by making threading a C++ standard, or at least making the threading model a predominant one, the overall "state of today" will improve in the near future simply because more programmers will be aware of it. Parallel processing really does require some training -- it cannot be adapted to every task.
Take for example a simple thumbnail-generating program (a form of is used by everyday users). If the program is written in its traditional linear model, it would not take advantage of multiple processors or cores (unless you ran multiple instances of it or otherwise manipulated it in an unplanned fashion). However, if the program utilizes threading, it could become scalable without requiring any intervention. Knowledge of hardware -- and not necessarily relying on the compiler to optimize your code just might help.
The aptly-named Frontier Thesis of the 19th century basically said that we were running out of the frontier in America. To Europeans settling the new continent, a few hundred years prior, North America seemed like unpopulated virgin lands. The wilderness! In the first European wave, various ships went up and down the coast plotting resources for later "exploitation" (using the word in the modern sense). It only recently occurred to scholars to admit that the American landscape wasn't wild at all. What juicy coastal lands they had settled had been entirely managed by the Native Americans through "swidden" agriculture. It's just that the new landscape was completely bizarre to the Europeans. To solve the frontier crisis, we (the Americans) went and acquired more lands through imperialism.
Here I end my narrative and name the 800 lb gorilla: capitalism. I am not suggesting that we will make a mistake of ignoring the moon's wildlife, or anything like that - but we shouldn't be arrogant to know what we are dealing with (and I am not even talking about the moon). The driving forces of going to the moon in these two articles is mislabeled as "progress" - but it really is capitalism. Or is it? The problem is - private industry at this point does not have the start-up capital to be able to go to the moon, let alone develop it. Sure, going to the moon is cool and all but why would we, in our current system, allocate so much of government money for the development? Keep in mind that the government's budget in this case is paid by us, the citizens.
So - once again, why bother? Are we running out of the moon-ness on Earth? Is this a socialist plot to have many finance the lunar adventures of the few? If we are so progressive and inclined to embrace socialism on the moon, why not embrace it down here first and prevent our own human beings from starvation and other forms of suffering?
That is an excellent point - and we are losing some cultural evidence to the online age. How in the heck do you archive an ultra-dynamic web page these days? (archive.org has its dear limitations.) To all the stunned people scratching their heads and thinking "how interesting," I must point out that this is an actual discipline in history: historiography.
We can, more often than not, tell more about the writers of a particular time period than the actual topic they are writing about. It's wise to keep that in mind when examining texts or researching information. My two all-time favorite examples are the different "translations" of "Art of War" and Theodore Ayrault Dodge's book on Alexander. You will find some paraphrased gems such as "..but the Spartans never knew anything about strategy.." and "..[the Persians] never contributed anything to the art of war.."
Slashdot Mirror
Some years back, I worked in home automation. During that time, I realized that the key is not retrofitting a home (that's an invitation for trouble or gimmickry) but to build a home with smart features in mind in the first place (ex: vent airflow and temperature sensors, actuators to adjust vents, etc.) Unfortunately, house builders were not really serious about the effort at the time and resorted to gimmickry anyway, when they could (calling a movie theater room with a single light and a touch panel controller 'home automation.')
What landed me the job was my "resume" - which was a side project where I automated a window shade controller and controlled it remotely through a linux machine. I cannibalized a worm gear out of an old VCR, connected it to a rotary window shade thing. Believe I used a segment of duct tape as a rudimentary U-joint. The motor was controlled by the parallel port and an H bridge, and a cron task would open the window shades in the morning and close them in the evening.
That was my first lesson in home automation: longevity. Home automation products, being new, aren't really tested for durability. My prototype certainly wasn't. At some point the contact switches I used for measuring rotation failed, and I came home to my venerable Linux machine twisting the window shades for hours.
Before you condemn American people for being unstable, you may want to step back and examine the relationship between medicare, medicaid, and substance abuse clinics in the states.
Short story is that some substance abuse clinics have started to diagnose abusers with mental disorders in proportions never seen before. Why? Possibly because state and federal funds will unquestionably reimburse for treating users - but the DSM IV diagnoses cost astronomically more than weaning drugs. This trend alone is responsible for pharmaceutical ramp-up, as drug prescriptions went up more than 100-fold in some places.
The Baltimore Sun investigated this trend and wrote up a series of articles. http://articles.baltimoresun.com/2010-11-07/health/bs-md-bbh-housing-day-two-20101107_1_mental-illness-rowhouses-that-bbh-rents-interviews-with-former-patients
I use the 980x for my minecraft server - and - it's made a difference. I'm pretty sure the number of concurrent players can approach 100 without any lag or making the machine sweat. Software problems, on the other hand, are a different issue.
Mobile computing is on the rise, and gaming is a strong component of it. There is a toolkit that will let you program in LUA (fairly common in game engines these days) and it will generate programs for both iPhone / iPad and Android at the same time. Programming is simple and the new game engine employs physics and other gizmos.
See game release: http://blog.anscamobile.com/2010/09/theyre-here-corona-sdk-and-corona-game-edition/
Video: http://www.youtube.com/watch?v=0e4p_5J_bZY
Having access to and mutilating the environment are two completely different things. Treating developers as hostiles by server admins doesn't create the friendliest work environment.
There is a big difference between a bug and the reason why the bug occurred - having access to a production environment is paramount to understanding the underlying issue.
In most newspaper sites the headline / lede / seo field / first graf may is usually programmatically brought in as the META description for SEO purposes (unless specifically overridden). It's a fairly common assumption that this field would be pure text and overlooked in that it doesn't need sanitization. Of course, it's also a fairly common consequence that some silly editor eventually breaks the site by putting HTML code in fields they weren't meant to house. You'd be surprised how many (even big) media sites fail to sanitize these fields.
Onto my point: having HTML (or faulty HTML for that matter) inside a HEAD description field seems like a bug. Sure, you can replicate the error by copying the environment and fix it by stripping anything unexpected out. However - that may not be the root of the problem. Thus, developers end up putting bandaids on a system and treating symptoms rather than curing the problem.
When copying this environment to reproduce the issue, one might simply grab the part that's affected, ignoring the user - CMS preferences which would actually end up telling you what the problem was. What a developer SHOULD do instead is poke around the environment, notice that this was a common occurrence with particular users, talk to the editors in question and shadow them for awhile to understand why this sort of thing keeps repeating.
In many cases, I've seen editors take advantage of programming or security holes to produce far richer and personalized web content than the original design or system permitted. By treating this problem out of the production environment context, the editorial side is completely cut out of the feedback and has no say in the matter and their creative outlet disappears with no dialogue. This in turn breeds hostility and distrust between technology and content.
I can assure you that in reality there is minimal dialog between developers, designers, project managers - and - editors. In my past experience access to the production environment was the only means of lateral communication between abstract technology and persons who use it. In my cases, I've been able to provide editors with features they hesitated to request to circumvent problems while still tightening various holes. This, in turn, improved everyone's day.
Look at it from a philosophical view- you don't want developers to be "writin' them codes" in vacuum of non-editorial space. They need to be a bit more intimately involved with the entire publishing cycle from start to end and not be ticket-solving space cadets when it comes to solving problems.
"This year, AOL is spending $50 million to expand Patch nationally to hundreds of sites by the end of the year."
http://www.boston.com/business/technology/articles/2010/08/05/with_patch_aol_offers_challenge_to_local_news/?page=full
AOL is going hyperlocal - going to give local newspapers a run for their money.
I'm glad first responses are so negative; now I don't have to bother trying ROR out.
Actually, they are. The new PHP contribution is NOT efficiency-related. Instead, they built privacy controls into PHP. However, the problem is that by default it's set to open.
This wouldn't be a question of data entry. In most cases, the data is already there. All you need is a way to connect it. For example, the U.S. Census Bureau has a list of neighborhoods and their polygonal borders.
Now, the CS students in your reference would simply apply a PIP (point-in-polygon) algorithm to see which neighborhood a particular lat, lon coordinate belongs to.
And since that's computationally intensive, the CS "students" would have to know a bit about optimization - including quad trees, and so forth. Bla.
A smooth line from the Seattle thrift store t-shirt roundup:
"Think your iPhone is cool? Let me show you a thing or two about Windows Mobile."
http://valleywag.gawker.com/5144493/the-shirts-off-of-microsofts-back
While vi and a Web Browser is good enough for some, I'd take just the Web Browser. Rapid development needs to break out of the constant theoretical-writing-uploading/saving-previewing cycle and that's why I put together my "eval2" project for PHP.
This video tells it better:
http://www.youtube.com/watch?v=Yfxrt2pc3pg
While the example is ultra-simplistic, I use this every day for altering regex or otherwise previewing REAL data as I protoype code. Anyhow, the typical horse and buggy mentality backlash against this approach has been "well, I can just do php -a".
For the interested, see http://eval2.sourceforge.net/
This is really simple: provide data feeds to the public -- from various government collection sources.
End of story. We don't need the government to spend months, or years even, building websites which dumb data down for us. Give us the raw data feeds and let us create mashups, interactive content and let people make their own judgment based on it. Sure, some sites might need heavy design (such as educational loan repayment sites, etc).
A prime example of this data feed is something like DC's http://data.octo.dc.gov/
And what can people do with that? Well, something like this:
Drunken sailor map
Apparently you can't make heads-or-tails of terminology either. You're thinking strict code execution, while I'm thinking conceptual division. In this case, I thought it was pretty obvious that I was referring to a CMS; I'll be sure to spell things out clearly next time.
And- just for the record, neat trick indeed. JavaScript can be and is executed server-side as well as client-side. The Dojo release build system works like that. See http://www.mozilla.org/rhino/
Being a practical type, I must confess that the learning curve with Dojo has been rather steep; having said that, once you get over the first major hump - it's literally all downhill from there. But, I'm not defending Dojo. Instead, I'm complimenting the book.
This book appears to solve the learning curve problem by starting with a practical tutorial and then going into guts.
IMO, the biggest problem with Dojo's userbase growth has been that Dojo seems to be both large and small at the same exact time, making it difficult to get oriented. One thing that developers should keep in mind is that Dojo is very scalable; performing a custom build will whittle it down from its 37+ MB source distribution (yes, graphics included) to however low you need it (in my case, couple of hundred kilobytes - smaller than some logo images out there).
In my case, I've completely embraced Dojo as a reliable way to quickly produce backend systems with it - and - more recently - front ends.
But that's just work. As for fun - without Dojo, I don't think that I would have put my open source project together or released it to the public. There are so many hours in a day and I don't have time to reinvent the wheel; Dojo was there for me.
For some amusing interaction between Dojo and PHP (not using the Zend framework..), see the videos / screenshots from http://eval2.sourceforge.net/
The Baltimore homicide map: http://essentials.baltimoresun.com/micro_sun/homicides/
My 2c: The best way to answer some tougher programming questions is to prototype specific tasks. Part of this process requires that you have an always-ready environment that allows you to do so. Your own prototyping tools would in this case simply be a ready environment which would permit you to just jump into code without worrying about prerequisites. Something as simple as a prepared template would do, or a tool like this one: http://www.youtube.com/watch?v=Yfxrt2pc3pg
Having been around for some years on this technocratic Earth, and having experience programming in pretty much all the standard (and some exotic) languages, I can say this: no matter which programming language a person might use, that programming language ultimately executes in machine code. Having said that, the most efficient way of writing code is in assembly.
What drives the wedge between pragmatists and idealists is development time. I could probably optimize my projects at work by dumping PHP and writing CGI programs in assembly - but - at what cost? Rather than spend $10k on development time, it's a better utilization of resources to lease a dual Xeon server for an entire year to meet performance requirements of the system. Not efficient on code level, but absolutely makes sense on a business level. Similarly, I could have employed C for previous data acquisition projects but LabView and G code allowed the project to be completed in two weeks instead of two months. During that time difference, numerous graduate students managed to put the system to good work. Time does matter.
Even assembly is not straight forward. You must be aware of all opcodes for your code to be efficient, and that means knowing which hardware you're developing a program for. Who has that amount of time to learn engineering specs of processors? Even C and C++ compilers aren't entirely efficient when it comes to generating programs. For amusement, see this classic piece:
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
This guy spends hours optimizing a program so to reduce its executable size from 3998 bytes to 45 bytes. In this process, it's not just the storage size of the program but also the number of instructions the program goes through. A great achievement in its own right, but, not worth the trouble for larger programs. After all, isn't point of programs to basically do a job? In other words, it's more efficient to write the program once (even if it's inefficient) and leave it be -- rather than rewrite it continuously until it's absurdly efficient.
There is a reason why R.A.D. has been given an acronym and everything. I'm afraid that in this hodge-podge of processors, operating systems, hardware, etc, the wisest course of action is to shoot for completing a task if the outcome is correct. It's ridiculous to expect today's programmers to stick to a single language and learn it intimately: that's just not how things work in the real world.
Now, I'm not endorsing Vista's inefficiencies or anything - just talking about day-to-day programming.
I am sure no one is seeing what I am seeing, but, this advertisement is so unbelievably inappropriate underneath the troll message.
There is absolutely no reason why an infrared remote controller couldn't be bidirectional. Added parts are fairly cheap - an extra photodiode. (I am skipping any other logic, microcontroller programming, and other dependencies). Therefore - you (well, the manufacturing-design engineers) could program a TV's firmware to 'authenticate' a particular remote controller. Assuming this authentication is done at a "safe" moment in time - when no one is looking - a code-hopping solution could be easily devised.
Of course - good luck getting a manufacturer to bother. We will be soon (on a historical scale anyway) approaching the first centennial of the invention and I would be surprised if by that time your DVD player could 'talk' to the TV natively - or any other devices for that matter. Consolidating all of these TV technologies into a cohesive solution hasn't happened yet.
How to recognise a good grave digger
How do you recognise good grave diggers if you're a business guy?
It's not as easy as it sounds. CV experience is only of limited use here, because great grave diggers don't always have the "official" experience to demonstrate that they're great. In fact, a lot of that CV experience can be misleading. Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone's a great grave digger.
I consider myself to be a pretty good grave digger. At the same time, I've spent a fair amount of time on the business side of the fence, filtering technical CVs for projects, interviewing people, etc. Thanks to this, I think I have a bit of experience in recognising good grave diggers, and I want to share it in this article, in the hope that it may help other "business guys" to recognise good grave diggers. And, who knows, perhaps some grave diggers who have the potential to be good but haven't really exploited this can also read this and realise what they need to do to become good (although, as I'll argue, that's definitely not accessible to all grave diggers!).
Ok, that's enough cutting and pasting. Seriously..this article is a bit sickening; it's all about dehumanizing the human being. Mark of a good programmer? Why not apply the phrenology test? Their skulls must have a particular shape in order for them to be "good."
I agree with you that it may be a desperate move; but, lets face it - this is nothing out of the ordinary. This sort of thing has been done time and time again. In order to protect its own market from cheap foreign knockoff souvenirs, they are enacting these regulations. USA does it on a daily basis.
Though, here is an amusing precedent for you. Look at the original Christian gospels; in Acts of the Apostles, Paul visits Ephesus so to try to convert the local heathens. The locals, who worship the (to us classical) Greek pantheon of gods and goddesses, don't reject Jesus and monotheism. They are just upset that by replacing their gods with a single God (and Jesus), the local silversmiths would lose out on their souvenir trade: selling statues of Diana. So religion and (nationalism) take back seat to economy.
Sources for the interested:
* http://www.sparknotes.com/lit/newtestament/section5.rhtml (look for 'trade')
* http://www.gospelhall.org/bible/bible.php?passage=acts+19&search=&ver1=kjv (may need to look around for this Ephesus-trade section - I am a little rusty on the original)
Not to criticize your humor (which is funny), but, from a historian's point of view:
This cliché statement (..doomed to repeat..) relies on the supposition that progression of events is linear in history. In other words, it's the idea that there is a sequence of events that seemingly always leads to the nearly-same end result. Part of this statement also assumes that progression of events may be cyclical -- but -- it's arrogant to assume that this cliché applies to every situation. Often it does not.
In other words, why do we assume that the cost of digital storage is always going to remain that high respective to economy? We are looking at the horizon of solid state hard drives that are actually affordable by the general public. Ten years ago this SSD concept seemed inconceivable - neither profitable for industry nor affordable by the consumers. Technologies will change and somewhere (or somewhen) out there - there may be a niche for a company to make digital preservation profitable.
So the person (namely, article author) who yells [Why are we jumping on this technological bandwagon without thinking of the consequences???] is a classic case of a declensionist attitude (things are getting worse..). Standing opposite to that attitude is the progressive one (things are getting better) - but - I don't subscribe to it either. I think there is a healthy sinusoidal bounce between good and bad aspects of digital film storage and it's completely up to time to reveal the outcome.
I agree with some of the previous posters that have faulted programmers for "the state of today." My feeling is that the divide between knowledge of hardware and knowledge of software is far too wide. In my experience, I have witnessed many programmers who spent more time organizing the readability of their code than analyzing the actual effectiveness of it: i.e. whitespace use vs algorithm optimization (be it processor method + instruction or i/o improvement). The end result: bloaty-pooh.
I feel that by making threading a C++ standard, or at least making the threading model a predominant one, the overall "state of today" will improve in the near future simply because more programmers will be aware of it. Parallel processing really does require some training -- it cannot be adapted to every task.
Take for example a simple thumbnail-generating program (a form of is used by everyday users). If the program is written in its traditional linear model, it would not take advantage of multiple processors or cores (unless you ran multiple instances of it or otherwise manipulated it in an unplanned fashion). However, if the program utilizes threading, it could become scalable without requiring any intervention. Knowledge of hardware -- and not necessarily relying on the compiler to optimize your code just might help.
The aptly-named Frontier Thesis of the 19th century basically said that we were running out of the frontier in America. To Europeans settling the new continent, a few hundred years prior, North America seemed like unpopulated virgin lands. The wilderness! In the first European wave, various ships went up and down the coast plotting resources for later "exploitation" (using the word in the modern sense). It only recently occurred to scholars to admit that the American landscape wasn't wild at all. What juicy coastal lands they had settled had been entirely managed by the Native Americans through "swidden" agriculture. It's just that the new landscape was completely bizarre to the Europeans. To solve the frontier crisis, we (the Americans) went and acquired more lands through imperialism.
Here I end my narrative and name the 800 lb gorilla: capitalism. I am not suggesting that we will make a mistake of ignoring the moon's wildlife, or anything like that - but we shouldn't be arrogant to know what we are dealing with (and I am not even talking about the moon). The driving forces of going to the moon in these two articles is mislabeled as "progress" - but it really is capitalism. Or is it? The problem is - private industry at this point does not have the start-up capital to be able to go to the moon, let alone develop it. Sure, going to the moon is cool and all but why would we, in our current system, allocate so much of government money for the development? Keep in mind that the government's budget in this case is paid by us, the citizens.
So - once again, why bother? Are we running out of the moon-ness on Earth? Is this a socialist plot to have many finance the lunar adventures of the few? If we are so progressive and inclined to embrace socialism on the moon, why not embrace it down here first and prevent our own human beings from starvation and other forms of suffering?
That is an excellent point - and we are losing some cultural evidence to the online age. How in the heck do you archive an ultra-dynamic web page these days? (archive.org has its dear limitations.) To all the stunned people scratching their heads and thinking "how interesting," I must point out that this is an actual discipline in history: historiography.
We can, more often than not, tell more about the writers of a particular time period than the actual topic they are writing about. It's wise to keep that in mind when examining texts or researching information. My two all-time favorite examples are the different "translations" of "Art of War" and Theodore Ayrault Dodge's book on Alexander. You will find some paraphrased gems such as "..but the Spartans never knew anything about strategy.." and "..[the Persians] never contributed anything to the art of war.."