В дебрях водопада
Aug. 29th, 2018 09:27 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЖутко мучаются проповедники agile, пытаясь изобретать то прототипы, то спиральную модель...
Это я сходил на очередную тусовку. DevOps Guru Switzerland: Open Source Performance Test Automation mit JMeter, Selenium und Taurus
Сразу ссылки:
Abstraction level above testing tools: Taurus (http://gettaurus.org/)
Run massively scalable, open source-based tests: BlazeMeter (https://www.blazemeter.com/)
Дальше немного заметок на полях. Частично на английском, потому что так записано в блокноте, а переводить влом.
Пропорция на этот раз была полтора к одному. В смысле, на трёх пришедших извне два организатора. Впрочем, всего народу было меньше двадцати человек.
Очень неудобно в этот Клотен ехать. Особенно отсюда, точнее обратно. Ветки электричек сюда и туда расходятся как раз перед аэропортом. Обратно ехал, вообще, на автобусах.
Заодно в аэропорту набрал туристических брошюр. Первого сентября в Цюрихе ночь музеев. И на этих выходных аэропорт празднует семидесятилетие.
Первый раз вижу, чтобы доклад начинался со шпионажа.
По идее должно было выглядеть по типу:
- Как вы это делате?
- Вот так.
- А надо вот этак.
Но было так:
- Как вы это делаете?
- Вот так.
- Спасибо.
Короче, диалога не получилось.
Увидел интересное добавление к agile версии модели водопада. Development и Test связаны циклом коррекции-изменения.
То есть, все прямоугольнички по новой религией стрелочками в одну сторону, а между тестом и разработкой есть обратная связь.
Ещё десять лет - и додумаются до того, что разработка даёт сообщения об ошибках в дизайн. Дизайн - в сбор требований. А requirements engineering не только получает приказ начинать, но и что-то отправляет обратно прямоугольничку инициации. Например, сообщение "Нафиг-нафиг. Мы с такими пожеланиями только денег сожжём немеряно, но ничего путного в результате не выдадем."
Узнал новое волшебное слово: "Shift Left Model".
Если раньше в начале проекта работали аналитики, потом подключались дизайнеры, потом медленно набирали силу разработка и тестирование, то сейчас предлагается это всё загнать влево. Чтоб не только аналитики радовались, но и тестировщики с разработчиками резвились на сырых требованиях.
Если кто-то скажет, что отсутствие мозгов решили компенсировать грубой силой, тот будет абсолютно прав.
Но, увы, это реалии современной индустрии. Фиг сейчас найдёшь requirements engineer, который скажет "Вы на самом деле хотите раскрасить интерфейс в эти цвета?" или "Вы уверены, что не стоит рассматривать случаи, когда пользователь вводит данные с ошибкой?"
Помнится, двадцать лет назад специалист по IT-договорам, услышав ранних предвестников agile, с удивлением замечал, что для этого клиент должен платить не за сделаннную работу, а за то, что работа делается. Точнее, что-то делается, а что - не понятно.
Время показало, что заказчики под такое найдутся. Толпами. И большими деньгами.
Если им такое нравится, пусть платят.
Несколько интересных фактов:
- Тестирование бывает разрушающее, которое ищет ошибки, и верифицирующее, которое говорит, что ошибок нет. В фармафирмах любят второе. По этой причине практически всё делается вручную и производит гору бумаги.
- Licenses create queues and bottlenecks.
С одной стороны, хорошо, когда все-все-все могут тестировать всё что угодно. С другой - дешевле, если разработчики будут не гонять массивные тесты после каждого маленького изменения, а думать перед тем, как что-то в коде менять.
Мечты... Мечты...
- Чтобы изменить набор тестовых данных в банке надо обратиться к ответственным. И они поменяют. Время это займёт от двух недель до двух лет. (Может человек и преукрасил немного, но цифра правдоподобная.)
- Performance tools report mean values but the interesting part is the distribution of test results.
- Manual test scripts trap: It is simple to create a script that records user's actions but this script is costly to change.
Естественно, в этих замечательных тулах нельзя добавить параметры и случайные отклонения. А, когда один и тот же тест размножается под много клиентов, мы меряем не поведение системы под реальной нагрузкой, а совершенно искусственный случай.
Тысяча клиентов, одновременно выбравших один и тот же пункт в меню, - это не наплыв посетителей, а DOS атака.
- Интересно, что второй докладчик пропагандировал диаметрально противоположный подход: Generate test automation scripts from requirements.
What is wrong with this approach? The word "generate". Miracle is moved to the responsibilities of a business analyst.
Ещё я попытался объяснить людям, что тесты не могут быть слишком хорошими.
Development creates value. Testing eats resources. If tests produce too many errors this errors will be ignored. If this is impossible, developers will blame test scenarios as wrong or irrelevant and as result such "productive" tests will be switched off.
If developers try to be honest with tests that stop them, managers will change this unproductive attitude.
И в заключение лучшее за вчера.
Each advocate of each popular belief in IT is excellent in one aspect: the critique of problems of other beliefs.
Это я сходил на очередную тусовку. DevOps Guru Switzerland: Open Source Performance Test Automation mit JMeter, Selenium und Taurus
Сразу ссылки:
Abstraction level above testing tools: Taurus (http://gettaurus.org/)
Run massively scalable, open source-based tests: BlazeMeter (https://www.blazemeter.com/)
Дальше немного заметок на полях. Частично на английском, потому что так записано в блокноте, а переводить влом.
Пропорция на этот раз была полтора к одному. В смысле, на трёх пришедших извне два организатора. Впрочем, всего народу было меньше двадцати человек.
Очень неудобно в этот Клотен ехать. Особенно отсюда, точнее обратно. Ветки электричек сюда и туда расходятся как раз перед аэропортом. Обратно ехал, вообще, на автобусах.
Заодно в аэропорту набрал туристических брошюр. Первого сентября в Цюрихе ночь музеев. И на этих выходных аэропорт празднует семидесятилетие.
Первый раз вижу, чтобы доклад начинался со шпионажа.
По идее должно было выглядеть по типу:
- Как вы это делате?
- Вот так.
- А надо вот этак.
Но было так:
- Как вы это делаете?
- Вот так.
- Спасибо.
Короче, диалога не получилось.
Увидел интересное добавление к agile версии модели водопада. Development и Test связаны циклом коррекции-изменения.
То есть, все прямоугольнички по новой религией стрелочками в одну сторону, а между тестом и разработкой есть обратная связь.
Ещё десять лет - и додумаются до того, что разработка даёт сообщения об ошибках в дизайн. Дизайн - в сбор требований. А requirements engineering не только получает приказ начинать, но и что-то отправляет обратно прямоугольничку инициации. Например, сообщение "Нафиг-нафиг. Мы с такими пожеланиями только денег сожжём немеряно, но ничего путного в результате не выдадем."
Узнал новое волшебное слово: "Shift Left Model".
Если раньше в начале проекта работали аналитики, потом подключались дизайнеры, потом медленно набирали силу разработка и тестирование, то сейчас предлагается это всё загнать влево. Чтоб не только аналитики радовались, но и тестировщики с разработчиками резвились на сырых требованиях.
Если кто-то скажет, что отсутствие мозгов решили компенсировать грубой силой, тот будет абсолютно прав.
Но, увы, это реалии современной индустрии. Фиг сейчас найдёшь requirements engineer, который скажет "Вы на самом деле хотите раскрасить интерфейс в эти цвета?" или "Вы уверены, что не стоит рассматривать случаи, когда пользователь вводит данные с ошибкой?"
Помнится, двадцать лет назад специалист по IT-договорам, услышав ранних предвестников agile, с удивлением замечал, что для этого клиент должен платить не за сделаннную работу, а за то, что работа делается. Точнее, что-то делается, а что - не понятно.
Время показало, что заказчики под такое найдутся. Толпами. И большими деньгами.
Если им такое нравится, пусть платят.
Несколько интересных фактов:
- Тестирование бывает разрушающее, которое ищет ошибки, и верифицирующее, которое говорит, что ошибок нет. В фармафирмах любят второе. По этой причине практически всё делается вручную и производит гору бумаги.
- Licenses create queues and bottlenecks.
С одной стороны, хорошо, когда все-все-все могут тестировать всё что угодно. С другой - дешевле, если разработчики будут не гонять массивные тесты после каждого маленького изменения, а думать перед тем, как что-то в коде менять.
Мечты... Мечты...
- Чтобы изменить набор тестовых данных в банке надо обратиться к ответственным. И они поменяют. Время это займёт от двух недель до двух лет. (Может человек и преукрасил немного, но цифра правдоподобная.)
- Performance tools report mean values but the interesting part is the distribution of test results.
- Manual test scripts trap: It is simple to create a script that records user's actions but this script is costly to change.
Естественно, в этих замечательных тулах нельзя добавить параметры и случайные отклонения. А, когда один и тот же тест размножается под много клиентов, мы меряем не поведение системы под реальной нагрузкой, а совершенно искусственный случай.
Тысяча клиентов, одновременно выбравших один и тот же пункт в меню, - это не наплыв посетителей, а DOS атака.
- Интересно, что второй докладчик пропагандировал диаметрально противоположный подход: Generate test automation scripts from requirements.
What is wrong with this approach? The word "generate". Miracle is moved to the responsibilities of a business analyst.
Ещё я попытался объяснить людям, что тесты не могут быть слишком хорошими.
Development creates value. Testing eats resources. If tests produce too many errors this errors will be ignored. If this is impossible, developers will blame test scenarios as wrong or irrelevant and as result such "productive" tests will be switched off.
If developers try to be honest with tests that stop them, managers will change this unproductive attitude.
И в заключение лучшее за вчера.
Each advocate of each popular belief in IT is excellent in one aspect: the critique of problems of other beliefs.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(frozen) no subject
Date: 2018-08-29 09:21 pm (UTC)(frozen) no subject
Date: 2018-08-29 09:33 pm (UTC)(frozen) Видите -- эволюция
Date: 2018-08-30 06:49 am (UTC)Вот я этого не понимаю.
Этого капитанства.
Я может и не могу похвастать огромным и авторитетным опытом програмирования,
но и я сталкивался с моментами в разработке...
где вот это вот "думать как что-то в кое менять" -- тупо не работает.
Во-первых -- потому что програмист ПОЛЮБОМУ думает...
я вообще не представляю как можно хоть что-то сделать в программировании "не думая".
Это дизайнер, может "не думая" мазнуть кистью... авось красиво получится.
А программист "не думая", может... ну бойлерплейта настрочить...
и то, даже тут надо бы подумать -- где и как.
Во-вторых -- потому что существует такая штука как объем кода и/или легаси.
Это пока пишеш мелкую приблуду, проект с нуля или еще что малоразмерное...
то можео себе еще представить, программист способен представить необходимый результтат в уме... и действтовать оттталвиваясь от него.
Но с большим объемом кода -- так не получается.
Никто не может представить себе работу... ну там ядра линукса или базы данных.
Вот так вот, чтобы "подумать заранее"...
Остается один немой вопрос -- какой ВАШ опыт в программировании?
(frozen) Рассудите шоле
Date: 2018-08-30 06:50 am (UTC)Этого капитанства.
Я может и не могу похвастать огромным и авторитетным опытом програмирования,
но и я сталкивался с моментами в разработке...
где вот это вот "думать как что-то в кое менять" -- тупо не работает.
....
(frozen) Re: Видите -- эволюция
Date: 2018-08-30 07:10 am (UTC)...
где вот это вот "думать как что-то в кое менять" -- тупо не работает.
...
Но с большим объемом кода -- так не получается.
У меня не получилось != Так не бывает
И не надо брать за образцы open source. Там задача эффективности просто не стоит.
(frozen) Да. При гипотезе что это просто я такой тупой %)
Date: 2018-08-30 07:47 am (UTC)Мой личный случай. Чтобы максимально близко к конкретике.
Легаси код.
Доволько большая апликуха, причем не просто окна/кнопочки,
а еще и собственный движко отрисовки карт и т.п.
Используется тонкий АПИ -- С++ врапер поверх андроидного Далвика.
Соответственно, вся мутотень с работой с окнами -- самопальная (в отличие от всяких МФС и прочих дотнетов).
И в этой мутотени, как часть задания, мне надо найти каким образом сделан переход от одного окна к другому (девайс -- планшет).
И... я его не нахожу.
Еще надо добавить, что никакого дебагера, чтобы можно было хотя бы таким образом его отследиь -- тоже нет.
Получается, по сути... мне надо найти в исходниках в несколько мегабайт,
строчку внешнего вида которого я себе даже не представляю,
ответственную за этот транзит.
Ну да... можно списать, и это легче всего сделать -- на то что это просто программист/я такой тупой.
Да и вообще, "это частный случай", а не то что это совершенно обычная при программировании пролема...
потому-то я и спрашивал про ваш программистский опыт -- не для того чтобы задирать нос, а вас уничижать,
а просто потому -- что если он у вас есть, то вы бы тогда сами понимали о чем речь.
Кстати, сам синиор, который и разрабатывал (10- лет) эту мутотень,
и которому понятное дело пришлось разбиратся ЗА меня,
признал что вопрос действительно хитрый,
и ему, зная кодовую базу, таки тоже пришлось поразбиратся.
То есть... это явно не эффект "тупого кодера", как бы вам не хотелось.
ЗЫ Да. Я знаю. "этого всего не случилось бы", если бы была документация,
внятная схема работы кода, или хотя бы код "не велосипедный"...
но это ОПЯТЬ -- то с чем приходится работать программисту: тонные легаси, отсутствие джокументации, запутаная велосипедная реализаци.
Например... схожая проблема была у меня, когда пытался выяснить,
а как же у Мелкософта сделаны колбеки... в СОМе, в Ишаке... %)))
(frozen) Re: Да. При гипотезе что это просто я такой тупой %)
Date: 2018-08-30 08:09 am (UTC)Мой личный случай. Чтобы максимально близко к конкретике.
"Личный случай" всегда можно покрыть неизвестному собеседнику подробностями.
Ну да... можно списать, и это легче всего сделать -- на то что это просто программист/я такой тупой.
Понятно. Тут системная ошибка.
Я сейчас параллельно слушаю про коммерцию. Ликбез будет в следующем посте.
но это ОПЯТЬ -- то с чем приходится работать программисту: тонные легаси, отсутствие джокументации, запутаная велосипедная реализаци.
Это результат современного подхода, о котором и идёт речь.
(frozen) Re: Да. При гипотезе что это просто я такой тупой %)
Date: 2018-08-30 08:18 am (UTC)А если не брать личный случай, то что брать?
Личный случай, тем более который хорошо запомнился, над которым думал --- хорошо тем, что в нем много деталей,
можно отследить причины и следствия.
А иначе что остается? Статистика баг-трекера?
Ну вот тогда так и получается... когда черпаешь информацию из подобных источников,
а не из живого опыта.
\\Понятно. Тут системная ошибка.
Чья? Какой "системы"?
\\Это результат современного подхода, о котором и идёт речь.
"Он не плачет и не пляшет, А на все рукою машет." (с)
(frozen) Re: Да. При гипотезе что это просто я такой тупой %)
Date: 2018-08-30 09:27 am (UTC)можно отследить причины и следствия.
Ясен пень, что я в той же ситуации буду смотреть на другие детали, выяснять другие факты и думать по-другому.
Причём, выяснить это я тоже могу, но только в диалоге. А это уже не развлечение, а работа. Да и общаться я буду со многими участниками процесса.
Модельные ситуации и проще, и честнее, и на них не висит "Я познал ИСТИНУ!"
(frozen) Re: Да. При гипотезе что это просто я такой тупой %)
Date: 2018-08-30 09:43 am (UTC)конкретно, к подобным системным сервисам в Винде существует стандартный интерфейс обращение -- через СОМ объекты.
кроме всего прочьего, там существует своя реализация "колбэков" -- когда нужно чтобы сам сервис дернул твою програму, по каким-то его внутреним причинам.
и эти колбэки... описаны и в литературе, и в документации, и примеры кода есть...
вот только... не работает оно.
Какие варианты? Кроме спросить самих разработчиков Ишака? Или того у кого ОНО работало?
Ну... я еще попробовал дизасемблером посмотреть -- да, есть такая штука и работает.
Но... это уже откомпилированый код.
А что надо написать? Что подсунуть компилятору, чтобы он его вот так правильно сделал? Какой-то хитрый ключ компиляции? Или может специальная форма декларации?
Пойди узнай.
А это -- время.
И невозможность реализовать необходимой в проекте фичи.
Вот. Какие варианты вы видите?
Опять "вина тупого програмиста", который "не хочет думать"?
Или все же... это такое "тайное знание",
которое то ли специально (надо пройти курсы Мелкософта, купить *правильные* мануалы... информации просто из книг просто "издательство Микрософт-пресс" или с МСДНа недостаточно),
или чисто случайно,
были спрятаны/утеряны?
(frozen) Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 09:58 am (UTC)1. Нанимать хороших программистов?
Ну, про рынок тут не буду, вы и сами понимаете.
А вот, ведь все равно, даже супер-пупер програмисты,
у них все равно не бесконечные, ни память, ни объем внимания, да и приницп 8+-2 для них точно так же действует.
То есть, нельзя задирать сложность разработки в надежде "а у нас програмисты такие суперские, что и это сделают".
2. Писать документацию?
Ну так, это просто увеличивает время на разработку.
Потому что надо писать код, а потому (желательно тут же) документацию.
И просто черкнуть строчку в описание функции, чтобы потом её выкусила система автогенерации доков -- не получится.
Потому что в той строчке ничего осмысленого написано не будет.
Ну будет "функциф белает бла-бла-бла-БАХ".
Ведь самая главная информация -- это как эта функция должна и может взаимодействовать с другим кодом.
То есть, это задача даже прямо противоположная той,
что выдана програмисту в виде задания по написанию кода.
Получается, что чтобы её правильно выполниь -- написать толковую документацию -- надо собрать митинг, с аритектором проекта -- чтобы писнуть пару строчек для чего функция нужна и почему именно такая.
В идаеле... если бы это писалось кнутовским литературным кодом...
если бы можно было отследиь, что это вот описание "бла-бла-БАХ",
встречается в "литературном" тексте,
между "сделать А" и "сделать С"... в виде "сделать В",
то это могло бы дать программисту какое-то понимание -- для чего и почему оно, и как важно ПЕРЕД вызовом "сделать В" делать А.
Но так ведь никто не делает.
3. Что там еще, написание тестов? Создание прототипов? Проработка архитектуры?
Там как минимум все те же трейдофы время/деньги.
Как вы сами правильно заметили...
серебряные пули не только дорого стоят,
но их еще и нету в продаже. %)
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 10:27 am (UTC)Не восемь, а семь плюс-минус два. Не зря десятка - это уже другой порядок.
Писать документацию?
Ну так, это просто увеличивает время на разработку.
Нет, конечно. Если за разработку считать не то, что прошло компилятор, а то, что вышло в релиз.
Потому что в той строчке ничего осмысленного написано не будет.
Надо нанимать квалифицированных людей или учить имеющихся.
Кстати, ещё один аспект, почему дипломированные программисты хуже людей, пришедших со стороны.
То есть, это задача даже прямо противоположная той,
что выдана программисту в виде задания по написанию кода.
Это проблемы менеджмента.
Получается, что чтобы её правильно выполнить -- написать толковую документацию -- надо собрать митинг, с архитектором проекта -- чтобы писнуть пару строчек для чего функция нужна и почему именно такая.
Это стандартный порядок работы в нормальных фирмах.
если бы это писалось кнутовским литературным кодом...
Там свои траблы. Потому методика и не пошла при всей красоте идеи.
Что там еще, написание тестов? Создание прототипов? Проработка архитектуры?
Там как минимум все те же трейдофы время/деньги.
Нет, конечно. Инвестиции в качество выгодны. Естественно, если они сделаны правильно.
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 11:35 am (UTC)Да. Быть здоровым И богатым -- оно завсегда лучше других вариантов. %)
\\Потому что в той строчке ничего осмысленного написано не будет.
\\Надо нанимать квалифицированных людей или учить имеющихся.
Ни встречал еще НИ ОДНОЙ документации,
где было бы что-то большее чем "эта функция делает бла-бла-бла".
Моменты типа "перед тем как делать бла-бла-бла, НУЖНО сделать блех-блех-блех", только или по смыслу, или из примеров/исходников, или... из собственного (горького) опыта.
А уж "а почему это так?"... вообще, остается только догадыватся.
А нет... соврал... какраз в хорошем качественном опенсорсе,
обычно бывает и описание "чё у нея внутре".
И очень даже неплохое.
\\Кстати, ещё один аспект, почему дипломированные программисты хуже людей, пришедших со стороны.
Ну... я сам самоучка.
Инженеры-механики мы. %)
\\То есть, это задача даже прямо противоположная той,
что выдана программисту в виде задания по написанию кода.
\\Это проблемы менеджмента.
Почему же?
Я тут про совершенно естественные вещи написал.
Когда дают задачу программисту -- перед тем кто-то, или он сам или в команде, провели декомпозицию -- чтобы ему В РАМКАХ ТАСКА уже углублятся в конкретную реализацию.
Но, для документации требуется ПРЯМО ПРОТИВОПОЛОЖНАЯ ЗАДАЧА -- скажем врайтеру документации дают имена функций -- для которых ему нужно понаписывать для чего они (в рамках системы) и как между собой взаимодействуют,
а никак не про то что у нея внутре...
\\Получается, что чтобы её правильно выполнить -- написать толковую документацию -- надо собрать митинг, с архитектором проекта -- чтобы писнуть пару строчек для чего функция нужна и почему именно такая.
\\Это стандартный порядок работы в нормальных фирмах.
Даже в нормальных фирмах есть такие вещи,
как контрактники, внешние библиотеки, все тот же легаси...
\\Там свои траблы. Потому методика и не пошла при всей красоте идеи.
Как бы, догадываюсь. Потому и "идеальный вариант".
\\Что там еще, написание тестов? Создание прототипов? Проработка архитектуры?
\\Там как минимум все те же трейдофы время/деньги.
\\Нет, конечно. Инвестиции в качество выгодны. Естественно, если они сделаны правильно.
А вот тут да. Менеджеры и заказчики -- должны понимаеть,
что это такое -- качество.
И какое и по какой цене оно им надо.
Впрочем, я не настроен педалировать эту тему, как принято у програмЁров,
потому что немного понимаю -- какие у них проблемы.
Это кодеру кажется что все так же просто как "беру деньги из тумбочки".
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 11:44 am (UTC)Моменты типа "перед тем как делать бла-бла-бла, НУЖНО сделать блех-блех-блех", только или по смыслу, или из примеров/исходников, или... из собственного (горького) опыта.
А уж "а почему это так?"... вообще, остается только догадываться.
В mission critical и в научном софте это стандарт. (Естественно, стандарт былой цивилизации, сейчас исчезающей)
Почему же?
Потому что менеджмент занимается распределением ресурсов. То есть, нехватка ресурсов - его ответственность.
Но, для документации требуется ПРЯМО ПРОТИВОПОЛОЖНАЯ ЗАДАЧА -- скажем врайтеру документации дают имена функций -- для которых ему нужно понаписывать для чего они (в рамках системы) и как между собой взаимодействуют,
а никак не про то что у нея внутре...
Это дурная идея, разделять написание текста для компиляторов и для людей.
Даже в нормальных фирмах есть такие вещи,
как контрактники, внешние библиотеки, все тот же легаси...
Это не значит, что документацию нельзя распространить на них. Всё делается при соответствующей постановке задачи и затратах ресурсов.
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 12:09 pm (UTC)\\Потому что менеджмент занимается распределением ресурсов. То есть, нехватка ресурсов - его ответственность.
Вы конечно знаете... что "ресурсы" -- не масштабируются.
Тем более когда они в виде времени, квалификации программиста.
Девять женщин не родят за 1 месяц.
Вообще... меня ваше "как правильно" интересует в русле "найти как решить проблему",
а у вас по ходу вся мотивация -- добится внимания как к "проповеди из горящего куста".
Потому что то что вы мне говорите, и так довольно общеизвестно.
Мне бы хотелось от вас больше атитюда
"Мы сами знаем что задача неразрешима... но мы хотим её решить!",
а не проповедей о смирении. ;)
\\Это дурная идея, разделять написание текста для компиляторов и для людей.
Не я устанавливаю ТАКИЕ правила.
Зато я знаю, что это именно программисты,
пробуют решить подобные проблемы -- системами автогенерации документации и т.п.
Вот, слышал про интересный проект -- Кайт,
про вытягивание информации из открытой документации,
с тем чтобы потом показывать её прямо при кодировании.
\\Это не значит, что документацию нельзя распространить на них. Всё делается при соответствующей постановке задачи и затратах ресурсов.
Да. Здоровыми и богатыми...
а если тебе не повезло... СамаВиновата (тм).
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 12:17 pm (UTC)В определённых пределах при правильном подходе ресурсы масштабируются.
Тем более, время - это выделяемый ресурс, который в большинстве случаев очень просто добавить.
Мне бы хотелось от вас больше атитюда
Надо разделять болтовню и работу. Что-то на самом деле серьёзное сюда не проходит просто по формату. Даже элементарную иллюстрацию нарисовать совершенно влом.
Не говоря о том, что решение конкретных проблем требует совершенно других затрат времени. (И без прослушивания одновременно семинара по электронной коммерции.)
Зато я знаю, что это именно программисты,
пробуют решить подобные проблемы -- системами автогенерации документации и т.п.
Компьютер не может генерировать смыслы. Тем более, не может отделить бред от полезной информации.
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 12:39 pm (UTC)Но не "ресурсы".
Вбросить мозгов, добавить компов, каждому по два... нет, по три, монитора.
Сагласен. Атлична масштабируется.
\\Тем более, время - это выделяемый ресурс, который в большинстве случаев очень просто добавить.
Да. мЭнагерский подход 101.
\\Мне бы хотелось от вас больше атитюда
\\Надо разделять болтовню и работу. Что-то на самом деле серьёзное сюда не проходит просто по формату. Даже элементарную иллюстрацию нарисовать совершенно влом.
То фигура речи, а не претензия... и не требование.
И так спасибо, за общение.
Если надоел, предупреждайте заранее. ;)
\\Зато я знаю, что это именно программисты,
пробуют решить подобные проблемы -- системами автогенерации документации и т.п.
\\Компьютер не может генерировать смыслы. Тем более, не может отделить бред от полезной информации.
"Мы сами знаем что проблема неразрешима... но мы хотим её решить" (С)
И знаете... как-то понемноге,
решение двигается.
Там нейросетки всякие и т.п.
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 01:25 pm (UTC)кстати получится, хотя бы потому, что эта несчастная строчка поможет потом искать функцию через пару лет (в 100к строк говнокода).
В вашем же примере "переход от одного окна к другому (девайс -- планшет)" -- банальный же git grep скорее всего найдет минимум файл с нужной функцией/методом, просто потому что зацепит ключевые слова из описания в комментарии. (Мне приходилось работать с большой, втч частично чужой (зависимости, сервисы, библиотеки) кодовой базе на разных языках чтобы понять какой компонент отвественен за (ошибочное) поведение, а только потом уже чинить и/или компенсировать это поведение.
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 01:35 pm (UTC)И чего? Искусственный Интеллект уже начал выдавать фотки котят?
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 01:51 pm (UTC)не имел подобного опыта %(
\\В вашем же примере "переход от одного окна к другому (девайс -- планшет)" -- банальный же git grep скорее всего найдет минимум файл с нужной функцией/методом, просто потому что зацепит ключевые слова из описания в комментарии.
Там как-то не в виде отдельной функции было сделано.
Так бы, я по смыслу не нашел бы что ли.
Там был какой-то "умный велосипедизм", програмер решил выпендрится.
И коментариев емнип небыло.
Ну, мутный былокод... если бы не довольно качественная функциональность в результате.
Кстати... то что вы описываете -- это ж инструменты и практики опенсорса же,
а автор журнала таковой показательно не любит...
тоже наверное какой-то личный опыт. %(
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 02:07 pm (UTC)(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 02:46 pm (UTC)Не идеализирует != Не любит
(frozen) Re: Вот вы говорите что знаете КАК ПРАВИЛЬНО
Date: 2018-08-30 02:54 pm (UTC)что вы постоянно демонстрируете такое отторжение.
Как по мне, то всякое проприетарное блоатваре -- много хуже.
а опенсорс идет по принципу
Не хочешь -- не пользуйся,
Не можешь не пользоватся -- вот исходники, или напиши сам.
Сложно где-то в мире найти большей справедливости. ;)
(frozen) Уточню
Date: 2018-08-30 02:57 pm (UTC)То что поделия большинства красноглазиков может быть того... и не собираюсь отрицать.
Но инструменты. Но практики.
Есть какие-то претензии к Гиту?
Или к Апачу?
Или к ядру Линукса?
Ну, кроме как в Таненбаумском стиле. %)
(frozen) Сначала Стефенсон Рокет чух-чух!
Date: 2018-08-30 03:00 pm (UTC)тем не менее, специалист долже бы видеть перспективу и в чух-чух,
хотя бы в ретроспективе.
как помню я в институте,
видел/пробовал програмы симуляцыы с еденицами нейронов,
читал о перцептроне...
сравните с современными.
проекстраполируйте.