Ну слушайте, я завтра (сегодня я занят) заявлю, что для компиляции, скажем, языка С, не нужен компилятор с языка С, пороюсь в загашниках и достану какую-нибудь приблуду, которая Сшный код конвертирует в ассемблерный.
Буду ли я прав? Буду, если сделаю оговорку, что компилятор не нужен не всегда. Без такой оговорки я буду неправ, поскольку в этом случае мое утверждение будет претендовать на то, что оно справедливо во всех случаях. Автор утверждения, которое я оспаривал, такой оговорки не сделал.
Поэтому давайте не будем общее утверждение подтверждать частными случаями? Приведенная выше примочка не является штатным средством, не входит в спецификацию protobuf, к тому же реализована только для .NET, а вовсе не для всех языков, для которых есть protobuf.
А не майкрософтовские неймспейсы у нас не в почете?
Гм. Мне это почудилось, что между "можно без протофайлов" и "можно без протофайлов, но с внешней примочкой" есть неуловимая смысловая разница? Или мне не почудилось, и она действительно есть?
Если предполагается restful взаимодействие с понятной предметной областью - то классический Rest однозначно лучше.
Звучит так, как будто restful-взаимодействие — самоцель. Но обычно нужно просто взаимодействие, а к restful обращаются потому, что это первое, что приходит в голову.
Ну т.е. можно сказать ведь, что "если предполагается взаимодействие через TCP-сокеты, то классическая работа с сокетами однозначно лучше". Трудно спорить. ;)
Очень жаль, что не рассказали о том, что протобаф доступен без всякого grpc и протофайлов как форматтер в "обычном" рест-взаимодействии.
Без gRPC — да.
Без протофайлов — нет. Ну т.е. можно "потом" руками модифицировать уже сгенерированный исходный код и брать на себя всю ответственность за нарушения контракта, но в первоначальной итерации все-равно нужно компилировать протофайлы.
Прочитал с удовольствием, узнал много того, до чего либо руки не доходили, либо нужды не было.
Очень хорошим языком написано, без заигрываний с читателем, без мачизма и дурацких картинок не к месту, отличная подача материала, четко и по делу, читается легко. Таких статей попадается — одна в месяц. Неужели место работы сказывается? ;)
К каким-таким недостаткам текста? Да я такого живого и увлекательного текста сто лет не читал! Удачи на первой работе! Ну и на последующих тоже, конечно. :)
Кошки удивлялись тому, что звук хозяина послышался из места, где его нет. Т.е. слышимое не совпадало с видимым. Кроме того, мог сказаться эффект неожиданности сам по себе. Даже если кошка видит меня, а я неожиданно скажу что-то громче чем обычно — она удивится. Чему же, по мнению японских товарищей, она удивилась в этом случае?
Похоже, это исследование уровня "среди бегунов на пробежке много толстых — значит, от бега толстеют".
Давно точу зубы на ваше приложение. Красивое, в целом удобное, но! Это же не приложение — это 5 приложений, объединенных одним таббаром. Каждая вкладка независима от других, сама себе на уме, "всё свое ношу с собой, ни с кем не делюсь".
Нет, я понимаю, что такой подход как раз в духе современных веяний — модульность, независимость, loosely coupling, но как-то за всем этим забывают о том, что приложение предназначено для того, чтобы пользователям удобно было, а не для того, чтобы разрабы добавляли строчки в перечень освоенных скиллов и рассказывали потом на конференциях, как они мужественно внедряли VIPER.
Вот смотрите, предположим, юзер тапает по иконке, но приложение не запускается, а выходит из фона (потому что недавно оно уже запускалось). Мы на первой вкладке делаем pull-to-refresh, видим обновленный баланс бонусов и баланс Magnit Pay. Идем на последнюю вкладку — там цифры старые. Почему? А потому. Надо и там pull-to-refresh. Информация двух вкладок пересекается, легко и просто добывается с бэкенда вообще одним запросом, но нет — юзер должен сделать два. Ваш бэкенд должен обработать тоже два. Вы целую статью написали о том, как много у вас пользователей, как велика нагрузка на бэкенд — странно, что обрабатывать вдвое больше запросов в таких условиях не считается у вас непозволительной роскошью. Т.е. тут все в проигрыше — и вы, и пользователи. Зачем так делать?
Баланс Magnit Pay тоже добывается дважды, независимо, на двух разных вкладках.
Когда приложение возвращается из фона — данные не обновляются. Почему? Почему вообще считается приемлемым показывать пользователям левые, не соответствующие действительности, устаревшие данные? Почему считается нормой врать пользователю в интерфейсе? Потому что так делает фэйсбук и прочие? Да не надо перенимать у грандов плохие практики, надо хорошие перенимать.
Знаете, к чему приводит необновление данных? К тому, что я перестаю им доверять, и даже если они актуальны, принудительно обновляю их на всякий случай. Чтоб быть уверенным хотя бы на 99%. Т.е. разработчики намеревались получить вдвое меньше запросов, а получили вдвое больше. Ожидания vs реальность.
Выше писали про сложности с показом бонусной карты, если интернет плохой. Простите, я правильно понял, что карту приложение не хранит локально, а каждый раз дергает с бэкенда? Карта — это такая сущность, которая обновляется раз в несколько месяцев, если вообще обновляется — зачем каждый раз ходить за ней на бэкенд? Ну а блокировка интерфейса при старте — до момента, когда с сервера загрузится контент для первой вкладки — это вообще что-то за гранью, это, архитектурно, какая-то студенческая поделка, а не приложение федеральной торговой сети. Как такое вообще могло уйти в прод.
Так я уже в третий раз задаю вопрос: это реалии российской территории, или реалии российских операторов?
В обсуждаемом контексте это тождественные понятия. Реалии российских операторов являются таковыми только на российской территории, в их, этих операторов, сетях.
Когда же вы в роуминге — в чужой сети, где имеют место ее (оператора/территории) собственные реалии.
Грубо говоря, если я с российской симкой нахожусь в роуминге на Кубе, то будет ли работать восьмёрка в начале номера, и будет ли работать кубинский код межгорода 119?
Поскольку я не настоящий сварщик и с телефонией знаком постольку-поскольку, я могу лишь обоснованно предполагать. Обоснованное предположение заключается в том, что когда вы в роуминге на Кубе, вы находитесь в сети местного оператора, звонки в которой маршрутизируются оборудованием местного оператора и по его правилам. Соответственно, раз местный оператор ничего не знает про российскую практику подмены 8 на +7, то вы никуда не дозвонитесь. Кубинский код межгорода, возможно, работать будет, а возможно и нет — это зависит от настроек маршрутизации местного оператора. Если у абонентов местной мобильной сети этот код работает — будет работать и у вас.
Именно потому, что все другие форматы записи номера — это "маршруты", использующие "команды" (8, 10, 8-10, 9, 0, 00 и т.д.), понимаемые (или не понимаемые, или понимаемые не так) оборудованием сети, к которой вы подключены.
Я бы перефразировал — нужны ли какие-либо еще форматы, кроме международного. То, что, например, в России можно позвонить через 8-ку — это местные российские реалии, исключительно ради совместимости с традиционным способом набора.
Это было сделано еще в СССР для удобства, чтобы не искать в телефоне знак плюс, для внутренних звонков, если оператор получает от вас телефон без знака плюс с 8, то просто меняет его на +7
Если кто-то помнит или знает, раньше были домашние телефоны и как правило там номера были из семи, шести или пяти цифр. На самом деле при наборе такого номера оператор автоматически дописывал вначале двойки или шестёрки, чтобы цифр стало семь, затем приписывает номер региона в котором ты находишься затем приписывает код страны в которой ты находишься и по итогу ты просто звонишь в собственный город абоненту номер которого ты указал.
Нет, увы, было не так, никто никуда ничего не подставлял. Оно вообще иначе было устроено. Декадно-шаговые механические АТС по-другому и не умели. Они не работали с цифрами, они имели дело с сигналами (тональными или пульсовыми) и коммутацией физических каналов связи.
Вообще, есть одно принципиальное отличие в процедуре набора номера на мобильном телефоне и на стационарном:
Когда вы набираете номер на мобильном, вы сначала его набираете весь целиком, а потом отсылаете. При этом вы можете набрать и меньше цифр, чем надо, и больше (звонок не пройдет, но именно набрать вам никто не помешает). Мобильный оператор получает номер полностью, парсит его и принимает решение, куда зароутить звонок. В процессе парсинга возможны разнообразные подмены и т.д. — всё как мы любим в программировании. Условно говоря, номер передается оператору в "пакетном режиме". Сама возможность этого обусловлена тем, что АТС мобильных операторов — это современные "софтверные" АТС.
Когда же вы набирали номер на классическом стационарном аппарате, то каждая цифра "отсылалась" сразу по мере набора. Хотя, конечно, трудно говорить об отсылке — между телефонным аппаратом и АТС уже в момент подъема трубки было установлено соединение (был гудок в трубке). Дальше вы начинали набирать номер, при этом АТС в реальном времени анализировала каждую набранную цифру, и если вы набрали что-то не так, то она прерывала вас, например, короткими гудками, еще до того, как вы закончили набор. В процессе набора вы не смогли бы набрать меньше цифр, чем надо (АТС будет ждать очередной цифры, в трубке будет тишина и больше ничего не будет происходить), вы не смогли бы набрать больше цифр, чем надо (АТС начнет устанавливать соединение с абонентом по поступлении последней цифры из ожидаемого кол-ва). Не уверен насчет маршрутизации локальных внутригородских номеров, но если вы в самом начале набрали "8", то вас тут же прокидывало на междугороднюю АТС и дальше ваш телефонный аппарат общался уже с ней (как правило, после прокидывания на межгород даже тональность гудка в трубке менялась, это же всё аналоговое было). Дальше междугородняя АТС ждала от вас либо код города, либо команду на выход на межгород ("10"). Таким образом, маршрутизация звонка осуществляется пошагово, с переключениями в реальном времени на те АТС, которые отвечают за то или иное направление. Условно говоря, номер передавался оператору в диалоговом режиме, а соединение устанавливалось прямо в процессе набора, поэтапно, от АТС к АТС. Ну и сами АТС были громоздкими механизмами с физической коммутацией соединений, отличаясь от нынешних даже больше, чем мэйнфреймы 70-80-х отличались от PC. Чуть лучше, чем тетенька-оператор в совсем уж старых фильмах — но принцип ровно тот же.
P.S. Отсюда, кстати, вытекает, что только международный формат записи номера (с плюсиком и т.д.) определяет универсальный и не зависящий от местонахождения звонящего "адрес" абонента в мировой телефонной сети. Заданный, говоря современным ИТ-языком, в декларативном стиле. Дескать, вот номер — а теперь давай, соедини меня с ним, мне все равно как ты это сделаешь.
Формат же записи с восьмерками, нулями, десятками, выходом на межгород и вот это всё — это, фактически, не номер, это маршрут ("сначала выйди на межгород, набрав 8, потом на международ, набрав 10..., а если ведомственная АТС, то прежде всего выйди в городскую сеть, набрав 9"). И этот маршрут зависит от того, в какой точке телефонной сети набирается номер. Императивный стиль, определенно.
Вам известна сказка про голого короля?
Ну слушайте, я завтра (сегодня я занят) заявлю, что для компиляции, скажем, языка С, не нужен компилятор с языка С, пороюсь в загашниках и достану какую-нибудь приблуду, которая Сшный код конвертирует в ассемблерный.
Буду ли я прав? Буду, если сделаю оговорку, что компилятор не нужен не всегда. Без такой оговорки я буду неправ, поскольку в этом случае мое утверждение будет претендовать на то, что оно справедливо во всех случаях. Автор утверждения, которое я оспаривал, такой оговорки не сделал.
Поэтому давайте не будем общее утверждение подтверждать частными случаями? Приведенная выше примочка не является штатным средством, не входит в спецификацию protobuf, к тому же реализована только для .NET, а вовсе не для всех языков, для которых есть protobuf.
Не понял вопроса.
Гм. Мне это почудилось, что между "можно без протофайлов" и "можно без протофайлов, но с внешней примочкой" есть неуловимая смысловая разница? Или мне не почудилось, и она действительно есть?
Звучит так, как будто restful-взаимодействие — самоцель. Но обычно нужно просто взаимодействие, а к restful обращаются потому, что это первое, что приходит в голову.
Ну т.е. можно сказать ведь, что "если предполагается взаимодействие через TCP-сокеты, то классическая работа с сокетами однозначно лучше". Трудно спорить. ;)
Без gRPC — да.
Без протофайлов — нет. Ну т.е. можно "потом" руками модифицировать уже сгенерированный исходный код и брать на себя всю ответственность за нарушения контракта, но в первоначальной итерации все-равно нужно компилировать протофайлы.
PunkBuster недалеко от нее ушел.
Видимо, всё же, только в этом случае?
А в остальных — не начинают, пока их не await'нут.
Простите, но LA — это не Bay Area.
И климат в Bay Area характеризуется, скорее, как "вечная весна", жары там не бывает практически.
GB — родина всего английского на планете. :)
P.S. В Канаде, кстати, тоже всё как у людей, хотя казалось бы, рядышком с США совсем. Остальных не проверял.
К чему гадать — просто поставьте в телефоне/компьютере локаль EN-GB, убедитесь.
Он доступен на десктопе, давно. Во всяком случае, в октябре 2019 уже был доступен.
Прочитал с удовольствием, узнал много того, до чего либо руки не доходили, либо нужды не было.
Очень хорошим языком написано, без заигрываний с читателем, без мачизма и дурацких картинок не к месту, отличная подача материала, четко и по делу, читается легко. Таких статей попадается — одна в месяц. Неужели место работы сказывается? ;)
Продолжайте, у вас отлично получается.
К каким-таким недостаткам текста? Да я такого живого и увлекательного текста сто лет не читал! Удачи на первой работе! Ну и на последующих тоже, конечно. :)
Спасибо, у меня есть. :)
И вообще, "я тут перед вами не как лягушка стою, а как женщина" (С)
В смысле, не как разработчик, а как обычный юзер. :)
Кошки удивлялись тому, что звук хозяина послышался из места, где его нет. Т.е. слышимое не совпадало с видимым. Кроме того, мог сказаться эффект неожиданности сам по себе. Даже если кошка видит меня, а я неожиданно скажу что-то громче чем обычно — она удивится. Чему же, по мнению японских товарищей, она удивилась в этом случае?
Похоже, это исследование уровня "среди бегунов на пробежке много толстых — значит, от бега толстеют".
Давно точу зубы на ваше приложение. Красивое, в целом удобное, но! Это же не приложение — это 5 приложений, объединенных одним таббаром. Каждая вкладка независима от других, сама себе на уме, "всё свое ношу с собой, ни с кем не делюсь".
Нет, я понимаю, что такой подход как раз в духе современных веяний — модульность, независимость, loosely coupling, но как-то за всем этим забывают о том, что приложение предназначено для того, чтобы пользователям удобно было, а не для того, чтобы разрабы добавляли строчки в перечень освоенных скиллов и рассказывали потом на конференциях, как они мужественно внедряли VIPER.
Вот смотрите, предположим, юзер тапает по иконке, но приложение не запускается, а выходит из фона (потому что недавно оно уже запускалось). Мы на первой вкладке делаем pull-to-refresh, видим обновленный баланс бонусов и баланс Magnit Pay. Идем на последнюю вкладку — там цифры старые. Почему? А потому. Надо и там pull-to-refresh. Информация двух вкладок пересекается, легко и просто добывается с бэкенда вообще одним запросом, но нет — юзер должен сделать два. Ваш бэкенд должен обработать тоже два. Вы целую статью написали о том, как много у вас пользователей, как велика нагрузка на бэкенд — странно, что обрабатывать вдвое больше запросов в таких условиях не считается у вас непозволительной роскошью. Т.е. тут все в проигрыше — и вы, и пользователи. Зачем так делать?
Баланс Magnit Pay тоже добывается дважды, независимо, на двух разных вкладках.
Когда приложение возвращается из фона — данные не обновляются. Почему? Почему вообще считается приемлемым показывать пользователям левые, не соответствующие действительности, устаревшие данные? Почему считается нормой врать пользователю в интерфейсе? Потому что так делает фэйсбук и прочие? Да не надо перенимать у грандов плохие практики, надо хорошие перенимать.
Знаете, к чему приводит необновление данных? К тому, что я перестаю им доверять, и даже если они актуальны, принудительно обновляю их на всякий случай. Чтоб быть уверенным хотя бы на 99%. Т.е. разработчики намеревались получить вдвое меньше запросов, а получили вдвое больше. Ожидания vs реальность.
Выше писали про сложности с показом бонусной карты, если интернет плохой. Простите, я правильно понял, что карту приложение не хранит локально, а каждый раз дергает с бэкенда? Карта — это такая сущность, которая обновляется раз в несколько месяцев, если вообще обновляется — зачем каждый раз ходить за ней на бэкенд? Ну а блокировка интерфейса при старте — до момента, когда с сервера загрузится контент для первой вкладки — это вообще что-то за гранью, это, архитектурно, какая-то студенческая поделка, а не приложение федеральной торговой сети. Как такое вообще могло уйти в прод.
"Обрабатывала" сойдет? Ну вот и славно.
В обсуждаемом контексте это тождественные понятия. Реалии российских операторов являются таковыми только на российской территории, в их, этих операторов, сетях.
Когда же вы в роуминге — в чужой сети, где имеют место ее (оператора/территории) собственные реалии.
Поскольку я не настоящий сварщик и с телефонией знаком постольку-поскольку, я могу лишь обоснованно предполагать. Обоснованное предположение заключается в том, что когда вы в роуминге на Кубе, вы находитесь в сети местного оператора, звонки в которой маршрутизируются оборудованием местного оператора и по его правилам. Соответственно, раз местный оператор ничего не знает про российскую практику подмены 8 на +7, то вы никуда не дозвонитесь. Кубинский код межгорода, возможно, работать будет, а возможно и нет — это зависит от настроек маршрутизации местного оператора. Если у абонентов местной мобильной сети этот код работает — будет работать и у вас.
Именно потому, что все другие форматы записи номера — это "маршруты", использующие "команды" (8, 10, 8-10, 9, 0, 00 и т.д.), понимаемые (или не понимаемые, или понимаемые не так) оборудованием сети, к которой вы подключены.
Я бы перефразировал — нужны ли какие-либо еще форматы, кроме международного. То, что, например, в России можно позвонить через 8-ку — это местные российские реалии, исключительно ради совместимости с традиционным способом набора.
Нет, увы, было не так, никто никуда ничего не подставлял. Оно вообще иначе было устроено. Декадно-шаговые механические АТС по-другому и не умели. Они не работали с цифрами, они имели дело с сигналами (тональными или пульсовыми) и коммутацией физических каналов связи.
Вообще, есть одно принципиальное отличие в процедуре набора номера на мобильном телефоне и на стационарном:
Когда вы набираете номер на мобильном, вы сначала его набираете весь целиком, а потом отсылаете. При этом вы можете набрать и меньше цифр, чем надо, и больше (звонок не пройдет, но именно набрать вам никто не помешает). Мобильный оператор получает номер полностью, парсит его и принимает решение, куда зароутить звонок. В процессе парсинга возможны разнообразные подмены и т.д. — всё как мы любим в программировании. Условно говоря, номер передается оператору в "пакетном режиме". Сама возможность этого обусловлена тем, что АТС мобильных операторов — это современные "софтверные" АТС.
Когда же вы набирали номер на классическом стационарном аппарате, то каждая цифра "отсылалась" сразу по мере набора. Хотя, конечно, трудно говорить об отсылке — между телефонным аппаратом и АТС уже в момент подъема трубки было установлено соединение (был гудок в трубке). Дальше вы начинали набирать номер, при этом АТС в реальном времени анализировала каждую набранную цифру, и если вы набрали что-то не так, то она прерывала вас, например, короткими гудками, еще до того, как вы закончили набор. В процессе набора вы не смогли бы набрать меньше цифр, чем надо (АТС будет ждать очередной цифры, в трубке будет тишина и больше ничего не будет происходить), вы не смогли бы набрать больше цифр, чем надо (АТС начнет устанавливать соединение с абонентом по поступлении последней цифры из ожидаемого кол-ва). Не уверен насчет маршрутизации локальных внутригородских номеров, но если вы в самом начале набрали "8", то вас тут же прокидывало на междугороднюю АТС и дальше ваш телефонный аппарат общался уже с ней (как правило, после прокидывания на межгород даже тональность гудка в трубке менялась, это же всё аналоговое было). Дальше междугородняя АТС ждала от вас либо код города, либо команду на выход на межгород ("10"). Таким образом, маршрутизация звонка осуществляется пошагово, с переключениями в реальном времени на те АТС, которые отвечают за то или иное направление. Условно говоря, номер передавался оператору в диалоговом режиме, а соединение устанавливалось прямо в процессе набора, поэтапно, от АТС к АТС. Ну и сами АТС были громоздкими механизмами с физической коммутацией соединений, отличаясь от нынешних даже больше, чем мэйнфреймы 70-80-х отличались от PC. Чуть лучше, чем тетенька-оператор в совсем уж старых фильмах — но принцип ровно тот же.
P.S. Отсюда, кстати, вытекает, что только международный формат записи номера (с плюсиком и т.д.) определяет универсальный и не зависящий от местонахождения звонящего "адрес" абонента в мировой телефонной сети. Заданный, говоря современным ИТ-языком, в декларативном стиле. Дескать, вот номер — а теперь давай, соедини меня с ним, мне все равно как ты это сделаешь.
Формат же записи с восьмерками, нулями, десятками, выходом на межгород и вот это всё — это, фактически, не номер, это маршрут ("сначала выйди на межгород, набрав 8, потом на международ, набрав 10..., а если ведомственная АТС, то прежде всего выйди в городскую сеть, набрав 9"). И этот маршрут зависит от того, в какой точке телефонной сети набирается номер. Императивный стиль, определенно.