Solving conflicts in composer.lock

We have all been there:

CONFLICT (content): Merge conflict in composer.lock
Automatic merge failed; fix conflicts and then commit the result.

Don’t panic, breathe, let’s walk through this.

Since I joined Usabilla, I have been working once more in a large team. With more people involved in the process of working with composer, adding, updating and removing libraries, merge conflicts are bound to happen. Ideally I would tell you to leave that process to only one person, but that is not realistic in teams over, well, one person. 😀

So it will happen, but how do we keep our sanity?

What I AVOID doing.

While reading other blog posts on this I found a practice that I consider not ideal. In most blogposts the first step towards fixing the conflict is usually:

$ git merge --ours composer.lock

What does this do? this will impose your version of the lock file, which seems fine, but has a catch. The catch here is that by ignoring the remote lock file you are discarding any updates done by the other developer.

“but Rafael, semantic version is great nothing will break cause my json file has ^1.2”, I agree, but as a policy I try to make sure our updates are conscious, just for good measure. Also I feel its good to respect the work of other people in your team and not discard those changes unless really required to.

What I DO do.

Its a simple switch around.

First I get the other developers changes:

$ git checkout origin/{base} -- composer.lock composer.json

Then you replay your changes on top of this, like:

$ composer require {new/package} --update-with-dependencies
$ composer update {existing/package}

You should know exactly what changes you made, so this should be no problem. Now you have kept all non-conflicting changes and updates from the other developer and applied your changes on top of it and the state of your dependencies is predictable and stable.

Oh, and you obviously run that great test suite after doing this, right?

Land ho! New challenge ahead.

A few months ago I posted about the situation at my former company and the uncertain future of our team. During these 3 months we explored many new opportunities and interviewed with many companies, from startups to consolidated giants, from financial market to education and user feedback, it was an amazing journey.

This journey is now over and I have found my new challenge, but more on that in a bit. Let me tell you a bit more about the journey.

Interviewing as a team

Few months ago Stripe posted an article about hiring teams and the benefits of that, I would like to also mention the benefits of interviewing as a team.

Our team went to many interviews as a full team, either together in big meetings or as individuals. The interesting aspect of this is that since we were a diverse group of people with many different roles, we analyzed companies from various angles, some of which I, in my interviewing experience, may never have thought to look into.

This made for a very fulfilling and unique experience, I got a lot more insights into companies than ever before. How does the business decide on features, how is UX looked after outside of screens, how do you make money and down to our usual questions of code/infrastructure.

If you ever get a chance to coordinate as a group and exchange notes on interviews, I do recommend doing so.

What’s next?

I’m happy to announce my next challenge, not just because I’m very excited to join the company and add to the great work they already do, but also because I was lucky enough to bring Rick Buitenman, my former manager, and Pauline Vos, my former “mentee”, along for the ride.

As of the first of July we will all be part of the Usabilla family!

Usabilla is a big player in the Dutch tech scene, a company built on the belief that continuous user feedback is the key to successful products. Their focus is on providing “Voice of Customer” solutions to help their more than 20K clients improve their user experience, conversions and boost customer satisfaction.

If you have ever used websites like ABN AMRO, KLM, HP, Philips, Vodafone and countless others, you may have noticed a feedback button, that is one of the many tools Usabilla provides.

I’ll be joining them as Lead Backend Engineer, where I’ll be able to focus on my 3 personal passions: coding/architecture, development work flow and growing/mentoring developers. Together we hope to take the platform to new levels of architecture, quality and performance.

Apart from coding, I’ll be working with the development team to take our development practices to even higher levels and make sure we are all learning and growing all the time. I love teaching and exposing people to more knowledge so this should feel right at home for me.

I’m also looking forward to learning from a entire new set of great developers as well as also getting a chance to expand into Golang which is in line with my own personal goals for this year.

I’m very excited to dive into the company and see how I can contribute to a great business and an amazing team.

Code Reviews – Not just a quality tool

I’m a big fan of Code Reviews, or Peer Reviews, within the work flow of a team. But many times when talking about them people refer to them mostly as a tool to avoid bugs, improve quality or the overlooking of details. While these things do surely come out of having a review process, I do not believe they are the real reason why they are a good thing for teams.

Code Reviews, to me, are about getting the team in sync. They are about making sure the team’s core values are spread throughout the team and observed. I’m not talking about Coding Standards, those can be enforced and checked with automated tools, I’m more concerned about architecture, code simplicity and conventions, things that are not measurable to some extent and more about making sure code reflects the core values you have.

