Резюме — это первое впечатление, которое работодатель получает о вас, поэтому важно уделить достаточно времени и внимания его составлению. Важно знать, какие элементы необходимо включить в резюме, чтобы выделиться среди других кандидатов, и, конечно же, учесть особенности написания резюме учитывая свой опыт.

Структура резюме

Обычно резюме состоит из следующих основных элементов:

1. Контактная информация: ваше ФИО, адрес, номер телефона, адрес электронной почты (обязательно поднимите этот блок на самый верх)

2. Желаемая позиция: сформулируйте на какую позицию вы подаете резюме, лично я рекомендую корректировать этот заголовок под каждую конкретную организацию, куда вы подаетесь, исходя из размещенных ей позиций (можно просто взять название вакансии).

2. Профессиональная цель/краткое резюме: здесь вы указываете на вашу цель и основные навыки, которые вы хотите продемонстрировать работодателю. Этот элемент особенно важен для молодого специалиста, поскольку у него еще не так много опыта работы. Только не лейте воды, лейте ключевые слова

3. Образование: перечислите все образовательные учреждения, в которых вы учились, начиная с самого последнего.

4. Опыт работы: перечислите все места работы, начав с последнего. Укажите название компании, должность и сроки работы.

5. Навыки и качества: здесь вы перечисляете свои ключевые навыки, релевантные для должности, на которую претендуете.

6. Дополнительная информация: в этом разделе можно указать любую дополнительную информацию, которая может быть полезна работодателю, например, знание иностранных языков, сертификаты, участие в профессиональных сообществах, проекты или достижения.

Ну и конечно, пишите резюме на том языке, на котором его будут читать. Использование англоязычных заголовков не добавляет веса резюме в РФ и уж тем более на пользу не работает обратная история.

Отличия между резюме начинающего специалиста и опытного инженера

Резюме молодого специалиста и опытного работника имеют свои особенности. Акцентируем на них внимание:

1. Образование: для молодого специалиста образование является ключевым элементом резюме, так как у него еще мало или нет опыта работы. Опытный работник, напротив, может уделить больше внимания своему опыту работы и достижениям, что может занимать более значимую часть резюме. Для молодых специалистов этот раздел может быть довольно объемным, поскольку чаще всего у них есть только образование без опыта работы. Для специалистов с опытом этот раздел можно убрать в самый конец резюме и особо не расписывать его.

2. Опыт работы: молодой специалист может упомянуть стажировки, фриланс-проекты или волонтерскую деятельность, чтобы показать свои навыки и опыт работы. Опытный работник, в свою очередь, подразумевает достаточно подробное описание своего опыта работы с разделением на обязанности, достижения и результаты. Старайтесь в описание упоминать названия конкретных технологий, с которыми вы работаете и которые необходимы организации, в которую вы подаете резюме.

3. Навыки и качества: начинающий специалист может выделить свои базовые навыки и знания, полученные в процессе обучения, можно креативно визуализировать их, но все равно желательно упоминать их в контексте проектов и работ, которые вы указали, рассказывая о своем опыте. Опытный соискатель может подчеркнуть свои продвинутые навыки и специализацию в определенной области, я бы предложил разместить этот раздел даже выше, над описанием опыта.

В заключении, хочу отметить, что резюме — это важный инструмент продажи вас как специалиста, считайте, что это витрина и если она не привлекает целевую аудиторию, то возможно ваше резюме просто пролетит мимо HR напрямую в корзину. Нужно учитывать свои особенности и особенности организации, в которую вы подаете резюме. Да, возможно некоторые вещи стоит корректировать, некоторые должны оставаться постоянными, но перед отправкой резюме стоит сфокусироваться на описании позиции и проверить себя, достаточно ли в вашем резюме раскрываются те аспекты, которые озвучены в вакансии, насколько вы, исходя из вашего резюме, соответствуете ожиданиям. Важно чтобы информация была конкретной, лаконичной и релевантной для позиции, на которую претендуете.

