User
Здравствуйте, меня зовут Сергей, я работаю JavaScript-программистом, и я - буддист. Но совсем не такой, каким вы меня только что представили. Наверняка, при прочтении слова "буддист", в вашей голове всплывает либо образ улыбчивого азиата в оранжевом одеянии, либо образ безработного хиппи-вегана, путешествующего по Индии, занимающегося йогой и ищущего "просветления" в сомнительных религиозных практиках. Так вот, я ни тот, и ни другой. Так кто же я? Чтобы ответить на этот вопрос, нужно для начала поближе познакомиться с историей буддизма.
Около трех с половиной тысяч лет назад Древняя Индия была завоевана ариями - одним из индоевропейских племен, пришедшем в Индию с предгорий Кавказа через территорию современного Ирана. Немного отклонившись от основной темы поста, скажу, что с этим завоеванием связано много интересных фактов. Именно потому, что кроме Индии эти племена завоевали также территории Европы и Ирана, все европейские, персидский и индийские языки родственны друг другу и входят в одну языковую семью. Вы же понимаете санскритское слово "веды" без перевода, верно? И именно по названию места происхождения этих племен в английском языке европеоидная раса называется caucasian race. А также именно по названию этого племени французский граф Жозев Артюр де Гобино дал имя своей печально известной расовой теории, позже популяризованной и претворенной в жизнь Адольфом Гитлером. Но давайте вернемся назад к нашей теме.
| Время | Занятие |
| 6:30 – 7:00 | Подъём |
| 7:00 – 7:30 | Медитация |
| 7:30 – 9:30 | Решение задач по алгоритмам |
| 9:30 – 10:00 | Путь на работу |
| 10:00 – 18:30 | Работа |
| 18:30 – 19:00 | Путь с работы |
| 19:00 – 19:30 | Общение с женой |
| 19:30 – 20:00 | Медитация |
| 20:00 – 22:00 | Решение задач по алгоритмам |
Привет, Хабр! Я консультант по информационной безопасности в Swordfish Security по части выстраивания безопасного DevOps для наших заказчиков. Я слежу за тем, как развивается тенденция развития компаний в сторону DevSecOps в мире, пытаюсь транслировать самые интересные практики в русскоговорящее сообщество и помогаю выстраивать этот процесс с нашей командой у заказчиков. За последние 2 года тема DevSecOps стала привлекать все больше внимания. Новые инструменты не успевают стать частью быстро растущего набора практик, из-за чего у меня появилось желание поставить некоторую контрольную точку в виде списка инструментов. Отправной точкой стал выход статьи коллег из Mail.ru, где отдельно был выделен раздел по безопасности Kubernetes. Я решил расширить этот список, охватив другие этапы жизненного цикла SDLC и приведя пару новых инструментов.
Вы когда нибудь задумывались о том, как в условиях мультикомандной разработки современного продукта избежать задержек из-за синхронизации команд? Далее я поделюсь опытом такой разработки на примере нашей команды Циан.Финансы. Деталями вертикального подхода к разработке и почему мы работаем именно так.
Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.
Самым непонятным и зубодробительным оказалось, наверное, Теория Категорий. Я освоился в ней только с третьего подхода. В первые два раза я честно все прочитал, кажется понял, но т.к. никакой связки с реальной жизнью она не имела, то спустя неделю она благополучно полностью выветривалась.
Попытки использовать как-то в работе изученные концепции разбивались о полное непонимание, как применить полученное глубокое знание. Ведь, напомню, что парадигму ФП (где-то удобнее, где-то не очень, но) можно использовать практически в любом ЯП, совсем необязательно для этого изучать условный Хаскель.
В последнее время на Хабре стали чаще появляться посты о том, как хорош Telegram, как гениальны и опытны братья Дуровы в построении сетевых систем, и т.п. В то же время, очень мало кто действительно погружался в техническое устройство — как максимум, используют достаточно простой (и весьма отличающийся от MTProto) Bot API на базе JSON, а обычно просто принимают на веру все те дифирамбы и пиар, что крутятся вокруг мессенджера. Почти полтора года назад мой коллега по НПО "Эшелон" Василий (к сожалению, его учетку на Хабре стёрли вместе с черновиком) начал писать свой собственный клиент Telegram с нуля на Perl, позже присоединился и автор этих строк. Почему на Perl, немедленно спросят некоторые? Потому что на других языках такие проекты уже есть
Тем не менее, в данной серии постов будет не так много криптографии и математики. Зато будет много других технических подробностей и архитектурных костылей (пригодится и тем, кто не будет писать с нуля, а будет пользоваться библиотекой на любом языке). Итак, главной целью было — попытаться реализовать клиент с нуля по официальной документации. То есть, предположим, что исходный код официальных клиентов закрыт (опять же во второй части подробнее раскроем тему того, что это и правда бывает так), но, как в старые времена, например, есть стандарт по типу RFC — возможно ли написать клиент по одной лишь спецификации, "не подглядывая" в исходники, хоть официальных (Telegram Desktop, мобильных), хоть неофициальных Telethon?
Определение истинной смертности от COVID-19 требует дополнительного времени. Сегодняшние данные свидетельствуют о том, что общий коэффициент смертности составляет 3–4%, при этом уровень смертности от инфекции будет ниже.
