Почитал про Python. Вот ни разу не впечатлён (положа руку на сердце - ОДИН раз впечатлён)

Почитал про Python. В частности вот это - http://rus-linux.net/MyLDP/BOOKS/python.pdf

Вот ни разу не впечатлён.

(положа руку на сердце - ОДИН раз впечатлён, про "ссылки" на объекты, сам - ДОЛГО над этим думал, но так и не "вкурил" НУЖНОСТЬ. А теперь - "вкурил")

Всё там же "стековая машина" со "словарями". Не  более того. А "синтаксис" без ОПЗ. Ну "синтаксис". На вкус и цвет.

Использовать как DSL - не то чтобы прям уж ИДЕАЛЬНОЕ решение. На мой вкус - тоже вполне себе "криптован".

В общем это моё частное мнение. "Уговаривать" меня в обратном - не  стоит :-)

Что касается "словарей" и построения на их основе "классов" - ну "мой FORTH" ровно так и устроен. Только он компилируемый и контроллирующий типы.

Что касается интроспекции - она также - есть. Как и множественное наследование, как и переопределение "методов" что мета-классов, что их экземпляров.

Лямбды - конечно тоже есть. Списки и словари - конечно тоже.

Параллельного присваивания - нету. Но в общем - понятно как его сделать, если сильно хочется. Собственно через "списки" о чём честно и написано в документации к Python.

Unicode - я тоже конечно же умею обрабатывать.

Ну и на закуску:
def __init__(self):
self.__dict__[self.__vdict_name] = {}
def __getattr__(self, name):
return self.__vdict[name]
def __setattr__(self, name, value):
self.__vdict[name] = value

--  подобное не кажется мне прям ИДЕАЛЬНЫМ для DSL.

По-моему вот это - http://18delphi.blogspot.com/2013/07/blog-post_196.html  - сильно веселее.

P.S. Хотя про интеграцию Python и Delphi - был бы рад, что-нибудь стоящее почитать.

P.P.S. Дали ссылку - http://dondublon.livejournal.com/68416.html

"После работы скрипта все объекты типа TPyObject уничтожаюся сами. Если объект представлял собой обертку для вашего рабочего объекта и держал на него ссылку, уничтожение ссылки коректно не делается и вы получите утечки памяти. Я достаточно долго ломал голову, как разрулить этот вопрос, в итоге получил рецепт: сделать у каждого такого TPyObject метод очистки ссылок, вызвать его вручную после работы скрипта, причем - это важно - этот метод должен быть не в деструкторе! Может, есть способ элегантнее, но я его не знаю."

Дьявол то - он как обычно - в деталях :-)

P.P.P.S. Похоже меня не до конца правильно поняли. Концепция ВНУТРЕННЕГО устройства Python - мне вполне БЛИЗКА и понятна. Потому и не впечатлён наверное. Может быть ждал "откровения", а оно - не случилось. А что до "синтаксиса" - тут и обсуждать нечего. Синтаксисы - они разные бывают. На вкус и цвет. Меня вот например SmallTalk - несколько "шокирует". Но это - ровным счётом ничего не значит. ОПЗ - я не то чтобы считаю сильной стороной. Нет конечно. Арифметика в ОПЗ - конечно ужасна. Но в целом - только арифметика.

P.P.P.P.S. Но! Изучая Python - я пришёл к выводу, что у меня допущена архитектурная недоработка. Продиктованная "слепым следованием" парадигме FORTH-машины. Надо помещать в стек и "шитый код" (да и вообще в ЛЮБОЙ контекст вызова) САМО "слово" (объект, в терминах Python), а не результат его выполнения. Тогда не нужно ни ОПЗ, ни "обратное присваивание", ни прочие "трюки".

P.P.P.P.P.S. И ещё я понял - КАК "скрестить ежа ("мой Forth") с ужом (Python)" и задействовать "батарейки в комплекте" от Python'а. В итоге получим ВНУТРИ "стандартность, гибкость и насыщенность" Python и СНАРУЖИ "понятность и гибкость DSL".

Заказал на Озоне себе книгу Лармана

Заказал на Озоне себе книгу Лармана. Жду когда привезут. Не научился я электронные книги читать. Стоит правда как самолёт. Но это - самая вменяемая книга по UML.

Чужая статья. Исправляем плохой дизайн API: функции обратного вызова без user-аргумента

Исправляем плохой дизайн API: функции обратного вызова без user-аргумента

Чужая статья. Delphi и предметно-ориентированные языки. Знакомо до "БОЛИ"

http://roman.yankovsky.me/?p=796

Сам - много об этом думал и многое сделал в этом направлении. Те же "скриптовые тесты" - примерно так и устроены.

Рад, что не я один :-)

Я бы правда использовал бы не Lexx/Yacc, а Forth/Lisp-машину.

Но "на вкус и цвет - все фломастеры разные"...

UML позволяет мне лично не "тупить глядя в монитор", а быстро входить в состояние "потока" для решения типовых задач

UML (отображаемый в сквозную базу знаний) позволяет мне лично не "тупить глядя в монитор" (http://18delphi.blogspot.com/2013/08/blog-post_2315.html), а быстро входить в состояние "потока" для решения типовых задач.

Примерно в таком ключе:

Пусть мы собрали некоторое количество требований и нарисовали некоторое количество прецедентов.

И пусть мы определились, что проектируемое приложение должно быть (по Layout'у) похоже на MSWord.

Тогда мы делаем примерно следующее:

Открываем базу знаний.

Вводим поисковый запрос "WordLike" или "OfficeLike".

Находим КЛАСС TWordLikeApplication видим, что он "абстрактный" (т.е. требует наследования и доопределения) и что он со стереотипом <<VCMApplication>>. Смотрим КТО от него наследуется. Может быть находим эти проекты и запускаем их. Чтобы убедиться, что это то, что нам нужно.

Ищем в базе знаний <<VCMApplication>>.

Находим этот стереотип. Понимаем, что он может быть вложен в <<VCMGUI>>, а тот в свою очередь в <<VCMProject>>.

Создаём <<VCMProject>> -> <<VCMGUI>> -> <<VCMApplication>>. Наследуем его от TWordLikeApplication.

Генерируем кода. Генератор генерирует "скелет приложения" и доопределяет абстрактные методы с указанием "вот тут напиши код". Определяем эти методы (в ДОКУМЕНТАЦИИ к ним "обычно" написано - что требуется от этого метода, если не написано, то бьём меня по голове и получаем нормальную документацию). Получаем ПУСТОЕ приложение. С УЖЕ определённой функциональностью.

Далее "вспоминаем", что у нас есть прецеденты.

Ищем по базе знаний стереотип <<UseCase>>. Который собственно у нас уже нарисован в требованиях.

Понимаем, что он может быть РЕАЛИЗОВАН стереотипом <<UseCaseRealization>>.

Смотрим ГДЕ может быть определён стереотип  <<UseCaseRealization>>.

Получаем цепочку <<VCMUseCases>> -> <<VCMUseCaseRealization>>.

Рисуем эту цепочку. Получаем "скелет прецедента". С необходимостью доопределить методы. Если что-то непонятно -  опять же - "бьём меня по голове" и получаем нормальную документацию.

Связываем <<VCMAppliaction>> с <<VCMUseCaseRealization>> связью реализации.

Получаем что наше приложение умеет реализовывать данный прецедент.

Учитывая тот факт, что <<VCMUseCaseRealization>> это ЕДИНСТВЕННОЕ место, где мы можем создавать экземпляры стереотипа <<VCMForm>> - мы с лёгкостью находим место, где мы можем создавать проектные формы с правильной инфраструктурой.

А в формах можно определять <<VCMOperation>>, которые собственно и служат "связующим звеном к пользователю".

Вкратце - как-то так.

P.S. Это я расписал для "стереотипов верхнего уровня", но примерно так же и работает для более "глубоких" проектных стереотипов типа "контейнеров".

Чужая статья. IDE vs текстовый редактор

http://tyvik.blogspot.ru/2013/08/ide-vs.html

Мда... "Особенности мышления".  Я вот например без AutoComplete - вполне живу и радуюсь, а вот без "нумерованных меток" - уже сильно сложнее.

Особенно никогда не понимал - зачем "плюшки". Зачем "ежа с ужом"?

Чужая статья. Мозг программиста

http://habrahabr.ru/post/191242/

"

Тупить в монитор

Самый частый и самый низкопроизводительный случай. Программист сидит и тупит в монитор. Читает тексты на разных языках, ищет что-то, пытается что-то решить. При этом основной используемый ресурс – это абстрактное мышление. Самое затратное, дорогое и низкопроизводительное. Поэтому продукты, действительно, гениальны, но приходят они с огромными временными и энергетическими затратами. Это самый низкоэффективный из всех кейсов.

Как избавиться от проблемы тупления в монитор? 

Весьма просто. Достаточно поместить часы в область зрения, и каждые 20 минут обязательно покидать рабочее место на 10 минут. Хорошая идея – занять это время физическими занятиями или общением. 

Не самые лучшие, хотя и популярные решения – покурить или посмотреть телевизор. Вредно для здоровья, но тоже помогает.

Нарисовать картинку

Используя возможности визуального восприятия и визуальной памяти, возможно принимать решения и анализировать многокомпонентные системы. Даже если количество элементов в системе превышает семи – не составит никакого труда работать с визуальным представлением этой системы в виде схемы.

Есть академические приемы использования этой методики. Во-первых, это прекрасный UML. Во-вторых, это методы XP (экстремального программирования) и SCRUM. Эффективность этих методов неоспорима.

Про XP можно почитать в википедии, а про UML отмечу немедленно некоторые из его замечательных свойств:

• Легко позволяет управлять уровнями абстрагирования и контролировать детализацию при разработке любого рода решений при программировании. Практически это единственный метод для действительно эффективного решения задач по декомпозиции (“Разделяй и властвуй!”).
• Единственно эффективный метод для достоверной передачи абстрактной информации между коллегами. Все поймут точно то, что задумал автор схемы, когда видят ее собственными глазами. Удивительно, но когда содержание схемы передается на пальцах – текстом или на слух, качество восприятия существенно снижается! Люди просто не понимают друг друга, или понимают вовсе не то и не так, как было задумано.
• UML в частности и вообще визуальные методы – известнейший прием менеджмента, когда нужно быстро и достоверно передать информацию между коллегами различной квалификации, различных специальностей, и получать фидбеки, организовать общение и обмен мнениями.
• UML в частности и другие визуальные методы – один из самых эффективных методов передачи рекламных сообщений.
• UML очень дешев – нарисовать схему карандашами, фломастерами или в векторном графическом редакторе можно легко и быстро. Эффективно заменяет многие часы тупления в монитор, фактически снижая количество затрачиваемого времени и энергии на решение логических задач.

Вообще визуальные методы – самые эффективные для обучения. Помните девочек-отличниц из средней школы? (Осторожно, сейчас будет разновидность юмора — сарказм) Большинство из них – дуры… Но ничто не мешает им систематически получать пятерки. Если вы заглядывали в их тетради – информация всегда хорошо структурирована, и представлена ЦВЕТНОЙ графикой. Поэтому они отлично запоминают материал, и легко используют его даже для абстрактных выводов. 

Умные не зубрят. Они конспектируют и рисуют.

Повысить качество иллюстраций просто — достаточно проработать цветовые коды (применить цвета, и сделать это осмысленно и системно) и решить задачи декомпозиции именно на этом этапе. Не допускать визуально сложных схем — делить их на фрагменты и выделять больше уровней, если это необходимо.

Понизить качество иллюстраций также несложно — для этого достаточно рисовать все одним цветом, и (или) делать сложные схемы. Так, чтобы они воспринимались медленно и с трудом.

Обсудить с коллегами

Одни из самых гениальных решений приходят в процессе обсуждения. Поэтому обсуждения так полезны, даже если не все участники обсуждения компетентны. Вспомните метод резиновой уточки.

Что происходит при этом? 

До обсуждения, в умах участников (или хотя бы одного, ключевого участника) уже присутствует визуальное и (или) абстрактное представление задачи.

Обсуждение же, как еще один канал восприятия, задействующий аудиальную память, вне зависимости от того, насколько аудиальное представление прокачано у конкретных участников – создает объемное представление предмета! Поэтому именно при обсуждении рождаются даже более гениальные мысли, чем при исключительно абстрактном анализе задач, при туплении в монитор. 

Яркие примеры многие из читателей сотни раз встречали в курилках и на планерках у талантливых руководителей.

Мы несколько раз в неделю устраиваем внутренние семинары. Каждый из коллег делится с другими коллегами своими текущими задачами и испробуемыми путями их решения. Пока рассказывают – на ум приходят светлейшие идеи.

Их, идей, много. Они гениальны и цена их низка – обычно за получасовую беседу рождается от 5 до 10 великолепных решений.

Из ТРИЗ. Японские инженеры на внутренних семинарах (планерках, мозговых штурмах – не суть) используют интересный метод. Вначале все участники высказывают как можно более глупые, дикие и сумасбродные идеи. В результате происходит, простите за терминологию, критичное расширение незавершенного гештальта, которое приводит к мгновенному расширению менталитета и получению новых ракурсов восприятия. Таким образом они рождают действительно гениальные, эффективные решения.

Счастье придет, если еще раз пройтись по статье и загуглить термины. Выделить слово, потом нажать правой кнопкой мышки и в открывшемся меню выбрать пункт “Искать...”

Спасибо за внимание и удачи всем!"

Чужая статья. Yii, непрерывная интеграция — как не сломать все

http://habrahabr.ru/post/191210/

Давно думаю о подобном.

"

Юнит-тесты и selenium-тесты

Честно скажу — их мало, очень мало. Их мы добавляем только тогда когда появился повторявшийся баг и в очередной раз тестировщики сказали “ну вот снова не работает!”
Мы никогда не меняем старые, написанные тесты — мы разрабатываем приложение с учетом обратной совместимости. Это нужно не только ради тестов — приложение имеет API для мобилок/десктопов и оно обязано быть обратно совместимым."

"P.S. Прежде чем ругать с фразами “это не тестирование”, “оно покрывает 5% функционала” и подобным: мы не тестируем. Мы именно делаем проверку работоспособности.

Это как проверка того, что лампочка горит в магазине — мы не проверяем её нагрев, не меряем излучаемый свет, не пробуем вкрутить в неподходящий патрон — мы проверяем, просто что она горит. Тоже самое мы делаем и с кодом. Простым, и не требующим поддержки способом."

Читаю Лармана

Читаю Лармана. Точнее оказалось - перечитываю.

Впечатления смешанные - от "ну так это я давно уже знаю", до "ну и зачем это всё".

Цитата. "Аналитик, непосредственно взаимодействующий с пользователем, только он может быть тестером."

"Аналитик, непосредственно взаимодействующий с пользователем, только он может быть тестером."

Вот нечего добавить. Кроме:

"С точки зрения управления, руководство должно способствовать здоровому антагонизму таких аналитиков с программистами, поскольку в условиях конкуренции и рождается то, что нужно."

Умный человек - подсказал.