Feed aggregator

Loosely typed interfaces - The Normalizer Pattern and Oracle SOA Suite

Peter O'Brien - Mon, 2010-07-19 15:56
When getting two or more systems working together, the making a connection part is generally the easiest, identity propagation is a bit trickier, but many times, the syntax and semantics of one system is at odds with another one. Over the decades this has been manifest in many ways and thankfully there are tools and techniques to work through them. A collation of such techniques is Enterprise Integration Patterns. The book, along with the associated website, is worthy of a dedicated article or two, and is not the real subject of this article. One message transformation pattern the book describes is the Normalizer Pattern where different formats for essentially the same object are catered for.
An example where this form of message translation becomes necessary is when using a service with a loosely typed interface. This can often happen when an existing system or utility (such as a batch / command processor) gets exposed as a web service. The request / response payload is little more than a collection of key / value pairs. There are a couple of ways to cater for this using Oracle SOA Suite 11g which I will outline in this article. One has full tool support. The other, a solution using XSLT, is not fully supported, but has an advantage in that the XSLT can be used both with the BPEL and Mediator components.

Troublesome Payloads
The challenge is to get something that is strongly typed into something that is loosely typed
Strongly TypedLoosely Typed
<department>
<name>Furniture</name>
<manager>Pam Beech</manager>
<budget>50000</budget>
<spent>20000</spent>
<committed>47000</committed>
</department>

<property>
<key>NAME</key>
<value>Furniture</value>
</property>
<property>
<key>MANAGER</key>
<value>Pam Beech</value>
</property>
<property>
<key>BUDGET</key>
<value>50000</value>
</property>
<property>
<key>SPENT</key>
<value>20000</value>
</property>
<property>
<key>COMMITTED</key>
<value>47000</value>
</property>
Now this is quite a simple example and the real world has a lot more complicated cases out there. Ones that would involve number formatting, character encoding, attribute concatenation, and so on. For the purposes of this exercise however, it is ideal to illustrate the point. All the files in this example are free and available for you to use, modify or incorporate into your own solution as you see fit. The example was produced and tested using Oracle Fusion Middleware 11.1.1.2.0. That is JDeveloper Studio 11.1.1.2.0 and WebLogic Server 11gR1. To reduce the number of files and dependencies involved, the example is a simple service (BPELProcessExample.wsdl) that takes a strongly typed request payload and returns a loosely typed response payload. The SOA composite project contains two BPEL processes that provide slightly different implementations for this same WSDL.

BPEL assign with copy and insertAfter
You can cater for the key / value pair structure by repeatedly appending a new 'property' element and then, using an XPATH predicate to specify which 'property' element is the target, copying the desired values. In the BPEL process this can all be done in a single 'assign' command, using the insertAfter instruction from the Oracle BPEL extension library. The BPEL designer supports this approach, and it is used extensively in production systems around the globe. It can get difficult to maintain and hard to read if the payload is large though. If dealing with a large payload see if you can split the copy / insertAfter instructions into two or more 'assign' commands. Ideally, you would give these 'assign' commands logical names such as 'assign_part_1_admin_details' and 'assign_part_2_finance_details'. What is a large payload in this case then? Well, I would say that if you have more than 10 key value pairs you should be seriously thinking about splitting them up and if you have more than 20, you should be definitely splitting them up. Remember, you might be familiar with the structure and understand how it is constructed, but what about the college graduate brought in by the consulting firm in a months time, or even you having to come back to this in 6 months time? Go on, make the maintenance a bit easier for everyone and break that assign behemoth into manageable chunks!

BPEL transform with XSLT
If experienced in dealing with XML documents then this approach will probably be very familiar to you. Extensible Stylesheet Language Transformations is used to convert XML data into some other format, which may also be XML data. In this case the stylesheet explicitly describes the target XML structure, making it somewhat easier to read than the BPEL assign approach described earlier. For example...
<client:property>
<client:key>
<xsl:text disable-output-escaping="no">MANAGER</xsl:text>
</client:key>
<client:value>
<xsl:value-of select="/client:process/client:department/client:manager">
</xsl:value-of>
</client:value>
</client:property>
The 'client' is a namespace prefix for the schema and in this SOA composite example the request and response happen to be defined in the same schema. This is easier to read, even if one is not all that familiar with XSL. For large payloads it is not necessary to split up the transformation as one might consider for the BPEL assign, but it could be done. The single transformation file could have a whole set of templates. However, the XSL Mapper does not support this approach yet, so if using this approach you will have to work in the Source editor, not the Design mode. Since this is using XSLT, the same XSL file can be used by the Mediator too, so it is not only a BPEL solution.

