В этом посте мы хотели бы еще раз поднять тему программирования без блокировок, сперва дав ему определение, а затем выделить из всего многообразия информации несколько ключевых положений. Мы покажем, как эти положения соотносятся между собой, с помощью блок-схем, а потом мы немного коснемся деталей. Минимальное требование к разработчику, постигающему lock-free, — умение писать правильный многопоточный код, используя мьютексы или другие высокоуровневые объекты синхронизации, например, семафоры или события.

Не так давно мне предложили вести курс основ теории алгоритмов в одном московском лицее. Я, конечно, с удовольствием согласился. В понедельник была первая лекция на которой я постарался объяснить ребятам методы оценки сложности алгоритмов. Я думаю, что некоторым читателям Хабра эта информация тоже может оказаться полезной, или по крайней мере интересной.

Фьютекс (futex — сокращение от «Fast userspace mutex») — это механизм, предложенный разработчиками Linux из IBM в 2002 году и вошедший в ядро в конце 2003 года. Основной идеей было предоставить более эффективный способ синхронизации пользовательских потоков с минимальным количеством обращений к ядру ОС.

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

Важный момент: фьютексы — это достаточно низкоуровневый инструмент, напрямую его использовать стоит лишь при разработке фундаментальных библиотек, вроде стандартной библиотеки C/C++. Очень маловероятно, что вам понадобится использовать фьютексы в обычном прикладном приложении.

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

Всем привет. Я — обычный программист, носящий лычку сеньора в одной обычной продуктовой компании. Я занимаюсь коммерческой разработкой около 10 лет, начинал с разработки прошивок для небольших железок, а сейчас изготавливаю бекенды различной степени сложности преимущественно на модных нынче Java/Kotlin. Эту профессию я выбрал по призванию — будучи ещё школьником все время что-то паял, программировал на бумажке (компьютера не было) и всё такое. Дальше шли профильное образование, работа в различных компаниях — именитых и обычных, зарубежных и отечественных. Поэтому я могу сказать, что являюсь идейным программистом. И никогда не понимал людей, которые ждут пятницу — всегда с удовольствием ходил на работу, какой бы ад там не творился. Так было по-крайней мере до недавнего времени. С какого-то момента я “сломался” и с трудом мог заставить пойти себя на некогда любимую работу. Меня и раньше что-то смущало, но теперь, когда мысли до конца оформились в голове — я могу сказать, что же не так с моим некогда уютным IT-мирком.

В последнее время GraphQL набирает всё большую популярность, а вместе с ней растёт и интерес со стороны специалистов информационной безопасности. Технологию используют такие компании, как: Facebook, Twitter, PayPal, Github и другие, а это значит, что пора разобраться, как тестировать такое API. В этой статье мы расскажем о принципах этого языка запросов и направлениях тестирования на проникновение приложений с GraphQL.

В версии Windows Server 2003 SP1 была представлена технология, называемая «хотпатчингом». То есть обновление системы «на лету», без необходимости ее перезагрузки. Технология позволяет устанавливать патчи на отдельные функции (как пользовательские, так и режима ядра). В версии 8.1 возможность установки хотпатчей была ликвидирована. Примечательно, что использовать данную возможность можно из user-mode'a даже в случае kernel-mode патчей.

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

Решил разрабатывать MiniFilter драйвер, конфигурируемый при помощи текстового файла.

Рассмотрим, что из себя в общем виде представляет MiniFilter:

Фильтрация осуществляется через так называемый Filter Manager, который поставляется с операционной системой Windows, активируется только при загрузке мини фильтров. Filter Manager подключается напрямую к стеку файловой системы. Мини фильтры регистрируются на обработку данных по операциям ввода/вывода при помощи функционала Filter Manager, получая, таким образом, косвенный доступ к файловой системе. После регистрации и запуска мини фильтр получает набор данных по операциям ввода/вывода, которые были указаны при конфигурировании, при необходимости может вносить изменения в эти данные, таким образом влияя на работу файловой системы.

