(ш!)кодер.by

Tax Free Польша

2011-09-09T02:00:00.000+03:00

Когда ездили в Польшу, первый раз в жизни попробовали вернуть налоги. Чтобы не забыть, опишу эту процедуру.

Нужно искать магазины со значком Global Blue (бывший Global Refund). Например, IKEA в Гданьске или Варшаве.

При расчете на кассе нужно предупредить о том, что хочешь вернуть налоги. В чеке должно быть не более 7 товаров. Один из чеков содержал 7 строчек, но товаров было 8 (2 подушки пошли одной строкой). Это ОК. Есть также некая минимальная сумма покупки - на данный момент 200 PLN.

В IKEA есть отдел по работе с клиентами, нужно подойти с чеками и паспортом, там к каждому чеку оформляют здоровую зеленую бумагу Global Refund с печатями и всякой остальной ерундой.

Мы возвращались в Беларусь через Брест-Тересполь (он же Варшавский мост).

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

Далее в теории деньги можно вернуть в Технобанке уже в Минске. Тем не менее на сайте Global Refund есть подозрительное "Polish cheques are only refundable in cash at our Refund Points!", ну и некоторые товарищи на форумах писали, что были проблемы с польскими чеками в Технобанке.

Поэтому мы решили получить деньги прямо на границе. На польско-белорусской границе, насколько я знаю, есть только один офис Global Refund - в тереспольском пункте. Несмотря на то, что написано на сайте, там есть два перерыва по часу, точное время уже не скажу, но вроде бы в 6 утра и 6 вечера. После прохождения польской границы, его нужно искать в здании слева (эдакая синяя дверь).

Нужен паспорт. Возвращают в злотых ~60% от налогов (около 14% от суммы покупки). Можно там же поменять на другие деньги, но курс грабительский.

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

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

Ксеноглоссофобия или боязнь незнакомых языков

2011-05-05T11:39:00.001+03:00

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

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

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

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

Итак, поехали! Если у вас в процессе чтения возникают вопросы или замечания, то прошу в комментарии

Миф 1 Для успешной карьеры достаточно знать всего лишь один мейнстрим язык

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

Даже в рамках одного языка часто не получается почивать на лаврах, тот же C# за время своего существования претерпевал серьезные изменения, С# 5.0 значительно отличается от C# 1.0 в том числе и концептуально.

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

Миф 2 Джависты пишут на джаве, а дотнетчики на сишарпе

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

На деле же в реальных проектах приходится иметь с целым рядом языков, существенно отличающихся друг от друга – SQL, джаваскрипты с экшинскриптами, HTMLи разных версий, XML/XSD/XSLT, скриптовые языки и т.п. На иных проектах до десятков доходит. Причем языки существенно друг от друга отличаются.

Получается, что изучение других языков – это норма жизни, а не исключение из правил.

Миф 3 Требуются годы, чтобы хорошо освоить язык

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

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

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

То есть сам язык – это всего лишь малая доля знаний разработчика.

Миф 4 Для любого .NET проекта годятся любые .NET разработчики

За годы .NET разработки я успел себя попробовать в разных типах проектов – десктоп приложения, веб-сервисы, веб-приложения, высокоскоростная обработка данных. Я в том числе разрабатывал и на Java.

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

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

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

Миф 5 Чтобы писать на каком-то языке, нужно его хорошо знать

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

Понятно, что идеального знания не требуется. Но все же, должно же быть какое-то фундаментальное понимание основ языка?

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

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

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

Если входное интервью не дает однозначного ответа, – мы иногда даем XSLT задачку в качестве входного теста. Суть задачки в общем-то в том, что подавляющее большинство XSLT либо не знает совсем, либо знает плохо.

Для справки, XSLT – это такой angle brackets язык, это совсем не ООП. Некоторым он просто взрывает мозг, там, например, нет переменных. В смысле var есть, но менять значение варов нельзя.

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

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

Итого

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

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

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

Языки, разработчики и менеджеры

2011-05-02T00:35:00.001+03:00

У нас в твиттере (опять) разгорелась дискуссия. Ну как, дискуссия-то особо не клеится, мыслей много, а сообщения слишком короткие – все-таки твиттер Может, в комментариях будет попроще.

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

К дискуссии присоединился Владимир Кочетков (магия твиттера, собираются три абсолютно незнакомых человека и обсуждают вопрос). Владимир считает, что проблема преувеличена, все-таки .NET, к C# достаточно близок, а особенности Nemerle освоить не так-то и сложно. Да и речь идет о небольшой туле, риск не так и велик.

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

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

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

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

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

В-четвертых, когда эти классные ребята с горящими глазами рассказывают другим классным ребятам (работающим в другой компании) о своем опыте в Nemerle… Я нахожу это полезным Это именно та адресная реклама, которая нам нужна на рынке программистов.

Ну и по поводу поддержки… Если вдруг тот, кто это все написал, уйдет куда-то (хотя с чего бы это?), а программисты в целом получают удовольствие от работы со всякими там маргинальными технологиями, то, может, другие разработчики наоборот будут рваться поддерживать этот кусочек, просто чтобы получить немного фана? Может, когда на собеседовании я вдруг скажу “а тут у нас еще на nemerle есть штукенция”, то у человека загорятся глаза и он все-таки пойдет к нам, а не к конкурентам?

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

Bugs is a software thing

2011-04-19T01:11:00.001+03:00

Bugs is a software thing.

In most business areas customers don’t pay for fixing issues. When you find a defect in your SLR camera, you just bring it back and get it fixed or get a new one for free. But in IT this is a norm when you pay for bug fixes as so this is some real functionality.

Ron Jeffries recently wrote a good story about defects. The main idea is defects shouldn’t be planned separately, they just have to be fixed and if it takes longer to release a feature we should factor this into estimates. In agile world we factor this into velocity.

But I’d like to touch base on why we usually try to plan and prioritize defects separately. Well, it is obvious, sometimes we have quite a few of them and some bugs take a lot of time.

