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

Именно поэтому каждый customer success менеджер в компании Wrike должен быть экспертом по управлению организационными изменениями и уметь проводить мероприятия по внедрению этих изменений. В данной статье мы разберем одну из наиболее известных моделей по управлению изменениями — ADKAR — и сопроводим описание каждой из ее фаз примерами и пояснениями.

На Хабре, да и не только, про ботов рассказано уже так много, что даже слишком. Но заинтересовавшись пару недель назад данной темой, найти нормальный материал у меня так и не вышло: все статьи были либо для совсем чайников и ограничивались отправкой сообщения в ответ на сообщение пользователя, либо были неактуальны. Это и подтолкнуло меня на написание статьи, которая бы объяснила такому же новичку, как я, как написать и запустить более-менее осмысленного бота (с возможностью расширения функциональности).

Качество кода — тема, которая родилась вместе с программированием. Для оценки и контроля качества менеджмента предприятий применяется ISO 9000, для продуктов — ГОСТ и тот же ISO, а вот для оценки качества кода ГОСТа нет. Точного определения и стандарта для качества кода тоже нет.



Каждый разработчик понимает качество по-своему, исходя из опыта. Представления джунов и лидов различаются, и это приводит к разногласиям. Каждая команда для отдельных проектов оценивает код по-своему. Команда обновляется, разработчики уходят, тимлиды сменяются — определение качества меняется. Эту проблему попробует помочь решить Иван Ботанов (StressoID) из Tinkoff.ru — Frontend-developer, преподаватель онлайн-курса по Angular, спикер на митапах и конференциях, ведущий уроков на YouTube и, иногда, тренер команд в компаниях.

В расшифровке доклада Ивана на Frontend Conf поговорим о читаемости, нейминге, декларативности, Code style, и косвенно коснемся отношений джунов и лидов: ошибки, грабли и «сгорание» тимлидов.

Disclaimer: Подготовьтесь морально, в тексте будет много плохого кода, взятого с «особенного» сайта.

Утром 1 октября 1970 года ученый-компьютерщик Виктор Глушков вошел в Кремль, чтобы встретиться с Политбюро. Он был настороженным человеком с пронзительными глазами в черных очках, с таким типом ума, который, решая одну проблему, мог найти параллельно метод решения всех аналогичных проблем. В тот момент у Советского Союза возникла серьезная проблема. Годом раньше Соединенные Штаты запустили ARPANET, первую распределенную компьютерную сеть с коммутацией пакетов, которая со временем породит интернет, каким мы его знаем сегодня. Распределенная сеть изначально была разработана с целью опередить СССР, позволяя компьютерам ученых и правительственных лидеров США обмениваться информацией даже в случае ядерной атаки. Это была высшая точка технологической гонки, и Советы должны были чем-то ответить.

По нашей просьбе Хабр создал хаб Kubernetes и нам приятно разместить первую публикацию в нём. Подписывайтесь!

Kubernetes — это просто. Почему же банки платят мне за работу в этой сфере большие деньги, в то время как любой может освоить эту технологию буквально за несколько часов?

После 18-го февраля начнется открытый и бесплатный курс "Deep Learning на пальцах".

Курс предназначен для того, чтобы разобраться с современным deep learning с нуля, и не требует знаний ни нейросетей, ни machine learning вообще. Лекции стримами на Youtube, задания на Питоне, обсуждения и помощь в лучших русскоязычных DS-сообществах — ODS.ai и ClosedCircles.

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

Одновременно и в том же объеме курс будет читаться для магистрантов Новосибирского Государственного Университета, а также студентов CS центра Новосибирска.

Выглядеть объяснение на пальцах будет примерно так:

Главная ссылка — dlcourse.ai. Подробности ниже.

Вступление

Чуть ли не каждый второй, кто впервые сталкивается с MSA (Micro Service Architecture), на первых порах восклицает: «Да я эти микросервисы еще …надцать лет назад». Отчасти они правы. И я тоже был из этой самой половины, и не понимал — почему такой шум?



В самом деле! Ведь MSA — это тоже про разработку софта. Какие здесь могут быть революции? Все методики знакомы. В некоторых местах можно даже удивиться: «А разве бывает по-другому»? Фанаты Agile и DevOps тоже скажут, что это всё наше, родное.

Но всё же прошу вас набраться терпения и продолжить читать дальше.

Привет, Хабр!

Ровно год назад мы — небольшое сообщество — собрались, чтобы переводить на русский самые крутые образовательные курсы, что есть в открытом доступе (например, физика Уолтера Левина). Без денег — просто интерес. И сегодня мы к вам — с надеждой, что вам понравится, что мы делаем.

Вместо КДПВ — озвученное нами видео 3blue1brown (да-да, мы договорились о переводе с автором самых крутых на Youtube видео про математику-физику-информатику).

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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

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

Итак, на 1 февраля запланирован DNS Flag Day. Эффекты этого события будут наступать постепенно, однако всё же быстрее, чем некоторые компании сумеют к нему адаптироваться.

Что это такое? Говоря простым языком, это манифест основных мировых разработчиков DNS-серверов: компаний CZ.NIC, ISC, NLnet Labs и PowerDNS.

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

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

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



