Logitech Brio 500, zoom sous linux

 Logitech Brio 500

Vous avez une caméra logitech Brio 500 et vous trouvez que vous êtes éloignez ans l'image dans les logitiels de messageries. Il est possible d'améliorer cela 

Lister les périphériques

v4l2-ctl --list-devices

Brio 500 (usb-0000:00:14.0-4):
       /dev/video0
       /dev/video1
       /dev/media0

Lister les fonctionnalités du périphériques

v4l2-ctl -d /dev/video0 --list-ctrls

User Controls

                    brightness 0x00980900 (int)    : min=0 max=255 step=1 default=128 value=129
                      contrast 0x00980901 (int)    : min=0 max=255 step=1 default=128 value=128
                    saturation 0x00980902 (int)    : min=0 max=255 step=1 default=128 value=128
       white_balance_automatic 0x0098090c (bool)   : default=1 value=1
                          gain 0x00980913 (int)    : min=0 max=255 step=1 default=0 value=0
          power_line_frequency 0x00980918 (menu)   : min=0 max=2 default=2 value=2 (60 Hz)
     white_balance_temperature 0x0098091a (int)    : min=2800 max=7500 step=1 default=5000 value=5000 flags=inactive
                     sharpness 0x0098091b (int)    : min=0 max=255 step=1 default=128 value=128
        backlight_compensation 0x0098091c (int)    : min=0 max=1 step=1 default=1 value=1

Camera Controls

                 auto_exposure 0x009a0901 (menu)   : min=0 max=3 default=3 value=3 (Aperture Priority Mode)
        exposure_time_absolute 0x009a0902 (int)    : min=3 max=2047 step=1 default=156 value=156 flags=inactive
    exposure_dynamic_framerate 0x009a0903 (bool)   : default=0 value=1
                  pan_absolute 0x009a0908 (int)    : min=-72000 max=72000 step=3600 default=0 value=0
                 tilt_absolute 0x009a0909 (int)    : min=-72000 max=72000 step=3600 default=0 value=0
                focus_absolute 0x009a090a (int)    : min=0 max=255 step=1 default=0 value=0 flags=inactive
    focus_automatic_continuous 0x009a090c (bool)   : default=1 value=1
                 zoom_absolute 0x009a090d (int)    : min=100 max=400 step=1 default=100 value=135

Modifier des valeurs

v4l2-ctl --set-ctrl=zoom_absolute=135

Ces modifications peuvent être faite pendant que vous utilisez la caméra. 

Multiple fetch dans une requête avec jpa

Hibernate et fort probablement les autres ORM sont limité dans la capacité de ramener tout une structure d'object imbriqué.

@Entity

private class Student{

 

    @Id

    private Long studentId; 

    private String firstname;

    private String lastname;

 

    @OneToMany(mappedBy = "student")

    private List<Course> courses

    @OneToMany(mappedBy = "student")

    private List<Book> books

}

MultipleBagFetchException

Si vous tentez de lancer cette requête provenant d'un repository

 

@Query("""

  select s 

  from Student s 

  join fetch s.courses

  join fetch s.books

""")

 List<Student> findStudentWithCoursesBooks();

vous obtiendrez une errreur de type MultipleBagFetchException. Il n'est pas possible de fetcher plus qu'une entité qui va généré un produit cartésien.

Il pourrait être possible d'éviter cette erreur en changeant les list pour des set dans l'entité Student, cependant le produit cartésien se produira toujours.

Solution avec transaction

@Query("""

  select s 

  from Student s 

  join fetch s.courses

""")

 List<Student> findStudentWithCoursesBooks(); 

Dans un service

@Transactional

public List<Student> getStudent(){

     List<Student>  students = studentRepository.findStudentWithCoursesBooks();

     for(Student student: students){

          student.getBooks().size();

     } 

}

Il y aura chargement des livres, puisque l'annotation Transactional a été utilisé l'erreur LazyInitializationException ne survientdra pas. Cependant pour chaque étudiant, une requête sql pour aller chercher les Book. C'est le problème n+1 souvent mentionné dans le domaine des orm.

S'il y a que très peu de student, et que la méthode getStudent() est très peu utilisé. Cela pourrais être une solution possible. Il y a toujours possibilité d'ajouter du cache dans l'application afin de limiter les dégats

Solution avec multiple requêtes

Il est possible de combiner de multiple requete, une pour chaque fetch que vous désirez.

Le problème du n+1 est ainsi évite.

Il faut cependant que les deux retournes les même Students dans notre cas. Il faut donc ajouter une condition

@Query("""

  select distinct(s)

  from Student s 

  join fetch s.courses

  where s.studentid  < 10

""")

 List<Student> findStudentWithCourses();

 

@Query("""

  select distinct(s)

  from Student s 

  join fetch s.books

  where s.studentid  < 10

""")

 List<Student> findStudentWithBooks(List<Student> students); 

 

 

 

Dans une classe au niveau du service

 

@Service
public StudentService{
    private StudentRepository studentRepository;

    @Transactional
    public List<Students> getStudentWithCoursesBooks(){

        List<Student> students = studentRepository.findStudentWithCourses();
        return !students.isEmpty() ?
            studentRepository.findStudentWithBooks(
               minId,
               maxId
             ) :
           students;
        }

}

 

Au niveau des requêtes seul deux requetes sont exécutés .

  

Conception d'api REST

 Il y a une multitude de question quand nous commencons à convevoir un API rest. Un débat qui reviens souvent est les ressources imbriqués, parent / enfant, sous-ressource.

Hierachie

Pourquoi opter pour

/parents/{idParent}/enfants/{idEnfant}

au lieu de 

