Пользователь пока ничего не рассказал о себе

Наибольший вклад в теги

Все теги (21)

Лучшие ответы пользователя

Все ответы (20)
  • Как вы планируете свой рабочий день, чтобы не выгорать?

    @bioroot
    Поддержу большую часть выше сказанного. Во-первых, работать с адекватным качеством можно не больше 6 часов в день. Я стараюсь брать по 4-5 часов (хотя это не отменяет того факта, что при какой-нибудь аварии на сервере нужно собраться и устранить проблему не глядя на часы, но такие ситуации крайне редки). Во-вторых, как только вы набьёте руку и будете интересовать клиентов больше чем они вас, уходите на фриланс. Ну или как минимум гибкий график жизненно необходим. В-третьих, подумайте, сколько денег вам нужно и чем для вас вообще является работа - способом заработка или призванием. Если первое, то работайте меньше. Лично я понял что для меня это именно способ заработка. Хотя в целом работа мне нравиться, но я не из тех кто готов по 12 часов писать код для работодателя, а остальные 12 часов - для pet-проектов. IT-субкультура навязывает что это не круто, но если вы сможете справиться со стереотипами, то станете продуктивнее и счастливее. Денег скорее всего станет меньше, но это на самом деле не так критично влияет на жизнь. Хотя сначала кажется что будет ужас, но у страха глаза велики.

    В сухом остатке, оценивайте работу в первую очередь по комфортности для вас, а не по доходу, известности компании и прочим побочным факторам. Если вы не создадите себе комфортных условий, то с гарантией выгорите, не смотря на психологов, доход, лекарства и репутацию как специалиста. Я, например, в качестве одного из главных критериев беру адекватность клиентов и доверительные отношения с ними. В результате мне не нужно писать гигантские отчёты по каждому потраченному часу, высылать пачки скриншотов с открытой IDE и выбивать заработанные деньги. Я просто говорю сколько они мне должны, они просто платят. Можно было бы нахватать больше клиентов и по большей ставке, но зачем? Всех денег не заработаешь, а удовлетворённость жизнью в текущем режиме выросла гораздо больше, чем просел бюджет.
    Ответ написан
  • Есть ли реальные преимущества у Pyramid / Flask перед Django в крупном проекте?

    @bioroot
    Pyramid - очень на любителя. Как раз сейчас занимаюсь проектом, где он взят в качестве основы. Скажу так, когда они писали что Pyramid позволяет легко делать простые вещи, оставляя возможность делать сложные (вспоминается, что примерно то же самое говорили про Perl), то они не врали. Легкие вещи действительно легко делать. Но чтобы сделать что-то мало-мальски сложное нужно залезть во фреймворк с головой. На мой взгляд много неочевидностей во всём. И к uwsgi он без бубна не прицепился, и без virtualenv не работает, и логирование при инициализации проекта для wsgi цепляется отдельной командой (при том что и сам проект и его работа с логами ожидаемо описаны в одном файле настроек), и т.д. и т.п. В общем пока развернул его вся симпатия к Pyramid улетучилась.

    До этого работал с Django. И да, я скорее всего не умею готовить Pyramid. Но когда я берусь изучать новую технологию, то первое время тщательно присматриваюсь, насколько без сопротивления она позволяет делать дело. Pyramid сопротивляется неоправданно много.
    Ответ написан
  • MVC, как лучше избежать дублирование кода?

    @bioroot
    Первым делом определитесь чего вы хотите на самом деле. Не понятно почему отсутствие проверки родителя — непрофессиональность. Если она не нужна, то непрофессиональность как раз её написание ради какой-то абстрактной идеи. Например, для региона может быть нужно сделать отдельную страницу при наличии страны и отсутствии его самого («для указанной страны не существует такого региона»). Если все ошибки ведут на одинаковую надпись «страница не найдена», то дополнительные проверки ни к чему.

    Далее надо определиться с реализацией. Но тут уже вам должно быть виднее какая у вас архитектура. По сути всё предложенное выше сводится к классическому паттерну Strategy: весь общий функционал оставляем в родительском классе, а все частности (ключевой момент — их должно быть мало) переносим в наследников. В вашем случае предком будет CRUDController с реализацией метеодов завязанной на modelClass, а потомками классы определяющие этот modelClass и метод checkRequest. Дёрганье checkRequest прописывайте где вам нравится. Не знаю как устроен Yii, но если он позволяет создавать контроллеры произвольных классов не наследуясь ни от кого, то имеет смысл вообще объявить CRUDController абстрактным и в нём же прописать абстрактный метод checkRequest. Тогда это будет вообще Strategy из книжки, а вы получите возможность использовать checkRequest в других методах CRUDController не опасаясь того что в наследниках он не определён. И ещё обычно в современных фреймворках есть метод, который дёргается перед любым экшеном контроллера. Возможно, там вашему checkRequest самое место.

    Продолжая фантазировать на тему, можно сделать тип модели modelClass передаваемым в параметре. Или получать его исходя из того что вам передали. Только надо сделать карту допустимых значений. Что-нибудь типа
    array(
    	...
    	'region' => array( 'model' => 'regionModel', 'parent' => 'countryModel' ),
    	'country' => array( 'model' => 'countryModel', 'parent' => null )
    )
    

    и из этой карты получать модель и родителя проходя по ключам массива и проверяя на существование параметра с таким ключом. Как только нашли — проверяем существование родителя и работаем по общим методам с уже определённым значением modelClass.

    Почему все советуют делать Strategy. Потому что эта штука зарекомендовала себя в боях. Классический ООП подход часто приносит больше трудностей при разработке (надо быть аккуратнее и чаще всего писать больший объём кода), но даёт заметный выигрыш при необходимости изменить какую-то часть проекта. К примеру, «нафантазированный» способ реализуется быстрее (надо добавить пару методов и карту соответствия, против базового класса + 5 классов дочерних для сущностей). Но при этом если понадобиться добавить какой-то новый экшн (например, добавление комментария к ревью), то в случае со стратегией вы просто впишите его в нужный класс. А для более простого метода придётся ломать себе голову с изобретением исключения в логике. Пару раз так можно сделать, но… после 12 костылей код превратится в тыкву.

    Но, в конечном итоге, решать всё-равно вам. Может быть и второй быстрый способ подойдёт, потому что «там стопудова ничего не будет меняться» (не верьте тем кто так говорит — обязательно будет). Может вы их скрестите и внесёте в базовый класс стандартную реализацию checkRequest, а в дочерних классах будете определять только modelClass и parentModelClass. Всё зависит от конкретных потребностей и архитектуры проекта.
    Ответ написан
  • Перспективы

    @bioroot
    По моему пару вещей выше забыли.

    1. Мобильные приложения захватывают рынок. Я бы при таком раскладе сильно налегал на программирование под них.
    2. Не скажу на 100%, но судя по тому что я видел победы в локальных IT конкурсах не сильно впечатляют работодателей. Не то чтобы в них не стоит участвовать, но лучше подумать о том, как начать делать себе имя другими способами. Публикации статей на профильных ресурсах, участие в open source проектах, наличие своего проекта (пусть даже это какой-нибудь узкоспециализированный плагин для jQuery) весят гораздо больше. Если будет показать работодателю, то есть шанс начать карьеру не с нуля. Ну или в крупной компании. Но участвовать в олимпиадах с мировой известностью тоже очень правильно и хорошо.
    Ответ написан
  • Регулярные выражения, максимальная длина строки

    @bioroot
    А есть какая-то веская причина не проверять условие вне регулярного выражения? Я с ходу не могу придумать адекватного способа это сделать без look-behind'ов. Собственно и с ними страшновато.

    Может лучше опишите задачу целиком? По опыту когда ко мне кто-то обращается с вопросом «как построить регулярку» в 90% случаев исходная постановка задачи помогает найти более адекватное решение, хотя часто и через другую регулярку.
    Ответ написан