Когда проект маленький, особых проблем с ним не возникает. Список задач можно вести в текстовом файле (TODO), систему контроля версий, по большому счёту, можно и не использовать, для раскладки файлов на живой сервер их можно просто скопировать (cp/scp/rsync) в нужную директорию, а ошибки всегда можно посмотреть в лог-файле. Глупо было бы, например, для простенького сервиса с двумя скриптами и тремя посетителями в день поднимать полноценную систему управления конфигурациями серверов.

С ростом проекта требования растут. Становится неудобно держать в TODO-файле несколько десятков задач и багов: хочется приоритетов, комментариев, ссылок. Появляется необходимость в системе контроля версий, специальных скриптах/систем для раскладки кода на сервер, системе мониторинга. Ситуация усугубляется, когда над проектом работает несколько человек, а уж когда проект разрастается до нескольких серверов, появляется полноценная инфраструктура («комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы», Wikipedia).

На примере нашего сервиса "Календарь Mail.ru" я хочу рассказать о типичной инфраструктуре и жизненном цикле разработки среднего по размерам веб-проекта в крупной интернет-компании.

Пакет Intel Parallel Studio XE давно известен разработчикам, в том числе и по публикациям в блоге Intel на Хабре. Недавно вышло обновление - Intel Parallel Studio XE 2013 Service Pack 1 (SP1), имеющее ряд интересных новшеств. Становится проще программировать для со-процессоров и встроенной графики, во многом благодаря поддержке стандарта OpenMP 4.0 (частичной). Поиск ошибок стал гибче, утечки памяти теперь обнаруживаются до завершения процесса, т.е. их можно искать в долгоиграющих сервисах и «падающих» приложениях. Найти узкие места в производительности будет легче благодаря новому представлению дерева вызовов, оценке накладных расходов и детальной информации о параллельных конструкциях.

Игровой цикл — это пульс каждой игры. Ни одна игра не будет работать без этого. Однако, к несчастью каждого нового разработчика игр, в сети нет хороших статей, в которых уделено достаточное внимание этой теме. Но не печальтесь, потому как только что вы получили возможность прочитать единственную в своем роде статью, уделяющую вопросу игровых циклов заслуженное внимание. По долгу службы мне часто приходится иметь дело с большим количеством кода мелких мобильных игр. И я каждый раз удивляюсь сколь много существует реализаций игрового цикла. Вы тоже можете удивиться как можно для такой, казалось бы простой, вещи можно придумать множество имплементаций. А ведь можно! И в статье я постараюсь рассказать о достоинствах и недостатках наиболее популярных вариантов игровых циклов. Также я постараюсь описать наилучший на мой взгляд вариант реализации игрового цикла.
(Thanks to Kao Cardoso Félix this article is also available in Brazilian Portuguese) (Thanks for me, in Russian also, прим. перев.)

На прошедшем неделю назад чемпионате мира по командному программированию ACM ICPC 2013 было 11 задач, одну из которых за отведённое время не смогла решить правильно ни одна из команд.

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

В этом году на ACM ICPC был 21 аналитик из Швеции, Нидерландов, США, Словакии, Беларуси и России. И 10 из них были из Яндекса. Все они в разные годы были призёрами ICPC. Специально для Хабра они разобрали все задания чемпионата.

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

Уже три года я публикую регулярные обзоры свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-май 2013.

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

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

Часть 1: Введение
Часть 2: Многопоточность
Часть 3: Рендеринг (Прим. пер. — в процессе перевода)
Часть 4: Doom classic — интеграция (Прим. пер. — в процессе перевода)

Движок для Doom III был написан в период с 2000 по 2004 год, в то время, когда большинство ПК были однопроцессорными. Хотя архитектура движка idTech4 разрабатывалась с учетом поддержки SMP, это закончилось тем, что поддержка многопоточности делалась в последнюю минуту (см. интревью с Джоном Кармаком).

Долгожданные итоги конкурса сил Android и iOS developer-ов на место в Dream-Team команде ZeptoLab, наконец, подведены. За эти полгода мы что обещали – сделали: подросли в 2 раза и концептуально оформили нашу обитель:


Как это было

Так сложилось, что по мере рабочей необходимости мне приходится интенсивно использовать C++/CLI и, соответственно, довольно часто объяснять новичкам, что это, как работает, как использовать и, зачем вообще надо. Так что со временем появилось желание написать статью с обзором языка, ответами на некоторые распространенные вопросы и показать места, где могут удачно лечь грабли.

Что это?

Когда Microsoft создавала платформу .Net, то она решила дать программистам писать под нее на нескольких уже существующих языках, в синтаксис которых были внесены некоторые изменения — VB, C++. Речь пойдет именно о последнем. Точнее, если мне не изменяет память, в первой редакции язык назывался C++ with managed extensions. Название как бы само намекает на сущность — вот мы вам дали плюсы с расширениями и теперь вы сможете разрабатывать под .Net на уже известных C++, при этом оставив всю мощь исходного языка.

Совсем недавно в ходе разработки одного проекта передо мной встала задача поиска удобного средства для написания юнит-тестов на C++. К каким результатам привело моё исследование подробнее в этой статье.

Введение

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

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

Это перевод статьи Being a Remote Worker Sucks — Long Live the Remote Worker Скотта Хенселмана за 27 февраля.

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

Работать удалённо – прекрасно, отстой.

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

Компания 37 signals — один из пионеров рынка SaaS и создатель фреймворка Ruby on Rails, знаменита не только своими софтверными продуктами, но и книгами Джейсона Фрида и Дэвида Хейнемейера Ханссона — Getting Real и Rework — которые основаны на реальном опыте разработки популярного софта и построения успешной компании. Обе книги стали бестселлерами. Осенью этого года выходит третья книга 37 signals под названием REMOTE: Office Not Required. Она посвящена преимуществам и организации удалённой работы.

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

Сегодня, 21 февраля 2013 года, компания Xamarin объявила о выходе Xamarin 2.0. Xamarin — компания, созданная разработчиками Mono, MonoTouch и Mono for Android, кросс-платформенной реализации платформы .NET.



На данный момент стоимость разработки под iOS в Visual Studio оценивается в 999 U.S$

Существует возможность скачать Starter Edition, которая позволяет писать не более 32к скомпилированных(?) строк кода, которые, по их мнению, будут достаточными для всех мини-приложений. Поддержка отсутствует. Купить/скачать — store.xamarin.com

via TechCrunch

В определенный момент мне стало некомфортно использовать стандартный контрол WebBrowser, предлагаемый Visual Studio.
Причин было несколько:
1. Использовался IE-движок, что само по себе уже сильный аргумент.
2. Кривая работа с JS.
3. Отсутствие масштабирования.
4. Если запустить на машине, где стоит IE6, то все его «достоинства» переносятся на приложение.

В итоге был начат поиск альтернативных решений.
Было рассмотрено 2 SDK. xulrunner(Mozilla) и Awesomium(Chrome)

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