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

Я думаю, всем из нас известна данная система компьютерной алгебры. Она не является конкурентом Wolfram Mathematica, но она обладает именно тем функционалом, который я требую от математического софта. Если говорить проще и доступнее — считать можно на всём, от палочек до суперкомпьютеров, и далеко не всегда задачи инженерной практики целиком переносятся с бумаги в программный код. Одним из примеров, который я честно говоря, еле-еле застал, является сегодня забытая поделка нашего конверсионного производства — цельнометаллический бытовой вакуумный гражданский термос, который выпускался ранее ещё в СССР на Урале. Чтобы наладить его производство институт, в котором я учусь, де-факто вручную на счётных машинках высчитал все необходимые параметры рабочего оборудования. Поэтому лицензия на Mathematica — не показатель и не ценз пригодности к практике. Считать, повторюсь, можно на всём.

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

Так или иначе, практически каждый из нас использовал в своей жизни технику интеллект–карт или Mind Mapping. Это всего лишь простая радиальная схема, но с правильным подходом ее можно превратить в мощный инструмент аналитики и синтеза информации, который всегда под рукой и достаточно прост в использовании. И что самое интересное, освоение техники настолько естественно для нашего мозга, что занимает всего лишь несколько минут…

Привет, Хабр!
Ничего не писал со времен своей первой статьи, решил, что пора это исправить.

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

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

Я старался покрыть максимальное количество разных топиков, особенно тех, что спрашивают на собеседованиях. Я старался воздерживаться от domain-specific литературы: профессионалы и так знают. Все картинки содержат ссылки на амазон.

А какие книжки нравятся вам?
Также в комментах можете писать, на какие темы вам были бы интересны посты.

Привет, Хабрахабр.

В этом посте мы хотим вам рассказать о хорошей книге Майкла Доусона «Beginning C++ Through Game Programming». Многие знакомы с творчеством Майкла по книге «Программируем на Python», которая многим пришлась по вкусу. Когда-то мы рассказывали о ней в нашем блоге. Мы еще не приняли окончательное решение по поводу издания книги, поэтому решили в очередной раз посоветоваться с вами. В качестве рецензии мы перевели мнение сайта www.gamedev.net. По содержанию книга по С++ напоминает Python, так как в ней выдержан такой же стиль — обучение через программирование игр.

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

Скорее всего, вы уже знаете об одной из таких методологий, разработанной Яндексом, — БЭМ. БЭМ утверждает, что трёх сущностей (блоков, элементов и модификаторов) достаточно для написания HTML и CSS, задания структуры кода и компонентной структуры с последующим масштабированием проекта до самого высокого уровня.

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

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

Изначально эта моя статья была опубликована в известном многим журнале Smashing Magazine. Но я решил, что и на Хабре она может быть интересна, ведь многие здесь занимаются собственными небольшими проектами.

Всем привет!

Пост повышенной несерьёзности, ибо пятница.
Хочу рассказать про антипаттерны, которые выкристаллизовались в нашей компании. Just For Fun.

Каждый раз, когда разработчики/монтажники/схемотехники применяли повторяющуюся отмазу, её фиксировали и заносили в список. Когда список вырос и в нём появилось почти 12 отмазок, нам пришла в голову идея сделать свой календарь с антипаттернами (поскольку отмазки иллюстрируют то, как не стоит думать и делать, приравниваем их к антипаттернам). Для этого нам предстояло осилить вёрстку календаря и к каждому анти-паттерну «родить» соответствующую картинку. Вёрстку делали в LaTex'е, а картинки — в inkscape, в svg-формате. В-общем, получилось вполне open-source'но. Но пост всё-таки больше не о технической реализации, а о самих анти-паттернах. Кому интересно, добро пожаловать.

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

Сегодня помимо книжных интернет-магазинов, где можно купить электронные версии книг, некоторые прогрессивные издательства предоставляют такую возможность прямо у себя на сайте, чем и радуют. Например, МИФ — у которых, кстати, практически отсутствует офис (пример иконических «37 signals»). Моя идея в том, чтобы создать нишевое мини-издательство, которое будет издавать книги только в виртуальном — не физическом — формате.

Как вы знаете, мы тут в своей Самаре каждый год проводим Фестиваль 404, куда приезжают разные люди и делятся опытом. Доклады записываем на видео и выкладываем совершенно бесплатно на свой канал youtube. Предлагаем подборку самых популярных видео докладов за прошлый год.

В прошлом году я уже делал такой пост. Его прочитали почти 30 000 человек. Могу скромно предположить, что этот пост тоже должен получиться интересным и полезным.

Представляю вашему вниманию перевод статьи в двух частях под названием "Can Experience be Designed?" от Oliver Reichenstein. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением компании Information Architects Inc..

Для начала загадайте число от одного до десяти. А затем сделайте шаг назад и посмотрите на словосочетание «Проектирование впечатлений пользователя» так, словно вы никогда раньше его не видели.



Смотрите внимательно на эти слова до тех пор, пока вы не услышите в своей голове волшебно красивый голос, произносящий их вслух: «ПРОЕКТИРОВАНИЕ ВПЕЧАТЛЕНИЙ ПОЛЬЗОВАТЕЛЯ». Что думаете? Все это кажется вам какой-то нелепицей? Нет, я говорю не про загадывание числа и не про шаг назад, а про идею. Идею о том, что кто-то может контролировать ваши чувства и ощущения. Или же вы с легкостью согласитесь, что ваши впечатления от прочтения этой статьи были продуманы мной как автором? Вы читаете этот текст каким-то своим, особым образом? Или вы прочитали и ощутили его так, как я это задумал?

В 60-х годах прошлого века, начало внедрения информационных систем для бухгалтерского учета в коммерческом секторе, привело к появлению новой профессии в сфере ИТ — ИТ-аудитора. Вскоре была создана первая профессиональная ассоциация ИТ-аудиторов – «Electronic Data Processing Auditors Association», целью которой стала выработка стандартов и лучших практик проведения ИТ-аудита.

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

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

В статье рассмотрены стандарты и руководства, разработанные международными организациями ISACA, Институтом Внутренних Аудиторов (IIA), ISO/IEC, IAASB (the International Auditing and Assurance Standards Board), PCAOB, и др. Для каждого из стандартов дается краткое описание структуры и особенностей их использования.

Доклад Никиты Налютина на конференции SQA Days – 13, 26-27 апреля 2013 г. Санкт-Петербург, Россия

Анонс. Новые методики тест-дизайна не всегда рождались одномоментно, не все в инженерной практике может появиться в результате только лишь одного озарения и гениальных идей, увиденных во сне. Достаточно большая часть современных практик тестирования появилась в результате кропотливой теоретической и экспериментальной работы по адаптации математических моделей. И, хотя, для того, чтобы быть хорошим тестировщиком, вовсе не обязательно быть математиком, полезно понимать, какая теоретическая база лежит в основе того или иного метода тестирования. В докладе я расскажу о том, какую базу для тестирования дает математическая логика, теория формальных языков, математическая статистика и другие разделы математики; какие направления, связанные с тестированием, существуют в теоретическом computer science; появления каких новых методов можно ожидать в ближайшее время

INTRO

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

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

Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.

Некоторое время назад я писал вводную статью о хуках (что это, зачем нужно, Hello world). Статья задумывалась простой, минималистичной и, вроде бы, такой и получилась. Единственный упрёк, который я услышал в комментариях — «Зачем же брать библиотеку Microsoft Detours, которая для коммерческого использования стоит 10 000$ ?». Замечание справедливое. В этой статье я приведу тот же пример с использованием другой библиотеки ценой примерно в 20 раз меньше (что уже вполне себе в рамках разумного) — madCodeHook.

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

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

Это статья попытка показать, что сила функциональных языков и в первую очередь Хаскеля — это в том числе и силе функторов и монад.

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

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

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

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

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

Статья изначально возникла в двухпоточном, как бы полосатом варианте. Как мог, попытался воспроизвести оригинальную верстку тут. В общем то, что отчеркнуто — это практичная полоса. Итак…

Видимые вычисления

или… О пользе бесполезного

Люди спорят.
Люди любят спорить.
Они спорят об искусстве, еде, фильмах, работе, предметах, явлениях, людях и о том, как лучше спорить.
Если не с кем поспорить снаружи, спорят с тем, кто внутри.

Есть люди, которые не спорят, которые молчат… Это временно. Это люди под впечатлением. Потом, как очухаются, они найдут привычные точки опоры для критики, они снова заспорят. То, о чем люди молчат — недолговечно, но только как акт чистого восприятия. Оно не исчезает. Будут другие, будут молчать, будут потом говорить…

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

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

Как только я опишу идею, у меня её украдут, либо реализуют конкуренты

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

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

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

Вот исходный вопрос:

Как используется ключевое слово yield в Python? Что оно делает?

Например, я пытаюсь понять этот код (**):

def _get_child_candidates(self, distance, min_dist, max_dist):
    if self._leftchild and distance - max_dist < self._median:
        yield self._leftchild
    if self._rightchild and distance + max_dist >= self._median:
        yield self._rightchild

Вызывается он так:

result, candidates = list(), [self]
while candidates:
    node = candidates.pop()
    distance = node._get_dist(obj)
    if distance <= max_dist and distance >= min_dist:
        result.extend(node._values)
        candidates.extend(node._get_child_candidates(distance, min_dist, max_dist))
        return result

Что происходит при вызове метода _get_child_candidates? Возвращается список, какой-то элемент? Вызывается ли он снова? Когда последующие вызовы прекращаются?

** Код принадлежит Jochen Schulz (jrschulz), который написал отличную Python-библиотеку для метрических пространств. Вот ссылка на исходники: http://well-adjusted.de/~jrschulz/mspace/

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

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

Agile движение имеет свой взгляд на спецификации. Наиболее экстремальное крыло выражает свои взгляды так:

В жопу спецификации!