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

У меня большая проблема, думаю что у многих она есть. Я говорю об утреннем подъеме на работу. Хочу поделиться как я её для себя решил.

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

Так вот, а что есть просыпаться под хороший рок, подумал я.

У меня ноутбук с которого я в свое время снес нафиг Win Vista  и поставил старый добрый WinXP, а потом и вовсе перешел на Ubuntu.

создаем простенький скриптик


#!/bin/bash
export DISPLAY=:0 && vlc -f ~/Downloads/RadioROKS_256.m3u

Тут ключевой момент в переменной DISPLAY. Дело в том, что если не задать её vlc не понимает на каком X терминале запускаться. Таким образом мы указываем что мы запускаемся на локальном хосте в текущей сессии.

Берем scheduller заданий cron.

crontab -e

и настраиваем scheduller


# m h  dom mon dow   command
0 7 * * 1-5 bash ~/wake_up.sh # JOB_ID_1

сохраняем конфигурацию и просыпаемся каждый будний день в семь утра под RadioRoks.

А как вы просыпаетесь?

Об архитектуре и DAO в частности

Я тут вот о чем подумал.

Я позапрошлом и прошлом моем проектах использовались ORM (Object Relational Mapping). И почему-то архитекторы приравнивали их к DAO. Тоесть слой сервисов напрямую дергали ORM слой, составляли критерии или HQL в случае hibernate. Таким образом осуществлялось взаимодействие с базой.

Полное дерьмо.

И вот почему. Что проще, замокать DAO или Hibernate? я про тестирование сервисов в изоляции.

Что проще, один класс DAO за другим переписать (смотри паттен branch by abstraction) под iBatis или еще проще под pure jdbc и наоборот или сидеть и искать все вызовы вашего текущего ORM слоя. И тем самым задерживать релиз из-за какой то внутренней переделки, на которую заказчику глубоко посрать, ведь ему реально посрать на то, что ты используешь для доступа к базе (CRUD).

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

Мысль на закуcку. В чем разница между DAO и Repository паттернами? IMHO в том что к Repostory Эрик Эванс добавил ряд требований, таких как Repository может быть применен

к Root Donain Object, и все модификации с Childs могут происходит через Repository.

Об эффективности оффшорных комманд

В наше время у буржуев с запада и Европы очень популярным стало скидывать работу в страны восточной Европы а также в страны Азии. Я сейчас говорю об IT бизнесе. Казалось бы чего грустить? Если работы валом, причем работы по меркам Украинских зарплат высокооплачиваемой, то о каких проблемах может идти речь? К сожалению проблемы есть и вот какие.

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

Митинги
Митинги должны быть короткими (до часа), на них желательно не опаздывать. Совместные митинги с заказчикам должны сопровождаться высоким качеством канала связи, иначе хана, отстающее видео от звука, или вместо спецификации транслируется пошаговая стратегия обновления экрана, накладывается на проблему языка и до ofshore команды доходят лишь крупицы информации.
Бороться с этим можно многими способами.
На митингах нельзя говорить одновременно нескольким людям из за того что на другой стороне это зачастую походит на Одесский Привоз в разгар торговли. Говорящий должен к себе направить камеру и говорить в микрофон.
Как то к нам приезжал Крэйг Ларман Craig page, и на одном из PBR предложил onshore стороне делать контрольные точки, ставя вопросы по теме к нам в offshore. Тем самым добиваясь полного понимания вопроса обсуждения. Это может затянуть митинг, но гарантирует понимание всех сторон.

Бюрократия и секюрити
В некоторых организациях эти моменты доходят до абсурда, по крайней мере так нам кажется со стороны ofshore. Нас менеджмент "удивляет" вопросами типа как бы нам повысить в 2 раза эффективность, и при этом загоняет нас в рамки виртуальных машин и паршивого канала связи с серверами onshore. Как следствие половину времени тратиться на поднятие енвайрмента, осознавания факта, что тебе уже некуда делать check out из svn, потому что больше 30 гигов на виртуалке не положено и кучи других неприятных активностей которые приносят скорее раздражительность чем удовлетворение от работы.

пока все. а как у вас обстоят дела?

Continuous delivery

Surfing in internet, i've found some interesting interview with Martin Fowler and Jez Humble, here is a link. Also there are guys who doubts about Continuous Delivery and Continuous Deployment practices, here is a link. Taking into account that i'm working in agile environment and we also have these painful release activities i decided to provide some comparison of what are these guys talking about and what we actually have in my project.

I can say that we haven't built a communism in this sphere. First of all we are not ready to release on demand, and this is the one of the main point of Continuous Delivery pattern. We still have problems in our culture such as keep all tests green, i will talk about it later. Because of business specific, constraints, security and finally complexity of the product we cannot automate everything. I think we have too bureaucratic process of several approves before release. The fact that we're offshore is also impose the fact that we cannot take part in release activity and also production health. And from technical point of view the architecture of the product is very complicated, there are a lot of external dependencies which we cannot automatically test, but only front to back manual testing.

