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

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

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

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

А теперь вот жизнь заставила (или подкинула возможность) все-таки разобраться во внутренностях всем хорошо известных документов, тем более, что в Штирлица теперь играть не обязательно, достаточно скачать с сайта «Майкрософта» официальные спецификации.

Что тут можно сказать? Невольно вспоминается старый пошлый анекдот: ну ужас. Ну просто ужас, но ведь не ужас-ужас-ужас.

Предисловие

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

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

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

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

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

Здравствуйте, хабрачеловеки!

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

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

В современной IT-индустрии часто случается так, что заверения производителя устройства относительно его функциональности не соответствуют действительности. От скепсиса по этому поводу перейдем к решению конкретной технической задачи…

Окружение, которое выращивает творческих программистов, убивает менеджмент и маркетинг. И обратное тоже верно.

Программирование — это великая Игра. Она поглощает тебя целиком, тело и душу. Когда ты весь погружён в него — для тебя более ничего не существует. Когда ты выныриваешь на свет, ты можешь с удивлением обнаружить, что прибавил 50 кг, возраст твоего исподнего приближается к возрасту первоклашки, и судя по количеству коробок из-под пиццы, уже пришла весна.
Но тебе всё равно, потому что программа работает, код красив, изящен и быстр.

Я работал со многими программистами на протяжении долгих лет — некоторые из них были очень яркими, а некоторые — определенно «никакими». Недавно я имел удовольствие работать с несколькими высококвалифицированными специалистами, так что я потратил немного времени в размышлениях, чем же я восхищаюсь в них. Что делает хорошего программиста таким хорошим, а плохого — таким плохим? Или, немного коверкая русский язык, что делает хорошего программиста хорошим?

Прочитал пост на ту же тему и вспомнил, что давно хотел поделиться своими впечатлениями о современных юзабилити, ui и вообще, современном софте в целом.

Итак, произошла тут у меня на днях трагедия: windows 8 осыпался в синий экран и после перезагрузки не смог залогиниться в мой профиль. Поискав причину в гугле, я в конечном итоге нашел что виноват скорее всего chkdsk — при некоторых условиях повреждается файл $system и в результате после его исправления chkdsk слетают права на все файлы на поврежденном диске. В итоге винда при попытке логина не может прочитать файлы профиля, т.к. к ним нет доступа из-за некорректных прав и на этом виснет.

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

«Когда человек не знает, к какой пристани он держит путь, для него ни один ветер не будет попутным». (С) Сенека, Луций Анней

Предисловие

Как-то один из топов уважаемой компании, которая занимается продуктовой разработкой ПО, пригласил меня, как эксперта, чтобы я оценил качество нового продукта. Я внимательно просмотрел и прослушал презентацию. Видно было, что коллеги очень старались и работали по 10-12 часов, чтобы продукт выглядел на высшем уровне. После чего меня спросили: «хороший получился продукт или нет?» Я поблагодарил за представленную презентацию, но попросил ответить на свой последний вопрос: «А какие процессы, и с какой целью вы собираетесь автоматизировать с помощью этого инструмента?» Вопрос почему-то вызвал замешательство у докладчиков. После небольшой паузы, топ, который, видимо, был идеологом нового продукта, ответил: «Был бы инструмент хороший, а какие процессы с его помощь автоматизировать мы найдем!» Мне пришлось сказать, что оценить продукт я не смогу. Не зная бизнес-целей, невозможно понять степень их достижения.

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

Для иллюстрации используем проект «Экспедиция за сокровищами Флинта»

На одной из конференций произошел комичный случай. Подходит слушательница:

— Александр, есть такой вопрос: Как нам повысить уровень доверия в отношениях с заказчиком?

— А что сейчас не так с уровнем доверия?

— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам…

— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.

— Понимаете… Мы ему джуниор инженеров продаем как синьор инженеров… И нам не хотелось бы, чтобы он обнаружил этот факт.

Напомню изначальную постановку вопроса: “Как нам повысить уровень доверия в отношениях с заказчиком?”

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

• Поможет осознать, где находятся ваши отношения с заказчиком
• Покажет, почему формы отчетов иногда бывают такие идиотские
• Возможно, поможет понять причины “неадекватного” поведения заказчика

Так уж завелось на хабре, что на каждую холиварную статью «Pro» всегда найдётся статья «Contra».
Я тоже решил не оставлять в одиночестве пост «Что не так с ООП и ФП».



Прямо противоречить написанному смысла не имеет, там ведь описан «вкус», а, как известно, на вкус и цвет… каждый любит свой ЯП.
Нет никакой проблемы с ООП и ФП. Чистота функций — это всего лишь инструмент, равно как и «всё является объектом».
Критика права лишь в одном — в борьбе за миллиметры хорошо видны яркие прорехи, а в любых вырожденных методах недостатки ярко проявляются.
Другое дело, что любые невырожденные методы так же имеют недостатки, только их больше, зато они не так легко заметны.
Любители С++ гнобят полное ООП, Javа гнобит Си++ за неполное ООП, Haskell гнобит другие ФП за грязные функции, остальные ФП гнобят Haskell за излишне чистые функции.
Всё имеет свою оборотную сторону медали.
Тогда почему досталось всё объектам и функциям, а не массивам и указателям?!

Я не понимаю причины существования бесконечных споров вокруг Объектно-ориентированного (ООП) и Функционального (ФП) программирования. Кажется, что такого рода вещи находятся за пределами человеческого понимая, и о них можно спорить бесконечно. Много лет занимаясь исследованием языков программирования, я увидел четкий ответ, и зачастую я нахожу бессмысленным обсуждение этих вопросов.

Если кратко, то как ООП, так и ФП неэффективны, если доходить в их использовании до крайности. Крайностью в ООП считается идея о том что “все что угодно является объектом” (чистое ОП). Крайностью для ФП можно рассматривать чистые функциональные языки программирования.

Компанией Intel в 2008 г. были предложены новые команды для x86 архитектуры, которые добавили поддержку на аппаратном уровне симметричного алгоритма шифрование AES(Advanced Encryption Standard). На данный момент AES — один из самых популярных алгоритмов блочного шифрования. Поэтому аппаратная реализация должна привести к повышению производительности программ использующих этот алгоритм шифрования(OpenSSL, The Bat, TrueCrypt ...). Новое расширение команд получило название AES-NI. Оно содержит в себе следующие инструкции:

• AESENC — Выполнить один раунд шифрования AES,
• AESENCLAST- Выполнить последний раунд шифрования AES,
• AESDEC — Выполнить один раунд расшифрования AES,
• AESDECLAST — Выполнить последний раунд расшифрования AES,
• AESKEYGENASSIST — Поспособствовать в генерации раундового ключа AES,
• AESIMC — Обратный Mix Columns.

Так как про сам алгоритм шифрования AES было уже было сказано многое, то в этом посте рассмотрим, как можно воспользоваться этими инструкциями.

Сегодня я хочу рассказать вам о префиксах в системе команд Intel IA-32 в 32- и 64-битных вариантах (также именуемых как x86 и x86_64). Но для начала напомню вкратце общую структуру IA-32 инструкции:

• Префиксы. Могут отсутствовать. Может присутствовать сразу несколько.
• Опкод. Может состоять из одного, двух или трех байтов.
• Mod_R/M байт. Используется для адресации операндов. Может отсутствовать в кодировке, если инструкция не имеет явных операндов.
• SIB (Scale Index Base) байт. Второй байт, использующийся для адресации операндов в памяти. Может отсутствовать.
• Байт смещения адреса (англ. displacement). 1, 2, 4 или ни одного байта.
• Константа (англ. immediate). 1, 2, 4 или ни одного байта.

Заранее прошу прощения, если как-то отнимаю ваше время, уважаемые читатели. Возможно, этот текст — всего лишь эмоции. Возможно, просьба о помощи — я что-то упускаю.

Такое время

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

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

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

Крутой стартапер

Продукт не важен, важно что он теперь крутой стартапер. Вы там, мол, делайте и работайте, a я пощеголяю. Ходит на тусовки, пишет в блоге статейки, снимает видео про стартаперство. Как быть крутым стартапером? Как выбрать название фирмы? Спросите у него! Через пару месяцев приходит разочарование: вроде бы он крутой стартапер, а дело не движется. Но ничего. Он найдёт в тусовке знакомых, у которых тоже не движется и успокоится.

Компания Opera Software до сих пор умеет удивлять. Только если раньше для этого находили некий хороший повод (внедрение полезных функций и инновационных технологий), то сейчас вести из Норвегии скорее удручают. Например, 8 октября разработчик объявил о выходе очередной версии браузера за номером 17. Проглядев перечень изменений, многие придут в замешательство.

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

1. иметь малые накладные расходы по памяти. Большая часть доступной памяти должна использоваться для хранения текста, а не служебной информации;
2. допускать эффективную вставку и удаление в произвольном месте текста.

Удовлетворить эти требования одновременно непросто. Если рассмотреть широкоизвестные структуры данных, такие как массивы, списки, деревья, стеки, очереди, кольцевые буфера — то такой структуры, которая бы позволила эффективно выполнить оба требования, не встречается. В случае массива имеем незначительные накладные расходы по памяти, но операция вставки имеет сложность O(n), где n — размер редактируемого текста. В случае списка сложность вставки и удаления составляет O(1), однако накладные расходы по памяти в несколько раз превышают размер собственно текста. Деревья, кучи, кольцевые буфера, ассоциативные массивы и прочие структуры и вовсе неприменимы для хранения текста в редакторе.

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

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

Несмотря на то, что эта структура данных была открыта давно и использовалась в текстовых редакторах на старых ЭВМ в 8-битную эпоху, это тайное знание предков было в значительной мере утеряно и в современных редакторах встречается редко. Попробуйте открыть файл, состоящий из одной строки мегабайт на 10, в Notepad или Far. Вставка и удаление символов будет длиться секундами.

Разработка, Направленная на Создание Мусора

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

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

Это работает так: