Как стать автором
Обновить
17
0
Кузьмич Максим @cr0ck

Пользователь

Отправить сообщение

Да что это такое, ваше качество кода?

Время на прочтение5 мин
Количество просмотров7.9K

Салют, коллеги.

Лично я, очень люблю поговорить про качество, поддерживаемость и выразительность кода (эти умные слова, часто звучат на код ревью)

К сожалению, такие разговоры часто и быстро скатываются в холивар. Но, кажется, я нашел способ "вести разговоры о высоком без боли".

Мысль такая, если приземлить обсуждение на конкретную практическую задачу, то будет сильно проще понять, какой именно смысл вкладывает в слово "выразительность" собеседник. 

Читать далее
Всего голосов 13: ↑12 и ↓1+11
Комментарии38

Тернистый путь к созданию и внедрению Content Style Guide

Время на прочтение8 мин
Количество просмотров1.7K

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

Читать далее
Всего голосов 4: ↑4 и ↓0+4
Комментарии0

Нужен ли Mockito, если у вас Kotlin?

Время на прочтение5 мин
Количество просмотров8.6K

Салют, коллеги.

В рамках пятничной статьи предлагаю посмотреть на интересный способ создания моков в Kotlin, без использования сторонних библиотек.

Я занимаюсь разработкой аддонов для Atlassian-стека в компании Stiltsoft и, из-за технических ограничений, до сих пор (да в 2021 году и, скорее всего, в ближайшие пару лет) вынужден использовать Java 8. Но, чтоб не отставать от прогрессивного человечества, внутри компании мы пробуем Kotlin, пишем на нем тесты и разные экспериментальные продукты.

Однако, вернемся к тестам. Часто у нас есть интерфейс из предметной области, нам не принадлежащий, но который активно используется нашим кодом. Причем у самого интерфейса много разных методов, но в каждом сценарии используем их буквально по паре штук. Например, интерфейс ApplicationUser.

Читать далее
Всего голосов 13: ↑12 и ↓1+11
Комментарии9

Проектирование в Confluence

Время на прочтение8 мин
Количество просмотров91K
Всем привет!

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



Читать дальше →
Всего голосов 36: ↑35 и ↓1+34
Комментарии8

Как проинтегрировать TeamCity и Bitbucket Server

Время на прочтение3 мин
Количество просмотров17K


Bitbucket Server (ранее известный как Stash) — решение для централизованного управления разработкой, позволяющее управлять вашими репозиториями, в том числе не открывая доступа к ним извне организации. Bitbucket позволяет упростить хранение репозиториев с исходными кодами на вашем сервере и обеспечивает простоту доступа к репозиториям для всех членов вашей команды.

В мире IT известно, что Bitbucket может быть проинтегрирован с другими продуктами и платформами в единую экосистему, которая делает процесс разработки всеобъемлющим и удобным. Чаще всего Bitbucket интегрируется с JIRA. Однако, поиск и локализация проблем — не единственная задача, с которой типовой процесс разработки сталкивается каждый день, и даже несколько раз в день. Более важной задачей является сохранение целостности проекта в процессе внесения дополнений и исправлений в код. Для этих задач вы можете использовать CI-сервер, который в том числе позволяет создавать сборки проектов и выполнять серии тестов для автоматической проверки функциональности.

Bitbucket «из коробки» предлагает интеграцию с родственным решением от AtlassianBamboo. Но, помимо Bamboo, существуют другие CI-решения, которые также достаточно популярны — TeamCity и Jenkins. В нашем посте мы обрисуем специфику интеграции Bitbucket и TeamCity.

Читать дальше →
Всего голосов 7: ↑6 и ↓1+5
Комментарии1

Как нарисовать графики и диаграммы в Atlassian Confluence

Время на прочтение8 мин
Количество просмотров49K
image

Atlassian Confluence — мощное решение для развертывания Enterprise Wiki в организации (хотя, нет никаких технических проблем с тем, чтобы использовать его и дома — лицензия на 10 пользователей стоит всего 10 американских долларов в год). И лично мне Confluence нравится тем, что имеет дружелюбный интерфейс и позволяет интуитивно понятно редактировать контент, с легкостью дополняя его визуальными составляющими, что позволяет в итоге получить красивые и удобные для просмотра страницы. Кстати, этот пост тоже написан в Confluence.
Читать дальше →
Всего голосов 8: ↑6 и ↓2+4
Комментарии0

Разработка Blueprints плагинов в Atlassian Confluence

Время на прочтение7 мин
Количество просмотров11K
Казалось бы, совсем недавно вышел Confluence 5, который принес пользователям уйму новых фич: новое визуальное представление, возможность переключения между приложениями непосредственно из wiki, нотификации о том, что добавлен комментарий либо содержимое страницы кем-либо изменено. Тем не менее, уже ощущается дыхание версии 5.1 Atlassian Confluence, которая направлена на упрощение процесса содания страниц с помощью технологии Blueprints. Blueprints помогает пользователям понять, какое содержимое они хотят создать и показываeт, как это сделать, буквально проводя пользователей за руку до получения готовой к просмотру wiki-страницы.

В данной статье рассматривается процесс разработки Blueprints плагинов от первоначальной идеи до получения конечного результата. Для этого будет разработан небольшой плагин для Atlassian Confluence, который позволяет создавать страницы из старой доброй wiki-разметки прямо в режиме просмотра страницы с помощью технологии Blueprints.
Читать дальше →
Всего голосов 10: ↑9 и ↓1+8
Комментарии3

Atlassian Confluence 5 — На пути к идеалу

Время на прочтение3 мин
Количество просмотров73K

За несколько дней до весны в линейке продуктов компании Atlassian большое и, самое главное, долгожданное событие: случился релиз Confluence 5 с ощутимыми изменениями в пользовательском интерфейсе и огромным количеством новых фич. Под катом обзор возможностей Confluence 5 с некоторым количеством картинок и большим количеством ссылок.



CEO Atlassian как бы говорит нам, что они отлично потрудились над Confluence 5




Читать дальше →
Всего голосов 27: ↑25 и ↓2+23
Комментарии45

KPI, или пособие по командному самоубийству

Время на прочтение11 мин
Количество просмотров447K
Для написания этой заметки  было затрачено:

  • 68338 километров на поездки.
  • 72 человеко-часа на почтовую переписку.
  • 423 человеко-часа на эксперименты с коллективом в 30 человек.
  • 88 часов на подготовку докладов и выступления на конференциях.
  • 17 чашек кофе на беседу с мудрыми людьми на афтепати.
  • Порядка 25 часов на набор этого текста и правку багов в нем :).
  • До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.


Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.

Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять KPI (ключевые показатели эффективности). Работает так: вы, как владелец бизнеса, назначаете конкретные цели для сотрудников. Они достигают или не достигают поставленных целей в процессе работы. Тем, кто достиг — выдается плюшка (денежная премия).

Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!



Ну, логично же, что:

  • Продажникам  нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
  • Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.


А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.

Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:



Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.
Читать дальше →
Всего голосов 130: ↑114 и ↓16+98
Комментарии122

Кормление и уход за разработчиками (или почему мы такие ворчуны)

Время на прочтение22 мин
Количество просмотров28K
Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.


Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.
Читать дальше →
Всего голосов 242: ↑228 и ↓14+214
Комментарии76

Информация

В рейтинге
Не участвует
Откуда
Беларусь
Зарегистрирован
Активность