SEWiki - Вклад участника [ru]

Devdays Весна 2018

2018-04-26T18:35:38Z

Alexandra:

Чтобы править эту страницу, нужно залогиниться в Sewiki. Тогда сверху будет кнопочка "править". Если у вас нет учётной записи — напишите Игорю желаемый логин.

Редактировать wiki одновременно нескольким людям стоит осторожно: после внесения правки проверьте, что она действительно сохранилась.

== Пример ==

Описание

== Квест-бот для телеграмма ==

Есть культовая серия игр конца 90-х - первой половины 00-х "Космические рейнджеры". Один из компонентов игры - текстовые квесты, очень увлекательная и разнообразная штука от простых логических задач в стиле загадки Эйнштейна до симуляторов дальнобойщика и зэка. Было бы здорово портировать эти квесты в телегу, неплохая такая развлекаловка. [https://yadi.sk/i/jb88tQju3UhBMS Презентация проекта в формате pdf]

Кодим на питоне.

Предложил: Чернышев Ярослав

== SpaceChem на Android ==

Есть замечательная игрушка SpaceChem ([http://store.steampowered.com/app/92800/SpaceChem/ страница в Steam]). Цель игры -- программировать реакторы, которые преобразуют одни химические соединения в другие. Каждый уровень игры представляет из себя реактор -- поле 10x8, на котором есть два манипулятора, которые можно программировать, размещая на поле различные команды (подхватить атом, повернуть атом, двигаться в другом направлении, объединить атомы и другие).

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

Идея: портировать SpaceChem на Android.

Технологии: Android, Java/Kotlin

Предложил: Новожилов Дмитрий

== Игрушка RogueLike на Python ==

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

Предложил: Никулин Данил

== Coverage App ==

Карты путешествий это здорово, но что делать, если ты путешествуешь только не дальше своей страны/города? (Грустно, но бывает.)

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

Предложила: Валерия Горячева

== /bin/init на Rust ==

systemd -- ужасающий кусок софта, но он уже захватил все крупные дистрибутивы Линукса. И это объяснимо: его подход к организации сервисов в самом деле довольно удобный по сравнению с теми ad-hoc-решениями, которые принимались раньше.

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

Халанский.

== Парсер dts-файлов на Haskell ==

В ядре Linux для ARM для описания набора доступных на системе устройств используются dts-файлы (Device Tree Source File). Но с ними есть такая проблема, что инструментальной поддержки у них немного. dtc (Device Tree Compiler) откровенно аскетичный, и если в dts синтаксическая ошибка, он скажет что-то не сильно более содержательное, чем "error". Логические же ошибки он и вовсе не проверяет. Предложение такое: задействовать монадические парсеры и показать суровым ядрописателям, что даже Хаскелль на что-то годен.

Халанский.

== surf с клавиатурой ==

All software sucks. Кроме, конечно, софта от https://suckless.org/. В частности, утверждается, что крохотный браузер https://surf.suckless.org/ does not suck. В самом деле, в подходе suckless есть какая-то логика: чем меньше софта, тем меньше что может suck.

Но понятно также и то, что всё, чем можно управлять только мышкой, -- если это не инструмент рисования диаграмм или пользовательских интерфейсов -- фундаментально sucks. Хочется исправить surf так, чтобы он заслуживал звание suckless и поддерживал базовые keybinding'и, знакомые любому любителю vimperator и иже с ними, а не только мышекликанье.

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

Халанский.

== Консольный stepik ==

Stepik -- сайт с хорошими курсами, это у него не отнять. Но веб-интерфейс у него довольно неудобный. Он очень медленный и ведёт себя местами странно. И многие вещи приятнее делать прямо у себя дома, в родной консоли. К примеру, отсылать задания. Или читать комментарии. Зачем для всего этого нужно ждать, пока все страницы Степика соизволят прогрузиться?

Stepik предоставляет API: https://github.com/StepicOrg/Stepik-API

Оно, на первый взгляд, более-менее полное, раз на нём работают даже мобильные приложения платформы. Также с его помощью уже создали несколько удобных вещей, к примеру, тот же отсылатель кода: https://github.com/StepicOrg/SubmissionUtility. Но всё же хотелось бы вылезать в веб-интерфейс ещё реже. Кажется вполне реальным скачивать видео, отсылать задания, получать комментарии, вообще не пользуясь браузером.

Халанский.

== J на GPU ==

Есть язык J, идейный последователь APL.

APL -- язык, на котором Conway's Game of Life записывается так (надеюсь, я случайно не взломаю wiki, напечатав этот текст):

life←{ ⍝ John Conway's "Game of Life".
↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ ⍝ Expression for next generation.
}

J -- язык, на котором эта игра записывается так:

l=:[:+/(3 4=/[:+/(,/,"0/~i:1)|.])*.1,:]

Суть этих языков в том, что они ориентированы на массивы данных -- как numpy, или R, или GNU Octave, но более радикально и/или консистентно: массивы данных являются *фундаментальной* сущностью в этих языках, такой же фундаментальной, как, к примеру, функции. Более подробно о массиво-ориентированных языках можно почитать тут: http://www.ccs.neu.edu/home/shivers/papers/rank-polymorphism.pdf, но вот базовый пример.

a =: 5 5 $ i.25 NB. Just a 5x5 matrix
a
0 1 2 3 4
5 6 7 8 9
10 11 12 13 14
15 16 17 18 19
20 21 22 23 24
< a NB. Put the whole matrix into a box
┌──────────────┐
│ 0 1 2 3 4│
│ 5 6 7 8 9│
│10 11 12 13 14│
│15 16 17 18 19│
│20 21 22 23 24│
└──────────────┘
< "2 a NB. Do it for two dimensions (matrix, basically the same as before)
┌──────────────┐
│ 0 1 2 3 4│
│ 5 6 7 8 9│
│10 11 12 13 14│
│15 16 17 18 19│
│20 21 22 23 24│
└──────────────┘
< "1 a NB. Do it for one-dimensional arrays (rows)
┌─────────┬─────────┬──────────────┬──────────────┬──────────────┐
│0 1 2 3 4│5 6 7 8 9│10 11 12 13 14│15 16 17 18 19│20 21 22 23 24│
└─────────┴─────────┴──────────────┴──────────────┴──────────────┘
< "0 a NB. Do it for zero-dimensional arrays (scalars)
┌──┬──┬──┬──┬──┐
│0 │1 │2 │3 │4 │
├──┼──┼──┼──┼──┤
│5 │6 │7 │8 │9 │
├──┼──┼──┼──┼──┤
│10│11│12│13│14│
├──┼──┼──┼──┼──┤
│15│16│17│18│19│
├──┼──┼──┼──┼──┤
│20│21│22│23│24│
└──┴──┴──┴──┴──┘

То есть map (и, на самом деле, многие другие концепции) получаются естественным образом.

Сейчас на APL пишут мало. На J тоже, но всё же побольше. При этом APL на GPU умеют выполнять, а J -- нет, о чём сообщество J сильно жалеет: в конце концов, ориентированные на массивы языки -- самый очевидный кандидат для выполнения на GPU.

Давайте попробуем исполнять на GPU какое-то подмножество J. Всё не получится: язык слишком крупный http://www.jsoftware.com/docs/help806/dictionary/vocabul.htm и с большим количеством граничных случаев, которые за несколько дней не выйдет покрыть. Но если язык будет парситься по синтаксису J и некоторые операторы будут работать, это уже хорошее начало. Технологии -- C, Rust или их помесь, а также что-нибудь для работы с GPU.

Халанский.

== Игра под NES ==

Иногда так устаёшь сидеть за компьютером, что хочется его выключить и пойти заняться чем-нибудь другим, забыть про все технологии, ощутить единство с природой и отдалиться от любых достижений технологического прогресса. К примеру, поиграть в Денди (aka NES/Famicom). Но, за неимением телевизора, это недостижимо -- остаётся только довольствоваться отголосками мечты.

Отголосок может, в частности, заключаться в создании своей собственной игры, которую можно хотя бы запустить в эмуляторе. Хотя бы, скажем, вот такой: https://www.youtube.com/watch?v=71JNREDtUQM

Технологии: Си, hex-редактор, терпение и спокойствие перед лицом чистого ужаса.

Халанский.

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

Предложил: Егоров Антон

== Эмулятор собеседования ==
Написать десктопное приложение, эмулирующее прохождение собеседования.

Перед пользователем ставится задача и дается время на ее решение (не больше 30 минут). При этом код необходимо писать в чем-то похожем на Google Docs, то есть нет никакой подсветки синтаксиса либо автодополнения.

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

При этом учитывается, что во время прохождения собеседования пользователь должен постоянно что-либо делать: если пользователь не пишет всевдокод/код, то должен отвечать на вопросы.

Будет возможность скомпилировать решение и проверить на тестах. Задачи можно взять из книги Cracking the Coding Interview, Gayle Laakmann.

Предложила: Мурычева Наталья

== Читалка формул из латеховских исходников ==

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

Идея: переводить формулы в текст (желательно не слишком формальный, чтобы слушать было приятно), и потом передавать это какой-либо читалке для озвучивания.

Предложила: Колесниченко Лара

== Благотворительность 2.0 ==

Люди постоянно тратят деньги на всякий виртуальный стаф. Давайте поможем людям тратить деньги на более полезные вещи.
Я предлагаю написать небольшое android-приложение, где пользователи в пару кликов смогут пожертвовать на наиболее понравившийся им проект.

Технологии: Java/Kotlin, android

Предложил: Кузиванов Николай.

== Public Channel Viewer ==

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

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

Предложила: Орищенко Александра

AU-conspectus

2017-11-07T12:28:37Z

Alexandra: /* Ссылки */

== Идея ==

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

=== Фичи ===

Запланировано и сделано:
* Поддержка сквозного содержания всех лекций
* Корректное отображение LaTeX символов на сайте
* Подсветка синтаксиса во вставках кода
* Мобильная версия сайта
* Система баг-репортов (выделил текст, нажал на кнопку -- в репозиторий отправилось issue)
* Telegram-bot, сообщающий о появлении новой лекции в репозитории
* Всплывающие подсказки к терминам, содержащие в себе информацию из википедии

Запланировано и не сделано:
* Подбор ссылок для каждой темы конспекта (neerc, wiki)
* Подбор подсказок на neerc.ifmo.ru/wiki (алгоритм был реализован, однако работал очень криво, и от его использования было решено отказаться)
* Искать ключевые слова, делать поиск, лёгкий NLP

Не запланировано, но сделано:
* Красивые превью ссылки в соцсетях (vk, twitter, facebook, telegram)

== Авторы проекта ==

* Стребежев Игорь: team-лидер; backend: настройка сервиса непрерывной интеграции, реализация telegram-бота; frontend: верстка и логика UI
* Орищенко Александра: backend: генерация AST и .md файлов, генерация .html файлов и извлечение метаинформации из AST; frontend: выделение подсказок у терминов
* Новожилов Дмитрий: backend: поиск и генерация информации для подсказок к терминам, объединение отдельных .html файлов с мета-информацией в целостные, готовые к публикации html страницы, генерация содержания конспекта, генерация сообщений для telegram-бота

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

== Известные баги ==

* Подсказки к терминам не всегда генерируются корректно
* При генерации issue слетает разметка LaTeX формул

== Ссылки ==

Репозиторий: https://github.com/demiurg906/au-conspectus

Баг-трекер: https://github.com/xamgore/au-conspectus/issues

Конспект: https://xamgore.github.io/au-conspectus/

Видео: https://youtu.be/FAAeSM95ws0 (внимание, включите субтитры)

Презентация: https://goo.gl/CvcUcQ

AU-conspectus

2017-11-07T11:42:24Z

Alexandra: /* Ссылки */

AU-conspectus

2017-11-07T11:40:13Z

Alexandra: /* Ссылки */

AU-conspectus

2017-11-03T07:04:27Z

Alexandra:

Система, генерирующая из набора markdown документов, сайт с конспектом по алгоритмам (слава Смалю), со следующими фичами:

Фичи:

# Оповещалка в telegram о новой главе в конспекте
# Система багрепортов (выделил текст — отправил issue)
# Подбор ссылок для каждой темы конеспекта (neerc, wiki)
# Искать ключевые слова, делать поиск, лёгкий NLP*
# Термины как в википедии: всплывающие определения*

Состав:
* Стребежев Игорь
* Орищенко Александра
* Новожилов Дмитрий

Репозиторий: https://github.com/demiurg906/au-conspectus

Bug-list:

# Стили написаны не для всех элементов
# Не всегда корректно работает поиск терминов в википедии и neerc.ifmo.ru/wiki
# Github pages отказывается хостить страницы (проблема github)

Bugs + future features: https://github.com/xamgore/au-conspectus/issues

* — дополнительные фичи

Devdays Осень 2017

2017-10-26T20:08:23Z

Alexandra:

= Темы проектов =

Чтобы править эту страницу, нужно залогиниться в Sewiki. Тогда сверху будет кнопочка "править". Если у вас нет учётной записи - напишите Игорю желаемый логин.

Редактировать wiki одновременно нескольким людям стоит осторожно: после внесения правки проверьте, что она действительно сохранилась.

== Depth map from single view ==

Матрица глубины (depth map) - это некоторая матрица, каждый элемент которой содержит дальность до объекта.
Другими словами, если имеется некотороые изображение, то матрица глубины говорит о том, какого расстояние до каждого нарисованного объекта.

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

Предложил: Никулин Данил

== Доработать децентрализованный мессенджер RetroShare ==

Децентрализованные мессенджеры представляют интерес тем (для любителей паранои :)), что не используют при своей работе подконтрольные третьим лицам центральные серверы. Для "регистрации" в сети пользователь создаёт пару открытый/закрытый ключ и передаёт открытый ключ тем, с кем хочет общаться. Находить IP собеседника достаточно эффективно можно с помощью [https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%D0%BD%D0%BD%D0%B0%D1%8F_%D1%85%D0%B5%D1%88-%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0 DHT].

Мессенджеров, которые работаю по такому принципу, оказывается, не так и много -- я видел только [https://github.com/RetroShare RetroShare] и [https://tox.chat/ Tox] . Я Пробовал пользоваться RetroShare: там всё хорошо, но есть некоторые недоработки, например нет индикатора, дошло ли сообщение до собеседника, удобного диалога сохранения файла и т.д.

За три дня можно разобраться в исходниках и устранить подобные недостатки.

Предложил: Егоров Антон

== Умное сохранение музыки из ВКонтакте ==

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

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

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

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

Технологии: Java/Kotlin (для облака и мобильного приложения), js для расширения (кажется, что оно будет маленьким, так что js по минимуму)

Предложил: Новожилов Дмитрий

== Квантовый форсаж ==

Квантовое лирическое отступление: в физике есть понятие: неопределенность Гейзенберга. Если не вдаваться в подробности, то существуют пары величин, которые нельзя измерить с идеальной точностью. Например, импульс и координата объекта. Можно написать формулу, которая будет утверждать, что произведение неопределенности координаты на неопределенность импульса должно быть больше некой константы, связанной с постоянной Планка.

Идея: написать простенькую 2D игру, где будет использоваться понятие неопределенности Гейзенберга.

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

Описание игры по существу: есть некий фон, на котором отрисовываются различные препятствия (геометрические объекты или подобие сталактитов и сталагмитов, на что фантазии хватит). Есть космический корабль, который летит вдоль этого фона. Корабль имеет два свойства: скорость и координату. Для простоты можно представить корабль в виде круга. Скорость и координата подчиняются неопределенности Гейзенберга.

Скорость может принимать значение из некоторого промежутка с какой-то вероятностью. По сути, скорость будет меняться скачками. Тоже самое с координатой. Есть некий ореол вокруг корабля в пространстве которого может случайно возникать корабль (само собой скачками). Чем сильнее меняется скорость, тем меньше меняется координата (ореол меньшего размера) и наоборот. Для изменения неопределенности будут появляться бонусы, которые можно съедать (но надо понимать, что меняя неопределенность одного свойства, мы автоматически меняем неопределенность другого).

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

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

Предложил: Тимашов Даниил
== Vassal online ==
Давайте напишем легковесный движок в вебе для разработки настольных игр.
Предложил: Кузиванов Николай

== Добрый CryptoLocker ==
Петя боится вирусов-вымогателей (ransomware). Но Петя при этом очень неосторожный человек и любит открывать письма с вложениями от неизвестных отправителей, поэтому уже выплатил злоумышленникам 10 биткойнов, чтобы расшифровать свои файлы.
А ещё Петя - параноик. Он хочет зашифровать свои файлы, чтобы хакеры не смогли узнать его секреты, но при этом он сам смог в нужный момент их расшифровать. Помогите Пете написать программу - аналог CryptoLocker-а, но только добрый, для динамического шифрования собственных документов.

Для справки:
CryptoLocker - это простейший вирус-вымогатель, который шифрует файлы с определёнными расширением (обычно офисные и pdf-ки) с помощью криптосистемы с открытым ключом. Закрытый ключ хранится на сервере злоумышленника.
После попадания в систему вирус связывается с сервером, и с помощью полученного от него открытого ключа шифрует файлы нужного расширения. Затем выводится окно со счастливой новостью о заражении и ссылкой на сайт, где после оплаты можно расшифровать свои файлы.

Задачи:
1) Собственно сам шифровальщик (лучше минимально защититься от простейшего реверс-инжиниринга, например, генерить имя домена командного сервера, а не хранить его в строке)
2) Командный сервер с бд + сервер с сервисом расшифровки.
3) Также нужно, чтобы шифровальщик делал некоторые действия с OS (автозапуск + сбор информации), но это в идеале

Технологии: Более актуально для Windows. Но под Linux тоже можно будет попробовать. Язык - я за Python).

Предложила: Шеметова Екатерина

== Коллективное предсказание продолжительности выполнения домашнего задания ==

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

Имеется хорошо изученный частный случай этой задачи: тот, когда все делают какие-то задачи сообща и при этом делают априорные оценки того, сколько времени на это уйдёт. Затем, когда задача выполнена и известно реальное количество затраченного времени, вычисляется отношение между временем ожидаемым и затраченным. Когда в следующий раз проводятся оценки того, сколько уйдёт времени, применяется этот коэффициент. Через несколько заходов, по-хорошему, оценки с некоторым коэффициентом приближаются к реальности. Почитать более развёрнуто можно тут:
https://en.wikipedia.org/wiki/Burn_down_chart

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

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

Предложил Дмитрий Халанский.

== Графы как часть разметки веб-страницы ==

Есть много библиотек, которые позволяют использовать на веб-страницах шаблоны, которые затем заполняются через JavaScript. К примеру, текст "<nowiki>{{user.isLoggedIn}}</nowiki>", размещённый где угодно на веб-странице, может превратиться в сложное дерево DOM-объектов, которое будет обновляться каждый раз, когда будет меняться значение переменной user.isLoggedIn. Известные примеры таких библиотек -- React и Vue.js.

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

Уже есть некоторые разработки по генерации графов из текстовых описаний -- к примеру, http://ushiroad.com/jsviz/ -- но нигде не было обнаружено такое, чтобы можно было представлять граф в виде обычного текста и при этом иметь в качестве вершин произвольные объекты DOM.

Предложил Халанский Дмитрий.

== Плагин к Coq на kakoune / kakoune-mode к Emacs ==

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

kakoune -- современный текстовый редактор, убийца vim, последователь vi, который создавался с целью исправить ставшие за многие годы очевидными ошибки остальных модальных текстовых редакторов. Я пересел на kakoune после трёх лет очень активного использования vim и не пожалел.
http://kakoune.org/

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

При этом на Coq удобнее всего работать в emacs. Который после kakoune не кажется удобным вообще никак.

Возникает две возможные задачи. Первая -- написать для kakoune плагин, добавляющий поддержку Coq. Вторая -- написать для emacs плагин, который позволяет писать в нём так же, как в kakoune. Первая задача заключается в написании всеми любимых shell-скриптов (потому что kakoune управляется ими), вторая -- в написании кода на Emacs Lisp, который, пусть и в силу Emacs неудачный, всё же Lisp.

Предложил Халанский Дмитрий.

== CRM-система для преподавателей и студентов ==

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

Доступ к системе с помощью веб-интерфейса (и мобильного приложения?).

Предполагаемый стэк технологий: фронтенд Angular2, бекенд NodeJS + Sequelize+ PostgreSQL (или полуфабрикат типа Firebase)

Предложил Чернышев Ярослав.

== Синхронизация звукового потока ==

Часто возникает такая ситуация, когда вы хотите послушать музыку или посмотреть лекцию со Stepik’а со своими товарищами с одного телефона. Однако при этом не хотите мешать другим людям вокруг своим звуком или сидеть только с одним наушником. Поэтому я предлагаю разработать приложение для Android, которое будет синхронизировать звуковые потоки на нескольких устройствах.

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

Предложила: Орищенко Александра

== "Горячий" поиск билетов ==

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

В связи с чем предлагается написать программу/бота который в фоновом режиме следил бы за доступными билетами и в случае появления подходящего билета информировал об этом на телефон/e-mail или выводил большущее сообщение прямо на рабочий стол.

Наверняка подобные штуки уже есть, но вновь изобретать велосипед никто не запрещал.)

Насчет технологий точно ничего не скажу, т.к. опыта в таких вещах по минимуму, а вернее его вообще нет. :)

Предложил: Милащенко Марк

== Кластеризация сигналов ==

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

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

В связи с этим предлагается написать программу которая:
- умела бы обрабатывать множество входных данных (осциллограмм) и выделять из них полезные сигналы
- Кластеризировала бы полученные сигналы на заданное количество множеств (например, методом k-средних или каким-либо другим методом кластеризации)
- Либо сепарировала бы данные используя различные методы кластеризации, а потом выдавала вердикт по предполагаемому количеству источников

Для таких целей скорее подойдет python, но предполагается написать это на с++. Хотя можно на чем угодно, что подходит.
Задача скорее не совсем подходящего масштаба и содержания, но может быть кто-нибудь заинтересуется.

Предложил: Милащенко Марк

Devdays Осень 2017

2017-10-26T20:07:31Z

Alexandra:

= Темы проектов =

Чтобы править эту страницу, нужно залогиниться в Sewiki. Тогда сверху будет кнопочка "править". Если у вас нет учётной записи - напишите Игорю желаемый логин.

Редактировать wiki одновременно нескольким людям стоит осторожно: после внесения правки проверьте, что она действительно сохранилась.

== Depth map from single view ==

Матрица глубины (depth map) - это некоторая матрица, каждый элемент которой содержит дальность до объекта.
Другими словами, если имеется некотороые изображение, то матрица глубины говорит о том, какого расстояние до каждого нарисованного объекта.

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

Предложил: Никулин Данил

== Доработать децентрализованный мессенджер RetroShare ==

Децентрализованные мессенджеры представляют интерес тем (для любителей паранои :)), что не используют при своей работе подконтрольные третьим лицам центральные серверы. Для "регистрации" в сети пользователь создаёт пару открытый/закрытый ключ и передаёт открытый ключ тем, с кем хочет общаться. Находить IP собеседника достаточно эффективно можно с помощью [https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%D0%BD%D0%BD%D0%B0%D1%8F_%D1%85%D0%B5%D1%88-%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0 DHT].

Мессенджеров, которые работаю по такому принципу, оказывается, не так и много -- я видел только [https://github.com/RetroShare RetroShare] и [https://tox.chat/ Tox] . Я Пробовал пользоваться RetroShare: там всё хорошо, но есть некоторые недоработки, например нет индикатора, дошло ли сообщение до собеседника, удобного диалога сохранения файла и т.д.

За три дня можно разобраться в исходниках и устранить подобные недостатки.

Предложил: Егоров Антон

== Умное сохранение музыки из ВКонтакте ==

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

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

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

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

Технологии: Java/Kotlin (для облака и мобильного приложения), js для расширения (кажется, что оно будет маленьким, так что js по минимуму)

Предложил: Новожилов Дмитрий

== Квантовый форсаж ==

Квантовое лирическое отступление: в физике есть понятие: неопределенность Гейзенберга. Если не вдаваться в подробности, то существуют пары величин, которые нельзя измерить с идеальной точностью. Например, импульс и координата объекта. Можно написать формулу, которая будет утверждать, что произведение неопределенности координаты на неопределенность импульса должно быть больше некой константы, связанной с постоянной Планка.

Идея: написать простенькую 2D игру, где будет использоваться понятие неопределенности Гейзенберга.

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

Описание игры по существу: есть некий фон, на котором отрисовываются различные препятствия (геометрические объекты или подобие сталактитов и сталагмитов, на что фантазии хватит). Есть космический корабль, который летит вдоль этого фона. Корабль имеет два свойства: скорость и координату. Для простоты можно представить корабль в виде круга. Скорость и координата подчиняются неопределенности Гейзенберга.

Скорость может принимать значение из некоторого промежутка с какой-то вероятностью. По сути, скорость будет меняться скачками. Тоже самое с координатой. Есть некий ореол вокруг корабля в пространстве которого может случайно возникать корабль (само собой скачками). Чем сильнее меняется скорость, тем меньше меняется координата (ореол меньшего размера) и наоборот. Для изменения неопределенности будут появляться бонусы, которые можно съедать (но надо понимать, что меняя неопределенность одного свойства, мы автоматически меняем неопределенность другого).

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

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

Предложил: Тимашов Даниил
== Vassal online ==
Давайте напишем легковесный движок в вебе для разработки настольных игр.
Предложил: Кузиванов Николай

== Добрый CryptoLocker ==
Петя боится вирусов-вымогателей (ransomware). Но Петя при этом очень неосторожный человек и любит открывать письма с вложениями от неизвестных отправителей, поэтому уже выплатил злоумышленникам 10 биткойнов, чтобы расшифровать свои файлы.
А ещё Петя - параноик. Он хочет зашифровать свои файлы, чтобы хакеры не смогли узнать его секреты, но при этом он сам смог в нужный момент их расшифровать. Помогите Пете написать программу - аналог CryptoLocker-а, но только добрый, для динамического шифрования собственных документов.

Для справки:
CryptoLocker - это простейший вирус-вымогатель, который шифрует файлы с определёнными расширением (обычно офисные и pdf-ки) с помощью криптосистемы с открытым ключом. Закрытый ключ хранится на сервере злоумышленника.
После попадания в систему вирус связывается с сервером, и с помощью полученного от него открытого ключа шифрует файлы нужного расширения. Затем выводится окно со счастливой новостью о заражении и ссылкой на сайт, где после оплаты можно расшифровать свои файлы.

Задачи:
1) Собственно сам шифровальщик (лучше минимально защититься от простейшего реверс-инжиниринга, например, генерить имя домена командного сервера, а не хранить его в строке)
2) Командный сервер с бд + сервер с сервисом расшифровки.
3) Также нужно, чтобы шифровальщик делал некоторые действия с OS (автозапуск + сбор информации), но это в идеале

