Привет и спасибо за отзыв! :-)
А вообще, эта статья появилась во многом по той причине, что в последнее время (а это уже после твоего ухода) многие процессы у нас действительно заметно улучшились.
The Buddhist term translated into English as «mindfulness» originates in the Pali term sati and in its Sanskrit counterpart smṛti. According to Robert Sharf, the meaning of these terms has been the topic of extensive debate and discussion. Smṛti originally meant «to remember,» «to recollect,» «to bear in mind,» as in the Vedic tradition of remembering the sacred texts. The term sati also means «to remember.» In the Satipaṭṭhāna-sutta the term sati means to remember the dharmas, whereby the true nature of phenomena can be seen.
Но кто будет так «закапываться» среди массовых пользователей приложений для «медитации»?..
Нравится нам это или нет, но в массах уже устоялся перевод как «осознанность», а если обратиться к буддийской терминологии, откуда этот самый mindfulness и вытащили для популяризации, то там [среди самих буддистов] чаще в ходу перевод как «памятование»… Под «медитацией», честно говоря, тоже каждый сегодня понимает что хочет, хотя у разных традиций бывают очень разные техники (и вообще цели практики). Но что противоположного по существу вы видите в «осознанности» и «сосредоточенности»?
Была мысль так сделать, когда полностью обновим текущие задания (иначе новые кандидаты окажутся не в равных условиях). Теперь есть больше уверенности, что это будет интересно, спасибо за вопрос
Если кандидат всё-таки прошёл первое интервью и взялся за прохождение задания, на что (как его сразу предупредили) требуется потратить много времени, — им всё-таки что-то движет. И обычно тут два направления этого движения:
или «спортивный интерес» (некоторые об этом нам говорили прямо и до, и во время, и после тестового задания),
или всё-таки интерес к компании.
Причём первое иногда переходит во второе: «Раз тестовое задание так затягивает, то и работать, наверное, не скучно?». А иногда оно сводится к тому, что: «Извините, переоценил себя, тест не тяну, поэтому давайте я опыта наберусь и выйду на вас в другой раз» (на самом деле, конечно, причина может быть в другом, но объяснения будут скорее всего примерно такими).
Каковы наши действия? Понять, перешёл ли кандидат в стадию интереса работы у нас, и продолжить с ним работу. Если этого интереса не появилось, то — в зависимости от результата + его общего «настроения» (от «Что за дурацкий тест у вас и с чего вы решили, что у меня столько времени, чтобы всё тут проходить?» до «Спасибо, это самое крутое задание, что я видел!») — в базу кандидатов, к которым можно вернуться через некоторое время, или всё.
Note: Kubernetes only sends the preStop event when a Pod is terminated. This means that the preStop hook is not invoked when the Pod is completed. This limitation is tracked in issue #55087.
Сотрудничество опенсорс компаний с мс всегда приводило их к банкротству/последующему поглощению корпорацией и я не хочу чтобы тоже самое произошло с гитхабом.
При всей моей нелюбви к MS… это не совсем правда. Например, у Microsoft и Red Hat очень долгая история сотрудничества в разных направлениях, что не мешает RH оставаться безоговорочным лидером (в частности и по финансовым показателям) в мире коммерции на базе Linux/Open Source.
Несмотря на то, что история GNU/Linux связана с GPL, свободное программное обеспечение (и сопутствующие ему свободы) не ограничивается этой лицензией (и её разновидностями). В частности, Apache License v2 — формально одобрена в FSF и совместима с GPL v3, поэтому существенных причин для «однако» я здесь не вижу.
Лично я люблю GPL и заложенную в неё идею автоматического «распространения» свободы, но, выбирая лицензию для dapp (а позже и loghouse), у нас в компании больше руководствовались предпочтениями соответствующей экосистемы (Kubernetes и связанных с ним Open Source-проектов). Почему? С целью минимизировать потенциальные проблемы интеграции с различными проектами в обозримой перспективе. Никто не мешает нам пересмотреть этот вопрос (в пользу GPL или других лицензий, или даже двойного лицензирования), если мы увидим такую необходимость, но пока она не возникала.
Касательно управления кластерами с помощью «ПО с закрытым исходным кодом» — по всей видимости, речь идёт про нашу внутреннюю разработку (antiopa). Она представляет собой квинтэссенцию накопленного нами опыта по Kubernetes, лучшие практики и во многом нашу добавленную стоимость. По факту это не софт как таковой, а услуга (коммерческая подписка), которую мы, будучи технарями, для своего же удобства автоматизировали там, где это возможно. Обязаны ли мы, даже являясь сторонниками свободного ПО, публиковать все свои лучшие практики в таком вот автоматизированном, готовом (для специалистов вроде нас) виде — вопрос не столь однозначный.
Пока мы видим для себя такой путь (пусть он не во всём идеален с позиций уважаемого RMS, но прекрасно укладывается в типовые бизнес-модели Open Source) и, по крайней мере, делимся своим опытом в статьях и докладах (на конференциях), а также выкладываем в качестве Open Source те полезные «дополнения» для экосистемы (см. наш GitHub), которые считаем полезными для большого сообщества и способными вырасти до массовых в своей области проектов (к слову, ими мы тоже пользуемся у себя, на их разработку мы тоже тратим очень много собственных ресурсов и они тоже добавляют нам той самой стоимости). Стараемся также помогать актуальным для нас Open Source-проектам по мере интересов и возможностей (примеры: 1, 2, 3).
«крупнейшая встреча любителей open source» — крупнейшая ли, когда есть как минимум OSCON (оцените/сравните число выступающих)?
«Концепция Операторов была впервые представлена на конференции KubeCon Europe 2018» — как это представлена в 2018-м году, если даже мы писали о них больше года назад (во многом опираясь на материалы ребят из CoreOS)?
Спасибо за поздравление! Поскольку у нас очень(!) часто об этом спрашивают и тут нет совсем короткого/простого ответа (в разных случаях делаем по-разному — зависит от ряда факторов), мы вчера решили, что сделаем доклад на тему СУБД и контейнеров/K8s — правда, уже к HighLoad++, т.к. на РИТ подана другая тема.
Во-первых, чисто технический. У Datadog нет такой автоматизации, как у Okmeter, чтобы все сервисы находились и мониторились «сами», без необходимости дополнительно настраивать/допиливать мониторинг. Детализация тоже проигрывает: если у Datadog сотни метрик с одной машины, то у Okmeter — тысячи. А это бывает критично для поиска источника проблем в случае их возникновения (необычных, конечно же).
Во-вторых, о том самом взаимодействии. Ребят из Okmeter мы лично знали, общались, видели общие взгляды на многие вопросы, быстро сошлись на взаимном желании помогать друг другу (для конечной пользы всем). Возможно, что и с другими сервисами удалось бы достичь чего-то подобного, но в случае масштабов Datadog это точно было бы на порядок сложнее, да и вероятности успеха (не только первой договорённости, но и быстрого/эффективного дальнейшего взаимодействия) явно меньше. А нам нужен был не просто хороший сервис, но и пресловутый «симбиоз», о котором статья.
Всё относительно. Даже среди рекламных слоганов есть популярная разновидность с деепричастием в начале («Управляя мечтой» и т.п.). Можно просто опустить глагол, оставив вопросительную форму, но это просто дело вкуса, а не дикости.
А вообще, эта статья появилась во многом по той причине, что в последнее время (а это уже после твоего ухода) многие процессы у нас действительно заметно улучшились.
Автор этого материала ниже развернуто ответил, а ещё подробнее обещаем раскрыть в следующих статьях по теме.
Но кто будет так «закапываться» среди массовых пользователей приложений для «медитации»?..
Причём первое иногда переходит во второе: «Раз тестовое задание так затягивает, то и работать, наверное, не скучно?». А иногда оно сводится к тому, что: «Извините, переоценил себя, тест не тяну, поэтому давайте я опыта наберусь и выйду на вас в другой раз» (на самом деле, конечно, причина может быть в другом, но объяснения будут скорее всего примерно такими).
Каковы наши действия? Понять, перешёл ли кандидат в стадию интереса работы у нас, и продолжить с ним работу. Если этого интереса не появилось, то — в зависимости от результата + его общего «настроения» (от «Что за дурацкий тест у вас и с чего вы решили, что у меня столько времени, чтобы всё тут проходить?» до «Спасибо, это самое крутое задание, что я видел!») — в базу кандидатов, к которым можно вернуться через некоторое время, или всё.
При всей моей нелюбви к MS… это не совсем правда. Например, у Microsoft и Red Hat очень долгая история сотрудничества в разных направлениях, что не мешает RH оставаться безоговорочным лидером (в частности и по финансовым показателям) в мире коммерции на базе Linux/Open Source.
Несмотря на то, что история GNU/Linux связана с GPL, свободное программное обеспечение (и сопутствующие ему свободы) не ограничивается этой лицензией (и её разновидностями). В частности, Apache License v2 — формально одобрена в FSF и совместима с GPL v3, поэтому существенных причин для «однако» я здесь не вижу.
Лично я люблю GPL и заложенную в неё идею автоматического «распространения» свободы, но, выбирая лицензию для dapp (а позже и loghouse), у нас в компании больше руководствовались предпочтениями соответствующей экосистемы (Kubernetes и связанных с ним Open Source-проектов). Почему? С целью минимизировать потенциальные проблемы интеграции с различными проектами в обозримой перспективе. Никто не мешает нам пересмотреть этот вопрос (в пользу GPL или других лицензий, или даже двойного лицензирования), если мы увидим такую необходимость, но пока она не возникала.
Касательно управления кластерами с помощью «ПО с закрытым исходным кодом» — по всей видимости, речь идёт про нашу внутреннюю разработку (antiopa). Она представляет собой квинтэссенцию накопленного нами опыта по Kubernetes, лучшие практики и во многом нашу добавленную стоимость. По факту это не софт как таковой, а услуга (коммерческая подписка), которую мы, будучи технарями, для своего же удобства автоматизировали там, где это возможно. Обязаны ли мы, даже являясь сторонниками свободного ПО, публиковать все свои лучшие практики в таком вот автоматизированном, готовом (для специалистов вроде нас) виде — вопрос не столь однозначный.
Пока мы видим для себя такой путь (пусть он не во всём идеален с позиций уважаемого RMS, но прекрасно укладывается в типовые бизнес-модели Open Source) и, по крайней мере, делимся своим опытом в статьях и докладах (на конференциях), а также выкладываем в качестве Open Source те полезные «дополнения» для экосистемы (см. наш GitHub), которые считаем полезными для большого сообщества и способными вырасти до массовых в своей области проектов (к слову, ими мы тоже пользуемся у себя, на их разработку мы тоже тратим очень много собственных ресурсов и они тоже добавляют нам той самой стоимости). Стараемся также помогать актуальным для нас Open Source-проектам по мере интересов и возможностей (примеры: 1, 2, 3).
«Концепция Операторов была впервые представлена на конференции KubeCon Europe 2018» — как это представлена в 2018-м году, если даже мы писали о них больше года назад (во многом опираясь на материалы ребят из CoreOS)?
Во-первых, чисто технический. У Datadog нет такой автоматизации, как у Okmeter, чтобы все сервисы находились и мониторились «сами», без необходимости дополнительно настраивать/допиливать мониторинг. Детализация тоже проигрывает: если у Datadog сотни метрик с одной машины, то у Okmeter — тысячи. А это бывает критично для поиска источника проблем в случае их возникновения (необычных, конечно же).
Во-вторых, о том самом взаимодействии. Ребят из Okmeter мы лично знали, общались, видели общие взгляды на многие вопросы, быстро сошлись на взаимном желании помогать друг другу (для конечной пользы всем). Возможно, что и с другими сервисами удалось бы достичь чего-то подобного, но в случае масштабов Datadog это точно было бы на порядок сложнее, да и вероятности успеха (не только первой договорённости, но и быстрого/эффективного дальнейшего взаимодействия) явно меньше. А нам нужен был не просто хороший сервис, но и пресловутый «симбиоз», о котором статья.