SymfonyWalk - C’est Fini

| Comments

90Km walked in 3 days. And it’s over.

I’ve been walking through amazing and gorgeous places during the last 3 days. I had in mind going to Madrid, but I’ve had two important problems.

  • My feet. This is one of my problems. My feet. What’s wrong with you?!
  • The next section was 42km, through the mountain and with any place where to sleep. No hotels, no hostels, no nice people offering her house. It should not be a problem, but the real problem has one single name. -6 degrees at night. I cannot expose myself for sleeping on the street with that cold. All next sections are like that, after 30-40km walking, nowhere to sleep.

I feel disappointed with myself. I had so many expectations I could do that, but I cannot put myself in danger 1 week before one of my most important moments on my entirely professional life, to be a speaker in the SymfonyCon, in Madrid. My fault.

But things happen. And what I wanted to demonstrate to myself is that I can do that. Yes, sure, with more or less preparation… but I can do that. Because the most difficult part of this things is trying them. And then, once tried, you can fail. Lot of times. You will fail. Even if you don’t expect that, you will fail. But failing is just the beginning of success.

I will stay here, in the middle of nothing, since the SymfonyCon starts. Resting and enjoying something different than Barcelona. The real world.

I want to thank all the people around the world that has encouraged me on this event. I’ll try again soon. Once and again till I achieve my goal. And once achieved, I will go on with another goal. Because this is life, my friends, goal after goal.

Looking forward to see you all in Madrid, this is going to be a great great event.

PD: Ryan, my friend, I will also take a plane XD

SymfonyWalk - Sleeping Bag

| Comments

I expected it would be much easier. Indeed, it should be easier, but once again, the effort on something is just the beginning of something simply bigger called “The plan”.

The problem is that I thought if would be much simple to sleep from Zaragoza to Madrid.

It is not. Damn!

So this is why I will have to sleep in a sleeping bag 9 days. I don’t exactly know where will I be able to clean myself, or to eat something, or sleep. In fact this is what OpenSource is. All OpenSource developers are Walkers in a world without hostels, but nice people.

I expect I will find some contributors around the adventure.

  • Food Pull Requests?
  • Bed Pull Requests?
  • Water Pull Requests?

7 days to go. I am ready. Am I?

PDD, Pragmatic Driven Development, English Version

| Comments

This post is just a translation of one of my previous posts, written in Spanish, for Spaniard people. I just wanted to translate it and to propose my idea to the entirely world, even knowing not everyone will be agree with my point of view.

You will find the original one here

There is a trend, in my opinion, extremely annoying about how we should work in any technical project. We have gone from being a voiceless sector to, for a while, a small egomaniac movement with categorical thoughts, making some monothematic readings so boring for the reader, just because these topics iterated for the umpteenth time with a very theoretical speech, non practical at all, far from the real life.

And that’s what we all need, a great doses of reality. Because reality is practical, not logical.

From my point of view, and given my small experience, I think this movement has to be eradicated to make way for a new movement of thought, maybe circumstantially called PDD, Pragmatic Driven Development (You know… I can also be so witty assigning new names and adding some cool tags to my Linkedin profile…). And the truth is that I am so tired seeing that some people is still telling me how I should do my job, what practices should I follow to make it “the right way” and what guidelines I should take to not being far from the real truth.

The real truth does not exist, or at least should not. Every single speech should have an objective part, based in good practices, but also should have a subjective part, relative to the real circumstances and taking care about the needs of the project. So, this is not seemed to be understood by some people. Seems that, like an outdated political movement, The ego blinds some people to understand so much certainty (must be that we are too used to being treated like sheeps… BeEeEe BeEeEe).

This is why I refuse to listen to such modernistic stupidity without solid arguments. I refuse to be near this hype, created from this people that don’t have any other way to stand out than selling their unique thought like it was the entrance of the heaven of wisdom. We have reached an illness point.

I personally always demand my attendees, or just the people that talk with me, to have an owning point of view, to treat my single one just like another point of view, even if they feel it is not correct, it is different or even distant from theirs, and to use it as a starting point of constructive discussion.

Important, I’m not telling that I disagree all these techniques, I’m not telling that all this architectural knowledge is not useful, I’m not telling that applying a great methodology is useless… I strongly think that all of them, born inside great minds and actually tested with great results, are very useful and really makes us better as developers, giving us more resources to work and making us better able to do our job successfully. I have to tell also that since I am actually practicing lot of them in my projects, like TDD, BDD and DDD, I feel better and more comfortable. I say thanks for that! What I am actually saying is that we are developers, not this kind of stupid people without capacity analysis. At the moment we lose this capacity, we lose our value.

  • Hey, dude! I am actually working on that project! Do you like it?
  • Well, I expect you are doing Hexagonal Architecture…
  • Hmmm… I don’t really need it…
  • You don’t need it? Sure you do!
  • In fact, not.
  • You are wrong!
  • Ok.

It is all about thinking things, and make sure about what we really need at each point, just ignoring everyone telling you, categorically, the way you need to do your job.

I truly hope all this pantomime to be ended soon. I hope as well that one day we will be able to work all together as a community or a team, this is what we really need, keeping in mind what really matters: learning, teaching and doing great projects, no matter the framework, the language even the architecture.

Have a really nice week, and enjoy your work :)

Symfony Walk, the Conference Section

| Comments

The day is getting closer. I am really exited about the idea of the Symfony Walk.

As you may know, the walk will consists in 12 days (10 walking, 2 resting, 1 resting day added as announced for my health), from Zaragoza to Madrid, so today I want to announce formally the last section of the Walk, dedicated to the people in the conference and to the entirely Symfony Community.

I want to open source the last part of my experience. I’d like everyone excited with the idea to walk beside me for the last 38km.

That’s the plan:

Excited about that? Good! Once in Madrid, a cold beer will be our best friend… ever!

Let me know if you want to join us through the Eventbrite event, so we can organize based on the total number of people. You can also contact me through my email, yuhu@mmoreram.com.

Looking forward to meet you there, it is going to be amazing!

PDD, Pragmatic Driven Development

| Comments

Hay una tendencia, a mi parecer, extremadamente molesta sobre como se tiene que trabajar en cualquier proyecto técnico. Hemos pasado de ser un sector con poca voz, a ser, desde hace un tiempo, un pequeño movimiento ególatra de pensamientos categóricos que hacen que según qué lecturas monotemáticas aburran al lector con tópicos iterados por enésima vez y con un discurso teórico, nada práctico, muy lejos de la realidad.

Y esto es lo que necesitamos, una buena dosis de realidad. Porque la realidad es práctica, no teórica.

Desde mi punto de vista, y según la lectura que puedo tener según mi pequeña experiencia, creo que este movimiento debe terminar para dar paso a lo que circunstancialmente podría referirme como PDD, Pragmatic Driven Development (Siguiendo con las directrices… yo también puedo ser muy molón con nombres que quedan de lujo en mi currículum). Y es que estoy cansado de ver como la gente me dice como tengo que enfocar mi proyecto, que prácticas debo seguir para hacerlo “bien” y que directrices debo tomar para no estar lejos de la verdad absoluta.

La verdad absoluta no existe, o no debería existir. Cualquier discurso debería tener una parte objetiva, basado en las buenas prácticas, pero también debería tener una parte subjetiva, relativa a las circunstancias reales y propias del proyecto. Pues parece ser que no se entiende. Parece ser que, y como si un movimiento político desfasado y arcaico se tratara, el Ego ciega demasiado como para poder entender tanta obviedad junta (será lo acostumbrados que nos tienen a ser tratados como borregos).

Es por esto que personalmente me niego a escuchar más estupidez modernista sin argumentos sólidos. Me niego a ser víctima de hype por parte de personas que no tienen más formas de destacar que vender su pensamiento único como si de la entrada al cielo de la sabiduría se tratara. Hemos llegado a un punto enfermizo.

Personalmente siempre exijo que la gente que me escucha tenga un pensamiento propio, que trate mi opinión como otro punto de vista, aunque sea incorrecto, distinto o distante, y que sirva como punto de soporte para dar aún más robustez al argumento que pueda darle uno a un tema específico, dado un punto de partida y un objetivo final.