As Kate mentioned in Ron’s story, we can minimize amount of bugs by learning from them. Correct. I’d also add that we can minimize amount of bugs by working in pairs and unit-testing. It’s rather obvious.

But the big thing which is not very well understood is that quite often bugs take a lot of time because of the way we tackle them.

I also quite often hear questions about the role of QA in agile projects. Many books just skip this question, people get confused and testing/bug fixing in a somewhat waterfall approach.

Let’s take a closer at a rather familiar loop many teams work in:

developers implement a feature during iteration X
when iteration X is over it is released for testing and being tested during X+1
when testing is done, release goes to customers and they explore it during X+2

So what’s bad here? The delay in between implementation and feedback on it. It’s the root cause of everything else.

It takes a lot more time to fix a defect which is found after several weeks of work on other features, people just entirely lose context on it. Sometimes another developer has to fix defects in code of his colleagues which doesn’t speed things up.

When bugs arrive, the team works on another release already and can’t fix them immediately (the team can’t fix them immediately also because the context is lost), so bugs require some filing – clear description, steps to reproduce, severity, etc. All these things should be formally documented, testers can’t just explain them to developers. And some issue tracking systems are nasty.

Apparently, this way bugs affect schedule of subsequent releases. So bugs is a big thing now and require prioritization. Prioritization isn’t a simple thing, developers need to provide estimates, product owners have to make some tough decisions. It may be difficult to engage product owners, so delays become even bigger.

When a bug is fixed it needs to be retested, but there is again a delay between a bug fix and a another test, so we have some context switching for testers.

Actually, such a way often results in bigger and bigger delays between implementation and actual testing. Some teams come up with a really heavy-weight approach to stay on top of the bugs, but in fact they just slow things down even more.

To summarize, we get the following wastes:

context switching (both for dev and test team)
formal filing and tracking which drags time
additional planning as a result (estimates, prioritization)

The key thing is to decrease delays, so the team should aim to test and fix defects almost immediately after implementation (let’s say during next 24 hours).

I heard about a brilliant approach to implement it. Unfortunately, I couldn’t implement this on one of my projects yet, but there are real projects which work in this way.

So in addition to a pair of programmers we also need a tester. They form a triplet (triple programming). The triplet works on each feature together:

the tester take part in all discussions
when developers work on a feature, the tester creates test cases
when developers think the feature is ready it gets tested immediately, developers can take care of e-mails and other stuff during testing
when a bug is found, the tester just shows it to developers, it is worked on immediately
during delays the tester automates tests (developers can also help)
after the tester is happy about quality, he shows the feature to customers
any issues found during the demo are fixed immediately

Apparently, some bugs are discovered later and go the tough way, but most of the time:

defects do not require documenting
defects are found and fixed in a reasonable time frame before people lose context
explicit planning is not required

But again, the key thing is to get feedback ASAP, no matter how.

I welcome your comments.

Outlook: hide delayed tasks

2011-04-15T00:54:00.001+03:00

There are certain tasks which I need to do, but I can’t do them until some date/time.

What I want is to put such tasks into my task list, but I don’t want them to be visible until their start date. I don’t want to put them into my calendar, I can do them after day X, but don’t know when exactly I will find time for them, so my task list is a better fit.

So the first step is to actually specify a start date for such a future task and then set up a filter on your outlook task list to hide delayed tasks and this is a little bit trickier:

Click on “Arrange By” on top of your task list and select “View Settings”
Click “Filter” button and select “Advanced” tab; by default it filters in current tasks (where Completion Date doesn’t exist AND Completion Flag doesn’t exist)
We also want to filter in tasks with Start Date “on or before” Today, so you click on a “Field” button under Define Criteria, select a Start Date there, specify “on or before” in Condition and type “Today” in the Value text box
Unfortunately this filters out all tasks without start date, apparently we want to show current task OR tasks without Start Date, so you again add Start Date field and pick up “doesn’t exist” Condition from a drop down there
This is it, enjoy, delayed tasks are filtered out now

(here is how your filter should look like)

Note that conditions from 2nd and 3rd points are actually appended to resulting query using AND logic, while 3rd and 4th conditions should use OR logic. Actually, I thought that you can’t specify this logic in Advanced tab since all conditions are ANDed by default, so initially I hacked my custom query in SQL tab (poor me, those SQL queries look pretty ugly, you can check an auto-generated one).

Funny enough, but Advanced filter is so advanced that it understands 3rd and 4th conditions should be ORed. So actually you don’t need to mess around with a SQL query.

Would you read me in English?

2011-04-14T12:50:00.000+03:00

Я читаю много блогов на английском и иногда чешутся руки оставить какой-то комментарий. Использовать свой OpenID для shсoder.by как-то глупо, ведь тут все на русском.

Подумываю, может мне стоит начать писать на английском? Лень заводить какую-то отдельную площадку.

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

Будете ли вы читать меня на английском

Теперь беленький

2011-04-05T01:02:00.000+03:00

Многих угнетал темный цвет фона - жалобы учтены, теперь он опять беленький.

Плюс к этому бложик можно посмотреть в неожиданных ракурсах, например, http://www.shcoder.by/view/sidebar#!/ или вот http://www.shcoder.by/view/flipcard#!/. Последний забавен тем, что все мои посты влазят на одну страницу (ну, почти все). Как-то мало я написал.

Вьюшками сильно не злоупотребляйте - там счетчики не работают. И рекламка не показывается (черт, палюсь-палюсь).

GTD для иррационалов

2011-03-31T01:34:00.000+03:00

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

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

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

Учитывая сий факт, мне кажется, что подходящей интерпретацией GTD для иррационалов является уже изрядно потрепанная техника Васи Кислого (narod.ru! дизайн сайта еще хуже, чем у меня), которую мне буквально недавно подкинули. Лексика иногда далека от культурной (в самый раз для ленивых иррационалов), тем не менее тут все взрослые люди, и, надеюсь, воспримут это с юмором. В общем, хватит оправдываться своим иррациональным нутром - марш работать!

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

