Из знакомых мне айтишников очень немногие стараются правильно произносить английские слова. Конечно, привычнее произносить 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 — оупен-би-эс-ди и т.д.

Если вы пользуетесь браузером firefox 4 и любите эффект Windows Aero, то эта небольшая заметка для вас!

Недавно я, программист на C#, нашёл в своей панели управления такую фичу, как Распознование речи. Сменил язык на английский, включил, и всю ночь разговаривал с компом. На утро решил написать калькулятор, разумеется говорящий. Потыкав в .Net'овские библиотеки нашёл System.Speech. Звучало многообещающе.

Изначально автор хотел назвать эту статью следующим образом: «О синглтонах, статических конструкторах и инициализаторах статических полей, о флаге beforeFieldInit и о его влиянии на deadlock-и статических конструкторов при старте сервисов релизных билдов в .Net Framework 3.5», однако в связи с тем, что многострочные названия по неведомой автору причине так и не прижились в современном компьютерном сообществе, он (автор) решил сократить это название, чудовищным образом исказив его исходный смысл.

-------------------------

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

Плагин Chosen создан для оформления красивых и удобных выпадающих списков с помощью jQuery и Prototype. Для установки плагина достаточно просто скачать файлы и прописать одну строчку:

$(".chzn-select").chosen()

(версия для jQuery)

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

Поскольку Chosen заменяет стандартный элемент HTML, то не нужно беспокоиться, как он работает с браузерами без поддержки JavaScript. Также не нужно ничего менять в бэкенде: формы сабмиттятся как обычно, изменения только в пользовательском интерфейсе.

Некоторые форки:
Chosen для MooTools
Модуль Chosen для Drupal 7

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

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

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

Методика общеизвестна и называется она — планирование.

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

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

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

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

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

В рамках пятничного фана мы решили рассказать вам о нашем поисковом исследовании ко дню всех влюбленных. Нам стало интересно, что же наши пользователи думают о любви. Мы вооружились методикой анализа долгосрочных логов, о которой мы рассказывали месяц назад и выяснили, например, что пикап приводит к свадьбе на 30% быстрее, чем классические знакомства. А еще нам удалось посчитать, сколько людей женятся «по обстоятельствам», а сколько – по любви. Или какие шансы, что ваш курортный роман закончится серьезными отношениями. Или стоит ли идти с девушкой в театр сразу после знакомства.

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

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

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

UPD: Хабраэффект в действии. Ругаемся с техподдержкой за несоответсвие обещаной максимальной нагрузки действительности.
UPD2: Хостер исправился. Сервер в полном здравии.

Moles – это легковесный тул от MS Research, который умеет автоматически генерировать заглушки для интерфейсов и виртуальных методов, а также для sealed классов, невиртуальных и статических методов (!), путем генерации кода, которому позднее можно будет подсунуть нужный делегат, вызываемый вместо определенного метода. Первый тип заглушек называется стабы (stubs), а второй – молы (moles). Именно эту штуку я использовал для тестирования асинхронных операций, о которых я рассказывал ранее, но давайте обо всем по порядку.

Stubs

Давайте рассмотрим такой пример. Предположим, что мы понимаем ценность модульных тестов, а также таких принципов, как Dependency Inversion, и других безумно полезных принципов и паттернов (может быть всех остальных принципов S.O.L.I.D., а возможно даже и F.I.R.S.T.). И дело даже не в том, что мы фанаты тестов или дядюшки Боба, а просто потому, что мы знаем, что высокая связность – это плохо. Поэтому мы стараемся в разумных пределах уменьшить зависимости путем выделения интерфейсов с последующим «инжектом» их в конструкторы классов или в методы, которым эти интерфейсы необходимы для выполнения своих задач.

До недавнего времени мне ужасно не нравилось работать с XML файлами, я старался избегать этого где только можно, по просту заменяя их стандартными конфигурационными файлами приложения. Но где нужно было использовать обмен данными – от XML’а было не уйти. Приходилось создавать большой объем кода для того чтобы сконвертировать либо прочитать небольшой объем информации. Да, таков уж XML Document Object Model (DOM) API.

Вступление

В этой статье я хочу поделиться с уважаемым хабраобществом своим опытом анализа и модификации обфусцированной .NET сборки на примере COMET-библиотеки PokeIn.



Несколько дней назад я заинтересовался COMET решениями для ASP.NET и нашел несколько интересных библиотек, среди которых некогда бывшая бесплатной PokeIn. Очевидно она пользовалась некоторой популярностью, так как авторы перевели ее из разряда open source в платную. На сайте бибилиотеки есть возможность скачать бесплатную версию с некоторыми ограничениями, среди которых, пожалуй, самое важное — это ограничение в 10 одновременных соединений. С ним мы и будем бороться.

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

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

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

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

Или с деньгами.

От переводчика

Недавно в проекте, где я работаю, мы столкнулись с проблемой утечки памяти. Прочитав множество статей — от рассказов по управлению памятью в .NET до практических рекомендаций по правильному освобождению ресурсов, я в том числе наткнулся на статью, в которой рассказывается, как корректно использовать события. Ее перевод я и хочу вам представить.
Это топик из песочницы, с которым я попал сюда на Хабр.

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

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

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

Что вы думаете по поводу метода прогрессивного джипега?