Que conste, no digo que las buenas prácticas no importen, no digo que tener conocimientos sobre arquitectura no importe, no digo que aplicar una buena metodología no importe… Creo que todas estas prácticas nacidas en grandes mentes y probadas con grandes resultados son herramientas que nos hace mejores, con más recursos y más capaces de trabajar problemas de forma satisfactoria. Debo añadir que soy practicante de muchas de ellas en el punto en que las necesito, y doy gracias a ello. Me hace mejor profesional. Lo que digo es que somos desarrolladores, no gente estúpida sin capacidad de análisis. En el momento que perdemos este análisis, perdemos completamente nuestro valor.

  • Estoy haciendo este proyecto, ¿te gusta?
  • Espero que lo estés haciendo con Arquitectura Hexagonal…
  • Pues la verdad es que no la necesito…
  • ¿Que no la necesitas? ¡Claro que la necesitas!
  • Pues no, en este caso no los necesito…
  • Lo estás haciendo mal.

Se trata de pensar las cosas, y decidir por uno mismo qué necesitas en cada momento, sin dejar que nadie, absolutamente nadie, te diga de forma categórica como debes hacer su trabajo.

Espero de verdad que toda esta borrachera se acabe pronto, espero que en un futuro empiece a haber comportamientos un poco más profesionales para trabajar todos como un equipo o comunidad, que es lo que necesitamos, teniendo en cuenta las cosas que verdaderamente importan: aprender y hacer buenos proyectos, no importa el Framework, el lenguaje o la arquitectura.

Extractor, a PHP Library for Compressed Packages

| Comments

Extractor is a simple php library for extracting all files from compressed packages. Available formats are

  • zip
  • Rar
  • Phar
  • Tar
  • Gz
  • Bz2

You can find the source in the Github repository.

Extractor uses the Finder Symfony component, so the result of extracting all compressed files given a package is nothing more than a Finder instance ready to be iterated and configured.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php

use Symfony\Component\Finder\Finder;
use Mmoreram\Extractor\Filesystem\TemporaryDirectory;
use Mmoreram\Extractor\Resolver\ExtensionResolver;
use Mmoreram\Extractor\Extractor;

$temporaryDirectory = new TemporaryDirectory();
$extensionResolver = new ExtensionResolver();
$extractor = new Extractor(
    $temporaryDirectory,
    $extensionResolver
);

/**
 * @var Finder $files
 */
$files = $extractor->extractFromFile('/tmp/myfile.rar');
foreach ($files as $file) {

    echo $file->getRealpath() . PHP_EOL;
}

You can use the temporary folder of your Filesystem using a TemporaryDirectory instance or you can use a SpecificDirectory instance if you want to specify where all files should be extracted.

1
2
3
4
5
6
7
8
9
10
use Mmoreram\Extractor\Filesystem\SpecificDirectory;
use Mmoreram\Extractor\Resolver\ExtensionResolver;
use Mmoreram\Extractor\Extractor;

$specificDirectory = new SpecificDirectory('/my/specific/path');
$extensionResolver = new ExtensionResolver();
$extractor = new Extractor(
    $specificDirectory,
    $extensionResolver
);

You can also work with remote files.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
use Symfony\Component\Finder\Finder;
use Mmoreram\Extractor\Filesystem\TemporaryDirectory;
use Mmoreram\Extractor\Resolver\ExtensionResolver;
use Mmoreram\Extractor\Extractor;

$specificDirectory = new TemporaryDirectory();
$extensionResolver = new ExtensionResolver();
$extractor = new Extractor(
    $specificDirectory,
    $extensionResolver
);

/**
 * @var Finder $files
 */
$files = $extractor
    ->extractFromFile('http://host.com/my-compressed-file.zip');

Bye Bye Symfony

| Comments

Don’t be afraid. You know what I think about the Symfony components and how I love them. Until now any circumstance has changed my mind about using them in my projects, and over the time, after discover every hidden single piece of code, I have turned more amazed of their power.

The reason of this post is just to tell you, with a simple example, how to say Bye Bye, Symfony! and say Hi PHP!. This really means uncouple from Symfony Components and still use them as the default implementation, while we can securely remove, from the composer require block, our Symfony dependencies.

One of the poor things I have heard these last months has been the word you must or you should event without knowing exactly what is the real direction of my project, so every word in this post will be just an idea you could have in mind when you design your own architecture, thinking about your real needs, far from the things you should or you must do.

To explain that, how we can say goodbye to Symfony, we will start with a simple example. A simple class we could find in every project. Our class will have no sense but will be useful in our specific example, helping us to understand what is all this about.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<?php

