В прошлом году появилась необходимость дополнить старый проект написанный на C функционалом на Python3. Не смотря на то, что есть статьи на эту тему я помучился и в том году и сейчас когда писал программы для статьи. Поэтому приведу свои примеры по тому как работать с Python3 из C под Linux (с тем что использовал). Опишу как создать класс и вызвать его методы, получить доступ к переменным. Вызов функций и получение переменных из модуля. А также проблемы с которыми я столкнулся и не смог их понять.

Недавно я натолкнулся на интересную работу итальянских учёных о сильно недооценённой роли удачи и случайности в нашей жизни. К сожалению, не нашёл полной версии на русском языке (может, плохо искал?), но очень уж хотелось поделиться прочитанным со своими не владеющими английским товарищами. Поэтому, засучив рукава, принялся за свой кустарный перевод. Авторы, Алессандро, Алессио и Андреа, любезно разрешили опубликовать его в общем доступе, поэтому, если заинтересовались, добро пожаловать под кат.

PVS-Studio поддерживает анализ проектов на языках C, C++, C# и Java. Использовать анализатор можно под системами Windows, Linux и macOS. В этой заметке речь пойдет об анализе кода, написанного на C и C++ в среде Linux.

Установка

Установить PVS-Studio под Linux можно разными способами, в зависимости от типа дистрибутива. Наиболее удобный и предпочтительный способ – использование репозитория: так это позволяет автоматически обновлять анализатор при выходе новых версий. Второй вариант – использовать установочный пакет, который можно скачать здесь.

Как максимально выгодно купить авиабилет?

Любой более-менее продвинутый пользователь Сети знает такие варианты как

• покупать заранее
• искать маршруты с пересадкой
• hidden-city ticketing
• мониторить чартерные рейсы
• искать в режиме инкогнито браузера
• использовать мильные карты авиакомпаний, всяческие бонусы и промо-коды

Полный список лайфхаков как-то делал Тинькофф-Журнал, не буду повторяться

А теперь ответьте на вопрос — как часто вы попадали в ситуации когда покупали авиабилет, а потом он стал стоить дешевле?

Это вторая часть статьи о том, как правильно общаться и избежать ошибок в процессе код-ревью. Здесь мы поговорим о том, как довести ревью до конца и избежать неприятных конфликтов.

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

Моё худшее код-ревью

Худшее код-ревью в моей жизни было для бывшей коллеги, назовём её Мэллори. Она начала работать в компании за несколько лет до меня, но только недавно перешла в мой отдел.

В последнее время я читал статьи о лучших практиках code review и заметил, что эти статьи фокусируются на поиске багов, практически игнорируя другие компоненты ревью. Конструктивное и профессиональное обсуждение обнаруженных проблем? Неважно! Просто найди все баги, а дальше само сложится.

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

Моя революционная книга обучит вас проверенным техникам по выявлению максимального количества недостатков в своём партнёре. Книга не затрагивает следующие области:

• Обсуждение проблем с сочувствием и пониманием.
• Помощь партнёру в устранении недостатков.

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

Как вам нравится такая книжка? Предполагаю, что она вам не очень по душе.

Идемпотентность — звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

От переводчика: этот текст — перевод записи в личном блоге Михаэля Штапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.

---

Этот пост было сложно написать с эмоциональной точки зрения, но я и не ограничился «коротким письмом, потому что у меня не было времени». Пожалуйста, перед прочтением этого текста учтите, что пишу я его с лучшими намерениями и не ставлю себе целью демотивировать или принизить вклад кого-то из разработчиков. Скорее, я хочу объясниться, почему мой уровень разочарования превысил все допустимые значения.

Debian был частью моей жизни на протяжении 10 лет.

Несколько недель назад, на посвященной Debian встрече, проходившей в Цюрихе, я встретился со своими старыми друзьями, которых не видел много лет. Когда я уже ехал домой на велосипеде, меня осенило, что все обсуждаемые нами темы так или иначе сводились к тому, что мы обсуждали с ними в прошлый раз. Мы дискутировали о достоинствах systemd, который вновь привлек внимание участников open source сообщества, затронули тему процессов в Debian. Кульминацией стало обсуждение демократии как таковой и соответствующие теоретические и практические ошибки. Но, на самом деле, это уже чисто швейцарская тема.

Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian и подходит ли он мне.

Итак, я принял решение, которое должен был принять давно: я сворачиваю свое участие в развитии Debian.

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

Внимание! Данный пост не призывает заниматься самолечением и самодиагностикой, не носит рекламного характера и служит исключительно просветительским целям.


Несмотря на акцент на болях в области поясницы в целом все написанное применимо в контексте болей и в других отделах позвоночника.

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

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

Можно долго спорить на тему, стоит ли давать маленьким детям доступ к планшетам и смартфонам. Кто-то говорит что это вредно для глаз или для психики, кто-то — что родителям надо бы самим играть и читать с детьми, а не пытаться отгородится от них гаджетами. Что характерно, чаще всего такое говорят люди, у которых своих детей нет. И которые не знают, какое это блаженство — когда чадо замолкает хотя бы на полчаса, перестает крушить все вокруг, спокойненько лежит на диване и смотрит мультики. Есть и еще один аргумент — дети чутко все повторяют за родителями, если родители непрерывно сидят уткнувшись в телефон, то очень сложно объяснить детям, почему родителям можно, а им — нет.

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

К сожалению, я очень быстро уяснил, что детский ютуб — это просто АДОВЫЙ ТРЕШ. Про это даже на Хабре уже был перевод статьи. Детские каналы — это какие-то бездонные клоаки, наполненные вырвиглазными видео типа "разворачиваем сто киндер-сюрпризов", "дурацкие стишки с убогой 3д графикой под крикливую музыку" и "гоняем машинки в Beam NG под дурацкие комментарии". По какой-то причине все это является очень привлекательным для маленьких детей, которые бросаются кликать на такие видео как только увидят их в рекомендованных. А YouTube не позволяет управлять рекомендациями. Даже дав своему сыну планшет с включенными "нормальными" мультиками, я уже через пару минут наблюдаю, как он за два клика по рекомендациям опять находит эти чертовы шоколадные яйца и снова начинает в них залипать.

Все, с меня хватит, решил я. И начал пилить свое приложение для просмотра ютуба, позволяющее выбрать список каналов и показывающее только видео с этих каналов. Как я это делал — под катом.

Когда я сижу, у меня болит спина.

Это происходит уже последние 10 лет. И неважно, где я нахожусь – на работе, в ресторане, даже дома на диване. Моя поясница кричит: «Прекрати сидеть!»

Чтобы уменьшить боли в спине, на работу я купила себе коленный стул. Потом стол для работы стоя. Потом вернулась к обычному стулу, потому что мне стало больно стоять.

Я ходила к врачам, хирургам-ортопедам и специалистам по боли. Я освоила пилатес, увеличила свою гибкость и силу мускулов. В какой-то момент мой пресс стал таким сильным, что муж стал называть его «дощечкой».

Эти средства немного помогли – сначала. Но боль так и не ушла. Поэтому несколько лет назад я решила принять это как должное: сидячее положение причиняет мне боль, и так будет всегда.

Мы знаем, что от глаукомы не застрахован никто.

Число больных глаукомой во всем мире более 100 миллионов (!) человек. Девять из десяти слепых живёт в развивающихся странах, и две трети из них могли бы быть вылечены, начни они лечится вовремя.

Глаукома является второй после катаракты причиной слепоты — до 20% всех случаев заболевания заканчиваются ею. Часть людей не догадывается о болезни. Выявляется часто глаукома на 2-3 й или на последней, 4-й стадии, когда помочь человеку часто уже невозможно. В России глаукома с недавних пор стала первой причиной безвозвратной слепоты, обогнав травматизм и сосудистые заболевания глаза.

Несмотря на серьёзный прорыв в понимании многих проблем глаукомы за последние несколько лет, надо признать, что до сих пор не предложено никаких эффективных методов предупреждения заболевания, его раннего (достаточно дешёвого метода!) выявления и доступных повсеместно способов лечения.

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


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

Среди глазных заболеваний есть те, которые особенно опасны. Они протекают вначале бессимптомно — ничего не болит, жалоб нет, могут «маскироваться» под другие «легкие» болезни и, самое главное, появиться в любом возрасте и безвозвратно «уничтожить» зрение.

