Суть — верна — надо иметь ваши собственные, Российские, руты итд, но форма комментария отвратительна. Какие незалежные и каким панам? У вас телевизор головного мозга.
(Если что я из ЕС, Литвы, которая, как многие думают, ненавидит Россию и всё такое)
Как выглядит смысловая разбивка давно описано в DDD. Вот пример, где даже слишком, слегка.
Для не очень больших проектов я использую смысловое разбиение с акцентом на реиспользованиe. Т.е. Я беру вот эту одну папку и переношу ее в другой проект почти без изменений.
Есть подписки, но это тоже тупик… Потому, что там 2 бакса, там 10, там 5, там 3, за программы 15,… в итоге знаю людей, у которых подписки это больше 500 баксов в месяц и это только начало… Калькулятор с подпиской 2 бакса в месяц? Один сериал на одном сервисе за 10 в месяц, второй на другом за 20 в месяц…
Я не об этом. Я о том, что фб в принципе не может стать платным. Ибо за деньги его купит малая часть аудитории, а весь смысл его бизнеса в количестве… Значит это манипуляция… (Пруфов не дам, просто здравый смысл)
Вангую — на следующий день как фб станет платным — он лишится ~80+% аудитории. И кому он тогда…
Мне, например, контекстная реклама удобна. Но после сообщения «разрешите, а-то мы станем платными» — запретил. Потому что они уху ели.
Что логично-то? Если они введут платную подписку — сразу потеряют огромную часть пользователей. Тех, например, как я, кому фб безразличен. Есть? Ок. Нет? Ок. И, основываясь на простой логике, без пуфов, такиж как я — %60-80 всего фейсбука. Молодь в тиктоке, постарше — однокласники (или аналоги)… Т.е. это просто блеф для не слишком разумных, имхо. А без массы пользователей и информации — кому вообще нужен фб? Простых аггрегаторов сейчас хоть… ешь…
Самая большая беда Конга — современные сценаристы. Которые заставляют и его и бедную годзиллу такой фигнёй заниматься, что мозг в трубочку сворачивается. Я не жду Достоевского от комиксоидного фильма, но хотелось бы хотя бы на уровне минимально здравого смысла что-то… И хм… диалоги… хм… Не пищу что думаю чтобы фанаты не набежали
Здесь есть одна проблема… Я делаю сложнейшие вещи, знаком с десятками или даже сотнями языков, технологий, паттернов,… Организую процессы в большой организации. Обучаю людей. Поддерживаю сервера. Пишу код, который работает десятилетиями без присмотра. Но я не пройду собеседование если меня начнут спрашивать про красно-черное дерево. Или попросят быстро, на бумаге, реализовать сложный алгоритм. Мало того, поскольку я знаю около 10+ языков программирования (упрощаю) — я не всегда помню даже названия стандартных функций тупо работы со строкой. Зато я за 2 дня решаю проблемы, которые целые команды не могли решить несколько месяцев (факт)… Голова забита десятилетиями опыта в разных областях. И, часто, мне надо загуглить какие-то вещи, чтобы вспомнить (! — ключевое слово) как это делается здесь. Не узнать как это делать, а вспомнить нюансы. Моя проблема самозванца именно в этом. Я решу вообще любую реализуемую задачу (если будет достаточно времени), но не уверен что пройду собеседование в почти любую серьезную контору кроме той, кто со мной уже работал. Беда…
проблема в том, что надо платить 200 гуглю, 200 эпплам, 200 яндексу, 200 ivi, 200,… Вроде и небольшие деньги, но если посчитать все подписки — становится ощутимо. Особенно если вы оплачиваете всей семье с детьми и все такое… 199 рублей легко превращается в 100+ евро. И это только начало перевода всего на подписки.
Если упростить, то сейчас у нас так — каждая фича в отдельной, простите, фиче. Затем они последовательно по некоторому алгоритму опускаются в preRC, далее в RC и когда уже точно пойдет в релиз — попадает в релиз. После деплоя релиз мерджится в мастер. Т.е. в мастере всегда лежит то, что на данный момент крутится на проде. В релизе всегда то, что уйдет в прод следующим. Разработка в мастере и релизах не ведется. Попадание в релизные ветки только через пуллреквесты из фич. Никаких исправлений прямо там. Хотфиксы бывают так редко, что можно считать их форсмажором. После деплоя релиза все обновляют свои фичи из нового мастера.
Ветка develop, вследствие нашей специфики, практически вообще не используется. Зато там есть все.
Поэтому все новые фичи начинаются с бранча от мастера. Т.е. взял мастер, отпочковал от него фичу, пилишь, двигаешь к релизу. Ну такой сильно-сильно кастомизированный gitflow. Работать позволяет, но… не красиво как-то. Поэтому как руки дойдут буду думать.
Основные инструменты — tfs (devops) + teamcity + много мелочей. Нам более чем хватает.
Я бы рассказал если бы оно было адекватным… Пока — есть два дополнительных PreReleaseCandidat и ReleaseCandidat в дополнение к Release. Что есть ужасъ, адъ и скрежет зубовный™. Но руки не доходят сесть и хорошо подумать. Все что можно автоматизировал, все привыкли, вроде «и так хорошо». Вот статья стала стимулом, наконец. Может дадут ссылок в комментариях на «новые тенденции» в данной области.
Если (когда) сделаю что-то в этой области, чем не стыдно поделиться — напишу обязательно.
А что там упрощать? Моя команда, когда-то, поняла суть за 5 минут объяснений включая джунов. Пользуемся много лет кастомизированным, потому что не получается сделать удобным для всех механизм когда не все из того что готовится к релизу может в этот релиз войти. Некоторые локальные тонкости.
Если разумно построить процессы — пользоваться можно. На самом деле сама схема достаточно проста и, главное, логична. Минусы, конечно есть. Но на свои задачи я ничего лучше пока не нашел. Будет интересно если кто-то предложит альтернативные варианты. Подписался.
Чаще всего DDD используется в крупных энтерпрайз решениях ибо именно там раскрывается вся его мощь. Показывать такой код чаще всего нельзя. Я, например, не могу показать свой код.
Можете посмотреть на плюралсайте лекции по DDD. Хориков, например, показывает неплохие уроки для чего нужен DDD и чем он полезен (для самых начинающих). Уже не помню кто еще.
Так что, навскидку, не помню, извините, не помогу. Если вспомню или наткнусь — поделюсь обязательно.
P.S. Некоторое дублирование кода неизбежно из за принципа… не знаю как это по русски, ограниченных контекстов (?). Это очень удобно, кстати, на больших проектах, которые пилятся большим количеством людей \ команд. Здорово окупается. Причем это удобно даже на относительно небольших проектах. Вообще, из моего опыта, DDD очень полезен начиная с некоторого размера проекта или команды, но надо осознавать его минусы и использовать без фанатичного следования «догме».
Голый sql допустим если использовать cqrs. Не помню используется ли он в том проекте на который я ссылался, но вроде должен был.
По ссылке что я привел — немного перебор, но, опять же, чтобы понять принцип — смотреть можно.
Цвет и форму иконок можно менять. Правда в иконке будет только два цвета, насколько я помню, зато любых + прозрачность. И форму тоже можно менять.
Я и не говорил что это идеальное решение. Но. Несколько тысяч, бесплатно, оффлайн, с поиском… Если хотите и вам не хватает того что там есть — сделайте экспорт из этого редактора и раскрасьте сами.
(Если что я из ЕС, Литвы, которая, как многие думают, ненавидит Россию и всё такое)
Для не очень больших проектов я использую смысловое разбиение с акцентом на реиспользованиe. Т.е. Я беру вот эту одну папку и переношу ее в другой проект почти без изменений.
Есть подписки, но это тоже тупик… Потому, что там 2 бакса, там 10, там 5, там 3, за программы 15,… в итоге знаю людей, у которых подписки это больше 500 баксов в месяц и это только начало… Калькулятор с подпиской 2 бакса в месяц? Один сериал на одном сервисе за 10 в месяц, второй на другом за 20 в месяц…
Я не об этом. Я о том, что фб в принципе не может стать платным. Ибо за деньги его купит малая часть аудитории, а весь смысл его бизнеса в количестве… Значит это манипуляция… (Пруфов не дам, просто здравый смысл)
Вангую — на следующий день как фб станет платным — он лишится ~80+% аудитории. И кому он тогда…
Мне, например, контекстная реклама удобна. Но после сообщения «разрешите, а-то мы станем платными» — запретил. Потому что они уху ели.
А можно узнать какие?
Вот уже и в машинах подогрев сидений по подписке…
Ветка develop, вследствие нашей специфики, практически вообще не используется. Зато там есть все.
Поэтому все новые фичи начинаются с бранча от мастера. Т.е. взял мастер, отпочковал от него фичу, пилишь, двигаешь к релизу. Ну такой сильно-сильно кастомизированный gitflow. Работать позволяет, но… не красиво как-то. Поэтому как руки дойдут буду думать.
Основные инструменты — tfs (devops) + teamcity + много мелочей. Нам более чем хватает.
Если (когда) сделаю что-то в этой области, чем не стыдно поделиться — напишу обязательно.
Если разумно построить процессы — пользоваться можно. На самом деле сама схема достаточно проста и, главное, логична. Минусы, конечно есть. Но на свои задачи я ничего лучше пока не нашел. Будет интересно если кто-то предложит альтернативные варианты. Подписался.
Можете посмотреть на плюралсайте лекции по DDD. Хориков, например, показывает неплохие уроки для чего нужен DDD и чем он полезен (для самых начинающих). Уже не помню кто еще.
Так что, навскидку, не помню, извините, не помогу. Если вспомню или наткнусь — поделюсь обязательно.
P.S. Некоторое дублирование кода неизбежно из за принципа… не знаю как это по русски, ограниченных контекстов (?). Это очень удобно, кстати, на больших проектах, которые пилятся большим количеством людей \ команд. Здорово окупается. Причем это удобно даже на относительно небольших проектах. Вообще, из моего опыта, DDD очень полезен начиная с некоторого размера проекта или команды, но надо осознавать его минусы и использовать без фанатичного следования «догме».
Голый sql допустим если использовать cqrs. Не помню используется ли он в том проекте на который я ссылался, но вроде должен был.
По ссылке что я привел — немного перебор, но, опять же, чтобы понять принцип — смотреть можно.
Я и не говорил что это идеальное решение. Но. Несколько тысяч, бесплатно, оффлайн, с поиском… Если хотите и вам не хватает того что там есть — сделайте экспорт из этого редактора и раскрасьте сами.