Комментарии 35
Да тут почти все обман. Ну так, условный но реальный пример — нужно интегрироваться с (внешним) REST-сервисом. Для настоящего программиста задача вполне рутинная, которую многие решали уже в жизни раз по сто.
А тут будет одно из двух — либо этот «менеджер» прочитал документацию и книжки, и реально понимает, для чего нужны методы в HTTP, и что означают статусы, и когда нужно применять GET, а когда POST. И если он это сделал — он правда стал немного программистом. Но сделали его таким чтение книжек и документации, а не какой-то там мифический инструмент low-code. А если он не прочитал — то скажем тривиальную аутентификацию, даже BASIC, он никогда не сделает.
Вообще странный вопрос, адрес rest сервиса, это какая-то особая магия который, обычные смертные обладать не могут?
Другое дело, что дергать rest из того, же excel или powerBI, имхо навыков нужно больше( где что нажат ), чем дернуть его из python или любого другого скриптового языка, но знаний программирования для этого не надо.
Сколько я этих интеграций писал, наверное сотни. И примерно лишь в 10% документация как следует описывала сервисы. Почему? Да потому что она имеет свойство устаревать. Это ее естественное состояние, в общем-то.
Кроме того, вот смотрите, вы написали адрес, а я писал метод. Т.е. POST или скажем PUT. И откуда вы его узнаете, если вы не понимаете ничего в HTTP, и вам эти названия ничегошеньки не говорят? Откуда вы знаете, какие заголовки нужно, если вы снова не знаете о HTTP, и вообще не понимаете, что это такое? Я готов согласиться, что понимание протокола это не навыки программирования, но прямо скажем — это не сильно отличается.
Для ясности — я просто привел REST как очевидный пример, они реально часто поддерживаются инструментом — но даже в таком инструменте у меня были проблемы. Скажем, инструмент умеет SOAP — но только в одном из форматов документа, а их два. Или умеет только BASIC аутентификацию, и не умеет SPNEGO (а попробуйте для начала найти живого программиста, который бы помнил все детали реализации SPNEGO :).
Ну и опять же — если вы не программист, вы не сможете понять, что вам нужно, если вы не вникните, не прочтете документацию, и т.п. — то есть не сделаете все тоже, что сделает обычный программист, вникая в подобную задачу. И как только вы это сделаете — вы решите задачу, но вы перестанете быть каким-то специальным low-code программистом, а станете нормальным, который читает документацию и изучает новые для себя технологии в каждом проекте.
Но в реальности не менеджер без программиста это интегрирует, а программиста просят это все настроить. То есть ему надо еще и эти инструменты знать
Какие-то у них не те недостатки low-code. Намного важнее огромная сложность доработки и поддержки таких решений.
Если вы Кока-Кола или WAG можете смело ставить себе такие системы
В первую очередь обучают основам — базам данных и дизайн-мышлению.
Такс, такс, такс, что тут у нас миллениалы изобрели на этот раз? Ага, точно, Excel и Access.
Power BI — это же такой no code, никому не надо знать эзотерический M или хотя бы DAX!
А чтобы поправить виджет под нужды, нужно поставить тулчейн и собирать TS код, сильно отличающийся от браузерного.
Power BI прекрасен, но python проще реализует «хотелки» заказчиков.
Не надо нам гуманитариев, спасибо
… ммм, как человек с высшим гуманитарным образованием, хотел бы поинтересоваться, где конкретно не надо гуманитариев, и почему?
В программировании не надо. Потому что как правило, плохо с логикой
"Плохо" в значении "хуже определенного уровня" или в значении "хуже, чем у какой-то другой группы"?
Вообще, конечно, занятно: большую часть своей истории логика изучалась с гуманитарными дисциплинами, но при этом у людей, занимающихся этими самими дисциплинами, "плохо с логикой"?
Хуже чем у сферического технаря в вакууме
Логика давно не гуманитарная дисциплина. Теорема Баеса, теорема Геделя, парадокс Скулема, недостижимые мощности и реверсивная математика...
Хуже чем у сферического технаря в вакууме
А на основании какого повторяемого эксперимента вы делаете это утверждение?
Логика давно не гуманитарная дисциплина. Теорема Баеса
Теорема Байеса разве не из теории вероятностей?
Что, впрочем, более важно: что из перечисленного нужно сферическому программисту в вакууме для повседневной работы? Я вот в индустрии двадцать с небольшим лет, и ничто из описанного для работы не применял.
И сколько из сферических программистов в вакууме эти, гм, понятия знает, понимает, и умеет использовать?
Выводы на основании личного опыта.
Теорема Байеса помогает не попадать в логические ловушки.
Является ли знание теоремы Байеса необходимым условием, чтобы не попадать в логические ловушки? Является ли знание теоремы Байеса необходимым, чтобы работать в прикладном программировании?
Выводы на основании личного опыта.
Это, конечно, очень достоверная и полезная информация.
>логика изучалась с гуманитарными дисциплинами
А кстати, поясните как технарю, это какого сорта логика? Ну т.е. что за учебники, что за законы? Входит ли в изучаемое что-то типа законов Де Моргана, ну т.е. логика как часть именно математики?
>И сколько из сферических программистов в вакууме эти, гм, понятия знает, понимает, и умеет использовать?
Я бы по своему чисто прикладному окружению сказал бы, что таких не очень много.
А кстати, поясните как технарю, это какого сорта логика?
Всех сортов.
"Далее в течение почти двух с половиной тысячелетий до второй половины 19 века логика изучалась как часть философии и риторики. "
(https://ru.wikipedia.org/wiki/%D0%9B%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0)
Я вам честно скажу: у меня логики как отдельной дисциплины не было. Была в курсе философии, была в (дополнительном) курсе риторики, но больше всего ее было в написании и защите своих и рецензировании и оппонировании чужим курсовым и дипломным работам. Так что я не могу вам ничего сказать про учебник логики про гуманитариев.
Мы уже рассказывали, как бывший руководитель SMM-агентства Евгений Спорыхин сделал «Тильду для ресторанов», используя платформу Bubble
Где работает в реальности этот продукт. Как посмотреть в живой природе? Какие компании используют?
Достаточно посмотреть на обычную Тильду, чтобы понять ограниченность лоу-кода.
А потом не дай бог кто-то этого внедрит, все привыкнут, но потом окажется, что чего-то не хватает, надо расширять и поддерживать. Вот тут вылезет ещё и вся неповоротливость этих "готовых решений", а сменить их на что-то нормальное будет дорого — менять придётся ещё все процессы, на них завязанные.
Понравилось про программистов, которые оценили разработку в несколько раз выше low-code решения, и про то, как программисты "не воспринимают low-code, потому что боятся потерять работу".
Разве стал бы специалист (любой области) отказываться от инструмента, если он позволяет выполнять ту же работу эффективнее? Я сам порой для некоторых "на коленке" проектов использовал bubble, а для других часами искал подходящие сервисы в надежде сделать проект меньшими усилиями. Но на практике часто уже на этапе знакомства с платформой видишь, что проект в неё в итоге не впишется. И с bubble такая же история: можно быстро сделать прототип, но чем дальше развиваешь, тем понятнее, что нужно быстрее с него слезать и делать "классическое" решение. (Хотя, конечно, там, где дальше прототипа дело не пошло и функционал прототипа простой — время экономится.)
Отсюда и оценка в IT-отделе в несколько раз выше: вероятно, специалисты сразу видят детали проекта и потенциальные узкие места чуть дальше и глубже и закладывают это в оценку. Есть вероятность, что в итоге придётся сделанное за 25к переписывать, вложив ещё 170к, заложенные IT-отделом. Наконец, странно, что это всё происходит внутри одной компании, и никто не попытался выяснить (по крайней мере в статье не рассказано), как же так получилось-то, что сотрудники другого отдела могут сделать то же самое и в несколько раз дешевле, чем их же IT? Тут много чего можно быть же. Либо есть проблемы в HR — люди не на своих местах и нужно тех ребят переместить в IT, раз они так круто делают ПО. Либо более дешёвое решение имеет какие-то недостатки — и тогда неплохо бы обсудить их и соотнести с планами и приоритетами бизнеса. Либо есть проблема в проджект менеджменте — не было человека, который бы состыковал видение программистов и пользователей, они друг друга не поняли, и программисты оценивали более сложную задачу, чем реально нужно было пользователям. А вместо всего этого поверхностно показывается: смотрите, как дёшев low-code, и вот какие нехорошие программисты.
Для этих генераторов есть своя ниша, но она не здесь. Пожалуйста, перестаньте, додо пицца и то успокоилась вроде.
2021 — год low-code. Как он спасает бизнесы в пандемию и превращает гуманитариев в программистов