A couple of weeks ago I migrated a React project using redux to <a target="_blank" rel="noopener noreferrer" href="https://redux-toolkit.js.org/">Redux Toolkit</a>.
Redux has always been my preferred state management tool for React (which doesn&#x27;t mean I &quot;love&quot; it), but one of its main problems is the amount of boilerplate code it requires.
Because of that I had a couple of helper functions, but there was still some things not properly handled, like proper type inference on reducers and actions (I use TypeScript).
A bit by accident (I think it was on Twitter), I found out about Redux Toolkit (RTK from now on), an official library from the redux team, which provides some opinionated helpers to reduce the amount of boilerplate, and I decided to give it a chance.
These are my impressions.
<h3>TL;DR</h3>
I first started to use it in a proof of concept, and I quickly loved it.
RTK does not &quot;replace&quot; any of the redux principles, so you can progressively adopt it, by replacing small bits of code. My plan was to use it just for some reducers, but I liked it so much that I ended up migrating the whole project in a series of consecutive pull requests.
<h3>A bit of context</h3>
Before the migration, I used to follow the <a target="_blank" rel="noopener noreferrer" href="https://github.com/erikras/ducks-modular-redux">ducks modular pattern</a>, which promotes putting all your action types, action creators and the reducer handling those actions on the same module.
This fits pretty well with RTK, as in most of the cases you will use <a target="_blank" rel="noopener noreferrer" href="https://redux-toolkit.js.org/api/createSlice">slices</a>, and end up exporting the reducer and action creators returned by it, from the same module.
If you use <a target="_blank" rel="noopener noreferrer" href="https://redux-toolkit.js.org/api/createAsyncThunk">async thunks</a>, they usually need to be used by that same slice, so it&#x27;s not a bad idea to export them also from there.
<h3>Why I love it</h3>
There are a couple of reasons for which I loved RTK right away. The main one is that they make an impressive work on making type inference in TypeScript work properly.
<ul>
<li>Slices detect the type of the initial state in order to know what is expected to be passed as <code>state</code> to reducers.</li>
<li>You can infer the type of your store from what is generated by <code>configureStore</code> or <code>combineReducers</code> functions, allowing you to also properly type the <code>dispatch</code> function.</li>
<li>Action creators are generated with the proper param types based on the reducers provided to <code>createSlice</code> or the callback provided to <code>createAsyncThunk</code>.</li>
<li><code>createSlice</code> can consume all the action creators generated by <code>createAsyncThunk</code>, and infer the proper payload for each one of them.</li>
</ul>
Thanks to this, the code is super predictable and potential bugs can be caught sooner.
<blockquote>
More details on how to use RTK with typescript https://redux-toolkit.js.org/usage/usage-with-typescript
</blockquote>
But this is not the only benefit. Other reasons that make it very nice to work with are:
<ul>
<li>It keeps the same concepts from Redux, but removing the boilerplate or your own helper functions if you have them (yes, I didn&#x27;t want to keep all those <code>switch</code> statements everywhere).</li>
<li>It is mostly transparent for the components dispatching the actions or consuming the state.</li>
<li>All the tests covering your reducers/actions/components should keep passing, as the outcome from RTK is the same as if you built everything manually.</li>
<li>It introduces a couple of extra helpers, like <a target="_blank" rel="noopener noreferrer" href="https://redux-toolkit.js.org/rtk-query/overview">RTK query</a> or the <a target="_blank" rel="noopener noreferrer" href="https://redux-toolkit.js.org/api/createListenerMiddleware">listener middleware</a>, which is very useful to dispatch actions as a result of other actions being dispatched.</li>
</ul>
<h3>Challenges I found</h3>
Of course, adopting a new tool always comes with some challenges.
The main &quot;problem&quot; I found is that RTK is a bit opinionated, but that&#x27;s precisely how they manage to reduce boilerplate code, and it&#x27;s also &quot;advertised&quot; in their website, so not a big surprise.
I usually prefer to be in control of everything (configuration over convention), but that&#x27;s just a personal preference, and sometimes it&#x27;s ok to accept a bit of magic for the sake of simplicity.
This caused the next challenges for my particular case:
<ul>
<li>
RTK assumes your project follows a strict <a target="_blank" rel="noopener noreferrer" href="https://redux.js.org/tutorials/fundamentals/part-7-standard-patterns#flux-standard-actions">Flux pattern</a>, meaning your actions always have the properties <code>type</code>, <code>payload</code> and optionally <code>meta</code> and <code>error</code>.
I was not following this pattern (my actions had the payload &quot;mixed&quot; on the first object level), so I had to adapt all my actions first, fix the tests, then migrate the reducer to RTK and make sure the tests kept passing.
<div></div>
</li>
<li>
Immutability is no longer promoted in reducers. Instead, the library requires <a target="_blank" rel="noopener noreferrer" href="https://immerjs.github.io/immer/">immer</a> internally, and using proxies they automatically ensure immutability, even if you &quot;mutate&quot; the state.
This feels a bit counterintuitive at first, because redux always promoted an immutable approach, and the use of immer is not obvious.
However, they have <a target="_blank" rel="noopener noreferrer" href="https://redux-toolkit.js.org/usage/immer-reducers#why-immer-is-built-in">good reasons</a> to do it, and if your reducers return a state object, you can still use the immutable approach. It&#x27;s up to you.
<div></div>
</li>
<li>
Action creators resulting of <code>createAsyncThunk</code> can only have one argument.
This is because the async thunk callback receives a second argument containing the <code>dispatch</code> and <code>getState</code> functions, as well as a couple of other goodies, enforcing this convention to avoid human errors.
<div></div>
</li>
<li>
You cannot dispatch other actions after the callback passed to <code>createAsyncThunk</code>, because it has to return the payload and RTK dispatches the action for you.
However, this is probably something you usually should not be doing, and in my case, I resolved it with the <a target="_blank" rel="noopener noreferrer" href="https://redux-toolkit.js.org/api/createListenerMiddleware">listener middleware</a>, listening for the second action in order to dispatch the second one.
</li>
</ul>
<h3>Conclusion</h3>
My conclusion is that RTK is definitely worth it if you use redux.
It makes code simpler, more predictable and better typed. However, it still requires knowing how redux works internally and what are its patterns, in order to understand why the library exposes the helpers it exposes and why.
For existing redux projects, you can migrate progressively, addressing the challenges bit by bit and not all at once, which simplifies its adoption.
For new projects in which you want to use redux, I would recommend starting right away with RTK.

A couple of weeks ago I migrated a React project using redux to Redux Toolkit. Redux has always been my preferred state management tool for React (which doesn't mean I "love" it), but one of its main problems is the amount of boilerplate code it requires.

Because of that I had a couple of helper…

My experience migrating to Redux Toolkit (RTK)

In 2019, GitHub published their own solution to run automated workflows called GitHub Actions, which allowed those hosting their code in GitHub, to be able to define and run their CI/CD pipelines in the same platform. When it was released, one of the main pain points to use it was that defining…

How to reduce duplication in your GitHub Actions workflows

Recently ReactJS v18 was released. I started to look into its improvements, and checked which of my projects could benefit from them.
The main react-based project I maintain at the moment of writing this article is <a target="_blank" rel="noopener noreferrer" href="https://github.com/shlinkio/shlink-web-client">shlink-web-client</a>, so I naturally created a new branch and started the process.
The update was quite smooth, as most of the other dependencies I was using from the react ecosystem were already updated to support v18. All but one, <a target="_blank" rel="noopener noreferrer" href="https://enzymejs.github.io/enzyme/">enzyme</a>, the testing framework I was using to unit-test react components.
To be precise, I was able to continue running my tests, but some of them (those using <code>mount</code> instead of <code>shallow</code>) were still rendering components with the &quot;old&quot; React v17 approach, causing them to behave as in that version and a warning being printed in the console.
<h3>First fix attempt</h3>
The way enzyme integrates with the react version you are using is through an adapter library. The last official one supports only React v16, but someone released an <a target="_blank" rel="noopener noreferrer" href="https://github.com/wojtekmaj/enzyme-adapter-react-17">unofficial adapter for v17</a> which, with close to 650k weekly downloads, quickly became the way to go.
I checked if there was one for React 18, but sadly there wasn&#x27;t.
Also, the author of the adapter for v17 posted an article indicating <a target="_blank" rel="noopener noreferrer" href="https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl">enzyme is dead</a>, he was not going to release one for v18, and publishing one for v17 was a mistake.
With those facts in mind, I started to face what was probably going to be the moment to migrate to <a target="_blank" rel="noopener noreferrer" href="https://testing-library.com/docs/react-testing-library/intro">react testing library</a>.
<h3>Migration strategy</h3>
I decided to follow a migration strategy similar to the one suggested in the article above, but with a couple of modifications:
<ul>
<li>I update to React 18 anyway, as tests still pass.</li>
<li>Migrate right away all tests using <code>mount</code>, as those are the ones behaving differently.</li>
<li>New tests should be written directly with react testing library (RTL from now on).</li>
<li>When an existing test needs to be changed, consider migrating it to RTL, and do it if there&#x27;s time.</li>
<li>Introduce some PR from time to time just migrating a handful of tests.</li>
<li>Once everything is migrated, get rid of everything related with enzyme.</li>
</ul>
<h3>First contact and impressions</h3>
I was a bit sceptical with RTL, as it was focused more on integration tests, instead of unit tests, which meant I had to completely change the mindset to write tests.
It also didn&#x27;t support shallow rendering, meaning that you will end up sometimes rendering a bigger component tree when testing container-like components, potentially causing side effects that could affect your test.
On the other hand there&#x27;s more and more people stating that <a target="_blank" rel="noopener noreferrer" href="https://kentcdodds.com/blog/why-i-never-use-shallow-rendering">shallow rendering is an anti-pattern</a>, and that&#x27;s probably the reason of enzyme getting &quot;discontinued&quot;.
Also, RTL has become the <a target="_blank" rel="noopener noreferrer" href="https://reactjs.org/docs/testing.html#tools">officially recommended framework</a> to test react components, it has become very popular, and it has even joined a wider group of testing libraries under the <a target="_blank" rel="noopener noreferrer" href="https://testing-library.com/"><code>@testing-library</code></a> organization.
The thing is that I started to use it, and I was quickly surprised with how it felt to work with it, and all the benefits it was bringing to my tests.
<h3>Benefits I have experienced</h3>
Once I started migrating the first tests I noticed some benefits:
<ul>
<li>Changing my mindset was actually easier than I thought. The docs are very well written, so it&#x27;s relatively easy to start using RTL.</li>
<li>My tests got simpler, and required less of those nasty global mocks that jest allows (I&#x27;m looking at you, <a target="_blank" rel="noopener noreferrer" href="https://jestjs.io/es-ES/docs/mock-functions#mocking-modules"><code>jest.mock</code></a>).</li>
<li>Tests were way less coupled with implementation details. I moved from testing the component props, to test what the user would see on the screen.</li>
<li>Related with previous point, I started to write my tests by looking at the screen instead of the component&#x27;s implementation.</li>
<li>Changes in source code led to fewer tests requiring to be changed.</li>
<li>A progressive migration was possible, where some tests still use enzyme and others are already using RTL.</li>
</ul>
And overall, it felt good and I have already dedicated a couple of PRs just to migrate more tests.
<h3>Challenges I faced</h3>
But of course, migrating to a new tool always comes with its own challenges, and this was not an exception. I&#x27;ll explain the main ones I have faced so far and how I tackled them:
<ul>
<li>
RTL lets you do some things in a couple of different ways, and the docs may not be super clear about what&#x27;s the recommended option.
For this I recommend reading <a target="_blank" rel="noopener noreferrer" href="https://acel.me/DCMb1">this article</a> from Kent C. Dodds, RTL&#x27;s author, which explains some common mistakes when using the library.
</li>
<li>
At first, I struggled a bit with asynchronous side effects and state changes in components, which can easily end up printing a warning like <code>Warning: An update to MyComponent inside a test was not wrapped in act</code>.
The warning also explains how you are supposed to solve this by wrapping your code in <code>act()</code>, but this warning comes from React, not RTL, and what it is not telling you is that RTL already wraps all needed operations in <code>act()</code>.
What this error usually mean is that you are not waiting for something to happen. <a target="_blank" rel="noopener noreferrer" href="https://acel.me/jnUdT">This other article</a>, also from Kent C. Dodds, explains everything you need to know about the things that can lead to this warning, and how to solve them.
</li>
<li>
Since you start testing from the user point of view, some use cases can be challenging to test without coupling with implementation details. For example, when you have a component which dynamically renders different images or icons, I used to directly check the component properties.
For this I found the best solution was to use <a target="_blank" rel="noopener noreferrer" href="https://jestjs.io/docs/snapshot-testing">jest snapshots</a>. I didn&#x27;t want to manually check which SVG was being rendered in the DOM, just that different ones were being used in every case.
<pre class="language-tsx"><code class="language-tsx">// I went from this...
test(&#x27;...&#x27;, () =&gt; {
 const wrapper = shallow(&lt;MyComp dynamicValue=&quot;foo&quot; /&gt;);
 expect(wrapper.find(FontAwesomeIcon).prop(&#x27;icon&#x27;)).toEqual(someIcon);
})

// To this
test(&#x27;...&#x27;, () =&gt; {
 const { container } = render(&lt;MyComp dynamicValue=&quot;foo&quot; /&gt;);
 expect(container.firstChild).toMatchSnapshot();
})
</code></pre>
</li>
<li>
Something very similar happens if you use some library that renders canvas. There&#x27;s no way to test that from a DOM point of view, which is what RTL does.
In my case I was using <a target="_blank" rel="noopener noreferrer" href="https://www.chartjs.org/">Chart.js</a> to render some charts, so I used <a target="_blank" rel="noopener noreferrer" href="https://github.com/hustcc/jest-canvas-mock">jest-canvas-mock</a>, which exposes a method on the canvas to see which are all the events invoked from the library.
Then I used snapshots again to verify they had the expected &quot;shape&quot;.
<pre class="language-tsx"><code class="language-tsx">// I went from this...
test(&#x27;...&#x27;, () =&gt; {
 const wrapper = shallow(&lt;MyCompWithCanvas /&gt;);
 expect(wrapper.find(Chart).prop(&#x27;data&#x27;).datasets).toEqual(...);
})

// To this
test(&#x27;...&#x27;, () =&gt; {
 const { container } = render(&lt;MyCompWithCanvas /&gt;);
 const events = container.querySelector(&#x27;canvas&#x27;)?.getContext(&#x27;2d&#x27;)?.__getEvents();

 expect(events).toBeTruthy();
 expect(events).toMatchSnapshot();
})
</code></pre>
</li>
</ul>
<h3>Conclusion</h3>
For better or worst, enzyme should no longer be considered an option. If you are starting a new project or are using it on small ones, consider migrating to RTL as soon as possible.
If you are using it in bigger projects, following the process described in this article will probably help you.
In any case, you will get surprised. React testing library is a great tool and provides many benefits over enzyme.
Its main issue is that it&#x27;s not a drop-in replacement for enzyme, so you will have to change a bit your mindset.

Recently ReactJS v18 was released. I started to look into its improvements, and checked which of my projects could benefit from them. The main react-based project I maintain at the moment of writing this article is shlink-web-client, so I naturally created a new branch and started the process.

The…

My experience migrating from enzyme to react testing library

Capturing code coverage for a test suite is a very useful way to know which parts of your source code are actually getting executed by tests. This is useful not only to know if you need to add more tests to your project (in case the coverage is too low), but also, if you want to apply technics like…

Capturing remote code coverage in API tests with PHPUnit

In the last couple of days I have been playing around with the idea of combining GitHub Actions and GitHub Pages to be able to dynamically build preview environments every time a pull request is opened against a repository hosting a client-side web app.
The idea is that you can quickly preview the changes made by some contributor, without having to clone their branch and running everything locally, something specially useful for open source projects.
In this article I will explain how to set everything up, and what are some considerations and problems you may face during the process.
<h3>Enable github pages</h3>
The first thing you need to do is enable your project to publish pages on some branch. I recommend creating a new branch for this, let&#x27;s say <code>preview-env</code>, and then enabling publishing on it.
In order to do that go to your repository and then Settings -&gt; Pages, look for the Source section, and you should see something like this:
<img src="/assets/img/preview-envs/github-pages-before-enabling.png" alt="GitHub pages before enabling"/>
Click in the dropdown and select your new branch, <code>preview-env</code>. Then click Save.
<img src="/assets/img/preview-envs/github-pages-after-enabling.png" alt="GitHub pages after enabling"/>
After saving you will see a message at the top of this section telling you what&#x27;s the URL in which the pages are published. It always follows the same pattern. If your organization is <code>my-org</code> and your repository is <code>my-repo</code>, the url will be <code>https://my-org.github.io/my-repo/</code>.
<h3>Configure the workflow</h3>
Now we need to configure a workflow that will &quot;deploy&quot; the preview environment for the branch every time a new pull request is created or updated:
Let&#x27;s imagine we have a React web app that is built with node.js. The configuration could look like this.
<pre class="language-yml"><code class="language-yml"># .github/workflows/deploy-preview.yml
name: Deploy preview

on:
 pull_request: null

jobs:
 deploy:
 runs-on: ubuntu-20.04
 continue-on-error: true
 steps:
 - name: Checkout code
 uses: actions/checkout@v2
 - name: Use node.js 14.15
 uses: actions/setup-node@v1
 with:
 node-version: 14.15
 - name: Generate slug
 id: generate_slug
 run: echo &quot;##[set-output name=slug;]$(echo ${GITHUB_HEAD_REF#refs/heads/} | sed -r &#x27;s/[~\^]+//g&#x27; | sed -r &#x27;s/[^a-zA-Z0-9]+/-/g&#x27; | sed -r &#x27;s/^-+\|-+$//g&#x27; | tr A-Z a-z)&quot;
 - name: Build
 run: npm ci &amp;&amp; npm run build
 - name: Deploy
 uses: JamesIves/github-pages-deploy-action@4.1.1
 with:
 branch: preview-env
 folder: build
 target-folder: ${{ steps.generate_slug.outputs.slug }}
 - name: Publish env
 uses: marocchino/sticky-pull-request-comment@v2
 with:
 header: Preview environment
 message: |
 ## Preview environment
 https://my-org.github.io/my-repo/${{ steps.generate_slug.outputs.slug }}/
</code></pre>
<blockquote>
If you are not familiar with GitHub Actions yet, take a look at the <a target="_blank" rel="noopener noreferrer" href="https://docs.github.com/en/actions">official documentation</a>.
</blockquote>
This workflow will follow the next steps:
<ul>
<li>Checkout the code from the repository.</li>
<li>Set-up node.js 14.15</li>
<li>Based on the branch name, generate a slug that we will use to have separated deployment folders for every pull request we receive. The slug is exposed to next steps as an output.</li>
<li>Build the project. This step will obviously depend on the needs of your project.</li>
<li>Using <a target="_blank" rel="noopener noreferrer" href="https://github.com/JamesIves/github-pages-deploy-action">JamesIves/github-pages-deploy-action</a>, deploy the contents we previously built in the GitHub page, under a sub-folder matching the slug we generated a few steps above, and under the branch <code>preview-env</code> (remember we enabled GitHub pages for this branch).</li>
<li>Finally, using <a target="_blank" rel="noopener noreferrer" href="https://github.com/marocchino/sticky-pull-request-comment">marocchino/sticky-pull-request-comment</a>, post a comment in the pull request with a link to the preview environment, so that you can just click on it and see the deployment.</li>
</ul>
The steps may change depending on your needs and how you build your project. For example, I have an extra step to update a property in the <code>package.json</code> that is then used to allow serving the app in a sub-path instead of the root of the domain.
You may also not build your site with node.js, as you could be using any of the multiple existing static site generators out there, but you get the idea.
Finally, you have probably noticed the config includes <code>continue-on-error: true</code>. This will allow the pull request to be merged even if this process fails for some reason.
<h3>Considerations when using forks</h3>
While the configuration above will work perfectly when creating pull requests inside the same repository, there are some limitations when the pull request comes from a fork (which is the usual in OSS projects).
For security reasons, the <code>GITHUB_TOKEN</code> injected in those cases doesn&#x27;t have write permissions, which will make the &quot;deploy&quot; step fail.
Also, you cannot define your own token with more permissions and inject it as a secret, as the secrets are not exposed to workflows running on forks.
However, with a couple small config changes, we can work around these limitations:
<h4>Change event</h4>
The first thing we need to do is use the <code>pull_request_target</code> event instead of the <code>pull_request</code> one.
<pre class="language-diff"><code class="language-diff">on:
- pull_request: null
+ pull_request_target: null
</code></pre>
According to the documentation, this is equivalent to the <code>pull_request</code> event, but it runs in the scope of the base repository.
Thanks to this, the <code>GITHUB_TOKEN</code> will come with write permissions, and we will have access to secrets if needed.
<h4>Checkout the fork</h4>
The second thing we are going to change is that we now need to specify the repository to checkout.
In order to do that, we need to add two inputs to the &quot;Checkout code&quot; step, like this:
<pre class="language-diff"><code class="language-diff"> steps:
 - name: Checkout code
 uses: actions/checkout@v2
+ with:
+ repository: ${{ github.event.pull_request.head.repo.full_name }}
+ ref: ${{ github.event.pull_request.head.ref }}
</code></pre>
This will ensure we checkout from the fork repository, instead of the base one, which is the default, as it&#x27;s the one where the <code>pull_request_target</code> event is scoped to.
And that&#x27;s it. With these two changes you can now deploy preview environments for pull requests coming from forks.
<blockquote>
IMPORTANT! The limitations of the <code>pull_request</code> event are there for a reason. People could potentially get access to your secrets or manipulate your code. Proceed at your own risk.
</blockquote>
<h3>Other considerations</h3>
Other than the limitations for forks, there are a few other minor things to take into consideration.
<ul>
<li>Changes in GitHub Pages do not reflect immediately. It may take up to a couple of minutes for the deployment to be available, but considering you will usually not review a PR right after it has been created, this should not be a big issue.</li>
<li>As you have seen, every time a pull request is created, the deployment will generate a new folder in your GitHub Pages branch. This may result in a lot of old folders to pile-up, so you may want to set up some way to clean them up periodically or after the pull request has been merged.</li>
<li>Due to the fact that GitHub Pages only allows static pages to be served, this process cannot be used with apps that require some kind of back-end or server-side logic.</li>
<li>If your project is already using GitHub Pages for something else (serve the project&#x27;s website or docs), that may conflict with this, preventing you from having this kind of preview envs.</li>
</ul>

In the last couple of days I have been playing around with the idea of combining GitHub Actions and GitHub Pages to be able to dynamically build preview environments every time a pull request is opened against a repository hosting a client-side web app. The idea is that you can quickly preview the…

Setting-up a preview environment for your client-side apps with GitHub Actions and GitHub Pages

In a project I&#x27;m working on, we recently needed to add some kind of encryption system that allowed us to store sensitive information in a secure manner, but being able to access to it at runtime in order to pass it to third party services.
Securely storing your own app passwords is easy. You just hash it, and the password can be verified without having to decrypt it, but if you need to &quot;decrypt&quot; it, the solution is not that easy.
We started by building our own solution based on <a target="_blank" rel="noopener noreferrer" href="https://docs.zendframework.com/zend-crypt/">zend/crypt</a>, which is an excellent solution and works like a charm, but you still need to store the master key somehow, and that&#x27;s the big problem.
After some research, someone pointed us to <a target="_blank" rel="noopener noreferrer" href="https://www.vaultproject.io/">vault project</a>, a self-hosted service which manages encrypted key-value pairs, in a more secure manner, where the master key is securely handled. I recommend you read the docs in order to see all its features.
Vault supports different storage backends, each one with its own pros and cons. Some are meant to be used in development environments (like in memory and local file) and others are more suitable for production, with support for high availability (like DynamoDB or <a target="_blank" rel="noopener noreferrer" href="https://www.consul.io/">consul</a>, another hashicorp&#x27;s service).
The official documentation indirectly recommends using vault with consul, which is a service with more features than just storing data. Indeed, it is a service discovery tool widely used this days in container-based infrastructures.
For this reason, we started using both vault and consul in development, in order to get used to both services, but in the end we found it problematic because of different reasons:
<ul>
<li>The consul server needs to get started before vault, otherwise vault fails on start-up. We saw this problem happening in development very frequently, which was annoying.</li>
<li>We talked with an expert sysadmin that was using consul in production environments. He told us it was a magnificent service, but he warn us about the possibility of having random data loss for no apparent reason. 
When using consul as a service discovery tool, that is not a big problem. Just recreating the consul cluster, all the data is retrieved again from running services. In our case it isn&#x27;t that simple. We were going to store sensitive and important data in consul, and loosing it could be a big problem.</li>
<li>I usually prefer to maintain as less services as possible in production. I see it from the point of view of a developer. If there is a cloud service that does the job, I prefer to use it rather than maintaining my own server. 
Be serverless as much as possible.</li>
</ul>
<h3>Finding an alternative</h3>
Ok, consul is discarded. We need another storage alternative.
Looking at vault&#x27;s documentation we saw there are a couple <a target="_blank" rel="noopener noreferrer" href="https://www.vaultproject.io/docs/configuration/storage/dynamodb.html">storage backends</a> that support high availability.
We finally decided to go with <a target="_blank" rel="noopener noreferrer" href="https://aws.amazon.com/dynamodb/">AWS DynamoDB</a>. It is much less prone to data loss due to redundant storage under it, easier to buck-up and restore, and much cheaper than having dedicated servers. Also, the project&#x27;s infrastructure is already in AWS, so communication should be fast.
Using DynamoDB we now only need to manage vault servers.
<h3>Vault&#x27;s high availability</h3>
Another of the vault&#x27;s feature is the possibility to configure several servers in high availability mode, as long as the storage supports it.
This was a must for us, since getting vault down would make the service to not properly work and produce inconsistent data.
The way vault manages high availability is very interesting. The first server that&#x27;s unsealed is set as active, and the rest are set in standby.
If a request is performed to one of the servers in standby, they just redirect the request to the active server.
If the active server is down, then one of the standby servers takes the leadership and is set as active.
The communication between servers does not happen via network communication, but on the shared storage. The active server creates a lock file, and this way, the rest of the servers know they have to standby.
This makes every server to work in an independent manner, and makes it easy to add more servers to the cluster if needed.
The only problem is how do I make my app dynamically read from the active server, but be able to read from others if the active is down.
Do I have to manually manage the load balancing? Do I have to implement some kind of strategy that tries to communicate to each server until one returns a response? That&#x27;s odd.
Vault&#x27;s documentation recommends using another consul&#x27;s feature to solve this problem, some kind of DNS that makes a cluster name to resolve to the active instances IP address. This way you just need to perform requests to the cluster name.
That&#x27;s good, but we weren&#x27;t going to use consul, right?
<h3>AWS internal load balancer to the rescue</h3>
After some investigation we saw contradictory opinions on behalf of hashicorp about using a load balancer with vault. Sometimes they recommend not to use it, sometimes they say they are not against nor in favor.
Because of the way high availability works in vault, if the balancer redirects to a standby instance and it redirects to the balancer again, you could enter an infinite redirection loop.
But what if you could make the load balancer consider standby instances out of service?
Gladly, vault&#x27;s API has an <a target="_blank" rel="noopener noreferrer" href="https://www.vaultproject.io/api/system/health.html">endpoint</a> that performs a health check returning a status 200 only on unsealed active instances. If the instance is not active, it returns a 429 status. This endpoint doesn&#x27;t require authentication.
Using this endpoint for the balancer&#x27;s health check, the balancer will never redirect to a standby instance.
Also, if the active instance has any problem and goes down, as soon as a standby instance takes leadership, the load balancer will notice it, and mark it as InService, starting to redirect requests to that instance.
Pretty nice. We can now configure our app to perform requests to the balancer and the problem is solved.
<h3>Configuring the AWS load balancer</h3>
When configuring the load balancer for the vault instances, we just need to take into account a few things.
First, the balancer should be a classic load balancer, and it has to be configured as internal. This makes the balancer name resolve to the private IP address, and therefore, you prevent anyone accessing vault from the outside.
It should also be configured to forward HTTP traffic on port 8200 (vault works on this port)
<img src="%7B%7Bsite.url%7D%7D/assets/img/vault-with-load-balancer/balancer-first-step.png" alt="Load balancer"/>
Then, when you are asked to configure the health check, use this params.
<img src="%7B%7Bsite.url%7D%7D/assets/img/vault-with-load-balancer/health-check.png" alt="Health check"/>
Configure the interval and healthy threshold according to your needs. Since for me it is a critical service, I reduced the interval to 15 seconds, and set the healthy threshold to 2. This way, when tha active instances goes down, it wont take more than 30 seconds to recover the service.
Finally add the instances to the balancer.
If everything is properly configured, after some seconds, in the instances tab of the balancer, you should see that only one of the instances is InService.
<img src="%7B%7Bsite.url%7D%7D/assets/img/vault-with-load-balancer/instances-status.png" alt="Instances status"/>
Now the balancer and the vault instances are ready to work!

In a project I'm working on, we recently needed to add some kind of encryption system that allowed us to store sensitive information in a secure manner, but being able to access to it at runtime in order to pass it to third party services. Securely storing your own app passwords is easy. You just…

Take advantage of vault project's high availability with an AWS internal load balancer

Recently I have been testing one service and its clustering capabilities, in order to see if it fits in a project I&#x27;m working on.
I decided the easiest way to do this was by creating a couple docker containers and setting up a cluster between them. It should be an easy task in theory.
My first approach was using a docker-compose file and linking the containers between themselves:
<pre class="language-yaml"><code class="language-yaml">version: &#x27;3&#x27;

services:
 test_1:
 container_name: test_1
 image: some:image
 links:
 - test_2
 - test_3

 test_2:
 container_name: test_2
 image: some:image
 links:
 - test_1
 - test_3

 test_3:
 container_name: test_3
 image: some:image
 links:
 - test_1
 - test_2
</code></pre>
My surprise when I run <code>docker-compose up -d</code> was that I received this message:
<pre class="language-bash"><code class="language-bash">ERROR: Circular dependency between test_2 and test_3 and test_1
</code></pre>
It makes sense, since docker-compose checks links in order to run containers in the correct order. It is not possible in this case because every container depends on the other two.
<h3>Fixing the problem with networks</h3>
By default docker assigns random (sort of...) IP addresses to containers. By using links you make an entry to be added to the hosts file of a container, mapping the name of another container with its IP address. This way you don&#x27;t need to know its IP address, you can access it over the network by just using its name.
I needed all containers to have a &quot;known&quot; network identifier in order to get the cluster working, because this service consumes a configuration on start-up that&#x27;s not dynamic.
The solution was making the containers have a static known IP, this way they can be run without links and still communicate between themselves.
Gladly, docker-compose supports networks since version 2, and I was able to define this configuration:
<pre class="language-yaml"><code class="language-yaml">version: &#x27;3&#x27;

services:
 test_1:
 container_name: test_1
 image: some:image
 networks:
 testing_net:
 ipv4_address: 172.28.1.1

 test_2:
 container_name: test_2
 image: some:image
 networks:
 testing_net:
 ipv4_address: 172.28.1.2

 test_3:
 container_name: test_3
 image: some:image
 networks:
 testing_net:
 ipv4_address: 172.28.1.3

networks:
 testing_net:
 ipam:
 driver: default
 config:
 - subnet: 172.28.0.0/16
</code></pre>
Using the <code>ipam</code> you can define a specific CIDR block for the new network, and then, attaching every container to that network, you can specify its IP address on that range.
Now, test_1 is always run with the IP address 172.28.1.1, test_2 with 172.28.1.2 and test_3 with 172.28.1.3, and I&#x27;m able to hardcode those addresses in the config files.
And that&#x27;s all!

Recently I have been testing one service and its clustering capabilities, in order to see if it fits in a project I'm working on. I decided the easiest way to do this was by creating a couple docker containers and setting up a cluster between them. It should be an easy task in theory.

My first…

Set specific IP addresses to docker containers created with docker-compose

Docker is, without any doubt, the trending tool these days. Everybody wants to use it, because it is very useful, allowing to easily generate development environments for any kind of application.
A couple months ago I started working with docker myself (it has taken me a while, I know), and now I can&#x27;t imagine working without it.
I started using it at work, but now I&#x27;m migrating all of my OSS projects too.
<h3>The first stopper</h3>
Regardless docker is very cool, there is a problem when you start using it.
I had my development environment perfectly configured, and all my tools properly integrated. I was able, among other things, to run any project tests from within PhpStorm, just by right-clicking any test class, test method or phpunit.xml file, and selecting the &quot;Run&quot; option.
However, once you start using docker in the project, it is not that simple.
<h3>Integration with PhpStorm</h3>
Gladly, since PhpStorm is a very powerful tool, it supports integration with docker, which can be then used, among other things, to automatically run tests inside a container.
<blockquote>
From this point, I&#x27;m going to explain the process, assuming you have already installed docker in your system. If not, you need to install at least <a target="_blank" rel="noopener noreferrer" href="https://docs.docker.com/engine/installation/">docker engine</a> and <a target="_blank" rel="noopener noreferrer" href="https://docs.docker.com/compose/install/">docker compose</a>.
</blockquote>
The first thing you need to do is configure the connection with docker engine. Go to Settings -&gt; Build, Execution, Deployment -&gt; Docker.
Click the green plus button and a new docker connection will be created. The only value you should need to change is the API URL:
<ul>
<li>Linux: unix:///var/run/docker.sock</li>
<li>Windows and Mac: http://127.0.0.1:2376 (The URL of the docker machine. If you are using the deprecated docker toolbox with boot2docker, you have to make sure which is the IP address of the virtual machine)</li>
</ul>
<img src="/assets/img/phpstorm-docker/phpstorm-docker.png" alt="Docker in PhpStorm"/>
Apply changes and we are done here.
<h3>Create the remote interpreter</h3>
Now let&#x27;s create a remote interpreter. It will be used so that tools that need a php runtime are executed inside a docker container.
Go to Settings -&gt; Languages &amp; Frameworks -&gt; PHP. In here, you select the default interpreter for your project.
<img src="/assets/img/phpstorm-docker/interpreter.png" alt="Interpreter"/>
Click the button with the three dots, which will open the dialog to create a new interpreter.
<img src="/assets/img/phpstorm-docker/interpreter-dialog.png" alt="Interpreter dialog"/>
In that dialog you will likely have a local interpreter. Click the green plus button, at the top-left corner, and select Remote.
That will open the dialog to create a new remote interpreter. One of the options is to use a docker image from which PhpStorm will create a docker container that should contain a php interpreter.
<img src="/assets/img/phpstorm-docker/docker-interpreter.png" alt="Docker iterpreter"/>
In this dialog, just select the server (this is the connection with the docker engine, the one we created in the first step), then select the docker image you want to use. The dropdown will be filled with all the images in your machine.
Finally select the interpreter path. Usually, <a target="_blank" rel="noopener noreferrer" href="https://hub.docker.com/_/php/">PHP-based docker images</a> have the php interpreter in the PATH, so just setting <code>php</code> should be enough.
Save everything and we are done configuring the interpreter.
<h3>Create the PHPUnit config</h3>
Now that the interpreter is created, we have to define a phpunit configuration that uses it.
Go to Settings -&gt; Languages &amp; Frameworks -&gt; PHP -&gt; PHPUnit, Use the green plus button at the top-left corner, select By Remote interpreter and a dialog window will be prompt.
It only contains a dropdown where you have to select the remote interpreter we created in previous step.
Select it and you&#x27;ll see a configuration similar to this.
<img src="/assets/img/phpstorm-docker/phpunit.png" alt="PHPUnit configuration"/>
As you can see, PhpStorm mounts the project dir as a volume inside the container, in the <code>/opt/project</code> dir, and based on that path, selects the path to composer&#x27;s autoloader script and the phpunit.xml script.
If any of those params is not correct in your project, you can (and should) change it.
And that&#x27;s it!
Now, you can right-click any test class, test method or phpunit.xml file and select &quot;Run&quot;. PhpStorm will automatically connect with docker engine, set up a temporary container and run the tests inside of it.
You&#x27;ll know it is working because of this:
<img src="/assets/img/phpstorm-docker/tests-in-container.png" alt="Tests inside container"/>
<h3>Conclusion</h3>
PhpStorm&#x27;s team is always working to add integrations with the latest development tools, making it the most powerful IDE for PHP.
Now go, configure your environment and start using docker. It&#x27;s amazing!

Docker is, without any doubt, the trending tool these days. Everybody wants to use it, because it is very useful, allowing to easily generate development environments for any kind of application. A couple months ago I started working with docker myself (it has taken me a while, I know), and now I…

Run PHPUnit tests inside a docker container from PhpStorm

<a target="_blank" rel="noopener noreferrer" href="https://letsencrypt.org/">Let&#x27;s Encrypt</a> is the latest internet trending. Its a relatively young Certification Authority which intends to provide free and automated SSL certificates so that everybody can set encryption to their sites and applications.
It is a <a target="_blank" rel="noopener noreferrer" href="https://www.linuxfoundation.org/">Linux Foundation</a> project sponsored by most of the biggest Internet companies, such as Google, Facebook, Mozilla or Cisco.
They provide tools to automatically generate, setup and renew SSL certificates, but those tools are still in early stages, and not all the integrations are easy.
In this article I&#x27;m going to explain how to setup one of this certificates in an Amazon Web Services Elastic Load Balancer (ELB from now on).
<h3>Generate the certificate</h3>
There are very good tutorials out there on how to generate a certificate, so I&#x27;m not going to dedicate much to this.
I usually follow the instructions from <a target="_blank" rel="noopener noreferrer" href="https://certbot.eff.org/">certbot</a>.
In there, you have to choose the web server of your choice, in this case &quot;None of the above&quot;, and your operating system, for example Ubuntu 16.04 (the only difference with older Ubuntu versions is that you can install the CLI tool from the standard repositories, otherwise there is a previous step where you have to download the <code>certbot-auto</code> script and run it, but that&#x27;s it).
Once you have installed the <code>letsencrypt</code> tool (or <code>certbot-auto</code>), you have to generate the certificate with the webroot plugin. This plugin just generates the certificate by providing the document root for each domain that will be included in the certificate.
<pre><code>letsencrypt certonly --webroot -w /var/www/mydomain -d mydomain.com -d www.mydomain.com -w /var/www/cool-site -d cool-site.com -d www.cool-site.com
</code></pre>
This will create a certificate valid for mydomain.com, www.mydomain.com, cool-site.com and www.cool-site.com.
All of the domains get verified from let&#x27;s encrypt side by putting a temporary hidden file inside provided web root folders.
In this case, the first two domains will be checked in the /var/www/mydomain folder, and the last two in /var/www/cool-site. If those domains are really served from there, the certificate will get properly created.
The problem with this in an Elastic Load Balancer is that you are running this tool in one server, but you will have more than one balanced server. This could make the previous process fail if the wrong server responds to the let&#x27;s encrypt check request.
To prevent this you will have to leave just one server temporarily. Don&#x27;t worry, it only takes a few seconds. Once the certificate is created you can add the rest of the servers again.
<blockquote>
There are other plugins which simplify deploying certificates in standalone web servers.
</blockquote>
<blockquote>
For example, the apache plugin automatically sets the configuration in the apache virtual host of your choice.
</blockquote>
If everything worked, you should now have 4 files in the <code>/etc/letsencrypt/live/mydomain.com</code> folder.
<pre><code>/etc/letsencrypt/live/mydomain.com
 |-- cert.pem
 |-- chain.pem
 |-- fullchain.pem
 |-- privkey.pem
</code></pre>
<h3>Setup the certificate in an ELB</h3>
Now that you have your certificate files, you need to upload them to the ELB.
Go to the AWS web console, select the EC2 service and go to Load Balancers. Once there select the load balancer of your choice and go to the Listeners tab.
<img src="/assets/img/load-balancers-listeners.png" alt="Load Balancer listeners"/>
Now you have to click on the &quot;Change&quot; link, in the SSL Certificate column of the HTTPS protocol, in order to set the new certificate.
<img src="/assets/img/load-balancers-set-certificate.png" alt="Load Balancer set SSL Certificate"/>
In this window, select the third option, Upload a new SSL certificate to AWS... and set the name of your choice for it.
Then, in the Private key field you have to place the contents of the <code>cert.pem</code> file, and in the Public key certificate field, the contents of the <code>fullchain.pem</code> file. You can leave the Certificate chain field empty.
Save, and you are done. Your ELB is now serving HTTPS request by using the previously generated Let&#x27;s Encrypt certificate.
<h3>Renewal</h3>
Renewing this certificate is easy. Just run the command <code>letsencrypt renew</code> (or <code>certbot-auto renew</code>) in the same server used to create the certificate in the first place.
That will generate the new certificate in the same location, and you can repeat the previous step with it.
The main problem with Let&#x27;s Encrypt certificates is that they are valid for three months only. Auto renewal is a feature that they want to implement at some point, but it&#x27;s not available yet.
By the moment, the best solution for standalone servers is creating a cron job that automatically runs the <code>letsencrypt renew</code> command, but for an ELB that won&#x27;t fix the problem.
You will probably need to create some kind of script that automatically uploads the certificate to the ELB after being renewed, by using the AWS REST API or the CLI interface.
<a target="_blank" rel="noopener noreferrer" href="http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-update-ssl-cert.html#us-update-lb-SSLcert-cli">This documentation</a> should be helpful. Pay special attention to the To replace an SSL certificate with a certificate uploaded to IAM section.

Let's Encrypt is the latest internet trending. Its a relatively young Certification Authority which intends to provide free and automated SSL certificates so that everybody can set encryption to their sites and applications. It is a Linux Foundation project sponsored by most of the biggest Internet…

Setup a Let's Encrypt certificate in a AWS Elastic Load Balancer

<a target="_blank" rel="noopener noreferrer" href="https://getcomposer.org/">Composer</a> is The Tool in any modern PHP project. Nowadays I can&#x27;t imagine to work without it.
It is much more powerful than some people think, easily solving the integration of third party components in our projects, but there are some advanced features that are less known.
I&#x27;m going to try to explain some of the best practices and mechanisms bundled with composer.
<blockquote>
If you are not familiar with composer, some time ago I wrote an introduction article that you should read before continuing with this one. <a href="/2014/07/19/dependency-management-and-autoloading-in-php-projects-with-composer/">Dependency management and autoloading in php projects with composer</a>.
</blockquote>
<h3>Globally installing composer</h3>
It is a good practice to have composer installed globally, instead of having a binary file per project.
After downloading the <code>composer.phar</code> file from the <a target="_blank" rel="noopener noreferrer" href="https://getcomposer.org/download/">composer</a> website, you can start using it by running <code>php composer.phar [...]</code>. Instead, we are going to place it in a global location so that we can run the command <code>composer [...]</code> from this moment on.
In UNIX systems, just make the file executable and move it to a folder that&#x27;s already in the path.
<pre class="language-bash"><code class="language-bash">sudo chmod +x composer.phar
sudo mv composer.phar /usr/local/bin/composer
</code></pre>
Under Windows systems, there is an installer that will make the work for you. Download it <a target="_blank" rel="noopener noreferrer" href="https://getcomposer.org/doc/00-intro.md#installation-windows">here</a>.
Now, go to any location and run <code>composer</code>. You should see composer&#x27;s help.
<h3>Create the composer.json file</h3>
The first thing you should do when starting a new PHP project is to create the composer.json file. It is the main configuration file, where metadata, dependencies and autoloading are defined.
You probably don&#x27;t remember the main parts of this file, and end up copying the file from othe projects. There is no need to do that, just run <code>composer init</code> and the Composer config generator will be executed, guiding you over the process of creating the file.
<h3>Add dependencies to an existing composer.json file</h3>
In the documentation of many libraries, they tell you to manually edit your composer.json file to add new dependencies. That can be problematic, because you could have a syntax error, forget to add a trailing comma, etc.
The best practice to add dependencies to your composer.json file is to run the command <code>composer require vendor-name/library-name ~3.0</code>. That will add the new dependency to your file (avoiding syntax errors) and then install it.
If you don&#x27;t include the version name, composer will try to find out what&#x27;s the best version to use, by following <a target="_blank" rel="noopener noreferrer" href="http://semver.org/">Semantic Versioning</a>. If it is not able to know which version to use, it will ask you to decide.
<h3>Production environments</h3>
The management of dependencies and new classes is not the same in our development environment and the production environment. In development we need new classes to be automatically autoloaded, and we want to have certain dependencies, like phpunit or php code sniffer that are not of any use in production.
In development we will usually install or update dependencies by running <code>composer install</code> or <code>composer update</code>. That will include all dependencies in require and require-dev blocks, and generate an autoloader by following different strategies. Some of those autoloading strategies imply the iteration of directories in order to find class files.
That is ok for development, but in production we need something more efficient than that, and also, we don&#x27;t want require-dev dependencies to be installed.
To get this done, in a deployment process, we should run this command instead.
<pre class="language-bash"><code class="language-bash">composer install --no-dev --optimize-autoloader --prefer-dist --no-interaction
</code></pre>
This is what each flag makes:
<ul>
<li><code>--no-dev</code>: prevents dependencies defined in the requre-dev block to be installed.</li>
<li><code>--optimize-autoloader</code>: generates a classmap autoloader, that will map each class with the file that contains it, preventing unnecessary directory iterations.</li>
<li><code>--prefer-dist</code>: installs distributable versions of the libraries, instead of source code, when possible.</li>
<li><code>--no-interaction</code>: will always try to make the proper decission in case any &quot;conflict&quot; is produced, so that the process is completly unatended.</li>
</ul>
This is the command you should use when deploying a project, just after clonning a clean repository.
<h3>Private repositories</h3>
This is probably one of the most powerful features while working on many private projects that depend on each other.
By default, composer fetches dependencies from a single repository, <a target="_blank" rel="noopener noreferrer" href="https://packagist.org/">Packagist</a>, which needs to have access to a public repository (usually github). But what happens if my code is private, and I don&#x27;t want to (or can&#x27;t) open source it? May I use composer to install private dependencies? The answer is yes.
The composer.json file can include a repositories block, where we define other repositories (either public or private) where composer will try to find dependencies.
There are several repository types supported by composer, from a VCS repository to a plain local directory containing zip files.
<pre class="language-javascript"><code class="language-javascript">{
 &quot;repositories&quot;: [
 {
 &quot;type&quot;: &quot;vcs&quot;,
 &quot;url&quot;: &quot;https://my-repos.com/something-private&quot;
 },
 {
 &quot;type&quot;: &quot;pear&quot;,
 &quot;url&quot;: &quot;http://pear2.php.net&quot;
 },
 {
 &quot;type&quot;: &quot;artifact&quot;,
 &quot;url&quot;: &quot;path/to/directory/with/zips/&quot;
 }
 ]
}
</code></pre>
Composer will look for dependencies on each defined repository in order, and Packagist as a last resource.
Defining repositories is very flexible and a little bit complex in some cases, so I recommend you to read the <a target="_blank" rel="noopener noreferrer" href="https://getcomposer.org/doc/05-repositories.md">documentation</a>.
<h3>CLI scripts</h3>
Sometimes a library includes some command line interface scripts that the user can use to automate configuring some stuff.
If you want to include your own CLI scripts and allow any user to find them when installing your library as a dependency, you will want to define them in the bin block.
<pre class="language-javascript"><code class="language-javascript">{
 &quot;bin&quot;: [
 &quot;scripts/generate-foo&quot;,
 &quot;scripts/create-bar&quot;,
 &quot;scripts/do-something&quot;
 ]
}
</code></pre>
It is just a list of script paths that composer will &quot;copy&quot; to the <code>vendor/bin</code> directory after installation (it doesn&#x27;t really copy them, it creates symlinks in UNIX systems and generates bat files under Windows).
This makes all the CLI scripts of all dependencies to be &quot;placed&quot; in the same location, so it is easier to find them.
This makes sense only in non-root projects (those that will be installed as dependencies of other projects and are not base applications).
<h3>Events</h3>
Composer will trigger some events during the process of installing dependencies, generating autoloaders and such. You can define some scripts or code snippets that will be automatically executed when those events are triggered.
These event listeners are defined in the scripts block. They can be either CLI commands or static class methods.
<pre class="language-javascript"><code class="language-javascript">{
 &quot;scripts&quot;: {
 &quot;post-package-install&quot;: &quot;Acelaya\\MyClass::postPkgInstall&quot;,
 &quot;post-install-cmd&quot;: [
 &quot;Acelaya\\MyClass::postInstall&quot;,
 &quot;phpunit -c app/&quot;
 ]
 }
}
</code></pre>
The complete list of events can be found in composer&#x27;s <a target="_blank" rel="noopener noreferrer" href="https://getcomposer.org/doc/articles/scripts.md#event-names">documentation</a>. Take a look at them and see if you can optimize your workflow.
<h3>Applications installation</h3>
At this point we all know that we can use composer to install libraries at project level, but what happens with applications, known as root projects in composer&#x27;s terms.
We can also use composer to distribute complete applications, allowing them to be easily installed by using this command.
<pre class="language-bash"><code class="language-bash">composer create-project vendor-name/app-name
</code></pre>
This will download the application (as if we would have cloned the repository) and then install its dependencies. We could even take advantage of composer&#x27;s events, and initialize a database or create some non-tracked directories.
<h3>Conclusion</h3>
And that&#x27;s pretty much all.
Use composer, it will improve your PHP projects.

Composer is The Tool in any modern PHP project. Nowadays I can't imagine to work without it. It is much more powerful than some people think, easily solving the integration of third party components in our projects, but there are some advanced features that are less known.

I'm going to try to…

Composer advanced concepts

Some time ago I wrote the most successful article of this blog, Advanced usage of ServiceManager in Zend Framework 2, explaining all the ways a service can be created by making use of Zend\ServiceManager, the service container component in Zend Framework 2. On this article I'm going to show a real…

Managing objects creation and dependency injection with Zend\ServiceManager

Setting up a development environment is not always easy, specially for web development. Sometimes you need to install and configure plenty of applications. A database server, a web server, server-side programming language binaries, mail server, job queue server, specific package managers, building tools, debug and profiling tools, etc.
Each one of them will need to be in a concrete version, and you will need to handle their dependencies too. You could think that&#x27;s a one time task, but what happens when you work on multiple projects at the same time. You need to install that for each one of them, and also make sure there are no conflicts with different environments.
There is a tool that eases this task, called <a target="_blank" rel="noopener noreferrer" href="https://www.vagrantup.com/">Vagrant</a>, that allows us to create a virtualized environments with all the tools, system packages and applications we need to use in a project. Each environment is running on its own virtual machine, so there is no conflicts between them.
The configuration of each virtual machine is defined in a file, that can be pushed to the VCS server, so that any other team member can use the same exact environment as you. By using that file, Vagrant creates a machine, downloads the OS and installs it, installs the packages and starts services, so that we can start working in no time.
This is a much more efficient way to work, since that configuration file (called Vagrantfile) can be reused multiple times.
<h3>Installing vagrant</h3>
Vagrant is a command line tool which eases the interaction with the virtual machines. Start a machine, halt a machine open a SSH connection or refresh the configuration by reading the Vagrantfile are easy tasks which only need a certain command to be executed.
There are packages for every major operating system that can be downloaded from <a target="_blank" rel="noopener noreferrer" href="https://www.vagrantup.com/downloads.html">here</a>.
You will also need to install <a target="_blank" rel="noopener noreferrer" href="https://www.virtualbox.org/wiki/Downloads">VirtualBox</a> to handle virtual machines. Others are supported too.
<h3>Creating the Vagrantfile</h3>
The Vagrantfile is the main configuration file for the virtual machine. It defines the operating system to be used, the system packages to be installed and how to do it, ports to be mapped to the host machine, folders to be shared, etc.
It is usually placed in the root directory of your project, since the folder containing it will be mapped to the folder <code>/vagrant</code> inside the virtual machine. This way the complete project will be available inside the virtual machine, for example to be served by a web server.
A simple example of a Vagrantfile could be this.
<pre class="language-ruby"><code class="language-ruby">Vagrant.configure(&quot;2&quot;) do |config|
 
 # This is the operating system to be installed. Ubuntu 12.04 in this case
 config.vm.box = &quot;hashicorp/precise32&quot;
 
 # The script &quot;bootstrap.sh&quot; will we run within the virtual machine once installed
 config.vm.provision :shell, path: &quot;bootstrap.sh&quot;
 
 # The port 8888 will be forwarded from the local machine to the virtual machine&#x27;s port 80
 config.vm.network :forwarded_port, host: 8888, guest: 80
 
end
</code></pre>
This is very easy to undertand. We are telling vagrant to install Ubuntu 12.04, start the machine and run the bootstrap.sh script, which could be used to define which system packages to install.
Then, we forward the port 8888 in the local machine to the port 80 in the virtual machine, so that we can see the application by accessing to <code>http://localhost:8888</code>.
You have an example project using this Vagrantfile <a target="_blank" rel="noopener noreferrer" href="https://github.com/acelaya-blog/vagrant">here</a>. Clone it, go to the folder and run <code>vagrant up</code>. Once it finishes go to <a target="_blank" rel="noopener noreferrer" href="http://localhost:8888">http://localhost:8888</a> and you should see a nice Hello World! which is being served from the virtual machine.
However, this example is too simple. In real projects we usually have more complex requirements, and configuring the complete Vagrantfile is not so easy.
For this situations, we have multiple online assistants which can be used to create more complex Vagrantfiles. One of the best for PHP projects is <a target="_blank" rel="noopener noreferrer" href="https://puphpet.com">PuPHPet</a>, which is based on Puppet.
<h3>Setting up the machine</h3>
The first step is to go to <a target="_blank" rel="noopener noreferrer" href="https://puphpet.com">PuPHPet</a>&#x27;s webpage and follow the steps of the wizard. Select the operating system to be installed, the web server, the PHP version and such, the result depends on your needs. Once you finish this you will be able to download a complete configuration file.
Extract downloaded file wherever you want, open a console and go to the extracted folder. Now run <code>vagrant up</code> and the machine will be created and configured. This process may take some time, so be patient.
After a while, the virtual machine will be up an running. You can take a look at the extracted Vagrantfile and see that it is a little more complex than the first example.
If you include the Vagrantfile and the puphpet folder in your project&#x27;s VCS you will be able to reproduce the same environment anywhere you go just by clonning the repository.
<h3>Guest and host machine integrations</h3>
SSH access: One of the more common things we&#x27;ll need to do is to open a SSH connection against the virtual machine. To accomplish that task we just need to go to the folder where the Vagrantfile lives, or one of its subfolders and run <code>vagrant ssh</code>. Now you are able to do anything on the virtual machine as if it were your host machine.
Folders sync: Another thing we&#x27;ll probably need to do is to sync folders between the host machine and the guest machine. As I said earlier, the Vagrantfile parent folder is mapped by default to the <code>/vagrant</code> folder in the virtual machine, but we could change the folders in case of need.
To define a folder that should be synced, just place a line like this in your Vagrantfile.
<pre class="language-ruby"><code class="language-ruby">config.vm.synced_folder &quot;subfolder/&quot;, &quot;/anywhere/else/in/the/virtual/machine&quot;
</code></pre>
Port forwarding: This was seen in the first example. We could map a port in the host machine to another port in the virtual machine so that requests to the first one are forwarded to the other. We could also access the virtual machine IP or hostname directly, that depends on our needs.
<h3>Managing virtual machines</h3>
After some time working with vagrant you&#x27;ll probably have more than one virtual machine created and vagrant also provides some commands to handle them. By the way, the virtual machines in vagrant are called boxes.
We have seen that the <code>vagrant up</code> command creates a virtual machine, but it also turns on a previously halted box. To safely halt a virtual machine, just run <code>vagrant halt</code> and all the resources will be freed. We have also the <code>vagrant suspend</code> which, as you can guess, is used to suspend a box and <code>vagrant resume</code>, which resumes a suspended box.
Sometimes we will need to update a virtual machine. Updating the Vagrantfile and running the <code>vagrant up</code> command is not enugh for already created boxes, you will need to run <code>vagrant reload</code> so that the Vagrantfile is processed again. If you also need to refresh the provisions (the bootstrap.sh script in our first example) either run <code>vagrant provision</code> or <code>vagrant reload --provision</code> which will both reload the configuration and provision the machine.
Finally, when you need to delete a virtual machine, just run <code>vagrant destroy</code>.
You can also manage all the boxes you have installed, without having to be in the directory of a specific machine, by using the commands under <code>vagrant box</code>. Try <code>vagrant box help</code> to see what&#x27;s available.
<h3>Conclusion</h3>
This is pretty much it. This will let you encapsulate a PHP project inside a virtual machine, allowing you to use different applications and services on each one of them and &quot;tracking&quot; the state of the machine itself so that any collaborator can work in the same environment as you.
Of course there are other advanced usages for Vagrant, like deployment of machines to virtualization systems like Amazon Web Services, but that&#x27;s another articles subject.
For a complete vagrant documentation, follow this <a target="_blank" rel="noopener noreferrer" href="https://docs.vagrantup.com/v2/getting-started/index.html">link</a>.

Setting up a development environment is not always easy, specially for web development. Sometimes you need to install and configure plenty of applications. A database server, a web server, server-side programming language binaries, mail server, job queue server, specific package managers, building…

Setting up a PHP development environment with Vagrant

Some time ago, on January 2014, I decided to start writing a blog.
Seemed like a good idea. I might be able to show my skills and learn new ones at the same time.
I didn&#x27;t wanted to use a very complex tool for this purpose, or to create one of my own (why to reinvent the wheel?), so I decided that blogger or wordpress could be the right options.
After weighing the pros and cons of both options I opted for wordpress, because it seemed more customizable, and having a <a target="_blank" rel="noopener noreferrer" href="https://en.wikipedia.org/wiki/Virtual_private_server">VPS</a> could ease the self-hosting task.
At the begining it was a good solution, but finally proved to be hard to control. Not easy to customize the layout, very resource consuming, hard to optimize, etc.
I looked for alternatives and found an interesting one without all the previous problems, <a target="_blank" rel="noopener noreferrer" href="https://sculpin.io/">Sculpin</a>.
We discussed the tool in the <a target="_blank" rel="noopener noreferrer" href="https://twitter.com/symfony_zgz">Symfony Zaragoza</a> group, and I really loved it from the begining.
<h3>First approach to Sculpin</h3>
In the Github era, many static site generators have appeared, because Github allows us to host static sites for free. Those generators allows us to make a &quot;dynamic&quot; website which is compiled into a static site.
There are many alternatives. From <a target="_blank" rel="noopener noreferrer" href="https://jekyllrb.com/">Jekyll</a>, the Github official static site generator written in ruby, to <a target="_blank" rel="noopener noreferrer" href="http://blog.getpelican.com/">Pelican</a>, another python-powered alternative.
The problem is that I&#x27;m a PHP developer, and I&#x27;m not as confortable with those languages as I am with PHP, so I looked for a PHP alternative and Sculpin appeared.
Sculpin uses Symfony components, and is fully integrated with composer. I like both tools so I finally decided to use it.
For more information about how to use Sculpin, it has a very good <a target="_blank" rel="noopener noreferrer" href="https://sculpin.io/getstarted/">documentation</a>.
<h3>Migrating from Wordpress</h3>
There was a few features in wordpress that I didn&#x27;t wanted to loose and are not easy to implement in a static site, like comments, built-in search and RSS feed. I also didn&#x27;t wanted to loose the already indexed content, so I needed to keep the old URLs, at least those pointing to the articles.
Luckily for me, there is a <a target="_blank" rel="noopener noreferrer" href="https://github.com/sculpin/sculpin-blog-skeleton">Sculpin Blog Skeleton</a> in github with many of the work already done. It includes an atom feed that is refreshed every time you compile your site.
To get comments in my static blog, I have used <a target="_blank" rel="noopener noreferrer" href="https://disqus.com/">disqus</a>. It uses a very easy javascript api to host your comments which are associated to the article&#x27;s unique URL. Also, they allow to import comments from wordpress, so I could also keep the old comments.
There are other platforms like this, but they don&#x27;t look as good as disqus.
The built-in search was one of the hardest features to implement. I have used <a target="_blank" rel="noopener noreferrer" href="http://lunrjs.com/">lunr.js</a>, a javascript full text search engine, but I was not sure how to deal with it, so I finally found a Sculpin blog using it, and copy-pasted the needed code. Thanks to <a target="_blank" rel="noopener noreferrer" href="http://blog.andrewshell.com">Andrew Shell</a> for his code.
After this I just needed to get the articles from wordpress.
Sculpin uses <a target="_blank" rel="noopener noreferrer" href="http://twig.sensiolabs.org/">twig</a> templates and/or <a target="_blank" rel="noopener noreferrer" href="http://es.wikipedia.org/wiki/Markdown">markdown</a> to write articles, so it&#x27;s easy to copy-paste html documents on them. That&#x27;s what I did. A little customization and done.
Keeping the URLs was easy, because I was using the y/m/d/foobar form in wordpress, and the Sculpin skeleton uses that format by default.
Finally I was considering to host the blog in Github, but I decided to use my VPS, to use some htaccess tricks, like some rewrite rules in order to redirect old URLs to new ones and set a customized 404 page.
The result is the blog you are now seeing.
<h3>Conclusion</h3>
My conclusion is that a dynamically generate static site is a good solution for a personal blog. It loads superfast, is very SEO friendly and is easily customizable, but it has an important problem. Only advanced users can use it.
The lack of <a target="_blank" rel="noopener noreferrer" href="https://es.wikipedia.org/wiki/WYSIWYG">WYSIWYG</a> editor makes users with no experience on HTML/Markdown (at least) impossible to deal with this kind of sites.
Also, the site needs to be deployed every time a new article is written.
Apart from that, as I said, It&#x27;s a good solution, and Sculpin is a really good tool. If you are curious, you can see the pre-compiled version of this blog in github, <a target="_blank" rel="noopener noreferrer" href="https://github.com/acelaya/blog">here</a>.

Some time ago, on January 2014, I decided to start writing a blog. Seemed like a good idea. I might be able to show my skills and learn new ones at the same time.

I didn't wanted to use a very complex tool for this purpose, or to create one of my own (why to reinvent the wheel?), so I decided that…

Migrating from Wordpress to Sculpin

One of the common problems we have to confront when starting a new PHP project is how to handle the different dependencies we are going to have.
One could think the easier solution is to download all the libraries we are going to need, put them in a <code>lib</code> directory and add them to the version control of the project, but this could be problematic. Let&#x27;s see why.
The main problems of using this practice are this.
<ul>
<li>Dependencies of dependencies: Our dependencies may have their own dependencies that we will also need to download.</li>
<li>Updates: What happens if we need a new feature in the last version of one dependendency? We are going to have to update it manually, and that can be a hard task. Baybe even the new version has new dependencies of its own that we will need to download.</li>
<li>Autoloading: How do we deal with autoloading the classes in the dependencies? Some of them may have its own autoloading system, but anyway, we are going to need to <code>include</code> all the autoloaders of each dependency.</li>
</ul>
How do we solve all of this? The answer is <a target="_blank" rel="noopener noreferrer" href="http://getcomposer.org">Composer</a>.
<h3>Starting with composer</h3>
Composer has become the dependency manager in the main PHP projects. It uses its own library repository (<a target="_blank" rel="noopener noreferrer" href="https://packagist.org/">packagist</a>) to handle dependencies, but you can setup private repositories too.
It uses a small configuration file, the <code>composer.json</code>, to know which are our dependencies, and it will download their dependencies recursively without us having to do anything special.
We can define an autoloading strategy in that file too, and forget about that task for our project and our dependencies.
This are some examples of famous PHP project&#x27;s <code>composer.json</code> files:
<ul>
<li><a target="_blank" rel="noopener noreferrer" href="https://github.com/zendframework/zf2/blob/master/composer.json">Zend Framework</a></li>
<li><a target="_blank" rel="noopener noreferrer" href="https://github.com/symfony/symfony/blob/master/composer.json">Symfony</a></li>
<li><a target="_blank" rel="noopener noreferrer" href="https://github.com/doctrine/doctrine2/blob/master/composer.json">Doctrine</a></li>
<li><a target="_blank" rel="noopener noreferrer" href="https://github.com/aws/aws-sdk-php/blob/master/composer.json">AWS PHP SDK</a></li>
<li><a target="_blank" rel="noopener noreferrer" href="https://github.com/Seldaek/monolog/blob/master/composer.json">Monolog</a></li>
<li><a target="_blank" rel="noopener noreferrer" href="https://github.com/thephpleague/flysystem/blob/master/composer.json">Flysystem</a></li>
</ul>
Now lets see a simpler composer file:
<pre class="language-json"><code class="language-json">{
 &quot;name&quot; : &quot;acelaya/zf2-acmailer&quot;,
 &quot;description&quot; : &quot;Mail sending module for Zend Framework 2&quot;,
 &quot;type&quot; : &quot;library&quot;,
 &quot;authors&quot; : [
 {
 &quot;name&quot; : &quot;Alejandro Celaya Alastrué&quot;,
 &quot;email&quot; : &quot;alejandro@alejandrocelaya.com&quot;,
 &quot;homepage&quot; : &quot;http://www.alejandrocelaya.com&quot;,
 &quot;role&quot; : &quot;Developer&quot;
 }
 ],
 &quot;keywords&quot; : [
 &quot;mail&quot;,
 &quot;zend&quot;,
 &quot;php&quot;
 ],
 &quot;homepage&quot; : &quot;https://github.com/acelaya/ZF2-AcMailer&quot;,
 &quot;license&quot; : [
 &quot;BSD&quot;
 ],
 &quot;require&quot; : {
 &quot;php&quot; : &quot;&gt;=5.3.0&quot;,
 &quot;zendframework/zendframework&quot;: &quot;&gt;=2.2.2&quot;
 },
 &quot;require-dev&quot;: {
 &quot;phpunit/phpunit&quot;: &quot;&gt;=3.7&quot;,
 &quot;squizlabs/php_codesniffer&quot;: &quot;1.*&quot;,
 &quot;phploc/phploc&quot;: &quot;*&quot;,
 &quot;pdepend/pdepend&quot; : &quot;1.1.0&quot;,
 &quot;phpmd/phpmd&quot; : &quot;1.4.*&quot;,
 &quot;sebastian/phpcpd&quot;: &quot;*&quot;,
 &quot;theseer/phpdox&quot;: &quot;0.6.5&quot;
 },
 &quot;autoload&quot; : {
 &quot;psr-0&quot; : {
 &quot;AcMailer&quot; : &quot;src/&quot;
 },
 &quot;classmap&quot; : [
 &quot;./Module.php&quot;
 ]
 }
}
</code></pre>
This is the composer file of my Zend Framework 2 module <a target="_blank" rel="noopener noreferrer" href="https://github.com/acelaya/ZF2-AcMailer">AcMailer</a>. Let&#x27;s explain it.
The properties name, description, type, authors, keywords, homepage and license are just metadata to provide useful information to other users and ease finding the project in <a target="_blank" rel="noopener noreferrer" href="https://packagist.org/">packagist</a>.
The require property is the place where we define our dependencies and the version we want to install. We can define here the minimum required PHP version and even the php modules we need (like <code>php-pdo</code>, <code>php-intl</code> and such).
The require-dev property allows us to define other dependencies that won&#x27;t be necessery in a production environment, like testing or documentation tools.
Finally the autoload property is where we define how our own classes are loaded. It is very easy to define a <code>psr-0</code> or <code>psr-4</code> autoloading strategy, but we can even define a <code>classmap</code> with a list of paths to files.
<blockquote>
You don&#x27;t have to remember the <code>composer.json</code> schema. You can interactively create it by running <code>php composer.phar init</code>.
</blockquote>
<h3>Installing dependencies</h3>
Once this is defined we just need the composer binary file (usually in phar format), that can be found <a target="_blank" rel="noopener noreferrer" href="https://getcomposer.org/download/">here</a>, and run <code>php composer.phar install</code>.
This will create a <code>vendor</code> folder in the root of our project, download our dependencies there, the dependencies of our dependencies, and set-up an autoloader that will be able to load all our dependencies and our own classes as well.
After this it&#x27;s enough with a single <code>include</code> statement to <code>vendor/autoload.php</code> to be able to access any class.
If later in the project we need to update an existing dependency, add new dependencies or change the autoloading, we just need to update the information in the <code>composer.json</code> file and run <code>php composer.phar update</code> to update dependencies and autoloader.
<blockquote>
It is recommended to include the composer binary in the PATH to be able to run <code>composer</code> instead of <code>php composer.phar</code>.
</blockquote>
<blockquote>
If you are using a VCS like <a target="_blank" rel="noopener noreferrer" href="https://git-scm.com/">git</a> in your project you will probably want to ignore your <code>vendor</code> folder.
</blockquote>
<h3>Advanced usages</h3>
This should be enough to start working with composer, but it is a much more powerful tool with more features. It is not a bad idea to take a quick read to its <a target="_blank" rel="noopener noreferrer" href="https://getcomposer.org/doc/">documentation</a>, but let&#x27;s see the main advanced features.
<ul>
<li>Classmap autoloader: By running <code>composer dumpautoload --optimize</code> we can generate a much faster autoloader which defines a class =&gt; file map array with all the classes handled by composer. This is the more suitable autoloader for production environments.</li>
<li>Production dependencies: If we include de modifier <code>--no-dev</code> while installing or updating dependencies, it will ignore (or remove) the require-dev dependencies. For example <code>composer update --no-dev</code></li>
<li>Private repositories: If you want to install dependencies from repositories other than <a target="_blank" rel="noopener noreferrer" href="https://packagist.org/">packagist</a>, you can do it by using the repositories property. It supports many types of repositories, from VCS to PEAR repositories. Complete documentation <a target="_blank" rel="noopener noreferrer" href="https://getcomposer.org/doc/05-repositories.md">here</a>.</li>
<li>Global packages: If you want to install dependencies globally, just add the <code>global</code> keyword before the <code>install</code> or <code>update</code>. That will install the dependencies in the <code>~/.composer/vendor</code> directory instead of installing them in the local <code>vendor</code> directory. For example <code>composer global update</code>.</li>
</ul>
And that&#x27;s all you need to know to start working with composer.
Update 2015-04-25: I&#x27;ve written an article addressing advanced concepts that is a good continuation to this one. <a href="/2015/04/25/composer-advanced-concepts/">Composer advanced concepts</a>.

One of the common problems we have to confront when starting a new PHP project is how to handle the different dependencies we are going to have. One could think the easier solution is to download all the libraries we are going to need, put them in a lib directory and add them to the version control…

Dependency management and autoloading in php projects with composer

Last week I passed the <a target="_blank" rel="noopener noreferrer" href="http://www.zend.com/en/yellow-pages/ZEND021590">Zend Framework 2 Certified Architect</a> exam.
I will try to explain how did I prepare it.
<h3>Studying</h3>
In late March I recived an email that my exam was going to be on May the seventh, so I saw that I was going to have 4-6 weeks to prepare it. I could have started earlier, but maybe I&#x27;m a little lazy.
Since this was one of the first times the Zend Framework certification exam was based on version 2 (2.2), there was no documentation or examples in the internet, so I decided to just read the whole <a target="_blank" rel="noopener noreferrer" href="https://framework.zend.com/manual/2.2/en/user-guide/overview.html">documentation</a>. I was working with Zend Framework 2 in my job, so I could apply the theory in real projects.
My main problem was that I needed to compatibilize the study with my work, so I started studying about an hour a day. Some days I didn&#x27;t studied, but some weekends I could spend more time on it.
About two weeks after I started I saw I wasn&#x27;t going to be able to read all the documentation, so I started to read the components documentation in order of importance. This finally was proved to be a good system. I got no questions in my exam about <code>Zend\Barcode</code>, <code>Zend\Debug</code>, <code>Zend\Navigation</code> and such trivial components, but plenty of questions about <code>EventManager</code>, <code>ServiceManager</code>, <code>ModuleManager</code>, <code>Mvc</code> and <code>Forms</code>.
I neither had any questions of ZendService components.
<h3>Questions</h3>
The <code>ServiceManager</code> was present in many questions, as well as any kind of plugin manager (<code>ControllerManager</code>, <code>ViewHelperManager</code>…)
In those questions a piece of code was present where many services were registered in different ways, from a plain PHP array, from a <code>Zend\ServiceManager\Config</code> object or directly by calling methods from a <code>ServiceManager</code> instance.
Then the <code>ServiceManager</code> instance was used to retrive services, and you were supposed to know which ones were the same instance, what type of object do they return or even which services return the same instance.
The <code>EventManager</code> was also present in many forms. In some questions you were supposed to know the difference between the <code>EventManager</code> and the <code>SharedEventManager</code>, how to attach listeners or how to use <code>ListenerAggregates</code>.
The <code>MvcEvent</code> appeared in many questions too, where you need to know about the <code>EventManager</code> and the <code>MVC</code> layer.
A good bunch of questions was related with Forms, Validators and Filters.
In those questions you may be asked about the <code>FormElementManager</code>, get an element where some filters were attached and know which would be the final output from a specific input, or get a form with many elements with validators and know if an input was going to make the form valid or not.
These was the most important parts, but I also had questions about <code>Hydrators</code>, <code>Zend\Db</code>, the <code>ModuleManager</code> and how Modules are loaded, <code>Zend\View</code> with its events layer and the <code>PhpRenderer</code>, <code>Zend\I18n</code>, <code>Zend\Cache</code> or <code>Zend\Config</code>.
<h3>Conclusions</h3>
I made the exam with two other people I knew. The three of us thought that it wasn&#x27;t a very complicated exam, with no tricky questions (like <code>$foo = &quot;Bar&quot;; echo $fo;</code>), but you have to know the theory very well, how the framework works and how it is supposed to be used.
It is important to know about factories, dependency injection and good practices.
It would be good to work with Zend Framework 2 as long as you study, because that shows you how it behaves in real environments. Sometimes the Albums tutorial is not enough.
I hope this article helps to anyone preparing the exam. I wish you luck.

Last week I passed the Zend Framework 2 Certified Architect exam. I will try to explain how did I prepare it.

Studying

In late March I recived an email that my exam was going to be on May the seventh, so I saw that I was going to have 4-6 weeks to prepare it. I could have started earlier, but maybe…

Alejandro Celaya | Blog

Software development, agile methodologies and open source software.

category Archive — "tools"

— 2017 —

— 2016 —

— 2015 —

— 2014 —