The RotatorContainer cycles through dijit.layout.ContentPanes and provides navigation in the form of tabs or a pager. There a number of timing settings you can adjust as well as the layout of the controls.

Give it a try!

Here’s how you can use it:

<script type="text/javascript">
dojo.require("dojo.parser");
dojo.require("dijit.layout.ContentPane");
dojo.require("dojox.layout.RotatorContainer");
</script>

<div dojoType="dojox.layout.RotatorContainer" id="myRotator" showTabs="true"
      autoStart="true" transitionDelay="5000">
    <div dojoType="dijit.layout.ContentPane" title="1">
        Pane 1!
    </div>
    <div dojoType="dijit.layout.ContentPane" title="2">
        Pane 2!
    </div>
    <div dojoType="dijit.layout.ContentPane" title="3">
        Pane 3!
    </div>
</div>

NOTE: There is some CSS needed to make the RotatorContainer look correct. Include or copy the contents of the dojox/layout/resources/RotatorContainer.css into your CSS file.

The magic happens once you have some content. It takes a bit of time to tweak things, but you can pretty much do anything you can imagine.

The RotatorContainer can be controlled by a pager which includes a play/pause button, next and previous button, and the current and total panes. You can also have as many pagers as you’d like. The pager code looks like this:

<script type="text/javascript">
dojo.require("dijit.form.Button");
</script>

<div dojoType="dojox.layout.RotatorPager" rotatorId="myRotator">
    <button dojoType="dijit.form.Button" dojoAttachPoint="previous">Prev</button>
    <button dojoType="dijit.form.ToggleButton" dojoAttachPoint="playPause"></button>
    <button dojoType="dijit.form.Button" dojoAttachPoint="next">Next</button>
    <span dojoAttachPoint="current"></span> / <span dojoAttachPoint="total"></span>
</div>

One thing I should note, if this widget should find it’s way into dojox, it’s possible the name or functionality will change.

If time permitted, I would have liked to add additional transitions such as a left-to-right wipe. Oh well.

Enjoy!

<CFSET myObj = CreateObject("java", "java.util.Hashtable")>

Suppose you have the following Java class:

class Person {
    private String name;

    public void setName(String n) {
       this.name = n;
    }
}

Now, let’s create an instance in ColdFusion and set a name:

<CFSET somebodySpecial = CreateObject("java", "Person")>
<CFSET somebodySpecial.setName("Chuck")>

Cool, but what happens if you pass an argument that isn’t a string:

<CFSET somebodySpecial.setName(123)>

coldfusion.runtime.java.MethodSelectionException:
    The selected method setName was not found.

Whoops! ColdFusion wasn’t able to find a method of Person with a signature of “public void setName(int)“. What you need to do is cast the arguments to the correct datatype. For this example, you could do something like this:

<CFSET somebodySpecial.setName(ToString(123))>

The problem is what if you need to call methods that use other data types such as int, double, or boolean. ToString() won’t cut it. Instead use ColdFusion’s JavaCast() function:

JavaCast(type, variable)

type        "boolean"
            "int"
            "long"
            "float"
            "double"
            "String"

variable    A ColdFusion variable that holds a scalar or string type

So, the correct way is:

<CFSET somebodySpecial.setName(JavaCast("String", 123))>
<CFSET somebodySpecial.setName(JavaCast("String", "Chuck"))>

No more MethodSelectionExceptions!

This will be my first time going to OSCON. It was a tough decision because there were some other conferences I wouldn’t have mind going to.

The first two days of the conferences, Monday and Tuesday, are tutorial days. They cost extra, but you get 3-1/2 hours of exposure. I’ve decided I’m going to the following tutorials:

• Pthreads programming: a hands-on introduction
• Linux performance monitoring
• New parallel programming tools for a multicore world
• Next-gen interaction with Ajax, Comet, and PHP

There are a couple others that sound interesting, I have decided to focus on content that is applicable to the direction CB1 is heading.

Early bird discounts end Monday, June 4th, so you’d better register today.

Begin by logging into Drupal and navigating to:

Administer > User management > Access rules

Click “Add Rule” and enter the following information:

• Access type: Deny
• Rule type: Host
• Mask: <IP address to block>

Add the rule and the user should be blocked. If you want to block entire class of IP addresses, you can use a ‘%’ such as “xxx.xxx.xxx.%”.

She had some interesting points about scalability. She basically said that no matter what language you write your web application, whether it’s compiled (C/C++) or interpreted (PHP, Java), you are subject to scalability issues. Another potential problem is optimizing before you know what exactly to optimize. This can lead to a loss of time that could have been spent on more important things.

Laura’s talk covers three types of best practices: general, scalability, and performance.

General Best Practices

First tip is to profile early and profile often. The earlier you can detect poor performance, the easier it is to fix. There are a handful of tools (APD, Xdebug, Zend) that can help with profiling. Use system profiling tools such as strace, dtrace, and ltrace to gather more information.

