Tag Archives: Yii 2.0 vs. laravel

It’s Laravel 5.1 for Enterprise Development

That’s a heck of a headline for a guy who wrote a book on Yii 2, certainly not where I expected to be at this point in time. When I first reviewed Laravel 5, I had an allergic reaction to it and wrote a snarky review on Laravel 5.0 (which I’ve since removed). So how did I go from that to recommending it for enterprise development?

Well, this transition started a few months ago, with the programmers in my company expressing a desire to move to Laravel. My first impulse was to say, “no way.” I had just spent a year preparing for our move into Yii 2. I fell in love with Yii 2 and wrote a 691 page book about it for beginners. I took a lot of pride in the book and kept working on it to make sure all the code worked and was clear and easy to understand. I got great feedback from the readers and have a 4.59 out of 5 rating on GoodReads.com.

So obviously it was a bit of shock to hear about laravel from the team. But rather than take a top down approach and dictate the framework choice, I wisely chose to open the topic to discussion and evaluation from programmers who are more advanced than I am. To keep up, I had to dig in deep and see if I could find what I felt I was missing. And the deeper I went, the more things started to tilt towards laravel.

To get there, though, I had to overcome my initial bias against Laravel, which based on the fact that Laravel was built on Symfony components, used Doctrine, and seemed to hardwire migrations into the workflow, at least in all the examples they were providing. So my objection was that it was slower, bloated, and not as database centric as I preferred.

In working with Laravel, however, I found that it wasn’t noticeably slower and the use of migrations led to a good work-flow, that if used correctly, could still adhere to proper discipline concerning the DB. Plus PHP 7 is on the horizon and it looks like it will eliminate most of the framework overhead, so the concern over using a framework that utilizes other big components like Symfony and Doctrine is no longer a significant factor.

Another thing that always threw me off with laravel was the obsession with the use of dependency injection. That never really clicked with me in the past, I just could never put all the pieces together to make sense of that. It somehow seemed gratuitous.

To put a little perspective on that, I always viewed coding to a contract as a more expensive proposition without a lot of upside. I thought it was an approach that was too intellectual, not practical, a better fit for java than for PHP.

I was 100% wrong about that. 100%. Wrong. Painfully so.

Anyway, the changes in laravel 5.0 and 5.1 really brought this to light. For example, their request class, combined with method injection is a very beautiful way of handling validation.

If a class is namespaced properly, you can inject an instance into either a constructor or method signature, without having to otherwise instantiate it, a nice piece of magic accomplished by reflection.

But even better than that, the service providers allow you to bind a concrete class to a contract, so you can call the instance of the class via the contract.

This makes changing the implementation of a class everywhere in your code as simple as changing one line of code. It’s awesome. That means you can test different implementations without having to create separate branches of your project, which makes it easier to manage.

One of the big features of laravel, one that moved our team sharply in their direction, is the ease of frontend integration using blade. It’s a super-clean template engine with crystal clear syntax. It makes working with bootstrap and jquery a snap. It also makes working with interspersed html and php very easy and clean.

There’s an old saying that fortune favors the bold. It may be a cliche, but it’s true. Taylor Otwell had a bold vision for laravel going back a number of years. In his book from 2013, he talked about changing the concept of model, long before laravel 5.1 came to fruition. And in some ways, it’s a counter-intuitive move, at least in the sense of moving things towards simplicity.

In a general sense, Occam’s Razor states that simplest answer is typically the most efficient. And I’ve always found that this is a great way to approach life, business and coding. But sometimes that can cause too narrow of a vision.

This is where Taylor boldly stepped forward. Fragmenting the idea of a model into smaller components is more complicated, but results in a more efficient workflow and maximizes the gains from loose coupling. While I can’t visualize the directory tree as easily, I feel more connected to the concepts, they seem clearer.

And while the structure is more complicated, the code generation via artisan takes this into account and helps you stub out handlers, service providers, middleware, and other class types, namespacing them for you and placing them in the proper folders in the application.

I don’t know how it is for other programmers, but I find most of the laravel syntax incredibly intuitive, and more so over time. This is not an accident. It’s all part of a cohesive set of principles and design patterns that are playing out perfectly at scale. It’s proof that the SOLID principles, and taylor’s specific implementation of them, actually matter.

So this was a huge attraction for our team, a sense of commitment from the path Taylor is blazing, that if we followed it, we would become better programmers. You know you have a future in programming if that idea excites you.

