The fundamental problem with all wearable computing and cell phones is that they are an interruptive technology. While they do queue up SMS messages and emails so you can deal with them when convenient, people don't do so. Instead they rudely proceed to stop whatever they're doing, even a conversation, to deal with the message right now.
I disagree with the basic premise of the article that film can be racist. It might not provide pure image quality as it should, but that's a fault of physics and design compromises, not some hidden racist agenda.
The same film that has trouble capturing the details of a black person's face has trouble capturing the details of a black car. A competent photographer knows what kind of film to use for their subjects.
It doesn't make the film itself racist, nor does it make the film's design engineer's racist.
Film is not "biased" towards people with "light skin." Quite frankly, I don't see how any visual medium that's designed to capture an accurate colour spectrum could be racially biased.
I think this whole article is a trollish attempt to inject a "racial issue" where there is none.
Agreed. I'm 6'2" myself, and it's been a long time since I had a seat with enough room. Some airlines even charge *extra* for the bulkhead seats now, which were the only ones that ever had enough leg room for me.
When you're 6'2" you don't buy a car without test driving it to see if there is enough head and leg room.
When the UI for different android devices varies as much as it does, you don't buy a model without trying it out to see if the vendor's choices make sense for you.
Add ons, apps, plugins, and so on are like after-market car accessories. Sure you can install them to change the defaults, but you're not required to, and I'd bet that most people don't.
Out of all the politicians around the world, I've not heard of one making any apologies for the surveillance or the abuse of law and process. Instead, they're all focused on the "leak" and what could have been done about it to prevent it. They're focused on charging the people involved to hopefully stop others from leaking in the future, when they should be red-faced with shame and embarassment over getting caught.
The TV still works, the computer still works, McDonald's still serves swill, and the boss is still harping for more work to be done.
As long as day-to-day life isn't affected, the average consumer cares far more about Miley Cyrus twerking than they do about oppressive surveillance.
Hell, how long has the TSA been invasively harassing people for the sake of security, and they put up with that, so why not put up with something that has no obvious impact on life?
It's Apple's new "iBoot" feature, which automatically restarts the phone when it detects an NSA probe, acting as if you noticed the spies and shut off your phone as a result. The more frequent your reboots, the more interested the goobernmint is in you.:P
So bring back philosophy classes. There was a time when philosophy was a core part of education, when students were taught to think, not merely regurgitate.
Aside from that, I think you're over-emphasizing the complexity of basic boolean logic that is required by the average programmer. At the level we're talking about, basic parenthesized AND and OR constructs are more than adequate; there is no need to introduce elementary school kids to concepts like NOR or XOR.
The languages used need to change pretty dramatically, too. Pascal-style compilers that produce some kind of code after error correction insertions would be far more helpful for kids to learn than barf-on-missing-semicolon compilers like Java. An awful lot of "errors" in code are caused by syntactic sugar, not actual errors in the logic being described.
Letting such code run with any resulting errors could be as educational for the kids as seeing the results of properly structured code run.
That's if the concept of a text language needs to be maintained at all. I've worked with a 4GL that used pictures and flow chart diagrams to "code". It was doable, but a pain in the butt for someone like me who prefers to type instead of mouse. But for kids used to tablets and phones, it might actually be an easier and quicker coding environment than a traditional keyboard. Using that language gave me a kickstart on thinking about how to do such an interface better. I don't think I want to tackle the job, but over the past couple or three years I've come to realize that text based programming is an arcane art that might well someday be dead except for a few historians still slugging away at COBOL.
By that I mean that directed energy weapons are highly unlikely to use photons as the means of deploying their energy bursts. Magnetic bubbles of plasma or streams of electrons or even subatomic particles would be far more likely to be used.
i.e. With SQL Server and Sybase you have to do something like:
UPDATE mytable SET deltaid = last-known-value-of-delta-id + 1;
SELECT * FROM mytable; // do analysis and calculations
UPDATE mytable SET deltaid = last-known-value-of-delta-id// To undo the lock without changes, or
UPDATE mytable SET foo = updated-value; // Repeat for any other records you need to update
COMMIT;
This is an absolute HACK of a way to code around the lack of SELECT...FOR UPDATE which lets you far more concisely do:
SELECT * FROM mytable FOR UPDATE; // Do calculations
UPDATE mytable SET blah = foo;// Only if necessary, there is nothing to undo // Repeat for any other records that need updating
COMMIT;
There's a reason every database I've ever encountered other than SQL Server and Sybase ASE implement "FOR UPDATE". It's part of the standard for SQL, and it was created because it's useful and necessary to implement consistent code in anything vaguely resembling a concise fashion.
Repeatable read is not the same as SELECT...FOR UPDATE.
Select for update lets you pin the data, analyze it, and then update it consistently with the values you read. While delta id's can let you detect update collisions with SQL Server and Sybase ASE, you have to write very platform specific code that updates the record, does it's analysis, and if no update is actually required, either rolls back the transaction or updates the delta id back to it's initial value.
What really sucks is that both SQL Server and Sybase ASE document the "FOR UPDATE" clause -- they just barf at runtime if you try to use it.
After all, the NSA has done such a stellar job of following the laws enacted to date.
Wake up: The only way to stop the NSA is to de-fund them. And even then, there are probably "slush funds" from the FBI, CIA, and DEA that they could tap into.
I remember a "dinosaur" telling me about an S/390 "virus" in my youth. It was written to infect the disk, drum, and tape controllers, and to replicate itself to any uninfected devices in the system.
It was relatively harmless. It would periodically pop up a console message like "I want a cookie.", and lock up the system until the operator typed in "cookie".
However, apparently the only way to purge the thing was to replace all the hardware controllers at the same time.
Whether true or not, I do not know. But it's the oldest "virus" story I've ever heard -- it was told to me way back in the 80s.
While it's true that there is a large market for CRM systems that do not require ERP, there is a significant market of ERP users that require CRM support from their ERP.
However, I do agree that the odds of finding a single solution that is good at both is unlikely. The author would be better off looking for seperate systems that support easy customization and extension so they can be tied together. While this will require some work, the odds of success are much greater.
One thing I would recommend: make sure the systems use a real database like PostgreSQL, DB/2 UDB, or Oracle. Those four support "SELECT...FOR UPDATE" syntax properly, which makes it possible to implement embracing locks between two seperate databases for a dual-system solution. MySQL with appropriate extensions and table configuration will work as well, but the odds are that either or both of the systems selected won't be coded to use those extensions, making it a very risky proposition. Sybase ASE and Microsoft SQL server do not support "SELECT...FOR UPDATE" syntax properly, so you can't implement embracing locks with those databases, despite their performance and popularity -- they cut corners and require a completely different (and more difficult) style of coding to achieve the same effect.
Ideally you want databases in the back end that can support two-phase XA commits rather than coding embracing locks, but that limits your database options even further, and comes with it's own set of technical challenges.
Of course if you can get away with generating a "report" from one system that is "imported" by the other, batch-style rather than having deep integration between the two, your job will be much easier. Don't let the wish lists of your users obstruct the focus on meeting the core needs of the business. Just because someone wants to hit a function key and be taken to the appropriate screen in the CRM system from the ERP doesn't mean that they have to have that functionality to do their job.
Remember, the most important thing to do is to get management buy-in on the risk and expense of the data and functionality migration. If you don't have buy-in from management and the ability to say no to unrealistic or unnecessary user demands, you're dead before you started.
For example, the Saskatchewan Health Information Protection Act means that the RCMP can not access the list of medical cannabis users maintained by Health Canada. Health Canada themselves are restricted by provincial regulations like HIPA, because they don't have jurisdiction.
As a result, the only thing the RCMP can do during an investigation is ask Health Canada if a particular address they are investigation had a medical license, and if so, what the plant count limit is. They can't find out anything about the prescribing doctor, the reason you have authorization, or anything else related to the case at hand. Only that you have been granted permission to grow n plants.
Slashdot Mirror
The fundamental problem with all wearable computing and cell phones is that they are an interruptive technology. While they do queue up SMS messages and emails so you can deal with them when convenient, people don't do so. Instead they rudely proceed to stop whatever they're doing, even a conversation, to deal with the message right now.
There is no excuse for it other than being rude.
I disagree with the basic premise of the article that film can be racist. It might not provide pure image quality as it should, but that's a fault of physics and design compromises, not some hidden racist agenda.
The same film that has trouble capturing the details of a black person's face has trouble capturing the details of a black car. A competent photographer knows what kind of film to use for their subjects.
It doesn't make the film itself racist, nor does it make the film's design engineer's racist.
So we're busy creating successors for ourselves after we're done killing off our species and most others through global warming.
After all, it's not like we'll to worry about being around to compete with these new life forms.
We've already pretty much doomed ourselves, and we're not doing anything to even slow down the heat-death, much less correct the problem.
Film is not "biased" towards people with "light skin." Quite frankly, I don't see how any visual medium that's designed to capture an accurate colour spectrum could be racially biased.
I think this whole article is a trollish attempt to inject a "racial issue" where there is none.
Agreed. I'm 6'2" myself, and it's been a long time since I had a seat with enough room. Some airlines even charge *extra* for the bulkhead seats now, which were the only ones that ever had enough leg room for me.
When you're 6'2" you don't buy a car without test driving it to see if there is enough head and leg room.
When the UI for different android devices varies as much as it does, you don't buy a model without trying it out to see if the vendor's choices make sense for you.
Add ons, apps, plugins, and so on are like after-market car accessories. Sure you can install them to change the defaults, but you're not required to, and I'd bet that most people don't.
Out of all the politicians around the world, I've not heard of one making any apologies for the surveillance or the abuse of law and process. Instead, they're all focused on the "leak" and what could have been done about it to prevent it. They're focused on charging the people involved to hopefully stop others from leaking in the future, when they should be red-faced with shame and embarassment over getting caught.
The TV still works, the computer still works, McDonald's still serves swill, and the boss is still harping for more work to be done.
As long as day-to-day life isn't affected, the average consumer cares far more about Miley Cyrus twerking than they do about oppressive surveillance.
Hell, how long has the TSA been invasively harassing people for the sake of security, and they put up with that, so why not put up with something that has no obvious impact on life?
It's about time the multinational thieves got lynched and paid their fair share.
It's Apple's new "iBoot" feature, which automatically restarts the phone when it detects an NSA probe, acting as if you noticed the spies and shut off your phone as a result. The more frequent your reboots, the more interested the goobernmint is in you. :P
So bring back philosophy classes. There was a time when philosophy was a core part of education, when students were taught to think, not merely regurgitate.
Aside from that, I think you're over-emphasizing the complexity of basic boolean logic that is required by the average programmer. At the level we're talking about, basic parenthesized AND and OR constructs are more than adequate; there is no need to introduce elementary school kids to concepts like NOR or XOR.
The languages used need to change pretty dramatically, too. Pascal-style compilers that produce some kind of code after error correction insertions would be far more helpful for kids to learn than barf-on-missing-semicolon compilers like Java. An awful lot of "errors" in code are caused by syntactic sugar, not actual errors in the logic being described.
Letting such code run with any resulting errors could be as educational for the kids as seeing the results of properly structured code run.
That's if the concept of a text language needs to be maintained at all. I've worked with a 4GL that used pictures and flow chart diagrams to "code". It was doable, but a pain in the butt for someone like me who prefers to type instead of mouse. But for kids used to tablets and phones, it might actually be an easier and quicker coding environment than a traditional keyboard. Using that language gave me a kickstart on thinking about how to do such an interface better. I don't think I want to tackle the job, but over the past couple or three years I've come to realize that text based programming is an arcane art that might well someday be dead except for a few historians still slugging away at COBOL.
No, I didn't read the article or watch any videos.
But bringing the hands together sounds like a position of prayer to me. :D
It sounds to me like bringing up the desktop requires a variation on a praying gesture. :)
A variant on it at least.
By that I mean that directed energy weapons are highly unlikely to use photons as the means of deploying their energy bursts. Magnetic bubbles of plasma or streams of electrons or even subatomic particles would be far more likely to be used.
Lasers, on the other hand, shoot photons.
Phasers are not lasers.
i.e. With SQL Server and Sybase you have to do something like:
UPDATE mytable SET deltaid = last-known-value-of-delta-id + 1;
// do analysis and calculations // To undo the lock without changes, or
// Repeat for any other records you need to update
SELECT * FROM mytable;
UPDATE mytable SET deltaid = last-known-value-of-delta-id
UPDATE mytable SET foo = updated-value;
COMMIT;
This is an absolute HACK of a way to code around the lack of SELECT...FOR UPDATE which lets you far more concisely do:
SELECT * FROM mytable FOR UPDATE;
// Do calculations // Only if necessary, there is nothing to undo
// Repeat for any other records that need updating
UPDATE mytable SET blah = foo;
COMMIT;
There's a reason every database I've ever encountered other than SQL Server and Sybase ASE implement "FOR UPDATE". It's part of the standard for SQL, and it was created because it's useful and necessary to implement consistent code in anything vaguely resembling a concise fashion.
Repeatable read is not the same as SELECT...FOR UPDATE.
Select for update lets you pin the data, analyze it, and then update it consistently with the values you read. While delta id's can let you detect update collisions with SQL Server and Sybase ASE, you have to write very platform specific code that updates the record, does it's analysis, and if no update is actually required, either rolls back the transaction or updates the delta id back to it's initial value.
What really sucks is that both SQL Server and Sybase ASE document the "FOR UPDATE" clause -- they just barf at runtime if you try to use it.
I'll have to look into that. I've never heard of an UPDLOCK clause.
Figures Microsquishy would have some incompatabible syntax for doing the same thing as the standards. :(
Yeah, that'll work.
After all, the NSA has done such a stellar job of following the laws enacted to date.
Wake up: The only way to stop the NSA is to de-fund them. And even then, there are probably "slush funds" from the FBI, CIA, and DEA that they could tap into.
I remember a "dinosaur" telling me about an S/390 "virus" in my youth. It was written to infect the disk, drum, and tape controllers, and to replicate itself to any uninfected devices in the system.
It was relatively harmless. It would periodically pop up a console message like "I want a cookie.", and lock up the system until the operator typed in "cookie".
However, apparently the only way to purge the thing was to replace all the hardware controllers at the same time.
Whether true or not, I do not know. But it's the oldest "virus" story I've ever heard -- it was told to me way back in the 80s.
It's worth noting that Microsoft was the originator of MS-DOS, not IBM. IBM bought DOS from Microsoft to deploy on their machines.
The predecessor, CP/M, did not implement CTRL-ALT-DEL functionality.
So even though it predates Windows, Microsoft did initiate it.
Typo: "those three" databases, not those four.
The selection of a database is key to success when dealing with systems integration. Don't let the rah-rah fanbois and sales reps tell you otherwise.
While it's true that there is a large market for CRM systems that do not require ERP, there is a significant market of ERP users that require CRM support from their ERP.
However, I do agree that the odds of finding a single solution that is good at both is unlikely. The author would be better off looking for seperate systems that support easy customization and extension so they can be tied together. While this will require some work, the odds of success are much greater.
One thing I would recommend: make sure the systems use a real database like PostgreSQL, DB/2 UDB, or Oracle. Those four support "SELECT...FOR UPDATE" syntax properly, which makes it possible to implement embracing locks between two seperate databases for a dual-system solution. MySQL with appropriate extensions and table configuration will work as well, but the odds are that either or both of the systems selected won't be coded to use those extensions, making it a very risky proposition. Sybase ASE and Microsoft SQL server do not support "SELECT...FOR UPDATE" syntax properly, so you can't implement embracing locks with those databases, despite their performance and popularity -- they cut corners and require a completely different (and more difficult) style of coding to achieve the same effect.
Ideally you want databases in the back end that can support two-phase XA commits rather than coding embracing locks, but that limits your database options even further, and comes with it's own set of technical challenges.
Of course if you can get away with generating a "report" from one system that is "imported" by the other, batch-style rather than having deep integration between the two, your job will be much easier. Don't let the wish lists of your users obstruct the focus on meeting the core needs of the business. Just because someone wants to hit a function key and be taken to the appropriate screen in the CRM system from the ERP doesn't mean that they have to have that functionality to do their job.
Remember, the most important thing to do is to get management buy-in on the risk and expense of the data and functionality migration. If you don't have buy-in from management and the ability to say no to unrealistic or unnecessary user demands, you're dead before you started.
That's not the case in Canada.
For example, the Saskatchewan Health Information Protection Act means that the RCMP can not access the list of medical cannabis users maintained by Health Canada. Health Canada themselves are restricted by provincial regulations like HIPA, because they don't have jurisdiction.
As a result, the only thing the RCMP can do during an investigation is ask Health Canada if a particular address they are investigation had a medical license, and if so, what the plant count limit is. They can't find out anything about the prescribing doctor, the reason you have authorization, or anything else related to the case at hand. Only that you have been granted permission to grow n plants.