Pull to refresh
3
0
Семен Левин @remal

User

Send message
> Я утрировал, говоря об Erlang. Почему бы не разрабатывать на Java?
К сожалению, жависты крайне плохо дружат с вебом, а, особенно, с клиентской стороной. Был как раз выбор между Java и PHP. По разным причинам выбрали PHP, хотя, возможно, мы и пожалеем об этом выборе.

> Symfony2 тоже требует некоторого обучения, однако, вас это не остановило.
Тем не менее, чтобы писать что-то, не уходящее особо за рамки tutorial'ала, много времени на обучение на надо. Когда полезли глубже, стало понятно что попали.

> Избыточная оптимизация алгоритмов — это экономия на спичках, в случае интерпретируемых языков c динамической типизацией. Я склоняюсь к тому, что код должен быть, в первую очередь, читаемым и легко поддерживаемым. Вы можете спокойно спать, зная, что элемент массива, содержащий целое число, в php занимает 144 байта? Я вот могу.
Под фразой «выбор адекватных алгоритмов еще на этапе написания» понимались только совсем очевидные случаи, типа индексы в базе расставить. Это если утрированно. В целом же, придерживаюсь такого же подхода.

> И при этом не говорю, что php плохой язык.
У меня о PHP по сравнению с той же Java резко негативное мнение, но чтобы не разводить срач, ограничусь просто этой фразой.

> Почему вы решили, что sf2 — фреймворк для этого простейшего уровня?
Исходя из документации и статей типа этой, когда все преподносится таким простым. Кроме того, был некий опыт уже с Symfony и относительно удачный. Но, да, это решение было ошибочным.

> Вы предлагаете писать индивидуальный каркас для каждого приложения, чтобы избежать использования фреймворков? Я понимаю, бывают ситуации, когда такой подход оправдан. Но разве это повод не использовать фреймворки в остальных случаях?
Я предлагаю прежде всего думать головой. И банально не надеется что Symfony или иной другой фреймворк решит все проблемы. Если очень упростить, то предлагаю 10 раз подумать о выборе конкретного фреймворка, если разрабатываемый функционал выходит за рамки его tutorial'а.

> Вы искали иголку в стоге сена, вместо того, чтобы явно указать необходимые навыки. Я лишь это хотел сказать. Ситуация на рынке — это тоже не вина фреймворка.
Тут, возможно, вы правы.
> Писать на Erlang. Разве кто-то утверждает, что sf2 создан для хайлоада?
Отлично, а Erlang так много народу знает? Или заказчик возьмет и радостно оплатит обучение команды, по вашему? Я-то только за, только вот одного моего желания мало. Бывают чисто объективные причины в виде бюджета и сроков или недостатка сотрудников, а бывают и политические.

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

> Проблема в том, что вы выбрали инструмент, который вам не подходит. Как вообще выбор пал на sf2, если у вас в штате мало php-разработчиков, знакомых с ним?
Инструмент на *этот* проект, согласен, выбрали неверно. Это моя ошибка. Но проблема не в кол-ве сотрудников, а в том, что конкретно этот фреймворк слишком сложен. Вопрос в том, обосновано ли он такой сложный. Имхо, нет.

> Зачем тут sf2? Для шаблонных проектов существуют CMS и специально обученные люди.
А что делать с проектами, для которых CMS не подходит, а фреймворк хочется, чтобы самим кучу кода не писать? 90% сайтов — это простейший уровень в плане программирования. Так почему тогда фреймворк для этого простейшего уровня должен быть таким монструозным?

> Не хватает. Не каждый коллектив разработчиков являет собой лигу выдающихся джентльменов.
Так нужен хотя бы один или пара действительно сильных на проект, чтобы написать ядро, а рутинную работу можно и более младшим сотрудникам поручить. В чем проблема-то? Совершенно классический расклад.

> Да и новых сотрудников искать проще, указывая в требованиях к кандидату опыт работы с конкретным фреймворком.
Новых сотрудников искать проще? Да еще и конкретный фреймворк указывая? Да ладно? Вы в курсе о ситуации на рынке труда сейчас? Мы два месяца искали одного PHP'шника! И это без указания конкретного фреймворка!

