среда, 11 ноября 2015 г.

#1183. Для себя. Про "новые" скрипты генерации

Генерировать списки "запускалок" для каждого элемента, который имеет генерируемые дочерние элементы.

Примерно так:

BeginList
Item Self.runner
IncludeList List1.runner
...
IncludeList ListN.runner
EndList

Чтобы это потом можно было ПРОЗРАЧНО запускать "запускалкой" скриптов.

вторник, 10 ноября 2015 г.

#1182. Для себя

Сделать DisableObjectsCache и проверить где объекты "убиваются невовремя".

При загрузке слов скриптовой машины OnDemand.

вторник, 3 ноября 2015 г.

#1181. Ссылка. Icon (язык программирования)

#1180. Ссылка. Метапрограммирование

https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%B0%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#.D0.93.D0.B5.D0.BD.D0.B5.D1.80.D0.B0.D1.86.D0.B8.D1.8F_.D0.BA.D0.BE.D0.B4.D0.B0

Цитата:

"
  • В Perl существует понятие «source filters» («фильтров исходного кода») — метода переработки файлов с исходным кодом перед выполнением, позволяющего полностью менять синтаксис и семантику языка. Одним из известных примеров является модуль Lingua::Romana::Perligata, позволяющий писать код Perl на латыни.[2]
  • В Форт программисту предоставляют встроенные в язык возможности по изменению своего синтаксиса и семантики. Это достигается определением архитектуры виртуальной машины и полного доступа к возможностям изменения её составляющих.
"

#1179. Ссылка. Введение в RxJava, часть первая – Вступление: Ключевые типы

http://m.habrahabr.ru/post/270023/

Цитата:

"Rx базируется на двух фундаментальных типах, в то время, как некоторые другие расширяют их функциональность. Этими базовыми типами являются Observable и Observer, которые мы и рассмотрим в этом разделе. Мы также рассмотрим Subject’ы – они помогут в понимании основных концепций Rx.

Rx построена на паттерне Observer. В этом нет ничего нового, обработчики событий уже существуют в Java (например, JavaFX EventHandler[1]), однако они проигрывают в сравнении с Rx по следующим причинам:
  • Обработку событий в них сложно компоновать
  • Их вызов нельзя отложить
  • Могут привести к утечке памяти
  • Не существует простого способа сообщить об окончании потока событий
  • Требуют ручного управления многопоточностью.
"

#1178. Цитата

"Ещё одно проявление уродства MDA: Коллега что-то поделал - у меня сгенерировалось 300 изменённых файлов. Из них моих - 5. В результате запросто можно закоммитить что-то не собираемое, поскольку обозреть все 300 файлов не реально. А в условиях первобытно-общинной системы контроля версий это превращается в сущий дизастр."

Полностью согласен. Такая проблема НЕ ТО ЧТО есть, она - ОСТРО стоит.

Проблема ОТЧАСТИ (отчасти именно капс-локом) в том, что "НОРМАЛЬНЫХ"инструментов для MDA/MDP "на рынке" так и нет.

А надо ли?

Хотя свои "изыскания" - я всё ещё продолжаю. Мне "деваться некуда".

Да и есть"мысли"...

#1177. Ссылка от Теплякова. Дрейфусы, аджайлы и прочие страшные слова

http://sergeyteplyakov.blogspot.ru/2015/11/agile-drayfus-and-other-scary-terms.html

Цитата:

"Другими словами, для того, чтобы «гибкая» команда была эффективной в ней должна быть критическая масса специалистов двух последних уровней. Конечно, это не гарантия результата, это лишь необходимые требования. Это значит, что нельзя забить на отбор сотрудников, набрать десяток человек средней компетенции, добавить к ним «продакт оунера», сказать, что «мы теперь работаем по скраму» и рассчитывать на положительный результат.
Для того, чтобы «гибкая» команда была эффективной, в ней должны быть специалисты (гуру и выше) во всех ключевых областях разработки.
Нужно, чтобы кто-то умел собирать требования и их анализировать, ведь это нельзя отдать просто на откуп «продакт-оунера», как многие полагают.
Кто-то должен уметь дизайнить и архитектурить ПО. «Херак-херак и в продакш», несмотря на популярность, является не лучшим подходом. Важно, чтобы в команде были люди, знающие ключевые архитектурные паттерны и последствия их применения.
Нужен кто-то толковый в тестировании, в базах данных, в целевой платформе, все это важно, чтобы качество продукта было на достойном уровне. И тут явно недостаточно книги «Изучи что угодно за 21 день» или подхода «да ладно, у нас гибкая команда, все должны быть взаимозаменяемыми».
А теперь вспомните свои «гибкие» команды и скажите, насколько они соответствовали этим критериям? Я почти уверен, что если команда соответствовала этим критериям, то успеху мог помешать очень тупоголовый заказчик или совсем уж неадекватный менеджер. Ну а если у команды не хватало компетенции в ключевых областях, то быстро становилось понятно, что одним скрамом проект не построить или построить, но не тот, или не к тому сроку, когда нужно."

Не смог процитировать меньше.

И комментарии:

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

"Полностью согласен.

А вообще, меня очень веселит, когда где-то звучит "настоящий скрам" или "а у нас все вообще по скраму". 

"Строгое следование гибким методологиям" - это же как "теща - девственница":))"