browser interface to the DB/ linux terminal / python (Jupyther)

Go to start of metadata
sqldeveloper is a great tool, so it has some limitations:

1. you need to install it on the PC. It's not that difficult for the dev environment, so one needs it also to be installed on demo environment (which is shared)
2. it is not that easy to plot some graphics. And when you try to demonstrate some "performance" improvements graphics are more convinient
3. it's nearly impossible to execute system (shell) commands..
4. when one needs to show something on demo (s)he should install sqldeveloper on the demo PC

What I use is an ipython notebook + JayDeBeApi. In this way I could reuse the Oracle JDBC driver and have an environment very close to MatLab:
And here is how it looks in my favourite browser:

To install that on Ubuntu one needs just to

    sudo pip install --upgrade ipython[all] && pip install JayDeBeApi

    ipython notebook

Антикоррупционная плодовитость законодателя

В последнее время много разговоров с критикой власти, мол крадут пуще прежнего.

К сожалению, доказательств пока я не видел ( если не считать  Першой Інстанції)


Я тут, в свободное время решил провести свой расчет.

Нынешний созыв "выкатил" почти в 1,5 раза больше законодательных документов* чем предыдущий. При этом прошлый созыв был при власти на  20% дольше (на данный момент)


На графике приводится среднее количество проектов зарегестрированных в ВРУ разных созывов в год.

* включая проекты постановлений, законопроекты и т.п. доступные с сайта rada.gov.ua

Статистификация: Средний размер взятки чиновников вырос за прошлый год

Наталкнулся на статью Transparency International в Украине "Штрафи за хабарництво менші за хабарі, а за ґратами - лише п’ята частина корупціонерів", на нее даже сослалась УНИАН, Українська Правда, Зеркало недели.


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


 
Возьмем первый абзац.

"Незважаючи на гучні заяви українських керівників про активну протидію корупції, обсяги хабарництва в країні збільшуються. Середній розмір хабара у минулому році склав приблизно 40 тис. грн., тоді як у 2014 році нечисті на руку чиновники брали в середньому 30 тис. грн. Загальна ж сума хабарів у 2015 році склала 19 млн грн. У 2014-му – на 3 млн менше. Зростання частково можна пояснити підвищенням курсу долара – корупціонери йдуть у ногу з часом і також підвищують розцінки на свої «послуги». Такі результати дослідження представили на прес-конференції представники Transparency International Україна та сайту новин про судові спори «Перша інстанція». Було проаналізовано близько 1000 справ за статтею 368 Кримінального кодексу («вимагання/отримання неправомірної вигоди») у період з березня 2014 по лютий 2016 року. Дослідження проводилося в рамках проекту «Судді під прицілом» за підтримки Посольства США в Україні."

1.  40 тыс грн * 1000 = 40 млн грн. Откуда 19 млн ?
2.  если проследить по ссылкам, то становится ясно что речь идет не о "среднем размере взятки" а о среднем размере взятки, по которой дело попало в суд. Т.е. авторы считают, раз в суды стали попадать дела с большими суммами взяток - то уровень коррупции возрос?  То же самое и по возросшему объему взяток.

 Абзац 2.

 "Лише п’ята частина чиновників (19%), яких судили за вимагання чи отримання хабара, опинилася за ґратами. Це дуже низький показник, враховуючи, що кожна частина статті 368 КК передбачає можливість позбавлення волі для хабарника. Середній термін ув’язнення склав 4 роки 7 місяців. Як відомо, максимальний термін покарання за неправомірне збагачення складає 12 років тюрми. Такого терміну за останні два роки не отримав жоден хабарник. 9% засуджених було виправдано. 38% отримали випробувальний термін.  Середній термін склав 2 роки 2 місяці. А 34% злочинців було оштрафовані - середня сума штрафу ледь перевищила 20 тис. грн."

1. Обратите внимание,  19% посадок - это "дуже низький показник", а 9% оправданий - высокий? 
2.  Максимальное наказание по 368 статье зависит от подпункта. Например п.1 - максимум 4 года (см ККУ ст. 368 п.1). Так что мысль "Середній термін ув’язнення склав 4 роки 7 місяців. Як відомо, максимальний термін покарання за неправомірне збагачення складає 12 років тюрми."  равносильна "максимальное наказание в Криминальном кодексе - пожизненное, при этом ни один Патриарх УПЦ на пожизненное за год посажен не был. Это зрада."***

Продолжение следует. См. http://statistifikacija.blogspot.com/2016/04/blog-post.html


* Зато авторы не поленились указать в 1-ом абзаце, что исследование проводилось при поддержки Посольства США (без указания выходных данных гранта).
** выделено автором 
*** т.е. имеет место возможная попытка манипуляции. 

Як навчитись швидко запам'ятовувати обличчя?

Пропоную для цього наступний підхід: тренування з використанням прокрутки у калейдоскопі фото. Якщо бачите повтор - натискаєте одну кнопку, якщо фото  нової людини - іншу.

На цьому методі засновано додаток для Андроїду Faciemo

кто поломал билд

Над проектом работают два разработчика : Рафик и Эллочка. Эллочка менее опытный разработчик и допускает в два раза больше ошибок чем Рафик.

Коммитят они последовательно, при этом у них есть CI сервер, который не дает закомитить пока:

1. не скомпилирует и не прогонит тесты над последним коммитом;
2. причем если последний коммит "ломает" билд - то сервер самостоятельно его отменяет;
3. т.е. в один момент времени может быть только один виновный;

Рафик ломает билд в 40% своих коммитов.

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

