Feed aggregator

APEX 4.0 Known Issues

David Peake - Fri, 2010-07-16 12:06
Since releasing APEX 4.0 we have identified a number of issues.
Many are directly related to upgrading applications from previous releases.
The known issues are outlined on OTN here: http://www.oracle.com/technology/products/database/application_express/html/4.0_known_issues.html
As with any upgrade we strongly recommend you test your applications in a development environment before applying to production.

Our development team is working very hard on these issues.
Many issues have workarounds provided.
Where appropriate we are also releasing patch set exceptions which can be downloaded from Oracle Support and installed in your environment.

We intend to roll all of these fixes into an APEX 4.0.1 release.
Before you ask - I can't provide dates for APEX 4.0.1 release!

Regards,
David

APEX4 Password Strength Meter Item Plugin

Oracle Apex Notebook - Fri, 2010-07-16 10:26
I was doing some tests with the new plugin functionality coming with APEX4 and the result is this plugin I'm sharing with you today.I based the plugin on the "Ajax Password Strength Meter Script" that you can find following this link: http://simplythebest.net/scripts/ajax/ajax_password_strength.htmlIt's a small plugin using jQuery that provides an easy interactive way to show the strength of a
Categories: Development

Physician, Heal Thyself

Mary Ann Davidson - Thu, 2010-07-15 04:04

"The fault, dear Brutus, is not in our stars, But in ourselves, that we are underlings." Julius Caesar (1,ii140-141)

There is in some cases a terrible - and in some cases terrifying - disconnect between technology and our larger societal ability to understand it, in particular, to understand the risks it poses and the unintended consequences of those risks. The limitations of technology are not necessarily what we think they are, either. That is, we wouldn't solve all our technology problems if only we had - more technology. No, many of the limitations are ones we create ourselves, because of our inability to understand systemic risks, and by the way we think about and talk about technology as if it were something "new" and "different," instead of recognizing patterns that have repeated themselves in other disciplines.

One of the perspective slaps to the side of the head you get when you leave the nerdified air of Silicon Valley is that large swathes of the world are not technophiles, let alone technoacolytes. By that I mean that, regardless of the benefits of technology, once you drive past Los Gatos on highway 17, most of the people you meet don't think we'd achieve world peace if only we had a standards compliant API for it. Nor for that matter does most of the world think that the Eleventh Commandment is "thou shalt honor the Lord they God, by making thy code open source." As long as I have worked in technology, I continue to find the number of technological cults and cult members to be truly astonishing. If I were a social scientist, I might observe that, having extirpated God from so much of public life, we rush to find other ways to fill the void. The last time I checked, Deuteronomy said, "I am the Lord thy God, who led you out of Israel, out of slavery. You will have no other gods before me." Technology, it should be said, is not god. More like a golden calf.

If that sounds silly, think about the number of discussions we have all had with technocult members who speak in raptured, hushed tones about (insert all that apply): cloud computing, open source, object-oriented programming, agile development, and so on. (And my personal favorite, referring to any technology as "awesome." God and the North Shore of O´ahu in winter are awesome,* everything else is merely amazing, at best.) Note: I am not denigrating any of these technological constructs, merely observing that none of them have created world peace, cured cancer, raised the dead or helped anybody lose that last pesky 10 pounds. It's just technology. Even in my happiest moments curled up with my iPhone -- which is really nice technology and has made me more efficient -- I don't expect the iPhone GPS system to help me find real direction in life.

The first limitation of technology is one we impose ourselves: we make it a god, when it isn't, and IT people the high priests, when they aren't. The reason anybody cares is because technology has substantially altered our world and, if we admit it, not always for the better. Unfortunately, when technologists make an idol out of technology, we get all the overhead that comes with creating a new religion.

  • Non-believers may be ostracized or pressured to convert.
  • Statements of opinion - or ecstatic utterances - are treated as religious tenets and therefore, not open for discussion.
  • Instead of honest disagreements, we have (literal) religious arguments.
  • We may (figuratively) burn heretics at the stake.
The result is that in many cases technology is pushed merely because it is the next path to salvation, and without any rational discussion of whether we need it and, most importantly what risks it subjects us to - and whether they can even be understood let alone mitigated. Technologists become like the snake, telling Adam and Eve they will be as God is if they take a bite, and, like Adam and Eve, we only later realize the technological apple has rendered us naked.

I should have realized this when I first moved to Silicon Valley many moons ago. I went to a party given by a friend who happened to work for a chip company that was a competitor to the company I worked for. She introduced me to a colleague who, instead of the usual "Hi, how are you, nice to meet you," glared at me and said, "we're going to kill you in MOS technology." ("Not tonight, unless you are serving hemlock," was my response.) The "technology as god" cult has been reinforced a number of times over the interim years, most recently by an entrepreneur I recently talked to who had a hard time understanding that inventing a cool new technology was not, per se, enough to get him in my door or anybody else's. While I admire his entrepreneurial gifts, unless he is solving a problem people care about and can explain, in less than 25 words, he is not going to get past the "I only want twenty minutes of your time" barrier. It's just technology. It's not (a) god. It's not even a worthy golden calf wanna be.

Another limitation of technology is linguistic. I don't mean the difference between French and German: more like the difference between English and Martian. Many technologists might as well be speaking Martian, they are so far removed from the people who need to understand what the technology can do, what it can't do, and why anybody would want to use it. End users. Customers. Legislators. Those who are legitimate stakeholders in determining whether the risks of technology usage outweigh the benefits, but who cannot do that unless technologists can make themselves understood. By way of example, I might just possibly be understood in La Jolla if I were to say to someone in the surf lineup at Windansea, **"´Auwe, aia he mano nui loa! E ku´u hoa, e hele mai!" However, I'd be far more likely to get a response if I said "Alas! There is a really big shark. Get over here, buddy!" At any rate, if I cannot deliver a warning in English, I should not then excoriate a friend (on his way to the emergency room thanks to the man in the gray suit ***) that he really needs to learn Hawaiian to avoid future shark bites.

