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

• действия выполняются вручную, что требует сосредоточенности и аккуратности;
• жёсткие временные рамки.

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

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

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

Сегодня наш гость — Максим Зелинский из компании «Сбербанк-Технологии». В его компании много внутренних проектов. Максим предлагает лайфхак, который подходит для тех, кто не считает себя гениями-многостаночниками.

В этой статье речь снова пойдет о сертификации. Не так давно я рассказывал о процессе получения сертификата от компании Google для Android разработчиков. Почитать об этом можно вот здесь. В статье я периодически приводил сравнение с процессом получения сертификатов от Oracle. Немного подумав, я решил раскрыть эту тему подробнее, благо сертификат от Oracle я получил полгода назад и еще не все забыл. Естественно, на хабре уже не раз описывали этот процесс. Например, достаточно подробные описания можно найти тут и тут. Однако, указанные статьи были написаны несколько лет назад, и затрагивают Java SE 7. Я же постараюсь сосредоточиться на особенностях экзамена по Java SE 8 и в принципе обновить информацию по процессу получения сертификата. Тех, кому все еще интерсено, прошу под кат.

Здравствуйте, хабрапользователи! В этой статье речь пойдет о предметно-ориентированном проектировании программного обеспечения с использованием, в первую очередь, стратегических шаблонов. Вторую часть – про тактическое проектирование – читайте здесь.

Данный подход использовал Вон Вернон в своей книге «Реализация методов предметно-ориентированного проектирования». Цель написания этой книги: дать возможность разработчикам совершить полет на самолете DDD (в детстве автор зачастую путешествовал со своей семьей на небольших самолетах). Вид с высоты дает более широкое представление о проблемах моделирования, не давая застрять в различных технических деталях. Наблюдая ландшафт DDD таким способом, можно осознать преимущества как стратегического, так и технического проектирования. Подробнее – под катом!

«Ментальная карта… Опять эзотерика?» — подумала я, впервые прочитав это название больше полугода назад. Потом вникла, попробовала нарисовать в таком формате свои планы на неделю. Получилось на удивление легко и интересно.
Здесь бы я могла написать, что с тех пор я стала пользоваться картами постоянно, но это не так. Я про них забыла. И вспомнила лишь в августе, когда планировала поездку в отпуск. Вот что из этого получилось.

Александр Крижановский (NatSys Lab.)

Нас сегодня будет интересовать операционная система – ее внутренности, что там происходит… Хочется поделиться идеями, над которыми мы сейчас работаем, и отсюда небольшое вступление – я расскажу о том, из чего состоит современный Linux, как его можно потюнить?

По моему мнению, современная ОС – это плохая штука.

Дело в том, что на картинке изображены графики сайта Netmap (это штуковина, которая позволяет вам очень быстро захватывать и отправлять пакеты сетевого адаптера), т.е. эта картинка показывает, что на одном ядре с разной тактовой частотой до 3 ГГц Netmap позволяет 10 Гбит – 14 млн. пакетов в сек. отрабатывать уже на 500 МГц. Синенькая линия – это pktgen – самое быстрое, что, вообще, есть в ядре Linux’а. Это такая штуковина – генератор трафика, который берет один пакет и отправляет его в адаптер много раз, т.е. никаких копирований, никакого создания новых пакетов, т.е., вообще, ничего – только отправка одного и того же пакета в адаптер. И вот оно настолько сильно проседает по сравнению с Netmap (то, что делается в user-space показано розовой линией), и оно вообще где-то там внизу находится. Соответственно, люди, которые работают с очень быстрыми сетевыми приложениями, переезжают на Netmap, Pdpdk, PF_RING – таких технологий море сейчас.

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

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

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

Акронис на прошлой неделе попросил меня рассказать про опыт на Хабре. После семинара я обещал выложить основные тезисы. Возможно, вы найдёте что-то полезное ниже.

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

При этом активных (голосующих) пользователей всего около 3 тысяч. Уровень знаний аудитории на входе в пост — в примерно 95% случаев низкий, в 5% — экспертный (разбиение оценочное). Проще говоря, есть люди, которые вообще не понимают, что вы хотите сказать (и их большинство), и есть те, кто разбирается в теме на голову лучше вас. Поэтому лучший пост — это тот, что проходит от ликбеза к хардкору. На площадке довольно высокий уровень агрессии (точнее, желания проверить материал на прочность). Ранее был экстремально высок. Средняя или низкая внимательность читателя (ранее была высокая).

Разумеется, это всё моё личное мнение, и можно поспорить. Сейчас постараюсь объяснить, почему я так считаю, и как это влияет на посты. Я основываюсь на опыте примерно 1500 постов за 6 лет, которые написал сам или помогал готовить.

Но начнём с численных показателей. Вот эти компании так или иначе вызвали мой интерес тем, что для них работают агентства или выделенный инхаусный пиар:


^{Данные тут на конец августа, я их к другому семинару (в Хабре для владельцев блогов) готовил.}

Представьте, что вам дали задачу поправить часть кода. В голове возникнет много мыслей. Кто его написал? Когда? А может он — legacy? Где документация? Давайте попробуем разобраться с «наследием» основательно и со всех сторон. Поможет нам в этом вопросе Андрей Солнцев @asolntsev (http://asolntsev.github.io/), разработчик из таллинской компании Codeborne. Начнём.

— Андрей, вы знакомы с трудами Michael Feathers, например, «Working Effectively with Legacy Code»? В книге акцентируется внимание на важности тестирования и выделяется одно из ключевых отличий legacy от не legacy-кода — это наличие тестов. Вы согласны с этим мнением?

Абсолютно согласен! Скажу больше: юнит-тесты — необходимое, но недостаточное условие. И с юнит-тестами можно навалить так, что сам Геракл не разгребёт.
Что для настоящего джедая мастхав, так это:

1. TDD — то есть тесты ДО кода.
   
2. Чистый код (и чистые тесты).
   

Я очень люблю книгу Robert C. Martin «Clean Code» («Чистый код»). Это для меня настольная библия. Категорически всем советую. Кстати, его блог тоже великолепен.

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

Эта статья — выражение моей личной боли. Кнопочные решения портят мне жизнь, я трачу время на споры и обоснования.

Когда мы общаемся с коллегами, заказчиками или пользователями, я использую фразу «кнопочное мышление». Что я имею ввиду под этим термином? Текущая статья — развернутый ответ на этот вопрос.

Синонимами кнопочного мышления я считаю «экранное мышление» или преждевременную концептуализацию. Я раскрою мышление кнопками на десятке примеров из практики. А здесь для начала история, которая наверняка случалась с каждым. Представьте к вам приходят и рассказывают о падении конверсии на сайте. А вы ему сразу: «Давайте кнопку покупки сделаем побольше и поярче!». Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Вот в таких случаях я говорю о кнопочном мышлении.

Для тех, кто любит смотреть, а не читать, есть видео и слайды.

Доброго времени суток! Решил поделиться с Вами историей, о совсем не тривиальном, как оказалось, решении проблемы воспроизведения качественного видео потока на Fedora 17 x86-64. До недавнего времени, проводя свободные часы за своим нетбуком (Asus 1215B, E-450, 8Gb RAM, 500Gb SATA), я считал, что меня всё устраивает. Хождение по интернетам, музыка, фильмы (в основном dvdrip'ы), игры (сейчас модно в старый-добрый Half-Life зарубить), всё работало без нареканий, пока мне не захотелось посмотреть фильм с пометкой 1080p. Стоявшая при покупке Windows 7 Home x64, в связке с K-Lite+MPC, без особых проблем справлялась с такими задачами, поэтому я, без задней мысли, дважды ткнул курсором в файл и приготовился к просмотру. Сказать что видео поток тормозил — ни сказать ничего! Небезызвестный параметр «Frames Per Second» превратился в «Seconds Per Frame», а настроение упало ниже плинтуса. И началось курение мануалов!

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


Скала Улуру в Австралии как пример монолита — КДПВ, не более

Что такое монорепозиторий?

Определения разнятся, но мы будем считать репозиторий монолитным при выполнении следующих условий:

• Репозиторий содержит более одного логического проекта (например, iOS-клиент и веб-приложение)
• Эти проекты могут быть не связаны, слабо связаны или связаны сторонними средствами (например, через систему управления зависимостями)
• Репозиторий большой во многих смыслах:
  
  • По количеству коммитов
  • По количеству веток и/или тегов
  • По количеству файлов
  • По размеру содержимого (то есть размеру папки .git)

Я обнаружил эту уязвимость, исследуя возможность перехвата одноразовых паролей, которые отправлялись банком поставщику телекоммуникационных услуг, а затем поступали на специальное приложение SIM-карты и выводились на пользовательский интерфейс Android.

Последняя статья про классические примитивы синхронизации.

(Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

Сегодня мы немножко заглянем в процессор. Чуть-чуть.

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

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

На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

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

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

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

Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

Как устроен спинлок?

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

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

Джефф — основатель StackOverflow. Ныне он работает над проектом Discourse.

Оригинальная статья: Is Your Computer Stable?

Дисклеймер: Хоть статья и называется "Надёжен ли твой компьютер?", речь идет не о надёжности как термине(англ. reliability), а, скорее, о стабильности (англ. stability). Статья о том, как автор тестирует новые компьютеры на стабильность и прочность.


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

Например, вот что может понадобится для сборки Scooter Computer:

1. Нанести немного термопасты на верхнюю часть корпуса.
2. Поместить в корпус материнскую плату.
3. Прикрутить материнскую плату к корпусу.
4. Вставить плату SSD.
5. Вставить плату RAM.
6. Подключить внешнее питание.
7. Загрузиться.

Вот и все.



Это до смешного просто. Мы с моим шестилетним сыном собирали конструкторы Лего, которые были намного сложнее. Сборка традиционных ПК отличается всего парой дополнительных шагов: вставить процессор, радиатор, подключить кабели. И, наконец, сборка сервера добавляет еще пару незначительных действий, возможно, с ограничениями на размер сборки. Мини-компьютер, обычный ПК или сервер — если вы смогли собрать один из них — считайте вы собрали их все.

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

Здравствуйте, меня зовут Евгений, и я веб разработчик. Несколько лет назад мне перепала функция DBA (Database Administrator), я получил по этому поводу несколько сертификатов и решал соответствующие задачи. Я давно хотел описать задачу версионирования базы данных, но мне казалось, что для этого должны быть какие-то беспроигрышные варианты, которые хорошо знают умелые дяди, а я просто чего-то недопонимаю. Вчерашнее собеседование и последующий поиск по тематическим ресурсам показал, что это не так, и задача действительно сложна, актуальна и не решается однозначно. Разберём её по пунктам.

Что мы версионируем

Мы используем контроль версий только для DDL (Data Definition Language) запросов. Сами данные нас не интересуют. Почему? Рассмотрим два крайних случая.

1. Данных мало (скажем, менее 50 мегабайт). В этом случае, мы можем просто периодически делать полный дамп базы и смело складывать его в репозиторий.
2. Данных много (больше гигабайта). В этом случае версионирование нам мало поможет, всё равно разобраться в этом будет довольно проблематично. Целесообразно в данном случае использовать стандартную схему с бекапами и архив логом, которая позволяет нам получить целостную версию базы на любой момент во времени.

Хотел бы поделиться простым, но полезным инструментом. Когда много работаешь с данными, часто возникают примитивные, но долгие операции, например: «скачать 10 000 урлов», «прочитать файл на 2Гб, и что-то сделать с каждой строчкой», «распарсить 10 000 html-файлов и достать заголовки». Долго смотреть в зависший терминал тревожно, поэтому долгое время я использовал следующий гениальный код:

def log_progress(sequence, every=10):
    for index, item in enumerate(sequence):
        if index % every == 0:
            print >>sys.stderr, index,
        yield item

Эта функция прекрасна, больше года она кочевала у меня из задачи в задачу. Но недавно я заметил в стандартной поставке Jupyter виджет IntProgress и понял, что пора что-то менять:

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

Вступление

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