Une histoire sur l'adoption de Django au lieu de Rails dans une jeune startup

Ravi de vous rencontrer, je m'appelle Matsunaga de LOGICA Co., Ltd. J'ai choisi Django pour développer un nouveau produit, mais comme Django est un débutant, je voulais connaître les connaissances de chacun et mettre en place un calendrier de l'avent. Je vous remercie.

Nous n'avons encore rien fait d'unique techniquement, nous avons donc décidé de publier notre propre expérience.

Adopté Django dans une jeune startup

Alors que la popularité de l'apprentissage automatique a augmenté et que la notoriété de Python s'est également accrue, j'ai l'impression que l'image de "Python = pour le calcul" se répand. Aussi, dans le cas du système web, Rails est très riche en services d'apprentissage de programmation tels que Techcamp et Progate, donc je pense que le nombre de personnes faisant des Rails est en augmentation, en particulier aux startups (le nombre d'échantillons n'est pas grand). Mais)

Dans le cas des startups, en particulier des entreprises où de très jeunes comme nous sont fondateurs, il existe de nombreux cas où il n'y a pas d'ingénieurs ayant une expérience de travail, et ** la facilité d'apprentissage ** devient très importante. Je pense qu'il est naturel que Rails et les frameworks PHP (pas familiers) avec beaucoup d'informations japonaises soient souvent choisis.

Je pense qu'il existe de nombreuses (?) Sociétés de capital-risque qui utilisent Django au Japon, mais je ne pense pas qu'il y ait beaucoup de jeunes sociétés de capital-risque. Alors que de nombreuses entreprises célèbres l'ont adopté à l'étranger, j'estime que je n'ai pas obtenu la citoyenneté japonaise.

Cette fois, j'ai résumé pourquoi j'ai choisi Django au lieu de Rails dans cette situation, et ce qui était bon et mauvais dans le choix de Django en tant que jeune startup. ** * Cet article ne décrit pas la technologie, les performances, le design, etc. de Django ** ** * Peut être limité aux jeunes et aux startups en démarrage **

C'est un article très spécialisé, mais si vous le souhaitez, restez avec moi jusqu'à la fin.

Notre situation actuelle

Nous utilisons un site de recherche croisée d'hôtels pour simplifier la recherche d'hôtels, en particulier pour le problème de la "recherche / réservation d'hôtel fastidieuse", même si le voyage est un voyage relaxant. Je développe. Ce n'est pas un Jaran ou Rakuten Travel, mais un site de comparaison similaire à Travelko-chan et trivago.

sakutabi.com

Je l'ai sorti il y a quelques jours, mais je n'ai pas fini d'écraser les bugs et ** une énorme quantité de saisie manuelle chaude ** du tout. (Afin de réduire le nombre de comparaisons, j'ai essayé d'identifier automatiquement différents noms de plans et noms de chambres sur chaque site de réservation, mais ce n'était pas quelque chose qui pouvait être réglé, donc je le ferai manuellement ** ) ~~ Pas lors de la rédaction d'un calendrier de l'Avent ~~

Actuellement, nous développons deux projets Django distincts, le robot d'exploration qui acquiert les informations sur les postes vacants et le site de comparaison lui-même. ** L'entreprise est encore seule, donc je la développe également seule.

Mon niveau en début de développement

Demandes / exigences pour la sélection de la technologie

L'embauche ne signifie pas que le nombre de développeurs augmentera considérablement, et comme le nombre de développeurs est petit pendant un certain temps, nous soulignons que c'est ** facile ** de toute façon.

  1. Je veux unifier le langage et le cadre
  2. Il y a un écran de gestion (ou vous pouvez le créer immédiatement)
  3. Je veux maintenir les nouveaux coûts d'apprentissage aussi bas que possible

Le premier est la question du changement de tête et des coûts d'apprentissage. Lorsque vous choisissez d'écrire le robot d'exploration (et l'écran de gestion) en Python (Django) et le média dans Rails, vous avez l'impression qu'il est ennuyeux d'absorber la différence dans la définition de la migration ou d'écrire un fichier de modèle séparé. J'avais le sentiment que je voulais le réutiliser. Je pense que le style à deux épées du framework full-stack ne devrait pas être fait au stade d'un ou deux développeurs avant de le réutiliser.

Quant au deuxième écran de gestion, même si je choisissais Rails, je pourrais gérer avec gemme, donc je m'en fichais beaucoup ici.

