CustisWiki - Новые страницы [ru]

Не умеешь - научим… Организация обучения тестировщиков до уровня, необходимого для начала работы (Светлана Яковлева, SQADays-11)

2012-05-17T18:09:55Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://www.linkedin.com/pub/svetlana-yakovleva/22/394/a97 Светлана Яковлева] <blockquote> В пос...»

Тестирование игр на мобильных устройствах и 3D телевизорах (Ольга Олейник, SQADays-11)

2012-05-17T18:07:01Z

StasFomin:

Feature Injection - работаем с требованиями (Алла Копылова, SQADays-11)

2012-05-17T17:52:19Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://www.linkedin.com/pub/alla-kopylova/3b/18/509 Алла Копылова] <blockquote> Уже давно ст...»

Не баг-трекер, а ... (Максим Кузьмич, SQADays-11)

2012-05-17T17:37:22Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://maksim-kuzmich.moikrug.ru/ Максим Кузьмич] <blockquote> Современный тестиров...»

Использование cygwin для автоматизации процессов тестирования в Windows (Игорь Рыбак, SQADays-11)

2012-05-16T14:18:45Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [Игорь Рыбак] <blockquote> При тестировании мы сталкиваемся со множес...»

Регрессионное тестирование методом свободного поиска (Сергей Вербенко, SQADays-11)

2012-05-16T14:07:52Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://sergeyverbenko.moikrug.ru/ Сергей Вербенко] <blockquote> Очень редко стоит во...»

Как я работу менял (Алексей Лянгузов, SQADays-11)

2012-05-16T14:02:56Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [Алексей Лянгузов] <blockquote> Доклад не запланирован, как и смена ра...»

Автоматизация тестирования модели разграничения прав доступа к функционалу (Андрей Терехин, SQADays-2011)

2012-05-16T13:23:02Z

StasFomin: /* Слайды */

DIY Java Profiling (Роман Елизаров, ADD-2011)/Стенограмма

2012-05-08T10:38:19Z

StasFomin:

У меня сегодня будет доклад про «Сделай себе сам профилирование на Яве». Слайды будут на английском, доклад я буду делать на русском. Слайдов очень-очень много, а времени не так много, поэтому я буду какие-то очень быстро проскакивать, и постараюсь оставить больше времени в конце на вопросы, и может быть даже где-то в середине. В принципе, не стесняйтесь, если захочется вдруг что-то спросить или уточнить, и даже меня прервать. Я лучше подробнее освещу то, что вам интересно, чем буду просто рассказывать то, что я хотел рассказать.

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

Профилирование приложения — неизбежный компонент любой оптимизации, оптимизация без профилирования невозможна. Вы профилируете, находите узкие места, оптимизируете-профилируете, это постоянный цикл.

Почему доклад называется «Do It Yourself Java Profiler», зачем что-то делать самому? Есть же огромное количество готовых инструментов, которые помогают профилировать — собственно профилировщики, и подобные инструменты.

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

Мы, когда пишем финансовые приложения, у нас есть еще задача обеспечить надежность системы. И мы делаем не «банки», где главное — не потерять ваши деньги, но которые могут быть часами недоступны. Мы делаем брокерские системы онлайн-торговли, где постоянно 24×7 доступность систем, это одна из ключевых их качеств, они никогда не должны падать.

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

Но и инструменты частенько непрозрачны. Да, есть документация, которая описывает «что», но она не описывает, как именно он достает эти результаты, и не всегда можно понять, что он собственно намерял.

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

В чем проблема с изучением? Естественно, если вы используете какой-то инструмент часто, то стоит его учить. Если вы программируете каждый день в какой-то любимой вами среде разработки, вы ее знаете вдоль и поперек, и это знание, естественно, окупается вам сторицей.

А если вам нужно что-то сделать раз в месяц, например, раз в месяц вам нужно ради бага с производительностью заниматься профилированием, то не факт, что изучение соответствующего инструмента окупится. Конечно же, если нет ситуации, когда инструмент решает задачу в разы быстрее.

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

Почему доклад о Java? Ну мало того, что наша компания программирует на Java, это ведущий язык 2001 года по индексу TIOBE, отлично подходит для enterprise приложений. А для данной конкретной лекции вообще замечательно — потому что Java — это managed язык, работает в виртуальной машине, и именно профилирование в Java делается очень легко.

Я буду рассказывать во-первых, просто о том, как решить многие проблемы профилирования, написав некий код на Java. Скажу о возможностях Java-машин, которые можно использовать, и расскажу о такой технике, как манипулирование байт-кодом.

Мы посмотрим сегодня на профилирование как CPU, так и памяти. Я расскажду про разные техники.

Профилирование CPU. Самый простой способ, это просто взять и запрограммировать. Если вам нужно разобраться, куда, сколько, чего, в вашей программе занимает времени, и сколько раз вызывается, то самый-самый простой способ: не надо никаких инструментов, ничего — написать просто несколько строчек кода.

В Java есть замечательная функция «currentTimeMillis», которая возвращает текущее время. Можно ее замерять в одном месте, замерять в другом, а дальше можно посчитать, сколько раз это сделано, суммарное время, минимальное и максимальное время, все что угодно. Самый такой простой способ. DIY в своей максимальной простоте и примитивизме.

Как ни странно, на практике способ отлично работает, приносит кучу пользы — потому что быстр, удобен и эффективен.

Когда этот метод хорошо работает? Это замечательно работает для бизнес-методов — бизнес-метод большой, вызывается не очень часто, и вам нужно что-то про него измерить. Более того, написав этот код, раз уж вы его написали — он становится частью вашего приложения и частью функционала. Более менее любое современное большое приложение содержит интерфейсы управления, какие-то статистики, … и в общем производительность приложения — это одна из трех вещей, которую часто хочется видеть, чтобы приложение о себе выдавало, просто как часть своего функционала.

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

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

Это возможно, если вы этот код пишете сами, собираете статистику, встраиваете сами в свое приложение.

Более того, вам, как человеку, который занимается циклом профилирования-оптимизации, вы потом эту информацию используете — что же в вашем приложении происходит? Эта информация всегда находится внутри вашего приложения, код работает в живой системе. У вас произошел какой-то неудачный день, что-то система не так работала, вы можете посмотреть в логах эту статистику, разобраться, и так далее.

Замечательная методика, нет никаких сторонних инструментов, только немножко кода на яве.

Что же делать, если методы короче, и вызываются чаще?

Дело в том, что такой прямой метод уже не подойдет, потому что метод «currentTimeMillis» не быстрый, и меряет только в миллисекундах.

Если вам нужно замерить только количество вызовов, то достаточно быстро можно это сделать используя Java-класс «AtomicLong». С его помощью, вы можете, внося минимальный вклад в производительность, посчитать количество вызовов какого-нибудь интересующего вас метода. Это будет работать до десятков тысяч вызов в секунду, не сильно искажая работу самого приложения.

Что же делать, если вам нужно еще замерить время выполнения? Замер времени исполнения коротких методов — это очень сложная тема. Стандартными никакими методами она не решается, несмотря на то, что в Java есть метод «systemNanoTime», он эти проблемы не решает, он сам по себе медленный, и с помощью него что-то быстрое сложно замерить.

Единственный реальный выход — это использовать нативный код, для x86 процессора есть такая замечательная инструкция rdtsc, которая возращает счетчик количества тактов процессора. Напрямую к ней доступа нет, можно написать на C однострочный метод, который вызывает «rdtsc», а дальше слинковать его с Java-кодом, и вызывать из Java. Этот вызов вам займет сто тактов, и если вам нужно замерить кусок кода, который занимают тысячу-другую тактов, то это осмысленно, если у вас идет оптимизация каждого машинного такта, и вы хотите понять, «плюс-минус», «быстрее-медленнее», как вы работаете. Это действительно редкий случай, когда вам нужно оптимизировать каждый такт.

Чаще всего, когда речь идет о каких-то более коротких кусках кода, и более часто вызываемых, используют другой подход, который называется «семплирование». Вместо точных замеров, сколько раз и чего вызывается, вы периодически анализируете выполнение программы, смотрите, где она исполняется, в произвольные моменты времени, например — раз в секунду, или раз в десять секунд.

Смотрите, где происходит исполнение, и считаете, в каких местах вы застаете свою программу часто. Если у вас в программе есть строчка, в которой она тратит все, или по крайней мере 90% своего времени, например, какой-нибудь цикл, а там, в глубине, какая-то строчка, то скорее всего, при остановке исполнения вы ее в этой строчке и застанете.

Такое место в программе называется «горячей точкой». Это всегда замечательный кандидат для оптимизации. Что классно — есть встроенная фукнция под названием «thread dump», чтобы получить дамп всех потоков. В Windows она делается путем нажатия CTRL-Break на консоли, а на Linux и других юниксах это делается посылкой третьего сигнала, командой «kill -3».

В этом случае, Java-машина на консоль выводит подробное описание состояния всех потоков. И если у вас действительно есть горячее место в коде, то скорее всего программу там и застанете. Поэтому опять же, когда у вас проблема производительности с кодом, не надо бежать к профилировщику, не надо ничего делать. Видите, что тормозит, сделайте хоть один thread dump, и посмотрите. Если у вас одно горячее место, в котором программа тратит все время, вы в thread dump и увидите эту строчку, в своей любимой среде разработки, без использования каких-нибудь сторонних, дополнительных инструментов. Посмотрите этот код, изучите, оптимизируйте — либо он слишком часто вызывается, либо он медленно работает, дальше уже разбор полетов, оптимизация, либо дальнейшее профилирование.

Также в современных Java-машинах есть замечательная утилита «jstack», ей можно передать идентификатор процесса, и получить на выходе thread dump.

Сделайте не один thread dump, сделайте несколько thread dumpов. Если первый ничего не выловит, посмотрите еще на пару-тройку. Может у вас в горячей точке не сто процентов времени программа проводит, а 50%. Сделав несколько thread dumpов, вы явно в хоть какой-то из этих моментов, достанете ваш код из горячей точки, и глазками посмотрите те места, где вы застали ваш код.

