OnTrack Available for Download

Monday, June 29, 2009

I blogged yesterday about my first Android application called OnTrack that enables diabetics to track various statistics. Well I wasn't getting much feedback from beta testing so I decided to go ahead and make it generally available for download here. To download the application visit the new OnTrack product page. The application will also be available on the market later this week.

Posted by Gerald Nunn at 7:52 PM | Categories: Android | | | Permalink

Android and Diabetes

Sunday, June 28, 2009

As I discussed in a previous post, I have diabetes and require several injections of insulin a day to control my blood sugar level. When I mention that to people they invariably cringe but trust me, it sounds worse then it actually is as the process of testing your blood followed by an insulin injection quickly becomes old hat and routine. Having said that, for a diabetic it is important to track various statistics such as blood sugar level in order to ensure that treatment is progressing well and no untoward trends are occurring. Without historical data it is pretty easy for your blood sugars to creep up on you over time without realizing it.

I recently bought a Google Android phone, the HTC Magic, from my carrier here in Canada, Rogers, and one of the things that attracted me to this phone is the ability to develop applications for it using Java. Considering I have diabetes, a natural first project was to write a program that would allow me to keep track of my statistics on the phone. I previously had a Windows Mobile phone and used a purchased application on that platform but I had several issues with that application such as its inability to remember settings. Now that I could build my own program I could get it working exactly the way I wanted and if it didn't work out I had only myself to blame.

So with that in mind, I sat down and started developing my application and learning Android. Overall, I found the process of developing an application for Android quite painless as the APIs are for the most part quite logical and straight forward. Any experienced Java developer should have little difficulty in learning this platform. There are some areas that could use some additional documentation however a bit of poking arond on the web and some posts to Android forums usually turns up the answer you need.

After a couple weeks worth of work a basic version of my application is now ready and in use on my phone. For those interested, here are a few screen shots of my diabetes application, I hope to put it on the Android market later this week where it will be available for free.

This screenshot shows the main screen of the application, entries are grouped and separated by date.

This screenshot shows the data entry screen. Like most Android applications, you can save an entry simply by pressing the back button.

Finally here is a screenshot that shows one of the available reports, this graph displays your glucose readings over time.

Posted by Gerald Nunn at 9:31 PM | Categories: Android | | | Permalink

Dynamic Visitor Tools

Tuesday, April 21, 2009

A feature in WebLogic Portal that is not well known is the Dynamic Visitor Tools (DVT), a sample added to WebLogic Portal 10.2 or later that allows users to customize the portal exeperience by simply dragging and dropping portlets. New portlets can also be easily added by dragging them from the DVT menu bar which appears at the top when DVT is active. If you have not had a chance to check out DVT previously then I would encourage you to visit the WLP demo site at http://wlp.bea.com and give it a whirl. Once you have registered or logged in, click the customize link in the top right corner to play with the DVT sample.

Posted by Gerald Nunn at 9:12 AM | Categories: WebLogic | | | Permalink

Manually Migrating a Server

Friday, April 17, 2009

I was recently helping a client setup whole server migration where one server in the cluster hosted a singleton JMS queue, as a result the client weanted to use whole server migration so that the server would automatically migrate to a new machine in case of failure. We also wanted to test manually migrating this server to an alternate machine in case a planned outage was required. Unfortunately it turned out that the process for manually migrating a server was not obvious, changing the server on the migration page did nothing and the server stubbornly continued to restart on the current host machine.

After doing some poking around, we found the following process worked.

• Stop the migratable server
• Change the machine to the server you want it to boot on in the Admin Console
• Change the list of candidate servers so that the machine you want to boot on is first in the list.
• The target machine in Servers|Control|Migration should reflect the machine you chose in b automatically but confirm it.
• Start the server, now starts on the new server.

I assume the existing process works the way it does because this would be the desired way to working when performing a failback, thus for a planned outage follow the steps above.

Posted by Gerald Nunn at 10:34 AM | Categories: WebLogic | | | Permalink

WebCenter Interaction and RAC

Thursday, April 16, 2009

I recently had to help a client decipher some older G6 documentation about using the Plumtree/ALUI/WCI portal with RAC and thought it might be useful to post the distilled instructions here.

A. Create a tnsnames.ora file in your PT_HOME/settings directory that contains something similar to the text below. Note replace the HOST and SERVICE_NAME entries with values that make sense for your system.