The title of this post is It’s Laravel 5.1 for Enterprise. One of the┬áreasons for this is that Taylor has developed an entire suite of products designed to support enterprise development. These include, laravel(PHP framework), forge (server management), lumin(PHP micro-framework), homestead(local dev environment), laracasts(video tutorials), elixir (asset management), artisan (command line interface), and I’m sure I’m probably forgetting something. Oh yeah, envoyer, which gives you seamless deployment with no downtime.

The point is that laravel itself is run like a commercial venture, and this is a big plus for enterprise development. With 5.1, they have also announced long term support. So that means we can count on bug fixes and security patches for years to come.

And so now this brings us to laracasts. The story of the rise of laravel would not be complete without mentioning Jeffery Way and laracasts. Taylor is lucky to have him on his team, he is a world-class instructor, helping all of us stay on the forward edge.

While I could write an entire post about the great quality of laracasts and how useful the videos are, the really short version for now is that our company purchased a company license, so that all our programmers can have access to the videos on demand. The videos are that good. To borrow from another cliche, the videos contribute to programmer happiness, which is vital to the success of the company.

So this all worked out perfectly for my company, the programmers are happy with the decision to use laravel for our future development. But where does this leave me and this blog? Obviously this post is not going to boost book sales, at least not mine.

Well, I still love Yii 2. It’s a great framework and it taught me a lot about programming. I still recommend learning more than one PHP framework and Yii 2 is an excellent choice. I’m still proud of the book I wrote for it.

At the same time, I feel a sense of loyalty to everyone who bought the book and to the readers of this blog. Rather than simply just stay silent, I thought it was important to share my views and our company’s conclusions regarding framework choice.

Going forward, I’m going to be coding in laravel. That means at 691 pages and a translation into Spanish, my Yii 2 book is complete. It’s been a great experience, but it’s time now for me to move on to a new chapter in my coding journey…

Advertisements

Yii 2 vs. Laravel 5

It’s time for a new PHP framework poll, please feel free to participate and make your voice heard. The last poll, published March 15, 2014, was very successful and over 1100 programmers participated. Thanks to everyone who voted, it was a very interesting result.

UPDATED 4/27/15

Originally I wrote about the comparison between Laravel 5 and Yii 2. I decided I was overly negative to Laravel 5 and that I needed more time to fully explore the possibilities of that framework, so I have removed the review portion of this post.

In any event, both Laravel 5 and Yii 2 are great frameworks. Try them for yourselves and decide for yourselves. I hope you’ll participate in the poll at the top of the page and let us know what you think.

Yii 2 Gii code generation

One of things about Yii 2 that is drastically different from some of the other frameworks is Gii, it’s code generation tool. I cover the use of Gii extensively in my book, Yii 2 For Beginners.

On the surface, this might just seem like a fun feature to use, a time-saver in certain circumstances. And that’s probably true of a lot of code generators, they only take you so far. But Gii is different.

Gii is so powerful that it has very meaningful impact on work flow. And this impact reaches deep into our profession. You can look at it from two perspectives, one, the individual developer doing work for clients, and two, from a team perspective, which can bring you up to full enterprise level.

So let me talk first about how it impacts the individual, and since a lot of my readers are beginners, it will help them understand the importance of Yii 2 and Gii.

1. Planning. Use of Gii impacts planning. Before you code a single line of code, you can factor in not only the efficiency of Gii, but also the workflow.

For example, to start, you look at the scope of the project and begin sketching out the table structure. The more well-thought out this data-structure is, the useful Gii becomes. If you use foreign keys to relate tables, Gii will understand this and generate relationships in the models.

This gives you the ability to imagine the project, and better yet, diagram the tables in MySql workbench, before any PHP is involved. And once you know the number of tables you are working with, you will have some idea of how long basic development will take. This is possible because you can average how long each table takes to convert to model to controller to view.

In a typical implemenation, there are 8 files generated. And they also typcially need customization, but once you have an idea of what you generally use for that, even the 1st level of customization goes quickly. When I say quickly, I mean crazy fast. It’s awesome. Awesome is not a technical word, but you have to give me a pass on that one, I really love Gii.

2. Strong MVC Pattern. The code that Gii generates is a beautiful implementation of the MVC pattern. It’s probably the easiest structure to follow of all the frameworks because you literally get folders named models, controllers, and views. And once you understand how it’s all stiched together, it just makes perfect sense.