Первое что я заметил, это WordPress, а именно на нем работает сайт сейчас, отлично отвечает и на http и на https, но никаких предпочтений не имеет. Заходишь себе по http, ну и сиди так.

Первым делом конечно пришло поискать ресурсы на WordPress, а там предлагаются плагины различного рода, чтобы переключаться, перенаправлять и т.п.

Но это мне показалось как-то странно.

В общем, все просто. Дело решается добавлением пары строк в файл .htaccess:

php_flag display_errors on
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{ENV:HTTPS} !=on
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

А чтобы не чувствовать себя персонажем из примеров Хайпа, рекомендую ознакомиться с простенькой документацией по .htaccess.

Теперь если вы попробуете открыть скажем такой адрес http://pelevin.pro/2016/12/07/forcehttps/ веб-сервер все равно направит вас на секьюрный https://pelevin.pro/2016/12/07/forcehttps/.

Перевод одноименной статьи Marek Kirejczyk из daftcode.pl.

Команды разработчиков программного обеспечения часто принимают решения о программной архитектуре или базовом технологическом стеке на основе спорных мнений из социальных медиа, да и в целом выбирая то, что считается «горяченьким», вместо того, чтобы провести скрупулезное исследование и серьезно рассмотреть возможный эффект от их применения на своих проектах. Я называю эту тенденцию Hype Driven Development (прим. разработка управляемая беззастенчивой рекламой или обманом, но обман… в общем я склонен считать что хайп это хайп, но в переводе иногда буду использовать другие слова), считаю ее вредной и выступаю за более профессиональный подход, который называю «Solid Software Enginering». Приглашаю узнать больше о том, как это работает, и выяснить, что можно сделать вместо этого [HDD].

Новая технология — новая надежда

Сталкивались с этим? Команда выбирает новейшие, самые горячие технологии, чтобы использовать их в своем проекте. Кто-то читает сообщения в блогах, кто-то видит в трендах на Twitter, а еще мы только что вернулись с конференции, на которой много говорили о новой технологии. Вскоре после того, как команда начинает использовать эту восхитительную новейшую технологию, можно наблюдать неожиданный эффект. Вместо того, чтобы решать задачи быстрее (как и обещалось) и создавать более совершенный продукт они сталкиваются с проблемами. Они замедляются, теряют мотивацию. Возникают новые проблемы, которые делают сложным или невозможным поставку следующей версии. Некоторые команды продолжают исправлять ошибки, вместо того, чтобы работать над новыми возможностями. Им нужно «просто еще несколько дней», чтобы все разобрать.

Hype Driven Development

Hype Driven Development (HDD) имеет множество оттенков и может коснуться вашего проекта по-разному:

Reddit Driven Development — когда команда или кто-то конкретный принимает решение по технологии / архитектуре / дизайну, основываясь на том, что об этом написал популярный блоггер, или это очень жарко обсуждается на Reddit, hackernews, Twitter, facebook, GitHub или других социальных медиа.

Conference Driven Development — присмотритесь к тому, что происходит после того, как люди вернулись с конференции. Люди вдохновляются. И это палка о двух концах. Переходя на новейшие «горячие» библиотеки/фреймворки/архитектурные парадигмы без должного их исследования можно попасть прямиком на шоссе из песни AC/DC (прим. Highway to hell).

Хотя зачастую можно встретить и обратный вариант, когда люди много ходят на различные курсы, тренинги и прочее, но в итоге не используют ничего… по этому поводу мне нравится следующее изображение.

Loudest guy driven decisions —  это когда у нас есть один парень, который все время говорит об этой клевой новой штуке, в которой у него нет никакого опыта, но говорит он безостановочно и в итоге команда принимает решение использовать её.

Gem/lib/plugin driven development —  особенно сильна в комьюнити Ruby On Rails, где время от времени я могу встретить такой длинный Gemfile, что длиннее будет только загрузка приложения. Это явление происходит от идем о том, что каждая проблема в Rail должна быть решена с помощью gem’а. Иногда самостоятельное решение стоило бы всего нескольких строк кода. Но мы просто решаем проблемы добавлением библиотек, плагинов, гемов или фреймфорков.

