DataArt давно дружит с командой ИТМО по спортивному программированию и помогает ей. Этим летом в гости в наш петербургский центр разработки пришли Илья Збань, Иван Белоногов и Владимир Смыкалов. Чемпионы мира 2017 года рассказали о том, как именно программисты соревнуются между собой, о тренировочных сборах, любимых задачах и сильнейших соперниках.

Олимпиада по программированию

Главное соревнование программистов — международная студенческая олимпиада под эгидой ACM (ACM-ICPC, или просто ICPC) — проходит с 1970-х, а в виде, близком к сегодняшнему, оформилась в 1989 году. Олимпиада предназначена для студентов и аспирантов, за редким исключением к соревнованиям не допускают программистов старше 24-х лет. К тому же, испытывать силы в финале можно только дважды, а в региональных отборах разрешается участвовать всего пять раз. На ранних этапах, проходящих по всему миру, соревнуются тысячи команд. Около сотни лучших доходят до финала.

Прошлогодний троянец-криптолокер Petya, конечно, многое умеет – ломает MBR и шифрует MFT, но сделаться столь же знаменитым как его эпигоны, у него не вышло. Но вся эта история с клонами – уничтожителями данных, видимо, настолько расстроила Януса, автора первенца, что тот взял и выложил закрытый ключ от него.

Однако опубликовал не просто так «нате, владейте!», а решил подойти к процессу творчески и поиграть с «белыми шляпами», запаролив архив и оставив в своем твиттере ссылку на него с подсказкой в виде цитаты из фильма «Золотой глаз». Авось, хотя бы так заметят и запомнят. Автор, видимо, фанат бондианы – отсюда и его никнейм, и название файла с ключом (Natalya), и имена троянцев Petya и Misha. Быстрее всех загадку отгадали в Malwarebytes и выложили содержимое файла:

Congratulations!
Here is our secp192k1 privkey:
38dd46801ce61883433048d6d8c6ab8be18654a2695b4723
We used ECIES (with AES-256-ECB) Scheme to encrypt the decryption password into the "Personal Code" which is BASE58 encoded.


В последнее время я вижу, как довольно большое количество людей применяет контейнерную виртуализацию только для того, чтобы запереть потенциально небезопасное приложение внутри контейнера. Как правило, используют для этого Docker из-за его распространенности, и не знают ничего лучше. Действительно, многие демоны первоначально запускаются от имени root, а далее либо понижают свои привилегии, либо master-процесс порождает обрабатывающие процессы с пониженными привилегиями. А есть и такие, которые работают исключительно от root. Если в демоне обнаружат уязвимость, которая позволяет получить доступ с максимальными привилегиями, будет не очень приятно обнаружить злоумышленников, уже успевших скачать все данные и оставить вирусов.
Контейнеризация, предоставляемая Docker и другим подобным ПО, действительно спасает от этой проблемы, но также и привносит новые: необходимо создавать контейнер для каждого демона, заботиться о сохранности измененных файлов, обновлять базовый образ, да и сами контейнеры часто основаны на разных ОС, которые необходимо хранить на диске, хотя они вам, в общем-то, и не особо нужны. Что делать, если вам не нужны контейнеры как таковые, в Docker Hub приложение собрано не так, как нужно вам, да и версия устарела, SELinux и AppArmor кажутся вам слишком сложными, а вам бы хотелось запускать его в вашем окружении, но используя такую же изоляцию, которую использует Docker?

Capabilities

В чем отличие обычного пользователя от root? Почему root может управлять сетью, загружать модули ядра, монтировать файловые системы, убивать процессы любых пользователей, а обычный пользователь лишен таких возможностей? Все дело в capabilities — средстве для управления привилегиями. Все эти привилегии даются пользователю с UID 0 (т.е. root) по умолчанию, а у обычного пользователя нет ни одного из них. Привилегии можно как дать, так и отобрать. Так, например, привычная команда ping требует создания RAW-сокета, что невозможно сделать от имени обычного пользователя. Исторически, на ping ставили SUID-флаг, который просто запускал программу от имени суперпользователя, но сейчас все современные дистрибутивы выставляют CAP_NET_RAW capability, которая позволяет запускать ping из-под любого аккаунта.
Получить список установленных capabilities файла можно командой getcap из состава libcap.

% getcap $(which ping)
/usr/bin/ping = cap_net_raw+ep

