Archive for the ‘PHP’ category

Magento with Facebook Connect

August 6th, 2009

My brother wrote a Magento module recently – the Facebook Connect Module.  It’s pretty straightforward, and allows you to make it easier for shoppers to enter in their information in to your Magento store.  When checking out, they can connect their Facebook info, using the Facebook Connect process, and their information will be imported in to your Magento store.  It’s not free – there is a charge for this, but the source code is included, not obfuscated or encrypted, so if you need to extend it or make customizations, you can.

Possibly one of the more interesting things it does: “Alerts users via Facebook notifications to changes in their order.”  This sort of social networking integration with ecommerce sites will possibly be more common in the future – perhaps some other sites are doing it already that I don’t know about?

You can also just sign up for the mailing list to be notified about new features and such over at http://biz.metrofindings.com/main.page/facebook_connect_magento_module.html

What other sorts of Magento tie ins to social networks would you like to see?

Traveling for a few days – London and Copenhagen

May 10th, 2009

I’ll be traveling the next 10 days, including time in London May 12-17 and Copenhagen May 18-20.  If any PHP or web people would like to get together for a drink/meal/chat/podcast/whatever, let me know.  I’m planning on attending one of the Dojo dinner activities (I think it’s Thursday May 14) so if you’re already going to that, awesome  :)

Best way to ping me is probably email – mgkimsal@gmail.com, though skyping me at mgkimsal should ring thru to my phone as well while I’m over there.

PPP PHP question v2 – the humbler post

March 22nd, 2009

Obviously I rubbed some people the wrong way, and didn’t explain my question(s) clearly enough from the outset, then got wrapped up in taking some offense from some of the responses.  Reviewing everything today I can see where I could have responded differently, and more clearly, earlier on.  Apologies to anyone who was offended (if anyone was).

I do think the original point(s) were somewhat lost.  To the original poster who offered the banking analogy – thank you.  However, I don’t think it’s enough, and is clearly at odds with some of my other experiences with Java/Groovy.  Let me show two code samples here (assuming WP doesn’t mangle the code too much – I need to get one of those code display plugins in here!)

In Groovy (Java), if I run this:

===========================
class person {
private email = “person email”
protected phone = “person phone”
public name = “person name”
def showInfo() {
println this.email + ” ” + this.name + ” ” + this.phone
this.onlyInUser()
}
}
class user extends person {
private email = “user email”
protected phone = “user phone”
public name = “user name”
def onlyInUser() {
println “I’m in the user class definition”
}
def showInfo() {
super.showInfo()
println this.email + ” ” + this.name + ” ” + this.phone
}
}
def u = new user()
u.showInfo()
===========================
I get this output:

===========================
person email person name person phone
I’m in the user class definition
user email user name user phone
===========================

*All* the *this* property accesses are class-bound, it seems, but the this.onlyInUser() call still calls the method in the child class.

In C# (my C# isn’t hot, but this *seems* to be a correct re-implementation of the same logic) if I run :

===========================

using System;
class person  {
public string name = “person name”;
protected string email= “person email”;
private string phone = “person phone”;

public virtual void showInfo() {
Console.WriteLine(“In the person showInfo method”);
Console.WriteLine( this.name + ” ” + this.phone + ” ” + this.email);
}
}

class User : person {
public new string name = “user name”;
protected new string email= “user email”;
private new string phone = “user phone”;

public override void showInfo() {
base.showInfo();
Console.WriteLine(“In the user showInfo method”);
Console.WriteLine( this.name + ” ” + this.phone + ” ” + this.email);
}

// Main begins program execution.
public static void Main()
{
User u = new User();
u.showInfo();
}
}

===========================

I get

===========================

In the person showInfo method
person name person phone person email
In the user showInfo method
user name user phone user email

===========================

Running seemingly equivalent code in PHP (5.2.5)
===========================
<?php
error_reporting(E_ALL);
class person {
private $email = “private person email”;
protected $phone = “protected person phone”;
public $name = “public person name”;
public function showInfo() {
echo $this->email.” – “.$this->phone.” – “.$this->name.”\n”;
$this->onlyInUser();
}
}
class user extends person {
private $email = “private user email”;
protected $phone = “protected user phone”;
public $name = “public user name”;
public function onlyInUser() {
echo “I’m in the user class definition\n”;
}
public function showInfo() {
parent::showInfo();
echo $this->email.” – “.$this->phone.” – “.$this->name.”\n”;
}
}
$u = new user();
$u->showInfo();
===========================
I get the following output:

===========================
private person email – protected user phone – public user name
I’m in the user class definition
private user email – protected user phone – public user name
===========================

There’s clearly a difference here, and it’s likely related to an logical difference between super and parent.  My limited Java-fu and C#-fu being what they are, I’m not able to quite grok why there’s a difference in behaviour between the examples ago.

Hopefully this is humble enough to garner some collective wisdom.  I’m not bashing PHP here, nor anyone’s contributions or anything of the sort.  Simply asking – why are these behaving differently?

PHP PPP question

March 19th, 2009

Why does this work? Why does this show the email address?

#1
<?php
class person {
    private $email = “foo”;
    function showEmail() {
        echo $this->email;
    }
}
class user extends person {}
$u = new user();
$u->showEmail();

but this doesn’t?

#2
<?php
class person {
    private $email = “foo”;
}
class user extends person {
    function showEmail() {
        echo $this->email;
    }
}
$u = new user();
$u->showEmail();

Also, why does this work

#3
<?php
class person {
    private $email = “foo”;
    function showEmail() {
        echo $this->email;
    }}
class user extends person {
    function showEmail() {
        parent::showEmail();
    }
}
$u = new user();
$u->showEmail();

Actually, #2 is one that makes sense to me and I can explain.  The $email is private in the parent class, and is not visible in the child class.  With E_ALL on, I’d get a notice about ‘undefined property’.

The concept of $this in PHP seems, to the outside eye, to be capricious at best and somewhat broken at worst.  As someone who has to field questions on this sort of stuff, from developers with OO experience in other languages, trying to explain it (not even defend it, just explain it) is often difficult.

JavaScript magazine launched

March 8th, 2009

Finally, after much work, we’ve got the first issue of JavaScript magazine (affectionately known as JSMag) out.  Extra special thanks to Rebecca Murphey for her helping hand in an hour of need.  You can read about all the authors or take a look at the first issue or even grab yourself a sample PDF file.  Our first issue includes:

ExtJS: An Introduction

Brett Harris and Jed Brubaker walk you through just what ExtJS can do for you.

The Red Pill: Functional Programming in JavaScript

Follow Robert Fischer through the more esoteric side of JavaScript.

Unit Testing JavaScript

Join Matt Henry as he shows you how to unit test your JavaScript code using the YUI testing functionality.

Don’t be Alert!

Robert Cameron demonstrates the various ways of debugging your JavaScript code without resorting to the overused alert() function.

What’s new in jQuery 1.3

Rebecca Murphey takes us on a tour of the next functionality lurking in the latest jQuery release.

Community news

Catch up with the latest JavaScript news with Matt Henry.

We’re definitely on the lookout for contributors, so email editor@jsmag.com if you’re interested.

Seven things about me (reply to Ben’s post)

January 13th, 2009

I got ‘pinged’ by Ben Ramsey on this topic, so here goes:

  1. First computer was Sinclair ZX81 – 1K of RAM – soldered together from a kit ordered from UK.
  2. Played bass in a number of bands, including a blues band when I was 18 and next youngest guy was 37.  Played for several years with some friends from HS – ‘modern rock / alternapop’ stuff. I may even have a CD somewhere.
  3. Worked at a Kroger during a strike – had to cross the picket line and got shouted/spat at.  Fun times to make $6.50/hour.
  4. Played Paul McCartney in a Beatlefest band competition (yep, played left-handed).
  5. I despise the taste of beer, beer related drinks, and cooked vegetables (I don’t mean combined, I mean as three separate things).
  6. Had a small article published in “Compute!’s Gazette” in the mid ’80s dealing with ’80 column mode’ on the C128.
  7. Got an email reply from Warren Robinett for my fanboy email.
  8. Have never done one of these ‘things about me’ blog meme things before.
  9. Have a hard time stopping at 7 when making lists.

I don’t have anyone in mind to ‘tag’ who hasn’t been tagged (and who has a blog that I know of) but if I think of anyone, I’ll ping them.  :)

Me griping about PHP :) (closures this time)

December 21st, 2008

Yeah, that’s about all this post will be. I read an article from IBM developerworks on the upcoming 5.3 features, and something got my dander up: closures.

I first got acquainted with closures in Groovy last year, and love them. They make sense. The syntax is pretty easy, and feels natural in the language. Not so in PHP. Once again, inconsistencies are not just legacy issues in PHP – they are created anew for us to deal with for years to come.

Look at the example here:

class Dog
{
 private $_name;
 protected $_color;

 public function __construct($name, $color)
 {
  $this-&gt;_name = $name;
  $this-&gt;_color = $color;
 }