Сегодня я расскажу про второй опыт восстановления зрения, но на этот раз более радикальный и с каким-то вообще невероятным результатом. А именно — о лазерной коррекции по технологии ReLEx SMILE.

Всем привет!
Сегодня я хочу поделится нашим опытом автоматизации тестирования веб-приложения с использованием Selenium WebDriver и фреймворка Behave.
Если интересно добро пожаловать под кат.

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

Совместно с нашими партнёрами мы активно разрабатываем, тестируем и поддерживаем семейство приложений для разных платформ: Android, iOS, Windows. Приложения активно развиваются, вместе с чем увеличивается и объём тестирования, в первую очередь — регрессионного.

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

Реализация такого подхода началась с одного из Android-приложений, о чём я и расскажу. Статья будет интересна начинающим авторам UI-тестов, в первую очередь для мобильных приложений, а также тем, кто хочет в некоторой мере автоматизировать процесс ручного тестирования.

Поехали!

Когда нужно сделать несколько запросов к HTTP API, разработчик обычно берет свой привычный язык/фреймворк и быстро пишет аналог curl в коде: HTTP-запрос, минимальный контроль ошибок, query- или json-аргументы, парсинг json body с названиями полей в виде строк. Все это замечательно работает, пока проект не начинает расти и несколько вызовов не превращаются в несколько десятков, а куски низкоуровневого кода не начинают размножаться копипастой. А дальше — стандартный набор багов, рожденных копипастой, которые начинают понемногу есть время у разработчика.

Swagger/OpenAPI — один из «комбайнов» для работы с HTTP API. Это язык описания API (недавно произошло объединение проектов генератора и спеки), генераторы серверного и клиентского кода, документации, тестов — много всяких полезных штук. Под катом я покажу, как по «человеческому» описанию API на сайте компании в несколько строк кода составить OpenAPI-описание и сгенерировать клиент на Python. И чем такой клиент будет лучше, чем вручную написанный код.

6-7 декабря в Москве состоялась пятая по счёту конференция «Гейзенбаг».
Её слоган — «Тестирование. Не только для тестировщиков!», и за два года регулярного посещения «Гейзенбагов» мне (прежде Java-разработчику, ныне — техническому лиду в маленькой компании, никогда не работавшему в QA) удалось многому научиться в области тестирования и многое внедрить в нашей команде. Я хочу поделиться субъективным обзором запомнившихся мне на этот раз докладов.

Привет, сообщество! Мы в Хекслете составили список из пяти бесплатных автоматизированных онлайн-платформ для новичков.

На русском:

HTML Academy
«Академия» учит верстать сайты. Основной контент в формате подписки (390 рублей в месяц) и интенсивов (от 12500 рублей), но есть несколько бесплатных автоматизированных курсов по основам HTML, CSS и JavaScript.

В HTML Academy не столько задания для прокачки в программировании, сколько для знакомства с основами веб-разработки. Но это идеальный формат для тех, кто никогда не писал код и хочет попробовать. Большое количество веб-разработчиков начинало путь именно здесь.

Code Basics
Это новый бесплатный сервис от Хекслета. Его основная идея — через решение простых заданий прямо в браузере погружать новичков в основы программирования. Сейчас есть уроки по PHP, JavaScript и Python, ближайшее время появятся — новые. Платформа подойдет лучше всего для изучения основ синтаксиса, и меньше — для прокачки алгоритмов.

Обучение построено вокруг чередования небольших порций теории (3-4 абзаца) и закрепления практики в тренажере. У каждого практического задания есть решение учителя, которое можно сравнить со своим после успешного прохождения и раздел для обсуждения задания.

Полгода назад Google представила обновленную версию своего почтового сервиса. Несмотря на то что многие пользователи были недовольны редизайном, в том числе и на Хабре, это теперь основной интерфейс для пользователей.

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

Чему армия могла бы научить тестировщика? Как выглядят две крайности в подходах к тестированию? Как объяснить, что технический долг платежом красен? Что есть общего у предыдущих вопросов?

Общее то, что при всей их разнице, они все близки одному человеку. У Джима Холмса за спиной несколько десятилетий IT-опыта, начавшегося в 80-х в ВВС США — неудивительно, что он готов рассказать о многом. Для него важно понятие «testing culture», и мы задали ему вопросы, которые могут очень сильно различаться, но в конечном счёте так или иначе связаны с культурой тестирования.

Приходя на новый проект, я регулярно сталкиваюсь с одной из следующих ситуаций:

1. Тестов нет совсем.
2. Тестов мало, их редко пишут и не запускают на постоянной основе.
3. Тесты присутствуют и включены в CI (Continuous Integration), но приносят больше вреда, чем пользы.

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

Что можно сделать, чтобы изменить сложившуюся ситуацию? Идея использования тестов не нова. При этом большинство туториалов напоминают знаменитую картинку про то, как нарисовать сову: подключаем JUnit, пишем первый тест, используем первый мок — и вперед! Такие статьи не отвечают на вопросы о том, какие тесты нужно писать, на что стоит обращать внимание и как со всем этим жить. Отсюда и родилась идея данной статьи. Я постарался кратко обобщить свой опыт внедрения тестов в разных проектах, чтобы облегчить этот путь для всех желающих.