Если у вас возникли вопросы по статье или что-то показалось спорным — пожалуйста, оставляйте свои комментарии, будем рады обсудить.
Спорного тут есть, давайте обсудим.
Навскидку — для горизонтального масштабирования схема неоптимальна. Если уж вы используйте VRRP, то для балансировщика проще прописать два VIP в DNS, каждый из keepalived будет одновременно работать и как MASTER и как BACKUP (зеркально). Если один из них упадет, его VIP переедет на соседний сервер. И не надо никаких дополнительных скриптов с пробросом портов.
Более подробно схема описана например тут.
Как короткое описание своего технологического стека c возможностью изучать тему «вглубь» по ссылкам — статья понравилась.
Немного критики. К сожалению, ряд моментов режет глаз.
Сравним с бекендом: MVC-фреймворк, ORM, Data Mapper, IOC-контейнер...
Почему MVC? Почему фреймворк? Почему ORM? И т.д. Это вовсе не необходимые компоненты бэкенда. Я бы назвал их «модными», но бэкенд может быть построен на совершенно других принципах. Кмк, такое сравнение тут не совсем к месту.
Самым монструозным из всех был конечно Smarty. Мне казалось, что люди сошли с ума. Как иначе можно было объяснить желание написать шаблонизатор… для шаблонизатора Perl?
Конечно же автор имеет в виду php, а не perl. Фраза о «шаблонизаторе для шаблонизатора» тоже модная, но слишком часто используется не в тему.
Давайте поясню. В статье $folder — переменная. Каким образом ей присвоили значение — совершенно неважно, важно то, что в примере она используется с ошибкой. Я тупо взял пример из статьи, без всяких «если» :)
Это перевод, конечно, но из той серии, которую переводить лучше не стоит. Автор вообще сам себе противоречит, сначала пишет, что в названиях файлов/директорий могут быть пробелы, а потом что-то типа:
Нет ли смысла в данном случае предусмотреть в том числе сохранение данных в SessionStorage?
Нет, автор статьи сделал серверное решение, оно абсолютно прозрачно для клиента. Использование интерфейса Storage предполагает какую-то дополнительную логику на стороне клиента, а это из другой оперы.
Неправильное они время выбрали для анонса. Хотя он написан вчера, 31го, но читать то его будут сегодня.
Ну написали бы завтра, что ли… Сидишь и голову ломаешь — то ли правда, то ли развод. Вроде по тексту все логично, хотя…
Примеры тестовых заданий, которые вы привели, действительно — очень странные.
Я обычно даю соискателям совсем простые задания, которые даже не выглядят чем-то законченным.
При этом меня интересует в основном ход мысли и особенности реализации — этого вполне достаточно.
если вы хоть когда-то делали одноцветные иконки в своем проекте, желаю вам адского пламени погорячее.
Что-то модно стало на Хабре желать кому-нибудь в аду гореть. Еще более модно только вспоминать, какой сейчас год на дворе.
Вы не допускаете мысли, что в каких-то проектах или местах проекта одноцветные иконки — к месту?
И самое главное, автор описал определенный технологический процесс. К дизайну его статья имеет отношение весьма отдаленное, а можно сказать, что даже никакого. Так что непонятно, к чему этот крик души.
Нет, даже в рабочее время «закрой статью» не будет, именно так. Если возникает проблема с сотрудником, то это или профессиональное несоответствие или несоблюдение сроков разработки (программирование). Причина этой проблемы никого не волнут. Какая разница Хабр это, соцсети или водка — не в детском саду.
В нашей компании просто не придают этому значения.
Неважно, куда человек пишет, что он читает и когда он это делает. Есть профессиональные требования. Если специалист им соответствует, то все в порядке.
Есть там ssh tunnel конечно же. Только интуитивно непонятно, что при использовании мастера подключений этот вопрос по моему 3-м шагом идет (если мне память не изменяет). По крайней мере для драйвера mysql.
Спорного тут есть, давайте обсудим.
Навскидку — для горизонтального масштабирования схема неоптимальна. Если уж вы используйте VRRP, то для балансировщика проще прописать два VIP в DNS, каждый из keepalived будет одновременно работать и как MASTER и как BACKUP (зеркально). Если один из них упадет, его VIP переедет на соседний сервер. И не надо никаких дополнительных скриптов с пробросом портов.
Более подробно схема описана например тут.
Исправление… Понял о чем вы, о первом наборе скриптов на perl.
Немного критики. К сожалению, ряд моментов режет глаз.
Почему MVC? Почему фреймворк? Почему ORM? И т.д. Это вовсе не необходимые компоненты бэкенда. Я бы назвал их «модными», но бэкенд может быть построен на совершенно других принципах. Кмк, такое сравнение тут не совсем к месту.
Конечно же автор имеет в виду php, а не perl. Фраза о «шаблонизаторе для шаблонизатора» тоже модная, но слишком часто используется не в тему.
Для загрузки файла вполне достаточно.
ОriginatorOrganizer… Оlder :)Ну написали бы завтра, что ли… Сидишь и голову ломаешь — то ли правда, то ли развод. Вроде по тексту все логично, хотя…
Я обычно даю соискателям совсем простые задания, которые даже не выглядят чем-то законченным.
При этом меня интересует в основном ход мысли и особенности реализации — этого вполне достаточно.
Вы не допускаете мысли, что в каких-то проектах или местах проекта одноцветные иконки — к месту?
И самое главное, автор описал определенный технологический процесс. К дизайну его статья имеет отношение весьма отдаленное, а можно сказать, что даже никакого. Так что непонятно, к чему этот крик души.
Неважно, куда человек пишет, что он читает и когда он это делает. Есть профессиональные требования. Если специалист им соответствует, то все в порядке.