Оно, таки, отличается: Проверка по бумажкам, наличие по пунктам, проход по методике испытаний. Внешне работает? Отлично, закорючка военпреда в протоколе. Далее автоматом понатыкать при помощи софтины сигналов для лога во все функции, убрать то, что ломает сборку, отчитаться о причинах выпиливания таблицей, сделать прогон, свести статистику вызовов и сверить с табличкой по методике для института сертификации. Отлично, закорючка военпреда в протоколе. Ах, да! Забыл про собрать умных «конструкторов» перед огромным ЖК-«ящиком» в пол стены, показать софтинку, дать ставленникам от конкурентов в составе комиссии время поковырять заботливо записанные в блокнот ошибки, а уже дальше все прелюдии с застольями и разговорами.
Речь в ветке разговора была про сертификаты. Если же говорить о выборе продукта, то мне ли рассказывать, как строятся заказы? На вооружении стоит «ультрасовременный» Debian 7 Squeez под названием «Astra Linux 1.4/1.5» 2012-го года выпуска, который даже не умеет заводить современные XHCI-контроллеры, чем вызывает взрыв проклятий в адрес производителя во время заказа на поставку оборудования с группой исполнения 1.10, когда на том же «кондовище» у Alt-а проблем нет.
Версии ядра разные? Привет сертификатам!
Согласен, на AL 1.6 с его вырвиглазно красным desktop-ом (главное — звезда в пол экрана!) подобной проблемы нет. Там есть проблема убитого при помощи selinux-а usability и гарантированно едущих переменных окружения при ручном создании пользователя…
Привет хвалёной безопасности! Даже у страшного, как ядерная война, МСВС-а с его колхозной «мандатной» библиотекой таких извращений не наблюдалось! Согласен, у Альта с этим тоже не порядок, но там хотя бы нет строгой ориентированности на «оборонку».
Согласен, бизнес знатно мимикрировал за эти годы, практически отправив в утиль основы концепции. Самый заметный признак оного — «свободное» ПО стало «жиреть» вслед за проприетарным. Как говорится, «бабло побеждает науку».
Волшебное слово «сертификат» — бумажка, от которой оборонный «эффективный» бюрократ получает удовольствие, сравнимое с эйфорией наркомана, а разработчики — головную боль и нежелание больше слышать это проклятое слово. И если первые получают закрытие этапа ОКР-а, значит выплату из бюджета, то вторые — возможность переключить, наконец, внимание с сиюминутно «важного» процесса сертификации по ОКР-у с трёхмесячной просрочкой сдачи на остальные 11-12 ОКР-ов, повешенных на отдел «эффективными» прожектёрами из руководства НТЦ/НТК.
Бумажка высоко ценится, ведь если человек с трёхэтажными регалиями, посещающий «овальный» кабинет в здании Дома Правительства Российской Федерации в костюме-тройке и красиво вещающий про «современные технологии» с лазерной указкой на коллаже диаграмм, ещё может вызвать умное кивание головами «коллег» словом «сертификат», то инженер советской закалки, вещающий об отсутствии стандартов разработки и единых форматах, лишь вызовет на рядах праздную болтавню «деловых людей», не имеющих никакого отношения к процессу разработки.
Они же пришли ходить по ковровым дорожкам, любоваться на хрустальные светильники, деревянные поручни, российский герб в два этажа высотою над центральной лестницей, заводить связи, дающие гарантию трудоустройства, если на своём предприятии бюджет треснет по швам, а 80% разработчиков уволятся нафиг.
Сертификат — это не о достоверности, а о бюрократии: «Без бумажки ты — букашка, а с бумажкой — человек!». Единственное, что может засвидетельствовать сий документ — факт успешного исполнения приложения, вызовы которого лепятся в начало каждой функции/метода и сыплющего бессмысленный лог о процентном применении данных функций. Если всё бьётся с цифрами лимитов в правилах, значит все довольны, военпреды тоже — можно пилить…
Сертификат не является доказательством качества ПО.
Я так понял, суждение лежит в плоскости доверия к результатам тестирования. Whuthering и amarao уповают на результаты оценок свободного сообщества, способного самостоятельно проверить наработки компаний. В таком ключе решение может быть лишь радикально-ориентированным в одном из двух направлений:
1) Все изменения публикуются на проверку сообществом;
2) Сообщество разработчиков создаётся своё для своих же нужд. Так сказать, ОборонНет-комьюнити с участниками не ниже 3-ей формы допуска.
Я не буду вмешиваться в дебаты про Java, это кажется не очень продуктивно
Ну, если делать выжимку по теме, то звучит она так: IDE для C++, ИМХО, лучше писать на языках, компилируемых в набор инструкций процессора. Ибо подсветка — ещё цветочки, а запуск программы в debug-режиме — вот это уже нагрузка серьёзная.
Кстати, уже который раз ищу, но не нахожу подобного проекта: Неужели никто не задумывался о реализации JRE из OpenJDK в виде модуля ядра?
И да, можно написать подсветку кода для таких простых языков на лексере, а в C++ нельзя. Потому что есть вот такие примеры.
Ну, define подсвечивать, по моему скромному мнению, просто незачем. Впрочем, здорово, если такая функция имеется, но сам он — своего рода «костыль», без которого под час просто никуда.
надо в кланг напихать все те 100500 оптимизаций, отложенных резолвов и пр., которые уже заимплементированы в нашем изначальном Java-парсере
Тогда проще создать свой анализатор, чтобы органично согласовать с логикой IDE.
В компаниях из новой категории «крипто-биржи» занимаются анализом кода, написанного на совершенно разных языках, с целью автоматического построения и анализа его иерархии — собирают алгоритмы. Так что, я бы не назвал идею написания своего стат-анализатора бесперспективной.
Но верите или нет, наш оптимизиронный «медленный» Java-парсер, показывает производительность по индексации лучше, чем просто взять и клангом все это добро обрабатывать так, как это кланг как компилятор делает.
Охотно верю. Сам его прикручивал в проект: тяжёлая штука. Но он не единственный противоречивый пример.
В одном проекте, написанном на C++/Qt, ядро парсера данных было лишено вкраплений Qt, а во многих местах даже на «голом СИ». Причина — жёсткие требования к производительности. Стояла задача выводить в генерируемом графическом контексте надписи с различной обработкой в качестве, не уступающем самой ОС.
Применили FreeType, т.к. он показал хорошую производительность. Однако, эта библиотека не могла определить габариты глифа символа без его полного рендеринга. Представляете, чего стоила задача предварительно оценить габариты надписи? Пришлось кэшировать эти самые габариты посимвольно коллекциями в памяти для ускорения. Нет, внутри библиотеки нашли внутренние методы оценки, но применять не стали, чтобы не включать библиотеку в проект. Тем более, что под Windows используется WinAPI. А влить в багтреккер так же не могли из-за глухой закрытости проекта.
Разрабатывал рендер надписей с эффектами, компоновкой и смешением с подложкой контекста на базе этой библиотеки. Лично не хватало только одного: расчёта габаритов глифов без их рендеринга и, соответственно, генерации массива графического контекста. ИМХО, это — единственный бич данной либы. 100 пудов решаемый, но для этого её надо либо изменять, либо форкать. Ну и огромные глифы долго рендерит из-за закраски.
Правильно, надо подсаживать программеров инструкциями на конкретные IDE, напрочь игнорируя суть действий. А то начнёшь указывать на флаги компиляторов — они научатся сравнивать сами компиляторы, изучать их. Глядишь, составят конкуренцию на рынке труда… Оно надо? Вот-вот! Надо нарисовать ещё одну «мартышкинскую» инструкцию и сопроводить это восхвалением 21-го века, мол, нынче модно быть не создателем, а потребителем.
Вы правда думаете, что дело только в том, что платформа именно на Java?)
Где я такое написал? О_О
платформе 19 лет уже и она вылизана довольно хорошо
Это — заблуждение номер раз. Вылизанных платформ нет. Есть первоначальные задачи, которые ставились перед архитекторами платформы. В число этих задач не входило написание GUI-приложений от слова «совсем».
Дело в том, что ее архитектура не была изначальна расчитана на C++, где на каждый чих нужно код именно резолвить, а не просто парсить.
А это-то тут при чём? О_О
IDE — суть автоматизированные текстовые редакторы, кто бы какие ярлыки на них ни вешал. Для редактируемого текста не имеет значения, на каком языке они написаны. Это имеет значение лишь для разработчика и платформы, под которую пишется само ПО. Не умножайте сущности!
Ну потому что даже чтобы покрасить правильно плюсовый код надо понять перед вами тип или не тип, то есть резолв сделать контекстный
А для работы с программным кодом на других языках как будто не требуется статического анализатора?
Так что Java как таковая тут не при чем.
Согласен, язык программирования ни при чём. А при чём виртуальная машина, предназначенная исполнять байт-код — результат компиляции этого самого языка, и её архитектура, которая аукается даже после Jit-компиляции.
проблемы, которые есть решаемые на текущей платформе
Безусловно они есть и решаемы в рамках текущей платформы, но они не столь фундаментальны, как вопрос использования этой «платформы». Программной, прошу заметить, платформы, не аппаратной. Java создавалась для решения совершенно иных задач. Это — инструмент для разработки backend-ПО в среде WEB. Но его ошибочно использовали для разработки мобильного ПО, а дальше и на desktop переползло… Всему причина — цена отладки ПО, за которую бизнес бездумно, без каких-либо тормозов вцепился, как в «ману небесную». Теперь сам же пожинает плоды этого решения. Конечно же производители «железа» дружно промолчали — им это выгодно. Вот интересное решение для обособленных задач под названием Java превратилось в проблему.
гораздо меньшего, чем написать все с нуля
Согласен, решение, лежащее в основе проекта, влечёт впоследствии к зависимости от него. Подобное утверждение корректно по отношению к любому языку программирования. Но, ведь, проблема-то не в языке. Даже в C++ есть ряд провалов по производительности относительно языка C, а у последнего — относительно Assembler-а.
второй парсер у нас кстати на C++ (на кланге)
Может стоило приложиться тогда к доработке его фукционала под свои требования? Open Source же, ё-моё!
проблемы эти решает не только CLion, а вся команда платформы
Чтобы ПО на Java было столь же производительным, под него нужно менять архитектуру процессоров.
Конечно, нас часто спрашивают про улучшения производительности. Я повторюсь, для нас это наиболее приоритетная задача, но точечных изменений получается сделать не много, а глобальные требуют времени больше, чем 1-2 релизных цикла.
Неужели задача отказаться от написания проекта на Java и перейти на C/C++ настолько не решаемая? В конце концов, можно даже использовать Qt. А так это будет бесконечный танец вокруг того, что изначально не рассчитывалось на производительность.
Бывают неявные преимущества, которыми может «оплачиваться» совместительство. К примеру, у компании бюджет не особо резиновый, короткий портфель заказов. Получая расширенные обязанности, требуешь расширенные права. В итоге напрягаешься, расширяешь портфель заказов, линейку продукции или создаёшь новое направление, добиваясь увеличения доходов компании естественным образом, а там и повышение в должности и зарплате. Но с этого момента неизбежно переходишь из разряда разработчиков в руководители проектов. В общем, авантюризм.
К счастью пока ещё далеко не все программисты хотят просто зашибать бабло. И не думаю что это сильно изменится вне зависимости от того сколько подобные люди будут рекламировать своё мировоззрение :)
Надеюсь, коллега!) Не хотелось бы нам такого будущего по принципам прошлого.
но и слишком высоко задирать планку тоже не стоит :)
Понимаю. Далеко не всем охота разбираться в «кишках» процессора, чтобы писать приложения. Кто-то преследует лишь цель реализации алгоритма. Как в своё время на FORTRAN (правильно писать название в верхнем регистре! :D Кто знает, тот поймёт), а позднее на Pascal и его наследнике Object Pascal, неразрывно связанном со средой разработки Delphy (которую, почему-то, привыкли считать языком программирования), писали приложения для науки физики, химики, даже физики-ядерщики. На то и существуют кроссплатформенные фреймворки, да библиотеки.
Не смотря на весь бескомпромиссный, на первый взгляд, скепсис, я был бы рад созданию нового, идеологически более целостного, языка программирования с прямым управлением памятью и куда лучшей парадигмой, нежели у стека C/C++. Даже первое время был неподдельный интерес к GoLang, но, увы, «не оно»… Т.е., задача всё ещё является не решённой. Может Qt-Project когда-нибудь дойдут до этого?
По мне, так он вообще плохо согласован. Однако, он — чуть ли не лучший язык с прямым управлением памятью. Не зря же «мелкомягкие» развивают C#, а «огрызок» ранее поддерживал развитие Objective-C. Даже применение Qt вносит некоторую гармонию в программирование на C++. Кстати, к слову, в последнем упомянутом фреймворке много заимствований из Java.
А чем концепция виртуальной машины идёт вразрез с научной логикой?
«Вот дом, который построил Джек...». Самим фактом запуска приложений на платформе через программную надстройку в виде виртуальной машины! Чтобы не распинаться кучей текста, дам ссылку на статью Кольца, уровни привилегий и защита в x86.
Запуская приложения на том же Android OS, мы беспощадно и максимально бестолково расходуем ресурсы коммуникатора, по маразму маркетологов Google обозванного «смартфоном». А самый критически важный ресурс — заряд аккумулятора. А всё потому, что кто-то забивает гвозди микроскопом запускает Java-приложения на мобильной платформе. И даже Jit-компиляция не особо спасает ситуацию.
Это если брать случай гипотетической компиляции Java-кода в LLVM
Увы, «300 рублей не спасут отца русской демократии». Проблема не в том, как оно компилируется. Проблема в том, что компилируется. С самого начала Java-код вкупе с библиотеками JVM — не эффективный по своей архитектуре. Это — как заворачивать гайки пассатижами: универсально, почти под любой диаметр, компактно, но шлицы-то методично уничтожаются, а грани — стачиваются. Ну не предназначено оно для этого!
Не спорю, каждому своё. Однако, автор преподносит свои рекомендации как «единственно верный способ не остаться за бортом современности», адресуемый всем программистам в России. Причём, он полагает, что смену формации рынка уже не остановить. Т.е., фриланс и удалённая работа по контракту — это реальность.
Но, если бы дело было только в этом… Кажется, что он говорит лишь о сфере программирования, но это не совсем так. На примере данной сферы труда, он декларирует довольно стандартные либерально-капиталистические установки:
— Будь универсален (будь не только программист)!
— Старайся угодить работодателю (докажи, что ты не верблюд)!
— Свободно прыгай между работами (о постоянном доходе забудь)!
— Посвящай работе свободное время (саморазвитие — твоя личная проблема)!
— Умей навесить на себя ценник и выгодно продаться (таких как ты тут — миллион, найдутся и подешевле)!
Вот за это я и унижаю автора как профессионала, программиста и человека в целом: за то, что обретая подобное мировоззрение, он имеет наглость навязывать его как истину в последней инстанции, принижая специалистов, сосредоточенных только на своей специализации. Т.е., принижает программистов за то, что они не торгаши. Чувствуете аналогию с медведевским «Если врачам нечего есть, так пусть идут в бизнес!». Так же и с программистами: Из человека-учёного он должен стать продажным исполнителем.
Скажем так, я воспринимаю капитализм — критической ошибкой в логике системы человеческих взаимоотношений и намекаю на его врождённую деструктивность и недееспособность. Принцип «Мухи — отдельно, котлеты — отдельно» предписывает разделить финансовую часть и процесс разработки. Автор статьи — из другого лагеря и довольно цинично подменяет понятия в угоду оправдания своего мировоззрения крупного капиталиста.
Следование его логике не даст программистам долгосрочных перспектив, но позволит научиться некоторое время успешно конкурировать за «кусок пирога», пока оный не будет окончательно съеден. Уменьшение количества конкурентов «схлопнет» рынок, деньгами которого они питаются. «Художник будет голодным» не ради искусства, а вопреки ожиданиям. Как можно заработать на искушённом зрителе в условиях конкуренции монополий? Дворцу не нужны технологии, чтобы править.
Признаю, Вы довольно справедливо критикуете именно этот абзац. В самом деле, не совсем верно утверждать, что Java популярен только из-за большей окупаемости. Простота языка программирования — понятие субъективное, зависит от образа мышления, привычек и особенностей логики программиста. Изначально этот язык был рассчитан на применение в ВЕБ-среде в качестве, нынче называемом «backend», однако растиражированная истерия о «дыре в безопасности» практически поставила на нём крест. И если бы не решение компании Nokia, а впоследствии и Google, вряд ли бы он стал настолько популярным к текущему моменту.
Мобильность бинарного кода приложений, а так же аппаратная абстракция от «железа», присущие языку, сыграли с рынком IT злую шутку: То, с чем на мобильных платформах должно было справляться сочетание фреймворков на C++ в купе с LLVM, было потеснено категорически спорным применением Java, а до того и «кастрата» под названием J2SE. Но «из песни слов не выкинешь», мы имеем в конечном итоге массовое помешательство, идущее в разрез с научной логикой, но органично вписываемое в бизнес-модели. Как это часто бывает, деньги победили рассудок. Осталось только дождаться «апокалипсиса». :)
Хотя вопрос мог решиться соглашениями между разработчиками ПО и процессоров, порождающими в конечном итоге новую архитектуру. Бизнес традиционно извращает технологическое развитие, и всё — из-за остервенелой драки за куски пирога под названием «рынок»: Максимально заработать, прилагая минимальные усилия, избегая какой-либо ответственности — логика зарвавшегося подростка, не находите? Жаль, что идеология языка Java попала в эту «мясорубку», хотя, если учитывать выпуски сырых стандартов 11-14-17, то досталось и языку C++…
Почитал я этот опус, несколько раз встретил рукой лицо и согласился с автором: в современной разработке действительно есть пугающие тренды. И одним из них являются подобные ему «продвинутые». Что ж, пойдём по порядку:
Привычка — страшная сила. Она заставляет сопротивляться изменениям, мешает развитию
А ещё из привычек складываются навыки.
Мы готовы к новому и можем не дожидаться, пока будущее наступит, и придется к нему адаптироваться. Мы можем выйти навстречу, знать бы только в какую строну.
Т.е., анализ современных технологий, расчёт эффективности новых решений и планирование рефакторинга проектов под них — более не востребованные подходы?
Егор Бугаенко знает, что нужно делать уже сейчас, чтобы и через 5–10 лет оставаться востребованным программистом. Его идеи, как и всегда, могут показаться спорными
Он не знает, а лишь полагает, что знает. Некоторые его идеи попахивают откровенным дилетантством.
Да и в том, что программисту необходим английский язык, вряд ли могут быть разные мнения
Ещё как могут быть. Видимо Егор забыл, что такое «порог вхождения» и чем он определяется. Глобализм — штука обоюдоострая, а местами и вовсе — вредоносная.
А вот по остальным пунктам будет интересно узнать мнение сообщества в комментариях
Т.е., по вопросу английского он не готов расставаться с иллюзиями?
Он думает, что код важен, а вся остальная упаковка вторична
Человек всего лишь верен принципам кроссплатформенности. Далее автор кидает море умных английских терминов, забывая, что всё решается простыми диаграммами. Ещё ниже автор прокатывается по программисту, который ушёл как одиночка. Однако, ему даже не приходит в голову, что мир не вертится вокруг вглядов автора. Программист просто послал куда подальше весьма проблемного контрибьютера.
На мой взгляд, сейчас быть одиночками неправильно. Рынок движется в сторону более многочисленных населенных команд: в них будет больше людей, они будут чаще приходить и уходить.
Быть одиночками действительно неправильно, но может стоит понять причину ухода людей? Для начала прекратить мыслить «модными терминами» и обратиться к машинной сути конечного продукта. Маркетинговые извращения в сфере IT ещё ни разу не приносили пользу науке программирования. они лишь бесконечно множат сущности, вызывая у всех участников синдром «рассеянного внимания».
Динамика человеческих ресурсов движется в сторону более высокой текучки
Может не стоит путать мягкое с тёплым? Капиталистическая машина производства стремится превратить человека во взаимозаменяемый болтик, чтобы экономить на демпинге цен на услуги разработчиков.
он должен открыть readme-файл
Автор видел когда-нибудь нормальную производственную документацию? Или говоря о современных тенденциях, он предлагает махровые анахронизмы?
Всего у 20–30% программистов есть собственное опубликованное приложение, а должно быть у всех
Перефразирую: «Профессиональное обучение специалиста — проблема самого специалиста». Автор, видимо, «прикоснулся к бюджету», раз позволяет себе подобную ересь.
плох тот программист, у которого нет pet projects
Плох тот программист, который провоцирует коллег на самостоятельное набивание шишек.
Второй страх, на мой взгляд, — это деньги
Ниже идёт ещё больше ереси, но уже завязанной на финансовой стороне вопроса. Программист, товарищ автор, — это человек учёный. Он не должен заниматься финансовой стороной вопроса. Это — откровенно лишний и даже деструктивный подход, смешивать две совершенно различные спецификации воедино. Ведёт к сведению роли разработчика в знаменитое «И швец, и жнец, и на дуде игрец». Иначе говоря, этот подход придуман кастой топ-менеджеров с целью экономии за счёт персонала. не надо все стрелки переводить на исполнителей, превращая их в «эффективных» — такие занимаются уже не разработкой, а выколачиванием денег. Постепенно им становится наплевать на результат своей работы — главное, чтобы деньги платили и не более. Автор, это не страх, это — отвращение к чужеродному для науки элементу!
Время full-time разработчиков с фиксированной оплатой уходит.
Приходит время «эффективных» менеджеров. :)
много лет писали на C++, а потом поняли, что нужно писать на Java
Только не надо выдавать массовое помешательство за прогресс! Программисты переходят с C++ на Java лишь потому, что за неё больше и чаще платят. Естественно, ведь той же самой касте топ-менеджеров выгоднее, когда время на отладку сокращается за счёт отсутствия необходимости следить за выделением памяти. Этим Java занимается сборщик мусора. Другой вопрос, сколько ресурсов потребляет приложение, запускаемое на платформе через виртуальную машину? А ещё вспомним, через какие тернии приходится реализовывать то, что по умолчанию доступно через системные API. А в той сфере, для которой и создавалась Java-машина, она присутствует лишь частично. Чаще всего используется не по назначению.
Рынок становится глобальным, удаленный доступ на рынок труда все проще и проще
Ага, только работодателям забыли об этом сообщить. Ведь до сих пор программист под боком оплачивается лучше, чем некий удалённый фрилансер, если только он не уникум. Опять же, кто платит деньги, тот и заказывает музыку. Теперь я убедился: автор — неизлечимый глобалист. И этот человек нас учит? Не смотря на слащавые сказки о великом фрилансе, автор совершенно умалчивает, что причина данного явления кроется в другом: развитие регионов в стране неравномерно. Человек, работая фрилансером в Краснодарском крае на московскую компанию, готов наступить себе не агорло и принять всю декларируемую автором ересь лишь потому, что так больше платят. Т.е., проблема-то не в способе зарабатывания денег, а в их отсутствии в регионе проживания специалиста.
Мне, как работодателю, такие люди ценнее
Весьма грустное упущение, что люди, подобные автору, становятся работодателями. Впрочем, при капитализме работа по методу «ничего личного, только бизнес» и приводит к продвижению по карьерной лестнице. Увы, сами специалисты пока что не способны объединяться с целью уничтожения основы для столь циничного лицемерия.
Ключевое слово «продавайтесь». Всё с автором понятно: Он к разработчикам отношения больше не имеет, но позволяет себе учить.
Хорошие программисты пишут код, лучшие — тикеты
Хорошие программисты пишут код, лучшие — занимаются разработкой. Автор опять смешал тёплое с мягким. Ну точно воспитанник эпохи.
Думаю, причина в страхе тикетных систем
А метод «сначала поговорить, устранить разногласия, а потом написать тикет» в расчёт уже не берётся? Бюрократизация вместо социализации?
одна из главных проблем, с которой мы сталкиваемся: люди просто не умеют разбивать задачу на более мелкие
Потому, что это задача не программиста, а системного архитектора. Стыдно такое не знать! Уж тем более — работодателю! Я уже сомневаюсь в квалификации автора…
В IT-сфере существует русскоязычное сообщество, с которым, мне кажется, надо бороться всеми силами
Автор, по видимому, не в курсе понятия «порог вхождения». Ну правильно: Вера в глобализм затмевает способность критически оценивать процесс самообразования подчинённых. Ах, да… у автора же обучение специалистов — проблема самих специалистов… Т.е., автор всячески дистанцируется от этой проблемы. Русскоязычное сообщество нужно для увеличения количества специалистов, а так же снижения количества времени, необходимого для изучения материалов. А специалист, который делает это свободно с применением английского языка, вряд ли может называться «русским». У него даже логика перестраивается соответствующим образом. он больше не участвует в развитии отечественной науки. Бороться надо всеми силами с подходом «only English формат». А «глобальный рынок» — весьма иллюзорное понятие. Он глобальный ровно до тех пор, пока это выгодно носителям «международного» языка. Автор уже напоминает «свидетеля Иеговы»…
Сейчас во многом мир меняется и уходит в сторону от программистов, которые хорошо знают алгоритмы и разбираются в математике, к тем, кто умеет компоновать код, собирая компоненты воедино...
..., но совершенно не понимает, как работает та шайтан-машина, для которой он пишет код. Т.е., узко направленный специалист-компоновщик. Раньше таких называли «конфигураторами», а теперь они называются «программистами». В какой-то момент программирование начнут воспринимать как «магию», а компьютер или цифроблок, если только бессовестные маркетологи не назовут его какой-нибудь smart-хренью, будет восприниматься как «артефакт». Давай, автор, призывай программистов к профессиональной деградации, ведь ты же сможешь на этом не слабо заработать! Ты же не программист, ты — капиталист!
Нет фолловеров на GitHub — ты не настоящий программист
Программист, провоцирующий коллег на самостоятельное набивание шишек, — не настоящий программист. Он — вредитель.
Я думаю, мы станем сборщиками — ассемблерами, а не кодерами
А кто в этом виноват? Кто прямо в этой статье забивает ещё один гвоздь в крышку гроба профессии программиста? Сознательность не приносит дохода, ведь, правда?
Если вокруг вас маленькое сообщество — вы плохой разработчик
Плохой разработчик тот, кто не признаёт существование сообществ по единству интересов. С малым сообществом проще работать, а ещё проще с ним договориться. Но это же не выгодно большому бизнесу, правда?
в 2029 это будет критическим показателем вашего профессионализма
Если только подобная политика не приведёт к технологическому краху из-за утери методов воспроизведения технологий.
В общем, что могу сказать, статья носит откровенно вредоносный характер, пагубно влияющий на неокрепшие умы. Новая поросль потом не поймёт, откуда при таком количестве «новых» и «современных» технологий столь стремительно множатся ошибки и сбои систем городского жизнеобеспечения. А когда это всё навернётся, не обнаружится того самого специалиста, способного при помощи «кувалды и какой-то там матери» заставить это всё работать хотя бы в пол силы. А всё потому, что «человек-творец» превращается в «квалифицированного потребителя», который знает, как «заколачивать деньги», но таких, как он, — великое множество, а «пирога на всех не хватит». И какими словами, интересно, он будет вспоминать автора данной статьи, если вообще вспомнит о его существовании? Когда пирога перестанет хватать даже на автора, он «запоёт» совсем другими словами, а поздно! Сам создал, сам и расхлёбывай! «За что боролся, на то и напоролся!».
Оно, таки, отличается: Проверка по бумажкам, наличие по пунктам, проход по методике испытаний. Внешне работает? Отлично, закорючка военпреда в протоколе. Далее автоматом понатыкать при помощи софтины сигналов для лога во все функции, убрать то, что ломает сборку, отчитаться о причинах выпиливания таблицей, сделать прогон, свести статистику вызовов и сверить с табличкой по методике для института сертификации. Отлично, закорючка военпреда в протоколе. Ах, да! Забыл про собрать умных «конструкторов» перед огромным ЖК-«ящиком» в пол стены, показать софтинку, дать ставленникам от конкурентов в составе комиссии время поковырять заботливо записанные в блокнот ошибки, а уже дальше все прелюдии с застольями и разговорами.
Версии ядра разные? Привет сертификатам!
Согласен, на AL 1.6 с его вырвиглазно красным desktop-ом (главное — звезда в пол экрана!) подобной проблемы нет. Там есть проблема убитого при помощи selinux-а usability и гарантированно едущих переменных окружения при ручном создании пользователя…
Привет хвалёной безопасности! Даже у страшного, как ядерная война, МСВС-а с его колхозной «мандатной» библиотекой таких извращений не наблюдалось! Согласен, у Альта с этим тоже не порядок, но там хотя бы нет строгой ориентированности на «оборонку».
Бумажка высоко ценится, ведь если человек с трёхэтажными регалиями, посещающий «овальный» кабинет в здании Дома Правительства Российской Федерации в костюме-тройке и красиво вещающий про «современные технологии» с лазерной указкой на коллаже диаграмм, ещё может вызвать умное кивание головами «коллег» словом «сертификат», то инженер советской закалки, вещающий об отсутствии стандартов разработки и единых форматах, лишь вызовет на рядах праздную болтавню «деловых людей», не имеющих никакого отношения к процессу разработки.
Они же пришли ходить по ковровым дорожкам, любоваться на хрустальные светильники, деревянные поручни, российский герб в два этажа высотою над центральной лестницей, заводить связи, дающие гарантию трудоустройства, если на своём предприятии бюджет треснет по швам, а 80% разработчиков уволятся нафиг.
Сертификат — это не о достоверности, а о бюрократии: «Без бумажки ты — букашка, а с бумажкой — человек!». Единственное, что может засвидетельствовать сий документ — факт успешного исполнения приложения, вызовы которого лепятся в начало каждой функции/метода и сыплющего бессмысленный лог о процентном применении данных функций. Если всё бьётся с цифрами лимитов в правилах, значит все довольны, военпреды тоже — можно пилить…
Сертификат не является доказательством качества ПО.
1) Все изменения публикуются на проверку сообществом;
2) Сообщество разработчиков создаётся своё для своих же нужд. Так сказать, ОборонНет-комьюнити с участниками не ниже 3-ей формы допуска.
Кстати, уже который раз ищу, но не нахожу подобного проекта: Неужели никто не задумывался о реализации JRE из OpenJDK в виде модуля ядра?
Ну, define подсвечивать, по моему скромному мнению, просто незачем. Впрочем, здорово, если такая функция имеется, но сам он — своего рода «костыль», без которого под час просто никуда.
Тогда проще создать свой анализатор, чтобы органично согласовать с логикой IDE.
В компаниях из новой категории «крипто-биржи» занимаются анализом кода, написанного на совершенно разных языках, с целью автоматического построения и анализа его иерархии — собирают алгоритмы. Так что, я бы не назвал идею написания своего стат-анализатора бесперспективной.
Охотно верю. Сам его прикручивал в проект: тяжёлая штука. Но он не единственный противоречивый пример.
В одном проекте, написанном на C++/Qt, ядро парсера данных было лишено вкраплений Qt, а во многих местах даже на «голом СИ». Причина — жёсткие требования к производительности. Стояла задача выводить в генерируемом графическом контексте надписи с различной обработкой в качестве, не уступающем самой ОС.
Применили FreeType, т.к. он показал хорошую производительность. Однако, эта библиотека не могла определить габариты глифа символа без его полного рендеринга. Представляете, чего стоила задача предварительно оценить габариты надписи? Пришлось кэшировать эти самые габариты посимвольно коллекциями в памяти для ускорения. Нет, внутри библиотеки нашли внутренние методы оценки, но применять не стали, чтобы не включать библиотеку в проект. Тем более, что под Windows используется WinAPI. А влить в багтреккер так же не могли из-за глухой закрытости проекта.
Это — заблуждение номер раз. Вылизанных платформ нет. Есть первоначальные задачи, которые ставились перед архитекторами платформы. В число этих задач не входило написание GUI-приложений от слова «совсем».
А это-то тут при чём? О_О
IDE — суть автоматизированные текстовые редакторы, кто бы какие ярлыки на них ни вешал. Для редактируемого текста не имеет значения, на каком языке они написаны. Это имеет значение лишь для разработчика и платформы, под которую пишется само ПО. Не умножайте сущности!
А для работы с программным кодом на других языках как будто не требуется статического анализатора?
Согласен, язык программирования ни при чём. А при чём виртуальная машина, предназначенная исполнять байт-код — результат компиляции этого самого языка, и её архитектура, которая аукается даже после Jit-компиляции.
Безусловно они есть и решаемы в рамках текущей платформы, но они не столь фундаментальны, как вопрос использования этой «платформы». Программной, прошу заметить, платформы, не аппаратной. Java создавалась для решения совершенно иных задач. Это — инструмент для разработки backend-ПО в среде WEB. Но его ошибочно использовали для разработки мобильного ПО, а дальше и на desktop переползло… Всему причина — цена отладки ПО, за которую бизнес бездумно, без каких-либо тормозов вцепился, как в «ману небесную». Теперь сам же пожинает плоды этого решения. Конечно же производители «железа» дружно промолчали — им это выгодно. Вот интересное решение для обособленных задач под названием Java превратилось в проблему.
Согласен, решение, лежащее в основе проекта, влечёт впоследствии к зависимости от него. Подобное утверждение корректно по отношению к любому языку программирования. Но, ведь, проблема-то не в языке. Даже в C++ есть ряд провалов по производительности относительно языка C, а у последнего — относительно Assembler-а.
Может стоило приложиться тогда к доработке его фукционала под свои требования? Open Source же, ё-моё!
Чтобы ПО на Java было столь же производительным, под него нужно менять архитектуру процессоров.
Неужели задача отказаться от написания проекта на Java и перейти на C/C++ настолько не решаемая? В конце концов, можно даже использовать Qt. А так это будет бесконечный танец вокруг того, что изначально не рассчитывалось на производительность.
Понимаю. Далеко не всем охота разбираться в «кишках» процессора, чтобы писать приложения. Кто-то преследует лишь цель реализации алгоритма. Как в своё время на FORTRAN (правильно писать название в верхнем регистре! :D Кто знает, тот поймёт), а позднее на Pascal и его наследнике Object Pascal, неразрывно связанном со средой разработки Delphy (которую, почему-то, привыкли считать языком программирования), писали приложения для науки физики, химики, даже физики-ядерщики. На то и существуют кроссплатформенные фреймворки, да библиотеки.
Не смотря на весь бескомпромиссный, на первый взгляд, скепсис, я был бы рад созданию нового, идеологически более целостного, языка программирования с прямым управлением памятью и куда лучшей парадигмой, нежели у стека C/C++. Даже первое время был неподдельный интерес к GoLang, но, увы, «не оно»… Т.е., задача всё ещё является не решённой. Может Qt-Project когда-нибудь дойдут до этого?
«Вот дом, который построил Джек...». Самим фактом запуска приложений на платформе через программную надстройку в виде виртуальной машины! Чтобы не распинаться кучей текста, дам ссылку на статью Кольца, уровни привилегий и защита в x86.
Запуская приложения на том же Android OS, мы беспощадно и максимально бестолково расходуем ресурсы коммуникатора, по маразму маркетологов Google обозванного «смартфоном». А самый критически важный ресурс — заряд аккумулятора. А всё потому, что кто-то
забивает гвозди микроскопомзапускает Java-приложения на мобильной платформе. И даже Jit-компиляция не особо спасает ситуацию.Увы, «300 рублей не спасут отца русской демократии». Проблема не в том, как оно компилируется. Проблема в том, что компилируется. С самого начала Java-код вкупе с библиотеками JVM — не эффективный по своей архитектуре. Это — как заворачивать гайки пассатижами: универсально, почти под любой диаметр, компактно, но шлицы-то методично уничтожаются, а грани — стачиваются. Ну не предназначено оно для этого!
Но, если бы дело было только в этом… Кажется, что он говорит лишь о сфере программирования, но это не совсем так. На примере данной сферы труда, он декларирует довольно стандартные либерально-капиталистические установки:
— Будь универсален (будь не только программист)!
— Старайся угодить работодателю (докажи, что ты не верблюд)!
— Свободно прыгай между работами (о постоянном доходе забудь)!
— Посвящай работе свободное время (саморазвитие — твоя личная проблема)!
— Умей навесить на себя ценник и выгодно продаться (таких как ты тут — миллион, найдутся и подешевле)!
Вот за это я и унижаю автора как профессионала, программиста и человека в целом: за то, что обретая подобное мировоззрение, он имеет наглость навязывать его как истину в последней инстанции, принижая специалистов, сосредоточенных только на своей специализации. Т.е., принижает программистов за то, что они не торгаши. Чувствуете аналогию с медведевским «Если врачам нечего есть, так пусть идут в бизнес!». Так же и с программистами: Из человека-учёного он должен стать продажным исполнителем.
Следование его логике не даст программистам долгосрочных перспектив, но позволит научиться некоторое время успешно конкурировать за «кусок пирога», пока оный не будет окончательно съеден. Уменьшение количества конкурентов «схлопнет» рынок, деньгами которого они питаются. «Художник будет голодным» не ради искусства, а вопреки ожиданиям. Как можно заработать на искушённом зрителе в условиях конкуренции монополий? Дворцу не нужны технологии, чтобы править.
Мобильность бинарного кода приложений, а так же аппаратная абстракция от «железа», присущие языку, сыграли с рынком IT злую шутку: То, с чем на мобильных платформах должно было справляться сочетание фреймворков на C++ в купе с LLVM, было потеснено категорически спорным применением Java, а до того и «кастрата» под названием J2SE. Но «из песни слов не выкинешь», мы имеем в конечном итоге массовое помешательство, идущее в разрез с научной логикой, но органично вписываемое в бизнес-модели. Как это часто бывает, деньги победили рассудок. Осталось только дождаться «апокалипсиса». :)
Хотя вопрос мог решиться соглашениями между разработчиками ПО и процессоров, порождающими в конечном итоге новую архитектуру. Бизнес традиционно извращает технологическое развитие, и всё — из-за остервенелой драки за куски пирога под названием «рынок»: Максимально заработать, прилагая минимальные усилия, избегая какой-либо ответственности — логика зарвавшегося подростка, не находите? Жаль, что идеология языка Java попала в эту «мясорубку», хотя, если учитывать выпуски сырых стандартов 11-14-17, то досталось и языку C++…
А ещё из привычек складываются навыки.
Т.е., анализ современных технологий, расчёт эффективности новых решений и планирование рефакторинга проектов под них — более не востребованные подходы?
Он не знает, а лишь полагает, что знает. Некоторые его идеи попахивают откровенным дилетантством.
Ещё как могут быть. Видимо Егор забыл, что такое «порог вхождения» и чем он определяется. Глобализм — штука обоюдоострая, а местами и вовсе — вредоносная.
Т.е., по вопросу английского он не готов расставаться с иллюзиями?
Человек всего лишь верен принципам кроссплатформенности. Далее автор кидает море умных английских терминов, забывая, что всё решается простыми диаграммами. Ещё ниже автор прокатывается по программисту, который ушёл как одиночка. Однако, ему даже не приходит в голову, что мир не вертится вокруг вглядов автора. Программист просто послал куда подальше весьма проблемного контрибьютера.
Быть одиночками действительно неправильно, но может стоит понять причину ухода людей? Для начала прекратить мыслить «модными терминами» и обратиться к машинной сути конечного продукта. Маркетинговые извращения в сфере IT ещё ни разу не приносили пользу науке программирования. они лишь бесконечно множат сущности, вызывая у всех участников синдром «рассеянного внимания».
Может не стоит путать мягкое с тёплым? Капиталистическая машина производства стремится превратить человека во взаимозаменяемый болтик, чтобы экономить на демпинге цен на услуги разработчиков.
Автор видел когда-нибудь нормальную производственную документацию? Или говоря о современных тенденциях, он предлагает махровые анахронизмы?
Перефразирую: «Профессиональное обучение специалиста — проблема самого специалиста». Автор, видимо, «прикоснулся к бюджету», раз позволяет себе подобную ересь.
Плох тот программист, который провоцирует коллег на самостоятельное набивание шишек.
Ниже идёт ещё больше ереси, но уже завязанной на финансовой стороне вопроса. Программист, товарищ автор, — это человек учёный. Он не должен заниматься финансовой стороной вопроса. Это — откровенно лишний и даже деструктивный подход, смешивать две совершенно различные спецификации воедино. Ведёт к сведению роли разработчика в знаменитое «И швец, и жнец, и на дуде игрец». Иначе говоря, этот подход придуман кастой топ-менеджеров с целью экономии за счёт персонала. не надо все стрелки переводить на исполнителей, превращая их в «эффективных» — такие занимаются уже не разработкой, а выколачиванием денег. Постепенно им становится наплевать на результат своей работы — главное, чтобы деньги платили и не более. Автор, это не страх, это — отвращение к чужеродному для науки элементу!
Приходит время «эффективных» менеджеров. :)
Только не надо выдавать массовое помешательство за прогресс! Программисты переходят с C++ на Java лишь потому, что за неё больше и чаще платят. Естественно, ведь той же самой касте топ-менеджеров выгоднее, когда время на отладку сокращается за счёт отсутствия необходимости следить за выделением памяти. Этим Java занимается сборщик мусора. Другой вопрос, сколько ресурсов потребляет приложение, запускаемое на платформе через виртуальную машину? А ещё вспомним, через какие тернии приходится реализовывать то, что по умолчанию доступно через системные API. А в той сфере, для которой и создавалась Java-машина, она присутствует лишь частично. Чаще всего используется не по назначению.
Ага, только работодателям забыли об этом сообщить. Ведь до сих пор программист под боком оплачивается лучше, чем некий удалённый фрилансер, если только он не уникум. Опять же, кто платит деньги, тот и заказывает музыку. Теперь я убедился: автор — неизлечимый глобалист. И этот человек нас учит? Не смотря на слащавые сказки о великом фрилансе, автор совершенно умалчивает, что причина данного явления кроется в другом: развитие регионов в стране неравномерно. Человек, работая фрилансером в Краснодарском крае на московскую компанию, готов наступить себе не агорло и принять всю декларируемую автором ересь лишь потому, что так больше платят. Т.е., проблема-то не в способе зарабатывания денег, а в их отсутствии в регионе проживания специалиста.
Весьма грустное упущение, что люди, подобные автору, становятся работодателями. Впрочем, при капитализме работа по методу «ничего личного, только бизнес» и приводит к продвижению по карьерной лестнице. Увы, сами специалисты пока что не способны объединяться с целью уничтожения основы для столь циничного лицемерия.
Ключевое слово «продавайтесь». Всё с автором понятно: Он к разработчикам отношения больше не имеет, но позволяет себе учить.
Хорошие программисты пишут код, лучшие — занимаются разработкой. Автор опять смешал тёплое с мягким. Ну точно воспитанник эпохи.
А метод «сначала поговорить, устранить разногласия, а потом написать тикет» в расчёт уже не берётся? Бюрократизация вместо социализации?
Потому, что это задача не программиста, а системного архитектора. Стыдно такое не знать! Уж тем более — работодателю! Я уже сомневаюсь в квалификации автора…
Автор, по видимому, не в курсе понятия «порог вхождения». Ну правильно: Вера в глобализм затмевает способность критически оценивать процесс самообразования подчинённых. Ах, да… у автора же обучение специалистов — проблема самих специалистов… Т.е., автор всячески дистанцируется от этой проблемы. Русскоязычное сообщество нужно для увеличения количества специалистов, а так же снижения количества времени, необходимого для изучения материалов. А специалист, который делает это свободно с применением английского языка, вряд ли может называться «русским». У него даже логика перестраивается соответствующим образом. он больше не участвует в развитии отечественной науки. Бороться надо всеми силами с подходом «only English формат». А «глобальный рынок» — весьма иллюзорное понятие. Он глобальный ровно до тех пор, пока это выгодно носителям «международного» языка. Автор уже напоминает «свидетеля Иеговы»…
..., но совершенно не понимает, как работает та шайтан-машина, для которой он пишет код. Т.е., узко направленный специалист-компоновщик. Раньше таких называли «конфигураторами», а теперь они называются «программистами». В какой-то момент программирование начнут воспринимать как «магию», а компьютер или цифроблок, если только бессовестные маркетологи не назовут его какой-нибудь smart-хренью, будет восприниматься как «артефакт». Давай, автор, призывай программистов к профессиональной деградации, ведь ты же сможешь на этом не слабо заработать! Ты же не программист, ты — капиталист!
Программист, провоцирующий коллег на самостоятельное набивание шишек, — не настоящий программист. Он — вредитель.
А кто в этом виноват? Кто прямо в этой статье забивает ещё один гвоздь в крышку гроба профессии программиста? Сознательность не приносит дохода, ведь, правда?
Плохой разработчик тот, кто не признаёт существование сообществ по единству интересов. С малым сообществом проще работать, а ещё проще с ним договориться. Но это же не выгодно большому бизнесу, правда?
Если только подобная политика не приведёт к технологическому краху из-за утери методов воспроизведения технологий.
В общем, что могу сказать, статья носит откровенно вредоносный характер, пагубно влияющий на неокрепшие умы. Новая поросль потом не поймёт, откуда при таком количестве «новых» и «современных» технологий столь стремительно множатся ошибки и сбои систем городского жизнеобеспечения. А когда это всё навернётся, не обнаружится того самого специалиста, способного при помощи «кувалды и какой-то там матери» заставить это всё работать хотя бы в пол силы. А всё потому, что «человек-творец» превращается в «квалифицированного потребителя», который знает, как «заколачивать деньги», но таких, как он, — великое множество, а «пирога на всех не хватит». И какими словами, интересно, он будет вспоминать автора данной статьи, если вообще вспомнит о его существовании? Когда пирога перестанет хватать даже на автора, он «запоёт» совсем другими словами, а поздно! Сам создал, сам и расхлёбывай! «За что боролся, на то и напоролся!».