Concernant le troisième coût d'apprentissage, si je suis seul, ** étudier = arrêter le développement **, et si je n'y suis pas habitué, je vais perdre du temps, j'utiliserai donc le langage et le cadre auxquels je suis habitué. C'était une exigence absolue pour l'utiliser. De plus, l'utilisation de deux cadres augmentera la quantité d'apprentissage, j'ai donc pensé dès le début que j'en utiliserais un.

** En tenant compte des trois conditions ci-dessus, j'ai choisi Django. ** **

Pourquoi j'ai choisi Django

Puisqu'il s'agit d'une startup en période d'amorçage, il y a de fortes chances que ce que vous faites soit effacé en pivotant etc. **, et comme c'est une prémisse majeure que moi, le fondateur, je participerai également au développement, ** je suis le plus facile à écrire * * Priorité à cela.

Raison personnelle

En conséquence, Python était le langage extrêmement familier, j'ai donc choisi Django, qui est un framework Python et dispose également d'un écran de gestion. Je suis plus habitué aux Rails, mais je n'étais pas non plus un ingénieur chevronné des Rails. ** Je n'ai pas fait de Django une comparaison technique entre Rails et Django. ** ** Une autre raison est que ** les robots sont habitués à écrire en Python ** (j'avais l'habitude de regarder beaucoup les robots dans mon travail précédent).

En passant, après avoir décidé de m'unifier à Python, j'ai écrit un script de déploiement avec fabric et cuisine, donc tout sauf le front-end multimédia est fait de Python. Si vous utilisez Django pour tous, il sera plus facile d'utiliser certains scripts de déploiement.

De plus, l'analyse est facile car Python dispose d'une bibliothèque complète. Je n'ai pas écrit de script d'analyse gorigori depuis un moment, mais je pense que ce sera un peu plus facile pour le travail d'analyse si vous créez un lot, etc. en utilisant l'ORM de Django dans un projet Django.

Raisons d'embauche

Bien que le nombre d'ingénieurs Rails ait augmenté, je ne pense pas que le nombre d'ingénieurs au-dessus d'un certain niveau ait fortement augmenté. Puisque la probabilité d'un ingénieur diminue lorsque vous touchez Django, et qu'il y a peu de startups qui adoptent Django, cela se démarque par lui-même, donc je pense que la difficulté d'embauche ne changera pas de manière significative entre l'ingénieur Rails et l'ingénieur Django. J'ai fait.

Cependant, tout cela est ** tout sur la prémisse du recrutement en milieu de carrière, et je fais une grosse erreur **, donc j'écrirai à ce sujet plus tard dans cet article.

Ce qui est bien avec Django

Tout est Django, donc c'est facile sans changer de tête, et c'est facile d'utiliser le code. Après cela, c'est facile car vous pouvez voir le résultat de l'exploration sur l'écran de gestion. C'est une pile complète, donc si vous recherchez les fonctionnalités que vous souhaitez, vous les trouverez, et comme les documents sont volumineux, ce n'est pas un problème pour le moment. ~~ Pas un avantage unique de Django ~~

Problèmes avec Django (choses qui semblent gênantes)

Eh bien le sujet principal (rires) ** En fait, je n'ai pas de problèmes techniques jusqu'à présent w ** C'est parce que la quantité de code est encore petite et que nous ne sommes pas au stade de presser les détails. C'est un projet que j'ai fait récemment, donc je n'ai pas besoin de mettre à jour la version de Django, et j'ai l'impression que "Oh, le framework full stack est pratique."

Cependant, certains points sont subtils pour les jeunes startups en période d'amorçage. Le "J'ai fait une grosse erreur sur la prémisse du recrutement à mi-carrière" que j'ai écrit plus tôt est inclus dans le contenu suivant.

1. 1. Difficile d'embaucher un stagiaire ou un emploi à temps partiel (peut-être)

La raison pour laquelle il peut être difficile d'embaucher est que je ne recherchais que des personnes ayant une expérience de travail, donc je ne cherchais pas réellement un stagiaire ou un emploi à temps partiel sans expérience à Django.

Les jeunes entreprises en démarrage embauchent souvent des personnes de la même génération en raison de problèmes financiers et de connaissances **, et des emplois à temps partiel en raison d'un travail acharné et ** de l'importance de «faire n'importe quoi» ** Je pense que le stagiaire est souvent adopté. En d'autres termes

Compétences au moment de l'embauche >>>>>> Vitesse de rattrapage et ajustement culturel