In my previous team I made sure to on-board every developer by having them read up on Object Calisthenics, a practice that helps code awareness and promotes simplicity. This practice cannot be enforced by automated testing like coding standards, and this is where I believe Code Reviews have a role to play. While having your code reviewed and then reviewing other people’s code, you are exposed more and more to these aspects, and both of those parts are equally important.

During our on-boarding process the first thing developers are exposed to is reviews by the team lead. In our case we were expanding from a one man team, so the team lead held the core values, what we believed good code should look like. The first few weeks were about expressing this and showing, by example, to the team. This is where you can show what your thinking would be to solve these problems in alternate ways. For this step its very important that both sides keep an open mind, because at this point you are building the new core values, which the team will believe in, this means no one is right.

Now, only having your code reviewed and criticized is not a learning experience, the real learning happens when you start reviewing other people’s code. This is where you have to start internalizing the agreed values and projecting them on other people’s code. In our process I noticed that some developers were focused on large tasks and some on short tasks, the ones on longer tasks took more time to integrate into this, due to the long feedback loop. I recommend you try to make sure new developers have a balance of short/long tasks so they are not out of the feedback loop.

After a few months of our team expansion we noticed that the comments made on each other’s code were a lot more standardized, especially to me, the team lead. I noticed that by the time I came in to make a comment, another team member had already made it. This was a good sign that the core values were being spread.

One thing to note is that when a big change happens in the team, here we went from 2 devs to 5, it is important to re-build core values together, not simply impose them. We had many team meetings to discuss code together in order to evaluate if our values were indeed useful and made sense. The practice of “code burns” is great for this. Code Burns are nothing more then team code reviews where you can make comments and discuss as a team about each point.

If you are trying to implement a Code Review process or if one is being implemented in your team, be sure to keep this in mind, its not about having your code criticized by someone else, its about helping everyone be on the same page about what the team believes is good code.

Looking for someone to do this in your company? I’m currently looking for new challenges

Need a Lead? Here’s my story.

After 2,5 years working with Symbid, our paths must now diverge. After having contributed as a partner company and then joined to build the in-house development team that would later form the base of Symbid’s Product Development team, and finally push it over into a fintech company, sadly we part ways before achieving our long dreamed and much schemed plans.

As is the lifetime of disruptive startups, sometimes there’s a will and a way but not enough resources to make the plan into concrete products. This is, from a 10,000 foot view and as much as I can share, the outcome of our hard work at Symbid. We achieved amazing things and built an extraordinary team over these years but were cut short of rolling out most of the exciting developments.

So as of today, I’m available to help other companies build amazing teams and release cool new products. If your company is in need of a Technical Lead with experience in many markets and a passion for growing teams and producing quality software, please drop by my LinkedIn profile to see more details, or email me at jobs@doh.ms, and let’s chat about how I can help your company and your team achieve both.

But that is not all, our unique situation also allows me to suggest even more. Many companies are in the process of hiring and building new teams, we all know that this takes effort and time, to get a team in sync and working like a well oiled machine. If this is where your company is at, I can offer you a chance to talk to our entire team, a complete team from backend and frontend developers to UX Experts, Product Owners, and Product Managers. If you want to kickstart your in-house team, we can offer you a fully integrated team that is ready to start building your visions and get your plans off paper. Please also reach out to me at jobs@doh.ms if this sounds like an opportunity for you.

What did I do at Symbid?

At Symbid I operated as the Technical Lead Developer. From my early days as “developer #1” my work revolved around converting business value into software feature, determining the best architecture and technologies to achieve goals and integrating our many partner systems. As we expanded into a Product Development team I also took on the responsibility of managing the developers, defining work practices, creating tooling to support our flow and team, as well as mentoring and guiding developers to achieve more of their potential. Over the last year I also had the chance to design a microservices infrastructure that would join all pieces of Symbid’s “Funding Network” and partner software, as well as migrate all our code to PHP 7.

I’m a lover of innovative and clean code, bringing many new ideas to our code base with concepts of DDD, TDD and strategies like CQRS and Command Buses, as well as many other technology and concepts currently under research and evaluation. I’m also a mentor and teacher at heart, so I love being able to bring some of what I do at AmsterdamPHP into the workplace, mentoring and growing our developers, pushing them towards leveling up their code as well as exposing them to the concept of community which I’m quite fond of.

What am I looking for?

I love building products, especially long running products that have a vision that aims at making the world a better place. Sounds corny but I love being able to leave a mark in the future of society through my tool set of technology. I also love iterations, being able to refine software over longer periods, redesign, refactor and improve constantly, which is why I love long running products and not the quick turn around of the web agency style of work.