/**
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 *
 * Feel free to edit as you please, and have fun.
 *
 * @author Marc Morera <yuhu@mmoreram.com>
 */

namespace Package\Generator;

use Symfony\Component\Routing\Generator\UrlGeneratorInterface;

/**
 * Class UrlPrinter
 */
class UrlPrinter
{
    /**
     * @var UrlGeneratorInterface
     *
     * Url generator
     */
    protected $urlGenerator;

    /**
     * Construct method
     *
     * @param UrlGeneratorInterface $urlGenerator Url generator
     */
    public function __construct(UrlGeneratorInterface $urlGenerator)
    {
        $this->urlGenerator = $urlGenerator;
    }

    /**
     * Generates Homepage route and print complete path
     *
     * @return string Route path
     */
    public function printHomePageRoute()
    {
        return $this
            ->urlGenerator
            ->generate('homepage');
    }
}

As we can see, use this class means use UrlGeneratorInterface. This class is part of the Symfony Routing Component, so is a really bad idea if you really want to make your project multi-environment

Is that good? Well, it depends on your both product requirements and technical requirements. If you want to use always the Symfony router component, this piece of code is good enough. Otherwise, If you want to use another router, you have a problem.

Say your project must work with and without Symfony. Our class should not depend on this interface. One of the strategies to uncouple external implementations is using ports and adapters.

I will explain how it works and how we can implement it.

Real life example

Let’s imagine we want to sell an USB device. We have decided in our product definition that this device will connect to external devices using USB Standard A (the big one). One of the possible approaches would be to design our device with the external connector coupled. This means selling it with the USB wire (like an USB camera, for example).

But why coupling our device with an specific output? Do you know what it really means?

  • If the wire breaks, we must change all the device.
  • You can connect with devices that accept only USB-A
  • Wire improvements means new device versions.

What would be an alternative decision? Well, why don’t we focus our efforts in the camera and we just let other companies to help us with the wire? This means more flexibility for the final user and capability of removing and changing the cable when is broken. And… they could connect their camera to many different formats, even for the most adventurous, their own formats.

So, in fact, our device should have one female USB port with an specification of how connect it with another device. The wire would be just an adapter of our device so many of them could be plugged-in.

We have talked about devices, ports, adapters, specifications, but… how can this help me with my project? Is that hard?

The answer is No.

Solution

Our goal is to create an specification for URL generators and force each adapter to implement it in their own way. As we know, the OOP languages resolve the specification with the interfaces.

Let’s create our specification.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?php

/**
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 *
 * Feel free to edit as you please, and have fun.
 *
 * @author Marc Morera <yuhu@mmoreram.com>
 */

namespace Package\Specification;

/**
 * Interface PackageUrlGeneratorInterface
 */
interface PackageUrlGeneratorInterface
{
    /**
     * Generates a route given its name.
     *
     * @return string Route path
     */
    public function generateUrl($routeName);
}

We are just specifying. We want that, whatever is the implementation, each adapter must fulfill this rule: Has a method called generateRoute that, given the route name, will return its complete path.

Let’s adapt our UrlPrinter to work with specification instead of implementation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<?php

/**
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 *
 * Feel free to edit as you please, and have fun.
 *
 * @author Marc Morera <yuhu@mmoreram.com>
 */

namespace Package\Generator;

use Package\Specification\PackageUrlGeneratorInterface;

/**
 * Class UrlPrinter
 */
class UrlPrinter
{
    /**
     * @var PackageUrlGeneratorInterface
     *
     * Url generator
     */
    protected $urlGenerator;

    /**
     * Construct method
     *
     * @param UrlGeneratorInterface $urlGenerator Url generator
     */
    public function __construct(PackageUrlGeneratorInterface $urlGenerator)
    {
        $this->urlGenerator = $urlGenerator;
    }

    /**
     * Generates Homepage route and print complete path
     *
     * @return string Route path
     */
    public function printHomePageRoute()
    {
        return $this
            ->urlGenerator
            ->generateUrl('homepage');
    }
}

Now, our UrlPrinter does not depends on any external library. Goal reached!

But, now what? I mean, we should implement our adapter, am I right? What is a camera with a great specification and without wire plugged in? (A wireless camera, welcome to the twenty century ^^. Just joking)

