в идеале ты как бы читаешь книгу а потом следишь просто за нововведениями в языке, так что нет смысла покупать "обновления"

А так нафиг 3 бамажные одинаковые книги

Ну я точно пдфку скачаю с торента. Были бы бумажные дополения покупал бы для коллекции. В шкафу места мало)

ты бы хоть читал что там копишь

Я в 2011 читал

а то по твоим вопросам создается впечатление что ты что-то где-то увидал и начинаешь сразу осыпать вопросами, даже не разобравшись что именно ты почитал

В вебстудиях когда работал там до жопы весь этот ооп. У них там работают по типу - быстро делай быстро. И многие начинают писать костылями и говнокодить когда главный критерий скорость. А в канторах по разработки как обстоят дела? Пишите костыли с глвнокодом или по феншую и с юниттестами?)

В вебстудиях когда работал там до жопы весь этот ооп. У них там работают по типу - быстро делай быстро. И многие начинают писать костылями и говнокодить когда главный критерий скорость. А в канторах по разработки как обстоят дела? Пишите костыли с глвнокодом или по феншую и с юниттестами?)

Хуяк хуяк и в продакшн

В вебстудиях когда работал там до жопы весь этот ооп. У них там работают по типу - быстро делай быстро. И многие начинают писать костылями и говнокодить когда главный критерий скорость. А в канторах по разработки как обстоят дела? Пишите костыли с глвнокодом или по феншую и с юниттестами?)

почему мы работаем медленно? потому что хотим быстрее

вот напишешь ты "говно" которое работает, сдаш проект и забудешь. А кто-то другой потом вносит правки (проекты же не умирают после сдачи, иначе какой в них смысл). И вот как дорого правки вносить уже дает представление о качестве кода.

и тут твое "до жопы ООП" и т.д. выходит сильно боком

при том что в "вэб студиях" за счет конвеерной сборки сайтов как раз таки все это даст нехилый профит. Но "зачем, нам бы что бы работало"

в целом же все это лишь говорит о некомпетентности кадров.

что логично с учетом того кто работает в этих самых вэб студиях

> Пишите костыли с глвнокодом или по феншую и с юниттестами?) все какают, но обычно не по середине комнаты

там и многозадачность пздц, работаешь над одним движком, тебе еще 100500 дополнительных сайтов, то подправить, это, модуль СРОЧНА нужен!!1 и все в этом духе. Видос видел "пробки об айти", там как раз про это говорят, что не всегда нормально есть возможность писать

там и многозадачность пздц, работаешь над одним движком, тебе еще 100500 дополнительных сайтов, то подправить, это, модуль СРОЧНА нужен!!1 и все в этом духе. Видос видел "пробки об айти", там как раз про это говорят, что не всегда нормально есть возможность писать

да все это произрастает из некомпетентности

некомпетентности разработчиков и менеджеров. Управляемый хаос

планирование для слабаков, теория ограничений придумана ограниченными

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

что тебе мешает планировать свою работу?

менеджер который в ухо орет?

ага, месяц как-то был спокойный, работали на расслабоне, серьезных задачь не было. А менеджер проектов в конце месяца говорит у нас проект горит, нужно было его сдать к концу месяца. Я в ахуе, чуть ли не матом на них. В общем весело

и сами херней маялись. Было такое в 2013, ушел от туда)

сами менеджеры*

ну это ссаные вебстудии, я туда больше не хочу, ну их в пень

небольшие аутсорс конторки не далеко ушли

там все через жопу и всем на все пох

многие совершенно не учатся на ошибках и не хотят брать хоть какую-либо ответственность. В том числе и разработчики

все хотят "работать на расслабоне"

все хотят "работать на расслабоне"

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

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

если ты не можешь обосновать свои решения с точки зрения "почему так дешевле" - значит так не дешевле.

ради прикола поработай в вебстудии)

чисто для фана, чтобы прочувствовать мои слова)

я тоже был когда-то джуном, и тоже мне казалось что делать нормально это долго и дорого и никому не нужно

+ помимо кода ты можешь просто не учитывать другие части пайплайна разработки которые страдают от твоей "повышенной скорости"

короч вместо того что бы ныть что "все надо делать быстрее" стоит задуматься можно ли делать быстро и качественно (да это дорого))0

я тоже был когда-то джуном, и тоже мне казалось что делать нормально это долго и дорого и никому не нужно

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

и джун в вебстудиях такого понятия нет, там треш угар и содомия

Что мешает найти работу, где нет такого подхода?

на тот момент когда работал, знания и отсутвие вакансий в регионе

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

когда я был джуном у меня было несколько другое представление о метриках качества)

ну не ко мне вопросы

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

если тебе говорят *как* делать, а не *что* делать, значит ты так и остался джуном

Не понимаю тогда, к чему всё это, если это было в твоём прошлом

Что ты сейчас пытаешься до всех донести?

прошло 4 года с момента этой офигительной истории

но все еще есть вопросы в духе "а вы реально по феншую и с юнит тестами?"

есть ли какая-то разница в твоей работе "тогда" и "сейчас"?)

В вебстудиях когда работал там до жопы весь этот ооп. У них там работают по типу - быстро делай быстро. И многие начинают писать костылями и говнокодить когда главный критерий скорость. А в канторах по разработки как обстоят дела? Пишите костыли с глвнокодом или по феншую и с юниттестами?)

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

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

2 крайности

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

а ты?)

не так и не так

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

третьего не дано чтоли?

Очевидно, что загоны про качестао нужны проектам, которые существуют больше недели

Хз че тут обсуждать

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

"правильно" не обязательно долго (иногда наоборот) и сильно зависит от контекста.

Абсолютно нормально делать на вордпрессе сайты-визитки

Очевидно, что загоны про качестао нужны проектам, которые существуют больше недели

Могу рассказать о проекте, который существует около десяти лет, компании, которая существует дольше пишущих здесь и код там до сих пор пишут с упором на скорость. Не показатель.

Могу рассказать о проекте, который существует около десяти лет, компании, которая существует дольше пишущих здесь и код там до сих пор пишут с упором на скорость. Не показатель.

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

Мы тоже пишем с упором на скорость

Качество кода как метрика актуальна в ИТ-компаниях, которые наяривают на фичи продукта. Остальному бизнесу немного(много) все равно.

понятие "скорость" вообще относительно

Именно поэтому щагоняемся тестами, паттернами, архитектурой

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

Реально пишут код каждый день.

Так быстрее)

Могу рассказать о проекте, который существует около десяти лет, компании, которая существует дольше пишущих здесь и код там до сих пор пишут с упором на скорость. Не показатель.

давай по другому переформулируем понятие "упор на скорость". Может быть "упор на эффективность и стоимость решений"?)

просто это типа... логичнее... решить проблему с наименьшими затратами

при отправке в методе указываеш parse_mode html или markdown

Как ботом телеграмма писать текст с форматированием, ну там болдом часть, курсивом?

другой вопрос что разработчики редко умеют в cost-benefit analysis.

ну и еще есть "генераторы фич"

у меня был товаристч который пилил класстеризацию меток на карте 1.5 месяца, на php... что по итогу за 3 дня переписали на эластику и работало это стабильнее и быстрее

Ребят подскажите вот что. Симфони 3, контроллер, есть action который рисует таблицу некоторых entity. По проекту есть еще несколько мест, где показывается эта же таблица, но с заранее устанолвенными фильтрами. Таблица рисуется с помощью twig render и передачей параметров фильтрации. Таких таблиц должно быть много. Не хочется под каждую entity писать обработку условий фильтрации. Как быть? Унаследоваться от одного репоза ? в котором реализовать фильтры? Или как лучше сделать? Какой тут BEST PRACTICES?

или вот еще типичные задачки которые у многих съедают драгоценные человеко-дни. Пилить очередной логин вместо того что бы заюзать какой-то готовый сервис. Или же пилить хитрую хрень на очередях для ресайза картинок вместо того что бы взять что-то типа imaginary, настроить по быстрому скейлинг по нагрузкам и жахнуть сверху cdn (пол дня работы на самом деле и не зависит от количества разных вариантов картинок).

Ребят подскажите вот что. Симфони 3, контроллер, есть action который рисует таблицу некоторых entity. По проекту есть еще несколько мест, где показывается эта же таблица, но с заранее устанолвенными фильтрами. Таблица рисуется с помощью twig render и передачей параметров фильтрации. Таких таблиц должно быть много. Не хочется под каждую entity писать обработку условий фильтрации. Как быть? Унаследоваться от одного репоза ? в котором реализовать фильтры? Или как лучше сделать? Какой тут BEST PRACTICES?

Набор фильтров разный для каждой таблицы?

конечно с такими подходами добавь ты еще тесты (которые пишутся по тем же принципам сложна значит хорошо). выйдет плохо. Хотя "вроде как и правильно"

Ребят подскажите вот что. Симфони 3, контроллер, есть action который рисует таблицу некоторых entity. По проекту есть еще несколько мест, где показывается эта же таблица, но с заранее устанолвенными фильтрами. Таблица рисуется с помощью twig render и передачей параметров фильтрации. Таких таблиц должно быть много. Не хочется под каждую entity писать обработку условий фильтрации. Как быть? Унаследоваться от одного репоза ? в котором реализовать фильтры? Или как лучше сделать? Какой тут BEST PRACTICES?

спецификации.

тогда у тебя можно будет выстраивать запросы как композицию

Опередил)

и ты общие вещи сможешь вынести

Набор фильтров разный для каждой таблицы?

ну конечно разные. В таблицах разные сущности.

и комбинировать как душа пожалает

гуглить "спецификации"?

гуглить "спецификации"?

https://github.com/Happyr/Doctrine-Specification - мы вот это юзали

может кто еще чего подскажет