In Chicago? Don't Have a DrupalCon Ticket Yet? But You're Reading This on a Weekend?
Update: Ticket taken. But if you want to come, please read below the fold.
See Permissions' Machine Names (and much more) with Xray Module for Drupal 7
With Drupal 7's third and final release candidate unleashed on us all this morning, it is long past time to help the #D7CX movement with a seasonal offering of our own.
+1 to Ending comment-to-subscribe on Drupal.org
As starving authors we at Agaric don't have a lot of cash to burn right now, but we've thrown $25 in the project to make it possible to subscribe to drupal.org issues without commenting. (On top of whatever we donated when this request for funding went out a year and a half ago).
Drupal Work Collectives
Agaric proposes the creation of a new kind of workplace, essentially a Drupal commune, but really more like an open source free software idea & brainstorming commune, kind of along the same lines as an artist's or writer's colony.
We're Writing a Book!
Yes it's true, for the past few months we've been hard at work with a lot of other co-authors on The Definitive Guide to Drupal 7.
Agaric Backs Community Coworking Center in NYC
Thinking it would be a great place to work a day or two while in New York City for clients or DrupalCamps, Agaric dropped a few dollars in the Kickstarter fund for New Work City: Community Coworking Center for Independents in NY.
Agaric Sponsors Modulecraft for the Building of Drupal Shared business, Development, and Training Tools
For community shared business, development, and training tools, Agaric throws a little sponsorship at modulecraft.
Agaric Provides Very Minor Assist in Readying Insert Module for Drupal 7
Benjamin Melançon of Agaric helped with a patch for the Drupal 7 version of Insert module.
Agaric?
What the word agaric means and why Agaric took it for our cooperative's name.
Designed to Life
Functionality designed to your life is the Agaric Design signature. Utilizing open source, free software from around the world, Agaric Design websites are impeccably crafted with a modern, sophisticated and understated spirit.
The Story on Agaric
I've always had a passion for good design and healthy coding, even back in the days of owning a web site cart in downtown Natick. Back then, my business partner and I made all natural HTML roll-up web sites and, as an incentive for customers to wait in line, we baked Drupal into different flavored designs.
At Agaric, we perform a lot of Drupal upgrades. These very often involve transitioning away from older versions of PHP. Even when your hosting service provides multiple versions of PHP, you can still run into issues activating the appropriate one for each site: whether that's within the web server, at the command line, or via Drush (or other tools). In this blog post, we'll be providing remedies for all of these cases. Most content applies to any PHP application.
I’ve been working on open source projects for a long time and contributing to Drupal for 6 years now.
And I want to share my experience and the things that helped me contribute to Drupal.
Where you can help:
I think one of the first problems I had to face when I started contributing was picking up an issue from the Drupal issue queue and to start working on it. When I started, all the issues seemed very hard or complex (and some are), fortunately there are a list of issues for people who want to start contributing to Drupal, these issues have the Novice tag. The idea of these issues is for someone to feel the experience of working on an issue.
What you need to know
Some of the things to learn while working on novice issues are:
- Use git
- Learn to create a patch using git
- When a ticket is old and the patch doesn’t apply anymore it is necessary to reroll the patch, that is a very common thing on the issue queue and is just updating the patch so it can be applied to the project again.
- Every time a new patch is uploaded, it is necessary to provide an interdiff. An interdiff is just a file showing what changed from the previous patch to the new one. This is a very important thing as it helps a lot for the reviewer to know what has changed. This is especially important if it is a big patch.
- Use the Drupal Coding Standards, and the easiest way to follow along is by using PHPCS and later integrate it with your IDE
- The changes must pass the "Core Gates" which essentially are checklists of things that every contribution must have in order to keep the quality of the code up to standards.
Don’t work on novice issues forever
While working on novice issues is a good way to start, it is necessary to jump to issues not marked as novice as soon as we feel comfortable with the things listed above. The non-novice issues are where we can really learn how Drupal works.
A few ways to start working on non-novice issues are:
- reviewing patches from other users, so you can learn how a change is done and start checking how the core works, reading code from others is a great way to improve your abilities as developer and at the same time help to keep moving the issues along, so they can be fixed.
- Another way to contribute is by writing tests, every patch with a fix must have a test to avoid regressions. While writing tests sounds like a hard thing to do, Drupal 8 help us a lot with this. There is a whole page written about the topic. Also the Examples module does not just provide examples of how to do things with Drupal but also how to test them, so keep that module at hand as it is a great resource. Drupal 8 has thousands of tests already, so for sure there is at least one which is very similar to what you need to do.
- Pick an issue related to the component you want to know more about, Drupal 8 has a lot of components, and if you want to know how a specific part works just pick one of its bugs and work on it. Don’t worry if the bug seems easy to fix in the issue but in the code it is not, that is normal. Before you start fixing the bug, it is necessary to understand what the problem is and part of that is learning how that specific part of the component works. So when finally a patch can be provided for that issue you will now know how that component works. This is (for me) the best way to learn. While you help Drupal to be more stable, at the same time you gain understanding on a very deep level of how Drupal works.
- Be your own critic while you are working on client work, if there is something which doesn’t seem right, don’t hesitate to look at an issue with that problem before you do a workaround, maybe someone has already written a patch and it might just need a reroll, a review or a test. Sometimes you can help while working on a project. At Agaric we recently found a bug while working on a project and it was a 6 year old issue that just needed a review and an extra test. Now it is fixed, for us and for everyone.
Final comments
When feeling frustrated while working on an issue, remember the Thomas Edison quote "Genius is one percent inspiration, ninety-nine percent perspiration", while we keep trying and keep working and asking questions and trying new things, just don’t give up, eventually we will make it happen. When someone starts contributing, it is normal to feel like they are not good enough. Just keep trying!
Remember, contributing for most of the people is an unpaid labor, don’t feel disappointed if there is an issue where you spent a good amount of time and no one reviews it, there are issues that have been around for years which aren’t committed, but even if they aren’t, the next developer with your same problem will find your patch and use it. So even if your code is not part of a module/core it still helps.
Going to conferences and meeting Drupalistas is a good way to keep you motivated and to learn new things. It is fun to meet in person the Drupal.org users who helped you in the issue queue.
Another thing that might help to keep you motivated is to see your name at DrupalCores.com. There you can see a list of users and mentions: for every new mention/contribution your nick will gain a few place in that rank.
According to the documentation:
- @variable: When the placeholder replacement value is:
- A string, the replaced value in the returned string will be sanitized using \Drupal\Component\Utility\Html::escape().
- A MarkupInterface object, the replaced value in the returned string will not be sanitized.
- A MarkupInterface object cast to a string, the replaced value in the returned string be forcibly sanitized using\Drupal\Component\Utility\Html::escape().
Using the @ as the first character escapes the variable if it is a string but if we pass a MarkupInterface object it is not going to be sanitized, so we just need to return an object of this type.
And Drupal 8 has a class that implements MarkupInterface called: Markup, so the code above for Drupal 8 will look like this:
public function content() {
$markup = new Markup();
$links[] = Link::fromTextAndUrl('Google', Url::fromUri('http://www.google.com'))->toString();
$links[] = Link::fromTextAndUrl('Yahoo', Url::fromUri('http://www.yahoo.com'))->toString();
$types = $markup->create(implode(', ', $links));
return [ '#markup' => t('Links %links', ['%links' =>$types]), ];
}
And that's it, our string will display the links.
If you want to see a real scenario where this is helpful, check this Comment Notify code For Drupal 7 and this patch for the D8 version.
Over 8 years have passed since there was a DrupalCamp in tropical Nicaragua. With the help of a diverse group of volunteers, sponsors, and university faculty staff, we held our second one. DrupalCamp Lagos y Volcanes ("Lakes & Volcanoes") was a great success with over 100 people attending in 2 days. It was a big undertaking so we followed giants' footsteps to prepare for our event. Lots of the ideas were taken from some of the organizers' experience while attending Drupal events. Others came from local free software communities who have organized events before us. Let me share what we did, how we did it, and what the results were.
Agaric organiza una reunión semanal en línea conocida como "Show and Tell". Los participantes comparten consejos y trucos que hemos aprendido y plantean preguntas a otros desarrolladores sobre tareas o proyectos en los que estamos trabajando. Cada semana pedimos a la gente que nos envíe un poco de información sobre lo que les gustaría presentar. Esto no es un requisito previo, sólo una sugerencia. Tener un aviso previo de las presentaciones nos permite correr la voz a otros que puedan estar interesados, pero usted puede simplemente presentarse, y lo más probable es que haya tiempo para presentar durante 5-10 minutos. Puede inscribirse en la lista de correo de "Show and Tell" y será notificado de los próximos eventos.
Recientemente hemos abierto el chat de "Show and Tell" para vincularnos con otras cooperativas que hacen trabajos de desarrollo web. Agaric fue contactada por miembros de Fiqus.coop en Argentina, ya que ellos ya habían comenzado con una iniciativa para conocer a otros desarrolladores de cooperativas y asi, compartir valores y metas. Nadie había enviado un aviso de presentación, así que cambiamos el tema del chat para que fuera más un encuentro y un saludo para conocernos mejor con el objetivo de poder compartir nuestro trabajo en los proyectos. El valor de la reunión se hizo evidente de inmediato cuando nos adentramos en la conversación con algunos miembros de Fiqus.
A continuación, invitamos a más desarrolladores a participar en la discusión y se abrieron las puertas para compartir más profundamente y conectar. Esta semana nuestra reunión fue exagerada! Nicolás Dimarco nos guió a través de una corta presentación de diapositivas que reveló un proceso y flujo de trabajo federado para compartir el desarrollo con los miembros de múltiples cooperativas. El plan es tan simple que todos lo entendieron inmediatamente. La conversación que siguió fue convincente, las preguntas fueron indicativas de dónde necesitamos educar a los demás sobre los principios cooperativos vs. las tácticas corporativas. Necesitamos más discusión sobre la confianza y la amistad. Hay tantos desarrolladores en trabajos corporativos que me han preguntado cómo funciona una cooperativa de desarrollo web y cómo funciona un proyecto sin un gerente. Primero, me gusta explicar que los proyectos tienen gerentes, pero ellos están manejando el trabajo, no a la gente. Tomarse el tiempo para conocer las habilidades y pasiones de cada uno sobre la programación es una parte esencial para poder trabajar juntos en una Federación. Fiqus.coop ha hecho que sea sencillo para todos ver el camino para compartir el trabajo en los proyectos!
Aquí está el enlace a la grabación de video del chat donde Nicolás Dimarco de Fiqus.coop presenta la fórmula de trabajo federado entre cooperativas. Aquí hay un enlace a las notas de la reunión del 20/3/2019 y algunas reuniones pasadas de Show and Tell.
Más información sobre el Show and Tell.
Algunas tiendas de Drupal ya trabajan juntas en proyectos y podemos ayudar a que crezcan compartiendo nuestras experiencias. Nos encantaría saber cómo trabajan y los procesos que han descubierto que hacen que compartir el trabajo en los proyectos sea un éxito!