RAC = 
  (DESCRIPTION = 
(ADDRESS_LIST= 
  (FAILOVER = ON) // Connection-Time Failover 
  (LOAD_BALANCE = ON) // Client Load x 
  (ADDRESS= (PROTOCOL = TCP)(HOST = rac1)(PORT = 1521)) 
  (ADDRESS= (PROTOCOL = TCP)(HOST = rac2)(PORT = 1521)) 
) 
(CONNECT_DATA= 
  (SERVICE_NAME = PLUM10.plumtree.com) 
) 
  ) 
 

B. Open the file configuration.xml in a text editor, look for the line:

    <component name="opendb:DBConnection/oracle" type="http://www.plumtree.com/config/component/types/opendb">

Under this line, insert the following entries:

<setting name="database-connection:rac-tnsnames-file">
<value xsi:type="xsd:string">C:/alui65/settings/tnsnames.ora</value>
</setting>
<setting name="database-connection:rac-tnsnames-data-source">
<value xsi:type="xsd:string">RAC</value>
</setting>

Obviously replace my hard code C:/alui65/settings/tnsnames.ora with your value. Note the data-source value used above, RAC, must match what is tnsnames.ora (the RAC= at the beginning)

C. Repeat step B for the following lines in configuration.xml:

 
<component name="aluidirectory:openjdbc" type="http://www.plumtree.com/config/component/types/opendb">
<component name="activityservice:persistence" type="http://www.plumtree.com/config/component/types/opendb">

D. Just do a search of the file for your database SID to make sure no other spots were missed.

Posted by Gerald Nunn at 8:57 AM | Categories: WCI | | | Permalink

Calibrating a Television

Tuesday, April 07, 2009

The Home Theater fairy, the lesser known cousin of the tooth fairy, visited me last week and blessed me with a new television. I ended up getting a great deal on a Samsung LN52A850 set and with spousal approval went and pulled the trigger. I had been thinking about getting a new television for some time as my 46" Samsung just felt a little small in the space we had and the new 52" set provides more of the larger picture we are used to from the theaters.

With a new set however comes the inevitable calibrating of the set in order to get the picture just right. In the past I have to admit I have been guilty of calibrating by simply using a movie and the Mark 1 eyeball which seems to be losing its efficiency with age. When browing the thread on calibrating the A850 at avsforum there was a post linking to a free calibration DVD put together by some of the avsforum members.

I've only had a chance to have a quick look at it but what I have seen so far is pretty impressive for a free effort. The disc contains various patterns that are displayed through a Blu-ray player or other HD source that allow you to perform a basic calibration without equipment. The disc is burned from an .iso and is navigable using a simple menu, it took me all of five minutes to burn the disc and start playing with it using my PS3. While the burning process is simple, what really makes the process easy is the sixteen page PDF document that accompanies the disc and guides you through the process of calibrating your set.

The disc allows you to calibrate the grayscale, colors, contrast, brightness, sharpness and other parameters of the television without having to use any tools. While the final results are not going to be as good as an ISF calibration they should be more then sufficient for the average joe. One thing I found useful on the Samsung set, which I assume would be available on all recent Samsung sets, is the availability of a blue mode. This blue mode allows you to adjust the colors on the set without requiring a blue filter by only displaying the color blue. In this mode different colors which have a blue component are still visibile and colors can be tuned by using the test pattern tweaking the settings until the blue appears identical.

The AVS HD 709 disc is a highly recommended tool and you owe it to yourself to check it out.

AVS HD 709 - Blu-ray, HD DVD, & MP4 Calibration

Posted by Gerald Nunn at 9:27 PM | Categories: Home Theater | | | Permalink

PS3 as a Blu-Ray Player

Thursday, March 19, 2009

For the last year or so I have been using a Samsung BDP-1200 as my Blu-Ray player and it has generally gotten the job done though it has required the occasional firmware upgrade to be able to play the latest discs. While I'm generally understanding of the need to update the firmware, it annoys my wife and the last straw for her was when she rented Australia and it would not play with no firmware upgrade available. Thus she gave her blessing to get a new BluRay player with the caveat that the new player handle everything and thus my quest for a new player was born. (As an aside for you men out there, the easiest way to get agreement from the wife for a new gadget is to make sure the old one annoys the heck out of her!)