Флаг p здесь означает permitted, т.е. у приложения есть возможность использовать заданную capability, e значит effective — приложение будет ее использовать, и есть еще флаг i — inheritable, что дает возможность сохранять список capabilities при вызове функции execve().
Capabilities можно задать как на уровне ФС, так и просто у отдельного потока программы. Получить capability, которая не была доступна с момента запуска, нельзя, т.е. привилегии можно только понижать, но не повышать.
Также существуют биты безопасности (Secure Bits), их три: KEEP_CAPS позволяет сохранить capability при вызове setuid, NO_SETUID_FIXUP отключает перенастройку capability при вызове setuid, и NOROOT запрещает выдачу дополнительных привилегий при запуске suid-программ.

Тихо и незаметно (с), вышел Python версии 3.5! И, безусловно, одно из самых интересных нововведений релиза является новый синтаксис определения сопрограмм с помощью ключевых слов async/await, далее в статье об этом.

Поверхностный просмотр «PEP 0492 — Coroutines with async and await syntax» поначалу оставил у меня вопрос «Зачем это надо». Сопрограммы удовлетворительно реализуются на расширенных генераторах и на первый взгляд может показаться, что все свелось к замене yield from на await, а декоратора, создающего сопрограмму на async. Сюда можно добавить и возникающее ощущение, что все это сделано исключительно для использования с модулем asyncio.

Но это, конечно же, не так, тема глубже и интереснее.

Это первая статья из небольшой серии, посвященной программированию на C# в функциональном стиле. Серия не про LINQ, как можно было бы подумать, а про более фундаментальные вещи. Навеяно F#-ом.

• Functional C#: Immutability
  
• Functional C#: Primitive obsession
  
• Functional C#: Non-nullable reference types
  
• Functional C#: работа с ошибками
  

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

Микросервисы дают преимущества…	…ценою издержек
Жесткие границы модулей Strong Module Boundaries Микросервисы усиливают модульную структуру, что особенно важно для больших команд разработчиков.	Распределённость Distribution Распределенные системы тяжелее программировать, поскольку удаленные вызовы медленные и всегда рискуют неудачей-отказом.
Независимый деплоймент Independent Deployment Простые сервисы проще деплоить, и, поскольку они автономны, меньше вероятность отказа системы в случае, если что-то идет не так.	Консистентность в конечном счете Eventual Consistency Поддержка cтрогой консистентности чрезвычайно сложна для распределённых систем, и это означает, что придется иметь дело с консистентностью в конечном счете.
Технологическое разнообразие Technology Diversity С микросервисами вы можете смешивать несколько языков, фреймворков и технологий хранения данных.	Эксплуатационная сложность Operational Complexity Вам потребуется опытная команда эксплуатации для управления множеством сервисов, которые будут регулярно редеплоиться.

В апреле 2001 Пол Грэм написал статью «Превосходя посредственность» («Beating the averages» — ориг).

Этот пост о том, почему Go, следуя статье, и есть то самое секретное оружие, которое должно быть у каждого стартапа.

Секретное оружие

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

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

Когда говорят, что инновации Made in Russia — это только спорные проекты вроде «Ё-мобиля» паровоза Черепановых, однозначно неоспоримые вроде космических ракет и прочих полу- и совсем неполу-военных изделий, или голые идеи на экспорт — не верьте. У нас есть чем похвастать, и мне за это гордо.

За прошедшие XX-надцать лет моя компания выросла из мелкого местечкового мухомора в топы рейтингов IDC и верхне-правильный угол «магического квадрата» Гартнера. Красивый офис на главной улице страны, Слон Дали на ресепшене, почти 3 тысячи человек в штате, 30+ офисов по всему миру… и прочие хвалилки. Но здесь не про это.

Почему это получилось? Много причин. Например, мой неизменный принцип: пробовать, пытаться и не бояться ошибок. А еще ― партнёрская программа, работа с ритейлерами, онлайнерами, столицами и провинциями ― там много чего было, но и это не по данной теме.

Все перечисленное — вторично (да простят меня те, кто несёт эту службу). Первично — наши технологии и продукты (в смысле, просто софт, а не «софт+всё остальное»). Поскольку если есть софт — всё остальное можно настроить. Если же нет главного — товара, — то всё остальное нет смысла строить. Иначе бизнес (продажи) будет либо одноразовым, либо коррумпированным, что мне претит категорически и фатально.