Технологии: Более актуально для Windows. Но под Linux тоже можно будет попробовать. Язык - я за Python).

Предложила: Шеметова Екатерина

== Коллективное предсказание продолжительности выполнения домашнего задания ==

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

Имеется хорошо изученный частный случай этой задачи: тот, когда все делают какие-то задачи сообща и при этом делают априорные оценки того, сколько времени на это уйдёт. Затем, когда задача выполнена и известно реальное количество затраченного времени, вычисляется отношение между временем ожидаемым и затраченным. Когда в следующий раз проводятся оценки того, сколько уйдёт времени, применяется этот коэффициент. Через несколько заходов, по-хорошему, оценки с некоторым коэффициентом приближаются к реальности. Почитать более развёрнуто можно тут:
https://en.wikipedia.org/wiki/Burn_down_chart

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

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

Предложил Дмитрий Халанский.

== Графы как часть разметки веб-страницы ==

Есть много библиотек, которые позволяют использовать на веб-страницах шаблоны, которые затем заполняются через JavaScript. К примеру, текст "<nowiki>{{user.isLoggedIn}}</nowiki>", размещённый где угодно на веб-странице, может превратиться в сложное дерево DOM-объектов, которое будет обновляться каждый раз, когда будет меняться значение переменной user.isLoggedIn. Известные примеры таких библиотек -- React и Vue.js.

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

