Yesterday, Facebook announced a new PHP runtime technology, HipHop, which allows PHP applications to run significantly faster.

Have you ever heard the urban legend about Van Halen’s contract rider that stated that the concert promoter must provide a large bowl of M&M’s in the band’s dressing room with all the brown M&M’s removed?

It’s true!

And for years I found myself at odds with the attitudes of my rock heroes. (I’m a closet ’80s hair-band fan.) Can you imagine the poor sap whose job it was to comb through the hundreds of M&M’s - by color?

The nerve of these pampered, self-centered, narcissistic minstrels who had somewhere along the path bought into the myth invented by Warner Bros. Records marketing team! I don’t care how many stadiums you can sell out, you are never cool enough to demand “no Brown M&M’s”! (Darn Kids. Get off my lawn!)

However, recently I got a fresh perspective on the purpose of a rock concert contract rider and the way Van Halen was using it.

The contract rider describes in great detail the set up and tear down of the band’s sets and in a very real way describes the day-to-day existence of the band on the road. Van Halen was the first band to bring big stadium shows out to the fans in small markets. The band knew which places had a high likelihood of being potentially dangerous for the crew, the fans, or themselves. They were aware of dangers like substandard construction of the concert venue, lax or under-skilled local contractors who were in charge of lighting, sound, or staging and poor organization among the public relations or security staff.

The band knew that in many cases, they had a better idea of how to put on an exciting and safe show than the people they hired in these small markets. As a safety check, they filled their contract rider with extremely specific instructions for how the promoter needed to run the show. But they couldn’t ensure that the promoter actually read and followed the rider. They had to take the promoters word for it that all instructions were followed to the letter.

That was until they came up with the idea of the bowl of M&M’s. The one that was to be placed in the dressing room, the one that was to have all the brown M&M’s removed. The band could take one look at that bowl and know instantly if the local promoter had or had not closely read and followed the instructions in the rider.

If they saw a single brown M&M they knew to line-check each and every part of the set up thoroughly. Did the promoter hire enough competent security guards? Did the lighting techs tighten down the clamps that hold the 100 lb lights suspended over the heads of the band? Did the sound engineer bother to plug the guitars into the amps? The Brown M&M’s clause in the rider created a trigger that let the band know what type of risk mitigation activities to begin once arriving on scene.

Triggers are one of the most useful tools a team of software engineers can pull out of their project toolbox.

Triggers, in the world of software development, are signposts along the project development path. They help answer the question, “Are the conditions such that my risks have now been elevated to issues?”
A Risk is a condition inherent on all projects; it is a thing that has the potential to become an Issue. An Issue is a problem that must be dealt with by members of the project team if they intend to deliver the project within the metrics of budget, timeline, and the client’s conditions of acceptance.

We track risks. We mitigate issues. But simply identifying and prioritizing risks by their likelihood and severity is not enough. Being able to identify WHEN a risk is evolving into an issue can save the project team a lot of painful rework and the client unnecessary heartburn. It is important that when the project team is identifying risks they are also outlining the triggers and corresponding activities to undertake to either prevent the risk from becoming an issue or lessen the impact should an issue materialize.

Anyone on the project team can (and should) help with this but I feel it falls to the Project Manager to “own” this part of the project lifecycle.

And Project Managers should take a lesson from Van Halen’s candy dish.

• Work to find triggers that are easily identifiable and are not dependant on a lot of other factors. (Either the Brown M&M’s are present or they are not).
• Keep your list of triggers close to you. (The dressing room in this case is the spot where the band got ready to work. Have the list easily accessible, refer to it, and update it frequently.)
• Be ready to demand unpopular actions from your project team when you notice a trigger is activating. (Van Halen would demand that the lighting engineers recheck all the stage lights if the Brown M&M’s were not removed. The PM should be ready to tell the project team they have to: recheck their code, re-estimate their task list, even re-architect their solution. )