3. Learn Good Practices. As your workflow and project planning are impacted by Gii, you begin to develop a discipline to the structure. While you are certainly not locked into anything, if you follow the breadcrumbs of good practices that Yii 2 and Gii are putting out there for you, your project becomes very tight and focused. Things are always done the same way, at least at the base level.

It’s understood of course that I’m talking about the bones of the project, not the skin. Presenting the data in the views often requires a lot of customization, but of course Yii 2 helps you bigtime there too with its widgets. But the widgets will have to be the subject of another post.

4. Grow As A Developer. As an individual developer, you build value into your skill set by following best practices. Today you are an individual developer or student. Tomorrow, you may work in a team environment. And those looking to hire programmers are looking for programmers that can follow a discipline and they’re most likely looking for programmers who have framework experience. And the good news is that this is a very accessible framework. You can learn it and benefit from it.

And that gives us the perfect transition to talk about team development. All the benefits that individual developers get from using Yii 2 and Gii are amplified in team and enterprise development. While time estimates are also important to individual developers, they can be absolutely critical in a company environment, where commitments are made to clients or to the backers of a venture.

So you can look at the list of benefits like this:

1. Workflow Standardization. The planning and flow of the project always follows the same path. Team members are assigned specific roles, which is certainly not unusual, but knowing the power of the framework and the capabilities of Gii enhances the strategic deployment of those resources.

2. Common Starting Point For Code. If the conversation starts with data-structure, it will lead to using Gii, in most cases. Obviously there are exceptions to everything. But to the extent that Gii gives us a common starting point for code, it gives the security of building a proven structure. The tight association it creates between model, controller, and view is not something you want to go out of your way to break, unless you have very good reason to do so.

3. Rapid Prototyping. Gii gives you the ability for rapid prototyping. Companies rarely have the luxury of asking “what if?” But with Gii, you can do that. You can even set aside a prototype branch with a separate DB, and playout those whatif scenarios quickly. No company would ever do that unless they could do it quickly and efficiently. But having that ability can give you a competitive advantage, so this is great.

4. Security Of Standardization. Lastly, I should state one of the most obvious benefits to the standardization that both Yii 2 and Gii offer. What if someone leaves the team? Someone else will have to take over their responsibilities, and wouldn’t it be better to know that they can do that efficiently because the structure and discipline of Yii 2 and Gii were adhered to? Of course it would. That’s a big reason why companies use frameworks in the first place.

Besides all the reasons I stated about the benefits of using Yii 2 and Gii, I thought about why it is so good at what it does and why I haven’t seen a competing framework offer something as compelling, at least not from my point of view. And I think the answer is that Yii 2 has it’s own native ORM implementation, which just makes their code generation seemless.

Having their own native ORM also gives Yii 2 the freedom to structure their MVC implementaion how they wish, so they’re able to keep it intuitive, without having to make sacrifices because of 3rd party ORM or other considerations. I believe this is a huge advantage and is one reason why Yii 2 is able to offer so much out of the box. If you haven’t tried this framework, I would strongly encourage you to do so.

I’d like to take a moment and thank all the programmers from around the world who are reading my blog, I hope you are finding it useful. And thanks again to everyone who has supported my book. Feel free to contribute with your own comments, links, and reviews, it is greatly appreciated.

Yii 2 MVC

Happy Holidays to everyone around the world, to our wonderful international following, I hope everyone has a great holiday season. I’ve been hard at work on a new writing project, a new book, which I will be releasing details on in the near future. One of the benefits of constantly doing technical writing is that you get to see things from many angles, which often gives you new perspective, even on the most basic things.

Since my blog is oriented towards beginners, I thought I would share some thoughts about the MVC pattern, and why I think Yii 2 does such a great job utilizing and preserving it. And while I’m mentioning Yii 2, a word of thanks to everyone who has bought Yii 2 For Beginners, I really appreciate your encouragement and support, it helps me vigorously pursue this work.

Ok, so jumping into MVC, it’s such a simple idea in many ways, that it quickly gets diluted, or at least our sense of it, depending on how an application is organized. I’m a big fan of an application having folders clearly named models, views, and controllers. in the basic app, these are very easy to find, right there in the root folder.