Our UrlPrinter needs a PackageUrlGeneratorInterface implementation to be built, so we have to implement an adapter. And because we still want to work with Symfony Routing Component as my first option, we will create the Symfony Adapter for my specification.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<?php

/**
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 *
 * Feel free to edit as you please, and have fun.
 *
 * @author Marc Morera <yuhu@mmoreram.com>
 */

namespace Package\Adapter;

use Package\Specification\PackageUrlGeneratorInterface;
use Symfony\Component\Routing\Generator\UrlGeneratorInterface;

/**
 * Class SymfonyUrlGeneratorAdapter
 */
class SymfonyUrlGeneratorAdapter implements PackageUrlGeneratorInterface
{
    /**
     * @var UrlGeneratorInterface
     *
     * Url generator
     */
    protected $urlGenerator;

    /**
     * Construct method
     *
     * @param UrlGeneratorInterface $urlGenerator Url generator
     */
    public function __construct(UrlGeneratorInterface $urlGenerator)
    {
        $this->urlGenerator = $urlGenerator;
    }

    /**
     * Generates a route given its name
     *
     * @return string Route path
     */
    public function generateUrl($routeName)
    {
        $this
            ->urlGenerator
            ->generate($routeName);
    }
}

This an adapter, my friends. Each adapter has one mission, and is just transform the way we understand the method generateUrl must work (specification) to the way each external project understands it (implementation). In this case, very easy, our generateUrl is the same as Symfony Router Component’s generate.

Symfony Component is now required by this adapter, but because we are not required to use this adapter (Maybe we can use a dummy one for our tests, or a mocked one), Symfony Component is not required by our package anymore, just suggested.

Let’s see another Adapter implementation, requiring another external library.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
<?php

/**
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 *
 * Feel free to edit as you please, and have fun.
 *
 * @author Marc Morera <yuhu@mmoreram.com>
 */

namespace Package\Adapter;

use Package\Specification\PackageUrlGeneratorInterface;
use AnotherProject\UrlGeneratorInterface;

/**
 * Class SymfonyUrlGeneratorAdapter
 */
class SymfonyUrlGeneratorAdapter implements PackageUrlGeneratorInterface
{
    /**
     * @var UrlGeneratorInterface
     *
     * Url generator
     */
    protected $urlGenerator;

    /**
     * Construct method
     *
     * @param UrlGeneratorInterface $urlGenerator Url generator
     */
    public function __construct(UrlGeneratorInterface $urlGenerator)
    {
        $this->urlGenerator = $urlGenerator;
    }

    /**
     * Generates a route given its name
     *
     * @return string Route path
     */
    public function generateUrl($routeName)
    {
        $routeName = '_' . $routeName;

        $this
            ->urlGenerator
            ->anotherGenerateMethod($routeName);
    }
}

Both adapters would be placed in the Adapter/ folder, and the final user should be able to switch them and even implement new ones.

From require to suggest

With our changes, we can remove “symfony/routing” from the require block and add it into the suggest block in composer.json file.

1
2
3
4
5
6
7
8
"require": {
    "php": ">=5.4",
    ...
},
"suggest": {
    "symfony/routing": "Required if using Routing adapter",
    "mmoreram/another-project": Required if using AnotherProject Routing adapter"
},

We will only require the packages needed by the adapter we are using.

What we win

Much. We win maximum implementation flexibility and minimum coupling. Would be wise to say that a PHP project should tend to this thought, but once again, it depends on many factors.

What we lose

It Depends. If you want your project to be understandable by a lot of developing knowledge levels, this architecture goes away from the comprehensibility of a simple code. You also can lose by having lot of files, so you should respect some kind of best practices code, to make people working on your project comfortable dealing with it.

Best practices

I should talk about Marc practices instead of Best practices. I am used to adding my adapters always in the folder /Adapter/{PortName}/, being PortName the name of the port we are dealing with in camel case format. In this case, we should add both adapters in /Adapter/UrlGenerator/.

Given this format we can determine what adapters we can use in our project in a very agile way.

Reference projects

First project that comes in my mind when I think about Ports/Adapters is Gaufrette, a filesystem abstraction layer with a lot of adapters implemented.

In Elcodi we are actually using this library and its really awesome how easy is using it.

