После публикации своего первого поста «Почему я люблю Microsoft. Заметки Зомби» я получил достаточно много писем с похожей просьбой — написать подробнее об используемых продуктах.
Просили — получите. При написании статья я поставил себе цель — описать основной маршрут. Расписывать тонкости установки и настройки нет смысла — их достаточно в Интернет. Я старался, чтобы прочитав этот пост администратор знал названия продуктов и технологий, для чего они нужны и потом уже мог ловко нагуглить всё остальное. Для того, чтобы облегчить поиск ключевые названия будут на английском. Если какая-то аббревиатура незнакома — это повод про неё почитать. И, да, я буду описывать решения от Microsoft, так как что-то смыслю только в них. Хочу сразу предупредить что топик очень конспективный.

Пост навеян вот этим уважаемым постом уважаемого @P_r_i_m_a_t.
Голь на выдумки хитра, программировать я не умею, а постеры с карт иметь очень хочется. Поэтому делаю обычно так:

Кармин Галло (Carmine Gallo) является специалистом по коммуникативным тренингам. Для подготовки своей новой книги он провел много часов над изучением докладов и презентаций Стива Джобса. И теперь он поделится со всеми нами секретами успеха настоящего мастера публичных выступлений, а по совместительству – исполнительного директора Apple.

Пять элементов, присутствующие во всех презентациях Apple.

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

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

Учёные уже полностью дизассемблировали H1N1 и занесли его в вирусную базу NCBI Influenza Virus Resource. Там всё задокументировано в подробностях. Например, образец A/Italy/49/2009(H1N1) был обнаружен в носу 26-летней женщины, вернувшейся из Италии в США. Вот первые 120 бит его генетического кода.

atgaaggcaa tactagtagt tctgctatat acatttgcaa ccgcaaatgc agacacatta

Сколько бит убьёт человека?
По приблизительным подсчётам, общий размер исходников H1N1 составляет 26 022 бит, а если исключить служебные стоп-сигналы (указывают на окончание каждой белковой последовательности), то исполняемый код состоит примерно из 25 054 бит. Это число является приблизительным ещё и потому, что в вирусе присутствует механизм генерации избыточного мусора для маскировки от антивирусов.

Итак, получается около 25 килобит или 3,2 килобайта. Таков объём кода для программы, имеющей ненулевые шансы убить человека. H1N1 написан гораздо эффективнее, чем компьютерный вирус MyDoom размером около 22 КБ.

Очень унизительно, что меня могут убить всего 3,2 КБ генетических данных. Впрочем, в 850 МБ человеческого генома по любому должны быть дыры для парочки эксплойтов.

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

А как делать этот самый рефакторинг, если даже неизвестно, с чего начать? Как осушить болото кода и не утонуть нем?

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

Внесу-ка я и свой вклад в дело, тем более, что кто-то просил поделиться информацией.

Как?

Уже скоро 4 года как я живу и работаю в Японии. Попасть сюда иностранцу с одной стороны довольно легко, но с другой стороны — нет. Как так? Дело в том, что программ иммиграции в этой стране нет, натурализация возможна (практически) только через брак, но в стране огромный дефицит инженеров. То есть продавцы, юристы, врачи, строители, таксисты есть, а инженеров мало. О причинах я расскажу ниже. Так вот, Япония каждый год импортирует огромное количество индийцев, китайцев, корейцев, филиппинцев, американцев, тайцев и т.д. для работы в технических областях. Однако, русскому инженеру (как всегда) протиснуться сложно. Хотя бы потому, что нужна виза, поручитель, беготня с бумагами (в последние год-два ситуация стала самую капельку лучше). Поэтому, если очень хочется именно в Японию, придется запастись какими-то уникальными (ну, или хотя бы редкими) знаниями — микроконтроллеры, программирование для RTOS, ГИС, хитрые БД, распределенные вычисления и т.п. А веб-мастеров полно и в Китае :)

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

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

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

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

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

В любой серьезной компании иногда возникает необходимость в том, чтобы сотрудник, уехавший в отпуск, срочно выполнил свои должностные обязанности. Рассмотрим ситуацию, когда компании необходим конкретный сотрудник, например, системный администратор, который в данный момент возлежит на пляже в тысяче километров от душного офиса. Допустим даже, что этот сотрудник согласен выполнить неожиданно свалившуюся ему на голову работу и на курорте есть интернет-кафе. Но вот проблема: кафе располагается в темном переулке, на его компьютерах стоят популярная ОС, трояны, кейлоггеры и прочие хактулзы, так что набирать пароль root'а от главного сервера компании на подобных машинах довольно неразумно.

