1. Зависимости пакетов, как и импорт модулей, формируют направленные графы.
2. Интернет — это граф, состоящий из ссылок между веб-страницами.
3. При проверке моделей анализ выполняется путём изучения «пространства состояний» всех возможных конфигураций. Узлы — это состояния, а рёбра — это допустимые переходы между ними.
4. Реляционные базы данных — это графы, в которых узлы являются записями, а рёбра — внешними ключами.
5. Графы — это обобщение связанных списков, двоичных деревьев и хэш-таблиц.¹

Доброго времени суток, уважаемые хабровчане.

В этой статье я хотел бы провести экскурс в одну сферу, которую нельзя отнести непосредственно к IT, но, она - техническая и, возможно, для вас она будет интересна. И, параллельно с ней и на её примере, поднять популярную здесь в последнее время тему востребованности специалистов.

 А пост, собственно, пойдёт о средствах радиосвязи и навигации и вообще электронике на современных морских судах, об использующихся технологиях, стандартах и даже о преждевременно “похороненной” специальности.

 Я планирую сделать несколько выпусков, чтоб в каждом последующем учесть вопросы в комментариях (надеюсь, они будут, и не очень сложные). А эту – вступительную – статью я разбил на два подпункта: социальный и технический. Те, кому интересна только техника - воспользуйтесь великолепным спойлером. Под ним – вводное, и пока не очень глубокое описание техники, устанавливающейся на морские суда с оригинальными фотографиями.

 Остальным советую ознакомиться со всей статьёй полностью: это не только дополнит повествование, но и, надеюсь, станет кому-то хорошим примером одной давно известной истины.

Аналогичную же задачу решает переход на ipv6, но при этом он требует поддержки со стороны самого транслятора, в то время как Tor абсолютно самостоятелен, хоть он и не является настоящим p2p.

Я постоянно пишу заметки. В общей сложности занимаюсь этим уже 4+ года. Сперва был приверженцем бумажных заметок, так как мало информации "для изучения" туда попадало. Потом появилась потребность в навигации в своих записях, поэтому ушёл в цифру.

Сначала пробовал ноуш для личных записей + Confluence для записей по личным проектам + Saved Messages в тг для ссылок .
Оказалось сложно и не удобно. Год назад открыл для себя Obsidian.

Перенёс туда всю инфу со всех пространств и было ОК несколько месяцев. Но информация всё копилась и копилась.

И тут пришло время усложнений и планирования...

File system level backup  в Postgres это первое чему нужно научится при использовании Postgres . Никакие pg_dump \ pg_restore не заменят Полный бэкап на уровне файлов. File system level backup это первая ступень для подготовки к Continuous archiving. Понимание архитектуры хранения – это фундамент, по которому можно понять сможете ли Вы жить с Postgres на больших объемах или у Вас другой путь?

Это перевод одноименной статьи.

Базовое использование

Сериализации JSON в Go

В стандартном пакете encoding/json присутствуют механизмы сериализации marshaling и десериализации unmarshaling JSON.

Пример:

Привет, Хабр! Недавно мы делали доклад на конференции HighLoad 2023 — «Мифы и реалии Мультимастера в архитектуре СУБД PostgreSQL». Мы — это Павел Конотопов (@kakoka) и Михаил Жилин (@mizhka), сотрудники компании Postgres Professional. Павел занимается архитектурой построения отказоустойчивых кластеров, а Михаил — анализом производительности СУБД. У каждого за плечами более десяти лет опыта в своей области.

Порассуждаем о том, как развивалась технология «Мультимастер» в экосистеме PostgreSQL, остановимся на том, что она из себя представляет, на каких внутренних механизмах PostgreSQL основана и как её можно использовать.

Мы также поговорим о том, существует ли «Честный Мультимастер» (само понятие «Честный Мультимастер» достаточно специфично и в основном употребляется в кругу разработчиков), какие реализации у него есть и как его следует применять.

Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software, и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО.

Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков, а простые продукты импортируют 1600 зависимостей неизвестного происхождения. Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно.

В этом посте я сделаю краткий обзор ужасного уровня безопасности современного ПО, а затем порассуждаю о том, почему он настолько плох. Также я упомяну нормативные/юридические аспекты, которые могли бы снова сделать качество ПО приоритетным. Наконец, я расскажу о написанном мной полезном ПО , позволяющем доказать, что сегодня по-прежнему можно разрабатывать минималистичное и простое ПО, остающееся современным.

Надеюсь, этот пост станет моральной поддержкой для страдающих программистов и технологов, стремящихся улучшить ситуацию. Дело не только в вас, и мы не просто страдаем от ностальгии: ПО сегодня действительно очень странное.

Приветствую тебя, хаброжитель!

В этой статье разберём 100 вопросов, они покрывают львиную долю того, что могут спросить на собеседовании джуниор Go-разработчика с практически любой специализацией. Конечно же, в реальной работе на Go требуются немного другие скиллы, чем умение быстро ответить на любой вопрос. Однако сложилась добрая традиция делать из собеседования викторину с главным призом в виде трудоустройства — к этому нужно быть готовым.

Статья о том, как в суде при помощи разработчиков удалось оспорить кредитный договор, оформленный на человека жуликами.

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

Хотя уменьшение сегодня уже необязательно, оно всё равно лучше.

