А чем https://dbeaver.io/ не угодил? Бесплатная коммьюнити-версия закрывает практически все ежедневные потребности. Из коробки - поддержка кучи распространенных БД. Визуализация связей тоже есть. Перечислять всех возможностей не стану - попробуйте сами (может быть, потребуется установить java, хотя последние версии дистрибутива вроде как этого не требуют; этого я не проверял). А так - я не против: все жанры хороши. Хочется самому сделать - очень хорошо. Но не надо только говорить, что на рынке нет ничего подходящего: все есть.
Хуже того - еще и начнут искать способ избавиться от такого разработчика. Не везде и не всегда, но случается. Со мной, к примеру, такое было. Даже обозвали "саботажником" ))). Расстался с легким сердцем
Ну ладно, программисты в обычном понимании станут вымываться из процесса. Несомненно появятся инструменты верификации кода, написанного ИИ. Вопрос первый: кто напишет эти инструменты? Тот же ИИ? Волк будет служить сторожем в овчарне и охранять овец от самого себя? Вопрос второй: программисты - ладно, они все-таки (пусть не все) как-то перестроятся на новые форматы работы. А что делать продакт-менеджерам, аджайл-кришнаитам и вообще - всей той обвязке, что существует (пока) в разработке ПО? Я, к слову, из программистов, так что вроде как проблемы индейцев шерифа волновать не должны, но все-таки любопытно )))
Все это прекрасно иллюстрирует отсутствие интеллекта у этих ИИ-ассистентов: в топку, если нет наработанной кодовой базы, нет устоявшихся идиом, нет достаточного количества проектов, нет механизма понимания (которого, впрочем, и без того не было). Проще говоря - неоткуда тырить. А человек может руководствоваться просто эстетическими мотивами (прикольно/интересно/необычно/оригинально) и поэтому готов потратить время и усилия на что-то новое, малоизвестное. ИИ-ассистенты такой способности лишены.
Позиция работодателя понятна и очевидна: лучше организовать и возглавить сверху, не дожидаясь самоорганизации снизу. Старый, надежный (до определенных пределов) метод
Если команда более-менее ровная по уровню квалификации и квалификация достаточно высокая, то ваш Серега поступал правильно. Он доверял разработчикам и защищал их от внешних воздействий. Результат очевидный. Андрей, судя по всему, перфекционист без меры. С командой из слабых разработчиков это в общем-то и неплохо. Без дубины тут порой не обойтись. Но с сильными разработчиками это метод работает плохо. Они, как говорится, и сами с усами. Да, можно и нужно поправить, обсудить, убедить в конце-концов, но ломать через коленку и принуждать делать исключительно так, а не иначе - рано или поздно приводит к выгоранию, раздражению и уходу
Слушайте, ну скучно. Конспект для себя самого? Лучше уж сразу найти "Рассказы о множествах" Виленкина, а еще лучше "Вычислимость и логика" Булоса и Джеффри.
что тут имеется в виду? опять БЛ в хранимках/функциях/триггерах?
Почему "опять"? Никуда этот подход не делся. Те, кто с этого начинал - так и продолжают. У кого есть время, ресурсы, финансовая подушка да и просто желание это переделывать? Работает же и свою копеечку приносит. В новых продуктах продолжают идти той же протоптанной дорожкой
Если они используют стандартные 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. Как раз по теме статьи: магнитные монополи и все такое. Не скажу, что совсем уж элементарная, но вполне доступная. Помню, на меня она произвела сильное впечатление. Рекомендую
Или, как вариант, "пи..ец, приехали"
А чем https://dbeaver.io/ не угодил? Бесплатная коммьюнити-версия закрывает практически все ежедневные потребности. Из коробки - поддержка кучи распространенных БД. Визуализация связей тоже есть. Перечислять всех возможностей не стану - попробуйте сами (может быть, потребуется установить java, хотя последние версии дистрибутива вроде как этого не требуют; этого я не проверял). А так - я не против: все жанры хороши. Хочется самому сделать - очень хорошо. Но не надо только говорить, что на рынке нет ничего подходящего: все есть.
Хуже того - еще и начнут искать способ избавиться от такого разработчика. Не везде и не всегда, но случается. Со мной, к примеру, такое было. Даже обозвали "саботажником" ))). Расстался с легким сердцем
Ну ладно, программисты в обычном понимании станут вымываться из процесса. Несомненно появятся инструменты верификации кода, написанного ИИ. Вопрос первый: кто напишет эти инструменты? Тот же ИИ? Волк будет служить сторожем в овчарне и охранять овец от самого себя? Вопрос второй: программисты - ладно, они все-таки (пусть не все) как-то перестроятся на новые форматы работы. А что делать продакт-менеджерам, аджайл-кришнаитам и вообще - всей той обвязке, что существует (пока) в разработке ПО? Я, к слову, из программистов, так что вроде как проблемы индейцев шерифа волновать не должны, но все-таки любопытно )))
Все это прекрасно иллюстрирует отсутствие интеллекта у этих ИИ-ассистентов: в топку, если нет наработанной кодовой базы, нет устоявшихся идиом, нет достаточного количества проектов, нет механизма понимания (которого, впрочем, и без того не было). Проще говоря - неоткуда тырить. А человек может руководствоваться просто эстетическими мотивами (прикольно/интересно/необычно/оригинально) и поэтому готов потратить время и усилия на что-то новое, малоизвестное. ИИ-ассистенты такой способности лишены.
Позиция работодателя понятна и очевидна: лучше организовать и возглавить сверху, не дожидаясь самоорганизации снизу. Старый, надежный (до определенных пределов) метод
Во припекло чувака :) Хотя многое по делу
Если команда более-менее ровная по уровню квалификации и квалификация достаточно высокая, то ваш Серега поступал правильно. Он доверял разработчикам и защищал их от внешних воздействий. Результат очевидный. Андрей, судя по всему, перфекционист без меры. С командой из слабых разработчиков это в общем-то и неплохо. Без дубины тут порой не обойтись. Но с сильными разработчиками это метод работает плохо. Они, как говорится, и сами с усами. Да, можно и нужно поправить, обсудить, убедить в конце-концов, но ломать через коленку и принуждать делать исключительно так, а не иначе - рано или поздно приводит к выгоранию, раздражению и уходу
Интересно. Жду продолжения. О 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. Как раз по теме статьи: магнитные монополи и все такое. Не скажу, что совсем уж элементарная, но вполне доступная. Помню, на меня она произвела сильное впечатление. Рекомендую