На всякий случай, о конторе. Когда я год назад менял работу, то предложений было очень много и я имел возможность сам выбирать работодателя. Так так контора у нас вполне нормальная. Былая адекватная зарплата, которая всегда выплачивается срок, разные плюшки типа ДМС. Возможность самим выбирать технологии на проект и даже менять язык разработки. Сказать что контора слабая и не способна привлечь хотя бы средних спецов явно нельзя. А вот, тем не менее, два месяца поисков.

Впрочем, похожая ситуация сейчас и в других фирмах — интересовался.

> Ваш комментарий чуть менее, чем полностью, состоит из демагогии, с помощью которой можно раскритиковать всё что угодно.
Вы можете воспринимать мой комментарий как угодно. Я просто описал мой опыт и взгляд на текущую ситуацию с Symfony.

 

Возможно, я не прав, но у меня сложилось впечатление, что вы меряете людей по себе. Меня от этого, к счастью отучили, хотя и непросто это было.
Отлично, что делать когда вам никто не дает денег на парк серверов, а нагрузки предвидятся нехилые такие? Можете сами замерить сколько Symfony жрет памяти на один запрос. И сколько минимум времени надо на выполнения кода простенького контроллера без запросов в базу.

Вот не получается у меня что-то с формами. Я лезу в доку, проверяю, что все норм, а все равно не работает. Лезу в гугл, экспериментирую с кодом, но все равно не работает. Открываю дебагер, а там просто нереальное кол-во абстракций.

У контроллеров есть метод getUser(). Отлично, а где этот юзер присваивается? А как изменить этот? А будет ли это очевидно?

По поводу «легко что-то отключить». Попробуйте отключить security, а потом создать свой SecurityBundle. Вас ждет неприятный сюрприз, т.к. Symfony будет думать что в системе есть *стандартный* extension «security». Ок, лезем в наш класс SecurityBundle\DependencyInjection\SecurityExtension, переопределяем метод getAlias(). Теперь начинает падать класс SecurityBundle\SecurityBundle, т.к. там идет проверка alias'а (нафига???).

Зачем-то поля формы можно задавать классом. Ок, а почему через аннотации можно указывать параметры валидации, а вот какие именно виджеты для каждого поля выводить — нет? Есть 3rd-party bundle, видел, да. Только вот меня он не устроил.

Почему html5 validation, в частности атрибут pattern не подставляется автоматом, когда указываешь в списке валидаторов Regex? Да, код в Symfony для этого есть, только вот не работает.

Почему когда я делаю бандл с namespace'ом аля Organisation\Department\SomeBundle, то resource locator'ы перестают искать шаблоны по строке что-то типа «SomeBundle:controller:view», когда делаешь все в точности по официальной доке? Привет часик с дебагером.

Как уже мною упоминалось выше, программирование валидации настроек бандлов — это вообще треш.

И таких мелких и не очень минусов там огромное кол-во. Проблема в том, что мы не штампуем по 5 сайтов за месяц. У нас проекты меньше полугода не длятся. И несмотря на то, что штат сотрудников огромный, PHPшников мало (я и сам одновременно на java пишу). А знакомых с Symfony вообще почти нет. И что делать, когда на проект с Symfony приходит менее компетентный коллега, который далеко не факт, что сможет продраться с дебагером под мышкой через эту кучу кода? Что, он меня дергать будет non-stop?

Что вам такого дает Symfony на крупных проектах, чтобы его так защищать? Модульность? Простоту тестирования? Так ничто не мешает написать слабосвязанный код и без Symfony. ServiceConainer'ер хочется? Так не вопрос, за адекватное время спокойно пишется свой, пусть и куда менее функциональный, но так этого и не надо. Вполне можно обойтись суперглобальными массивами, а не плодить обертки типа Request. И читабельность кода не пострадает. И т.д. «Идеальная архитектура», «100% покрытие тестами», «быстрое и легкое внесение изменений» — это лишь мифы. Да, к этим целям надо стремиться, но никогда не стоит забывать что серебряной пули не существует и всегда лучше сдать проект в срок, чем пытаться сделать супер-пупер код.