Эту идею можно развить дальше. Можно, запустив ява-машину, перенаправить ее выход в файл, и запустить скрипт, который делает thread dump каждые три секунды. Это можно делать совершенно спокойно на живой системе, без какого либо риска что-то с ней сделать. Потому что сам сбор thread dump досточно быстрая процедура, занимает от силы 100 миллисекунд, даже при очень большом количестве тредов.

А если вы пишите на яве, то скорее всего ваша система не hard real time, и вам там наносекунды не важны, потому что у вас уже периодически встречается сборка мусора и так далее. Т.е. вам лишнее засыпание системы на сто миллисекунд катастрофы не создает.

И даже в нашей, финансовой области, большинство систем, которые мы пишем, мы пишем все-таки для людей, с ними работают люди, да, там миллионы котировок в секунду, да, есть роботы (это отдельная история), но чаще всего на эти котировки смотрит человек, который плюс-минус 100 миллисекунд в глаза не заметит. Человек заметит, если будет торможение на двести миллисекунд, это уже будет заметная для человека задержка, но сто миллисекунд — нет.

Поэтому можно не переживать о лишних ста миллисекундах, и раз в три секунды делать thread dump, можно совершенно безопасно, даже на живой системе. При этом thread dump, это часть java-машины, хорошо оттестированная — я за весь свой опыт работы ни разу не видел, чтобы попытка сделать на Java-машине thread dump сделала с ней что-то плохое.

Т.е. это совершенно безопасный инструмент профилирования живых и работающих систем. После этого, получив файл thread dump, его можно посмотреть глазками, а можно написать несложный кусок кода, который анализирует, считает какие-нибудь статистики → хотя бы тупо, посмотреть, какие методы проявились и сколько раз, посмотреть, в каком состоянии находились потоки.

При этом если стандартные инструменты профилирования, действительно смотрят на состояние потока, которое выводит Java-машина («RUNNABLE»), то в реальности, ваше состояние ни о чем не говорит, потому что если ваша программа много работает с базой данных, и много работает с какими-то внешними… сетью, то ваш код может ожидать получение данных по сети, при этом java-машина его считает «RUNNABLE», и вы ничего не сможете понять — какие у вас реально методы, и какие ждут данных от сети. С другой стороны, если вы сами анализируете стеки, — вы можете написать, вы-то знаете, что ваша программа делает, что вот это — вызов в базу данных, что этот метод в стеке означает, что вы вошли в базу данных, можете посчитать, сколько процентов времени вы проводите в базе данных, и так далее, тому подобное. Вы можете знать, что вот этот метод на самом деле CPU не жрет, хотя java-машина думает, что он «RUNNABLE».

Более того, thread dump можно интегрировать в приложения, в Java есть замечательный метод

Thread.getAllStackTraces

который позволяет получить информацию о stacktrace программно.

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

Но есть проблема. Дело в том, что когда вы Java-машину просите сделать thread-dump, она не просто процесс останавливает, и делает стек, она включает флажок, что ява-машине надо бы остановится в следующем безопасном месте. «Безопасное место» — это специальные места, которые расставляет компилятор по коду, где у программы есть определенное состояние, где понятно, что у нее в регистрах, понятна точка исполнения, и так далее. Если брать кусок последовательного кода, где нет никаких обратных переходов, никаких циклов, то там «safe point» может не оказаться вообще. Причем неважно, что вызовы методов могут заинлайнится hotspot-ом, и savepoint-ов тоже не будет.

Поэтому если вы видите в thread dumpe какую-то строчку — это совершенно не значит, что это горячая строчка вашего кода, это просто ближайший savepoint к горячей точке. Потому что когда вы нажимаете «CTRL-BREAK», Java всем потокам выставляет флажок «остановиться на ближайшем savepointе», и только когда они останавливаются, Java-машина анализирует, в каком состоянии они это делают.

Теперь перейдем к профилированию памяти, как это делается.

Во-первых, есть замечательные, готовые фичи Java-машина. Есть отличный инструмент jmap, который выводит гистограмму того, чем у вас забита память, какие объекты и сколько памяти занимают. Это замечательный инструмент для общего обзора, что же у вас происходит, и чем забита память.

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

Проблема в том, что вы таким образом получите информацию о всех объектах, даже тех, которые сейчас в данный момент не используются, находятся в мусоре.

Поэтому у jmap есть специальная опция «live», которая перед тем, как сделать гистограмму делает сборку мусора, оставляет только используемые объекты, и только после этого строит гистограмму.

Проблема, что уже с этой опцией, большую, живую систему работающую с многими гигабайтами памяти, запрофилировать нельзя, потому что сборка мусора системы, работающей с десятком гигабайт памяти занимает десяток-другой секунд, и это может быть неприемлимо… в любой системе, если ваша система работает с конечными людьми, человек, которому система дольше трех секунд не отвечает, считает, что она зависла. Нельзя живую, работающую с человеком систему останавливать дольше чем на секунду, на самом деле. Даже секунда уже будет человеку заметна, но еще не катастрофа, но если вы подключите какой-то инструмент, который остановит на 10 секунд — то это будет катастрофа. Поэтому часто приходится довольствоваться на живых системах jmap-ов тех объектов, которые есть, и в целом, неважно, мусор это или нет.

Также дополнительно полезно знать дополнительные опции Java-машин. Например, у Java-машин можно попросить отпечатать гистограмму классов, когда вы делаете thread dump → «PrintClassHistogram».

Ява-машину можно попросить при исчерпании памяти записывать свое состояние на диск. Это очень полезно, потому что обычно, люди начинают оптимизировать потребление памяти только тогда, когда она заканчивается почему-то. Никто не занимается профилированием, когда все хорошо, а вот когда программе начинает памяти не хватать, она вылетает, начинают думать, как бы так соптимизировать. Поэтому это опцию полезно всегда иметь включенной. Тогда в плохом случае Java-машина вам запишет бинарный дамп, который вы можете потом, не на живой системе, любыми инструментами проанализировать. При этом, этот дамп можно в любой момент взять с Java-машины, тем же jmap-ом, с опцией «-dump», но это, опять же, останавливает Java-машину на долгое время, на живой системе вы это вряд ли заходите делать.

Реплика из зала: Там есть свойство, что этот «HeapDumpOutOfMemory» оптимизирован для тех случаев, когда память уже кончилась.

Да, конечно. «HeapDumpOutOfMemory» очень полезная опция, причем хотя она «-XX», не надо этих опций бояться, хотя этот «XX» подчеркивает их мегаспециальность, но это не экспериментальные опции, это нормальные production-опции ява-машины, они стабильные, надежные, их можно использовать на живой, реальной системе.

Это не экспериментальные опции! В java-машине есть четкое деление, но деление на экспериментальные и неэкспериментальные опции не зависит от числа X-ов.

Реплика из зала: Эта опция иногда не откладывают дампы…

Ну, в java-машине тоже бывают баги, все зависит от того, … бывают разные причины исчерпания памяти, я не буду на этом останавливаться, у нас времени мало.

Я хочу остановится на очень важном моменте, в оставшееся время, а именно, на профилировании выделения памяти.

Одно дело — чем память занята, как вы ее вообще используете. Если у вас где-то в коде есть излишнее выделение временной памяти, т.е. вы выделяете, … что-то с ним делаете, этом методе и потом забываете, он уходит в мусор, и garbage collector потом его забирает. И так вы делаете снова и снова, ваша программа будет работать медленнее, чем бы она работала с этим … но вы никаким профилировщиком по CPU это место кода не найдете, потому что сама операция выделения в Java-машине памяти, работает фантастически быстро, быстрее, чем в любом не-managed языке, C/C++, потому что в Java выделение памяти это банально увеличение одного указателя. Все. Это несколько ассемблерных инструкций, все очень быстро происходит. Она уже предварительно обнулена, все уже выделено и подготовлено. Вы этого времени при анализе горячих точек вашего кода не найдете — оно не высветится у вас никогда, ни в каком thread dumpe, ни в каком профилировщике, что это у вас горячая точка. Хотя у вас это все будет жрать ваше время, работы вашего приложения — почему? Потому что потом, сборщик мусора будет тратить время, чтобы этот мусор собрать. Поэтому смотрите, на то, сколько процентов времени ваше приложение тратит на сборку мусора.

Это полезная опция «-verbose:gc», «+PrintGC», «+PrintGCDetails», которые позволят вам разобраться, сколько времени вашего приложения уходит на сборку мусора. Если вы видите, что на сборку мусора уходит существенный процент времени, значит вы где-то в программе много выделяете памяти, вы это место не найдете, нужно искать, кто выделяет память.

Как искать? Есть встроенный в Java-машину способ, ключик «-Xaprof». Он вам, к сожалению, только при завершении процесса, выводит так называемый allocation profile, который говорит не о содержимом памяти, а о статистике выделяемых объектов → какие объекты и как часто выделялись.

Если у вас это действительно часто происходит, вы скорее всего увидите, что где-то заведен какой-то временный класс, который действительно очень часто выделяется. Попробуйте сразу сделать «aprof» — может вы сразу найдете вашу проблему.

Но не факт. Может получится ситуация, что вы увидите выделения большого количества массивов character-ов, каких-то string-ов, или чего-нибудь, и непонятно где.

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

А что делать, если у вас нет идеи, где это происходит? Ну надо как-то добавить сбор статистики всюду, по всем местам, где выделяется память. Для такого рода задач отлично подходит аспектно-ориентированное программирование, либо прямое использование манипуляций байт-кодом.

Я сейчас за оставшееся время попробую остановится как раз на технике манипуляции байт-кодом, которая как раз подходит, для решения задач типа «вот я хочу во всех местах, где выделяется массив, посчитать, сколько раз в этом месте это происходит, по всему своему коду, чтобы найти то самое место, в котором я почему-то очень много массивов int-ов выделяю». Т.е. я вижу, что их много выделяется, но я просто хочу найти где.