Посоветуйте книжку по маркетингу

2011-03-26T23:57:00.000+02:00

Хотел бы почитать что-нибудь интересное на тему маркетинга, не посоветуете?

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

Чуть-чуть подробней о том, зачем нам это.

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

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

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

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

Что-то слишком много вопросов :) Вероятно, опытные маркотологи и рекламщики смогли бы помочь бедным программистам. Понятно, что маркетинг часто нацелен на широкую аудиторию, а мы работаем с конкретными людьми, хотя их там десятки, если не сотни. Но маркетинг поднимает и такие вопросы, поэтому если есть книжки про b2b маркетинг, про что-то ближе к нам - пишите.

Про Google Adsense

2011-03-20T10:55:00.000+02:00

Я начал активно писать в блог прошлым летом. До этого было несколько попыток (например, в Лондоне я писал про Лондон, а в отпуске про отпуск - потому что было скучно), но я быстро сдавался.

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

Дело в том, что это был первый источник о статистике посещений моего блога. Уже после этого я узнал, что есть Google Analytics, Яндекс.Метрика или хотя бы Akavita, но это позже, когда я вошел во вкус.

Так в чем же собственно соль? Чем мне помогла статистика? Статистика посещений - это циферки сродни тем, на которые геймеры смотрят при прокачивании эльфа до 51го уровня. Более того, в Google Adsense эти циферки привязаны к самому азартному мерилу успеха - деньгам. Короче, графики придали динамику процессу, а циферки дали возможность меряться, прямо как в старые-добрые времена, когда я бродил по подземельям в Diablo.

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

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

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

Начнем с простой цифры - на сегодняшний день совокупный доход за все время использования Google Adsense составляет 1.12 евро.

У меня, конечно, очень популярный блог, но все же надо представлять о каких порядках идет речь. При таком раскладе, чтобы что-то реально получать, посещаемость нужно увеличивать раз в 1000. Тематика у меня простая - программизм в Беларуси. Dev.by, наверное, самый популярный сайт по этой тематике, а посетителей у него не больше 3 тысяч в день (можно посмотреть на Акавите). То есть на такой тематике далеко не уедешь :)

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

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

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

Больше рекламы, подключение других сетей, неудобное её расположение (например, чтобы было сложно отделить рекламу от текста) тоже привели бы к увеличению дохода.

Тем не менее, все это не про меня, смысла в этой активности в своем блоге я не вижу. Так что не судьба, похоже. Но я все же рекламку не снес - а вдруг попрет? ;) Вот и про деньги статейку написал... Жажда халявы - она такая, тяжело лечится.

Быстрая (пере) индексация писем в Outlook

2011-03-16T13:17:00.000+02:00

Если вы переустановили OS (например, Windows 7) и никак не можете дождаться пока Outlook (2010, к примеру) проиндексирует весь ваш почтовый архив (ну, большой он, например), то вам сюда. Например :)

С этой проблемой я сталкивался уже больше 2х раз. Настроил Outlook, подключил Local Personal Folders, пытаюсь найти письмо - а Outlook вам сообщает, что еще не проиндексировал письма. Индексатор вяло работает в фоне, и если вы что-то активно делаете, то он приостанавливается (это называется search indexer backoff). Кнопки Index Now, которая бы заиндексировала все прямо сейчас тоже нет. В итоге, индексация архива запросто может занять ДНИ.

Так вот, Search Indexer Backoff можно отключить. В окошке Win+R запускаете gpedit.msc, в Computer Configuration>Administrative Templates>Windows Components>Search находите пункт Disable Indexer Backoff и устанавливаете значение в Enabled (внимание! нетривиальная логика Disable Enabled). Теперь индексатор не будет снижать скорость индексации, если вы активно работаете с компом.

Назвать это "максимальной" скоростью индексации все равно язык не поворачивается, он там что-то около 5-10 процентов цпу пережевывает, но мой архив в течение часа или около того проиндексировался до конца, тогда как в прошлый раз я страдал целых два дня. После окончания индексации можно вернуть установки обратно.

Про аналогии и метафоры

2011-03-13T00:09:00.001+02:00

Аналогии очень здорово помогают объяснить сложные понятия другим людям, поэтому важно запоминать удачные – вполне вероятно это потом здорово поможет.

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

Например, technical debt мне казался всего лишь красивым словосочетанием, однако выяснилось, что эта аналогия очень близка западному миру. Однажды мы сделали хорошее дело и успели сделать фичу X к демо на 2 дня раньше срока. Правда, после демо заказчик все никак не мог понять, почему мы сразу же не можем приступить к фиче Y. В итоге кто-то случайно сказал, что эти два дня – это technical debt, который мы получили, сделав X раньше срока. Заказчик просиял, и все стало на свои места.

Броское analysis-paralysis (пусть и не совсем аналогия, но у многих эта фраза мгновенно вызывает в голове вполне четкую картинку) когда-то мне здорово помогло достичь понимания с коллегой, а спустя год или около того, та же фраза помогла уже этому коллеге объяснить беспокойство по поводу затягивающейся подготовительной фазы заказчику.

На тренинге по коучингу я пытался объяснить тренеру (не айтишнику) проблему рефакторинга – почему программисты все время недовольны своим кодом. Я рассказывал про "качество кода", и было видно, что основная идея куда-то постоянно ускользала. Я понял, что низкое "качество кода" понималось как наличие ошибок в коде. Тогда я сравнил код с книгой – книга может быть написана без ошибок, тем не менее, текст может быть низкого качества, то есть трудночитаемым, плохо структурированным или попросту не интересным. Понимание было достигнуто мгновенно.

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

Надеюсь, теперь стало понятнее, чем так полезны метафоры:

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

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

Grumpy Old Editor

