For the Laravel users out there the Laravel News site has shared some handy Bash aliases you can use from the command line to improve and streamline your workflow.

Bash aliases are shortcuts added to a file that allows you to reference another command through more memorable words, abbreviations, or characters. For example, if you use Git you may run git status many times throughout the day, so to save yourself time and keystrokes you could alias gs to git status and it’ll automatically expand and call the proper command.

Over the years I’ve seen a lot of unusual aliases and many are unique to the person. Shortcuts that make sense to me, might be confusing and weird to you. That’s what makes these so fun.

He shares how to create a basic alias in your .bash_aliases file and then shares some from different users in the community:

• WaveHack
• Jeffrey Way
• Bill Mitchell
• freekmurze
• sebastiaanluca

Each contribution includes the code needed to define their preferred aliases. They cover everything from general console command simplification out to more complex Laravel-specific functionality.

On the Laravel News site there's a new post that continues their series about building applications with Composer. In this latest post they talk about the "other half" of the Composer ecosystem - Packagist.

In our last blog post, we saw the basics of Composer but skipped over where it actually finds its packages, and how to publish packages of your own. In this blog post, we will be looking at exactly this, plus some security considerations when using composer in your application.

Packagist is the primary package repository for Composer. This is where you can publish your packages, and also where you can view other people’s packages. Composer will use Packagist to look for packages by default, however, more advanced users can customize this if they wish.

With the basic description out of the way, they then get into how to add your package to Packagist for others to use. The post also talks about package licensing, development versions, branch aliases, security considerations and how to keep on top of new versions of the packages you have installed.

In this recent post to his site Simon Holywell continues his look at namespacing in PHP with a look at importing and aliasing specific functions, not the entire class.

As a follow on to my short post about namespaces and functions from a year ago I thought it would be worth covering importing a specific function and aliasing functions via namespace operators too. This has been possible since PHP 5.6, but there is a nice addition in PHP 7 I’ll cover towards the end.

He starts with a refresher example of pulling in a namespace and using a method with the "use" statement. Following this he shares an update that just imports the one method via a "use function" call rather than the entire class/namespace. He again refactors this into something more usable (the original method name is quite long) with an alias. He then ends the post with the PHP 7 only trick using the braces to define grouped namespace handling (however, this doesn't allow for function level aliasing).

On the Exakat blog there's a new post sharing six good practices for "use" in PHP. The "use" keyword has a few different places it is used in PHP (like importing namespaced classes and passing in values to closures).

While reviewing code recently, I realized there are no guidelines for use. Every modern code do use ‘use’ (sic), as importing classes from composer or a framework is the norm. There are now quite a few variations in syntax for importing classes or traits. Although the impact on performance is low, as use is solved out, having a clean approach to ‘use’ is important to keep the code clean and readable. Let’s review what are the six good usage of use.

Each of the six tips they share come with a bit of explanation and code to back them up:

• Do not import unused classes
• Alway use alias
• Place all use at first
• Avoid using the same alias for different classes
• Group use expression for easy reading
• Limit the number of use expression

Some of them could be argued as to whether or not they're a "best practice" but it'd definitely interesting to see some tips for the use of this increasingly common little keyword.

Rob Allen's latest post focuses in on something that's been a part of PHP for a while now, back when namespacing was introduced - the "use" keyword. He shares some thoughts, both from others and himself, about whether or not they make code more readable.

I was having a discussion on IRC about use statements and whether they improved code readability or not. [...] Those longer class names make it a little hard to quickly parse what it going on. The [example with "use" statements] is clearly less cluttered, but is at the expense of ambiguity. Exactly what class is User? I would have to go to the top of the file to find out. Should I use aliases? If so, how should I name them?

He went out to Twitter for advice from other PHP developers on the issue too. The feedback from his question came mostly in support of the "use" statements:

• "I think use statements just abstract where the class is coming from. Some people find that useful."
• "I think it's helpful seeing all of the packages used by a class without having to look through the full code."
• "One reason I like them is that I can glance at a file and know dependencies immediately."
• "I do appreciate what you are saying about the indirection use statements introduce."

There's also a bit of talk about "aliasing" with namespaces rather than the full classname, then using the namespace and class name in the code to "minimise ambiguity".

Lorna Mitchell has posted three different ways you can use to get access to a namespaced class in a PHP 5.3 application, all useful depending on where you are in the application and your needs.

After what felt like years of debate over the notation to use for PHP's namespaces, it seems like the feature itself has had relatively little use or attention since it was actually implemented in PHP 5.3. We're all used to working without it but using it does make code neater.

Her three options are:

• Refer Namespace and Class Name
• Import the Namespace
• Alias the Namespace and/or Class

You can find out more about namespaces in PHP applications on the PHP manual.

The SitePoint PHP blog has posted the next two parts of their series looking at using namespaces in PHP - parts 2 and 3:

In the second part of the series they build on the basics and look at importing namespaces into a script, aliasing them to a shorter, easier to use name and some rules to consider about name resolution.

The third part of the series (the last part) looks at the keywords the namespace functionality uses and how to autoload namespaced classes to keep their namespacing intact.

On Till Klampaeckel's blog this recent post shows you how to (quick and easy) set up multiple Magento stores on different domains with the same codebase.

Multiple stores is probably the killer feature of the Magento Commerce store. It enables the needy to manage multiple stores through a single interface. Your very own mall in a box. It's also a management/deployment nightmaredream come true. A single piece of software powering multiple websites.

He sets up his directory structure and shows how to alias certain directories to ones in the local document root so that the application will find things correctly. Drop in a custom index.php "bootstrap" file to run the application and you should be all set.

In response to this previous post, Ben Ramsey has relayed some of this thoughts on the benchmarks that were done by Jonathan Street comparing functions and their aliases:

Mmy first reaction was something like: "Egads! These benchmarks are stupid and misleading! These functions are simply aliases of each other. There should be no discernible difference, and any buffoon should realize this fallacy!" This was before I clicked through from PHPDeveloper.org to read his post.

After reading his data and going on to the Better Benchmarks post that followed it, he found that most of the results of additional testing came out negligible and that there was almost no difference between the two.

Ben illustrates the proof of this with a few lines pasted from the "ext/standard/basic_functions.c" in PHP's source showing that the code is shared via a PHP_FALIAS function call.

In response to this previous post, Ben Ramsey has relayed some of this thoughts on the benchmarks that were done by Jonathan Street comparing functions and their aliases:

Mmy first reaction was something like: "Egads! These benchmarks are stupid and misleading! These functions are simply aliases of each other. There should be no discernible difference, and any buffoon should realize this fallacy!" This was before I clicked through from PHPDeveloper.org to read his post.

After reading his data and going on to the Better Benchmarks post that followed it, he found that most of the results of additional testing came out negligible and that there was almost no difference between the two.

Ben illustrates the proof of this with a few lines pasted from the "ext/standard/basic_functions.c" in PHP's source showing that the code is shared via a PHP_FALIAS function call.