Дмитрий Энтелис

Мы постоянно задаём такие вопросы и все отвечают, не припомню что бы кто-то не ответил. Тогда сразу открывается возможность для разговора о причинах смены работы:

1. Получал меньше хочет больше - всё понятно, давайте только обсудим на сколько больше вам хотелось бы получать?
2. Получал столько же сколько указано в вакансии на этой работе - причина смена места работы не в деньгах, тоже обсуждаем что не нравилось (в уме прикидываем как сделать что бы человеку всё нравилось)
3. Получал больше идёт на меньшую - и такое бывает. Жизненные обстоятельства (работа нужна срочно), сферу деятельности человек меняет.

Если бы мне человек не сказал доход с предыдущего места работы, ну не сказал и ладно, но для себя я галочку поставил бы что закрытый, опасливый человек, мы таких не любим )))

В вакансии у нас указана реальная вилка ЗП и от того сколько человек получал на предыдущем месте ни эта вилка, ни условия не изменятся. Девушка однажды пришла на собеседование так же на 25-30, сказала на предыдущем месте работы 200 получала, на джипе приехала ))

У нас люди приходят на собеседование и свободно говорят что у меня есть сейчас сторонний доход 35 например и у вас я планирую работать на 28, т.е. мы чётко понимаем что на стороне человек будет зарабатывать больше чем у нас, но он нам нравится то мы всё равно берём его.

турникеты не нужны? ну тогда тетрадочку в клетку на 48 листов, туда аккуратными буковками вписывать паспортные данные тех, кому можно, а потом им на лоб ставить штамп. Если у кого в салоне нет штампа на лбу, побить и выгнать!
Начнем с определения условий решения задачи, можно ведь нанять армию Лихтенштейна, которая будет сторожить автобусы, но уверен у вас найдутся причины отказаться от такой затеи.
1. Какова стоимость разработки системы? Что-то готовое - около нуля, свое мудрить - от нуля и до бесконечности.
2. Сколько эта система может стоить? Турникеты дорого, а тетрадка со штампом не удовлетворяет каким-то условиям. Тоже надо найти компромисс
3. Стоимость эксплуатации системы. Можно тратить по триллиону в месяц, из них 40к кондуктору, остальное на премию, а можно закупить турникеты, которые придется обслуживать раз в n времени
4. Спец. требования? Простота - эт понятно. Защищенность на каком уровне должна быть? печатать проездные на месяц на листочках - довольно недорого, но так может каждый, даже работник организации В.
Помимо того, надо понимать как происходит процесс погрузки и разгрузки, какие условия работы.. Например, загружая людей через переднюю дверь, закрыв остальные, можно будет возложить обязанности вышибалы-билетера на водителя. Тогда вам нужны или электронные пропуска и считыватели соответственно, или обычные пропуска, но со списком или обновляемые каждый месяц к примеру.
Я почему-то ратую за электронные пропуска хотя бы на основе nfc меток. Тогда в качестве считывателя подойдут спец.смартфоны со спец.программкой, выдаваемые водителям. Но для защиты от их копирования, спец. программа должна будет как минимум считывать код и определять клиента, перезаписывать на нфц метку новый код, по которому однозначно можно определить этого самого клиента, деактивировать старый и синхронизировать все это с сервером. Все это выльется в некоторую стоимость разработки ПО, закупки устройств и ежемесячное обслуживание(интернет для смартов, содержание сервера), но позволит быть уверенным, что ни один работник категории В не проникнет в автобус, а также обеспечит хорошую гибкость. Возможно дешевле будет использовать уже готовую систему пропусков, не создавая новый велосипед.
QR коды - дешево в использовании, но никакой защиты и удобства. Потерять бумажку легко, а для защиты придется каждый раз генерировать новые билетики и отдавать их работникам категории А и Б.
Еще неплохой вариант - рассылка смс с индивидуальными кодами. Смартфоны несмотря на 2016 есть не у всех, но вот телефоны то точно есть. При этом эти коды могут быть одноразовыми, что не позволит их просто отдавать друзьям категории В, которые тоже хотят кататься. Но и тут удобство не на первом месте - телефон может разрядиться или потеряться.

Вы хотите и рыбку съесть и косточкой не подавиться...
Как вы представляете при отсутствии турникетов ограничить проход человека в салон автобуса?
Разве что биты водителям раздать?
Тут тогда вообще нужна гуашь чтобы сделать пропуска разных цветов (цвет для А, для Б и для В) и что бы водитель видя пропуск другого цвета сразу в жбан битой бил...
Дешево и сердито выйдет.

Зачем нужен readonly, когда есть disabled..?

А вообще, вот (в зеленой плашке):

The difference between disabled and readonly is that read-only controls are still focusable, so the user can still select the text and interact with it, whereas disabled controls are entirely non-interactive. (For this reason, only text controls can be made read-only: it wouldn't make sense for checkboxes or buttons, for instances.)

tcpdf - альтернатива mpdf
phantomjs - скриншот в pdf

думаю, там опционы и вестинг, а не "доля акций"

в таком раскладе резиденту РФ владеть можно сколько угодно и в ус в РФ не дуть (дуть в США, чтобы не напарили, читать внимательно договор)

как только опционы превратятся в акции - дуть в обратном порядке (и да, в США могут откусить до 30% живых денег если все по честному)

но обычно проще вспомнить вот это и брать деньгами, а не опционами

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

А остальное проверяется на испытательном сроке. :)
Скорее всего наличие открытого кода это требование ведушего проекта чтобы не тратить время на многочасовые собеседования и тестирования.

