просмотрел статью по диаганали, по озвученным проблемам уже давно существует решение в виде page object, отсюда в тестах не используется xpath, а используется page object в котором уже скрыта (инкапсулирована) работа с xpath.
Итог: не обязательно добавлять data-testid можно использовать обычные id, class, tag если они есть, вопрос именования это отдельная тема, не будем спорить нужен ли БЭМ или альтернативы.
Добавляя data-testid мы не перестаем использовать xpath, мы вместо использование классов, тэгов, id. Начинаем использовать пользовательские атрибуты.
я знаю разницу между swarm и compose, но спасибо что напомнили.
я говорил что вместо использования docker-compose утилиты, можно сделать
docker swarm init
и далее брать текущие docker-compose.yml файлики и запускать примерно так
docker stack deploy -c ./docker-compose.yml test
и все будет работать так как везде docker-compose.yml версии 3 (тут нет специфичных вещей)
при этом разница в том что человек
Не доустанавливал docker-compose утилиту (в некоторых ос ее надо доставлять дополнительно)
Не изучал параметры утилиты docker-compose (вполне достаточно docker swarm, stack и тд того что идет из коробки)
Плюсом получил возможность примитивную возможность объединять в кластер, которой обычно достаточно ОЧЕНЬ многим (некоторые прод держат на docker-compose и если работает и их все устрайвает то почему бы и не ДА ?)
поэтому если человек ищет инструмент для запуска окружения, я бы в 2023 году советовал в начале использовать стандартный (docker swarm вместо docker-compose), а уже потом он сам выберет нужен ему k8s или k3s или что либо другое.
возможности утилиты docker-compose с лихвой перекрываются docker swarm mode и рациональней начинать изучение с нее в 2023 году (как и годами раньше), раньше году в 2015 когда не было swarm mode да docker-compose было полезно и удобно и некоторые по привычки могут его использовать и дальше.
даже не представляю зачем сейчас изучать docker-compose если можно можно брать эти же самые docker-compose.yml (любые где версия 3.х) и запускать их в docker swarm
docker swarm считается заброшенной, а docker-compose это вообще древний рудимент
возможно я набросил слишком холиварно, но docker swarm по всем параметрам обходит docker-compose, единственный минус это не подеррживает версию ниже 3, во второй там были свои "фишки".
я в свое время тоже пришел к деревьям, даже хотел сделать небольшой веб интерфейс для управления, но как всегда руки не дошли.
Моя идея была в том чтобы была мотивация делать дела из нижнего списка, чтобы видеть верхне уровневую цель, например: Основная цель поработить человечество, ее блокирует построение звезды смерти, ее блокирует необходимость создания стабильного ядра звезды смерти (вспоминаем фильм :) ), ее блокирует отсутвующий специалист, ее блокирует конкретная задача: Позвонить Дарт вейдору в понедельник для рекрутинга архитектора.
Вот когда у тебя список дел состоит из задач конкретных при этом всегда видно глобальную цель и при этом видно цепочку того что оно блокирует это лично меня мотивирует ее быстрее сделать, чем если бы просто была задача: Обсудить с Дарт Ведером вакансию архитектора, какого архитектора ? зачем ? что мне это даст ? и соответственно завершая такую мелкую задачку можно сразу показывать что она может разблокировать и фокусироваться на других задачах, также очень удобно одновременно указывать все известные блокеры которые можно делать паралельно.
Применяя такой подход в реальной жизни я гораздо быстрей достигал поставленных целей.
я бы добавил сюда еще то что тестировщика надо как можно раньше подключать к ознакомлению фитчи, от поставноки задачи аналитиком, чтобы он понимал какой именно результат нужен в итоге.
В идеале аналитик = тестировщик, чтобы кто ставил задачи он их и принимал.
опять же напомню я не специалист (не юрист и не эксперт в спорах в судах и НК РФ просто читал :) )
Насчет сроков, тут больше выносит валютный контроль, а не налоговая
Например в ситуации когда оба заказчика из России и один из них еще и с НДС работает (чаще заказчик), то при его проверке могут смотреть договора и если там зашита дата строго, а перевод был в другой день то могут возникнуть вопросы, решается это допником, знаю случаи когда в налоговой им намекали принести такой документ чтобы снять вопросы.
Сделали классную лазейку, что бы можно было без ЭДО обойтись и вообще принять по email документ.
Прочие условия, стороны договорились что документы переданные по электронной почте (указание почты в договоре в реквизитах) имеют силу простой электронной подписи - эта лазейка ? подобным образом можно и акты выполненных работ отправлять, что сторона должна предоставить мотивированный отказ от подписи в течение 10 дней или считается что работа принята и уведомление о расторжение
А насчет сложно и юриста, это реально полезно
Да я полностью согласен с этим, но тут проблема найти хорошего специалиста.
получить авторские права.
Авторские права это прямо целый новый мир, прекрасно понимаю что меня он касается, но там есть права которые отчуждаемые и не отчуждаемые и прочее, тут мне пока совсем не понятно как оно работает.
Акт нужен заказчику, что бы принять работу
Это я так понимаю в вашем случае когда он работу оплачивает авансом то ему акт необходим, а если оплата идет по факту сделанного, то платеж может гарантировать приемку работы или я не правильно понимаю ?
При этом оплату всегда можно разбить на несколько частей, хоть последний рубль оплатить подтверждая приемку работы, ну или отправлять акт на электронную почту.
тоже работаю как ип несколько лет в том числе и с иностранными заказчиками, там нет такого понятия как акт выполненных работ например у них считается если оплатил и не начал оспаривать в суде то все ок
В России сейчас тоже МОЖНО работать без актов, его чаще я видел что называют "Акт выполненных работ", для этого в договоре можно указать что стороны договорились работать без актов выполненных работ, оплата подтверждает качество работ, но как можно понять это удобно работает в ПОСТ оплате(когда оплата после выполнения работ происходит), акт на самом деле более необходим ИСПОЛНИТЕЛЮ!!!!!, чтобы потом не подали в суд и не сказали что вот мы оплатили, а вы работу не сделали, давайте деньги назад, а ты такой ОПА, вы работы приняли вот акт.
В договоре в первую очередь необходимо обращать внимание на предмет договора, я например работаю на патенте и желательно прописать чтобы предметом договора было то что в патенте (Услуги по разработке программ для ЭВМ, заключающиеся в постановке поручений в jira, trello и тд).
Следующий пункт это порядок оплаты (предоплата или постоплата), главное не вводить ограничений что например оплата каждое 10 число месяца (если другая сторона не сможет их выполнять), например имея такой пункт и заказчик оплатит 11 числа, у налоговой могут быть вопросы, почему в договоре 10 число, а деньги пришли 11 (договор не подходит под обоснование), самое простое такое допником (доп соглашением к договору) что стороны договорились что оплата за ..... будет осуществлена 11 числа, вообщем тут надо быть внимательным и четко понимать порядок оплат, с одной стороны фиксировать крайний срок оплаты чтобы можно было требовать деньги в том числе в судебном порядке.
Следующий важный пункт это порядок урегулирования и куда жаловаться на нарушения, на что я бы стал обращать внимания.
Ковид вновь людей научил обращать внимание на форсмажоры
Ну и еще важная часть это порядок расторжения договора, как его можно расторгнуть.
Помимо договора, например существует оферта (предложение заключить договор) его особенность в том что для согласия (подписи) может не требоваться ЭЦП для подписи, а может выступать акцепт (какое то действие, например перевод денег) что помогает в случае работы с иностранным заказчиком. Также существуют еще "договор-счет", "оферта-счет", а при условии что в некоторых случаях можно работать без актов этот же документ может быть и одновременно актом, например таким документом очень удобно получать деньги от заказчика из за границы, где прописываются набор условий (в шапке перечисляются услуги, суммы это по сути предмет договора) далее указываются способ акцепта (оплата в полном объеме по окончанию работ, может быть и перевод 1 рубля до начала работ тоже, но я так не делал), далее указывается остальные пункты, таким документом удобно проходить ВЭД в банках принимая swift платежи (когда они раньше еще были), при этом с заказчиком может быть еще один договор о неразглашение NDA причем западному заказчику достаточно чтобы ты распечатал договор подписал, сделал скан (или фото) и отправил его на почту (электронную) им, для них этого уже достаточно (в других юрисдикция)
в общем все это крайне сложно и требовало много времени на изучение и я понимаю что я по факту не знаю ничего :) было бы хорошо собраться фрилансерам и скинуться и получить консультацию у хорошего юриста что и как надо делать чтобы минимизировать последствия и да я знаю о правилах ведения бизнеса в России.
я по сути целевая аудитория, как раз искал себе подобное рабочее место (лежачее), но остановился на идеи купить стоматологическое кресло (установку) (цена поддержанной до 50к, которая содержит регулировки и тд) и к нему приколхозить уже кронштейн для монитора (там где лампа со светом будет монитор и она двигается хорошо в пространстве) и стол(столешницу) для клавиатуры (там где у стомотолога лежат приспособления он тоже пододвигается)
что касается именно этого кресла то я думаю что идея с поддержкой для ног не очень, там очень много движушихся частей, детали выглядят надежно, но это компромисс на то чтобы сиденье из сидячего превращалось в лежачее, хотя в целом выглядит оно нормально, ну и столешницу надо бы иметь возможность увиличить.
В остальном у этого кресла одни плюсы над тем колхозом который я придумал себе (еще не реализовал), но главный минус цена которая сэкономит время.
В любом случае начинание поддерживаю и интересно было прочитать статью
Можно просто привязать атрибуты к категории товара
тогда атрибуты будут не у товара, а у категории, а значения мы где будем хранить ?
в предложенном мной варианте категория товара воспринималась как тип и атрибуты я предложил добавлял типу товара, но только в виде колонок (product_tvs, product_phones), просто в магазинах может быть типа товара, он обычно один у товара, а могут быть категории это различные элементы меню где показывается товар и тут уже у товара будет связь не 1хN как у типов товаров, а NxM с категориями, поэтому не надо путать что является типом товара, а что категорией, у некоторых бывают и другие способы именования и структуры, речь тут совершенно не про категории или типы.
Статья о том как фильтровать по динамическим атрибутам, выбрали EAV потом начали гарадить ад с запросами потому что значения и атрибуты лежат где то в другом месте, я предложил не использовать eav, а атрибуты добавить товарам, тогда их значения будет лежать в той же строке что и сами товары и фильтровать по таким вещам значительно легче, особенно на больших данных, я молчу о возможности создать индексы.
Но нет лучше товары хранить в одном месте, категории в другом, к категориям привязать атрибуты, а потом эти атрибуты связать с товарами и хранить это(значения) в другой сущности (буква V из EAV) и потом удивлятся на больших данных как это все работает не очень быстро и запросы какие то не интуитивные.
Категория может содержать атрибуты например чтобы показать по чему в этой категории лучше фильтровать, но значения фильтрация идет по атрибутам и значениям товара.
как я уже выше писал серебряной пули нет мы уже ушли в обсуждения категорий, вместо того чтобы признать определенные факты: 1. EAV далеко не лучший способ хранения информации в РСУБД 2. В некоторых случаях пользовательские атрибуты можно задавать колонками в таблице, а значение хранить в этой самой колонке у сущности (товаре), получается существенный выйгрышь в скорости чтения и удобстве фильтрации, цена этому возможные блокировки(таблицы) на этапе создание или удаление атрибутов - это бывает не во всех базах.
В текущей статье о типах товара и не слова, все пользовательские атрибуты навешиваются на product, это сделано для упрощения, вам по сути тоже ничего не мешает повторить это процецедуры иметь кучу nullable колонок это не так плохо в отличие от проблем eav, где большая часть проблем это способы хранения V.
На самом деле новые типы товаров создаются довольно редко, последнее что было это вроде смартфоны и еще не надо путать тип товара и категорию в которой он отображается, вот менеджеры обычно любят играться с категориями в магазине.
Вернувшись к изначальному вопросу если понадобится на какой то тип товара навешивать атрибуты, можно под этот тип создать свою таблицу, ее структура плюс минус будет крайне похожей.
Или отобрать товары разных типов по какому-то одному атрибуту?
Если есть такие требования, то такие атрибуты можно навешивать на таблицу product (общие для всех), а те атрибуты что относятся только к какой то группе товаров их навешивать на группу, тут уже структуру надо допиливать напильником.
Вообще будет крайне странная вещь если в поиске ты поставил покажи мне товары с диагональю от 0 до 50 дюймов и там выпадут все мобильники и кучка телевизиоров с мониторами, крайне странная вещь.
Моя цель не показать универсальную структуру для хранения товаров в магазине, это не возможно, структура определяется требованиями к системе, а показать еще один способ отличный от EAV, который по моему мнению проще (для понимания и поддержки) и быстрее работает на большом числе данных, это не серебренная пуля.
Все предложенные вещи я показал просто для примера существует еще несколько вариантов как решить подобные проблемы и выбирать решение надо исходя из требований, но перечислять тут как можно сделать типы товаров и тд это мягко говоря оффтоп, у всех свой опыт, мой опыт говорит что EAV надо применять крайне осторожно и лишь тогда когда выхода вообще нет, а таких случаев крайне мало, другими словами если сравнивать EAV и просто накидать nullable колонок в таблицу продуктов, по мне(у вас может быть другое мнение это ок) вариант с колонками будет лучше, а раскидывать колонки на типы товаров такое можно делать если не нарушит какие либо требования.
о опять статья о том как создать свой EAV с блэк джэком и перфомансом.
рассказываю способ к которому можно придти от души потанцевав на граблях EAV. учитывая что новые атрибуты добавляются значительно реже чем читаются продукты, можно сделать хранение атрибутов товара ВНЕЗАПНО в КОЛОНКАХ таблицы продуктов.
Тогда когда добавляется атрибут release date можно создать запрос на добавление колонки release date с типом int в таблицу product, таким образом можно добавлять сколько угодно атрибутов товарам мобильные телефоны, мы получим решение кучи проблем EAV.
Внимательные люди могут заметить, а что если у нас не только мобильные телефоны в продуктах, но и например телевизоры ? тогда надо в продуктах добавить type_id и для каждого тайпа хранить свою таблицу product_phones (product_id, ... тут самые расширенные атрибуты) product_tvs(product_id, тут дополнительные атрибуты), например если нужно добавить пользовательский атрибут всем телевизорам, то внезапно добавим его в product_tvs
Когда нужно будет получить список пользовательских атрибутов у типов товаров, можно сделать внезапно посмотреть структуру таблицы (в разных бд там будут разные запросы, но везде можно увидеть имена колонок и их типы и из этого списка убрать product_id).
Цена добавления таким образом атрибута это возможная блокировка таблицы (если там большое количество данных), но блокировка будет не всех бд, в каких то можно добавить без блокировки таблицы, тогда цена этого будет равна нулю, у учитывая первое предположение что атрибуты добавляются довольно редко, а читаются часто можно даже и подождать в некоторых случаях.
Удаление колонки или ее редактирование делается похожим способом, выпадающие списки тоже легко реализовать с доступным одним значением или несколькими, не хочу чтобы комментарий заменял собой статью.
Самое главное как теперь это удобно фильтровать, когда пользовательские атрибуты в таблице реализованы колоннкой, ммм, как легко делать выборку, ммм, думаю без примера кода можно показать.
Я думаю многие находящиеся тут понимают почему эта функция стала обязательной к использованию, потому что оставить возможность продавцу оставлять свой реальный номер (по его желанию) в техническом плане ничего не стоит, но вы такую возможность обычным продавцам не оставили, поэтому рассказ про то какая это полезная функция и как она необходима всем можно было бы опустить
Смею предположить что возможно имея номер телефона и объявления, можно понимать кто чем интересуется и в последствие эта информация может быть "полезна" партнерам в рекомендациях, также как и аудио записи звонков, а раз информация "полезна" и представляет кому то "ценность", возможно они готовы выразить эту "ценность" в денежном эквиваленте, никто не хочет быть товаром, все хотят бесплатный сайт объявлений который существует неизвестно на что.
Чтобы эта функция была действительно полезной нужно лишь сделать чекбокс в котором будет включаться или отключаться эта функция защиты номеров и продавец сам сможет решить использовать ее или нет, пусть по умолчанию эта защита будет включена, но настройка может быть изменена в настройках профиля, тогда пользователи кому это действительно необходимо получили бы полезную функцию, а у кого заведен отдельный номер для объявлений могли бы его указывать и получать звонки напрямую без третей стороны.
Что касается технической части, когда количество номеров < количества объявлений чтобы закреплять номера за объявлениями, вы использовали очередь с приоритетом, где в качестве приоритета использовали дату последнего показа номера, ну и дополнительная операция в ней есть это возможность изменить приоритет. Учитывая масштабы в целом молодцы, но статья сводится к google redis priority queue причем тут нет даже примеров кода, кроме:
SELECT *
FROM dynamic_protections
ORDER BY last_show_time
LIMIT 1
FOR UPDATE SKIP LOCKED;
следующим этапом можно реализовать бесплатный call center avito, звонишь на 8 800 .... там оператор называешь ему номер объявления и он включает нашу любимую классическую музыку и соединяет с продавцом, а он задаст важный вопрос вы не мошенник ? чтобы предоставить максимальную степень защиты, потом можно рассказать как заменили операторов на техническое решение.
Это важно - сначала необходима должность и человек, а потом продукт его деятельности - архитектура.
наивность во мне говорит, что в начале есть требования(или процесс) потом архитектура, с изменением требованиям появляется необходимость в изменение архитектуры (техдолг), что же касается должности и человека это совсем необязательно.
прочитав ваш комментарий можно сделать вывод что архитектура это результат деятельности проектирования "Васи". Если всю работу по архитектуре передать на одного человека (или группу людей) то у них не останется времени на реализацию, а продукт это не то что мы хотели реализовать, а то что у нас получилось в итоге, отсюда имея самую лучшую архитектуру можно получить ужасную реализацию и ужасный продукт, да я знаю что продукт не только его реализация, но и его продвижение и тд, будем их считать одинаковой константой.
Архитектура как раз потеряла всякий ранг и каждый думает, что любая диаграмма и документ - уже архитектура
Никто не может дать четкое определение того что такое архитектура и почти всегда получается довольно субъективное определение, либо она что то дублирует.
Не понимание сложности и смыла процесса приводит к тому, что каждый вставляет свои 5 копеек, а ответственности никто не несет
Этому даже дали название DDD, когда нам было сложно понимать процессы либо они слишком сложны, поэтому будем применять универсальные решения и код тут далеко не на первом месте.
а ответственности никто не несет.
А кто должен нести ответственность ? а за что ответственность ? за "архитектуру" или за продукт или за его реализацию ? кто может проверить "архитектуру" кроме "Васи"?
Полное обесценивание - это как раз сказать, что мы через месяцок всю архитектуру переделаем...
Что в этом плохого ?
если например реализовали процесс покупки товара через корзину, а потом бизнес сказал ой, нам надо не продавать товар, а осуществлять подписку на ... и следом за изменением процесса изменили "архитектуру" и решение (корзины) и текущая система позволила это сделать без side effect для системы в целом, это ли не пример хорошей архитектуры ?
Очень часто даже бизнес не до конца понимает что он хочет в итоге и иногда выстреливают совсем внезапные вещи о которых даже не думали или бизнес хочет проверить гипотезу и надо asap либо выстрелит и сделаем лучше или похороним.
Архитектура проекта - это долгий процесс и мой опыт о том как его уложить в динамику и agile тут.
Не читал, добавил в закладки прочитаю позже.
ой получилось очень много букв, весь мой посыл откуда взятся Васи если бы он придерживался правила "не занимайтесь архитектурой, если вы не архитектор"
Я считаю что архитектурой может заниматься в том числе и разработчик если он в силах предложить решение (это позволит ему рости как специалисту), другое дело что его решение нужно показывать более опытным коллегам или другим разработчикам, также как и "архитектор" должен создавать решения("архитектуру") учитывая возможности команды, из этих решений уже и надо выбирать ответственным с учетом возможности его дальнейшей поддержки.
речь о том что если бы все придерживались правила "не занимайтесь архитектурой, если вы не архитектор" то как бы появились первые архитектор ? они бы либо не придерживались этого "правила", либо о нем не знали, либо никогда бы не стали архитекторами.
Минутка офтопа, архитектуру возводят в ранг религии типо это что такое непоколебимое, но как можно принимать решения на старте проекта которые повлияют на решения через год ? требования меняются постоянно, поэтому смысл тратить много времени на "архитектуру" на начальных этапах когда еще недостаточно компетенции в данном вопросе, вещь мягко говоря сомнительная, это уже из опыта, это был оффтоп.
А на самом деле проблема одна — технический директор вовремя не обратил внимание структуру проекта и распределение задач в целом, а бизнес не сообщил о своих планах подключать всё больше внешних источников данных и сервисов.
дочитал до этого места чуть со стула не упал, так как бывал в ситуации описанной выше со всех сторон, даже со стороны заказчика ставил требования и причина далеко не в CTO.
Очень часто то что делают как MVP или выбирая между сделать нормально за х времени или костыльнуть за у, причем y < x и выбирается решение естественно костыльнуть и вот такой зоопарк потом падает на поддержку, потом команда 2 в этот франкенштейн вкидывает еще костыли и франкенштейн начинает свою жизнь питаясь человека часами, но переписать естественно это нельзя потому что для этого надо бизнесу дать эстимейт по времени, но ты либо честный и говоришь что это нереально эстимейтить и говоришь сроки в месяцах и тебя естественно шлют либо что ?
И очень часто вместе с командой уходит и текущий самый "прошаренный айтишник", а вместе с этим и знания.
sad but true
Очень часто заказчики хотят управлять процессом, который они не хотят понимать и требуют привычные им метрики управления (сроки или другими словами цены) и исходя из этого получают ИЛЛЮЗИЮ управления. В каких то областях такой способ управления вполне работает (например производство), где все разбито на базовые типовые операции и там легко прогнозировать сроки, а в каких то областях это может не работать абсолютно, например разработка где каждая интеграция может иметь свои особенности и очень сильно отличаться и каждая интеграция это как первый запуск нового завода, в новом регионе, производящий разный продукт.
Чтобы изменилось если бы CTO вовремя обратил внимание на структуру проекта и распределение задач в целом, а бизнес ему сообщил о своих планах ?
уже давно существует https://www.sqlstyle.guide/ в том числе там есть и переводы и очень хорошие пояснения зачем и почему, взять его за основу очень логично.
это и есть agile здоровых людей(да я знаю манифест что он не об этом), взяли примерили на себе, собрали обратную связь, приняли решение (оставить или выбросить), так он и строится.
Иногда то что было отброшено раньше может прижиться чуть позже, меняется команда или цели проекта.
А обязательные обряды они в scrum, потому что это прям фреймворк и там лучше или соблюдать все или не начинать.
Scrum разновидность agile, но не единственная.
просмотрел статью по диаганали, по озвученным проблемам уже давно существует решение в виде page object, отсюда в тестах не используется xpath, а используется page object в котором уже скрыта (инкапсулирована) работа с xpath.
Итог: не обязательно добавлять data-testid можно использовать обычные id, class, tag если они есть, вопрос именования это отдельная тема, не будем спорить нужен ли БЭМ или альтернативы.
Добавляя data-testid мы не перестаем использовать xpath, мы вместо использование классов, тэгов, id. Начинаем использовать пользовательские атрибуты.
я знаю разницу между swarm и compose, но спасибо что напомнили.
я говорил что вместо использования docker-compose утилиты, можно сделать
и далее брать текущие docker-compose.yml файлики и запускать примерно так
и все будет работать так как везде docker-compose.yml версии 3 (тут нет специфичных вещей)
при этом разница в том что человек
Не доустанавливал docker-compose утилиту (в некоторых ос ее надо доставлять дополнительно)
Не изучал параметры утилиты docker-compose (вполне достаточно docker swarm, stack и тд того что идет из коробки)
Плюсом получил возможность примитивную возможность объединять в кластер, которой обычно достаточно ОЧЕНЬ многим (некоторые прод держат на docker-compose и если работает и их все устрайвает то почему бы и не ДА ?)
поэтому если человек ищет инструмент для запуска окружения, я бы в 2023 году советовал в начале использовать стандартный (docker swarm вместо docker-compose), а уже потом он сам выберет нужен ему k8s или k3s или что либо другое.
возможности утилиты docker-compose с лихвой перекрываются docker swarm mode и рациональней начинать изучение с нее в 2023 году (как и годами раньше), раньше году в 2015 когда не было swarm mode да docker-compose было полезно и удобно и некоторые по привычки могут его использовать и дальше.
даже не представляю зачем сейчас изучать docker-compose если можно можно брать эти же самые docker-compose.yml (любые где версия 3.х) и запускать их в docker swarm
docker swarm считается заброшенной, а docker-compose это вообще древний рудимент
возможно я набросил слишком холиварно, но docker swarm по всем параметрам обходит docker-compose, единственный минус это не подеррживает версию ниже 3, во второй там были свои "фишки".
я в свое время тоже пришел к деревьям, даже хотел сделать небольшой веб интерфейс для управления, но как всегда руки не дошли.
Моя идея была в том чтобы была мотивация делать дела из нижнего списка, чтобы видеть верхне уровневую цель, например: Основная цель поработить человечество, ее блокирует построение звезды смерти, ее блокирует необходимость создания стабильного ядра звезды смерти (вспоминаем фильм :) ), ее блокирует отсутвующий специалист, ее блокирует конкретная задача: Позвонить Дарт вейдору в понедельник для рекрутинга архитектора.
Вот когда у тебя список дел состоит из задач конкретных при этом всегда видно глобальную цель и при этом видно цепочку того что оно блокирует это лично меня мотивирует ее быстрее сделать, чем если бы просто была задача: Обсудить с Дарт Ведером вакансию архитектора, какого архитектора ? зачем ? что мне это даст ? и соответственно завершая такую мелкую задачку можно сразу показывать что она может разблокировать и фокусироваться на других задачах, также очень удобно одновременно указывать все известные блокеры которые можно делать паралельно.
Применяя такой подход в реальной жизни я гораздо быстрей достигал поставленных целей.
я бы добавил сюда еще то что тестировщика надо как можно раньше подключать к ознакомлению фитчи, от поставноки задачи аналитиком, чтобы он понимал какой именно результат нужен в итоге.
В идеале аналитик = тестировщик, чтобы кто ставил задачи он их и принимал.
опять же напомню я не специалист (не юрист и не эксперт в спорах в судах и НК РФ просто читал :) )
Например в ситуации когда оба заказчика из России и один из них еще и с НДС работает (чаще заказчик), то при его проверке могут смотреть договора и если там зашита дата строго, а перевод был в другой день то могут возникнуть вопросы, решается это допником, знаю случаи когда в налоговой им намекали принести такой документ чтобы снять вопросы.
Прочие условия, стороны договорились что документы переданные по электронной почте (указание почты в договоре в реквизитах) имеют силу простой электронной подписи - эта лазейка ? подобным образом можно и акты выполненных работ отправлять, что сторона должна предоставить мотивированный отказ от подписи в течение 10 дней или считается что работа принята и уведомление о расторжение
Да я полностью согласен с этим, но тут проблема найти хорошего специалиста.
Авторские права это прямо целый новый мир, прекрасно понимаю что меня он касается, но там есть права которые отчуждаемые и не отчуждаемые и прочее, тут мне пока совсем не понятно как оно работает.
Это я так понимаю в вашем случае когда он работу оплачивает авансом то ему акт необходим, а если оплата идет по факту сделанного, то платеж может гарантировать приемку работы или я не правильно понимаю ?
При этом оплату всегда можно разбить на несколько частей, хоть последний рубль оплатить подтверждая приемку работы, ну или отправлять акт на электронную почту.
комментарий можно удалить, ответил не туда https://habr.com/ru/post/711914/comments/#comment_25138518
тоже работаю как ип несколько лет в том числе и с иностранными заказчиками, там нет такого понятия как акт выполненных работ например у них считается если оплатил и не начал оспаривать в суде то все ок
В России сейчас тоже МОЖНО работать без актов, его чаще я видел что называют "Акт выполненных работ", для этого в договоре можно указать что стороны договорились работать без актов выполненных работ, оплата подтверждает качество работ, но как можно понять это удобно работает в ПОСТ оплате(когда оплата после выполнения работ происходит), акт на самом деле более необходим ИСПОЛНИТЕЛЮ!!!!!, чтобы потом не подали в суд и не сказали что вот мы оплатили, а вы работу не сделали, давайте деньги назад, а ты такой ОПА, вы работы приняли вот акт.
В договоре в первую очередь необходимо обращать внимание на предмет договора, я например работаю на патенте и желательно прописать чтобы предметом договора было то что в патенте (Услуги по разработке программ для ЭВМ, заключающиеся в постановке поручений в jira, trello и тд).
Следующий пункт это порядок оплаты (предоплата или постоплата), главное не вводить ограничений что например оплата каждое 10 число месяца (если другая сторона не сможет их выполнять), например имея такой пункт и заказчик оплатит 11 числа, у налоговой могут быть вопросы, почему в договоре 10 число, а деньги пришли 11 (договор не подходит под обоснование), самое простое такое допником (доп соглашением к договору) что стороны договорились что оплата за ..... будет осуществлена 11 числа, вообщем тут надо быть внимательным и четко понимать порядок оплат, с одной стороны фиксировать крайний срок оплаты чтобы можно было требовать деньги в том числе в судебном порядке.
Следующий важный пункт это порядок урегулирования и куда жаловаться на нарушения, на что я бы стал обращать внимания.
Ковид вновь людей научил обращать внимание на форсмажоры
Ну и еще важная часть это порядок расторжения договора, как его можно расторгнуть.
Помимо договора, например существует оферта (предложение заключить договор) его особенность в том что для согласия (подписи) может не требоваться ЭЦП для подписи, а может выступать акцепт (какое то действие, например перевод денег) что помогает в случае работы с иностранным заказчиком. Также существуют еще "договор-счет", "оферта-счет", а при условии что в некоторых случаях можно работать без актов этот же документ может быть и одновременно актом, например таким документом очень удобно получать деньги от заказчика из за границы, где прописываются набор условий (в шапке перечисляются услуги, суммы это по сути предмет договора) далее указываются способ акцепта (оплата в полном объеме по окончанию работ, может быть и перевод 1 рубля до начала работ тоже, но я так не делал), далее указывается остальные пункты, таким документом удобно проходить ВЭД в банках принимая swift платежи (когда они раньше еще были), при этом с заказчиком может быть еще один договор о неразглашение NDA причем западному заказчику достаточно чтобы ты распечатал договор подписал, сделал скан (или фото) и отправил его на почту (электронную) им, для них этого уже достаточно (в других юрисдикция)
в общем все это крайне сложно и требовало много времени на изучение и я понимаю что я по факту не знаю ничего :) было бы хорошо собраться фрилансерам и скинуться и получить консультацию у хорошего юриста что и как надо делать чтобы минимизировать последствия и да я знаю о правилах ведения бизнеса в России.
я по сути целевая аудитория, как раз искал себе подобное рабочее место (лежачее), но остановился на идеи купить стоматологическое кресло (установку) (цена поддержанной до 50к, которая содержит регулировки и тд) и к нему приколхозить уже кронштейн для монитора (там где лампа со светом будет монитор и она двигается хорошо в пространстве) и стол(столешницу) для клавиатуры (там где у стомотолога лежат приспособления он тоже пододвигается)
что касается именно этого кресла то я думаю что идея с поддержкой для ног не очень, там очень много движушихся частей, детали выглядят надежно, но это компромисс на то чтобы сиденье из сидячего превращалось в лежачее, хотя в целом выглядит оно нормально, ну и столешницу надо бы иметь возможность увиличить.
В остальном у этого кресла одни плюсы над тем колхозом который я придумал себе (еще не реализовал), но главный минус цена которая сэкономит время.
В любом случае начинание поддерживаю и интересно было прочитать статью
тогда атрибуты будут не у товара, а у категории, а значения мы где будем хранить ?
в предложенном мной варианте категория товара воспринималась как тип и атрибуты я предложил добавлял типу товара, но только в виде колонок (product_tvs, product_phones), просто в магазинах может быть типа товара, он обычно один у товара, а могут быть категории это различные элементы меню где показывается товар и тут уже у товара будет связь не 1хN как у типов товаров, а NxM с категориями, поэтому не надо путать что является типом товара, а что категорией, у некоторых бывают и другие способы именования и структуры, речь тут совершенно не про категории или типы.
Статья о том как фильтровать по динамическим атрибутам, выбрали EAV потом начали гарадить ад с запросами потому что значения и атрибуты лежат где то в другом месте, я предложил не использовать eav, а атрибуты добавить товарам, тогда их значения будет лежать в той же строке что и сами товары и фильтровать по таким вещам значительно легче, особенно на больших данных, я молчу о возможности создать индексы.
Но нет лучше товары хранить в одном месте, категории в другом, к категориям привязать атрибуты, а потом эти атрибуты связать с товарами и хранить это(значения) в другой сущности (буква V из EAV) и потом удивлятся на больших данных как это все работает не очень быстро и запросы какие то не интуитивные.
Категория может содержать атрибуты например чтобы показать по чему в этой категории лучше фильтровать, но значения фильтрация идет по атрибутам и значениям товара.
как я уже выше писал серебряной пули нет мы уже ушли в обсуждения категорий, вместо того чтобы признать определенные факты:
1. EAV далеко не лучший способ хранения информации в РСУБД
2. В некоторых случаях пользовательские атрибуты можно задавать колонками в таблице, а значение хранить в этой самой колонке у сущности (товаре), получается существенный выйгрышь в скорости чтения и удобстве фильтрации, цена этому возможные блокировки(таблицы) на этапе создание или удаление атрибутов - это бывает не во всех базах.
В текущей статье о типах товара и не слова, все пользовательские атрибуты навешиваются на product, это сделано для упрощения, вам по сути тоже ничего не мешает повторить это процецедуры иметь кучу nullable колонок это не так плохо в отличие от проблем eav, где большая часть проблем это способы хранения V.
На самом деле новые типы товаров создаются довольно редко, последнее что было это вроде смартфоны и еще не надо путать тип товара и категорию в которой он отображается, вот менеджеры обычно любят играться с категориями в магазине.
Вернувшись к изначальному вопросу если понадобится на какой то тип товара навешивать атрибуты, можно под этот тип создать свою таблицу, ее структура плюс минус будет крайне похожей.
Если есть такие требования, то такие атрибуты можно навешивать на таблицу product (общие для всех), а те атрибуты что относятся только к какой то группе товаров их навешивать на группу, тут уже структуру надо допиливать напильником.
Вообще будет крайне странная вещь если в поиске ты поставил покажи мне товары с диагональю от 0 до 50 дюймов и там выпадут все мобильники и кучка телевизиоров с мониторами, крайне странная вещь.
Моя цель не показать универсальную структуру для хранения товаров в магазине, это не возможно, структура определяется требованиями к системе, а показать еще один способ отличный от EAV, который по моему мнению проще (для понимания и поддержки) и быстрее работает на большом числе данных, это не серебренная пуля.
Все предложенные вещи я показал просто для примера существует еще несколько вариантов как решить подобные проблемы и выбирать решение надо исходя из требований, но перечислять тут как можно сделать типы товаров и тд это мягко говоря оффтоп, у всех свой опыт, мой опыт говорит что EAV надо применять крайне осторожно и лишь тогда когда выхода вообще нет, а таких случаев крайне мало, другими словами если сравнивать EAV и просто накидать nullable колонок в таблицу продуктов, по мне(у вас может быть другое мнение это ок) вариант с колонками будет лучше, а раскидывать колонки на типы товаров такое можно делать если не нарушит какие либо требования.
о опять статья о том как создать свой EAV с блэк джэком и перфомансом.
рассказываю способ к которому можно придти от души потанцевав на граблях EAV.
учитывая что новые атрибуты добавляются значительно реже чем читаются продукты, можно сделать хранение атрибутов товара ВНЕЗАПНО в КОЛОНКАХ таблицы продуктов.
Тогда когда добавляется атрибут release date можно создать запрос на добавление колонки release date с типом int в таблицу product, таким образом можно добавлять сколько угодно атрибутов товарам мобильные телефоны, мы получим решение кучи проблем EAV.
Внимательные люди могут заметить, а что если у нас не только мобильные телефоны в продуктах, но и например телевизоры ? тогда надо в продуктах добавить type_id и для каждого тайпа хранить свою таблицу product_phones (product_id, ... тут самые расширенные атрибуты) product_tvs(product_id, тут дополнительные атрибуты), например если нужно добавить пользовательский атрибут всем телевизорам, то внезапно добавим его в product_tvs
Когда нужно будет получить список пользовательских атрибутов у типов товаров, можно сделать внезапно посмотреть структуру таблицы (в разных бд там будут разные запросы, но везде можно увидеть имена колонок и их типы и из этого списка убрать product_id).
Цена добавления таким образом атрибута это возможная блокировка таблицы (если там большое количество данных), но блокировка будет не всех бд, в каких то можно добавить без блокировки таблицы, тогда цена этого будет равна нулю, у учитывая первое предположение что атрибуты добавляются довольно редко, а читаются часто можно даже и подождать в некоторых случаях.
Удаление колонки или ее редактирование делается похожим способом, выпадающие списки тоже легко реализовать с доступным одним значением или несколькими, не хочу чтобы комментарий заменял собой статью.
Самое главное как теперь это удобно фильтровать, когда пользовательские атрибуты в таблице реализованы колоннкой, ммм, как легко делать выборку, ммм, думаю без примера кода можно показать.
Я думаю многие находящиеся тут понимают почему эта функция стала обязательной к использованию, потому что оставить возможность продавцу оставлять свой реальный номер (по его желанию) в техническом плане ничего не стоит, но вы такую возможность обычным продавцам не оставили, поэтому рассказ про то какая это полезная функция и как она необходима всем можно было бы опустить
Смею предположить что возможно имея номер телефона и объявления, можно понимать кто чем интересуется и в последствие эта информация может быть "полезна" партнерам в рекомендациях, также как и аудио записи звонков, а раз информация "полезна" и представляет кому то "ценность", возможно они готовы выразить эту "ценность" в денежном эквиваленте, никто не хочет быть товаром, все хотят бесплатный сайт объявлений который существует неизвестно на что.
Чтобы эта функция была действительно полезной нужно лишь сделать чекбокс в котором будет включаться или отключаться эта функция защиты номеров и продавец сам сможет решить использовать ее или нет, пусть по умолчанию эта защита будет включена, но настройка может быть изменена в настройках профиля, тогда пользователи кому это действительно необходимо получили бы полезную функцию, а у кого заведен отдельный номер для объявлений могли бы его указывать и получать звонки напрямую без третей стороны.
Что касается технической части, когда количество номеров < количества объявлений чтобы закреплять номера за объявлениями, вы использовали очередь с приоритетом, где в качестве приоритета использовали дату последнего показа номера, ну и дополнительная операция в ней есть это возможность изменить приоритет. Учитывая масштабы в целом молодцы, но статья сводится к google redis priority queue причем тут нет даже примеров кода, кроме:
следующим этапом можно реализовать бесплатный call center avito, звонишь на 8 800 .... там оператор называешь ему номер объявления и он включает нашу любимую классическую музыку и соединяет с продавцом, а он задаст важный вопрос вы не мошенник ? чтобы предоставить максимальную степень защиты, потом можно рассказать как заменили операторов на техническое решение.
наивность во мне говорит, что в начале есть требования(или процесс) потом архитектура, с изменением требованиям появляется необходимость в изменение архитектуры (техдолг), что же касается должности и человека это совсем необязательно.
прочитав ваш комментарий можно сделать вывод что архитектура это результат деятельности проектирования "Васи". Если всю работу по архитектуре передать на одного человека (или группу людей) то у них не останется времени на реализацию, а продукт это не то что мы хотели реализовать, а то что у нас получилось в итоге, отсюда имея самую лучшую архитектуру можно получить ужасную реализацию и ужасный продукт, да я знаю что продукт не только его реализация, но и его продвижение и тд, будем их считать одинаковой константой.
Никто не может дать четкое определение того что такое архитектура и почти всегда получается довольно субъективное определение, либо она что то дублирует.
Этому даже дали название DDD, когда нам было сложно понимать процессы либо они слишком сложны, поэтому будем применять универсальные решения и код тут далеко не на первом месте.
А кто должен нести ответственность ? а за что ответственность ? за "архитектуру" или за продукт или за его реализацию ? кто может проверить "архитектуру" кроме "Васи"?
Что в этом плохого ?
если например реализовали процесс покупки товара через корзину, а потом бизнес сказал ой, нам надо не продавать товар, а осуществлять подписку на ... и следом за изменением процесса изменили "архитектуру" и решение (корзины) и текущая система позволила это сделать без side effect для системы в целом, это ли не пример хорошей архитектуры ?
Очень часто даже бизнес не до конца понимает что он хочет в итоге и иногда выстреливают совсем внезапные вещи о которых даже не думали или бизнес хочет проверить гипотезу и надо asap либо выстрелит и сделаем лучше или похороним.
Не читал, добавил в закладки прочитаю позже.
ой получилось очень много букв, весь мой посыл откуда взятся Васи если бы он придерживался правила "не занимайтесь архитектурой, если вы не архитектор"
Я считаю что архитектурой может заниматься в том числе и разработчик если он в силах предложить решение (это позволит ему рости как специалисту), другое дело что его решение нужно показывать более опытным коллегам или другим разработчикам, также как и "архитектор" должен создавать решения("архитектуру") учитывая возможности команды, из этих решений уже и надо выбирать ответственным с учетом возможности его дальнейшей поддержки.
Возможно вы ответили не на ту ветку ?
речь о том что если бы все придерживались правила "не занимайтесь архитектурой, если вы не архитектор" то как бы появились первые архитектор ? они бы либо не придерживались этого "правила", либо о нем не знали, либо никогда бы не стали архитекторами.
Минутка офтопа, архитектуру возводят в ранг религии типо это что такое непоколебимое, но как можно принимать решения на старте проекта которые повлияют на решения через год ? требования меняются постоянно, поэтому смысл тратить много времени на "архитектуру" на начальных этапах когда еще недостаточно компетенции в данном вопросе, вещь мягко говоря сомнительная, это уже из опыта, это был оффтоп.
ps минус поставил вам не я.
Если бы все придерживались этому правилу как бы появились "архитекторы" ?
дочитал до этого места чуть со стула не упал, так как бывал в ситуации описанной выше со всех сторон, даже со стороны заказчика ставил требования и причина далеко не в CTO.
Очень часто то что делают как MVP или выбирая между сделать нормально за х времени или костыльнуть за у, причем y < x и выбирается решение естественно костыльнуть и вот такой зоопарк потом падает на поддержку, потом команда 2 в этот франкенштейн вкидывает еще костыли и франкенштейн начинает свою жизнь питаясь человека часами, но переписать естественно это нельзя потому что для этого надо бизнесу дать эстимейт по времени, но ты либо честный и говоришь что это нереально эстимейтить и говоришь сроки в месяцах и тебя естественно шлют либо что ?
И очень часто вместе с командой уходит и текущий самый "прошаренный айтишник", а вместе с этим и знания.
sad but true
Очень часто заказчики хотят управлять процессом, который они не хотят понимать и требуют привычные им метрики управления (сроки или другими словами цены) и исходя из этого получают ИЛЛЮЗИЮ управления. В каких то областях такой способ управления вполне работает (например производство), где все разбито на базовые типовые операции и там легко прогнозировать сроки, а в каких то областях это может не работать абсолютно, например разработка где каждая интеграция может иметь свои особенности и очень сильно отличаться и каждая интеграция это как первый запуск нового завода, в новом регионе, производящий разный продукт.
Чтобы изменилось если бы CTO вовремя обратил внимание на структуру проекта и распределение задач в целом, а бизнес ему сообщил о своих планах ?
НИ-ЧЕ-ГО
уже давно существует https://www.sqlstyle.guide/ в том числе там есть и переводы и очень хорошие пояснения зачем и почему, взять его за основу очень логично.
статья была бы прекрасной если бы слово "документация" заменили на "инструкция", как минимум в заголовках.
Статью можно сократить (я использовал основные заголовки).
Советы по созданию инструкции
Но это была бы уже не статья, а checklist создания инструкции.
это и есть agile здоровых людей(да я знаю манифест что он не об этом), взяли примерили на себе, собрали обратную связь, приняли решение (оставить или выбросить), так он и строится.
Иногда то что было отброшено раньше может прижиться чуть позже, меняется команда или цели проекта.
А обязательные обряды они в scrum, потому что это прям фреймворк и там лучше или соблюдать все или не начинать.
Scrum разновидность agile, но не единственная.