2011-03-11T18:19:00.000+02:00

Коллеги из ThomsonReuters посоветовали блог - http://grumpyoldeditor.wordpress.com/. Бывший журналист Reuters со стажем работы в три десятка лет пишет о том, как правильно писать. Приятный английский и интересные заметки, есть чему поучиться.

P.S. Rolf Soderlind - не совсем английское имя, правда? Потому что он швед :) Так что происхождение не является оправданием плохому английскому, дерзайте.

Два монитора

2011-02-23T16:39:00.000+02:00

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

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

Вообще говоря, проще работать с одним монитором, так что подумайте. Интересный форм-фактор - широкоформатники. На 22-дюймовом мониторе с хорошим разрешением в режиме side by side уже вполне комфортно помещаются два окна без ощущения сжатости. Или, например, на домашнем ноутбуке проблема решается 15-дюймовой матрицей с разрешением в 1650x1080 (на стационарных мониторах обычно таким не заморачиваются, проще больше диагональ сделать, а не лепить пиксели) - кому-то кажется мелковатыми шрифты, но это скорее дело привычки.

Но все же еще лучше два больших монитора. Или три :) Поэтому вернемся к теме.

В Windows 7 несколько мониторов настраиваются быстро - через правый клик по рабочему столу и меню Screen Resolution или нажатием Win + P. В общем, выбираем опцию Extend Desktop и поехали.

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

Тем не менее в некоторых случаях различное разрешение - неизбежное зло. Например, в случае если вы подключаете второй монитор к ноутбуку. Эту проблему можно частично решить. Оказывается, в меню Screen Resolution в 7ке можно менять расположение мониторов относительно друг друга, просто перетягивая их мышкой. Поэтому если различается разрешение по вертикали, но совпадает по ширине (широкоформатная матрица ноутбука и стандартный монитор), то можно сделать ориентацию по вертикали. То есть у меня ноутбук стоит на столе и "рабочий стол" расширен вверх (а не вбок) на монитор на подставке над ноутбуком.

Еще один вариант ориентации, который я видел, - повернуть один из мониторов вертикально (то есть физически "положить" его набок, а потом поменять ориентацию монитора на альбомную в меню Screen Resolution). Так как вертикаль у нас становится длиннее, то это удобно для списков - почтового клиента, списков задач. Правда, не все подставки для мониторов такое позволяют :)

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

Здорово помогают управлятся с окнами на нескольких или больших мониторах новые горячие клавиши 7ки, что кажется удобным:
Win + Up/Down Arrow Key = Распахнуть/свернуть окно
Win + Right/Left Arrow Key = Распахнуть окно на левую или правую половину текущего экрана (удобно для больших широкоформатников)
Shift + Win + Right/Left Arrow Key = Переместить окно на другой монитор (супер!)
Win+number (1-9) = Запускает (или переключается на активное окно) приложение, закрепленное в этой позиции в панели задач

Вообще, в 7ке с горячими клавишами все хорошо и можно не только перемещать окна. Смотрите сюда - я для себя почерпнул много нового.

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

Ну, пока все. Если какие-нибудь еще хитрости знаете, то пишите в комментарии.

8 привычка высокоэффективных людей

2010-12-08T23:44:00.000+02:00

Господа, можете меня поздравить, я теперь официально высокоэффективен: прочитал аудиокнигу (ага, в машине) Стивена Коуви «7 привычек высокоэффективных людей».

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

Теперь о самой книге (и о восьмой привычке местного разлива).

Что реально понравилось, так это её объем в аудиоформате. В общем, похоже, там только выжимки, и, наверное, это правильно. Подобные книги обычно страдают переливанием из пустого в порожнее. С другой стороны, некоторые переходы были не совсем очевидны. Видимо, сказывается местами неудачная компрессия.

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

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

Поясню на примерах:

- идет встреча, важная шишка говорит – «вопросы есть?»; вопросы есть, но не хочется их задавать, дабы не показать свою некомпетентность

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

- появляется задача и побежали; работаем, работаем, а через полгода выясняется, что в соседней комнате уже решили проблему – обидно, потратили много времени зря

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

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

Вот у нас идет разбор хотелки заказчика, мы уже задали 40 вопросов и 41 как-то уже неудобно задавать (ну, мы дураки что ли? сами не можем разобраться?). Ну и ладно, наверное, должно быть так – вроде бы логично. Потом, правда, выясняется, что надо было совсем по-другому.

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

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

Очередной пример. Взяли в крупный холдинг завхоза. Живенький такой дядечка, все ходил и вопросы задавал – «а тут как?», «а это что?». В итоге, до директора отделения дозадавался.

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

5 мифов о документации

2010-10-18T23:19:00.001+03:00

Наверное, самая частая жалоба IT-шников – это отсутствие документации на проекте. Желание обрести “peace of mind” и иметь четкую инструкцию, что и за чем надо делать, вполне понятно, однако мифов по поводу документации столь много, что всех сезонов myth busters не хватит на внесение ясности в данный вопрос.

И все же давайте попробуем! Итак, 5 мифов о документации.

Миф1: Чем подробней, тем лучше

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

То есть детализация имеет мало общего с понятностью и правильностью тезисов.

Поэтому помните – после того, как вы напишите документ, кому-то придется его читать. Причем, если вы напишите его один раз, то читать его будут намного больше раз. Реальная экономия времени как раз в том, чтобы потребители тратили на чтение меньше времени.

Миф2: Навалились, еще чуть-чуть, и вот оно счастье!

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

Представьте себе ситуацию, когда документация обновляется, но все время с небольшим опозданием. В итоге, чтобы объяснить какой-то документ другому человеку, все равно документа недостаточно, и нужен кто-то, кто объяснит как оно на самом деле. Доверие к документации падает, после прочтения некого тезиса участники все равно его перепроверяют устно с носителями знаний. На передачу информации тратится столько же времени, как и в случае отсутствия документации. Плюс тратится время на саму документацию. По-моему, мы сами себя обманули?

Миф3: Документации нет. Очевидно, что в этом виноват кто-то другой

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

Многим, конечно, невдомек, что это не внешняя, а внутренняя проблема и начинать нужно с себя – например, приучить себя вовремя заполнять журнал (btw, это тоже документация, просто в другом формате). Серьезно, ведь на это нужно всего-то N минут в неделю, если вам так сложно это сделать, то почему вы думаете, что кому-то проще тратить значительно больше времени на другое?

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

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

Миф4: Документация – это файлы в формате .doc. Окей, .xls тоже годится

Традиционно результатом code review является .doc файл с табличкой, а может быть и .xls файлик. Удобно ли пользоваться таким документом? В случае если code review проводится группой людей, неплохо бы положить файл в репозиторий. Да, к сожалению, с merge изменений могут быть проблемы – файл лучше блокировать на время редактирования.

Что если список вести как issues в YouTrack, например? Просто пометить их определенным тэгом. Команда может голосовать по каждому пункту, оставлять комментарии и сразу принимать в работу, как любую другую задачу. Лучше, чем .doc, правда?

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

Product manager просит вас составить список шагов, который выполняется во время работы CruiseControl. Сделаем ему .xls? А что если аккуратно именовать Ant targets и написать html-страничку, которая красиво показывает, что и за чем следует в Ant скрипте. И поддерживать документ не надо, добавили target – он уже в отчете.

Про банальную генерацию .chm из комментариев в коде даже не буду упоминать.

Миф5: Заказчик постоянно меняет требования. Мы сделаем спецификацию и будем использовать её как щит

Да, пора снять розовые очки – это не работает. Какая основная задача разработчиков? Ну, помимо написания unit-test-ов, нужно, чтобы заказчик был доволен. Если вы упретесь рогом «Погоди, но ведь здесь так написано, даже если тебе это и не нравится», то будет ли заказчик доволен? Наверное, нет, но, скажете вы, по крайней мере, он нам будет обязан заплатить деньги.

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

А продолжит ли он с вами дальнейшую работу? А посоветует ли он вас своим партнерам? Или все-таки напишет где-нибудь у вас на сайте, что никогда в жизни не будет с вами работать и другим посоветует того же?

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

Итак, самый главный вопрос - «Что делать?»

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

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

Однако, подумайте об этом с другой стороны. Если продукт хороший и интерфейс интуитивно понятный, часто ли приходиться заглядывать в User Guide? Если у вас огромный Installation Guide, не значит ли это что нужно заняться автоматизацией? В случае подробной спецификации, не работаете ли вы по Waterfall модели – без тесного общения с заказчиком в процессе разработки? Во многих случаях документация – это своеобразный workaround для проблем, которые эффективнее решаются другими способами.

Мартин Фаулер писал в «Рефакторинге», что комментарии внутри метода – это плохой запах часто намекающий на то, что нужен рефакторинг. Если у вас в методе появляется //этот код вычисляет эту штуку вот таким офигенским спосбом, то скорее всего вам нужно выделить кусок кода в метод getШтукаОфигенски(); и комментарий больше будет не нужен.

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

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

Вместо сложного дизайна и объемных архитектурных документов используется принцип Simple Design (http://www.martinfowler.com/articles/designDead.html), подкреплённый юнит-тестами, непрерывным рефакторингом и code review в результате работы в паре.

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

#devcamp #di_by 1й день - впечатления

2010-10-14T23:20:00.000+03:00

На 14е я специально резервировал день отпуска, чтобы посетить http://devcamp.by/, - программа выглядела очень заманчиво. День прошел (и еще три дня впереди! особенно надеюсь на воскресенье), и так как далеко не все, кто хотел, смогли посетить конференцию сегодня, то попытаюсь вкратце описать мои впечатления.

Первый день #devcamp был посвящен Project Management. Большая часть информации не была для меня чем-то новым, тем не менее даже знакомый материал - хорошо поданный и структурированный - подталкивает на интересные мысли.

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

Что запомнилось?

Качественным исполнением и глубиной проработки материала порадовали коллеги из EPAM Systems:

Ваня Кравченко с Customer Focus (удачный шанс наконец-то послушать доклад, который я пропустил на EPAM TR Conference)
Юра Шиляев с Командоварением
Денис Петелин с Немотивирующими деньгами

Выгодно отличались живостью выступлений и презентаций коллеги из Exigen Services:

Света Колупаева про Парное программировани
Дима Зданович про Ретроспективу

Ребята, большое спасибо, вы молодцы.

Очень рад, что знакомые уже многим епамовцам тренера/презенторы, высоко оцениваются не только коллегами внутри компании, но и более широкой аудиторией. Да, у нас действительно неплохо, и EPAM - это далеко не МакДональдс, как кто-то думал до конференции ;)

Не на всех докладах пришлось побывать, поэтому если кого не упомянул - не обижайтесь, может быть, еще получу удовольствие от просмотра записи на http://di.by/ и обязательно напишу :)

Конечно, грех жаловаться, но как нас учит Дима Зданович, важно проводить ретроспективы и учиться на ошибках, а также в напутствие тем, кто еще только планирует заехать на #di_by, - были и некоторые неудобства:

Все-таки в шатре холодно, наверное, этот формат не для октября месяца :) Тем не менее, спасибо за пледы, они здорово помогли!
Указки, пульты ДУ, возможность подключить звук - надеюсь, на последующих днях все подготовят заранее, некоторым выступающим было действительно сложно
Думаю, что в Загорье не так уж много посторонних людей, жаждущих воспользоваться халявным вай-фаем, - можно было бы просто дать публичный доступ, особенно учитывая то, что, как выяснилось, одной циферки в выданном пароле просто не хватало :)
И все же возможность норамльно пообедать, пусть и за деньги, не выезжая в Минск (мы в итоге припоздали на fluent English) - это важно :) Я понимаю, что можно было заранее зарегестрироваться, но стоило дополнительно указать, что если этого не сделать, то будут только слойки
Чуть больше указателей на Загорье не помешало бы :)

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