Ce sera. De ce point de vue, Django n'est en aucun cas adapté aux débutants (détails ci-dessous), donc je pense que cela réduira les options de recrutement pour les jeunes startups w **

Comparé à Rails, Django a moins de matériel didactique facile à comprendre pour les débutants ** et ** moins d'informations en japonais **, donc pour les débutants en programmation ** «Programmation peu familière» plus «Anglais» Ce sera pénible **, et je pense qu'il est assez difficile de partir d'un débutant complet. (Si un débutant complet doit ou non faire d'abord le framework full stack)

Aussi, je ne pense pas qu'il y ait des personnes de la même génération qui aient de l'expérience avec Django w (j'ai 24 ans) En premier lieu, même si Rails sait qu'il est un ingénieur débutant, il ne connaît pas l'existence de Django. Je pense que même Python est suspect. Même si vous le savez, je pense que vous avez lu "Dijango" (la source est moi)

Comme il y a peu d'utilisateurs quelle que soit la génération, le nombre de personnes et d'endroits où vous pouvez facilement poser des questions est limité et, par conséquent, la capacité de lire des documents (en anglais) et du code source devient relativement importante. Cependant, ** lire des documents et du code source est naturel pour les ingénieurs **, donc pour ceux qui veulent devenir ingénieurs, je pense qu'il vaut mieux commencer par Django car cela vous donnera une bonne habitude.

Dans tous les cas, ** je pense que cela demande plus d'énergie que de démarrer Rails **

Cependant, je pense aussi que Python est un bon langage facile à étudier pour les débutants.

2. Coût de recherche élevé

Bien que cela recoupe partiellement le premier point, je pense que le coût de la recherche est élevé car il y a peu d'informations en japonais, il y a peu d'utilisateurs (nationaux) et il y a peu de sessions d'étude.

Surtout pour les startups où les jeunes ne sont pas toujours hautement qualifiés, il est très agréable de trouver un exemple immédiatement quand ils se demandent comment faire cela. Heureusement, Python et Django ne sont pas mineurs dans le monde, il existe donc de nombreuses bibliothèques. Cependant, je ne pense pas que ce soit une bonne start-up de s'inquiéter de ne pas les connaître ou de ne pas les mettre en œuvre. Il est facile de trouver l'anglais, il est donc plus difficile de se concentrer sur l'anglais que «je ne le trouve pas».

En ce qui concerne les sessions d'étude, je pense qu'une des raisons est qu'il n'y a pas de guerre religieuse comme le framework Javascript et la sélection d'outils, et il n'y a pas beaucoup de sujets à discuter en premier lieu. Cela peut avoir quelque chose à voir avec l'idée de Python.

En outre, bien que ce soit une image égoïste, il y a une image que les personnes qui utilisent Django pour les affaires n'apparaissent pas souvent dans les sessions d'étude en premier lieu w

J'aurais aimé qu'il y ait un endroit pour partager plus de connaissances sur le développement en utilisant Django, donc si l'entreprise a un peu de puissance de développement supplémentaire, Django (pas seulement avec le framework Python) rencontre et sessions d'étude. Je veux aussi le faire. Nous pourrons peut-être parler aux entreprises qui ont adopté Django.

Résumé

Bonne chose(?)

Mauvaises choses / préoccupations

** S'il y a une personne autre que moi qui est le développeur principal au début du développement, j'ai probablement choisi Rails w ** Django a été choisi ** Je suis le seul développeur pour le moment ** et le robot d'exploration est Python La ** condition personnelle ** dans laquelle j'avais l'habitude d'écrire était la plus grande.

J'ai écrit sur diverses sélections technologiques, mais en premier lieu, il est important pour les startups de créer rapidement et de créer de la valeur avec ** produits **, alors arrêtez de réfléchir profondément et faites de votre mieux en développement! !!

P.S. Nous recherchons également des amis, alors n'hésitez pas à nous contacter si cela vous intéresse! https://www.facebook.com/masaru.matsunaga.9

Recommended Posts

Une histoire sur l'adoption de Django au lieu de Rails dans une jeune startup
L'histoire d'avoir un regard doux et douloureux sur les utilisateurs personnalisés sur Django
Une histoire sur l'implémentation d'un écran de connexion avec django
Une histoire sur le changement du nom principal de BlueZ
L'histoire du champ de modèle Django disparaissant de la classe
Une histoire de regroupement de données de séries chronologiques d'échange