Шурутов Михаил
@shurutov
Инженер по эксплуатации вычислительной техники.
Информация
- В рейтинге
- 4 327-й
- Откуда
- Красково, Москва и Московская обл., Россия
- Зарегистрирован
- Активность
Специализация
Database Administrator, Инженер по эксплуатации вычислительной техники и автоматизированных систем
Lead
От 500 000 ₽
Git
Linux
Nginx
High-loaded systems
Database
Bash
PostgreSQL
Docker
LDAP
хотелось бы маленько поумнивать по поводу коммерческого/СОПО (свободное открытое ПО, не надо слово "открытое" убирать, однако!) вообще и импортозамещения в частности. Итак, что мы имеем (опуская политику, хотя в теме импортозамещения эта политика из всех щелей торчит):
Данный материал уже сильно не первый о практическом внедрении Эльбрусов (я надеюсь, ссылка на материал с пгконф не будет преступлением): https://pgconf.ru/2017/93795
А компании RedSys спасибо за интересный материал. Импортозамещение, я смотрю, уже умеет больше, нежели я думал. Приятно, однако.
Ubuntu — продукт коммерческой иностранной компании;
Linux, PostgreSQL — открытые свободные продукты, не принадлежащие какой-либо коммерческой/государственной организации; А PostgresPro, который есть постгрес от компании Postgres Professional — так вообще в списке отечественного ПО, мало того он ещё и сертифицирован ФСТЭК.
Так что postgres — это импортозамещение без скидок и оговорок. В отличие от остальных продуктов, по которым возможна дискуссия.
NodeJS — не скажу, не в теме;
Java — OpenJDK.
Это вот как-то так вкратце.
Да я в своей практике частенько сталкивался с тем, что emerge <> быстре и дешевле обходились, нежели ручками собирать, особенно вот в таких хитрых конфигурациях, когда надо несколько вариантов собирать.
Ну и эксплуатация — профдеформация, однако! Низзя засорять систему! :)
Под gentoo ручками что-то собирать?! o_O
Я удивлён.
Эххх, кто бы меня пнул в субботу/воскресенье — надо обязательно ебилд нарисовать, ибо хочется, однако! Благо есть куда запихать вместо всяких php-fpm-ов и прочих разных обёрток...
3 правило. На *них-машине оба варианта путей приведут к ошибке. Внезапно, однако!
Если уж используется java, то, по-моему, будет уместным пользоваться File.separator или path.separator для формирования путей;
6 правило. Я думаю, будет уместным упомянуть про виртуалки/контейнеры с возможностью создания снимков ФС.
Спасибо за понимание. А то тут много чего понаписали про то, что руководитель не нужен. Либо о том, что команда вполне себе может решать задачи, которые обязан решать руководитель.
Про боль. По личному моему опыту начинать решение проблем всё-таки предпочтительнее с приватной беседы. Боль — она вполне себе может быть обусловлена личными причинами, озвучивать которые публично вполне себе может быть не совсем приемлемо.
И самое главное — когда появляется боль, требующая внимания руководителя, эту боль надо решать немедленно, а не на плановом совещании.
И второе. Я как-то вот так предпочитаю направлять свои усилия, чтобы исключить вероятность нештатных ситуаций, а не решать проблемы. Соответственно, комфортно себя чувствую только там, где руководители понимают, что предотвратить проблему существенно дешевле, нежели постоянно решать возникающие проблемы.
Процитированное — это ключевые словосочетания.
Обобщая свой опыт, не зная вот вот этих ключевых слов, сделал безапелляционное заявление, был неправ, прошу прощения.
Но час на обсуждение. Регулярно. По некоторым причинам мне от этого грустно. :(
План+ретроспектива — соглашусь;
обсудить — только при необходимости, каковая имеет место быть далеко не всегда.
А вот обсуждение планов и задач каждого — оно не только громоздко, оно нередко выливается в какое-нибудь громогласное непотребство, которое приходится пресекать руководителю.
Соответственно, такой сбор — оно уже совсем не совещание, а какая-нибудь планёрка минут на 5-15.
Не надо так делать. Ничего хорошего в таких совещаниях нет и неизвестно. За всю свою жизнь ни разу не встречал коллективов, где бы подобные совещания чему-то способствовали. Либо таковые встречи заканчивались плачевно для коллектива/проекта/компании, либо прекращали быть (тоже плачевно для коллектива, потому что приводили к смене руководителя, а новый руководитель — он и есть новый руководитель).
Потому что "команда решает, как ей работать" тождественно равно "бардак". Не всегда полный, но бардак гарантированный. Имею как жизненных (до ВУЗ-а), так и профессиональных примеров, когда команда "решала". Все (ВСЕ!) эти примерыр заканчивались плачевно, в лучшем случае — приглашением нового руководителя. Решатели плакали крокодильими слезами в таком случае. Есть примеров, когда команда дорешивалась до ликвидации компании, как самостоятельного лица (либо конкуренты покупали, либо банкротство, либо ещё что-нибудь такое "весёлое").
Решает ВСЕГДА руководитель. Он же и отвечает за принятые решения перед вышестоящим руководством и прочими инвесторами. И именно поэтому у руководителя з/п выше, чем у рядовых сотрудников. Члены же команды имеет право, а у хорошего руководителя, обязаны, сформулировать и предложить пожелания/требования к средствам и способам совместной работы. А руководитель, в свою очередь, обязан прислушаться к мнению своих подчинённых и выбрать наиболее соответствующие целям и задачам средства и способы.
А идеальным является руководитель, у которого в подчинении есть товарищи, у которых в договоре прописано разрешение публично объяснять руководителю глубину его некомпетентности не выбирая выражений. Я, правда, таких не встречал, к своему великому сожалению. :(
Вооот! Спасибо Вам за комментарий, у меня как-то не получилось эту мысль донести, растёкся по древу. :)
Я повторю, вдруг не видно было:
Комментарий. Задача из разряда посмотреть, как человек думает. Без вариантов ответов будет лучше, наверное.
У меня сложилось впечатление, что вы немного путаете стаж и опыт. Разница, если очень кратно:
стаж: протирание штанов в офисном кресле, решение исключительно типовых задач путём механического копирования найденных решений схожих/подобных задач; развивается только навык слепой печати, да и то не всегда;
опыт: решение задач путём использования головного мозга и имеющихся в этом мозгу знаний для анализа условий и формализации задачи с целью выработки пути решения; анализ имеющихся средств и способов решения для выбора наиболее соответствующего условиям задачи (средств и способов зачастую несколько); собственно решения задачи и, наконец, оформления отчёта о проделанной работе. Финальный пункт также включается в опыт, ибо Вы задачу решаете не только в своё удовольствие, но и, в подавляющем большинстве случаев, для использования Вашего продукта более другими людьми.
Когда вы набираете опыт, мало того, что набирается некоторая база знаний, ещё и мозги развиваются, что весьма важно для решения сложных и трудоёмких задач.
первая задача — вполне себе достойная задача для собеседования разработчика с некоторым опытом. На понимание того, как работает компилятор/ява машина.
Причем важен не только и не столько правильный ответ, а именно то, как человек будет решать данную задачу.
Вот я, ни разу не ява-разработчик, вижу следующие подводные камни: число начинается с нуля, сколько встречался с языками программирования — восьмеричная система счисления, второе — десятичное. Отсюда вопрос — умеет ли ява складывать два числа в разных системах счисления, и если да, то проверяется пониманию соискателем преобразования чисел между системами счисления.
Есть два небольших нюанса:
Да, вы правы насчёт центоси — работает без указания формата.
без "z" tar выдаст ошибку.
Единственное, что навскидку не придумывается (именно не придумывается, не факт, что данную функциональность проблематично реализовать) — это вся и всяческая визуализация, типа тех же ER-диаграмм и прочих связей в БД. А так из vim-a вполне себе лёгкую IDE замастырить, я думаю, не проблема.
eix-sync
набирать короче. :)