Previous

Recent From Articles

Find My Mac – “No location a...

Find My Mac – “No location available” Posted by on Jun 20, 2013

Recent From General Updates

Let’s Try This Again

Let’s Try This Again Posted by on Aug 20, 2012

Recent From Tutorials

Design Patterns: Observer

Design Patterns: Observer Posted by on Nov 9, 2012
Next

Recent Posts

Find My Mac – “No location available”

I just noticed a funny quirk with the “Find My Mac” feature on my Mac Mini. For months my Mini has displayed a message, “No location available”, when I look at the locations of my devices through iCloud. It used to work fine. I thought that perhaps this had something to do with my ISP, but all of my other devices worked fine.

It occurred to me that the iPhone will not work with GPS if WiFi is off. I’ve had my mini wired to an ethernet switch for months, and I turned off the wireless network adapter when I did so thinking it was unnecessary wireless noise in my network. As it turns out, the Mini needs that adapter turned on for geolocation as well. I turned it back on and refreshed iCloud. There’s my mini!

read more

Design Patterns: Observer

One of my favorite design patterns is the observer.  Like most patterns, this serves to encourage developers to create loosely coupled code.  Properly implemented, the observer allows you work with a single object and inform related processes of changes that may require action to be taken.  One of the places where this can be incredibly useful is in committing models to storage.  Think about it – there’s a good chance you aren’t just saving and retrieving information to a database.  In many of the applications that I’ve dealt with, saving information in the modeling layer means I’ll need to deal with caching, search,  email notifications, statistics, and more.  Trying to cram all of this into the data access layer might look something like this:

As you can imagine, once you replace all of the comments above with actual code, these methods can get pretty heavy.  This is far from the OO ideal of a single purpose for a single class.  Now what happens when you have to save a large series of records?  How could you take a part of this process and make it asynchronous?  The observer pattern comes to the rescue.  For this example, I’ve chosen to implement the Standard PHP Library’s built in observer interfaces.

Now adding additional observers to handle data changes is easy.  We can add a few more classes and do something like this:

 Output:

So now with observers, you can create a workflow for your data specific to the situation.  Add as much or as little as you need to.  Each of the observers can go off and do what they need, such as engaging third party services like Gearman to create asynchronous offline tasks.  What’s more, all of these are much smaller, simpler classes that don’t need to know anything about what is going on elsewhere in the application to perform their given tasks.

read more

Design Patterns: Singleton

The singleton design pattern is probably one of the most basic patterns in use.  Many consider this an anti-pattern because developers tend to over-use it and create code that is really just procedural code in disguise of OO.  Still, this pattern can be useful in cases where the developer would like to reuse a single instance of an object with expensive resources, such as a database connection.

Now in order to use the object, you use the static instance method to retrieve it:

An interesting alternative to the singleton pattern is to use a dependency injection container (DIC).  The DIC works by keeping a registry of instantiated objects and providing them to various parts of the application upon request.  See http://framework.zend.com/manual/2.0/en/modules/zend.di.introduction.html

read more

CentOS Setting Time with NTP Date

From a bash terminal type:

# ntpdate us.pool.ntp.org

read more

Method Chaining in PHP

I saw this come across Stack Overflow today, and wanted to elaborate.  Method chaining is a particularly useful technique in modeling objects where the developer may call a series of methods that typically have no return value.  Let’s use a model Person object as an example:

Now if we wanted to set all of the properties of a newly instantiated Person object, we need to split the calls up like so:

 

But I like to type less.  That $person in there happens over and over again.  Let’s make it go away.  Revise the Person class, adding “return $this;” to the setter methods:

 

Now when we set the same properties as above, we can skip the reference to the object over and over:

 

read more