Жалею, что статья не вышла раньше на две с половиной недели, как раз зуб удалил…
Странно, что хирург посоветовал поставить имплант в течение 3 месяцев и не сказал, что лучше сразу.
Правда, там была старая нижняя семёрка слева, с которой были проблемы ещё лет 25 назад, сейчас уже от зуба почти ничего и не осталось. С другой стороны нижнюю семёрку удалили тоже лет 25 назад, имплант тогда не поставил.
И вот вопрос — имеет ли смысл сейчас бежать и ставить имплант или уже не дёргаться и можно до июня подождать?
И, в принципе, насколько важно ставить имплант в текущей ситуации (с отсутствием правой семёрки проблем не испытываю)?
Видимо, на большинство продуктов лишь бегло посмотрели. А жаль — подумал, было — "наконец-то не только маркетинг". На примере Redmine, про который сказано:
Слабые стороны: устаревший интерфейс, некоторые функции спрятаны в очень неочевидных местах. Нет инструмента для отслеживания времени и активности пользователя по задачам. Система требует определенных навыков для установки на вашем собственном сервере. Также требуется время, чтобы сориентироваться в интерфейсах и понять назначение каждой функции.
Disclaimer: я не "евангелист" Redmine, даже не контрибьютор, просто им пользуюсь.
Давайте по пунктам.
Думаю, у большинства сколь-нибудь сложных продуктов некоторые функции спрятаны в очень неочевидных местах.
Инструмент для внесения времени есть (включается в настройках проекта). Если речь про всякие трекеры — не интересовался, может есть плагины (их море, кстати, только некоторые устаревшие).
Какой именно активности пользователя не хватает? Есть такая и такая. Или хочется мгновенного уведомления о комментариях или смене статуса задачи? Возможно, для кого-то важно (сам бы я отключил, если бы такое было и отключалось).
Про навыки для установки на собственном сервере — да, есть такое. Хотя есть хостинг и готовые образы для тех, кто не хочет или не может этим заниматься.
См. пункт (1). Если сравнивать с простыми продуктами с меньшим набором функций, то, конечно, они будут проще (чертовски логично).
В целом ощущения (по тому же HN и Twitter), что, как минимум, среди технарей больше поддерживающих JetBrains. Некоторые очень даже креативно поддерживают.
Другой вопрос, что не все бизнесмены и чиновники в технических вопросах прислушиваются к технарям. Хотя, казалось бы...
За статью спасибо, но относительно темы двойственные ощущения — с одной стороны, полезно знать особенности СУБД, с другой — использование таких фич в реальных приложениях (а не ad hoc запросах) резко увеличивает затраты на поддержку других СУБД (или миграцию на них).
Интересный подход. У нас более "развязанная" архитектура (а логирование и прочие штуки можно приделывать к брокеру, через который общаются все модули), а модули, в принципе, могут быть на разных ЯП… У вас больше ориентированно на то, чтобы дать разработчикам рамки, за которые им не рекомендуется выходить, а у нас на то, чтобы разработчик конкретного модуля мог, при желании, сделать в нём почти всё, что угодно (лишь бы "контракт по API" не нарушался).
Но у вашего подхода, несомненно, тоже есть плюсы (в нашем немного больше шансов при стрельбе задеть ноги). Пока сходу не придумал, что можно позаимствовать, но буду иметь в виду.
Предлагаю чуть другую точку зрения: интересная статья на Хабре => повышение интереса к продукту => потенциальные новые участники в команде => помощь, в том числе и с документацией ;)
И, кстати, к написанию документации полезно привлечь именно новых людей, потому что для вас сложнее будет поставить себя на место новичка, чтобы объяснить не очень очевидные моменты. Понятно, что ревьюить и помогать тоже потребуется...
Теперь чуть лучше понял, что имеете в виду. Понятно, что "проценты" у всех разные, как и подходы, впрочем.
Ещё бы уточнить, как обеспечивается целостность без транзакций (когда реально несколько операций с БД и надо обязательно либо всё сделать и отправить письмо, либо ничего не сделать и не отправлять) — саги?
UPD: На всякий случай поясню, я не говорю про то, что всё всегда должно быть в транзакции. Но вот зарегистрировать факт необходимости вызова внешнего сервиса для наших задач очень удобно как раз в транзакции, а потом уже да — и повторы и прочее конечно не дело бизнес-логики — у нас за это отдельный PersistentInvoker отвечает. Конечно, есть подход, когда решение о "персистентности" вызова принимает не вызывающий код (а оркестрируется где-то сбоку) и он тоже имееет право на жизнь, просто у нас не прижился.
Такой вариант тоже подходит, но когда факт отправки почты вообще не важен. Либо я не совсем понял предложенное решение.
Часто отправка почты важна, но просто это не срочная задача. Обычно в наших проектах (и продуктах) если письмо не ушло, то сервис будет пытаться отправить его через некоторое время повторно (и только уже в редких случаях придётся человеку разбираться в чём проблема).
Disclaimer: в то, что сейчас напишу, я не планирую вкладывать ни пафос, ни нытьё. Это может со стороны выглядеть так, но если объяснять без примеров из личной жизни — будет неубедительно и, опять же, пафосно. Также я понимаю, что у всех разная жизненная ситуация и мои слова могут выглядеть как "мыши, станьте ежиками" (с)… Но разум мой ограничен и универсального совета дать не могу.
Сначала будет, возможно, скучная подводка к идеям, которую можно пропустить (и вернуться, если идеи покажутся совсем неприменимыми к вашей ситуации).
Приоритеты и формулировка успеха. Согласен с Канеманом, что Успех = Труд x Талант x Везение (жаль, точных коэффициентов никто не скажет). Другой вопрос, что сформулировать, что такое успех, мы должны сами (и формулировка со временем может меняться). "Успехов", естественно, может быть несколько (локальные/глобальные, работа/личная жизнь).
Поэтому необходимо как-то расставить приоритеты (и, чёрт возьми, не забывать оставить местечко и для полноценного отдыха — прокалывался на этом) и стараться учитывать их при принятии решений (будем честными, мы, человеки, не всегда принимаем взвешенные и логичные решения).
Со времён студенчества мои основные приоритеты были такие: интересные задачи, некоторая доля свободы, деньги. Деньги не как цель, но сначала их было мало и хотелось, чтобы их хватало (тоже в порядке приоритетов) на еду, книги, комп, нормальную одежду и небольшой запас на непредвиденные случаи. Со временем, когда появилась семья, приоритеты модифицировались: интересные задачи, семья, деньги, некоторая доля свободы.
Давайте посмотрим на последствия такой расстановки приоритетов:
Работа у меня почти всегда была интересной, но не слишком уж высокооплачиваемой. А на первой работе вообще застрял лет на пять на почти нищенской для программиста зарплате, но там было чертовски интересно (как следствие — ипотека на первую квартиру, когда работал уже на 4-ой работе, была ментальным адом, потому что не люблю кредиты в принципе).
Работа выбиралась исходя из приоритетов, поэтому обходил стороной банки и крупные компании.
Я разведён, сын живёт со мной, дочка — с бывшей женой. Правда, мы с сыном считаем, что в этом больше заслуга характера жены, но надо быть честным — проблемы в отношениях исчезающе редко связаны только с одним их участником.
Сейчас надо бы купить для нас с сыном хотя бы двухкомнатную квартиру, но это будет тот ещё квест, потому что в нужном районе в основном либо хрущёвки, либо "косящие под элитные" дома, но доплатить миллион-другой за это я не готов (на всякий случай — я живу в Ярославле). Но до этого ещё и не дошло, потому что надо ещё доделать ремонт в однушке...
Из-за смещения приоритета денег чуть выше, приходится заниматься управленческой работой (пропорции где-то 50/50 но часто бывают периоды смещения то в одну, то в другую сторону). Привет, "многозадачность". Причём, управление — это не какое-то уютное тимлидство, но это уже совсем другая история...
Идеи о том, как сделать работу интересной
Пишу просто как сделал бы я в разных ситуациях, подойдёт, наверное, не всем.
И да, обращение, естественно, не к mvv-rus (он просто зацепил меня сложным вопросом), а к любому читателю.
Если основной приоритет деньги, в зависимости от скиллов — искать работу в стартапе или в чём-то гуглоподобном. Или просто на собеседованиях стараться максимально узнать больше о будущих задачах и обстановке. Если скиллов пока не хватает — прокачивать скиллы.
Если деньги — не основное (или они борются за первое место с интересными задачами) — найдите компанию (или команду в большой компании), где и задачи будут интересны для вас и вы сможете влиять на происходящее. Если непонятно как — прокачивайте скиллы (в том числе и софт-скиллы). Вообще, в любой непонятной ситуации — прокачивайте скиллы :)
Если на данный момент вам кажется, что задачи совсем неинтересные и вы ни на что не влияете… Попробуйте найти в задачах что-то интересное, а в коллегах — интересных собеседников (возможно, получится влиять на архитектуру не являясь архитектором). Не получится — вернитесь к началу списка или подумайте, не пора ли сменить приоритеты.
Высыпайтесь. Да, вот так внезапно. Не всегда это может получиться (но тоже вопросов приоритетов, в том числе).
Как это работает в моей команде
Люди разные и я не буду говорить как должно быть, но расскажу про вариант, который кажется мне хорошим.
Я не являюсь "главным архитектором" или чем-то подобным. Более того, у нас в компании несколько платформ и в другие я просто не лезу, если у меня не спрашивают совета (с точки зрения себя как управленца чуть-чуть лезу, но это уже менее интересно).
В нашей команде (она, кстати, офигительная) у всех есть некоторая степень свободы в решении текущих задач, пока они не затрагивают платформу. Есть ревью, поэтому откровенной жести не случается. В моём понимании, если не давать разработчику принимать вообще никаких самостоятельных решений — он не будет развиваться и это плохо для всех.
К счастью, даже новички нам попадаются (чаще всего) адекватные, поэтому когда один разработчик не может что-то придумать — советуется с другими. Необязательно сразу с теми, кто опытнее. Кто-то вообще любит сначала с уточкой посоветоваться — благо, у нас их много.
А вот если задача либо как-то затрагивает платформу, либо из-за неё серьёзные проблемы на проекте — тогда собирается 2-3 человека и один из них, обычно, либо я, либо force (иногда — оба). Чаще всего мы с ним на одной волне, но бывает, что не сходимся во мнениях. В большинстве случаев, это касается незначительных деталей (и тогда решение за тем, кто больше в контексте задачи). Если всё серьёзнее, то такие варианты:
Зовём кого-то из опытных разработчиков (Миша, Саша — не нашёл вас на Хабре), чтобы помогли рассудить.
Есть некоторые области, в которых кто-то разбирается очевидно лучше в силу опыта (ну, скажем, я в метаданных и генерации кода, а force — в сетевом взаимодействии и многопоточности). Тут всё просто.
В крайне редких случаях я пользуюсь правом вето. Навскидку, пару раз за 10 лет вроде было. Это не потому что мы такие лапочки и живём душа в душу. Просто два умных человека, которые понимают, что идеальные решения — редкость и лучше принять хоть какое-то. А ещё, оба в курсе, что есть целый букет когнитивных искажений и иногда ты можешь быть совсем не прав, даже если уверен, что прав.
P.S. Извиняюсь за некоторый сумбур, не выспался...
Постараюсь ответить кратко, потому что двух статей за неделю я не осилю.
К тому же — да, что-то лучше обсуждать после второй статьи.
Но кто его умеет грамотно использовать? Вы, я, ещё десяток-другой человек?
Да ладно, всё значительно лучше. Просто негатив более ярко окрашен эмоциями, а когда всё в порядке — быстро забывается.
А где удаление через CTE, а где денормализация, а где индекс-хэлперы?
Может я везучий, а может упрямый, но как-то получалось обходиться без CTE. У нас в команде единодушное (вроде бы) мнение, что если понадобилось CTE, значит что-то не так…
Или как раз денормализация нужна. Кстати, не совсем понял про проблемы с денормализацией, но, это, наверное, тоже лучше после второй статьи обсудить.
Долго и дорого. Очень рад если в вашей компании могут позволить поднимать виртуалку на тесты и ждать сутки пока они прогонятся.
В принципе, создание БД на нескольких выделенных серверах работает достаточно быстро, поэтому до поднятия виртуалок не доросли ещё — для некоторых проектов просто используются два TeamCity — один на Linux, другой — на Windows.
Основные сценарии пока проверяются за несколько десятков минут (как я уже говорил — тесты производительности выполняются отдельно и пореже).
За сим откланяюсь. Ещё раз спасибо за фидбек.
Спасибо, и вам тоже. Тем более, за такой развёрнутый.
Лично я, конечно, за правильный способ. А по поводу сроков, начальников и обогащения...
Часто для писем нужна информация, которая не нужна коду, записывающему в БД. Так что письмо придётся обогащать данными в большинстве случаев — так лучше это сделать позже, не замедляя более приоритетные операции.
Сроки давят по-разному. Иногда можно объяснить, что лучше сделать правильно (особенно, если показать, в чём будет польза). Иногда — нет, не спорю. Тогда есть простой способ.
Понятно, что задача не самая однозначная. Но вы же согласитесь, что рассчитывать на постоянную доступность и быстрый отклик почтового сервера несколько оптимистично?
Читал "Дневники Киллербота", понравилось.
Жалею, что статья не вышла раньше на две с половиной недели, как раз зуб удалил…
Странно, что хирург посоветовал поставить имплант в течение 3 месяцев и не сказал, что лучше сразу.
Правда, там была старая нижняя семёрка слева, с которой были проблемы ещё лет 25 назад, сейчас уже от зуба почти ничего и не осталось. С другой стороны нижнюю семёрку удалили тоже лет 25 назад, имплант тогда не поставил.
И вот вопрос — имеет ли смысл сейчас бежать и ставить имплант или уже не дёргаться и можно до июня подождать?
И, в принципе, насколько важно ставить имплант в текущей ситуации (с отсутствием правой семёрки проблем не испытываю)?
Чёрт, я только после вашего комментария вспомнил, что коллеги давным-давно на одном из хакатонов запилили приложение для Android.
Вроде в комментах тут можно ссылки оставлять, тем более, что приложение бесплатное...
Redmine Time Management
Забыл, потому что сам не пользовался. Наверное, даже работает, если в свежем redmine кардинально эту часть API не поменяли.
Видимо, на большинство продуктов лишь бегло посмотрели. А жаль — подумал, было — "наконец-то не только маркетинг". На примере Redmine, про который сказано:
Disclaimer: я не "евангелист" Redmine, даже не контрибьютор, просто им пользуюсь.
Давайте по пунктам.
В целом ощущения (по тому же HN и Twitter), что, как минимум, среди технарей больше поддерживающих JetBrains. Некоторые очень даже креативно поддерживают.
Другой вопрос, что не все бизнесмены и чиновники в технических вопросах прислушиваются к технарям. Хотя, казалось бы...
В такой статье было бы полезно поделиться и другим взглядом на внутреннее устройство Valve:
https://medium.com/dunia-media/the-nightmare-of-valves-self-organizing-utopia-6d32d329ecdb
Понятно, что случаи разные бывают.
Uber, например, показательно мигрировал с MySQL на PostgreSQL и обратно.
Я-то со своей колокольни, стараюсь избегать vendor lock, когда его можно избежать.
P.S. Реализуют, потому что кому-то нужно решать частные задачи, тем более, что СУБД open source.
За статью спасибо, но относительно темы двойственные ощущения — с одной стороны, полезно знать особенности СУБД, с другой — использование таких фич в реальных приложениях (а не ad hoc запросах) резко увеличивает затраты на поддержку других СУБД (или миграцию на них).
Интересный подход. У нас более "развязанная" архитектура (а логирование и прочие штуки можно приделывать к брокеру, через который общаются все модули), а модули, в принципе, могут быть на разных ЯП… У вас больше ориентированно на то, чтобы дать разработчикам рамки, за которые им не рекомендуется выходить, а у нас на то, чтобы разработчик конкретного модуля мог, при желании, сделать в нём почти всё, что угодно (лишь бы "контракт по API" не нарушался).
Но у вашего подхода, несомненно, тоже есть плюсы (в нашем немного больше шансов при стрельбе задеть ноги). Пока сходу не придумал, что можно позаимствовать, но буду иметь в виду.
Amazon тоже юзаем для некоторых проектов, а вот SQS или SES — тут больше force в курсе. Так или иначе, всё что нужно — хэндлится :)
Но не все заказчики хотят/могут использовать Amazon, так что делаем по-разному.
Предлагаю чуть другую точку зрения: интересная статья на Хабре => повышение интереса к продукту => потенциальные новые участники в команде => помощь, в том числе и с документацией ;)
И, кстати, к написанию документации полезно привлечь именно новых людей, потому что для вас сложнее будет поставить себя на место новичка, чтобы объяснить не очень очевидные моменты. Понятно, что ревьюить и помогать тоже потребуется...
Теперь чуть лучше понял, что имеете в виду. Понятно, что "проценты" у всех разные, как и подходы, впрочем.
Ещё бы уточнить, как обеспечивается целостность без транзакций (когда реально несколько операций с БД и надо обязательно либо всё сделать и отправить письмо, либо ничего не сделать и не отправлять) — саги?
UPD: На всякий случай поясню, я не говорю про то, что всё всегда должно быть в транзакции. Но вот зарегистрировать факт необходимости вызова внешнего сервиса для наших задач очень удобно как раз в транзакции, а потом уже да — и повторы и прочее конечно не дело бизнес-логики — у нас за это отдельный PersistentInvoker отвечает. Конечно, есть подход, когда решение о "персистентности" вызова принимает не вызывающий код (а оркестрируется где-то сбоку) и он тоже имееет право на жизнь, просто у нас не прижился.
Кстати, а почему вы (и вы лично и другие участники команды) о LINQ to DB на Хабре не пишете? Интересно же (и уверен, что не только мне).
Такой вариант тоже подходит, но когда факт отправки почты вообще не важен. Либо я не совсем понял предложенное решение.
Часто отправка почты важна, но просто это не срочная задача. Обычно в наших проектах (и продуктах) если письмо не ушло, то сервис будет пытаться отправить его через некоторое время повторно (и только уже в редких случаях придётся человеку разбираться в чём проблема).
Disclaimer: в то, что сейчас напишу, я не планирую вкладывать ни пафос, ни нытьё. Это может со стороны выглядеть так, но если объяснять без примеров из личной жизни — будет неубедительно и, опять же, пафосно. Также я понимаю, что у всех разная жизненная ситуация и мои слова могут выглядеть как "мыши, станьте ежиками" (с)… Но разум мой ограничен и универсального совета дать не могу.
Сначала будет, возможно, скучная подводка к идеям, которую можно пропустить (и вернуться, если идеи покажутся совсем неприменимыми к вашей ситуации).
Приоритеты и формулировка успеха. Согласен с Канеманом, что Успех = Труд x Талант x Везение (жаль, точных коэффициентов никто не скажет). Другой вопрос, что сформулировать, что такое успех, мы должны сами (и формулировка со временем может меняться). "Успехов", естественно, может быть несколько (локальные/глобальные, работа/личная жизнь).
Поэтому необходимо как-то расставить приоритеты (и, чёрт возьми, не забывать оставить местечко и для полноценного отдыха — прокалывался на этом) и стараться учитывать их при принятии решений (будем честными, мы, человеки, не всегда принимаем взвешенные и логичные решения).
Со времён студенчества мои основные приоритеты были такие: интересные задачи, некоторая доля свободы, деньги. Деньги не как цель, но сначала их было мало и хотелось, чтобы их хватало (тоже в порядке приоритетов) на еду, книги, комп, нормальную одежду и небольшой запас на непредвиденные случаи. Со временем, когда появилась семья, приоритеты модифицировались: интересные задачи, семья, деньги, некоторая доля свободы.
Давайте посмотрим на последствия такой расстановки приоритетов:
Идеи о том, как сделать работу интересной
Пишу просто как сделал бы я в разных ситуациях, подойдёт, наверное, не всем.
И да, обращение, естественно, не к mvv-rus (он просто зацепил меня сложным вопросом), а к любому читателю.
Как это работает в моей команде
Люди разные и я не буду говорить как должно быть, но расскажу про вариант, который кажется мне хорошим.
Я не являюсь "главным архитектором" или чем-то подобным. Более того, у нас в компании несколько платформ и в другие я просто не лезу, если у меня не спрашивают совета (с точки зрения себя как управленца чуть-чуть лезу, но это уже менее интересно).
В нашей команде (она, кстати, офигительная) у всех есть некоторая степень свободы в решении текущих задач, пока они не затрагивают платформу. Есть ревью, поэтому откровенной жести не случается. В моём понимании, если не давать разработчику принимать вообще никаких самостоятельных решений — он не будет развиваться и это плохо для всех.
К счастью, даже новички нам попадаются (чаще всего) адекватные, поэтому когда один разработчик не может что-то придумать — советуется с другими. Необязательно сразу с теми, кто опытнее. Кто-то вообще любит сначала с уточкой посоветоваться — благо, у нас их много.
А вот если задача либо как-то затрагивает платформу, либо из-за неё серьёзные проблемы на проекте — тогда собирается 2-3 человека и один из них, обычно, либо я, либо force (иногда — оба). Чаще всего мы с ним на одной волне, но бывает, что не сходимся во мнениях. В большинстве случаев, это касается незначительных деталей (и тогда решение за тем, кто больше в контексте задачи). Если всё серьёзнее, то такие варианты:
P.S. Извиняюсь за некоторый сумбур, не выспался...
Чертовски сложный вопрос. У меня есть что сказать на этот счёт, но надо подумать на свежую голову, как это нормально сформулировать.
Чёрт возьми, это вам всем спасибо!
Постараюсь ответить кратко, потому что двух статей за неделю я не осилю.
К тому же — да, что-то лучше обсуждать после второй статьи.
Да ладно, всё значительно лучше. Просто негатив более ярко окрашен эмоциями, а когда всё в порядке — быстро забывается.
Может я везучий, а может упрямый, но как-то получалось обходиться без CTE. У нас в команде единодушное (вроде бы) мнение, что если понадобилось CTE, значит что-то не так…
Или как раз денормализация нужна. Кстати, не совсем понял про проблемы с денормализацией, но, это, наверное, тоже лучше после второй статьи обсудить.
В принципе, создание БД на нескольких выделенных серверах работает достаточно быстро, поэтому до поднятия виртуалок не доросли ещё — для некоторых проектов просто используются два TeamCity — один на Linux, другой — на Windows.
Основные сценарии пока проверяются за несколько десятков минут (как я уже говорил — тесты производительности выполняются отдельно и пореже).
Спасибо, и вам тоже. Тем более, за такой развёрнутый.
Лично я, конечно, за правильный способ. А по поводу сроков, начальников и обогащения...