Да, скорее всего, мы уже не увидим новые модели телефонов/смартфонов от Nokia, поскольку свой профильный бизнес компания продала корпорации Microsoft. Тем не менее, за долгие годы лидерства финский производитель создал немало интересных устройств, которые можно считать «иконами» всего сектора телефонов/смартфонов. Были решения удачные, были не очень, но все это и способствовало развитию рынка смартфонов/телефонов. Под катом много фотографий, так что будьте осторожны, если у вас платный трафик.

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

Под катом — 5 первых названий с описаниями от меня, для затравки.
update 1. В комментариях ещё 10+ названий.

Всем привет! Лето завершилось, но отпускной сезон ещё не закончен, впереди «бархатный» сентябрь. И сегодня нам хотелось бы поднять такую животрепещущую тему, как послеотпускная депрессия. Конечно, в строгом, клиническом смысле это вовсе не депрессия, а хандра. Но всё равно очень неприятное состояние, когда возникает ощущение, что всё удовольствие от отпуска пошло насмарку. Ты вдруг снова «вспоминаешь», как тебя раздражают коллеги, особенно отчётливо замечаешь недостатки офиса и рабочего места, тебя напрягают любые задания, и как ты вообще тут работаешь столько времени? С тоской вспоминается только что закончившийся отдых, и уже такое чувство, что это было не с тобой. Или очень давно. В общем, работать совершенно не получается.

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

Издательство Питер решило представить недавно выведшую книгу от автора бестселлера «Карьера программиста», которая поможет вам наилучшим образом подготовиться к собеседованию при приеме на работу менеджером проекта в крупную IT-организацию или перспективный стартап. Основную часть книги составляют ответы на технические вопросы и задания, которые обычно получают соискатели на собеседовании в таких компаниях, как Google, Microsoft, Apple, Amazon и других. Рассмотрены типичные ошибки, которые допускают кандидаты, а также эффективные методики поlготовки к собеседованию.

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



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

Самым показательным примером последнего времени является, несомненно, Collecting Card Game – Hearthstone. Можно сказать, что до её выхода не было действительно массовых популярных карточных игр на PC. Да, есть Magic the Gathering и другие попытки занять эту нишу, но их попытки оказались в разы менее успешными, чем у Blizzard.

Что же сделало эту игру такой популярной? Так называемая схема «Easy to learn, hard to master» (наиболее правильный перевод – легко начать играть, сложно достичь высот). Т.е. в первую очередь, любой игрок может установить себе эту игру и его встретит красочный туториал, с интересными персонажами (многим знакомые по вселенной Warcraft), озвучкой и сценариями. После прохождения туториала игра по большей части отпускает игрока в свободное плавание, но этого достаточно чтобы завладеть сердцами игроков.

Друзья, спасибо за позитивные комментарии после нашего последнего видео «Как навести порядок снизу: за 90 дней от бардака к проектному офису»! Мы решили продолжить разговор с нашим экспертом по управлению проектами Иваном Селиховкиным (selikhovkin). И затронули такую холиварную тему, как знания и навыки, которыми должен обладать хороший ПМ.

Я отчетливо помню, как после пары лет работы в Intel у меня возникло четкое убеждение, что я знаю, как надо. Убеждение было вскоре многократно пересмотрено после работы с аутсорсинговыми компаниями (о, сколько там многообразия!), стартапами, ИТ-отделами не-ИТ компаний и т.д.

Расширение контекста (не важно, инженера или менеджера) – чертовски важная штуковина. Поэтому помимо набивания собственных шишек, мне всегда было интересно разговаривать с людьми, имеющими разносторонний опыт и широкий кругозор. selikhovkin – безусловно, один из них. Как человек системный, Иван набросал еще и интеллект-карту «Знания и навыки хорошего менеджера проекта», по которой и вел рассказ.

В одном из комментариев к посту автора, многоуважаемого пользователями Habr, я ответил, что основной причиной неудач проекта является не использование методологий «через %опу» или «как получится», а наличие только операционного управления в рамках проекта. Проектный подход у таких менеджеров заканчивается уже после составления сметы проекта.
В этом посте проведу более детальное сравнение операционного подхода с проектным.

Уровни управления проектом

Так получилось, что тесть и теща у меня доктора педагогических наук. Что приводит к тому, что волей-неволей начинаешь постигать различные полезные методики :)

Однажды, после какого-то ученого совета за виски чаем на кухне тесть говорит: Саш, а вот как ты считаешь, почему люди чего-то не делают?

Честно сказать, вопрос поставил меня в тупик. Я начал фантазировать: ну, обстоятельства мешают, черты характера, недостаток опыта…

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

• Почему менеджеров проектов надо пересаживать в отдельное здание
• Что делать, когда ваш заказчик не пользуется вашей системой отчетов
• Как раскачать low-performer’а

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

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

Официальный учебный курс «Введение в Linux» от Linux Foundation, который ранее стоил 2400 долларов, будет доступен бесплатно на платформе онлайн-обучения EdX. Записаться на курс можно уже сейчас. Платформа массового онлайн-обучения EdX была создана Массачусетским технологическим институтом совместно с Гарвардским университетом. На ней представлены уже больше 30 университетов. Теперь и Linux Foundation станет официальным партнёром EdX. Курсу присвоен код LFS101x. Он рассчитан на 40 — 60 часов обучения. Занятия начнутся в 3-м квартале 2014 года.

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

• Это IT-сервисы на вашей территории.
• При этом это сервисы, эволюционно добравшиеся до «облака», то есть сервисы распределенных вычислений.

Зачем это нужно? Причин на практике четыре:

1. Экономия на железе: «облако» позволяет крутить сотни проектов на одном наборе железа, когда как без такой инфраструктуры железа потребовалось бы минимум втрое больше. Ну и в будущем нет проблем с заменой железа.
2. Экономия на лицензиях: так получилось, что лицензионные условия часто обозначаются не на пользователя, а на машину. А когда машина физически одна, а пользователей — 5-6, это серьезно дешевле.
3. Требования к скорости развертывания инфраструктуры. Из правильного настроенного частного «облака» можно легко запустить новый офис в регионе, чуть ли не за несколько минут. Или масштабироваться без боли.
4. Волшебный 152-ФЗ и ряд других нормативов: пока не всегда можно отдавать свои ПД на обработку кому-то третьему, требуется разворачивать фермы у себя.

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

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

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

Хочу просто поделиться недавно найденным сервисом для работы с регулярными выражениями. Да, это еще один сервис. Но у него есть особенность — он позволяет не только составлять регулярные выражения, но и помогает разбирать уже написанные — эдакий regexp-декомпилятор.
Сервис называется Regex101.

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

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

Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».

В блоге у Алексея Кривицкого (кстати, очень рекомендую) есть любопытная заметка о том, является ли Scrum инструментом или чем-то большим.

Леша считает, что Scrum — это не инструмент. Scrum для Алексея – это совокупность ценностей, принципов, хороших практик разработки, современных подходов лидерства и собственно, самого каркаса скрам.

Так что такое Scrum – инструмент или нечто большее?

Думаю у каждого грамотного системного администратора есть коллекция ссылок на полезные в работе ресурсы. Я имею в виду различные сайты и блоги, на которых выкладываются полезные с точки зрения системного администратора посты.
Предлагаю ими поделиться в формате ссылка — описание.
Пример: habrahabr.ru — разнообразные статьи и новости на IT и около-IT тематику.

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

P.S. Хабр, опеннет и лор можно не упоминать. Можно выкладывать ссылки на конкретные статьи, если считаете их очень полезными.

Начну с себя (т.к я администрирую linux, то и ссылки у меня в основном соответствующие):

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

Итак, я просил ответить на вопрос какие книги из статьи вы читали?

Результаты опроса:

Название книги	Количество голосов	Процент
Том ДеМарко. Deadline. Роман об управлении проектами	247	54%
Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы	174	38%
Джоэл Спольски. Джоэл о программировании	165	36%
Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды	148	32%
Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков	108	24%
Джеффри Янг и Уильям Саймон. iКона. Стив Джобс	94	21%
Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения	70	15%
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд	51	11%
Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса	48	11%
Патрик Ленсиони. Смерть от совещаний	21	5%
Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве	19	4%
Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве	16	4%
Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных)	11	2%

А теперь еще один бонус — список книг по заданной тематике, которые прислали нам читатели:

• Что такое домен коллизий?
• Сколько пар используется для Ethernet и почему?
• По каким парам идет прием, а по каким передача?
• Что ограничивает длину сегмента сети?
• Почему кадр не может быть меньше определенной величины?

Если не знаешь ответов на эти вопросы, а читать стандарты и серьезную литературу по теме лень — прошу под кат.

Есть два основных документа, которые чаще всего упоминаются при обсуждении стандартов центров обработки данных: это стандарт TIA 942 и классификация по уровням от Uptime Institute. Оба этих документа регламентируют уровни (Tier), что часто приводит к путанице: например, Tier III по TIA 942 и Tier III по Uptime Institute — это две большие разницы.

TIA vs Uptime

TIA 942 — Telecommunications Industry Association — Telecommunications Infrastructure Standard for Data Centers:

• Этот стандарт разработан ассоциацией телекоммуникационной промышленности США и, в первую очередь, касается вопросов организации структурированных кабельных систем в ЦОД, и в меньшей степени вопросов отказоустойчивости и других инженерных подсистем.
• Носит рекомендательный характер.
• Есть пошаговые инструкции и рекомендуемые схемы (помощь инженеру). «Делай как тут написано и получишь хороший результат».
• Соответствие стандарту заявляется владельцем объекта или исполнителем проекта (на уровне «Я делал как вы сказали, честное слово»).
• Обычно, на соответствие стандарту проверяется только проектная документация.
• Однажды реализованный объект не теряет уровень.