/enfants/{idEnfant}

 

La première approche peut être préférable si on veut montrer le lien hierarchique qui unit les ressources. Il faut cependant ne pas exagérer du niveau hierachique, car l'url peut rapidement devenir très long et rendre le tout moins lisible. Il est d'ailleurs rare de voir un api avec plus de 2 niveau.

Dans le deuxième cas, pour une sauvegarde, il faudrait que la ressource est le nom du parent.

Une autre approche serait

/parents/{idParent}?enfants={idEnfant}

 

Doublon

 

Rien n'empêche d'utilisé plusieurs approches, dans ce cas, on pourrait se retrouver dans le cas qu'il y a différent endpoint pour obtenir la même ressource.

 

Longueur des url

/companies/{idCompany}/departments/{idDepartment}/projects/{idProject}/employees

 

Il faut cependant ne pas exagérer du niveau hierachique, car l'url peut rapidement devenir très long et rendre le tout moins lisible. Il est d'ailleurs rare de voir un api avec plus de 2 niveau.

Changement de la relation

Avec une approche hierarchique,  s'il y a changement dans la relation dépendant si vous désirez continuer d'offrir la ressource ou non, il faudrat penser à utiliser le versionnement de votre api. Une redirection est aussi possible via en autre un api gateway

Sécurité

L'approche est une hierachie dévoile une relation entre les ressources qui pour dans certain casne pas être dévoilé.

Par exemple sur un site de rencontre

/users/{id}/pictures/

Il est possible qu'on ne veuille pas permettre à n'importe qui d'accéder à toutes les images d'une personne. Un autre niveau de sécurité peut être ajouté afin de permettre qu'a certain type d'utilisateur d'y accéder via par exemple la notion de rôle.

Il n'y a pas de bonne ou mauvaise approche, il faut juste connaitre les différentes possibilités et employé la méthode la plus adéquate pour nos besoins. N'oublier pas de bien documenter votre api par exemple avec un outil tel que spring-doc, swagger.

Versionnement de son api rest

 Vous avez un ensemble d'api qui est utilisé par de multiple clients. De nouvelle fonctionnalités prévue vont changer les valeurs de retour et les paramètres de certaines méthode. Afin de ne pas casser l'existant, il est possible de mettre en place plusieurs versions des apis.

Nous verrons différentes approche pour mettre en place le versionnement d'un api.

Versionnement des entités, payload

Dans la première mise en place d'un api vous avez une entité  Person

Si vous devez ajouter un nouveau champs dans cette entité, l'ancienne pourrait être renommé PersonV1 et la nouvelle PersonV2. PersonV2 ayan un champ prenom

Versionnement des url

@RestController
public class PersonController {

  @GetMapping("v1/person")
  public PersonV1 personV1() {
    return new PersonV1("Collin");
  }

  @GetMapping("v2/person")
  public PersonV2 personV2() {
    return new PersonV2("Collin", "Marc");
  }

}

Versionnement par un RequestParam

@RestController
public class PersonController {

  @GetMapping(value="/person", params="v1)
  public PersonV1 personV1() {
    return new PersonV1("Collin");
  }

  @GetMapping(value="/person", params="v2")
  public PersonV2 personV2() {
    return new PersonV2("Collin", "Marc");
  } 

}

L'appel se ferait de cette façon


http://localhost:8080/person?v2

Versionnement par l'headers de la requête

@RestController
public class PersonController {

  @GetMapping(value="/person", headers="api-version=1)
  public PersonV1 personV1() {
    return new PersonV1("Collin");
  }

  @GetMapping(value="/person", headers="api-version=2")
  public PersonV2 personV2() {
    return new PersonV2("Collin", "Marc");
  } 

 } 

Si vous utilisez un outils tel que rester, postman, il faut ajouter dans la section headers la clé

api-version

et la valeur

1

Versionnement par le media type

@RestController
public class PersonController {

  @GetMapping(value="/person", produces="application/vnd.api-v1+json")
  public PersonV1 personV1() {
    return new PersonV1("Collin");
  }

  @GetMapping(value="/person", produces="application/vnd.api-v2+json")
  public PersonV2 personV2() {
    return new PersonV2("Collin", "Marc");
  } 

 } 

Le media type doit être mis le headers avec la clé Accept.

Plusieurs approches ont été spécifiés et tous ont un moins gros acteurs du marché utilise chacune de ses approches.

GitHub utilise le média type

Microsoft utilise le heders

Twitter utilise le url 

Amazon utilise le request param

Mettre à jour la sa feature branch avec sa branche parent

Branche de fonctionnalité

Les branches de fonctionnalité sont un bon moyen de ne pas polluer la branche principale. Imaginer que l'utilisateur fait une multitude de commit pour une fonctionné x dans la branche principale entrecoupé de plusieurs autre concernant une fonctionnalité y.

Il peut devenir complexe en cas de problème de revenir en arrière ou bien simplement de suivre le développement.

Une branche de fonctionnalité permet de centralisé tous le développement autour d'une fonctionnalité avant de la mettre dans la branche principale. C'est une branche temporaire

Mettre à jour sa branche

Vous avez une branche de fonctionnalité feature/AddTaxManagement qui se base sur la branche principal par exemple develop.

De nombreuse personne envoie leur changement dans la branche develop.

Retourner dans la branche develop

>git checkout develop

 

 

Ramener les changements

>git fetch -p origin

Fusionner les changements remote en local

>git merge origin/develop

git checkout feature/AddTaxManagement

Fusionner la branche develop avec votre feature branch

>git merge develop

 

Pousser ses modifications dans la branche remote

>git push origin feature/AddTaxManagement