We have also implemented internally some features using this architecture, for example, the Geo Schema Populator, a new feature under development that will allow you to populate all Geo schema using some adapters. Right now only GeoData adapter is implemented.

Another example, the Currency Exchange Rates Populator with OpenExchangeRates implementation already done.

Final thoughts

Using ports and adapters is really a great tool for those who want to uncouple from implementations and a great pattern if you develop open source. Open source should satisfy as people as possible, so remember, specify and then implement.

Try it and then tell us your experience :)

One Section, One Component

| Comments

Symfony Walk

Symfony Walk will contain a total of 10 sections, and each one will have the name of one Symfony Component. One of the sections will be named Doctrine (yes, our big friend Doctrine) and last Component will be named like the project I am so proud to work in, Elcodi.

Each day, after walking around 35 Km in about 6 hours, I will post a small introduction about the component that names the current section. I’ll talk also about some scenarios that this component can be useful.

Happy Symfony Walk.

Symfony Walk: Zaragoza - Madrid

| Comments

The 2014 Madrid SymfonyCon is closer every day, and I have to admit that I admire this community. A community that has been able to feed the php world with valuable projects and better people.

I admire the synergies that are created in different repositories that make Symfony one of the best options when developing any web project, and the entire ecosystem that has been created around, an ecosystem very healthy and social.

That’s why I’ll pay my own tribute the coming months.

Symfony Walk 2014

The goal is to walk a path to SymfonyCon Madrid with no more tools than a backpack and good music. The principle of such route will be Zaragoza, so the road will be a total of about 360 kilometers.

I will divide the challenge in 10 days plus one resting day. During the next few days I will also define the final route and all resting points, where I will spend nights.

My reasons are none other than a mixture of personal challenge of something I’ve wanted to do for a long time and my gratitude to this community for all help I’ve received indirectly.

As you know I work on a project called [Elcodi] (http://elcodi.io). we have very clear which is our philosophy and the details that we care until the last sighs of the project, and we know it’s not easy.

We have overcome challenges as an open source project , we are overcoming challenges as an open source project, and hopefully over the next few years we should overcome greater challenges as open source project .

Well, I think the act of walking for 70 hours in 10 days is a good representation of what needs hard work, effort and time, but finally, in the bottom of the road, a great reward awaits your arrival.

In my case, the conference .

I’ll post more details about my little adventure soon.

Porque El Orden Importa

| Comments

La verdad es que reconozco que soy un poco neurótico con el código. Y es que en mi caso me gusta definir la belleza de mis lineas no tan solo en el aspecto funcional y en el aspecto de arquitectura, sino en el aspecto visual. Y en realidad considero que descuidar este aspecto es un problema muy grande a la larga.

Tratemos de pensar en la cantidad de horas que estamos ante estas lineas de código, y luego tratemos de analizar el impacto que estas tienen en nuestro día a día. ¿No creéis que importa el hecho de que esté ordenado, limpio y tratable?

Pues bien, es para esto que, y dado que llevo un tiempo con la manía de ordenar los namespaces de mis ficheros php, he decidido empezar el proyecto php-formatter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Console Tool

Usage:
  [options] command [arguments]

Options:
  --help           -h Display this help message.
  --quiet          -q Do not output any message.
  --verbose        -v|vv|vvv Increase the verbosity of messages
  --version        -V Display this application version.
  --ansi              Force ANSI output.
  --no-ansi           Disable ANSI output.
  --no-interaction -n Do not ask any interactive question.

Available commands:
  help       Displays help for a command
  list       Lists commands
use
  use:sort   Sort Use statements

Lejos de ser un analizador de PSR, cuya función ya cumple a la perfección el proyecto de Fabien Potencier php-cs-fixer, se trata de añadir, en modo comando, algunas funcionalidades tediosas que para mí son importantes, como es el caso de los Use Statements ( Poder ordenarlos por grupos, alfabéticamente o por longitud, ascendiente o descendiente… )

De momento solo hay esta funcionalidad, y aún le faltan un par de opciones, pero no dudéis en proponer comandos que nos puedan ser útiles a todos.

Os invito a que tengáis reglas estructurales y visuales en vuestros proyectos, ya que ayudan un poco a que el código quede un poco más estandarizado con el paso del tiempo, aunque sea a nivel visual.

Vuestros ojos os lo agradecerán.