Этот топик — ответ на топик "Пора завязывать использовать символы табуляции в коде".
Я хотел было ответить к комментариях, но в силу объема и желания независимости от исходного топика решил создать новый топик.

Итак, под катом — почему табы лучше пробелов, самые значительные заблуждения касательно табов и как ими правильно пользоваться.

По результатам этого вопроса.

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

0. Intro.

Ситуация следующая. Есть винт на 160Гб. На нем 2 раздела — 40Гб и 120Гб. С целью установки убунты как второй системы была произведена разбивка 120Гб -> 100+10+2+8.

Далее, с целью отката изменений, были объединены диски (10, 2 и 8) обратно в один 20Гб и отформатирован в NTFS. В нагрузку к этому, были проведены операции с MBR, результатом которой явилась ее смерть.

Итоги

1. При загрузке системы выводится сообщение MBR helper not found;
2. fdisk показывает один большой 160Гб диск.

Дураку понятно, что это начало веселой ночи.
Далее, под катом, решения вопроса.

Это перевод статьи Oliver Reeve об одном из способов ускорения компиляции проекта. Автору удалось ускорить компиляцию с 55 до 6 минут. В своём проекте я получил прирост производительности около 22% (около минуты). Это не столь поразительно, как достижения автора, но всё же, умножив эту минуту на количество компиляций в день, количество разработчиков и длительность разработки проекта, я получил экономию, которая точно оправдывает затраты на чтение статьи и настройку проектов. Описано решение для Visual Studio и С++, но идея применима и к другим IDE, компиляторам и языкам программирования (не всем). В следующей статье я рассмотрел еще пару способов ускорения компиляции решения.

Мой основной рабочий инструмент на протяжении вот уже 10 лет это Microsoft Visual Studio. Это прекрасная IDE (по крайней мере для С++ и С#), лучше которой для Desktop-разработки под Windows я не знаю. Тем не менее, общеизвестен один её недостаток — падение производительности на больших решениях. Я сейчас работаю над решением из 19-ти проектов (около 4к файлов, 350к строк кода). Компиляция и прочие издержки съедают изрядное количество времени. Именно поэтому я задался целью провести масштабное исследование путей повышения скорости работы Visual Studio, отделив мифы от реальности.

Сразу скажу, что в финале мне удалось добиться сокращения времени компиляции решения с 4:24 минут до менее чем одной минуты. Детали под катом.

Привет! Сегодня мы открываем блог на Хабре. Наша специализация – переводы на английский язык, написание и рассылка пресс-релизов в Рунете, а также создание справочных систем для ПО. За несколько лет работы накопились некоторые знания, которыми хотим поделиться с вами. Надеюсь, что блог будет вам полезен. Желаю приятного прочтения и жду вас в постоянных посетителях.



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

Если вы словили OutOfMemoryError, то это вовсе не значит, что ваше приложение создает много объектов, которые не могут почиститься сборщиком мусора и заполняют всю память, выделенную вами с помощью параметра -Xmx. Я, как минимум, могу придумать два других случая, когда вы можете увидеть эту ошибку. Дело в том, что память java процесса не ограничивается областью -Xmx, где ваше приложение программно создает объекты.

Google выложил под свободной лицензией новое семейство хеш-функций CityHash для строк. Пока представлены функции CityHash64 и CityHash128 для получения 64- и 128-битных хеш-кодов.

Как сообщают разработчики, в реальных условиях CityHash64 превосходит по скорости аналогичные хеш-функции как минимум на 30%.

В силу своей простоты данные хеш-функции не подходят для криптографических применений, но теоретически это идеальный вариант для хеш-таблиц. Правда, код пока сыроват, недостаточно оттестирован (см. warning) и нуждается в некоторой доработке.

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

Однако, в зависимости от вида, каждые 7, 11, 13 или 17 лет периодические цикады одновременно массово вылезают на свет и превращаются в шумных летающих тварей, спариваются и вскоре умирают.

Хотя наши странные цикады весело уходят в иной мир, возникает очевидный вопрос: это просто случайность, или числа 7, 11, 13 и 17 какие-то особенные?

Сразу после окончательного релиза 14 марта сырого Internet Explorer 9 в Твиттере появился аккаунт ie9bugs, в котором собираются значительные для веб-девелопера баги. И хотя есть баг-трекер Микрософта, но там чёрт ногу сломит, а тут в одном месте достаточно кратко описаны и даны ссылки на интересные нюансы. Нам скоро придётся вступить в это говно работать с передовым браузером от Microsoft, потому, имхо, вполне полезно знать все эти грабли. Особенно, зная, с какими темпами Микрософт их закрывает. Предлагаю присоединиться к этому сообществу, рассказать интересные моменты, которые у вас уже есть и прочитать то, что они уже открыли. Из того, что «порадовало» меня больше всего:

• IE9 понимает не больше 4095 селекторов в одном CSS-файле
• Можно подключить не более 31 CSS-файла
• События не цепляются к элементам, у которых background:transparent;

Особо радует первый баг, теперь большие таблицы стилей не объединишь в один файл) Микрософт нам, верстальщикам и JavaScript-программистам, приготовил ещё огромное количество работы, костылей и головной боли, выпустив IE9, радуемся)

