Онлайн-чатик — это конкурент почты. А чит в игре — это «диверсия» против компании.
«Автоматизированная стрельба из игровых танчиков» делает массовую аудиторию проекта недовольной и способствует оттоку пользователей с площадки, а соотвественно — оттоку потенциальной прибыли на внутриигровых покупках. Учитывая многомиллионную аудиторию проекта, даже небольшой процент пользователей конвертируется в большие суммы денег в течение какого-то периода времени. Если чит в игре работает годами, то и потеря потенциальной прибыли получается очень большой. А масштаб преступления напрямую влияет на строгость наказания.
Сгласен с пунктами 1 и 2. Но в том и дело, что у программистов всегда мало времени и команды программистов не состоят на 100% из идеальных работников :)
На практике никто никогда не позволит программистам условно целый год ваять какое-то супер-масштабируемое «произведение искусства», которое оценит каждый программист и похлопает по плечу. Владелец бизнеса по плечу не похлопает. Всегда есть бюджет, сроки и т.п. Поэтому и видим время от времени решения на скорую руку, хардкод и прочее, то что любой опытный программист понимает как некачественный код, но «так и быть, сделаем рефакторинг позже». А потом уходит из компании/проекта.
Мы живём не в видеальном мире. У вас в команде из 5 программистов никогда не будет 5 программистов-суперменов, где каждый на 100% освоил синтаксис, мыслит на 100% абстрактно и пишет на 100% масштабирумый код. В конце концов, всем свойственно делать ошибки будь то сознательно (см. пункт 1) или бессознательно.
P.S. Не путайте фразу «нормальная эволюция» с понятием «так и должно быть». Лапша — это плохо и так не должно быть.
Но «лапша» — это нормальная эволюция любого большого проекта. Так как на самой ранней стадии нельзя предвидеть то, как будет меняться бизнес и каким он будет через 5 лет. «По дороге» в бизнесе всегда меняются приоритеты, появляются/закрываются разные направления и сферы деятельности и т.д. С этим нужно смириться. Что есть — то есть. Это мир в котором мы живём.
То есть у вас есть выбор: с одной стороны свой кастомный паттерн, так сказать, гибкая архитектура или сдругой — Ангуляр с его высеченным в камне на веки паттерном. Что выберете в долгосрочной перспективе?
И вообще-то здесь есть одно «но». Именно потому что мир меняется и требования к проектам у всех разные, Ангуляр тоже пытается адаптироваться выпуская новые версии фреймворка. Для нас очевидно, разработчики разного софта выпускают новые версии. Но сам тот факт, что выходят новые версии Ангуляра говорит о том, что он не идеален. Потому что если бы паттерны Ангуляра изначально были бы «идеалными» и подходили бы всем, то не было бы и новых версий. Замкнутный круг. Но это мир в котором мы живём...
Придерживайтесь паттерна здравого смысла. Планируйте проект и его архитектуру заранее на сколько позволяет ситуация. Ну а потом по старинке: HTML / CSS / JS. Сам так делаю — всё хорошо работает и поддерживается.
Нет ничего страшного в отстутсвии фреймворка. Автор прав насчёт скорости — она не такая уж низкая, тем более, с современной браузерной поддержкой новых «плюшек» в HTML, CCS и JS.
Какой смысл спорить с командой об оптимизации и кому-то что-то доказывать? Изучите свою целевую аудиторию, донесите информацию до команды, поставьте их перед фактом. И не нужны никакие споры и научные статьи доказывающие важность оптимизации.
Например:
Если бОльшая часть аудитории вашего проекта сидит на IE7, то у меня для вас плохие новости: вам в 2021 году нужно бует затачивать сайт под IE7. И поспорит ли тут с вами команда если они будут в курсе происходяго? — Нет.
Ещё пример:
Статистика показывает, что всемирный мобильный трафик превысил трафик с настольных ПК. Вёрстка под мобильные устройства очень важна? Принцип вёрстки "mobile first" приобретает всё больше смысла? — Мне по барабану. 80% целевой аудитории некоторых моих сайтов — это люди с большими мониторами и мобильными версиями этих сайтов я занимаюсь в последнюю очередь.
Так что не нужно ни с кем спорить и ничего доказывать. Просто делайте наилучшее решение для вашей аудитории и убедитесь, что разработчики понимают контекст происходящего.
Roughness или «шероховатость». Данный атрибут отображает насколько “шероховата” поверхность, тем самым воздействуя на рассеяние света от поверхности. Измеряется от 0 до 1, где 0 — идеально плоская, а 1 — полностью шероховатая поверхность, которая отражает лишь небольшое количество света.
Тут в конце ошибка. Roughness — это не количество отражаемого света, а именно рассеивание (как вы написали выше). Это значит, что roughness со значением 1 максимально сильно рассеивает свет так что на поверхности не видно никаких бликов. На количество рассеиваемого света влияет baseColorFactor/baseColorTexture в паре с metallicFactor
Пример со значениями roughness, слева направо: 0, 0.5, 1.
Довольно низкий порог входа. Весьма большое, как мне кажется, количество задач покрывается знаниями, которые можно получить за 2-3 месяца с нуля.
Низкий порог входа только для тех, кто копипастит примеры jQuery со Stack Overflow.
Я пару лет активно занимался кастомным фронтедом HTML/CSS/Vanilla JS (никакого jQuery или Бутстрапа). А потом за 2-3 месяца освоил бекенд (настройка сервера и NodeJS). До этого я боялся бекенда. Думал, что им занимаются только хардкорные программисты. Но я очень удивился, когда осознал, что те логические задачи которые мне приходится решать на фронденте на порядок сложнее тех, с которыми я сталкиваюсь на бекенде. Это в разрезе одного среднестатистического сайта на котором я делаю и фронт, и бек.
Тут автор правильно заметил: фронтендер имеет дело с асинхронным кодом и «многослойным» приложением в котором вам параллельно нужно решать разные задачи (дирижировать этим всем). А на бекенде, грубо говоря: точка входа и точка выхода. И вся работа бекендера между этими точками «по прямой». Это я про обработку запроса.
Это моё субъективное впечатление на основе описанного выше опыта.
Да это не статья, а сплошной перевод текста через Google Translater (или чего похуже). Почему-то человек даже не поставил метку «перевод».
Читать невозможно: описания программ — это набор копипаст с первой страницы маркетинговых материалов. При том, дословно переведённый каким-то роботом.
«Ошеломило» — слишком громкое слово в данном случае. Просвечиваете манускриптов и картин ультрафиолетом — обычная практика у историков и применяется давно. А то, что о скрытом тексте на этой рукописи никто не знал так это потому что не считали нужным это изучать. Вообще-то, половина всех пергаментов, если их просветить, то покажут «скрытый» текст. И это так же как с палеонтологией: под нами, прямо сейчас, куча костей динозавров — нужно только начать копать. Но от того, что мы перекопаем всю планету и выкопаем какого-то тысячного по счёту тиранозавра и 100500-го птеродактиля, науке легче не станет — никакой новой информации мы из этого не почерпнём. И мы этого не делаем, потому что ресурсы ограничены.
Так же и с просветкой манускриптов — просвечивают только те, которые потенциально важны и интересны, а не всё подряд. Поэтому удивляться тому что студенты что-то там нашли не нужно. Новость высосана из пальца и подана очень пафосно.
Спасибо за статью! Есть полезные находки.
На заметку:
Этот карандаш — не растровое изображение, но он «вырезан вручную» с помощью CSS.
В случае, когда в английском вы видите ", but" (после запятой), то в такой форме речи это переводится не как ", но", а как ", а".
То есть должно было быть так:
Этот карандаш — не растровое изображение, а он «вырезан вручную» с помощью CSS.
Слишком абстрактные логотипы у нейросети. И речь не в том, что нет очевидной привязки к сфере деятельности компании — это как раз-таки приемлемо. Сами формы и графический ритм логотипов примитивны на столько, что порождают две проблемы:
1. Логотипы на столько абстрактны, что просто не идентифицируются целевой аудиторией как логотипы. Например: увидев абстрактную закорючку в печатных изданиях, интернете и т.п. без должного контекста человек не поймёт, что то на что он смотрит — это «клеймо» компании (чем в сущности и есть любой логотип). А подумает, что смотрит на картину Кандинского, на мазню ребёнка или на какой-то неопластицизм.
2. Или наоборот, слишком абстрактные, но запомнившиеся формы могут напоминать о логотипе компании в том контексте, когда это совсем неуместно. Например: вы пошли в туалет и смотрите на жёлтую овальную форму в унитазе с мочой и в этот момент, друг, вспоминаете логотип булочной (привет от ассоциативной памяти). Интересно, «Булочная» хотела бы чтобы вы о них вспомнили в таком контексте?
P.S. Да, логотипы оригинальные, но у меня большие сомнения насчёт того, чтобы они эффективно выполняют свою функцию.
Отличная статья. Давно уже нужно опустить дизайнеров с небес на землю. Потому что пока они в небе, то они художники, а не дизайнеры. А это разные вещи.
Спасибо за статью. Нужно побольше таких писать, чтобы интересующиеся заказчики находили их, читали и просвещались.
Только есть два замечания.
Так как статья рассчитана на тех кто вообще не в теме, то рекомендовал бы использовать меньше специфического сленга. Например, писать «утверждают» вместо «апрувят».
Behance и dribble хороши тем, что вы сначала видите работы и, если вас устраивает их уровень, пишете фрилансеру. Минус — вас игнорят или отвечают через 100 лет.
Нужно ещё уметь писать письма. :) И никогда не писать через сайты — только на имейл.
P.S. Я и сам иногда игнорю, если мне присылают письма типа: «Привет! Мы тут делаем проект по анимации и если тебе интересно давай поработаем.». Просто не хочется тратить на таких людей время.
Согласен. Не литературный перевод.
Вообще тут на Хабре с переводами плохо дело. Люди часто переводят дословно из-за чего стилистика речи выглядит странно (даже при корректном переводе). Русский айтишник, разговаривая с коллегой, никогда бы не выражался так как «разговаривают» переводчики Хабра.
В данном случае, чтобы фраза
Возможно, вас интересуют подробности о работе этого свойства. Позвольте мне о них рассказать.
звучала по-русски, то можно было бы написать просто:
«Работает это так...»
или
«Если вам интересно как это работает, то...»
Это не дословный перевод, но смысл не меняет. А воспринимается проще.
В общем, переводы на Хабре видно за версту даже не глядя на бейджик «Перевод».
Насчет байтов понятно. Мой пример можно расширить под 64 значение: модифицировать так, чтобы закончился не только алфавит, но и A-Z0–9_-. А потом начать сначала по тому же принципу.
Но я, в данном случае, все равно, не понимаю назначения хеша. Ведь мы избегаем коллизий добавляя ещё один символ к строке.
Онлайн-чатик — это конкурент почты. А чит в игре — это «диверсия» против компании.
«Автоматизированная стрельба из игровых танчиков» делает массовую аудиторию проекта недовольной и способствует оттоку пользователей с площадки, а соотвественно — оттоку потенциальной прибыли на внутриигровых покупках. Учитывая многомиллионную аудиторию проекта, даже небольшой процент пользователей конвертируется в большие суммы денег в течение какого-то периода времени. Если чит в игре работает годами, то и потеря потенциальной прибыли получается очень большой. А масштаб преступления напрямую влияет на строгость наказания.
Так понятнее?
content: attr(alt)не работает в Сафари.Сгласен с пунктами 1 и 2. Но в том и дело, что у программистов всегда мало времени и команды программистов не состоят на 100% из идеальных работников :)
На практике никто никогда не позволит программистам условно целый год ваять какое-то супер-масштабируемое «произведение искусства», которое оценит каждый программист и похлопает по плечу. Владелец бизнеса по плечу не похлопает. Всегда есть бюджет, сроки и т.п. Поэтому и видим время от времени решения на скорую руку, хардкод и прочее, то что любой опытный программист понимает как некачественный код, но «так и быть, сделаем рефакторинг позже». А потом уходит из компании/проекта.
Мы живём не в видеальном мире. У вас в команде из 5 программистов никогда не будет 5 программистов-суперменов, где каждый на 100% освоил синтаксис, мыслит на 100% абстрактно и пишет на 100% масштабирумый код. В конце концов, всем свойственно делать ошибки будь то сознательно (см. пункт 1) или бессознательно.
P.S. Не путайте фразу «нормальная эволюция» с понятием «так и должно быть». Лапша — это плохо и так не должно быть.
Но «лапша» — это нормальная эволюция любого большого проекта. Так как на самой ранней стадии нельзя предвидеть то, как будет меняться бизнес и каким он будет через 5 лет. «По дороге» в бизнесе всегда меняются приоритеты, появляются/закрываются разные направления и сферы деятельности и т.д. С этим нужно смириться. Что есть — то есть. Это мир в котором мы живём.
То есть у вас есть выбор: с одной стороны свой кастомный паттерн, так сказать, гибкая архитектура или сдругой — Ангуляр с его высеченным в камне на веки паттерном. Что выберете в долгосрочной перспективе?
И вообще-то здесь есть одно «но». Именно потому что мир меняется и требования к проектам у всех разные, Ангуляр тоже пытается адаптироваться выпуская новые версии фреймворка. Для нас очевидно, разработчики разного софта выпускают новые версии. Но сам тот факт, что выходят новые версии Ангуляра говорит о том, что он не идеален. Потому что если бы паттерны Ангуляра изначально были бы «идеалными» и подходили бы всем, то не было бы и новых версий. Замкнутный круг. Но это мир в котором мы живём...
Придерживайтесь паттерна здравого смысла. Планируйте проект и его архитектуру заранее на сколько позволяет ситуация. Ну а потом по старинке: HTML / CSS / JS. Сам так делаю — всё хорошо работает и поддерживается.
Нет ничего страшного в отстутсвии фреймворка. Автор прав насчёт скорости — она не такая уж низкая, тем более, с современной браузерной поддержкой новых «плюшек» в HTML, CCS и JS.
Какой смысл спорить с командой об оптимизации и кому-то что-то доказывать? Изучите свою целевую аудиторию, донесите информацию до команды, поставьте их перед фактом. И не нужны никакие споры и научные статьи доказывающие важность оптимизации.
Например:
Если бОльшая часть аудитории вашего проекта сидит на IE7, то у меня для вас плохие новости: вам в 2021 году нужно бует затачивать сайт под IE7. И поспорит ли тут с вами команда если они будут в курсе происходяго? — Нет.
Ещё пример:
Статистика показывает, что всемирный мобильный трафик превысил трафик с настольных ПК. Вёрстка под мобильные устройства очень важна? Принцип вёрстки "mobile first" приобретает всё больше смысла? — Мне по барабану. 80% целевой аудитории некоторых моих сайтов — это люди с большими мониторами и мобильными версиями этих сайтов я занимаюсь в последнюю очередь.
Так что не нужно ни с кем спорить и ничего доказывать. Просто делайте наилучшее решение для вашей аудитории и убедитесь, что разработчики понимают контекст происходящего.
Тут в конце ошибка. Roughness — это не количество отражаемого света, а именно рассеивание (как вы написали выше). Это значит, что roughness со значением 1 максимально сильно рассеивает свет так что на поверхности не видно никаких бликов. На количество рассеиваемого света влияет baseColorFactor/baseColorTexture в паре с metallicFactor
Пример со значениями roughness, слева направо: 0, 0.5, 1.
Это ложное впечатление. Прочитайте мой комментарий выше: habr.com/ru/post/535724/#comment_22530464
Низкий порог входа только для тех, кто копипастит примеры jQuery со Stack Overflow.
Я пару лет активно занимался кастомным фронтедом HTML/CSS/Vanilla JS (никакого jQuery или Бутстрапа). А потом за 2-3 месяца освоил бекенд (настройка сервера и NodeJS). До этого я боялся бекенда. Думал, что им занимаются только хардкорные программисты. Но я очень удивился, когда осознал, что те логические задачи которые мне приходится решать на фронденте на порядок сложнее тех, с которыми я сталкиваюсь на бекенде. Это в разрезе одного среднестатистического сайта на котором я делаю и фронт, и бек.
Тут автор правильно заметил: фронтендер имеет дело с асинхронным кодом и «многослойным» приложением в котором вам параллельно нужно решать разные задачи (дирижировать этим всем). А на бекенде, грубо говоря: точка входа и точка выхода. И вся работа бекендера между этими точками «по прямой». Это я про обработку запроса.
Это моё субъективное впечатление на основе описанного выше опыта.
Читать невозможно: описания программ — это набор копипаст с первой страницы маркетинговых материалов. При том, дословно переведённый каким-то роботом.
«Ошеломило» — слишком громкое слово в данном случае. Просвечиваете манускриптов и картин ультрафиолетом — обычная практика у историков и применяется давно. А то, что о скрытом тексте на этой рукописи никто не знал так это потому что не считали нужным это изучать. Вообще-то, половина всех пергаментов, если их просветить, то покажут «скрытый» текст. И это так же как с палеонтологией: под нами, прямо сейчас, куча костей динозавров — нужно только начать копать. Но от того, что мы перекопаем всю планету и выкопаем какого-то тысячного по счёту тиранозавра и 100500-го птеродактиля, науке легче не станет — никакой новой информации мы из этого не почерпнём. И мы этого не делаем, потому что ресурсы ограничены.
Так же и с просветкой манускриптов — просвечивают только те, которые потенциально важны и интересны, а не всё подряд. Поэтому удивляться тому что студенты что-то там нашли не нужно. Новость высосана из пальца и подана очень пафосно.
На заметку:
В случае, когда в английском вы видите ", but" (после запятой), то в такой форме речи это переводится не как ", но", а как ", а".
То есть должно было быть так:
И звучать стало по-нашему :)
1. Логотипы на столько абстрактны, что просто не идентифицируются целевой аудиторией как логотипы.
Например: увидев абстрактную закорючку в печатных изданиях, интернете и т.п. без должного контекста человек не поймёт, что то на что он смотрит — это «клеймо» компании (чем в сущности и есть любой логотип). А подумает, что смотрит на картину Кандинского, на мазню ребёнка или на какой-то неопластицизм.
2. Или наоборот, слишком абстрактные, но запомнившиеся формы могут напоминать о логотипе компании в том контексте, когда это совсем неуместно.
Например: вы пошли в туалет и смотрите на жёлтую овальную форму в унитазе с мочой и в этот момент, друг, вспоминаете логотип булочной (привет от ассоциативной памяти). Интересно, «Булочная» хотела бы чтобы вы о них вспомнили в таком контексте?
P.S. Да, логотипы оригинальные, но у меня большие сомнения насчёт того, чтобы они эффективно выполняют свою функцию.
Только есть два замечания.
Так как статья рассчитана на тех кто вообще не в теме, то рекомендовал бы использовать меньше специфического сленга. Например, писать «утверждают» вместо «апрувят».
Нужно ещё уметь писать письма. :) И никогда не писать через сайты — только на имейл.
P.S. Я и сам иногда игнорю, если мне присылают письма типа: «Привет! Мы тут делаем проект по анимации и если тебе интересно давай поработаем.». Просто не хочется тратить на таких людей время.
Вообще тут на Хабре с переводами плохо дело. Люди часто переводят дословно из-за чего стилистика речи выглядит странно (даже при корректном переводе). Русский айтишник, разговаривая с коллегой, никогда бы не выражался так как «разговаривают» переводчики Хабра.
В данном случае, чтобы фраза
звучала по-русски, то можно было бы написать просто:
«Работает это так...»
или
«Если вам интересно как это работает, то...»
Это не дословный перевод, но смысл не меняет. А воспринимается проще.
В общем, переводы на Хабре видно за версту даже не глядя на бейджик «Перевод».
Но я, в данном случае, все равно, не понимаю назначения хеша. Ведь мы избегаем коллизий добавляя ещё один символ к строке.