Уже есть некоторые разработки по генерации графов из текстовых описаний -- к примеру, http://ushiroad.com/jsviz/ -- но нигде не было обнаружено такое, чтобы можно было представлять граф в виде обычного текста и при этом иметь в качестве вершин произвольные объекты DOM.

Предложил Халанский Дмитрий.

== Плагин к Coq на kakoune / kakoune-mode к Emacs ==

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

kakoune -- современный текстовый редактор, убийца vim, последователь vi, который создавался с целью исправить ставшие за многие годы очевидными ошибки остальных модальных текстовых редакторов. Я пересел на kakoune после трёх лет очень активного использования vim и не пожалел.
http://kakoune.org/

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

При этом на Coq удобнее всего работать в emacs. Который после kakoune не кажется удобным вообще никак.

Возникает две возможные задачи. Первая -- написать для kakoune плагин, добавляющий поддержку Coq. Вторая -- написать для emacs плагин, который позволяет писать в нём так же, как в kakoune. Первая задача заключается в написании всеми любимых shell-скриптов (потому что kakoune управляется ими), вторая -- в написании кода на Emacs Lisp, который, пусть и в силу Emacs неудачный, всё же Lisp.

Предложил Халанский Дмитрий.

== CRM-система для преподавателей и студентов ==

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

