Wunderlist был развёрнут на AWS и использовал кучу тамошних сервисов, а у MS нет никакого бизнесового резона держать крупный сервис на платформе прямого конкурента.
Перетащить же приложение на другое облако без полного переписывания совершенно нереально. Я делал обратную миграцию (с Azure в AWS), знаю, что говорю. Боль, страдания, всё писать с нуля. Облака похожи, но в каждом всё по-другому.
(Вообще, странно, что MS купили именно Wunderlist, могли бы другого кого-нибудь, кто уже был в их родном облаке.)
Настройки «не показывать переводы» реально не хватает. 99% таких материалов я успеваю прочитать в оригинале, а учитывая с каким опозданием их обычно публикуют, часто ловишь себя на мысли а чего это я читаю то же самое второй раз? А, блин, плашку «перевод» не заметил. Опять.
C @Transactional проблем нет, коли он рантаймовый. Клин клином, аспект поверх аспекта, или можно в контейнер вклиниться, благо, большинство позволяют.
Автор же зачем-то тестирует наличие аннотации, у которой Retention=SOURCE. На этапе выполнения. Если уж на самом деле такое настолько нужно, то это зона ответственности компилятора. Следовательно, выбран не тот инструмент на неправильной фазе жизненного цикла.
Я мог бы ответить конструктивно, но вы уже перешли на личности.
Я знаю, как работает рефлексия, писал и на спринге, и на EE (от разных вендоров) и даже собирал собственный контейнер из запчастей. Дважды, в разных окружениях. Это не говоря о плагинах для мавена и грэдла для нужд автоматизации разработки моих проектов. Таки 20 лет на джаве пишу с периодическими перерывами на другие платформы, потому меня и берут в команду как эксперта или играющего тренера.
Давайте лучше не будем меряться толщиной mojo.
Касательно «пафоса» — я искренне благодарен вам за красивый антипример антипаттерна. Спасибо.
Спасибо за красивый пример того, как ни в коем случае нельзя делать. Использую в обучающих материалах как есть (нарочно мне бы не удалось такого ужаса придумать).
Когда кто-нибудь из моих младших коллег выкатывает нечто подобное, я обычно пишу в ревью что-то типа «если решение задачи получается настолько неожиданно громоздким и хрупким, возможно, стоило задуматься над правильностью её формулировки, прежде чем начинать писать код».
Хм, я пару раз натыкался на странное значение 8675309, копаясь в чужих CSSах, но почему-то в голову не пришло его загуглить. Однако, в жизни бы не придумал использовать 2128506 для тех же целей :)
Показал коллегам по проекту, поугорали над текстом вместе.
Spark непросто осилить, и ещё сложнее научиться правильно его готовить. Нам (один малоизвестный GIS-стартап) для построения процесса обработки от сырых данных до конечного результата потребовалось полтора года. Добились ускорения на три порядка относительно первоначальной наивной реализации (в несколько тысяч раз, не шучу), но всё ещё есть что улучшать в этом процессе.
Вы сейчас рассуждаете как честный пользователь, и со своей стороны правы.
Но с другой стороны вся картина видится несколько иначе (я знаю не понаслышке, потому как давно варюсь в энтерпрайзе). Кроме 95% честных юзеров есть 4% не очень честных, и 1% явно злонамеренных, которые могут испортить жизнь всех остальных жестоким абьюзом дыр в TOS. Пошаренный ресурс ведь конечный, и обслуживать misbehaving minority в ущерб честным юзерам никто не будет.
Средством ремедиации вероятнее всего будет введение лимита по сториджу на аккаунт и/или срока хранения загруженных файлов.
OneDrive — или на момент публичного запуска, SkyDrive — тоже был неограниченным по объёму, и это была одна из его основных рекламных фишек.
Но как только маленький процент пользователей начал заливать в облако HD-рипы на сотни терабайт, Майкрософт быстро прикрыл лавочку. Даже для одной из крупнейших корпораций жадность пользователей оказалось не по карману. В итоге имеем всего 5 гигов на аккаунт бесплатно.
Бэкэнд тележки вроде как в основном на AWS хостится, значит, оперативный сторидж у них S3. При больших объёмах он стоит весьма недёшево, а денег у Telegram LLC явно меньше, чем у Майкрософта. Лавочку прикроют, как только злоупотребление станет массовым.
Форматы с разделителями (TSV, CSV и подобные) как раз очень удобны для массивно-параллельной машинной обработки. С ними гораздо проще проводить цепочки последовательных преобразований, чем данными в бинарных форматах. Разница примерно как с документами в Markdown и PDF — покуда подготавливаешь текст, он должен оставаться в основном текстом, а отрендеренный в пакованный конечный формат документ ты уже особо не изменишь.
(Это я как проектировщик расчётных модулей на Spark утверждаю, если что.)
Такое партизанство — это крайне непрофессионально.
Если бы любой из моих подопечных разработчиков выкинул подобный грязный фортель, он точно был бы немедленно уволен. Правда, я работаю техлидом в нормальных конторах, где за самоуправство полагаются санкции, и при развороте любой неутверждённой фичи она сразу же откатывается.
Но, видимо, по логике Гугла в браузерной войне любые средства хороши, а запас репутации у них бесконечный, можно и не только не извиняться, но и наоборот, развивать наступление.
Буквально через пару недель после того как появился Chromium Edge (по движку он на уровне хромовской канарейки), в Google Docs появилась соответсвующая плашка, что «ваш браузер устарел, работать не буду». Они теперь в UA начали смотреть. Это 2019-то году! Слов нет вообще.
То есть, если «чужая» сборка хромиума — то фиг вам, а не гугловые сервисы. В западной прессе вовремя заметили, не успели эту хрень на все развернуть. Но сам факт более чем некрасивый.
В госконторах типа загсов и гибдд требуют побуквенного соответствия, причём во всей пачке документов, которые нужно им приносить. Может мне особо везёт, но дважды приходилось переделывать реквизиты уплаты пошлины, потому что в паспорте «ГОР.», а в чеке кассирши оба раза набивали «Г.»
Я один считаю, что раскраска в IDE должна всего лишь отделять разные классы сущностей, типа констант, ключевых слов, комментариев, строк и чисел, друг от друга, — и всё?
Мне в целом всё равно, какими цветами, лишь бы разными. Я даже никогда не менял тему с умолчальной ни в одном IDE, только шрифт покрупнее ставлю.
Так проблемы-то как раз никакой нет %) Особенно её не должно быть для такой серьёзной на вид конторы.
А основная странность — в том, что заняться этим они решили только сейчас. Обычно к автоматизации peer review приходят ещё в течение первого года, когда команда вырастает до ~15 человек, и надо выстраивать процессы, чтобы завалов с PR не было. Тут же явно припозднились, яндекс-деньги сколько уже существуют?
Но так-то я рад за них. Лучше иметь хорошие процесссы поздно, чем никогда.
Интересно, почему в описаниях проектов Яндекса (и связанных с ними) общепринятые в индустрии решения так часто выдаются за инновацию. Вы описали обычное, стандартное peer review. Практика эта хорошо формализована, и все более-менее продвинутые ребята так делают, причём давно.
Вам запрещено брать чужой опыт, и поэтому вы вынуждены додумываться до best practices самостоятельно? Это очень странно.
Тут больше вопрос про то, с какой реально скоростью будут выводиться серийные спутники.
Для вывода всего 75 штук Iridium NEXT SpaceX потребовалось около двух лет, а в этих проектах тысячи спутников. Даже если они маленькие, и за раз по 30 штук, всё равно объём пусков поражает воображение, потребуется несколько сотен за относительно короткое время. Я пока не видел информации по подготовке инфраструктуры, тех же пусковых площадок и цехов обслуживания ракет явно недостаточно.
В том проекте спутникового интернета тысячи спутников, в сём тысячи, в этом ещё тысячи… И все на низкой орбите. Есть такое хорошее аниме Πλανήτες про будни космических мусорщиков.
Казалось бы, такими темпами скоро каждому провайдеру действительно придётся заводить отдел по отлову и утилизации обломков, но на самом деле все эти проекты двигаются как-то уж очень медленно.
Перетащить же приложение на другое облако без полного переписывания совершенно нереально. Я делал обратную миграцию (с Azure в AWS), знаю, что говорю. Боль, страдания, всё писать с нуля. Облака похожи, но в каждом всё по-другому.
(Вообще, странно, что MS купили именно Wunderlist, могли бы другого кого-нибудь, кто уже был в их родном облаке.)
Автор же зачем-то тестирует наличие аннотации, у которой Retention=SOURCE. На этапе выполнения. Если уж на самом деле такое настолько нужно, то это зона ответственности компилятора. Следовательно, выбран не тот инструмент на неправильной фазе жизненного цикла.
Я мог бы ответить конструктивно, но вы уже перешли на личности.
Я знаю, как работает рефлексия, писал и на спринге, и на EE (от разных вендоров) и даже собирал собственный контейнер из запчастей. Дважды, в разных окружениях. Это не говоря о плагинах для мавена и грэдла для нужд автоматизации разработки моих проектов. Таки 20 лет на джаве пишу с периодическими перерывами на другие платформы, потому меня и берут в команду как эксперта или играющего тренера.
Давайте лучше не будем меряться толщиной mojo.
Касательно «пафоса» — я искренне благодарен вам за красивый антипример антипаттерна. Спасибо.
Когда кто-нибудь из моих младших коллег выкатывает нечто подобное, я обычно пишу в ревью что-то типа «если решение задачи получается настолько неожиданно громоздким и хрупким, возможно, стоило задуматься над правильностью её формулировки, прежде чем начинать писать код».
Spark непросто осилить, и ещё сложнее научиться правильно его готовить. Нам (один малоизвестный GIS-стартап) для построения процесса обработки от сырых данных до конечного результата потребовалось полтора года. Добились ускорения на три порядка относительно первоначальной наивной реализации (в несколько тысяч раз, не шучу), но всё ещё есть что улучшать в этом процессе.
Когда-нибудь я напишу об этом статью.
Но с другой стороны вся картина видится несколько иначе (я знаю не понаслышке, потому как давно варюсь в энтерпрайзе). Кроме 95% честных юзеров есть 4% не очень честных, и 1% явно злонамеренных, которые могут испортить жизнь всех остальных жестоким абьюзом дыр в TOS. Пошаренный ресурс ведь конечный, и обслуживать misbehaving minority в ущерб честным юзерам никто не будет.
Средством ремедиации вероятнее всего будет введение лимита по сториджу на аккаунт и/или срока хранения загруженных файлов.
Но как только маленький процент пользователей начал заливать в облако HD-рипы на сотни терабайт, Майкрософт быстро прикрыл лавочку. Даже для одной из крупнейших корпораций жадность пользователей оказалось не по карману. В итоге имеем всего 5 гигов на аккаунт бесплатно.
Бэкэнд тележки вроде как в основном на AWS хостится, значит, оперативный сторидж у них S3. При больших объёмах он стоит весьма недёшево, а денег у Telegram LLC явно меньше, чем у Майкрософта. Лавочку прикроют, как только злоупотребление станет массовым.
(Это я как проектировщик расчётных модулей на Spark утверждаю, если что.)
Если бы любой из моих подопечных разработчиков выкинул подобный грязный фортель, он точно был бы немедленно уволен. Правда, я работаю техлидом в нормальных конторах, где за самоуправство полагаются санкции, и при развороте любой неутверждённой фичи она сразу же откатывается.
Но, видимо, по логике Гугла в браузерной войне любые средства хороши, а запас репутации у них бесконечный, можно и не только не извиняться, но и наоборот, развивать наступление.
Очень удручают такие истории.
То есть, если «чужая» сборка хромиума — то фиг вам, а не гугловые сервисы. В западной прессе вовремя заметили, не успели эту хрень на все развернуть. Но сам факт более чем некрасивый.
Мне в целом всё равно, какими цветами, лишь бы разными. Я даже никогда не менял тему с умолчальной ни в одном IDE, только шрифт покрупнее ставлю.
А основная странность — в том, что заняться этим они решили только сейчас. Обычно к автоматизации peer review приходят ещё в течение первого года, когда команда вырастает до ~15 человек, и надо выстраивать процессы, чтобы завалов с PR не было. Тут же явно припозднились, яндекс-деньги сколько уже существуют?
Но так-то я рад за них. Лучше иметь хорошие процесссы поздно, чем никогда.
Вам запрещено брать чужой опыт, и поэтому вы вынуждены додумываться до best practices самостоятельно? Это очень странно.
Вот, нашёл этот твит — twitter.com/TheLarkInn/status/1115317993691418624
Для вывода всего 75 штук Iridium NEXT SpaceX потребовалось около двух лет, а в этих проектах тысячи спутников. Даже если они маленькие, и за раз по 30 штук, всё равно объём пусков поражает воображение, потребуется несколько сотен за относительно короткое время. Я пока не видел информации по подготовке инфраструктуры, тех же пусковых площадок и цехов обслуживания ракет явно недостаточно.
Казалось бы, такими темпами скоро каждому провайдеру действительно придётся заводить отдел по отлову и утилизации обломков, но на самом деле все эти проекты двигаются как-то уж очень медленно.