Стоит добавить, что подобные рассуждения применимы не везде и не всегда. У вас относительно краткосрочные или шаблонные проекты? Куча PHPшников в фирме, которые *уже* Symfony знают? Не хватает квалификации чтобы без фреймворка написать слабосвязанный код? Тогда, да, юзаем Symfony и не паримся.

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

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

ЗЫ: Да, я знаю о синдроме «not invented here». Не во всех случаях, к сожалению, его упоминание будет к месту.
Совет номер ноль: использовать Symfony только в тех проектах, что вписываются в Symfony'вский «стандарт» по функционалу.

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

В одном нашем проекте была чуть более «нестандартная» система авторизации, чем предполагает Symfony Security. После пары дней research'а от Security осталось очень мало, а остальной огромный кусок кода заменился одним, нами написанным, лаконичным сервисом.

В нынешнем проекте система безопасности еще более хитрая и в стандартную Symfony'вскую вообще не вписывается. Ну или вписывается кране слабо. В итоге вся Symfony Security была отключена вообще под ноль. Но проблем доставила другая часть фреймворка — формы.

Резюмируя, напишу так. Если вы понимаете как работает Symfony, как работают его части и почему там именно так все написано, а также плюсы и минусы этих решений, то, если у вас проекты не шаблонные, Symfony можно выкинуть. Причем во многих случаях даже нужно выкинуть. Ибо проще поддерживать, условно, 50 классов + ORM, чем воевать с огромным фреймворком.
Так, мысли в слух:

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

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

А потом начинается… «Я не буду верстать, т.к. это не моя работа и даже поправить две строчки в CSS буду верстальщика звать». «Я не буду писать доку, т.к. есть технические писатели, не трогайте меня». Потом: «Я не буду общаться с заказчиком, есть ПМ, и пофиг что ПМу нужен программист в разговоре, т.к. он более компетентен в соответствующих вопросах».

Никто никому ничего не обязан. И не обязан создавать комфортные условия на интервью. Возможно, просто HR глупый. А, возможно, даже, что фирма часто работает в режиме дедлайна и им нужен стрессоустойчивый человек.

Поэтому нытье аля «интервьюеры дураки» лично меня удивляет. Не понравилось? Выбери другую фирму, зачем сопли распускать?! Что, компетенции не хватает, чтобы самому работодателей фильтровать? Так займись самообразованием, а не поиском виноватых! Каким бы замкнутым интровертом не был бы человек, никто за него его жизнь не проживет.

На всякий случай: я работаю программистом и работу менять доводилось. И сам я намного ближе к интровертам.

 

Конкретно по вашему топику.

Тестовые задания. Если захочу в конкретно в какую-то фирму, то решу. В большинстве же случаев идет поиск среди N фирм, и до той, что предложила задание, далеко не факт что дойдет.

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

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

С остальным ±согласен…
Так я нигде и не писал, что разработчик должен принимать такие решения в одиночку. Не должен, разумеется. Но там, где «стандартный» разработчик потратит неделю, допустим, на реализацию change request'а, я потрачу денек потому что задумался каковы реальные цели заказчика и предложил измененную версию его запроса, которая будет удовлетворять его цели и, одновременно, будет стоить нам куда как меньше времени. Цифры, конечно, взяты с потолка.
А тех, кто понимает что проще здесь и сейчас вот в этом месте написать говнокод лишь бы работало, т.к. того требует бизнес, не существует, по вашему?

Мне, почему-то, всегда казалось, что просто кодить, пусть и качественно, не поднимая головы и не интересуясь о чем думают коллеги, ПМ, QA и даже заказчик, — это крайне безответственно.
Все то, что сейчас приходит в PHP, было в той же Java уже много лет назад. Тот же фреймворк Symfony 2 — вообще попытка писать на Java с синтаксисом PHP. При этом ладно бы все эти современные практики, паттерны и т.п. не просто копировались бы, а эволюционировали, так ведь пишешь и мысли «а вот это на Java спроектировано лучше» возникают постоянно.

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

