среда, 8 декабря 2010 г.

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

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

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

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

понедельник, 18 октября 2010 г.

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

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

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

четверг, 14 октября 2010 г.

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

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

пятница, 1 октября 2010 г.

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

По горячим следам предыдущего поста еще пару 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 минуты.

понедельник, 27 сентября 2010 г.

Hacking Outlook Public Folders

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

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

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

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

среда, 22 сентября 2010 г.

Android Infected


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

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

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

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

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

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

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

Skype cowardly blocks fring 

Юра Шиляев 

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

воскресенье, 19 сентября 2010 г.

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

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

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

пятница, 10 сентября 2010 г.

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

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

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

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

среда, 1 сентября 2010 г.

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

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

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

суббота, 28 августа 2010 г.

GTD и TDD

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

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

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

воскресенье, 22 августа 2010 г.

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

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

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

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

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

четверг, 19 августа 2010 г.

Дикарем в Черногорию?

Немного технических деталей про организацию поездки в Черногорию.

Мы воспользовались услугами Аэротрэвел и отдыхали на вилле Monte Royale в Будве. У EPAM Systems есть 5-процентная скидка на услуги Аэротрэвел и мы ей успешно воспользовались.

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

вторник, 17 августа 2010 г.

Черногория - сейчас и раньше

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

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

среда, 21 июля 2010 г.

Интернет в РБ становится дешевле

На Космос ТВ появились новые тарифы - метеор и комета. Вкратце, предлагают в 4 раза больше трафика за те же деньги - 16 GB за 50 тысяч вместо 4GB за 55. Шуму особенно не поднимают, если бы я случайно не наткнулся, то так бы и сидел на оптимальном.

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

понедельник, 19 июля 2010 г.

Round Robin

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

В нашей команде за этим понятием прочно закрепился и другой смысл – честное распределение рутинной работы между членами команды.

пятница, 16 июля 2010 г.

Production Clone

Я вот недавно про CI читал и прочитал очередной банал - test in production clone. Что, мол, непрерывная интеграция должна происходить на железе очень близком к production. И по характирестикам, и по настройке.

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

пятница, 9 июля 2010 г.

Akavita и Белтелеком

Зашел давеча на http://www.akavita.by/, думаю, добавлю себя в каталог их или там счетчик возьму, а браузер мне и говорит:
В связи с отключением питания в дата-центре предприятием Белтелеком, частично повреждена база данных. Ведутся восстановительные работы. Приносим извинения за неудобства...

PS:

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

Странное мероприятие под названием "плановое отключение электричества в дата-центре" (на четверть суток!) ярко характеризует отношение к белорусскому интернету и IT-индустрии в целом.
Сочуствую. Вот она вам государственная монополия. Примечательно, что вчера у них вместо PS было что-то вроде !@#$%^&* - я считаю, гораздо более эмоциональное заявление :)

среда, 7 июля 2010 г.

Ab Initio ETL

Чтобы не расстраивать тех, кто приходит ко мне по запросу в сабже, расскажу пару слов о том, что я знаю про Ab Initio, а знаю я чуть больше, чем просто то, что это дорогостоящая, очень быстрая и засекреченная ETL платформа. Каких-то больших секретов я вам не открою, однако мои впечатления вам могут быть вполне интересны.

понедельник, 5 июля 2010 г.

Stop rolling your own CSV parser

Your own CSV parser

Вот именно такую заметку я нашел, когда пытался подыскать подходящую версию CSV парсера для нашего приложения, - Stop Rolling Your Own CSV Parser.

Каждое предложение было до боли знакомо - после безуспешных попыток привести код в приемлемое состояние, захотелось все же воспользоваться готовым решением. Читая заметку, я был согласен с автором на 100%.

Дальнейший анализ все же показал, что не все так просто.

пятница, 2 июля 2010 г.

Data Quality

Читаю сейчас Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. Интересная книга, советую.

Книга

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

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

Data Quality

Один из (анти)паттернов, очень близкий к моим профессиональным интересам, - Data Quality.

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

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

Это сложно

Именно так:
0. Сложно определить - правильные данные или нет
1. Исправить неправильные данные сложно
2. Еще сложнее сделать это автоматически
3. Правильно исправить неправильные данные - совсем тяжело
4. Правильно исправленные данные скоро могут стать неправильными
5. Если вы исправляете данные за ваших поставщиков, поставщики данных поставляют вам все более неправильные данные
6. Если вы исправляете данные в принципе, то все неправильные данные, которые приходят из вашего приложения - это ошибки в вашем приложении

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

Медвежья услуга

Это похоже на глотание exceptions. Если вы проглотили exception, то вы спрятали ошибку. Ошибка все еще существует. Когда к вам придут и скажут - у вас здесь неправильно, то вы только можете надеяться, что сможете когда-либо выйти на истинную причину ошибки. Ведь вы её сами же маскируете, проглатывая некорректные данные.

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

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

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

среда, 30 июня 2010 г.

TDD и опытные разработчики

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

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

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

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

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

Опытные разработчики также не отрицают тот факт, что первый тест обычно не работает и тестирование приходится повторять вновь и вновь. Вновь и вновь.

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

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

Так что пишите юнит-тесты и вам не придется сожалеть о непротестированном коде.

понедельник, 28 июня 2010 г.

Учим албанский

Разгорелась дискуссия по поводу shkoder (увага, мой домен пишется через "с" - shcoder.by). Как подсказывает гугл (клик ми, там весело) - это вовсе не то, о чем вы думаете:
Шко́дер (алб. Shkodër или Shkodra) — город в Албании, расположенный на берегу Скадарского озера в 20 км от побережья Адриатического моря, вблизи слияния рек Дрин и Буна.
Кстати, а мы были на Скадарском озере (албанцы его тоже Шкодером называют), правда, со стороны Черногории. Там круто, национальный заповедник, так что похоже не судьба мне появлятся на первых страницах гугловского поиска. Тем более, говорят, там хорошая рыбалка.

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

UPD: Что-то кнопок я пока не вижу.. Видимо, жуткие баги... UPD: работает!

Pilates по-мужски

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

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

А мужики-то стесняются

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

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

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

Кстати, просто взгляните на немцев здесь - Gimnastyk nach Pilates. Да их там больше, чем тёть. (надеюсь, nach по-немецки ничего плохого не значит).

Таким образом, "женские" виды спорта - аэробика, тот же пилатес, аква-аэробика и т.п. - нужны и полезны. Не стесняйтесь :) Перекос в женскую сторону наоборот вам на руку, хотя бы эстетическое удовольствие получите от занятия. N.B. На аква-аэробику ходят в основном старушки, которым уже поздно заниматься нормальным спортом, - опять суставы виноваты. Но зато там весело.

Итак, Pilates

Итак, пилатес. Пилатес - он медленный. Дышим, медленно чего-то делаем, иногда возникают трудности с координацией (по крайней мере, у такого увальня как я), иногда статика. Большое внимание животу, все время нужно держать пресс в тонусе. Есть упражнения на растяжку.

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

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

BTW, поясню свою мысль по поводу эстетического удовольствия:



Надеюсь, вы меня понимаете.

Pilates и плоскостопие

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

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

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

воскресенье, 27 июня 2010 г.

Паведамленне на роднай мове

Гэта будзе цяжка, але я паспрабую. Мы ў Беларусі зусім мала размаўляем на беларускай мове, аднак большая частка ведае яе. Гэта проста, мы вывучаем мову ў школах, але потым цалкам забываем яе, бо не карыстаемся ў паўсядзённым жыцці.

Трэба адзначыць, што мой маленькі шкодзер дапамагае мне пісаць гэтае апавяданне, таму ўсе памылкі зусім не ад таго, што я згубіў навык, – проста вынік яго “дапамог” :)

Аднак вернемся да тэмы. Таму, што мова не выкарстоўваецца, ёсць шмат спасылак. Аднак я засяроджуся на тых, якія маюць сэнс для IT. Я бачу дзве асноўныя:
  1. Бібліятэкі, якія мы скарыстоўваем штодня, звычайна на ангельскай мове, таму цяжка пісаць нешта на беларускай
  2. Ад таго, што ўсе на ангельскай, айтышнікі ужо і ня ведаюць, як вымаўляць нейкія словы не толькі на беларускай, але і на рускай мове
Што мы можам зрабіць?