Что-то похожее встречается при работе со сборщиками в «новых» концепциях asp.net и т.п. В общем подобную историю можно встретить довольно часто, а временами, кроме прочего еще и наткнуться на Dependency Hell, в общем путей в ад много.

И, пожалуй, я хотел бы упомянуть здесь поведение, популярное среди HDD-разработчиков —  Stack Overflow driven development  —  когда разработчики копипастят решения со Stackoverflow (или в принципе откуда-то с просторов интернета) без реального понимания их сути.

HDD это о том, как команды несут погибель сами себе

Проблема хайпа в том, что он легко приводит к неверным решениям. Плохие архитектурные решения или неудачный выбор технологического стека зачастую преследуют команду месяцами или даже годами. А в самом худшем случае они могут привести к другой весьма проблематичной ситуации: The Big Rewrite. Что практически никогда не помогает.

Корнем всех зол, видятся, социальные медиа — где новые идеи распространяются гораздо быстрее, чем они тестируются и гораздо быстрее, чем люди в состоянии оценить их плюсы и минусы.

Анатомия обмана

Большая часть хайпа имеет сходую структуру. Она на картинке:

Шаг 1: Реальная проблема и решение

Все начинается в какой-то компании с проблемой. Команда этой компании решает, что технологическое решение проблемы выходит за рамки текущего стека, процесса или архитектуры. Команда создает новые фреймворки, библиотеки или парадигмы, и вскоре проблема решена.

Шаг 2: Презентация, шумиха и «ключевые слова»

Команда воодушевлена и готова продемонстрировать свою работу всему миру. Вскоре пишется сообщение в блоге и начинаются выступления на конференциях. Проблема часто является нетривиальной, поэтому команда с гордостью представляет свои впечатляющие результаты нетривиального решения. Люди заинтересованы новой технологией. Единственная проблема, не каждый заинтересованный способен в полной мере понять какая именно проблема была решена и тем более все детали ее решения, но все слышат ключевые слова в сообщении. В конце-концов это было нетривиальным решением нетривиальной задачи, объяснение которого требует больше, чем твит, сообщение в блоге или чат. И, вот, проходя долгий путь из различных средств коммуникаций: социальных медиа, сообщений в блогах, твитов, конференции и быстрых переговоров основной посыл размывается.

Шаг 3: Мания

В ход идут все формы HDD: чтение блогов, посещение конференций. Вскоре команды по всему миру начинают изучать новую технологию. Из-за размытости посыла некоторые из них делают поспешное решение использовать фреймворк, даже если он в действительности не решает актуальные для них проблемы. Тем не менее у команды есть надежда, что новая технология все таки им поможет.

прим. Я лично неоднократно сталкивался с подобным. А вы?

Шаг 4: Разочарование

По мере того как спринты (прим. речь идет о кратких временных интервалах планирования в рамках гибких подходов в разработке ПО) идут, приходит понимание, что технология не улучшает жизнь команды настолько, насколько ожидалось, зато добавляет много дополнительной работы. Очень много кода, который требуется переписать, и дополнительного обучения для команды. Команда замедляется, менеджмент злится, все чувствуют себя обманутыми.

Шаг 5: Осознание!

Наконец, команда делает ретроспективу и понимает, что именно несет новая технология и с какой целью ее использование было бы более уместным. Они становятся мудрее … ну, по крайней мере до следующего хайпа. ^_^

Примеры хайпов:

Давайте исследуем некоторые примеры хайпов и посмотрим как это было.

Пример 1: React.js

Шаг 1: У Facebook была проблема — сложные одностраничные веб-приложения, каким является Facebook, имеют множество различных событий изменяющих состояние в следствии чего становится сложно отслеживать происходящее и последовательно изменять состояние.

Шаг 2: Facebook представил новую парадигму с шумихой вокруг ключевых слов: functional, virtual DOM, components.

Шаг 3: Мания: Facebook создал фреймворк переднего-конца будущего (прим. простите, «front-end framework»)! Давайте всё писать на React!

Шаг 4: Погодите ка, работы много, но возврат инвестиций совсем не быстрый.

Шаг 5: React отлично подходит для продвинутых одностраничных приложений с большим количеством изменений/уведомлений в режиме реального времени странице, но не обязательно окупится для простых приложений.

Пример 2: TDD мертв благодаря DHH

Шаг 1: David Heinemeier Hansson (DHH, создатель фремворка Ruby on Rails)  осознает что трудно использовать TDD с Rails поскольку этот фреймворк не поддерживает в должной мере OOP. Делает прагматичный выбор — не писать тестов заранее.

Шаг 2: Хайп начинается с сообщения в блоге DHH blog post и разговора на конференции conference talk. Ключевые слова: TDD мертв.

Шаг 3: Давайте пропустим тесты. Наш Гуру так сказал. Мы все равно их не писали, теперь мы по крайней мере не делаем вид, мы наконец-то честны.

Шаг 4: Подождите! Намного меньше вещей стало работать по сравнению с тем что было раньше. Мы написали какой-то очень глючный код!

Шаг 5: “TDD не жив или мертв. TDD зависит от принимаемых компромиссов, например риск изменения API, навыки участников и существующий дизайн” — Кент Бек.

Пример 3: Микросервисы

Шаг 1: Большие монолитные приложение сложно масштабируемы. Вот почему наступает момент когда мы разбиваем их на сервисы. Так будет легче масштабировать с точки зрения количества запросов в секунду и разделения зоны ответственности между несколькими командами.

Шаг 2: Ключевые слова: масштабируемость, слабосвязность, монолит.

Шаг 3: Давайте перепишем все на сервисы! У нас тут «спагетти код» потому что у нас монолитная архитектура! Мы должны переписать все на микросервисы!

Шаг 4: Дерьмо! Теперь мы разрабатываем медленнее, у нас сложности с развертыванием и мы тратим массу времени на отслеживание багов между несколькими системами.

Шаг 5: Микросервисы требуют серьезных навыков DevOps у команды и с правильными подходом могут окупиться как вариант масштабирования система и команды. Пока вас не коснулись серьезные проблемы масштабируемости использовать такой подход — лишние издержки. Микросервисы извлекаются, а не пишутся.

Пример 4: NoSQL

Шаг 1: SQL базы данных имеют большие проблемы с высокой загрузкой и неструктурированными данными. Команды по всему миру начинают разрабатывать новое поколение баз данных.

Шаг 2: Ключевые слова: масштабируемость, BigData, высокая производительность.

Шаг 3: Наши базы данных слишком медленным и не недостаточно вместительны! Нам нужен NoSql!

Шаг 4: Нам нужно связать таблицы? Ну нет. Простые SQL операции становятся все более сложными. Разработка замедляется, а ключевые проблемы так и не решены.

Шаг 5: NoSql это иструмент для решения очень специфичных проблем (чрезвычайно большие объемы данных, неструктурированные данные или очень высокая нагрузка). SQL на самом деле является отличным инструментом и справляется с высокой нагрузкой и огромными объемам данных, если его использовать с умом. Варианты для NoSQL по прежнему крайне редки в 2016 году.

Пример 5: Elixir and Phoenix (или поставьте сюда пару своих любимых языков/фреймворков)

Шаг 1: Веб-фреймворки типа Ruby On Rails плохо справляются в случаях когда нужно иметь дело с высоконагруженными приложениями, распределенными приложениями или веб-сокетами.

Шаг 2: Ключевые слова: масштабирумость, высоконагруженные, распределенные, отказоустойчивость.

Шаг 3: О, мой хороший, (прим. я почти уверен, что у автора опечатки и он имел ввиду О боже мой!) наше приложение медленное и наш чат не масштабируется!

Шаг 4: Ничего себе, изучение функционального программирования и распределенного подхода не так просто. Мы двигаемся очень медленно.

