Notes

To content | To menu | To search

Monday 16 May 2011

[gandi] Use Cases 25 years later

Last week mysql-related stuff made me to reconfigure gandi-vps server and delete old instance after that. UI dialog asked me if I want to keep system partition but silently deleted custom created one with my Stanford-related stuff.

It was restored aster request to the support for free (it seems that standard rate is euro 70) so the story is was over. The one thing that has been slightly bothering me that statement "you have to detach the disks before deleting a VPS" is true but wrong.

Worst of all the answer is known for 25 years at least. So I wrote a feedback to gandi customer service but a thought about how many things we do wrong even if we already knew the answer is really depressing.

My feedback: This comment is related to case support-en #3584703 there you can find all background. Case is resolved, but I hope that our collaboration is not over and as I'm thinking to place some severs for our current projects on your cloud hosting, I feel like I should try to give a more detailed feedback.

It's now 25 years since Ivar Jacobson firstly developed use cases. Ok, count 5 years to development and discussion, 20 years.

The way of thinking behind use cases is about achieving user goals step-by-step. It's the easy part. Difficult one is that on EVERY STEP of every use case scenario which is user-system dialogue, SYSTEM is responsible for protecting interests of all stackeholders on every step.

Bearing that in mind you wouldn't have the situation "ok, pleb, it's your job to remember about detaching a partition to keep it safe". Protect stackholder interests on every step. A guarantee or assurance - user doesn't lose his data until he *explicitely* asks to do so. If you need to recursively delete all server-attached resources - ask about every one, or at least about important ones.

I don't know why I'm trying to tell all this stuff, but I feel it's important. It's not about make two/ten checkboxes or not, it's about right and wrong.

Friday 13 May 2011

quirks

Started to implement some minor changes to make current architecture a little bit more event-oriented. Thought to set up production mysql-slave on stats server for etl & reporting-oriented triggers and "process mining" to make the transition process smoother.

Easy-peasy, yeah, but

  • Neither Debian or Ubuntu has mysql-5.5 package yet

Thought to test all this stuff on 5.1, but

  • InfiniDB has a very annoying bug conflicting with system mysql-5.1 installation on Deb and Ubuntu which is marked as 'won't fix'. Brilliant way to support transition to column-oriented bla-bla for sure.

Angry. Building mysql-5.5 from source. Hate to have all these dirty-deb checkinstall packages...

memo

cmake . -DINSTALL_LAYOUT=DEB -DMYSQL_DATADIR=/usr/local/dev/mysqldata -DDEFAULT_CHARSET=utf8 -DDEFAULT_COLLATION=utf8_general_ci 
-DENABLED_PROFILING=TRUE -DMYSQL_UNIX_ADDR=/var/run/mysqld/mysql.sock
 
#http://dev.mysql.com/doc/refman/5.5/en/source-configuration-options.html
#http://dev.mysql.com/doc/refman/5.5/en/installing-source-distribution.html

Monday 10 January 2011

Текуще-учебное

Устроил себе (и своим финансам) небольшой личный вызов, начав слушать Стенфордский магистерский курс Paradigms for Computing with Data, крутящийся, в основном, вокруг техник использования R, взаимодействия с другими системами и  языками программирования.

Ощущения пока ошеломительно приятные. Что, в общем, не удивительно, так как читает часть, касающуюся R, профессор Джон Чемберс (John Chambers) --- член R Core Development Team, человек оказавший существенное влияние на архитектуру и философию языка.
Радостно уважение к слушателю -- акцент на понимание принципов и логики, а не пересказ методичек.

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

Посмотрим, что и как выйдет.

Friday 5 November 2010

Дискуссия о воспроизводимых исследованиях в R

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

Saturday 17 July 2010

Копипаст куска мыслей (когда-то предполагалось, что это даже ПЛАН, представляете?)

Расчистка завалов и кучек памяти зачем-то нам нужна. И, пожалуй, самое благословленное, что нам дало изобретение компьютеров -это именно возможность сделать ордунг-процесс осязаемым. ЧисткаФрендов. ГруппыПостов. ЗаполнениеПрофиля. РазгребаниеЗакладок. УдалениеНенужногоСХарда. Кстати, это последнее, наверное, самое крутое - там есть триггер, регулярно побуждающий к этому занятию (ну, если у вас маленький винт, или ssd, как у меня - спасибо ему за это). Но данные на харде обычно менее структурированы, чем в других случаях. По обеим координатам к ментально-мастурбационному идеалу, наверное, близок dropbox, если у вас там папочки, как у меня.

Иллюзия наведения порядка. Иллюзия контроля над жизнью. Мытьё посуды в варианте для гикоуродов. Фрактальноповторяющиеся рисунки маленькой карманной шизофренийки.

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