Манипулирование байткодом позволяет не только эти задачи решить, она позволяет любые изменения, нефункциональные, в код вносить, уже после его компиляции. Тем самым, этот способ декомпозировать профилирование от бизнес-логики. Если в начале я говорил, что часто профилирование может быть логичной частью вашего функционала, то бывают случаи, когда это не нужно, когда вам нужно найти проблему, решить, и чтобы никаких строк не осталось. В этом случае подходит такая замечательная техника, как манипулирование байт-кодом.

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

Самый лучший способ, который я знаю, это использовать библиотечку ASM, ObjectWebовскую. Это open-source библиотека, которая позволяет очень легко заниматься манипуляцией байткодом, и она фантастически быстрая — можно манипулировать кодом на лету, не сильно замедляя время загрузки приложения.

ASM устроен очень просто. У него есть класс под названием class-reader, который читает .class-файлы, и преобразовывает байтики, используя шаблон Visitor, в набор вызовов вида «я вижу метод», «я вижу поле с такими-то полями в этом классе» и так далее. Когда он видит метод, он начинает с помощью «MethodVisitor» сообщать, какой он там видит байт-код.

А потом есть, с другой стороны, такая штука, как «ClassWriter», который наоборот, превращает класс в массив байтиков, который нужен ява-машине.

Чтобы например, с помощью ASM-а, отследить все выделения массивов… в-общем, это делается примитивно. Вам нужно всего парочку классов сделать. Вам нужно определить свой класс-адаптер, который, когда ему говорят, что виден метод, перекрывает, и возвращает свой собственный метод-visitor, чтобы оузнать, что в этом методе происходит.

А когда внутри метода ему говорят, что вот, есть целочисленная инструкция с байт-кодом выделения массива («NEWARRAY»), то в этот момент, он имеет возможность … вставить свои какие-нибудь байткоды в восходящий поток и все. И вы отследили все места, где у вас выделяются массивы, и поменяли соответствующий байт-код.

Дальше — что делать, если вы хотите эти изменения делать на лету.

Если у вас есть набор скомпилированных классов — то это легко → вы как бы обработали этим инструментом, и все.

Если вам это нужно делать на лету, то в java-машине есть замечательная опция — javaagent. Вы делаете специальный jar-файл, у которого в манифесте указываете опцию «Premain-Class», и указываете там имя своего класса. Потом … метод «premain» по определенному шаблону, и тем самым, вы еще до запуска основного кода, c main-методом, получаете управление, и получаете указатель на interface instrumentation. Этот интерфейс замечательный, он позволяет вам, на лету, менять классы в java-машине. Он позволяет вам поставить свой собственный class-file трансформер, который Java-машина будет вызывать для каждой попытки загрузки класса.

И вы сможете классы подменять. Т.е. загружать не только те классы, которые на самом деле лежат, а с помощью того же ObjectWebASM, анализировать что-то, менять, и подменять их на лету… можете узнать размер выделенного объекта.

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

В завершении скажу, что совершенно не обязательно, для решения каких-то задач профилирования владеть каким-нибудь инструментом, достаточно знать байт-код, знать опции ява-машины, и знать стандатные ява-библиотеки, тот же javalang-инструмент. Это позволяет решить огромное число специфичных проблем, с которыми вы сталкиваетесь. Мы за десять лет у себя в компании разработали несколько доморощенных инструментов, которые решают проблемы не специфичные нам, которые не решают специфичные профилировщики. Начиная с того, что у нас в процессе работы появился развесистый, но тем не менее простой инструмент который анализирует thread dump, и выдает по ним статистику, это тем не менее простая утилитка, которую нельзя назвать инструментом. Классик на несколько страничек, который собирает статистику и выдает ее в красивом виде. Дико полезен, потому что нам не надо в production систему подключать какие-то профилировщики, просто thread dump, и все…

И кончая тем, что у нас есть свой собственный инструмент профилирования памяти, который опять же, маленький, его сложно назвать инструментом, который отслеживает, где и что выделяется, причем делает он это, практически не замедляя программы. Причем как коммерческие, так и открытые профилировщики, они тоже умеют отслеживать выделение памяти, но они пытаются решить проблему более сложную, и универсальную. Они пытаются узнать, в каком месте выделение памяти происходит, с полным stack-trace'ом. Это долго, это сильно замедляет. Не используют то же семплирование. Не всегда собирают, тем самым получая не всю статистику, и так далее.

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

Теперь я будут отвечать на вопросы (ответы на вопросы с 30:06).

Nemerle Deep Dive (Владислав Чистяков, ADD-2011)/Стенограмма

2012-05-07T21:47:08Z

StasFomin:

Здравствуйте, меня зовут Владислав Чистяков, я представляю здесь коммьюнити нового языка программирования Nemerle, и буду рассказывать о нем. На самом деле рассказ будет разделен на две части, в этом зале пройдет только такая, общая презентация, из которого можно будет узнать, что это такое, грубо говоря, на верхнем уровне, и посмотреть, что с этим можно делать. А остальная, большая часть докладов пройдет в другом зале, в малом, это будет дольше, там можно будет задавать серьезные вопросы, показывать код и так далее.

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

Основной источник заимствования — это C#. Из C# взята система типов, если кто знает такое название — номинативная, это когда тип определяется именем, а не какими-то другими атрибутами.

Из C# позаимствованы естественно позаимствованы классы, перечисления, структуры, ну и так далее, т.е. верхняя часть языка, как можно назвать.

Из ML позаимствованы выражения, т.е. внутренняя часть методов, тот самый код, который мы с вами все время пишем, и такой тип данных, как variant. В ML он назывался discriminated union, это нечто похожее на объединение в C, если кто-то не знаком с ML-подобными языками.

Операторы позаимствованы из С, но также можно сказать, что они позаимствованы из C#, это ведь язык, который является наследником.

Все остальное в языке сделано на базе макросов. Макросы, идея макросов, взята из LISP, но макросы Nemerle очень отдаленно похожи на макросы Лиспа, почему — я расскажу в последствие.

Давайте так, сделаем такой простой эксперимент, проведем… поднимите руки те, кто по крайней мере, в общих чертах знает C#? Большинство, я так понимаю.

Ну тогда следующий кадр будет вам понятен, это ничего не делающая программа на C#, демонстрирующая общие элементы языка. Всем видно?

Обратите внимание на подсветившиеся красненьким фрагменты, это фрагменты, которые на Nemerle будут не нужны, их можно будет удалить.

Вот, как будет эта программа выглядеть, если ее переписать на Nemerle. У нас изменились скобочки, через которые описываются параметры типов, изменилось описание параметров и возвращаемых значений функций, пропал return, (вот назад вернемся — все видели?). Появился module вместо статического класса, фактически это просто синоним, чтобы не писать лишней статики на уровне методов. И не нужно указывать тип при создании объекта, можно сказать что это (def) это аналог var, но на самом деле он вводит неизменяемую переменную, т.е. переменную, которую можно один раз определить, и больше не использовать, т.е. биндинг/байндинг.

Кроме того, стали не нужны операторы new (new Test<int>) для создания объекта, теперь это просто функция с именем типа, и не нужно указывать параметры типов, потому, что Nemerle выводит их сам, автоматически, даже в конструкторе и более сложных конструкциях.

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

Первый резон для изменения синтаксиса — это то, что авторы языка были очень неравнодушны к MLю, и они позаимствовали из него все, что они посчитали более удобным и красивым. Вкусовщина, можно сказать.
Второй резон, это то, что язык расширяемый, большая часть конструкций языка сделана на макросах, поэтому языку очень важно иметь регулярную грамматику, чтобы конструкции языка парсились без каких-то там хитрых изысков. Например, в C#, есть как минимум четыре места, которые очень тяжелы для парсинга, соответственно там пишутся очень сложные ручные … или используются весьма мощные генераторы парсеров. По-факту, сегодня все используемые production-парсеры сделаны вручную, или по крайней мере, с ручным участием.

Ну вот, здесь объясняется, что является чем, обратите внимание, return например, не нужен. Почему не нужен return — потому что любой блок кода, последнее значение является его возвращаемым.

Одна из особенностей языка, это то, что любая конструкция в усиляемом языке является выражением, т.е нет так называемых statement-ов(…), т.е. если в C# if например, это statement, то в Nemerle if — это выражение. Но если это выражение возвращает void, т.е. ничего не возращает, то оно аналогично стейтменту C#. И так как этого выделения нет, многие операции делаются проще, и удобнее. Например, вы можете использовать try/catch прямо из выражения, вам не нужно какие-то там лишние переменные вводить, что-то там еще делать, вы можете прямо в середине выражения написать try/catch, обработать ошибочку, и прямо там суммирование с чем-то, если у вас там какие-то целочисленные вычисления.

Кроме того, Nemerle поддерживает так называемый indent-синтаксис, в стиле python-а или F#-а, F# правда позже появился, значительно. Что некоторым очень нравится, так как значительно визуально сжимает код, может сравнить (см. предыдущий слайд-код), это один и тот же код, только записанный в indent-стиле, и в обыкновенном.

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

Я попробую своими словами объяснить… ну давайте я расскажу для начала, почему я сказал, что ядро все из ML-я, а потом, объясню, зачем этот язык был создан, и что он дает.

Итак, вот весь список доступных выражений в языке, на экране перед вами. Всем видно, можно прочесть? Ну давайте, я прочитаю, по быстренькому.

Оператор match. Если кто-то программировал на функциональных языках, то практически в любом функциональном современном языке, ну кроме LISPа, наверное, есть оператор match. Это такой switch на стероидах. Т.е. это такой switch, который позволяет не только перейти к какому-то индексу, строке, а позволяет разобрать структуру объектов. Т.е. если у вас есть какая-то сложная структура объектов, то он может прямо…, паттерн…, узнать в этой структуре. Если у вас есть какое-то деревце, ну например, DOM/XML, то вы можете прямо паттерном определить, какой-то там набор объектов и так далее. Очень мощная структура, оператор очень мощный, позволяет в некоторых случаях серъезно упростить решения задач, или сделать их по-другому.