Па-першае, не ўсе ведаюць, аднак праграмы можна пісаць і па-беларуску. Да, гэта значыць, што не толькі каментарыi мают быць на беларусай мове, але і сам код. Вось караценькі просценькі прыклад такога коду:

  1. using System;   
  2.   
  3. namespace МойРодныКут   
  4. {   
  5.     public enum Прыгажосць   
  6.     {   
  7.         /// <summary>   
  8.         /// Такая прыгожая, што лепш збегчы.   
  9.         /// </summary>   
  10.         СтрашнаПрыгожая,   
  11.   
  12.         /// <summary>   
  13.         /// У кожнага свае недахопы.   
  14.         /// </summary>   
  15.         АлеВумная,   
  16.   
  17.         /// <summary>   
  18.         /// Ведае, як прапатчыць KDE пад FreeBSD.   
  19.         /// </summary>   
  20.         СэксБомба   
  21.     }   
  22.   
  23.     /// <summary>   
  24.     /// Публічны шкодзер.   
  25.     /// </summary>   
  26.     public abstract class Шкодзер   
  27.     {   
  28.         /// <summary>   
  29.         /// Бывае і так!   
  30.         /// </summary>   
  31.         /// <param name="дзяўчна">Трэба дзяучына.</param>   
  32.         /// <returns>Вось дык вось.</returns>   
  33.         public МаленкіШкодзер ПагуляцьЗДзяўчынай(IТДзяучына дзяўчна)   
  34.         {   
  35.             if (дзяўчна.Прыгажосць == Прыгажосць.СтрашнаПрыгожая)   
  36.                 ПапіцьПіва();   
  37.   
  38.             if (дзяўчна.Прыгажосць == Прыгажосць.АлеВумная)   
  39.                 ПашкодзіцьУКодзе();   
  40.   
  41.             if (дзяўчна.Прыгажосць == Прыгажосць.СэксБомба)   
  42.                 return new МаленкіШкодзер();   
  43.   
  44.             return null;   
  45.         }   
  46.   
  47.         /// <summary>   
  48.         /// Гэта да. Асабліва цёмнае спадабаецца.    
  49.         /// </summary>   
  50.         public abstract void ПапіцьПіва();   
  51.   
  52.         /// <summary>   
  53.         /// А як жа інакш.   
  54.         /// </summary>   
  55.         public abstract void ПашкодзіцьУКодзе();   
  56.     }   
  57.   
  58.     /// <summary>   
  59.     /// Дзяўчыны бываюць розныя, аднак усе маюць прыгажосць.   
  60.     /// </summary>   
  61.     public interface IТДзяучына   
  62.     {   
  63.         /// <summary>   
  64.         /// Апасля макіяжа.   
  65.         /// </summary>   
  66.         public Прыгажосць Прыгажосць   
  67.         {   
  68.             get;   
  69.         }   
  70.     }   
  71.   
  72.     /// <summary>   
  73.     /// Агу-агу. Пісь-пісь.   
  74.     /// </summary>   
  75.     public class МаленкіШкодзер: Шкодзер   
  76.     {   
  77.         /// <summary>   
  78.         /// Здурэлі зусім?!?   
  79.         /// </summary>   
  80.         public void ПапіцьПіва()   
  81.         {   
  82.             throw new NotSupportedException("Сіську лепш дайце!");   
  83.         }   
  84.     }   
  85. }  

Не верыце, што тут няма памылак? Паспрабуйце праверыць у Visual Studio.

Па-другое, вось вам караценькі слоўнік. На дапамогу згубіўшымся кодзерам:
  • Скачаць – спампаваць
  • Эстимация – падлік
  • Баг – памылка
  • Билд – зборка
  • Релиз – пастаўка
Па-трэц’е, вось вам і перекладчык, калі зусім забыліся. Не ідэальна, але трымаецца дасткова добра.

Спадзяюся, што я вас неяк заахвоціў і хаця б адзін дзень у вас будзе беларускамоўным. Не губляйце свае карані :) А калі зауважылі памылкі, адзначце гэта у камЕнтарах.

четверг, 24 июня 2010 г.

Голосование

Меня сегодня подначивали по поводу моего нового домена :) Завидуют, наверное.

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

Всего лишь несколько комментариев по поводу shcoder.by:
  • Нет, я не шелл кодер :)
  • Я вожу Ford, к марке Skoda я холоден
  • Да, это от кодер и шкода (бел.)