 public function greet($greeting)
 {
  return function() use ($greeting) {
   echo "$greeting, I am a {$this-&gt;_color} dog named
   {$this-&gt;_name}.";
  };
 }
}

Given that ‘anonymous function’ inside the greet() method is a closure, WHY NOT NAME IT THAT? The PHP Reflection API was updated to include a “getClosures()” method, but what would you get? They keyword “closure” doesn’t exist, but could have. Instead we now have the keyword “function” looking like two different entities – it looks like a function call when used with the () directly after it, and also has its traditional function fname() syntax still available.

I have to teach this stuff, and being explicit with a closure keyword would have saved a lot of headaches to come in explaining this stuff to people. Additionally, it would have been less to type.

Compare

return function() use ($greeting) {
 echo "$greeting, I am a {$this-&gt;_color} dog named {$this-&gt;_name}.";
};

with

return closure($greeting) {
 echo "$greeting, I am a {$this-&gt;_color} dog named {$this-&gt;_name}.";
};

What’s more explicit, easier to understand, and fewer characters to type? Given the recent namespace separator debacle (using \ as a namespace separator, and justifying it because it’s “fewer characters to type”), I can’t really understand the rationale behind the closure syntax.

To be fair, the closure syntax RFC was up at http://wiki.php.net/rfc/closures and I didn’t comment in time. So, I guess it’s all my fault. :( Beauty and elegance have never been PHP’s strong suit, but it seems people went out of their way to make this unintuitive and bulkier than it needed to be. :/

On a more broad note, I really think the bulk of these changes (closures, namespaces, etc.) should have been put in php6 only, not in the 5.3 series.  I understand the need for testing and such, but we’re implementing new functionality and defining how it is expected to work based on the current PHP5 Zend Engine.  Whatever useful changes that might make a PHP6 faster/better/whatever can’t easily be implemented because the ‘new’ features are all dependent on a core engine that’s already 5 years old, which it itself was built with an eye towards backwards compatibility to PHP3.  Strategically, it just feels like the wrong move.  But hey, what do I know, right?  I can’t write C code patches, so my views don’t really have much weight, do they?

New community site for Javascript developers and user groups

December 17th, 2008

Testing out the demand for a community site focusing on Javascript developers. When I was investigating the Javascript Magazine idea (still in the works – got some great contributors potentially lined up!) I realized that Javascript is everywhere, yet nowhere. There are few, if any, Javascript user groups or similar resources out there. There’s *loads* of books, and occasionally a few sessions at conferences, but no social ongoing stuff. So, I’m looking to start one.

Head over to http://jsusers.com and join up. The system is pretty open right now as to how it might be used. I’m anticipating people will use it to form topical or regional ‘groups’ to manage communication between themselves. That would be the best use, at least as far as I can tell right now. I’m using it to get some interest in a Raleigh area Javascript user group, and hopefully we’ll meet next month.

Groups for YUI, dojo, mootools and others would be great, as would groups for dealing with Javascript and particular technologies (Javascript integration with specific .Net or PHP apps, for example). Really, it’s open to what ever people want to make of it, but I’d like to see adhoc group creation. :)

Question? Comments? Leave them here or ping me at @jusers

Are traditional object models enough? Can we evolve usefulness in OO models?

December 15th, 2008

Just a quick thought here after looking at someone’s code I just stumbled on. This person had a “isReadOnly()” method inside of a generic “set” method which would allow them to determine if a property should be allowed to be modified or not.

It got me to thinking again how the traditional notion of “visibility” in OO is, imo, broken. Perhaps that’s going a bit far. It doesn’t address the day to day needs most developers have. I’d say more developers need some sort of a way of making properties “read only” than they do dealing with “public, protected, private” PPP notions which we get in traditional OO implementations. What PPP gives is all-or-nothing – you get full access to this property (or method) or you don’t get any at all.

Short port (I gotta run) – why do we not have some sort of default “read only” property modifier in OO implementations? The Groovy approach would be to create a setXXX() method that was empty, effectively overriding the default setXXX() method to not perform any manipulation at all. It’s not *bad*, and is pretty clear, but some modifier like, oh, I dunno:

readonly String name

would be useful, no?

Javascript Magazine – gauging interest

December 11th, 2008

I’m in the planning stages of a Javascript magazine, similar to the GroovyMag publication I’ve already got out.  Before jumping in too deep, I’m looking to gauge interest in the idea.  Are you interested in a monthly Javascript magazine?  If so, click the link above and sign up.  Or, just leave a comment below.  :)  Thanks!