По поводу истории с Павленским.

Вот потому то истинно свободный человек стремится использовать свою свободу не для удовлетворения похоти и не для засовывания в себя необычных веществ, а, наоборот, инстинктивно избегает всего этого, чтобы оставить руки свободными для НАСТОЯЩЕЙ борьбы за свободу. (И именно поэтому мне так претит образ Моцарта в «Амадее» Формана, но нравится «Пролетая над гнездом кукушки» - кому многое дано, с того и многое спросится).

Другая мысль давняя, вызванная когда-то нашумевшим интервью жены художника. В том интервью она рассказала, что в их истинно свободной семье свободные родители воспитывают свободных детей тем способом, что не дают им мяса и не пускают в школу (чтобы не заразить детей конформизмом, понятно же). В общем, семейная минисекта со свободой половой ёбли (что и в обычных сектах часто практикуется). Такая вот у детей свобода.

«Метрополис»

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

UPD. Хотя, нашёл любопытное...
http://www.kinozapiski.ru/ru/article/sendvalues/282/
Я часто говорил, что не люблю «Метрополис» только потому, что сегодня не могу согласиться с идейным лейтмотивом фильма. Абсурдно утверждать, что сердце—посред­ник между руками и мозгом, то есть между работодателем и рабочим. Проблема тут социальная, а не этическая. Естественно, во время съемок я фильм любил, а иначе бы не мог продолжать над ним работу...

Тест на знание уголовных дел Алексея Навального.

Тест на знание уголовных дел Алексея Навального.
https://zona.media/test/2016/30/12/opera-omnia
Предлагаю дополнить его следующими вопросами:
1. В последний день суда по делу «Ив Роше» судья Елена Коробченко переквалифицировала обвинение на более лёгкую статью, что, в результате, дало возможность Алексею Навальному участвовать в президентской компании 2018 года.
По какой статье в итоге осудили братьев Навальных?
2. Летом 2013-го года Алексей Навальный заявлял, что подаренные ему Собяниным голоса депутатов-едросов - это верный признак того, что его хотят засудить и к выборам всё равно не допустят.
Что случилось?
3. Почему «Кировлес» продавал лес только людям, приближённым к чиновникам областной администрации?
4. Почему фирма «АвтоСАГА» не могла заключить контракт с «Ив Роше» напрямую, без паразитической прослойки в виде фирмы чиновника «Почты России» Олега Навального?

Вот такие девки пляшут.

У меня адрес Рекси доступен по http, но блокируется по https.

Оригинал взят у rexy_craxy в ... об лавку главою (ц)
Под шумок (?):



Upd.: еще образчики "государственно-частного" криворучия:

Collapse )

Идиоты. Тупые, злобные, криворукие идиоты.


ЗЫ Может, пригодится кому: летом аналогичную "полублокировку" (корень домена и инбокс доступны, остальное нет) наблюдал, работая из назарбаевского Казахстана. Кто у кого пиздит учится?

ЗЗЫ И, да, канал связи "ЛС ЖЖ" отныне считайте [окончательно] проваленным. И инбоксы/подзамки свои ревизируйте. И вообще переходите на Tox, благо он теперь и под АндроЕд имеется.



original post ]  [ comment count unavailable comments ]

Юнит-тестирование и нарушение принципа единой ответственности (Single Responsibility).

Очень раздражают IT-евангелисты. К адептам юнит-тестирования, в особенности TDD, это относится в максимальной степени. Читая таких евангелистов (а они сейчас в IT-пространстве доминируют) не устаю поражаться как тем "истинам", которые бывают приняты за базовые аксиомы, так и всеобщему "заговору молчания", которым встречают голого короля.

Так вот, у адептов юнит-тестирования непререкаемой догмой является эквивалентность понятий "тестируемы код" и "хороший дизайн". Под хорошо спректированным кодом сторонники юнит-тестирования зачастую понимают только тот код, который легко тестируется: этот факт, якобы, само собой свидетельствует о высоком качестве кода и о следовании принципам S.O.L.I.D.
Вот пример с набором типичных рекомендаций как сделать код тестируемым (а дизайн "хорошим").
https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
Тут вы встретите всё, что обычно бывает в таких текстах:
1. Проклятие статическим классам, которые означают "сильное зацепление" и сокрытие явных зависимостей.
2. Проклятие синглтонам из-за их статического характера.
3. Проклятие оператору new, потому что код становится зависимым от конкретных типов, а не от абстракций.
4. Прославление Dependency Injection