На самом деле я уже плавно перехожу в категорию кодеров, которых к коду допускать нельзя. Я, конечно, пытаюсь держать форму и даже кое-что писал как-то, показав кое-кому кое-чего, а если точнее то, что я еще ого-го!, однако, ясно, что еще пара-тройка лет, и я буду как один из моих менеджеров в начале моей девелоперской карьеры. Уж он как дорывался до кода, то за вечер столько набрасывал, что потом неделю разгребаешь и чешешь затылок - как бы это объяснить, что венгерская нотация уже не гуд.

Однако же иногда ой как хочется чуть-чуть нашкодить :) Так, что тут вам не там, и не надо нам здесь этого.

среда, 23 июня 2010 г.

Свой домен в зоне BY

Господа, свершилось и вроде бы работает - в адресной строке вы теперь должны видеть http://www.shcoder.by/.

Пару слов о процедуре. Она оказалась чуть сложнее, чем я думал (вдруг кто-то из патриотических соображений захочет поддержать отечественную зону). Для зоны BY вам нужно выполнить 3 шага:
  1. Определиться с DNS серисом, который вы будете использовать для управления своим доменом - я воспользовался http://www.zoneedit.net/; надо зарегестрироваться, вам выдадут первичный и вторичный DNS, их нужно будет указать во 2м шаге
  2. Купить домен в зоне BY - регистрируетесь на http://www.domain.by/, оплачиваете по инструкциям (79 тысяч БРБ или около 26$)
  3. Привязать домен к blogspot - здесь очень простая инструкция для zoneedit.com и blogspot; инструкция простая, но ждать, пока информация по вашему домену станет видна в DNS, придется от нескольких часов до пары дней
К слову, домен в .com вам обойдется в 2.5 раз дешевле и будет проще в использовании. Blogger сразу предлагает зарегестрировать домен за 10$ - причем вся дальнейшая настройка для blogger делается гуглом автоматически (никаких левых DNS), но это для com.

Опыт же общения с open.by (да, domain.by - это "открытый контакт") пока не очень позитивный. Для домена мне пришлось уже два раза съездить к ним в офис, причем в переписке они меня упорно величают andrw andrew. После того, как я им 2 раза на это указал, они ответили:

"Здравствуйте, andrw andrew, спасибо, мы учтем ваши замечания"

Похоже, они издеваются. Но зато наш родной BY.

пятница, 18 июня 2010 г.

5 почему

5 почему (Five Whys) - это одна из методик "бережливого" прозводства (Lean Software Development or Lean Manufacturing).

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

"Почему билд упал?" "Вкоммитали неработающий код" "Ааа, понятно....". Кому что стало понятно, правда, не очень ясно. Поэтому обычно я теперь спрашиваю много почему, до тех пор, пока проблема не развернётся в нечто действительно реальное и требующее корректив.

В этом случае я использовал аналитическую часть методики "5 почему", сама же методика идет немного дальше анализа.

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

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

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

Итак, я не побрился.
  1. Почему? - Еще не разобрали тот ящик, где лежала бритва
  2. Почему? - Не хватило времени
  3. Почему? - Не могли найти ящик, в котором лежала бритва
  4. Почему? - Бритва лежала отдельно от других принадлежностей (пены с лосьоном)
  5. Почему? - Забыли про бритву, когда складывались и положили в последний ящик, когда уже не знали, где лежала пена и лосьон
С каждым вопросом "почему" мы все больше углубляемся в проблему и взрезаем очередной её слой.

Это была аналитическая часть. Далее для каждой обозначенной проблемы приводим решение.
  1. Сначала разбирать вещи первой необходимости
  2. Записать сколько требуется времени для переезда
  3. Наклеить стикеры с содержимым на ящики
  4. Сгруппировать принадлежности по ящикам, нести ящик туда, где его нужно разбирать
  5. Провести инвентаризацию, вещи будет легко группировать еще до сборов (в какой ящик что положить) и ничего не будет забыто
То есть мы не просто пытаемся решить "основную" проблему, мы выстраиваем 5 линий защиты, которые нам помогут не допустить той же самой ошибки еще раз.

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

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

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

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

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

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

Открою секрет - мы её притягивали за уши к ответам, которые у нас уже есть. Мы задали гораздо больше почему, чем приведено выше, поэтому хотелось написать только значимые с самыми красивыми выводами. Рассуждения ниже объясняют, почему так получилось. И да, после того как мы нашли бритву, я не стал чаще бриться :)

