80 lines
5.3 KiB
YAML
80 lines
5.3 KiB
YAML
uuid:
|
|
- value: c7dd2a5b-3a7c-4ab0-8dc2-81f2d2cb8af1
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:57+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: "Why I don't only use Drupal"
|
|
created:
|
|
- value: '2022-08-30T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:57+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2022/08/30/why-dont-only-use-drupal
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>Yesterday, <a href="/daily/2022/08/29/why-like-drupal">I shared some of the reasons</a> why I like Drupal and why I use it for the majority of my projects. But, as I said, I don't use it exclusively and for some projects I used various different tools.</p>
|
|
|
|
<p>Essentially, I always try to recommend and use the best tool for the job.</p>
|
|
|
|
<p>I previously interviewed for a job and was asked to complete a coding test. The role was mostly Drupal-focussed, but as the test asked for a command-line application, I completed it using Symfony and Symfony Console, and was able to discuss why I'd made that decision. In my opinion, it was the best choice based on the requirements.</p>
|
|
|
|
<p>This is the same approach that I use when making recommendations for a new project.</p>
|
|
|
|
<p>I've delivered projects using other tools like the Symfony framework or a static site generator, as long as it fitted the requirements.</p>
|
|
|
|
<p>If there's a SaaS solution that can be used instead, or an off-the-shelf tool that can be integrated instead of writing a custom solution, then that should be evaluated.</p>
|
|
|
|
<p>There may be other constraints like budgets or deadlines to consider - maybe something can be delivered faster or cheaper using a particular technology, even if it's not the final solution.</p>
|
|
|
|
<p>There are situations though where a tool may be the best choice even though it's not the ideal fit based purely on the technical requirements. Maybe the client is already familiar with publishing content in Drupal, or an in-house development team is used to working with a certain tool or language. In that case, those things should be considered too.</p>
|
|
|
|
<p>Also, for me, having a chance to evaluate other technologies and explore what's happening outside of the Drupal ecosystem is a good opportunity. A lot of what I've learned about automated testing, for example, is from the wider PHP and JavaScript communities, as well as tools like <a href="/presentations/taking-flight-with-tailwind-css">Tailwind CSS</a> and <a href="//presentations/using-illuminate-collections-outside-laravel">Illuminate Collections</a> that I've been able to bring back into my other Drupal projects.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>Yesterday, <a href="http://default/daily/2022/08/29/why-like-drupal">I shared some of the reasons</a> why I like Drupal and why I use it for the majority of my projects. But, as I said, I don't use it exclusively and for some projects I used various different tools.</p>
|
|
|
|
<p>Essentially, I always try to recommend and use the best tool for the job.</p>
|
|
|
|
<p>I previously interviewed for a job and was asked to complete a coding test. The role was mostly Drupal-focussed, but as the test asked for a command-line application, I completed it using Symfony and Symfony Console, and was able to discuss why I'd made that decision. In my opinion, it was the best choice based on the requirements.</p>
|
|
|
|
<p>This is the same approach that I use when making recommendations for a new project.</p>
|
|
|
|
<p>I've delivered projects using other tools like the Symfony framework or a static site generator, as long as it fitted the requirements.</p>
|
|
|
|
<p>If there's a SaaS solution that can be used instead, or an off-the-shelf tool that can be integrated instead of writing a custom solution, then that should be evaluated.</p>
|
|
|
|
<p>There may be other constraints like budgets or deadlines to consider - maybe something can be delivered faster or cheaper using a particular technology, even if it's not the final solution.</p>
|
|
|
|
<p>There are situations though where a tool may be the best choice even though it's not the ideal fit based purely on the technical requirements. Maybe the client is already familiar with publishing content in Drupal, or an in-house development team is used to working with a certain tool or language. In that case, those things should be considered too.</p>
|
|
|
|
<p>Also, for me, having a chance to evaluate other technologies and explore what's happening outside of the Drupal ecosystem is a good opportunity. A lot of what I've learned about automated testing, for example, is from the wider PHP and JavaScript communities, as well as tools like <a href="http://default/presentations/taking-flight-with-tailwind-css">Tailwind CSS</a> and <a href="http://default/presentations/using-illuminate-collections-outside-laravel">Illuminate Collections</a> that I've been able to bring back into my other Drupal projects.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|