что больше deadbeef или abadbabe и почему
Очный отборочный этап: организационные вопросы и примеры заданий
К нам довольно часто поступает вопрос:
«Каким образом проходит поступление в IT ШКОЛУ SAMSUNG?»
Во всех регионах России это проходит одинаково: в начале необходимо подать заявку на сайте, затем пройти заочное онлайн-тестирование в системе «Абитуриент», а затем, ближе к началу учебного года (обычно, начало сентября) наступает самый важный этап поступления: очное вступительное тестирование.
Хотим обратить внимание, что задания для него составляются самостоятельно каждой площадкой IT ШКОЛЫ SAMSUNG, что исключает возможность массового списывания. Для нас важно, чтобы абитуриенты умели самостоятельно решать выданные им задания, так как во время учебного процесса их будут ждать гораздо более сложные вещи.
Как проходит отборочный этап?
Он проходит на площадке IT ШКОЛЫ SAMSUNG — в МОУ СШ № 103 Советского района г. Волгоград в кабинетах 2-4 и 2-5 на втором этаже школы. О точной дате и времени проведения очного отборочного этапа будет сообщено ближе к сентябрю по электронной почте и в SMS-рассылке. Всем абитуриентам будет выдан бумажный тест, разделённый на 5 разделов. В каждом из них нужно либо ответить на вопрос (все задания — без вариантов выбора ответа), либо написать код. Всего за очный отборочный этап можно набрать 50 баллов. Кол-во выдаваемых баллов за каждое задание зависит от его сложности и может очень сильно разниться.
Отметим сразу, что мы не ограничиваем абитуриентов в выборе языка программирования. Вы можете продемонстрировать знание любого и это никак не повлияет на выставляемые баллы. Самое главное: написанный код должен верно исполнял свою задачу.
Ниже, мы покажем вам примеры задач из нашего очного тестирования. В качестве практикума, мы рекомендуем решить их самостоятельно.
Раздел 1: Математика, логика, системы счисления.
В данном разделе важно знать информатику и уметь считать в различных системах счисления.
Пример 1.1:
Во сколько раз увеличится 65 в семеричной системе счисления, если справа приписать 00? Ответ дайте в десятичной системе счисления.
Пример 1.2:
Перечислите в порядке возрастания первые 6 натуральных чисел, трёхзначных в шестнадцатеричной форме, содержащих ровно 2 буквы, причём разные. Числа должны быть записаны в 16-ой системе счисления через запятую.
Раздел 2: Алгоритмы
Задания данного раздела созданы для проверки алгоритмического мышления, которое немало важно для любого программиста. Реальный код на каком-либо языке программирования писать не требуется, достаточно «псевдокода» или описания алгоритма в виде текста, либо диаграммы.
Пример 2.1:
Приведите алгоритм нахождения наименьшего из 3-х значений (переменных).
Пример 2.2:
Приведите алгоритм нахождения наименьшего из 100 чисел.
Раздел 3: Поиск и анализ информации
Как только абитуриент приступает к данному разделу, мы выдаём устройство с доступом к сети Интернет. Цель данного раздела: проверить навыки поиска во «всемирной паутине». Любой программист должен уметь свободно пользоваться поисковыми машинами и уметь находить различную информацию, иногда спасающему ему очень много свободного и рабочего времени.
Пример 3.1:
Что больше DeadBeef или aBadBabe и почему?
Пример 3.2:
Напишите численное значение для желтого цвета в цветовой модели RGB.
Раздел 4: Навыки программирования
Ответы на задания данного раздела должны быть написаны на реальном языке программирования. Абитуриенту разрешено скомпилировать и отладить программу на выданном ему устройстве.
Пример 4.1:
Программист Троко решал следующую задачу: Даны три целых числа. Выведите наибольшее из данных чисел (программа должна вывести ровно одно целое число). Однако Троко допустил ошибку, и никак не может найти ее. Он просит Вас помочь ему, найти тест, на котором его программа работает некорректно (получает любой вердикт, отличный от ОК). Для этого он предоставляет Вам свой код на языке программирования Java:
Задание: укажите три целых числа, при которых программа будет работать неверно.
Пример 4.2:
Написать программу, определяющая, бьет ли ладья, стоящая на клетке с указанными координатами (номер строки и номер столбца), фигуру, стоящую на другой указанной клетке.
Требуется вывести слово YES, если ладья способна побить фигуру за 1 ход, в противном случае вывести слово NO.
Входные данные: 1 1 5 5 Выходные данные: NO
Входные данные: 3 2 2 2 Выходные данные: YES
Раздел 5: Анкета
В этом разделе мы собираем общую информацию об абитуриенте. Нужно будет написать: почему вы решили пойти в IT ШКОЛУ SAMSUNG, как узнали о нас и когда будет удобно посещать занятия.
А что после теста?
Далее, после проверки работ абитуриентов составляется общий рейтинг. Чем больше баллов на очном вступительном испытании вы набрали, тем выше ваше место в рейтинге. План набора в волгоградской IT ШКОЛЕ SAMSUNG составляет 32 человека — это два учебных класса, занимающихся в разные дни недели (занятия проходят два раза в неделю).
Обычно, мы зачисляем первых людей из рейтинга, однако, некоторые могут сразу отказаться от обучения, либо их свободное время не позволяет посещать занятия вместе со всеми и мы проводим донабор из более нижних мест.
Результаты прохождения (кол-во баллов) очного вступительного испытания направляются каждому абитуриенту, а чуть позже высылается статус зачисления и дата первого занятия.
обсуждение deadbeef
Данная тема посвящена обсуждению проекта deadbeef player.
нет. для wildmidi есть весомые причины тащить с собой — лицензия и критические баги. в gtk нет ни того, ни другого.
Что не так с лицензией и какие конкретно баги?
ты еще gstreamer предложи использовать, ага..
Не аргумент. И мы про ffmpeg говорим вроде. Зачем передёргивать?
запили морду на EFL
Что не так с лицензией и какие конкретно баги?
она gpl3. а плеер gpl2.
баги давно пропатчены, и подробностей не помню. помню только что было несколько сегфолтов, несколько утечек памяти, и как минимум 1 срыв стека.
Не аргумент. И мы про ffmpeg говорим вроде. Зачем передёргивать?
ffmpeg не предоставляет нужных функций и достаточной стабильности для данного проекта. он изначально использовался только как временная мера для поддержки новых либо экзотических форматов, для которых еще не успели написать плагины.
я собирался это сделать. причем несколько раз.
1й раз был еще в самом начале проекта, но оказалось, что EFL ни у кого не установлен, и релизов нет (только сборки из VCS).
2й раз был когда они релизнули 1.0
оказалось, что тулкит больше ориентирован на мобильные платформы, а для десктопа слишком примитивен. (впрочем, для мобильных он тоже далек от моего идеала)
LGPLv3, если быть точным. В чём проблема?
ffmpeg не предоставляет нужных функций и достаточной стабильности для данного проекта. он изначально использовался только как временная мера для поддержки новых либо экзотических форматов, для которых еще не успели написать плагины.
О каких функциях и какой стабильности идёт речь? Уже лет 8 использую mplayer. Серьёзных проблем со звуком не встречал.
Не тролинга ради, можешь расписать его примитивность и недостатки по сравнению с тем же гтк2?
LGPLv3, если быть точным. В чём проблема?
значит еще раз лицензию поменяли. я точно помню, что было GPL3.
версия 0.2, которую я использую, под GPL2. не LGPL.
проблема в том, что я не использую код под [L]GPL3 в своем проекте.
О каких функциях и какой стабильности идёт речь? Уже лет 8 использую mplayer. Серьёзных проблем со звуком не встречал.
функции: sample accurate seeking, gapless playback, complete tagging support, cuesheet support
стабильность: ffmpeg вылетает при попытке играть многие (кривые) файлы.
Не тролинга ради, можешь расписать его примитивность и недостатки по сравнению с тем же гтк2?
Существует какой-нибудь менеджер плейлистов для Deadbeef? При количестве больше 15-20 становится неудобно выбирать плейлист.
в git есть виджет playlist browser. показывает плейлисты в виде списка (с поиском).
На curses морду не хочешь сделать? А то мутит уже от этого блевотного GTK. Хорошо хоть, что не кути…
хочу. причем уже давно. но времени нет, к сожалению. и даже не знаю, будет ли на это время когда либо.
значит еще раз лицензию поменяли. я точно помню, что было GPL3.
проблема в том, что я не использую код под [L]GPL3 в своем проекте.
Это и не требуется.
функции: sample accurate seeking, gapless playback, complete tagging support, cuesheet support
Это функции плеера, а не библиотеки с кодеком. И да, в mad, vorbis, flac этого тоже нет.
стабильность: ffmpeg вылетает при попытке играть многие (кривые) файлы.
История потерянного коммита
Был уже вечер, когда ко мне обратился разработчик. Из мастер-ветки пропал патч — коммит deadbeef.
Мне показали доказательства: вывод двух команд. Первая из них —
— показывала изменения файла, назовём его Page.php. В него добавились метод canBeEdited и его использование.
А в выводе второй команды —
— коммита deadbeef не было. Да и в текущей версии файла Page.php не было метода canBeEdited.
Не найдя решения быстро, мы сделали ещё один патч в мастер, разложили изменения — и я решил, что вернусь к проблеме на свежую голову.
Это сделали специально? Файл переименовали?
Поиск проблемы я начал с обращения за помощью в чат команды релиз-инженеров. Они среди прочего отвечают за хостинг репозиториев и автоматизацию процессов, связанных с Git. Честно говоря, они, наверное, и патч могли удалить, но сделали бы это без следов.
—follow
Continue listing the history of a file beyond renames (works only for a single file).
(Показывать историю файла после его переименований (работает только для одиночных файлов))
К сожалению, рассматриваемый репозиторий — один из самых больших у нас. С момента внесения первого патча и до его исчезновения была совершена 21 000 коммитов. Повезло ещё, что нужный файл правился только в десяти из них. Я изучил их все и не нашёл ничего интересного.
Ищем свидетелей! Нам нужен livebear
Стоп! Мы же только что искали deadbeef? Давайте рассуждать логически: должен быть некий коммит, назовём его livebear, после которого deadbeef перестал отображаться в истории файла. Возможно, это нам ничего не даст, но натолкнёт на какие-то мысли.
Для поиска в истории Git есть команда git bisect. Согласно документации, она позволяет найти коммит, в котором впервые появился баг. На практике её можно использовать для поиска любого момента в истории, если знать, как определить, наступил ли этот момент. Нашим багом было отсутствие изменений в коде. Я мог это проверить с помощью другой команды — git grep. Ведь мне достаточно было знать, есть ли метод canBeEdited в Page.php. Немного отладки и чтения документации:
livebear [build]: Merge branch origin/XXX into build_web_yyyy.mm.dd.hh
Выглядит как обычное слияние (merge commit) ветки задачи с веткой релиза. Но с этим коммитом удалось воспроизвести проблему:
Правда, ничего интересного в livebear я не нашёл, а его связь с нашей проблемой осталась неочевидна. Подумав немного, я отправил результаты своих поисков разработчику: мы сошлись на том, что, даже если доберёмся до истины, схема воспроизведения будет слишком сложной и мы не сможем подстраховаться от чего-то подобного в будущем. Поэтому официально мы решили прекратить поиски.
Однако моё любопытство осталось неудовлетворённым.
Упорство не порок, а большое свинство
Ещё несколько раз я возвращался к проблеме, прогонял git bisect и находил всё новые и новые коммиты. Все — подозрительные, все — слияния, но это ничего мне не дало. Мне кажется, что один коммит тогда попадался мне чаще других, но я не уверен, что именно он оказался виновником в итоге.
Конечно, я пробовал и другие методы поиска. Например, несколько раз перебирал 21 000 коммитов, которые были сделаны на момент возникновения проблемы. Это было не очень увлекательно, но мне попалась интересная закономерность. Я запускал одну и ту же команду:
Оказалось, что «плохие» коммиты, в которых не было нужного кода, были в одной и той же ветке! И поиск по этой ветке быстро привёл меня к разгадке:
changekiller Merge branch ‘master’ into TICKET-XXX_description
Это тоже было слияние двух веток. И при попытке повторить его локально возникал конфликт в нужном файле — Page.php. Судя по состоянию репозитория, разработчик оставил свою версию файла, выбросив изменения из мастера (а именно они и потерялись). Прошло много времени, и разработчик не помнил, что именно произошло, но на практике ситуация воспроизводилась простой последовательностью:
Осталось понять, как легитимная последовательность действий могла привести к такому результату. Не найдя ничего про это в документации, я полез в исходники.
Убийца — Git?
В документации было сказано, что команда git log получает на вход несколько коммитов и должна показать пользователю их родительские коммиты, исключая родителей коммитов, переданных с символом ^ перед ними. Выходит, что git log A ^B должен показать коммиты, которые являются родителями A и не являются родителями B.
Код команды оказался достаточно сложным. Там в изобилии были разные оптимизации для работы с памятью, да и в целом читать код на С никогда не казалось мне очень приятным занятием. Основную логику можно представить вот таким псевдокодом:
Здесь функция get_revision принимает на вход revs — набор управляющих флагов. Каждый её вызов как будто должен отдавать следующий коммит для обработки в нужном порядке (или пустоту, когда мы дошли до конца). Ещё есть функция setup_revisions, которая заполняет структуру revs и log_tree_commit, которая выводит информацию на экран.
У меня было ощущение, что я понял, где искать проблему. Я передавал команде конкретный файл (Page.php), потому что меня интересовали только его изменения. Значит, в git log должна быть какая-то логика фильтрации «лишних» коммитов. Функции setup_revisions и get_revision использовались во многих местах — вряд ли проблема была в них. Оставалась log_tree_commit.
К моей несказанной радости, в этой функции и правда нашёлся код, вычисляющий, какие изменения были сделаны в том или ином коммите. Я думал, что общая логика должна выглядеть как-то так:
Но чем дольше я всматривался в настоящий код, тем больше понимал, что ошибся. Эта функция лишь выводила сообщения. Вот и верь после этого своим ощущениям!
Я вернулся к функциям setup_revisions и get_revision. Логику их работы было сложно понять — мешал «туман» из вспомогательных функций, часть из которых нужна была для правильной работы с указателями и памятью. Всё выглядело так, словно основная логика — это простой обход дерева коммитов «в ширину», то есть достаточно стандартный алгоритм:
Заводится список (revs->commits), туда помещается первый (самый верхний) элемент дерева коммитов. Затем постепенно из этого списка забираются коммиты с начала, а их родители добавляются в конец.
Вчитываясь в код, я обнаружил, что среди «тумана» из вспомогательных функций встречается сложная логика фильтрации коммитов, которую я так долго искал. Это происходит в функции get_revision_1:
В случае когда происходит слияние нескольких веток, если состояние файла осталось таким же, как в одной из них, нет смысла рассматривать другие ветки. Если же состояние файла не менялось нигде, мы оставим только первую ветку.
Пример. Обозначим нулём коммиты, в которых файл не менялся, единицей — те, в которых файл изменился, и X — слияние веток.
В этой ситуации код не станет рассматривать ветку feature — в ней и изменений нет. Если файл там всё-таки изменили, то в X изменения «выкинули», а значит, их история не очень релевантна: этого кода уже нет.
Что-то похожее произошло и у нас. Два разработчика сделали изменения в одном файле — Page.php, один — в ветке мастера, в коммите deadbeef, второй — в ветке своей задачи.
Когда второй разработчик сливал изменения из ветки мастера в ветку задачи, произошёл конфликт, в процессе разрешения которого изменения из мастера он просто выбросил. Прошло время, работу над задачей он завершил, и ветку задачи залили в мастер, удалив таким образом изменения из коммита deadbeef.
Сам коммит при этом остался. Но если запустить git log с параметром Page.php, коммита deadbeef в выводе видно не будет.
Оптимизация — дело неблагодарное
Я бросился внимательно изучать правила отправки изменений и багов в сам Git. Ведь я думал, что нашёл действительно серьёзную проблему: подумать только, часть коммитов просто пропадает из вывода — и это поведение по умолчанию! К счастью, правила оказались объёмными, время было позднее, а на следующее утро мой запал улетучился.
Я понял, что эта оптимизация сильно ускоряет работу Git на больших репозиториях, таких как наш. А ещё для неё нашлась документация в man git-rev-list, и это поведение можно очень легко отключить.
На самом деле, есть много способов повлиять на работу этой логики. Конкретно про флаг follow в коде Git нашёлся комментарий 13-летней давности:
Can’t prune commits with rename following: the paths change.
(Перевод: Не получится выбрасывать коммиты, когда обрабатываются переименования: пути могут меняться)
P. S.
Сам я работаю в команде релиз-инженеров Badoo уже несколько лет, и многие в компании считают, что мы разбираемся в Git.
(Перевод. Оригинал: xkcd.com/1597)
В связи с этим нам приходится разбираться с проблемами, возникающими в этой системе, и некоторые из них мне кажутся достаточно любопытными — как, например, описанная в этой статье. Очень часто проблемы решаются быстро: со многим мы уже сталкивались, что-то хорошо описано в документации. Этот случай был исключением.
На самом деле, в документации действительно был раздел History Simplification, но он был только для команды git rev-list и заглянуть туда я не догадался. Полгода назад этот раздел включили и в мануал команды git log, но наш случай произошёл несколько раньше — я просто не успевал дописать эту статью. (*)
И напоследок у меня остался небольшой бонус для тех, кто дочитал до конца. У меня есть очень маленький репозиторий, где проблема воспроизводится:
Спасибо за внимание!
(*) UPD: Оказалось, что раздел History Simplification был в документации команды git log намного дольше, чем полгода, а я его просто пропустил. Спасибо youROCK, что обратил на это внимание!
В компьютерном программировании термин « магическое число» имеет несколько значений. Это может относиться к одному или нескольким из следующего:
СОДЕРЖАНИЕ
Безымянные числовые константы
Это предпочтительно по нескольким причинам:
Допустимые виды использования
В некоторых контекстах общепринято использование безымянных числовых констант (и, возможно, «не магия»). Хотя такое принятие является субъективным и часто зависит от индивидуальных привычек программирования, ниже приведены общие примеры:
Индикаторы формата
Источник
В файлах
В протоколах
В интерфейсах
Другое использование
Ограничения типа данных
Это список ограничений типов хранения данных:
Можно создать или изменить глобальные уникальные идентификаторы (GUID), чтобы они были запоминающимися, но это крайне не рекомендуется, поскольку это ставит под угрозу их силу в качестве почти уникальных идентификаторов. Спецификации для генерации GUID и UUID довольно сложны, что делает их практически уникальными при правильной реализации. Они должны создаваться только надежным программным средством.
Идентификационные номера продуктов Microsoft Windows для продуктов Microsoft Office иногда заканчиваются на 0000-0000-0000000FF1CE («ОФИС»), например < 90160000-008C-0000-0000-0000000FF1CE >, идентификатор продукта для «Office 16 нажми и работай. Компонент расширяемости «.
Значения отладки
Известные и распространенные примеры включают:
Так как они часто использовались для обозначения областей памяти, которые были по существу пустыми, некоторые из этих терминов стали использоваться во фразах, означающих «пропал, прерван, стерто из памяти»; например, «Ваша программа DEADBEEF».
DeaDBeeF
DeaDBeeF — простой и быстрый музыкальный плеер для Linux. Поддерживает большое количество музыкальных форматов, не требователен к ресурсам компьютера, имеет простой, легкий интерфейс.
DeaDBeeF поддерживает плагины (расширения), настраиваемые горячие клавиши.
Название
Интерфейс
Интерфейс DeaDBeeF очень простой и не перегруженный.
В верхней части расположено меню программы, ниже кнопки управления проигрывателем, ниже плейлисты.
Можно открыть несколько плейлистов в разных вкладках.
Установка
Установка через Snap
Установка в ArchLinux из AUR
Установка в openSuse
Установка в Gentoo
Разработка
Ведущий разработчик и основатель программы — программист Алексей Яковенко.
Программа написана на C с использованием библиотек GTK+.
DeaDBeeF полностью переведен на русский язык, включая теги у mp3 файлов.
С 2011 года существует версия DeaDBeeF под Android.
Программа кроссплатформенная
Работает в:
Релизы программы DeaDBeeF
| Версия | Дата релиза | |
|---|---|---|
| .. | ||
| 0.5.1 | ||
| .. | ||
| 0.6.0 | ||
| .. | ||
| 0.7.2 | ||
| 1.8.0 | 06 апреля 2019 | пресс-релиз |
| 1.8.1 | 23 июля 2019 | |
| 1.8.2 | 01 августа 2019 | |
| 1.8.3 | 19 марта 2020 | |
| 1.8.4 | 28 июня 2020 | пресс-релиз |
| .. | ||
| 1.8.8 | 01 августа 2021 | пресс-релиз |
Скачать программу:
Скриншоты программы
Главное окно проигрывателя DeaDBeeF
Комментарии
А так плеер хорош, сам пользуюсь периодически (потому что процентов 70 музыки я слушаю из сети). Все его сравнивают с Foobar2000, но мне он напоминает больше Apollo37. Очень винрарный был (хотя и сейчас можно найти) плеер, никакой фубар не сравнится.
>не буду его устанавливать из принципа
>русский программист пишет программу с английским интерфейсом и без поддержки русского интерфейса
Ну а что ему делать, если он решил ориентироваться на англоязычных пользователей, которые ему _заплатят_ в отличии от подавляющего большинства русскоязычных?
Я сам не могу называть себя программистом в полной мере, но вот такое отношение пользователей (особенно в странах бывшего СССР) частенько выбешивает до белых глаз: «сделай мне хороший программный продукт на халяву, а то не установлю твой хороший—и-бесплатный-но-с-рекламой продукт из принципа.»