Существует несколько решений этой задачи. Например, можно использовать одноразовые пароли, а именно систему s/key, использующую для генерации паролей алгоритмы md4 и md5. Об этой системе и будет рассказано далее.

Об использовании бесплатной программной телефонной станции «Asterisk» написано множество заметок, статей и книг. Не раз этот вопрос поднимался и на Хабре — и об устройстве, и об установке, и о тонкостях конфигурирования. Я же сегодня хочу посмотреть на Asterisk глазами руководителя IT, который «что-то слышал» и которому предстоит принять решение — внедрять у себя этот продукт, или остановить свой выбор на «классической» аппаратной АТС.

Статья рассказывает об организации отказоустойчивого файлового сервера на базе пакета Samba. Для понимая материала нужно иметь общее представление об администрировании ОС Linux, а также иметь опыт работы с обычной версией Samba.



Samba – это сервис CIFS, разработанный для того чтобы обеспечить семантику протокола CIFS (и соответственно доступ с машин под управлением Windows) к среде, использующей POSIX файловую систему. Основная функция Samba – преобразовать богатую семантику, которую используют клиенты на базе Windows к значительно более бедной семантике файловой системы POSIX.

Почитал я, как люди бьются с пользователями своего софта и решил поделиться с миром опытом. Сразу скажу, что опыт у меня не маленький — в своё время мои программы пользовались большим спросом и на их поддержке я не одну собаку съел. В результате клиенты пИсали кипятком, а пользователи саботировали любой другой софт, спускаемый сверху, кроме моего. В качестве истории успеха приведу не слишком большой проект автоматизации АЗС.

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

Привет, хабралюди!

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

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

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

Сегодня расскажу о том, с чем работает большинство читателей — о контроле версий.

Disclaimer

Далее будут описаны основные техники, реализованные в подавляющем большинстве систем контроля версий. Как они реализуются в приложениях, которые использует читатель, оставим на откуп многочисленным руководствам пользователя, how-to, FAQ и прочим документам, коих можно найти без труда. Главное – понять, по каким принципам и зачем оно работает именно так.

Простой способ защиты от HTTP DDoS — включить syn-cookies и заблокировать подонков. Но что делать если атакует 5к-10к хостов да еще и с динамическими IP? Тут нам на помощь придет frontend-backend архитектура c промежуточным кэшированием! Почему с промежуточным кэшированием? А потому что в моем случае от шквала запросов от frontend'а backend умирал унося за собой систему.

Продолжая тематику Многомерные кубы, OLAP и MDX и olap для маленькой компании, традиционно, предлагаю начать с простенького «Hello World» куба, который будет анализировать процессы и тенденции голосований на Хабре.

Итак, давайте попробуем создать свою первую OLAP систему.
Но, прежде чем, потирая руки, запускать Business Intelligence Studio, предлагаю вначале создать хранилище данных хабра-голосов, так называемый Data Warehouse.
Зачем? Причин в этом несколько:

• сама суть Data Warehouse-а хранить «очищенные» данные, готовые для анализа, поэтому даже его изначальная структура может сильно отличаться от структуры нашей хабра-OLTP базы данных
• в HabraDW (так мы его назовем) мы вынесем только ту информацию, которая нам нужна будет для анализа, ничего лишнего
• к Data Warehouse не накладываются требования нормализации. Даже наоборот, денормализировав некоторые данные можно добиться более понятной схемы для построения куба, а также скорости загрузки данных в куб

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

Для таких людей я перевёл новую статью Тома Демарко, одного из основоположников инжиниринга ПО, разработчика метрик для ПО и соавтора известной книги «Человеческий фактор: успешные проекты и команды».
Эта статья сильно провокационная и сейчас широко обсуждается в англоязычных блогах и странно, что я еще не встречал ее переводов на русский. Но, несмотря на провокационность, в ней есть несколько очень правильных идей, которые могут изменить у кого-то представление о важности и возможности контроля за разработкой.
В общем, читайте перевод статьи под катом.