Я чёртовы сутки просидел над таской. Нужно было спроектировать самостоятельный модуль, а людям с тяжелой формой перфекционизма нельзя давать задачи на проектирование.

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

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

В понедельник утром я отправил пулл реквест. Его приняли с восторгом. Но способ, на который я пошел… вот уж никогда не думал, что отважусь на такое.

Как может показаться, анализ сигналов и данных — тема достаточно хорошо изученная и уже сотни раз проговоренная. Но есть в ней и некоторые провалы. В последние годы словом «энтропия» бросаются все кому не лень, толком и не понимая, о чем говорят. Хаос — да, беспорядок — да, в термодинамике используется — вроде тоже да, применительно к сигналам — и тут да. Хочется хотя бы немного прояснить этот момент и дать направление тем, кто захочет узнать чуть больше об энтропии. Поговорим об энтропийном анализе данных.

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

UPDATE 2018-02-04: Еще одна мудрость со временем накипела: если хочется полной свободы выбора компаний любого размера, то лучше сразу говорить, что вы нашли хорошую компанию по релокейту и всё, что требуется, это финансовая поддержка. Деньги тут есть (особенно у страртапов), а времени — нет.

UPDATE 2017-03-19: По опыту двоих приятелей из Берлина (из России и Коста-Рики) могу обнадёжить, голубую карту могут сначала не дать, а через полгода таки дать прямо в Германии. Немцы тоже люди и их чиновники тоже умеют и искренне заблуждаться, и нарочно упираться.

UPDATE 2017-01-08: год спустя поимел опыт поиска и найма фронтендеров для двух компаний. Заявляю, что хорошего кандидата, подписавшего договор, готовы ждать месяц-два. Меня один средних размеров стартап согласился ждать 4 месяца после очного интервью. Так что заехать себя показать, а потом начать удаленно и через пару месяцев перебраться — вообще шоколад.

UPDATE 2016-09-02: полгода спустя немного подросла нижняя планка з/п для голубой карты, а остальное пока в силе.

UPDATE: по просьбе chilicoder добавляю ремарку: «автор смог переехать и найти работу даже без признанного диплома».

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

Представьте что в Роскосмосе решили собрать новую ракету не имея при этом чертежей и четкого понимания как ракета должна быть устроена. Отдельный завод занимается корпусом ракеты, отдельный выпускает двигатели, еще один — сопла. Главный менеджер Роскосмоса сказал что он доверяет профессионалам, и мастерски сделегировал всю работу заводам.



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

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

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

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

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

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.

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

«Фаззинг – методика тестирования, при которой на вход программы подаются невалидные, непредусмотренные или случайные данные.» © Habrahabr

Ключевое слово const — одно из самых многозначных в C++. Правильно использование const позволяет организовать множество проверок ещё на этапе компиляции и избежать многих ошибок из числа тех, которые бывает трудно найти при помощи отладчиков и/или анализа кода.

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

Не так давно в «Часкоре» была опубликована статья «Воспоминания экс-спамера». В ней один из интернет-предпринимателей, зарабатывавших на спаме во «В Контакте», объявил о том, что у такого бизнеса очень скоро почти не останется воздуха.

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

Будучи на конференции Qt Developer Days 2010 я узнал, что одним из самых популярных вопросов на собеседовании в разные зарубежные компании, работающие с Qt библиотекой, является вопрос о различиях в способах приведения типов в C++. Поэтому здесь я рассмотрю основные различия между static_cast, dynamic_cast, const_cast, reinterpret_cast, C-style cast, qobject_cast и qvariant_cast

Это третья часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»

Одно из преимуществ использования Mercurial — возможность работать командой над одним кодом. Mercurial позволяет каждому работать независимо и помогает объединять сделанные изменения.

Часть 3. Привыкаем работать в команде

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