На ваш суд скорее статья-вопрос, статья-рассуждение и местами — недоумение. С одной стороны нам презентовали авторитетное мнение Лесли Лэмпорта "Programming Should Be More Than Coding", расставляющее программирование и кодирование в импровизированном табеле о рангах. С оппонирующей стороны — я, не обладающий статусом достаточным для споров с мэтром и легендарным ВУЗом, который он представляет… но отказать себе в таком удовольствии и риске я не могу. Надеюсь, более опытные товарищи поправят мои огрехи в рассуждениях.

Умом я понимаю, что кодирование в современном мире принято воспринимать как низшую ступень инженерной деятельности, которая на эволюционном графике скорее ближе к шимпанзе, чем к программисту. И, возможно, в этом кроется наша большая ошибка, поскольку код — он как ДНК. Всего четыре нуклеотида, а какая пёстрая биомасса в продуктовой линейке.

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

После ответов на 14 вопросов об индексах, которые вы стеснялись задать, у меня возникло гораздо больше комментариев, уточнений и исправлений. Скомпилировать из всего этого статью выглядело затеей с минимумом пользы. И это заставило меня призадумался, а почему вообще мы должны «стесняться задавать» подобные вопросы? Стыдно не знать? А есть ли способ разобраться, не вгоняя себя в краску? Есть. Причем он избавит от многочисленных неточностей, которыми изобилуют многие «ответы». Вы будете чувствовать буквально каждый байт вашей базы кончиками своих пальцев.

Для этого, я предлагаю «поднять капот» у SQL Server и окунуться в сладостный мир шестнадцатеричных дампов. Может статься, что внутри все гораздо проще, чем вам казалось.

За более чем десять лет моих активных поисков и применения GTD/PM-методик в своей, без малого, десятилетней практике фрилансера и предпринимателя, до меня наконец дошло — серебряной пули нет. Многие знали об этом всегда, мне же понадобились годы. Когда для тебя одновременное количество проектов измеряется не одним десятком. Когда ты прокрастинатор настолько, что даже прокрастинируя этой статьей от работы умудряешься прокрастинировать прокрастинацию чтением писем Лейбница и готов прокрастинировать рекурсивно. Когда ты перфекционист шестого разряда и программист-романтик, то до последнего надеешься, что есть универсальное лекарство. Но его нет…

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

Предупрежу заранее, что я совершенно не считаю себя экспертом HTML/CSS/JS. Но, как архитектору, мне всегда была интересна организация и систематизация кода в самых разных его проявлениях, в том числе и представленных в виде CSS. Особенно сильно этот интерес был подогрет БЭМом, при первом знакомстве с которым подсознание отреагировало когнитивным дискомфортом. А поскольку БЭМ-стиль в проектах у меня стал появляться все чаще, я почувствовал острую необходимость осмыслить, наконец, свое отношение к организации стилей. Таким образом и появился данный топик-размышление, топик-дискуссия. Я понимаю, что взялся за пограничную задачу, поскольку далеко не всем верстальщикам знакомы тонкости объектно-ориентированного дизайна, а большинство архитекторов не написали ни одного CSS-стиля. И, как результат, мне пришлось неуклюже балансировать, чтобы было понятно всем. Но 'этот риск еще больше подогрел мой интерес к теме :)

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

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

Что до моего опыта, то свой первый заказ я выполнил на бирже поздней весной 2005, а уже зимой 2006 ушел с работы и никогда туда больше не возвращался. Мне посчастливилось всегда держать на очень высоком уровне конвертацию заявки в заказ. Как исполнитель я последний раз выходил на биржу во время кризиса 2008-2009, быстро восстановился и с того же 2009 использую их только как заказчик. Вам решать, насколько мои советы будут полезны. А желающих приглашаю под кат и за парты.

Сейчас, пожалуй, только староверы в глубокой тайге не знают, что такое фриланс. Причем те из них, кто еще не отдал добычу еды на аутсорсинг. И вместе с тем, как набирает обороты движение свободных разработчиков, рождается множество забавных, а, порою, опасных религий, с этим связанных. Про одну из них мне и хотелось бы поведать. Мотиватором для этого послужила данная статья на Хабре — habrahabr.ru/blogs/pm/95548.
NB: Статья, разумеется, шутливая и позже была перенесена в ХабраЮмор, но нас ведь не проведешь и мы прекрасно понимаем, что юмор используется для того, чтобы на рынок умов могло проникнуть то, что не пустят через парадный вход. Как говориться, политический анекдот — это тоже шутка. В общем обратите внимание, что рассматривается не упомянутая статья, а религия, частным порождением которой эта статья и является..

Итак, есть такая партиярелигия: заказчик — Враг, потому что он Виноват Во Всем. Именно так, с большой буквы «В». Иногда он Гад, Мерзавец и Подонок, но в итоге он все равно Виноват. Сорваны сроки — виноват заказчик, проснулись с больной головой — виноват заказчик, молоко убежало — виноват заказчик. Любое письмо от заказчика вызывает нервный тик, звонок — приступы бешенства, а уж встреча — это ринг микс-файтинга и DeathTrack'а без каких-либо правил.

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

Когда я в очередной раз использовал LogParser, то чтобы проникнуться и чужим опытом, ввел его название в поиск на Хабре. Как результат — сообщение «Удивительно, но поиск не дал результатов». Вот уж воистину удивительно, когда столь интересный инструмент обойден вниманием. Пришла пора восполнить этот пробел. Итак, встречайте LogParser. Маленькая, но чертовски полезная утилита для любителей SQL.

Из названия инструмента, казалось бы, очень непросто понять, что он делает в разделе SQL. А правда заключается в том, что он такой же LogParser, как и ChartGenerator. В то смысле, что он справляется с обоими задачами с одинаковыми успехом. В целом я бы его охарактеризовал как SQL-процессор гетерогенных данных. Концепция работы в общем такова, что он берет данные из некоторого формата и преобразует их в табличный вид (собственно говоря, только на этом этапе и выполняется иногда парсинг). Затем, посредством выполнения над этими табличными данными некоторого SQL-запроса формирует таблицу с результатом и сохраняет ее опять же в некотором формате. Если коротко, то цепочка выглядит как подготовка входных данных->SQL-процессинг->генерация выходных данных.

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

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