Шаг 5: Эликсир и Феникс великолепные фреймворки, но требует значительных усилий на изучение. Они окупаются в долгосрочной перспективе, если вам нужно дейтвительно специфическое высоконагруженное приложение.

Можно продолжать и продолжать:

В JavaScript новые фреймворки рождаются каждый день. Node.js (ключевые слова: программирование событий), реактивное программирование, Meteor.js (ключевые слова: shared state), передний конец MVC, React.js. В программной инженерии рождаются новые архитектуры: Domain Driven Development, Hexagon, DCI. А какой хайп предпочитаете вы?

Хорошие практики

Итак, если не стоит полагаться на мнения высказанные другими людьми в интернетах, то как принять разумное решение? Здесь несколько хороших практик:

Тестируй и исследуй до принятия решения:

• Spikes  — узнавайте интересующую вас технологию не из блогов, а лично, на своем опыте. Возьмите пару дней, чтобы создать прототип новой функциональности в новой технологии, прежде чем принять решение. Пусть команда проанализирует плюсы и минусы. Возьмите несколько конкурирующих технологий и пусть разные части команды создают свои прототипы.
• Hackathon — отличный способ для повышения уровня информированности команды о разных технологиях. Выберите пару дней для всей команды, чтобы пощупать все технологии, которые находятся на подъеме и заманчиво выглядят для использования. Это позволит членам команды сделать своё осознанное решение.

Когда?

• В принципе, когда ожидается значительная отдача от инвестиций. Большинство технологий создаются для решения конкретной задачи. Есть ли проблема? Это большая проблема? Будет ли сэкономлено много времени? Окупится ли использование новой технологии с учетом входа в нее и переписывания кода? Что делать, если мы изначально замедлились в два раза? А если четыре? Является ли она по-прежнему стоящей?
• Великим командам разрешено больше — некоторые команды просто быстрее чем другие приносят ценность. Им становится скучно с тем, что им дается очень легко. Эти команды могут внедрять новые технологии все чаще. Это не повод, чтобы не использовать Spikes и не делать Хакатоны. С другой стороны, если у команды есть проблемы  — действовать с осторожностью.

Нанимайте на работу правильных людей:

• Сильный технический бэкграунд это ваш друг  — люди знающие различные парадигмы, понимающие теорию программирования (алгоритмы, параллелизм)  и имеющие хорошую инженерную культуру, как правило, меньше подвержены хайпу.
• Опыт —  хайп сильнее у молодых разработчиков. С годами, люди, видевшие много технологий и сталкивавшиеся с трудностями много раз более рассудительно подходят к выбору технологий.Ну и конечно, ссылка на первоисточник для страждущих оригинал.

Взгляд разработчика, который бился головой, потом снова бился головой, потом придумал как круто не биться головой, а потом посмотрел то, что люди давно придумали, чтобы не биться головой, и в общем-то оказалось пришли мы к одному и тому же.

В качестве исторической справки отмечу, что git это распределенная система управления версиями, а была она изначально создана ни кем иным, как самим Линусом Торвальдсом (по ссылке можно посмотреть как старина Торвальдс фигачит код в ядро, как видно понедельники самые продуктивные дни Линуса) с целью управления разработкой ядра Linux и произошло это в уже не близком 2005 году.

Хватит лирики

В общем-то давайте к практике.

.gitignore

Git по умолчанию пытается отслеживать все файлы появляющиеся в папке (и подпапках) репозитория. Очевидно, что нет никакого смысла складывать в Git библиотеки, которые вероятно вы подтягиваете каким-нибудь менеджером пакетов или например всяческие obj, bin и прочие директории и файлы которые внезапно возникают вокруг вашего кода, но для самого кода ценности никакой не несут.

Именно для таких файлов существует такая штука как .gitignore, позволяющая объяснить git’у, что именно не нужно отслеживать. И, например, ваши Gui сразу же перестанут предлагать вам включить ненужные файлы в индекс, если вы пользуетесь не чистой консолью.

Типичные файлы .gitignore в зависимости от языка или среды разработки вы сможете найти на GitHub в соответствующем проекте.

