Tips, thoughts, technologies and techniques used in enterprise portal solutions. Originally published at Head in the Web
Tuesday, December 22, 2009
Interesting Post on WLP / Beehive Custom Events
I ran across this while working on tweaking some of my own flows. As luck would have it, I never got a chance to test it out, but wanted to keep a note on it just in case I run across it again:
Saturday, December 19, 2009
SVN Subversive Plugin For WebLogic Workshop 10.2
The usual URL at http://download.eclipse.org/technology/subversive/0.7/update-site/ doesn't work for Workshop for some reason. This URL does: http://www.polarion.org/projects/subversive/download/1.1/update-site/
Tuesday, December 15, 2009
Finally: An Answer To What I do
The most dreaded question for an IT professional is "What do you do"?
I've finally found the answer. I solve problems.
What kind problems? All kinds. The key piece is, my efficiency in solving a problem is directly proportional to how interesting I find the problem. It's true for all IT pros.
For an MIS guy, it's fascinating to find the best way to get file A to point B while keeping away hacker C.
For a Web Services guru, it's all about getting data from one place to another, and the further apart they are, the more interesting it is.
I have a lot of problems I find interesting, but the one I find most interesting is how to get user A to use system B and for system B to do something useful with system C while user A has no idea that there is a system C. It just happens.
That is what I do.
I've finally found the answer. I solve problems.
What kind problems? All kinds. The key piece is, my efficiency in solving a problem is directly proportional to how interesting I find the problem. It's true for all IT pros.
For an MIS guy, it's fascinating to find the best way to get file A to point B while keeping away hacker C.
For a Web Services guru, it's all about getting data from one place to another, and the further apart they are, the more interesting it is.
I have a lot of problems I find interesting, but the one I find most interesting is how to get user A to use system B and for system B to do something useful with system C while user A has no idea that there is a system C. It just happens.
That is what I do.
Tuesday, November 17, 2009
Suppress Eclipse Warnings Annotation
When I search for something too many times, I try to remember to post it here. So, to drop the warnings for type safety when you know all is fine, you can do the following:
@SuppressWarnings("unchecked")
List<CustomerBean> customers = (List<CustomerBean>)session.getAttribute(CSRD_CONTACT_LIST);
Tuesday, November 3, 2009
I Love The Internet Thiiiiiis Much
A recent thread on Linked In lead me to this site showing how many web sites there are: http://news.netcraft.com/archives/web_server_survey.html
Sunday, October 18, 2009
Software Project Failure
I'm on a roll with the LinkedIn rants today :)
Someone once said that failure can only occur when time and resources are limiting factors. In the case of software, all of the above are true, though the most consistent cause I see is that the process of doing the following in order:
1) Set a completion date
2) Define the requirements
3) Design the software
4) Develop the software
5) Change the requirements
6) Wonder what went wrong
Agile is a good step in preventing failure from the above process except that even shops that use Agile often face that the end date is set before work begins and that unrealistic expectations are set at the same time.
Another ongoing issue is that management's reaction to bad news about meeting functionality or a date is to throw more people on the project and demand more frequent meetings which pull the people most capable of solving the issue away from solving the issue. This trains developers to not communicate issues until the last minute, which accelerates this vicious cycle.
As Dennis Miller used to say “But that’s just my opinion. I could be wrong”
Do software development efforts fail because: 1) the technical staff is not skilled enough for the work, 2) management has unrealistic expectations, 3) lack of reasonable resources to perform the effort. I would be interested to know your thoughts.
Someone once said that failure can only occur when time and resources are limiting factors. In the case of software, all of the above are true, though the most consistent cause I see is that the process of doing the following in order:
1) Set a completion date
2) Define the requirements
3) Design the software
4) Develop the software
5) Change the requirements
6) Wonder what went wrong
Agile is a good step in preventing failure from the above process except that even shops that use Agile often face that the end date is set before work begins and that unrealistic expectations are set at the same time.
Another ongoing issue is that management's reaction to bad news about meeting functionality or a date is to throw more people on the project and demand more frequent meetings which pull the people most capable of solving the issue away from solving the issue. This trains developers to not communicate issues until the last minute, which accelerates this vicious cycle.
As Dennis Miller used to say “But that’s just my opinion. I could be wrong”
Labels:
Agile,
failure,
fuq,
Random Musings,
Software
Whatever Happened to the Promise of Java Beans?
I ran across a question on LinkedIn today and gave a long-winded rant-like response that I thought I would post here, too.
My Answer: Yes, and it has been dominated by IBM and Oracle for the past decade. When the books were written that proposed business models around the technology the expectation was that Swing would win massive acceptance and that Applets would continue to be the key technology of rich web applications. None of this came to pass.
There was also the expectation of an open market of beans, which missed the fact that most developers would rather write their own and only reuse when directed, or until it becomes a habit from being directed to do so. The reuse is still mostly of internally developed beans or those that are part of vendor applications.
And the vendor applications mostly make the beans proprietary, i.e., they only run within their servers.
The exceptions to my cynical gut-reaction is the FOSS community, where many Java Beans and other reusable components can be found.
As Dennis Miller used to say "But that's just my opinion. I could be wrong"
Javabeans are hailed as reusabel software components. Is anybody aware of a market for these wigits?
My Answer: Yes, and it has been dominated by IBM and Oracle for the past decade. When the books were written that proposed business models around the technology the expectation was that Swing would win massive acceptance and that Applets would continue to be the key technology of rich web applications. None of this came to pass.
There was also the expectation of an open market of beans, which missed the fact that most developers would rather write their own and only reuse when directed, or until it becomes a habit from being directed to do so. The reuse is still mostly of internally developed beans or those that are part of vendor applications.
And the vendor applications mostly make the beans proprietary, i.e., they only run within their servers.
The exceptions to my cynical gut-reaction is the FOSS community, where many Java Beans and other reusable components can be found.
As Dennis Miller used to say "But that's just my opinion. I could be wrong"
Wednesday, October 14, 2009
Configure Apache with multiple weblogic server instances
A guy I used to work with posted this handy article:
Configure Apache with multiple weblogic server instances
Wednesday, October 7, 2009
Links Be Gone
I often save web pages as Word documents for different reasons, and sometimes need to disable the links. Finding no help in Help, I did the usual search and found the trick elsewhere.
Here's what I found:
If you just want to remove the hyperlink property of the entry, select the document—[Ctrl]A—and unlink the field—[Ctrl][Shift][F9].
Here's what I found:
If you just want to remove the hyperlink property of the entry, select the document—[Ctrl]A—and unlink the field—[Ctrl][Shift][F9].
Tuesday, October 6, 2009
Achieving Artificial Intelligence with the Reverse
I believe that AI is taking the wrong path. They are trying to work top down because that's how humans who are generally successful at solving problems approach solving problems. Problems that are somewhat familiar are best served with a rigorous approach that leads to a planned conclusion. Still, many of the greatest break-throughs have come about by accident, i.e., not following the general path at first. Penicillin and Post-It Notes come immediately to mind.
But humans only solve most problems the usual way because they have a solid ground work to start from. The accidents create a new ground work for development. Accidents come about by not following the normal path, and I think the solution to AI is in taking a different path that will lead to a ground work that will support the entire field.
AI should take the approach of developing siloed expert systems. Make lots of them and keep refining until commoditized. Then start working on higher systems that can merge related systems together though interfaces like web services (but more efficient). Then build ever higher systems until a small set of controlling systems can leverage the legacy systems. The legacy systems, truly failures to create AI and the wrong accepted path will provide an infrastructure that will support a true AI solution.
But humans only solve most problems the usual way because they have a solid ground work to start from. The accidents create a new ground work for development. Accidents come about by not following the normal path, and I think the solution to AI is in taking a different path that will lead to a ground work that will support the entire field.
AI should take the approach of developing siloed expert systems. Make lots of them and keep refining until commoditized. Then start working on higher systems that can merge related systems together though interfaces like web services (but more efficient). Then build ever higher systems until a small set of controlling systems can leverage the legacy systems. The legacy systems, truly failures to create AI and the wrong accepted path will provide an infrastructure that will support a true AI solution.
Sunday, October 4, 2009
Saturday, October 3, 2009
Steps to use OBIEE JSR168 Portlets in WebLogic Portal
Someone told me they were having trouble getting the OBIEE JSR 168 portlets to run in WLP. Since WebLogic Portal has excellent support for all published portal standards, I figured that the best thing to do is provide illustrated, step-by-step instructions.
[caption id="attachment_268" align="aligncenter" width="438" caption="Figure 1: Add the JSR168 WAR as a shared library to the application Workspace Step 1"]
[/caption]
[caption id="attachment_269" align="aligncenter" width="438" caption="Figure 2: Add the JSR168 WAR as a shared library to the application Workspace Step 2"]
[/caption]
[caption id="attachment_270" align="aligncenter" width="300" caption="Figure 3: Add the JSR168 WAR as a shared library to the application Workspace Step 3"]
[/caption]
[caption id="attachment_272" align="aligncenter" width="438" caption="Figure 5: Add shared library to Portal project Step 2"]
[/caption]
[caption id="attachment_273" align="aligncenter" width="438" caption="Figure 6: Add shared library to Portal project Step 3"]
[/caption]
[caption id="attachment_274" align="aligncenter" width="443" caption="Figure 7: Add shared library to Portal project Step 4"]
[/caption]
[caption id="attachment_275" align="aligncenter" width="438" caption="Figure 8: : Add shared library to Portal project Step 5 (Check Allow newer versions unless need explicit version control)"]
[/caption]
Add <wls:specification-version> and <wls:exact-match> nodes if required.
[caption id="attachment_276" align="aligncenter" width="448" caption="Figure 9: Uncheck Build Automatically; Clean The Workspace Without A Build And Exit Workshop Step 1"]
[/caption]
[caption id="attachment_277" align="aligncenter" width="443" caption="Figure 10: Uncheck Build Automatically; Clean The Workspace Without A Build And Exit Workshop Step 2"]
[/caption]
Restart workshop, build, deploy.
Go to Portal\Portal Management. The portlet will be listed for use on streaming portals.
[caption id="attachment_267" align="aligncenter" width="438" caption="Congradulations!"]
[/caption]
Deploy the JSR168 WAR to the WebLogic Server
Add the JSR168 WAR as a Shared Library to the Application Workspace
[caption id="attachment_268" align="aligncenter" width="438" caption="Figure 1: Add the JSR168 WAR as a shared library to the application Workspace Step 1"]
[caption id="attachment_269" align="aligncenter" width="438" caption="Figure 2: Add the JSR168 WAR as a shared library to the application Workspace Step 2"]
[caption id="attachment_270" align="aligncenter" width="300" caption="Figure 3: Add the JSR168 WAR as a shared library to the application Workspace Step 3"]
Add Shared Library To Portal Project
Figure 4: Add shared library to Portal project Step 1
[caption id="attachment_272" align="aligncenter" width="438" caption="Figure 5: Add shared library to Portal project Step 2"]
[caption id="attachment_273" align="aligncenter" width="438" caption="Figure 6: Add shared library to Portal project Step 3"]
[caption id="attachment_274" align="aligncenter" width="443" caption="Figure 7: Add shared library to Portal project Step 4"]
[caption id="attachment_275" align="aligncenter" width="438" caption="Figure 8: : Add shared library to Portal project Step 5 (Check Allow newer versions unless need explicit version control)"]
Add Library Reference To Weblogic.Xml In The Portal WEB Project
<wls:library-ref>
<wls:library-name>sawjsr168portlets</wls:library-name>
</wls:library-ref>
Add <wls:specification-version> and <wls:exact-match> nodes if required.
Un-check Build Automatically, Clean The Workspace Without A Build And Exit Workshop
[caption id="attachment_276" align="aligncenter" width="448" caption="Figure 9: Uncheck Build Automatically; Clean The Workspace Without A Build And Exit Workshop Step 1"]
[caption id="attachment_277" align="aligncenter" width="443" caption="Figure 10: Uncheck Build Automatically; Clean The Workspace Without A Build And Exit Workshop Step 2"]
Restart workshop, build, deploy.
Log-in To Portal Admin Console
Go to Portal\Portal Management. The portlet will be listed for use on streaming portals.
[caption id="attachment_267" align="aligncenter" width="438" caption="Congradulations!"]
Thursday, October 1, 2009
If the WLS 8.x Left Navigation Missing
This usually happens after an older JRE is installed or machines with an older version of IE. You need to check Internet Options - Advanced Java to see which version is installed.
This can happen frequently in shops that use older versions of Documentum WebPublisher, which requires an older JRE to work.
This can happen frequently in shops that use older versions of Documentum WebPublisher, which requires an older JRE to work.
Monday, September 14, 2009
BEA Weblogic Portal 8.x Tips & Tricks
Originally published at developer.com
As documentation goes, BEA is in my top five vendor list. It can be hard to find documentation for older versions (it’s all still there, the links are just buried), but once you find the product documentation page you’ll have a well indexed reference for most of what you need. Still, there are always those wonderful little gotchas that you will run across where the answer either came after the documentation or is something that you can do to make your life easier that the product reference team didn’t think of (or, in some cases, they thought of it but didn’t give the best answer).
In this article I want to share a few solutions I have discovered outside of the standard documentation. Some you can find on BEA’s Dev2Dev (though it might take a long time), some came from trial and error, and one came from days of pain following a the recommended path to later try almost the total opposite approach and cut my work time by two-thirds. And I am sure there are dozens (if not hundreds) of other little helpful hints, but these are the ones that I remember the most in almost three years of building many BEA Portal solutions.
The most cherished word to any vendor is also the most dreaded to an IT department: Upgrade. This is very near the top of my mind with BEA showcasing Aqualogic as a growing technology stack. I know that as soon as they have the Aqualogic Portal (or whatever name they are going to give it), I will have a lot of upgrades to do (and as a professional services consultant, I personally look forward to it). Based on the many job postings from BEA lately, my guess is that it will be heavily based on the Plumtree portal they bought last year. You may think I digress speaking of future upgrades in an article about the current version, but it all ties in.
The first BEA portal upgrade I dealt with was from version 7.x (really .x in this case, because I don’t recall the exact release) to version 8. Being a self-appointed member of the semantics police, I recall complaining that the project name for this process included the word migration rather than upgrade. When the dust finally settled, I retreated from my position on the project title. Version 7 is nothing like version 8 (which was the point of mentioning the likelihood of the next version being based on an entirely different product).
Being the astute engineers that are expected in professional services, the migration team went directly to the BEA site for a hint on how to handle this project. As I said in the beginning, BEA has pretty good documentation available and we immediately found a very detailed set of instructions for upgrading. I’m not going to make a big deal of what I thought about the instructions because I’m still a fan of BEA products. What I will state is that I am really, really glad that I had to migrate multiple portals or else I wouldn’t have this topic to write about.
If you ever need to move from version 7 to version 8 (and there are plenty of version 7 applications still out there), ignore the upgrade documentation. Instead, inventory your existing application and separate it into webflow portlets and non-webflow portlets. By doing this, you will save yourself hours (days or weeks, depending on the size of your application). Do read the online instructions for working with version 8 if you’re not familiar with it. Then create a brand new portal in 8 with all of the pages in Workshop. Once you have a nice, blank portal, import your non-webflow portlets one at a time. With each import, run a build. Each time you do this you’ll get a stack of errors for the methods that have changed. Take the advice of the Hitchhikers Guide to the Galaxy and Don’t Panic. Track down the compile errors and look up what that method did for you in version 7 and change it to use the version 8 method. This will get easier with each portlet, especially if you have a consistent development process because before you are done you’ll start to anticipate errors and correct them before you build. This may sound tedious, but it is a heck of a lot easier than following the proscribed path and tracking down both compile errors and functional bugs.
Now, according to all the documentation, you can port your webflows to pageflows with minimal fuss. This reminds me of the question asked by every mother all over the world: “If you’re friend jumped off a bride, would you do it to?” Instead, create a new pageflow, fire up your old webflow editor, and re-write it in pageflow format. This will get rid of the many limitations imposed on version 8 webflow support and prevent the harried calls from whomever inherits your applications asking how the heck to make a change to that monster. Again, no matter how tedious this sounds, it will be worth it in the time saved. Additionally, version 9 has no support for webflows, so following this track will leave you ready for a future upgrade. In fact, many of the work-arounds described in this article have been solved as a standard feature in version 9 (which I had not investigated prior to starting this article).
Upgrading from one version 8 Serviceicipate errors and correct them before you build. This may sound tedious, but it is a heck of a lot easier than following the proscribed path and tracking down both compile errors and functional bugs.
Now, according to all the documentation, you can port your webflows to pageflows with minimal fuss. This reminds me of the question asked by every mother all over the world: “If you’re friend jumped off a bride, would you do it to?” Instead, create a new pageflow, fire up your old webflow editor, and re-write it in pageflow format. This will get rid of the many limitations imposed on version 8 webflow support and prevent the harried calls from whomever inherits your applications asking how the heck to make a change to that monster. Again, no matter how tedious this sounds, it will be worth it in the time saved. Additionally, version 9 has no support for webflows, so following this track will leave you ready for a future upgrade. In fact, many of the work-arounds described in this article have been solved as a standard feature in version 9 (which I had not investigated prior to starting this article).
Upgrading from one version 8 Service Pack (SP) to another is not nearly as difficult, yet some caution should still be exercised. The whole versioning naming convention is misleading. Sometimes they are referred to as .release, sometimes as service pack releases. This would make you think that they made some enhancements that are major changes, and you would be thinking correctly. However, it would also lead you to believe that methods and classes may be added or improved that require no effort on your part to upgrade, and there you have the gotcha. Sometimes they replace classes and methods. Though the changes are covered in the release notes, who wants to read through all of that to find the two or three things that are specific to your application?
I have found that most of the big changes take place in the framework implementations. The easiest way to a smooth upgrade is to import everything into a new portal except your portlet and framework JSPs. Those you want to leave behind, then create new JSPs in your new portal and copy-paste all of your custom code from your original application. Workshop will color code the stuff that no longer works right away for you. Once you have hand-moved your JSPs into your new portal, run your build and track down the little changes. Then regression test and find the other quirks that may have popped up. One that occurred from one SP to the next is the relative path used for page tab icons. The quickest way to figure out where to move your reference to is to let the icon fail to show up and the view the page source to see where it is looking for it. The relative path changed from the framework to application. While this was a wise approach (especially for clustered environments) it can be daunting to figure out without knowing that a change occurred and it isn’t some bug in your port.
Alright, this is just a quick note on a quirk of Workshop that can be annoying for those who frequently use either their own legacy code or purchase code. I’m sure most folks who have done any extensive work with Workshop have already discovered that a BEA control project has no option for adding classpaths. While I’m sure there was some good reason behind this, it’s tough to use your existing code base throughout your portal project if you can’t reference it when you need it. To get around this limitation, just make sure that what you need is in the classpath of another plain old Java project. Then set your build order so that the project with your legacy code reference is built before your control project.
This isn’t a perfect fix as you will still need to keep your various portal projects in sync if there are cross dependencies. You will also need to document this dependency in case your control project later becomes legacy code. Still, this is far more maintainable of a solution than duplicating your legacy code into your control project.
Portals that are built well (or are well funded despite not having been done right the first time) will grow. If the growth of your portal requires no security restrictions on your new portlets and you manager all of your portal layouts through Workshop, you will never know that there are some quirks to how portlets are associated to a portal in the portal administration application. For the rest of us, here’s a couple of things to consider if it is early enough, and how to deal with them if it is too late.
Properties about your portal are stored in the database when you deploy it to your server. From what I can guess (I’m too lazy to look it up, so please don’t send me a flood of comments that this is documented somewhere) the portal was designed to be run from a managed server with plenty of horsepower. This makes sense, considering that useful portals will require a fair amount of resources and have a large enough base of users to require a server farm. What this means to those of us who manage portals in the wild is that time spent documenting and following a proper deployment plan will save hours (or days) of work dealing with future changes.
When deploying your portal, you want to first deploy it to your admin server before deploying to managed servers. This approach will allow the server to handle LDAP propagation automatically for you, so that new users are added to the full server farm instead of the first server you deploy to. At the time of this first deployment, your portal assets are catalogued into the database for management. If you deploy to a managed server first, the assets become frozen and future deployments will not update your portal administration application with new portlets and/or page. With this in mind, even if you will not be initially deploying to a server farm it is still a wise strategy to create a managed server environment anyway and follow the above plan.
If you are already in production and didn’t plan for this, all hope is not lost. The best approach would be to re-build your environment with a deployment plan, eliminating extra steps in the future. That said, I have seen situations where this was not practical (generally based on political rather than technical challenges). In which case, the next approach to gain access to your assets is to do the following:
First, if you have an admin server and haven’t already deployed your portal to it, do so now. If you have resource constraints you can always remove it once you have updated your database.
Next, in the portal admin console, create a new desktop and then assign your current portal to it. The new desktop should contain your new pages and portlets as the new desktop will generate the necessary database entries. Depending on the service pack you have installed you may need to re-start the server to add these assets to your original desktop. Now you can manage your new assets.
Another important thing to remember about your initial deployment planning is that in a clustered environment, you must deploy your LDAP to Admin only, so that it replicates properly across all servers. Otherwise you will frequently run into user profile issues. In the managed server environment, you will want to use your Admin deployment to make updates as all the neat stuff is there, where you have to search or type group names to find them in managed server admin consoles.
Some portals are small, some are big, and some are gigantic. I’m not talking about users, and not necessarily functionality, but total code involved. Code bases get huge, especially if there have been upgrades or (gasp!) migrations from one platform to another. From SP 3 up, loading Workshop and running builds can seem to take forevvvvvvver as all the paths are validated and the code assists are updated. It’s the old story of do you want it easy to use or fast (pick one). The answer from everyone is: both! That’s ok. It was evolution that got you to this point and one more step will get you past it and back to fast(er) builds. The two-step trick is to first find all the legacy stuff that you aren’t using and get rid of it. Of course, most of us don’t have the time to do that, but the second step will help in that case, too. Step two is to find all the legacy stuff (preferably only what you still use) that has not changed in eons and JAR it up. JARs get stored more efficiently and only need to be referenced the very first time the environment is created. This will cut your build times anywhere from 10 – 80%, depending on how thorough you are and how honest you are.
Portals are often used to consolidate disparate data sources into a single view, especially with the growing popularity and need for Business Intelligence Dashboards. With many of these views being composites of separate sources and/or accessing web services, sometimes the data for a portlet takes a long time load. Despite the modularity of a portlets at design time, at run time it all is distilled into a single web page, and a web page doesn’t load until the last line of HTML as been generated and sent to the browser. When one or more of your portlets takes too long to load, you could be inundated with complaints about your portals performance, even after having done everything programmatically possible to streamline your back end calls. How do you provide the users with what they want while not gaining a reputation for causing a traffic jam at the coffee pot? Use the old iFrame trick (aka the new AJAX trick).
iFrames for portlets (note: version 9 has built-in functionality to handle this issue and it is strongly recommended that if you used this work-around in version 8 to re-write your portal to use the out-of-the-box features available in version 9).
One complaint I hear from developer is about how long it takes the application to start when developing. The default memory settings are low to be respectful of slower developer machines. It is easy to change by updating your setDomainEnv.cmd file to use your memory more efficiently. The basic setting is MEM_ARGS=-Xms96m -Xmx256m. Change this to MEM_ARGS=-Xms786m -Xmx768m and the full memory will be allocated immediately rather than growing as you need it (which is usually during start up). Keep in mind that if you have less than 1GB RAM installed, this won’t work, but then if you do have less, you need more to do any serious development. I consider 1.5 to be the minimum to be productive as a developer.
Once you are up and running, you may run into out of memory errors. While this is a good way to convince the boss to buy you an upgrade (as I did before I found the real problem), t
As documentation goes, BEA is in my top five vendor list. It can be hard to find documentation for older versions (it’s all still there, the links are just buried), but once you find the product documentation page you’ll have a well indexed reference for most of what you need. Still, there are always those wonderful little gotchas that you will run across where the answer either came after the documentation or is something that you can do to make your life easier that the product reference team didn’t think of (or, in some cases, they thought of it but didn’t give the best answer).
In this article I want to share a few solutions I have discovered outside of the standard documentation. Some you can find on BEA’s Dev2Dev (though it might take a long time), some came from trial and error, and one came from days of pain following a the recommended path to later try almost the total opposite approach and cut my work time by two-thirds. And I am sure there are dozens (if not hundreds) of other little helpful hints, but these are the ones that I remember the most in almost three years of building many BEA Portal solutions.
You Can Get There From Here
The most cherished word to any vendor is also the most dreaded to an IT department: Upgrade. This is very near the top of my mind with BEA showcasing Aqualogic as a growing technology stack. I know that as soon as they have the Aqualogic Portal (or whatever name they are going to give it), I will have a lot of upgrades to do (and as a professional services consultant, I personally look forward to it). Based on the many job postings from BEA lately, my guess is that it will be heavily based on the Plumtree portal they bought last year. You may think I digress speaking of future upgrades in an article about the current version, but it all ties in.
The first BEA portal upgrade I dealt with was from version 7.x (really .x in this case, because I don’t recall the exact release) to version 8. Being a self-appointed member of the semantics police, I recall complaining that the project name for this process included the word migration rather than upgrade. When the dust finally settled, I retreated from my position on the project title. Version 7 is nothing like version 8 (which was the point of mentioning the likelihood of the next version being based on an entirely different product).
Being the astute engineers that are expected in professional services, the migration team went directly to the BEA site for a hint on how to handle this project. As I said in the beginning, BEA has pretty good documentation available and we immediately found a very detailed set of instructions for upgrading. I’m not going to make a big deal of what I thought about the instructions because I’m still a fan of BEA products. What I will state is that I am really, really glad that I had to migrate multiple portals or else I wouldn’t have this topic to write about.
If you ever need to move from version 7 to version 8 (and there are plenty of version 7 applications still out there), ignore the upgrade documentation. Instead, inventory your existing application and separate it into webflow portlets and non-webflow portlets. By doing this, you will save yourself hours (days or weeks, depending on the size of your application). Do read the online instructions for working with version 8 if you’re not familiar with it. Then create a brand new portal in 8 with all of the pages in Workshop. Once you have a nice, blank portal, import your non-webflow portlets one at a time. With each import, run a build. Each time you do this you’ll get a stack of errors for the methods that have changed. Take the advice of the Hitchhikers Guide to the Galaxy and Don’t Panic. Track down the compile errors and look up what that method did for you in version 7 and change it to use the version 8 method. This will get easier with each portlet, especially if you have a consistent development process because before you are done you’ll start to anticipate errors and correct them before you build. This may sound tedious, but it is a heck of a lot easier than following the proscribed path and tracking down both compile errors and functional bugs.
Now, according to all the documentation, you can port your webflows to pageflows with minimal fuss. This reminds me of the question asked by every mother all over the world: “If you’re friend jumped off a bride, would you do it to?” Instead, create a new pageflow, fire up your old webflow editor, and re-write it in pageflow format. This will get rid of the many limitations imposed on version 8 webflow support and prevent the harried calls from whomever inherits your applications asking how the heck to make a change to that monster. Again, no matter how tedious this sounds, it will be worth it in the time saved. Additionally, version 9 has no support for webflows, so following this track will leave you ready for a future upgrade. In fact, many of the work-arounds described in this article have been solved as a standard feature in version 9 (which I had not investigated prior to starting this article).
Upgrading from one version 8 Serviceicipate errors and correct them before you build. This may sound tedious, but it is a heck of a lot easier than following the proscribed path and tracking down both compile errors and functional bugs.
Now, according to all the documentation, you can port your webflows to pageflows with minimal fuss. This reminds me of the question asked by every mother all over the world: “If you’re friend jumped off a bride, would you do it to?” Instead, create a new pageflow, fire up your old webflow editor, and re-write it in pageflow format. This will get rid of the many limitations imposed on version 8 webflow support and prevent the harried calls from whomever inherits your applications asking how the heck to make a change to that monster. Again, no matter how tedious this sounds, it will be worth it in the time saved. Additionally, version 9 has no support for webflows, so following this track will leave you ready for a future upgrade. In fact, many of the work-arounds described in this article have been solved as a standard feature in version 9 (which I had not investigated prior to starting this article).
Upgrading from one version 8 Service Pack (SP) to another is not nearly as difficult, yet some caution should still be exercised. The whole versioning naming convention is misleading. Sometimes they are referred to as .release, sometimes as service pack releases. This would make you think that they made some enhancements that are major changes, and you would be thinking correctly. However, it would also lead you to believe that methods and classes may be added or improved that require no effort on your part to upgrade, and there you have the gotcha. Sometimes they replace classes and methods. Though the changes are covered in the release notes, who wants to read through all of that to find the two or three things that are specific to your application?
I have found that most of the big changes take place in the framework implementations. The easiest way to a smooth upgrade is to import everything into a new portal except your portlet and framework JSPs. Those you want to leave behind, then create new JSPs in your new portal and copy-paste all of your custom code from your original application. Workshop will color code the stuff that no longer works right away for you. Once you have hand-moved your JSPs into your new portal, run your build and track down the little changes. Then regression test and find the other quirks that may have popped up. One that occurred from one SP to the next is the relative path used for page tab icons. The quickest way to figure out where to move your reference to is to let the icon fail to show up and the view the page source to see where it is looking for it. The relative path changed from the framework to application. While this was a wise approach (especially for clustered environments) it can be daunting to figure out without knowing that a change occurred and it isn’t some bug in your port.
Write Once, Run In Any Project
Alright, this is just a quick note on a quirk of Workshop that can be annoying for those who frequently use either their own legacy code or purchase code. I’m sure most folks who have done any extensive work with Workshop have already discovered that a BEA control project has no option for adding classpaths. While I’m sure there was some good reason behind this, it’s tough to use your existing code base throughout your portal project if you can’t reference it when you need it. To get around this limitation, just make sure that what you need is in the classpath of another plain old Java project. Then set your build order so that the project with your legacy code reference is built before your control project.
This isn’t a perfect fix as you will still need to keep your various portal projects in sync if there are cross dependencies. You will also need to document this dependency in case your control project later becomes legacy code. Still, this is far more maintainable of a solution than duplicating your legacy code into your control project.
Dude, Where’s My Portlet?
Portals that are built well (or are well funded despite not having been done right the first time) will grow. If the growth of your portal requires no security restrictions on your new portlets and you manager all of your portal layouts through Workshop, you will never know that there are some quirks to how portlets are associated to a portal in the portal administration application. For the rest of us, here’s a couple of things to consider if it is early enough, and how to deal with them if it is too late.
Properties about your portal are stored in the database when you deploy it to your server. From what I can guess (I’m too lazy to look it up, so please don’t send me a flood of comments that this is documented somewhere) the portal was designed to be run from a managed server with plenty of horsepower. This makes sense, considering that useful portals will require a fair amount of resources and have a large enough base of users to require a server farm. What this means to those of us who manage portals in the wild is that time spent documenting and following a proper deployment plan will save hours (or days) of work dealing with future changes.
When deploying your portal, you want to first deploy it to your admin server before deploying to managed servers. This approach will allow the server to handle LDAP propagation automatically for you, so that new users are added to the full server farm instead of the first server you deploy to. At the time of this first deployment, your portal assets are catalogued into the database for management. If you deploy to a managed server first, the assets become frozen and future deployments will not update your portal administration application with new portlets and/or page. With this in mind, even if you will not be initially deploying to a server farm it is still a wise strategy to create a managed server environment anyway and follow the above plan.
If you are already in production and didn’t plan for this, all hope is not lost. The best approach would be to re-build your environment with a deployment plan, eliminating extra steps in the future. That said, I have seen situations where this was not practical (generally based on political rather than technical challenges). In which case, the next approach to gain access to your assets is to do the following:
First, if you have an admin server and haven’t already deployed your portal to it, do so now. If you have resource constraints you can always remove it once you have updated your database.
Next, in the portal admin console, create a new desktop and then assign your current portal to it. The new desktop should contain your new pages and portlets as the new desktop will generate the necessary database entries. Depending on the service pack you have installed you may need to re-start the server to add these assets to your original desktop. Now you can manage your new assets.
Another important thing to remember about your initial deployment planning is that in a clustered environment, you must deploy your LDAP to Admin only, so that it replicates properly across all servers. Otherwise you will frequently run into user profile issues. In the managed server environment, you will want to use your Admin deployment to make updates as all the neat stuff is there, where you have to search or type group names to find them in managed server admin consoles.
Are We There Yet?
Some portals are small, some are big, and some are gigantic. I’m not talking about users, and not necessarily functionality, but total code involved. Code bases get huge, especially if there have been upgrades or (gasp!) migrations from one platform to another. From SP 3 up, loading Workshop and running builds can seem to take forevvvvvvver as all the paths are validated and the code assists are updated. It’s the old story of do you want it easy to use or fast (pick one). The answer from everyone is: both! That’s ok. It was evolution that got you to this point and one more step will get you past it and back to fast(er) builds. The two-step trick is to first find all the legacy stuff that you aren’t using and get rid of it. Of course, most of us don’t have the time to do that, but the second step will help in that case, too. Step two is to find all the legacy stuff (preferably only what you still use) that has not changed in eons and JAR it up. JARs get stored more efficiently and only need to be referenced the very first time the environment is created. This will cut your build times anywhere from 10 – 80%, depending on how thorough you are and how honest you are.
When Java Calls for A Coffee Break
Portals are often used to consolidate disparate data sources into a single view, especially with the growing popularity and need for Business Intelligence Dashboards. With many of these views being composites of separate sources and/or accessing web services, sometimes the data for a portlet takes a long time load. Despite the modularity of a portlets at design time, at run time it all is distilled into a single web page, and a web page doesn’t load until the last line of HTML as been generated and sent to the browser. When one or more of your portlets takes too long to load, you could be inundated with complaints about your portals performance, even after having done everything programmatically possible to streamline your back end calls. How do you provide the users with what they want while not gaining a reputation for causing a traffic jam at the coffee pot? Use the old iFrame trick (aka the new AJAX trick).
iFrames for portlets (note: version 9 has built-in functionality to handle this issue and it is strongly recommended that if you used this work-around in version 8 to re-write your portal to use the out-of-the-box features available in version 9).
Faster Star Up in Development
One complaint I hear from developer is about how long it takes the application to start when developing. The default memory settings are low to be respectful of slower developer machines. It is easy to change by updating your setDomainEnv.cmd file to use your memory more efficiently. The basic setting is MEM_ARGS=-Xms96m -Xmx256m. Change this to MEM_ARGS=-Xms786m -Xmx768m and the full memory will be allocated immediately rather than growing as you need it (which is usually during start up). Keep in mind that if you have less than 1GB RAM installed, this won’t work, but then if you do have less, you need more to do any serious development. I consider 1.5 to be the minimum to be productive as a developer.
Once you are up and running, you may run into out of memory errors. While this is a good way to convince the boss to buy you an upgrade (as I did before I found the real problem), t
Friday, September 11, 2009
Reality Check and Free Training
If you are just starting out in development, or have found that your skills are not as marketable as they once were, nothing helps like a certificate in a new, hot field.
I'm not going to go in depth here about the free online certification course Ajax and Web 2.0 Programming (with Passion!) Online Course, because Gene Babon does such a good job of setting this up on his Beantown Web (not just for Bostonians anymore!).
I'm not going to go in depth here about the free online certification course Ajax and Web 2.0 Programming (with Passion!) Online Course, because Gene Babon does such a good job of setting this up on his Beantown Web (not just for Bostonians anymore!).
Thursday, September 10, 2009
Propagating Weblogic 8.x Portals
Originally published at developer.com
Before Service Pack 5 (SP5), the most dreaded day of some portal projects was the push to production. If you have a fairly decent deployment plan, getting the portal EAR into production was a snap. What profited the pizza industry with the late-night dinner orders was moving all of the settings that are stored in the database from Staging to Production. Entitlement roles, groups, and the association of entitlements to portlets had to be re-created by hand. Because these deployments often take place after hours, the person with the pleasure of creating them will almost always make some mistake that takes hours to trace down. The mistakes aren’t because it is terribly difficult, but because even if you get to come in late for these deployments, you still probably woke up at your usual hour and are starting to fade a bit. That, and few deployment documents are perfect. The propagation tool is here to rescue you.
The propagation tool is built into SP5 and SP6, and is available as a patch upgrade to SP4 (note: there are other patches included in this download, so this may entail risk depending on what APIs you are using). For earlier versions, you need to contact your BEA representative.
There is an official manual for the propagation tool on the BEA site, which I recommend if you want every nuance. What I will cover here is a typical, simple, straight-forward approach that will save you some time. I also deviate a bit here for the sake of doing the process faster, knowing that time is often a factor when you get to your deployment phase. As with any process, I highly recommend doing a dry-run in a test environment first (mostly because I own no stock in pizza companies). The steps described here are for SP5. They should be the same for SP6. If you wish to attempt this on an earlier version, I suggest going to the link mentioned earlier.
First, you need to put the tool where you can use it. Copy propagation.war from <WEBLOGIC_HOME>\weblogic81\portal\lib to the root of your Staging domain (or Integration, if you are moving to Staging). To make sure you put it in the right place, make sure that adminPortal.war is already in the same path you are copying to.
Start your server through Workshop, then go to <DOMAIN_ROOT>\META-INF and open application.xml in your favorite XML editor. After the last <module> entry, add the following:
When you save the file, Workshop should detect the update and automatically deploy it to the server for you. If for some reason it doesn’t, you will need to stop your server, open config.xml, and manually add the following to the end of your <Application> node:
Once your server has started up again, check your installation by going to http://<SERVER>:<PORT>/propagation (example: http://localhost:7001/propagation). You should see the following screen:
[caption id="" align="aligncenter" width="398" caption="Propagation Screen"]
[/caption]
From the screen the next step should be obvious: Click Export an Inventory. The application will walk you through the steps with fairly clear instructions (you’re welcome to read them all, based on your paranoia level or the fragility of your application). The steps are as follows, with only minor comments where necessary:
Export complete! That was easy, wasn’t it? Now you need to import it. Again, I’m going to pare things down for the simple, straight-forward process here. If your application is really, really complicated, fragile, or you just have a lot of time on your hands, you can read the full documentation at http://e-docs.bea.com/wlp/docs81/sp5/prodOps/propTool.html#1025334.
First, you need to install the propagation application on the target server. Copy the same war file to the same place in your new domain. Then deploy your portal EAR to the new domain. So long as you create the EAR after installing the propagation application on the original server, you shouldn’t have to do anything else. If for some reason it doesn’t work for you, follow the same installation instructions given above for the original server.
The import process is also very simple, and has step-by-step prompts. With lots and lots and lots of warnings. Again, we’re going to cover the short path here. And, again, read the docs at the link given earlier if you have concerns. For me, the longest part was reading the warning labels.
With the EAR and the propagation application deployed on the target server, open the propagation application the same way as before, only with your new URL (http://mynewhost:7001/propagation), and do the following:
The next screen has you export what you have just imported. Again, for the dry run, I wouldn’t bother. For the real deal, though, it is a good best practice.
You can now go to your new portal URL and review how well things turned out for you. You will need to add your users to do much real testing. If you have an authentication method that relies on an external application, you will need to test and possibly reconfigure it for your new domain. If you use the internal LDAP, you should create your users before testing.
While not considered a best practice by BEA, it is a common practice to have the same users in Staging as Production, so I feel obligated to list the steps here to propagate these as well.
In your original domain, go to the Weblogic Server Console and navigate to your security realm and click on the Migration tab and then the Export tab.
[caption id="" align="aligncenter" width="398" caption="Weblogic Server Console"]
[/caption]
I prefer to enter a path ending with LDAP to make it easy to find. Click export, then check the path you entered to make sure you have the five expected files.
If necessary, copy the folder you exported to to somewhere where your new deployment can access it.
Now go to the Import tab in your new domain and enter the location to import from.
Despite the dire warning in the propagation screen, you should have most of your assets up and running, except some as noted in the Manual screen.
Now, go have dinner at home rather than the pizza.
Before Service Pack 5 (SP5), the most dreaded day of some portal projects was the push to production. If you have a fairly decent deployment plan, getting the portal EAR into production was a snap. What profited the pizza industry with the late-night dinner orders was moving all of the settings that are stored in the database from Staging to Production. Entitlement roles, groups, and the association of entitlements to portlets had to be re-created by hand. Because these deployments often take place after hours, the person with the pleasure of creating them will almost always make some mistake that takes hours to trace down. The mistakes aren’t because it is terribly difficult, but because even if you get to come in late for these deployments, you still probably woke up at your usual hour and are starting to fade a bit. That, and few deployment documents are perfect. The propagation tool is here to rescue you.
The propagation tool is built into SP5 and SP6, and is available as a patch upgrade to SP4 (note: there are other patches included in this download, so this may entail risk depending on what APIs you are using). For earlier versions, you need to contact your BEA representative.
There is an official manual for the propagation tool on the BEA site, which I recommend if you want every nuance. What I will cover here is a typical, simple, straight-forward approach that will save you some time. I also deviate a bit here for the sake of doing the process faster, knowing that time is often a factor when you get to your deployment phase. As with any process, I highly recommend doing a dry-run in a test environment first (mostly because I own no stock in pizza companies). The steps described here are for SP5. They should be the same for SP6. If you wish to attempt this on an earlier version, I suggest going to the link mentioned earlier.
First, you need to put the tool where you can use it. Copy propagation.war from <WEBLOGIC_HOME>\weblogic81\portal\lib to the root of your Staging domain (or Integration, if you are moving to Staging). To make sure you put it in the right place, make sure that adminPortal.war is already in the same path you are copying to.
Start your server through Workshop, then go to <DOMAIN_ROOT>\META-INF and open application.xml in your favorite XML editor. After the last <module> entry, add the following:
<module>
<web>
<web-uri>propagation.war</web-uri>
<context-root>propagation</context-root>
</web>
</module>
When you save the file, Workshop should detect the update and automatically deploy it to the server for you. If for some reason it doesn’t, you will need to stop your server, open config.xml, and manually add the following to the end of your <Application> node:
<WebAppComponent Targets="genericPortalServer" URI="propagation.war"/>
Once your server has started up again, check your installation by going to http://<SERVER>:<PORT>/propagation (example: http://localhost:7001/propagation). You should see the following screen:
[caption id="" align="aligncenter" width="398" caption="Propagation Screen"]
From the screen the next step should be obvious: Click Export an Inventory. The application will walk you through the steps with fairly clear instructions (you’re welcome to read them all, based on your paranoia level or the fragility of your application). The steps are as follows, with only minor comments where necessary:
- Enter the user name and password for the uber admin account
- Click Continue
- Click Export XML
- Click Export Locally and save to someplace convenient (unless you are propagating to an domain on the same machine with read-write privileges)
Export complete! That was easy, wasn’t it? Now you need to import it. Again, I’m going to pare things down for the simple, straight-forward process here. If your application is really, really complicated, fragile, or you just have a lot of time on your hands, you can read the full documentation at http://e-docs.bea.com/wlp/docs81/sp5/prodOps/propTool.html#1025334.
First, you need to install the propagation application on the target server. Copy the same war file to the same place in your new domain. Then deploy your portal EAR to the new domain. So long as you create the EAR after installing the propagation application on the original server, you shouldn’t have to do anything else. If for some reason it doesn’t work for you, follow the same installation instructions given above for the original server.
The import process is also very simple, and has step-by-step prompts. With lots and lots and lots of warnings. Again, we’re going to cover the short path here. And, again, read the docs at the link given earlier if you have concerns. For me, the longest part was reading the warning labels.
With the EAR and the propagation application deployed on the target server, open the propagation application the same way as before, only with your new URL (http://mynewhost:7001/propagation), and do the following:
- Click Import an Inventory
- Log in
- Click the Specify the file radio button
- Enter the full path to the zip file you created in the export process, including the file name, i.e., I:\DeveloperDotCom\Propagating BEA Portals\inventory.zip
- Click Continue (if you see The input file was not found. The application tree was loaded instead., check your path)
- Click Continue
- Click Preview Changes
- Click the checkbox, then click Continue
- Click Deployment Complete
- Click Continue
- Click Continue
- Scroll to the bottom and Click Continue
- On the Review Manual Changes page, there will probably be a list. This is why I recommend a dry run, because you may not need to do anything with this list, so click Continue the first time and out and note during your testing if anything needs to be dealt with. Note that users are not exported, and this is addressed later in this article.
- Click Continue
- Click Commit the Inventory
The next screen has you export what you have just imported. Again, for the dry run, I wouldn’t bother. For the real deal, though, it is a good best practice.
You can now go to your new portal URL and review how well things turned out for you. You will need to add your users to do much real testing. If you have an authentication method that relies on an external application, you will need to test and possibly reconfigure it for your new domain. If you use the internal LDAP, you should create your users before testing.
While not considered a best practice by BEA, it is a common practice to have the same users in Staging as Production, so I feel obligated to list the steps here to propagate these as well.
In your original domain, go to the Weblogic Server Console and navigate to your security realm and click on the Migration tab and then the Export tab.
[caption id="" align="aligncenter" width="398" caption="Weblogic Server Console"]
I prefer to enter a path ending with LDAP to make it easy to find. Click export, then check the path you entered to make sure you have the five expected files.
If necessary, copy the folder you exported to to somewhere where your new deployment can access it.
Now go to the Import tab in your new domain and enter the location to import from.
Despite the dire warning in the propagation screen, you should have most of your assets up and running, except some as noted in the Manual screen.
Now, go have dinner at home rather than the pizza.
Tuesday, September 8, 2009
Developing Software in a Sauna
There are cynics amongst us (if you are reading this, you should know that by now) who say that the most pleasurable part of a sauna is getting out of it and being relieved from the heat.
Coding software is like that, sometimes. You will always run across a bug in your software, or poor documentation, or an upgrade or language shift where all the things you expect to be there aren't. So you bang your head against the wall until a solution falls out it (hopefully your head, though the wall has contributed on occasion). And then you stop banging your head and give it a final slap as you solve the problem. Then it feels good. So good, you wind up banging your head again in a few months/days/hours over another problem.
Coding software is like that, sometimes. You will always run across a bug in your software, or poor documentation, or an upgrade or language shift where all the things you expect to be there aren't. So you bang your head against the wall until a solution falls out it (hopefully your head, though the wall has contributed on occasion). And then you stop banging your head and give it a final slap as you solve the problem. Then it feels good. So good, you wind up banging your head again in a few months/days/hours over another problem.
Thursday, September 3, 2009
How to Customize the Color Scheme for the BEA WebLogic Server 9.x Administration Console
Originally published at developer.com
At last year’s BEA World many portal developers were excited to hear that the WLS Administration Console is now portal-based. As developers, we all know that what excites us doesn’t always excite those who hold the purse strings, and customizing an application that is only used by IT generally falls pretty close to the bottom of the budget approval list. At least until there is a really good reason for it. So, my first foray into customizing the WLS Administration Console didn’t come about until 9.2, and was limited to changing color schemes.
For those of you looking for approval to customize your console, the driver for the project this article is based on came from a case where multiple BEA domains were running installed on the same physical machine. When the maintenance team would log in to the various consoles they would occasionally make an update to the wrong domain. Doh! For those who have done support, this comes as no big surprise. Many service activities are scheduled in off hours. Off hours are defined as when most users are off the applications and most IT folks are off their par because it is too late at night. The only visual cue as to which console you are logged into is some subtle text showing the user name and domain name.
The solution for this was to color-code the header in each Administration Console. While this sounds fairly straight-forward to the average portal developer, there are a few things that made it a bit of a challenge. First, the Administration Console application is compiled (as it should be), so cracking it open was a bad option as this could have upgrade implications. Second, even if one were to crack open the Administration Console portal (we’ve all made a similar call and regretted it at the next upgrade), the application under WEBLOGIC_HOME affects all domains rather than individual domains. Finally, the steps described at http://e-docs.bea.com/wls/docs92/console_ext/rebrand.html leave out a couple of minor pieces that are only obvious to portal developers. To make a long story short (which is only ever said when it is already too late) I came up with the following steps that worked for this effort.
(If you don’t already have a portal development environment, download the latest from http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/portal/.)
Create a new workspace for Eclipse for your customization project. For old-time Eclipse developers, this may sound odd. I thought it odd that the BEA best practice is a new workspace for each related group of projects and at first stuck to my old ways of one workspace for all projects. Then I made a change to the wrong project and stopped being so obstinate. Since there are similar types of projects from one group to the next, it is an easy mistake to make and thus the smart recommendation not to. Long story etc.
In your new workspace, create a new Java project named console-extension. While it doesn’t matter what you name your project, this name makes it easier to remember what it is for and to reference documentation related to console customization. Next, import [WEBLOGIC_HOME]\samples\server\medrec\console-extension into your new project. If you are unfamiliar with Eclipse imports, this is done with the File System option in the Import dialog. Once we have this tree in, we want to trim the branches that we don’t want to change by deleting the following:
\workspace\console-extension\framework\markup
\workspace\console-extension\common
All in \workspace\console-extension\framework\skins\xray EXCEPT the following:
css
images
skin.properties
All in \workspace\console-extension\framework\skins\xray\images
All in \workspace\console-extension\framework\skins\xray\css
All in \workspace\console-extension\framework\skeletons\xray
All in \workspace\console-extension\images
Now we want to add some files for our use. First, create a skeleton.properties file in \workspace\console-extension\framework\skeletons\xray and add the following:
jsp.search.path: ., ../default
Then do the following imports (all files in the path for each):
[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\framework\skins\default\images to /console-extension/framework/skeletons/xray/images
[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\images to /console-extension/images
[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\framework\skins\default\css\ to \workspace\console-extension\framework\skins\xray\css
Next, open /console-extension/framework/skins/xray/skin.properties and delete the following (spread in groups through the file):
theme.plain.search.path: plain/images, images
theme.alert.search.path: alert/images, images
theme.wlsmodules.search.path: wlsmodules/images, images
theme.wlstoolbar.search.path: wlstoolbar/images, images
theme.wlsbreadcrumbs.search.path: wlsbreadcrumbs/images, images
theme.wlschangemgmt.search.path: wlschangemgmt/images, images
theme.wlsworkspace.search.path: wlsworkspace/images, images
theme.wlsnavtree.search.path: wlsnavtree/images, images
theme.wlsmessages.search.path: wlsmessages/images, images
theme.wlsstatus.search.path: wlsstatus/images, images
theme.wlsquicklinks.search.path: wlsquicklinks/images, images
link.window-plain.href: plain/css/window-plain.css
link.window-plain.rel: stylesheet
link.window-plain.type: text/css
link.window-alert.href: alert/css/window-alert.css
link.window-alert.rel: stylesheet
link.window-alert.type: text/css
link.window-wlsmodules.href: wlsmodules/css/window-wlsmodules.css
link.window-wlsmodules.rel: stylesheet
link.window-wlsmodules.type: text/css
link.window-wlstoolbar.href: wlstoolbar/css/window-wlstoolbar.css
link.window-wlstoolbar.rel: stylesheet
link.window-wlstoolbar.type: text/css
link.window-wlsbreadcrumbs.href: wlsbreadcrumbs/css/window-wlsbreadcrumbs.css
link.window-wlsbreadcrumbs.rel: stylesheet
link.window-wlsbreadcrumbs.type: text/css
link.window-wlschangemgmt.href: wlschangemgmt/css/window-wlschangemgmt.css
link.window-wlschangemgmt.rel: stylesheet
link.window-wlschangemgmt.type: text/css
link.button-wlschangemgmt.href: wlschangemgmt/css/button-wlschangemgmt.css
link.button-wlschangemgmt.rel: stylesheet
link.button-wlschangemgmt.type: text/css
link.window-wlsworkspace.href: wlsworkspace/css/window-wlsworkspace.css
link.window-wlsworkspace.rel: stylesheet
link.window-wlsworkspace.type: text/css
link.book-wlsworkspace.href: wlsworkspace/css/book-wlsworkspace.css
link.book-wlsworkspace.rel: stylesheet
link.book-wlsworkspace.type: text/css
link.window-wlsnavtree.href: wlsnavtree/css/window-wlsnavtree.css
link.window-wlsnavtree.rel: stylesheet
link.window-wlsnavtree.type: text/css
link.window-wlsmessages.href: wlsmessages/css/window-wlsmessages.css
link.window-wlsmessages.rel: stylesheet
link.window-wlsmessages.type: text/css
link.window-wlsstatus.href: wlsstatus/css/window-wlsstatus.css
link.window-wlsstatus.rel: stylesheet
link.window-wlsstatus.type: text/css
link.window-wlsquicklinks.href: wlsquicklinks/css/window-wlsquicklinks.css
link.window-wlsquicklinks.rel: stylesheet
link.window-wlsquicklinks.type: text/css
script.skin.src: skin.js
script.skin.type: text/javascript
script.menu.src: menu.js
script.menu.type: text/javascript
script.util.src: util.js
script.util.type: text/javascript
script.delete.src: delete.js
script.delete.type: text/javascript
script.float.src: float.js
script.float.type: text/javascript
script.menufx.src: menufx.js
script.menufx.type: text/javascript
(note that if you want to customize any of the above UI elements for your own application leave the ones you need).
Open netuix-extension.xml and delete the following: default-window-icon="window-icon.gif" and default-window-icon-path="/console/images/"
To change our header appearance we need to change two files. First, open /console-extension/framework/skins/xray/css/body.css and change the value of background-color: for .bea-portal-body-header; Then, grab an image editor and change the color in /console-extension/framework/skins/xray/images/banner_bg.gif to the same value. For ascetics, you may wish to edit /console-extension/framework/skins/xray/images/banner_logo.gif as well.
Finally, save everything, then right-click on the console-extension project and select Export. Export as a JAR file to domain-dir/console-ext directory (or to a handy local location to later be uploaded to the domain-dir/console-ext directory). If you made any of your changes in the file system rather than in Eclipse, be sure to refresh your project before exporting or you will get errors.
The example below uses the color value of FFCC33 to replace the default:
While there may be some simpler paths to achieving this, this particular approach was the fastest solution that should have little or no impact to future upgrades within the 9.x WebLogic Server series. If most of these steps seem daunting, you can grab the workspace from here (PLEASE CREATE LINK TO workspace.zip) and find the values you want to change.
Scott Nelson is a Professional Services Principal Portal Consultant by day and a blogger with a sense of humor by night. This article illustrates the former. To confirm the latter for yourself, visit http://humor.fywservices.com/.
At last year’s BEA World many portal developers were excited to hear that the WLS Administration Console is now portal-based. As developers, we all know that what excites us doesn’t always excite those who hold the purse strings, and customizing an application that is only used by IT generally falls pretty close to the bottom of the budget approval list. At least until there is a really good reason for it. So, my first foray into customizing the WLS Administration Console didn’t come about until 9.2, and was limited to changing color schemes.
A Business Case for Customizing the Console
For those of you looking for approval to customize your console, the driver for the project this article is based on came from a case where multiple BEA domains were running installed on the same physical machine. When the maintenance team would log in to the various consoles they would occasionally make an update to the wrong domain. Doh! For those who have done support, this comes as no big surprise. Many service activities are scheduled in off hours. Off hours are defined as when most users are off the applications and most IT folks are off their par because it is too late at night. The only visual cue as to which console you are logged into is some subtle text showing the user name and domain name.
The solution for this was to color-code the header in each Administration Console. While this sounds fairly straight-forward to the average portal developer, there are a few things that made it a bit of a challenge. First, the Administration Console application is compiled (as it should be), so cracking it open was a bad option as this could have upgrade implications. Second, even if one were to crack open the Administration Console portal (we’ve all made a similar call and regretted it at the next upgrade), the application under WEBLOGIC_HOME affects all domains rather than individual domains. Finally, the steps described at http://e-docs.bea.com/wls/docs92/console_ext/rebrand.html leave out a couple of minor pieces that are only obvious to portal developers. To make a long story short (which is only ever said when it is already too late) I came up with the following steps that worked for this effort.
(If you don’t already have a portal development environment, download the latest from http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/portal/.)
Steps to Changing the Header Colors
Create a new workspace for Eclipse for your customization project. For old-time Eclipse developers, this may sound odd. I thought it odd that the BEA best practice is a new workspace for each related group of projects and at first stuck to my old ways of one workspace for all projects. Then I made a change to the wrong project and stopped being so obstinate. Since there are similar types of projects from one group to the next, it is an easy mistake to make and thus the smart recommendation not to. Long story etc.
In your new workspace, create a new Java project named console-extension. While it doesn’t matter what you name your project, this name makes it easier to remember what it is for and to reference documentation related to console customization. Next, import [WEBLOGIC_HOME]\samples\server\medrec\console-extension into your new project. If you are unfamiliar with Eclipse imports, this is done with the File System option in the Import dialog. Once we have this tree in, we want to trim the branches that we don’t want to change by deleting the following:
\workspace\console-extension\framework\markup
\workspace\console-extension\common
All in \workspace\console-extension\framework\skins\xray EXCEPT the following:
css
images
skin.properties
All in \workspace\console-extension\framework\skins\xray\images
All in \workspace\console-extension\framework\skins\xray\css
All in \workspace\console-extension\framework\skeletons\xray
All in \workspace\console-extension\images
Now we want to add some files for our use. First, create a skeleton.properties file in \workspace\console-extension\framework\skeletons\xray and add the following:
jsp.search.path: ., ../default
Then do the following imports (all files in the path for each):
[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\framework\skins\default\images to /console-extension/framework/skeletons/xray/images
[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\images to /console-extension/images
[WEBLOGIC_HOME]\server\lib\consoleapp\webapp\framework\skins\default\css\ to \workspace\console-extension\framework\skins\xray\css
Next, open /console-extension/framework/skins/xray/skin.properties and delete the following (spread in groups through the file):
theme.plain.search.path: plain/images, images
theme.alert.search.path: alert/images, images
theme.wlsmodules.search.path: wlsmodules/images, images
theme.wlstoolbar.search.path: wlstoolbar/images, images
theme.wlsbreadcrumbs.search.path: wlsbreadcrumbs/images, images
theme.wlschangemgmt.search.path: wlschangemgmt/images, images
theme.wlsworkspace.search.path: wlsworkspace/images, images
theme.wlsnavtree.search.path: wlsnavtree/images, images
theme.wlsmessages.search.path: wlsmessages/images, images
theme.wlsstatus.search.path: wlsstatus/images, images
theme.wlsquicklinks.search.path: wlsquicklinks/images, images
link.window-plain.href: plain/css/window-plain.css
link.window-plain.rel: stylesheet
link.window-plain.type: text/css
link.window-alert.href: alert/css/window-alert.css
link.window-alert.rel: stylesheet
link.window-alert.type: text/css
link.window-wlsmodules.href: wlsmodules/css/window-wlsmodules.css
link.window-wlsmodules.rel: stylesheet
link.window-wlsmodules.type: text/css
link.window-wlstoolbar.href: wlstoolbar/css/window-wlstoolbar.css
link.window-wlstoolbar.rel: stylesheet
link.window-wlstoolbar.type: text/css
link.window-wlsbreadcrumbs.href: wlsbreadcrumbs/css/window-wlsbreadcrumbs.css
link.window-wlsbreadcrumbs.rel: stylesheet
link.window-wlsbreadcrumbs.type: text/css
link.window-wlschangemgmt.href: wlschangemgmt/css/window-wlschangemgmt.css
link.window-wlschangemgmt.rel: stylesheet
link.window-wlschangemgmt.type: text/css
link.button-wlschangemgmt.href: wlschangemgmt/css/button-wlschangemgmt.css
link.button-wlschangemgmt.rel: stylesheet
link.button-wlschangemgmt.type: text/css
link.window-wlsworkspace.href: wlsworkspace/css/window-wlsworkspace.css
link.window-wlsworkspace.rel: stylesheet
link.window-wlsworkspace.type: text/css
link.book-wlsworkspace.href: wlsworkspace/css/book-wlsworkspace.css
link.book-wlsworkspace.rel: stylesheet
link.book-wlsworkspace.type: text/css
link.window-wlsnavtree.href: wlsnavtree/css/window-wlsnavtree.css
link.window-wlsnavtree.rel: stylesheet
link.window-wlsnavtree.type: text/css
link.window-wlsmessages.href: wlsmessages/css/window-wlsmessages.css
link.window-wlsmessages.rel: stylesheet
link.window-wlsmessages.type: text/css
link.window-wlsstatus.href: wlsstatus/css/window-wlsstatus.css
link.window-wlsstatus.rel: stylesheet
link.window-wlsstatus.type: text/css
link.window-wlsquicklinks.href: wlsquicklinks/css/window-wlsquicklinks.css
link.window-wlsquicklinks.rel: stylesheet
link.window-wlsquicklinks.type: text/css
script.skin.src: skin.js
script.skin.type: text/javascript
script.menu.src: menu.js
script.menu.type: text/javascript
script.util.src: util.js
script.util.type: text/javascript
script.delete.src: delete.js
script.delete.type: text/javascript
script.float.src: float.js
script.float.type: text/javascript
script.menufx.src: menufx.js
script.menufx.type: text/javascript
(note that if you want to customize any of the above UI elements for your own application leave the ones you need).
Open netuix-extension.xml and delete the following: default-window-icon="window-icon.gif" and default-window-icon-path="/console/images/"
To change our header appearance we need to change two files. First, open /console-extension/framework/skins/xray/css/body.css and change the value of background-color: for .bea-portal-body-header; Then, grab an image editor and change the color in /console-extension/framework/skins/xray/images/banner_bg.gif to the same value. For ascetics, you may wish to edit /console-extension/framework/skins/xray/images/banner_logo.gif as well.
Deploying Your Updates
Finally, save everything, then right-click on the console-extension project and select Export. Export as a JAR file to domain-dir/console-ext directory (or to a handy local location to later be uploaded to the domain-dir/console-ext directory). If you made any of your changes in the file system rather than in Eclipse, be sure to refresh your project before exporting or you will get errors.
The example below uses the color value of FFCC33 to replace the default:
While there may be some simpler paths to achieving this, this particular approach was the fastest solution that should have little or no impact to future upgrades within the 9.x WebLogic Server series. If most of these steps seem daunting, you can grab the workspace from here (PLEASE CREATE LINK TO workspace.zip) and find the values you want to change.
Scott Nelson is a Professional Services Principal Portal Consultant by day and a blogger with a sense of humor by night. This article illustrates the former. To confirm the latter for yourself, visit http://humor.fywservices.com/.
Tuesday, September 1, 2009
Can I Told You So Be Retroactive?
I was part of the team at my former employer bidding for the re-work of the MBTA web site. Lo and behold (whatever that means), I get around to reading /. for the first time since then and I run across this little item that talks about how the new-and-improved site didn't support Opera and has been rolled back to it's earlier version.
So, if they had gone with my former company and if I had stayed, they wouldn't be having these issues. But, then, I probably wouldn't have time to read about them :)
So, if they had gone with my former company and if I had stayed, they wouldn't be having these issues. But, then, I probably wouldn't have time to read about them :)
Monday, August 31, 2009
Quieter Console for WLP 9.2.x Domains
In the server console window when starting WLP 9.2.x there is a lot of logging that is both useless and slows down the start of your unit tests when developing. Here is how to get rid of that:
Go into your WebLogic Administration Console.
Under Environment on the left hand side navigation there is a node called Work Managers. Click on that and add a new Work Manager for the name:
weblogic.wsee.mdb.DispatchPolicy
Be sure to check the target server on the Next screen after adding the name.
Note: This tip came from Dev2Dev, which is sadly no longer.
Go into your WebLogic Administration Console.
Under Environment on the left hand side navigation there is a node called Work Managers. Click on that and add a new Work Manager for the name:
weblogic.wsee.mdb.DispatchPolicy
Be sure to check the target server on the Next screen after adding the name.
Note: This tip came from Dev2Dev, which is sadly no longer.
Sunday, August 30, 2009
Whether to Use Open Source or Windows Development Platform
The following questions was on LinkedIn today:
Here is my response:
I started typing a couple of different responses, and then stopped as it occurred to me that the world of the operating system has turned upside in the last ten years, because your choice for OS is literally Mircrosoft or Open Source. All of the other vendors have either gone open source or are too small to consider as real choices anymore.
So from the OS point of view, it is a choice of who your support vendor is now.
Once you choose your operating system, then you need to choose your software packages. This is where in-house skill is a big part of the equation, because if you don't have people that will take complete ownership of both the framework and custom code, your open source options narrow. You have to look at which projects have the most solid team that will still be updating the product n years from now. Currently, those are products that either have vendor sponsorship (and you expect the vendor to be around n years from now) or are so wildly popular for so long that even if the current group gets rich and bored someone else will step in.
And, back to the Windows or something else question: For a web-based application, if software doesn't run on both (at least a version that runs on both), I wouldn't consider it.
But (as Dennis Miller used to say every week), that's just my opinion. I could be wrong.
How to decide whether to use Open Source or Windows development platform. we are working on creating a SAAS model for a payroll and HR software. The debate we currently having is to on what software to develop Open Source or Windows. Need some help to decide the parameters on which to compare so as to come up with a logical decision rather than the decision based on gut.
Here is my response:
I started typing a couple of different responses, and then stopped as it occurred to me that the world of the operating system has turned upside in the last ten years, because your choice for OS is literally Mircrosoft or Open Source. All of the other vendors have either gone open source or are too small to consider as real choices anymore.
So from the OS point of view, it is a choice of who your support vendor is now.
Once you choose your operating system, then you need to choose your software packages. This is where in-house skill is a big part of the equation, because if you don't have people that will take complete ownership of both the framework and custom code, your open source options narrow. You have to look at which projects have the most solid team that will still be updating the product n years from now. Currently, those are products that either have vendor sponsorship (and you expect the vendor to be around n years from now) or are so wildly popular for so long that even if the current group gets rich and bored someone else will step in.
And, back to the Windows or something else question: For a web-based application, if software doesn't run on both (at least a version that runs on both), I wouldn't consider it.
But (as Dennis Miller used to say every week), that's just my opinion. I could be wrong.
Saturday, August 29, 2009
Annotation Overrides in a Cluster
The original blog I referenced in my original blog (I recall someone laughing at the term "Legacy Web Application" back in 2000) is sadly gone. So, for those who may run into the following error:
Here is the closest reference still available to help you out: http://blogs.oracle.com/jamesbayer/2007/08/changing_weblogic_annotations.html
"javax.enterprise.deploy.model.exceptions.DDBeanCreateException: [J2EE Deployment SPI:260142]The descriptor at 'META-INF/annotation-manifest.xml' in module
Here is the closest reference still available to help you out: http://blogs.oracle.com/jamesbayer/2007/08/changing_weblogic_annotations.html
Sunday, August 23, 2009
Permission Error on Delete Directory for Java Projects on Windows
I wish I had take a screen shot of the error to make this easier for folks to say "oh, yeah, I have that problem". The thing is, when you build some J2EE applications from a project on the Desktop or My Documents (which I am only now starting to use out of convenience for back up programs that think that is where things should be stored) and then are done with them you find you can't delete them. You get this annoying warning that you might not have permission to do so, even though your are the administrator in Windows and the owner of the files.
This is because of a bug in Windows meant to annoy those of use who like having the directory structure match the namespace. The generated name spaces are often too long when combined with all that extra path crud that goes to My Documents or Desktop for the OS to handle. So, the simple solution is take the folder and drag it into the root of the drive and then delete it. Apparently, only delete is crippled by this bug and not move. Go figure.
And, yes, I know that Microsoft bashing is cheap and easy. So am I, which is why I do it. I am fully aware that if it were not for Microsoft I would most likely be living in a trailer wondering why a guy that likes and understands something as complex as programming is ignored by Corporate America and treated like a warehouse worker (the way it was before Bill was a Billionaire). Thank you Bill, for everything :)
PS: Microsoft bugs still piss me off.
This is because of a bug in Windows meant to annoy those of use who like having the directory structure match the namespace. The generated name spaces are often too long when combined with all that extra path crud that goes to My Documents or Desktop for the OS to handle. So, the simple solution is take the folder and drag it into the root of the drive and then delete it. Apparently, only delete is crippled by this bug and not move. Go figure.
And, yes, I know that Microsoft bashing is cheap and easy. So am I, which is why I do it. I am fully aware that if it were not for Microsoft I would most likely be living in a trailer wondering why a guy that likes and understands something as complex as programming is ignored by Corporate America and treated like a warehouse worker (the way it was before Bill was a Billionaire). Thank you Bill, for everything :)
PS: Microsoft bugs still piss me off.
Sunday, August 16, 2009
Scott Adams Nails it Again
My Session Has Fallen and I Can't Get Out
Ran across on question on LinkedIn today and thought the answer belonged here as well...
Q: (paraphrased for grammar) How to automatically redirect to the login page after a session time out?
A: Assuming that there is a security session that is separate from your server session, you can add a hidden AJAX component that checks every n seconds and redirects when the session is closed. When you do this, you need to include in your keep alive call an appended parameter that is incremented or changed randomly each time or else you may get a cached response from the browser and miss that magic time out moment.
If you need to know if the session of the same application on the same server has timed out, there is a chicken and egg paradox as any call to the server to check if the session is still alive will keep the session alive, so it will never time out. I've heard of applications that have worked around this, but have not had to research it out as the requirement always resolved to a security session timing out that lived on another server (as described in the first paragraph) or the that simply have the page go to the login page on the next click after the timeout was acceptable.
To go to the login page after the next click in a timed out session, simply fill in the security node of your web.xml completely and the web server will do the rest.
Q: (paraphrased for grammar) How to automatically redirect to the login page after a session time out?
A: Assuming that there is a security session that is separate from your server session, you can add a hidden AJAX component that checks every n seconds and redirects when the session is closed. When you do this, you need to include in your keep alive call an appended parameter that is incremented or changed randomly each time or else you may get a cached response from the browser and miss that magic time out moment.
If you need to know if the session of the same application on the same server has timed out, there is a chicken and egg paradox as any call to the server to check if the session is still alive will keep the session alive, so it will never time out. I've heard of applications that have worked around this, but have not had to research it out as the requirement always resolved to a security session timing out that lived on another server (as described in the first paragraph) or the that simply have the page go to the login page on the next click after the timeout was acceptable.
To go to the login page after the next click in a timed out session, simply fill in the security node of your web.xml completely and the web server will do the rest.
Friday, August 14, 2009
Work is the Curse of the Web Technologist
While it is very good to be busy in economic times such as these, it becomes easy to fall behind when keeping ahead. One obvious example is the fall off of my postings on this blog. The other is when a new spec right at the heart of my day-to-day livlihood is under construction for four months before it pops up on my radar.
In this case, I'm talking about HTML 5.
OTOH, web specifications seem to be totally outside of the whole "Internet speed" thing, because I'm still waiting for there to be more HTML 4 compliant pages on the web :)
In this case, I'm talking about HTML 5.
OTOH, web specifications seem to be totally outside of the whole "Internet speed" thing, because I'm still waiting for there to be more HTML 4 compliant pages on the web :)
Wednesday, August 12, 2009
Some Comments on Offshore and Outsourcing.
This question came up on Linked In today, and I thought I would post my response to it here for those that don't belong (and if you don't and you are reading this blog, you probably should):
I read the question as one about outsourcing, and I see many responses about off-shoring. I'll give my 2 cents on both, and you can owe me a nickle including tip.
Outsourcing is a way to mitigate risk for mission critical goals. The mitigation is in two forms. The first is, outsourcing to experts provides the perceived safety that the job will get done correctly. The perception is right about half the time (in my experience).
The other form of risk mitigation is the ability to place the blame for any failure on the vendor. As a vendor, I know that the likelihood of this being the reason for outsourcing increases with the number of people involved in the decision.
Off-shoring is a mixed bag. There are some companies that are really good, and some that are not. There are individuals within companies that are really good, and many that are not. In other words, on one level there is no difference between offshore and outsourcing.
On another level, there is the communication gap that is unavoidable due to both cultural and temporal differences. There are some companies that try to offset the temporal differences by having teams that work hours that coincide with US business hours. Anyone who has ever used 24 hour services knows that the best and brightest rarely work in the wee hours, and those that do are still not at the top of their game.
Off shoring works great for both parties far more often if the requirements are crystal clear and fairly static. Otherwise, your mileage will vary. Since the successes are a huge boost to ROI, they are well publicized and very motivating. The much more frequent failures are kept low key to protect careers.
And, as Dennis Miller often said: "But that's just my opinion...I could be wrong"
I read the question as one about outsourcing, and I see many responses about off-shoring. I'll give my 2 cents on both, and you can owe me a nickle including tip.
Outsourcing is a way to mitigate risk for mission critical goals. The mitigation is in two forms. The first is, outsourcing to experts provides the perceived safety that the job will get done correctly. The perception is right about half the time (in my experience).
The other form of risk mitigation is the ability to place the blame for any failure on the vendor. As a vendor, I know that the likelihood of this being the reason for outsourcing increases with the number of people involved in the decision.
Off-shoring is a mixed bag. There are some companies that are really good, and some that are not. There are individuals within companies that are really good, and many that are not. In other words, on one level there is no difference between offshore and outsourcing.
On another level, there is the communication gap that is unavoidable due to both cultural and temporal differences. There are some companies that try to offset the temporal differences by having teams that work hours that coincide with US business hours. Anyone who has ever used 24 hour services knows that the best and brightest rarely work in the wee hours, and those that do are still not at the top of their game.
Off shoring works great for both parties far more often if the requirements are crystal clear and fairly static. Otherwise, your mileage will vary. Since the successes are a huge boost to ROI, they are well publicized and very motivating. The much more frequent failures are kept low key to protect careers.
And, as Dennis Miller often said: "But that's just my opinion...I could be wrong"
Monday, July 27, 2009
Just Like the Good Ole Days
Back when 14.4k baud modems were fast, mice were beige, IBM made PCs, and new software versions were relased annually instead of weekly, software came with useful, intiutive manuals that included tutorials for everything you needed to get up and working.
Other than the ability to take the manual in its binder to the couch to flip through, dog ear and highlight, I was happy to discover a full set of training buried in the doc folder of the Oracle Database install (and many other of their applications, though location may vary).
Even if you don't have the full install, the 2 Day DBA and other really useful documents can be found online, too. The 10.2 version is located here: http://www.oracle.com/pls/db102/portal.all_books.
Other than the ability to take the manual in its binder to the couch to flip through, dog ear and highlight, I was happy to discover a full set of training buried in the doc folder of the Oracle Database install (and many other of their applications, though location may vary).
Even if you don't have the full install, the 2 Day DBA and other really useful documents can be found online, too. The 10.2 version is located here: http://www.oracle.com/pls/db102/portal.all_books.
Installing PMD Plugin for WebLogic Workshop 10gR3
For those that read my Cleaner Code with the PMD Eclipse Plug-In article on Developer.com, you will know that PMD is one of my favorite tools for saving time in code reviews. I recently wanted to review a project built for WebLogic Portal 10.3 and was frustrtated to find that it would not install through the Eclipse updater. At the time I wrote the article, I was unable to find zip install for the more recent PMD versions. Today I found a new location for the old download and unzip install files for PMD on SourceForge today at http://sourceforge.net/projects/pmd/files/, and it seems to work fine when installed with this approach.
Friday, July 24, 2009
WebLogic Workshop 8.x Out Of Memory Fix
A clip from the release notes:
Large Applications May Require Additional Memory Allocation If you are building and testing a large application, WebLogic Workshop may run out of memory, which can cause it to run slowly or shut down. Workaround: You can increase your memory allocation by modifying the Workshop.cfg file, located in the BEA_HOME\weblogic81\workshop\ directory. Add this flag to the command-line arguments: VM flag -Xmx512m
Wednesday, July 22, 2009
WSRP over HTTPS in WLP
Ever run across a problem that sounds real familiar, but you don't remember all the details of the solution? Recently someone was telling me an issue they were having with WSRP where the WSDL when accessed over the HTTPS port still showed the HTTP end point. That is when I experience De Ja Vue (I'v seen this before).
When using HTTPS with WSRP in WLP you must edit the wsrp-producer-config.xml in the producer application:
The bold is where the default value has been changed to true. My conclusion from this is that with WLP your WSRP portlets are either available over HTTP or HTTPS, but not both. I haven't tested this theroy, however, as I have not yet worked on a WSRP project that was not over HTTPS.
When using HTTPS with WSRP in WLP you must edit the wsrp-producer-config.xml in the producer application:
<!-- This element describes the capabilities of this producer. Set the secure attribute to "true" if you require this producer offer any port over SSL. -->
<service-config>
<registration required="true" secure="true"/>
<service-description secure="true"/>
<!-- Set accepts-mime to true to more efficiently process uploaded files when the consumer is a WebLogic Portal. -->
<markup secure="false" rewrite-urls="true" transport="string" accepts-mime="false"/>
<portlet-management required="true" secure="true"/>
</service-config>
The bold is where the default value has been changed to true. My conclusion from this is that with WLP your WSRP portlets are either available over HTTP or HTTPS, but not both. I haven't tested this theroy, however, as I have not yet worked on a WSRP project that was not over HTTPS.
Thursday, July 16, 2009
What is Web 2.0?
I saw this question posted on Linked-In today and thought I would blog my input, especially as I have been tied up with some paid work and haven't been blogging as much lately...
Q: What are the differences between Web 1.0 and Web 2.0?
A: In addition to answers already provided, Web 2.0 is often a battle cry for selling new IT products and services rather than an actual technology. It encompasses AJAX, blogs, wikis, RSS, mash ups, and just about everything else that is currently popular.
What is the same between the web before and Web 2.0 (no one ever referred to Web 1.anything until the Web 2.0 marketing banner was raised) is that these technologies can be a huge benefit when implemented well against a solid design and massive headache if done wrong.
Not all of the technologies are mature yet, which is where the big push to use them can be beneficial. Why? Because as development teams run into the issues and limitations vendors will be pushed to fix them, which will accelerate their maturity.
IMHO :)
Q: What are the differences between Web 1.0 and Web 2.0?
A: In addition to answers already provided, Web 2.0 is often a battle cry for selling new IT products and services rather than an actual technology. It encompasses AJAX, blogs, wikis, RSS, mash ups, and just about everything else that is currently popular.
What is the same between the web before and Web 2.0 (no one ever referred to Web 1.anything until the Web 2.0 marketing banner was raised) is that these technologies can be a huge benefit when implemented well against a solid design and massive headache if done wrong.
Not all of the technologies are mature yet, which is where the big push to use them can be beneficial. Why? Because as development teams run into the issues and limitations vendors will be pushed to fix them, which will accelerate their maturity.
IMHO :)
Friday, July 10, 2009
Speed Up The WebLogic Portal Admin Tool
Large WLP applications usually have many desktops. For speed and convenience, these are often based on a .portal file. You may notice a long delay in the loading of the list of .portal files when creating a new desktop. If you do, you can greatly improve the speed of that list being created with one or two steps. The firs step is to store all of your .portal files in a single location. Many people do this already, which is why for them this will be a one step process. The final step is to add the path in web.xml like this:
This can be found in the performance tuning manual that comes with WLP, but we all know how often we get to read the whole manual :)
<context-param>
<param-name>portalFileDirectory</param-name>
<param-value>/</param-value>
</context-param>
This can be found in the performance tuning manual that comes with WLP, but we all know how often we get to read the whole manual :)
Wednesday, July 8, 2009
If Building Architects Had To Work Like IT Architects...
Confession: I'm buried in trainings and deliverables and recycling some material from my original catch-all blog.
This was forwarded to me today. Normally I would be concerned about copyright violation, but this is way too good not to share. If the unknown author ever contacts me I will happily take it down after thanking the person profusely for the best description of my job I could ever send to a layperson.
Dear Mr. Architect:
Please design and build me a house. I am not quite sure of what I need, so you should use your discretion.
My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdowns for each configuration so that I can arbitrarily pick one at a later time.
Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).
As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)
Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate (among other things) my 1952 Gibson refrigerator.
To assure that you are building the correct house for our entire family, you will need to contact each of my children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any decisions that you make.
Please don't bother me with small details right now. Your job is to develop the overall plans for the house and get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpeting. However, keep in mind that my wife likes blue.
Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.
While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the potential home buyers in my area that they like the features this house has.
I advise you to run up and look at the house my neighbor built last year, as we like it a great deal. It has many things that we feel we also need in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the construction cost.
Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.
You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your ideas and completed plans.
Finally, I consider all of this work a demonstration of your qualifications (or lack thereof) and so of course do not expect to be billed for this.
PS: My wife has just told me that she disagrees with many of the instructions I've given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.
PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case.
This was forwarded to me today. Normally I would be concerned about copyright violation, but this is way too good not to share. If the unknown author ever contacts me I will happily take it down after thanking the person profusely for the best description of my job I could ever send to a layperson.
Dear Mr. Architect:
Please design and build me a house. I am not quite sure of what I need, so you should use your discretion.
My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdowns for each configuration so that I can arbitrarily pick one at a later time.
Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).
As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)
Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate (among other things) my 1952 Gibson refrigerator.
To assure that you are building the correct house for our entire family, you will need to contact each of my children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any decisions that you make.
Please don't bother me with small details right now. Your job is to develop the overall plans for the house and get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpeting. However, keep in mind that my wife likes blue.
Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.
While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the potential home buyers in my area that they like the features this house has.
I advise you to run up and look at the house my neighbor built last year, as we like it a great deal. It has many things that we feel we also need in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the construction cost.
Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.
You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your ideas and completed plans.
Finally, I consider all of this work a demonstration of your qualifications (or lack thereof) and so of course do not expect to be billed for this.
PS: My wife has just told me that she disagrees with many of the instructions I've given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.
PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case.
Monday, July 6, 2009
One AJAX XSS Solution
While there are definitly some cool aspects to AJAX, it also reminds me of the good old days of the browser wars (which seem to be back, albeit more of a Cold War). While my personal preference is to stick to simple solutions that will cause less headaches in production, sometimes you just have to do something the hard way. So far, I've been lucky and have found a simpler solution to the AJAX needs of my clients, but I almost didn't once, which is when I found an article at Solitex Networks on one solution. I'm sure there are other approaches, and would love to see some comments pointing them out.
Monday, June 29, 2009
Best Answer is There is Not Always One...
...Best answer, that is. Which is the gist of my response on the recent LinkedIn question "Adobe Flex vs Java Swing - Looks most similar way of architecture. Any points form your side?". My best answer being:
While I agree in part with the comment about neither being the best choice, the decision should be based on the application audience and the development team skills. If the application is to be a public facing Internet application, Flex support is ubiquitous, making it the superior option (IMHO).
If the application audience is only internal or partner users, the pure Java implementations have some advantages that appeal to some development and/or maintenance teams. OTOH, if the skills and experience don't already exist in-house, Flex is a lower risk path.
Bottom line is usability and ROI, and the ability to deliver those key values depends on your available skill set and distribution channel.
As Dennis Miller often said: "...that's just my opinion. I could be wrong."
Monday, June 22, 2009
Hopefully Much More Next Week
I'm in a training class all week, leaving little time for blogging about the things I'm learning as I learn them. For my reader, please check back next week, in time for the holiday ;)
Friday, June 19, 2009
Oracle JDeveloper 11g: RTFM
After so many years of finding better answers through Google or Dev2Dev (moment of silence), I rarely use the help menu of applications anymore. Yesterday I was having trouble with one of the JDeveloper wizards. I searched Google, I searched OTN, I posted to discussion lists. No answer. Desperate to get past this issue, I opened the Help menu. I still didn't find what I was looking for (I solved that by experimentation and guess work), but I did find all of the training material listed right there.

This would have saved me days of navigating around OTN, where I did not find the training I needed that was right in the IDE all the time.
Interesting lesson learned, and the first application of the alternative definition of RTFM I read recently: Read The Fancy Manual
This would have saved me days of navigating around OTN, where I did not find the training I needed that was right in the IDE all the time.
Interesting lesson learned, and the first application of the alternative definition of RTFM I read recently: Read The Fancy Manual
Wednesday, June 17, 2009
Is There a Prize with That?
I just started answering questions on LinkedIn lately, and got a Best Answer yesterday on a question about Doubt in handling Exceptions in Java*. Before the Internet, everyone had 15 minutes of fame. Now it is more like 15 nanoseconds :)
*Requires LinkedIn account to view
*Requires LinkedIn account to view
Thursday, June 11, 2009
WLP Sessions and Porlets in Shared Libraries
Awhile back, I ran into an issue where session data was being lost between requests in a WebLogic Portal project. As it only occurred in a clustered environment, it was obvious that the value was not being persisted, even though persistence was set properly with
After much frustration, someone on the team ran across an additional setting for the session-descriptor node: sharing-enabled. In the case where a portlet is from a shared library, the persistence does not work unless sharing-enabled is set to true.
In hindsight, this behavior makes some sense, in that most portlets that are distributed as shared libraries by vendors do not require session values. However, in the case where a shared library is created by an application team to reuse portlets across portals where WSRP is not practical, the need to share sessions may arise, and now you know how to fix it.
For other deployment descriptor options, see http://download.oracle.com/docs/cd/E12840_01/wls/docs103/webapp/weblogic_xml.html
<wls:session-descriptor>
<wls:persistent-store-type>replicated_if_clustered</wls:persistent-store-type>
</wls:session-descriptor>
After much frustration, someone on the team ran across an additional setting for the session-descriptor node: sharing-enabled. In the case where a portlet is from a shared library, the persistence does not work unless sharing-enabled is set to true.
<wls:session-descriptor>
<wls:persistent-store-type>replicated_if_clustered</wls:persistent-store-type>
<wls:sharing-enabled>true</wls:sharing-enabled>
</wls:session-descriptor>
In hindsight, this behavior makes some sense, in that most portlets that are distributed as shared libraries by vendors do not require session values. However, in the case where a shared library is created by an application team to reuse portlets across portals where WSRP is not practical, the need to share sessions may arise, and now you know how to fix it.
For other deployment descriptor options, see http://download.oracle.com/docs/cd/E12840_01/wls/docs103/webapp/weblogic_xml.html
Wednesday, June 10, 2009
Good Thread on White Space in JSPs
While it is tempting to quickly skim an blog entry for the information I'm seeking at the time, a recent find on dealing with white space with JSPs reminded me that there is a darn good reason most blogs have a comment feature.
The thread I'm talking about is Trim Spaces in Your JSP at Raible Designs. Fortunately, my paranoia paid off, and I did not try this setting blindly on the project where I was looking for such an answer (and have since rolled off). I almost did, but decided not to because I knew I would not be around to support the change, and that whoever I told about it may forget it. As it is a performance enhancement and the application had some peformance issues (too many cooks in the presentation layer kitchen IMHO), it was not as easy of a call as it may seem.
The con that comes up in the comments on that post is that it wipes all white space between tags. If I were the only person developing on the project, or if was a small team where I knew for certain that only experience JSP developers were working on the JSPs, I'd still feel safe. This is because if a space has to be in a page between two dynamic parameters, the experienced JSP developer will use an entity code rather than just a blank space.
There is also a comment in the thread about how to cut down white space in a build file. That was actually the type of solution I was seeking at the time (and missed at the time). I would have to experiment with the solution before I suggested it, but it looks like what I wanted.
The thread I'm talking about is Trim Spaces in Your JSP at Raible Designs. Fortunately, my paranoia paid off, and I did not try this setting blindly on the project where I was looking for such an answer (and have since rolled off). I almost did, but decided not to because I knew I would not be around to support the change, and that whoever I told about it may forget it. As it is a performance enhancement and the application had some peformance issues (too many cooks in the presentation layer kitchen IMHO), it was not as easy of a call as it may seem.
The con that comes up in the comments on that post is that it wipes all white space between tags. If I were the only person developing on the project, or if was a small team where I knew for certain that only experience JSP developers were working on the JSPs, I'd still feel safe. This is because if a space has to be in a page between two dynamic parameters, the experienced JSP developer will use an entity code rather than just a blank space.
There is also a comment in the thread about how to cut down white space in a build file. That was actually the type of solution I was seeking at the time (and missed at the time). I would have to experiment with the solution before I suggested it, but it looks like what I wanted.
Labels:
file size,
HTML,
J2EE,
JSP,
performance,
White Space
Tuesday, June 9, 2009
My New 1000 GB (1TB) Drive
I've been wanting a 1 TB drive since Seagate started selling them at a reasonable price. Besides being budget conscious in the current economy, I also got paranoid with all the reports of problems. I trusted Seagate to fix them eventually, but it still left me with some hesitation. I finally got to the point where every time I looked at my main and back up drive free space, I was getting concerned (I like to have 50% free). Then New Egg had a sale. I hemmed and hawed for a couple of days and finally bought the Western Digital Caviar Green WD10EADS 1TB. It is cheaper than the Caviar Black, though not by much. Reading the reviews, the price difference has to do with speed. I also read the reviews of unhappy customers to see what the complaints were, and the only problem with the Green was speed. The other drives had issues with noise, or failing within a short period of time. I'm in agreement with most reviewers, in that a drive that big is only for storage, so speed is not as important. Good thing, too, because the drive is not fast. It is quite, though, which is appreciated in my home office where there are two towers and one laptop running all the time with a combined 6 to 7 drives running (depending on if the portable is plugged into the laptop) and 14 fans running. I look forward to summer just so my window A/C will drown out the noise.
Installation was a breeze, which is good because the OEM one comes with no instructions. No I just have to stay patient and test the drive for a couple of weeks before I wipe the 500 GB Seagate it is replacing and move it up to my main drive.
Installation was a breeze, which is good because the OEM one comes with no instructions. No I just have to stay patient and test the drive for a couple of weeks before I wipe the 500 GB Seagate it is replacing and move it up to my main drive.
Monday, June 8, 2009
A Tutorial by Any Other Name...
It may be just because they are really good at SEO, but everytime I'm looking for a quick (free) tutorial on something I want to learn about or need a refresher, RoseIndia usually comes up. I think the reason for the quality of most of their tutorials is that they don't create them all themselves. This is not immediatly obvious, unless you keep looking at other search results for tutorials and find the same one posted in 20 other places. Still, they are good aggregtor for technical tutorials, and for that I definitly recommend bookmarking them.
Wednesday, June 3, 2009
Quick Cookie Click
Any browser that supports JavaScript will pop an alert with the current cookies from the domain currently displayed if you enter this in the location bar:
javascript:alert(document.cookie)
Handy if you don't work with JavaScript or cookies enough to have a web developer tool bar installed.
javascript:alert(document.cookie)
Handy if you don't work with JavaScript or cookies enough to have a web developer tool bar installed.
Tuesday, June 2, 2009
The Best Web Developer Extension for FireFox
The only thing this tool lacks is an IE version. If you know of a better (free) one, please, please, please tell me.
Web Developer
Web Developer
Monday, June 1, 2009
Catch a Wave
Reading The enterprise implications of Google Wave over on ZDNet, I find the article really well done. I do have a nit to pick with one comment:
My observation has been that most computing technology innovations start in the business market and flounder around until consumers catch on to it. Then again, he may just be saying that for his set up, as his next sentence is:
"With Google’s tendency to emphasize the consumer world first and the enterprise later, it’s also valid to ask if Wave will really have much impact on businesses."
My observation has been that most computing technology innovations start in the business market and flounder around until consumers catch on to it. Then again, he may just be saying that for his set up, as his next sentence is:
"Interestingly, you might be surprised at some of the answers, so let’s take a look."
Latest Developer.com Article
When my articles appear on Developer.com, they have 120 days exclusive rights. Rather than have readers wait four months, I post a link to the article here (when I remember to).
The latest is 10 Things You Should Know About WebLogic Server 10.3, handy if you are considering a move to the latest version of WLS.
The latest is 10 Things You Should Know About WebLogic Server 10.3, handy if you are considering a move to the latest version of WLS.
Sunday, May 31, 2009
Tables Vs CSS Layouts
I'm in the midst of customizing the themes for my blogs. Now, if I had oodles of time, I would build my own theme from the ground up. I don't have a nano-oodle, let alone multiple oodles, so I'm just hacking up the default theme.
No matter how well designed a web application is, it is always hard to step into someone else's work and make changes that perfectly dovetail the original source. Not impossible, just hard. So, to keep a long story from getting way too long (it is impossible to make a long story short, because it is always too late by the time the thought occurs), I found myself using tables to modify the layouts (gasp!).
Using tables for something other than tabular data is something I avoid, but I do it anyways sometimes. In the case of the theme on this blog, it was a matter of the fastest way to modify an existing layout that I did not design. If I had more time, I'm sure I could have gotten past the bugs that cropped up when I tried modifying the CSS instead. If I had built it myself from the ground up, I could definitly have avoided the table approach because I am careful to avoid redundant classes and I document the things that aren't glaringly obvious because I know I will forget later if I don't. But, since neither of these were the case, I used the table. The momentary twinge of guilt passed as soon as I moved on to something else that caught my over-burdened attention. Until I ran across a job posting that stated something to the effect of "If you use tables for layout, do not apply". Which got the question stuck in my mind "what is the truth about using tables or CSS for layout"?
I've been reading about the topic for six or seven years now, so it didn't surprise me that a search on "tables vs divs" in Google returned "about 15,400,000" results in 0.41 seconds. What did surprise me was that the first six results were 100% relevant, and that the general consensus of the first ten results agreed with my thoughts on the topic, which are:
If this sparks folks to register and comment, I will be happy to elaborate further.
No matter how well designed a web application is, it is always hard to step into someone else's work and make changes that perfectly dovetail the original source. Not impossible, just hard. So, to keep a long story from getting way too long (it is impossible to make a long story short, because it is always too late by the time the thought occurs), I found myself using tables to modify the layouts (gasp!).
Using tables for something other than tabular data is something I avoid, but I do it anyways sometimes. In the case of the theme on this blog, it was a matter of the fastest way to modify an existing layout that I did not design. If I had more time, I'm sure I could have gotten past the bugs that cropped up when I tried modifying the CSS instead. If I had built it myself from the ground up, I could definitly have avoided the table approach because I am careful to avoid redundant classes and I document the things that aren't glaringly obvious because I know I will forget later if I don't. But, since neither of these were the case, I used the table. The momentary twinge of guilt passed as soon as I moved on to something else that caught my over-burdened attention. Until I ran across a job posting that stated something to the effect of "If you use tables for layout, do not apply". Which got the question stuck in my mind "what is the truth about using tables or CSS for layout"?
I've been reading about the topic for six or seven years now, so it didn't surprise me that a search on "tables vs divs" in Google returned "about 15,400,000" results in 0.41 seconds. What did surprise me was that the first six results were 100% relevant, and that the general consensus of the first ten results agreed with my thoughts on the topic, which are:
- The approach that is the least complicated is preferred over the one that is the most complicated
- The semantic web is yet to come, hopefully will come, and it is better to use CSS for layout than tables when it does get here
- If the layout is overly complex, the semantics will be lost regardless which approach is used
- There is no value in re-writing your code simply to eliminate tables in layouts, while it is valuable to update to CSS if you need to re-write anyway
- The best choice depends on the goal of the page
If this sparks folks to register and comment, I will be happy to elaborate further.
Labels:
CSS,
DHTML,
DIV,
HMTL and CSS,
HTML,
layout,
semantic web
Friday, May 29, 2009
GIS
For those smarter or more up on acronyms than I, ignore this post.
As posted at my parent blog, I was reading this SF story last night in Analog. There was a reference to GIS, which I've seen around alot lately on the job boards but haven't bothered to look up. For the curious, it stands for Geographic information system.
As posted at my parent blog, I was reading this SF story last night in Analog. There was a reference to GIS, which I've seen around alot lately on the job boards but haven't bothered to look up. For the curious, it stands for Geographic information system.
Consider This When Planning Web Services
As soon as Web Services started getting buzz I was both excited and concerned. Interoperability and reuse are great things. Shorter time to market is a huge benefit. Bandwidth is limited. That last was never brought up by the sales people taking clients to $1000 dinners while pitching $30,000 web service platforms with $1,000,000 support contracts.
Web services are still a great way to expose legacy systems to myriad clients across the enterprise. Where they become expensive is when they are built with only one or two expected clients to support a (myopic) SOA vision. Especially when many of the new services being built are only aggregations of other services that will generally be a specialized interface to business logic required by a limited number of clients.
If an architecture includes web services, a list of clients must be part of support case or the design is simply buzz word bingo.
This technical rant was prompted by a developer.com article that has way to much code to share with the folks who will often make the final decision, but may get their advisers excited enough to explain it to them.
Web services are still a great way to expose legacy systems to myriad clients across the enterprise. Where they become expensive is when they are built with only one or two expected clients to support a (myopic) SOA vision. Especially when many of the new services being built are only aggregations of other services that will generally be a specialized interface to business logic required by a limited number of clients.
If an architecture includes web services, a list of clients must be part of support case or the design is simply buzz word bingo.
This technical rant was prompted by a developer.com article that has way to much code to share with the folks who will often make the final decision, but may get their advisers excited enough to explain it to them.
Tuesday, May 26, 2009
Good Article on WebLogic Deployment Plans
In WLS, deployment plans let you change the values in deployment descriptors at deployment time. This is really handy when you want to move your deployment archives from one environment to the next (i.e., from Staging to Production) and need different settings based on the environment. Maxence Button blogged an excellent how-to at http://m-button.blogspot.com/2008/08/how-to-use-deployment-plan.html
Monday, May 25, 2009
Favicon Generator
I rememeber what a pain this was the first time, and the next to last time, where I hadn't done it in years. Today I found an site that will generate one for free and tells you how to use it. Must have bookmark: DeGraeve.com Favicon Generator.
Google Maps Gets Even Cooler
Apparently they are just starting this new bit where they show the actual buildings on the street maps and camera shots. It doesn't show up everywhere, but it does in Boston. See for yourself here: http://www.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=boston&sll=35.229548,-80.834937&sspn=0.001597,0.002865&ie=UTF8&ll=42.358845,-71.05559&spn=0.005779,0.011458&z=17
Cross Domain AJAX on FireFox…Sort Of
At least, how to run it locally. Explained well at http://blog.dirolf.com/2007/06/enabling-cross-domain-ajax-in-firefox.html
Friday, May 22, 2009
Keep Your Ego in Check
I have to point to this just for the title: Never Eat Anything Bigger Than Your Head. Just wish I could remember where I first heard that phrase...
Anyway, it is a good post about sizing stories in Agile.
Anyway, it is a good post about sizing stories in Agile.
Thursday, May 21, 2009
Couple of Twitter Notes
Yesterday an acquaintance began following me on Twitter, and I found that they were using Twitter Job Search. It's in beta, and I wish I had time to contribute as it looks promising.
It appears that some companies are following people as a marketing approach, which is the only reason I can think of for an eBusiness-in-a-box company to start following me that had no job postings. Their Twitter page did remind me that I wanted to customize my Twitter page as I have noticed some folks have done, and I found this handy blog post on how to.
It appears that some companies are following people as a marketing approach, which is the only reason I can think of for an eBusiness-in-a-box company to start following me that had no job postings. Their Twitter page did remind me that I wanted to customize my Twitter page as I have noticed some folks have done, and I found this handy blog post on how to.
Wednesday, May 20, 2009
Got Ebay?
With all the recent press (Craigslist drops prostitutes, Craigslist CEO demands apology) about craigslist the last few days, eBay is up almost 10%. According to Google Finance, eBay owns about 25% of craigslist.
Microsoft Undoes It Again
Remember when web standards were supposed to end cross browser development issues? Now you can not share documents the same way, according to this ZDNet article.
Tuesday, May 19, 2009
Useful Google API Article Series
Developer.com has a series on Google integration with PHP at http://www.developer.com/services/article.php/3680076.
I suppose this would be a good time to grouse that they never gave my two series (WSRP and POI) a page of their own :)
Between the York District Boy Scouts Spring Wateree Campout and a cold, I have not been posting much lately, so this a is re-tread from Frequently Unasked Questions.
I suppose this would be a good time to grouse that they never gave my two series (WSRP and POI) a page of their own :)
Between the York District Boy Scouts Spring Wateree Campout and a cold, I have not been posting much lately, so this a is re-tread from Frequently Unasked Questions.
Labels:
Google,
Open Source,
PHP,
POI,
Programming,
WSRP
Thursday, May 14, 2009
Delicious Deviation
If you are like me (and I am realistic to know that the odds are really against that), you could care less about visitors to your blog that have Javascript disabled. There is really just no reason for it, with 99.99% of browsers supporting it. So, if you want to save a few bytes and just have a clickable icon for your Delicious tag, here is my version:
<img id="DeliciousIcon1" title="Bookmark this on Delicious"
src="http://static.delicious.com/img/delicious.small.gif"
height="10" width="10" alt="Bookmark this on Delicious"
style="cursor: pointer; vertical-align: middle"
onclick="window.open('http://delicious.com/save?v=5&noui&jump=close&url='+encodeURIComponent('<?php the_permalink() ?>')+'&title='+encodeURIComponent('<?php the_title() ?>'),'delicious', 'toolbar=no,width=550,height=550'); return false;" />
<img id="DeliciousIcon1" title="Bookmark this on Delicious"
src="http://static.delicious.com/img/delicious.small.gif"
height="10" width="10" alt="Bookmark this on Delicious"
style="cursor: pointer; vertical-align: middle"
onclick="window.open('http://delicious.com/save?v=5&noui&jump=close&url='+encodeURIComponent('<?php the_permalink() ?>')+'&title='+encodeURIComponent('<?php the_title() ?>'),'delicious', 'toolbar=no,width=550,height=550'); return false;" />
Wednesday, May 13, 2009
It's Like It's 1998 Again
Adrian Kingsley-Hughes blog post on ZDNet today reminds me of when Windows 95 users where expecting the next service pack and instead got an ad for an upgrade.
Buying Vista is the biggest mistake I have made since buying Circuit City stock.
Buying Vista is the biggest mistake I have made since buying Circuit City stock.
Monday, May 11, 2009
How Not to Succeed with Agile
Originally published at developer.com
The purposely provocative title is meant to capture the attention of people with two opposing mindsets. The first are the proponents of agile methods who will want to pick apart any arguments against their preferred approach. The second are those who oppose agile and are looking for justification for their concerns. The goal of this article is to reduce the opposition between these two schools of thought, and to provide some food for thought to those who are undecided.
The truth is development projects following agile methodologies have failed. Projects following waterfall and RUP have also failed. Just as the cliché that one should not judge a book by its cover is often true (I missed out on the intellectual pleasure of Robert Heinlein’s Friday for many years due to that primitive prejudice), one should also avoid drawing a conclusion about a topic based on the title alone (The Art of War is more about how not to fight).
We will not go into deep detail of agile methodologies today. There are too many to cover adequately in a single reading, and the specifics of these methodologies do not have a direct impact on why agile projects succeed or fail. Agile is as much a way of thinking about projects as it is a set of tools that can be applied to projects, and the aspects that make up successful thinking can apply to agile and non-agile methodologies.
Both definitions of agile in one online dictionary include the word “quick”. The word agile evokes thoughts of athletic prowess and graceful, fast feline predators. It is not surprising the people who chose to adopt agile methodologies for the first time do so when facing a tight deadline. Perhaps choosing a methodology by its name will be the new cliché.
People who have followed agile methodologies for multiple projects will tell you that they provide quick results, and can show you artifacts that prove it. What they may have forgotten (or simply neglected to mention) is that successful agile projects have a few advantages to be successful with agile methodologies.
For an IT shops’ first agile project to be successful, the project must be the right project for that shop to adopt agile techniques. The project should be small, in both time frame and team size. The managers of the project must be willing to either adopt agile deliverables as they are, or adapt their method of measurement. Most importantly, the project team either needs to have enough members already experienced in agile or be given the latitude to get through the learning curve.
Agile methodologies rely on continuous and open communication between all levels of stake holders. For traditional waterfall groups, it is unheard of for a developer to contact a business sponsor or client to find out what is meant by a particular requirement description. In an agile project, the ability to do so can mean the difference between success and failure.
Agile methodologies can be used successfully to deliver a large project, but not by a team that is learning to use these techniques for the first time. Large projects often include many team members, at multiple locations. An IT shop can grow a small agile team to a large, distributed team over a few projects, but it is likely to be disappointing to try to assemble a large team from scratch, even if all of the members are experience in agile. Like many adjectives, agile has different meanings to different people in different contexts, and two highly experience agile project members could have entirely opposing approaches. Large agile teams must be grown organically rather than assembled randomly. These caveats to applying agile projects are most likely the root of the general consensus that agile is not appropriate for large projects. Perhaps this caution is a good idea when introducing agile methodologies to a team for the first time.
In describing the ingredients of projects that can succeed with agile above, it is important to note that the different modal operators of probability used are chosen specifically, rather than simply to provide variety in wording. Project managers new to agile must be willing to adapt. Teams new to the agile approach as a team needs to either have enough members with agile experienced or be given the opportunity to stumble and learn. Communication across stake holders can impact results. There are exceptions, such as when those with roles that include being the translator of business requirements to technical requirements have good relations and communications with business and development and are highly competent in those communications.
This section began with a reference to a dictionary definition. In addition to the current English meaning of the word, most dictionaries include the history of a word, its etymology. At that same reference link, the etymology of agile is given as “from Latin agilis, from agere to drive, act”. So, apparently the meaning of agile in the English language evolved from its origins to include the notion of “quick”. Agile methodologies can evolve within an organization to be what we want them to be, though it is unlikely that they can be exactly what is desired the first time out.
The introduction mentioned that there are opposing mindsets about agile. It also included a reference to The Art of War, and these are not coincidences. An agile project team with members of both camps has two strikes against it from the start. It only takes one more strike to be out.
Many proponents of agile tend to be over zealous in their belief of the superiority of their preferred agile methodologies. While their enthusiasm may win support from the undecided, it can also cause those opposed to agile methodologies to push back even harder. It can also frighten those who are participating in an agile project for the first time, as agile methodologies are very different from waterfall approaches and change causes anxiety for many. Where patient mentoring will frequently overcome FUD (Fear, Uncertainty and Doubt), ignoring the FUD of others generally results in greater FUD.
Most opponents of agile are against it because of FUD. Sometimes rightly so, as agile is not a panacea and is not the perfect methodology for every combination of projects and teams. Those most opposed to agile methodologies are non-developer team members. Experienced waterfall project managers and analysts are highly trained in creating complete definitions of deliverables and measuring progress towards those deliverables with specific tools. While agile is still a measurable methodology, the measurements are defined as the project progresses instead of up front. This can be too far outside of the comfort zone of some people. And people who are uncomfortable will often do whatever it takes to become comfortable again. For some, that is achieved by adapting and learning, i.e., becoming agile themselves. For others, the approach is to make every effort to bring things back to the way they are used to. These latter individuals most likely do not do it consciously, but they will sabotage an agile project. How? By doing exactly as they are trained. By trying to capture every minute detail for a story definition rather than outlining it and providing feedback during the daily testing. By trying to fit too many features into a single iteration. By thinking a milestone was missed because an iteration did not deliver all of the features planned. By not delivering requirements that are completely defined because the due date for the requirement has not yet arrived on the calendar. By running an agile project in a waterfall mentality. In short, by not being part of the agile process by being agile themselves.
To repeat, those who oppose agile processes and sabotage agile projects most likely do not do it consciously. If everyone isn’t onboard with the agile process at the beginning of the project, it can still succeed. If everyone isn’t onboard with agile by the end of the project, that project will most likely have been a failure. If everyone pulls their own weight, but pull in a different direction, something is bound to come apart.
Those who have delivered successful agile projects have good reason to be confident in their approach. Successful agile projects result in solid software, often delivered either under-budget or with more features than originally projected. The iterative approach of providing rapid, demonstrable deliverables quickly builds enthusiasm for both the clients and the developers. Those who began the agile project with FUD and then learned to adapt and adopt new processes are those who become the biggest supporters of agile. It is important that they remember that they had their doubts at first if they are to convince others who suffer FUD that they, too, can become successful agile project members.
Hopefully you realize that this section has many redundancies to the first section. Project deliverables may be software and documentation, but it is people who deliver them.
Waterfall projects are successful when there is a rigid adherence to process. To some, that rigid adherence may be the only ingredient they are aware of. They may not acknowledge that the project also required the experience and knowledge to create an accurate project plan with achievable milestones.
In agile projects, rigid adherence to process is a key ingredient to failure. Agile is made up of many different processes that can be adopted, combined, added, dropped and modified as needed. First-time agile projects are prone to the mistake of choosing their processes and sticking to them even when they don’t work.
A perfect example is Test Driven Development (TDD). In TDD, automated test procedures are written first, then the development is done and tested continuously. This is a great approach to ensure functional quality. It works perfect for the Control layer of an MVC architecture, for example. However, for the view layer of a web project, it can result in deliverable falling out of synch as it takes much longer to write tests for web pages than it does to write the page itself.
Daily stand up meetings are an excellent communication tool. Run properly, they provide an excellent benefit. However, if one or more of the unconscious saboteurs join in (or, as is often the case, lead) these meetings, they can become a key factor in iteration failure. Choosing to make the stand up every other day or weekly while leveraging instant messaging can put an iteration back on track if the daily stand up is detracting from productivity.
Another fallacy held by extreme supporters and detractors of agile is that it cannot be combined with waterfall. Nothing could be further from the truth. An agile development team that begins prototyping based on the initial, high-level requirements of a waterfall project will be able to demonstrate their achievements earlier in the development stage and get immediate feedback from clients. Because another fallacy about waterfall is that all of the requirements are defined before development begins. Change orders are part of the waterfall process, and it is very rare they aren’t used. The earlier the change order occurs, the better the chances of success are, and agile development processes within a waterfall project facilitate these early changes in direction that lead to improved deliverables.
Agile processes work if implemented in an agile manner and followed by people willing to be agile.
Why do agile projects fail? When agile methodologies are not used in a project labeled as agile. Whether you consider the root of the word agile as meaning to take action and get immediate results, or the modern meaning of quick deliverables, simply using the word agile is not enough to take action or be quick about it. Nor is simply taking quick action truly agile, unless it is done with purpose and support. Many of the most successful agile projects I have participated in were not labeled agile; we simply followed agile methodologies as a development team and met waterfall deliverables, usually ahead of schedule.
Agile projects do succeed, and agile methodologies are designed for success. Like any tool, if it is not used properly it will not accomplish what it is designed for, and can cause actual damage. If you have a fly to swat, a fly swatter works well… unless it is tied to a Buick.
The Wikipedia entry on Agile at http://en.wikipedia.org/wiki/Agile_software_development contains many disclaimers, making it more honest than most references found during the writing of this article.
A short list of SDLC approaches can be found at http://testdog.com/knowhow/Sorting%20Out%20SDLC.html. While there are many, many other sites about various SDLC approaches, this one seemed to have the least agenda and the most variety.
Why Agile Projects Fail
The purposely provocative title is meant to capture the attention of people with two opposing mindsets. The first are the proponents of agile methods who will want to pick apart any arguments against their preferred approach. The second are those who oppose agile and are looking for justification for their concerns. The goal of this article is to reduce the opposition between these two schools of thought, and to provide some food for thought to those who are undecided.
The truth is development projects following agile methodologies have failed. Projects following waterfall and RUP have also failed. Just as the cliché that one should not judge a book by its cover is often true (I missed out on the intellectual pleasure of Robert Heinlein’s Friday for many years due to that primitive prejudice), one should also avoid drawing a conclusion about a topic based on the title alone (The Art of War is more about how not to fight).
We will not go into deep detail of agile methodologies today. There are too many to cover adequately in a single reading, and the specifics of these methodologies do not have a direct impact on why agile projects succeed or fail. Agile is as much a way of thinking about projects as it is a set of tools that can be applied to projects, and the aspects that make up successful thinking can apply to agile and non-agile methodologies.
The Project
Both definitions of agile in one online dictionary include the word “quick”. The word agile evokes thoughts of athletic prowess and graceful, fast feline predators. It is not surprising the people who chose to adopt agile methodologies for the first time do so when facing a tight deadline. Perhaps choosing a methodology by its name will be the new cliché.
People who have followed agile methodologies for multiple projects will tell you that they provide quick results, and can show you artifacts that prove it. What they may have forgotten (or simply neglected to mention) is that successful agile projects have a few advantages to be successful with agile methodologies.
For an IT shops’ first agile project to be successful, the project must be the right project for that shop to adopt agile techniques. The project should be small, in both time frame and team size. The managers of the project must be willing to either adopt agile deliverables as they are, or adapt their method of measurement. Most importantly, the project team either needs to have enough members already experienced in agile or be given the latitude to get through the learning curve.
Agile methodologies rely on continuous and open communication between all levels of stake holders. For traditional waterfall groups, it is unheard of for a developer to contact a business sponsor or client to find out what is meant by a particular requirement description. In an agile project, the ability to do so can mean the difference between success and failure.
Agile methodologies can be used successfully to deliver a large project, but not by a team that is learning to use these techniques for the first time. Large projects often include many team members, at multiple locations. An IT shop can grow a small agile team to a large, distributed team over a few projects, but it is likely to be disappointing to try to assemble a large team from scratch, even if all of the members are experience in agile. Like many adjectives, agile has different meanings to different people in different contexts, and two highly experience agile project members could have entirely opposing approaches. Large agile teams must be grown organically rather than assembled randomly. These caveats to applying agile projects are most likely the root of the general consensus that agile is not appropriate for large projects. Perhaps this caution is a good idea when introducing agile methodologies to a team for the first time.
In describing the ingredients of projects that can succeed with agile above, it is important to note that the different modal operators of probability used are chosen specifically, rather than simply to provide variety in wording. Project managers new to agile must be willing to adapt. Teams new to the agile approach as a team needs to either have enough members with agile experienced or be given the opportunity to stumble and learn. Communication across stake holders can impact results. There are exceptions, such as when those with roles that include being the translator of business requirements to technical requirements have good relations and communications with business and development and are highly competent in those communications.
This section began with a reference to a dictionary definition. In addition to the current English meaning of the word, most dictionaries include the history of a word, its etymology. At that same reference link, the etymology of agile is given as “from Latin agilis, from agere to drive, act”. So, apparently the meaning of agile in the English language evolved from its origins to include the notion of “quick”. Agile methodologies can evolve within an organization to be what we want them to be, though it is unlikely that they can be exactly what is desired the first time out.
The People
The introduction mentioned that there are opposing mindsets about agile. It also included a reference to The Art of War, and these are not coincidences. An agile project team with members of both camps has two strikes against it from the start. It only takes one more strike to be out.
Many proponents of agile tend to be over zealous in their belief of the superiority of their preferred agile methodologies. While their enthusiasm may win support from the undecided, it can also cause those opposed to agile methodologies to push back even harder. It can also frighten those who are participating in an agile project for the first time, as agile methodologies are very different from waterfall approaches and change causes anxiety for many. Where patient mentoring will frequently overcome FUD (Fear, Uncertainty and Doubt), ignoring the FUD of others generally results in greater FUD.
Most opponents of agile are against it because of FUD. Sometimes rightly so, as agile is not a panacea and is not the perfect methodology for every combination of projects and teams. Those most opposed to agile methodologies are non-developer team members. Experienced waterfall project managers and analysts are highly trained in creating complete definitions of deliverables and measuring progress towards those deliverables with specific tools. While agile is still a measurable methodology, the measurements are defined as the project progresses instead of up front. This can be too far outside of the comfort zone of some people. And people who are uncomfortable will often do whatever it takes to become comfortable again. For some, that is achieved by adapting and learning, i.e., becoming agile themselves. For others, the approach is to make every effort to bring things back to the way they are used to. These latter individuals most likely do not do it consciously, but they will sabotage an agile project. How? By doing exactly as they are trained. By trying to capture every minute detail for a story definition rather than outlining it and providing feedback during the daily testing. By trying to fit too many features into a single iteration. By thinking a milestone was missed because an iteration did not deliver all of the features planned. By not delivering requirements that are completely defined because the due date for the requirement has not yet arrived on the calendar. By running an agile project in a waterfall mentality. In short, by not being part of the agile process by being agile themselves.
To repeat, those who oppose agile processes and sabotage agile projects most likely do not do it consciously. If everyone isn’t onboard with the agile process at the beginning of the project, it can still succeed. If everyone isn’t onboard with agile by the end of the project, that project will most likely have been a failure. If everyone pulls their own weight, but pull in a different direction, something is bound to come apart.
Those who have delivered successful agile projects have good reason to be confident in their approach. Successful agile projects result in solid software, often delivered either under-budget or with more features than originally projected. The iterative approach of providing rapid, demonstrable deliverables quickly builds enthusiasm for both the clients and the developers. Those who began the agile project with FUD and then learned to adapt and adopt new processes are those who become the biggest supporters of agile. It is important that they remember that they had their doubts at first if they are to convince others who suffer FUD that they, too, can become successful agile project members.
Hopefully you realize that this section has many redundancies to the first section. Project deliverables may be software and documentation, but it is people who deliver them.
The Process
Waterfall projects are successful when there is a rigid adherence to process. To some, that rigid adherence may be the only ingredient they are aware of. They may not acknowledge that the project also required the experience and knowledge to create an accurate project plan with achievable milestones.
In agile projects, rigid adherence to process is a key ingredient to failure. Agile is made up of many different processes that can be adopted, combined, added, dropped and modified as needed. First-time agile projects are prone to the mistake of choosing their processes and sticking to them even when they don’t work.
A perfect example is Test Driven Development (TDD). In TDD, automated test procedures are written first, then the development is done and tested continuously. This is a great approach to ensure functional quality. It works perfect for the Control layer of an MVC architecture, for example. However, for the view layer of a web project, it can result in deliverable falling out of synch as it takes much longer to write tests for web pages than it does to write the page itself.
Daily stand up meetings are an excellent communication tool. Run properly, they provide an excellent benefit. However, if one or more of the unconscious saboteurs join in (or, as is often the case, lead) these meetings, they can become a key factor in iteration failure. Choosing to make the stand up every other day or weekly while leveraging instant messaging can put an iteration back on track if the daily stand up is detracting from productivity.
Another fallacy held by extreme supporters and detractors of agile is that it cannot be combined with waterfall. Nothing could be further from the truth. An agile development team that begins prototyping based on the initial, high-level requirements of a waterfall project will be able to demonstrate their achievements earlier in the development stage and get immediate feedback from clients. Because another fallacy about waterfall is that all of the requirements are defined before development begins. Change orders are part of the waterfall process, and it is very rare they aren’t used. The earlier the change order occurs, the better the chances of success are, and agile development processes within a waterfall project facilitate these early changes in direction that lead to improved deliverables.
Agile processes work if implemented in an agile manner and followed by people willing to be agile.
Conclusion
Why do agile projects fail? When agile methodologies are not used in a project labeled as agile. Whether you consider the root of the word agile as meaning to take action and get immediate results, or the modern meaning of quick deliverables, simply using the word agile is not enough to take action or be quick about it. Nor is simply taking quick action truly agile, unless it is done with purpose and support. Many of the most successful agile projects I have participated in were not labeled agile; we simply followed agile methodologies as a development team and met waterfall deliverables, usually ahead of schedule.
Agile projects do succeed, and agile methodologies are designed for success. Like any tool, if it is not used properly it will not accomplish what it is designed for, and can cause actual damage. If you have a fly to swat, a fly swatter works well… unless it is tied to a Buick.
Additional Reference Links
The Wikipedia entry on Agile at http://en.wikipedia.org/wiki/Agile_software_development contains many disclaimers, making it more honest than most references found during the writing of this article.
A short list of SDLC approaches can be found at http://testdog.com/knowhow/Sorting%20Out%20SDLC.html. While there are many, many other sites about various SDLC approaches, this one seemed to have the least agenda and the most variety.
Subscribe to:
Comments (Atom)