This is also where I feel my skills are of more use. Companies that are involved in the local community and giving back to OSS get a big bag of bonus points. I do enjoy running UGs and spreading technology at various conferences, as a speaker or attendee, so I do expect my company to see the value in that and support my efforts. Give me that much and I’ll spread the love to every person I see and make sure I’m bringing back to the company as much ideas and knowledge as I can to take us even further.

I love leading teams technically and building/planning systems to solve the problems your company is aiming at. If possible I prefer focusing on the tech side of things and not so much on the HR part of that, I’ll mentor and help developers plan their careers, but I’m not so good at managing their vacation days.

If any of this, sounds like what your company needs please tell me about your vision and your needs, I would love to be a piece in that puzzle.

Above all of this, the team we have built at Symbid is close to my heart and we are all out there looking for a new challenge, any chance I have to keep them together will be the best outcome I can imagine.

Look me up on Linkedin: https://nl.linkedin.com/in/rafaeldohms
Email me at: jobs@doh.ms

20 Years of PHP, and how I got on this train

PHP, the most loved and hated language on the internet turns 20 today, 20 years ago Rasmus released Personal HomePages to the public, what happened next will blow you away™.

Ben Ramsey called on us to blog about our history, so I decided to take a few minutes and do just that.

Back in the 90’s in the midst of the Counter Strike and IRC wave of the Internet I started getting interested in HTML and CSS on top of my current adventures in IRC scripting (yes, I distributed one called Doomsday Script with some l337 chars.). I even stumbled onto Cold Fusion as my first run into something that could “make the web remember stuff”. By this time I was heading out of school and into College, somewhere along the end of the 90’s.

It was early 2000 when I had enrolled into Computer Enginneering and got word from a friend that the company she worked at, a small publicity agency, was looking for some developers to do HTML and Flash, which by then I was good enough at, having developed multiple websites for things like my Counter Strike Clan and my IRC channels I was OP of (I know… but hey, it was the cool thing back then).

I ended up getting the job and one day the owner of the company, Gaston, showed me how i could use this PHP thing to query a database and show current birthdays of the month on an HTML page. I was blown away in the 10 minutes it took him to show me the parts of this thing working. Then he turned to me and issued what was to become the start of my PHP adventure and what, looking back, may have been the most important moment in my early professional career. “Now go ahead and work on creating our intranet”.

What? A whole “intranet”? All with these html files with <? ?> in them? (yes, short tags, and spaghetti… good days.) Sure, why not? I picked PHP up as fast as the content available on the internet back then could push me forward. I still remember this one very crazy guy we hired that kept talking about this “Object Oriented” stuff that sounded like real voodoo. Jobs came and went, me and a few friends developed a site called Cerrado Mix which was later bought by a local newspaper, it was a party coverage site and it got me into all the cool parties, I was totally cool back then.

There I was, the only PHP developer in Brasil, no one else did this. Or at least that is what it felt like, until in 2006 I ran into this new thing, a “PHP Conference Brasil”, a gathering of people who worked with PHP? What? I’m not alone?

This event changed my career again, showed me not only the local community but the international, I even got to meet this Derick Rethans guy and saw a presentation by a local farm boy turned PHP dev by the name of Guilherme Blanco. But most important of all, this showed me there was a PHP community.

A few months after that, PHPDF was born, my first user group, as a result of meeting Adler Medrado and Pablo Sanchez at and after the conference. The cool thing about this conference is that I vowed to be back in 2007, as a speaker. So in 2007 PHPDF had its first “PHPDF Roadshow”, at which I did my very first talk (Yes, I totally violated Cal’s Bat Shit Crazy Rule and spoke and organized a conference). In 2007 I came back as a speaker to the conference. Not only that I spoke there every year since, until I moved away from Brazil. And I’m now truly honored to be going back there in its 10 year anniversary as a keynote speaker.

Equipe - PHPDF Roadshow

What a Ride it has been form there. I moved to SP in 2008, started PHPSP, had my first international conference experience at ZendCon 2008 (trivia, this is where the PHP Ninja Turtles first met). That is actually when i got my first ElePHPant, from Mr. Community Cal Evans. Then I got to go to php[tek] in 2009 and finally broke the international speaker circuit in 2011 and finally move to the Netherlands in 2011, now calling AmsterdamPHP my home.

Thank you Rasmus for kicking this off, thank you Gaston for that first lesson, and thank you community for pushing me along all the steps that came since, I could not possible name everyone who made a difference in this long road, so let’s just go for THE PHP COMMUNITY.