Вот уже месяца 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 потянем, вот отсюда и цифра. А чем заниматься будут? Да найдем, у нас вон всякого сколько, и все делать везде надо.
По порядку:
1. Никакого стим-движка не существует и никогда не существовало. Движок, на котором была сделана HL2 назывался Source.
2. Судя по всему Jeyko имел ввиду утекший альфа-билд 2003 года, в котором был недоделанный AI но уже работающая физика. Сам с ним в свое время игрался.
3. HL2 включала в себя часть переработанного кода Havok Physics версии 2. На том этапе кроме основных наработок по симуляции физики твердых тел и Ragdoll ничего особо и не было, то есть все остальное было реализовано средствами самого Source.
4. Несмотря на то что Havok сегодня все еще жив, последняя версия его вышла в 2017-м году и по популярности он существенно проигрывает реализации Nvidia Physx как по количеству фишек и плюшек так и по количеству игр, вышедших с его поддержкой. Из последнего крупного только Fallout 4 могу вспомнить.
5. По поводу того что роликом стоило впечатлиться — действительно ничего прорывного там нет как для ролика. Прорывное заключается в том что проект такого уровня выходит с BSD-3 в мир.
6. Кроме того что товарищ видел в альфе халфы, добавилась просто тонна фишек и плюшек которые идут «из коробки»: частицы/декали, симуляция тканей, симуляция разрушений, симуляция физики твердых тел, симуляция жидкостей и дымов, привычный уже Ragdoll, да даже элементарная логика конвейерных автоматов.
(напомню что в HL2 декали, взрывы, отдача оружия и много чего еще было реализовано средствами самого Source и было по сути заскриптовано)
7. То есть используя опенсорсное решение в виде Physx SDK 4 вы уже можете в своем проекте иметь все вышеперечисленные фишки, при этом никаких отчислений с продаж вашего коммерческого проекта Nvidia за это не попросит. А вот тот же Havok — будьте добры лицензируйте, а чего в нем нет — допиливайте сами ручками.
Так что это крайне правильное и сильное решение с их стороны. Единственное не могу однозначно сказать как раньше обстояли дела с Nvidia Physx в проектах на Unity или UE, но сейчас вы вольны вообще для проекта своего написать свой движок и использовать в нем наработки Physx.
Возможно немного сумбурно, но если что, думаю меня поправят.
Там весь замут был в том что оно очень грубо звучит практически в любом контексте, и чаще всего интерпретируется как негативное. Некоторая логика в этом есть, хотя лично мне было бы по барабану.
Fluent Design (не) сдвигая парадигмы
Разбираем первые устройства TP-Link с Wi-Fi 6: роутер Archer AX6000 и адаптер Archer TX3000E
Все описанное актуально на момент комментария для устройства Archer AX6000 v1.0 и прошивки 1.1.0 Build 20200427 rel.80857(4555).
Руководство для дизайнера по DPI
Ember.js: (снова) время попробовать
Как-то так.
Ember.js: (снова) время попробовать
А вот с тем же React например Pug дружит официально через плагин.
Конечно, эстетически мне Ember очень нравится своей «Рельсовостью», он логичен и понятен тем кто пришел из мира Rails, но вот информации по нему за пределами официальных доков и пары годных статей на медиуме кот наплакал.
Пишите статьй, выкладывайте свои приложухи или примеры, хорошему фреймворку этого очень не хватает.
Как рекомендовать музыку, которую почти никто не слушал. Доклад Яндекса
Идеальный вариант это просто дать возможность исключать неугодные треки или альбомы целиком чтобы сервис их вообще не учитывал до тех пор пока именно этот самый трек не захочет проиграть пользователь, либо пока не исключит из такого «игнора».
Влюбленный Сократ: кто на самом деле заложил основы западной философии
Как рекомендовать музыку, которую почти никто не слушал. Доклад Яндекса
Технологичненько.
Есть ли жизнь под Windows 98, часть вторая — про софт
P.S. даже не помню насколько успешно, но потом сразу перешагнул на GeForce 4 вместе с апгрейдом всего остального и переходом на XP
Как рекомендовать музыку, которую почти никто не слушал. Доклад Яндекса
По обработке обратной связи реально пару раз писал, никто вообще не ответил ничего.
В остальном конечно сервис классный и в общем рекомендации устраивают, иногда что-то реально интересное попадается, но чаще всего разочаровывает и заставляет вернуться к локальному прослушиванию в той же клементине, где треки можно сортировать и фильтровать личному по рейтингу.
В общем гибкости не хватает Я.Музыке и логичности.
Как рекомендовать музыку, которую почти никто не слушал. Доклад Яндекса
в идеале чтобы у каждого трека был свой «вес» по которому они подбираются, или система ± 5 баллов, что-то такое.
Зачем Додо Пицце 250 разработчиков?
На заданный в заголовке статьи вопрос в тексте статьи четкого ответа не дается.
Зачем Додо Пицце 250 разработчиков?
Очень многие проекты на определенном этапе своего развития поступают также, а потом от этого часто возникают серьезные структурные проблемы в том числе когда не понятно для чего создавались целые отделы, каких-то разработчиков кидают то на роль техподдержки, то на роль мелких ПМ-ов которые должны показывать свою нужность определенными KPI иначе вылетят, кто-то просто пинает балду.
Я всецело уверен что любые кадровые амбиции должны быть подкреплены в первую очередь четким планом действий для чего нужны эти люди, и чем это обусловлено. Это называется компетентностным подходом к найму — вы нанимаете сотрудников обладающих определенными компетенциями, необходимыми на текущем этапе развития бизнеса, фактически исходя из сформулированных проблем бизнеса, для их решения.
Я все же надеюсь что не дураки это решение принимали и за ним стояло нечто большее чем просто погоня за масштабом и красивой цифрой. Однако к сожалению в статье об этом ничего не сказано.
Зачем Додо Пицце 250 разработчиков?
Реальной аргументации нет совершенно в статье, к этому и подкол. Статья была бы существенно полезнее если бы было расписано конкретно на каких компонентах Додо ИС провисы, почему они произошли, как их нашли, сколько конкретно нужно человек на решение каждой задачи, компетенции этих людей.
Например в нашем таск-трекере столько-то незакрытых задач по такому-то компоненту, чаще всего проблема в том-то, мы прикинули что нужно еще два джуна т.к. лид на это направление есть и он потянет их а задачи пустяковые. А вот это направление — новое, для него нужно сформировать команду из лида, стольки-то миддлов, и т.п.
Ну хотя бы что-то осмысленное с точки зрения статьи на хабр. Пока это просто запись маркетолога в ЖЖ-шечку с картинкой про красивую цифру.
P.S. мы на одном из проектов тоже страдаем, где есть реальные проблемы, мы знаем о них уже полгода, но бизнес не хочет их решать, просто согласовав в работу задачи на сравнительно небольшой объем, а ищет только новых людей кто будет не понятно чем заниматься.
P.P.S. вспоминается юмореска Романа Карцева про раков по пять рублей но больших или по три но маленьких.
Зачем Додо Пицце 250 разработчиков?
— Зачем Додо Пицце 250 разработчиков?
— Да хз, хотели 300 но обосновать не смогли, комдир сказал максимум 250 потянем, вот отсюда и цифра. А чем заниматься будут? Да найдем, у нас вон всякого сколько, и все делать везде надо.
Выигрышная стратегия Гомоку – 35 ходов
«Яндекс» объяснил, почему удалил из поисковой выдачи официальный сайт Telegram
Nvidia сошла с ума и открывает PhysX под BSD-3
1. Никакого стим-движка не существует и никогда не существовало. Движок, на котором была сделана HL2 назывался Source.
2. Судя по всему Jeyko имел ввиду утекший альфа-билд 2003 года, в котором был недоделанный AI но уже работающая физика. Сам с ним в свое время игрался.
3. HL2 включала в себя часть переработанного кода Havok Physics версии 2. На том этапе кроме основных наработок по симуляции физики твердых тел и Ragdoll ничего особо и не было, то есть все остальное было реализовано средствами самого Source.
4. Несмотря на то что Havok сегодня все еще жив, последняя версия его вышла в 2017-м году и по популярности он существенно проигрывает реализации Nvidia Physx как по количеству фишек и плюшек так и по количеству игр, вышедших с его поддержкой. Из последнего крупного только Fallout 4 могу вспомнить.
5. По поводу того что роликом стоило впечатлиться — действительно ничего прорывного там нет как для ролика. Прорывное заключается в том что проект такого уровня выходит с BSD-3 в мир.
6. Кроме того что товарищ видел в альфе халфы, добавилась просто тонна фишек и плюшек которые идут «из коробки»: частицы/декали, симуляция тканей, симуляция разрушений, симуляция физики твердых тел, симуляция жидкостей и дымов, привычный уже Ragdoll, да даже элементарная логика конвейерных автоматов.
(напомню что в HL2 декали, взрывы, отдача оружия и много чего еще было реализовано средствами самого Source и было по сути заскриптовано)
7. То есть используя опенсорсное решение в виде Physx SDK 4 вы уже можете в своем проекте иметь все вышеперечисленные фишки, при этом никаких отчислений с продаж вашего коммерческого проекта Nvidia за это не попросит. А вот тот же Havok — будьте добры лицензируйте, а чего в нем нет — допиливайте сами ручками.
Так что это крайне правильное и сильное решение с их стороны. Единственное не могу однозначно сказать как раньше обстояли дела с Nvidia Physx в проектах на Unity или UE, но сейчас вы вольны вообще для проекта своего написать свой движок и использовать в нем наработки Physx.
Возможно немного сумбурно, но если что, думаю меня поправят.
В ядре Linux слово fuck заменили на hug
В ядре Linux слово fuck заменили на hug