Uber Inbox и альтернатива Recall Message

2010-10-01T22:32:00.000+03:00

По горячим следам предыдущего поста еще пару Oulook советов.

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

Вкратце, в Options Outlook-а отключается сохранение писем в Sent Items и добавляется правило на сохранение письма в Inbox после отправки. Очень просто, по-моему, все должно быть понятно по скриншотам в статье.

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

Более того, таким способом Outlook включит письма в Conversations не только из Sent Items, но и из других папок, включая локальные папки.

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

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

Решение, предлагаемое лайфхакером, простое. Опять-таки, на событие "отправка письма" вешается действие по задержке отправки на 3 минуты. После нажатия кнопки Send письмо 3 минуты лежит у вас в Outbox, его можно удалить, поправить и т.п. Сразу скажу, мне показалось, что достаточно 1-1.5 минуты.

Hacking Outlook Public Folders

2010-09-27T23:52:00.000+03:00

Если вы работаете в крупной компании, то скорее всего пользуетесь Exchange Server и Outlook. Вероятно, у вас большой поток писем и часто возникает надобность делиться письмами с вашей командой.

Для этой цели хорошо подходят Public Folders - вы создаете для вашей команды такую папку со своей структурой, и вся проектная переписка попадает туда. Вместо того, чтобы делать коллеге Forward письма или ставить в CC всю команду просто на всякий случай (рискуя попасть под spam фильтр), вы перетягиваете письма в ваш Public Folder.

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

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

Чтение Inbox

Во-первых, я держу свой Inbox пустым (похоже на то, что описывает Макс Дорофеев в своем слайдкасте), поэтому новых писем немного и они отправляются либо в Public Folders (архив), либо в Local Folders (личное), либо в задачи. Письма в Inbox отсортированы по дате по возрастанию (то есть новые письма - внизу). Это честнее по отношению к коллегам и так удобнее читать.

Читая письма, я пользуюсь пробелом. Включить эту опцию можно в File>Options>Mail>Outlook Panes>Reading Pane:

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

Public Folders видны только в Folder List View (Ctrl+6), поэтому если вы используете Mail View (Ctrl+1), который значительно компактнее и включает секцию Favorites, то перетягивание писем вручную в Public Folders может быть утомительным. В любом случае, стандартная процедура перетягивания письма обычно требует активной мышиной возни, а это вредно для ваших суставов.

Quick Steps

В Outlook 2010 можно создать Quick Steps для часто повторяемых действий, например, вот так:

Как видите, у меня есть два основных типа Quick Steps:

Переместить письмо в одну из проектных Public Folders и пометить его как прочтенное
Создать задачу и прикрепить к ней письмо

У каждого Quick Step есть горячее сочетание клавиш. Outlook 2010 здесь не гибок и дает возможность использовать только Ctrl+Shift+число от 1-9. Каждый Quick Step у меня начинается с цифры, которая подсказывает, какой hot key использовать для Quick Step. Панель сверху используется просто как памятка, я не нажимаю на Quick Steps мышкой.

Если письмо не требует от меня действий, я нажимаю одно из сочетаний Ctrl+Shift+номер папки, и письмо попадает в нужный Public Folder.

Создать такой Quick Step непросто. В диалоге создания Quick Step при выборе стандартного действия "Move To" Outlook предлагает указать целевую папку - набор недавно использованных папок либо опция Other Folder, показывающая структуру ваших папок в диалоговом окне. Удивительно, но в этом диалоге нет Public Folders.

Зато если вы выберете или откроете письмо, затем нажмете кнопку Move в Ribbon меню над письмом и выберете опцию Other Folder, то там сможете выбрать нужный вам Public Folder. После этого эта папка будет доступна в списке недавних папок и теперь можно будет создать соответствующий Quick Step.

Помимо перетягивания писем в Public Folders, можно также включать в CC почтовый адрес целевого Public Folder, однако, убедить заказчиков так поступать обычно сложно.

Письма-задачи

Quick Step для создания задачи из письма звучит как перебор, ведь все знают, что письмо можно отметить флажком, и оно попадет в ваш список задач. Но с этим способом есть проблема - ваша задача будет названа Subject-ом письма и не будет говорить вам, что требуется сделать (что уже не очень правильно). Если же вам нужно выполнить разные действия на письма с похожим Subject-ом или если Subject письма нерелевантен, то читать подобные списки задач непросто. Таким образом, этот Quick Step мотивирует вас на создание корректных задач и поддержание вашего to do list в хорошем состоянии.

Быстрый доступ к Public Folders

Так как Public Folders расположены удаленно, то могут возникнуть 3 проблемы:

Недоступность папок в Offline режиме
Медленный поиск
Также может быть неудобно то, что папки не доступны в Mail View (только в Folder List)

По поводу 3го пункта - если нажать Ctrl и щелкнуть мышью по Quick Step, то вы перейдете в папку, в которую Quick Step должен перемещать письма.

Также можно использовать Favorites. Работает это не совсем тривиально, поэтому немного деталей.

В Folder List находите ваш любимый Public Folder и в меню по правому щелчку мыши выбираете опцию Add To Favorites; ваш Public Folder попадет в секцию Public Folders > Favorites - он все еще не в основном Favorites в Mail View.

Далее, выбрав вашу папку в Favorite Public Folders, нажимаете по ней правым щелчком, и выбираете пункт Show in Favorites - эта опция наконец-то добавит выбранный Public Folder в Favorites в Mail View.

Кстати, в Favorites можно также добавить ссылки на Search Folders, разбив свой входящий поток писем по разным критериям (например, важные письма, письма, где только вы в TO или где вы всего лишь в CС). Это может помочь после возращения из отпуска или после болезни, когда писем действительно много.

