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

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

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

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

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

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

Все компании разные, но между лучшими техническими руководителями, с которыми мне довелось работать, существует кое-что общее. Снимаю шляпу перед Брайаном Столером, Натаном Хантом, Эваном Гилбертом и Ричем Бердоном за то, что послужили мне хорошим примером.

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

Качества

Вы всегда должны улучшать три своих качества: компетентность, скорость и осведомленность.

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

Для тех, кто не любит много читать и хочет знать все ответы сразу — напишу в первых строках этой небольшой статьи, что, по моему скромному опыту, в «топ» App Store попасть ужасно трудно, и для этого требуется приложить недюжинные усилия. Более того, скажу вам, что крупные издатели вылезают в «топ» именно за счет налаженной работы с журналистами, блогерами и всевозможными порталами пишущими про мобильные приложения, ну и разумеется за счет четко налаженной системы маркетинга приложений, направленной на увеличение количества скачиваний. Чуть легче «запихнуть» в топ бесплатное приложение, это разумеется при условии, что Apple его заметит и поставит в «New & Noteworthy» (Новое и Заслуживающее внимания) в App Store. Ну а теперь обо всем по порядку.

Введение

Данная статья является продолжением цикла статей: Использование паттерна синглтон [1], Синглтон и время жизни объекта [2], Обращение зависимостей и порождающие шаблоны проектирования [3], Реализация синглтона в многопоточном приложении [4]. Сейчас я хотел бы поговорить о многопоточности. Эта тема настолько объемна и многогранна, что охватить ее всю не представляется возможным. Здесь я заострю внимание на некоторых практичных вещах, которые позволят вообще не думать о многопоточности, ну или думать о ней в крайне минимальном объеме. Если говорить точнее, то думать о ней только на этапе проектирования, но не реализации. Т.е. будут рассмотрены вопросы о том, как сделать так, чтобы автоматически вызывались правильные конструкции без головной боли. Такой подход, в свою очередь, позволяет значительно уменьшить проблемы, вызванные состояниями гонок (race condition, см. Состояние гонки [5]) и взаимными блокировками (deadlock, см. Взаимная блокировка [6]). Этот факт уже сам по себе представляет немалую ценность. Также будет рассмотрен подход, который позволяет иметь доступ к объекту из нескольких потоков одновременно без использования каких-либо блокировок и атомарных операций!

Эта статья является продолжением предыдущей и второй из общей серии биографий. На этот раз я рассмотрел несколько фамилий, которые более известны среди любителей JS.

В любой профессии есть тонкая прослойка людей, которые являются действительно высококлассными специалистами. Не исключение и область фронт-енд разработки — здесь также есть выдающиеся личности. К их мнению прислушиваются, за ними следят в блогах и социальных сетях и читают их книги. В процессе своей работы они рождают различные оригинальные решения или техники, которые мгновенно расходятся по миру веб-разработки и остаются актуальными не один год. Они создают удобные онлайн-сервисы для верстки, пишут полезные js-библиотеки, совершенствуют браузеры, пропагандируют веб-стандарты и оказывают непосредственное влияние на их развитие. Они могут называть себя front end engineer, front-end developer, web developer, web designer, UI Designer, browser compatibility expert или просто css lover, но для большинства из нас они — звезды мирового фронт-енда, которые делают интернет таким, каким мы его знаем. На Хабре довольно часто появляются обзоры интересных решений, техник и новостей из мира веб-разработки с указанием западных авторов, однако далеко не все знают что-нибудь о них кроме имени. Мне захотелось вкратце рассказать для широкой публики о некоторых из этих товарищей.

Некий dypsilon выложил на GitHub огромную коллекцию ссылок на ресурсы по веб-разработке, за что ему огромное спасибо.

Список состоит из ссылок на библиотеки, руководства и статьи.

Frontend: github.com/dypsilon/frontend-dev-bookmarks
Backend: gist.github.com/dypsilon/5819528 (много node.js)

Ссылок много, но все — строго по делу и упорядочены по группам (пример для фронтенда):

1. Архитектура
2. Фреймворки
3. Cross Browser
4. Cross Device
5. Паттерны и сниппеты
6. Манипуляция с DOM
7. … и многое другое

matmuchrapna советует еще frontdesk Вячеслава Олиянчука.
Настоятельно рекомендуется добавить в закладки, а лучше — почитать.

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

Перевод статьи Дэвида Альберта — Understanding C by learning assembly.

В прошлый раз Аллан О’Доннелл рассказывал о том, как изучать С используя GDB. Сегодня же я хочу показать, как использование GDB может помочь в понимании ассемблера.

Уровни абстракции — отличные инструменты для создания вещей, но иногда они могут стать преградой на пути обучения. Цель этого поста — убедить вас, что для твердого понимания C нужно также хорошо понимать ассемблерный код, который генерирует компилятор. Я сделаю это на примере дизассемблирования и разбора простой программы на С с помощью GDB, а затем мы используем GDB и приобретенные знания ассемблера для изучения того, как устроены статические локальные переменные в С.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

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

• веб-версии у почтовых провайдеров (Gmail, Yandex, Mail, Yahoo итд.)
• десктопные почтовые клиенты (Outlook, Bat, Thunderbird, Mac Mail)
• мобильные почтовые клиенты (Blackberry, Android, Iphone, Ipad итд)

К сожалению, не существует обязательного стандарта верстки писем, который бы универсально поддерживался бы всеми клиентами. Часть поддерживает CSS3, часть нет, какие-то теги и аттрибуты поддерживаются, какие-то нет, не говоря уже о том, что поддержка HTML и CSS меняется даже в пределах одного почтового клиента от версии к версии. Последнее особенно заметно на примере Outlook (от Express и 2003 к Outlook 2011).

Что же необходимо знать тем, кто собирается самостоятельно верстать HTML-код для email-писем?

Что вам кажется привлекательней: сталкиваться с новыми интересными задачами и разрабатывать нетривиальные алгоритмы или переписывать с одного языка на другой уже существующую логику и воевать со странными особенностями конкретных API? Я занимаюсь мобильной разработкой уже лет 8, и, не раздумывая, выбираю первый вариант, но и повоевать с API тоже люблю. Тем, кто со мной согласен, но еще не знает, как заниматься первым и сводить к минимуму второе, будет интересно заглянуть под кат.

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

В этом посте будут рассмотрены вопросы верстки при создании нативных приложений для android. Той верстки, которая описывается в xml файлах из директории res/layout/ Итак начнем:
Существует пять стандартных типов верстки:

• AbsoluteLayout
• FrameLayout
• LinearLayout
• RelativeLayout
• TableLayout

Введение от автора поста

Имея опыт разработки ПО для ответственных систем более чем 8 лет, хочу познакомить сообщество с некоторыми материалами, связанными с разработкой и верификацией ПО для ответственных систем (аэрокосмическая область, медицина, транспорт и промышленность). Получив согласие на перевод и адаптирование ряда интересных статей у зарубежных коллег решил воспользоваться данным ресурсом. Буду рад, если статья заинтересует наше сообщество. В статье использованы материалы фирмы Vector Software, Inc.
На вопросы отвечу в комментариях или в личку

Какой Вы используете инструмент тестирования?

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

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

Вы не сможете оценить инструмент тестирования, прочитав его спецификацию

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

В продолжении статьи о кроссплатформенной и кросс-аппаратной оптимизации, на примере задачи поиска полным проходом по таблице из 5 полей и 10 000 000 строк, и неизбежности этой задачи даже при индексном поиске, я покажу как ускорить такой поиск в 3.5-5.3 раза с использованием C++ независимо от аппаратной платформы.
В предыдущей статье нам удалось ускорить поиск в 1.3 раза: GitHub.com
Мы не будем банально описывать конструкции языка, а покажем преимущества C++ при решении одного из этапов реальной задачи.
Мы по-прежнему пишем кроссплатформенно под MSVC11(MSVS2012) и GCC 4.7.2, и используем в них C и частично реализованный стандарт C++11.
Для упрощения понимания мы все ещё пишем без индексного поиска, но это решение в дальнейшем будет использоваться при индексном поиске.

Существует мнение, что C++ имеет заметные накладные расходы по сравнению с C и поэтому он медленнее. Помимо этого, даже, существуют статьи показывающие преимущества в скорости языков с компиляцией налету (JIT — Just-in-time compilation), таких как Java и C#. Сравнить последние мы оставим тем, кто считает их быстрыми, но мы объясним почему это не так. А C и C++ мы сравним на примере задачи поиска данных.
Задача поиска данных часто встречается в: веб-сервисах, системах управления баз данных (СУБД), гео-поиске и аналитике.
Сначала для простоты объяснения поставим задачу поиска элементов полным проходом по массиву из 10 000 000 элементов (структур), содержащих 5 полей с диапазонами значений: amount_of_money(0-1000000), gender(0-1), age(0-100), code(0-1000000), height(0-300). А в следующих статьях добавим в решение индексный поиск.
Мы будем писать кроссплатформенно под MSVC11(MSVS2012) и GCC 4.7.2, и использовать в них частично реализованный стандарт C++11.

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