А копипаст-то вот он. С милой меткой ,,,Not Started,,,,,,


Сформулировать принципы data-driven user-centred community management/marketing
* технологии и инфрастурктура анализа
* обработка и трансформация данных
* статистика и моделирование
* визуализация и презентация
* пользовательское поведение
* метрики
* "рейтинги, роли, звания"
* "технологии, алгоритмы, защита от накруток",
* лояльность
* психология
* саморегулирование
* поддержка вариативности пути (уникальный профайл - RPG spec - многокритериальное сегментирование)
* "саморегулирование сообщества, институциональные нормы"

Saturday 3 July 2010

Сочинившаяся для практикантки задачка на азы структур данных в R

Исходные данные:

ch = data.frame(rost=round(rnorm(100,175,30)), ves=round(rnorm(100,65,19)), zarplata=abs(round(rnorm(100,25,70))*1000))

Задачи:

  1. Богатые пузаны (с зарплатой >90000 и весом >85 кг) подкупили одного из исследователей, чтобы он прибавил в записях к их росту 10 см. Известно, что подкупленный исследователь отвечал за каждую третью запись в таблице. Исправьте ошибку
  2. Определить средний (медианный и арифм.) вес людей, ростом более 180 см
  3. Отобрать для всех чётных наблюдений людей с зарплатой >25000, но <45000, либо с весом >70 кг, распределив их равномерно по группам A,B,C; не попавших в выборку определить в группу D. Использовать функцию ifelse. Группу для каждого наблюдения записать в новый столбец group.

Sunday 18 April 2010

Планирование и тестирование

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

Обнаружил, что всё-таки есть и обсуждались штуки, от которой я начал думать от большой лени.

Лень эта заключается в том, что писать дублирующиеся штуки, например, планы/спецификации для постановки задачи и документацию к коду после её исполнения мне дюже лениво. Так же как и думать "а правильно ли оно работает, или всё надо переделать?".

Рецепт частично известен - требования в виде Use Cases (и всех их производных и потомков-мутантов) отлично преобразуются в документацию. Agile-метОды позволяют максимально сократить и объем письменных требований, полагаясь на живую коммуникацию, код и всё такое. Только если посмотреть в базовые требования к этим подходам, везде там требуется вовлечённость эксперта из предметной области, заказчика/стейкхолдера или каких-нибудь их ипостасей вроде продакт-оунеров, в идеале - фул-тайм. А если эксперт ленив, злобен, любит пить чай больше, чем объяснять свои требования, и, кроме того, ничего не понимает в этом вашем программировании? Ну, положим, сформулировать требования в виде коротенькой истории на кусочке туалетной бумаги с перфорацией ещё можно (с треском). Но вот заниматься докмуентированием и мучительной оценкой корректности реализации -- ну право слово, я так занят, у меня пятки чешутся и нос не прочищен.

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

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

Есть решения, однако, и для такого случая: самый известный из них это, наверное, BDD - Behavior-Driven Development гражданина по имени Dan North. И даже инструменты, позволяющие человечьим почти языком реализовывать это всё тоже есть (и много). Pyccuracy и MoreliaViridis, например, для Python.

В детали пока вдаваться не будем. Важно, что это попытка дополнить тесты, проверяющие техническую работоспособность/корректность кода, acceptance/приёмочными тестами (поэтому концепт еще называется ATDD - ну да, Acceptance Tests-Driven Development), фиксирующими ожидания пользователей и, в идеале, автоматизирующими проверку приложения на соответствие этим ожданиям - идеал ленивца!

Инструменты для этого всего любопытны и весьма остроумны, отдельного рассказа заслуживает то, как там обходятся проблемы тестирования соответствия бизнес-правилам/считальным алгоритмам. Любопытна и попытка (идея, в общем, лежит на поверхности) совместить это всё с Use Cases, которая предпринята гражданином Michael Dowling в его Spectacular, который я надеюсь найти время посмотреть поближе.

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

Предпосылки:

  1. мы делаем что-то похожее издалека и зажмурившись на RESTful приложение, так что оно, чёрт побери stateless;
  2. архитектура приложения проста и деление на слои (с берега) видится прозрачным
  3. благодаря пункту 1, интерфейс прост, инкапсуляция прилична

Отсюда, как мне кажется, следует, что customer-level (acceptance) тесты должны быть не особо замысловаты в реализации и, скорее всего, доктестов будет для них достаточно. Хотя, возможно, придется и что-то более замысловатое использовать: во-первых, для проверок, требующих работы непосредственно с самим API (что-то в этом духе?), а во-вторых, надо будет крепко подумать над принципом тестирования бизнес-правил, которых у нас не мало.

Ну, как-то так. Если осилю поправки-обновления-дополнения, то продолжим.