Европа в мой регион последние года 2 - 3 крайне неохотно отправляет что-либо - вплоть до того, что сразу магазины пишут 'Delivery to Ukraine is not supported'
Нужна полноформатная низкопрофильная клавиатура с кнопками управления медиапроигрывателем и ISO - энтером - и всё, тишина, перекатиполе. 99% всех клавиатур - обрезки, пригодные только для набора текста или игр или как пульт для компьютера. Да встройте вы везде энкодеры для управления громкостью, добавьте ещё ряд кнопок - для управления плеером, звуком, ещё какими-то функциями, почему этого не делается - загадка
надо поискать и если продаётся - купить попробовать, выглядит как что-то годное, мне кажется, вот эти вогнутые кнопки будут очень удобны в отличие от обычных плоских
да хоть так, хоть так. Неясно, почему столько чести правому шифту, зато Энтер режут все, кому ни попадя. Хотите вы тот бек слеш - ну режьте шифт правый, он и так длинный, но Энтер оставьте большой
так ведь не говорилось вообще всем варежки захлопнуть и молчать)
это естественно, что много какие процессы в вк можно улучшить - в том числе найм. Но просто хотелось ответить автору статьи, что при всём уважении к его опыту, но вк - большая компания, давно на рынке и они, скорее, если и прислушиваются к каким-либо замечаниям конкретно по собеседованиям для разработчиков, то, думается, эти люди имеют намного больше опыта и, возможно, гораздо лучше понимают внутреннюю специфику компании и её проектов
А вот был бы автор условно аксакалом, ещё помнил пхп5.4, поучаствовал в жизни 5 или больше компаний, стартапов, проектов, вот от такого человека было бы интересно услышать какую-то критику, так как базироваться она будет на большом опыте, на внутряках и на понимании - какие могут быть приблизительные хотелки у подобного работодателя.
что до знаний мидла - мидлу вполне себе нужно знать достаточную базу языка, своего стека, протоколов, инструментария, версионности, редакторов, терминалы, деплои, докеры, всего понемногу, чтобы на более-менее самых разных задачах в своём проекте не теряться, чтобы можно было работать с таск-трекером, планировать, писать код, проводить дебаг как через дебаггер, так и через vdd ('var dump die'), версионность, участвовать в тестированиях и деплоях, взаимодействие с фронт-ендом, с девопсами. Чем меньше тебе нужно объяснять, что как куда делать со стороны сениора или тим-лида - тем больше ты мидл и наоборот)
Естественно, что расширенные кругозор, более глубокие знания, софтскилы, навыки общения и умение передавать свои знания, объяснять материал коллегам или там джунам - приветствуются и формируют хорошие задатки на дальнейшее развитие, но вот развитие архитектуры, какие-то методологии, подходы, а тем более около-сфера, финансы, управление продуктом - как правило, заниматься этим нанимают отдельных специалистов, а зачастую какое-либо внимание со стороны разработчиков и вообще не приветствуется (например, финансы или NDA моменты) либо остаётся непонятым - "на вашем уровне есть задачи от тим-лида в таск-трекере".
|| Совершенно не было вопросов про их диалект KPHP
А с чего бы они были? Вас могли собеседовать на самые разные проекты с самым разным пхп - от обычного легаси php5.6 (но надеюсь, там уже нету такого кода), так и на php7.1, на 8.2. KPHP, насколько понимаю - какой-то внутренний диалект, который вообще не факт, что до сих пор используется. А если и используется, то в каких-то нишевых разработках и пилят такой код сениоры либо мидлы, которых получили опыт/экспертизу. Было бы странно у вас спрашивать что-либо по каким-то внутренним наработкам, диалектам языков или особенностям настроек чего-либо.
Здесь были вопросы интервьюеру с моей стороны, про то, как он взаимодействует с последними версиями PHP и режимом use-strict, а также пару вопросов про подкапотное преобразование в C++
такое довольно странно спрашивать у интервьюера, если это не разработчик с проекта или тим-лид - и даже если это так, взаимодействие с use-strict - оно или есть, или нету, что до подкапотного преобразвания в C++ - такое не особо есть смысл спрашивать, так как если php код какой-то движок и переваривает в C++, то на это дело есть отдельный транспайлер/конвертор, делать обзорную лекцию по которому - достаточно странно, с этим просто столкнёшься или нет, а столкнувшись или изучив внутренню документацию, станет понятно, какой код переварит успешно, а какие места лучше писать по-другому. Все эти знания опять же спрашивать странно, так как они общего характера для большинства транспайлируемых/конвертируемых языков вроде того же HaXe. А какую-то конкретику/специфику вряд ли можно так выделить, чтобы на интервью рассказать.
Это похоже на то, чтобы на собеседовании спрашивать, "а как у вас на проекте Ts в Js переваривает, есть ли свой диалект и какие особенности". Ну переваривает и переваривает, за это отвечает какой-то софт или библиотека или самописная вещь, но если вас не собеседуют прям туда - зачем вообще копать в такие узконаправленные вещи, неплохо бы сосредоточиться на общем уровне, а в специфику вас и так введут или покажут.
полное отсутствие вопросов про паттерны разработки
а чего про них спрашивать-то? как правило, типовые задачи сами по себе складываются в эти самые шаблоны, не стоИт задачи, чтобы писать код который бы именно вот по шаблонам по канонам был выполнен, задача диктует исполнение и иногда это - фабрика, иногда - декоратор, иногда адаптер, а бывает и такое, что это класс-одиночка-божественный объект-шестирукий Шива, нафаршированный методами как следует.
Получается, базовые вещи по такому вроде бы и спрашивать нечего, а специфику незачем, типа там "как бы вы реализовали шаблон "Мост" на php"? Что и кому дадут такие вопросы и ответы, зачем это?Просто показать, что "я учил"?
архитектурные подходы и методологии проектирования
выше справедливо замечали, что это не мидлового уровня задачи, сейчас бы доверить мидлу тасовать архитектуру или тащить DDD на микросервисы или там свой фреймворк запилить или "давайте перейдём на Лару - все переходят на Лару". Этим другие люди заниматься должны, другого опыта, квалификации и экспертизы
Не было вопросов про оптимизацию и решения около-бизнесовых кейсов
оптимизацией опять же другим бы людям заниматься, то, что вы с этим сталкивались и разобрались - здорово, было ли это правильно? Нужно ли будет это на текущем проекте? Неясно. Это и выглядит не совсем правильно, если на проекте мидлы роют в оптимизацию - это показатель проблем и чудовищного техдолга проекта, ошибок проектирования. И опять же не мидлу заниматься таким, обычно на такое тратят время специально обученный разумный человечек, который наоборот не делает никаких мидловых задач, а занимается вот как раз узкими местами и методами их преодоления.
Решение около-бизнесовых кейсов - да с чего вообще спрашивать про такое? Опять же на больших проектах и в серьёзных компаниях этим отдельные отделы и люди занимаются, то, что вы как мидл с чем-то таким сталкивались - здорово. А про что ещё у вас спросить, с чем вы сталкивались, хотя не должны были? Может, с клиентами спецификации составляли? Может, финансовое планирование место имело? Может, обучали отдел техподдержки? Ну так этого всего на новом проекте не будет, как правило, если нанимают нового человека - значит, или много или будет много и прямых задач по разработке на пхп
Не было вопросов про системы контроля версий
Что спрашивать? Везде git. Ну merge, как и везде. Какие-то свои процедуры создания и вливания веток. Cherry-pick, кстати - это здорово, но не совсем здраво и опять же указывает на определённые проблемы в ведении веток проекта. Это вроде совсем базовые вещи, которые должен знать любой, кто вообще работал с git. Про контроль версий обычно интернов спрашивают или совcем новичков, чей пет-проект просто сохранялся в IDE по факту как файлы.
Не было упоминания методологий процесса разработки и стратегического планирования развития продукта
вот уж что не мидла ума дело - так эти две вещи. Сейчас бы привлекать разработчиков на стратетическое планирование продукта или там SDLC обсуждать. Что ещё, может, финансы распределим, бизнес-план построим?) Людей там спланируем в ИТ-отдел нанять? И чем вы, как новопришедший разработчик, собрались помочь при разработке стратегии продукта, не зная ни продукта, ни домена, не имея экспертизы хотя бы в несколько лет по этому самому продукту, либо сходных знаний.
Методологии процесса разработки - даже комментировать странно. Не нашего уровня вообще задачи, да и задачи ли - как правило, в компании на проектах эти самые процессы уже устоявшиеся, а на новых проектах применяются накатанные же схемы взаимодействий, чтобы все процессы и потоки были сходные с теми, что уже есть. Это не с полного 0 в RnD отдел на новый язык-технологию наниматься и что-то там пробовать, чтобы нужно было какие-то вырабатывать методологии. Опять же туда нанимают сильно других людей - начинать такие проекты и разрабатывать такие методологии.
Даже unix системы не упомянули.
Опять же - что там упоминать и зачем? Как правило, в вашем резюме уже написано, с какими системами вы работали - windows, linux, соответственно, какие-то навыки есть, которые вам позволяют на текущем месте выполнять задачи - то что толку про это спрашивать? Основы знания терминала или что спросить? Как работает ядро линукса? Как пропатчить кде
И вообще - возможно, у них проект под windows и там linux/unix нету необходимости применять.
= = = =
резюмируя, не очень понятно, зачем автор написал статью - это достаточно амбициозно, имея такие опыт и экспертизу, давать такой компании как VK советы и рекомендации, как собеседовать "мидлов". По автору такое ощущение, что он попробовал проект-два, 2 года выполнял какие-то задачи, допустим, что успешно, попутно занимался кучей побочных задач, чем обычно грешат проекты с текучкой кадров, или недоукомплектованные, или с техдолгом, или стартапы ("решения около-бизнесовых кейсов", господи). То что знал - не спросили. Зато спросили, что не знал. Уже успели получить какое-то своё видение - "какой должен быть мидл", которое в ВК почему-то не разделили. Налицо нехватка опыта работы в крупных компаниях на хорошо спланированных и делегированных проектах - где бекенд занимается бекендом, фронт-енд - фронт-ендом, есть архитекторы, CTO, аналитики, отдел поддержки.
п.с: VK, напишите мне в личку, пожалуйста, если всё ещё ищете мидла на язык слона - обещаю сосредоточиться на php и не лезть в стратегическое планирование продукта)))
п.п.с: автор, без обид, но такие статьи лучше бы писать, проработав в индустрии хотя бы лет 10, вашего опыта пока хватает только на успешную работу на вашем проекте/компании
но вот они были - и вы на них не ответили) получается, вы и не мидл, вы и не джун, вы - просто разработчик, который работал, получил какой-то опыт и экспертизу, своё видение и предпочитаете заточенность на решение задач какому-то общему кругозору (который, как правило, хотят видеть большие компании, ведь, как правило, туда всегда ищут больше, чем надо - вдруг куда-то вырастет. Исполнителей по факту наличия задач в таск-трекере обычно ищут фриланс-конторы, которым абсолютно всё равно на вообще любые ваши знания и опыт, пока вы можете реализовывать задачи)
скорее всего это конкретно вам не повезло, возможно, какая-то аппаратная проблема либо "виндовс" не той системы. Я просто работаю с Firefox ещё со времён, когда Хрома как браузера не было и, не считая некоторых неудачных патчей, при которых действительно можно было словить краш, всегда всё было отлично (да и то, как оказалось, причиной сбоя был аддон сохранения сессии)
нужно же что-то делать, что потом будут в рекламе маркетологи хвалить)
мегапикселей уже наелись, разрешения уже подняты донельзя, диагонали давно превысили рост баскетболиста - вот сделают новые прозрачные телевизоры и будет чем хвастаться))
здесь та же самая проблема, как и с тачскрином - где-то в каких-то местах это очень уместно, но тот же автопром и промышленное оборудование, станочники сильнейшим образом показали, что просто всё абстрактно перетащить на тачскрин-управление не принесёт ни удобства, ни радости. Эффект новизны проходит и тебя начинает люто бесить невозможность открыть в новенькой тесле бардачок, не проводя хитрых манипуляций на тачскрине.
Так и эти телевизоры - для каких-то целей они будут очень удачны и новые горизонты откроют, но для обычного бытового применения это, скорее всего, не пригодится, ведь телевизор чаще всего - немобильное, стоящее у стены/висящее на стене устройство, "ему прозрачным быть без надобности". Это как стеклянную раковину в ванную комнату сделать - да, прикольно, можно показывать соседям, что вот я мою руки и вижу пол - но практически это мало что даст
Европа в мой регион последние года 2 - 3 крайне неохотно отправляет что-либо - вплоть до того, что сразу магазины пишут 'Delivery to Ukraine is not supported'
да, я таких 2 купил... просто конкретно уровень громкости куда удобнее управляеться через энкодер, а не хот-кеи... ну да ладно
раскладка не проблема - 1 раз изучаете метод "слепой" печати и пригождается на всю жизнь на все клавиатуры.
+1, моделей и брендов много - выбрать нечего
Нужна полноформатная низкопрофильная клавиатура с кнопками управления медиапроигрывателем и ISO - энтером - и всё, тишина, перекатиполе. 99% всех клавиатур - обрезки, пригодные только для набора текста или игр или как пульт для компьютера. Да встройте вы везде энкодеры для управления громкостью, добавьте ещё ряд кнопок - для управления плеером, звуком, ещё какими-то функциями, почему этого не делается - загадка
в этом списке должна быть, если тем более не возглавлять его, гробница ДжонИ - жука-еретика (что бы это не значило) из игры Hollow Knight
наконец-то я вижу нормальный энтер и левый шифт
надо поискать и если продаётся - купить попробовать, выглядит как что-то годное, мне кажется, вот эти вогнутые кнопки будут очень удобны в отличие от обычных плоских
да хоть так, хоть так. Неясно, почему столько чести правому шифту, зато Энтер режут все, кому ни попадя. Хотите вы тот бек слеш - ну режьте шифт правый, он и так длинный, но Энтер оставьте большой
да, много кому (например, мне) 16:10 удобнее, охотимся за такими ноутбуками и мониторами)
божественный фильм, можно пересматривать каждый год.
так ведь не говорилось вообще всем варежки захлопнуть и молчать)
это естественно, что много какие процессы в вк можно улучшить - в том числе найм. Но просто хотелось ответить автору статьи, что при всём уважении к его опыту, но вк - большая компания, давно на рынке и они, скорее, если и прислушиваются к каким-либо замечаниям конкретно по собеседованиям для разработчиков, то, думается, эти люди имеют намного больше опыта и, возможно, гораздо лучше понимают внутреннюю специфику компании и её проектов
А вот был бы автор условно аксакалом, ещё помнил пхп5.4, поучаствовал в жизни 5 или больше компаний, стартапов, проектов, вот от такого человека было бы интересно услышать какую-то критику, так как базироваться она будет на большом опыте, на внутряках и на понимании - какие могут быть приблизительные хотелки у подобного работодателя.
что до знаний мидла - мидлу вполне себе нужно знать достаточную базу языка, своего стека, протоколов, инструментария, версионности, редакторов, терминалы, деплои, докеры, всего понемногу, чтобы на более-менее самых разных задачах в своём проекте не теряться, чтобы можно было работать с таск-трекером, планировать, писать код, проводить дебаг как через дебаггер, так и через vdd ('var dump die'), версионность, участвовать в тестированиях и деплоях, взаимодействие с фронт-ендом, с девопсами. Чем меньше тебе нужно объяснять, что как куда делать со стороны сениора или тим-лида - тем больше ты мидл и наоборот)
Естественно, что расширенные кругозор, более глубокие знания, софтскилы, навыки общения и умение передавать свои знания, объяснять материал коллегам или там джунам - приветствуются и формируют хорошие задатки на дальнейшее развитие, но вот развитие архитектуры, какие-то методологии, подходы, а тем более около-сфера, финансы, управление продуктом - как правило, заниматься этим нанимают отдельных специалистов, а зачастую какое-либо внимание со стороны разработчиков и вообще не приветствуется (например, финансы или NDA моменты) либо остаётся непонятым - "на вашем уровне есть задачи от тим-лида в таск-трекере".
|| Совершенно не было вопросов про их диалект KPHP
А с чего бы они были? Вас могли собеседовать на самые разные проекты с самым разным пхп - от обычного легаси php5.6 (но надеюсь, там уже нету такого кода), так и на php7.1, на 8.2. KPHP, насколько понимаю - какой-то внутренний диалект, который вообще не факт, что до сих пор используется. А если и используется, то в каких-то нишевых разработках и пилят такой код сениоры либо мидлы, которых получили опыт/экспертизу. Было бы странно у вас спрашивать что-либо по каким-то внутренним наработкам, диалектам языков или особенностям настроек чего-либо.
такое довольно странно спрашивать у интервьюера, если это не разработчик с проекта или тим-лид - и даже если это так, взаимодействие с use-strict - оно или есть, или нету, что до подкапотного преобразвания в C++ - такое не особо есть смысл спрашивать, так как если php код какой-то движок и переваривает в C++, то на это дело есть отдельный транспайлер/конвертор, делать обзорную лекцию по которому - достаточно странно, с этим просто столкнёшься или нет, а столкнувшись или изучив внутренню документацию, станет понятно, какой код переварит успешно, а какие места лучше писать по-другому. Все эти знания опять же спрашивать странно, так как они общего характера для большинства транспайлируемых/конвертируемых языков вроде того же HaXe. А какую-то конкретику/специфику вряд ли можно так выделить, чтобы на интервью рассказать.
Это похоже на то, чтобы на собеседовании спрашивать, "а как у вас на проекте Ts в Js переваривает, есть ли свой диалект и какие особенности". Ну переваривает и переваривает, за это отвечает какой-то софт или библиотека или самописная вещь, но если вас не собеседуют прям туда - зачем вообще копать в такие узконаправленные вещи, неплохо бы сосредоточиться на общем уровне, а в специфику вас и так введут или покажут.
а чего про них спрашивать-то? как правило, типовые задачи сами по себе складываются в эти самые шаблоны, не стоИт задачи, чтобы писать код который бы именно вот по шаблонам по канонам был выполнен, задача диктует исполнение и иногда это - фабрика, иногда - декоратор, иногда адаптер, а бывает и такое, что это класс-одиночка-божественный объект-шестирукий Шива, нафаршированный методами как следует.
Получается, базовые вещи по такому вроде бы и спрашивать нечего, а специфику незачем, типа там "как бы вы реализовали шаблон "Мост" на php"? Что и кому дадут такие вопросы и ответы, зачем это?Просто показать, что "я учил"?
выше справедливо замечали, что это не мидлового уровня задачи, сейчас бы доверить мидлу тасовать архитектуру или тащить DDD на микросервисы или там свой фреймворк запилить или "давайте перейдём на Лару - все переходят на Лару". Этим другие люди заниматься должны, другого опыта, квалификации и экспертизы
оптимизацией опять же другим бы людям заниматься, то, что вы с этим сталкивались и разобрались - здорово, было ли это правильно? Нужно ли будет это на текущем проекте? Неясно. Это и выглядит не совсем правильно, если на проекте мидлы роют в оптимизацию - это показатель проблем и чудовищного техдолга проекта, ошибок проектирования. И опять же не мидлу заниматься таким, обычно на такое тратят время специально обученный разумный человечек, который наоборот не делает никаких мидловых задач, а занимается вот как раз узкими местами и методами их преодоления.
Решение около-бизнесовых кейсов - да с чего вообще спрашивать про такое? Опять же на больших проектах и в серьёзных компаниях этим отдельные отделы и люди занимаются, то, что вы как мидл с чем-то таким сталкивались - здорово. А про что ещё у вас спросить, с чем вы сталкивались, хотя не должны были? Может, с клиентами спецификации составляли? Может, финансовое планирование место имело? Может, обучали отдел техподдержки? Ну так этого всего на новом проекте не будет, как правило, если нанимают нового человека - значит, или много или будет много и прямых задач по разработке на пхп
Что спрашивать? Везде git. Ну merge, как и везде. Какие-то свои процедуры создания и вливания веток. Cherry-pick, кстати - это здорово, но не совсем здраво и опять же указывает на определённые проблемы в ведении веток проекта. Это вроде совсем базовые вещи, которые должен знать любой, кто вообще работал с git. Про контроль версий обычно интернов спрашивают или совcем новичков, чей пет-проект просто сохранялся в IDE по факту как файлы.
вот уж что не мидла ума дело - так эти две вещи. Сейчас бы привлекать разработчиков на стратетическое планирование продукта или там SDLC обсуждать. Что ещё, может, финансы распределим, бизнес-план построим?) Людей там спланируем в ИТ-отдел нанять? И чем вы, как новопришедший разработчик, собрались помочь при разработке стратегии продукта, не зная ни продукта, ни домена, не имея экспертизы хотя бы в несколько лет по этому самому продукту, либо сходных знаний.
Методологии процесса разработки - даже комментировать странно. Не нашего уровня вообще задачи, да и задачи ли - как правило, в компании на проектах эти самые процессы уже устоявшиеся, а на новых проектах применяются накатанные же схемы взаимодействий, чтобы все процессы и потоки были сходные с теми, что уже есть. Это не с полного 0 в RnD отдел на новый язык-технологию наниматься и что-то там пробовать, чтобы нужно было какие-то вырабатывать методологии. Опять же туда нанимают сильно других людей - начинать такие проекты и разрабатывать такие методологии.
Опять же - что там упоминать и зачем? Как правило, в вашем резюме уже написано, с какими системами вы работали - windows, linux, соответственно, какие-то навыки есть, которые вам позволяют на текущем месте выполнять задачи - то что толку про это спрашивать? Основы знания терминала или что спросить? Как работает ядро линукса?
Как пропатчить кдеИ вообще - возможно, у них проект под windows и там linux/unix нету необходимости применять.
= = = =
резюмируя, не очень понятно, зачем автор написал статью - это достаточно амбициозно, имея такие опыт и экспертизу, давать такой компании как VK советы и рекомендации, как собеседовать "мидлов". По автору такое ощущение, что он попробовал проект-два, 2 года выполнял какие-то задачи, допустим, что успешно, попутно занимался кучей побочных задач, чем обычно грешат проекты с текучкой кадров, или недоукомплектованные, или с техдолгом, или стартапы ("решения около-бизнесовых кейсов", господи).
То что знал - не спросили. Зато спросили, что не знал. Уже успели получить какое-то своё видение - "какой должен быть мидл", которое в ВК почему-то не разделили. Налицо нехватка опыта работы в крупных компаниях на хорошо спланированных и делегированных проектах - где бекенд занимается бекендом, фронт-енд - фронт-ендом, есть архитекторы, CTO, аналитики, отдел поддержки.
п.с: VK, напишите мне в личку, пожалуйста, если всё ещё ищете мидла на язык слона - обещаю сосредоточиться на php и не лезть в стратегическое планирование продукта)))
п.п.с: автор, без обид, но такие статьи лучше бы писать, проработав в индустрии хотя бы лет 10, вашего опыта пока хватает только на успешную работу на вашем проекте/компании
но вот они были - и вы на них не ответили) получается, вы и не мидл, вы и не джун, вы - просто разработчик, который работал, получил какой-то опыт и экспертизу, своё видение и предпочитаете заточенность на решение задач какому-то общему кругозору (который, как правило, хотят видеть большие компании, ведь, как правило, туда всегда ищут больше, чем надо - вдруг куда-то вырастет. Исполнителей по факту наличия задач в таск-трекере обычно ищут фриланс-конторы, которым абсолютно всё равно на вообще любые ваши знания и опыт, пока вы можете реализовывать задачи)
вы бы со "спун-юзингом" потише себя вели, а то "утром в газете - вечером в куплете")))
"Значит, хорошие сапоги, надо брать" (с)
скорее всего это конкретно вам не повезло, возможно, какая-то аппаратная проблема либо "виндовс" не той системы. Я просто работаю с Firefox ещё со времён, когда Хрома как браузера не было и, не считая некоторых неудачных патчей, при которых действительно можно было словить краш, всегда всё было отлично (да и то, как оказалось, причиной сбоя был аддон сохранения сессии)
а почему неудобно? всё логично: покупаем "плохую" соцсеть, делаем из неё хорошую)) мыслить нужно шире)
картинка с утёнком, который держит ножик* )))
нужно же что-то делать, что потом будут в рекламе маркетологи хвалить)
мегапикселей уже наелись, разрешения уже подняты донельзя, диагонали давно превысили рост баскетболиста - вот сделают новые прозрачные телевизоры и будет чем хвастаться))
здесь та же самая проблема, как и с тачскрином - где-то в каких-то местах это очень уместно, но тот же автопром и промышленное оборудование, станочники сильнейшим образом показали, что просто всё абстрактно перетащить на тачскрин-управление не принесёт ни удобства, ни радости. Эффект новизны проходит и тебя начинает люто бесить невозможность открыть в новенькой тесле бардачок, не проводя хитрых манипуляций на тачскрине.
Так и эти телевизоры - для каких-то целей они будут очень удачны и новые горизонты откроют, но для обычного бытового применения это, скорее всего, не пригодится, ведь телевизор чаще всего - немобильное, стоящее у стены/висящее на стене устройство, "ему прозрачным быть без надобности". Это как стеклянную раковину в ванную комнату сделать - да, прикольно, можно показывать соседям, что вот я мою руки и вижу пол - но практически это мало что даст
сори, про 21:9 не знал - как поисковик показал, так и решил положиться на результаты из интернета, для меня все эти ультраширокие мониторы - в новинку
а я в нетерпением жду 34`` с разрешением типа 3440х1800 или даже 3440х2400.
У меня сейчас 3440х1440 (43:18) - и это всё здорово, когда фильмы смотришь, а вот по работе места не хватает и хотелось бы что-то вроде 40:25
п.с: но я, естественно, не дождусь(