Phil Sturgeon philsturgeon

We had a long discussion about all of this over email (should have done that sooner) and here are most of the points for anyone reading this:

If you want to add a line in a twitter bio about Laravel, DO IT. If you want to put on your LinkedIn profile that you use Laravel on your projects, DO IT. You’re not hurting PHP. You’re helping it and anyone who was around during PHP’s dark days should know this.

I never suggested you shouldn’t do it, or that you would “hurt PHP”. I said branding yourself as a “Laravel developer” first is damaging to yourself. Lots of people branded themselves as a CodeIgniter developer for a while. What good has that done them now?

People will not be confused by this. Employers will not be confused by this. As someone who has probably looked at 1000 resumes for Laravel developers I’ve never seen even one where the only reference to anything PHP or development related is Laravel.

Here’s one. http://www.linkedin.com/profile/view?id=263426041&authType=OUT_OF_NETWORK&authToken=a0_e

Following the assumption that part of what makes something a "framework" is that it dictates architecture, the "sample application" or "application layer" is what should be called the "Framework". In which case those people would label these repos differently.

https://github.com/laravel/laravel/ - This is the "framework"

https://github.com/illuminate - This is the "component vendor", where multiple "components" or "packages" can be found.

https://github.com/laravel/framework - This is... something other than "framework". FuelPHP use foundation, or maybe "kernel", or... something.

For other projects this distinction is different.

Option A)

Null content items break things.

foreach ($foos as $foo) {
    if (! $foo instanceof Face) {
        throw new Exception ('AAAGGGGGHHH!');
    }
}

Moved to

FORMAT: 1A
# My API

## GET /places

+ Response 200 (text/plain)

As a refinement to his previously published book, the author of "Building APIs You Won't Hate" found that API books and training tends to introduce documentation, testing and caching as an after-thought, as if these are not important. However, some new experiences have shown that API development works best when these items are thought out first, as well as including a strong pragmatic approach to ensure the API solves real problems without getting stuck on the theory of how to "properly" create it.

Other pragmatic talking points include: Why and how documentation first can stop your team(s) from getting violent, when is REST not what you want, why is hypermedia sometimes a distraction, convenient ways to avoid versions in your API or at least postpone it, and comprehensive but simple endpoint integration testing beyond trivial examples.

	$ python
	Python 2.7.5 (default, Oct 21 2013, 17:28:33)
	[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
	Type "help", "copyright", "credits" or "license" for more information.
	[>>> [1, 3, 5] + [345, 6]
	[1, 3, 5, 345, 6]
	>>>

	$ php -a
	Interactive shell

	Traceback (most recent call last):
	File "facebook_cover.py", line 44, in <module>
	photo = graph.put_photo(image_resource, album_id=payload['page_id'])
	File "/task/__pips__/facebook.py", line 219, in put_photo
	data = urllib2.urlopen(req).read()
	File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
	return _opener.open(url, data, timeout)
	File "/usr/lib/python2.7/urllib2.py", line 400, in open
	response = self._open(req, data)
	File "/usr/lib/python2.7/urllib2.py", line 418, in _open

	package main

	import (
	"testing"
	"io"
	"io/ioutil"
	"net/http"
	"net/http/httptest"
	)

	<?php

	$foo = "global";

	include "namespaced.php";

	echo $foo; // Outputs: "something"