В детстве я редко ходил в залы аркадных автоматов, потому что особо в них не нуждался, ведь дома у меня были потрясающие игры для C64… но есть три аркадные игры, на которые у меня всегда находились деньги — Donkey Kong, Dragons Lair и Outrun…

… и я очень любил Outrun — скорость, холмы, пальмы и музыка, даже на слабой версии для C64.


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

Итак, вот мой «проект на выходные», который в итоге занял пять или шесть недель по выходным

• Сыграть в игру
• Посмотреть исходный код

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

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

Можно также поиграть

• в демо с прямой дорогой
• в демо с кривыми
• в демо с холмами
• в готовую версию

PSR — Чуть больше, чем стиль оформления кода.

Как показала практика, многие PHP-разработчики знакомы с аббревиатурой PSR. Однако большинство все еще ограничены знанием, что PSR это стандарт оформления кода.

Ребята из PHP-FIG (PHP Framework Interop Group), группа концепций совместимости PHP, которые занимаются развитием PSR (PHP Standards Recommendations) шагнули далеко вперед. Поэтому давайте разберемся, что из себя представляет PSR…

Привет, Хабр! Представляю вашему вниманию перевод статьи Why Development Teams are Slow: Common Software Jams and Solutions автора Эрика Эллиота.



Если вы больше любите слушать, чем читать, то в аудио формате перевод доступен на Яндекс.Музыке и в Apple Podcasts

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

• Нереалистичные ожидания
• Слишком много открытых тикетов
• Неконтролируемый объем задач
• Накопление код ревью
• Плохая подготовка
• Выгорание разработчиков
• Баги
• Текучка кадров

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

Часть 1: Web / Android

Примечание: данная статья является переводом на русский язык оригинальной статьи «DevOps tools are not only for DevOps. Building test automation infrastructure from scratch». Однако все иллюстрации, ссылки, цитаты и термины сохранены на языке оригинала, чтобы избежать искажения смысла при переводе на русский язык. Желаю вам приятного изучения!

Оценивая свою работу, я недавно много размышлял о том, как мне писать хороший код. Учитывая, что никто не интересуется тем, как писать плохой код, возникает вопрос: как узнать, что ты написал на Go хороший код? Если есть какая-то шкала между хорошо и плохо, то как понять, какие части шкалы относятся к хорошему? Каковы его свойства, атрибуты, отличительные признаки, паттерны и идиомы?

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

Сегодня я хочу затронуть тему ESLint'а, прекрасного инструмента для проверки JavaScript проектов на наличие ошибок.

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

Сегодня Lifext расскажет:

• Так ли плох холестерин, как его малюют?
• Как узнать свой уровень?
• Что стало с мужчиной, который съедал 25 яиц в день?
• Триумф и крах обезжиренных диет;
• А сахар то здесь каким боком?
• История: тайны судмедэкспертов;
• Выводы Lifext;

Сегодня мы будем разрабатывать desktop приложение на Golang

Разработка golang desktop приложения — не совсем типичная задача для golang программиста.

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


Посмотрите или прочитайте доклад Алексея Катаева на Saint TeamLead Conf, если не знаете, по каким формальным признакам определить классная ли у вас команда. Если хотите уметь измерять технический долг в часах, а не оперировать категориями «совсем чуть-чуть», «сколько-то», «ужасно много». Если ваш продакт-менеджер считает, что команда из трех человек за месяц сделает 60 задач — покажите ему эту статью. Если ваш руководитель обвешал разработку метриками и предлагает вам принимать меры на основе результатов вроде: «34% считают, что в команде есть проблема с планированием», этот доклад для вас.

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

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

Решение — под катом.

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

Итак, имеем карандаш:

На конференциях и в неформальных беседах на работе нет-нет да и возникает разговор о важности работы QA-инженера и его роли в проекте. Это может быть и робкий вопрос коллеги-программиста «А, может, выпустим без QA?», и объёмный доклад.

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

Привет, Хабр. Меня зовут Антон Титов, CTO компании Spiral Scout. Сегодня я хотел бы рассказать вам про нашего PHP-слона. А точнее про вторую версию опен-сорсного full-stack PHP/Go фреймворка — Spiral.

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

Фреймворк совместим с большинством PSR рекомендаций, поддерживает MVC и работает в 5-10 раз быстрее Laravel/Symfony.

Если вы никогда не слышали о Spiral и гадаете, что такое PHP/Go фреймворк и куда делась первая версия — добро пожаловать под кат.

7 ноября на конференции HighLoad++ 2017, в секции «DevOps и эксплуатация» прозвучал доклад «Лучшие практики CI/CD с Kubernetes и GitLab». В нём мы делимся практическим опытом решения проблем, возникающих при построении эффективного процесса CI/CD на базе указанных Open Source-решений.

По традиции рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде.