Доступ к системе с помощью веб-интерфейса (и мобильного приложения?).

Предполагаемый стэк технологий: фронтенд Angular2, бекенд NodeJS + Sequelize+ PostgreSQL (или полуфабрикат типа Firebase)

Предложил Чернышев Ярослав.

== Синхронизация звукового потока ==

Часто возникает такая ситуация, когда вы хотите послушать музыку или посмотреть лекцию со Stepik’а со своими товарищами с одного телефона. Однако при этом не хотите мешать другим людям вокруг своим звуком или сидеть только с одном наушником. Поэтому я предлагаю разработать приложение для Android, которое будет синхронизировать звуковые потоки на нескольких устройствах.

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

Предложила: Орищенко Александра

== "Горячий" поиск билетов ==

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

В связи с чем предлагается написать программу/бота который в фоновом режиме следил бы за доступными билетами и в случае появления подходящего билета информировал об этом на телефон/e-mail или выводил большущее сообщение прямо на рабочий стол.

Наверняка подобные штуки уже есть, но вновь изобретать велосипед никто не запрещал.)

Насчет технологий точно ничего не скажу, т.к. опыта в таких вещах по минимуму, а вернее его вообще нет. :)

Предложил: Милащенко Марк

== Кластеризация сигналов ==

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

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

В связи с этим предлагается написать программу которая:
- умела бы обрабатывать множество входных данных (осциллограмм) и выделять из них полезные сигналы
- Кластеризировала бы полученные сигналы на заданное количество множеств (например, методом k-средних или каким-либо другим методом кластеризации)
- Либо сепарировала бы данные используя различные методы кластеризации, а потом выдавала вердикт по предполагаемому количеству источников

Для таких целей скорее подойдет python, но предполагается написать это на с++. Хотя можно на чем угодно, что подходит.
Задача скорее не совсем подходящего масштаба и содержания, но может быть кто-нибудь заинтересуется.

Предложил: Милащенко Марк