Основные недостатки заключаются в том, что:
  • если подумать, то зачастую на один вопрос почему существует много ответов; то есть получается этакое дерево ответов; в частности большая часть веток дерева, которое могло быть построено по нашей проблеме, не приводили нас к необходимости инвентаризации; ветки бывают интересными и не очень; наверное, в этом случае важно содержание, а не форма - красивая цепочка почему не самоцель
  • правильных решений проблем методика автоматически не дает, никто вас не страхует от некреативных решений - "забыли бритву?" "окей, надо в следующий раз не забывать"; хотя 5 степеней проработки все же дают лучше результат, чем поверхностный анализ (хоть где-то что-то правильное придумаете)
  • иногда анализ тяжело развить, к примеру, "забыл бритву" "почему? потому что рассеянный" "почему рассеянный? o_O? потому что с улицы бассеянной." - мы упираемся в проблему, причин которых мы не знаем; часто все же бывают решения, например, "весенний авитаминоз" с вполне понятным способом решения проблемы; также можно попробовать найти другую ветку, то есть на более ранних этапах попробовать дать другой ответ почему; и на самом деле цепочка вопросов может быть связана другими способами; в технической поддержке зачастую есть несколько уровней поддержки, проблема передается с одного уровня на другой, пока не будет решена; в этом случае вопросы могут быть "почему первая линия поддержки не решила проблему?", "почему вторая линия не решила проблему?" - опять таки важно содержание, а не форма
  • иногда 6й, 7й и т.д. вопросы вскрывают проблемы поинтереснее; наверное, это просто выражается в неудовлетворенности от ранее данных ответов, что следует воспринимать как толчок для бOльшего количества почему; то есть не надо стремится к формализму, любая методика может нуждаться в адаптации к проблеме
В целом же, любая ретроспектива и корректирующие действия лучше, чем ничего. Проблемы выше все же не настолько критичны, тем более секрет в том, что если с первого раза не удалось сразу решить что-то, то будет второй раз (если он будет), который позволит нам снова взглянуть на ту же ситуацию уже в свете прошлого анализа и корректив, сделанных ранее.

В любом случае, удачного вам анализа.

четверг, 3 июня 2010 г.

Motivation

Многие уже подозревают, но не все убеждены, что айтишники работают не за деньги, а за идею. Здесь чуть-чуть подробнее и с огоньком:



Интересно, что Scrum (ну,  для тех, кто не знает - гибкая методология разработки ПО, здесь подробнее) эксплуатирует все три упомянутых способа мотивации:
  • Self direction - самоорганизующаяся команда
  • Mastery - перерывы между итерациями разработки, когда разработчики занимаются своим собственным развитием (инженерные дни); кстати, в ролике выше это попадает также и в категорию self direction
  • Purpose - цели спринта (итерации разработки) или цели релиза

Top 10 Office 2010 Features

Пользуясь новым офисом уже как минимум несколько месяцев (начиная с беты), скажу, что улучшения заметны.

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

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

И наконеце мой top 10 (может быть попозже добавлю картинок с примерами, сейчас лень):
  1. Новый splash screen. Красиво переливается :) Настраивает на нужный лад. 
  2. Поддержка нескольких exchange servers в Outlook 2010. Ну, я не буду вдаваться в подробности, кому приходилось ранее работать более чем с одним exchange server-ом знают насколько раньше все было плохо. Причем, даже непонятно зачем MS так нас обижали отсутствием возможности нормально работать с несколькими серверами. 
  3. Outlook 2010 conversations (разговоры). Да, теперь письма группируются по subject, пусть это и не удивляет пользователей gmail. Группировка сделана аккуратно, то есть в Outlook она мне больше нравится, чем в gmail. Корректно собирает разговор из разных папок. Один нюанс - если поиск сделан только по текущей папке, то в сгруппированном разговоре останутся письма только из текущей папки (ну как бы логично, но неудобно). Решается включением в настройках по умолчанию поиска по всем папкам. Одна только проблема - у меня это работает медленно. Но писем действительно много. С другой стороны, иногда что-то полезное и из архивов появляется.
  4. Outlook 2010 Search (поиск). Появился мини-язык поисковых запросов. Удобно. При свободном вводе появляется подсказка с выбором поиска по полям From, Subject - удобно тоже.
  5. Project 2010 and Visio 2010 Ribbon Interface (новая панель инструментов введенная ранее в Office 2008 для Office, Excel и т.п.). Теперь действительно часто используемые функции удобно расположены в Ribbon-ах (в том числе контекстных), много того, что раньше было запрятано теперь легкодоступно и бросается в глаза.
  6. Outlook 2010 MailTips (подсказки). Посылая письмо еще до отправки вы видите out of office auto-reply, иногда здорово экономит время. При посылке на список (distibution list) появляется посдказка о том, сколько подписчиков в списке. Помогает образумить людей и заставляет их дважды подумать перед посылкой письма на широкую аудиторию.
  7. Project 2010 Timeline View (временная шкала). Ну, это прорыв. Простая, но удобная фича. Особенно часто на стороне заказчика я вижу, как многие пытаются построить в Excel или еще где-нибудь некие высокоуровневые таймлайны или роадмапы. Да, они нужны для презентаций, не будешь же ты топ-менеджменту показывать Gantt Chart. Важно также не просто наличие фичи, но и то, что с ней удобно работать.
  8. Project 2010: Team Planner (планировщик ресурсов). Опять-таки просто, но очень удобно. В теории помогает сделать ручное распределение ресурсов и поэтому удобно показывает, кто занят, а кто нет. На практике удобно и при автоматическом levelling.
  9. PowerPoint 2010 Smart Art (умная графика). Списки и прочее легко трансформируется в непросто списки, а к примеру визуальные workflows или круговые диаграммы. Много пресетов, помогают оживить презентацию. 
  10. Word 2010 Navigation Pane (навигационная панель). Совмещает в себе поиск и навигацию по документу. Попробуйте, ненавязчиво (просто воспринимается в новом офисе как само собой разумеющееся), но удобно.
Честно сказать, не укладываюсь я в 10ку, хочется еще добавить, например, Calendar Preview в Outlook. Интересно то, что я сам бы и не вспомнил про это улучшение - заметил его в списке у Daniel Moth, хотя пользуюсь этим каждый день. К хорошему быстро привыкаешь.

И на последок не могу не упомянуть про Visio 2010 Auto Allign. Подозреваю, что присутствовало и в предыдущих версиях, но теперь легко доступно через Ribbon, потому и было мною замечено. Да, теперь эта опция заметна, но логика её работы от этого не стала понятнее. В общем, просто возьмите некую нормально организованную диаграмму, выделите все элементы и нажмите эту кнопку. У меня все квадратики, ромбики, кубики и т.п. разбежались по всему листу как тараканы - вообще без всякой логики :) Когда я случайно показал этот фокус ребятам на проекторе, некоторые долго не могли успокоится. Взрывает мозг. Да, над этой фичой придется еще поработать.

воскресенье, 30 мая 2010 г.

Экспедиция в Экспедицию

UPDATE: Меряемся с женой бложиками - альтернативное изложение событий, в комментариях голосуем, у кого лучше вышло :)

Без особого планирования собрались с женой отпраздновать её ДР походом в ресторан. Так как Славца спихнуть было не к кому, круг подозреваемых для выездного отдыха сузился до узкого круга мест с террасами, в итоге решили съездить в Экспедицию - слышал хорошие отзывы. Плюс, насколько я помню, там раньше был ресторан Советский, мы там Ёхелевскую свабьду отмечали, то есть территория знакомая.

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

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


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


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


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

Но не тут было - Ленино кольцо! Решив, что было просто снято где-то до ресторана, все же выдвинулись домой. Отсмотрели фотки:



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

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

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

Порядком расстроенные вернулись домой. И вот, разбирает Лена рюкзак, достает пакет с сушками и с характерным звуком кольцо падает на ковер. Самое смешное, что поначалу Лена подумала, что я её разыгрываю и отмахнулась от меня, мол это баранка выпала :)

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

среда, 26 мая 2010 г.

ConcurrentBag and BlockingCollection

В .NET 4.0 появился ряд новых классов для многопоточных приложений, в частности BlockingCollection и несколько Concurrent коллекций, к примеру, ConcurrentQueue и ConcurrentBag.

BlockingCollection удобно использовать для построения пайплайна обработки данных:
static void ProcessFile(string inputPath, string outputPath)
{
  var inputLines = new BlockingCollection<string>();
  var processedLines = new BlockingCollection<string>();

  // Stage #1
  var readLines = Task.Factory.StartNew(() =>
  {
    try
    {
      foreach (var line in File.ReadLines(inputPath)) inputLines.Add(line);
    }
    finally { inputLines.CompleteAdding(); }
  });

  // Stage #2
  var processLines = Task.Factory.StartNew(() =>
  {
    try
    {
      foreach(var line in inputLines.GetConsumingEnumerable()
.Select(line => Regex.Replace(line, @"\s+", ", ")))
      {
        processedLines.Add(line);
      }
    }
    finally { processedLines.CompleteAdding(); }
  });

  // Stage #3
  var writeLines = Task.Factory.StartNew(() =>
  {
    File.WriteAllLines(outputPath, processedLines.GetConsumingEnumerable());
  });

  Task.WaitAll(readLines, processLines, writeLines);
}

Однако, BlockingCollection - это обертка над интерфейсом IProducerConsumerCollection, коий реализуют выше указанные Concurrent коллекции. Так вот мы активно используем BlockingCollection. И недавно выяснилось, что по умолчанию BlockingCollection использует ConcurrentQueue, то есть поддерживает порядок обработки данных. Что зачастую нам не требуется. ConcurrentBag же не поддерживает порядок, но, как вы уже догадались, работает быстрее.

В целом же разница исчисляется во многих разах:

For mixed producer-consumer scenarios that do not require item ordering, ConcurrentBag(T) can be dramatically more efficient than ConcurrentStack(T) , ConcurrentQueue(T), and other synchronized collections.

Подробнее со статистикой здесь:
Thread-safe Collections in .NET Framework 4 and Their Performance Characteristics

воскресенье, 23 мая 2010 г.

Parallel Computing in MS

Слышали про новую фичу Excel 2010? Обработка таблиц на HPC Server 2008 R2 кластере. Это не шутка, фича позиционируется как серьезное улучшение в 2010 экселе. Это значит, что есть пользователи, у которых в Excel зашито столько логики, что им действительно имеет смысл просчитывать таблицы на кластере. А вы все со своими дотнетами бегаете.

Вообще, HPC Server 2008 R2 - это еще один шаг от Microsoft в стороную параллельных/распределенных вычислений. Он используется не только для обработки экселевских таблиц :) Краткий список возможностоей - собственно HPC кластер для распределенных вычислений (на основе MPI, насколько я понимаю), поддержка HPC Server в VS2010, возможность использовать в том числе и Linux машины в кластере, возможность использовать spare processing cycles компьютеров под Windows 7 в сети (grid computing), поддержка GPGPU. Тем, кто хочет знать больше, - сюда, первые несколько постов содержат дорожную карту по HPC и MPI.

Интересно еще будет почитать про усилия Microsoft в сфере GPGPU...

воскресенье, 16 мая 2010 г.

Йога по-дилетантски

Физкультпривет.

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

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

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

Для йоги практически ничего не нужно (кроме желания) и я с успехом (переменным) занимался ей в командировках.

Что мы обычно делаем на йоге?
  1. Упражнения (асаны, ага) на гибкость
  2. Статика и более активная нагрузка на мышцы
  3. Упражнения на равновесие
  4. Упражнения на расслабление и дыхание
На первых парах все вообще достаточно тяжело, потому что даже те асаны, которые вроде и не предполагают сильного напряжения, вызывают трудности - ничего не гнется и приходиться гнуть это дело с дополнительными усилиями.

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

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

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

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

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

Ну и несколько хинтов напоследок:
  1. Если асана дается легко, то скорее всего что-то делаем неправильно - обязательно что-то должно тянутся или напрягаться, надо поелозить, попробовать поменять положение
  2. В некоторых асанах тяжело дышать, к примеру, при скручивании, или "лодке" на животе, попробуйте дышать по-другому - грудью вместо живота или наоборот или и то и другое
  3. Спина должна быть прямой - тогда и ноги лучше тянуться и сами мышцы спины тоже; и да, лицам мужеского пола нужно уделять этому дополнительное внимание :) Смотрите в зеркало или ложите руки на поясницу, чтобы понять, как все запущено
  4. Чтобы меньше падать, советуют фиксировать взгляд на неподвижной точке или вертикальной прямой; не знаю, мне не помогает, я лузер? :)
В общем, вот мой способ поддерживать себя в относительной форме. А у вас есть другие способы держать себя в форме? Буду рад услышать, велком в каменты.