Итак, софт. Чем здесь можно гордиться? Есть чем! Расскажу вам, уважаемые хабравчане, про «Шестёрку».

Данная статья будет интересна тем, кто вдруг осознал, что ему хочется
попробовать создать что-то без навязанного обществом JEE и Spring.

Вы, о дорогой Java Смельчак, не хотите быть винтиком в огромном механизме вашего Фреймворка?
Вам надоело чувствовать себя «машинисткой» по написанию конфигов и настроек?
Вы хотите решать задачи так, как хочется вам, а не так, как это видится автору унифицированной на нужды
миллионов библиотеки?

Тогда добро пожаловать под кат, где я поделюсь с вами полезными находками Мира без Фреймворка.

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

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

Мне очень нравится Yii Framework. Он быстрый, удобный, гибкий. Мне нравится, как реализован в нём паттерн ActiveRecord. Но бывают случаи, когда бизнес-логика, а, если быть точным, доменная логика, очень сложная и постоянно растёт и модифицируется. В таких случаях удобнее пользоваться паттерном DataMapper.

В тоже время мне нравится Doctrine 2 ORM. Это пожалуй самая мощная ORM для PHP, имеющая широчайший функционал. Да, возможно, она «тяжеловата» и замедляет работу приложения. Но начиная разработку, прежде всего стоит думать об архитектуре приложения, так как «преждевременная оптимизация корень всех бед»

Таким образом, однажды мне пришла в голову мысль связать 2 этих интересных мне инструмента. Как это было сделано, описано ниже.

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

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

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

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

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

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

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

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

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

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

Большие и популярные сайты

Behance - работы лучших дизайнеров со всего мира

Даже относительно ограниченный набор возможностей CSS дает нам много возможностей в типографике, которые можно реализовать, используя каскадные таблицы стилей. Антиква или гротеск? Большой или маленький шрифт? Интерлиньяж, апрош, размер шрифта и всевозможные отступы… Список можно продолжать до бесконечности.

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

В конечном счете, мы выделили 13 общих проблем и вопросов, имеющих отношение к типографическим проектам, и попробовали найти ответы на них в нашем исследовании:

1. Насколько популярны шрифты с засечками и без засечек в заголовках и основном тексте?
2. Какие шрифты используются наиболее часто?
3. Каков средний кегль для шрифта?
4. Каково, в среднем, соотношение между размером шрифта в заголовке и в основном тексте?
5. Чему равно среднее значение интерлиньяжа для основного текста?
6. Каково усредненное соотношение между значением интерлиньяжа и размером шрифта для основного текста?
7. Чему равно среднее значение соотношения между интерлиньяжем и длиной строки?
8. Каковы, в среднем, отступы между абзацами?
9. Каково усредненное соотношение значений отступа между абзацами и интерлиньяжем?
10. Как выделяются стилистически ссылки?
11. Сколько символов обычно используется в строке?
12. Как часто ссылки выделяются подчеркиванием?
13. Как часто используется замещение шрифтов (sIFR и прочие)?

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

Недавно встала задача повышения безопасности при создании токена, а также поддержки sha512. Статья получилась узконаправленная, но я уверен, что сталкиваюсь с подобным не только я.

Для решения текущих задач при программировании API интернет-магазина на Symfony2 решил подружить FOSUserBundle и WSSEAuthenticationBundle c алгоритмом sha512 и вскоре выяснил, что для этого потребуется небольшая доработка. Об этом и пойдет речь в моей статье.

Задача: как получить деньги от другого человека здесь и сейчас?

Вы оказываете услуги, но при этом не предприниматель. Вы решили что-то продать. Вы расплачиваетесь за всех. Вам нужно погасить задолженность по кредитной карте. Вот лишь небольшой список тех ситуаций, когда нужно передать деньги от одного человека другому.
Вообще вариантов передачи денег несколько: отдать наличными, перевести электронными деньгами, оформить платеж через интернет-банк, сделать перевод с банковской кары на банковскую карту Visa или Mastercard. Каждый способ по-своему хорош, но карты все же рулят!
Мне было интересно сделать review российских сервисов P2P-переводов по банковским картам.

На Июль 2013 г. найдено 6 сервисов по переводу средств с карты на карту по технологиям Visa Money Transfer® и MasterCard MoneySend®:

• MasterCard Mobile
• Qiwi
• Альфа- Банк
• RuRu
• PayOnline
• Русский Стандарт

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

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