Как бы выглядело приложение настоящего TDD-зелота? Нет ни статических классов, ни статических функций вообще (а, значит, нет и синглтонов), все public- и protected-методы помечены как virtual. Приватных методов нет, т.к. приватные методы нельзя сделать виртуальными. Все зависимости между компонентами системы передаются либо в параметрах конструктора, либо в аргументах вызова метода в виде ссылок на интерфейсы. Вот тогда мы всё можем замокать и протестировать до самых кишок.

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

Разве функция расчёта площади треугольника по формуле Герона не носит сама по себе явно статический характер? А расчёт силы гравитации между двумя телами массами m1 и m2 центры которых находятся на расстоянии R друг от друга, разве не является "просто формулой", которую естественне всего представить в виде статической функции?
В мире обычного проектирования, код, которому нужно получить площадь треугольника сделает вызов:
TriangleCalc.GetSquareByGeron(a,b,c);
В мире TDD придётся написать что-то типа:
var triangleCalc = new TriangleCalc();
trianglуCalc.GetSquareBeGeron(a,b,c);
Либо же, помятуя о запрете оператора new, вводить интерфейс ITriangleCalc и передавать компоненту экземпляр интерфейса в виде "явной зависимости".

Впрочем, TDD-евангелисты, глядя на такие примеры, скорее всего согласятся, что это перебор, даже, наверное, помянут антипаттерн "академическое приложение": дескать, не такие уж мы экстремисты и ко всякой рекомендации надо подходить с умом. Но в том-то и проблема, что рекомендации евангелистов (и IT-сфера здесь не исключение) всегда носят абсолютный характер. "Статика - зло", - об этом кричат везде и повсюду. Но никто не напишет о том, когда статика - это правильно и хорошо и в каких случаях её следует использовать. Другая же проблема заключается в том, что необходимость тестирования действительно может нарушить ранее принятый хорошо спроектированный дизайн.

Рассмотрим случай с кэшированием. Пользователю достуен некий метод GetByKey(key) класса XXX и мы хотим убедиться, что в случае двух последовательных обращений по одному и тому же ключу функция Load(key) будет вызвана лишь однажды, а в другой раз последует обращение к кэшу. Если тестировать объект как чёрный ящик, проверить это мы никогда не сможем. Но мы можем раскрыть содержимое этого чёрного ящика, отнаследовавшись от класса XXX и переопеделив в классе-наследнике метод Load таким образом, чтобы он увеличивал счётчик обращений при каждом своём вызове. Но, стоп!, для этого переопределяемый метод должен быть объявлен как virtual protected. А в соответствии с намерениями нашего дизайна, этот метод объявлен у нас приватным, потому что не было никакой необходимости его переопределять. Ничего не поделаешь, придётся вносить изменения в код класса XXX.

Рассмотрим теперь вопрос взаимодействия компонентов. В проекте, над которым я в данный момент работаю, есть класс XXXParser, который разбирает старый экзотический "язык" XXX, есть класс YYYGenerator, который помогает строить YYY-скрипты, и есть класс Converter, который представляет собой типичный медиатор - он женит парсер с генератором и перегоняет скрипты из одного языка в другой. Так вот, в этом конвертере откровенно нарушаются догмы TDD-проектирования. Мой медиатор обращается к XXXParser-у через его статический фасад, а для генерации YYY-кода он обращается напрямую к статическому классу YYYGenerator. Да, такой класс не замокаешь. Чтобы сделать код класса тестируемым (в терминах "белого ящика"), мне пришлось бы избавляться от статики, вводить пару интерфейсов IXXXParser и IYYYGenerator, а затем "настраивать" класс Converter путём передачи объектов парсера и генератора через конструктор. Но дело в том, что за пределами задачи тестирования я совершенно лишён мотивации строить проектное решение подобным образом. Ни мой Parser, ни мой Generator не представляют собой кандидатов для использования паттерна стратегия - это типичные "хэлперы", мне в голову не приходит такой случай, при котором вариативность алгоритмов парсинга или генерации была бы востребована. Мой Converter делает именно то, что и задумывалось по дизайну. Да, он не раскрывает все свои зависимости "явно" посредством длинного списка аргументов конструктора, зато имеет своим плюсом ясность и лаконичность использования в клиентском коде.

Обобщая вышесказанное мы видим, что дизайн, разработанный на основе анализа бизнес-требований, весьма разительно отличается от того дизайна, который получился в результате добавления требования о тестировании. Требование тестируемости - это дополнительная обязанность класса: наш класс должен не только хорошо выполнять свои бизнес-функции, но и позволять себя тестировать модульному коду. На классе теперь лежит две обязанности, а это прямое нарушение принципа Single Responsibility.

