Thursday
Jan092014

The Best New WebBrowser

Ok this might be a catchy headline but I have been stating this for sometime and now I have decided to call it out in print.

Your iPhone and Android device, why you say? Well it is because most of your always connected devices have a new type of 'smart hyperlink' © which equals your connected application you downloaded or have pre-loaded on your device.

The popular format to transmit content back and forth to your new browser is JSON, how this data is displayed is dependent on your specific browsers. An example would be Google Calendar this specific browser presents data in one specific view and you smart hyperlink © when clicked launches that application or smart browser and displays the data in a known a familiar calendar view to you.

People can say well there are many games that do not need to be connected after downloaded to be played, which is correct which I say these games are only cached smart interactive views which if you have angry birds or other applications see that the cached games gets updated almost daily.

So this makes me very excited about the future and why I have been into mobile handhelds since the Palm 7 with the very cool flip antenna which for some reason was not a chic magnet.

Monday
Jan062014

The new peer programming (Google Glass)

I have to admit I got this idea when watching a video example of a instructor showing his method to draw a picture. The video was from the perspective from his eye since he was recording from Google Glass.
My idea is to use Google Glass with developers remote and local blended. This is only one way how an experienced developer may be remote and the junior onsite developers can be local working more direct with the client and giving solid help from the more senior developer who is remote.
Another way could be a local onsite senior developer with a group of offshore working to produce the solution under the direction of the onsite developer lead.
I think this style of development has a potential to work and here is why I think it will, I have with moderate success worked with voip and screen share and another developer, but something always seemed missing and I would get frustrated not knowing is the developer working or stuck etc.. There is something about seeing the constant view of what the other person is looking at that keeps it more connected and real that glass will bring to just voice and screen share. I understand you have to look away for a break or check email on another screen, these unannounced pauses and quite periods can causes a disconnect between the members of the joint session. I think this more connected interaction with glass and hangouts will add to the productivity and might be that missing piece that I get when doing the tradditional screen share and voip!
Now my disclaimer! you have to have a team that can work in peer programming environment, in my tenure I have come across multiple personalities and team dimensions and with out a peer programming team this will not work.
I could see this being a bigger idea where a collective group of ace developers offer time packages to companies for this scheduled peer remote mentoring. To think about it even at $1500 for google glass, it could be passed around to multiple developers on different days. Maybe this could be a scheduling and bidding service where the expert mentor and his reviews can command big bucks to tackle your hard coding problems??

Thursday
Dec192013

WebCenter Portal an Agile Approach (Continuous Integration) 

To recap from my prior post, we have our teams working within their own JDeveloper Applications testing their code locally through the ide built in tools. Alone this can produce “works on my machine” syndrome, so how do we eliminate this syndrome? Through Continuous Integration where we fail fast. I am not going to explain the merits or each nuance to implement CI in this post, I will be showing the project setup and how to get the applications building and running for our Acme Portal Project using Hudson and working with their dependent applications.
A quick explanation of Continuous Integration (CI) it is a software development practice where members of a team integrate their work frequently leading to multiple integrations per day, in a automated build, including running tests to detect integration errors as quickly as possible, verifying each team member’s contribution and integration quickly in a fail fast manner for the entire portal application.
I want to also comment that Hudson Server can be used as a Deployment engine too, not covered in this post but planned for future posts.
Below is the end result of our applications building is a screenshot of our now healthy Portal Project with all the applications (Hudson Projects) building and integrating amongst themselves.

 

 

I want to also comment that Hudson Server can be used as a Deployment engine too, not covered in this post but planned for future posts.
Below is the end result of our applications building is a screenshot of our now healthy Portal Project with all the applications (Hudson Projects) building and integrating amongst themselves.

The above picture is the project dependency tree; I will go into detail on how I have them setup to build and their dependencies. The order in which I describe them is the order that each application is built when starting from scratch and is the path of the dependency tree.  *** Be carful naming ambiguity ***, 1 JDeveloper application maps to 1 Hudson Project and a JDeveloper application can have multiple JDeveloper projects encapsulated, which will just cause more ant tasks in multiple Ant files getting called within the 1 Hudson Project.