I looked around at the available players and while a lot of options were available most of the good ones were in the PS3 price range. While I hadn't looked at a PS3 previously, considering I already have a Wii and an XBox 360, given that it was about the same price as a regular player and Sony was very active in keeping the firmware up to date I decided to get this instead of a player. It didn't hurt that my eight year old son was strongly in favor of this direction since he had been wanting to try Little Big Planet for quite a while now.

So I headed down to BesyBuy and picked one up along with the Nyko IR Remote for the PS3. I needed the Nyko so that my Harmony remote could control the PS3 during movie playback since the PS3 uses BlueTooth otherwise. So I got home and unpacked the PS3 and proceeded to set it up which turned out to be a breeze since I just reused the HDMI and optical connections from the BDP-1200 it was replacing. One thing to keep in mind with the Nyko remote is that when setting up the Harmony remote the device type is the Nyko and not the PS3 itself. Also note the Nyko cannot power on and off the PS3, no big deal since you have to go to the machine anyways to pop in a disc.

Once it was up and running we popped in a BluRay and were off to the races. Overall the video quality was excellent and generally on par with the BDP-1200 I had previously. The load time for the BluRay was much faster on the PS3 which my wife greatly appreciated, the BDP-1200 was a bit of a slug in this respect. More importantly for my wife, the PS3 handled every BluRay thrown at it which made her very happy. I do have one issue with the PS3 however and that is these periodic white flashes I get only when using the XMB menu and playing regular DVDs, BluRays and games have no issues. I believe this is an HDMI issue and if I turn down the resolution to 720p or 1080i then everything is fine, it only happens at 1080p.

After doing some reading, I suspect the problem is the HDMI cable I am using may only be Category 1. Apparently a Category 1 cable is only rated for up to 1080i but you might get lucky and find it is able to handle 1080p. A Category 2 cable is rated for bandwidth above 1080p and thus should handle 1080p no problem. With this in mind I ordered a couple of 6' HDMI cables (1.3 and Category 2) for $13 from monoprice.com, a much better deal then dropping $60 at the local BestBuy. Once the cables arrive I'll post again about whether or not they fix my issue.

Posted by Gerald Nunn at 12:21 PM | Categories: Home Theater | | | Permalink

WebLogic Portal and JSF

Wednesday, March 18, 2009

Just a quick FYI that there is a great new whitepaper available from the Oracle site on using JSF with WebLogic Portal. This whitepaper provides a comprehensive guide (152 pages!) for building JSF portlets in WebLogic Portal, highly recommended. You can download the whitepaper at the link below, a big thank you to Peter Laird for taking the time to put this together.

Developing JSF Portlets with WebLogic Portal.

Posted by Gerald Nunn at 3:56 PM | Categories: WebLogic | | | Permalink

WLST and Templates Glitch

The WebLogic Scripting Tool (WLST) is a great tool for creating pre-configured domains quickly and easily. The tool allows you to define a script in Python that automates the creation of the domain by working with the object model defined in WebLogic. For those unfamiliar with WLST, a great summary can be found here.

Recently I was working with a client to automate the creation of their domains and ran across two issues as follows:

• The username and password for node manager was not taking after it was changed, it was always using the default generated username/password when it was written; and
• A JMS subdeployment could not be targetted to a JMS Server, it always defaulted to the target of the JMS Resource the subdeployment belonged to.

After investigating both issues, it turned out that these operations were getting overwritten by the defaults in the template JAR when the domain was being written. When the code was debugged it was evident that things had been set correctly, however when the domain was written these changes were ignored. The issue was that the directives in the template were overriding what was being done in WLST code. While annoying, an easy workaround exists. All that needed to be changed was to move these operations after the write operation, at this point they could be performed successfully. Here is an example with some pseudo-code:

readTemplate(path)

#Update domain config settings
#...

writeDomain(workingDirectory)
closeTemplate()
readDomain(workingDirectory)

#Perform tasks here that only work if done after domain is written
#...

#Write new changes back out again
updateDomain(workingDirectory)

A small issue with an easy fix, just one thing to keep in mind when working with WLST.

Posted by Gerald Nunn at 3:42 PM | Categories: WebLogic | | | Permalink

Federated versus Local Portal Development

Tuesday, January 27, 2009

A question that comes up from time to time at clients is what are the differences between developing a federated portal, using Web Services for Remote Portlets (WSRP), and a local portal. For those unfamiliar with the terms, a federated portal is one where the portal and portlets are typically running in different applications and containers where as a local portal is one where the portal and portlets are in the same application and container.

