Уже попробовал вдоль и поперек с несколькими разными фотками и десятком стилей. Главная проблема здесь видится в том что в отличие от каких-нибудь фильтров FaceApp (блендинговых если правильно помню), нейронка шедеврума не улавливает ключевых черт лица, так для большого носа картошкой она может "придумать" что он совсем другой формы. То же касается усов и бороды — в 1 из 3 случаев вообще их "не видит". Как бы начало очень хорошее, но локальный Stable Diffusion пока справляется лучше...
Максимально близко к этому в своё время пытались подойти именно Adobe со своим XD в том эпохальном представлении на Adobe MAX 2015 (Design with Data опередил своё время и это казалось просто нереально круто).
Sketch.app при всём своём очаровании ушел куда-то совсем не туда.
Был ещё интересный Invision app с большими амбициями (если не изменяет память то очень долго обещали прорыв со своей STUDIO, но по факту и половину фишек не реализовали от того что хотели)...
Эх, сейчас уже много чего забылось и вообще сферу деятельности поменял, а надо было заметки делать чтобы потом книгу по истории инструментов для веб-дизайна написать.
Ну может хоть какие-нибудь VK или Yandex чего придумают. Проблема в том что сейчас технологии позволяют сделать убер-инструмент, но вот сложность его проектирования во многом зависит ещё и от состояния обоих отраслей (дизайн и фронт), а в них сейчас хоть уже и не "дикий запад", но от состояния стабильности набора технологических решений очень далеко. Кроме того ещё сама система веб-стандартов — это бегущая курица без головы — вот какой-нибудь Draft стандарта например по leading trim уже как с апреля 23-го существует в рамках CSS Inline Layout Module Level 3, но ещё нигде не поддерживается, а заботливые разработчики Figma делают кнопочку в свойствах тестового блока "Vertical trim", и никто не пишет что напрямую это не стандартная фишка и надо её адаптировать, а дизайнер уже отчитался что все макеты согласованы и надо верстать, а все отступы из-за этого по факту нужно пересчитывать. Понятно что это частный случай и можно сказать мол один раз наступили, теперь делайте "так", но вот таких моментов десятки, и чтобы всё работало как полагается — на уровне индустрии нужна огромная бизнес-воля не только в виде ресурсов это реализовать но также внедрить, а главное — донести до широкой общественности как теперь надо пользоваться.
Прошу прощения что несколько сумбурно, но это уже эмоциональная сторона проявляется на фоне разочарования современным вебом, который при всём своём великом разнообразии больше похож на первичный бульон в котором только должна зародиться более сложная форма живой материи.
/* тут должна быть картинка про то что когда-то трава была зеленее, мы — моложе, а для счастья хватало Фотошопа с одной стороны и jQuery с другой. */
Удивительно что за последние 20-30 лет фундаментально никто не смог эту проблему решить в той степени чтобы больше не касаться... В своё время в Фотошопе с состояниями слоёв и смарт-объектами эмулировали компоненты, потом пришёл XD и казалось ну вот Adobe максимально близко к решению этой проблемы, и с их мощностями рано или поздно получится сделать единую систему в которой дизайн и фронт будут взаимно интегрированы, но и тут даже разочарование. Я уже молчу про всякие Zeplin + Sketch или Avocode... Теперь Figma со своим dev-mode вплотную приближается к решению проблемы но вот как будто всё равно уходит куда-то не туда, и приходится изобретать свои велосипеды.
Мне интересно получится ли дожить до того момента когда какое-нибудь действительно универсальное решение позволит без тонны костылей решать проблемы интеграции дизайна с фронтом и делать это предсказуемо и единообразно...
Вот уже месяца 3 пользуемся AX6000, и железка конечно вменяемая, но прошивки сырые до ужаса, например нельзя отдельному подключенному устройству поставить ограничение на занимаемую ширину канала, можно только наоборот — кому-то давать приоритеты. Настроек QoS практически нет, если один из подключенных клиентов вытягивает какой-нибудь жирный файл то канал забивается для всех, особенно мозги чудят если это видео, и штатными средствами никакой приоритизации для таких случаев толком не настраивается. Да и OneMesh до сих пор не доступен, хотя уже середина лета 2020 года, а он уже полгода висит на сайте в списке поддерживаемых… Антивирус из набора HomeCare вообще только три тумблера имеет и всё, то есть никакого белого списка или исключений, как сработал так и привет, пару раз то ему сайт 7zip не понравился, то во время загрузки моего собственного архива из облака обрывал соединение.
Все описанное актуально на момент комментария для устройства Archer AX6000 v1.0 и прошивки 1.1.0 Build 20200427 rel.80857(4555).
До сих пор отправляю многих коллег, субподрядчиков и заказчиков на эту статью. Все еще актуально. Разве что в идеале конечно уже некоторые части обновить бы.
Какой юзкейс у шаблонизаторов? Если без сарказма, то эстетическое наслаждение от наблюдения за чистым кодом без лишних скобочек и закрывающих тегов, при этом всегда четко видно и легко воспринимать уровень вложенности в структуре. Чувствую сейчас набегут сторонники автолинтеров и заминусуют, но каждому удобно что-то свое. С 2013 года связка sass + slim + coffee для рельсовых проектов настолько стала родной что везде хочется чего-то подобного. Для голого фронта без руби-окружения pug.js более чем адекватная замена slim, очень похожая по синтаксису.
Как-то так.
Он так и не научился дружить со Slim-подобными шаблонизаторами? Просто как-то подружить его без лишних костылей с Pug.js не вышло, а Emblem.js вроде не понятно как поддерживается, ибо он только с 1 и 2 версиями ember-cli официально совместим, и завести его по-человечески для 3 версии CLI тоже ума не хватает, а найти хоть где-нибудь вменяемый реальный пример в живом коде — затея вообще почти бессмысленная.
А вот с тем же React например Pug дружит официально через плагин.
Конечно, эстетически мне Ember очень нравится своей «Рельсовостью», он логичен и понятен тем кто пришел из мира Rails, но вот информации по нему за пределами официальных доков и пары годных статей на медиуме кот наплакал.
Пишите статьй, выкладывайте свои приложухи или примеры, хорошему фреймворку этого очень не хватает.
Конкретно если перейти и нажать «Слушать» на тот же Кровосток, там наряду с обычными композициями почти половина инструменталов на основные альбомы. Подобная картина например с исполнителями у которых при нажатии на «Слушать» играют и все сборники и ремиксы и инструменталы и лайвы, а слушать хочется только студийки например, или только номерные альбомы без мусора.
Идеальный вариант это просто дать возможность исключать неугодные треки или альбомы целиком чтобы сервис их вообще не учитывал до тех пор пока именно этот самый трек не захочет проиграть пользователь, либо пока не исключит из такого «игнора».
То есть чтобы мне прослушать песни исполнителя без минусов, нужно вручную создавать плейлист со всеми песнями кроме минусов, иного варианта нет?
Технологичненько.
Прослезился. Сам на MX440 с натугой запускал Сан-Андреас году примерно в 2005, правда на Win Me.
P.S. даже не помню насколько успешно, но потом сразу перешагнул на GeForce 4 вместе с апгрейдом всего остального и переходом на XP
Не знаю насколько именно в эту тему, но писал еще в конце декабря в поддержку, так и не ответили. Суть в чем. Почему нельзя в Я.Музыке по аналогии с Я.Радио ставить дизлайки или запрещать играть трек прямо в списке треков исполнителя или в альбоме? Например очень бесит когда хочешь прослушать треки исполнителя, а там половина альбомов — это просто минусы треков, причем явно никак нельзя исключить некоторые треки: даже если ставишь на треке «Не рекомендовать» (его надо проиграть, только тогда видно значок), и нажимаешь на прослушивание альбома или исполнителя, он все равно проигрывается! Это вот даже не логично. В чем тогда смысл «не рекомендовать»? Или по вашим сгенерированным плейлистам хочется как-то отдельные треки помечать неугодными, чтобы подобные игнорировались даже при прослушивании и не попадали в плейлисты. А так то инструментал попадет то какой-то «бонус-трек» то просто трехсекундный проигрыш (который на альбоме был но нафиг не нужен).
По обработке обратной связи реально пару раз писал, никто вообще не ответил ничего.
В остальном конечно сервис классный и в общем рекомендации устраивают, иногда что-то реально интересное попадается, но чаще всего разочаровывает и заставляет вернуться к локальному прослушиванию в той же клементине, где треки можно сортировать и фильтровать личному по рейтингу.
В общем гибкости не хватает Я.Музыке и логичности.
Не к вам лично, а к бизнесу в целом — я бы за такие подходы убивал. Формально это означает что-то вроде: «мы хотим набрать народу тупо для красивой цифры, а для чего нам это надо, да фиг знает, для масштаба».
Очень многие проекты на определенном этапе своего развития поступают также, а потом от этого часто возникают серьезные структурные проблемы в том числе когда не понятно для чего создавались целые отделы, каких-то разработчиков кидают то на роль техподдержки, то на роль мелких ПМ-ов которые должны показывать свою нужность определенными KPI иначе вылетят, кто-то просто пинает балду.
Я всецело уверен что любые кадровые амбиции должны быть подкреплены в первую очередь четким планом действий для чего нужны эти люди, и чем это обусловлено. Это называется компетентностным подходом к найму — вы нанимаете сотрудников обладающих определенными компетенциями, необходимыми на текущем этапе развития бизнеса, фактически исходя из сформулированных проблем бизнеса, для их решения.
Я все же надеюсь что не дураки это решение принимали и за ним стояло нечто большее чем просто погоня за масштабом и красивой цифрой. Однако к сожалению в статье об этом ничего не сказано.
Ну если так посудить, то 100 уже позволяет смотреть в два раза масштабнее чем когда 50, а обойдутся существенно дешевле чем 150 (хотя 150 это уже в три раза).
Реальной аргументации нет совершенно в статье, к этому и подкол. Статья была бы существенно полезнее если бы было расписано конкретно на каких компонентах Додо ИС провисы, почему они произошли, как их нашли, сколько конкретно нужно человек на решение каждой задачи, компетенции этих людей.
Например в нашем таск-трекере столько-то незакрытых задач по такому-то компоненту, чаще всего проблема в том-то, мы прикинули что нужно еще два джуна т.к. лид на это направление есть и он потянет их а задачи пустяковые. А вот это направление — новое, для него нужно сформировать команду из лида, стольки-то миддлов, и т.п.
Ну хотя бы что-то осмысленное с точки зрения статьи на хабр. Пока это просто запись маркетолога в ЖЖ-шечку с картинкой про красивую цифру.
P.S. мы на одном из проектов тоже страдаем, где есть реальные проблемы, мы знаем о них уже полгода, но бизнес не хочет их решать, просто согласовав в работу задачи на сравнительно небольшой объем, а ищет только новых людей кто будет не понятно чем заниматься.
P.P.S. вспоминается юмореска Романа Карцева про раков по пять рублей но больших или по три но маленьких.
Кратко суть статьи:
— Зачем Додо Пицце 250 разработчиков?
— Да хз, хотели 300 но обосновать не смогли, комдир сказал максимум 250 потянем, вот отсюда и цифра. А чем заниматься будут? Да найдем, у нас вон всякого сколько, и все делать везде надо.
Очередной раз когда комментарий интереснее статьи...
P.S. даже логотип для языка Chef взяли от системы управления конфигурациями, написанной на Ruby...
Уже попробовал вдоль и поперек с несколькими разными фотками и десятком стилей. Главная проблема здесь видится в том что в отличие от каких-нибудь фильтров FaceApp (блендинговых если правильно помню), нейронка шедеврума не улавливает ключевых черт лица, так для большого носа картошкой она может "придумать" что он совсем другой формы. То же касается усов и бороды — в 1 из 3 случаев вообще их "не видит". Как бы начало очень хорошее, но локальный Stable Diffusion пока справляется лучше...
Уже снова включили
Запустили с первого раза без единого тестировщика, может повезло
Максимально близко к этому в своё время пытались подойти именно Adobe со своим XD в том эпохальном представлении на Adobe MAX 2015 (Design with Data опередил своё время и это казалось просто нереально круто).
Sketch.app при всём своём очаровании ушел куда-то совсем не туда.
Был ещё интересный Invision app с большими амбициями (если не изменяет память то очень долго обещали прорыв со своей STUDIO, но по факту и половину фишек не реализовали от того что хотели)...
Эх, сейчас уже много чего забылось и вообще сферу деятельности поменял, а надо было заметки делать чтобы потом книгу по истории инструментов для веб-дизайна написать.
Ну может хоть какие-нибудь VK или Yandex чего придумают. Проблема в том что сейчас технологии позволяют сделать убер-инструмент, но вот сложность его проектирования во многом зависит ещё и от состояния обоих отраслей (дизайн и фронт), а в них сейчас хоть уже и не "дикий запад", но от состояния стабильности набора технологических решений очень далеко. Кроме того ещё сама система веб-стандартов — это бегущая курица без головы — вот какой-нибудь Draft стандарта например по leading trim уже как с апреля 23-го существует в рамках CSS Inline Layout Module Level 3, но ещё нигде не поддерживается, а заботливые разработчики Figma делают кнопочку в свойствах тестового блока "Vertical trim", и никто не пишет что напрямую это не стандартная фишка и надо её адаптировать, а дизайнер уже отчитался что все макеты согласованы и надо верстать, а все отступы из-за этого по факту нужно пересчитывать. Понятно что это частный случай и можно сказать мол один раз наступили, теперь делайте "так", но вот таких моментов десятки, и чтобы всё работало как полагается — на уровне индустрии нужна огромная бизнес-воля не только в виде ресурсов это реализовать но также внедрить, а главное — донести до широкой общественности как теперь надо пользоваться.
Прошу прощения что несколько сумбурно, но это уже эмоциональная сторона проявляется на фоне разочарования современным вебом, который при всём своём великом разнообразии больше похож на первичный бульон в котором только должна зародиться более сложная форма живой материи.
/* тут должна быть картинка про то что когда-то трава была зеленее, мы — моложе, а для счастья хватало Фотошопа с одной стороны и jQuery с другой. */
Удивительно что за последние 20-30 лет фундаментально никто не смог эту проблему решить в той степени чтобы больше не касаться... В своё время в Фотошопе с состояниями слоёв и смарт-объектами эмулировали компоненты, потом пришёл XD и казалось ну вот Adobe максимально близко к решению этой проблемы, и с их мощностями рано или поздно получится сделать единую систему в которой дизайн и фронт будут взаимно интегрированы, но и тут даже разочарование. Я уже молчу про всякие Zeplin + Sketch или Avocode... Теперь Figma со своим dev-mode вплотную приближается к решению проблемы но вот как будто всё равно уходит куда-то не туда, и приходится изобретать свои велосипеды.
Мне интересно получится ли дожить до того момента когда какое-нибудь действительно универсальное решение позволит без тонны костылей решать проблемы интеграции дизайна с фронтом и делать это предсказуемо и единообразно...
Все описанное актуально на момент комментария для устройства Archer AX6000 v1.0 и прошивки 1.1.0 Build 20200427 rel.80857(4555).
Как-то так.
А вот с тем же React например Pug дружит официально через плагин.
Конечно, эстетически мне Ember очень нравится своей «Рельсовостью», он логичен и понятен тем кто пришел из мира Rails, но вот информации по нему за пределами официальных доков и пары годных статей на медиуме кот наплакал.
Пишите статьй, выкладывайте свои приложухи или примеры, хорошему фреймворку этого очень не хватает.
Идеальный вариант это просто дать возможность исключать неугодные треки или альбомы целиком чтобы сервис их вообще не учитывал до тех пор пока именно этот самый трек не захочет проиграть пользователь, либо пока не исключит из такого «игнора».
Технологичненько.
P.S. даже не помню насколько успешно, но потом сразу перешагнул на GeForce 4 вместе с апгрейдом всего остального и переходом на XP
По обработке обратной связи реально пару раз писал, никто вообще не ответил ничего.
В остальном конечно сервис классный и в общем рекомендации устраивают, иногда что-то реально интересное попадается, но чаще всего разочаровывает и заставляет вернуться к локальному прослушиванию в той же клементине, где треки можно сортировать и фильтровать личному по рейтингу.
В общем гибкости не хватает Я.Музыке и логичности.
в идеале чтобы у каждого трека был свой «вес» по которому они подбираются, или система ± 5 баллов, что-то такое.
На заданный в заголовке статьи вопрос в тексте статьи четкого ответа не дается.
Очень многие проекты на определенном этапе своего развития поступают также, а потом от этого часто возникают серьезные структурные проблемы в том числе когда не понятно для чего создавались целые отделы, каких-то разработчиков кидают то на роль техподдержки, то на роль мелких ПМ-ов которые должны показывать свою нужность определенными KPI иначе вылетят, кто-то просто пинает балду.
Я всецело уверен что любые кадровые амбиции должны быть подкреплены в первую очередь четким планом действий для чего нужны эти люди, и чем это обусловлено. Это называется компетентностным подходом к найму — вы нанимаете сотрудников обладающих определенными компетенциями, необходимыми на текущем этапе развития бизнеса, фактически исходя из сформулированных проблем бизнеса, для их решения.
Я все же надеюсь что не дураки это решение принимали и за ним стояло нечто большее чем просто погоня за масштабом и красивой цифрой. Однако к сожалению в статье об этом ничего не сказано.
Реальной аргументации нет совершенно в статье, к этому и подкол. Статья была бы существенно полезнее если бы было расписано конкретно на каких компонентах Додо ИС провисы, почему они произошли, как их нашли, сколько конкретно нужно человек на решение каждой задачи, компетенции этих людей.
Например в нашем таск-трекере столько-то незакрытых задач по такому-то компоненту, чаще всего проблема в том-то, мы прикинули что нужно еще два джуна т.к. лид на это направление есть и он потянет их а задачи пустяковые. А вот это направление — новое, для него нужно сформировать команду из лида, стольки-то миддлов, и т.п.
Ну хотя бы что-то осмысленное с точки зрения статьи на хабр. Пока это просто запись маркетолога в ЖЖ-шечку с картинкой про красивую цифру.
P.S. мы на одном из проектов тоже страдаем, где есть реальные проблемы, мы знаем о них уже полгода, но бизнес не хочет их решать, просто согласовав в работу задачи на сравнительно небольшой объем, а ищет только новых людей кто будет не понятно чем заниматься.
P.P.S. вспоминается юмореска Романа Карцева про раков по пять рублей но больших или по три но маленьких.
— Зачем Додо Пицце 250 разработчиков?
— Да хз, хотели 300 но обосновать не смогли, комдир сказал максимум 250 потянем, вот отсюда и цифра. А чем заниматься будут? Да найдем, у нас вон всякого сколько, и все делать везде надо.