Блоки выражений. Это такие же блоки, как в C#, только они могут возвращать значения, из себя.

Именованные блоки, это замена return-у, на презентации в другом зале я это продемонстрирую, это интересная штука. Они позволяют, например, выйти из трех циклов сразу, и более того — сразу возратить значение какой-то переменной. Это такая структурированная замена break-у. Совершенно безопасная, очень удобная, при этом, собственно, очень мощная.

Связывание def. В отличие от C#, Nemerle пропагандирует функциональное программирование, и поэтому он подталкивает к созданию неизменяемых переменных. По факту, когда вы пишите даже обыкновенный C#-код, большинство переменных могут быть неизменяемые, когда они задаются один раз, а дальше только используются.

Естественно, Nemerle поддерживает и обычное итеративное программирование, поэтому, в язык введена конструкция mutable. Это полный аналог var из C#, т.е. создание переменной, значение которой можно переопределить дальше.

Обработка исключений «throw, try/catch/finally». Это то же самое, как и в C#, только c одним условием, что его можно использовать не только как statement С#, но и внутри выражений. Если у вас есть какое-то вычисление, вы можете защитить кусочек этого вычисления, и вернуть значение по дефолту.

Набор операторов. Фактически весь набор операторов, который здесь присутствует, это полный набор операторов языка. Возможно я здесь что-то забыл, но не думаю, что больше трех каких-то операторов. На самом деле в языке можно использовать огромное количество операторов, даже больше чем в C#, но все остальные операторы сделаны в виде макросов, и являются синтаксическим сахаром, а не базовыми вещами.

Естественно в языке есть вызов функций/методов/индексов, без этого никуда.

Приведение типов. Приведений типов в целом два. Точнее одно из них не совсем приведение типов и называется «уточнение типов». Смысл в том, что это скорее подсказка компилятору, что вы здесь, намерены… считаете, что в этом месте должен быть такой-то тип, например, там int. Вы можете в любом месте программы, в выражении, в if-е, еще где-то там, поставить двоеточие, т.е. написать выражение, двоеточие, и тип. И соответственно, компилятор попытается проверить, что там действительно получается тип int, если у него есть какие-то сомнения, он примет вашу сторону, если он не сможет вывести int, он выдаст ошибку времени компиляции.

Второе приведение типов — это так называемый «ножик-оператор» → выражение, потом оператор, потом тип. Смысл его в том, что это именно динамическая проверка типов. Если вы пытаетесь статически к чему-то привести, например к (???)-стриму, то вам сразу, во время компиляции выдадут сообщение об ошибке, что так нельзя. Соответственно, если нужно сделать какой-то там непонятный ?cast, то нужно привести cначала что-то к object-у, а потом приводить к нужному типу.

Смысл разделения на два оператора в том, что это дает большую надежность коду. Некоторые проверки, некоторые приведения типов в C#, являются грубо говоря затыканием ошибок, т.е. они могут маскировать ошибки. С вот этими двумя операторами такого не получается, они более безопасны.

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

checked — как в C#-е, позволяет задать семантику целочисленных вычислений, с переполнением или без, соответственно, генерировать исключение при переполнении или нет.

Доступ к члену, понятное дело, через точку.

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

Так, про это я немножно поговорил…

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

Макросы, грубо говоря, можно разделить на два части. Макросы, которые расширяют язык, позволяя ввести в языке какие-то новые конструкции, и как-то упростить свою личную жизнь, более красиво писать код. Например, если кто-то переходил с Java на C#, обратил внимание, что есть очень удобная конструкция using. Собственно такая конструкция using, она в Nemerle сделана с помощью макросов, и вы можете делать такие конструкции буквально в мгновение ока. Кроме того, макросы могут быть могут быть не синтаксическими. Макросы могут просто изменять поведение кода, или генерировать код в процессе компиляции. При этом макросы могут быть двух уровней:

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

А макрос — это всего лишь функция, на том же самом языке, Nemerle, который позволяет получить доступ у компилируемому проекту, причем, получить доступ в виде синтаксического дерева, с которым довольно удобно работать, у которого есть специальный срез для этой обработки, и собственно, как-то проанализировать этот проект, что-то в нем прочитать, что-то узнать, что-то новое сгенерировать. В принципе, он позволяет, в том числе заменять реализацию тел методов, но в основном, макросы, предназначены для генерации нового кода. Кроме того, макросы можно использовать для контроля за кодом. То есть, если у вас есть какие-то там корпоративные правила, хотя бы например, какая-то замена FxCop → можно проверять наименования, причем очень сложным образом, можно отслеживать… вплоть до порядка объявления переменных. Все что в коде есть, можно отследить с помощью макросов, и выдать диагностические сообщения, вплоть до сообщений об ошибках.

Это я уже буду на другом докладе рассказывать…

Сейчас мы перейдем к тому, что соотвественно, что макросы могут.

Как я уже говорил, макросы можно разделить на две большие группы: прикладные библиотеки, DSL-и и фреймворки, и на расширения языка.

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

Тогда я в двух словах расскажу. В F#-е есть такая замечательная, на самом деле, возможность, так называемых computation expressions. Они позволяют, творить в языке небольшую магию. Есть в функциональном языке, очень непонятная для простых смертных вещь, «монада». Вещь трудна для изучения, понимания, и даже на самом деле, использования. Но позволяет делать иногда очень красивые вещи. Единственная проблема, то, что монады — это паттерн функционального программирования, и в истинно функциональном языке они встраиваются непосредственно в язык. Например, Haskell имеет прямую поддержку для монад. И там, на монадах сделано очень многое, ведь монады в Haskelle, это заодно и средство борьбы с их ленивым выполнением. В Haskell все вычисления откладываются до сих пор, пока они физически не потребуются в программе. Монада — это средство связать несколько вычислений в цепочку, и тем самым, добиться оперативности. Кроме того, монады, это красивое средство скрывать поток связанных вычислений, и поэтому на их базе можно создавать очень красивые вещи. Например, асинхронные вычисления «как будто последовательные», это какие-то генераторы. Ну все наверное знают, в C# есть такая штука, итератор называется. Ключевое слово yeild-return в каком-то методе, превращается в конечный автомат, который генерирует последовательность, и позволяет несколько раз выходить из функций, как бы виртуально.

Вот, computation expression позволяет делать все то же самое, но на уровне буквально одного-двух выражений. Т.е. вы можете в одном методе, объявлять 200 таких вот генераторов, они вам будут генерировать отдельные последовательности. На монадах можно делать очень многое, а computation expressions это такой сахар над ними, позволяющий создать так называемые builderы, для реализации самых разных паттернов использования.

В C# эта штука захардкожена физически, в Nemerle она была реализована в качестве макросов, причем… это было довольно-таки смешно → зашел парень на форум, «что у вас есть?».

Мы говорим: — «макросы». А он говорит, «я тут изучил F#, там есть computation expressions». А мы — «Макросы! Да, это не одно и то же, но на этом можно сделать второе». Ладно, говорит он, попробую.

Обычно ведь как — «Все встают и уходят», в смысле — «Поспорили и разошлись». Но парень оказался упорный, буквально через два дня, он пришел, с такой вот обалденной радостью, и говорит, что вот там, у меня, получилось и даже очень нравится, потому, что это расширяемо, в отличие от F#, где это забито в язык, раз и навсегда. Естественно, с первого раза у него не все здорово получилось, помогли ребята, у которых было побольше опыта в создании макросов, и через неделю, буквально, у нас были computation expression, которые теперь можно использовать в своих программах для реализации сложных workflow, потому что computation expression можно даже переключать между потоками. У вас вычисление идет например, в одном потоке, предположим в бекграунд-потоке, и вас надо переключится и что-то вывести на экран. На экран, во многих библиотеках можно выводить исключительно из GUI-потока. Вы конечно можете использовать разные дурные средства, которые позволяют, там, передать сообщение синхронно, еще что-то там. Но в данном случае, просто можно написать небольшой вызов, так называемый «переключатель контекста», и дальнейшее выполнение пойдет в рамках GUI-потока. Соответственно, точно также можно переключится обратно, и продолжить асинхронные вычисления.

Еще больше интересно то, что эти асинхронные вычисления можно связывать. Одно это computation expression можно связать с другим, другое еще с чем-то и создать граф вычислений, причем они будут друг от друга зависеть, и можно будет не боятся, что что-то там произойдет, вся связь идет, грубо говоря, на уровне вызовов между функциями, … как бы без залезания внутрь объяснить… В общем, это позволяет дожидаться одним вычислением других, продолжать вычисление в других потоках и так далее. Очень широкие возможности по асинхронному выполнению, что может быть использовано как для распараллеливания вычислений, так и для создания каких-то workflow.

К примеру, вот у вас есть сайт, на котором нужно реализовать какой-то wizard. Идеалогия wizarda, когда человек на каждой страничке по кнопочке продвигается вперед, но может отменить, и вернуться назад. Вот computation expression, если в продукт попала синхронизация состояний (?? 23:10), что в общем-то несложно, позволяет синхронизовать состояние такого workflow, сохранять, соответственно откатываться вперед и назад, взяв объект, который находился в состоянии до перехода.

