Просто обычно так получается, что основные аргументы против это:
ой, дорого, да я за эти деньги… (в абсолютных суммах — да, относительно конкурентов — зачастую даже дешевле)
вот мне надо по-другому как-то чтобы это работало (нет, я не хочу дать шанс специалистам из миллиардной корпорации предложить свой вариант, который зачастую весьма и весьма не плох. Хотя да, есть нюансы, но решаются обычно просто)
мне надо работать с файлами работать на iOS (почти никак)
Почему-то про слегка кривоватый bluetooth стэк никто не спрашивает. Про то, как c микрофона блестящих новых airpods загнать голос в хорошем качестве в мак тоже никто не спрашивает. Про батарейку, которая года через два на iphone 6/6s ощутимо деградирует, тоже особенно вопросов не задают.
И, вот если по-честному, сколько у вас денег, что вы всю эту музыку купили, положили к себе на винт и храните её?
У меня вот столько нет, поэтому я 160 рублей плачу гуглу.
И, кстати, за 160 рублей, гугл мне гарантирует лучший за эти деньги уровень сохранности.
Это почему вдруг? До появление iPhone X в линейке было примерно два размера (SE не в счёт) — обычный и plus. Первый хорошо лежит в кармане, но дисплей всё же мелковат. У второго с дисплеем всё в порядке, но уже не в каждый карман входит так легко, как стандартный. Появился X, у которого экран больше чем у plus, а физический размер аппарата совсем немного больше стандартного.
Ну, если говорить про серьёзный взрослый ДХ, да и сноуборд/горные лыжи, то там вполне себе работа всех групп мышц. Если про спуститься с горочки, то это совсем не оно.
Вот это реально очень большая печаль. Пару лет назад, когда только скайп начали с телевизоров выпиливать, хотел купить телевизор со скайпом. Это же удобно, чёрт возьми, когда внук во весь экран и всё это парой кнопок с пульта. Но, как выпилили, так и не запилили обратно. Крайне жаль, потому что идея, как по мне, была просто потрясающей.
Ну, не настолько разные они по отношению к JS. Про soundness в быту поспорить можно, но для обычной разработки вперёд, как показала практика, это не даёт такого большого выигрыша, как например, более развитый туллинг и экосистема.
Собственно, на первый взгляд flow и ts про одно и то же. Если немного приглядеться, то flow всё же больше про js + types и система типов более правильная. Зато у ts сильно лучше туллинг и сильно больше библиотек уже искоробки. Потому ts всех и победил. Хотя, как по мне, flow интереснее.
На заре хайпа про NoSQL у этой аббревиатуры было еще одно значение — Not Only SQL. Что идеологически гораздо более правильно, но вот только про хорошие примеры SQL + что-то ещё в одном флаконе мне неизвестно.
Потому что инстанс с терабайтом озу стоит семь баксов в час?
Есть ощущение, что это очень сильно уменьшает потребность в горизонтальном масштабировании.
Тот редкий момент, когда пропустив половину истории получается не укорочённая версия, а совсем другая история и другие выводы.
Особенно доставило, что про джойны(которые в случае острой необходимости довольно прямо лепятся поверх любого kv-хранилища) есть, а про распределенные транзакции, в которые все реляционки очень бодро упираются — нет.
Кстати, и мое ощущение от обратного движения в сторону реляционных бд вовсе не в том, что они прям сильно лучше стали, а в том, что хайпа про «моему уютному бложику не прожить без шардирования и репликации» поубавилось. Ну и виртуализация стоит теперь дешевле чашки кофе и расти вертикально теперь сильно проще и дешевле.
Вопрос в размере кодовой базы. Если всё входит в одну среднюю голову одного среднего программиста — то проблем нет. Проблемы начинаются тогда, когда проект растёт.
Как выкладка происходит в плане взаимодействия разработки и тестирования?
Разработчики разработали новую фичу, она прошла некоторый QA, а как дальше это попадает на прод? Есть промежуточная площадка (препрод), где фичу гоняют на живых данных, или она сразу уезжает в прод?
Более чем практичная. Проект на 75kloc — сначала перевели тесты через бабель еще во времена 6-й ноды (~33kloc). Потом перевели всё остальное уже с 8-й нодой. Все довольны очень сильно, всё здорово.
Я понимаю, что это сильно за пределами вводной статьи, но это какой-то очень уж сферический пример. Поэтому у меня вопросы:
как это все работает, когда тело метода handle() требует асинхронных операций. В базу, например сходить. И, поскольку Java многопоточная, то как обстоят дела с конкурентным доступом к одному и тому же request/response из разных потоков.
как использовать композицию? Например, накрутить кастомную авторизацию, чтобы сбегать в базу и найти пользователя по сессии.
К вёрстке отношения никакого не имею, латехом пользовался. С книгами и научными статьями всё понятно. А насколько надо заморочиться, чтобы получить уровень вёрстки глянцевых журналов с помощью Latex? Видел краем глаза, как это делают в InDesign.
Если не ошибаюсь, начиная с ios 11 можно выключить клавиатуру с емодзи.
Просто обычно так получается, что основные аргументы против это:
Почему-то про слегка кривоватый bluetooth стэк никто не спрашивает. Про то, как c микрофона блестящих новых airpods загнать голос в хорошем качестве в мак тоже никто не спрашивает. Про батарейку, которая года через два на iphone 6/6s ощутимо деградирует, тоже особенно вопросов не задают.
И, вот если по-честному, сколько у вас денег, что вы всю эту музыку купили, положили к себе на винт и храните её?
У меня вот столько нет, поэтому я 160 рублей плачу гуглу.
И, кстати, за 160 рублей, гугл мне гарантирует лучший за эти деньги уровень сохранности.
Это почему вдруг? До появление iPhone X в линейке было примерно два размера (SE не в счёт) — обычный и plus. Первый хорошо лежит в кармане, но дисплей всё же мелковат. У второго с дисплеем всё в порядке, но уже не в каждый карман входит так легко, как стандартный. Появился X, у которого экран больше чем у plus, а физический размер аппарата совсем немного больше стандартного.
Ну, не настолько разные они по отношению к JS. Про soundness в быту поспорить можно, но для обычной разработки вперёд, как показала практика, это не даёт такого большого выигрыша, как например, более развитый туллинг и экосистема.
Собственно, на первый взгляд flow и ts про одно и то же. Если немного приглядеться, то flow всё же больше про js + types и система типов более правильная. Зато у ts сильно лучше туллинг и сильно больше библиотек уже искоробки. Потому ts всех и победил. Хотя, как по мне, flow интереснее.
На заре хайпа про NoSQL у этой аббревиатуры было еще одно значение — Not Only SQL. Что идеологически гораздо более правильно, но вот только про хорошие примеры SQL + что-то ещё в одном флаконе мне неизвестно.
Потому что инстанс с терабайтом озу стоит семь баксов в час?
Есть ощущение, что это очень сильно уменьшает потребность в горизонтальном масштабировании.
Тот редкий момент, когда пропустив половину истории получается не укорочённая версия, а совсем другая история и другие выводы.
Особенно доставило, что про джойны(которые в случае острой необходимости довольно прямо лепятся поверх любого kv-хранилища) есть, а про распределенные транзакции, в которые все реляционки очень бодро упираются — нет.
Кстати, и мое ощущение от обратного движения в сторону реляционных бд вовсе не в том, что они прям сильно лучше стали, а в том, что хайпа про «моему уютному бложику не прожить без шардирования и репликации» поубавилось. Ну и виртуализация стоит теперь дешевле чашки кофе и расти вертикально теперь сильно проще и дешевле.
Вопрос в размере кодовой базы. Если всё входит в одну среднюю голову одного среднего программиста — то проблем нет. Проблемы начинаются тогда, когда проект растёт.
Как выкладка происходит в плане взаимодействия разработки и тестирования?
Разработчики разработали новую фичу, она прошла некоторый QA, а как дальше это попадает на прод? Есть промежуточная площадка (препрод), где фичу гоняют на живых данных, или она сразу уезжает в прод?
У меня ощущение, что вы только что придумали мобильную операционную систему. Приложения — и есть те самые модули.
Более чем практичная. Проект на 75kloc — сначала перевели тесты через бабель еще во времена 6-й ноды (~33kloc). Потом перевели всё остальное уже с 8-й нодой. Все довольны очень сильно, всё здорово.
JS из молодости и современный ES6+, к счастью, довольно разные вещи.
Я понимаю, что это сильно за пределами вводной статьи, но это какой-то очень уж сферический пример. Поэтому у меня вопросы:
handle()требует асинхронных операций. В базу, например сходить. И, поскольку Java многопоточная, то как обстоят дела с конкурентным доступом к одному и тому же request/response из разных потоков.Ну, для того, чтобы полноценно пользоваться async/await понимать как работают промисы всё же необходимо.
К вёрстке отношения никакого не имею, латехом пользовался. С книгами и научными статьями всё понятно. А насколько надо заморочиться, чтобы получить уровень вёрстки глянцевых журналов с помощью Latex? Видел краем глаза, как это делают в InDesign.