Devdays Осень 2017 — различия между версиями

Материал из SEWiki
Перейти к: навигация, поиск
(Графы как часть разметки веб-страницы)
Строка 68: Строка 68:
 
== Графы как часть разметки веб-страницы ==
 
== Графы как часть разметки веб-страницы ==
  
Есть много библиотек, которые позволяют использовать на веб-страницах шаблоны, которые затем заполняются через JavaScript. К примеру, текст "{{user.isLoggedIn}}", размещённый где угодно на веб-странице, может превратиться в сложное дерево DOM-объектов, которое будет обновляться каждый раз, когда будет меняться значение переменной user.isLoggedIn. Известные примеры таких библиотек -- React и Vue.js.
+
Есть много библиотек, которые позволяют использовать на веб-страницах шаблоны, которые затем заполняются через JavaScript. К примеру, текст "<nowiki>{{user.isLoggedIn}}</nowiki>", размещённый где угодно на веб-странице, может превратиться в сложное дерево DOM-объектов, которое будет обновляться каждый раз, когда будет меняться значение переменной user.isLoggedIn. Известные примеры таких библиотек -- React и Vue.js.
  
 
Этот же подход можно применять и к тому, чтобы расширять набор средств отображения сведений на веб-странице. Простой пример, который и предлагается в качестве работы, -- это описание в тексте веб-страницы графа, вершинами которого могут быть произвольные DOM-объекты. В текстовых браузерах должно быть видно текстовое представление графа, в графических -- интерактивный граф.
 
Этот же подход можно применять и к тому, чтобы расширять набор средств отображения сведений на веб-странице. Простой пример, который и предлагается в качестве работы, -- это описание в тексте веб-страницы графа, вершинами которого могут быть произвольные DOM-объекты. В текстовых браузерах должно быть видно текстовое представление графа, в графических -- интерактивный граф.

Версия 20:39, 26 октября 2017

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

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

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


Depth map from single view

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предложил: Тимашов Даниил

Vassal online

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


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

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

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

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

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

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

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

Есть много библиотек, которые позволяют использовать на веб-страницах шаблоны, которые затем заполняются через JavaScript. К примеру, текст "{{user.isLoggedIn}}", размещённый где угодно на веб-странице, может превратиться в сложное дерево 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.

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