Также, XML-литерал, это очень простой макросик, который был написан буквально за два дня. И он в язык вносит возможность написания XML-литералов прямо внутри кода. Причем эти литералы, они генерируют во время компиляции X-элемент, т.е. это не работа с текстом, не текстовая замена, это именно живые XML-литералы, если кто-то использовал Visual Basic или SCALA, он собственно, может себе представить, что это такое. Кроме того, в XML-литералах поддерживаются так называемые сплайсы, куда можно передать какие-то выражения, от текстов, до опять таки, XML-элементов (X-элемент, X-атрибут, X-name, и так далее). И они собственно будут проверены во время компиляции, что они подходят для этого места, и соотвественно, корректность XML. При этом, разумеется, совершенно невозможно туда запихнуть текст, который потом развернется в какую-нибудь бяку типа яваскрипта, или испортит что-то где-то. Кроме того, в этих же XML-элементах сделаны такие элементы, как циклы, которые позволяют генерировать наборы элементов, и условные включения элементов, можно написать такой маленький when, и если условие истинно, то элемент появится, в зале C я потом все это продемонстрирую.

Самый пожалуй мощный на сегодня макрос, это Nemerle.PEG, макрос-генератор парсеров в идеалогии PEG. PEG — это относительно новая, хотя на самом деле забытая старая технология создания парсеров без (???) 25:40, что делает парсер очень расширяемым, очень гибким.

Кроме того, наш парсер поддерживает неограниченность (???) 25:45, и очень большое количество оптимизаций, что позволяет, с писать одной стороны пользовательский парсер с очень сложным языком, на самом деле я не знаю компьютерных языков, которых нельзя было им распарсить, только если они очень сложно контекстно зависимы, и то, контекстно зависимые языки, такие как C++, можно спокойно парсить, причем довольно просто. При этом он показывает весьма высокую скорость, соответственно, наши тесты показывают 3-4 мегабайта в секунду, … т.е. мегабайтные файлы редактируются, без всяких там оптимизаций и так далее.

Очень мощный парсер, на самом деле на нем тот же XML держится, XML-литералы сделаны на (???) 26:40 … фактически.

Один фреймворк, на самом деле скорее, не рабочий такой фреймворк, а, скорее экспериментальный (указывает на Nemerle.WUI.Reactive), только проба пера, это Nemerle.WUI.Reactive, который позволяет создавать динамические web-приложения, прямо на статически типизированные языки, я это тоже, продемонстрирую в зале C.

Можно в принципе показать, действительно красиво, давайте отвлечемся на секундочку, я просто запущу и покажу результат:

(демонстрация на 41:20)

Вот, самый простой примерчик, все строится на идеологии…, есть такой паттерн «Model-View-View-Model». Идея его в чем заключается: что вы работаете не с данными приложения на странице, а вы как бы создаете такую сущность, как «View-Model», как модель для предоставления контента. Эта модель отражает те данные, которые у вас находятся в графическом интерфейсе, и которые выводятся на экран. Т.е. ничего лишнего. Когда вы на сервере такую модель выполняете, вы просто пихаете туда данные из базы данных, и вызываете метод сериализации в JSON. JSON передаете на клиента, он JSON съедает и заполняет внутреннюю Javascriptовую структуру. Эта внутренняя JavaScriptовая структура генерируется по вот этой модели.

Это класс с привычным синтаксисом описания тех же типов по другому, вот в данном случае есть «FirstName», «LastName», «FullName», и «FullName» это на самом деле конкатенация строк. В Nemerle есть такой макрос «бакс» ($), посмотрите, во что он разворачивается:

Примерно такой же код генерирует C#, когда вы плюсом пользуетесь.

Этот макрос позволяет в строку вставлять вот такие включения. В итоге, у нас при вычислении этого свойства получится строка, в которой у нас сначала будет «FirstName», потом будет «LastName», и восклицательный знак после этого. Вот такая модель. Все это было бы наверно просто и понятно, если бы это работало в каких-нибудь WinForms-приложениях, еще где-то, но на самом деле, это используется в веб, вот это вот модель, и генерируеnся в том числе яваскрипт-код, который так называемый React-Ins поддерживает.

Вот эта вот вьюшка (HelloWorldView), она работает с вот этой вот конкретной моделью, и в ней нет практически никакого кода, только файл. Если вы обратите внимание, то вот он код, какое-то поле текстовое, и у него есть такой-то тег, «data-bind», в котором «value», т.е. значение этого поля, связывается со свойством «FirstName». Второе поле связывается со свойством «LastName». А потом просто «span», т.е. грубо говоря просто текстовый блок, его текст связывается со значением «viewModel.FullName», которое, как мы видели, вычисляемое свойство, которое сконкатенирует значения двух других свойств.

Теперь запустим все это дело.

Мы получим такой вот, интерактивный интерфейс:

Который на самом деле работает на JavaScript, сейчас я вам его покажу:

А Javascript этот компилируется макросом, во время компиляции:

Естественно, перед этим срабатывают все проверки типов, у нас в IDE работает… сейчас еще раз покажу,…

У нас в IDE работает, видите, весь интерфейс, работает complete code, нотификация, стандартные фишки intellisense:

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

Т.е. если мы например, вернемся сейчас в броузер, то вы можете увидеть, как FirstName превратился не просто в какое-то свойство, а превратился на самом деле в некоторый объект «observable» при каких-то начальных значениях.

Используется javascriptовый фреймворк Knockout, где вот эти вот «observable» рассылают автоматически уведомления о своем изменении, т.е. когда например, вводится binding с полем, то изменение поля, автоматически изменяет значение вот этого свойства.

Ну и как я сказал, это не готовый фреймворк, а только такой демонстрационный зачаток, но в принципе, планируется в дальнейшем развивать, если найдутся люди готовые этим заняться, кому это будет интересно, — я этим фреймворком не занимаюсь, я это сделал как демонстрацию. Дальнейшее развитие — автоматическая сериализация и передача JSONа, автоматическая валидация, то, что в обычных сложных фреймворках делается огромным объемом кода. Вот то, что я вам демонстрирую, было создано буквально за дня три. Чтобы это довести до ума, программисту, который хорошо знает макросы, понадобится где-то месяц. Зато в конце этого месяца человек будет иметь действительно мощный фреймворк, который практически ни от чего не зависит, кроме веб-сервера.

Вернемся к докладу.

Кроме того есть еще библиотека, более традиционная, «Nemerle on Rails», где-то аналог «Ruby on Rails», который собственно эмулирует его работу. Там есть так называемая миграция баз данных, поддержка какого-то движка HTMLя, не помню…

Кроме того, есть множество мелких макросов. «$-строки» я вам уже показывал. Это все макросы, которые входят в стандартную библиотеку. Например, макрос «Record» позволяет автоматически сгенерировать конструкторы, для всех полей классов. Некоторые поля можно просто проигнорировать, туда можно дать какой-то другой атрибут, и эти поля будут исключены. Все остальные попадут в список полей конструктора → наверное все уже устали писать каждый раз класс-конструктор, который запихивал все значения параметров в поля, так вот, макрос «Record» одним написанием атрибута над классами, решает эту проблему.

Есть макросы, которые позволяют автоматизировать разные паттерны проектирования, т.е. вместо того, чтобы выписывать этот паттерн под копирку, вы можете применить атрибут, класса, метода или еще чего-то и реализовать такие паттерны как «абстрактная фабрика», «aggregate», «proxy», «sigleton». И естественно, вы можете создавать какие-то свои макросы, которые решают какие-то ваши прикладные задачи, в соотвествии с какими-то паттернами.

Макрос «late» — это нечто похожее на «dynamic» из четвертого сишарпа, но на самом деле он создан задолго до появления «dynamic-ов» в C#, и позволяющий без синтаксического оверхеда динамически вызывать методы. Т.е. пишите макрос late, далее, какой-то динамически типизированный код, далее этот код компилируется только синтаксически, и все вызовы происходят уже динамически.

Применение макроса «Memoize» к методу позволяет «меморизировать» его состояние для конкретных значений параметров, что позволяет иногда очень сильно повысить производительность, и упростить код.

На самом деле макросов намного больше.

Есть такие макросы, как автоматическая генерация структурного сравнения, «CompareTo» пишется автоматически, просто перебором полей. Естественно, он не очень умный, он за вас не сможет узнать, есть ли какие-то поля, которые не надо применять в сравнении, но тем не менее, если вам нужна такая быстрая и тупая релизация сравнений по всем полям, то вы его применяете и буквально сразу получаете реализацию без таких-вот…

То же самое с хеш-кодом, есть макрос для регэкспов, есть так называемый «list comprehension», типа очень маленького компактного LINQ-а, но со специализированным синтаксисом для списков.

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

Сам язык понятен C# программистам, ну может для начала потратят пару дней и изучат прочтением пары статей.

Для более глубокого изучения нужен опыт — ведь никто не научился программировать по книжке или статье, только реальное программирование может этому научить. Но зато, потратив месяц-два на изучение, производительность труда вырастает очень серьезно. Можно просто решать какие-нибудь задачи, которые раньше решались очень тяжело.

Я думаю, что мое время уже истекло, поэтому, спасибо за внимание, еще скажу, что через час, в зале C будет расширенная версия моего доклада, где можно будет задавать вопросы, посмотреть на код — я будут показывать все то же самое в виде кода, и соответственно в конце моего доклада будет еще отдельный большой, ну нормальный такой доклад, по Nemerle.PEG, вот этому самому генератору парсеров, который на самом деле уникальный, аналогов ему на самом деле нет. Cпасибо за внимание!

Ответы на вопросы начались с 38:35, и там тоже было интересно. В частности, по результам этого обсуждения стартовал эпический тред в духе «Менеджеры против гиков» («Тчортовы гики, вы рискуете чужим баблом!»).

Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011)/Стенограмма

2012-05-07T21:20:19Z

StasFomin: переименовал Участник:StasFomin/Language Oriented Programming в Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011)/Стенограмма

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

Меня зовут Максим Мазин, я работаю в компании JetBrains инженером в проекте YouTrack. YouTrack — это багтрекер, и самое увлекательное в YouTrack то, что он написан с помощью Language Record программирования. Что это такое? Это такая концепция, которая полагает, что при написании программ, первым делом вы создаете специальный предметно-ориентированный язык, а затем, на этом предметно-ориентированном языке, вы начинаете уже писать собственно код программы.

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