Van Halen was OK with being known as a bunch of pampered rockstars because it was better than being known for concerts like the Rolling Stones 1969 Altamont concert where security was provided by the local chapter of the Hell’s Angels and one fan was fatally shot. Or the Who’s 1979 Cincinnati concert where 11 fans were trampled to death in a mad rush to get the best seats in the “open” venue.

As a Project Manager, become OK with the role of gadfly, understand it is your job and your responsibility to initiate the discussion of “what could go wrong.” Then document the triggers and the mitigation strategies. Keep a watchful eye on them and be prepared to act. When the project delivers successfully, you get to enjoy that bowl of M&M’s - even the brown ones.

http://www.snopes.com/music/artists/vanhalen.asp

If you want to create a new Lead via Visualforce or web form with Apex it’s very possible you could overlook the Assignment Rules.  As you might know, it’s not even always obvious on the native Lead creation layout.  Notice the lower left corner checkbox in the screenshot below.

To enforce Assignment Rules in Apex you’ll need to instantiate the Database.DMLOptions class, set the useDefaultRule property of assignmentRuleHeader to True, and finally call a native method on your Lead called setOptions, with the Database.DMLOptions instance as the argument.
The code below demonstrates:

That’s it.  Hope it helps.

Happy clouding ~~~

I’ve got lots of clients who use a single checkbox to mark a record Inactive, in lieu of deleting the record. It’s quick and easy and clear. But sooner or later, as Inactive records build up over time, most of them decide that they want to exclude all the Inactive records from the finds they do — but not all the time, just most of the time.

The obvious solution if you’re a hardcore FileMaker user is a multi-request find that uses the Omit option. You make one request with the criteria you want, then re-enter find mode, check the Inactive box and the Omit option, and select Constrain Found Set.  But this can be intimidating to some users, and really, if I’m being totally honest with myself, I have to admit that it takes too many steps to be truly easy.   

I could use script-triggers to postprocess all finds run in that context, but that demands enough budget or a compelling reason to undertake that level of complexity and effort.  In the absence of either, you can offer an inexpensive solution by presenting the existing data differently, so that people can do a simple, positive find rather than a complex omit find.

Make a calculation field called Status, and code it to return “Inactive” if the box is checked, and to return “Active” if the box is unchecked.  Expose this new field to find mode, and you’re in business.  Now people can type in their find criteria as usual, including typing in “Active” in the Status calc field, hit the Enter key as they always do, and the single-request find will bring back only the records that meet the criteria AND have the Inactive box unchecked.

Understanding the difference between a table and a table occurrence is vital when developing a relationships in a FileMaker solution.   If the Relationships Graph for your FileMaker solution never has more than one table occurrence per table, then it may not be important to understand the differences.  However, once you do understand the difference it may help you to utilize relationships in FileMaker in ways you did not realize were possible.  To understand how tables, table occurrences, and relationships work together we must understand each one.

The best place to start is to first understand a table.  A table stores information about one specific kind of thing: for example, a given table may store information about vehicles, or swimmers, or scholarships. A table stores its data in a row-and-column format. Each row represents one instance of a thing: one vehicle, or one car, or one scholarship. These rows are often known as “records” in database terminology. The columns define the common data elements stored for each instance of a thing: a car’s weight and model year, or a scholarship’s amount. These columns are often called “fields” in database parlance. A table is thus the collection of these records and their field data. In FileMaker, tables are created in the Manage Database Dialog under the Tables tab. All database data in FileMaker is stored in tables.

A table occurrence is a visual representation of a given table in the Relationships Graph.  The best way to think of a table occurrence is as a window or point of view into the actual table. This window or viewpoint can be used to see and/or manipulate the data that resides in the table.  Layouts, for example, are based on a specific table occurrence and can access the data in the specific table occurrence or any data related to that table occurrence.  The use of these table occurrences will be easier to understand once we look at relationships.

Finally, what is a relationship?  A relationship is way of reaching data in one table based on the information that resides in the records of another table.  This is done by linking one or more fields in one table occurrence to one or more fields in another table. For example, you might link a customer ID on an Order record with a customer ID on a Customer record. That’s a way of saying “this order belongs to that customer.”  Another way to think about this is that relationships are a pre-specified query from one table occurrence to the next.  The relationship we just described, for example, would also allow you to find all orders for a given customer. By using these relationships we can report on data in other tables and also display their information through portals from the standpoint of the current table occurrence.

Now that the definitions are out of the way, why are these tools useful?  And why does FileMaker allow more than one table occurrence per table in the relationships graph?  If a relationship is like a pre-specified query into another table, there are times when we need to search for data in one table in multiple ways.  That is why we need table occurrences.

Imagine a straightforward Company-Contact Management System.  We may have the following tables: Company, Contact, Address.  The way these tables are related is as follows:
- one Company can have multiple Contacts
- one Company can have multiple Addresses
- one Contact can belong to only one Company
- one Contact can have multiple Addresses, and these addresses may not need to directly relate to that contact’s company

We don’t need to create a table specifically for Contact Addresses and another for Company Address to implement this solution.  We can simply create one Address table and have it appear as two table occurrences:
- Contact Address will be a table occurrence that is based on the Address table and directly relates to the Contact table occurrence
- Company Address will be a table occurrence that is based on the Address table and directly relates to the Company table occurrence.

Here’s how the Relationships Graph might look. Table occurrence with the same color are based on the same underlying table.

Why not just relate both Company and Contact to the same Address table occurrence?   FileMaker doesn’t allow for loops in the Relationships Graph. A loop would exist if there were ever more than one pathway between any two table occurrences. Since Company and Contact will need to be related to each other, by relating them to Address we would form a loop.  Now, why are loops forbidden?  Well, computers aren’t as smart as we are. A computer can only follow specific instructions.  Imagine that your computer is “standing on” the Company table occurrence and you tell it that you want to see the Address that belongs to a specific Contact.  Well, the computer sees that it is ”standing on” the Company table occurrence and that there are two ways to get from there to Address. One is by going directly to Address and the other is by going to Contact and then on to the Address.  Since both ways are valid the computer cannot decide which way to take on its own.  This is why we need table occurrences. By having multiple table occurrences that point to the same table, all we need to do is to tell the computer the specific table occurrence which we want to grab the data through (in the above Graph it would be Address1).  Then the computer can go to that specific table without any confusion. Between any two table occurrences in the Relationships Graph, there will only ever be one unique path

Through this example we can see how table occurrences are just a window or way to look into the table to see or manipulate data.  We can also see that relationships are just a way in which we direct FileMaker from a perspective on one table to a perspective on another table (a table occurrence can also be thought as a “perspective on a table”).

I hope this will help people understand the difference between tables, table occurrences, and relationships.  For a more in-depth understanding of these concepts, data modeling in general, and many more aspects of FileMaker I highly recommend taking the FileMaker Training Series: http://www.soliantconsulting.com/training

Thinking of upgrading to OS X 10.6? Have you already upgraded? If you answered yes to either of the previous questions, then there are some things to be aware of. Take a moment and explore the links below.

Which versions of FileMaker are compatible with Snow Leopard?
Supported versions of FileMaker can be found here.

Are there any known issues?
The best way to keep on top if current issues regarding Snow Leopard and FileMaker is to search FileMaker’s knowledge base. There are also many resources online which feature some discussion around bugs that folks are seeing. A search from any major search engine will easily grab you the results you want. I did want to add some of the more noticeable bugs here:

1. Attempting to install FileMaker Pro 9 Advanced on a clean install of Mac OS X v10.6

2. Snow Leopard compatibility issues with FileMaker 9 and earlier versions

3. Exporting to the “.xls” format gives an error if Rosetta is not installed

4. Issue when attempting to open a FileMaker Pro file via Apple Script on Mac OSX v10.6

5. What do I need to know when installing FileMaker Server 10 and FileMaker Server 10 Advanced

I’m sure that more issues and resolutions will continue to be posted to FileMaker’s site, but I hope this helps make you aware of some the known bugs.

Adobe and SalesForce have always worked well together.

They are complimentary technologies - Flash is primarily a display platform and SalesForce is more data focused.
Using Flex or Flash to present data from the SalesForce cloud is a great way to make a really seamless and slick user experience. This latest development makes that even easier than it was previously.
Go to this page to find out more and download the IDE.

New Capabilities

Using the Flash or SFDC IDE tools previously enabled you to make either a Flash Builder project or a new SalesForce project.
Now you can make a combined Flash Builder / SFDC project that uses a WSDL to enable you to connect to the SalesForce schema.
You can also create an Adobe AIR app which manipulates offline data and synchs it when you are online again.

There is no guide on how to download the WSDL document from SF for use in the IDE - here’s what you do.

Another trick to remember is that you’ll need your API key to connect to SalesForce - it gets pasted on the end of your password.

Flex / SalesForce integration enables the creation of awesome cloud-based enterprise apps, so get out there and start coding!

Caspar

Occasionally the question comes up as to who should estimate tasks and who should create the work breakdown structure (WBS) for a project.

Should the technical lead estimate the tasks for the developer? Should the developer estimate their own tasks? And if either the task estimation or the WBS creation take more than one person to do, doesn’t it get expensive to do all that planning?

Two principles from my studies in prepping for the PMP exam immediately come to mind (both from Rita Mulcahy’s excellent study guides www.rmcproject.com):

1. Estimating should be done by the person doing the work whenever possible, and,

2. The project plan, for which the WBS is one element, should follow the BARF principle. BARF stands for:

Bought into
Approved
Realistic
Formal

For the WBS to be bought into and realistic, it must be created with the help of the team.

Of course there are always exceptions. Perhaps you don’t yet have all the people who will be doing the work staffed on your project or even know who they are. But when questions like this come up it’s good to know there are at least generally accepted best practices for guidance. And if you cut corners, don’t be surprised if down the road you find yourself wishing you spent a bit more time on the planning phase of your project.

When writing a PHP application, avoid explicitly using the special variables, like $_GET, $_POST, and $_SESSION in your internal classes, so that you can more easily test the class outside of a web environment - specifically, from the command line.

When you run a PHP script from a web page, you

So instead of:

class ShowRecordController {
    public function __construct() {
        ....
    }

    public function run() {
        if ($_REQUEST['method'] == ... ) {
        }
        ....
    }
}

you can pass in the parameters to the constructor:

class ShowRecordController {
    protected $request;
    public function __construct($request) {
       $this->request = $request;
        ....
    }

    public function run() {
        if ($this->request['method'] == ... ) {
        }
        ....
    }
}

This will make it easier to test your application on the command line, and will also make it easier to re-use the classes you have written.

Here is an example of how to print a component to disk using Flex.
The basic idea is to grab the component as a new BitmapData Object, covert that to a PNG ByteArray and then use a FileReference to save the ByteArray to disk.
As you can see in the example here, you can pretty much output any object - and it won’t get clipped by the scrollbars on the browser page.

Here is the relevant code (the demo has view source enabled for full source code):

			private function writeDGToDisk (  ): void {

				var fr:FileReference = new FileReference();
				var encoder:PNGEncoder = new PNGEncoder();

				var bitmapData : BitmapData = new BitmapData(taskDataGrid.width, taskDataGrid.height, true, 0x000000);
				bitmapData.draw(taskDataGrid);
				var byteArrayData:ByteArray = encoder.encode(bitmapData);

				fr.save(byteArrayData,"datagrid.jpg");
			}

Enjoy.
Caspar