Многие говорят, да и я раньше говорил, что PHP разработчиков проще найти и они дешевле. Ага, если бы! Чтобы найти одного адекватного PHP'шника, надо такое кол-во резюме отсмотреть и людей отсобеседовать, что порой просто вешаться хочется. Возможно, мое «адекватный разработчик» — это на самом деле уровень, как минимум, senior'а, но, блин, после опыта на той же Java с ее возможностям и требованиям к знаниям и опыту (привет многопоточность, к примеру), PHP кажется каким-то детским садом.

Кстати, при всем при этом и у Java минусов хватает. Это даже с учетом того, что идеальных решений не может быть в принципе.

Не, не спорю, относительно простенький сайт почему бы не написать и на PHP (тот же интернет-магазин с кучей плюшек — это тоже простенький сайт, ничего кроме совершенно банальной логики и UI там нет (утрирую, конечно)). Особенно если опыта на PHP больше у конкретного человека или команды. Но ведь одним этим даже и веб-программирование не ограничивается.

ЗЫ: С .net'ом не работал, так что тут прокомментировать не могу.
Можно ли сделать так, чтобы кнопка подписки у расширения для Хрома появлялась только на нужных страницах? Например, расширения RSS подписки показывают кнопку только если находят на странице RSS ленту и делают это в адресной строке.
Неуверенность неуверенности рознь. Если человек предлагает гениальные решения, но не может их отстоять, то какой от него будет смысл? Минимальный уровень психологической устойчивости, уверенности в себе и умения общаться нужен всегда.
А что XML declaration и doctype делает внутри body??
Планируется ли gzip включить, если статика браузером запрашивается? Цена-ценой, но без gzip'a клиент тупо вынужден больше и дольше грузить.
Понравилось бы или нет — не важно. Его задача была — создать успешный продукт. Он с ней справился. Все. Задача рядовых разработчиков, в принципе, аналогична, только на другом уровне. Если что-то не нравится — меняй работу.

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

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

ЗЫ: На всякий случай: сам я работаю разработчиком.
ЗЗЫ: И фанатом ни Apple, ни Джобса не являюсь.
А что мешает не строить предположения, а скачать JDK и посмотреть что в том же HashMap случай с null отдельно обрабатывается?
… а та одна — это «Единый реестр сайтов ...»
Вот нет чтобы залезть в исходники, увидеть что там сплошные аппаратно-зависимые типы и сделать соответствующий вывод…
Думается мне, что всяко дешевле чем $1 млн в год
gricom уже писал подобное вступление: habrahabr.ru/users/gricom/topics/
Было бы неплохо увидеть продолжение тех постов, например, в виде сравнения готовых решений.
Сорри что не сразу ответил.

Во-первых, для дизайнеров, как и для 99% профессий есть соответствующее образование. Тот факт, что мало кто этим заморачивается, не отменяет ни наличие теории, ни требования включать голову.

Во-вторых, в комментариях очень верно привели сравнение с архитектором. Обосновывать «почему не 300, а 311 пикселей» надо не столько с точки зрения картинки, сколько с точки зрения людей, которые будут потом работать с вашим дизайном. Любой выебон дизайнера автоматом увеличивает стоимость проекта, а также съедает нервные клетки тех же верстальщиков.

Поинтересуйтесь как-нибудь как работают дизайнеры помещений, к примеру. Я как раз сейчас занимаюсь ремонтом в квартире и с одним таким работаю.

Задача дизайнера — сделать и *практично*, и красиво. Просто красиво — вон из профессии.
Дизайн сайта — не рисование красивой картинки. Ответ «художник так видит» автоматом говорит о профнепригодности дизайнера, в качестве веб-дизайнера.

Впрочем, подобный ответ для любого человека и для любой профессии, имхо, говорит о том, что мозг во время работы не включался.

Information

Rating
Does not participate
Location
San Jose, California, США
Date of birth
Registered
Activity