Представьте, прикрыли вы левый глаз случайно, а правым то все «как в тумане»! Читаете в интернете как себе помочь или звоните друзьям, а они — не переживай, проморгается. Пока ждали — вроде бы и правда туман прошел. Вот так периоды беспокойства повторяются, но на первых порах мало тревожат. А он (убийца) начал свое коварное дело. Причем как правило на обоих глазах, даже если второй никак не беспокоит! И возраст не помеха — дети также подвержены этому заболеванию — 10% детей слепнут именно от глаукомы.

Глаукома достаточно распространена во всех странах — в 15% случаев слепоты причиной является именно она. Это ставит ее на второе место среди причин неизлечимой слепоты!

А все почему — потому что человеческий мозг очень хорошо «замещает» провалы в поле зрения, если они возникают постепенно, адаптируется и только когда 30-40% от зрительного нерва погибло начинается ощущение «тумана». А все — привет, потерянное невозобновимо!

Ну или почти вся...

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

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

Anyone can wield an axe, but it takes a true warrior to make it sing melees melody.

Я предполагаю, что читатель знаком с epoll, по крайней мере прочел страницу man. О epoll, poll, select написано достаточно много, чтобы каждый кто разрабатывал под Linux, хоть раз о нем слышал.

Несколько недель назад специалисты по информационной безопасности предупредили об опасном зловреде, получившем название VPNFilter. Как оказалось, главной целью этого malware являются роутеры самых разных производителей. Одной из первых на VPNFilter обратила внимание команда специалистов по инфобезу из Cisco Talos.

Зловред постоянно совершенствуется разработчиками. Недавно был обнаружен новый модуль, который использует тип атаки man-in-the-middle в отношении входящего трафика. Злоумышленники могут модифицировать трафик, проходящий через роутер. Также они без проблем могут перенаправлять любые данные на свои сервера. Модуль вируса получил название ssler.

Расскажу о профессиональной эмиграции разработчика в Финляндию. У меня никогда не получалось писать кратко, а тема очень большая, но попробую :)



Я переехал в Финляндию полгода назад, причем не в Хельсинки, как большинство, а в небольшой город Вааса на западном побережье — население 65 тыс. Финляндию я до этого давно и прочно любил, жил в Питере и последние несколько лет постоянно туда катался и изучал страну — примерно 35 въездов в нее туристом было.

Зачем НЕ нужно переезжать в Финляндию

Финляндия — несмотря на благополучие, страна не для каждого.

Во-первых, здесь НЕ стоит ждать очень высоких зарплат, не в IT по крайней мере. ЗП разработчиков хорошие, значительно выше среднего по стране, но далеко не огромные. После налогов они сравнимы с обычными московскими или хорошими питерскими, при более высокой (хотя и не в разы) стоимости жизни. В некоторых странах Европы были бы больше, в Штатах — сильно больше. Зарплат вполне хватает для более чем достойной жизни (ипотека-машина-путешествия-хобби), но богатым тут стать трудно.

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

Проблемы, симптомы

Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.

Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.

У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.

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

Лайфхак по 152-ФЗ

Для начала небольшое, но важное отступление.

Недавно знакомый из торговой компании попросил посмотреть их договор с веб-студией. Те собирались дорабатывать сайт магазина. Первым делом я открыл техзадание и увидел, что ребята планируют зарегистрировать владельца сайта в Роскомнадзоре как оператора персональных данных. Я подумал: «Они это серьезно?» И сам же ответил: «К сожалению, да».

Это 4-я статья из цикла переводов текстов зарубежных представителей опенсорс движения. Значительная часть предыдущих статей была посвящена анализу причин, мешающих разработчикам активнее участвовать в OS проектах.


Сегодняшний текст посвящен поиску решения одной из ключевых проблем опенсорса: трудности финансирования проектов. Мне эта статья понравилась в первую очередь сравнительным анализом различных способов привлечения денег на опенсорс разработку — что, конечно, не умаляет прочих ее достоинств.

Было бы очень интересно узнать об опыте читателей – пользовались ли вы какими-либо из описанных автором сервисами/инструментами? Какие увидели преимущества/недостатки, что сработало/не сработало?

Приятного чтения!