Archives de
Author: Dayo

Développeur depuis 2008, j’écris pour me souvenir et explorer de nouveau horizons.
Extensions Gnome/Ubuntu

Extensions Gnome/Ubuntu

Suite a mon passage sur Ubuntu voici les extensions Gnome que j’utilise:

Media Control

Afin de pouvoir rapidement controller la lecture audio de Spotify ou d’un site web.

https://extensions.gnome.org/extension/4470/media-controls/

Media Control avec Spotify

gTile

Avec un grand écran, la chose qui me manquait le plus de Windows 11 c’était la possibilité de facilement agencé les fenêtres des logiciels. Grace a gTile je n’ai plus ce problème.

https://extensions.gnome.org/extension/28/gtile/

J’utilise les raccourci suivant:

RaccourciDescription
Super+Alt+KP_1Quart inférieur gauche de l’écran
Super+Alt+KP_2Moitié inférieure
Super+Alt+KP_3Quart inférieur droit
Super+Alt+KP_4Centre gauche
Super+Alt+KP_5Centre
Super+Alt+KP_6Centre droit
Super+Alt+KP_7Quart supérieur gauche
Super+Alt+KP_8Moitié supérieure
Super+Alt+KP_9Quart supérieur droit
Ceci est rapide a obtenir

Clean Code

Clean Code

Notes de lectures

Clean Code, le titre d’un livre écrit par Robert C. Martin, uncle Bob, est une véritable Bible pour certain. Voici quelques éléments qui j’ai retenus.

Nommage

  • Utiliser des noms clair, sans ambiguïté
  • Utiliser le même pour pour un concept unique

Fonctions

  • Garder les fonctions courtes, 20 lignes
  • Peu d’imbrications
  • Une fonction ne fait qu’une chose
  • Éviter d’avoir trop d’arguments

Commentaires

Mieux vaut changer son code pour le rendre claire que d’avoir un commentaire. Le code peux changer, le commentaire non.

<?php

// vérifie si l’employé peux avoir la retraite a taux plein
if($emplyee->flags && $employee->age > 65)

Ou plutot

<?php

if(($employee->peutAvoirLaRetraiteATauxPlein())

Formatage

Le plus important est d’avoir un formatage commun afin que le code sois visuellement cohérent et d’évité d’avoir des changement dans la gestions des sources.

Objets

Erreur

Utiliser des exceptions plutôt que des code de retour pour simplifier la gestion des erreurs. Ne pas utiliser null pour les même raisons.

Classe

Comme les fonctions:

  • Garder les fonctions courtes, 100 lignes
  • Peu d’imbrications
  • Une classe ne fait qu’une chose

Emergent Design

Afin de produire du code propre nous pouvons suivre ces 4 règles:

  • Passer tout les test
  • Refactoriser, Dedupliquer
  • Être expressive
  • Ne pas avoir trop de classes et de fonctions
Oh My ZSH dans Windows Terminal

Oh My ZSH dans Windows Terminal

Première étape, installer Windows Terminal. Il suffit de l’installer depuis le Microsoft Store: https://aka.ms/terminal

Windows Terminal permet d’avoir différent shell dans des onglets.

Comme cet article parle de Oh My ZSH, il nous faut Linux, nous installons Ubuntu via le Microsoft Store:

Utilisez Windows Terminal pour ouvrir un shell sur votre Ubuntu:

Il est temps d’installer ZSH avec : sudo apt-get install zsh.

Ensuite direction le dépot Git de Oh My ZSH pour les instructions d’installation. J’ai utilisé sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" et fait de zsh mon shell par défaut.

J’ai ensuite changé mon thème par « agnoster » en utilisant vim ~/.zshrc.

Afin de prendre en compte le changement de thème nous rechargons le fichier avec source ~/.zshrc. Et voilà le résultat.

Bon, il nous manque encore la font que nous installons avec : sudo apt-get install fonts-powerline.

Il n’y a pas de changement car nous devons spécifier a Windows Terminal une font compatible, ce sera Cascadia Code PL. Une fois téléchargé a partir de la page des release, installez de préférence le fichier CascadiaCodePL.ttf.

Pour configurer Windows Terminal, cliquez sur le chevrons a droite puis sur « Paramètres ».

Ouvez le fichier avec le Bloc Notes, puis rajouter la ligne "fontFace": "Cascadia Code PL", comme sur l’image ci-dessous :

Une fois sauvegardé vous devriez alors voir :

Pour plus d’information sur Oh My ZSH :

Et voila !

Utiliser les GitHub Actions pour PHP

Utiliser les GitHub Actions pour PHP

GitHub a publié les GitHub actions afin de mettre en place du CI/CD directement sur leur plateforme.

Nous allons les utiliser pour lancer les tests et PHPStan.

Afin de pourvoir tester en local et pas seulement sir GitHub nous utiliserons ACT. Une fois installé, utiliser les commandes :

  • act.exe -l afin de lister vos actions
  • act.exe afin d’exécuter vos actions
La liste des actions
L’exécution d’une action

Pour avoir une actions il faut créer un fichier sous .github/workflows/. Afin de ne pas avoir à tout faire nous allons utiliser l’action setup-php-action.

Voici le fichier que nous allons utiliser.

name: "CI"

# Triggers the workflow on push or pull request events
on: [push, pull_request]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
            php-version: '7.4'
            tools: phpstan, composer

      - name: Validate composer.json and composer.lock
        run: composer validate

      - name: Get composer cache directory
        id: composercache
        run: echo "::set-output name=dir::$(composer config cache-files-dir)"

      - name: Cache dependencies
        uses: actions/cache@v2
        with:
          path: ${{ steps.composercache.outputs.dir }}
          key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
          restore-keys: ${{ runner.os }}-composer-

      - name: Install dependencies
        run: composer install --prefer-dist

      - name: Setup problem matchers for PHPUnit
        run: echo "::add-matcher::${{ runner.tool_cache }}/phpunit.json"

      - name: Run PHPStan
        run: phpstan analyse src --level max

      - name: "Run tests"
        env:
          sfdc_username: ${{ secrets.SFDC_USERNAME }}
          sfdc_password: ${{ secrets.SFDC_PASSWORD }}
          sfdc_client_secret: ${{ secrets.SFDC_CLIENT_SECRET }}
          sfdc_client_id: ${{ secrets.SFDC_CLIENT_ID }}
        run: |
          cp .env.example .env
          vendor/bin/phpunit --coverage-clover=coverage.xml
  • A la ligne 4 nous demandons a lancer l’action sur les push et les pull request.
  • Ligne 11 et 12 nous fessons un checkout de notre code.
  • Ligne 14 et 14 nous utilisons l’action « Setup PHP » avec PHP 7.4 et composer, ligne 18 et 19.
  • Ensuite nous installons nos dépendances.
  • Puis ligne 39 nous ajoutons un matcher PHPUnit afin d’avoir les informations dans la GUI.
  • Ligne 42 nous exécutons PHPStan.
  • Ligne 45 a 49, nous utilisons des secret en tant que variable d’environnements, puis ligne 52 nous exécutons nos tests.

Afin d’ajouter des secrets, directions l’onglet Settings puis la section Secrets, il vous restera à cliquer sur New Secret.

Pour plus d’informations, direction la section Secret de la doc.

Ci-dessous d’autre image des actions:

Actions en cours
Affichage lors d’un échec
Détails de l’échec.
Historique des actions

Pour plus d’informations, regardez la documentations des GitHub Actions.