In the Advanced Application, which is the one I work with, the application has folders for frontend, backend, and common, and within those folders, you find the model, view, and controller folders. I know I’ve mentioned it before, but it bears repeating, the Advanced Application gives you a working user model, with registration, login, and forgot password functionality as well as the frontend/backend separation that I just talked about, so I actually found that easier to work with than the basic app. Just a heads up if you are relatively new to all this.

So from a basic organizational standpoint, Yii 2 is very intuitive and very well defined. Now I know that might sound a little vague, so let me try to be a little more specific and talk about an advantage that Yii 2 has over many other frameworks.

In Yii 2, you do not have to manually define each route. Yii 2 has built-in routing logic that sends the user request to the appropriate controller and view. By itself, that’s pretty cool, it alleviates you from having to keep track of all the different routes moving through the system as well as it relieves you from constantly having to bounce around to a routes file or equivalent. You don’t have to keep track of the path, so no headaches when there is a typo in the route or you forgot to reference something correctly. You can avoid that entirely, so that’s a plus for Yii 2.

But there’s another big plus from Yii 2’s architecture, and this may be a by-product of Yii 2’s built-in route definition, and that is it gives you a sense of a well-defined MVC right out of the box. You get to see how the controllers interact with the views, how they utilize the models, and how it all fits together. In a sense, the framework itself defines the MVC pattern more strongly, and it teaches you a very efficient and effective structure that you can use as you build out your application.

In the advanced application especially, you get enough examples of validation, form models, and the user model, to really see the MVC pattern operating beautifully. You get just the right amount of logic in the controllers to keep them thin. If you were, for example, to extract too much logic out, so you have almost no logic in the controller, you would be constantly drilling dwon into other classes to keep track of what’s going on. If you have too much logic, the core mission of a controller, which is essentially routing, is lost in clutter. Yii 2 finds the perfect balance for you right out of the box.

Another measure of a successful implementation of the MVC pattern is how little PHP ends up in the view file, always a challenge in modern development. If you look at Yii 2’s implementation of a form view, for example, you will be amazed at how clean it is, and how little is actually there. It’s one of many things I love about the framework.

In the MVC pattern, models are supposed to carry the most weight in terms of volume of code, since they do so much. The models in Yii 2 have been consturcted to push a lot of their logic into the parent classes, which you do not have to write, so you get to focus on setting up your validation rules and relationships. For example, when you create a model in Yii 2 from a table, the model knows the attributes, you don’t have to declare them at the top of the class.

Not only is that convenient, but it also keeps the code clean and gives you a great structure that the models will adhere to. Depending on your level of OOP experience, this might not seem as apparent at first, because, as it is with any larger structure, there’s a lot to get used to. Just the sheer size of the framework can be a little overwhelming, expecially for newer programmers or those with less framework experience.

But learning a new framework always involves taking in a lot of new information, and if you think about it, constant learning is one of the defining characteristics of being a programmer, especially given how quickly things can change. Don’t worry, you are not alone in that, and the good news is that is a lot of support out there for Yii 2. A lot of programmers love this framework.

In the months ahead, I hope to be able to bring you more insights and tutorials that will help get the most out of your experience with Yii 2. Once again Happy Holidays to everyone around the world.

And thanks again to everyone who has supported my blog and book. Feel free to contribute with your own comments, links, and reviews, it is greatly appreciated.

Yii 2 Framework Development

Welcome to anyone from around the world who is just discovering this blog. It’s amazing how programming transcends international boundaries, which were always artificial anyway. Over 1000 developers have taken part in the polls on this site and I would encourage you to participate, either by voting or commenting or doing both, let your voice be heard.

Also, thanks to everyone who has bought Yii 2 For Beginners, I appreciate your support.

I recently discovered this Youtube video on the development of the Yii 2 framework.

I would strongly encourage you to watch the video, it’s about 3 minutes long. It shows a time-compressed evolution of the framework, starting with the first development by Qiang Xue, quickly followed by Alexander Makarov (Samdark). Then as the video progresses, you see some of the other Yii 2 stars such as Carsten Brandt (Cebe) and eventually Kartik V. popping in to make some contributions. Over 300 developers contributed to the making of Yii 2.

This video is just fascinating on so many levels. For one, you get to see how Yii 2 starts, with Qiang Xue laying out the base classes. Who knew that validators were such a big group of classes? If you ever wondered what the founder of Yii actually did, here it is in graphic detail, played out against some pulse-pounding music.

