Если команда более-менее ровная по уровню квалификации и квалификация достаточно высокая, то ваш Серега поступал правильно. Он доверял разработчикам и защищал их от внешних воздействий. Результат очевидный. Андрей, судя по всему, перфекционист без меры. С командой из слабых разработчиков это в общем-то и неплохо. Без дубины тут порой не обойтись. Но с сильными разработчиками это метод работает плохо. Они, как говорится, и сами с усами. Да, можно и нужно поправить, обсудить, убедить в конце-концов, но ломать через коленку и принуждать делать исключительно так, а не иначе - рано или поздно приводит к выгоранию, раздражению и уходу
Слушайте, ну скучно. Конспект для себя самого? Лучше уж сразу найти "Рассказы о множествах" Виленкина, а еще лучше "Вычислимость и логика" Булоса и Джеффри.
что тут имеется в виду? опять БЛ в хранимках/функциях/триггерах?
Почему "опять"? Никуда этот подход не делся. Те, кто с этого начинал - так и продолжают. У кого есть время, ресурсы, финансовая подушка да и просто желание это переделывать? Работает же и свою копеечку приносит. В новых продуктах продолжают идти той же протоптанной дорожкой
Если они используют стандартные xsd из ISO-20022, то на входе и выходе уже не некий xml, а вполне себе международный формат обмена финсообщениями. Например ЦБ РФ их опубликовал. Если не ошибаюсь, с 2018 этот формат продвигают. Дальше пилотных проектов дело, вроде, еще не дошло, но в узких кругах ходят упорные слухи, что ЦБ таки наклонит банки на них переходить. Посмотрим... В отличие от расхристанного SWIFT-а, эти xml хотя бы парсятся по людски, не через известный проход )
Ничего нового. SWIFT не пинал только ленивый. И медленный, и страшный (в последнем не трудно убедиться, почитав толстенные талмуды со спецификациями сообщений). И древний. Но он работает. Уже полвека. Не быстро, но надежно. На его использование "заточено" просто чудовищное количество софта. Несколько раз предлагались его замены, разрабатывались международные стандарты (например, ISO-20022). Чтобы его заменить, мало хотеть. Надо предложить такую замену, которая позволила бы с минимальными затратами отказаться от SWIFT-а, не теряя надежности (речь ведь идет об активах - и не только, кстати о деньгах - на немеряные триллионы). Нужно внести изменения в законодательство. Переписать кучу софта, выстроить инфраструктуру зачетов и клирингов, обеспечить безопасность.
Пытайтесь, конечно, но помните, что финансы весьма консервативная сфера, любит тишину, предсказуемость, доверие участников.
И, к слову, внутри страны банки обычно SWIFT не используют и платежи идут весьма и весьма быстро. С использованием почему-то критикуемых вами коррсчетов. И это работает. Без бантиков, погремушек, скромненько так, но работает ) Четко, предсказуемо, быстро. Может быть, именно ваш банк позволяет себе подзадерживать платежи из-за чего у вас такое предубеждение? Но 20 минут на перевод из Москвы во Владивосток - реальность. Да, это стоит чуточку дороже, но если кому-то очень надо, то пожалуйста. А так списание из банка А и зачисление в банк Б происходит в течение пары-тройки часов.
По результатам наблюдений, проводившихся независимыми коллективами и частными лицами в разных частях света на протяжении около 4 тысяч лет, было твердо установлено, что отношение длины окружности бревна к его диаметру немногим больше числа 3. Исключений не обнаружено.
Уж простите меня, шалуна, но в связи с этим вашим описанием вспомнился бородатый анекдот: "Самая приятная болезнь - чесотка: почесал и еще хочется". Этак можно проверять и перепроверять до бесконечности. Зато все при деле)
Я чёт не понял. Вот нужна в проекте Kafka, допустим. Нормальное требование? Я включаю в maven/gradle зависимость и больше не парюсь - из maven central все, что нужно подтягивается. Вы предлагаете форкнуть ту же Kafka в свой бронированный репозиторий и уже юзать его? А если нужна другая версия той же Kafka? Опять форкать? Аналогично с другими зависимостями. Рано или поздно (точнее - весьма быстро) между оригиналом на maven central и вашим репозиторием появятся расхождения и вполне вероятно - не совместимые. Где быстрее и качественнее будут сделаны доработки, закрыты дыры и выполнено тестирование - у вас или на maven central? Что делать? Безопасникам нечем заняться, что-ли? Или продолжать делать вид, что ничего не происходит, все абсолютно стабильно?
В незапамятные уже времена в библиотечке "Квант" была опубликована совершенно улетная книга "Природа магнетизма" (авторы Каганов и Цукерник). Книгу несколько раз переиздавали, но легко найти pdf. Как раз по теме статьи: магнитные монополи и все такое. Не скажу, что совсем уж элементарная, но вполне доступная. Помню, на меня она произвела сильное впечатление. Рекомендую
Семь крупнейших игроков в сфере искусственного интеллекта - Nvidia, Microsoft, Apple, Amazon, Alphabet и Tesla - сегодня составляют 35% всего индекса S&P
Юниксы распространялись с исходными кодами на лентах. Деньги брались только за ленты и пересылку (и, согласитесь, это оправданно и приносило нуль доходов). Исходники шли бесплатно. Просто люди были другими.
Не думаю. Ни Пайк, ни Керниган, ни Ритчи, ни Томпсон (навскидку - это те, кто замутил С и сделал так, что он и его "родственники" вроде С++ стали основой операционных систем, баз данных, графики, драйверов и т.д.) никогда не требовали компенсации за свои труды. Думаю, Пайку неприятно, что деляги (пусть и талантливые) вроде Альтмана и других фактически тырят из кодовых баз решения, алгоритмы, экспертизу, палят тучу энергии и пытаются из этого извлечь выгоду. Ни Пайк, ни Ритчи не монетизировали по-настоящему своих находок. Максимум - гонорары за книги и лекции.
Однако, проект Go, что ни говори, вполне удачен. Я лично не адепт языка, но не могу не признать очевидного ) Кому не нравится - не используйте или предложите лучшее. Желательно конструктивно, без обычной в таких случаях holy war. С удовольствием почитаю. Всех с наступающим!!!
Во припекло чувака :) Хотя многое по делу
Если команда более-менее ровная по уровню квалификации и квалификация достаточно высокая, то ваш Серега поступал правильно. Он доверял разработчикам и защищал их от внешних воздействий. Результат очевидный. Андрей, судя по всему, перфекционист без меры. С командой из слабых разработчиков это в общем-то и неплохо. Без дубины тут порой не обойтись. Но с сильными разработчиками это метод работает плохо. Они, как говорится, и сами с усами. Да, можно и нужно поправить, обсудить, убедить в конце-концов, но ломать через коленку и принуждать делать исключительно так, а не иначе - рано или поздно приводит к выгоранию, раздражению и уходу
Интересно. Жду продолжения. О PDP-5 и PDP-8 будет?
Слушайте, ну скучно. Конспект для себя самого? Лучше уж сразу найти "Рассказы о множествах" Виленкина, а еще лучше "Вычислимость и логика" Булоса и Джеффри.
Почему "опять"? Никуда этот подход не делся. Те, кто с этого начинал - так и продолжают. У кого есть время, ресурсы, финансовая подушка да и просто желание это переделывать? Работает же и свою копеечку приносит. В новых продуктах продолжают идти той же протоптанной дорожкой
Не поздновато-ли?
Если они используют стандартные xsd из ISO-20022, то на входе и выходе уже не некий xml, а вполне себе международный формат обмена финсообщениями. Например ЦБ РФ их опубликовал. Если не ошибаюсь, с 2018 этот формат продвигают. Дальше пилотных проектов дело, вроде, еще не дошло, но в узких кругах ходят упорные слухи, что ЦБ таки наклонит банки на них переходить. Посмотрим... В отличие от расхристанного SWIFT-а, эти xml хотя бы парсятся по людски, не через известный проход )
Ничего нового. SWIFT не пинал только ленивый. И медленный, и страшный (в последнем не трудно убедиться, почитав толстенные талмуды со спецификациями сообщений). И древний. Но он работает. Уже полвека. Не быстро, но надежно. На его использование "заточено" просто чудовищное количество софта. Несколько раз предлагались его замены, разрабатывались международные стандарты (например, ISO-20022). Чтобы его заменить, мало хотеть. Надо предложить такую замену, которая позволила бы с минимальными затратами отказаться от SWIFT-а, не теряя надежности (речь ведь идет об активах - и не только, кстати о деньгах - на немеряные триллионы). Нужно внести изменения в законодательство. Переписать кучу софта, выстроить инфраструктуру зачетов и клирингов, обеспечить безопасность.
Пытайтесь, конечно, но помните, что финансы весьма консервативная сфера, любит тишину, предсказуемость, доверие участников.
И, к слову, внутри страны банки обычно SWIFT не используют и платежи идут весьма и весьма быстро. С использованием почему-то критикуемых вами коррсчетов. И это работает. Без бантиков, погремушек, скромненько так, но работает ) Четко, предсказуемо, быстро. Может быть, именно ваш банк позволяет себе подзадерживать платежи из-за чего у вас такое предубеждение? Но 20 минут на перевод из Москвы во Владивосток - реальность. Да, это стоит чуточку дороже, но если кому-то очень надо, то пожалуйста. А так списание из банка А и зачисление в банк Б происходит в течение пары-тройки часов.
По результатам наблюдений, проводившихся независимыми коллективами и частными лицами в разных частях света на протяжении около 4 тысяч лет, было твердо установлено, что отношение длины окружности бревна к его диаметру немногим больше числа 3. Исключений не обнаружено.
Что-то непонятненько... В заголовке "Зарплаты стажеров взлетели", в тесте "ожидания". Таки взлетели или нет?
Уж не скажу, что прямо по теме, но что-то в этом есть: https://www.youtube.com/watch?v=AWijE4ZI--4
Уж простите меня, шалуна, но в связи с этим вашим описанием вспомнился бородатый анекдот: "Самая приятная болезнь - чесотка: почесал и еще хочется". Этак можно проверять и перепроверять до бесконечности. Зато все при деле)
Я чёт не понял. Вот нужна в проекте Kafka, допустим. Нормальное требование? Я включаю в maven/gradle зависимость и больше не парюсь - из maven central все, что нужно подтягивается. Вы предлагаете форкнуть ту же Kafka в свой бронированный репозиторий и уже юзать его? А если нужна другая версия той же Kafka? Опять форкать? Аналогично с другими зависимостями. Рано или поздно (точнее - весьма быстро) между оригиналом на maven central и вашим репозиторием появятся расхождения и вполне вероятно - не совместимые. Где быстрее и качественнее будут сделаны доработки, закрыты дыры и выполнено тестирование - у вас или на maven central? Что делать? Безопасникам нечем заняться, что-ли? Или продолжать делать вид, что ничего не происходит, все абсолютно стабильно?
В незапамятные уже времена в библиотечке "Квант" была опубликована совершенно улетная книга "Природа магнетизма" (авторы Каганов и Цукерник). Книгу несколько раз переиздавали, но легко найти pdf. Как раз по теме статьи: магнитные монополи и все такое. Не скажу, что совсем уж элементарная, но вполне доступная. Помню, на меня она произвела сильное впечатление. Рекомендую
Если (не дай бог, конечно) дело дойдет до операции, большинство предпочтет искусного врача, нежели ремесленника от нейрохирургии. Или нет? )))
Вижу шесть. Кто седьмой?
Юниксы распространялись с исходными кодами на лентах. Деньги брались только за ленты и пересылку (и, согласитесь, это оправданно и приносило нуль доходов). Исходники шли бесплатно. Просто люди были другими.
Не думаю. Ни Пайк, ни Керниган, ни Ритчи, ни Томпсон (навскидку - это те, кто замутил С и сделал так, что он и его "родственники" вроде С++ стали основой операционных систем, баз данных, графики, драйверов и т.д.) никогда не требовали компенсации за свои труды. Думаю, Пайку неприятно, что деляги (пусть и талантливые) вроде Альтмана и других фактически тырят из кодовых баз решения, алгоритмы, экспертизу, палят тучу энергии и пытаются из этого извлечь выгоду. Ни Пайк, ни Ритчи не монетизировали по-настоящему своих находок. Максимум - гонорары за книги и лекции.
И какими вам видятся эти самые будущие нормальные языки? Я без иронии, если что. Действительно - интересно
Однако, проект Go, что ни говори, вполне удачен. Я лично не адепт языка, но не могу не признать очевидного ) Кому не нравится - не используйте или предложите лучшее. Желательно конструктивно, без обычной в таких случаях holy war. С удовольствием почитаю. Всех с наступающим!!!