• Download the Flash Player Debugger version.
• Create an alias in your profile to tail the flashlog.

Creating an Alias Command

Once you install the debug player, any movie you open in your browser will output it’s trace commands to a flashlog.txt file. This is normally located in the Library directory for your user. So we’re going to make an alias to open it quickly in terminal. If you’re not familiar with alias commands think of them as shortcuts in terminal.

Let’s get straight to the meat of it. First we have to find our flashlog. By default the flashlog is stored here:
/Users/[your system username]/Library/Preferences/Macromedia/Flash Player/Logs/flashlog.txt’

If for whatever reason you aren’t getting a flashlog you may need to look into taking some simple modifications to your mm.cfg file.’ Otherwise you should be ready to make your alias command.

We want to put our alias command in our shell profile so that the shortcut will be available for us automatically when we open up terminal. To do this launch a new terminal window and type:
nano ~/.bash_profile

Nano works like a regular text editor, so simply paste the alias command below any existing statements in the document, be sure to replace your system username with your actual user name:
alias fl='tail -F /Users/[your system username]/Library/Preferences/Macromedia/Flash\ Player/Logs/flashlog.txt’

Now that you’ve done that hit ctrl-o to save the changes you’ve just made to the file and ctrl-x to exit nano. Now close the terminal window and open a new terminal. Type ‘fl’ and press enter. You can now see the live output as any instance of the player writes output to the flashlog. If you want to stop viewing output just hit ctrl-c while you’re in the terminal window to close the stream.

What the presenter initially did was build out a traditional presenter class to extend the model and provide two methods to find possible status and priority objects from the database. This requires the author to delegate class methods from the model that the Presenter class could use. It also requires us to wrap any instance variable of the child object in the presenter class before we pass it to the view.

class StoryPresenter

  def initialize(story)
    @story = story
  end

  delegate  :id, :class, :errors, :to_param, :new_record?,
            :to => :@story

  def possible_statuses
    @statuses = Status.find(:all).map{ |s| [s.name, s.id] }.unshift []
  end

  def possible_priorities
    @priorities = Priority.find(:all).map{ |e| [e.name, e.id] }.unshift []
  end

  def method_missing(name, *args)
    @story.send name, *args
  end

end

And then the implementation in the controller looks something like this:

def create
  story = @project.stories.build(params[:story])
  respond_to do |format|
    format.js do
      @story = StoryPresenter.new story
      render :action => "stories/new" unless story.save
    end
  end
end

A member in the audience suggested that instead of treating the presenter as a traditional presenter object we simply write it as a module. Then we no longer would have to delegate the methods from the model and instead of wrapping any instance variable of the child class we could just extend it. The argument for this is clear. It’s less code, and it’s more flexible.

module StoryPresenter

  def possible_statuses
    @statuses = Status.find(:all).map{ |s| [s.name, s.id] }.unshift []
  end

  def possible_priorities
    @priorities = Priority.find(:all).map{ |e| [e.name, e.id] }.unshift []
  end

end

And then the implementation in the controller looks something like this:

def create
  @story = @project.stories.build(params[:story])
  respond_to do |format|
    format.js do
      @story.extend StoryPresenter
      render :action => "stories/new" unless @story.save
    end
  end
end

However, the arguments against using a presenter as a mixin are more philosophical. If we’re using the presenter pattern we should encapsulate only what we need the view to use explicitly to prevent logic leaking into the view or the controller by other authors. By treating the Presenter object as a class and explicitly delegating the model methods we do just that. To utilize further methods of the model we would need to return to the presenter object and extend it there as opposed to just sliding extraneous logic into our controller or view.

In my presentation I briefly explained the concept of syndication via RSS and Atom - then touched on a high level overview of what a CMS system is used for. This was mainly to acknowledge the fact that not that many people are keen on the how or why of RSS. After demystifying the essential technologies involved, I focused on what blogging is really about. You can check out my slides below or view it in fullscreen.

• Disclaimer: You can click through them to proceed, but you can’t step back. This is due to a shortcoming in Keynote’s export to flash functionality. I wrote a viewer tool to load the .swf file created by keynote to preload it, but I could not interact with the movie itself as it’s an older format of SWF.

Use the Minimum Necessary to Communicate Meaning

Unfortunately, life is not so simple for the HTML author. Technology binds us to complications that create an environment that is less precise, less absolute, than merely writing a sentence. But if you can put the pressures we face from design implementation and browser support aside to focus on the basic semantic meaning; you will find that the aforementioned complexity is quite easy to deal with by incorporating small tweaks to your HTML. Here are two primary points in regards to the over complexity of HTML when thinking in terms of implementation as opposed to meaning.

• Writing HTML based purely on semantic meaning results in much clearer and flexible HTML that is easier to style and maintain.
• Complications during implementation are best tackled by adding superfluous markup to correct a problem as it arises rather than preemptively.

Only Add Superfluous Markup After Challenges Arise

Here is an example. Let’s say we have a body of content containing two unsorted lists with four items a piece. Now let’s say we want the unsorted lists in this body of content be styled differently from the general rules we have already applied. If we wanted the absolute most flexibility, we could have preemptively given each list item (<li>) it’s own class. That would be a total of eight elements with additional markup. We could reduce this to only two elements by simply applying a class to the unsorted lists (<ul>) and leaving the list items bare. Or, provided the body of content is encapsulated in it’s own HTML element to semantically describe the associations between the content elements, we could give the containing object a class or ID. Let’s say this body of content is the secondary content on the page. We could give the encapsulating div a class, thus reducing the amount of marked up elements from eight to one.

Only Use Containing Elements to Construct Associations

It’s far to easy and common to find html documents that have nearly every individual element wrapped in it’s own division (<div>) but this is a terrible breakdown in semantics. These excessive containers create meaningless layers of information that add no semantic value to the document. Elements certainly need to be packaged into other containing elements but only when they need to be associated to each other.

• There should never be a time when a lone element is enclosed in it’s own containing element.
• If an element is alone in a container - it should be strong enough to stand on it’s own and the containing element should be eliminated.

Take this blog as an example. This post contains many headings, paragraphs, and unsorted lists. It makes sense to enclose the content of this entry into it’s own division to symbolize that all of these various elements are part of a larger body of content. A single heading, paragraph, or bullet point in this post could not stand on it’s own to communicate the message of this article. Think about that when trying to make sense of when you should or should not apply a containing element. In other words, when writing a long novel you would not put every single sentence on it’s own page. Wrapping every single paragraph, image, and list of your content into a <div> is not so different.