Комментарии 124
Ой как хитро - тегнуть ангулар, реакт, от души набросить на них и пропихивать втихаря мол...
И тут приходит к нам новый разработчик, который очень хочет попробовать язык Dart от Google в деле. Долго ходил он обедать с техдиром, пока таки не убедил его прыгнуть в этот омут с головой.
СТО, который сам не наигрался ещё в технологии, и на подобное соглашается, - горе в компании.
>лучше нанимать талантливых и опытных людей
Тут есть другая крайность. Талантливые и опытные люди, уже на смотревшись на взлёт и падение проектов, повзрослев, переходят в состояние "всё тлен" и не зацикливаются на фреймворках и архитектурах, а больше мыслят прототипами, наименьшими усилиями и мыслями "взлетит, тогда и будем рефакторить". А молодёжь готова именно на модном современном фигачить велосипеды любого конструктива и они будут ездить, пусть и в 5 раз медленней, чем могли бы.
А бизнес... А что бизнес? Думаете современный бизнес мыслит понятиями красот технических решений? Для бизнеса есть условная капитализация, и в эпоху печатанья денег от технических решений программистов капитализация практически не зависит. Ну выкинули мильон на велосипед, а за тем и сам велосипед, но за это время понабежало 2 мильона клиентов, никто ничего и не заметил. Программисты пьют смузи, бизнес делает байбеки, все счастливы.
и в эпоху печатанья денег от технических решений программистов капитализация практически не зависит. Ну выкинули мильон на велосипед, а за тем и сам велосипед, но за это время понабежало 2 мильона клиентов
Бизнес это ж тоже, не великий и ужасный рациональный ИИ, типа того, что обыгрывает чемпионов по шахматам или го, а система из людей с различной мотивацией, убеждениями, моральными принципами, планами.
К примеру, я видел акционеров, умных логичных и молниеносно соображающих людей с крепким финансовым и маркетинговым бекграундом, которые искренее верили, что аутсорс рулит, и что после сковывающего со всех сторон, и требующего постоянных копромисов инхауса, это как новый виток развития бизнеса, новый уровень, где ресурсы безграничны, и девять женщин рождают ребенка за месяц, если только акционеры найдут деньги на эту авантюру.
Там, среди тех, кто делает байбеки и кешауты, тоже искренее хотят хороших технических решений, только вот не знают как, и могут лишь доверится нааемным работникам (или довериться не до конца, и позвать техаудит, что часто является ожесточенным рытьем, находясь в яме)
Техаудит бизнес интересует ровно во время дью дилидженс )) А аутсорс бизнесу приятен лёгкостью его ампутации. Какие люди, какие технические решения? Цифры в балансе - всё что бизнесу интересно. А то, что эти цифры через десятый уровень взаимосвязаны с "техникой" - мало кто видит и вообще хочет видеть. Бизнес через 5 лет продадут и это будет уже не их проблема, как оно и на чём шевелится.
Вот видите, ту же ситуацию мы видим по разному. Но я же не зря написал "искренне верили". То есть, эти люди делали ставку на взрывное ускорение деливери за счет аутсорса, и подкрепляли ставку своими деньгами. А техаудит делали не перед продажей, а потому, что подгорело знатно от в пятый раз сорванных сроков при эеспоненциальном росте штата.
Как по мне тут надо внести некоторые поправки, про какой бизнес идет речь))) если про практически монополи и прочие конторы в кучей нулей в прибыли, так меня это вообще не трогает (молодцы программеры), а если под бизнесом понимается то, чего у нас собственно нет, то бизнес конечно жаль потому как ввиду отсутствия знаний он доверяет всему, что пишут в том числе на Хабре)) или говорят с высоких трибун(цифровизация наша ВСЕ))
Вот смотрите, табличка на 10 тысяч строк, реализованная за 10 минут предельно наивным кодом..
Занятный прикол у этой таблички. Скролл вниз работает, ок. Но если взять ползунток справа и пролистать резко куда-нибудь в середину - я уже вот минуты 2 жду пока загрузятся строки. Причем переключил вкладку и вернулся обратно и что я вижу:
Ничего
Уверен оно дозагрузится и всё будет окей, но что-то не очень шустро оно по итогу летает. Firefox 108.
В FF, к сожалению, сломали overflow-anchor (скачки при инерции скролла), так что приходится пока что переключаться в нём с виртуального рендеринга на ленивый.
Мне кажется это слабоватым аргументом, ведь $mol позиционируется как победное решение без боли. Я, к слову, не фронтендер, и хуже того, даже не веб-разработчик, так что судить о качестве фреймворка (конструктора, если угодно) не могу. Просто прочитал статью, зацепился за одну проблему, но уверен, если копнуть, и другие всплывут.
Причём причина-таки всех мелких бед будет упираться в то, что у вас нет ресурсов на то, чтобы такие косяки исправлять, а у крупных компаний, вроде как и есть.
Любое другое решение с адаптивной табличкой на 10к строк умрёт сразу, даже не показав вам скроллбар.
https://clusterize.js.org не тормозит даже в FF
Это не адаптивная таблица. Так-то и в $mol можно зафиксировать высоты и заэнфорсить виртуализацию. Лучше глянуть мой доклад про виртуализацию рендеринга, чтобы лучше понимать проблемы.
Мне кажется вы пытаетесь продать то что не нужно. Один раз высота просчитывается и фиксируется, никто в своем уме изменение размеров таблицы на лету не посчитает адекватным юзер-кейсом, кроме джуна тестера, который вчера карандаши тестировал и пришел к выводу, что гранёный плохо ощущается в *опе, лучше круглый ?
Не говоря уже о том, что 10к строк ни одно известное живое существо в нашей вселенной не воспримет. Моя задача как профессионала отговорить бизнес от технологий ради технологий, заставить 10 раз подумать. И ваше "в FF к сожалению сломали" яркий тому пример.
Как бы непонятно, а что делать-то? Писать свой более лучший фреймвёрк для всего?)
Начать стоит с повышения технической культуры в сторону выбора лучших решений.
Это всё лозунги.
А на прикладном уровне вам это как видится? Поделитесь, по возможности.
Я же целый раздел в конце этому посвятил.
Перед реализацией новой фичи, составляется документ с описанием вариантов решений, анализом их сильных и слабых сторон, и обоснованием выбора одного из них. После чего проводится ревью, где другие разработчики помогают улучшить анализ, если автор что-то не учёл. И только после всего этого начинается собственно написание кода.
Вы это прикладным решением называете? Извиняюсь за подробности, а кто за эти упражнения будет платить?)
Тот же, кто платит за тесты - конечный пользователь.
Я несколько сомневаюсь, что пользователь осознанно пожелает оплачивать состязания творческого коллектива в перфекционизме.
Если ваша личная практика строится именно так, то я выступаю с усредненной больничной позиции. Как ваши, вне сомнения, прекрасные порывы претворить в жизнь массово?
А пользователя кто-то разве спрашивает? Я вам по секрету скажу, лучшие технические решения снижают косты, а не повышают.
Проблема в том, что "стоимость поиска лучшего решения" + "стоимость реализации лучшего решения" далеко не всегда окупают экономию на костах. А ещё самое неприятное в том, что нередко все эти посиделки с поиском, анализом и обоснованными/согласованными выводами не выдают решение, которое на поверку оказывается лучшим. Это только эксплуатация покажет.
Стоимость поиска в масштабах проекта ничтожна. И она как раз позволяет не разрабатывать своё, а взять лучшее. В отличие от более распространённого подхода: сэкономили на анализе, потом потратили кучу времени на кривой велосипед, а бизнесу сказали, что у нас всё "на Реакте".
Это не так, зависит от глубины поиска. Я вот выбирал набор визуальных компонентов для фронта.
Быстрый поиск и анализ - это посмотреть сайт, сам набор, пошерстить доку на предмет адекватности, посмотреть примеры.
Второй уровень - почитать ишшью на гитхабе (несколько дней, неделя), поизучать исходники (месяцы?).
И третий уровень - использовать эти компоненты в реальном проекте, в течении например года, потому как не знаешь что и когда всплывает, и составить свое мнение + наткнутся на свои ишшью. Все компоненты.
Шорт лист компонентов у меня состоял из трех. Три года для продукта - это ощутимый срок. А для заказной разработки и подавно.
Так что, позволю себе гиперболу, - чтобы быть профессионалом и не обманывать бизнес надо 30 лет опыта на рекате, 30 лет на ангуляре и 30 лет на вуе. Но позвольте, это в сумме 90 лет, жизни не хватит. И 30 лет назад был дос.
Чем больше слабых мест в решении вы найдете до начала работ, тем лучше. Вы сможете скомпенсировать их архетектурой, изолировав их от остального кода.
Конечно, всех нюансов технологии и требований бизнеса вы можете не знать, но предугадать многое вполне возможно. От синьёра ожидается, что у него уже есть за плечами опыт эксплуатации.
Время потраченное на анализ, это копейки по сравнению с временем разработки.
У вас прекрасная индивидуальная вселенная, Виктор Олегович позавидует.
Коммерческая разработка (в основном) редко предполагает творческие изыскания, поскольку есть ТЗ и фиксированные ресурсы на реализацию этого ТЗ в рамках договора.
Что если субъект не имеет возможности обедать своего ГД? Какую рекомендацию вы дадите в этой ситуации? Когда нет пользователя, который безропотно за всё заплатит.
В прямых руках React + Typescript + MobX идеально подходит и справляется с 99.9% всех проектов.
Сможете на этой связке за пол часа поднять новый бизнес процесс в компании?
В атоматизации бизнес процессов компании (быстрее крупной, чем мелкой) непосредственно само программирование занимает дай бог 10% и, в конечном итоге, будут это пол часа или 2 дня - никто не заметит. И поосторожней с такими эстимейтами. По опыту - такое шапкозакидательство практически всегда выдаёт неопытность как минимум именно во внедрении.
Ну да, подумаешь, держать штат из 2 программистов или из 32, никто не заметит.
Кажется, вы скатываетесь в агрессивную защиту. То есть ваше творение настолько эффективно, что повышает производительность программиста в 16 раз? Извините, такого в жизни не встречал пока.
Ну вот теперь и встретили. Добро пожаловать в мир высокоуровневых решений.
Тогда почему ваше великое творение никому не известно, а 99.99% "велосипедистов" и компании предпочитают тратить на разработку в 16 раз больше времени и в 32 раза больше программистов? Этож какие деньжищи-то можно сберечь!
А вы статью вообще не читали?
Там воды больше, чем в типичной курсовой. Не решился тратить свое время на это.
В таком случае на комментарии можете тоже его не тратить, а то фичу до конца спринта доделать не успеете.
К слову, многие фичи на $mol деливерятся за пол часа.
А такой срочности точно есть необходимость? Прямо за полчаса, к окончания митинга, чтоли?
Вот смотрите, табличка на 10 тысяч строк, реализованная за 10 минут предельно наивным кодом..
Подергал ползунок туда-сюда. Чем дольше дергал - тем больше памяти жрала вкладка в Хроме. Тоже недоработка разработчиков браузера?
По умолчанию, не используемые ресурсы автоматически очищаются. Но конкретно в этой демке данные генерируются на лету, и чтобы они не перегенерировались постоянно (что вызывало бы недоумение), для них автоочистка отключена.
пол гига для одной вкладки с одним списком для текущих конфигураций железа явно многовато...
Можно скриншот? Тут разбирается реальный кейс, где потребление памяти не превышает 100мб, против почти гигабайта в реализации на vue.
ну не должна реклама быть такой длинной. лаконичнее надо быть, никто же до конца не дочитал.
Эмоционально видение проблемы разделяю. Но рационально автор не сумел отделить личную боль от общественной.
Общая боль состоит в неэффективности бизнеса. От этого все тормоза, неудобства и баги.
Личная боль - нарушение гармонии (в понимании автора). Да, убогие решения строят ерунду, на которой пишут "мега-супер-храм-вашего-всего". То есть бьют больно по мечте, по красоте, по идеалу, наклеивая ярлык "идеал" на кучу из отходов жизнедеятельности. Ну и рекламируя громко это изделие, разумеется, под флагом "идеальное лично для вас" (хотя меня они не знают ни на грамм, разумеется).
Раздел "что делать" так же несколько искажает реальность, а потому нереалистичен по части воплощения в жизнь.
Например:
вы не рабы, а интеллектуальная элита современности
Интеллектуальная элита современности, я уж извиняюсь, но это точно не IT. IT - это слесаря. Им поручают напилить гаек, ну и они дают стране угля именно в указанных габаритах.
Интеллектуальная элита же не даёт стране угля. Она даёт стране будущее. Какое будущее нам дали IT-шники? Нет, они лишь угля нам навалили, а дальше мы вот разгребаем все эти тормоза и баги.
Из показанного непонимания следует:
В IT сильный дефицит кадров, а хороших кадров - острый дефицит.
Понятно, что если себя причислил к интеллектуальной элите, то сразу начинаешь думать "как меня такого гениального мало".
Но в реальности кадров завались. Дефицита реально нет. Хотя есть искажённые требования к слесарям, определяемые самими слесарями с целью улучшения позиции оных слесарей на их текущем рабочем месте. Ну а причина опять та же самая - неэффективность бизнеса. Не следствие, а именно причина.
Каждый проект имеет уникальную архитектуру
И опять мимо. Названия там могут быть отличающиеся, но от общего цикла работы с данными никто из велосипедистов никуда не денется. Всегда - взять данные, передать, показать, прочитать ввод, передать, сохранить. Ну а если при этом чешут ухо пяткой, то нового от этого в проекте ничего не появляется. Или если показывают с графиками и анимацией, то суть явления "показать" от этого тоже никуда не девается.
Одни и те же детские болезни в каждом проекте.
Вот и подтверждение от автора - ничего в проектах не меняется, включая одни и те же болезни.
Но, тем не менее, автор поднял важную тему. Не беда, что не дотянул до глубин. Главное - чем больше подобных обсуждений случится, тем будет лучше. Хотя быстро уменьшающаяся карма, похоже, сильно ограничит данное направление дискуссии. А жаль. Но это тоже часть нашего неидеального мира.
Поддерживаю. Архитектуры и проекты в целом в подавляющем большинстве одинаковые с небольшой в масштабах приложения спецификой (для того же получения данных - REST, RPC, Socket, binary, GraphQL), которая разруливается адаптерами. Целые массивные слои (роутинг, сборка, валидация, кодогенерация, темизация, локализация, механизмы SSR, BFF) с незначительными изменениями таскаю из конторы в контору с крайне различающимся бизнес-направлением (от банков до бирж), если сделать их достаточно гибкими и фреймворконезависимыми.
И по поводу основной проблемы бизнеса тоже соглашусь, на мой взгляд это "все надо очень быстро", которая исходит из самой сути предпринимательства - вложения денег ради получения денег. Это приводит к требованиям использовать широко распространенный фреймворк, готовые библиотеки и взаимозаменяемых сотрудников, которых легко найти на рынке. И рождает требование "технари в первую очередь должны думать о бизнесе (читай - быстром росте количества фичей), а потом о своих идеалах, скорости приложений, стабильности, архитектурной согласованности, поддерживаемости". Мне это тоже доставляет личную боль как творческому человеку, и боль за результаты своего труда, потому что высокая скорость разработки приводит к формированию легаси и техдолга, которые за пару лет могут превратить проект в неподдерживаемый и нестабильный. Но с этим приходится мириться, вкладывая усилия в гибкость архитектуры, чтобы в будущем довольно просто можно было сменить одни части на другие и достаточно изолированно отрефакторить.
Тоже поддерживаю.
взаимозаменяемых сотрудников, которых легко найти на рынке
Хотя в этом случае желание бизнеса приводит к обратным результатам. Бизнес хочет взаимозаменяемое, но он ведь не один. Все хотят взаимозаменяемое, и их много, поэтому все ищут "специалиста по ХХХ с опытом от УУУ лет". Но когда все ищут одно и тоже, то получаем дефицит. А потом, когда специалисты наелись технологией ХХХ и перепрыгнули на технологию ZZZ, она постепенно становится новой модой и бизнес теперь начинает искать спецов по ZZZ. Но их массово опять нет, опять имеем голод. И так продолжается уже лет 30.
Рынок подстраивается под популярные технологии, это нормально для всех отраслей - раньше нужны были кто работал лопатой, теперь экскаватором. Много курсов Реакта и Вью выпускают много потенциальных разработчиков. Есть временной лаг между этапами спрос-предложение-"предложение с опытом работы YYY", но не критичный на мой взгляд, и доносит до бизнеса идею что сотрудников нужно в том числе выращивать самостоятельно.
Я спросил на работе, хочет ли бизнес много некачественных фич - сказали нет. Но каждые недели надо что-то выпускать.
На данный момент вижу проблему в самом скраме. Ничего кроме мелких правок не укладывается в две недели скрама. Что-то более менее достойное нельзя разбить на тестируемые куски, можно либо сделать но не протестировать - такое не хотят, либо выходит такое мелкое и изолированное, что тестер не может тестировать. Ну не пишется софт настолько мелкими самостоятельными модулями.
Но пока на весь негатив по скраму один ответ - если вы не можете есть суп вилкой, вы не правильно её применяете. Гениально же.
Поэтому в программировании я теперь люблю только деньги, и то, что можно за них купить. При том что я не свитчер, всю жизнь код пишу. И кажется я теперь понимаю прикол опенсорса - ты просто не участвуешь в этом балагане, в котором испохаблен весь дух профессии и переписаны качества хорошего программиста в угоду тем, кто платит.
Бизнес врёт, это нормально. Они просто верят, что можно «много качественных фич», и поэтому не хотят некачественных. Но много-то всё равно хотят.
Но каждые недели надо что-то выпускать.
по гайду продолжительность спринта не больше месяца. Также не обязательно, собственно, выпускать результат работы за спринт.
А почему это должны быть отдельные именно модули? Это ж изменения - они не обязаны быть модулями
Я когда ни спрашиваю "хочет ли бизнес много некачественных фич", отвечают "хотим 30% усилий которые дают 70% результата". Эта сказка качует из ума одного менеджера к другому, дает им отчитаться про "мы внедрили вот это по плану 1 неделя вместо 1 месяца, супер-топ команда и метод управления". В реальности получается костыльное минимально рабочее решение + 70% техдолга, который в геометрической прогрессии растет и сначала тормозит дальнейшую разработку, а в скором времени - блокирует. Факт, что то что таким образом написано за год надо дорабатывать еще 2 года все гонят прочь, разработчики не могут разобраться в той каше, которую из себя представляет продукт и уходят, новые нанятые какое-то время мучаются и смиряются до тех пор, пока история не повторится, внедрение фич идет медленно, менеджеры нанимают еще разработчиков и затраты растут как снежный ком, денег не хватает, клиенты и инвесторы в ярости, компания рушится.
Стандартный кейс, который встречал практически везде, где бизнес гонится за скоростью и играет "в быструю", а не "в долгую". Ситуация особенно усугубляется, если используются велосипедные решения и их разработчики становятся ключевыми, тогда скорый исход проекта в небытие еще ускорится, сколько бы строк в таблице ни выводил этот фреймворк. Исходя из этой специфики я бы все равно придерживался популярных решений (React, Vue, Angular) - так хотя бы можно отсрочить кризис в компании. Но решить его может только сам бизнес, кардинально изменив модель требований и ожиданий.
А интеллектуальная элита это простите кто? Nullопроизводители или Zaконодатели?)
В Хроме на Винде не смог воспроизвести. Возможно это какая-то МакОС специфика. А мака у меня нет. Поэтому придётся вам использовать популярные отлаженные фреймворки, которые при обновлении текста инпута будут просто сбрасывать каретку в самый конец (поведение по умолчанию в браузерах), а не пытаться оставлять её на месте, а то и привязывать к словам, как это делает $mol.
То есть если я введу в инпуте в середину слова новую букву - каретка сбросится на конец?
Если измените текст программно.
автор предлагает Пользователю (клиенту) поотлаживать
Коллегам, которые строят из себя клиентов.
Это что за жесть?
У вас там не корректный код.
Удачи с пакетом $mol_atom234 и ручным отслеживанием этого всего
Много вы видели пакетов с 234 мажорными версиями?
в прошлом комменте половина была проигнорирована
"я не собираюсь тратить время и силы на" общение с токсичными мудаками, которые думают, что я им что-то должен.
Без понятия кто у вас в ссылке повырезал подчёркивания. Можете попробовать эту ссылку: https://calc.hyoo.ru/#!sheet=vckvt1_r6xid2
Пока что ни один модуль не перевалил за 3 версию API, не выдумывайте. Но даже если и перевалит - ничего страшного.
А, это видимо хабровый типограф постарался.
Чисто там, где не сорят. У нас нет никаких импортов. А информация по всем зависимостям есть в выгрузке. Напрмиер: https://calc.hyoo.ru/web.deps.json
Число означает приоритет зависимости, который нужен для корректного разруливания циклических зависимостей.
package.json генерируется автоматически на случай, если вы захотите опубликовать пакет в нпм.
Поиск по проекту есть в любой IDE.
В одной компании мы разрабатывали свой фреймворк на базе React. И решили мы как-то сделать простое приложение для ведения заметок для проверки его в деле. Заняло у нас это несколько дней ...
Неудовлетворённый таким положением дел, я взял свой любимый конструктор $mol и сделал аналогичное приложение за 2 часа (я засекал).
Аргументы уровня "защиты Чубакки". А если кто-то выполнит ту же задачу на реакте за 2 часа, то что? Я тоже могу сказать, что напишу парсер JSON на Kotlin за 2 часа, а на Erlang за неделю. Это вообще хоть что-то говорит об этих двух языках?
А если кто-то выполнит ту же задачу на реакте за 2 часа, то что?
Рекомендую тему "самый короткий язык программирования", где автор считал проблемой скорость набора программы и максимально сократил длину операторов, а скорость набора измерял на программе вычисления факториала (потому что у него для этого был специальный оператор). Аргументы о том, что скорость набора не является ограничением ("тыщу символов в минуту набираю, но такая фигня получается") им не воспринимались и предложения сравнить на более реальных задачах не нашли отклика.
Что же касается конструкторов, то у них у всех общая проблема - задача, под которую он заточен, делается быстро, чуть в сторону - и у нас сроки вырастают в разы, а накладные расходы вообще не поддаются исчислению. Был замечательный конструктор, который для прототипирования как-то годился, но идея одного гения использовать в реальности была провалена. Приходящим программистам давалось задание сделать на его базе ядро для аналога существующего приложения, месяцы возни, что-то получалось, но это была борьба - конструктор создавал те элементы, которые умел, программист их скрывал-отключал, рисовал свои поверх, в итоге расход ресурсов вырастал в разы и время тратилось впустую. В итоге за месяц было написано ядро без использования конструктора, которое делало даже больше, чем всё, чего добились предыдущие, потребляло значительно меньше ресурсов, работало быстрее и имело сильно меньше ограничений.
Какой то поток графомании. Устал читать на десятом абзаце. Извините.
Автор напоминает чем-то dz - тот долго разрабатывал и толкал свою "вечную ос", не знаю чем все закончилось, но ничего о ней уже давно не слышал.
Согласен. Часто не хватает критики вокруг технологий и инструментов которые нас окружают.
Дмитрий делает это прекрасно (слог хороший) и соответствует фразе "критикуешь - предлагай". Вот он и предлагает, но пока это слабо подхватывается. Надеюсь у него от этого руки не опускаются
Мало профи: знают разные фреймворки и разные языки
Решения принимают люди с узким кругозором или без технического бэкграунда.
Вот что то здесь явно не так)
Тот же React - это просто разросшийся XML-шаблонизатор.
А php это просто разросшийся html-шаблонизатор.
Но наше партнёрство сорвалось с буквально такими словами: "ты просто
самый звёздный кандидат, идеально нам подходишь, но мы решили делать
проект на Реакт". То есть человек был готов доверить мне технический
успех проекта, но не был готов доверить выбор.. шаблонизатора?
То есть это как удивиться тому, что стартап решили делать на php и потому не взяли звездного разраба на другом языке, так чтоли?)
Самое интересное, что автор так и не понял что на самом деле дурит бизнес.
Не программисты дурят. Менеджеры дурят. Каждый менеджер продвигает свой проект, либо себя на более высокую позицию. И в меру своего разумения внедряет что-нибудь, на что компания выделяет деньги.
А то, что программисты получают свою ЗП, так это так принято в развитом мире.
Тут мой коллега берёт платформу 1С и делает аналог вообще за пол часа
Вы не пошутили тут?
Вот я фронт, вроде знаю все технологии, про которые рассказывает автор, и даже больше. Но вот абсолютно не могу понять, что за проблема тут решается. Пытался осилить офф. сайт, там в интродакшне картинка, ноль описания. Всё какие-то высокороувневые конструкторы. Кто-то что-то понял? Если да, как вы это сделали?
Вы про какой сайт-то?
что за проблема тут решается
Автор продаёт вам свой велосипед, ругая чужие велосипеды.
Но вот абсолютно не могу понять, что за проблема тут решается.
Автор решает проблему нужности себя на рынке. Эта статья не для программистов. Она для бизнеса.
Автор по сути пытается обмануть бизнес, заявив - вот все они фигня, а я именно тот, кто вам нужен. Купите меня.
ели дети кашку а потом бац и ответочка))))
Ровно те же выводы после почти 30 лет в велосипедостроении. Спасибо за обобщения.
https://mol.hyoo.ru/#!demo=mol_list_demo_table/section=demos
виджет для выбора дат проработан слабо. Нет возможности быстрого выбора года курсором, высота поля ввода скачет при переключении месяца.
Первый раз вижу такую противоречивую статью на Хабре. 26 тыс. просмотров, под 90 комментариев и рейтинг 0 ))) 52 на 52
Ещё одна попытка вылить серебряную пулю?
Прогресс движется к тому, что большая часть сегодняшних айтишников будет не нужна, потому что делают одно и тоже.
Называть всех тех, кто создаёт "информационные миры" - "интеллектуальной элитой современности " не совсем корректно. Одно дело код уметь писать, какой бы он эффективный не был, а другое - быть интеллектуалом. Единицы задумываются о реальных проблемах и как-то пытаются с ними работать. Большинство получают хорошую ЗП и закрывают свои потребности. Зачем им делать свою работу лучше, если это приведёт к их сокращению? Не все готовы сделать еще один шаг на уровень выше, чтобы оставаться востребованными.
С другой стороны сам бизнес работает по своим правилам. Бизнесу не нужен ваш супергибкий фреймворк, который работает в сотни раз лучше и быстрее аналогов. Ему нужно конкретное решение текущей проблемы с поддержкой этого решения. Да, бизнес чаще всего переплачивает за это, но получает рабочее решение. Взять всё переписать, чтобы получить профит - идея конечно хорошая, но чаще не реализуемая.
Есть огромное количество накопившихся системных проблем, которые просто решить не получится. Нужны фундаментальные изменения в подходах к разработке и организации информационных систем, включая работу с персональными данными. Хорошо бы всё переписывать, но другой вопрос - как это должно выглядеть, чтобы могло эволюционно развиваться в течении следующих десятков лет. А то каждый раз всё переписывать - слишком дорогая затея. IT сегодня находится во власти корпораций и пока так будет особых изменений можно не ждать, так как они не заинтересованы в эффективности \ выгодности для конечного потребителя своих услуг.
Я один такой невнимательный, что не рассмотрел плашку "на правах рекламы"?
Программисты дурят бизнес (в лице менеджеров);
Бизнес (в лице менеджеров) дурит клиента;
Клиенты дурят бизнес (через программистов);
GOTO 1
Впрочем, ничего нового.
Забавно. У большинства комментариев критикующих статью, автора или mol - ровно один минус.
Интересно
Автор действительно храбрый человек раз так смело взялся высказать такие опасные и конфликтные мысли на Хабре. Мне кажется это достойно уважения. Наверное долго пришлось карму копить.
Выскажу тогда и свои мысли.
Сколько наблюдаю за коллегами на работе и за собой, всё твёрже убеждаюсь, что в программировании много психологии: решения принимаются не объективно и бесстрастно, а на основе нравиться/не нравиться (это вызывает боль/а это крутая идея).
Но позвольте напомнить вам, что вы не рабы, а интеллектуальная элита современности.
И мне кажется, это и есть основная причина. Их слишком переоценивают и это приводит к перегибам и избалованности. Программисты начинают скучать и ищут новые "развлечения". И это приводит к большому количеству фреймворков и велосипедов.
Может я не прав и не правильно мыслю? Поправьте меня пожалуйста тогда.
Всё так, всё так.
Но Вам карму так сольют, что вы пожалеете за то, что написали правду. Дураков всегда больше чем умных)
Как программисты дурят бизнес?