You also get to see how Yii 2 grows as a codebase, and how that intensifies as more developers come into to contribute. Entire branches of the framework seem to suddenly emerge as the energy pours in from the community. Each update is represented by a small spotlight effect or maybe it’s a small lightening bolt. Anyway, it’s pretty cool.

The representation of the project is made possible through Google’s Gource software, which extracts the updates from Github and compiles them into a video.

I’ve already done a lot of comparisons to Laravel on this site, but there is even a version for Laravel. One myth that dispelled for me was that I thought that Laravel was only one person, but you can see from the video that there were many people involved. Also, I think the video gives the impression that Laravel is lighter than Yii 2, but I think this is because Laravel depends on Symfony 2 and Doctrine, and obviously, that is not included in the Gource.

In some ways, the two videos draw a nice contrast between the two frameworks. The gource for Yii 2 is the entire framework, (up to the date it was made), the gource for Laravel can’t be because it’s layered on other dependencies. So no matter how gracefully that is handled, and Taylor Otwell did a great job, no doubt about that, it still is not quite the same as a single integrated entity like Yii 2, where the parts fit together seamlessly.

At this point, I can’t really claim objectivity, since I wrote a book on Yii 2, but I do think these differences matter. For example, Yii 2 really sticks to the MVC pattern in an intuitive way. You get folders named, Models, Controllers, and Views. You get files with names like Site Controller.php in the controllers folder. Yii 2 does the routing for you, whereas in Laravel, and Symfony 2 and Zend 2 for that matter, you have to set all the routes manually, and that is every route through the site explicitly declared, which is a big pain.

I think you can see from the video that a lot of effort went into the creation of Yii 2. So let’s conclude with another thanks to all those who contributed to the making of such a great framework. Feel free to let us know what you think, we would love to hear your comments, thanks for participating.

What do $foo and $bar actually mean in PHP?

Let’s start with a warm welcome to anyone from around the world who is just discovering this blog. Over 1000 developers have taken part in the polls on this site and I would encourage you to participate, let your voice be heard.

Also, thanks to everyone who has bought Yii 2 For Beginners, I appreciate your support. Starting this week, I will be adding tutorials on Yii 2 that build off of examples in the book, so I hope this can be a great resource for you.

Ok, so what is up with $foo and $bar? The use of $foo, and it’s companion $bar, in examples and lessons has always bothered me. One reason for that is that I know the origin of the composite word, Foobar, which is derived from fubar. Fubar is an epression that started in the US military. It stands for “fucked up beyond all recognition.”

So once upon a time, in the early days of programming, someone apparently thought it was clever to use a phonetic variation of fubar, split in half to use in programming examples. In other words, it was a joke. It was a joke, however, that caught on, and so now we seem to be stuck with it.

So what’s wrong with that? Ok, here’s the problem. Some people, like myself, know the origin of the word. The word itself has meaning. That meaning gets injected into the example on a subliminal level, which distracts from understanding the objective of the lesson.

Also, since $foo and $bar combine to represent a single word, the first thing I always try to see is if they are meant to be related that way when they are used in an example and more often than not, they are not meant to be related, though in some cases, one is used as a child of the other. You can see how confusing this can get.

It’s not that I don’t have the brain power to overcome the inference of fubar, but on the other hand, I would rather not waste bytes or neurons, precious as they are, on something like that. I have a much better use for them elsewhere.

Now you could say I’m in the minority, and that most people, especially those around the world who don’t speak english as a first language, are not going to have that distraction and you would be right about that. However, $foo and $bar still make for bad examples. Here’s why:

Even without the inference, using $foo and $bar is like using $could_be_anything_1 and $could_be_anything_2 or as the way my brain sees it, $lazy_example_1 and $lazy_example_2.

Wouldn’t be better for example, if you were going to explain arrays to people, to do it in a way that also points them in the right direction for future use and future lessons. For example, here we have a snippet from PHP.net on the new array syntax:

// as of PHP 5.4

$array = [
"foo" => "bar",
"bar" => "foo",
];

And look, they used my favorite word for the example, I didn’t have to go far to find someone using it. So just to reiterate why this is so bad, the first key is foo and has a value of bar, the second key is bar and has a value of foo. Does this mean they are interchangeable in the code and that they are equal to each other? Of course not. Arrays don’t work that way. But imagine you were just learning. You could see how that would potentially be confusing.