Tests.
I really like the article testing-pyramid, especially the phrase "Where we also value that the information provided from the right matters to our customer and is rich in information, and the information from the left matters to our developers and their ability to be efficient." I've been a witness and also opponent in production issue judgement, when some guy asks, please point me some test that you have done for this User Story. So i just want to highlight that all test are valuable and you should automate them as march as possible.
The other issue that might cause you avoid acceptance tests and other complicated test is actually complexity of these tests. In compare to unit tests, they require more reliable interface, the should be understandable for other guys then IT, i mean BA and QA, and finally they should be produced by other guys other than IT.
So, while your software is evolved , your testing framework is also should evolve.
And final issue about acceptance test is actually maintenance. No doubt that it's rather harder to maintain acceptance test then unit test. First of all, you should wait much more time the result of these tests in you continuous integration system, because of the nature of these test. The second point is that the reason of the failure of such tests may be hidden under complexity of the flows under these tests.   And this is the main problem of resistance of developers to keep them green


Ready to production code.
One guy reproached me, that using brunches is more efficient way to produce features in your software. But i would like to remind you what branches causes:

• Merging process. This process may be too long and painful
• You cannot guarantee the coexisting of several features in mainline on demand
• you cannot build continuous delivery pattern upon multiple brunches   

Deployment pipeline

Well, this is an implementation of Continuous Delivery pattern. And IMHO it's strongly coupled with specific and architecture of the software. So any implementation of Deployment Pipeline should be flexible. May be it should have a pluggable architecture.

So thats all so far. I believe that it was interesting for you. 

Болезнь отошла

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

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

Ко всей драматичности ситуации добавился еблан который подсел в купе на станции "Раздельная". Почему еблан? Потому что храпел как еблан.

Утром выйдя из поезда я позвонил в страховую и вызвал доктора. Диагноз ОРВИ, мне кажется все доктора ставят одинаковый диагноз, их нужно вызывать для того чтобы лекарства привозили, забирать их на пороге и говорить "пока доктор", своеобразные драгдиллеры делающие кассу определенным аптекам, ну а мне то что, страховая платит.

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

Среда.

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

О душе.

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

Виски.

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

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

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

Вроде все

 

Investigation through the testing

Я заранее прошу прошение у читателя за обилия терминологии на английском, просто иногда трудно перевести на русский, да и стоит ли переводить?

Я уже полтора года работаю в условиях Agile а именно по Scrum методологии. причем мы проповедуем Large Scale Distributed Scrum. У нас порядка 8 команд распределенных по всему земному шару, которые работают над одним продуктом и в одном codebase.

Пару спринтов назад к нам поступила в работу User Story которая требовала дополнительного технического исследования перед планированием и оцениванием трудозатрат для реализации. К сожалению сценариев еще не было готово поэтому Specification by Example, которые потом практически безболезненно ложатся на интеграционные или функциональные тесты, мы сочиняли параллельно исследованию. Решено было попробовать описать сценарий интеграционным тестом который бы покрывал один из пунктов Spec by Example.

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

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

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

О популярности языков программирования

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

Вот ссылка на блог моего знакомого blog-in binary.

Если лень читать, то на мой комент о том что не смотря на то что Java выглядит несомненно скудноватой по сравнению с C# по ряду причин, компенсируется это наличием языков программирования на основе JVM такими как Scala и Groovy, которые поддерживают ряд вещей которых нет в Java (замыкания, динамическое программирование и т.д.) автор блога ответил что смысла в них нет ибо по рейтинку tiobe они занимают не больше 0.1% по популярности.

Заглянув на ресурс tiobe я обнаружил, что и впрямь Scala и Groovy являются аутсайдерами рейтинга.
капнув глубже выяснилось, что, скажем, баш также вылетел из top списка и почему-то bash и bourne shell у них не одно и тоже?
И как это D, R и Q языки программирования (это что вообще за хрень такая?) на 23, 30 и 31 а bash, которым мы все любим пользоваться для скриптования непонятно в какой заднице?
Кроме того у меня закрадываются сомнения по поводу того что PL/SQL стоит ниже по рейтингу чем T-SQL, аргументирую это тем, что во-первых из моего опыта rонторы в которые я устраивался требовали знания именно Oracle а не MS SQL, во-вторых именно база Oracle признана de facto стандартным продуктом для использования в Enterprize, ну и в-третьих не забываем о PostgreSQL, пусть не такой популярной как MySQL но добавляющей к PL/SQL рейтинг (не смотря на то что в PostgreSQL используется PL/pgSQL)

Как говориться почувствуйте разницу, 0.8 % это не только IT вакансии

А вот еще сравнение

похоже bash и groovy делает pascal (кто бы сомневался), тогда как по рейтингу tiobe паскаль на 17 месте и рейтинг у него 0.709%

Ниже цитата с сайта tiobe
The ratings are calculated by counting hits of the most popular search engines. The search query that is used is
+" programming"
This search query is executed for the top 6 websites of Alexa that meet the following conditions:

• The entry page of the site contains a search facility
• The result of querying the site contains an indication of the number of page hits

Based on these criteria currently Google (32%), YouTube (10%), Yahoo! (3%), Bing (3%), Wikipedia (16%), Blogger (32%) and Baidu (3%) are used as search engines.

Я вот не пойму с каких пор на YouTube можно достать адекватную инфу про язык программирования. На момент написания этого блога Wikipedia вылетела из TOP 6 сайтов алексы и заменил её поисковик life.com. Ну да ладна по большому счету все языки программирования в одинаковых условиях, а статистика это наука и спорить с ней сложно.
Поэтому я смирился, что Scala, groovy и, наконец bash аутсайдеры по рейтингу tiobe, но на мой взгляд это противоречивые данные.

Нельзя судить о популярности языка программирования по количеству найденных ссылок в поисковиках по +"language programming". Язык популярен тогда когда он реально востребован на рынке труда