Pull to refresh
17
0
Кузьмич Максим @cr0ck

User

Send message

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

Reading time5 min
Views7.9K

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

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

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

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

Читать далее
Total votes 13: ↑12 and ↓1+11
Comments38

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

Reading time8 min
Views1.7K

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

Читать далее
Total votes 4: ↑4 and ↓0+4
Comments0

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

Reading time5 min
Views8.6K

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

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

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

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

Читать далее
Total votes 13: ↑12 and ↓1+11
Comments9

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

Reading time8 min
Views92K
Всем привет!

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



Читать дальше →
Total votes 36: ↑35 and ↓1+34
Comments8

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

Reading time3 min
Views17K


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

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

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

Читать дальше →
Total votes 7: ↑6 and ↓1+5
Comments1

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

Reading time8 min
Views49K
image

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

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

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

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

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

Reading time3 min
Views73K

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



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




Читать дальше →
Total votes 27: ↑25 and ↓2+23
Comments45

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

Reading time11 min
Views447K
Для написания этой заметки  было затрачено:

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


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

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

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



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

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


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

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



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

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

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

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


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

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

Information

Rating
Does not participate
Location
Беларусь
Registered
Activity