Меня зовут Евгений и я жаворонок. Сегодня проснулся в 6 утра, открыл окно в кухне, заварил кофейку и решил глянуть, «что нового». Мне написал мой бывший коллега «Андроид»… Точнее «Андроид-разработчик» Максим, но так звучит фантастичнее…



Он спросил:

– Женя, привет. (wave) Вопрос к тебе, как мега лайв хакеру. Сколько времени нужно спать, что бы мозг отдохнул и можно было плодотворно работать? Умные будильники сильно помогают?

Я ответил, а потом подумал, ведь и парочке сотен человек с Хабра тоже пригодится хоть один пунктик из вычитанных мною ранее советов, ведь «так как никто не слушает, приходится повторять»:

Здравствуйте, дорогие читатели!

Не так давно мы занялись проработкой книги "Writing High-Performance .NET code", которая до сих пор не переведена на русский язык, хотя ей и скоро год.



Нас, конечно, не удивило, что такую книгу уже растаскивают на цитаты, однако выяснилось, что уважаемый автор Бен Уотсон даже выложил на сайте «Codeproject» целую статью, написанную по мотивам одной из глав. К сожалению, объем этого материала слишком велик для хабропубликации, однако мы решили все-таки перевести первую часть статьи, чтобы вы могли оценить материал книги. Приглашаем к прочтению и к участию в опросе. Кроме того, если все-таки целесообразно перевести и вторую часть — пишите в комментариях, постараемся учесть ваши пожелания.

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

Как ни прискорбно, придется признать – мы сами закладываем себе мины. В первой части я подробно разобрал основные риски в разработке ПО и описал технологические и методологические способы ослабления этих рисков. За прошедший год я получил множество комментариев, основной смысл которых сводился к следующему: «все круто, но с чего начать и как все это будет выглядеть в реальном мире». Действительно, первый текст носит скорее теоретический характер и представляет собой каталог ссылок. В этой статье я постараюсь привести как можно больше примеров.

Как dba и консультант по оптимизации производительности SQL Server в Ambient Consulting, я часто сталкиваюсь с необходимостью анализа узких мест производительности на экземплярах SQL Server, которые вижу первый раз в жизни. Это может быть сложной задачей. Как правило, у большинства компаний нет документации по их базам данных. А если есть, то она устарела, или же её поиск занимает несколько дней.

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

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

Как и с любыми скриптами, сначала проверьте их в тестовом окружении, прежде чем запускать в продакшене. Я бы рекомендовал вам погонять их на тестовых базах MS, таких как AdventureWorks или pubs.

Ну, хватит слов, давайте я покажу скрипты!

Многие из читателей Хабрахабра хотели бы открыть свой бизнес и перестать работать на «дядю». Но как это сделать? Какие опасности это таит? Ответы на эти и другие вопросы можно найти в замечательной книге «Бизнес для программистов. Как начать свое дело».

Ее написал Эрик Синк – бывший разработчик Spyglass, основатель и руководитель SourceGear, одного из основных поставщиков ПО в области контроля версий, а также колумнист MSDN.

Основная тема книги – это как стартовать и развить свою маленькую компанию независимого поставщика ПО. Эрик разбивает эту задачу на несколько традиционных компонентов: как стать предпринимателем, люди, маркетинг, продажи. Но каждый из них рассматривает через призму восприятия программиста. Например, приводит следующий совет по поиску идей:
Idea FindGoodProductIdea ()
{
ArrayList candidateList = BrainstormLotsOfIdeas();
return ChooseTheBestIdea(candidateList);
}

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

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

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

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

Статья для соискателей.

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

В продолжение темы: раз, два, три, четыре.

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

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