А то выгорание это только в айти. Не надо думать что если, айтишка то сразу возможно модное слово выгорание.
Я уже написал, что думаю. "Выгорают" те, кто занимается не своим делом. Или те, кто в принципе считает, что выходя на работу, делают одолжение работодателю самим фактом своего присутствия – а когда выясняется, что от них ещё и каких-то результатов ожидают, это напрочь ломает их картину мира.
Собрались в зуме несколько человек, которые преодолели пятилетний рубеж в ИТ
Полагаю, если бы,собрались те, кто преодолел рубеж лет хотя бы в 15 (и лучше не в зуме, а за чашечкой пива), у них нашлись бы более интересные темы, чем "выгорание". Каждому своё: если вы "выгорели" за такой срок – это вообще не ваша сфера деятельности, ищите другую.
Понятия не имею 🙂 Не использовали мы его. Пишут, что готов, а как на практике – смотреть нужно. Веб тоже вроде как готов, и у нас даже частично в продакшн – но таки чуть сыроват ещё. Вот только что новую версию выкатили, посмотрим.
Только для этого нужно тестировать, а это уже после компиляции и цикл разработки дольше.
Да ладно. Вот SQL как раз можно в любой момент проверить – причём не только на синтаксис, а ещё и на логическую правильность. Заходишь в шелл тестовой базы, запускаешь свой запрос и смотришь, что вернул. В случае же с ОРМ результат можно будет увидеть только после сборки, и если ошибся, придётся снова пересобирать всё, или как минимум, какую-то часть проекта. Так что где тут бензопила (вжик...), а где топор – вовсе не так однозначно.
код гарантирует синтаксически верный запрос, а также проверку типов, ещё на этапе компиляции.
Ошибку синтаксиса SQL, наверное, тоже непросто пропустить – если код хоть как-то тестируется. Проверка типов – замечательно. Но не получается, что снимаем одну проблему, а взамен получаем кучу других? На том же хабре весьма регулярно появляются статьи об их успешном (или не очень) преодолении. Как вот эта, например. Никого не отговариваю, просто интересно.
да хоть с помощью сырого SQL
Вот это, по-моему, звучит совсем нехорошо. Если технология не позволяет получить нужный результат, надо брать другую, а не зоопарк устраивать.
Вот честно, не понимаю я смысла в ОРМ. В частности, в примерах автора SQL читается намного лучше, чем эквивалентный ему код – при том, что запросы все очень простые. Как уложить в ОРМ по-настоящему сложный запрос и не сойти с ума (особенно на этапе поддержки, когда понадобится его чуток поменять) – для меня загадка. А полный перевод сколько-нибудь сложного проекта на другую базу нужен примерно никогда. Оно точно того сто̀ит?
Нет. Нормальное предложение звучало бы примерно: Which setting affects the limit of issue list API requests rate? Оно понятно всем и сразу, и учить писать нужно именно так.
Брала примеры и делала скриншоты из реальных дискуссий
А с чего Вы взяли, что дискуссии на гитхабе ведут исключительно хорошо владеющие английским? Настолько хорошо, что на их примере можно учить других? Если Вы английский филолог, то грамматику Вам должны были преподавать в ВУЗе, и строить обучение ей других на основе случайных фраз, надёрганных в интернете – как минимум, странно.
UPD: перечитал, моя версия понятна, но на английском звучит грубовато. Правильно было бы нечто вроде: Would you elaborate, which...
Буду рада увидеть примеры, обмен опытом всегда ценен
Если бы Вы использовали тексты, а не скриншоты с презентаций, можно было бы попробовать процитировать и предложить нормальные версии. А так перенабивать каждую фразу просто лень. Пожалуй, отмечу только сиреневый (3). Вы сама хоть понимаете, что там написано? Я нет. Если перенести слово issue в конец предложения, оно обретает некий смысл – хотя тоже весьма расплывчатый.
Английский не преподаю, и не считаю, что хорошо его знаю. Но использую ежедневно, в общении в том числе с нативными спикерами. Извините, но буквально все Ваши примеры звучат до крайности ненатурально. Носители языка, да и просто люди, свободно им владеющие, в жизни так не напишут. Не надо такому учить, пожалуйста.
Что поправили-то? Поменяли миллион на десять? На скриншоте рядом с цифрой 100000 нет символа % – а там, где он есть, значения не превышают 100. Я с АЕ не работал никогда, и не знаю, в каких попугаях там цифры. Но точно не в процентах, это просто не имеет смысла в пределах одного цветового пространства – только при сравнении охватов в разных. Но и в этом случае ни о каких многократных различиях речи быть не может. Вот например, в телевидении было принято измерять уровни сигнала в IRE – а потом неожиданно появились компьютерные видео, где ограничение уровней 16-235 оказалось ненужным, и оказалось, что они выходят за диапазон 0-100%. Но долгое время продолжали мерить в IRE – просто по привычке, и получился выглядящий абсурдно, но понятный профессионалам индустрии диапазон от -7% до +109%.
ставят лампы (или пиксели в случае с OLED/MicroLED) в несколько раз ярче, чем надо, но используют большую часть времени только на пару десятков %. И вот эти условные 20% реальной яркости считаются за 1.0.
Да что ж Вы такое пишете-то? 🤦♂️ О какой характеристике речь? Дайте ссылку. Есть максимальная яркость – которую может иметь вся площадь экрана в течение неопределённого времени, и пиковая – нормируется либо по времени (редко), либо (обычно) по площади экрана. Например, 1000 нит 10% означает, что не более 10% площади экрана может одновременно излучать свет с такой яркостью.
Если когда-нибудь индустрия придёт к дефолтной линейной (16- или 24-битной) шкале яркости
Да вроде давно уже пришла, 16-бит ACES при редактировании используется повсеместно. Другое дело, что потом всё равно требуется трансформация в цветовое пространство, поддерживаемое оконечными устройствами.
Так вот, в процессе отладки на HDR‑играх я частенько обнаруживал, что значение пикселя может переваливать вообще за 10,0, даже не за 5,4.
Это детали внутренней реализации конкретного кодека, к стандарту HDR никакого отношения не имеющие и в данном контексте просто вводящие в заблуждение. Например, ни в одном видеоредакторе яркость 540, и тем более 1000% установить невозможно.
Поэтому я, опять же, чрезмерно упрощая, упомянул именно 1000, как минимальный порог, с которого даже для неискушённого человека начинаются существенные различия.
Буквально несколько дней назад купил себе новый ноутбук. 4K HDR-600 TrueBlack, пиковая яркость 750. Собственно, одной из причин выбора именно этой модели была поддержка работы с HDR контентом. Могу заверить, что разница огромная. Я бы даже сказал, что при обычном дневном освещении яркость близка к чрезмерной, больше может понадобиться только на прямом солнечном свете.
Если говорить очень упрощённо HDR — это когда пиксель может быть ярче 100%.
Извините, это чрезмерная упрощённость. Ярче 100% какого цветового пространства? И что за дикие цифры, 540%? Rec.2020 имеет максимальную яркость 107% от Rec.709, например.
Ключевая особенность, которой должна обладать камера, чтобы снимать настоящий HDR — гибридная логарифмическая гамма.
🤦♂️ HLG – просто один из стандартов той самой компрессии изображения, позволяющий его отображать с приемлемой точностью как на HDR, так и на SDR устройствах. Наличие его поддержки в камере (большая редкость даже в топовых моделях) всего лишь позволяет получать фото/видео с большим ДД без постобработки. При этом съёмка в RAW, хоть и требует постобработки, ДД всегда даст заведомо больший.
Важно, чтобы такой дисплей имел многозональную подсветку, 10-битную матрицу и пиковую яркость не менее 1000 нит, иначе HDR он не сможет показать.
Вообще-то есть разные стандарты HDR. HDR-400, например, требует 400 нит яркости, а вовсе не 1000. И картинка будет точно лучше, чем SDR. А HDR-5000 просто не существует, максимум 4000 – это стандарт для оборудования кинотеатров высшего класса. Не уверен даже, что есть хоть одно реальное устройство, которое ему соответствует.
Мой вопрос был об источнике информации о том, что организации, где кто-то кого-то ставит на место, обычно делают плохие продукты. Мне очень любопытны наблюдения, на основе которых сделан именно этот вывод.
Я не пойму, Вы таким образом трафик своей статье собираете, или что? Вот прямо в подробностях тут расписать: кто, когда, и по какому поводу начал гнуть пальцы, какой проект делался и к каким результатам это привело? Серьёзно? Есть вещи очевидные – когда люди заняты работой, она делается. Когда выяснением, где чьё место и взаимной расстановкой по таким местам – то нет.
Я уже написал, что думаю. "Выгорают" те, кто занимается не своим делом. Или те, кто в принципе считает, что выходя на работу, делают одолжение работодателю самим фактом своего присутствия – а когда выясняется, что от них ещё и каких-то результатов ожидают, это напрочь ломает их картину мира.
От вида деятельности не зависит.
Полагаю, если бы,собрались те, кто преодолел рубеж лет хотя бы в 15 (и лучше не в зуме, а за чашечкой пива), у них нашлись бы более интересные темы, чем "выгорание". Каждому своё: если вы "выгорели" за такой срок – это вообще не ваша сфера деятельности, ищите другую.
Понятия не имею 🙂 Не использовали мы его. Пишут, что готов, а как на практике – смотреть нужно. Веб тоже вроде как готов, и у нас даже частично в продакшн – но таки чуть сыроват ещё. Вот только что новую версию выкатили, посмотрим.
Да ладно. Вот SQL как раз можно в любой момент проверить – причём не только на синтаксис, а ещё и на логическую правильность. Заходишь в шелл тестовой базы, запускаешь свой запрос и смотришь, что вернул. В случае же с ОРМ результат можно будет увидеть только после сборки, и если ошибся, придётся снова пересобирать всё, или как минимум, какую-то часть проекта. Так что где тут бензопила (вжик...), а где топор – вовсе не так однозначно.
Ошибку синтаксиса SQL, наверное, тоже непросто пропустить – если код хоть как-то тестируется. Проверка типов – замечательно. Но не получается, что снимаем одну проблему, а взамен получаем кучу других? На том же хабре весьма регулярно появляются статьи об их успешном (или не очень) преодолении. Как вот эта, например.
Никого не отговариваю, просто интересно.
Вот это, по-моему, звучит совсем нехорошо. Если технология не позволяет получить нужный результат, надо брать другую, а не зоопарк устраивать.
Так по-моему, на джаве уже и не пишут иначе, независимо от сложности. Нужна база – цепляй ОРМ. Могу ошибаться, конечно – давненько с ней дела не имел.
Вот честно, не понимаю я смысла в ОРМ. В частности, в примерах автора SQL читается намного лучше, чем эквивалентный ему код – при том, что запросы все очень простые. Как уложить в ОРМ по-настоящему сложный запрос и не сойти с ума (особенно на этапе поддержки, когда понадобится его чуток поменять) – для меня загадка. А полный перевод сколько-нибудь сложного проекта на другую базу нужен примерно никогда. Оно точно того сто̀ит?
Я же специально уточнил: на естественных ландшафтах. А уж кого на Ваших работах называют менеджерами, не в курсе.
Нет. Нормальное предложение звучало бы примерно: Which setting affects the limit of issue list API requests rate? Оно понятно всем и сразу, и учить писать нужно именно так.
А с чего Вы взяли, что дискуссии на гитхабе ведут исключительно хорошо владеющие английским? Настолько хорошо, что на их примере можно учить других? Если Вы английский филолог, то грамматику Вам должны были преподавать в ВУЗе, и строить обучение ей других на основе случайных фраз, надёрганных в интернете – как минимум, странно.
UPD: перечитал, моя версия понятна, но на английском звучит грубовато. Правильно было бы нечто вроде: Would you elaborate, which...
Если бы Вы использовали тексты, а не скриншоты с презентаций, можно было бы попробовать процитировать и предложить нормальные версии. А так перенабивать каждую фразу просто лень. Пожалуй, отмечу только сиреневый (3). Вы сама хоть понимаете, что там написано? Я нет. Если перенести слово issue в конец предложения, оно обретает некий смысл – хотя тоже весьма расплывчатый.
Тоже миф какой-то на самом деле. Не встречал такого на естественных ландшафтах.
Прочитал вот это и не удержался:
Английский не преподаю, и не считаю, что хорошо его знаю. Но использую ежедневно, в общении в том числе с нативными спикерами. Извините, но буквально все Ваши примеры звучат до крайности ненатурально. Носители языка, да и просто люди, свободно им владеющие, в жизни так не напишут. Не надо такому учить, пожалуйста.
Что поправили-то? Поменяли миллион на десять? На скриншоте рядом с цифрой 100000 нет символа % – а там, где он есть, значения не превышают 100. Я с АЕ не работал никогда, и не знаю, в каких попугаях там цифры. Но точно не в процентах, это просто не имеет смысла в пределах одного цветового пространства – только при сравнении охватов в разных. Но и в этом случае ни о каких многократных различиях речи быть не может. Вот например, в телевидении было принято измерять уровни сигнала в IRE – а потом неожиданно появились компьютерные видео, где ограничение уровней 16-235 оказалось ненужным, и оказалось, что они выходят за диапазон 0-100%. Но долгое время продолжали мерить в IRE – просто по привычке, и получился выглядящий абсурдно, но понятный профессионалам индустрии диапазон от -7% до +109%.
Вы не обратили внимание на отсутствие символа %?
Да что ж Вы такое пишете-то? 🤦♂️ О какой характеристике речь? Дайте ссылку. Есть максимальная яркость – которую может иметь вся площадь экрана в течение неопределённого времени, и пиковая – нормируется либо по времени (редко), либо (обычно) по площади экрана. Например, 1000 нит 10% означает, что не более 10% площади экрана может одновременно излучать свет с такой яркостью.
Да вроде давно уже пришла, 16-бит ACES при редактировании используется повсеместно. Другое дело, что потом всё равно требуется трансформация в цветовое пространство, поддерживаемое оконечными устройствами.
Это детали внутренней реализации конкретного кодека, к стандарту HDR никакого отношения не имеющие и в данном контексте просто вводящие в заблуждение. Например, ни в одном видеоредакторе яркость 540, и тем более 1000% установить невозможно.
Буквально несколько дней назад купил себе новый ноутбук. 4K HDR-600 TrueBlack, пиковая яркость 750. Собственно, одной из причин выбора именно этой модели была поддержка работы с HDR контентом. Могу заверить, что разница огромная. Я бы даже сказал, что при обычном дневном освещении яркость близка к чрезмерной, больше может понадобиться только на прямом солнечном свете.
Извините, это чрезмерная упрощённость. Ярче 100% какого цветового пространства? И что за дикие цифры, 540%? Rec.2020 имеет максимальную яркость 107% от Rec.709, например.
🤦♂️ HLG – просто один из стандартов той самой компрессии изображения, позволяющий его отображать с приемлемой точностью как на HDR, так и на SDR устройствах. Наличие его поддержки в камере (большая редкость даже в топовых моделях) всего лишь позволяет получать фото/видео с большим ДД без постобработки. При этом съёмка в RAW, хоть и требует постобработки, ДД всегда даст заведомо больший.
Вообще-то есть разные стандарты HDR. HDR-400, например, требует 400 нит яркости, а вовсе не 1000. И картинка будет точно лучше, чем SDR. А HDR-5000 просто не существует, максимум 4000 – это стандарт для оборудования кинотеатров высшего класса. Не уверен даже, что есть хоть одно реальное устройство, которое ему соответствует.
У Вас страшная путаница в понятиях, извините уж.
Поспорили.
Зачем мне это знать?
Либо я это уже знаю, либо меня самого пора увольнять.
Вопросы правильные, но к тайм-трекингу сотрудников относятся примерно никак.
Оценивать работу нужно по результатам, а не по стуло-часам.
Я не пойму, Вы таким образом трафик своей статье собираете, или что? Вот прямо в подробностях тут расписать: кто, когда, и по какому поводу начал гнуть пальцы, какой проект делался и к каким результатам это привело? Серьёзно?
Есть вещи очевидные – когда люди заняты работой, она делается. Когда выяснением, где чьё место и взаимной расстановкой по таким местам – то нет.
Всего наилучшего.