Смотрите — вот существуют универсальные языки программирования. При программировании при помощи языка Java, PHP или C# возникает проблема — у вас при программировании возникает огромное количество bullet plate (??? 01:15) -кода, т.е. такого кода, который будет повторяться из раза в раз, но не потому, что он делает какую-то содержательную работу, а просто для того, чтобы компилятор мог этот код скомпилировать. Писать скобочки круглые, точки, … ну и так далее.

В случае, когда вы пользуетесь каким-то фреймворком, то у вас появляется еще дополнительная боль от фреймворка. Вам нужно инициализировать библиотеки, открывать окна, устанавливать какие-то свойства, в зависимости от того, что у вас за библиотека. В принципе, во многих современных языках программирования, ну например, С#, существует практика добавлять в язык предметно-ориентированные конструкции.

В языке Java существует конструкция synchronized, которая не является какой-то конструкцией общего назначения, является специальной, предметно-ориентированной конструкцией, предназначенной для параллельного программирования.

Точно так же, в языке C++, существует перегрузка операторов. Вот, сравните. В нормальной ситуации, если бы у вас не было конструкции synchronized вам бы пришлось написать вот столько вот кода. Блок «finally» и блок получения блокировки, это все вот bullet-plate код, который не интересно писать постоянно. Вместо этого существует DSL-ная конструкция «synchronized», которая позволяет захватить блокировку и не беспокоится о том, что ее надо отпустить.

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

Это все очень хорошо, но как вы знаете, что в языке Java, начиная с пятой версии, появились read-write локи, и это означает для нас, что нам снова нужно писать код вот такого стиля, как показано слева:

Т.е. надо блокировки захватывать, блокировки отпускать, … это все полностью нивелирует удобства.

Если бы можно было писать… самостоятельно расширять языки, нам бы удалось решить разные проблемы. Например, те конструкции, языковые расширения, которые есть, в языке Java, они позволяют вам решать определенный набор задач. Но мы в жизни сталкиваемся и с другими задачами. Например, если мы пишем веб-аппликейшн, то нам нужно работать с базами данных, писать веб-уровень, и так далее. Для этого DSLей нет, есть только фреймворк.

Точно также, если мы используем какую-нибудь концепцию вроде dependency injection, то нам тоже нужно для этого использовать фреймворки, и хуже того — использовать смеси языков, писать одновременно на Java, на XMLе, и все это не очень весело. И главное — нам ничего с этим не поделать, потому что создание языкового расширения грозит нам разными рисками.

Какие проблемы возникают при создании DSL и почему бы при возникновении какой-нибудь потребности не бросаться сразу создавать DSL?

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

Вот например. Если у вас есть некоторые библиотеки и фреймворки, в нашем случае для Java, например Hibernate, Spring или Joda Time, то все они между собой совместимы, принципиально, на уровне компиляции. Т.е. вы можете одновременно использовать в вашем проекте компоненты и Hibernate и Spring, и ничего вам не может помешать. Но если у вас есть языковые надстройки, в виде каких-то макросов, или еще каких-нибудь техник, которые добавляют вам предметно-ориентированные конструкции в язык Java, то и эти надстройки созданы независимым образом, то все время существует риск, что эти надстройки будут с друг другом конфликтовать.

Вот например, такой очень простой пример. Допустим у нас откуда-то появилось расширение, которое делает что-то полезное, и в частности поддерживает интерполяцию выражений в строках. Можно написать такую конструкцию, и вместо «resultCount» будет подставлено значение этого выражения.

В тоже самое время, в друг к нам приходит другое языковое расширение, которое позволяет делать что-то полезное и в частности тоже делает интерполяцию строк. В Java же нет интерполяции строк, поэтому достаточно ожидаемо, что разные люди будут ее релизовывать в разных языковых расширениях. И допустим, синтаксис слегка отличается. Тогда при совместном использовании языковых расширений A и B, у вас мгновенно возникает неустранимая неоднозначность, как следует интерпретировать вот этот вот buzz.

Данный пример он очень простой, но по факту, все, кто создает DSL на основе текстовой информации, так или иначе сталкиваются с проблемой, у них возможно нет уверенности в том, что расширения не будут противоречивы.

Другая проблема, которая мешает нам создавать DSLи. Допустим тем не менее, вопреки сложностями и проблемам с совместимостью разных расширений вы принимаете решение написать DSL. Пишите какой-нибудь препроцессор, натравливаете этот препроцессор на вашу программу вашими DSLными конструкциями, она компилирует и выдает какой-то код, байт-код например, или какой-то исполняемый код. Это все очень хорошо, но в наше время никто не пишет код, не используя IDE. Так не делают просто, потому что без использования IDE продуктивность разработчика драматически снижается. Поэтому в большинстве случаев, когда вы создадите такой DSL, будут ситуации, когда ваши разработчики, ваши коллеги, предпочтут использовать просто язык Java в Idea, просто язык C# вместе с ReSharperом, нежели брать ваше поделие, и что-то с помощью вашего поделия писать, потому что нет поддержки IDE.

Под поддержкой IDE понимается все возможности, которые современные IDE оказывают разработчику. Т.е. это подсветка синтаксиса естественно, подсветка ошибок до компиляции, рефакторинг, интеграция с Version Control-ами, все остальное.

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

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

Существуют очень много разных попыток сделать это, поддержать DSL в том или ином виде, тема очень горячая, тут наверное еще можно добавить Nemerle, и может быть еще OCaml, сейчас есть очень много разных средств, чтобы создавать DSLи. В рамках Eclipsa существует XText-фреймворк, который позволяет написать грамматику и получить что-то вроде DSLя c поддержкой IDE.

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

Но к счастью, в нашей компании JetBrains, была создана среда MPS.

MPS означает meta-programming system, в основном предназначена для создания и расширения языков, причем такого расширения, что сразу после его создания появлялась поддержка IDE.

Я уже много раз сказал, что текстовые грамматики неизбежно приводят к проблемам. Поэтому естественным решением является работа напрямую с AST → абстрактным синтаксическим деревом, и заставлять программиста прямо, напрямую создавать абстрактное синтаксическое дерево.

Попытки такие ранее предпринимались, и как правило такие попытки сводятся к редактированию диаграмм. Рисуется диаграмма, в некотором смысле… у меня ребенок программирует на свойствах в большей степени, вы рисуете диаграммы, у вас получаются картинки, далее эти картинки собираются, получается код.

Есть проблема — рисовать эти картинки неудобно — мышкой хватать, таскать, неудобно. У нас, у программистов, есть привычка писать код вручную.

Поэтому в MPSе реализована концепция проекционных редакторов.

О чем речь? Вот у вас есть абстрактное синтаксическое дерево. Т.е. это то представление программы, которое получается, в любом случае получается, когда парсер распарсил программу. В то же время, у вас есть его проекция, во что-то вроде текста.

Для каждого узла этого синтаксического дерева есть соответствующая ему ячейка. Те из вас, кто знакомы с TeXом, должны примерно представлять, примерно похожие концепции. Точно также, для каждого элемента у вас есть ячейка, ячейки объединяются в еще более крупные ячейки и так далее.

При этом воздействие на эти ячейки, когда вы пишете в эти ячейки, или каким-то образом на них воздействуете, то сразу же, мгновенно влияет на эту деревяшку. При этом наша цель, как разработчиков MPS, сделать так, чтобы вы вообще не чувствовали, что вы работаете не с текстом, а с напрямую с деревяшкой. Здесь конечно проблема, но те из вас, кто пользуются IDEA, должны понимать, что когда вы редактируете текст в IDEA, Eclipse или еще где-то, вы тоже не редактируете текст — вы тайпаете что-то, что поглощается IDEA, и она это во что-то превращает. В случае Eclipse это в большей степени редактирование текста, в случае IDEA — это еще меньше редактирования текста.

У такого проекционного редактора есть положительные стороны, и есть отрицательные стороны. Положительные стороны понятны. У нас нет никаких текстовых грамматик, никакого текста, никаких проблем текстовых грамматик, никаких конфликтов, все совместимо, все очень хорошо.

Отрицательная сторона, состоит в том, что все-таки есть некоторое отличие от редактирования текста. В тоже самое время, (???) проблема. Дело в том, что привыкание… по нашему опыту, люди, которые начинают работать с MPSом, они привыкают к стилю программирования внутри MPSа, примерно в течении двух недель. Т.е. в течении этих двух недель они могут выдавать какую-то положительную обратную связь, о том, что им неудобно, непривычно, чем-то отличается от программирования в текстовом редакторе. Через две недели они привыкают и начинают работать с той же скоростью, как они работали ранее. Я надеюсь, что если вы попробуете скачать, и начнете пользоваться, то мы получим больший feedback, и мы сможем сделать проекционный редактор еще более похожим на текстовый редактор.

Идея такая. При создании языков вы выписываете мета-модель языков, его абстрактный синтаксис, задаете систему типов, описываете конкретный синтаксис, и автоматически получаете на выходе язык, вместе с компилятором, плюс MPS-тест для работы с кодом на этом языке.

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

Вместе с MPSом, внутри него, поставляются разные языковые расширения, для работы с замыканиями, с коллекциями… и так далее. И некоторое количество языков для работы с XML, тупо для работы. Т.е. вы можете вводить XML, и что самое главное — генерировать XML из своего кода.

Ну и еще есть некоторое количество языков, которые предназначены для создания языков. MPS в плане создания языков вполне честно (??? 16:20)

Вместо демонстрации — выглядит как-то так ↑.

Я показывают не со своего компьютера, поэтому все, кого интересует демонстрация, приглашаю на стенд в коридоре. Тут посмотрите, как просто взять и заDSLлить поддержку языковой конструкции.

Фактически, это все, что я хотел рассказать, осталось несколько важных вещей.

MSP подходит не только для создания языковых расширений, т.е. не только в Java можно добавить конструкций, которых в них не хватает, но также вы можете создавать какие-то собственные DSLи.

Вот например, Мартин Фаулер создал язык для описания своей финансовой отчетности.

