Дивився тримачі для монітора, в решті решт, обрав підставку.
Айфон, наскільки я пам’ятаю, потрібно через сторонній софт, як вебку, підключати, що для мене не варіант.

Я хочу якось купити собі Sony A6400 і тоді зможу і фотки робити, і підключати його, як камеру.

У мене немає OnlyFans, але у знайомого є. Якщо вам цікаво, можу спитати у нього посилання і кудись вам в зкинути.

Docker випустили апдейт щодо ситуації.
Якщо коротко: ми погано прокомунікували, нічого видаляти не будемо, тільки якщо овнери самі видалять, ми дуже сорі.

www.docker.com/...​end-of-docker-free-teams

Найбільше питання навіть не в тому, хто і скільки має платити, та видалять безкоштовні організації чи ні. Питання чи залишаться назви видалених організацій заблокованими для нових користувачів. Бо якщо ні, це відкриває велику дірку для malicious code injections.

GitLab не наймає в Україні, якщо що.

Drone.UA і Аеророзвідка (не знаю, чи є у них сайт, але вони є на ФБ). Це ті, що спадають на думку.

Просто чесно сказати: «Дякую, але я зрозумів, що не буду зпівпрацювати з вашою компанією».
Це набагато краще, аніж піти потім через місяць чи два.

Робив таке кілька років тому, щоправда без операторів.

Принципово схема виглядала наступним чином: по вебхуку (ми ловили каменти в ПР, а не сам факт створення) автоматизація (у нас то був Дженкінс) створювала в нон-продакшн кластері новий неймспейс і встановлювала туди сервіси із залежностями, як наприклад, БД.

Із технологій використовували Jenkins, Helm (бо Хельм імперативний). Спочатку юзали амбрела-чарт, але потім розпиляли його на окремі чарти, бо то був жах із ним працювати. Перейшли на Skaffold .

Важливий нюанс, що вам потрібно не просто підняти сервіс в ізоляції, а забезпечити йому необхідні залежності. Наприклад, як менеджити БД в такому випадку? Якщо кожен фіча-енв використовує одну й ту саму БД, що робити із несумісними міграціями і змінами в схемі?

Якщо сервісів в вашій екосистемі багато, як забезпечити ізоляцію? Дуплікувати всю інфру може бути дуже дорого. Якщо ні, то потрібно якось дуплікувати трафік на фіча-енв або ж використовувати там кенері.

Коротше кажучи, фіча-енви — це круто, але потребує багато зусиль і іноді ті самі задачі можна вирішити легше, наприклад, якщо сервіс, розгорнутий локально, буде підключатись до АПІ в дев, тощо.

Проходив з ними співбесіду десь тижні два тому.

Я прямо запитав рекрутера, чи можливо буде працювати із ними при поверненні в Україну і той відповів, що напряму із людьми в Україні вони не співпрацюють. Рекрутер був з Gitlab, не зі сторони.

Так, може, він не володів всією інформацією. Але рекрутер — представник компанії. Тож якщо він каже, що не наймають, я робою висновок, що не наймають.

Gitlab не наймає людей в Україні.

Але повертаючись до оригінального питання, поза аутсорсом немає поняття «замовника». Ви просто працюєте в компанії. Ваги замовники — її клієнти.

Чи можна купити ОВДП будучи податковим резидентом іншої країни?

Онлайн (в Монобанку) є стандартний договір, в якому прямим текстом вказаний пункт: «Я підтверджую, що не є податковим резидентом іншої країни». Які є принципові зміни в купівлі ОВДП в цій ситуації і чи можна їх взагалі купувати податковим нерезидентам?

Я не дуже розумію, до чого тут «контрольна група тих, хто не використовує Kubernetes». Всі питання так чи інакше стосуються цієї тенології. Тому я не розумію, як людина, що не користується K8s може відповісти на питання: «Як часто ви оновлюєте версію Kubernetes?»

Нажаль, із ДОУ прийшло не так багато респондентів, як хотілося б. Більшість, все ж таки, із Телеграму та Реддіту. Хоча я міг судити про це лише із приросту відповідей після того, як розміщував опитування на кожному із ресурсів.

А скільки треба?

Google форма режет длинные ответы, но в сырых данных в Airtable всё есть без изменений

dou.ua/forums/topic/36560

Результати опитування доступні тут: dou.ua/forums/topic/36560

Так, звичайно!

Результати опублікую в першу чергу на каналі CatOps, але також там, де збирав дані, в т.ч. На Доу

И такие вот списки помогали понять, что в принципе спрашивают, можно и нужно знать, про что можно почитать.

Лёгким движением руки меняем заголовок на «На что стоит обратить внимание при изучении работы Linux / сетей / баз данных / обеспечения безопасности» (тут просто обо всём есть вопросы). И там далее по тексту: «... при изучении стоит так же обратить внимание на общую архитектуру ОС, типы файловых систем, их преимущества и недостатки, работу блочных устройств...» ну и так далее.

И вуаля! Из тупого гейткиперского списка практически такой же текст превратился в какое-никакое пособие для домашней работы.

интересно как вы прикидываете динамику роста.

Когда я только начинал свой карьерный путь, меня часто спрашивали, какие книги я прочитал за последние N времени. Можно прикинуть опорные временные точки. Например, испытательный в компании 3 месяца, можно спросить, что человек выучил за последние 3 месяца. Спросить, учил ли сам или группой и так далее.

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

Нет ничего плохого в том, чтобы спросить про таблицы IPTABLES, если речь зашла о сетевых фильтрах или маршрутизации трафика на Linux машинах. Точно так же вопросами можно контекст переключать, например, если вы долго общались про БД, а теперь хотелось бы и про Web что-то, можно перевести разговор пресловутым «что будет, когда написать google.com в браузер». Хотя я лично стараюсь таких вопросов избегать и переключать контекст во время интервью явно: «Хорошо, вот мы поговорили про БД, давайте ещё поговорим о Web...».

Резюмируя, мне кажется, что этот цикл статей о «вопросах на собеседование» — это дешевый способ DOU собрать просмотров и продать контекстной рекламы по боковым панелям, ведь такие статьи непременно вызовут горение в комментариях (как вот у меня, например, хехе).

P.S. И это не говоря уже, что в этой конкретно статье часть вопросов вне контекста, мягко сказать, странная и куча вопросов вообще повторяются.

Каждый раз в подобных дискуссиях я натыкаюсь на communication breakdown с аутсорсом.

Це спроба __компанії__ «заробити» на тому, що людина буде рости швидше ніж їх ЗП.

Компании зарабатывают на предоставлении услуг или сервисов. Вот эта идея о перепродаже голов даже звучит как-то противно.

Я не вижу смысла продолжать эту дискуссию дальше — она ни к чему не приведет.

Хорошего вам дня!

Не существует такого списка.

«Что должен знать девопс» звучит приблизительно так же, как «что должен знать разработчик». Java-разработчик должен знать Java, а JavaScript-разработчик, стало быть, JavaScript.

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

Точно так же и соискатель, если имеет опыт с определённым стеком, будет в это стек целиться. Исключение, разве что, сознательный переход от одного стека в другой. Например, человек, который всю жизнь работал с AWS, хочет перейти в GCP. Но даже тут такой список не поможет.