Git Flow

«Си» позволяет очень просто выстрелить себе в ногу. На «Си++» сделать это сложнее, но, когда вам это удается, ногу отрывает полностью.

Bjarne Stroustrup

Фраза отца С++ в мире разработки характеризует многое. Собственно git это такая штука, которой стрелять в ногу можно  бесконечно огромным количеством способом, зависящим в основном от вашей фантазии и психических отклонений.

Но умные люди в принципе уже придумали и описали наиболее типичные и простые в использовании с точки зрения владения кодом и управления способы.

Если кратко, то зовется это все Git Flow, и описано множество раз на просторах безграничного интернета.

Git-flow — это набор расширений git предоставляющий высокоуровневые операции над репозиторием для поддержки модели ветвления Vincent Driessen.

Установка Git flow

Для начала нужно иметь установленный git;

Если с Git все хорошо, то в зависимости от используемой операционной системы можно использовать следующие способы установить git flow.

OS X — Homebrew

$ brew install git-flow

OS X — Macports

$ port install git-flow

Linux

$ apt-get install git-flow

Windows

Все сложно

Windows SourceTree

Данный клиент поддерживает Git Flow и позволяет весьма просто управлять им из Gui-интерфейса «из коробки».

Начало работы

Для начала git flow необходимо инициализировать, настроить его для работы с конкретным проектом, причем это нужно объяснить вашему локальному git, поэтому подобные махинации необходимо повторить на каждой машине разработчика (поправьте меня, если я не прав).

В общем для инициализации нужно использовать команду

git flow init

В случае использования SourceTree все можно сделать из интерфейса (больше не буду отдельно упоминать SourceTree, по ссылке все достаточно подробно и полно).

Feature

Как правило ветки Feature нужны только в репозиториях разработчиков, в них ведется разработка новшеств для последующих релизов.

Ветка типа Feature создается из основной ветки разработки (по умолчанию develop).

git flow feature start featurename

В наименовании фичи можно исходить из потребностей конкретно вашего процесса разработки. Может быть вам будет удобно использовать какой-нибудь идентификатор пользовательской истории из вашего трекера, а может краткое текстовое название. В итоге вы получите такую ветку feature/featurename.

Когда работа над фичей завершена, результаты труда необходимо вернуть в исходную ветку разработки. По сути нужно выполнить следующие действия:

• Выполнить слияние ветки фичи в ветку разработки (feature/featurename в develop в моем примере).
• Переключиться обратно в ветку разработки.
• Удалить ветки фичи.

git flow feature finish featurename

Если работа над фичей идет совместно с коллегами — опубликуйте ёё на удаленном севере.

git glow feature publish featurename

Соответственно чтобы получить кем-то опубликованную фичу необходимо выполнить

git flow feature pull origin featurename

Можно отслеживать фичу в репозитории origin выполнив

git flow feature track featurename

Release

Ветка используется для подготовки нового релиза продукта. Используется как правило перед выпуском новой версии для устранения мелких недочетов, багов и стабилизации решения, а так же позволяет подготавливать различные метаданные для релиза.

Для начала релиза

git flow release

git flow release start RELEASE [BASE]

Где [BASE] вы можете указать при желании в виде sha-1 хеша коммита из которого нужно начать релиз. Этот коммит должен обязательно принадлежать ветки разработки.

Конечно же если вы работаете в команде, рекомендую сразу опубликовать ветку

git flow release publish RELEASE

И так же по аналогии для отслеживания нужно использовать

git flow release track RELEASE

Завершение релиза один из наиболее сложных и важных шагов всего процесса ветвления в ходе которого происходят следующие действия:

• Ветка релиза сливается в ветку мастер
• Рализ помечается тегом равным его имени
• Ветка рилаза сливается обратно в ветку разработки
• Ветка релиза удаляется

git flow release finish RELEASE

Чтобы опубликовать тэги

git push --tags

Исправления

Исправления нам необходимы в том случае, когда требуется срочное изменение состояния продакшн-версии разрабатываемого продукта. Как вы понимаете она у нас находится в ветке master и помечена тэгом версии, соответственно мы ветвим hotfix от тега на ветке мастер.

git flow hotfix start VERSION [BASENAME]

Version — определяет имя нового исправленного релиза.

[Basename] — не обязательный аргумент, указывающий на коммит, от которого произойдет ветвление.

Завершение исправления выглядит так:

git flow hotfix finish VERSION

В этот момент оно сливается в ветки develop и master, коммит в ветке master помечается тегом с версией исправления.

Резюме

Выше приведены не все возможности и не все команды git-flow, кроме того использовать git со всеми его командами возможно и далее, т.к. git flow это просто набор инструментов упрощающих ветвление.

На самом деле самое важное с фундаментальной точки зрения описано в самой модели ветвления, принципы которой можно использовать и не прибегая к помощи git-flow.

Думаю в ближайшее время подготовлю перевод этой статьи.

В прочем, я довольно активно пользуюсь сервисом. И вот на прошлой неделе столкнулся с интересной ситуацией. Вечером я оставил автомобиль недалеко от дома, а утром, когда решил им воспользоваться обнаружил, что им кто-то пользовался и поставил с другой стороны дороги и рядом с ним еще одно авто. В прочем это логично и так и должно быть.

Я забронировал автомобиль и пошел к нему. Прямо на той точке, где он отображался я его не увидел и нажал кнопку «подать звуковой сигнал», услышав откуда был гудок я пошел в ту сторону… как мне показалось…

В общем я нашел авто, почистил его, сфоткал, посмотрел документы (посмотрел, но не проверил соответствие номеров) и даже подписал акт приемки. А вот завести автомобиль не получилось. Ну я решив «ну нет дак нет», вышел из него и хотел было нажать кнопку завершения аренды, как понял, что у меня в приложении горит другой номер забранированного авто, хотя вроде как в этом месте.

В общем через пару минут я нашел авто на котором приехал вчера, там где его оставил. Вероятно из-за близости к зданию GPS немного сдвигал координаты в другую сторону. Я позвонил в сервис и сообщил, что чуть было не уехал на другом авто, которое по какой-то причине оказалось открыто.

Я доехал до того авто, еще раз проверил, сфоткал для информации и отправил на почтовый ящик, подтвердил оператору, что сейчас все двери закрыты и оператор перевел его в закрытое состояние еще раз. На этот  раз все двери закрылись. Оператор естественно поблагодарил за потраченное время и внимательность, но тут дело было как раз в моей невнимательности и воле случая…

В общем-то ничем не примечательная история, если только ты не занимаешься разработкой уже много лет.

Через пару дней мне в голову пришла идея, как могло случиться такое, что автомобиль в итоге оказался открыт.

Пару дней назад уже отправил это видео в сервис Делимобиля, надеюсь разработчики работают над усилением безопасности своих автомобилей.

P.S> Честно говоря я предполагаю, что какое-то время назад, разработчикам поставили задачу «сделать чтобы приложение в телефоне быстрее реагировало и отвечало на запросы» и они её успешно решили, в общем-то.

Сегодняшняя наша история будет о сервисе каршеринга, бурно развивающегося в Москве «Делимобиля».

Начну по порядку, начиная с момента регистрации в сервисе.

Регистрация

Регистрация начинается с заполнения простой формы расположенной здесь здесь.

1. Телефон (он же является потом логином, первый пароль придет вам сообщением после регистрации, но его можно сменить)
2. Ф.И.О. — ну естественно настоящие, ибо они будут в договоре
3. Email — пишут, пока только по делу
4. Кодовое слово — что-нить что не забудете, желательно
5. Промокод — если хотите получить в подарок 20 минут, просто напишите мой номер телефона в формате 7916691ХХХХ мои друзья, если вдруг не знают, могут увидеть мой телефон в профиле ВК, например, или спросить  .

Способ подписания договора выбирайте какой больше нравится. Я выбрал курьера, т.к. мне не особо хотелось кататься и  искать офис, хотя судя по карте их прилично. Это стоит порядка 300-400 рублей, и в качестве бонуса за лень часть вам компенсируют минутами.

Договор довольно простой, душу закладывать не просят. Курьер уведомляет и приезжает вовремя, по крайней мере мне звонили упорно, пока не дозвонились и не согласовали время.

В общем дальше шаги такие

Скиньте сканы документов, через сайт или через приложение на телефоне. Их довольно оперативно проверяют, готовят договор и отправляют к вам курьера для подписания.

Когда все готово, просто привязываете свою карту. Партнер у ребят Альфа-Банк, вроде как солиднейший банк у нас, все должно быть гладко.

Пока не выполните все три шага — в приложении будут автомобили, вы можете найти их в городе и потрогать, но покататься не дадут.

Кататься

Как только все готово, просто открываете приложение на телефоне и смотрите где на карте ближайшее авто. На моей практике ни разу не было, чтобы в радиусе 5-15 минут пешком не было хотя бы одной машины.

Выглядит примерно так:

В принципе в приложении есть инструкция, весьма понятная, как им пользоваться в картинках. Приведу её здесь.

Опыт

В общем немного о том, как и что на практике

1. Если Вы видите, что рядом есть машина, и даже если она стоит там уже несколько часов или дней — нажмите забронировать, а потом идите к ней. 20 минут ожидания бесплатные, в принципе дойти, если автомобиль в рамках пешей доступности более чем достаточно. Иначе может случится смешное, когда вы подходите к авто, смотрите какое оно красивое, жмете кнопку забронировать, а вам в ответ «автомобиль не свободен». Пам-пам.
2. GPS штука капризная, если добрый дядя (или тётя) запарковались за углом какой-нить большущей высотки, может оказаться, что GPS немного привирает. Ну на каких нибудь метров 50-100. В принципе кнопка «Поморгать» помогает, она очень громко бибикает и моргает.
   У меня к примеру было вот так
   Вот меня телефон видел довольно точно (синяя точка) и там на самом деле находилось авто.
3. Авто откроется когда нажмешь кнопку «Старт аренды» и будет 3 минуту, чтобы осмотреть все и согласиться с тем, что все в порядке и ты готов ехать или сказать, что с машиной что-то не в порядке. А закроется так же при нажатии кнопки в телефоне, предварительно проверив положение коробки, ручник, окна, двигатель и т.п. и если что-то не так, сообщит тебе.
4. Оно уведомляет вас по СМС.
   О том что заканчивается время бесплатного ожидания тоже уведомляет.
5. Кстати 252 рубля это в пробке не спешно от ул. Лесной (это между Белорусской и Новослободской) до ВДНХ в пробке с остановкой в магазине. Сказочно просто.
6. В автомобиле есть все (три) типа зарядок, но вот в моем она почему-то не работала. После остановки позвонил им и сообщил, мило побеседовали и зафиксировали. Надеюсь исправят и надеюсь это редкость.

В общем то-все. Можно разве что еще добавить, что ехать из центра в сторону ВДНХ, в час пик, на машине в которой сидишь впервые (я вообще в Solaris не ездил за рулем никогда, да все авто Solaris сейчас), после более чем 2 лет перерыва вождения в принципе… БОДРИТ!!! С учетом того что я в принципе не люблю ночью по незнакомым дорогам кататься, ибо и так дорогу не знаю.

Вот в общем в итоге вот, припарковал. Мне нравится, кстати, расцветка. Она довольно не броская и при этом стиль общественного транспорта ощутим.

В общем жалко только, что мне за этот пост денег не платили. А так бы подписал, что реклама.

используйте промокод на здоровье и водите аккуратнее (:

UPD: У некоторых товарищей после прочтения возникают вопросы (а у коллег айтишников возникает желание блеснуть профессиональным навыком видения проблем) и они задают вопросы. Я не ставил перед собой цели ответить на вопросы за представителей сервиса или рассказать о нем полную информацию. Ответы на многие вопросы можно найти на сайте в разделе FAQ.