Cheating Or Good Design?

A comment on Reddit (by raygundan) points out an interesting technique Apple uses on their iOS platform:

when you switch apps, the device saves a screenshot of what the last screen looks like for that app so that when you switch back again, that saved screenshot is the first thing you see. This is done to buy time for the app to fully load. Instead of showing you a blank screen or a loading screen, the device shows you a screenshot of the app. This technique works because the time it takes to load the rest of the app isn’t very long anyway, so a second of showing a screenshot that the user cannot interact with doesn’t cause confusion. What it does do is make it looks as if the app has loaded instantly, which results in a very good experience for the user.

I think this is a brilliant idea. It seems we live in a world full of loading gifs and I appreciate fine details like this. The fine details that you don’t see is the difference between mediocre and extraordinary.

Laravel Blade

Blade is the simple template/theme system built into Laravel and up until this point it has been very basic. It supported most of the simple things such as variables {{ $var }}, @if @else, @section, and finally a thing called @yield.

Because of the simplicity of it on a new project I thought we would need something more advanced and went with Twig. Twig had more features and was more powerful but it also didn’t really fit into my workflow. The biggest problem was working with Eloquent results and twig doesn’t like calling results like this:

foreach (Book::with('author')->get() as $book)
{
    echo $book->author->name;
}

I asked Taylor about it and he did a few changes to get that working but then I had troubles with other calls. So it just felt like it was more of a fight than what it was worth. After discussing this, last week Taylor and Shawn McCool really made Blade awesome. First Shawn recommended a “render_each” method. Which is an excellent feature in my opinion. It works my including a looped view:

<ul>
    {{ render_each('categories.list', $categories, 'cat') }}
</ul>

// categories/list.blade.php
<li>{{ $cat->name }}</li>

As you can see that is a big time saver. But it doesn’t stop there. Now Blade can have layouts inheritance and several other really useful goodies:

@layout('layouts.common')

@section('content')

    <p>My content</p>

@endsection

Then inside layouts.common:

<html>
<head>
    <title>Test</title>
</head>
<body>
    @yield('content')
</body>
</html>

This is just some of the basics of the new features and it does a lot more. Although I don’t consider it a full replacement for Twig it has 90% or more of the features I wanted to use. The biggest missing feature (depending on your needs) is that Blade still just parses as php. So it can call things that are not assigned and doesn’t prevent you from using php code in your views. Personally I like that feature but if you are really wanting to limit what people can do in the views then this may not be ideal. So use what is best for the task at hand.

For a video overview of what is coming please watch this:

http://www.screenr.com/embed/ft28

Laravel Bundle Assets

The past few weeks I have been building a few Laravel bundles and one of the features of bundles is the ability to have assets that are moved to your public folder during install. This is great when your bundle has css, js, images, etc..

The downside to this though is that while building the actual bundle it is a pain to keep having to run the following command each time you change a file:

php artisan bundle:publish

I have came up with a few different options to make this easier for developers. The first method which I believe would be supported across every os is to symlink the assets to public/bundles/folder/. However the down side to this is you have to add new symlinks when you add new files. So not ideal for the way I typically develop.

The second option is specific to mac but it works wonderfully. What I have done is purchase live reload and use it to run the bundle publish command. The reason I originally purchased the app was because I am using less for my css and I liked the fact that it would compile the css and also refresh your browser so you can see changes instantly.

The bigger benefit is live reload allows you to run terminal commands after you save and before it refreshes your browser. So all you have to do is add in your artisan command and not have to worry about it again. Here is a screenshot showing this:

livereload

Hopefully this will help you if you are building bundles with public assets. If you have any other tips please post them in the comments.

Laravel Log Viewer

A simple Laravel bundle to display your log files via the browser.

Installation

php artisan bundle:install logviewer

Publish assets

php artisan bundle:publish logviewer

Then edit your application/bundles.php file and add:

return array(
    'logviewer' => array(
        'location' => 'logviewer',
        'handles' => 'logviewer'
    )
);

Download

You can clone the repo by running the code below:

$ git clone git://github.com/ericbarnes/Laravel-Log-Viewer

Or visit the GitHub Repo.

New Laravel Bundle App

Since starting at UserScape I have been tasked with building a new bundle application for the Laravel framework. So far all the work has been done “behind the scenes” but I wanted to share a few screenshots of what I have completed so far.

bundle-home

This is a temporary home page which showcases the latest and the most popular. Currently the most popular will be determined by number of installs but I have some ideas for better stats and filtering that will come later.

bundle-user

This is the grid list. I tried keeping it simple so you can quickly scan the titles and also show each users gravatar for branding.

I am really happy with what I have completed so far and it should be a simple and effective way for users of the framework to find pre-built code to put in their applications.

If you are interested in seeing how to create a bundle check out Taylor’s Videos

CodeIgniter Output Caching

This week I had the privilege of doing load testing on an aws setup. The goal of the test was to support 25k concurrent users and was designed to ramp up over a period of a few minutes. The first round of testing failed pretty quick and I only had a select number of large queries cached. So the db spiked and was the bottle neck. During that test we was only able to reach 10k concurrents.

For the second round of testing I decided to just setup output caching before I even loaded the db in a MY_Controller. I set the number of minutes to something relatively high and was ready to commence the load test. Unfortunately this test maxed out the db again and I was honestly scratching my head on just why that would be the case.

Since this didn’t make any sense to me I decided I better figure just what is going on. I got my local system setup the exact same way, enabled mysql query log, and then proceded to test and see what was going on. Queries was being ran even after the cache file was written. At this point it was way late so I decided I better sleep on it and try and think about what I was missing.

The next morning I got to work ran the same tests and got the same results. Starting researching and then realized it was just my ajax calls that was generating the queries. This had me puzzled because the ajax controller extended the MY_Controller so it should be cached as well. Turns out I was wrong and missed the most important note in the user guide:

Warning: Because of the way CodeIgniter stores content for output, caching will only work if you are generating display for your controller with a view.

The more I thought about it the more sense that makes since the Loader ties into the output library but I wasn’t thinking clearly at 3am. Looked at my ajax controller and sure enough I was just returning a json string.

return json_encode($vars);

The quick fix was to change the return to the following:

return $this->output->set_output(json_encode($vars));

My hope is this will help others if they ever run into the same situation. Unfortunately the load testing was only scheduled for two rounds but I feel confident by fixing that it would have passed with flying colors.

So the moral of the story. READ THE MANUAL 🙂

New Year, New Job, New Framework

I am happy to announce that starting January 9th I will be working full time for Userscape. If you are not familiar with them they are the company behind the awesome HelpSpot help desk software.

Laravel

Not only will I be a part of a great company but they have also hired the creator of the Laravel framework, Taylor Otwell. I have been watching that framework closely the past few months and I am very impressed with what he has done with it. Laravel’s motto is:

Laravel is a clean and classy framework for PHP web development. Freeing you from spaghetti code, Laravel helps you create wonderful applications using simple, expressive syntax. Development should be a creative experience that you enjoy, not something that is painful. Enjoy the fresh air.

The simplicity of framework is what drew me in originally. But now it will just keep getting better and better because it will be the framework of choice for Userscape. The reason I feel this way is that HelpSpot can be purchased as either a downloaded application or hosted with their partner Engine Hosting, so Laravel will be tested in a wide range of different hosting environments.

CodeIgniter

Even though my day job will be with Laravel I still love CodeIgniter and I am still on the CodeIgniter Reactor team. CodeIgniter is and has always been near and dear to me and I really enjoy using it. Plus I will be doing contract and freelance work for companies that are heavily invested into it. I am very excited with where CodeIgniter v3 is heading and I think it is a big step in the right direction that we have all been wanting.