Jekyll2017-11-01T13:15:57+00:00http://biruwon.github.io/Biruwon’s BlogJust another blogHow I see remote working2017-10-31T00:00:00+00:002017-10-31T00:00:00+00:00http://biruwon.github.io/2017/10/31/remote<p>
I'm currently looking for a remote job and from time to time I found an interesting company/project which I'm not sure
if they are open to remote or not. In order to explain myself how my vision of remote working is or how it would be
perfect for me, I'll write this as sometimes I struggle myself trying to explain it in a few lines in an email or cover
letter. I hope this would help me with that.
</p>
<p>
There are tons of resources about the benefits of remote working so this post won't be about that, but if you haven't
done it yet, I would recommend you to read this book: <a href="https://37signals.com/remote" target="_blank">Remote</a>
</p>
<h2 class="section-heading">How much time I want to work from home?</h2>
<p>
I wrote on these emails something like "I don't want 100% but a 70% remote time". So what do I want to do in the remaining 30%?
This time includes how we meet each other. If I'm going to join a new team, I would like to meet them and to know how they
think or their personality which I think is important for later so this person isn't just a digital face in your video conference
tool. Being there, if they own an office, will help me to understand the product and codebase, their vision and to clarify
expectations. This can last a month or even more if necessary.
</p>
<p>
It's important to me to keep in contact with the rest of your team or the people you talk daily so being all together one week every
3 months sounds good to me. Some companies organize these all together trips which help with that too. Maybe there is an important
release that week or something like that. A hackathon is perfect too. For me, it's important that you have someone, let's say your
team lead, that once per month organize a video call with you just to see how things are going.
</p>
<h2 class="section-heading">How do you treat a remote developer?</h2>
<p>
Don't treat a remote developer as a lone wolf, who is in charge of the projects nobody wants. If your company is going to open
a position within a team, then the whole team should work as if they were all remoters even if they work at the office. You
can even start allowing them to have some days per week working from home, I'm pretty sure they will appreciate it. But more
important is that every decision/discussion is done via video call and your remote worker isn't just someone who hears the
last bits of what was decided.
</p>
<p>
Some companies, to not say most of them, just want remote workers to save money. That's not the way. If you just want cheap
developers, you'll have the quality that you pay for. I'm not saying that you should pay the Silicon Valley salary to someone
in Spain, some companies offer a competitive salary based in your location and cost of living.
</p>
<p>
Now that you have some remote workers, spend that money on them on having a good and comfortable equipment at home and on
having some in person meetings from time to time. Spending that money on beers, toys at the office or team events for people
who usually see each other everyday doesn't worth as much as you think.
</p>
<p>
If your company is thinking about going remote, one way to start is to allow it to a developer that wants to stay at your company
but for any reason can't live where you have the office. Losing years of knowledge, someone who already knows the team and the
money you will spend on hiring/training a newcomer is a terrible mistake.
</p>Antonio JesúsI'm currently looking for a remote job and from time to time I found an interesting company/project which I'm not sure if they are open to remote or not. In order to explain myself how my vision of remote working is or how it would be perfect for me, I'll write this as sometimes I struggle myself trying to explain it in a few lines in an email or cover letter. I hope this would help me with that.Some common questions when you start writing tests2016-11-01T00:00:00+00:002016-11-01T00:00:00+00:00http://biruwon.github.io/2016/11/01/testing<p>On this post I'll try to answer some of the questions that I asked myself when writing tests. There is plenty of
information on the internet about what an unit test is, some katas to start with it, etc but there is a big difference
between the typical example and production code. You'll also find what an integration test is, or a mock, or what TDD is
as there are enough information out there</p>
<h2 class="section-heading">To mock or not to mock</h2>
<p>So once you're into testing and discover mocks you use them for every class you use as a dependency. As we have been
told, unit tests can't fail because some external dependency, that this is an integration. In my humble opinion, this is
an error. Mocking should be only used when it's really necessary, when the effort for using the dependency is huge or
will make your test suite slow. I'd include in there external libraries or their wrappers, database/repositories, sending
emails, writing to a file, etc.</p>
<h4>What are the disadvantages of mocks?</h4>
<p>The main problem is that your test is coupled to the implementation. When you have that feeling that you're writing
the same lines of codes than the real implementation, that's coupling. You'll have some calls to your mock with what it's
exactly receiving, with how many arguments, what the return value is. It can generate a monster of mocking objects</p>
<h4>What's the solution then?</h4>
<p>Apply TDD and avoid creating mocks for you own classes unless than necessary. I have found myself doing this: creating
some class, then writing the tests for it, and finally refactoring it to extract the logic in some other class. My tests
are already covering both classes, but I'm mocking now the extracted class, so I need to create again some other test for
the extracted class as otherwise no test will execute it.</p>
<p>Of course, the disadvantage of not mocking is the setup of the objects can be really complex. You have two
dependencies which at the same time have more and then it grows exponentially. This is for me a code smell and remember
that you're already mocking the database, your redis queue, etc.</p>
<p>
Useful articles:
<a href="https://8thlight.com/blog/uncle-bob/2014/05/10/WhenToMock.html" target="_blank">When to mock</a>
<a href="http://martinfowler.com/articles/mocksArentStubs.html" target="_blank">Mocks aren't stubs</a>
</p>
<h2 class="section-heading">Unit vs Integration tests</h2>
<p><a href="#">
<img src="/img/no_integration_test.jpg" alt="No Integration test" />
</a></p>
<p>Imagine the case of the image, some isolated unit tests but the application breaking. This is were integration tests
are useful. Some cases are, an external library like a queue system where you can test if a job is inserted on redis.
Generation of payments getting/inserting data into the database, using some fixtures in the setUp() and deleting the
rows inserted in the tearDown(). External API calls using a fake server is another example. But don't use them for
increasing the coverage of your code.</p>
<h4>Functional tests</h4>
<p><img src="https://2.bp.blogspot.com/-YTzv_O4TnkA/VTgexlumP1I/AAAAAAAAAJ8/57-rnwyvP6g/s1600/image02.png" alt="Test pyramid" /></p>
<p>The image from the article <a href="https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html" target="_blank">No more end to end tests</a> describes how I think they should be distributed. It's mentioned a
70/20/10 separation: 70% unit tests, 20% integration tests, and 10% end-to-end tests. Functional tests or whatever they
are called nowadays, are an important part for testing the UI of the application but the cost of maintaining and writing
them is too high. As a developer I think you shouldn't write them. If you're lucky enough having a QA member in your team
helping, it should be part of his job. Functional tests should cover the main functionality and some bugs caused in the
past, that's all.</p>
<h2 class="section-heading">How much coverage?</h2>
<p>For me, the aim is 100% and this is where you should point. If you set a minimum limit, let say, 80%, does this mean
that you should only cover 4 of your 5 methods on your class? Specially if you're doing TDD you should have a highest
number.</p>
<blockquote>
<p>If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I
would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy,
but not thinking about what they are doing.</p>
-- Martin Fowler
</blockquote>
<p>I usually exclude from the coverage:</p>
<p>Entities, DTOs, Queries and Repositories, specific classes from the framework and the glue between the client and the
backend side like Controllers.</p>
<h2 class="section-heading">Other important points</h2>
<p></p>
<h4>Law of Demeter</h4>
<p>This is how the <a href="https://en.wikipedia.org/wiki/Law_of_Demeter" target="_blank">Law of Demeter</a> is
summarized:</p>
<blockquote>
- You can play with yourself.
- You can play with your own toys (but you can't take them apart),
- You can play with toys that were given to you.
- And you can play with toys you've made yourself.
</blockquote>
<p>Basically it says you need to avoid method chains, like using a getter from an injected object which returns another
object with another getter. Let say User->getCountry()->getCity()->getName(), this is usually solved having a city
property on the User object.</p>
<h4>How to test APIs?</h4>
<p>As you want to know if the interaction with the API is working properly, but you can't use a production environment for
that, you can build your own API mock server. You can simulate the API behaviour writing some blueprints using for
example <a href="https://github.com/apiaryio" target="_blank">Apiary</a>. With that, you'll have a way to test your API
integrations or prototype a new one.</p>
<p>One important thing, if you're using internals APIs and not propietary APIs like Twitter, is that the integration
tests you're writing can be executed by the other teams of your company building these APis on their testsuites. This is
a faster way to know about breaking changes or possible bugs.</p>
<h4>What time is it?</h4>
<p>When dealing with tests using some time related functions, you can be on trouble if you can't freeze the time. For
that, exists multiple libraries or built-in classes that can help you depending of the language/framework you use.
For example, on Symfony, I'm using <a href="https://github.com/symfony/phpunit-bridge/blob/master/ClockMock.php" target="_blank">ClockMock</a>.</p>
<p>This help you avoiding a test failing on a process that can be only executed the first day of the month. As a curious
example, we were having some tests failing in our test suite depending of the timezone they were executed. Try to change
your timezone to something like UTC+5 and execute it to be sure.</p>Antonio JesúsOn this post I'll try to answer some of the questions that I asked myself when writing tests. There is plenty of information on the internet about what an unit test is, some katas to start with it, etc but there is a big difference between the typical example and production code. You'll also find what an integration test is, or a mock, or what TDD is as there are enough information out there