В последнее время параллельные вычисления прочно входят в жизнь, в частности, с использованием GPU.

Здесь было много статей на эту тему, поэтому ограничусь лишь поверхностным описанием технологии. GPGPU — использование графических процессоров для задач общего назначения, т.е. не связанных напрямую с рендерингом. Пример — библиотека Nvidia PhysX для расчёта физики в некоторых современных играх. Эта технология выгодна тем, что GPU хороши на параллельном выполнении с множеством потоков. Правда, потоков должно быть много, иначе производительность сильно упадет. Ещё из-за особенностей работы с памятью приходится несколько хитрить с передачей данных из оперативной памяти в видеопамять. Известные реализации: CUDA (Nvidia, только для видеокарт), OpenCL (Khronos Group, для гетерогенных систем) и AMD FireStream. Здесь будет обсуждаться только OpenCL.

Итак, приступим к практике. В качестве языка основной программы выберем Python. Он, конечно, не очень быстр сам по себе, зато отлично работает как «клей» — во многих применениях основной расчёт идёт в OpenCL, а код на Python только «подносит патроны». Существует отличная библиотека PyOpenCL, которой и будем пользоваться.

Навеяно в ходе последних событий
Необходимость знаний математики
и
Кризис программиста

Несколько слов о программистах для студентов младших курсов и тех, кто еще только собирается поступать в институт.

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

Можно дать тысячу интерпретаций данного утверждения, но многие согласятся, что понятие «программист» несколько шире понятия «кодер». Программисты в массе своей субъективны, часто рассуждают о тех или иных темах исходя из своего личного опыта и предпочтений. А опыт и предпочтения у всех различные. Это мешает в обсуждений общих вопросов, так как каждый тянет одеяло в свою сторону.
То, что написано дальше — это только моя точка зрения.

(Разбор комментариев в конце статьи)

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

Эпопея началась в 2008 году с решения не поддаваться на шантаж компании IPAT. По словам Касперского, его лаборатория была не единственной жертвой тролля, но единственной, что принципиально не принимала никаких предложений о «мирном» разрешении проблемы.

Другие производители антивирусов выплатили IPAT от нескольких десятков тысяч до нескольких миллионов долларов.

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


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

• Бизнес архитектура
• Архитектура информационных систем (потоки данных)
• Технологическая архитектура

Таким образом, разработчики чаще всего говорят о технологической архитектуре приложения.

Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии.  Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.

Данный топик написан мной по результатам общения с представителями IT компаний, которые, заинтересовавшись циклом статей про студенческие проекты, приехали на Мат-мех в поисках людей, которых можно было бы нанять к себе в компанию. В результате найм несколько не удался, поскольку по словам нанимателей “брать на работу программистов из студенческих проектов можно только по географическому признаку”. Похоже проблема подбора квалифицированных кадров существует и стоит довольно остро. Я попытался раскрыть свои мысли по поводу того, где брать программистов или как их выращивать.

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

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:

• Модульные тесты с покрытием около 50%
• Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
• Пересечение из гибких методологий под общим названием ScrumbanXP

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

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

Наши привычки постоянно развиваются и меняются. Изменяется стиль кодирования, подход к написанию кода в целом. Обычно это хорошо, но иногда этот процесс минует некоторые плохие привычки и они надолго остаются с нами. Я хотел бы поделиться размышлениями о некоторых «не очень хороших» привычках, которые я наблюдал в себе и в других людях на протяжении многих лет. Некоторые даже могут быть не похожи на плохие…

Несмотря на то, что мировая культура в лице Википедии и Пола Маккартни уверяет нас, что Mary had a little lamb, на территории одной восьмой части суши продолжают считать, что на самом деле «У Мэри был ягнёнок». Кто же на самом деле был у Мэри, и как записать это на разных языках мира? Попробуем выяснить это (а также понять, что думают по этому поводу японцы) вместе с нашим любимым Python-ом и встроенным в него модулем поддержки многоязычных переводов gettext.

Это четвертый вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 10 мин.):

Темы и детали видеозаписи под катом

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

Некоторое время назад я загорелась желанием изучать веб-дизайн и какой-нибудь язык программирования. И, конечно же, у меня возник закономерный вопрос «с чего начать». Более того, положение дел усугублялось тем, что никакого опыта ни в веб-дизайне, ни в программировании у меня не было вообще.
Что же делать? Как учиться самой? Куда двигаться, и за что хвататься?

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

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

Если в один прекрасный момент вам ударило в голову желание насадить разумное, доброе, вечное, и пересадить всех с SVN на GIT, сразу встают три проблемы:

• Объяснить зачем это нужно разработчикам и руководству
• Ввести в обиход новую схему работы с кодом
• Научить ничего не подозревающих девелоперов новым техникам

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

(Перевод)

Последние несколько лет я провел в изучении и экспериментах со многими языками программирования. В частности, я начал использовать Scala как основной язык, стараюсь использовать функциональный стиль везде где это возможно. Меня также весьма заинтересовал Haskell (чистый функциональный язык) и Clojure (современный диалект Лиспа).

Таким образом, я постепенно отказываюсь от объектно-ориентированной парадигмы, несмотря на то, что использовал в основном её последние 17 лет моей профессиональной деятельности. У меня появляется чувство, что объекты это то, что мешает нам писать лапидарный, структурированный и повторно используемый код.

Многочисленные статьи, посвященные TDD в общем и Unit-тестам в частности, как правило, оперируют довольно искусственными примерами. Например, давайте напишем функцию, которая складывает два числа и напишем для неё тест. Честно говоря, на таких примерах трудно оценить преимущества использования автоматизированных тестов.

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

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

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

Локализация здесь осуществляется довольно нехитро. Все строки, требующие перевода, оборачиваются в макрос _TR():

wprintf(L"%s\n", _TR("Some translating string"));

Макрос возвращает нужную версию текста в зависимости от текущего используемого языка. Определён он следующим образом:

#define _TR(x) g_Translator.Translate(x)

Здесь происходит обращение к глобальному объекту g_Translator, который в функции Translate() считает в рантайме crc32 от указанной строки, ищет в своей xml-базе перевод с совпадающей контрольной суммой и возвращает его.

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

Немного погуглив по запросу «compile-time crc32» я быстро понял, что задача это не самая тривиальная, а готовых решений мне найти так и не удалось.

Согласитесь, каждый раз, когда вы видите человека, который использует Vim, вам кажется, что он знает то, чего не знаете вы. Иначе, как вы можете объяснить тот факт, что он использует редактор, который, по вашему мнению, является open-source мусором? Думайте, что хотите, но есть целый ряд причин, по которым програмисты поклоняются Vim.
Пока вы не потратите по крайней мере месяц на ознакомление с ним, вы, несомненно, будете его ненавидеть. Именно по этой причине большинство новичков работают с Vim около дня, после чего больше никогда к нему не притрагиваются. Они даже представить себе не могут, какой невероятной скоростью и гибкостью он обладает. Нужно всего-лишь найти в себе силы и преодолеть те трудности, которые встретятся вам на протяжении всего того времени, что вы знакомитесь с Vim.

Большинство из нас проходили русский язык. Но, так как это происходило в переходном возрасте, мы проходили его мимо. Кто-то в это время работал, кто-то занимал первые места на спортивных соревнованиях, кто-то играл на приставках, а большинство вкладывали всё своё доступное время в общение с компьютером.

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

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

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

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

Мотивация

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

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

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

С технической точки зрения юнит-тесты – это очень простой инструмент, основанный на паре несложных концепций: (1) тестируемый класс, (2) набор тестовых методов, завернутых в некоторый класс и (3) набор методов, с помощью которых можно удостовериться в том, что состояние тестового класса соответствует (или не соответствует) некоторому значению.

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach"), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.