ииии — бинго! Только что вы признались в том, что полный список заявленного функционала будет невозможно использовать в существующих решениях. А значит — хрена с два оно выстрелит.
Допиливать тонны библиотек, чтобы воспользоваться новым решением, никто не станет.
Брать подмножество нового языка тупо чтобы заменить существующее решение без какой-либо выгоды тоже никто не будет (это затраты времени).
А раз в одном из основных языков (да, JS один из основных игроков на рынке) существующие решения не способны переваривать этот формат — никому оно нахрен не нужно. Потому что взаимодействие — штука адски важная.
Да и в других языках ситуация аналогичная.
Это ж будет тупо транскодинг в XML, который есть и в YAML и десятках других собирающихся в XML языков. И да, такого аргумента я не увидел.
Собственно, ситуация следующая:
YAML, насколько я помню, имеет абсолютно спокойный транскодинг в XML, равно как и Tree, разница исключительно в масштабах проектов и уровне поддержки со стороны сообщества (читай, гарантии поддержки и исправления ошибок).
При этом в YAML есть достаточно продуманная система типов, которая в отличии от Tree сделана с оглядкой на большинство языков.
Я, честно говоря, не понимаю как может сочетаться «Произвольная иерархия 5/5» и «Простота реализации 5/5» и «Удобство редактирования 5/5». Дело в том, что реализация — это не только парсер, это еще и перевод системы типов во внутренний формат языка приложения. И если типы YAML или JSON почти всегда имеют полное отражение внутри языка (то есть возможен беспроблемный перевод структуры данных приложение-форматированное представление и форматированное представление-приложение), а XML дает определенные возможности для сложных выборок в дальнейшем, то Tree, как я вижу, не обладает такими возможностями — он вызовет неиллюзорные проблемы на многих структурах во многих языках.
А если говорить про XML — стоит скорее уж спросить, какие есть в Tree возможности перемещения по дереву и выполнения Xpath-запросов. Думаю, это известный факт, что XML это в первую очередь структура данных в памяти, а не просто дамп, иначе можно было бы называть форматом данных и sqlite, например.
Единственный вариант поста, который бы звучал разумно — это
«Эй, чуваки, я запилил еще один формат, который умеет полноценно конвертироваться в XML и JSON, по сравнению с существующими у него такие-то плюшки:
-свободная грамматика, на которой можно реализовать то-то то-то и то-то
-по крайней мере такой же человекочитаемый как и YAML
-есть компактный формат для передачи по сети
-есть потоки
-уже есть плагин для IDEA
-легко сделать библиотеку под свой язык, под D энкодер/декодер размером всего в 100 строк, под JS — 120, вот примеры
и вот как он выглядит:…
»
А все это «да XML хуже, и JSON хуже, и YAML хуже, они все всасывают по всем статьям, вот вам табличка» — это сразу уже настораживает и выглядит как буллшит.
Думал я о том, что не так с XML и почему его в последнее время променяли, на бестолковый JSON.
Потому что на всех языках есть веб-серверы или работа с сетью. PHP, ruby, python, go etc. Потому что там где работа с сетью — взаимодействие с веб-клиентами и браузерами. Где JS и JSON.parse().
XML — сложная структура, зачастую — обладающая избыточной сложностью, зачастую — сложная для программиста в своей формальности, зачастую — не совпадающая по типам.
Типы JSON — bool, number, string, map/hash/object и array — есть в практически всех языках нативно, и программисты на любом языке не испытывают проблем с осмыслением формата JSON, пусть он и нелеп.
Соответственно — на абсолютно всех языках уже есть рабочие и быстрые реализации парсера JSON и дампера в JSON, которые можно использовать.
А вообще нелепое решение. Непонятно, зачем.
Аргументы типа «он красивый, эффективный и быстрый» — дурацкие.
Аргументы типа «Он такой же простой для реализации парсера в любом языке, как ini-файл, вот доказательство, он парсится в JS быстрее чем встроенный парсер JSON — вот тесты во всех браузерах, он обладает такой же полнотой, как XML — не через трансляцию в XML, а нативно, он более эффективно работает с сетью и гзипается, чем любой из популярных стандартов» — не увидел.
Да и вообще, надо думать не от охренительности решения, а от задачи. Пока нет конкретной задачи или задач, которую продукт решает лучше чем существующие — смысла в нем нет. Поэтому минуснул.
Не, не впечатлили.
Куча вещей, которые можно сделать препроцессорами, пара сомнительных мелких нововведений и :has, который, конечно, всем хотелось (да и мне тоже), но который стооолько геммороя принесет. И с быстродействием, и с починкой кривой верстки.
Проблема не в том что не делают.
Проблема в том, что толком нет ни одного «флагмана» с небольшим размером экрана. Все эти mini и nano — это откровенно дерьмовые телефоны в похожем на флагман корпусе.
То есть: хреновая сборка, глючное ПО, маленькое коммьюнити на XDA (разрозненное по отдельным моделям сообщество) и как следствие — кривые кастомные билды, никаких обновлений до последнего андроида.
Я месяц назад искал себе телефон. У старого начал деградировать контроллер батареи, поэтому вариантов не было.
Три, всего три требования:
-экран от 3.5 до 4.5 дюймов (точнее привязка к габаритам, но по экрану примерно можно судить точные размеры)
-не скрипящий корпус
-обновление до Android 5 (или обещание обновления)
Под это требование подошел всего, черт возьми, один телефон: xperia z1 compact. Еще почти подходил z3 compact, но они почти по всем спекам совпадают (экран больше при таком же корпусе), и мне чисто внешне z1 понравился.
Больше ни у кого из производителей нет телефона, который будет нормально обновлен до последней версии андроида, и при этом не будет торчать из кармана.
Вообще нет.
Субьективно (нужно реально будет поизучать, когда возникнет потребность — опубликую обязательно) — медиана средней мобильной страницы НЕ мобильного приложения укладывается в 150-250 кб на данный момент. Из них ассеты (подгружающееся парралельно содержимое: изображения, шрифты etc) занимают 100-150кб, и они не загружают основной поток загрузки содержимого.
На JS, html и css в среднем для мобильной (не адаптивной, а именно мобильной версии) по факту занимают 50-150 Кб.(сразу говорю, я говорю гзипнутые размеры, по факту это до 500 кб спокойно может быть).
Поэтому «средняя веб-страница весит более 1.7 МБ» в контексте мобильного jQuery — такое же лукавство, как и «на андроид 4.4 оно отрабатывает за столько-то секунд». Я могу для сравнения взять мой убитый Atrix 4g 2011 года выпуска — на нем для тестов сейчас Cyanogen 4.4 стоит, и Sony Z1 — на нем стоковый 4.4, и сравнить, за сколько тестовый скрипт загрузится и отработает. Уверен, разница будет в два раза минимум.
кривая статья. очень много допущений.
очень умилило «за минимальную скорость мобильного интернета возьмем 1мбит» и выведение закона мура по версиям андроида без уточнения девайсов.
а самого главного ответа — насколько jquery медленнее vanilla js — нет, чисто «да у наших пользователей, наверное, хорошие устройства с хорошим интернетом, они спокойно загрузят лишние 30кб жса». И да, «средняя страница — 1.7 мб» — это смешно. тут хорошо бы взять медиану, причем именно страницдля мобильных, а не всех сайтов мира
Да я-то тут при чем. Я фронтэнд обеспечиваю. Я вообще джаву не умею и не хочу уметь (но, видимо, андроида ради и придется когда-нибудь).
Как специалист я сраный фронтэндщик, который даже верстает медленно, зато умеет в джаваскрипт так, что все вокруг хренеют, на этом мои прикладные способности заканчиваются. То, что я умею дизайн, ux, настраивать nginx, спокойно кодить под рельсы, работать с кучей других языков, читать исходники v8, паять усилители, управлять разработчиками и разбираться в особенностях низкоуровневых протоколов — это круто, но это исключительно жырный плюс к тому, что я хороший фронтэндщик, который понимает как работает все, с чем он взаимодействует — начиная от того, как работают http-запросы на всех уровнях модели OSI и заканчивая тем, как повысить конверсию :) Потому и занимаюсь такими замороченными проектами.
И вот честно, никакого желания в этот неплохой багаж знаний добавлять особенности работы кэшей под джаву)
С react-ом — сравнивать вообще что-либо сложно, особенно с react+om.
А в нынешней версии (0.11.х) почти все детские ошибки исправили. Я за проектом почти год уже слежу и могу на полном серьезе сказать — 99% кейсов покрыто, и неожиданные ошибки в духе «что-то не работает, хотя должно» — на 0.11 у меня ни разу не появлялись. Да, были ляпы, связанные именно с новыми фичами (вот два, которые я закоммитил: #652, #594, например) — но конкретно с работой приложения они уже не были связаны.
Я бы сказал, что сейчас Vue — medium rare. Да, немного сыроват, но удовольствие от употребления будет наблюдаться у большинства :)
А насчет 50-60 обновлений в секунду — я в январе за подобный проект берусь. При этом это полноценный энтерпрайз с джавой на бэкенде и прочими удовольствиями жизни. Сейчас думаю над выбором: ангуляр или React+Om. При этом совесть меня склоняет к первому, а предчувствие жопы с перформансом — к второму. О Vue там и речи быть не может, конечно — даже не из соображений того, что он нестабилен так или иначе, а как минимум из-за того, что он поддерживаться будет не один год, и найти разработчиков на vue в дальнейшем будет сложнее, чем на react или angular.
О, вы меня сподвигли начать писать статью про vue.js, наконец.
Который при желании может прикидываться и ангуляром, и бэкбоном (в минимальной форме, конечно, но порог входа для тех, кто с ними имел дело, около плинтуса), летает (перфоманс — изумительный). Поддерживается буквально двумя людьми, но при этом мелкие issue-ы, которые я им пишу, например, вечером в четверг, в 6 утра в пятницу оказываются уже исправлены :)
Ну и подход очаровывает.
«DI? да нахрена вам DI в фреймворке для клиентсайда, у тебя есть AMD или CommonJS или что еще придет в твою больную голову»
«Что? Навигация? Чувак, тебе оно точно надо? Посмотри сколько клевых библиотек для навигации и без нашей помощи сделано, мы тебе сделали директиву для смены лейаутов, на здоровье»
«Компоненты? Службы? Модели? Директивы? Сервисы? Чо ты к нам пристал. На тебе фильтры для шаблонов, компоненты для, собственно, автономных компонентов, и директивы для всяких мимимишных жкверишных плагинов твоих, хватит тебе».
И реально хватает ведь.
А что самое крутое — он эти шаблоны свои — ну вот такой, например: {{ profiles[currentUserId] }} — (да-да, привет, ангуляр) он не разворачивает как-то, а превратит в
и если флаг debug установлен — он сам вызовет дебаггер на ошибке. А this реально указывает на окружение, которое можно полноценно поинспектировать.
Я так приложение в айфрейме дебажил (был один прикол, связанный с хромовскими приложениями). Как бы я с другими фреймворками это делал — вообще бы не представляю.
в какой-то степени. В этой ситуации хорошо подошло бы что-то вроде cel-shader-а.
Просто альфа позволяет дать большое количество цветов, а пиксельарт (если я его правильно понимаю) обычно подразумевает 256-цветовую палитру. Соответственно нужно было бы делать приведение до ближайшего цвета.
у устройства нет никаких физических кнопок, кроме как кнопки включения и громкости
О боже, еще один разработчик устройств решил, что кнопка камеры не нужна.
Чувствую, что скоро пойду писать петицию на change.org какой-нибудь, потому что снимать с наэкранной кнопкой — это ужас. Если при нажатии физической двухпозиционной кнопки получается хоть сколько-то плавное движение сделать, то по тапу на наэкранную устройство дергается и фото получается смазанным. Сколько не было устройств — так и не смог понять, как вообще люди снимают на них что-то.
я вас не минусовал.
я вообще не связан с 3д-моделированием на интеллектуальных алгоритмах.
То, что вы считаете чем-то слабо или криво работающим — не значит, что оно и правда так. Вы не знаете, что под капотом, не знаете, какие технологические решения были использованы, не знаете, сколько научно-исследовательской работы положено в основу всего, какие математические теории используются, но уже готовы критиковать.
Как человек, который активно пилит рекомендательную систему для музыки — могу по своему опыту сказать: если есть достаточно изначальных данных для анализа (в моем случае уже накопленное поведение людей), возможность протестировать новые модели анализа — крайне малого количества весьма неточных данных может оказаться достаточно для выстраивания весьма стройной модели.
В моем случае, например, из для жанров аудиозаписей (которые забиты весьма криво и неточно) — строится модель, в ней устраняются сглаживания, устраняются выбросы. После этого строится ранжирование по времени внесения записей, строится линия в 22-мерном пространстве, соответствующая изменению жанрового вектора, экстраполируется, уменьшается до единичного вектора, дальше все множество таких единичных векторов через гномоническую проекцию проецируется в 21-мерное пространство, в котором идут определения жанровых предпочтений пользователя, и далее через нейронную сеть (мне было лень писать уже дальше алгоритм для расчетов) идет обучение системы о том, что пользователю нравится и что не нравится.
И это все делается в браузере (в том числе в мобильничках) в реальном времени для 5000 векторов. С некоторыми допущениями, конечно — на разных стадиях отсеиваются заранее неподходящие вектора, например, есть таблицы для переводов и так далее.
А начиналось все с ранжирования по прямому сравнению порядка жанров — просто {рок; альтернатива; поп} и {рок; поп; альтернатива} считались ближе, чем {шансон; классика; рок}.
Если что — я это один хрен опубликую с картинками и графиками в ближайшее время вместе с новым релизом, в котором уже это все будет, поэтому и спокойно рассказываю все детали.
Когда мы писали приложение, описанное в нашей предыдущей статье, то реализовали его как SPA. Соответственно, пришлось очень плотно поработать над очисткой памяти, и буквально всё имело конвеер dispose. При этом, возможна ситуация, когда со страницы на сервер шлется запрос, и пользователь внезапно покидает страницу (например, он ткнул не тот пункт меню). View model текущего окна проходит конвеер dispose, пользователь уходит на другую страницу.
И тут с сервера возвращается результат запроса.
Говорить о том, что может случиться в такой ситуации, бессмысленно – случиться может всё, что угодно. Лучшее, что происходило — летела ошибка, и становилось понятно, что что-то не так.
Как-то хреновенько приложение спроектировано. В такой ситуации в лучшем случае должно быть изменение локально объявленных переменных, которые прибиваются garbage collector-ом после колбэка.
Случай 3. Двойные вызовы к сервисам
Проблема:
У нас возникла ситуация, когда несколько объектов на странице могут попросить одни и те же данные. Ходить на сервер за одними и теми же данными не хочется (как и показывать одинаковые статусы по типу описанных выше). Попробуем что-нибудь придумать.
Вы это. Инвалидацию кэша придумайте лучше. А данные хорошо бы хранить все-таки в модельке или сторадже каком-нибудь.
Не, в целом был бы это пост из песочницы — было бы круто.
Но вот для корпоративного блога, в котором пишут
Основу штата составляют высококлассные специалисты в технологиях Microsoft, Java, Mobile (iOS, Android, Windows Phone, Titanium), MicroStrategy, SAS.
Допиливать тонны библиотек, чтобы воспользоваться новым решением, никто не станет.
Брать подмножество нового языка тупо чтобы заменить существующее решение без какой-либо выгоды тоже никто не будет (это затраты времени).
А раз в одном из основных языков (да, JS один из основных игроков на рынке) существующие решения не способны переваривать этот формат — никому оно нахрен не нужно. Потому что взаимодействие — штука адски важная.
Да и в других языках ситуация аналогичная.
Собственно, ситуация следующая:
YAML, насколько я помню, имеет абсолютно спокойный транскодинг в XML, равно как и Tree, разница исключительно в масштабах проектов и уровне поддержки со стороны сообщества (читай, гарантии поддержки и исправления ошибок).
При этом в YAML есть достаточно продуманная система типов, которая в отличии от Tree сделана с оглядкой на большинство языков.
Я, честно говоря, не понимаю как может сочетаться «Произвольная иерархия 5/5» и «Простота реализации 5/5» и «Удобство редактирования 5/5». Дело в том, что реализация — это не только парсер, это еще и перевод системы типов во внутренний формат языка приложения. И если типы YAML или JSON почти всегда имеют полное отражение внутри языка (то есть возможен беспроблемный перевод структуры данных приложение-форматированное представление и форматированное представление-приложение), а XML дает определенные возможности для сложных выборок в дальнейшем, то Tree, как я вижу, не обладает такими возможностями — он вызовет неиллюзорные проблемы на многих структурах во многих языках.
А если говорить про XML — стоит скорее уж спросить, какие есть в Tree возможности перемещения по дереву и выполнения Xpath-запросов. Думаю, это известный факт, что XML это в первую очередь структура данных в памяти, а не просто дамп, иначе можно было бы называть форматом данных и sqlite, например.
Единственный вариант поста, который бы звучал разумно — это
«Эй, чуваки, я запилил еще один формат, который умеет полноценно конвертироваться в XML и JSON, по сравнению с существующими у него такие-то плюшки:
-свободная грамматика, на которой можно реализовать то-то то-то и то-то
-по крайней мере такой же человекочитаемый как и YAML
-есть компактный формат для передачи по сети
-есть потоки
-уже есть плагин для IDEA
-легко сделать библиотеку под свой язык, под D энкодер/декодер размером всего в 100 строк, под JS — 120, вот примеры
и вот как он выглядит:…
»
А все это «да XML хуже, и JSON хуже, и YAML хуже, они все всасывают по всем статьям, вот вам табличка» — это сразу уже настораживает и выглядит как буллшит.
Потому что на всех языках есть веб-серверы или работа с сетью. PHP, ruby, python, go etc. Потому что там где работа с сетью — взаимодействие с веб-клиентами и браузерами. Где JS и JSON.parse().
XML — сложная структура, зачастую — обладающая избыточной сложностью, зачастую — сложная для программиста в своей формальности, зачастую — не совпадающая по типам.
Типы JSON — bool, number, string, map/hash/object и array — есть в практически всех языках нативно, и программисты на любом языке не испытывают проблем с осмыслением формата JSON, пусть он и нелеп.
Соответственно — на абсолютно всех языках уже есть рабочие и быстрые реализации парсера JSON и дампера в JSON, которые можно использовать.
А вообще нелепое решение. Непонятно, зачем.
Аргументы типа «он красивый, эффективный и быстрый» — дурацкие.
Аргументы типа «Он такой же простой для реализации парсера в любом языке, как ini-файл, вот доказательство, он парсится в JS быстрее чем встроенный парсер JSON — вот тесты во всех браузерах, он обладает такой же полнотой, как XML — не через трансляцию в XML, а нативно, он более эффективно работает с сетью и гзипается, чем любой из популярных стандартов» — не увидел.
Да и вообще, надо думать не от охренительности решения, а от задачи. Пока нет конкретной задачи или задач, которую продукт решает лучше чем существующие — смысла в нем нет. Поэтому минуснул.
Куча вещей, которые можно сделать препроцессорами, пара сомнительных мелких нововведений и :has, который, конечно, всем хотелось (да и мне тоже), но который стооолько геммороя принесет. И с быстродействием, и с починкой кривой верстки.
Проблема в том, что толком нет ни одного «флагмана» с небольшим размером экрана. Все эти mini и nano — это откровенно дерьмовые телефоны в похожем на флагман корпусе.
То есть: хреновая сборка, глючное ПО, маленькое коммьюнити на XDA (разрозненное по отдельным моделям сообщество) и как следствие — кривые кастомные билды, никаких обновлений до последнего андроида.
Я месяц назад искал себе телефон. У старого начал деградировать контроллер батареи, поэтому вариантов не было.
Три, всего три требования:
-экран от 3.5 до 4.5 дюймов (точнее привязка к габаритам, но по экрану примерно можно судить точные размеры)
-не скрипящий корпус
-обновление до Android 5 (или обещание обновления)
Под это требование подошел всего, черт возьми, один телефон: xperia z1 compact. Еще почти подходил z3 compact, но они почти по всем спекам совпадают (экран больше при таком же корпусе), и мне чисто внешне z1 понравился.
Больше ни у кого из производителей нет телефона, который будет нормально обновлен до последней версии андроида, и при этом не будет торчать из кармана.
Вообще нет.
На JS, html и css в среднем для мобильной (не адаптивной, а именно мобильной версии) по факту занимают 50-150 Кб.(сразу говорю, я говорю гзипнутые размеры, по факту это до 500 кб спокойно может быть).
Поэтому «средняя веб-страница весит более 1.7 МБ» в контексте мобильного jQuery — такое же лукавство, как и «на андроид 4.4 оно отрабатывает за столько-то секунд». Я могу для сравнения взять мой убитый Atrix 4g 2011 года выпуска — на нем для тестов сейчас Cyanogen 4.4 стоит, и Sony Z1 — на нем стоковый 4.4, и сравнить, за сколько тестовый скрипт загрузится и отработает. Уверен, разница будет в два раза минимум.
очень умилило «за минимальную скорость мобильного интернета возьмем 1мбит» и выведение закона мура по версиям андроида без уточнения девайсов.
а самого главного ответа — насколько jquery медленнее vanilla js — нет, чисто «да у наших пользователей, наверное, хорошие устройства с хорошим интернетом, они спокойно загрузят лишние 30кб жса». И да, «средняя страница — 1.7 мб» — это смешно. тут хорошо бы взять медиану, причем именно страницдля мобильных, а не всех сайтов мира
Как специалист я сраный фронтэндщик, который даже верстает медленно, зато умеет в джаваскрипт так, что все вокруг хренеют, на этом мои прикладные способности заканчиваются. То, что я умею дизайн, ux, настраивать nginx, спокойно кодить под рельсы, работать с кучей других языков, читать исходники v8, паять усилители, управлять разработчиками и разбираться в особенностях низкоуровневых протоколов — это круто, но это исключительно жырный плюс к тому, что я хороший фронтэндщик, который понимает как работает все, с чем он взаимодействует — начиная от того, как работают http-запросы на всех уровнях модели OSI и заканчивая тем, как повысить конверсию :) Потому и занимаюсь такими замороченными проектами.
И вот честно, никакого желания в этот неплохой багаж знаний добавлять особенности работы кэшей под джаву)
Но про Om запомню, спасибо.
А в нынешней версии (0.11.х) почти все детские ошибки исправили. Я за проектом почти год уже слежу и могу на полном серьезе сказать — 99% кейсов покрыто, и неожиданные ошибки в духе «что-то не работает, хотя должно» — на 0.11 у меня ни разу не появлялись. Да, были ляпы, связанные именно с новыми фичами (вот два, которые я закоммитил: #652, #594, например) — но конкретно с работой приложения они уже не были связаны.
Я бы сказал, что сейчас Vue — medium rare. Да, немного сыроват, но удовольствие от употребления будет наблюдаться у большинства :)
А насчет 50-60 обновлений в секунду — я в январе за подобный проект берусь. При этом это полноценный энтерпрайз с джавой на бэкенде и прочими удовольствиями жизни. Сейчас думаю над выбором: ангуляр или React+Om. При этом совесть меня склоняет к первому, а предчувствие жопы с перформансом — к второму. О Vue там и речи быть не может, конечно — даже не из соображений того, что он нестабилен так или иначе, а как минимум из-за того, что он поддерживаться будет не один год, и найти разработчиков на vue в дальнейшем будет сложнее, чем на react или angular.
Который при желании может прикидываться и ангуляром, и бэкбоном (в минимальной форме, конечно, но порог входа для тех, кто с ними имел дело, около плинтуса), летает (перфоманс — изумительный). Поддерживается буквально двумя людьми, но при этом мелкие issue-ы, которые я им пишу, например, вечером в четверг, в 6 утра в пятницу оказываются уже исправлены :)
Ну и подход очаровывает.
«DI? да нахрена вам DI в фреймворке для клиентсайда, у тебя есть AMD или CommonJS или что еще придет в твою больную голову»
«Что? Навигация? Чувак, тебе оно точно надо? Посмотри сколько клевых библиотек для навигации и без нашей помощи сделано, мы тебе сделали директиву для смены лейаутов, на здоровье»
«Компоненты? Службы? Модели? Директивы? Сервисы? Чо ты к нам пристал. На тебе фильтры для шаблонов, компоненты для, собственно, автономных компонентов, и директивы для всяких мимимишных жкверишных плагинов твоих, хватит тебе».
И реально хватает ведь.
А что самое крутое — он эти шаблоны свои — ну вот такой, например: {{ profiles[currentUserId] }} — (да-да, привет, ангуляр) он не разворачивает как-то, а превратит в
и если флаг debug установлен — он сам вызовет дебаггер на ошибке. А this реально указывает на окружение, которое можно полноценно поинспектировать.
Я так приложение в айфрейме дебажил (был один прикол, связанный с хромовскими приложениями). Как бы я с другими фреймворками это делал — вообще бы не представляю.
Просто альфа позволяет дать большое количество цветов, а пиксельарт (если я его правильно понимаю) обычно подразумевает 256-цветовую палитру. Соответственно нужно было бы делать приведение до ближайшего цвета.
О боже, еще один разработчик устройств решил, что кнопка камеры не нужна.
Чувствую, что скоро пойду писать петицию на change.org какой-нибудь, потому что снимать с наэкранной кнопкой — это ужас. Если при нажатии физической двухпозиционной кнопки получается хоть сколько-то плавное движение сделать, то по тапу на наэкранную устройство дергается и фото получается смазанным. Сколько не было устройств — так и не смог понять, как вообще люди снимают на них что-то.
я вообще не связан с 3д-моделированием на интеллектуальных алгоритмах.
То, что вы считаете чем-то слабо или криво работающим — не значит, что оно и правда так. Вы не знаете, что под капотом, не знаете, какие технологические решения были использованы, не знаете, сколько научно-исследовательской работы положено в основу всего, какие математические теории используются, но уже готовы критиковать.
Как человек, который активно пилит рекомендательную систему для музыки — могу по своему опыту сказать: если есть достаточно изначальных данных для анализа (в моем случае уже накопленное поведение людей), возможность протестировать новые модели анализа — крайне малого количества весьма неточных данных может оказаться достаточно для выстраивания весьма стройной модели.
В моем случае, например, из для жанров аудиозаписей (которые забиты весьма криво и неточно) — строится модель, в ней устраняются сглаживания, устраняются выбросы. После этого строится ранжирование по времени внесения записей, строится линия в 22-мерном пространстве, соответствующая изменению жанрового вектора, экстраполируется, уменьшается до единичного вектора, дальше все множество таких единичных векторов через гномоническую проекцию проецируется в 21-мерное пространство, в котором идут определения жанровых предпочтений пользователя, и далее через нейронную сеть (мне было лень писать уже дальше алгоритм для расчетов) идет обучение системы о том, что пользователю нравится и что не нравится.
И это все делается в браузере (в том числе в мобильничках) в реальном времени для 5000 векторов. С некоторыми допущениями, конечно — на разных стадиях отсеиваются заранее неподходящие вектора, например, есть таблицы для переводов и так далее.
А начиналось все с ранжирования по прямому сравнению порядка жанров — просто {рок; альтернатива; поп} и {рок; поп; альтернатива} считались ближе, чем {шансон; классика; рок}.
Если что — я это один хрен опубликую с картинками и графиками в ближайшее время вместе с новым релизом, в котором уже это все будет, поэтому и спокойно рассказываю все детали.
Как-то хреновенько приложение спроектировано. В такой ситуации в лучшем случае должно быть изменение локально объявленных переменных, которые прибиваются garbage collector-ом после колбэка.
Вы это. Инвалидацию кэша придумайте лучше. А данные хорошо бы хранить все-таки в модельке или сторадже каком-нибудь.
Не, в целом был бы это пост из песочницы — было бы круто.
Но вот для корпоративного блога, в котором пишут
немножко страшно становится.