Прим. перев.: Этой статьёй мы открываем цикл публикаций про пакетный менеджер для Kubernetes, который активно используем в повседневной работе, — Helm. Оригинальным автором материала является Matt Butcher — один из основателей проекта Helm, работающий над Open Source-проектами в Microsoft и написавший 8 технических книг (в частности, «Go in Practice»). Однако статья дополнена нашими (местами — обширными) комментариями, а в скором времени будет ещё больше расширена новыми заметками по Helm более практической направленности. ОБНОВЛЕНИЕ (03.09.2018): вышло продолжение — «Практическое знакомство с пакетным менеджером для Kubernetes — Helm».



В июне Helm перешёл из статуса ведущего проекта Kubernetes в фонд Cloud Native Computing Foundation (CNCF). CNCF становится родительской организацией для лучших в своём роде cloud native-инструментов с открытым исходным кодом. Поэтому большая честь для Helm стать частью такого фонда. И наш первый значимый проект под покровительством CNCF по-настоящему масштабный: мы создаём Helm 3.

Привет, я Юрий Буйлов, занимаюсь разработкой в CarPrice, а также внедряю практики DevOps, микросервисы и Kubernetes. Хочу рассказать про Kubernetes в духе пиратства — только не про управление большим красивым кораблем на парусах, а, скорее, про флот маленьких неприглядных рыбацких лодочек, местами ржавых, но очень быстрых, шустрых и опасных.

Будет интересно тем, кто разрабатывает или переводит инфраструктуру на микросервисы, внедряет DevOps поверх Kubernetes и всячески идет в cloud native. Расскажу про наш путь, в конце статьи поделюсь нашими наработками окружения для микросервисов — дам ссылку на шаблон, который будет удобен для разработчиков и тестировщиков.

Эта статья — по видео выступления на конференции @Kubernetes Conference by Mail.ru Cloud Solutions, если не хотите читать, можно посмотреть.

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

В данной статье речь пойдет, как писал выше, о платформе SonarQube. Немного теории — что это такое вообще, для тех, кто слышит о ней впервые:

SonarQube (бывший Sonar) — платформа с открытым исходным кодом для непрерывного анализа (англ. continuous inspection) и измерения качества кода.
Поддерживает анализ кода и поиск ошибок согласно правилам стандартов программирования MISRA C, MISRA C++, MITRE/CWE и CERT Secure Coding Standards. А также умеет распознавать ошибки из списков OWASP Топ-10 и CWE/SANS Топ-25 ошибок программирования.
Несмотря на то, что платформа использует различные готовые инструменты, SonarQube сводит результаты к единой информационной панели (англ. dashboard), ведя историю прогонов и позволяя тем самым увидеть общую тенденцию изменения качества программного обеспечения в ходе разработки.

Более подробно можно узнать на официальном сайте

Поддерживается большое количество языков программирования. Судя по информации из ссылки выше — это более 25 языков. Для поддержки конкретного языка необходимо установить соответствующий плагин. В community-версию входит плагин для работы с Javascript (в том числе typesсript), хотя в wiki написано обратное. За Javascript отвечает плагин SonarJS, за Typescript SonarTS соответственно.

Для отправки информации о покрытии используется официальный клиент sonarqube-scanner, который, используя настройки из config-файла, отправляет эти данные на сервер SonarQube для дальнейшей консолидации и агрегирования.

Для Javascript есть npm-обертка. Итак, начинаем пошаговое внедрение SonarQube в Vue-проект, использующий Typescript.

Я — большой любитель TypeScript. По возможности я стараюсь использовать этот язык в своих проектах. TypeScript даёт разработчику отчёты об ошибках и проверку типов в JavaScript и TypeScript-коде. Кроме того, тот, кто пишет на TypeScript, может пользоваться удобными возможностями по автозавершению кода, может, быстро и надёжно, выполнять рефакторинг. TypeScript — это первая линия обороны от ошибок в коде. Ещё одна сильная сторона этого языка заключается в том, что он позволяет, при написании программ, пользоваться самыми свежими возможностями JavaScript. При этом то, что получается при преобразовании TypeScript-кода в JavaScript, будет поддерживаться всеми браузерами. Это очень приятно.



Правда, не все фронтенд-проекты предусматривают применение TypeScript. Что если можно было бы пользоваться возможностями TypeScript, но при этом не переводить на него весь проект (и всю команду), и не добавлять в конвейер сборки проекта новый инструмент? Это возможно благодаря VS Code и JSDoc.

Привет, %username%!

Сегодня многие начинающие веб-разработчики делают большую ошибку, и не одну. Они что-нибудь сверстают, а потом покупают хостинг. Далее покупают домен. Регистрируют и подключают SSL-сертификат. Я, спасаясь от минус-кармы, просто расскажу как не тратить деньги на свои тестовые проекты.

Договариваемся об эффективном и удобном общении при удалённой работе (и не только)

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

Не за горами очередной старт курса для руководителей разработки «Team Lead 2.0». В связи с этим мы провели открытый урок под названием «Почему мои коллеги/сотрудники ведут себя как @%§?». На вебинаре поговорили о том, что заставляет людей вести себя некорректно, почему люди идут на конфликт, какие есть способы влияния на поведение.

---

Преподаватель — Станислав Михальский, технический директор «Развитие.Ру».

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