Which one is right for me?
As one can see from the diagrams there is not much difference in the BPEL designer between the two examples and the decision on which technique to use would be based on factors which are different from company to company, but clearly use of the XSL mapper is an important factor.
The complete example application with SOA composite is available at http://sites.google.com/site/soastation/soastation_looselytyped_normalizer.zip

JDeveloper Overview and (book) Review

Eduardo Rodrigues - Sat, 2010-07-17 16:55
Dear visitors, I will pretend I forgot that I'm about a year without posting anything and I will go straight to the subject that I owe to you: The review of the book "Processing XML documents with...

This is a summary only. Please, visit the blog for full content and more.

JDeveloper Overview and (book) Review

Java 2 Go! - Sat, 2010-07-17 16:55
Dear visitors, I will pretend I forgot that I'm about a year without posting anything and I will go straight to the subject that I owe to you: The review of the book "Processing XML documents with...

This is a summary only. Please, visit the blog for full content and more.
Categories: Development

unplumb (or unbinding) NICs on Linux

Dan Norris - Fri, 2010-07-16 23:30

I’ve been quiet for a long time now, but this entry hopefully will shake the cobwebs off and get me back into the habit.

I recently had a need to “unplumb” (from Solaris fame) or make interfaces on Linux “disappear” from the ifconfig list. It could be that I don’t know how to completely deconfigure an interface, but I didn’t find any methods to unassign an IP address from a Linux Ethernet interface after it was assigned. You can take interfaces down (ifconfig eth3 down) and reconfigure them to assign different addresses, but not remove the address completely.

After many searches and finding nothing that matched my need, I turned to my fellow Oakies (thanks, Mark!) who turned up this post from 2 years ago that hinted at a solution. It is driver-specific which is not ideal, but that makes sense given what I’m trying to do.

Here’s the generic version of the solution:

echo "<interface_name>" > /sys/bus/pci/drivers/<driver_name>/unbind

Determining the driver_name is pretty simple: check the /etc/modprobe.conf file (on OEL/RHEL 5.x). In that file, you’ll find things like this:

...
alias eth0 igb
alias eth1 igb
alias eth2 igb
alias eth3 igb
...

These lines indicate that the Ethernet driver used on this system by eth[0-3] is the igb driver. Now that you know the driver name, the tricky part is figuring out what the driver wants you to use as the interface name. I’ll give a few examples (and I haven’t figured out the scientific way to determine what the driver expects short of reading source code).

For the bnx2 driver, you can use the relatively simple ethernet interface name, like this:

echo "eth2" > /sys/bus/pci/drivers/bnx2/unbind

For my test system, the igb driver doesn’t use the “simple” Ethernet interface name like the bnx2 driver does. Instead, when trying that, it gives an error that the interface doesn’t exist. Time to dig in a little deeper.

On this system, the igb directory looks like this:

# ls -l /sys/bus/pci/drivers/igb/


So, knowing that I have 4 interfaces on the system, I made the correlation to the 4 addresses that appear as symlinks in the driver’s directory and expect that they indicate the interface name. Checking a couple of those (each symlink references a directory), I see this:

# ls -Ll /sys/bus/pci/drivers/igb/0000:01:00.0


You can see the directory with name “net:<interface_name>” as a subdirectory in each listing above. This tells us which interface from /sys/bus/pci/drivers/igb/0000* corresponds with which of the Linux Ethernet interface names. From this, we can see that eth2 is really 0000:07:00.0. So, in order to unbind this interface such that it no longer appears in the “ifconfig -a” output, we run this command:

echo "0000:07:00.0" > /sys/bus/pci/drivers/igb/unbind

and then it no longer appears in the “ifconfig -a” output. If you wanted to make this permanent, you should comment out the corresponding line from /etc/modprobe.conf so that it won’t be configured at boot time. Using the echo command above takes effect immediately, but won’t persist through a reboot (after reboot, the interface will return) unless the /etc/modprobe.conf changes are made.

Now, hopefully the next blog post after this one won’t require 14 more months of preparation!

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.

Pages

Subscribe to Oracle FAQ aggregator