IT-шник широкого профиля
После публикации статьи «TOTP без смартфона» она получила много интересных и полезных комментариев. Я решил подождать, пока обсуждение затихнет и провести работу над замечаниями и высказанными мыслями.
Поскольку объём работы оказался достаточно большой, то оформил её в виде отдельной публикации-послесловия.
Несмотря на то, что в наше время существует letsencrypt и подобные сервисы с утилитами, которые всё делают сами, я считаю что каждый айтишник должен уметь выпускать самоподписанные сертификаты для базового понимания их работы.
К тому же, в собственной сети не так важен правильный сертификат, когда на всех клиентских устройствах можно предустановить свой доверенный корневой сертификат и подписывать им сертификаты внутренних ресурсов. Но у автора статьи просто был спортивный интерес и на досуге хотелось вникнуть в тему.
Я снимаю кинофестивали, шины от поставщика Формулы-1 и даже робота-хирурга прямо в операционной. Но снимал и из багажника, в студии-каморке, и начинал с подручных средств. Поэтому решил собрать 3 комплекта для съемок под разный бюджет: от бабушкиной пенсии до зарплаты айтишника.
Я читаю курс статистического мышления магистрам, и одна тема вызывает у них явные затруднения — чем стандартное отклонение отличается от стандартной ошибки, и в каких случаях, применять ту или иную статистику. Думаю, будет интересно поговорить об этом в блоге ЛАНИТ.
Насколько пользователь должен быть уверенным в себе? В своих навыках работы на компьютере? Включил и работает? Или больше? И насколько больше?
В современных реалиях владение компьютером для работников, трудящихся в офисе – вроде как обязательный навык. Но непонятно, как его померить. Давайте посмотрим, насколько пользователь уверен в том, что он уверенный пользователь.
Маленькая ремарка – от сотрудников обычной компании не требуется настраивать многоуровневую сеть или проводить замену оборудования при поломках и модернизации оного.
Перечень навыков, которые указываются соискателями в резюме обычно стандартный, но широкий. Тут и владение офисными программами, и навыки работы в интернете, и магия обращения с принтерами, и разные там фотошопы, автокады, коралы. Верхом навыков является уверенное обращение с 1С. Со всеми сразу 1С-ами.
Общаясь с соискателями, будущий руководитель или рекрутёр почти никогда не акцентируют на этих строчках резюме внимания. А зря. Ведь офисный сотрудник большую часть времени проводит за компьютером. И от его реального навыка зависит как быстро он будет взаимодействовать с “инструментом”.
Привет, Хабр!
Rust имеет два основных типа макросов: декларативные и процедурные. Каждый из этих типов служит различным целям и предоставляет различные возможности манипуляции с кодом.
Декларативные макросы работают, сопоставляя заданные шаблоны с фактическим кодом и заменяя его на другой код во время компиляции. Что-то типо хорошей системы поиска и замены, но для исходного кода. Декларативные макросы подходят для задач, когда нужно избежать дублирования кода или когда нужно предоставить удобный синтаксис для повторяющихся задач.
А вот процедурные макросы уже имеют больше возможностей, они позволяют манипулировать абстрактным синтаксическим деревом кода, т.е можно анализировать, модифицировать и генерировать код на лету. Процедурные макросы могут быть разделены на три категории: атрибутивные макросы, макросы производных и функциональные макросы.
В этой статье мы как раз и рассмотрим то, как их пишут на Rust.
Начнем с декларативных!
В предыдущем уроке мы проговорили для чего может понадобиться домашняя лаборатория и самое главное — кому она нужна. Допустим вы решили, что вам она нужна. Тут же встанет вопрос: «На чем строить эту виртуальную лабораторию?». Вопрос не такой простой, как может показаться на первый взгляд. Как минимум здесь два важных пункта, которые очень тесно связаны друг с другом:
Компания у нас на full-remote, поэтому заседание кружка параноиков мы проводим как-то так. Иногда под банджо в углу.
В жизни любого проекта наступает катастрофа. Мы не можем заранее знать, что именно это будет - короткое замыкание в серверной, инженер, дропнувший центральную БД или нашествие бобров. Тем не менее, оно обязательно случится, причем по предельно идиотской причине.
Насчет бобров, я, кстати, не шутил. В Канаде они перегрызли кабель и оставили целый район Tumbler Ridge без оптоволоконной связи. Причем, животные, как мне кажется, делают все для того, чтобы внезапно лишить вас доступа к вашим ресурсам:
Макаки жуют провода. Цикады принимают кабели за ветки, и расковыривают их, чтобы отложить внутрь яйца. Акулы жуют трансатлантические кабели Google. А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.
Короче, рано или поздно, кто-то обязательно что-то сломает, уронит, или зальет неверный конфиг в самый неподходящий момент. И вот тут появляется то, что отличает компании, которые успешно переживают фатальную аварию от тех, кто бегает кругами и пытается восстановить рассыпавшуюся инфраструктуру - DRP. Вот о том, как правильно написать Disaster Recovery Plan я сегодня вам и расскажу.
Привет, меня зовут Ася Исакова, и я организационный психолог. Я уже 10 лет работаю с разными командами, и за это время видела сотни горящих, выгорающих и сгоревших на работе людей. В этой статье я расскажу, как управлять своим вниманием так, чтобы хватало сил на важные дела и оставалось на себя.
Разбираемся с управлением вниманием на примере огурцов, снежков и медведей
Восприятие английского на слух: упражнения, полезные советы и подборка ресурсов
Привет! Это Лена, методист курсов английского в Практикуме. Мы уже знакомы по статьям про собеседование для разработчиков и small talk. В этот раз поговорим о восприятии английского на слух и прокачаем навык общения с иностранными коллегами.
Большую часть своей рабочей биографии я занимаюсь различными финтех продуктами – Яндекс.Деньги, 1ЦУПИС и так далее. Последние два года я разрабатываю очередное платежное решение и хочу рассказать о некоторых задачах, с которыми мы встретились. Но мне интересно рассказать не только про появившиеся решения, но и, в первую очередь, про то, как вообще можно думать про архитектуру сложных систем.
Недавно я купил новый ноутбук и мне нужно было настроить его перед использованием. Но у меня не было настроения выполнять все те привычные шаги, о которых я рассказывал в предыдущем посте. Я пожаловался на это своему коллеге, и в ответ он предложил целиком копировать диск на новый ноутбук. Хотя эта идея показалась мне интересной, у меня возникли сомнения, которыми я поделился с ним.
Размышляя на тему минусов IT, я вспомнил историю моего знакомого Сергея, который работал на позиции Senior Java Developer в одном российском банке. В какой-то момент его настолько припекло, что он решил выйти из IT. «Прощай, немытое айти! Страна рабов, страна господ!», — браво повторял он, когда увольнялся. Как думаете, что из этого вышло?
Привет, Хабр!
Эта статья — моя подборка приёмов и техник, которые помогут писать лаконичный и производительный код на Go без лишних костылей и велосипедов.
Речь пойдёт о:
полезностях для конкурентного программирования
приёмах в Go в целом, таких как использование iota, работа с ошибками, вывод интерфейса и т.д.
методах оптимизации работы со слайсами
Обсудим, как избежать ненужной аллокации памяти, как быть с состоянием гонки, поговорим про компактность и лаконичность кода и ещё про массу полезных штук.
Некоторое время назад у нас возникла задача организовать возможность создания managed баз данных. Сложность данной задачи в том, что нам надо развертывать и управлять тысячами баз данных PostgreSQL, которые обеспечивают репликацию, бэкапы, мониторинг и другие полезные пользователям функции. При этом в ядре нашей системы лежит Kubernetes, в котором запускаются приложения пользователей. И по ряду факторов нам требовалось запускать базы данных внутри кластера.
Чтобы не изобретать велосипед, мы решили рассмотреть известные операторы, позволяющие разворачивать базы данных PostgreSQL в Kubernetes и управлять ими.
Если вы не провели последние два года на ферме в Сибири, вы, вероятно, слышали о Stable Diffusion или пробовали генерировать изображения с помощью моделей, вроде Dall-e или Midjourney. Они становятся все лучше каждый день, и по качеству уже сравнимы с людьми, а во многих аспектах даже лучше (например, им не нужно платить).
Исследования в области создания видео уже идут полным ходом во многих лабораториях и компаниях, так что это лишь вопрос времени, когда генеративные модели сместят людей с очередного столпа на котором держится наше общества — порно. Я не вижу чтобы кто то поднимал тревогу об огромном количестве людей, которые потеряют работу из-за этого. Я не такой бессердечный, поэтому, прежде чем наступил этот печальный момент, я решил принять меры и создать базовое руководство, которое даже работник индустрии для взрослых сможет понять и использовать, чтобы оставаться в игре. Давайте посмотрим, что к чему.
Продолжаем обзор паттернов интеграции микросервисов. В первой части мы рассказали, зачем IT-специалистам нужны шаблоны интеграции, и для каких задач они подходят. Подробно остановилисьна Circuit Breaker, Sidecar, Ambassador, Anti-Corruption Layer и Async Request-Reply. Сегодня по плануразобрать Backends for Frontends, Cache-Aside, Gateway, Gateway Aggregation и Gateway Routing.
Доброго времени суток, дорогие читатели! Сегодня я затрону одну интересную тему — графические дисплейные сервера и протоколы в Linux. В этой статье я расскажу вам о архитектуре X11 и Wayland, историю их создания и наконец-то сделаем вывод: Иксы на мороз, или вейланд на помойку?
Еще в далеком 2016 году вышла Fedora 25 с окружением GNOME 3.22 на базе дисплейного сервера Wayland. А в RHEL 10 выкинут X11 на мороз. Релиз RHEL 10 намечен на 2025 год, CentOS Stream 10 — на 2024 год. Для обеспечения работы приложений, требующих X11, будет использоваться XWayland. Таким образом, в 2029 году (к моменту окончания первого этапа поддержки RHEL 9) стоит ожидать появление первого аппаратного обеспечения, не поддерживающего X11.
И как я думаю — будущее за Wayland. Но пока X11 является стандартом. Давайте разберем это!
