Internet Strategy Guide

@auroraeosrose's talk. Going over definitions so that everyone is on the same page.

Everything uses streams

• include/require
• stream functions
• file system functions
• many other extensions

What is a stream in php? They allow you access input and output very generically. You can read and write linearly and may or may not be seekable. Comes in chunks of data. Think of a 15GB file, would you want to read that into memory? Of course not, PHP will laugh at you for being stupid.

Thank Sara Goleman and Wez Furlong for the awesomeness of streams.

Edit: Originally didn't get Wez's name in the presentation, he thankfully provided me with his identity.

(continue reading...)

Matthew Turland is presenting. If you haven't heard of him, you're a nub (k, not really but I really wanted to put that in a post somewhere). He's an auther for php|architect and author of Web Scrapign with PHP, a contributer to Zend Framework, lead developer of Phergie. So yeah, kind of a big deal. He currently works at Synacor which provides internet solutions to ISPs, media companies and advertisers.

The biggest change to SPL in 5.3 is the containers. Why containers? Arrays aren't always great. The underlying hash table algorithm is not always ideal for the task at hand.

We'll be looking at a lot of benchmarks. The code is available on github so you can compare the performance results for yourself.

(continue reading...)

Today's session is given by derick rethans, the author of xdebug so he might know what he's talking about.

Xdebug provides protections against things like stack overflow in PHP and infinite recursion. You can set this by setting the nesting level. It also provides a pretty formatted errors but not only is it pretty but it provides more information such as memory usage, time, function name and location on items in the call stack. It can also collect parameter information which shows the type with options to display the variable name (if possible) or values. It opts to minimal information to prevent crashing html displays with the browsers.

Another hot option is the ability to link to the files. The var_dump is overloaded to create a pretty, color-coded output. You can turn this off by setting the overload vardump option to 0.

(continue reading...)

We're starting with a map of the world showing the 24 major timezones. Timezone changes (daylight savings times) make things tricky. The abbreviations for timezones aren't enough to determine the user's timezone. EST can mean different things.

The 64-bit signed integer used internally provides more than enough time for us to use (+/- 90 billion years if I heard correctly). strtotime() and functions with timestamps have been replaced with classes (such as new DateTime()).

The bundled timezone database has 564 zones so far that isn't dependent on timezone abbreviations. They have the format Continent/Location or Continent/Location/Sublocation like Europe/Amsterdam. Updated database is released 20 times a year. Some changes are very sudden. Basically, you're timezone database is probably outdated.

(continue reading...)

Trying to record @akrabat's talk about zend_form but didn't get good camera placement. Won't be able to put up the video I do have until after Amsterdam. Will need to get a voice recorder instead.

Filters are destructive. This is important to know that. Validators only reject data. Decorators are used for form rendering. Apparently I'm not the only one confused by it because Rob Allen said we'll go over that extensively. Zend_Form decorators are a combination of Decorator and Strategy Pattern.

(continue reading...)

Josh Holmes is giving the keynote and is very insistent on enthusiasm. Talking about simple projects and used twitter as an example. Twitter may have been been written in a weekend by most of us, it is successful because it filled a niche. Seems like part of the talk will be analyzing why we say "I could of wrote that in a weekend" with an air of disdain.

Looking at the definition of simplicity. First few definitions talk about foolishness and naiveté but the last definition is where we focus on "clarity of expression" and "Austerity in embellishment."

(continue reading...)

Starting off the best practices with source control @lornajane asked who is using source control and how much of that is using distributed source control. I'm 2/2 so far. woot. For those who aren't familiar with source control, it creates a history and is a great collaboration tool.

Using source control is being discussed. You create a repository, add your project, check out your project, make changes. You can update to get changes from others then you commit it all back to the repository.

We're looking at an svn log and will be discussing distributed vs non-distributed systems. Demonstrating a sample diff.

Source control Tool

* Subversion (svn)

* Git (git)

* Bazaar (bzr)

* Mecurial (hg)