Robert Martin, Author of Clean Code, uses an interesting phrase, “lies and disinformation.” He is referring to comments in code that grow outdated in time because they are not maintained as the code changes. A bad choice of language in tutorials and examples is just as harmful. It slows down the learning process and makes it less fun.

Imagine the poor guy just learning PHP and programming having to spend an extra ten minutes of his time to realize that foo and bar are not equal to each other. If that happened to me, I would be angry and want my time back. Nothing is as precious as time and anything that degrades it in a learning enviroment is as bad as “lies and disinformation.”

Imagine an array example instead:

// as of PHP 5.4 example array named basket, where “string” is key and integer is value:

$basket = [
"apple" => 1,
"cookie" => 4,
];

Now obviously, there is a little more color to the example. Also I added more to the comment for clarity, even though those aspects might be explained elsewhere. It doesn’t hurt to have it there, because when people do a Google search, they may come directly to this snippet, you never know.

Why choose the word $basket? Well, what would a future or current programmer possibly work on that would require an array? That list is probably endless, but one good example would be a shopping cart. And right away, as a human, I’m a lot more interested in the example. Arrays might be fun if I can play with apples and cookies. I might even start to get creative about what I can do with the basket.

So obviously this is as basic as it gets, but it does have implications. We have seen a movement in modern PHP towards more clear snytax, and what I mean by that is code that makes its intentions more clear.

The modern PHP frameworks like Laravel and Yii 2 have done a good job making the code more intuitive. In fact I think Taylor Otwell, Laravel inventor and developer, has been very influential in this regard. I initially found his framework very attractive, but then Yii 2 came out and as you can tell from the history of this blog, and the book I wrote about it, I fell in love with it.

An example of excellent and intuitive syntax in Yii 2 is the behaviors method that you can use on either a model or a controller. We’re about to take a quantum leap in complexity from the array example, but as long as we give a good example, we will understand it.

A typical implementation of behaviors in a model would look like this:

public function behaviors()
{
  return [
     'timestamp' => [
          'class' => 'yii\behaviors\TimestampBehavior',
          'attributes' => [
              ActiveRecord::EVENT_BEFORE_INSERT => ['created_at', 'updated_at'],
              ActiveRecord::EVENT_BEFORE_UPDATE => ['updated_at'],
                ],
          'value' => new Expression('NOW()'),
            ],
        ];
     }

Screenshot of the code with no scroll:

yii 2 behaviors

If you are following along from the book, this example appears in the User model and Profile model. We use a different type of behavior for controllers, but you can get a clear idea of how cool and how flexible this concept is.

TimestampBehavior is one of Yii 2’s out-of-the-box behaviors, so everything is in place that you need to attach it to any model. All it’s doing here is automatically setting the value of two attributes, ‘created_at’ and ‘updated_at’ with a ‘value’ of ‘NOW()’ before insert or update.

This means before any record is created or updated, the timestamp value is set, and, assuming that you have the corresponding columns on your DB table in DATETIME format, you will get the desired result and the fields in your table will be updated with the current DATETIME.

Can you see how intuitive the concept is and how clear the code is? Anyway, let’s just step through this to make sure we understand it.

By configuring the behavior, we influence how the model will work. We give the behavior a name, in this case ‘timestamp.’ We tell it what class to use, in this case ‘yii\behaviors\TimestampBehavior.’

Next we tell it which attributes we want to affect, and we use ActiveRecord::EVENT_BEFORE_INSERT to tell it when and how to use it. In other words, it will set the value of the attribute before inserting or updating, which is made fairly clear from the name of the event.

And then finally, what ‘value’ we want to give it. We’re using an instance of the expression class, which let’s us define what type of value we want, which allows us to pop in the MYSQL syntax ‘NOW()’, so ActiveRecord can hand it into the insert statement.

You know the syntax is well-written when it is easier to understand than the verbal explanation. At least it seems that way to me. I’ve been staring at it for a while now. It just seems clearer and clearer to me, which is always a good sign.

Now imagine the above example as:

 public function behaviors()
    {
        return [
            'foo' => [
                'class' => 'foobar',
                'attributes' => [
                    qux => ['baz1', 'baz2'],
                    qux => ['baz2'],
                ],
                'value' => new Expression('quux'),
            ],
        ];
     }

Screenshot of the code with no scroll:

bad behaviors

That’s not realistic, no one would do that to you, at least I hope they wouldn’t. Anyway, I think you get the point. A real example makes you want to play with the system. A $foo/$bar example is just fubar. Feel free to take the poll and let us know what you think.

