Ну смешно же. То есть переслать 140 байт текста по инфраструктуре заточенной под это, оптимизируемой десятилетиями и использующей для передачи этих данных служебные соединения (по сути своей и так нужные для поддержания связи с вышкой) - это дорого.
А использовать для этого же какое-нибудь rest api поверх десятка микросервисов каждый из которых это упаковывает/распаковывает и переписывается каждый квартал командой любителей смузи - это дешево?
Может стоит честно говорить что российские операторы офигели с ценами на смс, а ВК *пока что* офигел чуть меньше с ценами на сообщения? И решать вопрос в эту сторону.
Да я знаю, и видел как переусложняют вещи потихоньку, итерациями подстраиваясь под новые требования и сам тоже много тысяч строк кода написал, которые можно было бы заменить простеньким data pipeline’ом на spark. Когда работаешь в текучке не всегда замечаешь что можно было бы сдать назад и избавиться от десятка микросервисов, сменив стек технологий на более подходящий.
Думаю в этом плане у Маска неплохая возможность улучшить путем упрощения. Задавать неудобные вопросы «почему не сделать это проще» и иметь достаточно власти в руках, чтобы от инициативы не смогли отмахнуться те кому все и так норм.
Вопросы «как устроен Твиттер» с разбором всех их классных архитектурных идей - это разве не классика последних 5 лет System Design?
При том что думаю половину их костылей сейчас можно просто закрыть более мощным железом и деньгами и это будет дешевле чем держать лишнюю тысячу разработчиков на окладе.
Годы на реализацию постинга коротких заметок и комментариев к ним? Боюсь представить сколько тогда должна занять разработка какой-нибудь учетной системы для кафе/магазина.
Очень гибкий график для распределенной команды. Аж с 10 до 19 по Москве, столько свободы. Даже когда я работал в целиком очной компании в Москве с минимальным количеством удаленки, мы ограничивали время для «быть на связи» с 11 до 15, чтобы дать людям возможность начать пораньше/попозже
Не хвастовства ради, а чисто расширить кругозор, в Чехии в последний год крупные магазины (Globus, Kaufland, Makro) переходят на формат «сканируй товары по ходу сбора с полок приложением, для оплаты на кассе сканируешь QR приложения на терминале оплаты. Выборочно (меня примерно в 1 из 10 раз) иногда касса просит кассира проверить, он сканирует пяток случайных товаров из корзины, чтобы проверить что они добавлены и оплачены.
Пропускная способность терминала и комфорт покупок, по сравнению с обычным терминалом самообслуживания улетают в небеса, редкие «контроли» на этом фоне даже если и занимают время на дождаться продавца - не нервируют.
Логические задачи - это конечно хорошо и полезно для общей тренировки, но почему бы при этом не учить детей тому, для чего они действительно могут использовать знания.
Если чуть отойти от темы программирования, то информатика - это ведь наука о сборе и обработке информации. Да, выражается это в первую очередь в написании программ. Но ведь базовые принципы которые мы каждый день применяем при проектировании/организации систем - это тоже информация. Банально как организовать устойчивую к сбоям систему (доступность отдельных компонентов, масштабирование, failover, disaster recovery, важность мониторинга и сборка обратной связи) - это вполне себе кусок информатики, который можно использовать хоть в прокладке электричества, хоть в открытии кафе. A/B тестирование и его подводные камни, сбор статистики и её анализ.
Даже если говорить о программировании - почему не объяснять его на примерах автоматизации повседневных ручных задач, вместо абстрактных "соревновательных" заданий? Как сделать граппер сайта с уведомлением о новых выкладках в телеграм (недавно такой себе делал, чтобы найти новую квартиру для аренды). Программа которая наложит водные знаки на изображения, и пережмет их в нужный формат. Какой-нибудь учет показаний горячей/холожной воды для ТСЖ. Миллионы маленьких задач, на которые люди тратят часы повседневной жизни, и которые могли бы быть автоматизированы за пару часов программирования. Да, эти часы - это слишком мало, чтобы поднимать этот вопрос глобально (ну подумаешь, 20 минут в день потратить на фильтрацию и просмотр объявлений. А в месяц - это уже 10 часов вникуда).
А я бы пошел. При вполне полноценной сеньерской позиции в работе, не ради денег, а чисто ради гуманистических целей и помощи подрастающему поколению.
Но не на полную ставку, а 0.5 дня в неделю (2-3 урока условно), и чтобы не приходилось 70% этого времени тратить на ведение журналов, отчетов по журналам, подробных планов уроков и отчетов по проведению уроков. (Жена если что в Московской школе успела годик поработать перед декретом, так что почти с личного опыта соотношение полезного времени и отчетов).
Вопрос только в том, нужно ли это руководству школы, оркестрировать десяток таких приходящих специалистов? Или же им лучше взять вчерашнего студента педагогического и дать ему по зарплате одной ставки почти две, потому что учителей свободных нет.
Бесплатный Rectangle умеет делать всё, что вы описали и даже больше. Хотя лично у меня эта привычка из винды сразу клацать на квадратик в заголовке окна после открытия приложения уже выветрилась.
Rectangle пробовал, он умеет только делить в равных долях. При этом если сделать два приложения на пол экрана (слева и справа), а потом увести границу одного из них (уменьшив или увеличив) - второе не изменит своих размеров. В актуальной винде - дозаймет оставшуюся часть экрана. По мне более логичное и полное поведение в моих типичных сценариях (которые я и описал). Что за квадратик - я не знаю :-) Я про отнесение окна целиком в угол (сторону) экрана. Ну или Win+стрелки на худой конец.
Не знаю, зачем бы это понадобилось на Mac
Не засорять системные (а так же пользовательские) папки следами использованных один раз приложений. Хотя возможно это действительно решается более правильными процедурами установки/удаления программ, тут я соглашусь, в винде это далеко от идеала.
Тоже есть уйма бесплатных приложений, красивых и удобных.
Так мы про то "какая ОС более современна и удобна" или "как много на свете бесплатных, красивых и удобных приложений"?
То, что Мак это компьютер для дизайнеров, не более чем городская легенда.
Ну, для дизайнеров или нет, но по вашему же списку: 1, 5, 6, 11 - в первую очередь нацелены на дизайнеров и людей активно работающих с графикой. А для условных программистов: 2, 18. Есть некоторый перекос, не находите?
А можно мне ещё поддержку «snappy corners”, как в винде? Или хотя бы два окна закрепить с возможностью расширять одно и сужать другое (30% под мессенджер, 70% под ide)
И аналог Windows Sandbox для быстрого создания изолированной среды для одноразовых сомнительных программ.
Буфер обмена с историей.
Половина списка выше неплохо закрывается подпиской на Office365+Onedrive. А для остального я видимо не дизайнер, на продуктивность влияет не так сильно как управление окнами
Может тогда проще сразу ему денег отнести? Или плейстейшен. Зачем мучить человека какой-то непонятной работой, при этом делая хуже и ему (приходится работать) и себе (хуже качество товаров, уходит время впустую на заходы когда магазин не работает).
Местечковые магазины могут жить хорошо, но это должно быть не за счёт «давайте поддержим местного бедняжку», а за счёт предоставления более «персонализированных» преимуществ чем может предоставить сетевой магазин. К примеру, я хожу в два местечковых магазина регулярно, в одном закупаюсь вьетнамскими специями и ингредиентами, в другом квасом и грузинскими лимонадами (дело в Чехии если что). Нужны ли эти продукты крупным сетевикам? Наврятли, не такой уж большой спрос. А паре местечковых магазинов этого спроса видимо вполне хватает на спокойную жизнь.
А в чем отличие этого ID от продажи билетов на матчи в привязке к паспорту? Ну с теми же поездами система ведь уже есть, и вроде как работает? В чем плюс введения ещё одной идентифицирующей сущности?
А в чем негарантированность работы GPS? Есть преценденты ограничения приема сигнала ль спутников GPS для конкретных людей? Ну если не учитывать появляющиеся периодически интересные особенности работы GPS в окрестностях московского кремля? Организовываемые к слову отнюдь не оператором спутников, и едва ли ГЛОНАСС будет работать иначе.
Даже если захотеть это сделать - как это будет реализовано технически, с учетом принципа работы GPS и сроков эксплуатации текущих спутников?
Когда мы выбирали механизм хранения локальных данных для нашего ПО, чтобы уйти от локального SQL - мы проверяли и Sqlite и LiteDB и сериализацию с сохранением в файлы.
К удивлению, LiteDB с существенным отрывом обошла ручное сохранение файлов (не помню точных цифр, давно это было, но она была в 2-3 раза). Экспериментировали и с сжатием, и без сжатия, и просто записью бинарного потока данных, чтобы избавиться от накладных расходов на сериализацию.
Там достаточно много низкоуровневых оптимизаций работы с файловой системой, которые позволяют этого добиться. Повторить все это самим конечно можно, но надо ли если кто-то уже это сделал?
Ложка дегтя - как выяснилось в эксплуатации в production - её хранение данных не слишком надежно. На наших масштабах (~10000 установок, 3-5 RPM на запись в среднем) - мы ловили по несколько сломавшихся БД в месяц. Попытки достучаться до разработчика и раскопать в чем проблема - не приводили ни к чему, игнор, потом "обновитесь на последнюю версию", потом повторение ситуации. Сложный конечно вопрос, кто виноват, LiteDB или проблемы с файловой системой у клиентов, но SQL (LocalDB) это переживал нормально.
В итоге остановились на том, что в LiteDB перенесли большие, часто меняемые, но не слишком критичные данные и относились к нему как к персистентному кешу. Критичные к потере данные - оставили в SQL
А правильно ведь я понимаю, что это регулирование относится к любым акциям, вне зависимости от способа их получения?
Условно, я работаю в FAANG, получил как часть ЗП акции. Акции естественно у зарубежного брокера с которым работает компания.
Если я приезжаю в РФ (в данной дискуссии опустим вопрос про валютное резиденство), после чего через год захочу продать эти бумаги, даже если следующим шагом я хочу перевести деньги от брокера в российский банк — мне все равно сделают атата и оштрафуют на 100% операции?
Есть плюс в том, что проблемы reliability остаются за кадром и не нуждаются в отдельной обработке приложением.
Это наверное не так актуально для http-функций, но например для функций которые обрабатывают сообщения проходящие из условной очереди - это позволяет не думать о том что подписка на очередь может внезапно оборваться из за проблем с сетью. Или лок на партишен не переосвободится из за рестарта процесса.
С точки зрения функции - ей на вход просто приходит одно сообщение, которое надо обработать, а вся инфраструктура и работа по преобразованию «источник данных => входные параметры» остаётся за кадром.
Можно ли это обеспечить своими силами на голом железе? Можно, однозначно, вопрос только в объёме работы. Retry, DLQ, Throughput limiter. Обо всем этом надо вспомнить и подумать на этапе проектирования/разработки и корректор сделать. А в случае Azure Functions - это все есть из коробки и позволяет сосредоточиться на бизнес-логике.
Сам в Dynamics не работал, но коллеги «сбежавшие» оттуда в наш департамент (IC3) говорят примерно такое-же. Чайка-менеджмент, политика «закрыть таску сейчас, а потом хоть трава не расти» и плохие процессы планирования развития продукта в основном среди жалоб.
Ну смешно же. То есть переслать 140 байт текста по инфраструктуре заточенной под это, оптимизируемой десятилетиями и использующей для передачи этих данных служебные соединения (по сути своей и так нужные для поддержания связи с вышкой) - это дорого.
А использовать для этого же какое-нибудь rest api поверх десятка микросервисов каждый из которых это упаковывает/распаковывает и переписывается каждый квартал командой любителей смузи - это дешево?
Может стоит честно говорить что российские операторы офигели с ценами на смс, а ВК *пока что* офигел чуть меньше с ценами на сообщения? И решать вопрос в эту сторону.
Да я знаю, и видел как переусложняют вещи потихоньку, итерациями подстраиваясь под новые требования и сам тоже много тысяч строк кода написал, которые можно было бы заменить простеньким data pipeline’ом на spark. Когда работаешь в текучке не всегда замечаешь что можно было бы сдать назад и избавиться от десятка микросервисов, сменив стек технологий на более подходящий.
Думаю в этом плане у Маска неплохая возможность улучшить путем упрощения. Задавать неудобные вопросы «почему не сделать это проще» и иметь достаточно власти в руках, чтобы от инициативы не смогли отмахнуться те кому все и так норм.
Вопросы «как устроен Твиттер» с разбором всех их классных архитектурных идей - это разве не классика последних 5 лет System Design?
При том что думаю половину их костылей сейчас можно просто закрыть более мощным железом и деньгами и это будет дешевле чем держать лишнюю тысячу разработчиков на окладе.
Годы на реализацию постинга коротких заметок и комментариев к ним? Боюсь представить сколько тогда должна занять разработка какой-нибудь учетной системы для кафе/магазина.
извините конечно, но во сколько бы вы оценили «полноценную» реализацию такого рекурсивного распаковщика?
Очень гибкий график для распределенной команды. Аж с 10 до 19 по Москве, столько свободы. Даже когда я работал в целиком очной компании в Москве с минимальным количеством удаленки, мы ограничивали время для «быть на связи» с 11 до 15, чтобы дать людям возможность начать пораньше/попозже
Если использовать телефон только для звонков - зачем брать андроид и платить х10 против нокиа 3310?
Ну где новинка, а где уже пройденный этап.
Не хвастовства ради, а чисто расширить кругозор, в Чехии в последний год крупные магазины (Globus, Kaufland, Makro) переходят на формат «сканируй товары по ходу сбора с полок приложением, для оплаты на кассе сканируешь QR приложения на терминале оплаты. Выборочно (меня примерно в 1 из 10 раз) иногда касса просит кассира проверить, он сканирует пяток случайных товаров из корзины, чтобы проверить что они добавлены и оплачены.
Пропускная способность терминала и комфорт покупок, по сравнению с обычным терминалом самообслуживания улетают в небеса, редкие «контроли» на этом фоне даже если и занимают время на дождаться продавца - не нервируют.
Логические задачи - это конечно хорошо и полезно для общей тренировки, но почему бы при этом не учить детей тому, для чего они действительно могут использовать знания.
Если чуть отойти от темы программирования, то информатика - это ведь наука о сборе и обработке информации. Да, выражается это в первую очередь в написании программ. Но ведь базовые принципы которые мы каждый день применяем при проектировании/организации систем - это тоже информация. Банально как организовать устойчивую к сбоям систему (доступность отдельных компонентов, масштабирование, failover, disaster recovery, важность мониторинга и сборка обратной связи) - это вполне себе кусок информатики, который можно использовать хоть в прокладке электричества, хоть в открытии кафе. A/B тестирование и его подводные камни, сбор статистики и её анализ.
Даже если говорить о программировании - почему не объяснять его на примерах автоматизации повседневных ручных задач, вместо абстрактных "соревновательных" заданий? Как сделать граппер сайта с уведомлением о новых выкладках в телеграм (недавно такой себе делал, чтобы найти новую квартиру для аренды). Программа которая наложит водные знаки на изображения, и пережмет их в нужный формат. Какой-нибудь учет показаний горячей/холожной воды для ТСЖ. Миллионы маленьких задач, на которые люди тратят часы повседневной жизни, и которые могли бы быть автоматизированы за пару часов программирования. Да, эти часы - это слишком мало, чтобы поднимать этот вопрос глобально (ну подумаешь, 20 минут в день потратить на фильтрацию и просмотр объявлений. А в месяц - это уже 10 часов вникуда).
А я бы пошел. При вполне полноценной сеньерской позиции в работе, не ради денег, а чисто ради гуманистических целей и помощи подрастающему поколению.
Но не на полную ставку, а 0.5 дня в неделю (2-3 урока условно), и чтобы не приходилось 70% этого времени тратить на ведение журналов, отчетов по журналам, подробных планов уроков и отчетов по проведению уроков. (Жена если что в Московской школе успела годик поработать перед декретом, так что почти с личного опыта соотношение полезного времени и отчетов).
Вопрос только в том, нужно ли это руководству школы, оркестрировать десяток таких приходящих специалистов? Или же им лучше взять вчерашнего студента педагогического и дать ему по зарплате одной ставки почти две, потому что учителей свободных нет.
Rectangle пробовал, он умеет только делить в равных долях. При этом если сделать два приложения на пол экрана (слева и справа), а потом увести границу одного из них (уменьшив или увеличив) - второе не изменит своих размеров. В актуальной винде - дозаймет оставшуюся часть экрана. По мне более логичное и полное поведение в моих типичных сценариях (которые я и описал). Что за квадратик - я не знаю :-) Я про отнесение окна целиком в угол (сторону) экрана. Ну или Win+стрелки на худой конец.
Не засорять системные (а так же пользовательские) папки следами использованных один раз приложений. Хотя возможно это действительно решается более правильными процедурами установки/удаления программ, тут я соглашусь, в винде это далеко от идеала.
Так мы про то "какая ОС более современна и удобна" или "как много на свете бесплатных, красивых и удобных приложений"?
Ну, для дизайнеров или нет, но по вашему же списку: 1, 5, 6, 11 - в первую очередь нацелены на дизайнеров и людей активно работающих с графикой. А для условных программистов: 2, 18. Есть некоторый перекос, не находите?
А можно мне ещё поддержку «snappy corners”, как в винде? Или хотя бы два окна закрепить с возможностью расширять одно и сужать другое (30% под мессенджер, 70% под ide)
И аналог Windows Sandbox для быстрого создания изолированной среды для одноразовых сомнительных программ.
Буфер обмена с историей.
Половина списка выше неплохо закрывается подпиской на Office365+Onedrive. А для остального я видимо не дизайнер, на продуктивность влияет не так сильно как управление окнами
Может тогда проще сразу ему денег отнести? Или плейстейшен. Зачем мучить человека какой-то непонятной работой, при этом делая хуже и ему (приходится работать) и себе (хуже качество товаров, уходит время впустую на заходы когда магазин не работает).
Местечковые магазины могут жить хорошо, но это должно быть не за счёт «давайте поддержим местного бедняжку», а за счёт предоставления более «персонализированных» преимуществ чем может предоставить сетевой магазин. К примеру, я хожу в два местечковых магазина регулярно, в одном закупаюсь вьетнамскими специями и ингредиентами, в другом квасом и грузинскими лимонадами (дело в Чехии если что). Нужны ли эти продукты крупным сетевикам? Наврятли, не такой уж большой спрос. А паре местечковых магазинов этого спроса видимо вполне хватает на спокойную жизнь.
А в чем отличие этого ID от продажи билетов на матчи в привязке к паспорту? Ну с теми же поездами система ведь уже есть, и вроде как работает? В чем плюс введения ещё одной идентифицирующей сущности?
А в чем негарантированность работы GPS? Есть преценденты ограничения приема сигнала ль спутников GPS для конкретных людей? Ну если не учитывать появляющиеся периодически интересные особенности работы GPS в окрестностях московского кремля? Организовываемые к слову отнюдь не оператором спутников, и едва ли ГЛОНАСС будет работать иначе.
Даже если захотеть это сделать - как это будет реализовано технически, с учетом принципа работы GPS и сроков эксплуатации текущих спутников?
Когда мы выбирали механизм хранения локальных данных для нашего ПО, чтобы уйти от локального SQL - мы проверяли и Sqlite и LiteDB и сериализацию с сохранением в файлы.
К удивлению, LiteDB с существенным отрывом обошла ручное сохранение файлов (не помню точных цифр, давно это было, но она была в 2-3 раза). Экспериментировали и с сжатием, и без сжатия, и просто записью бинарного потока данных, чтобы избавиться от накладных расходов на сериализацию.
Там достаточно много низкоуровневых оптимизаций работы с файловой системой, которые позволяют этого добиться. Повторить все это самим конечно можно, но надо ли если кто-то уже это сделал?
Ложка дегтя - как выяснилось в эксплуатации в production - её хранение данных не слишком надежно. На наших масштабах (~10000 установок, 3-5 RPM на запись в среднем) - мы ловили по несколько сломавшихся БД в месяц. Попытки достучаться до разработчика и раскопать в чем проблема - не приводили ни к чему, игнор, потом "обновитесь на последнюю версию", потом повторение ситуации. Сложный конечно вопрос, кто виноват, LiteDB или проблемы с файловой системой у клиентов, но SQL (LocalDB) это переживал нормально.
В итоге остановились на том, что в LiteDB перенесли большие, часто меняемые, но не слишком критичные данные и относились к нему как к персистентному кешу. Критичные к потере данные - оставили в SQL
Условно, я работаю в FAANG, получил как часть ЗП акции. Акции естественно у зарубежного брокера с которым работает компания.
Если я приезжаю в РФ (в данной дискуссии опустим вопрос про валютное резиденство), после чего через год захочу продать эти бумаги, даже если следующим шагом я хочу перевести деньги от брокера в российский банк — мне все равно сделают атата и оштрафуют на 100% операции?
Есть плюс в том, что проблемы reliability остаются за кадром и не нуждаются в отдельной обработке приложением.
Это наверное не так актуально для http-функций, но например для функций которые обрабатывают сообщения проходящие из условной очереди - это позволяет не думать о том что подписка на очередь может внезапно оборваться из за проблем с сетью. Или лок на партишен не переосвободится из за рестарта процесса.
С точки зрения функции - ей на вход просто приходит одно сообщение, которое надо обработать, а вся инфраструктура и работа по преобразованию «источник данных => входные параметры» остаётся за кадром.
Можно ли это обеспечить своими силами на голом железе? Можно, однозначно, вопрос только в объёме работы. Retry, DLQ, Throughput limiter. Обо всем этом надо вспомнить и подумать на этапе проектирования/разработки и корректор сделать. А в случае Azure Functions - это все есть из коробки и позволяет сосредоточиться на бизнес-логике.
Считать контрольные суммы видимо. Ручкой на листочке.