One of the main reasons technologists cannot or will not make themselves understood is the overuse of jargon. I've never met a group of people who were more jargon happy than technologists, unless it is teenagers -- who at least grow out of it if for no other reason than that they are forced to. (I don't care a hoot about "intergenerational communication styles," if a candidate for an open headcount insists on using "BFF" and "OMG" in an interview, he/she will experience "GFG"****.) If we are honest, we admit that we use jargon not only for the sake of efficiency but to make us feel smarter and superior than those who are not in the techno-know. Jargon becomes a means to exclude people from the club, and a means to hornswoggle others if we are fortunate enough to have an audience of either true believers or one that is too embarrassed to admit what they do not know. For our part, we reason, if they are too stupid to know what OCSP and HAML***** stand for, then they are not worth the time for us to offer our explanations. Jargon is also a means to cut yourself out of the herd. Everyone wants to be the first to either invent a new buzzword or be the first to use it. I'd only just learned what the acronym APT stands for -- Advanced Persistent Threat -- and already, I have had slimy sales reps emailing me asking about what Oracle does to combat APT and do I know that they have a product that can protect against it, not to mention slice, dice and make julienne fries? (What I'd really like is a product that protects against APSRs - Annoyingly Persistent Sales Reps. Nobody has offered to sell me one yet.)

I'm not immune to the temptation. I was once in a meeting with a bunch of developers talking about security issues. After listening to the discussion, I said with great solemnity, "as I see it, we need an ITP story. In fact, we need an S-ITP story. " Everyone nodded. Finally, someone had the courage to say, "what is S-ITP?" to which I replied, "the Secure Internet Toaster Protocol." ****** We get wrapped up in our own linguistic cleverness to the point we do not always know what we are saying. How then, can we expect our constituents to understand what technology is capable of, and what it is not capable of? True, there are many other organizations or cohorts that are almost as jargon happy as we are, but few of them are tasked with the level of responsibility we have. It's not just the Marine Corps and the Three Letter Agencies that do national security: technoids do. At least when I was in the Navy, you could always look up FAADCPAC******* or other cryptic acronyms in the DICNAVAB (Dictionary of Naval Abbreviations). Good luck with that in our industry (this is where the cloud cult members insist that all I have to do is look up my acronym in the acronym cloud). The point is: I shouldn't have to.

