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

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

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

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

Бегло просматривая новый стандарт C++11, решил углубить свое понимание в теме rvalue references. Все, в принципе, замечательно, но есть подводные камни, а именно: некоторая потеря обратной совместимости с С++03.

Признак того, что объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция».

Каждый раз когда из написанного класса вы создаёте всего один экземпляр, используете только раз и тут же выбрасываете, следует думать: «ой, надо бы это отрефакторить! Можно сделать проще, намного проще!»

Перевод доклада Джэка Дидриха, одного из ключевых разработчиков языка Питон. Доклад прозвучал 9 марта 2012 на конференции PyCon US.

Тренер следит за вами. Тренер помнит. Тренер не забывает и не прощает.

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

23 февраля состоялся анонс Visual Studio 11 beta и в часовом выступлении было рассказано об основных функциональных новинках будущего продукта. Сама Visual Studio 11 beta станет доступна для загрузки уже на следующей неделе, 29 февраля. Visual Studio 11 beta будет выпущена в «go live» лицензии и позволит разрабатывать приложения для будущей операционной системы Windows 8. Не даром на 29 февраля запланировано еще одно мероприятие – анонс Windows 8 Consumer Preview в рамках Mobile World Congress, который пройдет в Барселоне. Но возможность разрабатывать приложения для Windows 8 это ожидаемая функция, и в ней, пожалуй, нет ничего необычного для будущей версии продукта. Для тех, кому не терпится узнать о некоторых нововведениях связанных именно с инструментарием, добро пожаловать под кат.

Доброго вам дня, коллеги. Предлагаю вам прочитать статью о базовом аспекте вычислительной геометрии — точном вычислении предикатов.

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

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

• геометрический предикат «поворот»;
• противоречивость «наивной» реализации поворота;
• применение интервальной арифметики для упрощения расчета предикатов;
• длинная арифметика и несколько альтернативных способов вычислений предикатов;
• расчет погрешности вычисления поворота в числах с плавающей точкой.

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

Введение

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

• Разные шаблоны для имен файлов: 4 — Звезда | 04 — Звезда | 04. Звезда
• Разные имена исполнителей в тегах: Чиж & Co | Чиж и Ко. | Mylene Farmer | Mylène Farmer
• Не указаны исполнители альбома (что приводит к полному бардаку в альбомах-компиляциях)
• Не совсем корректная информация об альбомах, состоящих из нескольких дисков
• Путаница в годах изданий и переизданий (ремастеринг, и т.д.)

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

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

В листе рассылки Git развернулась дискуссия о том, как язык программирования высокого уровня снижает производительность приложения, в связи с обсуждением JGit. Дискуссия особенно интересна, потому что в ней принимали участие программисты, эксперты высочайшего уровня как в C, так и в Java. Один из них — Шон Пирс (Shawn O. Pearce), известный Java-программист из компании Google, активный коммитер в Eclipse, соавтор Git и автор Java-имплементации Git под названием JGit. В своём сообщении он назвал реальные ограничения, с которыми сталкивается высококвалифицированный разработчик, пытаясь написать эффективный Java-код, сравнимый по производительности с максимально оптимизированным кодом C. Хотя письмо датируется апрелем 2009 года, но некоторые аргументы Шона до сих пор не потеряли актуальность.

List: git
Subject: Re: Why Git is so fast (was: Re: Eric Sink's blog — notes on git,
From: «Shawn O. Pearce» <spearce () spearce! org>

Как было сказано ранее, мы сделали много маленьких оптимизаций в коде Git на C, чтобы добиться реально высокой производительности. 5% здесь, 10% там, и внезапно ты уже на 60% быстрее, чем был раньше. Нико [Питре], Линус [Торвальдс] и Джунио [Хамано] — все они потратили определённое время в последние три-четыре года для оптимизации отдельных фрагментов Git, исключительно для того, чтобы он работал максимально быстро.

1 Введение

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

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