Представьте: вы работник стартапа, сварганили по-быстрому прототип и постепенно начинаете его развивать. И вот вам уже хочется, чтобы во время очередного спешного релиза не приходилось перепроверять все разделы сайта вручную (руками директора по продукту). Конечно, можно нанять отдельного тестировщика, но на это в вашем LEAN-стартапе бюджета не дают — «лучше давайте купим наконец-то кофе-машину». Знакомо?

И тут кто-то произносит слово «автотесты».

И сразу начинается: это целая история, это очень сложно, это очень дорого, от этого будет больше вреда, чем пользы и вообще это кровавый Enterprise и СЕЛЕНИУМ.

На хабре уже было много статей о распределенных системах управления версиями (DVCS), их сравнений, а также сравнений GUI-клиентов для них. Также были обсуждения плагинов к IDE для работы с git и mercurial. Но практически не было информации об инструментах визуального сравнения и разрешения конфликтов слияния.


Недавно я «перескочил» с mercurial (который до сих пор считаю более удобным и логичным) на git, потому что, подавляющее большинство проектов, которые мне интересны, используют git и хостятся на github. В связи с этим, встал вопрос о пересмотре арсенала инструментов, в частности вопрос выбора инструмента визуального сравнения и слияния (diff and merge). Дабы восполнить недостаток информации на хабре, я решил написать этот мини-обзор. Как говориться — по горячим следам.

Под катом Вы также найдете примеры настроек Git для использования с DiffMerge и WinMerge под Windows. Думаю многим сэкономит время.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Тестирование программного кода — кропотливый и сложный процесс. Львиную долю работы в нем совершают unit-тесты. Пока они не «загорятся зеленым», тестировать дальше смысла нет.

Как же писать unit-тесты правильно? Стоит ли гнаться за 100% покрытием? С какими сложностями приходится сталкиваться инженерам на практике? Своим опытом делятся Marc Philipp и Всеволод Брекелов.

Прошло уже три месяца с тех пор, как я опубликовал свою первую статью о наших попытках масштабировать Git для очень крупных проектов при помощи инициативы, которую мы назвали «Git Virtual File System». Напомню: GVFS в сочетании с некоторыми правками в Git позволяет работать с ОЧЕНЬ большими репозиториями, виртуализируя как папку .git, так и рабочую директорию. Вместо того, чтобы скачивать репозиторий целиком и проверять все файлы, инструмент динамично скачивает только те фрагменты, которые вам нужны, выявляя их на основании того, над чем вы работали до этого момента.

За это время много чего произошло, и я хочу поделиться с вами новостями. Три месяца назад GVFS был только мечтой. Не в том смысле, что его не существовало — у нас была готовая реализация — но в том, что он еще не показал себя в деле. Мы опробовали его на больших репозиториях, но не успели внедрить в рабочий процесс для сколько-нибудь значимого количества разработчиков. Поэтому у нас было только умозрительное убеждение, что все будет работать. Теперь же у нас есть подтверждение этому.

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

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

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

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

// "Enjoy the Content" — from author with Love 

Два подхода к разработке через тестирование вызывают особенно много споров — из-за некоторого методологического сходства TDD (Test Driven Development) и BDD (Behaviour Driven Development) часто путают даже профессионалы. Старшие инженеры по автоматизации тестирования «Альфа-Лаборатории» Юлия Ковалева и Анна Чернышева рассказывают базовые вещи о сходстве и различиях двух популярных методик и то, какой подход у них используется в самой компании.

Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).

Майские каникулы — хорошее время, чтобы изучить что-то. Вот я и решил полистать все статьи из хаба GTD. В виду своего большого интереса к данной теме ранее я уже знакомился с различными материалами по личностной эффективности, в том числе в свободное время почитывал книги: Стивен Кови «Семь навыков высокоэффективных людей», Питер Брегман «Правило четырех секунд: Остановись. Подумай. Сделай», Даниел Канеман «Думай медленно… решай быстро», Дэниел Гоулман «Фокус. О внимании, рассеянности и жизненном успехе».

И что же я узнал, просмотрев такой большой объем информации, останавливаясь на самом интересном? Что там в истории от 2007 года до 2017 на 150 страницах? А ничего (почти).

В этой статье мы попытаемся рассказать, как с помощью удаленных и территориально распределенных команд мы наладили процесс выпуска прикладных решений, расширяющих функциональность нашего продукта «1С:ERP Управление предприятием 2».

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

Рассказывать о долгом и тернистом пути всегда непросто. Однако за последние годы инфраструктура разработки Яндекс.Денег сделала большой шаг в сторону автоматизации самого важного для нас процесса — релиза, о чем просто грех не рассказать. Фактически получилось полноценное решение Continuous Integration и Continuous Delivery на базе связки Bitbucket, Jenkins и Jira.

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

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

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

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

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

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

У нас в Badoo крутятся >30 самописных демонов, написанных на разных языках, и ~10 из них – на Go. Все эти демоны работают на порядка 300 серверах. Как мы к этому пришли, не получив в итоге «зоопарк», как админы с мониторингом умудряются спать спокойно, не ограничивая при этом никого в смузи, а девелоперы, QA и релизеры живут дружно и до сих пор не переругались – читайте под катом.

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

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

Начну свою первую статью с небольшой предыстории. К моменту когда все началось, я уже на протяжении 7 лет участвовал в научном проекте, целью которого была разработка семантической технологии проектирования интеллектуальных систем. А началось все с прочтения одной замечетельной статьи (спасибо vovochkin) во второй половине 2015 года. Именно тогда я понял, что разрабатываемая нами технология хорошо подходит под решение задач в области интернета вещей. Это был первый фактор который привел меня к текущему проекту. Вторым фактором было то, что мне сильно нравился фильм «Железный человек» и я сильно хотел иметь своего «Джарвиса» у себя дома.