Кто виноват?
С вероятностью >85% Рафик не виноват (см. закон Баеса)

А вот если Рафик ломает билд в 10% своих коммитов то вероятность того что Рафик не виноват <70%

Пример выбора порядка выполнения подзадач при необходимости ответа заказчика

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

• подзадача 1  - время выполнения 1/2 дня (`t_{1}=1d=8h`);

• подзадача 2 - время выполнения 1 час (`t_{2}=1h`);

• подзадача 3 - есть два несовместимых варианта решения :

• вариант А  - пол дня (`t_{3}^A=1h`)
• вариат - B  3 дня (`t_{3}^B=3d = 24h`). 

   Выбор за заказчиком. Заказчик может ответить в течении часа (`t_{reply}^{fast}=1h`), а может и затребовать день(`t_{reply}^{slow}=1d`). По нашим (с разработчиком) прикидкам с вероятностью 90% заказчик выберет вариант B (`P_{3}^B=90%`). На то чтобы сформулировать ему вопрос понадобится около получаса (`t_{email} = 1/2h`).

   Я бы работал по следующему плану:

• отправил письмо заказчику;
• подзадача 1;
• подазача 2 ;
• если не получен ответ то приступил бы к подзадаче 3, вариант Б.
• по получении ответа либо продолжил бы делать вариант Б либо переключился на вариант А

   Разработчик же решил делать так:

• отправил письмо заказчику;
• подзадача 3, вариант Б (который 3 дня);
• получил ответ от заказчика (угадал - т.е. вариант Б+)
• подзадача 1;
• подзадача 2;

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

    Дальше для тех, кто любит математику:

    Сначала мой случай.
    Максимальное время на выполнение всего задания (худший случай) при моем подходе:

`T_{my}^{max} = t_{email,1,2} + max( (t_{reply}^{slow} - t_{email,1,2} + t_3^A), t_3^B ) =`
`= 1/2h + 4h+1h +max ((1d - 1/2h-4h-1h),3d) =`
`= 5 1/2h +max ((2 1/2h), 3d) = 29 1/2 h`,

   где `t_{email,1,2} = t_{email} + t_1 + t_2`;

   Минимальное время на выполнение всего задания (лучший случай) при моем подходе:

`T_{my}^{min}= t_{email,1,2} + min( (t_{reply}^{slow} - t_{email,1,2} + t_3^A), t_3^B ) = 8 h `

   Вероятность худшего случая при моем подходе :

`P_{my}^{max} = P_3^B = 90%`

    Мат. ожидание времени выполнения при моем подходе:

`E[T_{my}] = P_{my}^{max} * T_{my}^{max} + (1-P_{my}^{max}) * T_{my}^{min} = `
` = 90 % * 29 1/2 h + 10% * 8h = 27.35 h `

    Теперь подход разработчика.

     Максимальное время на выполнение всего задания (худший случай) при подходе разработчика:

`T_{dev}^{max}= t_{email}+max(t_{reply}^{slow} + t_3^A, t_3^B) + t_{1,2} =`
`= 1/2h + max(1d + 1/2d,3d) + 4h + 1h = 29 1/2 h`

    Минимальное время на выполнение всего задания (лучший случай) при подходе разработчика:

`T_{dev}^{min} = t_{email}+min(t_{reply}^{slow} + t_3^A, t_3^B) + t_{1,2} = 14h`

   Вероятность худшего случая при подходе разработчика:

`P_{dev}^{max} = P_{email}^{long}= 50%`

Мат. ожидание времени выполнения при подходе разработчика:

`E[T_{dev}] = P_{dev}^{max} * T_{dev}^{max} + (1-P_{dev}^{max}) * T_{dev}^{min} =`
` = 50 % * 29 1/2 h + 50% * 14h = 21.75 h `

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

Lindy Effect on source code

Recently I have a talk to one manager who, after looking through the source code  discovered, that old-and-dirty code is not changed for a year within which my team worked on the project.

My first thought and reply was that no one never re factored it because it simply works and the business will hardly pay for that.

But I was wondering if a Lindy effect applies here.

Could you expect that newly committed source code will (in general) have lower probability to remain within a year than source committed a long time ago?

I'll try to explain it with another example.
Writing a software is like writing a book. You write first version, then show it to your spouse and rewrite, the show it to the editor an rewrite again, and again and again. So at version X you have some text which was added in version 2, some comes from version 1, some comes within the current version. What text have more chances to be removed - added within version X, X-1 or added within X-C  (c >1)?

I have checked that with one of the most critical project (as for me) : mercurial_SCM (one of two most used source control system). It was chosen due to:

1. widely used
2. the source code of that project is within mercurial itself
3. at time of publication there were 25000+ commits made by 250+ authors (see ohloh.net stat)

On figure 1 you can see that 97% of source code which were committed at least 5000 commits ago will remain  the next 1000 commits*.

You also could found out that lines committed 20000 commits ago have 99.5% probability to survive next 1000 commits.

On figure 2 the same statistics is given for Mozilla project 

On figure 3 the statistics is given for Pidgin chat client

On figure 3 the data is given for GNU Octave

On figure 4 the data is given for CLisp programming language.

On figure 5 the data is given for python programming language project.

On figure 6 the data is given for nginx web server project.

On figure 7 the data is given for GNU Multi-Precision Library project

The source code of how I did that one could find in github.

* I have chosen to compare not in dates, but in commits, thus reducing effects of some activity picks.

** the higher is the age, the less input data was, so figures are a bit more volatile on the right