Design

What if you’re actually terrible at what your real job is?

, , 2 Comments

So this may be very Merlin Man (site, twitter, podcast1, podcast2, and podcast3) inspired, but I have to ask it, just for everyone's sanity: What if you're actually terrible at what your real job is?

Let's say you're hired to build websites. sure. You're hired to build websites. But as Horace Dediu (podcast)  points out, a lot of what we need to look at is the "Jobs to Be Done" and when you look at it in that perspective, your Job to Be Done is really to solve their communication issue.

That's right. You're not building a website, but communicating information. Be it "This is good" or "That is bad", or just "Buy this widget", the job you are doing for your employer is helping them to disseminate information.

If you get up every day, build exactly what they tell you to build, exactly the way they say, there's two very, very real possibilities of what is happening:

  1. You're viewed as nothing more than a production worker
  2. You're terrible at actually solving the problems given to you, and thus become #1

Sure. You have to be able to make things pretty to be a designer, and you have to be able to code to be a programmer, but you have to be able to problem solve to be effective at either.

So, what do you do if you decide you're terrible at your job?

Get better.

How to build truly responsive images

, , , , 2 Comments , , , , ,

UPDATE: it looks like Scott Jehl has already beaten me to the punch, so check out his github project!

So, I was almost asleep, and this idea popped into my head. I want to write it down for two reasons:

  1. So I don't forget it.
  2. To see if anyone else agrees, disagrees, or sees any flaws in the idea.
Basically, I think I have figured out how to make images ridiculously responsive
  1. in a syntax that is logical and 
  2. in a way that can be powered by javascript and 
  3. fails gracefully to non-javascript supporting clients
The code starts out as simple as:
<image data-alt="Some image" data-width="300px" data-height="300px"
  id="my_image" class="some_class">
 
  <source src="/images/high-dpi/image.jpg"
    media="screen and (-webkit-device-pixel-ratio: 2.0)" />
  <source src="/images/print-dpi/image.jpg" media="print" />
  <source src="/images/regular-dpi/image.jpg" />
  <img src="/images/regular-dpi/image.jpg" width="300"
    height="300" alt="Some image" />
</image>

With no javascript, nothing but the <img> tag is displayed, and everything is happy.

With javascript, we run a system which turns it into the following (this becomes easier if we can evaluate media queries in JS, but I'm not sure if we can do that, so I'm showing an alternate way):

<style>
  #my_image {
    background-image: url('/images/regular-dpi/image.jpg');
    background-repeat: no-repeat;
    background-size: 300px 300px;
  }
  @media print {
    #my_image { 
      background-image: url('/images/print-dpi/image.jpg');
    }
  }
  @media screen and (-webkit-device-pixel-ratio: 2.0) {
    #my_image {
      background-image: url('/images/high-dpi/image.jpg');
    }
  }
</style>
<image data-alt="Some image" data-width="300px" data-height="300px"
  id="my_image" style="width: 300px; height: 300px;">
</image>

And now for the fun part - we can use document.getElementById('my_image').style.backgroundImage to get the right image!

This means that the last and final step then turns into:

<image data-alt="Some image" data-width="300px" data-height="300px" id="my_image">
  <img style="width: 300px; height: 300px;" src="/images/high-dpi/image.jpg"
    alt="Some image" width="300" height="300" />
</image>

Which should make it happy with screen readers and other similar systems.

This approach has a few distinct advantages:

  1. It leverages existing tools for defining when to load a particular image (media queries)
  2. It provides a graceful fallback for no javascript support
  3. It (hopefully) will be relatively close to whatever is selected for moving forward in a browser integrated solution, as it fits with the patterns already established.

So that's it. That's my master plan. What do you think?

How to fix the heck out of your Brother Control Center in OS X!

, , 11 Comments


If you have (or use) a Brother printer, you know EXACTLY what I am talking about.

EVERY time you restart your computer, you get the obnoxious control center which wants to run an install (on a printer you probably don't have connected) and takes a minimum of 2 (3 in my case) clicks to dismiss, and it's slow to boot!

Then you remember, click on the system icon, go to preferences, uncheck display at start up, hit ok, and you're done.

Then you reboot again and BAM! There's Brother right back in your face with the obnoxious control center again.

You angrily click through to close it out, go BACK to preferences, UNcheck the startup option, and hit Ok. Now, because you're NOT crazy, it's time to make sure it saved what you did. You go BACK to preferences again AND IT IS STILL CHECKED!

Come ON!

But let me share a secret with you.

Let me save your sanity!

Open up a terminal, and type the following:

mkdir ~/Library/Preferences/Brother/

Now, go back, one last time, into Preferences, and uncheck on startup, and press Ok.

Ok, fine, you can go check it again, but look! It's listened to you!

You're welcome!

How to build a better date widget in symfony with jQuery

, , , , No Comments , , , , , , ,

We're going to step things up a notch with this one, so hang on for the ride, because for those of you not already well versed in symfony and jQuery, there will be a lot of new information, and it will go pretty quickly, but I will try to make sure to keep everyone caught up. This is another post I hinted towards back when I first wrote about symfony widgets. Right, so, on to the fun!

First things first, let's talk about requirements. My only real requirement is that it must be seamless. We must be able to only implement the widget, and have everything else work exactly as intended. For a date widget, this means when the user clicks that submit button, an array with 'month', 'day', and 'year' must be sent back. Not a string, not JSON, just that basic array.

It's for the above reason that we will need to make a widget on top of the basic jQuery UI Datepicker Widget. The Datepicker alone would just return a string when we submitted the form, which would then require at least a custom validator, if not much more. So to simplify things later, we'll put in more effort now.

There are four things we will be doing in this tutorial to make this happen. Here's a quick overview:

  1. Set up majaxJqueryPlugin to give us our jQuery/jQuery UI base
  2. Set up a new module for us to use with the widget tutorials
  3. Create our widget class
  4. Create our jQuery UI widget that goes along with our widget class

1. Setup majaxJqueryPlugin

We're using my plugin for two reasons:

  1. It's my blog, so of course, I'm using my plugin
  2. We need jQuery UI, both the JavaScript and the CSS, and majaxJqueryPlugin provides that right away

Setting it up is easy:

cd plugins
wget -O majaxJqueryPlugin.zip http://jmather.com/wp-content/plugins/download-monitor/download.php?id=4

Now we add the plugin to our Project Configuration. Open up your config/ProjectConfiguration.class.php file, and place this line somewhere within your setup() function:

    $this->enablePlugins('majaxJqueryPlugin');

And one last step, we need to publish the assets:

./symfony plugin:publish-assets

Alright, now we're ready to move on to the good stuff.

2. Setting up our plugin

Now we need to make a new plugin, and set up a few directories for future use. It's pretty self-explanatory so we'll cut right to the code, and come back afterwards to talk about some of the extras.

./symfony generate:plugin majaxWidgetPlugin
mkdir -p plugins/majaxWidgetPlugin/web/js
mkdir -p plugins/majaxWidgetPlugin/lib/widget

We made our plugin, then we made the directory our jQuery plugins will go in, and the directory where we will store our widgets. The -p flag means "no error if existing, make parent directories as needed" which saved us a few mkdir commands.

3. Making our symfony widget

Now open up plugins/majaxWidgetPlugin/lib/widget/majaxWidgetFormDate.class.php and here's our code:

<?php
 
class majaxWidgetFormDate extends sfWidgetFormDate
{
  public function render($name, $value = null, $attributes = array(), $errors = array())
  {
    $sfContext = sfContext::getInstance();
    $resp = $sfContext->getResponse();
    $resp->addJavascript('/majaxWidgetsPlugin/js/jquery.majax.dateselector.js');
 
    $id = $this->generateId($name);
 
    $txt = ($this->getOption('can_be_empty') == true) ? 'true' : 'false';
 
    $display = '<div id="'.$id.'"></div>';
    $display .= '<div id="'.$id.'_ctrls">';
    $display .= parent::render($name, $value, $attributes, $errors);
    $display .= '</div>';
    $display .= '
<script type="text/javascript">
$(function() {
  $(\'#'.$id.'\').majaxdateselector({can_be_empty: '.$txt.'});
});
</script>
';
    return $display;
  }
}

So, to start out, we extend sfWidgetFormDate, as that will make the controls we need to manage a date submission. The only change we need to do, is to override the render function, which will let us add some custom code around the standard output, to allow us to more easily control the display.

The first thing we do in the render function is to include the required JavaScript. Some will say the widget shouldn't know about the JavaScript, but I say, if the widget shouldn't know... who should? We want to make this as transparent as possible, so why should we have to also remember to add a JavaScript include to use this widget?

Next, we grab our generated ID, and figure out our options (i.e. can the date be null) that we can pass along to Datepicker. After that we wrap the whole deal in a containing div, and then wrap the native controls in another specific div. You will see why we did this in a minute. Lastly, we write the JavaScript to activate the widget.

4. Making our jQuery Plugin

As is the standard, I'll show you the code, then highlight portions that are interesting. This file goes in plugins/majaxWidgetPlugin/web/js/jquery.majax.dateselector.js

(function($) {
        $.widget('ui.majaxdateselector', {
                version: '1.0.0',
                eventPrefix: 'majax.dateselector',
                options: {
                        can_be_empty: false,
                        datepicker_opts: {
 
                        }
                },
                _create: function() {
                        this.options['id'] = $(this.element).attr('id');
                        this._hide_real_ctrls();
                        this._build_facade();
                        return this;
                },
                _build_facade: function() {
                        $(this.element).html('<input size="10" type="text" id="'+this.options['id']+'_display" />');
                        var tfDisplayUpdate = function(widget) {
                                return function() {
                                        widget._update_ctrls(this.value);
                                }
                        }
 
                        $('#'+this.options['id']+'_display').change(tfDisplayUpdate(this));
 
                        var m, d, y;
                        m = $('#'+this.options['id']+'_month').val();
                        d = $('#'+this.options['id']+'_day').val();
                        y = $('#'+this.options['id']+'_year').val();
                        if (parseInt(m) > 0 && parseInt(d) > 0 && parseInt(y) > 0)
                        {
                                $('#'+this.options['id']+'_display').val(this._zero_pad(m, 2)+'/'+this._zero_pad(d, 2)+'/'+y);
                        }
                        $('#'+this.options['id']+'_display').datepicker(this.options['datepicker_opts']);
                        if (this.options['can_be_empty'])
                        {
                                $('#'+this.options['id']).append(' <input type="button" id="'+this.options['id']+'_empty" value="Clear" />');
                                $('#'+this.options['id']+'_empty').button();
                                var tfClear = function(widget) {
                                        return function() {
                                                widget._clear_display();
                                                return false;
                                        }
                                }
                                $('#'+this.options['id']+'_empty').click(tfClear(this));
                        }
                },
                _zero_pad: function(num,count)
                {
                        var numZeropad = num + '';
                        while(numZeropad.length < count) {
                                numZeropad = "0" + numZeropad;
                        }
                        return numZeropad;
                },
                _clear_display: function() {
                        $('#'+this.options['id']+'_display').val('');
                        $('#'+this.options['id']+'_month').val('');
                        $('#'+this.options['id']+'_day').val('');
                        $('#'+this.options['id']+'_year').val('');
                },
                _update_ctrls: function(val) {
                        var vals = val.split('/');
                        if ((val == '' || vals.length != 3) && this.options['can_be_empty'])
                        {
                                $('#'+this.options['id']+'_month').val('');
                                $('#'+this.options['id']+'_day').val('');
                                $('#'+this.options['id']+'_year').val('');
                        }
 
                        var m, d, y;
                        m = vals[0];
                        d = vals[1];
                        y = vals[2];
 
                        if (parseInt(m) > 0 && parseInt(d) > 0 && parseInt(y) > 0)
                        {
                                $('#'+this.options['id']+'_month').val(parseInt(m));
                                $('#'+this.options['id']+'_day').val(parseInt(d));
                                $('#'+this.options['id']+'_year').val(parseInt(y));
                        }
                },
                _hide_real_ctrls: function() {
                        $('#'+this.options['id']+'_ctrls').css('display', 'none');
                },
                _show_real_ctrls: function() {
                        $('#'+this.options['id']+'_ctrls').css('display', null);
                },
                destroy: function() {
                        this._show_real_ctrls();
                        ('#'+this.options['id']).html('');
                        $.Widget.prototype.destroy.call(this);
                        return this;
                }
        });
})(jQuery);

You know, looking over, it's pretty clear, I feel, what most parts do. The functions "_hide_real_ctrls", and "_show_real_ctrls" hide and show that wrapping div we built around the original controls, so we can keep them in play, but not have to worry about controlling them. The "_build_facade" function builds our fake interactive Datepicker object, and optionally our 'Clear' button, if our date is allowed to be empty. Functions "_clear_display" and "_update_ctrls" to exactly as you would expect. Cure functions "_create" and "destroy" are from the jQuery UI Widget framework, and are called ... can you guess when? 🙂

We're done!

Once you're done, you can replace any sfWidgetFormDate instance with a majaxWidgetFormDate instance, and everything else is handled. A little bit of effort up front, and many rewards down the road!

How to customize sfGuardUser in sfDocrineGuard

, , , 10 Comments , ,

One of the questions I see quite frequently is "How do I customize the user management interface for sfDoctrineGuard?" There are many different ways to go about it, but let me tell you about mine.

If you know me, you know I'm about attention to detail. I want the absolute cleanest solution you can come up with, and then I want it to look polished. So what you're about to see will be quite a bit more involved than you would normally expect for such a tutorial, but I believe you will agree, at the end, that it was well worth the trip.

The first step is to get ready to customize. It's easy, I promise. Here we go!

mkdir apps/backend/modules/sfGuardUser
mkdir apps/backend/modules/sfGuardUser/config
cp plugins/sfDoctrineGuardPlugin/modules/sfGuardUser/config/* apps/backend/modules/sfGuardUser/config/

That's all you need to do, to begin customization!

Ok, so we're all set up to change our page... so what do we want to do?

To make it easier to follow along, we'll set our goal as the following: Add a 'Name' field to the user form.

This will take a few steps:

  1. Create our sfGuardUserProfile table and object.
  2. Add a great piece of useful code to BaseFormDoctrine.class.php that lets us make this look awesome.
  3. Create a custom form that includes our new relationship in the mix.
  4. Modify the generator.yml we copied over to:
    1. Use that form
    2. Add the new field to the top of the form.
    3. One last little tweak.

That being said... let's get started!

1. We add our new object and relation. Open your config/doctrine/schema.yml file and add the following:

sfGuardUserProfile:
  tableName: sf_guard_user_profiles
  columns:
    user_id: { type: integer(4), primary: true }
    name: { type: varchar(255) }
  relations:
    User:
      local: user_id
      class: sfGuardUser
      type: one
      foreignType: one
      foreignAlias: Profile
      onDelete: CASCADE

Note: pay special attention to integer(4). If you forget this, MySQL (and I assume other databases) won't be able to build the relation properly as the field types will not match.

Now we need to rebuild things. If you don't know how to do a migration, here's the code you want:

./symfony doctrine:generate-migrations-diff
./symfony doctrine:migrate
./symfony doctrine:build --all-classes

Your sfDoctrineGuardUserProfile is ready to go, so let's build our new admin form.

2. Add embedMergeForm to BaseFormDoctrine

The embedMergeForm function originates from (I believe) Roland Tapken of Cybso in this post. It's a great piece of code. It gives us the function of embedded forms, with the look of merged forms. Here is the code I do (also adapted with one of the fixes from the comments section):

<?php
// File: lib/form/doctrine/BaseFormDoctrine
 
/**
 * Project form base class.
 *
 * @package    dcms
 * @subpackage form
 * @author     Jacob Mather
 * @version    SVN: $Id: sfDoctrineFormBaseTemplate.php 23810 2009-11-12 11:07:44Z Kris.Wallsmith $
 */
abstract class BaseFormDoctrine extends sfFormDoctrine
{
  /**
   * Embeds a form like "mergeForm" does, but will still
   * save the input data.
   */
  public function embedMergeForm($name, sfForm $form)
  {
    // This starts like sfForm::embedForm
    $name = (string) $name;
    if (true === $this->isBound() || true === $form->isBound())
    {
      throw new LogicException('A bound form cannot be merged');
    }
    $this->embeddedForms[$name] = $form;
 
    $form = clone $form;
    unset($form[self::$CSRFFieldName]);
 
    // But now, copy each widget instead of the while form into the current
    // form. Each widget ist named "formname|fieldname".
    foreach ($form->getWidgetSchema()->getFields() as $field => $widget)
    {
      $widgetName = "$name-$field";
      if (isset($this->widgetSchema[$widgetName]))
      {
        throw new LogicException("The forms cannot be merged. A field name '$widgetName' already exists.");
      }
 
      $this->widgetSchema[$widgetName] = $widget;                           // Copy widget
      $this->validatorSchema[$widgetName] = $form->validatorSchema[$field]; // Copy schema
      $this->setDefault($widgetName, $form->getDefault($field));            // Copy default value
 
      if (!$widget->getLabel())
      {
        // Re-create label if not set (otherwise it would be named 'ucfirst($widgetName)')
        $label = $form->getWidgetSchema()->getFormFormatter()->generateLabelName($field);
        $this->getWidgetSchema()->setLabel($widgetName, $label);
      }
    }
 
    // And this is like in sfForm::embedForm
    $this->resetFormFields();
  }
 
  /**
   * Override sfFormDoctrine to prepare the
   * values: FORMNAME|FIELDNAME has to be transformed
   * to FORMNAME[FIELDNAME]
   */
  public function updateObject($values = null)
  {
    if (is_null($values))
    {
      $values = $this->values;
      foreach ($this->embeddedForms AS $name => $form)
      {
        foreach ($form AS $field => $f)
        {
          if (isset($values["$name-$field"]))
          {
            // Re-rename the form field and remove
            // the original field
            $values[$name][$field] = $values["$name-$field"];
            unset($values["$name-$field"]);
          }
        }
      }
    }
 
    // Give the request to the original method
    parent::updateObject($values);
  }
}

Save your file, and let's move on to step three.

3. Build our new interface form.

Let's make a new file, lib/form/doctrine/myGuardUserAdminForm.class.php, and fill it with the following:

<?php
 
class myGuardUserAdminForm extends BasesfGuardUserAdminForm
{
  public function configure()
  {
    $uprof = new sfGuardUserProfileForm($this->object->Profile);
    unset($uprof['user_id']);
    $this->embedMergeForm('Profile', $uprof);
  }
}

Ok! Hard stuff done! Last little bits now!

4. Modifying the generator.yml to use our new form, and expose our new field.

All you have to do now is update the form section of the generator.yml to look like the following:

      form:
        class: myGuardUserAdminForm
        display:
          "NONE":                   [Profile-name, username, password, password_again]

Now all you have to do is clear your cache, and go to your sfGuardUser form page, and you will see your new field!

5. Cleaning up messes.

Remember back in the schema.yml where we specified the onDelete: CASCADE? Bad news, that probably didn't take care of it. There's a bug somewhere between Symfony and Doctrine where sometimes foreign key constraints aren't always handled appropriately. To counteract that, we will just run an SQL command to correctly establish the relationship so that when users are removed, we also remove their auxiliary profile data.

Here's your magic:

ALTER TABLE sf_doctrine_guard_user_profiles ADD CONSTRAINT sf_doctrine_guard_user_profiles_user_id_sf_guard_user_id  FOREIGN KEY (user_id) REFERENCES sf_guard_user(id) ON DELETE CASCADE;

And we're done! See? It was quite a long trip, but I hope you agree with me, the result is worth it.

02/16/2011 - Note: A thanks to hectorh30 from #symfony for pointing out an error in step three regarding the name of the profile form. It has been corrected.

02/12/2011 - Note: And in step one about paths. Thanks hectorh30!

03/03/2011 - Note: Thanks to dmclark for pointing out myDoctrineGuardAdminForm should be myGuardUserAdminForm

03/28/2011 - Note: Thanks to Richard Linkster for pointing out a copy command that was all busted up.

1 2 3