Difference ways to interact with source control. Lorna gives a shout out for all the command line user people and is now mentioning IDE plugins, Trac, Tortoise[SVN|Git|Bzr|Hg]. I need to see if there's a tortoiseBzr for OSX. I'm thinking of moving to Git since that gives my team more GUI tools, love Bzr but haven't found many tools. Done with that sidebar. On to Centralized Source Control.

(continue reading...)

K, trying a bit of live(ish) blogging. This will be interesting since this will be stream of thought on the tutorial as it goes on.

Todays tutorial is given by Arne Blankerts.

We're starting off with an over view of websecurity and what we'll be doing today. Looks like I missed questions, good thing I didn't have any.

We'll be getting source to look at, makes me wish I wasn't lazy and had set up an environment.

Starting off with types of security. Transport layer,infrastructure, data warehouse,interface design, user level and application level...those sort of things.

Remember to secure your infrastructure. Anecdote about a setup with default root of database was given. Keep in mind how you train users. Example error alerts training people to accept errors as ok and to click through.

(continue reading...)

Apparently my php-fu has become good enough that I've been asked to review books. So sometime in the future I will talk about Packt Publishing's book, "PHP Team Development". My complimentary copy is apparently in the mail, so hopefully I learn to read by then.

Seriously though, I hope this book will help me tweak my current team practices. Guess I'll find out after it arrives.

An interesting topic came up in #phpc today. It revolved around some issues I've been encountering in my latest code designs/structures. It also leads into some side topics that I will attempt to explore.

From my point of view, the discussion centered around what is the best 'default' visibility to use for methods. Another thing touched upon is the Open/Closed principle, which I think I subscribe to or may subscribe to(this depends on my ability to determine what half of the words in the entry mean).

Out of the whole discussion, here is the points I got (aka understood) out of it. Please correct me in the comments if I'm off base in any way.

Methods should only be public when necessary. This is to help reduce the amount of side-effects that can occur because of method overrides.

K, I can accept that and in thinking about my past code, I use to use protected more than private. I used public very sparingly.
Now I find, since I started unit testing, that I have a large amount of public functions than I've had in the past. That is because I can't figure out how to test private methods. One way that I can think of is to create public methods that allow you to test the private ones. Unfortunately, this makes me wonder why the method isn't public to begin with since it seems redundant and wasteful to have these public methods to access private methods.
Please note the key word methods, property accessors are a different story.
The best solution (I can think of) to testing private methods is Mock Objects. Unfortunately, even though I've started to use mocks/doubles more, I'm unsure if my implementation is correct. Until I'm confident in my understanding of mocks/doubles, I worry about having false positives in test results.

Another assertion that was made in the discussion was that private methods allow you to preserve the class' core functionality.
Unfortunately, no matter what the visibility of the method is, you're able to override it (and potentially mess with the core functionality you were trying to preserve).
Example:

class foo{
    private function foobar() {
        echo "foo\n";
        return "foo foo\n";
    }

    public function bar() {
        echo "w00t ";
        return $this->foobar();
    }
}

class bar extends foo{
    private function foobar() {
        return "bar\n";
    }

    public function baz() {
        echo $this->bar();
    }

    public function wut() {
        echo $this->foobar();
    }
}

$f=new bar();
$f->baz();
$f->wut();

By running the above code, you get:

w00t foo
foo foo
bar

If preservation of core functionality is your main concern, then you're better off using final.

So after all that rambling, you're probably wondering what I'm trying to get to. It still comes down to visibility's effect on inheritance. The way I see it, unless you declare the method as final, you can't lock down the parent functionality because private methods can still be overridden. Trying to figure out what level of visibility for a method is a situational call. There is no correct 'default' visibility. Sure private is safer because of least privilege but it makes testing a bear (or at least a bear at my current skill level in testing). Public potentially opens you up for abuse or misuse.

What I would still like to know is, how do you do class method visibility? How does that affect your testing methodology? Can someone give me an example (that isn't a singleton) where private is a better choice over protected? I like protected because it seems less limiting to me and my current coding style appreciates that degree of flexibility.