• Что сегодня подразумевается под веб-компонентами?

    @MadridianFox
    Web-программист, многостаночник
    Веб-компоненты - обобщающее название нескольких технологий, позволяющих создавать собственные элементы с инкапсулированными структурой, стилями и поведением.
    Т.е. вы создаёте один-два файла в какой-нибудь папочке, описываете в них разметку, стили и js-код и вызовом некоторых api-функций говорите браузеру - "вот мой собственный элемент с именем my-element, если встретишь тэг , то наполни его вот этим, стилизуй вот так и по событиям выполняй этот код".
    Технологии, которые это позволяют постепенно появляются в браузерах, но как обычно не полностью и не везде. Нужны полифилы.

    И да, веб-компонент мужского рода)
    Ответ написан
    1 комментарий
  • Единый список "Сегодня" / "ToDo" с разных досок Trello. Как сделать?

    Maksclub
    @Maksclub
    maksfedorov.ru
    Решение:
    • Называете одинаково на всех досках список ToDo
    • В поиске вбиваете: list:ToDo
    • Если нужно только активные list:ToDo is:open
    • Если нужно только активные кроме доски NotDo list:ToDo is:open -board:NotDo
    • Можно комбинировать запрос (фильтровать, минусовать) и сохранять эти запросы для расширенного тарифа


    Фильтрация задач по спискам или доскам в Trello
    Ответ написан
    1 комментарий
  • Как сформировать налоговую декларацию со штрих-кодом(pdf-417)?

    @Eddy_Em
    Советую не мучиться со всякой XML'щиной, а сделать один раз шаблон в латехе и генерировать потом pdf'ки. Для штрих-кодов есть разные пакеты. Я, к примеру, использовал pst-barcode.
    Ответ написан
    1 комментарий
  • UX взятый с другого сайта?

    @RoverWhite
    Ну если Вы не собираетесь что-то сдирать у Apple то вероятно у Вас не должно возникнуть никаких проблем. Чтобы данный интерфейс стал Авторским, его необходимо запатентовать, причем именно в виде решений для организации интерфейса, на моей памяти такого никто не делал.
    Ответ написан
    Комментировать
  • Проект со сложной логикой на Symfony – как проектировать? Примеры?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Как хранить бизнес-логику чтобы модели не превратились в монстров из десятков тысяч строк?

    Тут не совсем модели. Entity - это просто объект данных, умеет хранить их в себе и бросать исключения, если не правильные данные вставляете, все. Repository - умеет работать со своим Entity И БД.

    БЛ находится в классах сервисах.

    Читал про Command Bus где, если правильно понял, на каждое действие в системе – свой класс?

    Вообще под каждое дествие - не обязательно, тут нужно руководствоваться здравым смыслом.

    Как их организуете (их тогда будут сотни)?

    Иерархически. Путь к классу должен быть "понимаем".

    Есть ли смысл выносить каждую доменную модель в модуль/микросервис, хранить всю связанную логику где-то там внутри, а с остальными общаться по внешнему API?

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

    За ответы в клиентскую часть – отдельный сервис-фронтенд?

    Если в "сервис" вы вкладываете понятие простого класса, умеющего форматировать ответы вашего проекта - мысль здравая.
    Если ответы будут асинхронными (от сервера к другому) - имеет смысл выностить в отдельный клиентский класс.

    Каков оверхед?

    Ничтожный.

    Используют ли такое на практике?

    Да

    Какие подводные камни?

    Следствием серьезной декомпозиции в любом случае будут лишние сущности, чем раньше от них будете избавляться - тем лучше.

    Как не превратить кидание/получение событий типа PostBeforeEdit/PostBeforeEditHandler в "callback hell"?

    Если есть возможность отказаться от событийной модели - часто лучше отказаться.
    Листнеры доктрины конечно штука мощная, но работает не всегда очевидно.

    Функционал "PostBeforeEdit/PostBeforeEditHandler" часто дешевле и проще вынести в сервис, но опять же руководствуйтесь здравым смыслом.

    ACL Где храните указанную логику?

    Если ACL будет не тривиальный - готовьте себя к тому, что он будет размазан по уровню контроллеров.

    Какие структуры для описанного выше – best practice?

    Если есть возможность привести к одноуровневому виду - сделайте. Если с точки зрения бизнеса может потребоваться иерархическая (не фиксированной вложенности) ACL - до последнего убеждайте, что это плохая идея, не повторяйте чужих ошибок.

    В моём понимании это выглядит как куча трёхмерных кубов доступа "crud – group – entity – field", как это сделать более плоским пока только одна идея – делать кучу таблиц many-to-many.

    Гибкая настройка вплоть до каждого поля 90% что не нужна. Если можно свести к понятию скопов прав - сделайте это.
    Структуру можно предлагать только зная ваш проект.

    Версионирование. Как вы версионируете подобные проекты?

    Semver.

    А если нужна "N-1" рабочая версия на продакшене?

    Значит на прод попадает ваша версия с тегом "N-1"))

    Есть ли смысл разделять версии в рамках единой кодовой базы проекта и как (неймспейсы, конфиг, модуль, что-то ещё)?

    Храните яйца в отдельных корзинках. Если модуль развивается полностью отдельно и может быть вынесен как зависимость проекта в vendor - делайте.

    И, самое главное – как всё это совместить?

    • РУКОВОДСТВУЙТЕСЬ ЗДРАВЫМ СМЫСЛОМ
    • Принимаете жесткие соглашения по правилам написания кода, например такие
    • Постарайтесь убедить бизнес в том, что без покрытия кода автотестами будет дороже, нестабильней и дольше. + Пишите тесты. Если объем тестов в 4 раза больше кода, который они тестируют - это норм. У меня бывали случаи, когда для критичного функционала тестов было в ~16 раз больше, чем кода.
    • Жесткие, обязательные кодревью.
    • Если задача крупная - декомпозируйте ее.
    • Технический долг - возвращайте обязательно И как можно скорее.
    • Перед тем как писать код для работы с внешним сервисом - имеет смысл написать его эмулятор.
    • Спешите только в случае серьезных проблем на проде)). Фичи "на вчера" отличаются от фич "на потом" только приоритетом выполнения, более ничем.
    Ответ написан
    6 комментариев
  • Как подготовиться к закону Яровой?

    @nirvimel
    1. Купите недорогой VPS (от $15/год, можно даже дешевле) и поднимите на нем личный VPN. В Сети есть куча подробных руководств как это делается. Только не надо говорить, что у вас нет на это денег, интернетом вы же не бесплатно пользуетесь. Просто примите это как небольшую дополнительную плату за интернет за ваш спокойный сон.
    2. Работая через VPN (обязательно), заведите себе новый почтовый ящик на зарубежном сервере у компании, у которой нет никакого бизнеса и любых коммерческих интересов в РФ. Пусть это будет не мажорный гигант индустрии, а скромная компания, малоизвестная в РФ. Главное - это наличие SSL в веб-интерфейсе и в IMAP, в остальном почта есть почта, она просто работает, и этого достаточно.
    3. Работая через VPN, заведите себе новый аккаунт в vk facebook и/или google (если вы неспособны полностью отказаться от использования социалок). При регистрации указывайте место проживания подальше от РФ. Учитывайте, что все гиганты индустрии, имеющие большой бизнес в РФ, полностью сотрудничает с ГБ, но аккаунты нерезидентов, зарегистрированные и посещаемые с зарубежных IP, они не станут сливать по умолчанию (но по первому запросу сольют мгновенно). Так что забудьте про любые приваты в социалках, ведите все общение так, как будто все это читает весь ваш квартал и все те, кому бы вам меньше всего хотелось это показывать. Для приватного общения пользуйтесь только безопасной почтой (пункт 2) и защищенными чатами, на telegram jabber на зарубежных серверах. Все это касается только тех, кто не может окончательно завязать с пагубной зависимостью от соц.сетей. Очевидно, наиболее безопасным (и полезным для здоровья) вариантом является полный отказ от социалок.
    4. Не вбрасывайте в старые ящики и соц.аккаунты адреса и ссылки на новые чистые, не указывайте новые адреса в любых исходящих и старайтесь, чтобы они не попали во входящие. Помните, что в любой социалке и любом веб-интерфейсе почты (сотрудничающей) кнопка "удалить" скрывает удаляемое только от вас самих и не более того.
    5. (Самый неприятный пункт) Забудьте про vk, mail.ru и российские gmail и facebook. - КАК? - Так! Я понимаю, что это не легко, что они давно стали частью вашей жизни. Но это придется сделать! Поговорите сами с собой, спросите себя что для вас важнее: ваша личная безопасность, спокойствие и крепкий сон или старые привычки, которыми вы опутаны, и которые не хотят отпускать вас? Учтите, что продолжая пользоваться местными социалками (и сотрудничающими иностранными), вы продолжаете каждый день генерировать на себя тонны компромата, который может обернуться против вас в самый неожиданный момент самым неприятным образом. Проявляя активность в своих старых аккаунтах, вы не даете им "протухнуть" и не даете даже формального повода добрым компаниям снести их через пол года, после истечения отведенного законом срока хранения (как известно, vk не ограничивается минимальным сроком хранения, а хранит все метаданные и текст практически вечно за исключением видео/аудио).
    Ответ написан
    26 комментариев
  • Как сделать личный кабинет и реф. систему на wordpress?

    @deadmemoras
    1 шаг:
    Убрать cms и писать на фрейме или с 0.
    Ответ написан
    Комментировать
  • Как создать такую спираль в Adobe Illustrator?

    goandkill
    @goandkill
    live slow — die old
    6d0e72a744fa41cab2a17cad9bf7d2a6.png

    1. Рисуешь круги
    2. Объединяешь их в compound path
    3. Копируешь этот compound path
    4. Делаешь один из compound path меньшего размера
    5. Выделяешь оба, делаешь им Blend
    6. Рисуешь path спиралью.
    7. Выделяешь спираль и blend, делаешь replace spline
    Ответ написан
    2 комментария
  • Какую библиотеку PANTONE использовать для покраски логотипов в CMYK?

    Nekto_Habr
    @Nekto_Habr
    Чат дизайнеров: https://t.me/figma_life
    Какую библиотеку PANTONE использовать для покраски логотипов в CMYK?


    Pantone+ Solid Coated
    Для перевода в CMYK - ищем пантон из первой библиотеки в библиотеке Pantone+ Color Bridge Coated (название будет такое же, но в конце добавится буква "P")

    PANTONE CMYK Coated
    PANTONE CMYK Uncoated
    Чем они отличаются?


    Coated - для мелованной бумаги
    Uncoated - для немелованной

    Либо подразумевается покрытие материала (в случае, если печать не на бумаге). Это означает, что краска будет впитываться либо в покрытие материала, либо в сам материал (если он не покрыт специальным слоем).
    Ответ написан
    2 комментария
  • С чего начать писать тех.задание?

    @dmitryKovalskiy
    программист средней руки
    protect.gost.ru/v.aspx?control=8&baseC=-1&page=0&m... - 4 странички эти уже прочитали?из них 1 страничка обложки, а вторая пустая. Первые пункты - "Основание для разработки", "назначение разработки". На мой взгляд если вы не можете описать эти 2 пункта - вы не очень понимаете какую проблему вообще решаете, а соответственно написать конкретное тех.задание будет трудно
    Ответ написан
  • Как настроить illustrator для Web дизайна?

    Nekto_Habr
    @Nekto_Habr
    Чат дизайнеров: https://t.me/figma_life
    У иллюстратора во все времена традиционно плохо работает всё, что касается пиксель-перфект. Придется помучаться.

    Много кто, и я в их числе, советуют не использовать эту функцию привязки к пиксельной сетке (которая в панельке transform и в диалоге создания нового документа). Вместо этого, нужно в настройках программы сделать пользовательскую сетку кратной одному пикселю (edit->preferences->guides and grid), и потом в меню view включить snap to grid (отобразить сетку можно с помощью CTRL+' ).

    Этот костыль лучше и безглючнее
    Ответ написан
    7 комментариев
  • Как вот так анимировать иконки, что используется для этого?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    PhotoShop, After Effects -> to gif.

    Можно конечно попробовать сымитировать на CSS, но это будет весьма трудоемко. Можете начать отсюда:
    https://daneden.github.io/animate.css/
    https://developer.mozilla.org/en-US/docs/Web/CSS/C...
    https://developer.mozilla.org/en-US/docs/Web/CSS/@...
    продолжить сюда:
    greensock.com/tweenmax

    Демки: css-live.ru/cssjssvg-s-podvypodvertom/ezhenedelnay...
    Ответ написан
    Комментировать
  • Какой фреймворк выбрать для громоздкого сайта?

    @kamwork
    А зачем для него впринципе frontend фреймверк? Обычный статейник, берите WP или другую готовую CMS.
    Ответ написан
    Комментировать
  • Docker как локальный web-сервер (замена Open Server, Xampp и т.д.)?

    IvanCher
    @IvanCher
    Мысли шире
    Странные конечно ответы отмечены решениями, меня это несколько удивляет.
    Немного расскажу автору вопроса про вагрант и докер, в чем разница.
    Вагрант - это лишь обертка над virtualbox для создания заранее сконфигурированной машины в виртуалбоксе. Польза от него есть, но только для разработчиков. На продакшн сервер Вы не сможете развернуть то же окружение при помощи вагранта.

    Докер, на сегодня, это целый набор инструментов. Сам докер является клиент-серверной системой контейнеризации, сервер докера должен крутить в линуксе, клиент хоть где.
    Для винды у докера есть своя сборка, которая включает докер-сервер/клиент, докер-машин, докер-композ.
    Докер-машин будет для Вас запускать очень легковесную виртуальную машину с линуксом, и на ней с докер-сервером. С винды(хоста) вы будете обращаться к этой виртуалке через стандартный докер-клиент.

    Докер, в отличии от вагранта, позволит Вам иметь идентичные окружения и на дев-сервере, и на продакшн, и на тестовом, и везде, где только можно. Этим он выгодно отличается от вагранта.
    Вагрант в связи с вышеупомянутым недостатком и ориентированность только на дев-окружение, тихонько отмирает.

    В итоге, советую Вам сейчас уже начинать с докера всё же, а на вагрант забить и без необходимости не забывать себе голову лишней технологией, посколько чем забить голову - найдется :)

    На счёт того, как конкретно развернуть на докере ламп или что-то подобное, сперва прочтите Getting started на оф. сайте докера, затем гляньте на докхабе образы для веба, там их несколько и каждый описывает инетерсные подходы.

    Удачи, надеюсь мой комментарий был Вам полезен.
    Ответ написан
    11 комментариев
  • Как сделать Gif такие как на dribbble???

    AppFA
    @AppFA
    Frontend developer at Yandex
    Motion design, скорее всего подобное делается в After Effect.
    Ответ написан
    Комментировать
  • Как вы используете Mac OS?

    SnapSh0t
    @SnapSh0t
    iOS-Developer
    тоже всегда пользуюсь Spotlight для поиска каких-либо программ или выполнения каких-либо операций.

    Терминал немного проапгрейдил программой "oh my Zsh" его плюсы можно найти во всемирной паутине.
    Ответ написан
  • Как вы создаете сайты в плане дизайна?

    arutyunov
    @arutyunov
    Mooza.ru — Делаем сайты
    Проектирование и прототипирование должны предшествовать открытию фотошопа.
    Прототипировать можно как на бумаге, так и с помощью софта.

    Не наметив цели, вы не сможете выбрать верный путь. Прототип — это постановка цели.

    Вы должны понимать, что главное — это не красиво, а удобно. Промо-сайты — исключение, но и там удобство должно присутствовать.
    Если же начать работу сразу с фотошопа, то вы будете по 10 раз переделывать одни и те же элементы, меняя их местами и т.д. И вы потратите гораздо больше времени на макет, чем если бы вы имели на руках прототип будущего макета.
    Ответ написан
    Комментировать
  • Прием платежей, без посредников?

    @dmitryKovalskiy
    программист средней руки
    Не хотите посредников? Ок, без проблем. Вам нужен договор на услуги эквайринга с каждой системой электронных денег, которые вы хотите на сайте, а также с банком предоставляющим услуги эквайринга банковских карт. По каждому такому договору вы обязаны будете пройти приемосдаточные испытания и на выходе получите нужные вам услуги с комиссией около 3%. Хотите меньше? Поднимайте оборот до миллионов в месяц, тогда может и снизят. Опять же - у каждой системы будет свой оборот и если по банковским картам вам за оборот и снизят комиссию, то по электронным кошелькам оборот может и не дотянуть. Добавьте еще разработку и внедрение страницы агрегирования всех этих приблуд, поддержку API каждой системы приема платежей в отдельности, а так же ежедневные сверки реестров по каждой платежной системе. Если вы считаете что вот вся эта работа стоит экономии в 2% - то вперед к победе коммунизма. Да и кстати - если вы физ.лицо, то ни одна организация с вами не будет заключать договора на поставку подобных услуг. Ни банки, ни вебманя никто... Физлицам дорога только в Яндекс.Кассу, Робокассу и иже с ними подобными.
    Ответ написан
    2 комментария
  • Попросили проверить код, на что смотреть нужно?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Смотря зачем)). Я когда делаю Code Review критерии следующие:

    * Безопасность:
    - Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
    - Никаких trigger_error, только исключения.
    - Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
    - Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
    - За eval как правило шлю на **й.
    - @ допускается только в безвыходных ситуациях, например проверка json_last_error.
    - Перед работой с БД - обязательная проверка данных.
    - Никаких == и !=. Со swtich - единственное исключение, по ситуации.
    - Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
    - Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
    - Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
    - Конкатенации в sql - только в безвыходных ситуациях.
    - Параметры в sql - ТОЛЬКО через плейсхолдеры.
    - Никаких глобальных переменных.
    - Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
    - Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

    * Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
    - В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
    - Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

    * Организация кода:
    - Никаких глобальных функций.
    - Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

    * Тестируемость (в смысле простота тестирования) кода должна быть высокая.
    - Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

    * Принципы MVC:
    - Никаких обработок пользовательского ввода в моделях, от слова совсем.
    - Никаких ***ть запросов в БД из шаблонов.
    - Никаких верстки/js/css/sql-ин в контроллерах.
    - В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
    - В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

    * Принципы SOLD:
    - Никаких божественных объектов умеющих во все.
    - Если метод для внутреннего пользования - private, никаких public.
    - Статические методы разрешаются только в случае безвыходности.

    * Принцип DRY разрешено нарушать в случаях:
    - Явного разделения обязанностей
    - В тестах (каждый тест должен быть независимым, на сколько это возможно)

    * Работа с БД:
    - Запрос в цикле должен быть РЕАЛЬНО обоснован.
    - За ORDER BY RAND() - шлю на***й.
    - Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
    - Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
    - SELECT * - запрещен.
    - Денормализация БД должна быть обоснована.
    - MyISAM не используется (так уж)) )
    - Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
    - БД не должна содержать бизнес логики, только данные в целостном виде.
    - Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

    * Кэш должен очищаться по двум условиям (не по одному из, а именно по двум):
    - Время.
    - Протухание по бизнес логике.
    Разрешается по только времени в безвыходных ситуациях, но тогда время - короткий период.
    - При расчете ключей кэша должна использоваться переменная из конфигурации приложения (на случай обновлений кэш сбрасывается кодом, а не флашем кэш-сервера). В случае использования множества серверов - это очень удобный и гибкий инструмент при диплое.

    * О людях:
    - "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
    - "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
    - "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
    - "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
    - "У меня все работает!" - рад за тебя, а как на счет продакшна?
    - "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

    * Всякое:
    ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
    То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

    Это далеко не полный список требований, очень много зависит от проекта в целом и от принципов, заложенных в нем. Для больших мредж реквестов 200 комментариев к коду - это ок. Дерзайте.

    UPD

    Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions
    Ответ написан
    56 комментариев