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


<sup>Распределительная


Стойки</sup>

Ниже рассказ про устройство ЦОД в картинках и объяснения, где, что и как работает.

Осторожно, трафик.

Приятного времени суток!

Сколько человек хочет заняться разработкой под Android, но в силу определенных обстоятельств все никак не может начать (у кого-то нет времени, кому-то скучно просто прорешивать примеры, лень, неопределенность)? Сколько человек добавляет каждую, кажущуюся интересной и полезной, статью на хабре в избранное и забивает? До конкурса ВКонтакте на разработку мессенджера под Android, я был среди числа вышеописанных пользователей. Но в один роковой момент все изменилось…

Я собрал здесь некоторые не очень очевидные факты о заглавных и строчных буквах, с которыми может столкнуться программист в работе. Многие из вас переводили строки во «все заглавные» (uppercase), «все строчные» (lowercase), «первую заглавную, а остальные строчные» (titlecase). Ещё более популярна операция сравнения без учёта регистра. В мировом масштабе такие операции могут быть весьма нетривиальны. Пост построен в виде «сборника заблуждений» с контрпримерами.

1. Если я переведу строку в uppercase или lowercase, число Unicode-символов не изменится.

Нет. В тексте могут попасться строчные лигатуры, которым не соответствует один символ в верхнем регистре. Например, при переводе в uppercase: fi (U+FB00) -> FI (U+0046, U+0049)

2. Лигатуры — изврат, ими никто не пользуется. Если их не учитывать, то я прав.

Нет. Некоторым буквам с диакритикой нет точного соответствия в другом регистре, поэтому приходится использовать комбинированный символ. Скажем, в языке африкаанс есть буква ʼn (U+0149). В верхнем регистре ей соответствует комбинация из двух символов: (U+02BC, U+004E). Если вам попадётся транслитерация арабского текста, вы можете столкнуться с (U+1E96), которой в верхнем регистре также нет односимвольного соответствия, поэтому придётся заменять на (U+0048, U+0331). В ваханском языке есть буква (U+01F0) с аналогичной проблемой. Вы можете возразить, что это экзотика, однако на африкаанс в википедии 23000 статей.

3. Ну хорошо, но давайте считать комбинированный символ (с участием modifying или combining code points) одним символом. Тогда длина всё же сохранится.

Нет. Есть, например, в немецком языке буква «эсцет» ß (U+00DF). При переводе в верхний регистр, она превращается в два символа SS (U+0053, U+0053).

Не так давно я проводил опрос «Какие материалы о Java вас интересуют на русском языке?» среди посетителей Хабра. Вторым этапом моего исследования будет обзор существующих русско-язычных ресурсов.

Книги

За 2009 на Ozon.ru можно найти 8 книг по Java (всего за последние 3 года их вышло 22 — примерно по 7 в год, на books.ru набор примерно такой же, так что наша выборка довольно репрезентативна). Посмотрим, что это за книги?

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

Но очень немногие знают, что все эти проблемы можно просто и быстро устранить.



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

Паттерн Singleton появился, пожалуй, как только появились статичные объекты. В Smalltalk-80 так был сделан ChangeSet, а чуть в самых разных библиотеках стали появляться сессии, статусы и тому подобные объекты, которых объединяло одно — они должны были быть одни-единственные на всю программу.

В 1994 году вышла известная книга «Паттерны проектирования», представив публике, среди 22-х прочих, и нашего героя, которого теперь назвали Singleton. Была там и его реализация на C++, вот такая:

Небольшая иллюстрация того, как на языке C# реализовать монаду Maybe и зачем это вообще нужно. Смотреть видео рекоммендуется в разрешении 720p.



Сопутствующую статью можно найти тут (англ. яз.). Комментарии приветствуются!

Преамбула

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

И вот, вы, принимая пост, знакомитесь с командой: вроде бы есть потенциально сильные разработчики с опытом, есть несколько подающих надежды юниоров. Но что-то сразу бросается в глаза. И чем дольше вы вглядываетесь в эти занятые работой умные лица, тем более понимаете, что перед вами не команда, а «группа разработчиков». А то, что они пишут… Вы и не думали, что программисты могут так писать код. Вы смотрите на пластилиновую архитектуру, на классы в 6000 строк кода, на методы, занимающие десять страниц машинописного текста, на кейсы, ветвящиеся как головы Лернейской гидры. И у вас появляется невольный вопрос: а можно ли что-то с такой командой сделать вообще?

И мой ответ — можно. И нужно!

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

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

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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

Ниже — перевод статьи о проблеме работы с udp в сетевых приложениях. Переводчик позволил себе сменить примеры: в исходном тексте другие сетевые адреса и код на ruby. В переводе использован простенький скрипт на перле. Суть проблемы и решение от этого не меняются.
Кроме того, местами добавлены мои комментарии (в скобках, выделены курсивом).
Картинка для привлечения внимания взята из текста замечательной книги «learnyousomeerlang.com»

Тяжкая работа лёгких протоколов

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

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

Будьте осторожны в своих желаниях — они сбываются!



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

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

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

Стала доступна запись моего доклада с РИТ-2012, на котором по просьбе Олега Бунина я постарался раскрыть тему создания условий для творческой работы в группе:

• Что убивает мотивацию творчества?
• Как создать и поддерживать состояние потока?

В конце я проиллюстрировал сказанное примерами из открытого проекта UsabilityLab для стартапа SpinPlaces.

После длительного перерыва мы вновь публикуем результаты нашего исследования рынка труда в IT индустрии. Напомним, что в предыдущих наших постах мы рассказали о зарплатах «Мобильных» разработчиков, Дизайнеров, Руководителей проектов по разработке ПО, Системных администраторов windows и даже описали из чего состоит социальный пакет в IT компании.



Это пост мы решили посвятить отцам интернета — Web программистам:

• HTML верстальщик, Web мастер
• Программист PHP
• Старший (ведущий) программист PHP
• Программист ASP.NET
• Программист JavaScript
• Программист (старший, ведущий) Perl
• Программист (старший, ведущий) Python
• Программист (старший, ведущий) Ruby
• Программист Flash/Flex

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

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


Американец. Прожорливый, здоровенный, старый. Но тут уж рад и такому, машина не моя.

Есть у такого способа путешествовать несколько преимуществ и особенностей.

Помню оживленное обсуждение на хабре Google AI Challenge, а заметок по подобному соревнованию от Microsoft не нашел. И раз уж мне посчастливилось этот конкурс выиграть, наверное мне о нем и рассказывать.

Как и в случае с Google AI Challenge сама корпорация Microsoft непосредственного участия в организации не принимала, а разработкой занималась шведская фирма Giraff.

Cloudball — упрощенная версия футбола. Играют две команды по 6 игроков. Игроки могут «вести» мяч, бить его в любую сторону и делать подкаты. Мяч упруго отбивается от бортиков. У каждого игрока есть свое амплуа (вратарь, левый защитник, правый защитник и т.д.), но придерживаться их не обязательно.

Вот пример матча:

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

Формулировка задачи

Если юнит-тесты работают с базой и меняют её — что сделать, чтобы результаты прогона были повторимы?
Ответ — чистить базу перед тестом. Но хочется иметь какой то набор данных в базе, чтобы каждый раз его туда не записывать из тестов (будем называть такие данные “базовым набором”). Таким образом мы упростим сами тесты и их setup во много раз.