Share localhost over the internet with ngrok

One of the more annoying things when developing on your local computer is that your clients or friends can’t see what you develop. You can upload it on your web server or you can work directly on the web server but that is inconvenient and slow. So I was very happy to discover this great tool called ngrok. There are similar tools (localtunnel etc) but this one is really easy to use.

Who is your daddy is ngrok and what does it do?

Ngrok is a cool little program that creates a tunnel from the public internet ( to a port on your local machine. You can give this URL to anyone to allow them to try out a web site you’re developing without doing any deployment. Of course your local server has to run at the time of sharing but that is not a problem – you just leave your PC on.

How do I run this ngrok?

With ngrok it is super simple to expose a local web server to the internet. On Windows you just download ngrok.exe, unzip it some folder and then in command prompt (cmd) you just tell ngrok which port your web server is running on.

This is the most simple way (This opens port 8080 on your local machine to the internet). Type this in your command prompt:

ngrok 8080

You will see something like this :

Tunnel Status                 online
Version                       0.11/0.8
Protocol                      http
Forwarding           ->
Web Interface                 http://localhost:4040
# Conn                        0
Avg Conn Time                 0.00ms

Of course the port (in this case 8080) has to be the port that your localhost is running on. Now just give the generated URL (in our example to your client or friend and let them test out your application.

You can do a lot more with ngrok, like inspecting your traffic, XML/JSON syntax checking, replaying requests, requiring passwords to access your tunnels, accessing your tunnels over HTTPS, forwarding non-HTTP services, forwarding to non-local services and more.

Check out ngrok here.

Laravel 4 profiler – Log and display SQL queries

Laravel 3 had a cool profiler bundle called Anbu, written by Daylee Rees. It was written as a bundle but Taylor, creator of Laravel, liked it so it was eventually included in the Laravel core. Laravel 4, at the time of this writing, however has no such profiler included in the core. So how do we display database SQL queries for debugging?

Here are a couple of solutions:

1. Use Loic Sharma’s Profiler. It is a PHP 5.3 profiler based off of Laravel 3’s Anbu. I have not tried this yet so just follow the instructions there.

2. Try Profiler by Juy, a PHP 5.3 profiler for Laravel 4. Backend based on sorora/omni, fronted based on loic-sharma/profiler, some features inspirated from papajoker/profiler, some features written by Juy.

3. Create an event that will listen to illuminate.query. Open your routes.php file and add this at the bottom:

 Event::listen('illuminate.query', function($sql)

This will print every query on the screen on the place where it is called so it might not look pretty,especially in loops. Also you might not see the queries on the screen in some cases since they will be “hidden” in the HTML source code (so just view the page source to see them, they will usually be at the top of the page)

4. You can also display the last executed query by placing a code in front of the code that executes a query. For example let say we have this code in our controller:

// Grab all the users
$customers = Customer::orderBy('name','asc')->get();

Place the Event::listen code in front of that statement and you will see that query displayed on your screen.

// dump the next executed query and die (dd)
Event::listen('illuminate.query', function($sql)

// Grab all the users
$customers = Customer::orderBy('name','asc')->get();

Keep in mind that this will only display 1 query. If your statement calls more queries they will not get displayed.

5. Put the following code in the App::before filter to get a dump of your database queries:

DB::listen(function($sql, $bindings, $time)

6. There is another “trick” that I use sometimes (because having SQL queries displayed all the time is not practical and it messes up the code and design): I intentionally make an error in my SQL statement. For example here I mistyped type as tyspe:

$contracts = Contract::where('tyspe','=',0)->orderBy('note','asc')->get();

Since tyspe doesn’t exist Laravel returns an error,showing me the complete SQL statement:

SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘tyspe’ in ‘where clause’ (SQL: select * from `contracts` where `tyspe` = ? order by `note` asc) (Bindings: array ( 0 => 0, ))

Let me know if you know of any other solutions in the comments.

Database table relationships: One-to-One vs. One-to-Many vs. Many-to-Many

A lot of people have problem with relational databases and how to define relationships between two tables.

This is a guest post by Dave from where he teaches us how to easily recognize the correct relationship:

General Rule and One-to-Many Relationship

Back when I taught database design at university I had a LOT of students who struggled with One-to-One vs. One-to-Many vs. Many-to-Many. Part of the problem is that English can be a bit confusing with plural forms: Person/People, Mouse/Mice, etc. Another part of the problem is that verbs do not always have exact inverses so we end up saying ‘Queen Elizabeth RULES England’ but then have to say the rather awkward ‘England IS RULED BY Queen Elizabeth’. There are so many slight variations in English that it gets confusing. Here’s a very simple way to ALWAYS get it right:

If you want to figure out the relationship between X and Y, complete the follow two statements:

  • Each X GOES WITH, at most, ____ Y
  • Each Y GOES WITH, at most, ____ X

Let’s assume we have Person and Country tables. For the sake of this example we assume that every person lives in only one country. So, for this specific case, we have the context of ‘where a person lives’:

  • Each Person GOES WITH, at most, ONE Country
  • Each Country GOES WITH, at most, MANY Person(s)

Now, keep the last two words of each statement…

  • We have [ONE Country] to [MANY Person]

A One-to-Many relationship is always “owned” by the MANY side, which is to say that the Foreign Key goes in the table for the MANY side (we put the Country identifier in the Person table).

Many-to-Many Relationship

A Many-to-Many relationship (use the same two statements to figure this out) is special; it requires a third table. Each of the two related items has a One-to-Many relationship with this new third table, so the third table contains TWO Foreign Keys, one for each related table.

So, in the context of ‘places a person has visited’, we have:

  • Each Person GOES WITH, at most, MANY Country(ies)
  • Each Country GOES WITH, at most, MANY Person(s)

Incidentally, this ‘third table’ is conventionally named for the other two tables, in alphabetical order: CountryPerson or Country_Person, but can be named anything (e.g. Visited). Naming it after the other two tables makes it easy to figure out what the purpose of the table is; alphabetical is just arbitrary.

One-to-One Relationship

A One-to-One relationship (again, same two statements) is super easy – it does not matter which of the two tables gets the Foreign Key. Almost always one or the other of the items logically “owns” the other one… but it technically does not matter.

The most common kind of One-to-One relationship, in my experience, is an “IS-A” relationship – like “A Customer IS-A User” or “An iPhone IS-A Mobile Device.” A trick that I use for IS-A type relationships is to use the same Primary Key(identifier) in both tables. That way either Primary Key can serve as the Foreign Key to the other table.

But One-to-One relationships are not ALWAYS IS-A relationships… for example…

In the context of “place that this person rules (as in King/Queen)”, we have:

  • Each Person GOES WITH, at most, ONE Country
  • Each Country GOES WITH, at most, ONE Person

Here we could put the Person identifier in the Country table OR we could put the Country Identifier in the Person table. Since there will likely be fewer Countries than Persons, I’d put the Person identifier in the Country table because it will result in less data to store/handle.

There you have it, the (very) short version of my ‘what kind of relationship is this?’ lecture.
Hope it helps someone.

Script php artisan clear-compiled handling the pre-update-cmd event returned with an error

I had a problem with Basset package (website didn’t load, it kept timing out) so I tried to remove it from the composer.json file to see if it helps. After running php composer.phar update I got this error:

Script php artisan clear-compiled handling the pre-update-cmd event returned with an error

You can even get this error:

Script php artisan optimize handling the post-update-cmd event returned with an error

To fix this error open your composer.json file and delete the scripts key (or just the part that fails – in bold). In my case it was this:

	"scripts": {
		"pre-update-cmd": [
			"php artisan clear-compiled"
		"post-install-cmd": [
			"php artisan optimize"
		"post-update-cmd": [
			"php artisan optimize"

I ran php composer.phar update again and it worked.

Some people report that after this they have problems with running php artisan optimize and few others . I didn’t have this problem but if you have it then delete the app/bootstrap/compiled.php file and then try running php composer.phar update