Even God - the real one - communicated in a language his followers could understand (and wrote the rules down on tablets). Technologists won't even do that. The other thing God (or His scribes) did was tell stories. It's easier for most people to get their minds around a creation story that begins "in the beginning, the world was formless and void..." than around the Big Bang and/or quantum physics. Phrases like "Can the Ethiopian change his skin or the leopard its spots?" speaks to the fact that some things are immutable. We get it so well that the number of people who use the phrase vastly exceed the number who know where it comes from. (Jeremiah 13:23). Analogies, stories, and using examples people understand all help make the complex more simple: God is more understandable than the average technologist. No wonder most people know that they shouldn't lie, cheat, steal but we have lots of the Clueless Faithful who think it's a good idea to allow houses to talk to power plants. (What next, wireless access to life support systems? Because it is just so expensive to send a nurse into someone's room.)

On the occasions when I have had the privilege of testifying in front of Congress, I've had 5 minutes to try to help well-intended legislators do something that will make a positive difference. How far do you think I'd get if I said, "we need to deploy IpV6 broadly to fix all our cybersecurity problems" or "insecure RNGs are the bane of network encryption?" I might actually get farther if I said, "'Auwe, eia he mano nui loa! E ku'u hoa, e hele mai!" (At least, Senators Inouye and Akaka - and the rest of the state of Hawai´i delegation - might understand.) I readily admit that I am not a technologist - I don't have the in-depth knowledge that most of my team has. What I do have is the ability to ask questions until I understand the gist of - and details of - a problem, and the ability to translate the problem into terms others can understand. Without that communication, you get people suffering from avoidable shark bites because they don't speak Hawaiian. Why is it so hard for technologists to understand that if they cannot communicate, their technological acumen is worthless, even dangerous?

Maybe the reason technologists resist the use of analogies is that it would reveal that the emperor has no clothes or, more accurately, that the emperor's clothes are the same ones everyone else is wearing. By that I mean, that if we can use analogies to explain technology and technological limits, it makes it all too obvious that we already have examples we can use to, for example, craft public policy. We might be forced to admit that technology isn't the ooh, aah, gee whiz stuff we say it is, it's just the same old problems wrapped up in shiny new bits.

For example, there are a number - no, a lot - of cybersecurity bills in draft currently. A core element of many of these bills is the degree to which the Federal government should exert "control" over private networks and what form that control should take. In my opinion, there are many reasons for thinking that the Federal government is not well suited to such a role. One of the main reasons goes to basic accountability 101. The best example I could come up with was physical security. The CEO of a company that has no door locks, no physical security of any kind, and whose company experiences massive thefts from people wandering around their buildings would not have a job for very long. The police might help investigate the break in but they would also be the first to recommend locks and a security system. They certainly would not take over building defense.

"Oh, but cyber is different." Why, precisely? Assets are increasingly stored electronically, corporate "boundaries" include electronic ones (or should). If we think there is nothing valuable to protect on corporate networks then let's skip authentication and dispense with firewalls. Clearly, we know that data is valuable and corporations do have a responsibility to protect their own resources - they owe that to shareholders. If cyber is so "complicated" that we can't possibly secure it, one has to ask why these entities knowingly continue to double down on risk they cannot mitigate. The buck stops somewhere and it is not (primarily) at the Department of Homeland Security. Business cannot realistically have it both ways - embrace the increasing use of technology ("do more with less!") and then declaim responsibility for having done so. And just as the local police department does not have keys to local businesses -- nor do they install and monitor close circuit TV in each business to detect and prevent crime -- we ought to have sensible boundaries about who secures what.

Jargon makes people feel smart and superior, but end users and key stakeholders - including, increasingly, legislators - do not speak that jargon. If we cannot learn to de-jargon ourselves and speak in languages that our audience can understand and process, technology will continue to ensnare us instead of setting us free. I'll close with an illustration that bring together several of the themes I have been talking about: responsibility, limits, and all wrapped up in a nice, de-jargoned turn of phrase:"The LORD God took the man and put him in the Garden of Eden to work it and take care of it. And the LORD God commanded the man, "You are free to eat from any tree in the garden; but you must not eat from the tree of the knowledge of good and evil, for when you eat of it you will surely die." (Genesis 2:15-17)I wish technologists were as forthright.

* Ok, I admit, I just violated the first commandment by making surfing a god. But the North Shore when it breaks is pretty awe-inspiring, at the least.

** Not that I've ever seen a shark there. But I did see a dorsal fin pop up next to me one Saturday. It was the longest three seconds of my life until I heard the exhale of - a dolphin.

*** "Man in the gray suit" is a surfing euphemism for "shark"

**** Gone for good

***** Caught you! OCSP is the Online Certificate Status Protocol, but HAML is something I made up (Hack Attack Markup Language, by which we all craft standards-compliant security vulnerabilities so it is easier for hackers to exploit them on multiple web applications, in a standards-compliant way).

****** As far as I can tell, there is no reason to put household appliances on a network and many reasons not to. Anyway, I don't really think you need special authorization to toast bagels vs. white bread.

******* Fleet Accounting and Disbursing Center, US Pacific Fleet, if you care.

Books

Matterhorn: A Novel of the Vietnam War by Karl Marlantes

http://www.amazon.com/gp/product/080211928X/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0979528534&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1VJP13PEV1Q4RBD3F060

It's not often I get a chance to read a book that I think will become a classic, but this is one of them. The author is a decorated Vietnam-war veteran and the "authenticity" shows. The premise is that a green 2LT is sent into the bush with his team to take and hold a territory known as "the Matterhorn." It's impossible for me to describe how gripping this book is, how real the characters are, and how invested you become in them. I would never - I hope - have the hubris to say that I understand what it was like to have been in Vietnam, but after reading this book, I feel I have been a spectator. A great, magnificent book. A Dog for All Seasons: A Memoir by Patti Sherlock

http://www.amazon.com/Dog-All-Seasons-Memoir/dp/0312577923/ref=sr_1_1?ie=UTF8&s=books&qid=1273709745&sr=1-1

Personally, I am not so hot on border collies since one of them tried herding Thunder on the Nordic trail (Thunder did not want to be herded) and I had an expensive vet bill from the border collie biting him. One reason I think leash laws are critical. But I digress.

We forget that so many dogs (mine included) are working dogs. Working dogs need something to do besides sit in a dog basket and snarf dog treats. Working dogs are also indispensable to many people (you can't really herd sheep without them). The author wrote this book about a remarkable border collie named Duncan who lived with her on a sheep ranch in eastern Idaho. A dog that was more than merely a dog. Well worth the read.

Sailing in the Wake of the Ancestors: Reviving Polynesian Voyaging by Ben Finney

http://www.amazon.com/Sailing-Wake-Ancestors-Polynesian-Excellence/dp/1581780249

The resurrection of Hebrew as a popular (i.e., not merely scholarly) language is one of the great comeback stories in history. The other is the resurrection of Polynesian voyaging. This book tells the how and the why of how a dead or dying art was recreated, and the shot in the arm it gave to Polynesian peoples, who must now - largely as a result of the work of the Polynesian Voyaging Society - be acknowledged as the greatest navigators of all time. The author does not spare the infighting that almost led to the destruction of the Polynesian Voyaging Society and the means by which it was resurrected. The happy ending is the number of Polynesian peoples who are participating in wayfinding, just as their ancestors did. (It's still amazing to me that anybody can travel thousands of miles by the stars, observing ocean currents and birds.)

Physician, Heal Thyself

Mary Ann Davidson - Thu, 2010-07-15 04:04

"The fault, dear Brutus, is not in our stars, But in ourselves, that we are underlings." Julius Caesar (1,ii140-141)

There is in some cases a terrible - and in some cases terrifying - disconnect between technology and our larger societal ability to understand it, in particular, to understand the risks it poses and the unintended consequences of those risks. The limitations of technology are not necessarily what we think they are, either. That is, we wouldn't solve all our technology problems if only we had - more technology. No, many of the limitations are ones we create ourselves, because of our inability to understand systemic risks, and by the way we think about and talk about technology as if it were something "new" and "different," instead of recognizing patterns that have repeated themselves in other disciplines.

One of the perspective slaps to the side of the head you get when you leave the nerdified air of Silicon Valley is that large swathes of the world are not technophiles, let alone technoacolytes. By that I mean that, regardless of the benefits of technology, once you drive past Los Gatos on highway 17, most of the people you meet don't think we'd achieve world peace if only we had a standards compliant API for it. Nor for that matter does most of the world think that the Eleventh Commandment is "thou shalt honor the Lord they God, by making thy code open source." As long as I have worked in technology, I continue to find the number of technological cults and cult members to be truly astonishing. If I were a social scientist, I might observe that, having extirpated God from so much of public life, we rush to find other ways to fill the void. The last time I checked, Deuteronomy said, "I am the Lord thy God, who led you out of Israel, out of slavery. You will have no other gods before me." Technology, it should be said, is not god. More like a golden calf.

If that sounds silly, think about the number of discussions we have all had with technocult members who speak in raptured, hushed tones about (insert all that apply): cloud computing, open source, object-oriented programming, agile development, and so on. (And my personal favorite, referring to any technology as "awesome." God and the North Shore of O´ahu in winter are awesome,* everything else is merely amazing, at best.) Note: I am not denigrating any of these technological constructs, merely observing that none of them have created world peace, cured cancer, raised the dead or helped anybody lose that last pesky 10 pounds. It's just technology. Even in my happiest moments curled up with my iPhone -- which is really nice technology and has made me more efficient -- I don't expect the iPhone GPS system to help me find real direction in life.

The first limitation of technology is one we impose ourselves: we make it a god, when it isn't, and IT people the high priests, when they aren't. The reason anybody cares is because technology has substantially altered our world and, if we admit it, not always for the better. Unfortunately, when technologists make an idol out of technology, we get all the overhead that comes with creating a new religion.


  • Non-believers may be ostracized or pressured to convert.

  • Statements of opinion - or ecstatic utterances - are treated as religious tenets and therefore, not open for discussion.

  • Instead of honest disagreements, we have (literal) religious arguments.

  • We may (figuratively) burn heretics at the stake.


The result is that in many cases technology is pushed merely because it is the next path to salvation, and without any rational discussion of whether we need it and, most importantly what risks it subjects us to - and whether they can even be understood let alone mitigated. Technologists become like the snake, telling Adam and Eve they will be as God is if they take a bite, and, like Adam and Eve, we only later realize the technological apple has rendered us naked.

I should have realized this when I first moved to Silicon Valley many moons ago. I went to a party given by a friend who happened to work for a chip company that was a competitor to the company I worked for. She introduced me to a colleague who, instead of the usual "Hi, how are you, nice to meet you," glared at me and said, "we're going to kill you in MOS technology." ("Not tonight, unless you are serving hemlock," was my response.) The "technology as god" cult has been reinforced a number of times over the interim years, most recently by an entrepreneur I recently talked to who had a hard time understanding that inventing a cool new technology was not, per se, enough to get him in my door or anybody else's. While I admire his entrepreneurial gifts, unless he is solving a problem people care about and can explain, in less than 25 words, he is not going to get past the "I only want twenty minutes of your time" barrier. It's just technology. It's not (a) god. It's not even a worthy golden calf wanna be.

Another limitation of technology is linguistic. I don't mean the difference between French and German: more like the difference between English and Martian. Many technologists might as well be speaking Martian, they are so far removed from the people who need to understand what the technology can do, what it can't do, and why anybody would want to use it. End users. Customers. Legislators. Those who are legitimate stakeholders in determining whether the risks of technology usage outweigh the benefits, but who cannot do that unless technologists can make themselves understood. By way of example, I might just possibly be understood in La Jolla if I were to say to someone in the surf lineup at Windansea, **"´Auwe, aia he mano nui loa! E ku´u hoa, e hele mai!" However, I'd be far more likely to get a response if I said "Alas! There is a really big shark. Get over here, buddy!" At any rate, if I cannot deliver a warning in English, I should not then excoriate a friend (on his way to the emergency room thanks to the man in the gray suit ***) that he really needs to learn Hawaiian to avoid future shark bites.

One of the main reasons technologists cannot or will not make themselves understood is the overuse of jargon. I've never met a group of people who were more jargon happy than technologists, unless it is teenagers -- who at least grow out of it if for no other reason than that they are forced to. (I don't care a hoot about "intergenerational communication styles," if a candidate for an open headcount insists on using "BFF" and "OMG" in an interview, he/she will experience "GFG"****.) If we are honest, we admit that we use jargon not only for the sake of efficiency but to make us feel smarter and superior than those who are not in the techno-know. Jargon becomes a means to exclude people from the club, and a means to hornswoggle others if we are fortunate enough to have an audience of either true believers or one that is too embarrassed to admit what they do not know. For our part, we reason, if they are too stupid to know what OCSP and HAML***** stand for, then they are not worth the time for us to offer our explanations. Jargon is also a means to cut yourself out of the herd. Everyone wants to be the first to either invent a new buzzword or be the first to use it. I'd only just learned what the acronym APT stands for -- Advanced Persistent Threat -- and already, I have had slimy sales reps emailing me asking about what Oracle does to combat APT and do I know that they have a product that can protect against it, not to mention slice, dice and make julienne fries? (What I'd really like is a product that protects against APSRs - Annoyingly Persistent Sales Reps. Nobody has offered to sell me one yet.)

I'm not immune to the temptation. I was once in a meeting with a bunch of developers talking about security issues. After listening to the discussion, I said with great solemnity, "as I see it, we need an ITP story. In fact, we need an S-ITP story. " Everyone nodded. Finally, someone had the courage to say, "what is S-ITP?" to which I replied, "the Secure Internet Toaster Protocol." ****** We get wrapped up in our own linguistic cleverness to the point we do not always know what we are saying. How then, can we expect our constituents to understand what technology is capable of, and what it is not capable of? True, there are many other organizations or cohorts that are almost as jargon happy as we are, but few of them are tasked with the level of responsibility we have. It's not just the Marine Corps and the Three Letter Agencies that do national security: technoids do. At least when I was in the Navy, you could always look up FAADCPAC******* or other cryptic acronyms in the DICNAVAB (Dictionary of Naval Abbreviations). Good luck with that in our industry (this is where the cloud cult members insist that all I have to do is look up my acronym in the acronym cloud). The point is: I shouldn't have to.

Even God - the real one - communicated in a language his followers could understand (and wrote the rules down on tablets). Technologists won't even do that. The other thing God (or His scribes) did was tell stories. It's easier for most people to get their minds around a creation story that begins "in the beginning, the world was formless and void..." than around the Big Bang and/or quantum physics. Phrases like "Can the Ethiopian change his skin or the leopard its spots?" speaks to the fact that some things are immutable. We get it so well that the number of people who use the phrase vastly exceed the number who know where it comes from. (Jeremiah 13:23). Analogies, stories, and using examples people understand all help make the complex more simple: God is more understandable than the average technologist. No wonder most people know that they shouldn't lie, cheat, steal but we have lots of the Clueless Faithful who think it's a good idea to allow houses to talk to power plants. (What next, wireless access to life support systems? Because it is just so expensive to send a nurse into someone's room.)

On the occasions when I have had the privilege of testifying in front of Congress, I've had 5 minutes to try to help well-intended legislators do something that will make a positive difference. How far do you think I'd get if I said, "we need to deploy IpV6 broadly to fix all our cybersecurity problems" or "insecure RNGs are the bane of network encryption?" I might actually get farther if I said, "'Auwe, eia he mano nui loa! E ku'u hoa, e hele mai!" (At least, Senators Inouye and Akaka - and the rest of the state of Hawai´i delegation - might understand.) I readily admit that I am not a technologist - I don't have the in-depth knowledge that most of my team has. What I do have is the ability to ask questions until I understand the gist of - and details of - a problem, and the ability to translate the problem into terms others can understand. Without that communication, you get people suffering from avoidable shark bites because they don't speak Hawaiian. Why is it so hard for technologists to understand that if they cannot communicate, their technological acumen is worthless, even dangerous?

Maybe the reason technologists resist the use of analogies is that it would reveal that the emperor has no clothes or, more accurately, that the emperor's clothes are the same ones everyone else is wearing. By that I mean, that if we can use analogies to explain technology and technological limits, it makes it all too obvious that we already have examples we can use to, for example, craft public policy. We might be forced to admit that technology isn't the ooh, aah, gee whiz stuff we say it is, it's just the same old problems wrapped up in shiny new bits.

For example, there are a number - no, a lot - of cybersecurity bills in draft currently. A core element of many of these bills is the degree to which the Federal government should exert "control" over private networks and what form that control should take. In my opinion, there are many reasons for thinking that the Federal government is not well suited to such a role. One of the main reasons goes to basic accountability 101. The best example I could come up with was physical security. The CEO of a company that has no door locks, no physical security of any kind, and whose company experiences massive thefts from people wandering around their buildings would not have a job for very long. The police might help investigate the break in but they would also be the first to recommend locks and a security system. They certainly would not take over building defense.

"Oh, but cyber is different." Why, precisely? Assets are increasingly stored electronically, corporate "boundaries" include electronic ones (or should). If we think there is nothing valuable to protect on corporate networks then let's skip authentication and dispense with firewalls. Clearly, we know that data is valuable and corporations do have a responsibility to protect their own resources - they owe that to shareholders. If cyber is so "complicated" that we can't possibly secure it, one has to ask why these entities knowingly continue to double down on risk they cannot mitigate. The buck stops somewhere and it is not (primarily) at the Department of Homeland Security. Business cannot realistically have it both ways - embrace the increasing use of technology ("do more with less!") and then declaim responsibility for having done so. And just as the local police department does not have keys to local businesses -- nor do they install and monitor close circuit TV in each business to detect and prevent crime -- we ought to have sensible boundaries about who secures what.

Jargon makes people feel smart and superior, but end users and key stakeholders - including, increasingly, legislators - do not speak that jargon. If we cannot learn to de-jargon ourselves and speak in languages that our audience can understand and process, technology will continue to ensnare us instead of setting us free. I'll close with an illustration that bring together several of the themes I have been talking about: responsibility, limits, and all wrapped up in a nice, de-jargoned turn of phrase:

"The LORD God took the man and put him in the Garden of Eden to work it and take care of it. And the LORD God commanded the man, "You are free to eat from any tree in the garden; but you must not eat from the tree of the knowledge of good and evil, for when you eat of it you will surely die." (Genesis 2:15-17)
I wish technologists were as forthright.


* Ok, I admit, I just violated the first commandment by making surfing a god. But the North Shore when it breaks is pretty awe-inspiring, at the least.

** Not that I've ever seen a shark there. But I did see a dorsal fin pop up next to me one Saturday. It was the longest three seconds of my life until I heard the exhale of - a dolphin.

*** "Man in the gray suit" is a surfing euphemism for "shark"

**** Gone for good

***** Caught you! OCSP is the Online Certificate Status Protocol, but HAML is something I made up (Hack Attack Markup Language, by which we all craft standards-compliant security vulnerabilities so it is easier for hackers to exploit them on multiple web applications, in a standards-compliant way).

****** As far as I can tell, there is no reason to put household appliances on a network and many reasons not to. Anyway, I don't really think you need special authorization to toast bagels vs. white bread.

******* Fleet Accounting and Disbursing Center, US Pacific Fleet, if you care.


Books

Matterhorn: A Novel of the Vietnam War by Karl Marlantes

http://www.amazon.com/gp/product/080211928X/ref=pd_lpo_k2_dp_sr_1?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0979528534&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1VJP13PEV1Q4RBD3F060

It's not often I get a chance to read a book that I think will become a classic, but this is one of them. The author is a decorated Vietnam-war veteran and the "authenticity" shows. The premise is that a green 2LT is sent into the bush with his team to take and hold a territory known as "the Matterhorn." It's impossible for me to describe how gripping this book is, how real the characters are, and how invested you become in them. I would never - I hope - have the hubris to say that I understand what it was like to have been in Vietnam, but after reading this book, I feel I have been a spectator. A great, magnificent book.

A Dog for All Seasons: A Memoir
by Patti Sherlock

http://www.amazon.com/Dog-All-Seasons-Memoir/dp/0312577923/ref=sr_1_1?ie=UTF8&s=books&qid=1273709745&sr=1-1

Personally, I am not so hot on border collies since one of them tried herding Thunder on the Nordic trail (Thunder did not want to be herded) and I had an expensive vet bill from the border collie biting him. One reason I think leash laws are critical. But I digress.

We forget that so many dogs (mine included) are working dogs. Working dogs need something to do besides sit in a dog basket and snarf dog treats. Working dogs are also indispensable to many people (you can't really herd sheep without them). The author wrote this book about a remarkable border collie named Duncan who lived with her on a sheep ranch in eastern Idaho. A dog that was more than merely a dog. Well worth the read.

Sailing in the Wake of the Ancestors: Reviving Polynesian Voyaging by Ben Finney

http://www.amazon.com/Sailing-Wake-Ancestors-Polynesian-Excellence/dp/1581780249

The resurrection of Hebrew as a popular (i.e., not merely scholarly) language is one of the great comeback stories in history. The other is the resurrection of Polynesian voyaging. This book tells the how and the why of how a dead or dying art was recreated, and the shot in the arm it gave to Polynesian peoples, who must now - largely as a result of the work of the Polynesian Voyaging Society - be acknowledged as the greatest navigators of all time. The author does not spare the infighting that almost led to the destruction of the Polynesian Voyaging Society and the means by which it was resurrected. The happy ending is the number of Polynesian peoples who are participating in wayfinding, just as their ancestors did. (It's still amazing to me that anybody can travel thousands of miles by the stars, observing ocean currents and birds.)

OWSM 11g self paced online course

Vikas Jain - Thu, 2010-07-15 02:00
Oracle University (OU) has published an online course on OWSM 11g on iLearning.
  • Oracle Web Services Manager 11g: Essentials - D67432GC10

  • Oracle Web Services Manager 11g: Securing SOA Components - D67433GC10
These are self paced online courses that provide a quick way to get started on OWSM.

UKOUG Back to Basics…. It’s coming back!

Lisa Dobson - Wed, 2010-07-14 03:08
Hot on the heels of the work I have done to get the Northern Server Tech community recognised as a UKOUG SIG, I’m now working to put together another ‘Back to Basics’ event to be held early next year.The concept behind the Back to Basics events is to deliver a full day of content which is specifically aimed at Newbies and covers a variety of topics.There is no confirmed date or venue as yet, Lisahttp://www.blogger.com/profile/16434297444320005874noreply@blogger.com0

InSync10

Jo Davis - Tue, 2010-07-13 17:09
Hi again everyone
So for InSync10 in August (Melbourne, Australia) I submitted two presentations that are completely different from one another so that the organisers could pick whichever fit in best with the rest of the agenda. They both got in - LOL! So for the record, this year I'm presenting about:

  • the effect of Subledger Accounting when you upgrade to R12; and
  • how you could use a risk-based approach to UAT for the R12 upgrade
I've done the draft outline so far - time to knuckle down this week as I think that both topics require support materials rather than just a presentation. Does anyone other than me read white papers from conferences - I always like to walk away with some reference material (preferably in PDF rather than hardcopy) - is it just me? Does anyone else keep them forever? (Yes, I still refer back to Cathy Cakebread's whitepaper on reconciling AR to GL which was originally written for R9 I believe).
Take care
Jo

Oracle Applications R12 – Complete Documentation

Habib Gohar - Tue, 2010-07-13 03:01
For complete documentation of Oracle Applications R12 ………. http://download-west.oracle.com/docs/cd/B40089_02/current/html/docset.html Regards

Multiple Matrix in one Report

Habib Gohar - Tue, 2010-07-13 02:37
When we run a wizard to create a new matrix report, we can only create a single matrix on a report. How we can make a report having multiple matrixes? Very simple ………… In report Builder Layout Model, Just select “Additional Default Layout” from the tools and create an additional layout. This will help in creating a […]

Incomplete restore....

Bas Klaassen - Tue, 2010-07-13 02:32
Yesterday I was asked to help during a restore/recovery operation of the eBS datbase. Before restoring the dba'er removed the original database (rm *). After restoring the database files from the backup abd trying to start the database, we noticed the database did not to start because he could not find his redo log files. It seemed the redo log files were not in the backup, and therefore not Bas Klaassenhttp://www.blogger.com/profile/04080547141637579116noreply@blogger.com0
Categories: APPS Blogs

APEX 4.0 - New Dynamic Action Sample Application

Anthony Rayner - Thu, 2010-07-08 05:10
In Application Express 4.0, we have introduced a new feature called 'Dynamic Actions', which enables you to define client-side behaviour declaratively in APEX. In order to try and help people gain understanding in some of the possibilities this feature offers, I have created a new dynamic action sample application featuring many different examples of both native and plug-in dynamic actions.
  • You can access this application online here.
  • Alternatively, you can download this application and install it in your own workspace, which I would recommend so you can really see what's going on. Download here.

Please note: Currently the drag and drop example doesn't work in IE, I will try and fix this up when I have time.

Useful Links:
  • To sign up for a free workspace and try out APEX 4.0 for yourself, please click here.
  • To learn more about this and other new features in Oracle Application Express 4.0, please visit our New Features page.
  • Dynamic action official documentation
  • To follow the Oracle Dynamic Actions OBE, which offers an excellent starting point, click here.

I welcome any feedback you may have and will try and blog some more about some of the specific examples when I can.

Anthony.
Categories: Development

The only thing you should NOT ask Icelanders (and maybe Norwegians) to do...

Moans Nogood - Tue, 2010-07-06 11:18
I love to visit Iceland. Not because of the landscape (We Do Not Use landscapes), but because of the people there. Man, they're funny and good to talk to.

This time (last week, for two days only) I detected a deep, slow-burning anger in the folks up there, that I haven't felt before.

One of them - a very stylish, suit-dressed bartender in his 40's, who broke his principle about not talking politics with guests (hey, the bar was empty), said that he suspected there would be real riots in the fall of 2010 if the few guilty bastards were not punished for real in court.

The handful of real bastards have been driven out of Iceland, by the way: People simply spat on them when they met them on the street AND painted their houses and cars red at night. One of the bastards re-painted his house in its original color. Guess what happened the following night.

They all now live in the UK or Florida.

Fine and good. Now you know.

But this post is about the one thing you should never ask an Icelander to do: A list.

You see, back around year 900 several Norwegian vikings sailed to Iceland. They pretty much remembered everything: Clothes. Food. The ship. Oares. Live animals. Tools. Pen & Paper. You know - all the usual stuff for a 400 years voyage.

But whoever was in charge of The Norwegian Iceland Travel List forgot one thing, and whether they discovered it quickly (i.e. on the journey) or when they had settled in in their small mud huts, I do not know. But man, they must have told The List Guy a thing or two upon suddenly remembering what they had forgot:

Women.

Anyway, they apparently decided to do something about it, because DNA-tests of Icelandic women some years ago confirmed that they originate from the British isles.

The British scientist who found this out, and who was interviewed on Danish Radio, commented on the fact that Icelandic women look Pretty Damn Good by saying (rather drily): "They probably didn't take the ugly ones."

So now you know.

HowTo - OWSM 11g: Install OWSM on base Weblogic

Vikas Jain - Wed, 2010-06-30 14:56
If you have a vanilla Weblogic (WLS) environment with no Fusion Middleware components deployed such as SOA Suite, Webcenter, etc., and you have JAX-WS clients and web services deployed in such an enviornment, you can secure these clients and services using OWSM by following this guide for step-by-step instructions on how to set it up. These instructions will be included into official documentation in the near future.

Note that these are just install instructions, with no change or bearance to the licensing model. As of Jun 2010, OWSM is licensed only through SOA Suite, and doesn't come with a standalone license. In short, to secure your clients & services using OWSM on base Weblogic, you would need to acquire SOA Suite license on top of Weblogic license.


var docstoc_docid="45646770";var docstoc_title="How To install OWSM 11gR1 on base Weblogic";var docstoc_urltitle="How To install OWSM 11gR1 on base Weblogic"; How To install OWSM 11gR1 on base Weblogic
Thanks to Amit Gokhru for validating and documenting these instructions.

FAQ - Using HTTP token policies with OWSM

Vikas Jain - Wed, 2010-06-30 13:42
When using HTTP token policies with OWSM 11g, you may want to review the following to understand their implementation behavior.

What types of HTTP token policies are available?
Following pre-defined OWSM policies are available out-of-the-box.
Client policies: oracle/wss_http_token_client_policy, oracle/wss_http_token_over_ssl_client_policy
Service policies: oracle/wss_http_token_service_policy, oracle/wss_http_token_over_ssl_service_policy

What does HTTP token policies do?
On the client side, it adds base64 encoded username/password per the Basic Authentication scheme to the HTTP Authorization header according to RFC822 and RFC2617
For example, Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
On the service side, OWSM agent gets hold of this HTTP header, decodes the username/password, and uses it to authenticate against the configured identity store through OPSS login module and WLS authenticator. Additionally, if oracle/wss_http_token_over_ssl_service_policy is used, it checks if SSL connection was indeed used to connect to the service.

Is the HTTP Authorization header sent with every message? If not, how can I enable it to be sent with every message?
No. Oracle web services stack follows the challenge-response authentication mechanism wherein client doesn't send an authorization header in the initial request to which service responds back with a 401 (Unauthorized) HTTP message. Client then stuffs the Authorization header into the second request which is then processed by the service.
This default behavior can be altered such that the Authorization header is always sent by setting a property on the client side.
In the request context, set the property ClientConstants.PREEMPTIVE_BASIC_AUTH to true

How can I disable SOAP security header inclusion when using HTTP token with SSL client policy?
The out-of-box oracle/wss_http_token_over_ssl_client_policy policy is configured to include a timestamp element in the SOAP security header similar to below.
<code style="color:#000000;word-wrap:normal;"> <wsse:Security xmlns:wsse="<a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</a>" env:mustUnderstand="1">  <br />      <wsu:Timestamp xmlns:wsu="<a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</a>" wsu:Id="Timestamp-oq2ulH1wHpSwkqAlKMaf5Q22">  <br />           <wsu:Created>2010-06-21T15:28:02Z</wsu:Created>  <br />           <wsu:Expires>2010-06-21T15:33:02Z</wsu:Expires>  <br />      </wsu:Timestamp>  <br /> </wsse:Security  <br /></code>

This can be disabled by modifying the client policy with timestamp attribute value set to false.
Note that oracle/wss_http_token_client_policy doesn't include the SOAP header.

The Art of Agile Development

Peter O'Brien - Tue, 2010-06-29 16:39
Keep this book to handThe Art of Agile Development was recommended to me by Jeff McKenna when he provided some Scrum coaching to those of us in the Dublin office working on Oracle Social CRM. Back then it was a new, hot off the press book, but I have recently reread it because I have found it useful in providing guidance on what to watch out for when changing agile development practices. This was necessary due to changes in teams and technologies as some of us focused full time on Fusion Applications. Practices, roles and responsibilities we had gotten used to had to be adapted or dropped to blend in with APM, Oracle Fusion Application's development methodology.

The book, by Shane Warden and James Shore, is a great introduction to agile development methodologies by covering both XP and scrum. Practical examples are generally from XP projects because that is where the authors have the greatest experience. The authors identify a broad set of practices that would be considered as characteristics of agile development methodologies in way or another. Recognising that it is very rare in most organisations to be able to follow an agile methodology completely as prescribed alternatives are mentioned, but not in every case. Shane and James are also very clear that many of these practices are often taking place at the same time in a software project rather than in a sequential waterfall methodology. However, categorising practices by what sort of activity and the nature of the activity give a very useful matrix for teams to analyse how agile their own practices are and perhaps identify areas where realistic improvements can be made. Just being able to have a label or term for a specific practice makes discussing within a group easier.

Download poster from James ShoreI see the collection of practices being grouped by nouns (planning, analysis, design & coding, testing, deployment) and verbs (thinking, collaborating, releasing, planning, developing). For example, when team members are working on implementing a specific feature that kind of collaboration is 'design & coding collaborating' and the section in the book covers some pair programming techniques. In fact, this particular section addresses the misconception that pair programming is a fulltime 'paired for life' regime. It is a useful tool that can be used for a few hours a day to make some significant progress, reduce interruptions, and spread the knowledge of how and why parts of the system being developed work.

Other useful techniques peppered through the book include the Agility Self Assessment and the many skill development routines, which the authors called 'etudes'. These are short exercises that may help in getting the feel for a more agile approach. When reading the chapters you might be thinking we don't have the development experience to let team members do organic, incremental architecture design, or implement thorough automated testing. I wonder how many people never complete the book because they do not believe they can carry out these changes and deliver software in a timely fashion. It's not until towards the end of the book that the authors address the reality of the mixed capabilities of the team. If this was at the beginning it might give the readers more staying power. The book does have some helpful advice on working with and around the politics, the mixture in experience levels, and heavy weight project management within your organisation. It has to be read in it's entirety though and does make for an excellent reference book to dip in and out of.
This article has been edited since it was first published.

Near-shore development in Tandil-Argentina

Marcelo Ochoa - Tue, 2010-06-29 09:30
This post is bit off topic about Oracle, but not at all.
I remember read by a first time the term near-shore development during OOW08 in a Information Week newsletter free at OTN Lounge.
Two years ago I see the increasing on development using this model in my City Tandil, 400Km far from Buenos Aires in Argentina.
Specially, I am working as external consultant with the company Temperies which was founded and growing in Tandil unlike other companies which are part of the Technology Park and came from Buenos Aires.
But why this market still growing in Tandil with well know economy changes?
First Why Tandil?

  • Is a very nice small city (130000 habitants) surrounded by hills where the quality of life makes the difference in term of productivity of the development team, this is one of the bigger difference against other Argentine cities such as Buenos Aires, Cordoba or Rosario. Any worker can get his workplace in less than five minutes walking.
  • Has a recognized University in Computer Science.
  • Is cheap to live here, so salaries are not so high.

Second Why Argentina?
  - Is a country with a big difference in term of US$/Euro exchange rate compared with another countries like Chile for example, and believe me when an near-shore project is evaluated this point is very important because with the same money you can do the project several times :)
  - Most of the computer science graduated and under-graduated students have very good knowledge of English.
  - The time zone of Argentine is in middle of Europe and US West coast, so projects can be perfectly managed around the team synchronization, if we work with San Francisco, we work during our afternoon, if we work with Germany, we work during our morning, and thats all.
Finally I want to remark that there are plenty of offers in term of Software Factories in Tandil, from small companies with 10 to 20 employees to big factories with more than one hundred employees to fit with every need.
As I set at the beginning of this post I am working with Temperies a mid-range Software Factory which, in addition to the list of goodness exposed previously, have an strong commitment with Agile practices, Oracle and a widely experience with success stories in near-shoring projects around the world, and obviously the CIOs are good friends of mine :)
Well if anybody want to go deeper in this area just drop me an email to marcelo.ochoa gmail.com or see you at the Oracle Open World in September.

Concepts Guide: 11/27 - Oracle Utilities

Charles Schultz - Fri, 2010-06-25 15:14
Wow, this chapter was hugely disappointing! I mean, it makes for a better sales pitch than technical introductions to useful features. I believe I could summarize this chapter using a pseudo-code:


products[] = getListofProducts();
foreach product in products[]
do
printHeader "Overview of $product"
print "$product is a powerful utility to manage your data quickly"
end



What is even more disappointing is that I have used all of these features/products (with the exception of the Data Pump API) and know first-hand that they are all quite useful and handy. DataPump in particular is blazingly fast at moving raw data (but amazingly slow with the subsequent ddl like indexes and stats). I mean, I could go on and say a number of excellent things about these products and the specific "things" they do, and only scratch the surface at that, and I would have surpassed what is covered in the Concepts Guide.

The one thing I did learn was that I did not realize DBID could be used to set the DBNAME. I'll have to get that a try sometime.

Woot, two chapters in one day!

Concepts Guide: 10/27 - Application Architecture

Charles Schultz - Fri, 2010-06-25 14:57
Again, I am struck by the archaic terminology (minicomputers and mainframes?). In a way, I guess the fact that the underlying technologies have not changed all that much speaks to the stability of those particular designs. And that's a good thing, right?

The architecture described in the first few pages is interesting. With a title like "Application Architecture", I was mislead into thinking this chapter was more about the application, but rather it is the fundamental pieces that Oracle has built to interface with various applications. I am a bit cautious about the apparent benefits of scaling vertically and horizonatally; obviously, everyone wants the option to scale if needed. While Vertical scaling seems to be the most common solution, I am a bit discouraged how hard Oracle PR has pushed Horizontal scaling in the form of RAC, almost as if it were a panacea for all functional and performance issues. But I digress.

I was excited to see the section "How Oracle Net Services work". As with previous technical material in this document, I was again disappointed with the high-level summary provided, instead of the real nuts and bolts. Ironically, in light of the coverage, I was surprised to find mention of "industry-standard higher level protocols"; seems to be a bit of bandwidth to advertise how compliant they are. I would think the reader would be more interested in the details that specifically relate to how Oracle talks to itself, leaving the underlying transports systems for a book of another scope. The whole point of an API is to abrstract out the details that one does not really care about. So I was glad to move on to the next section about the Listener and Services.

Yet my concern did not stop there. Check out this quote from the Listener section:
When multiple databases or instances run on one computer, as in Real Application Clusters, service names enable instances to register automatically with other listeners on the same computer. A service name can identify multiple instances, and an instance can belong to multiple services. Clients connecting to a service do not have to specify which instance they require.

Wow. Ok, so RAC runs on one computer?!? Since when? I have to admit that I am greatly impressed by how PMON communicates not only with the local listener, but also remote listeners on different computers. But there is no mention of local_listener, remote_listeners or how those play a huge role. Worse, "services" have not even been covered in sufficient detail yet; it would probably help to point out that while a service may map to multiple instances, all such instances must be part of the same database. Regardless, I have to repeat that I am duly impressed by the slickness we call "services" (head nod to Jeremy Schneider for his paper on making it a little more public). If only more beans were spilled out of the can here in the Concepts Guide.

And then the chapter ends right there. Egads! 6 pages covers Application Architecture?!?

Live Event: Oracle Enterprise Linux Configuration and Diagnostic Tips & Tricks

Sergio's Blog - Thu, 2010-06-24 02:34
On Monday June 28 at 9am PDT, our very own Greg Marsden, Senior Development Manager, will host a webcast on Oracle Enterprise Linux best practices for data center deployments. I highly recommend this session. Register here.
Categories: DBA Blogs

HowTo - OWSM 11g: Prevent PII data leakage in Oracle SOA composites

Vikas Jain - Wed, 2010-06-23 17:07
When SOA endpoint is protected using OWSM service policy, then message can be decrypted, but after that if the message contain PII attributes, they can end up in clear in logs and instance viewer in the console.
To provide security for prevention of such PII data leakage, there is an OWSM custom policy assertion available written by Robin Zimmermann and Rakesh Saha that allows selective attribute encryption within the application, and then decrypt it on the way out before it's re-encrypted using the OWSM client side policy.
See https://owsm-11g-custom-assertions.samplecode.oracle.com/

btw, Oracle BPEL 10g provided a feature for obfuscating attribute data. This solution is better than that approach as it uses digital encryption instead of obfuscation technique, and is policy based.

Pages

Subscribe to Oracle FAQ aggregator