Devdays Весна 2018

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

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

Пример

Описание

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

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

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

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

SpaceChem на Android

Есть замечательная игрушка 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

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