Кроме того, с помощью MPSа мы написали YouTrack, такой большой багтрекер — большой, в смысле с большим количеством кода (сгеренированного). Но мой предыдущий опыт разработки подсказывает мне, что код содержательный, который мы пишем и редактируем, этого кода достаточно мало. Опять таки интересующимся, мы на выходе можем показать, как выглядит код в редакторе, сколько там таблиц. Кода достаточно мало, из-за того, что уровень абстракции поднят достаточно высоко. Для разработки YouTrack был создан набор языков, часть этих языков открыта, а часть — закрыта. Мы их пока не отдаем, потому что они не достигли пока продажного качества.

Вот, приложение настоящее, живое.

У MPSа есть положительное свойство. Он «Apache 2.0»-лицензированный, абсолюно бесплатный, даже для коммерческого использования.

Скачать его можно здесь. Теперь если у вас есть какие-то вопросы, предлагаю вам их задать.

(18:46)

Автотестирование веб-сервиса с Ruby и Rspec (Игорь Любин,SQADays-2011)

2012-04-27T20:10:23Z

StasFomin:

Поведение пользователей на массовых сервисах (ProductCampSPB-2012)

2012-04-27T20:01:33Z

StasFomin: /* Слайды */

О чем мы забываем в QA или “Знакомьтесь – Manageability!” (Роман Юферев, SQADays-2011)

2012-04-27T19:51:45Z

StasFomin: /* Аннотация */

Java One 2012:Отчет Белобородова Дмитрия

2012-04-23T15:59:16Z

DmitryBeloborodov: /* Язык Kotlin для платформы Java */

Конференции Java One и Oracle Develop 2012 в России проходили 17-18 апреля в здании Российской Академии Наук (Ленинский проспект, 32a). Несколько параллельных треков включали доклады, связанные с языком Java и прочими технологиями Oracle. В холлах были также стенды самой компании Oracle и компаний-партнеров. Меня заинтересовали только доклады, касающиеся языка Java, впечатления о посещении которых далее и приведены.

Общие впечатления, что понравилось на конференции:

Интересные темы докладов, причем, сделанные не только работниками Oracle.
Удовлетворительные условия технического характера, созданные для просмотра и прослушивания докладов:
- презентации демонстрировались на больших экранах, хорошо видных из любой части аудитории;
- наличие синхронного перевода (качество не оценивал).
Раздаваемый участникам конференции набор включал необходимый минимум (расписание докладов со схемой аудиторий, ручку, блокнот) и был почти без рекламной макулатуры.
На открытии продемонстрирован забавный клип Java Life, показанный впервые на американском Java One 2011.

Что не понравилось:

Катастрофическая ситуация с питанием, особенно во второй день конференции. Совсем-совсем ничего не досталось на обед минимум половине людей. Пришлось даже уйти чуть раньше с доклада до перерыва перед последними двумя докладами, чтобы досталось хоть что-то поесть и смочь досидеть до конца конференции. Учитывая тот факт, что это первая на моей памяти платная оракловская конференция (оказывается, прошлогодняя тоже была платной), просто непонятно, почему нельзя было избежать проблемы с едой...
В первый день не удалось попасть в синий зал на два последних доклада (не было свободных мест), подобное уже было в прошлом году на питерском Java Tech Day: слишком маленькое помещение или неправильно выбраны аудитории организаторами.

Файлы презентаций пока недоступны на официальном сайте, но ссылки на некоторые доклады появились в отзыве о конференции на Хабре.

Подробная программа конференции

Коридор со стендами

Стенд с расписанием и планом

Вход в большой зал

Сцена большого зала

Пуфики в коридоре

Отзывы о докладах расположены в хронологическом порядке их посещения и оценены по пятибалльной шкале ().

Взаиморасчеты в ЖКХ: кто виноват и что делать?

2012-04-18T15:19:33Z

AlexandraVelyaninova:

В журнале «Коммунальный комплекс России» (№3/2012) опубликована статья «Взаиморасчеты в ЖКХ: кто виноват и что делать?» ведущего аналитика нашей компании Татьяны Лисиной. Татьяна рассматривает проблемы взаиморасчетов в ЖКХ и предлагает пути их решения. Работа управляющих компаний вызывает много нареканий по поводу злоупотреблений, хищений и бесконтрольности их деятельности. Выходом из сложившейся ситуации является развитие единых расчетных центров, оснащенных современными биллинговыми системами.

С самого начала предвыборного 2011 года и до сих пор одно за другим появляются в СМИ сообщения о совещаниях, коллегиях, выездных заседаниях с участием самых высокопоставленных лиц. Лейтмотив всех выступлений примерно такой: «…Злоупотребления и хищения в сфере ЖКХ приобрели характер эпидемии» (Д. А. Медведев, выступление на заседании коллегии МВД России, 10 февраля 2012 года). Слово «эпидемия» можно расценить только как признание, что дела идут все хуже. Необходимо срочно разыскать злоумышленников.

А далеко ходить не надо. Еще в октябре 2011 года министр регионального развития Виктор Басаргин назначил виноватых в привычном развале жилищно-коммунального хозяйства: «Прежде всего, необходимо из процесса расчетов убрать посредников. В первую очередь это как раз управляющие компании, которые прокручивают деньги жильцов. Для некоторых компаний это вообще основной источник доходов. Второе — расчетно-кассовые центры. Сегодня руководитель РКЦ субъективно решает, кому платить, а кому — нет. И это благодатная почва для злоупотреблений». И вот уходящий Президент грозно требует от полиции активного пресечения злоупотреблений, а губернаторам поручает следить за расходами управляющих компаний.

Странная рыночная экономика у нас получается. Управляющие компании, которые появились после принятия Жилищного кодекса, — коммерческие организации, на каком основании будет раскрыта структура их расходов?

Поймите правильно — иллюзий о качестве управляющих компаний, созданных на основе спешно приватизированных городских жилищных контор, не было ни у кого. Смена названия и даже организационно-правовой формы никак не повлияла на качество их услуг. Для качественного изменения управляющих компаний, превращения их в ответственных субъектов рыночной экономики не было главного условия — заинтересованности в этом самих управляющих компаний. И не могло быть. Ведь акционирование жилищных компаний фактически повлекло за собой полную отмену контроля за их деятельностью. Естественным следствием этого стало безудержное стремление управляющих компаний к достижению максимальной выгоды без учета интересов других сторон.

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

Таблица 1

Недостатки в работе управляющих компаний и вызванные ими проблемы для потребителей ЖКУ и поставщиков ресурсов

Проблемное поведение управляющей компании	Следствие для граждан	Следствие для поставщиков
УК не ведет расчета квитанций	Неудобство оплаты по абонентским книжкам/расчетным листкам поставщиков, необходимость сверки начислений с поставщиками	Уменьшение сборов
УК не ведет учета аварий, недопоставок	Переплата, необходимость сверки начислений в аварийные периоды	Уменьшение сборов, перерасчеты задним числом
УК задерживает перечисление оплаты поставщикам	Отключения	Отсутствие оборотных средств, в том числе для оплаты налогов по начислению
УК не оплачивает задолженность перед поставщиком	Отключения, повторное взимание оплаты при банкротстве УК, судебные издержки	Отсутствие оборотных средств, в том числе для оплаты налогов по начислению, судебные издержки
УК выполняет не все работы (объемы, состав)	Переплата, ухудшение состояния дома
УК использует платежи на капитальный ремонт не по назначению	Не накапливаются средства для капитального ремонта, ухудшение состояния дома, повторная оплата ремонта
УК не ведет учета по домовым счетчикам	Переплата	Уменьшение сборов
УК оплачивает завышенные объемы работ/услуг	Переплата, ухудшение состояния дома
УК не отчитывается перед муниципальными властями	Бесконтрольность УК, ухудшение состояния дома

По сообщениям СМИ, приведенные в таблице сценарии реализуются в полной мере, а результатами деятельности управляющих компаний недовольны буквально все. Долги перед поставщиками растут, качество услуг УК плохое, тарифы и нормативы потребления завышены, качество капитального ремонта не выдерживает критики. И это несмотря на то, что в результате монетизации льгот и роста тарифов жильцы стали платить больше. Граждане жалуются на принуждение к подписанию договоров и невозможность контролировать УК, на чехарду с умышленными банкротствами управляющих компаний и многое другое — проблемы разнообразны, как сама жизнь.

IPazzPort

2012-04-18T14:57:07Z

StasFomin:

Модель KP-810-02

Позиционируется, как:

Пульт для домашнего кинотеатра;
Устройство для грамотного презентатора (обучение, тренинги), все что выходит за рамки тупого перелистывания слайдов. Например, с его помощью уже можно использовать ZoomIt (как в режиме увеличения, так и рисования).
Управление безклавиатурными девайсами (станки с ЧПУ, и прочее, куда некуда засунуть клавиатуру).

Интерфейс: 2.4Ghz dongle — это лучше, чем BlueTooth. Больше дальность, надежность, девайс не «теряется».

Ротация кадров внутри компании

2012-04-12T17:31:43Z

AlexandraVelyaninova:

Руководитель HR-службы Евгения Удалова рассказала журналу CIO о ротации сотрудников внутри компании. В каких случаях ротация персонала приносит положительный результат, а когда может навредить? Почему при кажущейся простоте ротация сотрудников — довольно непростой управленческий инструмент? Евгения делится положительными примерами внутренней ротации и обращает внимание на возможные «подводные камни».

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

Итак, в каких случаях ротация кадров внутри компании может быть эффективной:

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

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

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

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

Быстрый старт нового проекта. Если в компании налажены механизмы ротации персонала, у вас не возникнет сложностей с тем, чтобы собрать новую команду из уже работающих сотрудников. Плюсы формирования такого «костяка» стартующего проекта очевидны: люди лояльны к компании и хорошо знают используемые технологии, их профессионализм доказан, вокруг «костяка» можно быстро нарастить достаточно большую команду (до 10 человек), приходящие люди не будут «оторваны» от компании, поскольку их погружением и адаптацией будут заниматься уже работающие у вас сотрудники.