PS.
HR никода не спрашивали меня про публичные репозитории. Но последнее время профиль в LinkedIN разрывается от предложений с астрономическими зарплатами. Наверняка врут. :) Хотят узнать где мои репозитории.

отвечал, мол, благотворительностью не занимаюсь.

Дело не в благотворительности, а в том, чтобы у вас уже был реализованный потенциал!
Если у вас не будет ни одного репозитория, но зато будет успешный стартап, пусть даже небольшой, но приносящий хотя бы тысяч 5-10 в месяц, и еще и интересный технологически, или например будет приложение в Google Play или расширение в Chrome Webstore, проприетарное и продаваемое за деньги, и при этом реально покупаемое хоть иногда, то для адекватного работодателя все это даже лучше, чем репозиторий аналогичной популярности.

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

Если не секрет, то как после этого ответа протекало собеседование?))

Ответ желательно не менять ни в коем случае, он характеризует Вас как специалиста исчерпывающе.

отвечал, мол, благотворительностью не занимаюсь

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

Начиная от паяльника в одно место, до исков стоимостью в несколько миллиардов

Почему люди уходят на чужой клиент? Чем он лучше? Изучи, подлатай свой.

Если не можешь сделать лучше, а приложение пользуется таким спросом, что появляется много сторонних клиентов, это можно даже монетизировать, сделав отдельный девелоперский API с авторизацией и предоставляя его для авторов сторонних клиентов за определенный $$. Этот способ нам в свое время оказался более удобным, чем активно развивать свой клиент.
Тем более, что крупные разработчики будут с тобой сотрудничать, и стараться соблюдать договоренность по искользованию API, а мелким делать в обычном API делать подлянки, они устанут и выйдут из конкурса.

Дело в том что это не native, а сделанное через одно место портирование браузерного языка на мобильные платформы. Если используете JS, то не стоит ожидать чего то сверестественного и нормально работающего, тем более при 60 FPS.
Да и тем более 4 ядра на телефоне != 4 ядрам на ПК. Производительности телефона не хватит запустить что либо более менее ощутимое по нагрузке.

Исходя из вашего вопроса - "деплой" это разворот сервера с нуля до рабочего состояния.

Все зависит от количества деплоев:
1. Если вам достаточно задеплоить 1 сервак и забыть про него - проще поднять руками.
2. Если вы постоянно разворачиваете > 2 серваков - однозначно надо использовать автоматизированные инструменты.

Рассмотрим несколько популярных инструментов:
1. Ansible - на мой взгляд самый удобный инструмент для быстрой и удобноый работы с парком серверов, устанавливает весь софт и настройки на вашей VPS.
2. Docker - позволяет создать на вашей VPS еще одну виртуальную машину с заранее прописанными настройками и софтом, также его иногда используют для параллельного запуска нескольких БД / веб - серверов и т.д.
3. Также есть Puppet, Chef, Salt - ими не пользовался.

Рассмотрим другое толкование слова "деплой" - заливка изменений проекта на сервер, который находится в рабочем состоянии (т.е. имеется уже рабочий проект)

Тут все зависит от размеров проекта:
1. Если проект маленький / средний fabric вполне справляется с такими задачами, как подтянуть изменения из репозитория / собрать статику / перезагрузить nginx и т.д., но использовать его для разворота сервера - это тяжелая работа, которую проще делать с помощью других инструментов (описано выше). Сам я тоже использую fabric для обновления прода.
2. Если проект большой и приближается к хайлоаду - то надо использовать Continuous Integration, это позволит вам сделать автоматизированную выкладку кода на боевой сервер - к примеру, пушите коммиты в репозиторий на github, срабатывает хук, начинает работать Jenkins, идет прогон тестов, при успехе тестов обновляется прод.

Инструментов для CI много:
1. Jenkins - простой и бесплатный, с кучей расширений и прочих плюшек.
2. Travis-CI - бесплатный для опен сорс, платный для приватных проектов (69$ минимальный план).
3. Buildbot, tox - не использовал.

P.S. Я думаю, что понятие "деплой" - это выкладка изменений на боевой сервер. То, что делаете вы - создаете новый сервер, разворачиваете окружение - ближе к развороту сервера. Если так делается каждый раз, когда льются изменения на боевой сервак - надо менять workflow.

Нет.
SSL даёт доверие, но не гарантирует защиту! (хотя, говорят всем иное...)
Явное отсутствие SSL - это конечно же только ВИДИМЫЙ недостаток для пользователей.
Данные могут шифроваться и без SSL и, также, могут быть переданы 3-им лицам после прохождения внутри SSL (или где-то на пути).
Кратко: не вводите ФИО нигде, если есть хотя бы малая доля недоверия к сервису.
(а ФЗ № 152 - здесь ни при чём)

ФЗ-152 признаёт весьма ограниченный круг средств защиты. Если Вы используете SSL от "неправильного" центра - с точки зрения ФЗ Вы также не выполняете требования.
Однако, на практике любые объективные шаги с защите ПДн - есть хорошо.

Если решать в общем виде, не привязываясь к движку:
Под каждую новостную категорию завести автоматически генерируемый xml, например, rss.
А второй сайт с нужным периодом парсит эти ленты и импортит себе в базу.

Возможо, в Битриксе есть какие-то готовые инструменты, но это пусть знатоки данной cms выскажутся

Чем смотриться расход ОЗУ? Как работает PHP (через php-fpm? как модуль apache? из командной строки?). 20МБ ОЗУ уходит на сам PHP интерпретатор. Это нормально.