Комментарии 103
НЛО прилетело и опубликовало эту надпись здесь
Дело не совсем в зеленой или забористой траве раньше.
Вот инструменты разработки за 15 лет качественно выросли. Как человек который писал немного в Visual Studio 6.0 могу точно это сказать. Равно как и Entity Framework это небо и земля по сравнению с удобством мапинга сущностей через SqlCommand ExecuteReader.
Однако все это не привело к качественному улучшению разрабатываемого софта. Понятно, что лишние абстракции негативно влияют на перформанс, но тогда количество новых удобных фич должно расти?
Но нет, фич особо больше не становится, тормоза растут (отдельное спасибо электрону!), затраты на разработку растут.
Кстати, забыл написать, что спасибо ФААНГу нужно говорить не только за стартапоподобный подход с работой на помойку, но еще и росту зарплат. Выкупая с рынка десятки тысяч инженеров за большую зарплату это драйвит вектор зарплаты вверх. А страдают за это пользователи поиска, контекстной рекламы и ютьюба.
Вот инструменты разработки за 15 лет качественно выросли. Как человек который писал немного в Visual Studio 6.0 могу точно это сказать. Равно как и Entity Framework это небо и земля по сравнению с удобством мапинга сущностей через SqlCommand ExecuteReader.
Однако все это не привело к качественному улучшению разрабатываемого софта. Понятно, что лишние абстракции негативно влияют на перформанс, но тогда количество новых удобных фич должно расти?
Но нет, фич особо больше не становится, тормоза растут (отдельное спасибо электрону!), затраты на разработку растут.
Кстати, забыл написать, что спасибо ФААНГу нужно говорить не только за стартапоподобный подход с работой на помойку, но еще и росту зарплат. Выкупая с рынка десятки тысяч инженеров за большую зарплату это драйвит вектор зарплаты вверх. А страдают за это пользователи поиска, контекстной рекламы и ютьюба.
Самая большая проблема — «закон Мёрфи Вирта».
Когда-то наш преподаватель по «методам оптимизации» вещал, что оптимизация бывает или по скорости или по памяти. Про оптимизацию по скорости разработки тогда никто не знал…
Когда-то наш преподаватель по «методам оптимизации» вещал, что оптимизация бывает или по скорости или по памяти. Про оптимизацию по скорости разработки тогда никто не знал…
Ну как это не привело к качественному улучшению, мы пилим сейчас crm, ее сложность, функционал, юзабилити порядком выше аналогичных решений которые были 10-20 лет назад. И задачи которые на нее возложены тоже более емкие. В общем по многим показателям прогресс не стоит на месте.
Но какие-то банальные вещи, типа «напечатать заявление на отпуск», почти невозможны без 8Гб памяти.
Можно и обратное сказать, в «новых» CRM типа АМО и Битрикс24 функционал на порядок меньше, чем например в нашей CRM, заложенной 10-20 лет назад, тут как посчитать
Скажите пожалуйста, когда появился SAP?
У вас сложность и функционал больше сапа? Задачи вы решаете более емкие?
У вас сложность и функционал больше сапа? Задачи вы решаете более емкие?
Вот инструменты разработки за 15 лет качественно выросли. Как человек который писал немного в Visual Studio 6.0 могу точно это сказать.А я, как человек, который писал на Delphi, изрядно сомневаюсь в этом росте. Ничего хотя бы сравнимого по удобству с древней компонентной IDE от Inprise так и не появилось. И, что интересно, там всё работало из коробки без каких-то дополнительных настроек и 100500 плагинов, а на выходе получались довольно компактные программки (от 200Кб) без каких-либо дополнительных зависимостей. К которым не нужно было прилагать десятки метров фреймворка и UI которых отрисовывался молниеносно, без подлагиваний, даже на Pentium-100.
удачи дебажить многопоточные приложения в 15 летних IDE
Я бы даже сказал, что всё стало хуже, потому что если на дельфи было писать просто, то на всех современных языках писать сложно.
Есть мнение, что индустрию специально пустили по пути «машинного усложнения», чтобы остановить свободный приток профанов — а то когда каждая кухарка может написать себе приложение, индустрия почти и не нужна.
Есть мнение, что индустрию специально пустили по пути «машинного усложнения», чтобы остановить свободный приток профанов — а то когда каждая кухарка может написать себе приложение, индустрия почти и не нужна.
Да какая кухарка, во времена расцвета Delphi средняя кухарка не знала, с какой стороны у компьютера находится выключатель.
если на дельфи было писать просто, то на всех современных языках писать сложно.
Я не могу сказать за конкретно дельфи, но в сравнении с технологиями, которые лично мне были доступны в районе, скажем, 90-ых (Basic, C++/MFC, VBA, VB, JavaScript, ASP), нынешние технологии выглядят не сложнее, а зачастую и проще.
Ну, не знаю, не знаю. Лично для меня стиль написания программ в современном .NET (в частности — исходника ASP.NET Core) — с цепочками вызовов нескольких методов подряд через точку (да еще и со сменой типа объекта в процессе (как, например при конфигурировании Options IServiceCollection где-то в середине цепочке легким движением руки превращается в OptionsBuilder), кучей лямбд (причем — не просто коротких типа параметр=>результат, а лямбд с фигурными скобками или лямбд внути лямбд), и широким использованием возможностей скрывать типы используемых переменных (var, параметры лямбда-функции) — выглядит сильно сложнее, чем стиль того же .NET, применявшийся 10 лет назад. По крайней мере, исходные текты от MS мне стало читать заметно сложнее.
PS Пардон, первый вариант был ответом не вам, я перемстил его в нужное место.
PS Пардон, первый вариант был ответом не вам, я перемстил его в нужное место.
Вас же никто не заставляет писать ни на современном .net, ни, если на нем, то в таком стиле.
При этом, внезапно, это все равно проще в понимании и отладке, чем попытка отладить ASP.NET на IIS Integrated, с его событиями, переходами в unmanaged, и прочими прекрасными веселухами. У меня они рядом, поэтому я это хорошо вижу. Рассуждать о поведении ASP.NET Core намного, намного проще, чем о поведении ванильного ASP.NET.
Писать никто не заставляет — но читать-то приходится.
Ну, а проще или нет — это субъективно (см. мой комментарий ниже).
Тем более, что мне прежде всего требуется понимание — надеюсь, код библиотеки уже отладили, без меня ;-)
А что до отладки, то лично я в давние времена привык к тому, что есть закрытый код, исходники которого просто недоступны. Например — системные вызовы Windows, да и код IIS — тоже. Поэтому выработал способы борьбы, работающие и в этих условиях (при наличии хорошей документации, конечно): проверка параметров перед вызвовом закрытого кода и сравнение результата с ожидаемым, установка точек останова на любой свой код функции обратного вызова и т.д.
Однако для этого требуется хорошая документация. И у MS она тогда уже была. Но это все — чисто мои привычки.
Но в некие совсем уж древние времена (Windows то ли 3.0, то ли 3.1) с документацией от MS было сложнее (по крайнейе мере, в России), так что даже как-то пришлось в отладчике смотреть, как именно возвращаются значения из процедуры диалога в функцию его вызова: там фиксированный набор значений возващался напрямую (недокументированно), а большинство — через поле в структуре диалога (документированно).
Ну, а проще или нет — это субъективно (см. мой комментарий ниже).
Тем более, что мне прежде всего требуется понимание — надеюсь, код библиотеки уже отладили, без меня ;-)
А что до отладки, то лично я в давние времена привык к тому, что есть закрытый код, исходники которого просто недоступны. Например — системные вызовы Windows, да и код IIS — тоже. Поэтому выработал способы борьбы, работающие и в этих условиях (при наличии хорошей документации, конечно): проверка параметров перед вызвовом закрытого кода и сравнение результата с ожидаемым, установка точек останова на любой свой код функции обратного вызова и т.д.
Однако для этого требуется хорошая документация. И у MS она тогда уже была. Но это все — чисто мои привычки.
Но в некие совсем уж древние времена (Windows то ли 3.0, то ли 3.1) с документацией от MS было сложнее (по крайнейе мере, в России), так что даже как-то пришлось в отладчике смотреть, как именно возвращаются значения из процедуры диалога в функцию его вызова: там фиксированный набор значений возващался напрямую (недокументированно), а большинство — через поле в структуре диалога (документированно).
Писать никто не заставляет — но читать-то приходится.
Обычно читать надо, когда вы пишете что-то связанное.
Но не суть. Легкость чтения, как уже сказано, вещь субъективная (особенно когда вы попробуете сравнить, скажем, код с лямбдами с кодом, который делает то же самое, но без лямбд). А в общем, ваш комментарий только подтверждает тот факт, что сейчас разрабатывать-то легче: и документации больше, и кода больше открыто, и инструменты улучшились.
С документацией конкретно у MS дело однозначно ухудшилось, по сравнению с тем, что было 10-15 лет назад — но опять-таки, это мое субъективное впечатление (впрочем, если будет не лень — статью про это напишу, для обсуждения, есть такие планы). Исходный код документацию не всегда заменяет: по нему сложнее понять общую архитектуру решения, которая в хорошей документации обычно описана. У меня претензии к современной документации MS как раз больше в этом плане: детали реализации в той же ASP.NET Core, типа классов и их свойств с методами, описаны достаточно полно, а вот общая архитектура просматривается по документации плохо. Раньше, насколько я помню, с этим было лучше.
А, например, в документации по MS Exchange плохо и с полнотой описания деталей (с архитектурой там проще — она практически не меняется): например, внутри появилось некоторое количество новых сущностей, их наличие видно по структуре классов объектов, возвращаемых через PowerShell, но в документации о них ни слова. Или есть куски (похоже, перенесенные из облака), для которых описан только рецепт применения для частных случаев в ограниченном количестве.
Ну, а легкость разработки — вещь субъективная. Помню, например, по ранним 90-м, что были люди, которые предпочитали писать код по нескольку операторов в строчку, вплоть до того, что «сколько на строке уместится» (правда, обычно — все же с учетом логической связи между операторами), и им так было лучше — меньше места по вертикали занимало. Кстати, тогда это было отчасти оправданно — потому что на дисплее помещалось только 25 строчек. А сейчас такое скорее всего просто никто не потерпит.
PS Не знаю, насколько полезно именно доказывать (просто обсудить-то полезно), что писать программы стало проще или сложнее — уж больно много в этом субъективных моментов: кто на кого учился и кто к чему привык.
А, например, в документации по MS Exchange плохо и с полнотой описания деталей (с архитектурой там проще — она практически не меняется): например, внутри появилось некоторое количество новых сущностей, их наличие видно по структуре классов объектов, возвращаемых через PowerShell, но в документации о них ни слова. Или есть куски (похоже, перенесенные из облака), для которых описан только рецепт применения для частных случаев в ограниченном количестве.
Ну, а легкость разработки — вещь субъективная. Помню, например, по ранним 90-м, что были люди, которые предпочитали писать код по нескольку операторов в строчку, вплоть до того, что «сколько на строке уместится» (правда, обычно — все же с учетом логической связи между операторами), и им так было лучше — меньше места по вертикали занимало. Кстати, тогда это было отчасти оправданно — потому что на дисплее помещалось только 25 строчек. А сейчас такое скорее всего просто никто не потерпит.
PS Не знаю, насколько полезно именно доказывать (просто обсудить-то полезно), что писать программы стало проще или сложнее — уж больно много в этом субъективных моментов: кто на кого учился и кто к чему привык.
По-моему, тут существенно, для какой области предназначены эти технологии.
Delphi была, с одной сторны, очень хороша для разработки приложений для десктопа под Windows (среди перечисленных вами к этой категории отностится только VB) в том числе — и для работы с БД, причем как файловыми, так и по схеме клиент-сервер, с другой — достаточно универсальна, чтобы ее можно было использовать для разработки для платформы Windows в целом: на ней можно было делать и сетевые программы, и системные службы, и даже программы для веб-сайов под IIS — то, что ныне именуется «back end» (а вот VB такой универсальностью не обладал). Впрочем, в этих, остальных? областях Delphi, на мой субъективный взгляд, ничуть не выигрывала у того же Visual C++.
А сейчас разработка приложений для десктопа — она, мягко говоря, не сильно востребована. Впрочем, и для этой области в современных (условно) средствах разработки есть, по крайней мере, одна сравнимая альтернатива — Windows Forms в .NET.
Другое дело, что в более актуальных для современности областях разработки, таже схожего назначения — например Web, front-end PWA, решающие идейно примерно те же задачи, что и десктопные клиенты лет 20 назад — ничего подобного Delphi по простоте испоьзования («накидать компонентов на форму»)и, одновременно, универсальности лично я не знаю. Впочем, и задачи у фронт-энда — они посложнее чем в десктопной разработке 20-летней давности: тут и необходимость поддержки страниц разного размера (ведь формы — они чаще были фиксированные по размеру), и далеко не идеальная надежность канала связи, и отсутствие стандартного API для доступа к серверу, и т.д.
PS А вообще, «проще/сложнее писать» — это IMHO характеристика сильно субъективная, зависящая от пишущего, его опыта и его привычек.
Delphi была, с одной сторны, очень хороша для разработки приложений для десктопа под Windows (среди перечисленных вами к этой категории отностится только VB) в том числе — и для работы с БД, причем как файловыми, так и по схеме клиент-сервер, с другой — достаточно универсальна, чтобы ее можно было использовать для разработки для платформы Windows в целом: на ней можно было делать и сетевые программы, и системные службы, и даже программы для веб-сайов под IIS — то, что ныне именуется «back end» (а вот VB такой универсальностью не обладал). Впрочем, в этих, остальных? областях Delphi, на мой субъективный взгляд, ничуть не выигрывала у того же Visual C++.
А сейчас разработка приложений для десктопа — она, мягко говоря, не сильно востребована. Впрочем, и для этой области в современных (условно) средствах разработки есть, по крайней мере, одна сравнимая альтернатива — Windows Forms в .NET.
Другое дело, что в более актуальных для современности областях разработки, таже схожего назначения — например Web, front-end PWA, решающие идейно примерно те же задачи, что и десктопные клиенты лет 20 назад — ничего подобного Delphi по простоте испоьзования («накидать компонентов на форму»)и, одновременно, универсальности лично я не знаю. Впочем, и задачи у фронт-энда — они посложнее чем в десктопной разработке 20-летней давности: тут и необходимость поддержки страниц разного размера (ведь формы — они чаще были фиксированные по размеру), и далеко не идеальная надежность канала связи, и отсутствие стандартного API для доступа к серверу, и т.д.
PS А вообще, «проще/сложнее писать» — это IMHO характеристика сильно субъективная, зависящая от пишущего, его опыта и его привычек.
Во время расцвета Делфи (2000-2004) я наблюдал, как на нем писали. Берется форма, туда херачатся контролы, все переменные глобально, это все путается лапшой из коллбеков. Так и сейчас можно писать, и не только на Делфи, другое дело что за такое вышвырнут из профессии за шкирку.
Так ведь пишут же! Берётся node.js, через npm подтягивается 500Мб зависимостей (по компоненту на каждый чих, даже если из всего пакета нужна ровно одна функция на 5 строчек кода), всё это заворачивается в контейнер и льётся в облако (сервера давно не в моде).
А уж какая там асинхронная лапша из коллбэков при этом образуется! Delphi-кодерам такое даже не снилось.
И ничего, как-то не вышвыривают из профессии.
А уж какая там асинхронная лапша из коллбэков при этом образуется! Delphi-кодерам такое даже не снилось.
И ничего, как-то не вышвыривают из профессии.
НЛО прилетело и опубликовало эту надпись здесь
Вы удивитесь, но даже и с промисами умудряются лепить лапшу на 20 уровней вложенности.
НЛО прилетело и опубликовало эту надпись здесь
IMHO есть сильная визуальная разница между кодом на async/await и promise или его аналоге из C# Task. Код на async/await выглядит как обычный линейный (или там разветвленый — с условными операторами и циклами, так тоже нормально) код, только вот в некоторых местах он согласен подождать, а что там под капотом — это сверху не видно. А вот цепочка promise или Task'ов, объединенных ContinueWith — она для меня выглядит выглядит как «дом который построил Джек» — хоть код и синхронный, но какой-то слишком слепленный. И ещё хорошо, если этот код — линейный, без ветвлений и циклов, логика-то разная может быть.
Впрочем, кто к чему привык (мне вон во времена оны и пресловутый фортрановский код на GOTO был норм, потому что другого не было).
Впрочем, кто к чему привык (мне вон во времена оны и пресловутый фортрановский код на GOTO был норм, потому что другого не было).
А ведь и с интернетом то же самое было.
Помню, как под предлогом того, что «большие страницы размером с мегабайт это очень плохо» буквально задушили и привалили сверху камнем все визуальные редакторы, типа дримвийвера или фронтпэйджа. Хотя, опять же, каждая кухарка могла сделать свой сайт на них.
Теперь страницы весят по 50 мегабайт, и никого это не парит, но главное уже сделано — никаких общедоступных и лёгких в освоении инструментов нет, это громоздкое говнище, которое не каждый браузер ещё откроет без сбоев, делает целая команда «специалистов» с пятью разными инструментами.
Воля ваша, а я, как и с отменой Дельфи, вижу здесь только одну причину — надо было вышвырнуть с ценного рынка «профанов». А то слишком много воли взяли, эдак ему надо программу — сам напишет, надо сайт — сам нарисует, А КТО ДЕНЬГИ ПЛАТИТЬ БУДЕТ?
Теперь с деньгами проблем нет.
Помню, как под предлогом того, что «большие страницы размером с мегабайт это очень плохо» буквально задушили и привалили сверху камнем все визуальные редакторы, типа дримвийвера или фронтпэйджа. Хотя, опять же, каждая кухарка могла сделать свой сайт на них.
Теперь страницы весят по 50 мегабайт, и никого это не парит, но главное уже сделано — никаких общедоступных и лёгких в освоении инструментов нет, это громоздкое говнище, которое не каждый браузер ещё откроет без сбоев, делает целая команда «специалистов» с пятью разными инструментами.
Воля ваша, а я, как и с отменой Дельфи, вижу здесь только одну причину — надо было вышвырнуть с ценного рынка «профанов». А то слишком много воли взяли, эдак ему надо программу — сам напишет, надо сайт — сам нарисует, А КТО ДЕНЬГИ ПЛАТИТЬ БУДЕТ?
Теперь с деньгами проблем нет.
Т.е. вы не в курсе того, что есть куча готовых визуальных конструкторов для сайтов? Жена вот моя без всяких специальных навыков поддерживала сайт для места, где она работала.
Если уж вспоминать про прежние времена, то и во время появления Delphi визуальные конструкторы интерфейсов для Windows вполне себе были: PowerBuilder, например. Да и Visual Basic тогда, ЕМНИП, тоже уже появился.
Но Delhi имел над ними то преимущество, что это был универсальный язык, а потому система компонентов Delhi была расширяемой средствами самого Delphi: если не хватало возможностей готовых компонентов, можно было поднапрячься и сделать свой (да и сторонние — тоже были в ассортименте, нередко — с исходным кодом, так что под себя их подкрутить можно было, что-нибудь от чего-нибудь аккуратно унаследовав). Ну, и программы другого типа на нем писать было можно, особенно на последующих 32-битных версиях: там где я работал в начале 00-х, Delphi вполне заменял C/C++, на нем были написаны и сервисы Windows, выполнявшиеся в фоне на серверах и обеспечивавшие логику работы распределеной БД, и даже веб-сайт. То есть, выбравший Delphi не был ограничен возможностями его как чисто визуального конструктора только для десктопных интерфейсов и с предопределенным набором компонентов.
А нынешние визуальные конструкторы сайтов, о которых вы ведете речь — они AFAIK не универсальны и не слишком расширяемы. Впрочем, если у вас есть примеры обратного — сообщите: мне тоже хочется иметь в арсенале такой легко расширяемый конструктор для сайтов, каким был Delphi для Windows.
Но Delhi имел над ними то преимущество, что это был универсальный язык, а потому система компонентов Delhi была расширяемой средствами самого Delphi: если не хватало возможностей готовых компонентов, можно было поднапрячься и сделать свой (да и сторонние — тоже были в ассортименте, нередко — с исходным кодом, так что под себя их подкрутить можно было, что-нибудь от чего-нибудь аккуратно унаследовав). Ну, и программы другого типа на нем писать было можно, особенно на последующих 32-битных версиях: там где я работал в начале 00-х, Delphi вполне заменял C/C++, на нем были написаны и сервисы Windows, выполнявшиеся в фоне на серверах и обеспечивавшие логику работы распределеной БД, и даже веб-сайт. То есть, выбравший Delphi не был ограничен возможностями его как чисто визуального конструктора только для десктопных интерфейсов и с предопределенным набором компонентов.
А нынешние визуальные конструкторы сайтов, о которых вы ведете речь — они AFAIK не универсальны и не слишком расширяемы. Впрочем, если у вас есть примеры обратного — сообщите: мне тоже хочется иметь в арсенале такой легко расширяемый конструктор для сайтов, каким был Delphi для Windows.
НЛО прилетело и опубликовало эту надпись здесь
Отчасти справедливо. Ну ещё многословность — на Java например, чтобы десктопное приложение с GUI написать кода получается сильно больше в ущерб качеству.
Все так, но вот просто взять и исправить не получится, потому что в отрасли слишком много лишних людей: людей которые только делают вид что они разработчики, лиды, CTO итд. Аналатиков и проджектов тудаже, не всех конечно, но последнее время я очень часто встречаюсь с «аналитиками» которые описывают очевидные вещи канцеляритом и считают свою свободу выполненной, даже без проверки граничных условий, а уж проджекта, который реально менеджер а не «игрок в передаста» я видел последний раз лет десять назад.
ИХМО, индустрию губит переусложнение «на ровном месте». Приведу пример. Почти лет 20 назад, будучи вчерашним студентом, реализовал систему выходного контроля достаточно сложных электронных изделий. Это заняло чуть меньше года. Да, схемотехника и конструктив вели другие специалисты, но архитектура и весть программизм (от микроконтроллеров до прикручивания БД), был на мне. Несомненно, внутри — худшие практики. Но оборудование, с модификацией, проработало почти 15 лет. Смотреть на код — глаза выжигать, но работало и модернизировалось даже после моего увольнения.
Недавно прикидывал, а если бы такую систему построить на лучших современных практиках, сколько бы ушло сил? Приблизительно раз в 10 больше… А на выходе — та же система, диагностирующая произведенную продукцию, выявляющую брак и приблизительно место его локализации… И не факт, что «современную» систему было бы проще поддерживать, чем старый говнокод, который с кучей goto на C++ в вшитых тестовых сценариях…
Недавно прикидывал, а если бы такую систему построить на лучших современных практиках, сколько бы ушло сил? Приблизительно раз в 10 больше… А на выходе — та же система, диагностирующая произведенную продукцию, выявляющую брак и приблизительно место его локализации… И не факт, что «современную» систему было бы проще поддерживать, чем старый говнокод, который с кучей goto на C++ в вшитых тестовых сценариях…
Возможно, проблема в том, что многие IT компании берут пример организации рабочего процесса с Google, не придавая значения тому, что в их случае можно все сильно упростить.
Факт состоит в том, что современное IT скорее тянет на дно бизнес, чем помогает ему развиваться.
Угу. То-то я наблюдаю благодарности от клиентов, которым "современное IT" помогло работать во время локдауна.
А какие новейшие технологии используются во время локдауна? Скайп-конференции (Зум, Тимс не важно). Ах ну да, поддержка в браузере, плагин не надо ставить. Правда заплатим за это лагучим клиентом на электроне. Еще используется Cisco Anyconnect, новейшая разработка, не имеет аналогов.
Внезапно, 10 лет назад было все тоже самое, но никто почему-то не кричал, что все это спасает мир.
Внезапно, 10 лет назад было все тоже самое, но никто почему-то не кричал, что все это спасает мир.
А какие новейшие технологии используются во время локдауна?
А я где-то сказал про новейшие? Мы поставили им ПО, оно помогает им работать, не приходя в офис. ПО написано в году, предшествующем локдауну, считается за "современное".
Вы отделяетесь от темы. Какое новое ПО вы написали, которого раньше не было и которое помогает во время локдауна?
Какое новое ПО вы написали, которого раньше не было
А откуда взялось ограничение "которого раньше не было"?
Но вообще, компания, в которой я работаю, делает ERP-систему, лет десять назад этой системы не было. Эта система помогала людям во время локдауна.
лет десять назад этой системы не было
ERP-систем вообще не было или именно этой? Если именно этой, то мы возвращаемся всё к тому же вопросу и всё к той же проблеме.
ERP-систем вообще не было или именно этой?
Именно этой.
Если именно этой, то мы возвращаемся всё к тому же вопросу и всё к той же проблеме.
Так какой проблеме-то?
Вот есть реальный небольшой американский бизнес, производит/торгует каким-то power equipment. Они себе поставили наш софт, который явно относится к современному IT, и весьма довольно им пользуются. Во время локдауна они нам писали благодарственные письма, что как круто, что они могут делать часть вещей, не приходя в офис, спасибо нам.
Где проблема-то?
Проблема в том, что вы говорите, что придумали какой-то новый софт с уникальными возможностями.
Тогда как это вызывает сомнения.
Тогда как это вызывает сомнения.
Проблема в том, что вы говорите, что придумали какой-то новый софт с уникальными возможностями.
Я? Где я такое говорю? Я специально перечитал тред, я такого нигде не говорю.
Но вообще, компания, в которой я работаю, делает ERP-систему, лет десять назад этой системы не было. Эта система помогала людям во время локдауна.
Ну да, если вы просто пишете, что я пишу систему которой раньше не было. Любой системы которой пишется сейчас раньше не было. А если по факту, то все это уже существует десятки лет, просто почему-то конкретная фирма десятки лет проспала ERP.
А если по факту, то все это уже существует десятки лет, просто почему-то конкретная фирма десятки лет проспала ERP.
То, что концепция ERP существует десятки лет, никак не отменяет того, что современные ERP помогают бизнесу сейчас.
А несовременные не помогали бы?
Что такого было сделано, что условно ERP десять лет назад не могло?
Что такого было сделано, что условно ERP десять лет назад не могло?
А несовременные не помогали бы?
А вот это подмена вопроса. Вы сказали, цитирую:
современное IT скорее тянет на дно бизнес, чем помогает ему развиваться
Я оппонирую именно этому высказыванию, считая его ошибочным.
Ваше право. Я лично не особо понимаю, как конкретно SAAS решение помогает бизнесу развиваться так, как не могли бы развиваться обычные инсталляции. Да, рынок ERP был полон оборзевшими решениями по невменяемой цене, может быть вы решаете именно эту проблему.
Хотя я зашел на сайт и на страничке pricing кроме очередного маркетингово булшита опять ничего не увидел
www.acumatica.com/acumatica-pricing А меня сильно смущает, когда я не вижу цен и мне нужно контактировать с сейлзом, чтобы хоть как-то оценить SAAS решение.
Так что вменяемость цен тут тоже под вопросом. Может их бы 1С устроил бы коробочный, был бы он распространен на западе?
www.pcmag.com/reviews/acumatica
Estimating licensing costs can be difficult.
Хотя я зашел на сайт и на страничке pricing кроме очередного маркетингово булшита опять ничего не увидел
www.acumatica.com/acumatica-pricing А меня сильно смущает, когда я не вижу цен и мне нужно контактировать с сейлзом, чтобы хоть как-то оценить SAAS решение.
Так что вменяемость цен тут тоже под вопросом. Может их бы 1С устроил бы коробочный, был бы он распространен на западе?
www.pcmag.com/reviews/acumatica
Estimating licensing costs can be difficult.
Я лично не особо понимаю, как конкретно SAAS решение помогает бизнесу развиваться так, как не могли бы развиваться обычные инсталляции.
То, что вы чего-то не понимаете, не дает вам права говорить, что оно "тянет бизнес на дно".
Может их бы 1С устроил бы коробочный, был бы он распространен на западе?
Может быть и устроил бы. Вот только "коробочный 1С" — это тоже "современное IT", так что в тезисе ничего особо не меняется.
коробочный 1С
31 июля 2003 года выпущено первое тиражное решение «1С: Предприятие 8.0. Управление торговлей»
Очень современное решение.
То, что вы чего-то не понимаете, не дает вам права говорить, что оно «тянет бизнес на дно».
Не видя ценник я не могу ничего сказать про решение.
Однако то, что я видел на сайте покрывается одним www.devexpress.com/products/net/application_framework
за 2000 долларов.
31 июля 2003 года выпущено первое тиражное решение «1С: Предприятие 8.0. Управление торговлей»
Нет, это не устроит по регуляторным соображениям.
Однако то, что я видел на сайте покрывается одним www.devexpress.com/products/net/application_framework
То, что "вы видели на сайте" — возможно. То, что компания реально продает — нет, не покрывается.
Вы уверены?
github.com/eXpandFramework/eXpand
Конечно, данное решение требует пары разработчиков на постоянной основе. И, вероятно, дешевле платить за лицензию в месяц 10к долларов, чем платить им зарплату. Однако, опять таки, я прекрасно знаю, что такое SAAS.
Это вытягивание денег на постоянной основе. Хочешь плагин/адаптер — плати деньги в доп разработку/маркетплейс.
Подсади клиентов полностью в облако — выпусти новую версию. Хочешь новые фичи — плати x2.
Хочешь свалить — иди давай ищи как экспортнуть всю историю и все документы, проще уж продолжать платить.
А главное, в соглашении наверняка написано, что ответственности у компании нет никакой.
github.com/eXpandFramework/eXpand
Конечно, данное решение требует пары разработчиков на постоянной основе. И, вероятно, дешевле платить за лицензию в месяц 10к долларов, чем платить им зарплату. Однако, опять таки, я прекрасно знаю, что такое SAAS.
Это вытягивание денег на постоянной основе. Хочешь плагин/адаптер — плати деньги в доп разработку/маркетплейс.
Подсади клиентов полностью в облако — выпусти новую версию. Хочешь новые фичи — плати x2.
Хочешь свалить — иди давай ищи как экспортнуть всю историю и все документы, проще уж продолжать платить.
А главное, в соглашении наверняка написано, что ответственности у компании нет никакой.
Вы уверены?
Да, уверен.
Но, впрочем, это не важно. Не важно по двум причинам.
Во-первых, предлагаемые вами решения — тоже часть "современного IT", так что они никак не помогают подтвердить тезис "современное IT скорее тянет на дно бизнес, чем помогает ему развиваться".
А во-вторых, даже если вы найдете какое-то решение, которое решает задачи клиента лучше, чем приведенные выше, и при этом не является "современным IT" — даже этого не достаточно, чтобы сказать, что "современное IT скорее тянет на дно бизнес, чем помогает ему развиваться". Потому что чтобы "помогать развиваться", не надо "помогать развиваться" лучше всех. Достаточно просто помогать развиваться. Если решение из "современного IT" это делает — а они это делают, — ваш тезис ошибочен.
Acumatica does not warrant that the Service will be error-free.
Your sole and exclusive remedy for Acumatica’s breach of this limited warranty shall be that
Acumatica shall use commercially reasonable efforts to modify the Service to meet the
performance and functionality specifications, in all material respects, described in the most
current Documentation, and if Acumatica is unable to restore such performance and
functionality, you shall be entitled to terminate this Agreement and shall be entitled to receive a
pro-rata refund of the Subscriber Service Fees paid for under this Agreement for your use of the
Service for the terminated portion of the Term.
Acumatica warrants that Acumatica will
use commercially reasonable efforts to safeguard and accurately maintain Subscriber Data,
consistent with industry security standards and backup procedures. In the event of a breach of
this Section 6.4, Acumatica shall use commercially reasonable efforts to correct Subscriber
Data or restore Subscriber Data as quickly as possible, but in any case not to exceed three (3)
business days.
Except as provided in this Section 6, Acumatica disclaims, to the
extent authorized by law, any and all warranties…
То есть система глючит — мы приложим «сommercially reasonable efforts»
Мы просрали ваши данные — мы приложим «commercially reasonable efforts»
А все остальное мы вааще не в курсе.
Нет современно ПО конечно же драйвит бизнес.
Меня радует формулировка «commercially reasonable efforts»
Так как бабки мы уже получили, то любое действие явно не commercially reasonable. Ну а если не нравится — иди давай мигрируй нахер.
Your sole and exclusive remedy for Acumatica’s breach of this limited warranty shall be that
Acumatica shall use commercially reasonable efforts to modify the Service to meet the
performance and functionality specifications, in all material respects, described in the most
current Documentation, and if Acumatica is unable to restore such performance and
functionality, you shall be entitled to terminate this Agreement and shall be entitled to receive a
pro-rata refund of the Subscriber Service Fees paid for under this Agreement for your use of the
Service for the terminated portion of the Term.
Acumatica warrants that Acumatica will
use commercially reasonable efforts to safeguard and accurately maintain Subscriber Data,
consistent with industry security standards and backup procedures. In the event of a breach of
this Section 6.4, Acumatica shall use commercially reasonable efforts to correct Subscriber
Data or restore Subscriber Data as quickly as possible, but in any case not to exceed three (3)
business days.
Except as provided in this Section 6, Acumatica disclaims, to the
extent authorized by law, any and all warranties…
То есть система глючит — мы приложим «сommercially reasonable efforts»
Мы просрали ваши данные — мы приложим «commercially reasonable efforts»
А все остальное мы вааще не в курсе.
Нет современно ПО конечно же драйвит бизнес.
Меня радует формулировка «commercially reasonable efforts»
Так как бабки мы уже получили, то любое действие явно не commercially reasonable. Ну а если не нравится — иди давай мигрируй нахер.
И что?.. Вот вы написали кучу текста, который вам не нравится. Окей, вам не нравится, не пользуйтесь. А я ссылаюсь на кастомера, которому понравилось и помогло. Как то, что вам не нравится, отменяет его положительный опыт?
PS. Раз уж вы, не я, привели ссылку на сайт компании, то я могу себе позволить ответить цитатой оттуда же:
Acumatica’s flexibility continues with allowing you three choices in licensing the software based on your business needs.
[...]
Private Cloud Subscription (PCS) [...] An annual subscription license for Acumatica hosted in a private cloud with the hosting provider of your choice. You decide where the software and date is hosted and when updates are applied.
Private Cloud Perpetual (PCP) [...] A license for Acumatica that you pay upfront for the perpetual use of Acumatica ERP. This has been the legacy model and includes an annual maintenance charge. It can be deployed on your premise or in a hosted private cloud.
(https://www.acumatica.com/cloud-erp-software/product-editions/)
Все было бы хорошо и я был бы рад с вами во всем согласиться(особенно учитывая тот факт, что эмоционально я полностью на вашей стороне), но против рынка особо не попрешь. Если вы один раз попробуете нанять команду людей, которые могут мыслись категориями из разряда предложенных вами решений, вы быстро поймете, что проще «дать возможность независимым командам выбирать стек для микросервисов», чем плевать против ветра. Бизнес сурово и неумолимо диктует свои требования(особенно, если этому бизнесу так же сурово диктует свои требования венчур!), и сегодня эти требования чаще всего звучат как скорость разработки и доставки решений важнее количества штатных единиц с тайтлом «Software Engineer».
Подходы разработки не всегда оптимальны и эффективны но задачи бизнеса решаются. Да и быстрее, с текущими стеками все куда быстрее и с меньшими трудозатратами чем 10 лет назад.
Пока железо развивается быстрее, чем софт деградирует, ничего не поменяется. Потому что у обычных людей (не разработчиков) нет никакого критерия, что бы отличить качественное ПО от какашки, кроме тормозни и глюков. Как только железо перестанет скрадывать деградацию софта, юзеры сразу начнут напрягать разработчиков и багоделы отвалятся естественным образом.
НЛО прилетело и опубликовало эту надпись здесь
ИТ рынок до недавнего времени рос очень бурно. но рост уже сменяется стагнацией. а прикладные задачи никуда не исчезнут. и тогда начнётся борьба за эффективность. эта борьба уже видна на примере мобильных приложений. вот я не очень давно писал под юнити кусок про обработку больших растровых изображений. весь он получился приветом из 90х. экономия на байтах, битовые сдвиги вместо умножения, самодельные бинарные форматы вместо жсонов. потому что каждый пользователь приложения — это твой хлеб. а телефон у него — дешевый китаец с 1 гб памяти. и батарейка должна выжираться медленнее, чем у конкурентов. и тут не до абстракций и контейнеров.
НЛО прилетело и опубликовало эту надпись здесь
Вот даже если захотеть поверить, что все сказанное в статье правильно и нужно начинать революцию уже вчера, то достаточно посмотреть на предположение, что качество Warcraft, Google и Facebook падает из-за ситуации в ИТ. Это ключевая мысль и она неверная.
Качество поиска Гугла не падает, оно растёт. Только критерии роста определяют не пользователи, а бизнес. Гугл выжимает из него все больше и больше денег — просто посмотрите на отчеты компании. То же самое касается и Фейсбука.
Вы думаете, лента стала работать хуже, потому что там React Native и много эффективных менеджеров? Нет, лента начала приносить больше денег из-за того, что в среднем пользователи проводят больше времени, листая её.
Варкрафт не дотянул до ваших ожиданий? Ну, сорян, Frozen Throne был флагманским продуктом на тот момент, а Рефоржд никому не нужен на фоне мобильного Хартстоуна.
В статье поднято много важных проблем, но выводы неверные. Разработка ПО массового использования сейчас достаточно хорошо отражает свободный рынок. За что платят, то и делают. Делают так, как за это платят. Грубо говоря, если Гугл готов платить Васе 10к за говнокод на ноде, то зачем Васе работать за 500 баксов на Дельфи в МухосранскОблЭнерго?
Качество поиска Гугла не падает, оно растёт. Только критерии роста определяют не пользователи, а бизнес. Гугл выжимает из него все больше и больше денег — просто посмотрите на отчеты компании. То же самое касается и Фейсбука.
Вы думаете, лента стала работать хуже, потому что там React Native и много эффективных менеджеров? Нет, лента начала приносить больше денег из-за того, что в среднем пользователи проводят больше времени, листая её.
Варкрафт не дотянул до ваших ожиданий? Ну, сорян, Frozen Throne был флагманским продуктом на тот момент, а Рефоржд никому не нужен на фоне мобильного Хартстоуна.
В статье поднято много важных проблем, но выводы неверные. Разработка ПО массового использования сейчас достаточно хорошо отражает свободный рынок. За что платят, то и делают. Делают так, как за это платят. Грубо говоря, если Гугл готов платить Васе 10к за говнокод на ноде, то зачем Васе работать за 500 баксов на Дельфи в МухосранскОблЭнерго?
НЛО прилетело и опубликовало эту надпись здесь
Хотим. Корень проблемы в том, что из мира IT напрочь исчезли энтузиасты. Вчерашние энтузиасты выросли, обзавелись семьями и предсказуемо захотели денег, а новая смена так и не пришла. Все молодые с горящими глазами, готовые просаживать недели и не спать по трое суток ради безумной идеи, сюда уже давно не идут. Они идут куда-то ещё, потому что эпоха фронтира в IT закончилась, ореол романтики рассеялся, и из искусства IT стало ремеслом. Соответственно все люди искусства, желающие самовыразиться и чем-то обогатить этот мир, находят себе другую область деятельности.
А новое поколение приходит сюда исключительно с целью заработать денег. Они с самого начала знают, с какой стороны у бутерброда масло, и палец о палец не ударят без предварительного расчёта окупаемости.
Поэтому у нас больше никогда не будет демосцены, не будет трекерной музыки и не будет шустрых программок, способных работать в 16Кб памяти.
А новое поколение приходит сюда исключительно с целью заработать денег. Они с самого начала знают, с какой стороны у бутерброда масло, и палец о палец не ударят без предварительного расчёта окупаемости.
Поэтому у нас больше никогда не будет демосцены, не будет трекерной музыки и не будет шустрых программок, способных работать в 16Кб памяти.
А я бы сказал, что проблема обратная — мир IT полностью отдали энтузиастам, которые окончательно оторвались от реального мира Поэтому, например, на хабре делают WYSIWYG-редактор, потому что О ГОСПОДИ ЭТО ЖЕ СТИЛЬНО, МОДНО, МОЛОДЁЖНО, ТАКАЯ КРУТАЯ МУЛЬТИПЛАТФОРМЕННАЯ ФИЧА…
Те демосцены делали в виде маленьких приложений, чтобы любой их мог открыть — думали о тех, кто будет это смотреть.
Больше демосцен у нас не будет, потому что создатели современных демосцен свои творения будут выкладывать на гитхаб в виде кода и без инструкций по компиляции: «мне и так норм, а если тебе надо ты и делай».
Те демосцены делали в виде маленьких приложений, чтобы любой их мог открыть — думали о тех, кто будет это смотреть.
Больше демосцен у нас не будет, потому что создатели современных демосцен свои творения будут выкладывать на гитхаб в виде кода и без инструкций по компиляции: «мне и так норм, а если тебе надо ты и делай».
По мне так «Плач Ярославны»: «Убираем всех, кого я считаю лишними.»?
Да вот загвоздка: компании не только на ИТ завязаны.
Например, бухгалтерия вообще может продукт не производить (обычно и не производит).
Но без неё можно свою зарплату вообще не получить.
Сюрприз!
А так, какие-то крокодиловы слёзы: нас не понимают, а мы же ГЕНИИ!!!
Шта? Займитесь делом! И лучше начать с себя. Возможно тогда и мир прекраснее станет.
Да вот загвоздка: компании не только на ИТ завязаны.
Например, бухгалтерия вообще может продукт не производить (обычно и не производит).
Но без неё можно свою зарплату вообще не получить.
Сюрприз!
А так, какие-то крокодиловы слёзы: нас не понимают, а мы же ГЕНИИ!!!
Шта? Займитесь делом! И лучше начать с себя. Возможно тогда и мир прекраснее станет.
Отчасти согласен, мы ушли в технологии ради технологий.
2005. ASP classic на VBS, за 1 месяц сделал систему для учета оперативных задач менеджмента. Работает до сих пор!
2010. ASP.NET MVC + Bootstrap. Публичный закрытый для своих сайт с парой форм, регистрацией и таблицей с сортировкой. Разработка + тестирование + доработка внешнего вида 1 неделя.
2021. Net core 5 + Angular 11 + Angular Material + Ef + ASP NET Identity. Настройка авторизации и аутентификации через JWT, с учетом обработки ролей на фронте (из кода на бэке только генерация токена, зато файл startup.cs на 150 строк настроек), битва за создание контроллеров с EF core CRUD которые принимают комплексные json объекты из фронта (и не пытающиеся создать все «прилепленные» объекты), гениальное приведение типа в TypeScript, когда объект этого типа создается, но доступ по параметру не работает, т.к. в json пришел userId, а у тебя в классе userid, а ты такой смотришь, тип есть, данные есть, а при попытке получить данные — undefined, а при попытке указать как в json ругается уже VSС. Прошло 20 дней, готово пара сложных форм и все. Зато есть типа «каркас» приложения который сделан по всем лекалам бестпрактис.
2005. ASP classic на VBS, за 1 месяц сделал систему для учета оперативных задач менеджмента. Работает до сих пор!
2010. ASP.NET MVC + Bootstrap. Публичный закрытый для своих сайт с парой форм, регистрацией и таблицей с сортировкой. Разработка + тестирование + доработка внешнего вида 1 неделя.
2021. Net core 5 + Angular 11 + Angular Material + Ef + ASP NET Identity. Настройка авторизации и аутентификации через JWT, с учетом обработки ролей на фронте (из кода на бэке только генерация токена, зато файл startup.cs на 150 строк настроек), битва за создание контроллеров с EF core CRUD которые принимают комплексные json объекты из фронта (и не пытающиеся создать все «прилепленные» объекты), гениальное приведение типа в TypeScript, когда объект этого типа создается, но доступ по параметру не работает, т.к. в json пришел userId, а у тебя в классе userid, а ты такой смотришь, тип есть, данные есть, а при попытке получить данные — undefined, а при попытке указать как в json ругается уже VSС. Прошло 20 дней, готово пара сложных форм и все. Зато есть типа «каркас» приложения который сделан по всем лекалам бестпрактис.
Контейнеризация, контейнеризация, эджайл, микроксервисы, лучшие практики… где же про это слышал? А, так у себя на работе сегодня… и уже несколько лет тошнит от этих слов.
— можешь карету починить за день?
— да тут на час работы
— а за три дня, неделю, месяц?
— ну если постараться…
Все так боялись «Х*к, Х*к и в продакшен», что вылетели в другую крайность, где, чтобы зарелизить нужно два прихлопа, три притопа и соблюсти еще кучу ритуалов и танцев с бубнами, чтобы на выходе получить вечно тормозящее и глючное мессиво, но у нас же сурьезная фирма, веников не вяжем
— можешь карету починить за день?
— да тут на час работы
— а за три дня, неделю, месяц?
— ну если постараться…
Все так боялись «Х*к, Х*к и в продакшен», что вылетели в другую крайность, где, чтобы зарелизить нужно два прихлопа, три притопа и соблюсти еще кучу ритуалов и танцев с бубнами, чтобы на выходе получить вечно тормозящее и глючное мессиво, но у нас же сурьезная фирма, веников не вяжем
Ничто не ново под луной
Deming, W. Edwards — Out of the Crisis-MIT Press (2011)
Deming, W. Edwards — Out of the Crisis-MIT Press (2011)
Много справедливого, но в целом, мне кажется, вы напрасно пытаетесь слить всю разношёрстную и разнородную ситуацию в некую «единую теорию всего», которая «всё объясняет». Ну вот, например, мне кажется, что неверно противопоставлять «прагматиков» настоящего «романтикам» прошлого. Из того, что я читал, складывается впечатление, что в 80-х годах порог входа был настолько низок, что человек мог легко забить на свой исторический/филологический факультет и пойти «в программисты» после двух вечеров с компьютером. Да, где-то нужны были суперспецы, а где-то требовалась страничка кода на Бейсике. Вам не нравится Warcraft 3, а E.T. нравится?
Куча ресурсов тратилась на переизобретение велосипеда или использование неоптимальных технологий, потому что банально не хватало кодовой базы. Хотите решать дифуры? Берите фортран, потому что для него есть библиотека, а если не фортран, но будете писать библиотеку сами. Ну и так далее. Не, я тоже не люблю Electron и не вижу необходимости переписывать хорошее работающее на Javascript'е, но у каждого времени свои извращения, что с этим поделать. А с другой стороны, лет 20 назад сказал бы кто, что снова наступит вспышка интереса к низкоуровневому программированию, я бы не поверил. А таки пришёл всякий IoT и Arduino, так что происходит всё и сразу.
Куча ресурсов тратилась на переизобретение велосипеда или использование неоптимальных технологий, потому что банально не хватало кодовой базы. Хотите решать дифуры? Берите фортран, потому что для него есть библиотека, а если не фортран, но будете писать библиотеку сами. Ну и так далее. Не, я тоже не люблю Electron и не вижу необходимости переписывать хорошее работающее на Javascript'е, но у каждого времени свои извращения, что с этим поделать. А с другой стороны, лет 20 назад сказал бы кто, что снова наступит вспышка интереса к низкоуровневому программированию, я бы не поверил. А таки пришёл всякий IoT и Arduino, так что происходит всё и сразу.
Про Google только чушь не надо пороть
Нет, что вы! Гугл лучшая компания! Десятки тысяч инженеров заняты полезным делом: улучшают решения для удобства пользователей, закрывают баги, обеспечивают сапорт 24/7.
А нет, постойте, это же в гугле люди пишут по 2 года и ровно 10 строчек идет в прод. Это в гугле сотни проектов закрываются каждый год не доходя до прода. Это в гугле висят баги с 2015 года не исправленные. Это в гугле удаляют приложения с десятками тысяч установок без объяснений сапорта. Это в гугле банят аккаунты пользователей без объяснения причин. Это в гугле в адворкс списываются деньги за фантомные переходы а сапорт молчит.
А нет, постойте, это же в гугле люди пишут по 2 года и ровно 10 строчек идет в прод. Это в гугле сотни проектов закрываются каждый год не доходя до прода. Это в гугле висят баги с 2015 года не исправленные. Это в гугле удаляют приложения с десятками тысяч установок без объяснений сапорта. Это в гугле банят аккаунты пользователей без объяснения причин. Это в гугле в адворкс списываются деньги за фантомные переходы а сапорт молчит.
Конечно конечно вы правы! Именно поэтому Google весь мир знает, любит и ценит ( даже я их библиотеками пользуюсь и опять же их Google C++ Testing Framework и… многия… многия. А вы… вы так и будете писать всякий хлам в местах, где вас не знает никто. Ведь всегда проще обливать грязью тех, кто добился успеха, чем «выбиться в люди» самому, да? Глядишь и люди подумают или скажут «Ай моська! Знать она сильна, раз лает на слона!». Старый, но верный принцип… вам должно быть минимум неудобно от своих слов, но вы наверное и слова такого не знаете — «неудобство», да?
PS Без обид, — когда вы хоть немного приблизитесь к их уровню, тогда и будете иметь моральное право на осуждение и оценку деятельности этих специалистов, а пока это выглядит как попытка неандертальца критиковать летающую тарелку." Или вы следуете современной моде, типа ругать все американское? Так признались бы честно…
PS Без обид, — когда вы хоть немного приблизитесь к их уровню, тогда и будете иметь моральное право на осуждение и оценку деятельности этих специалистов, а пока это выглядит как попытка неандертальца критиковать летающую тарелку." Или вы следуете современной моде, типа ругать все американское? Так признались бы честно…
Допустим, вы априори считаете собеседника нонеймами (что довольно глупо так как на данном ресурсе почти нет случайных людей). Однако, если вы хотя бы немножечко были бы в теме, то вы наверное бы знали, насколько другие «не ноунеймы» знают, люят и уважают гугл. Например, Stadia port of Terraria canceled after co-creator locked out of Google accounts. Или например Google slammed for ‘monopoly power’ in new antitrust lawsuit from 35 states.
Ой спасибо, что открыли мне глаза! Я то сижу в мухосранске охранником на проходной и пишу в коменты, завидуя гуглу самой страшной завистью. А код я вообще отродясь не писал и продуктами гугла не пользовался, а они волшебные!
И да, конечно же я не знаю слово неудобство по отношению к одной из самых грязных монополий в мире, которая если что-то и делала, то только для того, чтобы получать еще больше денег. И да, Андроид и Ютьюб они купили, Хромиум был создан на вебките.
Ведь всегда проще обливать грязью тех, кто добился успеха, чем «выбиться в люди» самому, да
Ой спасибо, что открыли мне глаза! Я то сижу в мухосранске охранником на проходной и пишу в коменты, завидуя гуглу самой страшной завистью. А код я вообще отродясь не писал и продуктами гугла не пользовался, а они волшебные!
И да, конечно же я не знаю слово неудобство по отношению к одной из самых грязных монополий в мире, которая если что-то и делала, то только для того, чтобы получать еще больше денег. И да, Андроид и Ютьюб они купили, Хромиум был создан на вебките.
Гугл лучшая компания! Десятки тысяч инженеров заняты полезным делом: улучшают решения для удобства пользователей, закрывают баги, обеспечивают сапорт 24/7.
Всё так. У вас только одно заблуждение: что пользователь здесь — это человек, заходящий в поиск, почту, ютуб, и т. д. Нет — для Гугла пользователи — это покупатели рекламы. А вот эти все остальные — это так, массовка.
НЛО прилетело и опубликовало эту надпись здесь
Этот «плачь Ярославны» я слышу с 990-х годов прошлого тысячелетия.
ИТ движется не туда.
Зачем нужен Pascal, когда можно писать на ассемблере.
Никто такты процессора не экономит.
А уж с кучей/памятью как работают…
GUI и windows это от лукавого.
Зачем они нужны, хватить и DOS'а.
Всё гораздо проще.
Выживает то, что приносит прибыль.
Всё остальное «отмирает».
ИТ движется не туда.
Зачем нужен Pascal, когда можно писать на ассемблере.
Никто такты процессора не экономит.
А уж с кучей/памятью как работают…
GUI и windows это от лукавого.
Зачем они нужны, хватить и DOS'а.
Всё гораздо проще.
Выживает то, что приносит прибыль.
Всё остальное «отмирает».
Показательно, что в английском coder и software engineer это разные, а в переводе у нас это и то и то «программист».
Бизнес давно ищет ответ.
Производительность труда в IT падает, и это меня тоже беспокоит. С другой стороны, законы Адама Смита никогда в истории человечества не нарушались, не нарушатся и сейчас. Аналитика IDC — до 2024 нужно 0,5 млрд приложений. Де-факто к бизнесу нужно по разработчику. Это невозможно! Значит, бизнес и будет разработчиком. Но не в том смысле, в котором хотят сегодня кодеры.
Есть еще проблема, которую разработчики забывают — поддержка текущего софта. Написать что-то новенькое это прям приятно, а как его поддерживать — ой, ну это пусть кто-то другой. Или давайте теперь рефакторить. Или мониторинг давайте сейчас специально накручивать и т.п.
Что это будет? Возможно, это будет low code (к которому сейчас много вопросов, но он улучшается день ото дня). Только в России — Elma, Comindware. В мире и Amazon Honeyode, и Ms Powerapps и т.п. Возможно, это будет в далеком будущем какой-то process mining (app mining) полностью переосмысленный. Но что-то будет, и это будет интересно!
Бизнес давно ищет ответ.
Производительность труда в IT падает, и это меня тоже беспокоит. С другой стороны, законы Адама Смита никогда в истории человечества не нарушались, не нарушатся и сейчас. Аналитика IDC — до 2024 нужно 0,5 млрд приложений. Де-факто к бизнесу нужно по разработчику. Это невозможно! Значит, бизнес и будет разработчиком. Но не в том смысле, в котором хотят сегодня кодеры.
Есть еще проблема, которую разработчики забывают — поддержка текущего софта. Написать что-то новенькое это прям приятно, а как его поддерживать — ой, ну это пусть кто-то другой. Или давайте теперь рефакторить. Или мониторинг давайте сейчас специально накручивать и т.п.
Что это будет? Возможно, это будет low code (к которому сейчас много вопросов, но он улучшается день ото дня). Только в России — Elma, Comindware. В мире и Amazon Honeyode, и Ms Powerapps и т.п. Возможно, это будет в далеком будущем какой-то process mining (app mining) полностью переосмысленный. Но что-то будет, и это будет интересно!
Если очень глубок погрузиться, в ИТ, то возможно, и может возникнуть ситуация,
"- Да, были люди в наше время,
Не то, что нынешнее племя:
Богатыри — не вы!"
А если пользоваться, анализом и обобщением, то схожие процессы были в НИИ созданных в 30х и 50х, вот был прогресс, а в 70х они уже штаны просиживали, и отписками занимались.
Общие стадии в развитие технологий можно выделить в автоматизации производства, до этого была волна механизации.
Да, отрасль стала массовой, она созрела, ни она первая, ни она последняя. В зрелой отрасли, есть и болото, и передовые разработки, здесь же варятся вещи, которые завтра упрутся в формальные отписки и распиливание грантов/бюджетов, или поменяют образ жизни всего человечества. Что-нибудь типа квантовых вычислений, генных технологий и т.д. И на первом этапе, это будет клуб лучших среди лучших, а потом порог вхождение снизиться, и все повториться.
"- Да, были люди в наше время,
Не то, что нынешнее племя:
Богатыри — не вы!"
А если пользоваться, анализом и обобщением, то схожие процессы были в НИИ созданных в 30х и 50х, вот был прогресс, а в 70х они уже штаны просиживали, и отписками занимались.
Общие стадии в развитие технологий можно выделить в автоматизации производства, до этого была волна механизации.
Да, отрасль стала массовой, она созрела, ни она первая, ни она последняя. В зрелой отрасли, есть и болото, и передовые разработки, здесь же варятся вещи, которые завтра упрутся в формальные отписки и распиливание грантов/бюджетов, или поменяют образ жизни всего человечества. Что-нибудь типа квантовых вычислений, генных технологий и т.д. И на первом этапе, это будет клуб лучших среди лучших, а потом порог вхождение снизиться, и все повториться.
абсолютно верно. последние 3 проекта которые я видел были усложнены и необоснованно раздуты, последние 2 проекта которые я рефакторил и запускал как антикризисный менеджер мне удалось сократить в 10 раз по объёму кода с сохранением функциональности, команду разработчиков удалось сократить в 4 раза в одном проекте и в 3 раза в другом. в 90% случаев которые я анализирую сервисная архитектора применяется неправильно, в 80% проектов лишний зоопарк решений. там где можно использовать простой MVC лепят фронтенд фреймворк, где можно обойтись одним программистом работает команда из 3 менеджеров и 1 инженера. цены на одно и то же тз колеблются от 30 000 до 580 000, там где можно обойтись 1 модулем vue у людей по 5 минут собирается npm. из-за неправильно выбранной архитектуры приходится увеличивать количество разработчиков в 2-3 раза больше чем нужно, и скорость разработки падает. там где достаточно просто нажать publish выстраивают сложные ci/cd цепочки которые работают раз в месяц… в виртуальной машине кубернетис, в контейнере докер, в нём Линукс, в нём бессерверная архитектура, в зайце утка, в яйце игла, в огороде бузина а в Киеве дядька
Для полного понимания картины у меня просьба большая. Скинуть ссылку на опыт работы, что бы видеть контекст.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Суровая правда о разработчиках и разработке