Развитие горизонтальных связей между подразделениями. По нашему опыту, видимый эффект появляется через 3-4 года после начала мероприятий по ротации. Горизонтальные связи между производственными подразделениями — как рабочие, так и личные — улучшают координацию и взаимодействие при совместной работе над задачами, сохраняют целостность компании, позволяют делиться опытом и успешными практиками. Этот механизм также помогает руководителям производственных направлений видеть компанию в целом, а не ограничиваться только своей «частью».

Уход от производственных конфликтов. Если между какими-то специалистами «пробегает искра», мы всегда можем перевести одного из них в другое подразделение.

И, чтобы «уравновесить» сказанное, несколько слов о том, когда ротация может сыграть с компанией злую шутку:

Нарушение слаженности работы коллектива. Здесь речь идет даже не о командной работе, а просто о «сбитом» коллективе, способном решать производственные задачи совместными усилиями. Только представьте себе, что происходит с таким коллективом, если каждые три месяца к ним кого-то переводят из другой проектной группы, а кого-то забирают в другие проекты. Существенно увеличиваются затраты на погружение и обучение новичков, снижается темп работы и производительность, появляется ощущение «дня сурка» и воцаряется атмосфера «времянки».

Резкая смена вида деятельности. Эксперимент с переводом сотрудников на позиции, подразумевающие другой вид деятельности или полную смену технологий, может завершиться неудачей. Например, перевод инженера по внедрению на проект разработки ИТ-модуля в надежде, что он достаточно быстро «потянет» аналитические задачи. Такими перестановками и «рокировками» можно снизить мотивацию сотрудника или, наоборот, сформировать у него завышенные ожидания, а в результате получить специалиста, неспособного демонстрировать требуемое качество работы.

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

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

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

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Ротация кадров внутри компании»

DDD: Реализуем проект Вавилонская башня (Максим Цепков, Software People 2012)

2012-04-10T20:37:36Z

MaksTsepkov: /* Коммунальный биллинг */

Взгляд на облако с разных сторон

2012-04-10T15:35:16Z

AlexandraVelyaninova:

Ведущий системный инженер Дмитрий Морозов рассказал журналу Intelligent Enterprise об эффективном внедрении частного облака. Что дает перевод инфраструктуры в облако и как его проводить в условиях непрерывности бизнес-процессов компании? Своим опытом Дмитрий делится в комментарии к статье «Незаметная революция» (о внедрении облачного решения в РГТЭУ).

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

Перевод инфраструктуры в облако делает ее более прозрачной и управляемой, расширяет возможности для ее масштабирования, упрощает и ускоряет внесение в нее изменений. Однако эти изменения проводятся не «в вакууме», а в условиях непрерывности бизнес-процессов компании. У нас сложилась и хорошо себя зарекомендовала практика проведения анализа тех процессов, которые предстоит перевести в частное облако. Таким образом, вырабатываются соглашения об объеме предоставляемых IT-отделом услуг, а также правила и регламенты взаимодействия сотрудников бизнес- и IT-подразделений — своего рода SLA. И только с учетом этих условий создается техническая архитектура облака.

Например, чтобы при размещении базы данных (БД) Oracle в облаке одновременно учесть интересы пользователей и возможности ИТ-отдела, разрабатывается набор правил. В них указывается количество и объемы поддерживаемых БД, частота появления новых БД, регламент резервного копирования и т. д. В результате SLA между пользователями и ИТ-отделом задает параметры для технических регламентов и влияет на архитектуру облака.

Репликация: База Знаний «Заказных Информ Систем» → «Взгляд на облако с разных сторон»

Опыт внедрения Product Management. Подводные камни (Анна Лопатухина, ProductCampSPB-2012)

2012-04-10T09:06:30Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://ru.linkedin.com/in/alopatuhina Анна Лопатухина] <blockquote> * Необходимо четко...»

Построение офиса менеджеров продуктов (Игорь Парфeнов, ProductCampSPB-2012)

2012-04-10T08:57:04Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://www.linkedin.com/in/igorparfenov Игорь Парфeнов] <blockquote> Я расскажу о своем ...»

На каком языке говорить с СхО (Сергей Колпаков, ProductCampSPB-2012)

2012-04-10T08:48:03Z

StasFomin: /* Примечания и отзывы */

Коллективный процесс (Елизавета Хоботина, ProductCampSPB-2012)

2012-04-09T23:27:31Z

StasFomin:

Анализ мобильного рынка и приложений для шоппинга (Яна Кузьмина, ProductCampSPB-2012)

2012-04-09T23:23:48Z

StasFomin:

Процессы разработки B2B продукта «Единый Клиент» (Елена Журавлева, ProductCampSPB-2012)

2012-04-09T23:10:58Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://zhuravleva-kholodova.moikrug.ru/ Елена Журавлева] <blockquote> </blockquote> == Видео ==...»

Проектирование продуктового портфеля на примере Comindware (Константин Бредюк, ProductCampSPB-2012)

2012-04-09T07:06:08Z

StasFomin:

Завод Вертикалей (Юрий Воронцов, ProductCampSPB-2012)

2012-04-09T06:57:17Z

StasFomin: переименовал Завод Вертикалей (Юрий Воронцов, ProductCampSPB-2012 ) в Завод Вертикалей (Юрий Воронцов, ProductCampSPB-2012)

Стейкхолдеры, их идеи, их приоритеты. KJ method: порядок из хаоса. (Иван Михайлов, ProductCampSPB-2012)

2012-04-09T06:39:57Z

StasFomin: /* Примечания и отзывы */

Увеличение продаж за счет выстраивания матрицы продуктов (ProductCampSPB-2012)

2012-04-09T06:30:32Z

StasFomin: /* Видео */

Позиционирование на рынке ECM на примере системы электронного архива (Лилия Кочеткова, ProductCampSPB-2012)

2012-04-08T20:37:00Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: Лилия Кочеткова <blockquote> </blockquote> == Видео == {{vimeoembed|39974348|720|304}} {{CONFID...»

Смена концепции программного продукта GUI Machine (Рустем Гайфутдинов, ProductCampSPB-2012)

2012-04-08T20:29:50Z

StasFomin: /* Видео */

Создание новых рынков (Дмитрий Журавлев, ProductCampSPB-2012)

2012-04-08T20:20:13Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://www.linkedin.com/in/dmitryzhuravlev Дмитрий Журавлев] <blockquote> </blockquote> == Виде...»

Saas-стартап HR-рекрутинга (Максим Игнатов, ProductCampSPB-2012)

2012-04-08T18:52:24Z

StasFomin: Новая страница: «== Аннотация == Категория:Максим Игнатов ;Докладчик: [[:Категория:Максим Игнатов|Максим И...»

Что посмотреть сегодня вечером? Yota Play (Виталий Григораш, ProductCampSPB-2012)

2012-04-08T18:41:26Z

StasFomin: /* Слайды */

Игровые механики в полезных приложениях (Дмитрий Орлов, ProductCampSPB-2012)

2012-04-08T18:37:13Z

StasFomin: /* Видео */

Выработка концепции интерфейса продукта (Ольга Павлова, ProductCampSPB-2012)

2012-04-08T18:31:41Z

StasFomin: Новая страница: «== Аннотация == Категория:Ольга Павлова ;Докладчик: [[:Категория:Ольга Павлова|Ольга Павл...»

Генерация новых продуктов и идей (Сергей Морозов, ProductCampSPB-2012)

2012-04-08T18:24:36Z

StasFomin: /* Видео */

Как заполучить крупных клиентов? (Антон Марченко, ProductCampSPB-2012)

2012-04-08T17:54:02Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [http://marchenkoanton.moikrug.ru/ Антон Марченко] <blockquote> Доклад будет построе...»

Адаптация зарубежных продуктов: Создать или украсть? (Михаил Зарин, ProductCampSPB-2012)

2012-04-08T17:43:21Z

StasFomin:

Лицензируемое ПО vs SaaS - подходы к разработке и маркетингу (Мария Бондаренко, ProductCampSPB-2012)

2012-04-06T20:18:52Z

StasFomin:

Аналитика использования продукта - нужны ли вам метрики и как их раздобыть? (Алексей Ильин, ProductCampSPB-2012)

2012-04-06T19:56:14Z

StasFomin:

Взаимодействие в команде (Дина Шелепина, ProductCampSPB-2012)

2012-04-06T19:45:35Z

StasFomin:

Product Management Course в UC Berkeley (ProductCampSPB-2012)

2012-04-06T15:56:29Z

StasFomin:

Опыт продуктового менеджмента мобильного стартапа (Стас Давыдов, ProductCampSPB-2012)

2012-04-06T14:31:03Z

StasFomin:

ISPMA — стандарт обучения и сертификации менеджеров продуктов (Андрей Маглиас, ProductCampSPB-2012)

2012-04-06T14:14:47Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [mailto:andrey.maglyas@lut.fi Андрей Маглиас] <blockquote> </blockquote> == Видео == {{vimeoem...»

Переход от хаоса к планированию, или проблемы роста интернет-отделов внутри компаний (Яна Москвина, ProductCampSPB-2012)

2012-04-06T14:02:18Z

StasFomin:

Корпоративный инкубатор - путь к продуктоводству (Роман Белодед, ProductCampSPB-2012)

2012-04-06T13:51:05Z

StasFomin:

Как не надо делать мобильные приложения (Татьяна Авлочинская, ProductCampSPB-2012)

2012-04-06T09:19:21Z

StasFomin:

Мегаплан. Продукты, управление требованиями, команда. (ProductCampSPB-2012)

2012-04-06T08:58:05Z

StasFomin: /* Видео */

Сообщества тестировщиков. Старт дан. И что дальше? (Круглый стол, SQADays-2011)

2012-04-06T08:48:13Z

StasFomin: