• Делим Laravel на компоненты
    0

    Спасибо за ответ. А расскажите, почему именно ларовские компоненты использовались, а не симфоневые?

  • Делим Laravel на компоненты
    0

    Не понимаю позиции заказчика — отказ от фреймворков. Ведь ты в любом случае будешь использовать (микро)фреймворк, только самописный. Убедить не пытались? Если пытались, то как?
    Расскажите, пожалуйста, подробнее.

  • Время до первого байта: что это такое и почему это важно
    +2

    Я просто уплыл. Этот материал можно было выразить в трех предложениях: ttfb является временем от отправки запроса до получения ответа. На него влияют такие параметры. Вы как фронтендер реально ничем не можете на него повлиять.


    Спасибо за впустую потраченные 5 минут.

  • Как мы пересадили всю команду на другой язык за один день (на самом деле нет)
    0

    Спасибо. Сохранил.

  • Вопросы будущему работодателю
    0

    Вполне возможно. Мне большую часть этого списка прислал в свое время коллега, я его только слегка модифицировал.

  • Вопросы будущему работодателю
    0

    Да, это бизнес-аналитика. Пункт связан со следующим по списку.

  • Вопросы будущему работодателю
    +10

    Мой личный список вопросов работодателю (если не было освещено на собеседовании).


    Чем я буду заниматься? Только узкими обязанностями или еще и смежными?
    Какой стек на моём проекте? Есть ли легаси?
    Что с тестированием
    Есть ли CI/CD и девопс инженер?
    Будет ли единый ПМ и четко заданный жизненный цикл таска?
    Есть ли БА?
    Системы мониторинга, сборщик логов?
    Переработки бывают? Оплата?
    Системы трекинга времени и руткиты на рабочем компе?
    Отпуска: дробление отпуска, включены или нет выходные, за сколько нужно предупреждать, отказы
    За что и как часто получаются премии? Кто определяет их размер?
    Есть ли СБ? Какие требования у СБ?
    Почему открыта вакансия? Если не новая, то куда ушел предыдущий разработчик?
    Аналогично про гибкий график, карьерный рост. Что это значит и в чем выражается.
    Ретроспектива.
    Код ревью в компании: кто, как долго, что если пожар.

  • Советы по оптимизации Laravel-архитектуры с AWS
    +3
    Именно в этом Laravel лучше PHP, в котором нет никаких шаблонов.

    Вы серьезно? Вы думаете, после подобных фраз к вам придет хоть один человек на курс? Ну вот объективно оцените свой уровень и поймите, что это полный и беспросветный ужас.

  • Разработка под Docker. Локальное окружение. Часть 1
    0

    Ничего сложного. docker-compose.yml класть в то место, где ты его будешь запускать. Он ищет в той папке, где ты вызвал команду docker-compose up -d. Идентификатор lesson1 появился из названия папки в которой запускается проект. То есть автор запускал проект в папке lesson1.

  • «Мы всегда верили в конкуренцию и право выбора пользователя» © Яндекс
    0

    Не согласен. Тут вы тоже можете пойти и выбрать другой поисковик — гугл, яху, рамблер и другие. Поисковик правильно выводить, как аналогию магазина. Ибо это, если можно так назвать, маркетплейс ссылок.

  • «Мы всегда верили в конкуренцию и право выбора пользователя» © Яндекс
    0

    Он будет корректным, если к вашей фразе дополнить, что при этом люди, в основном смотрят только первые 3-5 шоколадок на первой полке, а переход в подсобку осиливают единицы из миллионов.


    Претензия не в том, что они не могут пиариться, а в том, что у них не те условия. Справедливо дать всем возможность использовать одинаковые инструменты, пусть и платно. То есть хочешь иметь такую привилегию — заплати Яндексу деньгу и получи свою возможность использовать этот функционал. Не хочешь платить — твое право, но Яндекс также не должен терять свой доход, ради которого он и занимает доминирующую позицию.

  • Разработка чат-бота (laravel+botman)
    +2

    В корне с вами не согласен. Здесь должен был быть аргумент о скорости работы, но никак не о скорости установки. Развертка нового laravel приложения занимает минут 5, из которых 4 — скачивание пакетов из сети.


    1) composer create-project laravel/laravel project_name
    2) правка .env для подключения к базе
    3) все.


    Остальные действия ты делаешь так или иначе, когда работаешь с чистым php.


    Правда я согласен с тем, что использование фреймворка для такой простой задачи — стрельба из пушки по воробьям.

  • Семь «абсолютных истин» джуниора, от которых пришлось отучиваться
    +2

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


    ИМХО.


    • Комментарии в коде часто недостаток, чем польза. Чаще всего они содержат //todo, либо //fixme, либо // это переменная. Если требуется комментарий, то надо подумать, а нельзя ли было написать лучше. Чаще всего, код документирует сам себя. Выбирай грамотные названия переменных. Комментарий ставится только тогда, когда без него никуда.
    • Даже если код вызывается редко это не отменяет необходимости сделать его оптимально.
    • Абстракции на уровне бизнес логики не менее важны, чем на уровне поддерживающего слоя.

    UPD: Комментарии нужны для того, чтобы описать почему здесь сделано именно так, а не иначе, а не для ответа на вопрос что здесь происходит.

  • Как объединить бэки двух ритейлеров на SAP за 12 часов
    0
    Здесь могу ответить только примерно так: вас привлекли, как профессионала для того, чтобы сделать свою работу. Также, как привлекают программистов, дизайнеров и так далее. Вы, как специалист в определенной области знаете ее гораздо лучше, чем все маркетологи и директора вместе взятые. Следовательно, и вопрос следует ставить так: либо вы доверяете и я делаю так, как считаю правильным с точки зрения знаний и опыта, а вы способствуете этому, либо мы делаем так, как сказали вы и получаем негатив от потребителей контента. При этом, естественно, за основу берется пожелание заказчика, то есть делать что-то абстрактное, естественно не нужно.
  • Как объединить бэки двух ритейлеров на SAP за 12 часов
    0
    А вот за этот ответ — уважение. Признать ошибку это уже многое. И все же, на мой взгляд, необходимо доносить до маркетологов информацию о том, что подобные материалы можно публиковать на неспециализированных платформах, вроде Яндекс.Дзена, но никак не на ресурсе, посвященном IT, где львиная доля посетителей — разработчики различного уровня, желающие более качественного раскрытия материала. В общем-то говоря, выдает небольшую некомпетентность специалистов, не учитывающих целевую аудиторию.

    P.S. Надеюсь, что второй материал из серии раскроет информацию подробнее.
  • Как объединить бэки двух ритейлеров на SAP за 12 часов
    +4

    Я выскажу свое, сугубо субъективное мнение. Проблема этого материала в том, что он состоит только из воды с вкраплением отдельно взятых и не особо связанных фактов. Вопрос в том, а что конкретно хотели таким материалом донести? То, что вы смогли слить две больших разрозненных системы в одну? Молодцы. Поработали, постарались. А поделиться архитектурой этих систем и рассказать в чем конкретно были сложности и какие были подводные камни?


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


    ИМХО. Статья несет два посыла: "придите к нам на конференцию, мы вас еще напоим водичкой" и "смотрите, какие мы крутые".


    P. S. Прошу прощения за агрессивный тон комментария. Не претендую на истину в последней инстанции — личное мнение.

  • Shit happens. Яндекс удалил часть виртуальных машин в своем облаке
    0
    Меня больше смущает, что на стоимости в 1000 долларов за железо + администрирование, эти 3-4 раза дороже выйдут как раз 3-4 тысячи долларов. У бизнеса часто возникают серьезные вопросы в духе «А за что мы переплачиваем 2-3 тысячи вечнозеленых»? Не за надежность ли и возможность экстренно вертикально/горизонтально и быстро нарастить мощности? Не за сохранность ли данных и администрирование железок?
    Такие минусы, как произошли у Яндекса заставляют задуматься о желании переехать туда. С их-то ценником, мне кажется, можно не допускать такое. Надеюсь, что они, реально, сделают выводы и такого не повторится.

    P.S. Если потерялись данные — проблема не Яндекса, а бизнеса (читай, админа), который не настроил бэкапы, тут я не оправдываю. Хотя, конечно, хостинг доверие потерял и часть данных гарантированно вылетели в трубу — за это тоже нужно давать хорошую плюшку.
    P.P.S. Если упал какой-то важный сервис по ошибке Яндекса, то, на мой взгляд, Яндекс должен возместить ущерб такого падения. И дать шоколадку сверху.
  • Готовимся к хакатону: как выжать из себя максимум за 48 часов
    0
    Поэтому хакатоны так любят студенты и безработные. Ну либо люди в отпуске, которым не особо есть чем заняться (а так тоже бывает). В основном, если есть желание участвовать, необходимо понимать, что это будет два бессонных (ну сон по 4 часа — максимум) дня непрерывного кодинга, причем вы не успеете все равно сделать идеальный продукт.
    Хотите участвовать — берите неделю отгула / отпуска — один день до, два дня на хакатон, четыре дня на выспаться. И будет счастье. Если работа на неделе — нет, не выйдет.

    Ах да. Важно. Не юзайте энергетики. Они блокируют на некоторое время нейромедиаторы, которые потом все равно дадут о себе знать. Шарахнет усталостью еще сильнее, чем раньше.
  • От 5 до 7 и ведерко кофе
    +6
    В тему. Есть шикарная (без шуток, очень хорошая) научная книга в тему сна от Мэтью Уолкера «Зачем мы спим». Подробная научная работа, покрывающая большУю часть исследований, существующих на сегодняшний день со ссылками на источники и further reading. Если хочется научной информации — туда. Несмотря на относительно легкий характер повествования, книга крайне нагружена информацией, в том числе, по нейрофизиологии — там есть, например, информация о работе нейромедиаторов и их влиянии на различные ощущения и желание спать.
  • С чего начать разработку архитектуры?
    +11
    На мой взгляд, статья в чистом виде вода. Из чего это можно понять: пол текста — клишированные обороты, вроде
    Фундаментальная концепция приводит к появлению первых идей и к созданию первых моделей обработки данных.

    Много красивого текста, но по факту никакой полезной информации.

    В случае, если автору хотелось рассказать про архитектуру, следовало бы просто прочитать литературу на это счет. Из признанного и успешно работающего: Мартин (Чистая архитектура и чистый код), Вигерс (разработка требований к программному обеспечению), Басс (архитектура программного обеспечения на практике), O'Reilly.

    Кроме того, можно было бы взять другие источники по разработке: прочитать про DDD и другие подходы к проектированию. Помимо этого, нужно знать о том, как проектируется MVP и чем прототип отличается от MVP.
  • PHP GR8: повысит ли JIT производительность PHP 8
    0
    Вот тут вы правы. PHP — интерпретируемый язык программирования, несмотря на opcache и ввод JIT в 8 ветке языка. Но если у PHP есть что-то вроде php -f index.php где он ругнется на неверный синтаксис и бросит (сразу) error, то для python мы это увидим когда непосредственно столкнемся, что может произойти далеко не сразу (знатоки питона, если это не правда — поправляйте). Однако, и правда, все это происходит в рантайме.

    Это дело решается тестами, но, поверьте, тесты не всегда хорошие и не всегда имеют 100% покрытия.
  • PHP GR8: повысит ли JIT производительность PHP 8
    +3
    Да, как бы странно это не было, я не считаю в данном случае Мартина правым в данной ситуации. Вернее, не согласен с тем, как этот материал повернут вами в контексте комментария, на который вы его отправили.

    Смотрите. Кирилл говорит о том, что реализация на языке Python приводит к проблемам, которые будут найдены непосредственно в рантайме, что недопустимо. Что можно избежать в PHP использовав принципы того же Мартина — ISP + DI с использованием встроенных средств языка, а не внимательности разработчика. Кроме того, он апелирует к тому, что мы перестаем хардкодить и начинаем работать с абстракциями.

    Суть комментария в том, что не важно, является ли ключевое слово вредным или нет: такое решение в языках есть и с ним мы живем. Если в Python реализовали множественное наследование через пень-колоду (к слову, сам автор в комментариях согласен с тем, что интерфейсы нужны), не дали нормального способа создавать абстрактные классы и методы, а в PHP это сделать реально, пусть и с использованием «вредного» interface (к слову, я не вижу дублирования кода в данном контексте, хотя если судить по Мартину оно здесь должно быть) — я выберу более безопасный, а как следствие, подходящий инструмент, который меня защитит от этого.

    Кроме того. Мартин аппелирует к Eiffel, который решил проблему множественного наследования. Каким образом он это сделал? Мы можем указать, какие методы родительского класса мы наследуем. То есть потенциально доступна ситуация, когда родительский класс имеет какой-то метод, а дочерний — не имеет. Для меня такая ситуация является недопустимой и именно для этого принципиально и нужны интерфейсы. Это контракт, который гарантирует мне работу и ошибки компиляции.

    P.S. Я не спорю с самой статьей и идеей. Если бы решилась проблема множественного наследования, принципиально у нас бы было всего два инструмента: класс и интерфейс, а абстрактный класс был бы не нужен, так как его функции перенял бы интерфейс. Ну или наоборот.
  • PHP GR8: повысит ли JIT производительность PHP 8
    +3
    Вы видимо не захотели прочитать книгу «Паттерны проектирования» от банды четырех.
    Там говорилось об одном важном пункте композиция вместо наследования.
    Рекомендую почитать аргументацию, она развенчивает все мифы, указанные по вашей ссылке и дает понимание, когда использовать то или другое.

    К тому же я хочу обратить ваше внимание на наличие частичного наследования в PHP, реализованного в виде трейтов.

    P.S. Строка выше относится к тому, что оригинальная статья опирается на синтаксис языка Java, которая не позволяет использовать множественное наследование. Кроме того, рекомендую прочитать википедию по поводу множественного наследования и убедиться, что оно далеко не так «красиво», как его изображают в вашем материале.
  • Vivaldi 2.4 — Двигаем кнопки двумя руками
    –1
    В этом случае, согласитесь, данная уязвимость была бы в браузерах mozilla firefox и chrome, а также других браузеров на основе chromium, вроде Яндекс.Браузера и подобных, так как они отображают корректный url не превращая строку в punnycode.

    Прошу вас, пообщайтесь с разработчиками. Данная проблема стоит, пусть и не очень остро, но url играет крайне важную роль, как для SEO, так и для специалистов по маркетингу. А вы заменяете его набором непонятных для пользователя символов.
  • Vivaldi 2.4 — Двигаем кнопки двумя руками
    –1
    Можете указать, конкретно какие требования безопасности будут нарушены, если перевести punnycode в нормальный понятный URL? Все браузеры это делают, оставляя punnycode только если присутствует комбинация символов из разных языков.

    Русскоязычные домены — довольно частое требование бизнеса. У меня на поддержке есть четыре таких сайта.
  • Пожалуйста, прекращайте говорить про шаблон Репозиторий с Eloquent
    +2
    Максимально точно выражено мое мнение, полностью поддерживаю. Но необходимо дополнить.

    Использование репозитория просто как абстракции над хранилищем зачастую не имеет смысла в продуктах до определенного размера. Тут проблема в том, что любое изменение бизнес-условий в продукте чуть выше размером, чем домашняя CRUD страничка, вызовет мучительные боли чуть пониже спины, потому что эти изменения коснутся каждого файла проекта, где подобные операции используются.
    К примеру, буквально вчера в большой лигаси-системе я зарелизил небольшой блок, который касался добавления нового типа сущности. Проблема в том, что этот тип сущности требовалось получить из внешнего источника, отличного от базы данных. Кроме того, его нужно было зарегистрировать во всех элементах сайта, где он может потенциально использоваться. Итого, мне пришлось изменить что-то в районе 80 файлов на стороне сервера, чтобы добавить тривиальную функцию. А это непаханое поле ошибок и потенциальных багов, которые необходимо еще отлавливать.

    Используй разработчик паттерн репозиторий, да и в целом, поддерживай он исходники в более качественном состоянии, подмена кода была бы не такой страшной и менять пришлось бы не более 10-15 файлов.

    То есть выбирая инструмент, а я пропагандирую отказ от AR в пользу более очевидного, но имеющего больший порог входа репозитория и сущности, как коллекции — объектного представления структуры данных, необходимо понимать и представлять не только то, что будет сейчас, но и загадывать на перспективу. Ибо, как сказал небезызвестный в узких кругах широких масс, некий М. Фраулер, чистая архитектура это такая архитектура, изменения в которую вносятся максимально просто.

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

    Резюмируя. Если вы хотите сделать быстро, проверить гипотезы, не планируете вносить большие изменения от слова совсем — используйте Eloquent as is — это крутейший инструмент, значительно ускоряющий процесс разработки продукта. Но если вы делаете проект для заказчика, в условиях изменяющихся бизнес-требований, с учетом необходимости длительной поддержки сервиса, не поленитесь, пишите репозитории: они окупятся. И дело даже не в смене базы данных, а в целом, в простоте поддержки продукта на разных этапах его существования.
  • Монорепозитории: пожалуйста не надо
    0

    Одна из задач разработчика — доказать, что такая революция нужна. Особенно, в случае, когда тут команда разработчиков.


    А вообще, не могу не согласиться, что чаще происходит именно так.


    P. S. Накладные расходы в начале примерно такие же. Особенно, если в команде есть джуны.

  • Монорепозитории: пожалуйста не надо
    0

    Немного персонального опыта.
    Работал и с монорепами в команде 8+ человек, работал и с полирепой в средней по размеру команде.


    Имхо. Накладные расходы увеличиваются серьезно в полирепе. У нас есть makefile, который умеет инициализировать репозитории, подбрасывать симлинки на реальные инстансы кода вместо сабмодулей и много чего еще для работы. Кроме того это требует наличия метарепозитория (инфраструктурной репы), который умеет собирать все и деплоить в прод по кнопке. Все это требует вдумчивой проработки и внимания на поддержку.


    Мое мнение сложилось примерно тем же, что и с микросервисами: это круто и хорошо, об этом надо задумываться, но только тогда, когда проект реально имеет несколько крупных команд поддержки/разработки и проблемы монорепы начинают мешать

  • За что я ненавижу Eloquent ORM
    +1

    Да. Я уже понял свою ошибку и критику воспринял. Посмотрите мои ответы под первым комментарием.
    Я обязательно напишу материал про то, как лично я считаю правильным организовывать и писать приложения на ларе.

  • За что я ненавижу Eloquent ORM
    0

    Пожалуй ты прав. И с названием, и с тем, что надо чуть более явно выразить пути решения. Буду чуть более внимательным в дальнейшем. Наверное, стоит сделать материал о том, "как правильно" с высоты своей колокольни.
    Спасибо за критику)

  • За что я ненавижу Eloquent ORM
    –2

    Повторюсь, об этом и пост — надо всегда помнить об этом паттерне и писать код так, чтобы минимизировать проблемы при рефакторинге. Я упоминал, что ar неплох для быстрой разработки.
    А насчет того, кто виноват — никто. Это не проблема, а подводный камень, который следует иметь в виду. И сразу учитывать при проектировании. Это одна из тех жертв, на которые надо идти осознанно.

  • За что я ненавижу Eloquent ORM
    0

    Да. Всего-то. Пара десятков часов?) А потом менеджер приходит и спрашивает, почему такие неоправданно высокие расходы по времени?


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

  • За что я ненавижу Eloquent ORM
    –2

    Никто не мешает. Об этом и пост.
    Проблема (ну или не проблема, а подводный камень) в том, что ларавель из коробки работает с Eloquent. И не заточен под доктрину, хотя никто не запрещает прикрутить ее.
    Фишка в том, что при этом придется забыть о генерации моделей (entity+repository) командой (естественно, с этой болезнью можно справиться). Придется подзабыть про нативную авторизацию из коробки (которая реально привязана к моделька юзера хотя и не намертво), да и про некоторые библиотеки.


    То есть запрещать то нам, разработчикам, никто не станет (собственно, многие так и делают, как ты сказал). Но лишние сложности привнесет.


    И еще одно. Этот пост имеет еще один подтекст. Когда приложение вырастает из стадии MVP, далеко не всегда (признаемся, почти никогда) бизнес идет на полное переписывание или хотя бы серьезный рефакторинг, который в этот момент требуется. Вот и получается. Нам, мышкам, приходится колоться, плакать, но все равно кушать кактус в виде AR.