There are two types of effective profiling: debugging and habitual. Debugging profiling is about spotting deviations from the norm and habitual profiling is making the norm better. Profiling is an art and requires lots of practice to know where to look.

It is essential that the IT admins and the developers cooperate. This allows crisis’ to be handled properly, especially in production environments were outages are time critical. Team members should report alert the developers of any abnormal behavior changes after a new code release is pushed. Before pushing new code, schedule a launch window and procedures for having developers fix problems and possibly falling back to a previous version. Avoid pushing releases on Fridays, otherwise key team members may be unavailable or over worked on the weekend.

It is recommended to test your application with production data. Test data may not take into account certain scenarios where bugs can be introduced. It is advised to have a staging environment which uses production data and also undergoes simulated load testing.

In order for you to track your application’s performance, you should record your applications performance over a period of time, then analyze the data to find potential issues. There are several means of tracking performance including access logs, system metrics, application profiling, and query profiling.

When a problem occurs, don’t make assumptions. The problem may be caused by something other than what you think it might be.

Scalability Best Practices

When the web application begins to suffer performance issues, start to decouple and isolate components to track down the source. If you need to tweak code, spend only enough time to refactor as needed. Reduce load on servers by moving static content on to dedicated servers.

By default, PHP stores session data on the hard drive. This can cause performance issues and can benefit from storing the session data in a database or better yet in a distributed cache such as memcached.

The most important thing you can do to improve performance is to cache as much data as possible. There are many levels of caching. You can cache data sets or precomputed fragments. For things like images, you can set up dedicated services for caching and serving static content. The usual suspects are recommended for caching (APC, memcached, Squid).

PHP out of the box does not cache compiled pages. That means that ever request, each page has to be parsed and executed. Extensions such as APC and Zend can cache the compiled pages for an immediate speed improvement.

MySQL’s query cache works, but isn’t necessarily implemented the best way. If you query a table, the results are cached on the MySQL server. If a row is inserted, updated, or deleted, the entire cache is flushed. This supposedly has been fixed in MySQL 5.1, but a setting has to be set to not flush the cache.

To scale, your data can be federated across multiple MySQL servers. There can be complications with regards to data reliability and table joins can suffer from major speed hits.

A more reliable way to scale is to use replication. Replication does suffer from “slave lag” issues. The reason the lag can be high is because the master server uses multiple threads to store the data locally. The slave server has to process the replicated items in a single threaded mode to ensure the order of which the transactions is preserved. You can display the status of MySQL’s I/O and SQL thread by executing a SHOW PROCESSLIST statement.

The more database writes, the greater the lag. Depending on your application, you may only want to use replication for failover or backups.

Sometimes you may benefit from designing your application to avoid situations where data is hard to scale and can’t easily be cached.

Performance Best Practices

You definitely want to use a compiler cache. As described above, use APC or Zend for PHP5. If you are connecting to an external data source, perhaps a web service or data feed, minimize the number of instances you request them. Cache their response if possible. You may be able to load the data dynamically using Javascript and a little Ajax magic. Maybe the data isn’t a must have or maybe you can have a page dedicated to display the 3rd party data.

When tuning your applications performance, change one thing at a time. If you change more than one thing, how do you know which change caused the improvement and how do you know if you didn’t introduce new bugs changing the other things. Use MySQL’s EXPLAIN statement to profile your queries and enable the slow query logging. Use MyTop or InnoTop to help profile your queries.

It is crucial that your database is properly indexed. If a table has poorly designed indexes or perhaps too many indexes. Use the smallest data type possible and try to design your tables to be fixed width. That means, use char instead of varchar, set the length of your fields to logical lengths (ie use 128 chars instead of 107 chars). De-normalize when necessary. Remove static data out of the database or store it in a MEMORY table. Use the appropriate storage engine for each table.

For your queries, minimize the number of queries and cache them outside the database when possible.

She claims that deeply recursive code is expensive in PHP. Make sure you are not doing unnecessary looping. If you find that you are, chances are you are doing something wrong and that there is a better idiom for performing the task.

Don’t try to work around or re-write perceived inefficiencies in PHP. Use regular expressions to do intense string manipulation. instead of writing complex serialization code, use PHP’s extensions to do the heavy lifting. Before spending time to write some boilerplate function, check to see if there are any extensions that exist that could help save you time.

Laura gave this talk on behalf of George Schlossnagle. George’s original presentation can be found at http://omniti.com/~george/talks. This was an excellent session and proved to be beneficial.

This blog will be very technical, so you won’t be hearing about boring non-technical stuff, just the boring technical stuff.

As you may already know, CB1, INC. is a technology consulting company. Custom software development and website design for enterprises is our primary business. Feel free to contact us if you have questions or you think CB1 can be of service to you!