Some clients naively believe that developing a portal for a federated environment is identical to a local portal and that the WLP framework takes care of all the differences. While the WLP framework does do a good job of abstracting the differences between a federated portlet and a remote one, it is not perfect and I’ve seen more then one client get burned by assuming it was.

Given that, I thought it would be interesting to write a short post with regards to what you need to keep in mind when developing a federated portlet using WSRP. So with no further ado here are some thoughts, while not comprehensive, should provide you with some food for thought.

Behavior Issues. First understand that federated portlets and local portlets do not run in the same context and do not behave identically in all instances. There are many subtle nuances that crop up when attempting to convert a local portlet to a federated portlet that can be surprising to a developer new to remote portlets. For example, a common practice in backing files in a local portlet is to place information to be passed to the render objects (Page Flow controller, JSP, etc) as an attribute in the request object. This will not work in a federated portal since the backing phase and the render phase are actually two separate requests in a federated environment.

As a result, my personal recommendation is that if you are developing a federated portlet it should be run as a federated portlet in all environments, including on the developers workstation. Doing this does not require running a separate portal instance on the developers workstation since it is actually easy to do by simply creating a proxy portlet out of the same container and drop that in a test portal instead of a local portlet. I covered this topic in a previous blog post.

Governance. A federated portal is typically built by multiple development teams and spans multiple systems. Thus just like an SOA initiative, governance becomes a key factor in a successful rollout of a federated portal. A federated portal however is even more complicated then an SOA initiative because in addition to governing services one must also place governance around the user interface.

Without adequate governance and planning, different development teams could build portlets using different user interface paradigms leading to difficulties for users to navigate due to differences in UI. Another negative outcome you often see is different teams building the same style interface but using different artifacts (CSS, JS, images, etc) to do so. This leads to maintainability issues since any change in the Portal style requires multiple artifacts to be updated.

In short governance of the user interface must be a top priority in a federated portal implementation, particularly one that spans multiple lines of business in an organization.

Performance. The topic of performance is always a concern, regardless of whether the portal is local or federated. Federated portals had additional concerns since all access to the portlets is done remotely. Thus addressing items like keeping the size of the HTML in portlets small become more important since we are adding additional network hops.

Distributed Information. A significant issue in federated portals is that information is distributed across multiple pieces of infrastructure. For example, if multiple portlets are working with a specific customer then some of that customer information, such as first name and last name, can exist in multiple places at the same time. If this information is cached for performance reasons and another portlet changes that information then this information can become stale and out of sync with the proper state.

In a local portal addressing this issue is relatively easy, however in a federated portlet where the information resides in separate applications and infrastructure the problem becomes more complicated. A federated portal implementation should recognize if information is going to be shared and if it is mutable determine a strategy to ensure that information stays synchronized across all portlets and containers. Potential strategies here include using events to signal changes or adopting a distributed cache such as Coherence.

Versioning. Another key consideration is to have a versioning policy and plan for anything that couples the consumer and separate producers together. For example, it is very common in a federated portal implementation to use inter-portlet communication (IPC) to pass information between different components in the Portal. Any changes to this information or the structure of the information due to new requirements could result in the need to upgrade and redeploy multiple components of the Portal.

As an example, let’s imagine a federated portal implementation that provides insurance information. A consumer portlet allows the user to select a policy number to view while portlets provided by different lines of business provide different pieces of information about that policy. In this case the consumer portal tells the portlets which policy is selected by passing them a class that contains the policy number. This class is de-serialized, using Java serialization, on the producers where they retrieve the policy number to be displayed.

All well and good, however a new requirement for one of the portlets is that it display some additional information that requires the consumer to provide extended information about the policy. Using the example above, we cannot simply add the new information to the class because it will break the de-serialization of the class on all the other producers. This relatively simple change is now forcing us to upgrade all producers simultaneously.

There are a few ways around this such as making the serialization/de-serialization version resistant or by using XML and ensuring additional attributes can be added with no impact. The key take away though is to ensure that you have a strategy for versioning and this be taken into account from the start of development.

That concludes this post, while the list above is not comprehensive hopefully it includes enough to get you thinking.

Posted by Gerald Nunn at 10:58 AM | Categories: WebLogic | | | Permalink