Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

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

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

Капитан Очевидность намекает: чтобы такого не допустить, важно уметь понимать, в каком состоянии находится ваш продукт на каждом этапе его развития. В этой большой статье предлагается методика оценки его состояния в самой наглядной форме – в форме таблиц и графиков. Здесь обобщен мой опыт и опыт всей команды новосибирского офиса Parallels за последние шесть лет. Чтобы было понятно: мы делаем Parallels Plesk Panel – хостинг-панель, которая используется примерно на каждом втором сервере в мире, предоставляющем услуги веб-хостинга. Применив эту методику, мы получили вот такие результаты:

1. существенно улучшилось качество выпускаемых релизов (согласно Incident rate);
2. релизы стали более предсказуемыми, точность наших прогнозов и оценок выросла в разы;
3. появилось понимание, почему что-то идёт не так и как этого избежать в будущем.

Заинтересованных лиц прошу под кат и в комменты. Отвечу на любые вопросы.

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



Понять последних можно, ведь большинство статей и agile-евангелистов говорят, примерно следующее: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

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

И так, за час удалось «восстановить» около 2.5 миллионов паролей на средней рабочей конфигурации, без специальных словарей и радужных таблиц. Среди найденных паролей присутствуют 16-символьные алфавитно-цифровые комбинации, и далеко не в единственном экземпляре.

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

    Есть такая замечательная технология, как динамическая бинарная инструментация (Dynamic Binary Instrumentation, DBI), которая заключается во вставке в бинарный исполняющийся код анализирующих (в общем случае) процедур. Основная прелесть данного подхода заключается в том, что нет необходимости в исходном коде анализируемого приложения – работа происходит непосредственно с бинарным файлом.

— Какое отношение имеет морская свинка к морю?
— Примерно такое же, как утконос к проектированию дирижаблей.

Введение.

Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи».

Осенью 2011 я крутил в голове:
[1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008
[2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко
[3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).

Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.

За что именно я зацепился:

• Таичи Оно (Öno Taiichi) не понимал, почему его система работает.
• Существует несколько разных типов производственных потоков – V, A, T, I. Каждый тип потока ставит особые задачи.
• Неудачи внедрения доски Максима Дорофеева в некоторых подразделениях
• Ряд компаний не смог внедрить систему Тойота, несмотря на все приложенные усилия.
• Система Тойота и система Форда основывается на одинаковых принципах, но прикладные решения ограничены определенными типами производства.

Как-то давно я уже писал об этом, но немного скудно и сумбурно. После я решил расширить список инструментов в обзоре, добавить статье структуры, учесть критику (большое спасибо Lefty за советы) и отправил ее на конкурс на СекЛаб (и опубликовал ссылку, но по всем понятным причинам ее никто не увидел). Конкурс закончен, результаты объявили и я с чистой совестью могу ее (статью) опубликовать на Хабре.

Бесплатные инструменты пентестера веб-приложений

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

1. Сетевые сканеры
2. Сканеры брешей в веб-скриптах
3. Эксплойтинг
4. Автомазация инъекций
5. Дебаггеры (снифферы, локальные прокси и т.п.)

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

К моменту, когда у нас возникло желание попробовать новую систему организации процесса, мы были сработанной командой, ведущей успешную Scrum разработку.

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

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

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

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



Несколько дней назад я размышлял, почему так получилось, что тщательно прописанный и формализованный проект в очередной раз со свистом вылетел из сроков и бюджета, превысив их в разы. Иногда бывает, что проекты ведут себя по другому, но чаще происходит именно так. И это мало зависит от того, какую методику я использую для оценки объема работ и самой разработки. Даже McConnell, которого я считаю серьезным авторитетом в области разработки ПО, в начале книги Software Estimation: Demystifying the Black Art констатирует то, что простые методики оценки размера проекта удивительным образом оказывается ничуть не хуже сложных и испытывают те же самые проблемы. Возможно этот вывод можно распространить не только на методики оценки.

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

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

(на иллюстрации персонаж фильма «Железный человек 2» Иван Ванко в момент произнесения фразы «Ваш софт — говно»)

1. Индустрия на стероидах

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



Заинтересованная аудитория: авторы HTML-контента, разработчики скриптов серверных приложений (PHP, JSP и т.д.), менеджеры веб-проектов и любые другие люди, так или иначе связанные с дизайном форм ввода данных, дизайна баз данных и онтологий, которые затрагивают личные имена людей.

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