«В тот момент, когда изобретатель конструирует какое-либо устройство, чтобы осуществить незрелую идею, то неизбежно оказывается в полной власти своих мыслей о деталях и несовершенствах механизма. Пока занимается исправлениями и переделками, он отвлекается и из его поля зрения уходит важнейшая идея, заложенная первоначально. Результат может быть достигнут, но всегда ценой потери качества.
Мой метод иной. Я не спешу приступить к практической работе. Когда у меня рождается идея, сразу же начинаю развивать её в своем воображении: меняю конструкцию, вношу улучшения и мысленно привожу механизм в движение. Для меня абсолютно неважно, управляю я своей турбиной в мыслях или испытываю её в мастерской. Я даже замечаю, что нарушилась её балансировка. Не имеет никакого значения тип механизма, результат будет тот же. Таким образом, я могу быстро развивать и совершенствовать концепцию, не прикасаясь ни к чему». Никола Тесла
С одной стороны, одному ли мне кажется, что проблема алекситимии связана с банальным «пробелом в образовании»?
В детстве (или юности) ребенку не объяснили какие бывают эмоции, не показали как их выражать, для чего, в нужный момент родители были заняты и упустили возможность объяснить. Лишь недавно для меня это стало открытием, оказывается реально ребенку надо объяснять всё, вот абсолютно ВСЁ, ведь он ничего еще не знает, в т.ч. эмоции и реакцию. Мои родители были не слишком эмоциональны, у нас не было принято выражать эмоции открыто, вот и стало «нормой» радоваться или горевать потихоньку.
С другой, быть может это следующий виток эволюционного развития?
Отказ от психоэмоциональной составляющей, переход на строго рациональное мышление. Вместо этого, человека антидепрессантами пичкают, пытаясь убедить его в существовании болезни. Ведь любая «нормальность» есть лишь результат усреднения и унификации общества.
1. Когда речь заходит про автоматизацию развертывания, всегда очень интересно — а как автоматизируется интеграционное и приемочное тестирование API на тех средах, с которыми уже интегрируются внешние системы?
Например, если речь про эквайринг (не знаю касается статья этой части ваших систем), как проверяется полный цикл корректной работы как бы «извне», с точки зрения внешней системы?
Уточню что считаю это важным пунктом CI/CD, без автоматизации тестирования сильно падает темп выкатывания обновлений, либо же снижается надежность/стабильность.
2. Chatops — можете рассказать пожалуйста — увидели в этом потребность или просто экспериментируете на модной волне? Если держать общий чат для уведомлений о выкатывании — с наращиваем количества сервисов начнется жуткий спам, на мой взгляд.
Поинтересоваться, а почему думаете именно в функциональной парадигме?
Мне кажется, что популярные нынче функциональные языки типа F# или Haskell как то уходят от математически четкой декларативности, а без этого, потенциальная мощь подхода сильно снижается. Даже вот первый пример на Wiki — да мало чем отличается от императивной версии.
На мой взгляд, если уж программирование останется в каком то виде (и нас не заменит ИИ), то языки буду становиться всё более предметно-ориентированными (DSL) и абстрактными.
Вот да, соглашусь. «Боязнь» что то менять у меня обычно возникает только если не понимаю как это работает, как может затронуть другие места.
Потому, нещадно убеждаю других доводить код до такого состояния — чтобы всем было понятно.
Но есть и ребята, которые расписывают достаточно детально все ветки повествования, в зависимости от реакции, вопросов.
Вот я как раз из таких, и всё именно так, как вы расписали. Причем опыт выступлений уже имеется, но всё равно, если мне необходимо выступить максимально хорошо — то я максимально детально прописываю текст выступления.
Совет в статье про отсутствие такого текста (подстрочника) считаю скорее вредным для новичков, он подойдет лишь 1 из 100.
Насмотрелся немало на «да я своими словами буду импровизировать» (и как слушатель докладов, и как преподаватель на экзаменах). Если человек 1-2й раз в жизни что-то рассказывает по теме, то с вероятностью 99% он зависнет на каких то слайдах, отвлечется на какие то левые темы, не озвучит нужные мысли. Опять же, просто мозг так устроен — в состоянии стресса он будет выбирать самый простой путь, а значит, балаболить на наиболее знакомые темы.
Как правильно написали выше: «Хорошая импровизация должна быть тщательно отрепетирована.»
Однако же, если так прикинуть, статья целиком про «хотелку» людей — сначала маленькой группы, потом всё больше и больше. :) Из хотелок всё и создаётся, подкрепленных стараниями.
В Польше, например, есть налоговые оптимизации, связанная с авторскими правами для творческих профессий, и вот Программист входит в список таких профессий, а следовательно программисты имеют своего рода право на налоговый вычет (если так можно выразиться).
Можно повернуть вопрос и по другому — а в каких языках отказались от любых вариаций множественного наследования? И тогда задуматься — а может отказались с какой-то целью?
Хотя, справедливости ради, мне рыдать хочется что теперь реализации методов по-умолчанию привносят в интерфейсы C# :( в Java они уже давно имеются.
Auto Layout динамически вычисляет размер и положение всех представлений в вашей иерархии представлений на основании их ограничений.
Подскажите, пожалуйста, правило понимаю что речь по сути просто про относительный Layout, как с Panel/Grid/Margin в WPF например? До это всё задавалось точными координатами что ли?
(я сам не разработчик под iOS).
Заинтригован, продолжайте, будет интересно почитать как вы реализовывали мониторинг успешности релизов (авто-тесты, health-checking приложений после вывода и т.п.), для больших legacy монолитов это всегда больная тема.
Метрики DevOps тоже крайне интересуют, что вы вкладываете в понятие успешного внедрения DevOps.
Не соглашусь, всё-таки всегда как раз гордился тем, что при должном желании, хороший Программист/Разработчик в принципе неплохо въезжает в любую Предметную Область.
Проекты бывают разные и каждый требует особых знаний, так что это скорее естественное умение в нашем ремесле — уметь понимать любую Предметную Область.
Программирование оторванное от мира не несет смысла.
Прежде всего — хвалю за проделанную работу, всегда хорошо что человек пробует что-то новое.
НО,
Во-первых, можете полить меня кипятком, но для сложных случаях — где сокращение синтаксиса от обычного создания нового экземпляра и перенос свойств вручную?
Во-вторых, очень уж я боюсь судьбы фронтенда для .NET, что начнет появляться громадное количество микро-фреймворков просто потому что «хотелось чуть перламутровее».
В-третьих, сама по себе идея автомаппинга сильно различающихся сущностей мне кажется порочной.
П.С. Извиняюсь дико, но не «Dependancy» а «Dependency».
Спасибо большое за подробное изложение возможностей платформы.
Знающие люди, а подскажите, пожалуйста, по двум моментам:
1) Пропускная способность Oracle BPM и overhead на саму платформу.
Допустим, если наружу выставлена Web RESTful точка доступа с одним методом POST, он внутри исполняет пустую BPEL-схему, которая не делает ничего, лишь возвращает «Hello, World».
1.1) Сколько миллисекунд добавляет сама обработка такой BPEL-схемы? Т.е. за сколько будет отвечать метод.
1.2) Сколько запросов в минуту ориентировочно сможет выдержать один сервер? Т.е. при какой нагрузке (rpm) приложение станет возвращать ошибки недоступности.
2) Дизайн.
Почему все схемы, дизайн отчетов и дашбордов, BPM-дизайнер — будто прямиком из нулевых годов? Неужто на такой визуал «клюёт» Бизнес которому демонстрируют возможности платформы?
Важно тут концентрироваться не на конкретных именах продуктов или компаний (типа Jenkins и Ansible), а на потребностях наших команд (например, возможности быстрой интеграции изменений), чтобы развивать доверие к самому девопсу в целом.
Надежный и точный Layout и так очень мощная сторона WPF, за это он мне полюбился в своё время.
Но, к сожалению, за все эти годы так и не подвезли возможность устанавливать несколько стилей для одного элемента, приходится плодить мелкие подстили на каждый случай, из-за чего становится невыносимой поддержка больших библиотек стилей.
Потому что — было так канонично. На самом деле в статье про это упоминается, что в своё время маниакально стремились под каждый слой сделать отдельные DTO, аукается до сих пор.
Меня сильно напрягает стремление каждый слой отделить строго своим собственным набором сущностей/DTO объектов (абсолютно идентичных), а потом перегонять всё через AutoMapper туда-сюда по несколько раз. Поверх них еще навернуть абсолютно на любую зависимость интерфейсы, на каждую сущность интерфейсы либо абстрактные классы. Потом приходят люди и пытаются это осознать месяцами.
Полностью согласен с последней мыслью «Лучше красивый, хорошо работающий код, чем архитектурное спагетти с соусом из недопонимания.», и благодарен что она прозвучала. :)
Но всё равно часто забывают про целесообразность накручивания, именно целесообразность, а не «потому что могу забубенить такое».
Конструктив, наверное, но сначала хотел услышать мнение, не испортив его своим. :)
По моему опыту, я как то перестал видеть грань между «просто логикой» и «бизнес-логикой», став называть всё «логикой».
Обычно под «просто логику» попадает сначала то, до чего Бизнесу пока нет дела. Но со временем, этот кусок логики может затронуть бизнес и начать влиять на него. Тогда она превращается в бизнес-логику.
Касалось это по сути всего: обработки ошибок, значений по-умолчанию, валидаций и т.д.
lifehacker.ru/sekrety-produktivnosti-ot-korolya-gikov-nikoly-tesla
В детстве (или юности) ребенку не объяснили какие бывают эмоции, не показали как их выражать, для чего, в нужный момент родители были заняты и упустили возможность объяснить. Лишь недавно для меня это стало открытием, оказывается реально ребенку надо объяснять всё, вот абсолютно ВСЁ, ведь он ничего еще не знает, в т.ч. эмоции и реакцию. Мои родители были не слишком эмоциональны, у нас не было принято выражать эмоции открыто, вот и стало «нормой» радоваться или горевать потихоньку.
С другой, быть может это следующий виток эволюционного развития?
Отказ от психоэмоциональной составляющей, переход на строго рациональное мышление. Вместо этого, человека антидепрессантами пичкают, пытаясь убедить его в существовании болезни. Ведь любая «нормальность» есть лишь результат усреднения и унификации общества.
Например, если речь про эквайринг (не знаю касается статья этой части ваших систем), как проверяется полный цикл корректной работы как бы «извне», с точки зрения внешней системы?
Уточню что считаю это важным пунктом CI/CD, без автоматизации тестирования сильно падает темп выкатывания обновлений, либо же снижается надежность/стабильность.
2. Chatops — можете рассказать пожалуйста — увидели в этом потребность или просто экспериментируете на модной волне? Если держать общий чат для уведомлений о выкатывании — с наращиваем количества сервисов начнется жуткий спам, на мой взгляд.
Мне кажется, что популярные нынче функциональные языки типа F# или Haskell как то уходят от математически четкой декларативности, а без этого, потенциальная мощь подхода сильно снижается. Даже вот первый пример на Wiki — да мало чем отличается от императивной версии.
На мой взгляд, если уж программирование останется в каком то виде (и нас не заменит ИИ), то языки буду становиться всё более предметно-ориентированными (DSL) и абстрактными.
Потому, нещадно убеждаю других доводить код до такого состояния — чтобы всем было понятно.
Вот я как раз из таких, и всё именно так, как вы расписали. Причем опыт выступлений уже имеется, но всё равно, если мне необходимо выступить максимально хорошо — то я максимально детально прописываю текст выступления.
Совет в статье про отсутствие такого текста (подстрочника) считаю скорее вредным для новичков, он подойдет лишь 1 из 100.
Насмотрелся немало на «да я своими словами буду импровизировать» (и как слушатель докладов, и как преподаватель на экзаменах). Если человек 1-2й раз в жизни что-то рассказывает по теме, то с вероятностью 99% он зависнет на каких то слайдах, отвлечется на какие то левые темы, не озвучит нужные мысли. Опять же, просто мозг так устроен — в состоянии стресса он будет выбирать самый простой путь, а значит, балаболить на наиболее знакомые темы.
Как правильно написали выше: «Хорошая импровизация должна быть тщательно отрепетирована.»
Хотя, справедливости ради, мне рыдать хочется что теперь реализации методов по-умолчанию привносят в интерфейсы C# :( в Java они уже давно имеются.
Подскажите, пожалуйста, правило понимаю что речь по сути просто про относительный Layout, как с Panel/Grid/Margin в WPF например? До это всё задавалось точными координатами что ли?
(я сам не разработчик под iOS).
Метрики DevOps тоже крайне интересуют, что вы вкладываете в понятие успешного внедрения DevOps.
Проекты бывают разные и каждый требует особых знаний, так что это скорее естественное умение в нашем ремесле — уметь понимать любую Предметную Область.
Программирование оторванное от мира не несет смысла.
НО,
Во-первых, можете полить меня кипятком, но для сложных случаях — где сокращение синтаксиса от обычного создания нового экземпляра и перенос свойств вручную?
Во-вторых, очень уж я боюсь судьбы фронтенда для .NET, что начнет появляться громадное количество микро-фреймворков просто потому что «хотелось чуть перламутровее».
В-третьих, сама по себе идея автомаппинга сильно различающихся сущностей мне кажется порочной.
П.С. Извиняюсь дико, но не «Dependancy» а «Dependency».
Знающие люди, а подскажите, пожалуйста, по двум моментам:
1) Пропускная способность Oracle BPM и overhead на саму платформу.
Допустим, если наружу выставлена Web RESTful точка доступа с одним методом POST, он внутри исполняет пустую BPEL-схему, которая не делает ничего, лишь возвращает «Hello, World».
1.1) Сколько миллисекунд добавляет сама обработка такой BPEL-схемы? Т.е. за сколько будет отвечать метод.
1.2) Сколько запросов в минуту ориентировочно сможет выдержать один сервер? Т.е. при какой нагрузке (rpm) приложение станет возвращать ошибки недоступности.
2) Дизайн.
Почему все схемы, дизайн отчетов и дашбордов, BPM-дизайнер — будто прямиком из нулевых годов? Неужто на такой визуал «клюёт» Бизнес которому демонстрируют возможности платформы?
Вот. Потребности команд. «Золотые слова Юрий Венедиктович» ©
Решать проблему, а не стремиться вкрутить еще больше сложновыдуманных нетривиальных инструментов.
Лучи ненависти в сторону PowerShell и DSC, которые, на мой взгляд, созданы без оглядки на прошлый опыт и скорее с желанием придумать нечто новое прикольное, чем решить досадные ограничения bat-скриптов.
Но, к сожалению, за все эти годы так и не подвезли возможность устанавливать несколько стилей для одного элемента, приходится плодить мелкие подстили на каждый случай, из-за чего становится невыносимой поддержка больших библиотек стилей.
Полностью согласен с последней мыслью «Лучше красивый, хорошо работающий код, чем архитектурное спагетти с соусом из недопонимания.», и благодарен что она прозвучала. :)
Но всё равно часто забывают про целесообразность накручивания, именно целесообразность, а не «потому что могу забубенить такое».
По моему опыту, я как то перестал видеть грань между «просто логикой» и «бизнес-логикой», став называть всё «логикой».
Обычно под «просто логику» попадает сначала то, до чего Бизнесу пока нет дела. Но со временем, этот кусок логики может затронуть бизнес и начать влиять на него. Тогда она превращается в бизнес-логику.
Касалось это по сути всего: обработки ошибок, значений по-умолчанию, валидаций и т.д.