Yii 2 For Beginners

I’ve been studying the PHP framework scene for the last 3 years in depth. I’ve done comparisons on all the major frameworks, including Laravel, Symfony, and Yii, and in the end I chose Yii 2 as my framework of choice. You can see a little of the history of this, my blog, Yii 2 vs. Laravel, talks about discovering Yii 2 when it was only in Alpha. After trying all of the other frameworks, watching countless videos and reading many books, I settled on the one PHP framework that had no book whatsoever to help beginning programmers.

I always felt, if only there were a book for beginners, I could learn this quickly, I just needed someone to point the way. Instead, I learned piecemeal by gleaning tips from the forum, the guide, and from the fact that the framework was very intuitive. Even though I made progress, I still found myself wishing for the book. Learning this would be so much easier, if I just had a book!

How ironic is it that 6 months later, I end up writing the book I yearned for? Well, I kept very detailed notes on my development and I noticed over time that I could organize them into a book. I just had to be willing to sacrifice the time, which could have been spent developing actual sites, which instead had to go into writing lessons for other people.

It was a tough choice, but I chose to write the book, it seemed like a worthwhile endeavor. It turned out to be an incredible challenge. It pushed me mentally and physically. I spent long nights picking apart every detail, striving for excellence and clarity, so that others could more easily understand how to use Yii 2.

I started out fairly objective about PHP frameworks, simply looking for the easiest framework that could support robust development. Although I had a lot of respect for Symfony, I felt it was overly complicated and bloated. I didn’t like having to learn Yaml, even though it’s not difficult. I didn’t like having to write every route through the site. I didn’t like what I saw of doctrine. And I didn’t like the fact that alhough they had beautifully written documentation, there was no real effort made to service beginning programmers. This has a downside for businesses that have to hire programmers because it then becomes more expensive to train programmers. So in that sense, Symfony is an expensive discipline.

Laravel, on the other hand, went out of it’s way to service beginners and I loved that about it. The problem was, I just never felt like they were helping me build anything. None of the examples I found at the time, for example, dealt with a robust user login and verification. And without that, what kind of site do you have? And then, because it’s built on top of Symfony, it brings in Symfony’s bloat and performance issues. The other programmers at my company didn’t like it either. It didn’t seem robust enough to them, though in fairness, I should say that it was very new when we were doing those comparisons.

I turned to Yii 1.1.14 because my company had settled on it and the programmers loved it, but I found it difficult to grasp personally. In retrospect now, since I came up to speed on Yii 2, I understand 1.1.14 a lot better, but at the time, it seemed so difficult to use. The reality was that it was difficult to learn, but easy to use. You just had to be at a certain level as a programmer to get that. I hated that about it.

Then I discovered Yii 2 and everything changed. Whereaas Yii 1.1.14 was old and ugly, using old array syntax, no namespaces, etc., Yii 2 was a beacon of modern PHP. And being beautiful architecturally in this case is not just a superficial thing, it is extremely versatile and useful, way more intuitive than it’s predecessor. I have so much enthusiasm and passion for it, that I want to share it, and this was one of the motivations to write Yii 2 For Beginners.

Also, I know that right now, a beginning programmer is wandering around, wondering how to go from novice PHP programmer to framework developer. That’s a tough transition to make. I know just how frustrating it is. I want to help.

There are many, many, more advanced, and more qualified programmers than me, who apparently don’t have time or the interest to bring it down to the beginning level, so that task has fallen to me, at least in the short-term. I didn’t plan for this to happen, I’ve just found myself in these circumstances. There is no other beginning Yii 2 book out right now. So I did the best I could and I put a lot of effort into making Yii 2 as understandable for a beginning programmer as possible.

I realize that by being so into Yii 2, I no longer have objectivity to the other frameworks. That was bound to happen. I had to pick one. And when I get into something, I go all in.

So Yii 2 For Beginners is out now. I’m really glad I could contribute something to help beginners harness the potential of Yii 2, it really is an amazing framework.

Now that the book is done, I’m looking forward to getting back to application development, I hope to have a new site done in January. After that, I’m going on vacation, if I’m still breathing…

I will continue to support PHP and Yii 2 beginners on this blog, and hopefully continue with the polls, which people seem to find interesting. Over 1000 developers have voted in my polls. I hope to continue to develop this blog as a resource for the community.