P.S. Большой постскриптум.
Моё твёрдое убеждение состоит в том, что слепое следование принципам TDD способно разрушить хороший дизайн. Сегодняшний день я потратил на поиски человека, который бы не побоялся сказать про "голого короля". И нашёл. Ниже будут цитаты.
James O Coplien
http://rbcs-us.com/documents/Segue.pdf
It can be even worse: the very act of unit testing may cause the interface of the map to grow in a way that’s invisible in the delivered program as a whole. Felix Petriconi and I have been debating the unit testing issue in Email, and today he wrote me that: “You are right. E.g. we introduced in our application lots of interfaces to get the code under (unit) test and from my point of view the readability degraded.” David Heinemeier Hannson calls this “test-induced design damage:” degradation of code and quality in the interest of making testing more convenient (http://david.heinemeierhansson.com/2014/testinduced-design-damage.html). Rex Black adds that such tradeoffs exist at the system level as well as at the unit level.

David Heinemeier Hansson
http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
It's from this unfortunate maxim that much of the test-induced design damage flows. Such damage is defined as changes to your code that either facilitates a) easier test-first, b) speedy tests, or c) unit tests, but does so by harming the clarity of the code through — usually through needless indirection and conceptual overhead. Code that is warped out of shape solely to accomodate testing objectives.
...
I think part of why we've been able to go so long with only murmurs of a debate about the value of TDD as a design principle, is post hoc rationalization. If you accept the premise that red-green-refactor is the true guiding light for all programming design, any sacrifices on its altar seem trivial. Who cares if you need two or three extra layers of indirection to unit test a controller? OF COURSE it's worth it.
...
I think part of why we've been able to go so long with only murmurs of a debate about the value of TDD as a design principle, is post hoc rationalization. If you accept the premise that red-green-refactor is the true guiding light for all programming design, any sacrifices on its altar seem trivial. Who cares if you need two or three extra layers of indirection to unit test a controller? OF COURSE it's worth it.
...
Above all, you do not let your tests drive your design, you let your design drive your tests! The design is going to point you in the right direction of what layer in the MVC cake should get the most test frosting.

When you stop driving your design first, and primarily, through your tests, your eyes will open to much more interesting perspectives on the code. The answer to how can I make it better, is how can I make it clearer, not how can I test it faster or more isolated.

The design integrity of your system is far more important than being able to test it any particular layer. Stop obsessing about unit tests, embrace backfilling of tests when you're happy with the design, and strive for overall system clarity as your principle pursuit.


P.P.S. Стоит ещё упомянуть статью Сергея Теплякова «Тестируемый дизайн vs. хороший дизайн». Статья не направлена против юнит-тестирования, но в ней явно проводится мысль о том, что "хороший дизайн" стоит на первом месте.

Мошеннические лайки в FB.

Не знаю насколько это новость, но выяснилось то, что я давно подозревал.
FB ставит рекламным записям фейковые "лайки" от друзей.

Т.е., когда такая запись появляется в вашей ленте, в левом верхнем уголочке вы можете увидеть "лайк" якобы от френда и ещё успеете удивиться, почему это ваш друг тянет в вашу ленту подобную фигню. Лайки, очевидно, проставляются случайным образом, для чего они служат, думаю, объяснять не нужно. Если пройти по рекламной ссылке, то лайка френда вы уже не обнаружите. О така фигня, малята.

Кому жаловаться и что с этим делать? Никому не жаловаться и ничего не делать - куда же вы денетесь с подводной лодки? Времена, когда Цукерберг и компания делали КРУТУЮ ВЕЩЬ (если верить создателям фильма «Социальная сеть») давно прошли, теперь ребята пожинают плоды.

Навальный и выборы (или снова к вопросу о борьбе нанайских мальчиков).

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

http://pravo.ru/news/view/115907/
Изначально Навальным были предъявлены обвинения в мошенничестве по 4-й части "обычной" 159-й статьи Уголовного кодекса, которая предусматривает лишение свободы до 10 лет. Но 30 декабря 2014 года Елена Коробченко, судья Замоскворецкого райсуда Москвы переквалифицировала инкриминирумые им деяния на мошенничество в сфере предпринимательской деятельности (ч. 2, ч. 3. ст. 159.4 УК РФ – до пяти лет лишения свободы).

Вот так вот лёгким движением своей судейской длани перед самым приговором Елена Коробченко переквалифицировала Навальному обвинение из тяжёлого преступления (до 10 лет) в преступление средней тяжести (до 5 лет) и дала тем самым возможность последенему принимать участие в выборах 2018-го года.

Стоит напомнить, а то опять заплесневелый пасквиль гулять вбросили.

Оригинал взят у ffedd_ya в N123 разбор мифов про Кубу
В последнее время в интернете публикуется текст, на тему "как всё хорошо было на Кубе до Фиделя" (тут например - http://ibigdan.livejournal.com/9983730.html)

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

Ниже разборCollapse )