1. libs – this project is our repository of third party libraries used in the applications, since JDeverloper and ojdeploy is using Ant I will not involve maven for dependency management. New ADF Oracle has started supplying maven dependencies but this is not the case for WebCenter yet. An example of a third party jar in our project is the commons-lang3-3.1.jar. This configuration says to watch for added jars and if updated, download and then trigger the first lowest application on dependency tree to start to build.

Configuration settings:

  • Job Name: libs
  • Repository: svn/portal/trunk/libs   [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build other jobs: CommonsProject [Commons is the lowest application that needs this application] 
  • Block build when downstream job is building:true
  • Block build when upstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

2. CommonsProject – this project is triggered when new code is checked in or when a new jar is added to the library project.

Configuration settings:

  • Job Name: CommonsProject
  • Repository: svn/portal/trunk/CommonsProject  [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build after other jobs are built: libs
  • Build other jobs: BackendEndProject [this is the above the dependency tree for our projects] 
  • Build after other jobs are built:libs
  • Block build when downstream job is building:true
  • Block build when upstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

3. BackendEndProject – this project is triggered when new code is checked in or when the CommonsProject is built.

Conifguration setting:

  • Job Name: BackendEndProject
  • Repository: svn/portal/trunk/ BackendEndProject [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build other jobs: ComponentsProject [this is the above the dependency tree for our projects] 
  • Build after other jobs are built: CommonsProject
  • Block build when downstream job is building:true
  • Block build when upstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

4. ComponentsProject– this project is triggered when new code is checked in or when the BackendEndProject is built.

Configuration settings:

  • Job Name: ComponentsProject
  • Repository: svn/portal/trunk/ ComponentsProject [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build after other jobs are built: BackendEndProject
  • Build other jobs: AcmeProject [this is the top Parent that puts all the projects together for the Portal] 
  • Block build when downstream job is building:true
  • Block build when upstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

5. AcmePortal– this project is triggered when new code is checked in or when the ComponentsProject is built.

Configuration settings:

  • Job Name: AcmePortal
  • Repository: svn/portal/trunk/ AcmePortal [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build after other jobs are built: ComponentsProject
  • Block build when downstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

The above configurations ensure that our dependencies are harmonized and that our code will fail fast when they are not, unit testing and Code Quality Metrics are generated for management and team members to review.

The above picture showing a failed build touches on this fail fast paradigm that I have eluded too in this post. This practice when done correctly encourages frequent check-ins to ensure your code is working with others, it also fosters when managed correctly a group think/mentoring when a failure occurs where the team addresses the issues from the broken build. 

 

The above picture is to demonstrate one of the type of reports that can be available to the team and management.  Unit testing and reporting is an important topic and will have its own future post devoted to it.

 

 

 

Sunday
Oct272013

WebCenter Portal an Agile Approach

Introduction

Let’s first lay out the initial vision for our Ace Portal team. We just parachuted into the Acme Company who recently purchased Oracle WebCenter Portal. They know they need a Portal since Oracle packaged it with their Enterprise Corporate database purchase. The first step to our mission is to create an initial setup of a Portal in an agile development environment. This allows us to gather requirements, deploy small sets of Portlets in a timely fashion, and effectively allow the client to provide feedback throughout the process. A note to all Agile purists (if there is such a thing): this approach may not follow a traditional Agile methodology, however this is how I've successfully deployed WebCenter Portal projects in the past.

Our team will consist of a multifaceted talented set of team members. Titles and skill sets are as follows:

  • User Experience (UX) members: ADF Skins developer with CSS3, ADF template, and WCAG/508/ADA experience.
  • Middle-tier developers: JSF/ADF components and basic Java bean development experience.
  • Back-end developers: ADF business components, database and services skills.
  • Content Management Dev/Administrator: A limited license is usually given by Oracle to WCC, however the company might already have an existing CMS in place (i.e. Documentum).
  • Administrator Software Configuration Management (SCM): WebCenter Portal Administrator, Oracle Metadata Repository (MDS), Jenkins and ojdeploy Ant task experience.

Now we need to setup our development environment with a project layout that will allow our team to work independently while still deploying on an integrated domain. We must also remember that our Acme client may not have the necessary portal knowledge to effectively communicate the needs of the project’s look-and-feel and portlet details. Therefore, our development team will be deploying various versions in order to receive useful feedback from the client. The client has hinted about having an application that will work with this new database they just bought from Oracle and something like a stock ticker for the CFO. Project Configuration, Continuous Integration, and Build & Deploy systems are needed simultaneously. I like to refer to this group as "The Agile Landscape":

Project Configuration

Let’s get started by splitting out projects into our areas of concern. Guess what? They each match up perfectly with our team setup (this is by design).

Project Hierarchy Diagram

Project Descriptions

UX_Project: [JDeveloper ADF Skin] skins, javascript (minimal if needed) and Sprites (images) - images as we know are frowned upon. Note: I am not sure why the ADF Skin Editor cannot run inside JDeveloper 11.1.1.7. JDeveloper 11.1.2 * is required currently.
Component_Project: [JDeveloper Fusion Web Application ADF] This project will consist of taskflows and simple Java beans. This is where the controller layer lies for our portlets, and also includes some business logic. The secret sauce cannot be given out - each project is different. I like to try and keep the bounded task flows encapsulated into their own flow logic. The approach is to pass all of the parameters into the taskflow - even requests and session values. At first it might be difficult to figure out what logic can be reused across these taskflows (let alone the entire corporate landscape). Keep in mind, however, that as we grow our portlets and taskflows - they will naturally group into categories which we can collect in multiple component projects after multiple iterations.
Commons_Project: [JDeveloper Generic Application] Having a placeholder encourages re-use so I have created a commons project. Note: This is not required for every project.
BackEnd_Project: [JDeveloper Fusion Web Application ADF] This project will house the data components for the databases and web services. This can also include a custom content repository or a WebCenter Content connection. To start I created a simple POJO data-bound control.
Master_Project: [JDeveloper WebCenter Portal Framework Application Project] This will be the collection of every other project as shared resource jars. MDS Configurations and Site Resources will be included here (i.e. navigation, security, site templates, etc.). We will name this Master WebCenter Framework Portal Project: ‘AcmePortal’. This is instrumental for managing site resources that can be updated without a complete redeploy of the entire Portal.

JDeveloper Project Screenshots

UX Project

Components Project

Commons Project

BackEnd Project

Master Project

Conclusion

This is a high-level walkthrough of the layout for our projects and assets. This allows our team to work simultaneously in an agile environment to create a portal and answer the business needs for the Acme Company. It is absolutely imperative that these separate projects are continuously growing and dependencies are consistently updated in order to encourage a fail-fast integration approach. Stay tuned for my next post which will describe how to seamlessly build and integrate all of these projects together. The image below displays the simple Acme Portal using a single portlet on the home page to show each piece working together.
Tuesday
Oct012013

OOW2013

 

 

 

WCP = Single pane of glass for end users.
1. Responsive design templates, and ability to create specific templates for targeted mobile device page variant is key for targeting.

WCC = mobile
1. Has mobile applications for iPhone and android.
2. New responsive traditional web UI to edit documents.
3. Ability to have a more personal content management than can share, meaning very smooth workflow and collaboration of content before going live.
4. Web UI looks like dropbox, oracle now has document service in the cloud probably reason for Dropbox look.
5. On premise WCC syncs with the cloud, nice idea to do on premise then when approved deploy to cloud service for sharing let oracle handle the load i.e. CDN for your documents.

ADF , Meta Data Service MDS*, customizations and extensions
1. Layered customizations
2. Can do personalizations for end user.
3. Repository = File classpath or DB
4. Context gets setup to get from MDS get merged XML to display to user.
5. Patch safe since customizations are separate from base xml
6. Sandbox for customizations fork of the main line i.e context were others can hare too.
7. MDS labels to publish a set of changes to production (customization set)
8. Good idea for layers: Global,Site,Role,User,country,organization,internal/external,job role.
9. MDS ties to ADF resource bundles for internationalization.
10. DTRT api to allow run time customizations.

Building ADF team the journey
1.bit.ly/ADFTour
2.oracle.com/jdev
3.oracle fusion developer guide
4.oracle.com/usableapps. ***

Team roles:
Adf team lead
Add developer
Skin developer
Database developer
Java expert
JSF expert

Types of teams due to adf shared libraries.
UI teams (mobile)
Services
Soa layer

Cloud Developer Services (big push for oracle)
Make sure ADFLogger is being used.
support note 971256.1 to get add source code.

Reuse:
1. Create base classes
2. Develop templates
3. Build declarative components
4. Distribute via ADF libraries
5. Agree upon - and enforce naming conventions

Adf YouTube channel:YouTube.com/user/ADFInsiderEssentials

Architecture questions:
Team size,skill capability
One vs multiple appa
One vs multi-page apps
Level of software reuse
Sequential vs parallel development
Application customization
Legacy application modernization
Integrating mobile

Webcenter Portal direction:
Multi-Channel,Consumerization,Cloud -> road map
Focus- Worker Productivity and Mobility.

Targeting devices is the key push for webcenter portal.
Native application through rest services.

ADF adaptive thoughts:
1.Simplicity vs flexibility the conundrum for ADF.
2. El expression to access passed in variables from the bounded taskflow to generify page and BC components like names of data controls etc...
3. DynamicComponent is out of the box dynamic component allows for CRUD without having to do all the messy coding works with many different components through tree binding like a drop down box. Attribute model is key DC to show hide read only based on value of a field business logic component is the main object for that.
4. oracle.job.client.ELEnvInfoProvider and EL to resolve the connection have a bounded taskflow pass it in blog articles on this at groundside blog

Adf best practices:
1. Pageflow and Page templates always use them.
2.Extend base classes def base classes not needed too, good for logging and transaction times for BC components.
3. Always define facets for developer to add too.
4.Declarative components are nice to extend the functionality of a common reused components.
5. Example date component that is declarative then changing common date changed in one place because its declarative instead of the base component and changing the format in 90 places.
6. Always work with the grain of the framework. Going against the framework you will fail figure out how it is done.
7. Have to work with version control inside JDeveloper do to all the files that go with making one change.
8. 11.2.* does not have git support
9. Without maven check in shared libraries in approved repository of svn for different component developers to checkout and reference in their workspace.
10. ADFLogger runtime can be changed.
11. Always start with creating build structure and building of the modularizations and automate the building or you will FAIL .

Scale WCP
1. Big hit with numerous adf components on a page.
2. Jascript partitioning.
3. Multiple ADM take up database connection, adm does not release connection it has its own pool consider webservices with good SLA
4. Definitely need to tune webcenter portal out of box is no good.
5. Client_state_max_tokens lower
6.MDS cache needs to be increased usually purge MDS too.
7. CDN for adf http://www.ateam-oracle.com/cdn-support-in-adf-faces-11-1-1-6/
8. Oracle OATS for testing add


'My Take' Portal has to be more than a view in a browser has to evolve to a single pane that is contextual and device aware. The desktop is only one of many devices phone,tablets etc...(TV).

My own quick notes that I want to go back too.
Links
Bit.ly/jsf-lifecycle

https://groups.google.com/forum/?hl=en#!forum/adf-methodology

https://blogs.oracle.com/jdeveloperpm/entry/adf_faces_stencils_for_visio_available_on_samplecode

https://blogs.oracle.com/onesizedoesntfitall/entry/adf_naming_and_project_layout

Blogs.oracle.com/ground side