Pull to refresh
4
0

System Administrator, DevOps

Send message

Иногда приходится пользоваться Glovo. Вот это реально творение сумрачного гения.

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

  • База адресов откровенно убогая, т.к. используется google maps, который крайне хреново знает все места вне США. И при этом невозможно ввести адрес руками.

  • Ужасающее главное меню. Чтобы просто добраться до списка ресторанов, нужно угадать, с какой стороны будет эта кнопка и как она сегодня называется. Иначе будет ровно такой же список, но только "акционных" ресторанов.

  • Нет автоперевода меню ресторанов/магазинов. Особенно прекрасно там, где не знаешь даже алфавит. И да, название блюда скопировать невозможно.

  • Классика - рекламная заставка на весь экран с 2+ кнопками. Да, алфавит ты не знаешь :) Как хорошо, что кнопка "скройся" обычно самая незаметная...

То же самое у меня. Очень раздражает…
Да, не спорю. Просто на то время LTSP был весьма нестабилен и глючноват, оказалось проще и быстрее сделать свой проект. Да, звучит странно, но факт.
В 2013-2014 LTSP был достаточно сырым. После нескольких тестов решили от него отказаться.

Ну и еще пара особенностей, которые нужны были:
1. Поддержка вебкамер и вообще любого железа в потенциале (мало ли, что бизнес запросит).
2. Настройка окружения пользователя. Например, браузеров и т. п. Это так и не понадобилось, но, опять же, мысли были.
Действительно неплохие мысли. И да, похожее делал на TeamCity+MSDeploy и на TeamCity+OctopusDeploy. В большой инфраструктуре с большим количеством инсталляций ПО незаменимо.
Devops — носитель знания/понимания о двух сторонах: разработке и эксплуатации. Он не затыкает дыры, а, скорее, говорит, как можно их обойти в разработке и снизить влияние «необходимого зла» в эксплуатации. Этакий knowledge bridge. Соседний комментарий как раз про это.
Если же devops стал козлом отпущения — мне жаль, это говорит о неправильно построеной разработке.
Очень часто механизм разработки формируется только разработчиками. А devops или тот, кто выполняет его обязанности, приходит позже. Так что да, зачастую приходится перестраивать процессы очень сильно.
Да, соглашение должно быть и должно вырабатываться всеми сторонами процесса. Пример мне нравится, кстати: фокус на управляемости и повторяемости всех этапов. Спасибо.
И поэтому тоже, но главное (с его слов) — больше свободы творчества.
Это и есть тот конфликт development vs. operations, о котором было написано в начале статьи. Он рассмотрен огромное количество раз в разных источниках и с разных точек зрения. Здесь скорее рассмотрено его возможное решение в виде devops.
Тут стоит разделять админов офисной инфраструктуры ( часто — просто support по факту) и админов «серверных» так сказать. Не всякий админ сможет корректно настроить инфраструктуру под большой проект, например.
Здесь я действительно многое писал с позиции скорее админа (operations). Я понимаю, что devops и админ — разные специальности, задачи и даже отчасти мышление. Идея статьи в том, чтобы показать многие конфликтные моменты, возникающие из непонимания того, где заканчивается development и начинается operations. Одна из задач devops — как раз в сглаживании таких «конфликтных» взаимодействий т.к. он должен обладать достаточной компетенцией в обеих сферах. И да, это не единственная и не основная из задач.
Здесь имелся в виду не разбор чужого кода (с ним, обычно, все неплохо), а задачи, связаные с конфигурированием уже написаных сервисов/систем. Это просто «непрофильная» задача для тех, кто привык писать код — сконфигурить что-то относительно сложное. Можно, но неудобно/неинтересно для мышления. «Написать свое» психологически проще.
Кстати, из этого во многом растут ноги у систем управления конфигурацией и вообще концепции infrastructure as a code.
Дело в том, что часто народ просто-напросто не задумывается о том, в какой среде и как будет работать софт. При использовании любых средств управления конфигурацией, оркестрации и т.п. все равно в первую очередь надо продумывать, что и как будет работать.

Information

Rating
Does not participate
Location
Воронеж, Воронежская обл., Россия
Date of birth
Registered
Activity