Refactoring UI

I could not understand what the designers were looking at until this book explained it from a developer point of view.

I think leaving the designer to do the designing work is a better way for website, but it does not hurt to learn some designer technique.

Testing Laravel Application


class DeveloperTest extends TestCase {

    public function we_all_should_write_test()


If you don’t know where to start, this is a very good starting point.

Two points to emphasize:

  1. Tests give you confident to change code. (Laracasts)
  2. The value of tests get higher as time goes on.

Usually my workflow is this:

  1. How the feature is reached?
  2. What is expected to come out?

That’s pretty much it. Write test first, not after. It helps me clarify the problem and write a better solution.

The Manager’s path

At the first year of my career, many have told me that you cannot be a developer for forever. At some point, you will have to move up.

I am lucky that I did get move up, but what is an engineer’s manager, a tech lead, a VP of engineering, or a CTO? In this book, it explains their roles, expectation from the top, and from the ones they are managing of.

It helps me to understand more about these possibilities.

Laravel Nested Resource Group

When I started with Laravel, nested resource group was available. I liked it because I can easily create a beautiful URL with ease. For example, to generate an URL like this/user/1/blog/10, I just need to nest my route with this:

Route::resource('', 'BlogController');

and my controller will be

class BlogController
    public function show(User $user, Blog $blog) 

Since 5.2, this option is removed from documentation (but still available to use). So I was wondering why and I found someone already spotted this and submit a merge request. However, it was not merged with the reason below given by @taylorotwell.


OK, no problem. I will take his word for it. Since you can archieve something similar with alternative approach, e.g.

Route::post('user/{$user}/blog/{$blog}', 'BlogController@store');
Route::resource('blog', 'BlogController')->except(['store']);

but… I still want to know why it is not a good idea? I want to find out… so I can become a better developer.

Is it because of security? This is the first thing I come of mind. Assuming the URL meant to let user store or view their own blog, e.g. user Alice with user id 1, and she has blog entries 10,11,12. Does it mean if she access URL user/1/25 will be a problem? I don’t think so given if Policy is setup properly.

The other thing I can think of is keeping the route simple. It is because if your model route key name is not its ID but a customized route key name, the URL will be very long. e.g., using the route example above, if the user model route key name is user’s name and the blog model route key name is the blog title, the route will be user/alice/blog/this-is-my-title-of-my-blog. It is definitely longer than blog/this-is-my-title-of-my-blog.

There must be some disadvantage of using nested route, what do you think it is?

Laracon 2019

In Laracon, you usually get some hard technical talks and some soft talks. I recommend to check out @bobbybouwmann if you already have at least one year of Laravel experience, @gonedark and @colindecarlo’s talk if you are quite seasonal.

The usual speakers such as @adamwathan, @freekmurze, @gonedark, @mijustin, @colindecarlo, @youyuxi, and @stauffermatt.

Of course, @taylorotwell‘s vapor announcement was the “keynote”. Watch it.

@kthomas901 gave a talk on launching side project. She said “…wanting the security from corporate is completely OK…” and “…know when to end.” are my favorite quotes.

LiveWire created by @calebporzio is some great stuff.

I also get a chance to meet my favorite podcast hosts @michaeldyrynda and @JacobBennett. I also get to say thank you to @marcelpociot for helping me getting started with creating a PHP package.

My feeling is that @mijustin and @stauffermatt are the Laravel evangelists and they are the biggest cheerleaders of the Laravel community. I like how @mijustin just pour it out and reminded all of us that we only see a person’s positive side from the Internet but they could be struggling. He was reminding us that it’s OK to fail and it’s OK to share about failure. @stauffermatt reminded us that what a special community @taylorotwell has started. We must cherish this magic, continue to be proud of what we do, and continue to be a welcoming community.

Using Mock in Laravel Unit Testing

When you have a test that uses a class that pull data from an external API, it might be a good idea to mock this object so it does not reach anywhere outside of your local development or your CI service provider, and you can assure you are getting the data you are expecting.

Let’s use the simple example provided by Mockery.

class Temperature
    private $service;

    public function __construct($service)
        $this->service = $service;

    public function average()
        $total = 0;
        for ($i=0; $i<3; $i++) {
            $total += $this->service->readTemp();
        return $total/3;

You need to test the $service. However, this $service class calls an external API when you call readTemp(), we can use Mockery to bypass that when running test in Laravel.

According to Laravel Mocking, in 5.8, you can do the following

use App\Service;

$service = $this->mock(Service::class, function ($mock) {
    $mock->shouldReceive('readTemp')->times(3)->andReturns(10, 12, 14);

So, in your test, you can do the following:

public function TemperatureAverageTest()
    $service = $this->mock(Service::class, function ($mock) {
        $mock->shouldReceive('readTemp')->times(3)->andReturns(10, 12, 14);  

    $temperature = new Temperature($service);
    $this->assertEquals(12, $temperature->average());

When I first use Mockery in 5.8, I was stumbleupon on why after running $this->mock(...) the object does not create a mock. That’s when I find out it actually returns a mock object not overriding automatically all Service, I actually have to use it and apply it in my code.

The Bullet Journal Method

In the digital age, pen and paper still thrive. Our brains are just better with pen and paper. (I think that’s why Apple Pen exists)

In this book, it is not a “how” to do Bullet Journal (BoJo). It’s why to BoJo.

It does not tell you how to take notes, it give you a starter method and some example for you to build on.

I personally use the Muji Weekly Monthly Planner, but using this, I can also implement the BoJo method to my note taking and journaling method.

In the end, I think having your own style to make a journal is the best, but BoJo is a good place to start if you don’t know where to begin.