На мой взгляд в шпаргалках (и видимо вопросах на собесах) не хватает чего-то наподобие "Как вы будете разбираться с приложением, которое упало по OOM", "Как вы будете выяснять, почему приложение иногда перестаёт отвечать в рамках SLA (а потом опять начинает, само да...). Я про то, что JMC, VisualVM, Profiler в IDEA и это вот наше всё :)
Киньте в комментарии "+", если думаете что дублирование имеет смысл. "-" если думаете, что этому контенту место на Дзене, а не на Хабре. Ну а если, еще и мнением своим поделитесь - за это отдельное спасибо.
К статье наверно плюсик?
Да, да и ещё раз да. В конце концов, теперь у нас есть уровень материала - сложный или простой...
У меня от дома до метро - 1.7км. Автобусы ходят, но с половины дистанции и ещё в пробке постоять. От метро до офиса - ещё два ровно, и там (ну вот так вышло) вообще ничего не ходит. Если нужно ещё и съездить на встречу в рабочее время - то 10+ километров в день ножками - легко. Т.е. два с половиной часа минимум. А я ленивый...
Попробуйте как-нибудь провести "пару простых действий" без интернета. Вот совсем-совсем. И без доступных во внутренней сетке зеркал. Приходите к серверу или даже рабочей станции с воздушным зазором, вставляете flash, и накатываете...
Легко у него получается, и удобно :) У меня эта вундервафля уже лет восемь. Ничего удобнее для внутрирайонного перемещения и до / от метро не придумано. По магазинам тоже хорошо, два - три пакета в руках вообще никак на процесс езды не влияют
Seagway нифига не компактный. И не переносится одним человеком. И не кладётся в багажник. И не стоит дома рядом с кроссовками, занимая примерно столько же места.
А вот с моноколесом это всё получается (ну если только не совсем монстр на 2,5 киловатта с пробегом 130 км и максималкой под 70).
Именно. Потому что оно практически не занимает место, и "бегает как собачка", т.е. усилия по перекатыванию - отсутствуют. Получается идеальное антипробочное сочетание - от дома до метро на моноколесе, потом быстро и без пробок на метро, потом опять таки быстро - до офиса.
Borland "профукал" несколько не таким способом. Точнее, на некоторых аспектах в статье не заострено особого внимания. А зря.
Так вот... в одной далёкой галактике одна компания на букву M решила, что всё, что работало до этого на Win32 - это уже как-то несовременно. И сказала буквально следующее - в новых релизах все пользовательские программы будут работать только на .Net. И сама Windows тоже будет на .Net. А кто не успел - повторит судьбу Win16 приложений.
Компания Borland на примерно тот момент имела практически лучшую IDE для быстрой разработки. И звалась она Delphi 7. (Может быть и 6, я уж не упомню). В то же самое время (о чём в статье кстати сказано) Borland решила активно играть в ALM (Application Lifecyle Management) и прочие не-разработческие истории.
И началось шоу. Следующая вышедшая на .Net версия Delрhi была ужасной. Нет, она была настолько кошмарной, что работать на ней было невозможно. Сообщество разработчиков пожало плечами и осталось на Delphi 7. Следующая версия была вроде как получше, но тоже такое себе. Как пример - туда тоже не завезли Unicode. Это можно было решить сторонними компонентами, но по сути требовало полной переработки приложения. В BDE баги были тоннами. Сообщество в очередной раз пожало плечами, но многие уже задумались о том, что делать дальше.
Всё это наложилось на совершенно ушибленную ценовую политику и отсутствие бесплатных Starter версий. Да, серьёзно! Вы не могли вкатится в технологию, не заплатив приличной суммы денег. И получали за них мягко говоря сомнительного качества продукт. Если мне не изменяет склероз, то была даже какая-то программа - обменяй свои свежие лицензии на Delphi на лицензии на Delphi 7 (последняя версия на Win32).
Мир тем временем шёл вперёд, Web интерфейс для внутрикорпоративных приложений потихоньку начал становиться стандартом, появлялись разные интересные технологии и возможности. Что сделала Borland - ничего! Выпустила очередной релиз, который опять толком не работал. Сделай они хотя бы возможность транслировать dfm в Web-страницу (все метаданные и сценарии обработки собственно у них уже были) - и их бы носили на руках. Но нет.
Только в 2006 году появилась RAD Studio, на которой можно было разрабатывать, а не бороться со средой разработки. Но паровоз к этому моменту уже ушёл.
PS: Возможно кто-то вспомнит Sybase PowerBuilder, который в ряде аспектов не уступал, а то и превосходил по своим возможностям. Был куплен и убит SAP...
В данном случае - повезло, что всё это не сложилось. Треугольники на "родных" элементах не просто так для красоты делали. Хотя по фото стенку трубы и катет шва не сильно определишь.
Но лично я бы добавил диагоналей, причём как в самих надставках, так и от верха надставки к основанию (к месту крепления колеса). Последние можно вообще сделать из полосы типа 4x40, и крепить на два болтика М10 как железные верёвки
Спасибо огромное за материал! Жалко 10 плюсиков статье не могу поставить, только один.
И маленькая просьба - тот постер / cheatsheet, который был в соседней статье для привлечения внимания - можно его в векторе (pdf) выложить и тут ссылку дать? Я распечатаю и на стенку повешу, чтобы сверяться с.
Вот почти мой случай. Только у меня в имплеменатации №1 реальный входящий поток, а в №2 - восстановленный из таблиц БД. Нескольких. И в какой-то момент нужно добежать и перепрыгнуть на основной. Но бежать как-нибудь так, чтобы не уронить SLA на реализацию, загрузив на 100% CPU. Весело... Но `throws Exception` в сигнатуре интерфейса решает
...потом когда потребуется вторая имплементация уже так просто не впилишься, читать надо больше книг правильных"... Причем основным оппонентом был начальник разработки... Патология
Не патология. Вот прямо сейчас... совокупляюсь с собственным же кодом, написанным пару лет назад в парадигме "а нафига нам интерфейсы". И вариантов собственно немного: сделать вторую и третью имплементацию у десятка классов под совершенно другой режим работы, или плодить if-ы внутри. И как бы if-ы я тоже писать умею, проблема в том, что у требуемых мне для решения задачи сервисов тоже блин нужно заводить вторую и третьи стратегии работы, а это вот уже превращается в многоуровневые if-ы, где указания на режимы работы расползаются через enum-ы, и спасибо если не строковые константы или карты "исполнителей", где ключами те же строки. Были бы с самого начала выделены "узкие" интерфейсы на каждую реализуемую часть функциональности (пусть даже "толстый" сервис имплементировал бы штук пять) - сейчас стало бы в разы проще. Но тогда это выглядело лютым оверхедом на разработку. Да и как резать не очень понятно было.
Каждый раз эта альтернатива - или понятно как читать (функцию на 200 строк сверху вниз), или понятно как расширять (когда этих функций 20 в пяти классах), но тогда фиг прочитаешь и контекст в голове соберёшь. FizzBuzz Enterprise Edition получается. Была бы у IDE функциональность "inline кода для чтения программистом", чтобы все эти микрофункции можно было бы слепить в кучу, убрав параметры и return и посмотреть на большое полотно - было бы проще.
Соглашусь... с оговоркой. Разработки бывают разные. И не обязательно на C. К примеру ну кто в 2025 году работает с адресной арифметикой в кровавом enterprise? А требования к коду, который обрабатывает бизнес-данные в соответствии с бизнес-алгоритмами для удовлетворения бизнес-пользователей :) - ещё оттуда. Как выше правильно замечено - был же Pascal, где программист говорил - мне нужен массив от 65 до 81, компилятор брал под козырёк и бежал компилировать что велено. А не выделывался такой весь "ты кожаный считай от нуля и нигде не ошибись в смещениях, потому что мне так проще будет".
Собственно комментарий выше - он не критика явления как такового. Да, есть железо, где до сих пор экономят каждый байт. K ПП x ещё можно вспомнить. Но, кажется, не следует возводить в абсолют требования индексации с нуля для произвольного языка X решающего спектр задач Y, просто потому, что "здесь так принято". Я нормально читаю текст вроде matcher.group(0).substring(1) , но предпочёл бы для строки начиная со второго символа в ней именно эту цифирь в коде и видеть
Интересно, а зачем "послябрь" ? Нуллябрем можно забить первый элемент enum-а например, чтобы первый месяц года попадал на человеко-читаемое значение. Чтобы не писать -1 к пользовательскому вводу, если язык не позволяет определять ordinal (Java). Вряд ли в production живёт код с таким enum, но в академических целях почему бы и нет. Для языка с индексацией с единицы по умолчанию был бы просто первый элемент JANUARY, последний - DECEMBER, а ещё один то куда?
Ну вот он я. Что-то умею программировать. Но не привык и не люблю индексировать с нуля. Потому что в естественном языке принято обозначать словом "первое" начальное значение. Первое место. Первый в очереди. Первое число месяца. Нигде не используется "нулевой". Бонусом - если элемент в коллекции один, то его индекс (был бы) - тоже один.
Но нет же. На PDP-11 видите ли надо было экономить одну команду, зато теперь человечество в каждом поколении учится думать в 0-индексации и отлаживает идиотские ошибки. Особенно доставляет -2 какой-нибудь, чтобы взять предпоследний элемент.
Хотя, как просто могло бы быть в альтернативной реальности: в массиве из 10 штук - первый элемент имеет индекс [1], последний, десятый - индекс [10]. Предпоследний - 10-1, индекс [9]. Но так слишком скучно будет программировать: что написал, то и работает :)
PS: Древний как ... анекдот: а у вас в исходном коде тоже есть месяц "Нуллябрь" ?
Спасибо за развёрнутый обзор! Однако, придётся добавить ложку дёгтя. MindMap откровенно слаб для управления требованиями. By design - он предназначен для управления ортогональными категориями и понятиями. В нём удобно описывать отдельные непересекающиеся фичи. И мы так и делаем. Но вот именно с задачей управления требованиями, например - требования по быстродействию для каждого из сервисов - беда.
К сожалению, если какое-то требование применяется к нескольким разделам - соответствующий блок нужно механически копировать и вставлять. Возьмём например требование по быстродействию для фич А,Б,В. Особенно если у A 0,5 сек, у Б и В - 1 сек. Получим 2 или 3 элемента на диаграмме. Из этого следуют неприятные последствия, особенно когда фич много: если требование по быстродействию разделится на два подтребования - то таковую замену нужно по всему документу делать вручную; совершенно не решается задача "а давайте соберём все требования по быстродействию в одну таблицу и отсортируем по времени"; "переформулируем требование таким то образом" и прочее. Такие задачи (увы) лучше решать в специализированном софте, который позволяет устанавливать отношения между требованиями, грубо говоря - в реляционной БД.
Немного может помочь adoc со своим переиспользованием фрагментов, но тоже всё далеко не прозрачно получается. Хотя комбинация adoc + plantuml в части разработки технической документации великолепна.
Что касается XMind - стоило бы показать, как использовать механизм маркеров и фильтрацию по ним, здесь цифры - приоритет выполнения, следующий маркер - оценка % выполнения. Такое "на ура" заходит на встречах с бизнесом, особенно с учётом того, что фичи можно сворачивать и разворачивать.
Спасибо за материал, кратко и со вкусом!
На мой взгляд в шпаргалках (и видимо вопросах на собесах) не хватает чего-то наподобие "Как вы будете разбираться с приложением, которое упало по OOM", "Как вы будете выяснять, почему приложение иногда перестаёт отвечать в рамках SLA (а потом опять начинает, само да...).
Я про то, что JMC, VisualVM, Profiler в IDEA и это вот наше всё :)
К статье наверно плюсик?
Да, да и ещё раз да. В конце концов, теперь у нас есть уровень материала - сложный или простой...
У меня от дома до метро - 1.7км. Автобусы ходят, но с половины дистанции и ещё в пробке постоять. От метро до офиса - ещё два ровно, и там (ну вот так вышло) вообще ничего не ходит. Если нужно ещё и съездить на встречу в рабочее время - то 10+ километров в день ножками - легко. Т.е. два с половиной часа минимум. А я ленивый...
Попробуйте как-нибудь провести "пару простых действий" без интернета. Вот совсем-совсем. И без доступных во внутренней сетке зеркал. Приходите к серверу или даже рабочей станции с воздушным зазором, вставляете flash, и накатываете...
Легко у него получается, и удобно :) У меня эта вундервафля уже лет восемь. Ничего удобнее для внутрирайонного перемещения и до / от метро не придумано. По магазинам тоже хорошо, два - три пакета в руках вообще никак на процесс езды не влияют
Seagway нифига не компактный. И не переносится одним человеком. И не кладётся в багажник. И не стоит дома рядом с кроссовками, занимая примерно столько же места.
А вот с моноколесом это всё получается (ну если только не совсем монстр на 2,5 киловатта с пробегом 130 км и максималкой под 70).
Именно. Потому что оно практически не занимает место, и "бегает как собачка", т.е. усилия по перекатыванию - отсутствуют. Получается идеальное антипробочное сочетание - от дома до метро на моноколесе, потом быстро и без пробок на метро, потом опять таки быстро - до офиса.
Borland "профукал" несколько не таким способом. Точнее, на некоторых аспектах в статье не заострено особого внимания. А зря.
Так вот... в одной далёкой галактике одна компания на букву M решила, что всё, что работало до этого на Win32 - это уже как-то несовременно. И сказала буквально следующее - в новых релизах все пользовательские программы будут работать только на .Net. И сама Windows тоже будет на .Net. А кто не успел - повторит судьбу Win16 приложений.
Компания Borland на примерно тот момент имела практически лучшую IDE для быстрой разработки. И звалась она Delphi 7. (Может быть и 6, я уж не упомню). В то же самое время (о чём в статье кстати сказано) Borland решила активно играть в ALM (Application Lifecyle Management) и прочие не-разработческие истории.
И началось шоу. Следующая вышедшая на .Net версия Delрhi была ужасной. Нет, она была настолько кошмарной, что работать на ней было невозможно. Сообщество разработчиков пожало плечами и осталось на Delphi 7. Следующая версия была вроде как получше, но тоже такое себе. Как пример - туда тоже не завезли Unicode. Это можно было решить сторонними компонентами, но по сути требовало полной переработки приложения. В BDE баги были тоннами. Сообщество в очередной раз пожало плечами, но многие уже задумались о том, что делать дальше.
Всё это наложилось на совершенно ушибленную ценовую политику и отсутствие бесплатных Starter версий. Да, серьёзно! Вы не могли вкатится в технологию, не заплатив приличной суммы денег. И получали за них мягко говоря сомнительного качества продукт. Если мне не изменяет склероз, то была даже какая-то программа - обменяй свои свежие лицензии на Delphi на лицензии на Delphi 7 (последняя версия на Win32).
Мир тем временем шёл вперёд, Web интерфейс для внутрикорпоративных приложений потихоньку начал становиться стандартом, появлялись разные интересные технологии и возможности. Что сделала Borland - ничего! Выпустила очередной релиз, который опять толком не работал. Сделай они хотя бы возможность транслировать dfm в Web-страницу (все метаданные и сценарии обработки собственно у них уже были) - и их бы носили на руках. Но нет.
Только в 2006 году появилась RAD Studio, на которой можно было разрабатывать, а не бороться со средой разработки. Но паровоз к этому моменту уже ушёл.
PS: Возможно кто-то вспомнит Sybase PowerBuilder, который в ряде аспектов не уступал, а то и превосходил по своим возможностям. Был куплен и убит SAP...
Гм. А почему на Вашем же скрине номер записи - 07 ?
В данном случае - повезло, что всё это не сложилось. Треугольники на "родных" элементах не просто так для красоты делали. Хотя по фото стенку трубы и катет шва не сильно определишь.
Но лично я бы добавил диагоналей, причём как в самих надставках, так и от верха надставки к основанию (к месту крепления колеса). Последние можно вообще сделать из полосы типа 4x40, и крепить на два болтика М10 как железные верёвки
Спасибо огромное за материал! Жалко 10 плюсиков статье не могу поставить, только один.
И маленькая просьба - тот постер / cheatsheet, который был в соседней статье для привлечения внимания - можно его в векторе (pdf) выложить и тут ссылку дать? Я распечатаю и на стенку повешу, чтобы сверяться с.
Вот! https://www.youtube.com/c/CuttingEdgeEngineeringAustralia Хотя с починкой ЧПУ он не сладил, продал железо.
Оставлю это здесь: https://pgconfigurator.cybertec.at/
В Java таки нашли способ замокать даже то, что мокать не предполагалось by design. Интерфейсы для этого не нужны.
Вот почти мой случай. Только у меня в имплеменатации №1 реальный входящий поток, а в №2 - восстановленный из таблиц БД. Нескольких. И в какой-то момент нужно добежать и перепрыгнуть на основной. Но бежать как-нибудь так, чтобы не уронить SLA на реализацию, загрузив на 100% CPU. Весело...
Но `throws Exception` в сигнатуре интерфейса решает
Не патология. Вот прямо сейчас... совокупляюсь с собственным же кодом, написанным пару лет назад в парадигме "а нафига нам интерфейсы". И вариантов собственно немного: сделать вторую и третью имплементацию у десятка классов под совершенно другой режим работы, или плодить if-ы внутри. И как бы if-ы я тоже писать умею, проблема в том, что у требуемых мне для решения задачи сервисов тоже блин нужно заводить вторую и третьи стратегии работы, а это вот уже превращается в многоуровневые if-ы, где указания на режимы работы расползаются через enum-ы, и спасибо если не строковые константы или карты "исполнителей", где ключами те же строки. Были бы с самого начала выделены "узкие" интерфейсы на каждую реализуемую часть функциональности (пусть даже "толстый" сервис имплементировал бы штук пять) - сейчас стало бы в разы проще. Но тогда это выглядело лютым оверхедом на разработку. Да и как резать не очень понятно было.
Каждый раз эта альтернатива - или понятно как читать (функцию на 200 строк сверху вниз), или понятно как расширять (когда этих функций 20 в пяти классах), но тогда фиг прочитаешь и контекст в голове соберёшь. FizzBuzz Enterprise Edition получается. Была бы у IDE функциональность "inline кода для чтения программистом", чтобы все эти микрофункции можно было бы слепить в кучу, убрав параметры и return и посмотреть на большое полотно - было бы проще.
Соглашусь... с оговоркой. Разработки бывают разные. И не обязательно на C. К примеру ну кто в 2025 году работает с адресной арифметикой в кровавом enterprise? А требования к коду, который обрабатывает бизнес-данные в соответствии с бизнес-алгоритмами для удовлетворения бизнес-пользователей :) - ещё оттуда. Как выше правильно замечено - был же Pascal, где программист говорил - мне нужен массив от 65 до 81, компилятор брал под козырёк и бежал компилировать что велено. А не выделывался такой весь "ты кожаный считай от нуля и нигде не ошибись в смещениях, потому что мне так проще будет".
Собственно комментарий выше - он не критика явления как такового. Да, есть железо, где до сих пор экономят каждый байт.
K ПП xещё можно вспомнить. Но, кажется, не следует возводить в абсолют требования индексации с нуля для произвольного языка X решающего спектр задач Y, просто потому, что "здесь так принято". Я нормально читаю текст вродеmatcher.group(0).substring(1), но предпочёл бы для строки начиная со второго символа в ней именно эту цифирь в коде и видетьИнтересно, а зачем "послябрь" ? Нуллябрем можно забить первый элемент enum-а например, чтобы первый месяц года попадал на человеко-читаемое значение. Чтобы не писать -1 к пользовательскому вводу, если язык не позволяет определять ordinal (Java). Вряд ли в production живёт код с таким enum, но в академических целях почему бы и нет. Для языка с индексацией с единицы по умолчанию был бы просто первый элемент JANUARY, последний - DECEMBER, а ещё один то куда?
Ну вот он я. Что-то умею программировать. Но не привык и не люблю индексировать с нуля. Потому что в естественном языке принято обозначать словом "первое" начальное значение. Первое место. Первый в очереди. Первое число месяца. Нигде не используется "нулевой". Бонусом - если элемент в коллекции один, то его индекс (был бы) - тоже один.
Но нет же. На PDP-11 видите ли надо было экономить одну команду, зато теперь человечество в каждом поколении учится думать в 0-индексации и отлаживает идиотские ошибки. Особенно доставляет -2 какой-нибудь, чтобы взять предпоследний элемент.
Хотя, как просто могло бы быть в альтернативной реальности: в массиве из 10 штук - первый элемент имеет индекс [1], последний, десятый - индекс [10]. Предпоследний - 10-1, индекс [9]. Но так слишком скучно будет программировать: что написал, то и работает :)
PS: Древний как ... анекдот: а у вас в исходном коде тоже есть месяц "Нуллябрь" ?
Спасибо за развёрнутый обзор! Однако, придётся добавить ложку дёгтя. MindMap откровенно слаб для управления требованиями. By design - он предназначен для управления ортогональными категориями и понятиями. В нём удобно описывать отдельные непересекающиеся фичи. И мы так и делаем. Но вот именно с задачей управления требованиями, например - требования по быстродействию для каждого из сервисов - беда.
К сожалению, если какое-то требование применяется к нескольким разделам - соответствующий блок нужно механически копировать и вставлять. Возьмём например требование по быстродействию для фич А,Б,В. Особенно если у A 0,5 сек, у Б и В - 1 сек. Получим 2 или 3 элемента на диаграмме. Из этого следуют неприятные последствия, особенно когда фич много: если требование по быстродействию разделится на два подтребования - то таковую замену нужно по всему документу делать вручную; совершенно не решается задача "а давайте соберём все требования по быстродействию в одну таблицу и отсортируем по времени"; "переформулируем требование таким то образом" и прочее. Такие задачи (увы) лучше решать в специализированном софте, который позволяет устанавливать отношения между требованиями, грубо говоря - в реляционной БД.
Немного может помочь adoc со своим переиспользованием фрагментов, но тоже всё далеко не прозрачно получается. Хотя комбинация adoc + plantuml в части разработки технической документации великолепна.
Что касается XMind - стоило бы показать, как использовать механизм маркеров и фильтрацию по ним, здесь цифры - приоритет выполнения, следующий маркер - оценка % выполнения. Такое "на ура" заходит на встречах с бизнесом, особенно с учётом того, что фичи можно сворачивать и разворачивать.