То, что Outlook делает в случае добавления папки в Public Folder Favorites зависит от настроек File>Account Settings>E-mail>Ваш Аккаунт>Change>More Settings:

Eсли пункт Download Public Folder Favorites помечен галкой, то Outlook создает локальную версию удаленной папки и периодически синхронизирует вашу локальную версию с версией на сервере. Теперь папка становится доступной и в Offline режиме, также поиск по папке может быть быстрее.

Возникает непреодолимое желание выбрать эту опцию, но попробовав её, я был вынужден её отключить:

Почему-то письма скачиваются, если вы их открываете напрямую из Public Folders, если просматривать письма из Favorites, то Outlook переливается всеми цветами своей палитры, но письмо не показывает.
Синхронизация папок происходит не сразу - вы письмо уже скопировали, а в Favorites его еще не видно.
Если вы перетащите письмо в Favorites - оно попадет лишь в вашу локальную копию общей папки и не появится на сервере. То есть эти папки по сути read only (хотя сначала таковыми не выглядят).

Если же эта опция не включена, то в Favorites у вас будет просто ссылка на Public Folder - никаких сюрпризов, вы работаете с удаленной папкой. Если вы туда перетащите письмо, то оно попадет на сервер.

В связи с этим, с первыми двумя проблемами я смирился (проблема доступа к папкам в offline и не такой шустрый поиск), зато если вы потеряете свой notebook, то меньше будет проблем с offline контентом на нем, плюс поиск может быть и медленный, но потребляет меньше ресурсов на вашей машине (наверное).

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

Android Infected

2010-09-22T23:48:00.001+03:00

Хотите верьте, хотите нет, но этот пост я пишу с нового телефона. На конференции я пощупал Nexus One у Юры Шиляева и HTC Desire у Жени Киселевича. Ждать чудес надоело и я таки взял последний.

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

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

Общие впечатления очень хорошие, но и не без недостатков:

- нет синхронизации с exchange по задачам; для себя я решил, что в телефоне буду вести только личные задачи - оно и удобнее, не будут путаться рабочие дела с домашними;

- нет скайпа. то есть он был, но теперь его не стало - клиент fring заблокирован скайпом, а клиент от скайпа теперь доступен только абонентам verizon (причем он не работает по WiFi, более того раньше он WiFi соединение намеренно рвал); это грустно, когда жадность доводит людей до неадеквата.

Но в любом случае - думаю ждать Windows phone 7 еще долго (я не про релиз, я про тот момент, когда пофиксят все баги), поэтому пока советую Андроид.

Skype cowardly blocks fring

Юра Шиляев

Location : ул. Острошицкая, Минск,

560 новых читателей в Национальной Библиотеке

2010-09-19T02:43:00.000+03:00

В EPAM работают много книголюбов, и, наверное, именно поэтому очередная конференция EPAM Thomson Reuters состоялась в Национальной Библиотеке.

Это уже пятая конференция. За пять лет к названию конференции добавилось слово Thomson (наш заказчик стал крупнее) и из него выпало слово Developers, ведь продукты делаются совместными усилиями бизнес-аналитиков, специалистов по качеству, производительности, интеграции, а также разработчиков и их менеджеров.

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

В этот раз я участвовал в конференции с активной позиции - два доклада по CI, круглый стол по Agile, плюс пару слов о proof of concept, который мы недавно делали на .NET 4.0. Про последнее рассказывал в основном зале перед аудиторией ~500-600 человек и очень рад тому, что масштабы уже совсем не пугают (ну, может быть, только чуть-чуть).

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

Из неожиданного:

Подходили незнакомые ребята и говорили спасибо за выступление; что тут сказать, доброе слово и собаке приятно :)
Подарили Blogging Heroes : Interviews with 30 of the World's Top Bloggers с пожеланиями увидеть меня в следующем издании. Уже прочитал первое интервью с askdavetaylor.com - похоже, придется поднажать, у него миллион посетителей в месяц :)

Afterparty прошел в клубе Broadway/Bronx, где Мартин давал уже традиционные уроки меренги, а с Аркадием можно было запросто пообщаться. Целый вечер драйв поддерживали ребята из Artefact, за что им респект и уважуха. В общем, отлично провели время, только пиво закончилось слишком рано :)

P.S. А записаться в библиотеку можно любому :) Правда, без ученой степени читать придется в читальном зале.

JavaScript - есть и хорошие стороны

2010-09-10T00:54:00.000+03:00

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

Скопипастив очередной кусок JS, я вспомнил слова Мартина Фаулера (интересное интервью - хоть посмотрите, как он выглядит), что для расширения кругозора надобно учить хотя бы по одному новому языку в год. Полиглоты, называет он таких программистов :) Я же подумал - надоело мне мучаться с JS, хочу научиться писать на нем нормально.

В общем, я чуть-чуть попытался разобраться (ниже со ссылками), по-моему, очень даже интересно.

Сначала я решил посмотреть, что у нас есть из почитать. Две наиболее советуемые книги по JavaScript это:

JavaScript: The Definitive Guide by David Flanagan
и
JavaScript: The Good Parts by Douglas Crockford

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

Douglas Crockford: "The JavaScript Programming Language"/1 of 4
Douglas Crockford: "The JavaScript Programming Language"/2 of 4
Douglas Crockford: "The JavaScript Programming Language"/3 of 4
Douglas Crockford: "The JavaScript Programming Language"/4 of 4

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

К слову, Дуглас Крокфорд, как выясняется, интересный товарищ. В частности, он придумал JSON - ныне очень популярный формат (AJAX, например, это часто не Async JS and XML, а Asynch JS and JSON, просто потому что последний обычно компактнее, а значит быстрее).

Так вот, после просмотра лекций Дугласа выяснилось, что в JS есть не мало интересных моментов (те самые The Good Parts), я упомяну лишь то, что, к примеру:

Там не нужны классы, однако ООП вполне там работает
Паттерн Prototype - это основа наследования JS и часть языка
В JS Reflection - это приятно; объект - это коллекция свойств и функций, по которым можно итерироваться
Лямбда-функции, которые в C# появились не так давно, в JS существуют с самого начала (про Java давайте не будем вспоминать, closures вроде там до сих пор только обсуждают - поправьте меня, если я не прав)
Паттерн Decorator нужен в C# и Java всего лишь из-за ограничений этих языков

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

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

Но это еще полбеды. Девушка из комментов ко второй части лекции сразила меня наповал:

This is really indepth. I am not sure half the time what is he talking about. Maybe more simplified examples would help..

Так что, видимо, JavaScript обречен так и остаться непонятым :) Похоже, тут даже наличие попытки изучить ситуации не исправит.

P.S. Там же на Yahoo Video есть лекции Крокфорда по DOM, найдете по ссылкам в Related сами - тоже интересно, особенно его комментарии, как так получилось, что во всех браузерах все по разному. Кстати, видео 2006, а очередной виток войны браузеров он предсказал четко, правда, про Chrome тогда еще не знал.

Singleton in .NET 4 - вопрос снят?

2010-09-01T21:42:00.002+03:00

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

С моей точки зрения этот вопрос не так уж много показывает (скажем так, он кажется обманчиво интересным), но ответы на сопутствующие вопросы (более интересные) сами его провоцируют. Например, на вопрос "Какие вы знаете шаблоны проектирования", ответ обычно начинается с "Singleton, Factory..."

К сожалению, несмотря на то, что GoF имеет успех уже на протяжении более 15 лет, достаточно часто ответ на этом заканчивается. Кстати, на второй часто задаваемый вопрос "Чем отличается Factory от Abstract Factory" ответ дается еще реже.

Но давайте разберемся, стоит ли начинать ответ с Singleton? Наверное, не стоит. Вообще, многие считают, что Singleton - это anti-pattern. И в любом случае, Singleton - это далеко не самый интересный шаблон проектирования.

Что также хочется отметить, обычно просят реализовать просто Singleton, не упоминая ленивую инициализацию, однако почему-то на доске очень часто появляется double checked locking. Это плохой стереотип - все так делают, значит, так нужно. В реальной жизни ленивая инициализация чаще всего не требуется, а еще чаще стоимость многопоточной реализации Singleton (потому что у дополнительной синхронизации есть стоимость) превышает экономию на отложенной инициализации.

Так вот, к чему это я все? :) Проблема настолько избита, что в .NET 4.0 ввели специальный класс, который наконец-то дает нам out-of-the-box реализацию, - Lazy, и реализация значительно упрощается:

   1: public class LazySingleton

   2: {

   3:     // static holder for instance, need to use lambda to construct since constructor private

   4:     private static readonly Lazy<LazySingleton> _instance

   5:         = new Lazy<LazySingleton>(() => new LazySingleton());

6:

   7:     // private to prevent direct instantiation.

   8:     private LazySingleton()

   9:     {

  10:     }

11:

  12:     // accessor for instance

  13:     public static LazySingleton Instance

  14:     {

  15:         get

  16:         {

  17:             return _instance.Value;

  18:         }

  19:     }

  20: }

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

Чуть побольше про ленивую инициализацию и Lazy можно почитать на MSDN здесь. Есть и на русском, но поверьте, оно вам на таком русском не нужно.

И вот казалось бы, одним вопросом для дотнетчиков меньше. Но что-то у меня есть подозрения, что вопрос еще какое-то время побудет актуальным :) Как считаете?

GTD и TDD

2010-08-28T12:10:00.000+03:00

Вот вы думаете зря что ли в TDD и GTD две буквы из трех одинаковые? Вы еще, наверное, думаете, что TDD - это когда тесты пишут перед реализацией.

Дело в том, что нужно быстро взять и прочитать TDD by Example Кента Бека и все сразу станет на место - не может ведь быть, что 240 страниц текста посвящено только test first принципу.

Не может быть и не есть.

Кент, например, рассказывает нам, что основной принцип TDD - это движение маленькими шажками. При решении какой-то задачи, он предлагает записать её на листик (ну, в VS есть настоящий to do list, такой же как и в Outlook) и прикинуть, понятно ли как решить задачу прямо сейчас. Если нет, то подумать, какой шаг может нас приблизить к решению основной проблемы. Таким образом он предлагает идти рекурсивно до первой простейшей атомарной задачи, которую мы и возьмем для реализации.

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

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

Более того, если во время реализации пришла какая-то супер-идея как сделать что-то лучше, то мы не отвлекаемся, а просто вносим её в наш to do list. Это важно, мы выгружаем её из мозга, чтобы она не мешалась у нас под ногами и не мешала нам сконцентрироваться над текущей задачей.

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

Причем, стоит особо отметить, - не будь у нас зеленого теста (или теста вообще), мы бы не были на 100% уверены в завершенности задачи. А точнее мы бы на 99% процентов были уверены, что первый запуск выдаст нам парочку-другую - а может и больше - непростых ошибок.

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

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

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

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

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

Господа, это и есть принципы Getting Things Done, адаптированные к программированию, то есть TDD - это и есть, не побоюсь громких слов, эффективная система time management для разработчиков.

И помните, только настоящим пацанам не нужны тесты!

Мозг и ночные бдения

2010-08-22T21:43:00.008+03:00

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

Gtd Dev Labs2010 Part I

View more webinars from Maxim Dorofeev.

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

Когда под рукой есть Outlook, то все просто, но у меня вот иногда такое ночью бывает. Приходит в голову идея, и пытаешься её «не забыть». Она тебя теребит, мешает заснуть, и тут приходит вторая идея. Мозг все больше не спит, накапливается критичиская масса идей, которые нужно не забыть, ведь неплохие идеи :) Все, сон потерян, и нужно что-то делать, чтобы не проснуться завтра с больной головой.

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