Непонятно про deployment… В случае Java/.Net всё можно свести к схеме: копируем бинарники в новую папку, далее меняем конфиг сервера, чтобы смотрел уже в новое место. А как в Go? Там получается проще, чем копирование файлов?
Корпорациям часто требуется решение, которое удовлетворяет следующим пунктам:
1. Поддержка (дали монету — починили багу)
2. Возможность смены вендора (например, для Java, если Oracle откажется от поддержки, можно работать с IBM, похожее с базами данных, хоть и не настолько легко, для .Net есть открытый CoreCLR, а также Mono).
3. Зрелость (присутсвие языка на рынке N лет, наличие библиотек)
4. Наличие опытных разработчиков (причем как с опытом в этом решении, так и с опытом работы в предметной области)
5. Наличие формальных преимуществ, по сравнению с используемыми решениями.
У Go есть проблема с пунктом 5 (ибо обещанной производительности нет, всё на уровне java, которая на уровне .Net, кроме математики, которую сейчас логичнее делать на GPU и OpenCL, который может дать ускорение на порядки). Упрощение по сравнению с С тоже сомнительное, ибо под старичка есть море компиляторов, а если нужен GC, то подойдет и Java Card, .Net Micro Framework и еще куча известных технологий.
Со зрелостью тоже вопрос, однако маркетологи стараются это скрыть (ну в стиле гугла, хром предлагался и при установке флеша, и реклама на телевизоре была).
С четвертым пунктом тоже засада, ибо под более популярные языки уж слишком большой рынок разработчиков.
Потому и получается, что несмотря на попытки гугла войти в Enterprise Development, все пока неудачно…
Я больше поверю в разгильдяйство в органах и коррупцию, чем в то, что они стараются всеми силами нас защитить.
Например, я думаю, ты сразу ответишь, какие возможности для преступников дает обязательная сертификация ПО (ну там фстеками разными и пр.). И ведь она используется.
Как у Oracle? Если кратко: в свое время была разработана технология, позволяющая минимально использовать посредников между базой данных и браузером. Не особо взлетело, однако идея интересная.
А по факту: добавление JSON является очередным давлением на конкурентов: как на хранилища без схемы, так и на PosrgeSQL, который всё это уже умеет.
Народ пересылает ДСП информацию через инструменты, не предназначенные для ДСП. Если инструменты поменяются (хотя тоже будут не сертфицированные), то что улучшится?
При этом вы получаете:
1. Более простой код подписки/отписки (например, насколько легко отписаться от всех event'ов сейчас? Модель может это сделать сама, или только ждать, пока UI это произведет? А а RX от подписки может отказаться и слушатель, и publisher)
2. Возможность разделения канала и способа аггрегации: т.е. по одному пути идут изменения (+ фильтры и т.д.), а в совсем других методах вы описываете, как аггрегировать.
3. Есть уже некоторые готовые аггрегации, такие как сумма, максимум и пр.
Не понимаю… Зачем приводить командные строки? Допустим, у нас проектов 50. В 30 их них есть пакет А. В 20 нет. И также допустим, что мы хотим начать использовать какой-то интерфейс из пакета А в одном из 20 проектов. В случае, когда нет ошибок программиста, надо всегда подумать и подключить dll правильно, с помощью командной строки: Install-Package для nuget или packet для другого пакетного менеджера. Это будет правильно, спору нет. Я же показываю ситуацию, когда dll подключена в обход менеджера пакетов, т.е. ошибка программиста. В случае SolutionCop система автоматом поймает такую ситуацию. А как ты рассказываешь, что надо опять человеку подстраховать (ага, в век автоматизации).
Почему при отсутствии файлов проект вообще прошел тесты и запустился на CI сервере.
В проекте, допустим, 300 файлов. После неправильного мержа пропало около 200. Так как это unit тесты, на них никто особо не ссылается, а значит в результате пропажа не видна после прогона тестов. merge проходит мимо code review, а потому получаем вот такую штуку. И как ПМ должен был не пропустить? Проверять каждый merge?
Хмм… У меня в статье речь не о том, чтобы сменить пакетный менеджер, а о том, чтобы проверять ряд вещей, где проверки nuget конфигурация — это просто пара пунктов. Ведь твой тул не сможет проверить, что, например, все файлы на диске включены в проект, верно?
Про замену nuget — ок, я не исследовал этот вопрос.
Почему? Дорогу своим разработкам, дают рабочие места и т.д. Это логично для новых технологий, когда еще нигде в мире они не завелись. Иначе же получится, что Япония будет спонсировать другие государства. Другой вопрос, если бы роботакси массово (!) ездили в других странах. Тогда, скорее всего, логичнее было бы переводить не разработки, а промышленность (с помощью пошлин заставлять собирать локально), а потом уже постараться субсидиями создать и своих разработчиков.
Тут вопрос к компетентности админов, а также тех, кто их нанимает и проверяет.
Если ПО работает с БД, то наличие сети в любом случае необходимо, а это, по-моему, означает, что проще разместить такое ПО на серверах и управлять в одной точке, а не носиться по пользователям.
Админы на предприятии не способны настраивать GPO?
появилась проблема с клиентом Oracle, которая возникла из-за того, что кто-то «просто поставил инсталлятором всё необходимое» забив на то, что кто-то другой сделал своим инсталятором то же самое, но несколько раньше.
Админ всё ставит в одну папку, смешивая dll-ки? И не проверяя результат?
Я не против десктопных приложений. Я против «безумных» авторов, которые считают, что только их программа написана правильно и не учитывают очень большого количества нюансов (например, упоминаемые уже ранее завышенные полномочия пользователя)
Тут проблема в том, что разработчики не разбираются в безопасности, при разработке ПО. Однако в случае Web об этом все узнают слишком поздно :-)
В смысле? Так уж сложилось, что есть престижные вещи, которые не должны стоить дешево, иначе теряется призрак элитарности. Потому и есть золотые телефоны, часики Apple за $15к и т.д. Ведь основная суть — это показать обществу, что вы, как минимум, обращались с деньгами определенного порядка, а значит с вами можно говорить на более-менее «дорогие» темы.
1. Поддержка (дали монету — починили багу)
2. Возможность смены вендора (например, для Java, если Oracle откажется от поддержки, можно работать с IBM, похожее с базами данных, хоть и не настолько легко, для .Net есть открытый CoreCLR, а также Mono).
3. Зрелость (присутсвие языка на рынке N лет, наличие библиотек)
4. Наличие опытных разработчиков (причем как с опытом в этом решении, так и с опытом работы в предметной области)
5. Наличие формальных преимуществ, по сравнению с используемыми решениями.
У Go есть проблема с пунктом 5 (ибо обещанной производительности нет, всё на уровне java, которая на уровне .Net, кроме математики, которую сейчас логичнее делать на GPU и OpenCL, который может дать ускорение на порядки). Упрощение по сравнению с С тоже сомнительное, ибо под старичка есть море компиляторов, а если нужен GC, то подойдет и Java Card, .Net Micro Framework и еще куча известных технологий.
Со зрелостью тоже вопрос, однако маркетологи стараются это скрыть (ну в стиле гугла, хром предлагался и при установке флеша, и реклама на телевизоре была).
С четвертым пунктом тоже засада, ибо под более популярные языки уж слишком большой рынок разработчиков.
Потому и получается, что несмотря на попытки гугла войти в Enterprise Development, все пока неудачно…
Например, я думаю, ты сразу ответишь, какие возможности для преступников дает обязательная сертификация ПО (ну там фстеками разными и пр.). И ведь она используется.
То есть нет фактов, что использовались телеграмы всякие, верно?
А по факту: добавление JSON является очередным давлением на конкурентов: как на хранилища без схемы, так и на PosrgeSQL, который всё это уже умеет.
См, например, stackoverflow.
При этом вы получаете:
1. Более простой код подписки/отписки (например, насколько легко отписаться от всех event'ов сейчас? Модель может это сделать сама, или только ждать, пока UI это произведет? А а RX от подписки может отказаться и слушатель, и publisher)
2. Возможность разделения канала и способа аггрегации: т.е. по одному пути идут изменения (+ фильтры и т.д.), а в совсем других методах вы описываете, как аггрегировать.
3. Есть уже некоторые готовые аггрегации, такие как сумма, максимум и пр.
В проекте, допустим, 300 файлов. После неправильного мержа пропало около 200. Так как это unit тесты, на них никто особо не ссылается, а значит в результате пропажа не видна после прогона тестов. merge проходит мимо code review, а потому получаем вот такую штуку. И как ПМ должен был не пропустить? Проверять каждый merge?
Про замену nuget — ок, я не исследовал этот вопрос.
А как ты хотел иначе? )))
Админы на предприятии не способны настраивать GPO?
Админ всё ставит в одну папку, смешивая dll-ки? И не проверяя результат?
Тут проблема в том, что разработчики не разбираются в безопасности, при разработке ПО. Однако в случае Web об этом все узнают слишком поздно :-)