API c'est un sigle en anglais Application Programming Interface. On peut imaginer une API comme un contrat type entre un fournisseur de services et plusieurs clients. Cela ouvre la multitude de possibilités pour le système eCommerce du fournisseur.
📙️️ Par exemple, le constructeur de cuisines pourrais utiliser son outil 3D existant et envoyer les commandes directement dans le back-office du SI de Leroy Merlin. Ainsi le business peut engager les nouvelles collaborations tout en assurant le contrôle sur les commandes et les paiements.
Le schéma suivant met en évidence quelques outils techniques qui se trouvent dans notre boite d'outils préférés pour ce genre de projet:
Maintenant on expliquera plus en détail chaque brique logiciel présenté ci-dessus.
En terme d'architecture nous avons opté pour une approche hybride - Microservice dans Monolithe 😱. Techniquement c'est un jar à part entier avec toute la logique centré API (configuration, sécurité, controllers REST), mais qui se trouve à l'intérieur du monolithe.
Pourquoi une telle approche? En fait, le déploiement indépendant est un processus assez délicat dans l'échelle d'une grande entreprise (hébergement, sécu, réseaux, etc.) Mais cette approche hybride permettra dans le futur proche d'extraire ce composant sous la forme du fat Jar ou conteneur Docker et le déployer comme une vraie micro-services.
📙️️ Oui, en pratique l'élégance et la beauté d'une technologie avancée peut être très limitée par les circonstances rigides autour de vous. Mais comme des professionnels et malgré circonstances techniques on doit trouver des compromis ⚖️ pour faire avancer le business.
Dans le reste, l'architecture est classique - le pure REST en JSON.
Le framework Spring est devenu un standard de facto dans le développement logiciel d'entreprise en Java. A notre avis ce framework, créé dans les années 2000 par 🧑🔬 Rod Jonson, a gagné la bataille contre la norme J2EE.
Nous sommes très Spring à DevAtlant et ce framework était un composant technique central dans l'architecture du projet. Le sous-projet Spring.Test s'est avéré très pratique surtout lors du développement des tests end-to-end et de rétrocompatibilité de différentes versions de l'API.
La sécurité d'utilisation de l'API était l'une des besoins non-fonctionnelles majeures dans le Cahier de Charges du projet.
📙️ La performance ⏰ et l'audit 🔎 étaient 2 autres besoins non-fonctionnelles clairement exprimés par le client. Cela constituera une article entière dans notre série consacrée à ce sujet.
La pièce centrale du module de sécurité est un Header HTTP dédié qui sert à authentifier et autoriser l'accès. Ce header contient la clé sécrète unique 🔑. Chaque partenaire reçoit sa propre clé pour chaque type d'environnement (dev, recette, production).
1
|
|
Le problématique majeur c'est la provenance de cette clé sécrète. Qui doit le générer et attribuer à chaque partenaire ? Pour les solutions automatisées nous recommandons l'utilisation de la technologie oAuth 2.0 boosté par Spring. Pour le nombre limité des clients de vos API, vous pouvez générer et stocker la clé à la demande dans la configuration de serveur.
Sur tous nos projets on applique les principes d'industrialisation 🏗 du génie logiciel. L'un de ces principes est l'automatisation.
Pour le code source on utilise
Maven, GitLab, Jenkins, Sonar Qube, Nexus
. Rien de nouveau ici.
Mais la question de la qualité de la documentation se pose très souvent dans tous les projets plus ou moins complexes. Et cette question devient cruciale quand on parle de l'API, où la qualité de la documentation doit être toujours impeccable, car la doc est utilisée par plusieurs équipes externes❗️ De l'autre coté, soyons franc, les développeurs n'aiment pas écrire 🤮 еt surtout maintenir à jour la documentation du projet 🆘. Nous avons trouvé une solution à ce paradoxe - le projet Swagger ✅
Swagger permet d'incorporer les annotations
spécialisées autour de vos méthodes du @RestController
.
Et ces annotations sont utilisés lors de la génération de la documentation.
Un immense avantage du Swagger c'est la documentation que les partenaires peuvent exécuter lors de la phase d'exploration de votre API.
Et nous avons remarqué que nos développeurs sont très à l'aise avec cette approche qui ne ressemble pas du tout à l'élaboration du document Word fade et sans etat d'âme.
Comme résultat on a une documentation:
Nous pensons que c'est inutile d'expliquer l'importance de communication des erreurs aux client de votre API. Bien sûr, vous pouvez inventer votre propre structure ou modèle des codes et messages de retour, mais nous vous recommandons de jeter un œil sur le projet VND.errors (qui fait partie du project Spring Hateoas).
L'utilisation est très simple et puissante à la fois. Tout d'abord il faut importer le JAR de Hateoas. Avec maven il suffit de faire :
1 2 3 4 5 6 |
|
Puis, on peut déclarer l'intercepteur des nos exceptions API dans le controlleur Spring annoté par @ControllerAdvice
comme suit:
1 2 3 4 5 6 7 8 9 10 11 |
|
Et finalement, en cas d'erreur le client obtient une erreur suivante représentée dans le protocole HTTP : Dans la capture d'écran ci-dessus le plus important c'est le body de la réponse en format JSON avec les 3 champs suivants :
Le format est très bien pensé - facile à utiliser et ouvert à être enrichie par vos propres règles ✅.
Nous sommes très fans de l'approche TDD. Les tests automatiques pour notre module API ont permis non seulement de garantir la qualité du code, mais aussi ont devenu une plateforme de test de assurant la rétrocompatibilité de différentes versions.
Au début du projet nous avons écrit les tests unitaires et d'intégration avec jUnit
et Spring.Tests. C'était la version /V1/
de l'API.
Un peu plus tard le protocole de l'API a évolué jusqu'à la version /v2/
.
Nous avons eu la besoin d'assurer le fonctionnement en parallèle 🔃 de /V1/
et /V2/
. Nos tests d'intégration
existants ont permis en quelques jours de créer les jeux de tests pour la /V1/
et /V2/
.
Comme Leroy Merlin en Ukraine opère en deux langues - l'ukrainien 🇺🇦 et le russe 🇷🇺 - on avait besoin de localiser tous les messages de l'API.
Nous avons choisi d'implémenter la localisation en ce basant sur l'abstraction fournie par Spring ResourceBundleMessageSource
Pour le management des traductions plus poussé et en plusieurs langues nous utilisons LocaleApp
La nature hybride de l'architecture (décrite plus haut) impose packaging hybride également. Le core de l'API était mit dans le WAR et le projet Swagger était déployé via le fat Jar buildé par le plugin maven du Spring.Boot. Donc nous avons paramétré notre CI serveur Jenkins en ajoutant un nouveau step - le déploiement du JAR avec la documentation Swagger.
]]>La société DevAtlant Software EURL a été créée en 2016 à Lannion - 📡 la capitale française de télécoms. 6 mois après nous avons ouvert le centre de développement à 🇺🇦 Kiyv . L'histoire de la création de la structure en 🇫🇷 France est présentée dans cette article 🔥 parue dans Le Télégramme.
DevAtlant Software est un éditeur de logiciel sur mesure : modules d'intégration, sites e-commerce, services web à fort trafic, streaming vidéo en ligne, chatbots. Nos clients sont des grandes entreprises françaises qui opèrent à l'international.
🛠 Parmi nos travaux les plus complexes c'est le développement du système eCommerce pour Leroy Merlin Ukraine. En 5 mois notre équipe de 3 ingénieurs a conçu et a développé le système de gestion des commandes en Java. Les dossiers d'architecture fonctionnelle et technique ont été élaborés en UML. Le processus de développement est industrialisé et permet de déployer une nouvelle version en production en cliquant sur un bouton. Jenkins et SonarQube assurent l'exécution automatique des tests unitaires, fonctionnels et la non-dégradation de la dette technique. L'application est en production depuis 2 ans et elle est devenue une vraie plateforme digitale pour toute l'entreprise.
Nos avantages concurrentiels sont l'excellence technique et la maitrise de la langue française. Nos ingénieurs sont capables d'expliquer l'apparition d'un bug dans un code multithread en utilisant des formules de politesse en français 😃.
L'Ukraine nous a attiré tout d'abord par les privilèges inédites d'État pour les entreprises IT :
✅ Toutes les produits et services IT destinés à l'exportation sont exonérés de la TVA.
✅ Les ingénieurs en Ukraine sont embauchés en tant que autoentrepreneurs. Cela signifie l'absence de charges patronales pour l'employer, d'où l'économie à 50% sur les fonds salariaux.
✅ D'après l'analyse UNIT.City l'export de services IT depuis l'Ukraine atteint 5.4 $ milliards en 2018. L'Ukraine est le premier exportateur en Europe des services informatiques.
✅ Actuellement en Ukraine il y a plus de 4000 entreprises IT avec environ 185 000 ingénieurs.
✅ Selon les résultats du portal HackerRank les programmeurs ukrainiens se positionnent
en 11 place dans le top de 50 pays avec les meilleurs informaticiens.
Le TJM (Taux Journalier Moyen) varie entre 150 et 350 € selon le profil.
Ce TJM étant 2/3 fois moins élevé qu'en Europe et les compétences confirmées des programmeurs
ukrainiens font de l'Ukraine une destination de prédilection pour l'outsourcing des services high-tech.
Presque tout projet pour un nouveau client démarre d'un simple MVP en mode forfait.
Après les prestations se déclinent en mode régie ou hybride.
Ces conditions permettent au client de mieux choisir son prestataire tout en gardant le contrôle sur le budget.
L'écosystème IT en Ukraine se développe très vite.
Plus de 20 villes possèdent leur IT-clasters - les plus connus sont Lviv IT Cluster, Kharkiv IT Cluster, IT-Dnipro Community et Kyiv IT Cluster.
Plus de 50 coworking et hubs.
Plus de 1000 IT-conférences ont lieu chaque année.
La plus connue conférence Java en Europe 🔥 Devoxx aura sa troisième édition
à Kiev le 1-2 Novembre 2019.
Les cabinets de services RH, juridiques et comptables spécialisés dans le secteur IT sont bien présents dans toutes les grandes villes de l'Ukraine.
Real, production-grade and automated acceptance tests on top of Selenium are running on different environments.
If you are using Serenity you will find here a useful tip - how to set up a multi environment configuration.
Recently I discovered the powerful Java framework for writing acceptance tests on top of Selenium, which is called Serenity.
One of the basic requirements we have is to run your tests on different environments:
So you need to tell the serenity framework where to find those config. We have started to using Spring profiles to manage this configuration. Hopefully Serenity supports Spring. But we faced the problem of handling 2 different configs: 1. Serenity.properties 2. Spring-based config with localhost.properties, staging.properties, production.properties
The solution is to use the special config file natively understandable by Serenity framework - serenity.conf
1 2 3 4 5 6 7 8 9 10 11 |
|
Unfortunately this very useful feature is not yet documented on the official project page, I have found it here
This feature is available for you from 2.0.30. Guys from Serenity project releases often (369 releases! at date of the 22 March 2019 ), so keep in mind to regularly updating your maven dependency from official GitHub release page
1
|
|
In fact, the datetime-local attribute is rather new in HTML5 specification and the implementation differs from one browser to another.
By reading the HTML5 specs about this attribute, I noticed that date and time part should be separated by literal string “T”
FireFox is more permissive for this particular scenario and displays the date correctly. Chrome respects the specification without applying any magic and does not recognize the “wrong” date format.
The solution is to respect the w3c specification and to use the literal string “T” between date and time parts. Like this
1
|
|
If your HTML code is generated programmatically (PHP, Java, etc), you should apply the special formatting for your objects containing dates.
For my Java project with Spring and Thymeleaf, I applied the following annotation for my fields typed as Date.
1 2 3 4 5 |
|
Please, note, that accordingly to SimpleDateFormat pattern doc, literal T must be enclosed between single quotes.
]]>L’idée était de capter l’attention des étudiants par la création d’une application ludique et interactive. L'interaction avec les étudiants a été assurée grace aux smartphones qui sont aujourd'hui omniprésents. Le processus de création – l’élaboration du code d'application dans l’IDE – a été montré du A à Z avec le vidéoprojecteur.
Et après cela nous avons décrit les différentes opportunités offertes aux étudiants ukrainiens pour continuer leurs études ou la vie professionnelle en France.
En Avril 2017 notre équipe a organisé sa première conférence « Building Telegram chatbot in 15 minutes » dont l’objectif était de créer un événement medio-technologique pour motiver les étudiants ukrainiens. Cette motivation a 2 facettes :
Cette conférence a eu lieu à l’Université d’Etat de la Chimie et de Technologie de Dnipro.
Nous avons consciemment choisi le titre très concret еt technologique pour attirer le plus grand nombre des étudiants. Les chatbots, le messenger Telegram sont très à la mode en ce moment.
La meilleure façon pour réussir votre présentation c’est de faire agir votre audience. Cette technique j’ai vu pour la première fois en 2009 au soirée Paris JUG animée par Didier Girard. Faire du code on live, déployer sur un serveur avec IP publique et inviter l’audience à voter en utilisant des SMS – c’étais tout simplement époustouflant. Cela m’a marqué à tel point que je m’en souviens en 2017 et je le raconte dans cette article.
En s’inspirant de cette approche, nous avons créé le jeu « Deviner un nombre » sous forme de chatbot Telegram.
Le principe est très simple :
Lors de la présentation nous avons montré le processus de la création de l’application du A à Z:
Programmation et toute l’activité autour étaient les composants clés de la présentation. En 30 minutes nous avons essayé de lever le rideau de la programmation industrielle:
Le code source de ce bot est disponible sur notre github.
Voici notre bref retour d'expérience:
Avec l’autorisation de Corentin je publie ici ce travail.
L'étude complète est disponible pour le téléchargement ici. Pour tous ceux qui sont intéresses par la conclusion, je mets ici juste le dernier paragraphe :
En vue de tous les éléments que nous avons abordés précédemment au cours de ce dossier, je recommanderai donc à l'entreprise de patienter avant de commencer une exportation de ses services vers les États-Unis. En effet, cette dernière est tout de même relativement récente (septembre 2016) et se trouve avoir une concurrence très fournie en matière de solutions informatiques sur mesure. Il faudrait donc patienter quelques temps afin de se forger une clientèle fiable et fidèle en France tout d'abord, afin d'élaborer une réputation pour l'entreprise et par la suite, commencer l'élaboration d'un projet d'exportation de ses services avec l'aide de la COFACE notamment, qui sera d'une aide précieuse pour pouvoir avoir une idée concrète de la fiabilité du projet d'exportation de services de solutions informatiques sur mesure vers un pays dont l'industrie l'informatique est très répandue.
Je tiens à remercier Corentin d’avoir accompli cette excellente étude en toute autonomie. On prend en compte tes recommandations et on partira à la conquête de San-Francisco en 2018 :)
]]>Прямая ссылка на мой корткий спич - https://youtu.be/9yHCnKHthV4?t=86
]]>Я буду писать об IT-компании, но по сути это будет применимо к любому бизнесу.
Форма собственности, государственная/региональная финансовая помощь, налоги и тд. Начинать всегда нужно со чтения документации – RTFM никто не отменял и здесь. В интернете есть множество специализированных ресурсов, где Вы сможете прочитать о всех этих вопросах.
Я рекомендую вот этот ресурс - https://www.afecreation.fr .Официальный источник. Коротко, методично и ясно. Конечно, все на французском. Начните отсюда - Этапы создания компании
Я не буду объяснять насколько важно выбрать хорошего бухгалтера.
Расскажу как сделать так, чтоб этот выбор был максимально комфортным.
Спросите в Вашем Pole Emploi список аккредитованных agents comptables или прямиком идите сюда http://www.experts-comptables.fr . Эти бухгалтера предоставляют 8 часов бесплатных консультаций. Здесь Вам помогут выбрать форму собственности (SARL, EURL, SAS ), определиться с уставным капиталом. Хороший бухгалтер будет обходиться в районе 1000 евро в год.
Есть много online агенств (в облаке) предоставляющих бухгалтерские услуги. Бухгалтеры as a Service. Я подписал контракт с этими ребятами - https://www.compta-intouch.com Я им плачу 110 евро в месяц. Это на 50% дешевле чем настоящий, живой бухгалтер. Учитывая специфику моей профессии, когда все находиться в “клаудах”, выбор мне дался довольно легко.
Updated: По прошествию более чем 15 месяцев со дня написания этого поста, отношение к этому сервису у меня сильно поменялось. Эта компания оказалась мягко говоря непрофессиональной. Не сдали годовые отчеты. Игнорировали мои звонки и письма. Пришлось вернуться к живому бухгалтеру. Да дороже, но можно всегда прийти и побеседовать по неотложным вопросам. Вывод: compta-intouch - люто НЕ рекомендую!
Устав — свод правил, регулирующих организацию и порядок деятельности в какой-либо определённой сфере отношений или какого-либо государственного органа, организаций, предприятия, учреждения и так далее. Устав делают юристы. Это дорого – примерно 1000 евро. Вот пример реального devis
Создавая компанию, Вы должны будете указать ее адрес. Собственно офиса у вас может и не быть, но почтовый адрес, куда будет приходить письма от разных гос. администраций, быть обязан. Не спешите ставить Ваш личный адрес. Воспользуйтесь услугой domiciliation. Это когда один и тот же физический адрес используется многими компаниями за небольшую арендную плату. То есть Вы можете жить и работать у себя в квартире в городе Кашан, а ваш адрес на официальных документах, визитках и тд, может быть place Opera 18, 75001 Paris. Согласитесь, последний вариант намного более профессиональнее.
Я подписал контракт с http://www.technopole-anticipa.com. Цена вопроса - 60 евро. Очень классные ребята. Рекомендую. Но они работают только в регионе Сote d'Armor (22), но смогут Вас сореентировать по похожим ассоциациям и в других регионах.
Кроме переадресации почты, они так же предлагают:
Собственно в продолжение последнего пункта из предыдущей главы о различных событиях.
Это хорошая возможность познакомиться с коллегами по цеху и наладить бизнес связи.
Например, на одном из хакатонов организованном Code D'Armor я познакомился с разработчиком из местного стартапа и впоследствии заключил с ними небольшой контракт на разработку решения для видео стриминга.
Ну и на последок надо сказать, что одна из причин открыть компанию именно в регионе 22, это морские красоты региона. Приятно делать бизнес в красивом месте
]]>
Dans ce post, je voudrais partager mes idées sur la ruée vers la startup qui fait bouillonner le monde technologique d'aujourd'hui.
Généralement, quand on crée une entreprise c’est pour gagner de l’argent. Malheureusement 80% des startups vont s’écraser sans atterrir à l’aéroport des entreprises réussis. Pour beaucoup des ingénieurs cette dilemme présente un obstacle incontournable pour se lancer dans l’aventure de l’entreprenariat. En 2011, j’ai lisait le blog de Nicolas Martignole @nmartignole, je comprenais sa philosophie du consultant indépendant et cela m’attirais beaucoup. Je n’osais pas de suivre le même chemin. J’avais peur de perdre la stabilité (lire la stabilité salariale) de ma position au sein d’une SSII. Dans 5 ans, après avoir travaillé pour quelques petites startups comme un salarié, j’ai pu voir quelques avantages qui étaient inédits pour moi. Et ces avantages m’ont incliné finalement vers la création de mon propre entreprise.
Ces avantages sont les suivants :
A mon avis ces avantages, à longue terme, sont plus importants qu’un salaire de 5K. Puisqu’après avoir travaillé toutes ces caractéristiques (même pendant quelques mois) vous deviendrez un soldat universel.
C’est inutile de décrire le nombre de technos que vous allez découvrir. Il faudra les apprendre, expérimenter avec et , le plus important, les vendre à vos clients. Cela n’est plus un simple HelloWorld cloné sur GitHub. Cela devient en quelques sorte votre produit et votre carte de visite dont vous êtes entièrement responsable. Le fait d’être propriétaire de quelque-chose va vous rendre discipliné et vous allez travailler méticuleusement sur chaque détail de votre code.
En tant qu’entrepreneur vous allez être confronté en permanence aux différents aspects du business technologique.
Prospection clientèle.
Vous allez travailler votre éloquence et apprendre de donner les présentations qui émerveillent. J’ai du m’acheter un bouquin exprès pour cela “Ecrire & Parler pour convaincre“ - manuel pratique pour rédiger et prononcer des discours efficaces.
Négociation des prix.
Évidemment il faudra bien négocier les pris de vos prestations. Croyiez-moi, c’est un art pour un technicien. Bon les prix eux-mêmes sont plus ou moins fixes, disons 600 euros par jour ou 50 euros l’heure. Mais le pack de prestations peut être configuré d’une manière très complexe. Par exemple, vous faites un développement d’un composant back-end en NodeJS chiffré à 10 jours. Outre le code source du composant vous pouvez vendre la garantie et le support de 10 jours. Vous pouvez envisager également de vendre la formation aux équipes du client sur comment utiliser votre serveur ou sur NodeJS. Si vous êtes passionné de l’automatisation et des pratiques du devOps, comme je suis, vous pouvez proposer une prestation de déploiement de votre projet sur Docker/Vagrant/Otto. Et ainsi de suite. Comme vous voyez cela peut être très varié.
Gestion administrative/financière de votre entreprise.
Vous allez faire connaissance avec le monde de la comptabilité et de l’administration. Choisir le statut juridique. Décortiquer les nuances de l’imposition. Signer des contrats. Faire des bons de commandes. Etc. T outes ces actions vont entrevoir pour vous la complexité de la gestion de l’entreprise.
Vous dirigez vous-même votre entreprise. Vous êtes un seul responsable de vos réussites et de vos échecs. Pour moi cette notion de responsabilité est très importante car elle est toujours accompagnée de la discipline, de la persévérance et de la maturité. Ce sont les qualités qui vont vous aider tout au long de votre vie.
Comme vous voyez c’est difficile d’évaluer les rapports financiers que cette expérience de l’entrepreneur technologique vous apportera. A mon avis ce rapport est plus de la nature qualitative que quantitative. C’est un level-up. Même, si vous allez perdre de l’argent, c’est qui est tout à fait possible, vous allez devenir quelqu’un de diffèrent. Conceptuellement diffèrent.
Alors, mon message est n’hésitez pas à devenir des entrepreneurs. C’est un meilleur investissement que vous pouvez faire.
]]>Речь пойдет о Master 2 en informatique, в 2004 это называлось DESS, что соответствует нашему диплому специалиста / магистра.
Итак программа обучения разбивалась на 3 части:
В этой статье я раскрою только 1-ую составляющую, а именно теоритический семестр. За эти 6 месяцев в нас впихнули столько материала, что я до сих пор не могу прийти в себя. Начиная от криптографии, с малой теоремой Ферма, заканчивая тонкостями международного права на патенты из области компьютерных программ.
Каждый день был чрезвычайно насыщен – быстрый темп лекций, огромный объем информации на самостоятельную проработку, практические занятия. Свои трудности я долго описывать не буду, но было очень тяжело. Когда после этих 6 месяцев я пошел работать как стажер на предприятие, я первый месяц думал, что нахожусь на райском отдыхе на Гавайях:)
А вот как выглядело расписание лекций во втором триместре, с января по апрель 2005:
А теперь самое интересное - это полный список предметов на мастере.
Tronc commun:
Filière Réseau:
Filière Communication:
Filière Image:
Самое полезное и незабываемое - это был Le Projet (Проект с большой буквы). У нас такого аналога нет. В начале семестра вся группа разбилась на команды по 4-5 человек. У всех групп было одно и тоже задание – спроектировать, реализовать и сдать в эксплуатацию программный комплекс для секретаря факультета по управлению расписанием. Ни много ни мало, а целый серьезный проект. За 6 месяцев работы мы прошли по всем фазам развития проекта:
У каждого в команде были свои обязанности – PM, архитектор, дизайнер. Но программистами были все :)
Изюминка этого проекта заключалась в том, что это было напрямую связано с теми предметами, что нам читали на лекциях. Скажем когда нужно было готовить план по распределению ресурсов и времени, то мы внимательно вслушивались в рекомендации профессора по Project Management. Если были вопросы по проектированию, то тут нам на помощь приходил преподаватель по Архитектуре, со своими паттернами. По лицензиям мы общались с бельгийским юристом, который нам читал Право в Информатике. Все предметы гармонично сливались с проектом и мы видели практическую пользу теории.
Вот короткий список того, что меня тогда поразило:
Итак в далеком 2004 году, скромный паренек из Днепропетровска, я поехал учиться во Францию. Сам. Бесплатно. На факультет информатики университета Марн-ля-Валле. Чтобы осуществить этот проект, я проделал довольно большую работу и теперь хотел бы поделиться своим опытом, советами и примерами документов.
Речь пойдет о бесплатном обучении в французском университете по программе, спонсируемой французским правительством, так называемая Bourse d'études du Gouvernement Français или сокращенно BGF.
Официальное описание программы на сайте Франции в Украине. Я не буду перечислять все необходимые формы, заявки, свидетельства и копии. Это все красиво и четко изложено в официальных источниках. Поэтому перейдем непосредственно к самым сложным и творческим процессам, а именно:
Самое сложное было получить предварительное согласие французского университета о зачислении. Я бы рекомендовал начать именно с этого пункта, и вот почему:
Я отправил порядка 80 запросов в разные университеты, и получил только 2 согласия по почте и 3 в электронной форме.
Моя основная стратегия на этом этапе сводилась к следующему:
Образец моего мотивационного письма вы можете скачать здесь.
Несколько рекомендаций и ссылок :
А вот пример projet d'études для математиков. Используется все та же тройная схема, с более детальным описанием Вашего опыта. Обратите особое внимание на использование спец. лексики.
То, что будет в посольстве лично у Вас, никто не скажет. Ниже просто мой личный опыт, который в очередной раз доказывает, что наша жизнь - игра, и все зависит от миллиона случайностей…
На конкурсе в посольстве, в 2004 году, было примерно 80 человек. Конкурс состоял из двух частей:
Письменную часть я попросту провалил. Сильное волнение и осознание того, что от этого сочинения зависит вся твоя дальнейшая жизнь ввели в дикий ступор. 30 минут я смотрел на стены и соседей, думая с чего начать. За последние 15 минут, я все-таки собрался и выдавил какое-то подобие сочинения.
До устной части у меня было 4 часа свободного времени и я отправился гулять по Киеву в весьма грустном настроении. Я понимал, что мое сочинение - это fail и уже думал как буду готовиться уже на следующий год. За эти 4 часа я уже смирился с поражением. Волнение прошло и на устную часть я шел спокойный и уверенный. Это, наверное, мне и помогло. 15-минутная беседа прошла просто блестяще. Из глубин памяти вырывались нужные слова. Я понимал не только вопросы, но и шутки французов, и мои ответы вызывали положительную реакцию. Словом я был на высоте и у меня закралась маленькая надежда - что невозможное случиться и я поеду во Францию.
Чудо случилось и в сентябре 2004, на рейсовом автобусе ЕвроЛайн, я поехал в Париж.
Поэтому дерзайте, верьте в свои силы и все у Вас получиться! Удачи!
Оставляйте ваши комментарии и фидбек в Disсqus. Буду помогать по мере возможности.
]]>And I would like to start this blog by describing when and how the idea to built my own company appeared.
So in hot summer 2015, somewhere in Ukrainian steps between Kiev and Dnipropetrovsk, the idea to launch a software company was born. It took several months to actually start the company development from the ground.
After working for a while as employee for big and small software companies and taking different responsibilities, I accumulated enough knowledge to make a step forward, take some risk and start my own business.
Being a software engineer, I’m passionated by the opportunity to discover and learn something new, especially in technical field. Our industry forces us to always learn and having few new books to read before going to sleep. Otherwise your knowledge will be outdated and you couldn’t reuse the best tools that others engineers invent to simplify various tasks. But I learned not only the low level programming stuff like how to debug the performance issue on a JVM in production, but I was interested a lot how to make the project from the business perspective: