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

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

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

Из знакомых мне айтишников очень немногие стараются правильно произносить английские слова. Конечно, привычнее произносить C++ как «си-плюс-плюс», а не «си-плас-плас» или «опен-бэ-эс-дэ», а не «оупэн-би-эс-ди».
Но когда «echo $value;» читают как «ечо валуй» — это уже не смешно. Другой человек вас может просто не понять, особенно иностранец.

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

♫ — прослушать произношение в словаре
► — прослушать произношение на youtube

Начнем с названий:

ABBYY	аби		►
Adobe	эдоуби	[əˈdəʋbɪ]	♫
Apache	эпэчи	[əˈpætʃiː]	►	от «a-patchy»
Asus	офиц. э́сус амер. э́йсус		►
BenQ	бенкью		♫
Cisco	сискоу	[ˈsɪskoʊ]	♫
EBay	ибэй		♫
Eee PC	и писи		►
Ethernet	изэрнэт	[ˈiθərˌnɛt]	♫
Itanium	айтэйниум	[aɪˈteɪniəm]	►
Juniper	джу́нэпэр	[ˈdʒunəpər]	♫
LaTeX	лэйтех лэйтек латех латек	[ˈleɪtɛk] ['leɪtɛx] [ˈlɑːtɛx] [ˈlɑːtɛk]
Linux	офиц. линэкс вар. линукс	[ˈlɪnəks] [ˈlɪnʊks]	►
Mac OS X	мэк оу-эс тэн		►
MySQL	офиц. май-эс-кью-эл вар. май-сиквел		►	как «My Ess Que Ell», см. оф. сайт
nginx	энджин-икс		►	(от engine-x)
PuTTY	пати	[ˈpʌtɪ]		см. оф. сайт
Qt	кьют	[kyut]		см.
TeX	тех тек	[ˈtɛx] [tɛk]		не «текс»
XBox 360	экс-бокс фри сискти		♫
Xen	зен	[ˈzɛn]	♫
Xeon	зион		♫
Xerox	зирокс	[ˈzɪərɒks]	♫
Xilinx	зайлинкс	[ˌzaɪliːŋks]	►
ZyXel	рус. зайксел амер. зайзел		►	см.

Аббревиатуры:

GNU	гну		►	вар. гню
GWT	гвит	[ˈɡwɪt]
ICANN	айкэн		►
IEEE	ай-трипл-и		►	как «I triple E»
ISO	айсо		►
PNG	пинг	[ˈpɪŋ]	♫	как «ping», см. спецификацию
PXE	пикси	[ˈpɪksi]	►
RUP	рап		►
SCSI	скази	['skʌzi]	♫
SOAP	соуп	[soʊp]	►
SQL	эс-кью-эл	[ˈɛsˈkjuˈɛl]		неофиц. «сикуел»
SWF	свиф	[ˈswɪf]		см. спецификацию
WYSIWYG	визивиг	[ˈwɪziˌwɪg]	♫
XAML	зэмл	[ˈzæməl]	►
XUL	зул	[ˈzuːl]
Yii	длинное «и»	[ji:]	►

Обычно аббревиатуры произносятся по правилам английского языка: API — эй-пи-ай, PCMCIA — пи-си-эм-си-ай-эй, OpenBSD — оупен-би-эс-ди и т.д.

Преамбула

Пару лет назад я и мои сотрудники столкнулись с проблемой сопровождения большого количества аналогичных БД на удаленных филиалах. Удалены они иногда на тысячи километров, а объемы исчислялись гигабайтами – что не позволяло использовать какое-либо зеркалирование серверов. Осложнялась ситуация мелкими отличиями, т.е. 95% бизнес-логики филиалов совпадало, но было ещё 5%, которые сильно мешали и ни о какой автоматической обработке группы филиалов не было и речи.

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

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

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

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

Многие, думаю, создавали, ну или хотя бы пытались создать какую-нибудь игрушку. И очень часто инди-разработчики выбирают жанр аркады, скролл-шутера, платфомера или что-то в этом роде. Здесь я хочу рассказать о создании простейшего редактора уровней к такой аркаде.
В качестве платформы я выбрал C# + XNA 4.0, и WinForms для пользовательских элементов в редакторе уровней.
Создаем в VisualStudio проект Windows Game и вперед!

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



Silverlight имеет отличную поддержку анимации. Дергаешь свойства в Blend, ставишь ключики. И все работает, контролы реагируют на действия пользователя. Программно, через Storyboard, анимация изменения свойства из состояния А в состояние Б, без происшествий по середине, тоже делается легко. Но когда дело доходит до сложной анимации (физика, расчет столкновений, динамическое изменение анимационной кривой), то реализация анимации через Storyboard значительно усложняет код или вообще не возможна.

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

Именованные шаблоны

Многие «проблемы» XSLT связаны с тем, что мы слишком часто пытаемся писать на нём в процедурном стиле. Мы постоянно пытаемся сделать из него Smarty, но упираемся в один простой факт — XSLT является декларативным языком, как бы необычно это для нас не выглядело.
Например, мы пытаемся использовать именованные шаблоны, воспринимая их как процедуры, выводящие данные в определённом формате:

<xsl:template name="CreateItemLink">
    <xsl:param name="item"/>
    <a href="/item/?id={$item/id}">
        <xsl:value-of select="$item/name"/>
    </a><br/>
</xsl:template>

* This source code was highlighted with Source Code Highlighter.

Наверное, многие программисты именно так написали свой первый шаблон. И он неплохо решает свою задачу. Декларативный XSLT предлагает немного другой подход:

<xsl:template match="item">
    <a href="/item/?id={id}">
        <xsl:value-of select="name"/>
    </a><br/>
</xsl:template>

* This source code was highlighted with Source Code Highlighter.

Разница совсем не велика. Дело вкуса и стиля программирования. Давайте посмотрим, как шаблон будет использоваться в дальнейшем.

В топике рассматривается еще одна простая система версионирования структуры БД, а также ИМХО, почему нам не подходят другие.

В последние годы тема юнит-тестов, регрессивного тестирования, continuous integration, TDD, BDD, etc становится все популярней и все больше разработчиков начинают активно применять данные техники в своих проектах. При этом отдельным вопросом встает проблема автоматического тестирования пользовательского интерфейса в десктопных приложениях. В этой статье я постараюсь рассмотреть уже существующие решения, а так же привести вариант своего велосипеда написания тестов для UI на .net.

Большинство программистов, которых нелегкая судьба свела с платформной.Net знают о существовании значимых типов (value types) и ссылочных типов (reference types). И довольно многие из них прекрасно знают, что помимо названия, эти типы имеют и другие различия, такие как расположение объектов оных типов в памяти, а также в семантике.

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

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

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

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.

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

Разберем, какой оседлать собственное подразделение разработки и добиться успеха.

Это интервью Криса Уонстрота, CEO и сооснователя Github. Данное интервью — часть серии “Bootstrapped, Profitable, & Proud” о компаниях с выручкой более миллиона долларов, обошедшихся без венчурного финансирования на старте и приносящих доход.

Wireshark — одна из незаменимых утилит для «прослушки» сети, при работе с сетевыми протоколами. В состав программы уже входит некое количество диссекторов¹, которое помогают детально рассмотреть пакеты базовых протоколов. Но при работе над проприетарным протоколом компании Nortel я столкнулся с отсутсвием подходящего диссектора. А нужен он был как воздух. Выход был очевиден — написать свой. Что я и сделал.
Таким образом, имея небольшой опыт написания плагина «анатома» под Wireshark, я решил поделиться знаниями и опытом с сообществом. Ну и для себя записать, на случай, если в будущем понадобится.

Диссекция — лат. dissectio, от dissecare, рассекать

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

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

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

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

Здравствуйте!
Я хотел бы рассказать о проектах Migrator.Net и ECM7.Migrator.

Migrator.Net — это механизм контроля версий базы данных, похожий на Migrations в Ruby on Rails. Migrator позволяет автоматизировать выполнение операций изменения БД и автоматически ведет учет версий.

Migrator написан на C# и будет удобен, в первую очередь, при использовании в проектах под.NET.

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

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

Понятно, что напрашивающийся (и правильный) ответ — «Потому что код приходится не только писать, а и читать». Едва ли этот ответ стоит целого поста, но автор им не ограничивается.

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

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

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