Примерно 2.5 года назад я приступил к созданию простенького пет проекта для тестирования себя на предмет усвоения знаний. Как это работало: в процессе усвоения информации выписываю важные моменты > в приложении создаю из них вопросы > прохожу созданный тест спустя пару месяцев > вспоминаю что забыл, остальное закрепляю.

После доведения приложения до нужного уровня, разработка отложилась, пока на работе не столкнулся с проблемой больших временных затрат у ведущих разработчиков на проведение собеседования, оценку и подведение итогов. 

Изучив проблему, я подумал: почему не реализовать решение на базе своего приложения для тестов, и бонусом сделать функционал создания тестов общедоступным? И тут понеслось… 2 года непрерывной разработки, множество усвоенных новых знаний, 100500 рефакторов, - 10 выгораний.

Привет, Хабр!

В этой статье я расскажу о своем опыте изучения английского языка и поделюсь вещами которые работали и не работали для меня. Процесс изучения языка очень индивидуален, и никогда нельзя утверждать что верный какой-то один метод / схема (хотя некоторые статьи на Хабре прямо говорят: вот этот метод правильный, а вот этот нет).

Начнем с бекграунда и причин.

Я – инженер машиностроитель (мой профиль – торцевые уплотнения вращающихся валов). Я начал работать в своей отрасли сразу после бакалавра, параллельно заканчивая магистратуру, и как только я начал работать, я стал стараться впитать как можно больше теоретических знаний по моей специальности из академических источников. Достаточно бысто я понял, что последняя серьезная книга по моей специальности на русском языке была написана в 1978 году. И спустя больше чем 40 лет технологии сильно поменялись, а вот их описание на русском языке отсутствовает. Зато я нашел на reddit людей работающих в штатах в моей же отрасли. Они мне насоветовали кучу классной литературы. Разумееется, она вся на английском, и русского перевода не имеет.

Начал свой путь изучения языка я в январе 2022 года с около нулевого уровня. В всех моих школах преподование английского языка было не на самомом высоком уровне, а в университете было достаточно выучить 30 предложений наизусть чтобы получить достойную оценку на экзамене.

Конечно, перед началом обучения я прочитал много статей на хабре о том как люди учат языки. Некоторые из них поражали скоростью овладения материалом (что-то вроде с нуля до fluent за 4 месяца). Но одна вещь была неизменна – у всех был какой-то план изучения языка.

Сегодня ровно 20 лет, как я начал программировать профессионально. За эти годы я:

• Получил одобрение на петицию по грин‑карте за выдающиеся способности в науке.
• Стал Google Developer Expert.
• Стал IEEE Senior Member.
• Был операционным директором в компании со 100 сотрудниками.
• Написал код, который скачали 135 миллионов раз.
• Выступал перед аудиторией в 2000 человек, дважды.
• Стал самым честным человеком в России по версии НТВ.

Но упустил я гораздо больше и делал всё это слишком долго. Думаю, этот путь можно было бы пройти «на скорость» лет за 5 с теми подходами, принципами и приоритетами, которым я научился. Если вы только начинаете свой путь, этот текст может сэкономить вам 15 лет жизни.

Доброго времени суток!

Представляю подборку из 100 вопросов с собесов на позицию джуна Python-разработчика. На Хабре есть неплохие статьи на тему подготовки к собеседованию и всё в таком духе, но прямо набора вопросов/ответов на понимание Python в формате чек-листа не встречал.

Для кого статья?

Хабры и Хаброчки, я хотел бы перед самой статьёй обсудить вопрос целесообразности писать свой движок, вместо готовых решений. Есть куча статей, которые опишут разные движки от более популярных до менее. Я бы хотел затронуть немного другой вопрос: "Как человеку, который изучал программирование много лет заняться геймдевом?". Обычно, есть два пути в геймдев:

Умышленный путь. Это когда человек, который играет в игры рано или поздно решит их создать. Тогда, он выбирает где ему учиться этому и выучивает игровые движки и C-образные языки к ним (чаще всего, C#).

Путь прогеров. Программист увлекается математикой и пишет код. Так или иначе, везде где есть код — есть компьютер. Цифровые развлечения (в том числе и игры) не проходят мимо тех людей, который постоянно пишут код. Так, часть прогеров решает написать свою игру и начать свой путь в геймдев. Об этом пути мы и поговорим.

Так зачем выбирать "сложный" путь? Во-первых, не для всех он сложнее. Лично мне сложнее перейти на C# с использованием Unity, чем написать новый проект на Python. Во-вторых, люди не всегда понимают сам движок. Сейчас я преподаю в институте "Бизнеса и Дизайна". Это один из первых профильных учреждений, занимающихся геймдевом. И вот у студентов я спросил зачем им движок. Каково было моё удивление, что далеко не все понимаю, вообще зачем он нужен. Спойлер, не из-за пресетов.

Всех заинтересовавшихся, приглашаю в мир змеиных игр!

Привет, Хабр! Меня зовут Александр Бехтерев, я работаю QA-инженером в Учи.ру. Не так давно перед нами встала задача перехода с библиотеки Selenium на новую и мощную библиотеку Playwright. Этот переход был вызван желанием улучшить процессы тестирования и попробовать что-то новое. 

В этой статье я постараюсь подробно рассмотреть процесс создания проекта на Python, Pytest и Playwright с применением паттерна Page Object, а также оставлю шаблон yml, который позволит запускать автотесты в CI.