Ну и много ещё чего найдено за две недели, читайте сами.

UPD:

A reliable exploit for Internet Explorer 9 on Win7 SP1 is now available for our Gov customers. Unpatched vuln + ASLR/DEP/Sandbox bypass

Редакционное расстояние, или расстояние Левенштейна — метрика, позволяющая определить «схожесть» двух строк — минимальное количество операций вставки одного символа, удаления одного символа и замены одного символа на другой, необходимых для превращения одной строки в другую. В статье излагается метод вычисления редакционного расстояния при использовании небольшого объема памяти, без существенной потери скорости. Данный подход может быть применен для больших строк (порядка 10⁵ символов, т.е. фактически для текстов) при получении не только оценки «схожести», но и последовательности изменений для перевода одной строки в другую.

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

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

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

Все привыкли редактировать текст в текстовых редакторах, блокнотах, веб-формах и т.д. В процессе набора текста мы пользуемся привычными стрелками, кнопками «End» и «Home», более опытные зажимают «Ctrl» и стрелками шагают по словам (что, кстати, не всегда работает). И при переходе на консоль мы ориентируемся на те же самые правила, даже не зная, что bash предлагает очень удобные средства и комбинации клавиш, которые очень упрощают работу и минимизируют количество операций для выполнения задачи. К тому же, в bash есть удобные средства работы с историей, масса различных подстановок и других интересных функций. Самые часто используемые мной и любым опытным администратором я и опишу в этой статье.

В 2008 году будущая команда «Мосигры» начала воплощать свою давнюю мечту по изданию качественной отечественной настольной игры. С продажи первой партии «Шакала» началась история розничной сети. Сначала мы открыли интернет-магазин, потом магазин в реале, а затем за два года построили сеть, покрывающую крупнейшие города России, Украины, Беларуси и Казахстана.

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

Осенью 2008-го года у нас на руках уже была большая партия игры «Шакал» (в премиум-версии), стоящая немалых денег, масса энтузиазма, глобальные планы и некоторое количество денег на сайт и первый маленький магазин.

А теперь медленно и по порядку.

Иногда полезно представить граф в графической форме, так чтобы была видна структура. Можно привести десятки примеров, где это может пригодиться: визуализация иерархии классов и пакетов исходного кода какой-нибудь программы, визуализация социального графа (тот же Twitter или Facebook) или графа цитирования (какие публикации на кого ссылаются) и т.д. Но вот незадача: количество ребер в графе зачастую настолько велико, что нарисованный граф просто невозможно разобрать. Взгляните на эту картинку:



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

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

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

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

Документация – такая штука, к которой мало кто питает тёплые чувства: скучно, занудно, однообразно. И, тем не менее, иногда не возникает сомнений в её необходимости: ведь кому-то после вас этим пользоваться или, тем паче, модифицировать. И тогда появляется вопрос: как сделать документацию правильно?

Существует тьма статей на тему «как писать документацию», но если вы решили взяться за неё в первый раз, то в новой для вас области не сразу понятно, дело ли пишет автор, или отсебятину выдумывает.

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

Вступление

Приветствую всех.

Люди любят читать. Но не все, и не всё. А то, что любят, не всегда можно найти в магазинах. А если и можно найти, то не всегда это по карману. Из этого следует один элементарный факт: что-то с этим надо делать. Конечно, можно читать с экрана монитора/ноутбука/телефона. Или распечатать и читать в разрозненных, пусть и упорядоченных, листочках. Кроме того (это более затратный вариант, но для любителя чтения он лучше), можно купить специализированную читалку на электронных чернилах. Да, она решает проблему, но… Спустя какое-то время начинаешь скучать по весу настоящей книги, по шелесту перелистывания бумажных страниц, и по кипе других подобных маловажных, но таких приятных сердцу мелочей.
И из этой неприятности тоже есть свой выход. Просто-напросто надо самому сделать нужную книгу.
Осторожно, под катом очень много фотографий.

В официальной Google-группе, посвященной Android'у, время от времени появляются жалобы разработчиков о том, что трудно найти уникальные, надежные и стабильные идентификаторы для Android-устройств.
В блоге android-developers был опубликован небольшой топик, посвященный тому, как отслеживать индивидуальные установки приложений. Думаю, кому-то это будет полезно.

Инженер Google, автор трёх книг по веб-производительности и активист Open Source, Стив Содерс (Steve Souders) представил новый проект HTTP Archive, который должен стать отличным дополнением к известному Архиву интернета.

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

Например, из статистики видно, что за последние шесть месяцев использование флэша в Сети снизилось на 16%, а средний размер страницы с контентом вырос на 88 КБ.