«Пипл хавает» — да: и я, и вы, и множество других людей купили псевдо «смарт» ТВ (на любых ОС).
Я понимал, что ОС так себе, но покупал из-за самого экрана. Просто, не было выбора аналогичного ТВ без смарта или с Андроидом.
Но это никак не говорит о непригодности Андроид для телевизоров. Как по мне не сильно от планшетов отличается: понятно, что для нормальной работы нужно ставить не самое дешевое железо. Уверен (надеюсь), в тех же Sony Android-телевизорах все хорошо с этим.
Мне кажется неправильным говорить «эмбеддед» про смарт-ТВ: без приложений это вовсе не смарт, а классические «эмбеддед» заточены на дешевое железо, а не широкую экосистему приложений.
Сейчас приложения делают под 3 платформы: веб, Android, iOS. И при этом сильно думают как сэкономить (Cordova, Flutter, ...). webOS — х-ая платформа (даже не 4ая). И это никак не равно вебу, хотя там и есть что-то от него (отдельный код, релизный цикл, свои баги и АПИ).
LG сейчас сильно не хватает приложений. Отсюда и попытка популяризовать платформу за счет открытия обрезанной версии системы. Может еще денег хотят заработать на полной версии системы. Но, учитывая первый абзац, вряд ли у них это получится. Так что еще несколько лет жить этой ОС под крылом LG.
Чем мне это не нравится? Кто-то поведется, появится несколько новых устройств без приложений. ИМХО лучше сконцентрироваться на решении проблем текущей самой популярной аналогичной open source ОС (Андроид). Они там есть и решаемы. А так наоборот дробление усилий.
У меня есть телевизор с webOS, chromecast, apple tv, андроид-свисток. Мысли:
1. При покупке телевизора нет выбора что там будет. И все равно платишь за «смарт»-составляющую (опять же нет выбора купить без нее). Поэтому хочется что-то встроенное нормальное. Т.е. я согласен и пользуюсь внешними устройствами, но был бы рад получить либо пустой телевизор, либо качественный смарт (Андроид на данный момент).
2. Chromecast первого поколения не работает стабильно с текущим телевизором, нужно новый покупать (может заработает, а может нет). Chromecast встроен в Андроид ТВ обычно (не уверен, что всегда), что гарантирует нормальную работоспособность на данном ТВ.
3. Внешние устройства отдельно грузятся и нужно включать / выключать — неудобно.
4. В вебОС, по сути, только одно приложение приличное — Youtube. Остальные: часто вообще нет; если есть, то обрезанный функционал и ошибки. В целом, проблемы маргинальной ОС.
5. С телевизором идет хороший пульт, который позволяет управлять мышкой движением пульта в пространстве — это снимает практически все вопросы по планшетным приложениям (если бы был Андроид).
Если сравнивать с Андроид для производителей есть преимущества? Т.к. Андроид вроде бы подходит для мобильных, планшетов, тв и интернета-вещей. Плюс, есть множество приложений под Андроид. А их ОС не очень (есть ТВ от LG): очень замечательно, когда веб-страница перезагружается на середине просмотра видео с радостным сообщением, что они очистили память. Понятно, что нет поддержки Chromecast, а так же приложений мало и они ущербные.
У меня ощущение, что через пару лет они совсем от этой ОС откажутся и в телевизоры поставят Android (надежда).
В компании из статьи нет тимлидов, а СЕМы не программируют (хотя в каких-то подразделениях по час в день в виде парного программирования, как было в комментарии выше). Откуда про условные иерархии? SEM — менеджер, сотрудники его команды — исполнители. Вроде де бы все просто.
Как по мне сильно зависит от сложности задачи и известности технологий/необходимых частей кода.
Если все по накатанной, то смысла вдвоём программировать нет.
Одна из главных идей — это Dart на любом фронте: web (DartAngular или другое), iOS (Flutter), Android (Flutter). По заявлениям это позволяет шарить 70% кода (при этом самого сложного/потенциально ошибочного) и иметь единую команду разработки.
Соответственно, в разы ускоряется (и удешевляется) разработка и отладка.
Пока что функции весьма специфичны: есть условия когда они уже и полезны, но говорить о широком использовании пока что слишком рано:
— писать/поддерживать сложновато ещё
— стоимость ещё должна упасть
В принципе, об этом и статья.
Как альтернативы есть системы на базе докера (например, кибернетис умеет скейлить до 0 deploy) и Google Apps Engine (стартует достаточно быстро, автомасштабируется так же до 0). Там можно писать обычные приложения на многих языках.
Dapp довольно жуткий, поэтому массово и не взелетел. С помощью примитивных скриптов и какого-нибудь проекта docker-squash (если не хочется собирать образ новым докером) то же самое отлично решается.
Немного вступлюсь за Kubernetes: там есть request и limit на cpu и память. Реквесты используются для размещения pod на нодах. Лимит по cpu — ограничение через cgroups. Лимит по памяти — прилетает OOM killer.
При этом не помню про blkio. Скорее всего нет. Но это из-за идеологии отсутствия локальных хранилищ.
Ещё интересны ограничения на трафик. Что-то на эту тему так же есть в k8s.
Если говорить про настройки хоста/ядра, то это тоже можно делать. Но это уже никакой не чёрный ящик.
В итоге как поменялось отношение к «успешным» людям в интернете?
PS. А вот «вознаграждения» в таких случаях (если нет заранее заявленной программы) — это друга статья УК про вымогательство. Нужно понимать, что наличие публичной программы поиска уязвимостей — это часть пиара компании с соотв. заранее выделенным бюджетом. Если такой пиар не считается важным, то и никаких денег не будет.
Как по мне, в статье описано, что основная проблема автора в США — это отсутствие друзей и скукота, а не деньги. Тот же американский Санкт-Петербург — весьма мелкий южный городишко, далеко не Нью-Йорк.
Если говорить про деньги, то продвинутый сеньор наверняка половину отдаёт налогами. Хотя в целом да, в США можно найти зп лучше, чем в кроссовере, но, как по мне, только в США в офисе и с местными расходами. В России же не видел лучше предложений с учётом удаленной работы (если, вдруг, есть, то всем будет интересно услышать).
Блог компании mail.ru? По тексту много различных «маркетинговых» уловок, чтобы по всем направлениям продвинуть этого провайдера услуг.
Сам способ сравнения убивает весь смысл облака. Нужны VPS — берите VPS, а не облачные ресурсы. А то и дедики на hetzner, если все равно никакой облачной инфраструктурой не предполагается пользоваться (т.к. в сравнении этого нет, а с их учётом фавориты могут легко поменяться).
Т.е. для сравнения нужно что-то более сложное с различными сервисами и отказоустойчивостью. С точки зрения цен в облаке часто более важным является стоимость хранения (esb, s3, managed MySQL/postgresql, managed document db, ...), чем вычислительных ресурсов.
Не стоит забывать и про платформенные услуги: Firebase у Google, что-то несколько другое есть у AWS, про Azure не скажу. Кому-то могут подойти и сэкономить чемодан денег.
По Гуглу можно добавить, что формально они не работают с физ. лицами в России — как минимум ИП.
Из принципиальных проблем: не все видно из статического изображения. Например:
— при скролировании: что остаётся на месте, что двигается. Бонусом изменение размера, появление/скрытие элементов при скролинге.
— разная верстка под разный размер окна браузера: резиновая/фиксированная, появление/скрытие элементов (адаптивная вёрстка)
— z-index — в простейшем случае для модальных окон
— наведение мышью
— щелчки — анимация кнопок
— эффекты от таймера — анимации, карусели
Но сама по себе идеи интересна и в будущем дизайнеры, возможно, будут помечать слои в psd понятным для щелкунчика образом.
Swarm пробовали, сырой (нестабильный) был. Надеюсь, Docker Inc. угомонятся с фичами через какое-то время и стабилизируют решение. Можно будет повторно посмотреть, хотя уже вряд ли будет иметь смысл переезжать.
Kubernetes изначально выглядит как что-то сложное, но достаточно быстро понимаешь, что ничего страшного. Он в том или ином виде поддерживается GCP (Google Kubernetes Engine), AWS (kops), Azure (Azure Container Service), on-prem (разные варианты). При этом и от Kubernetes хочется большей стабильности (например, приходится пользоваться альфа/бета фичами), но уж что поделать.
У меня сложилась такая схема:
0. Реформаторы кода и линтеры запускаются до подачи кода на code review
1. Продуктовые вопросы (как это должно работать в таком-то случае? как это должно работать совместно с такой-то функцией)
2. Высокоуровневый дизайн (структуры данных, библиотеки/модули/пакеты/классы/публичные методы)
3. Качество кодирования (приватные методы, код внутри методов, тесты)
Если есть вопрос по определенному пункту, то ниже не спускаемся, т.к. может оказаться, что соответствующий код будет переделан.
В примере из статьи не было нулевого пункта. Сразу были комментарии по пунктам 0, 1?, 2, 3. Это дало возможность разработчику исправить только 0 и 3, а по принципиальным для проектирования моментам ничего не сделать. Если бы были замечания только по пункту 2, то их бы не получилось так просто игнорировать.
Основная же идея о том, что можно пропускать плохой код ради обучения специалистов не понравилась. Если юниор (вообще или в проекте), то можно перед написанием кода делать верхнеуровневое проектирование (исключит пункты 1 и 2). А вот к коду внутри методов можно действительно временно снижать планку, если приходится работать с юниорами в программировании (регуляр уже должен корректно писать код на уровне методов).
Я понимал, что ОС так себе, но покупал из-за самого экрана. Просто, не было выбора аналогичного ТВ без смарта или с Андроидом.
Но это никак не говорит о непригодности Андроид для телевизоров. Как по мне не сильно от планшетов отличается: понятно, что для нормальной работы нужно ставить не самое дешевое железо. Уверен (надеюсь), в тех же Sony Android-телевизорах все хорошо с этим.
Мне кажется неправильным говорить «эмбеддед» про смарт-ТВ: без приложений это вовсе не смарт, а классические «эмбеддед» заточены на дешевое железо, а не широкую экосистему приложений.
LG сейчас сильно не хватает приложений. Отсюда и попытка популяризовать платформу за счет открытия обрезанной версии системы. Может еще денег хотят заработать на полной версии системы. Но, учитывая первый абзац, вряд ли у них это получится. Так что еще несколько лет жить этой ОС под крылом LG.
Чем мне это не нравится? Кто-то поведется, появится несколько новых устройств без приложений. ИМХО лучше сконцентрироваться на решении проблем текущей самой популярной аналогичной open source ОС (Андроид). Они там есть и решаемы. А так наоборот дробление усилий.
1. При покупке телевизора нет выбора что там будет. И все равно платишь за «смарт»-составляющую (опять же нет выбора купить без нее). Поэтому хочется что-то встроенное нормальное. Т.е. я согласен и пользуюсь внешними устройствами, но был бы рад получить либо пустой телевизор, либо качественный смарт (Андроид на данный момент).
2. Chromecast первого поколения не работает стабильно с текущим телевизором, нужно новый покупать (может заработает, а может нет). Chromecast встроен в Андроид ТВ обычно (не уверен, что всегда), что гарантирует нормальную работоспособность на данном ТВ.
3. Внешние устройства отдельно грузятся и нужно включать / выключать — неудобно.
4. В вебОС, по сути, только одно приложение приличное — Youtube. Остальные: часто вообще нет; если есть, то обрезанный функционал и ошибки. В целом, проблемы маргинальной ОС.
5. С телевизором идет хороший пульт, который позволяет управлять мышкой движением пульта в пространстве — это снимает практически все вопросы по планшетным приложениям (если бы был Андроид).
У меня ощущение, что через пару лет они совсем от этой ОС откажутся и в телевизоры поставят Android (надежда).
Если все по накатанной, то смысла вдвоём программировать нет.
Соответственно, в разы ускоряется (и удешевляется) разработка и отладка.
— писать/поддерживать сложновато ещё
— стоимость ещё должна упасть
В принципе, об этом и статья.
Как альтернативы есть системы на базе докера (например, кибернетис умеет скейлить до 0 deploy) и Google Apps Engine (стартует достаточно быстро, автомасштабируется так же до 0). Там можно писать обычные приложения на многих языках.
При этом не помню про blkio. Скорее всего нет. Но это из-за идеологии отсутствия локальных хранилищ.
Ещё интересны ограничения на трафик. Что-то на эту тему так же есть в k8s.
Если говорить про настройки хоста/ядра, то это тоже можно делать. Но это уже никакой не чёрный ящик.
PS. А вот «вознаграждения» в таких случаях (если нет заранее заявленной программы) — это друга статья УК про вымогательство. Нужно понимать, что наличие публичной программы поиска уязвимостей — это часть пиара компании с соотв. заранее выделенным бюджетом. Если такой пиар не считается важным, то и никаких денег не будет.
Если говорить про деньги, то продвинутый сеньор наверняка половину отдаёт налогами. Хотя в целом да, в США можно найти зп лучше, чем в кроссовере, но, как по мне, только в США в офисе и с местными расходами. В России же не видел лучше предложений с учётом удаленной работы (если, вдруг, есть, то всем будет интересно услышать).
Сам способ сравнения убивает весь смысл облака. Нужны VPS — берите VPS, а не облачные ресурсы. А то и дедики на hetzner, если все равно никакой облачной инфраструктурой не предполагается пользоваться (т.к. в сравнении этого нет, а с их учётом фавориты могут легко поменяться).
Т.е. для сравнения нужно что-то более сложное с различными сервисами и отказоустойчивостью. С точки зрения цен в облаке часто более важным является стоимость хранения (esb, s3, managed MySQL/postgresql, managed document db, ...), чем вычислительных ресурсов.
Не стоит забывать и про платформенные услуги: Firebase у Google, что-то несколько другое есть у AWS, про Azure не скажу. Кому-то могут подойти и сэкономить чемодан денег.
По Гуглу можно добавить, что формально они не работают с физ. лицами в России — как минимум ИП.
— при скролировании: что остаётся на месте, что двигается. Бонусом изменение размера, появление/скрытие элементов при скролинге.
— разная верстка под разный размер окна браузера: резиновая/фиксированная, появление/скрытие элементов (адаптивная вёрстка)
— z-index — в простейшем случае для модальных окон
— наведение мышью
— щелчки — анимация кнопок
— эффекты от таймера — анимации, карусели
Но сама по себе идеи интересна и в будущем дизайнеры, возможно, будут помечать слои в psd понятным для щелкунчика образом.
Kubernetes изначально выглядит как что-то сложное, но достаточно быстро понимаешь, что ничего страшного. Он в том или ином виде поддерживается GCP (Google Kubernetes Engine), AWS (kops), Azure (Azure Container Service), on-prem (разные варианты). При этом и от Kubernetes хочется большей стабильности (например, приходится пользоваться альфа/бета фичами), но уж что поделать.
0. Реформаторы кода и линтеры запускаются до подачи кода на code review
1. Продуктовые вопросы (как это должно работать в таком-то случае? как это должно работать совместно с такой-то функцией)
2. Высокоуровневый дизайн (структуры данных, библиотеки/модули/пакеты/классы/публичные методы)
3. Качество кодирования (приватные методы, код внутри методов, тесты)
Если есть вопрос по определенному пункту, то ниже не спускаемся, т.к. может оказаться, что соответствующий код будет переделан.
В примере из статьи не было нулевого пункта. Сразу были комментарии по пунктам 0, 1?, 2, 3. Это дало возможность разработчику исправить только 0 и 3, а по принципиальным для проектирования моментам ничего не сделать. Если бы были замечания только по пункту 2, то их бы не получилось так просто игнорировать.
Основная же идея о том, что можно пропускать плохой код ради обучения специалистов не понравилась. Если юниор (вообще или в проекте), то можно перед написанием кода делать верхнеуровневое проектирование (исключит пункты 1 и 2). А вот к коду внутри методов можно действительно временно снижать планку, если приходится работать с юниорами в программировании (регуляр уже должен корректно писать код на уровне методов).