Выбор языка/фреймоврка под текущий проект и с прицелом на будущее?
Здравствуйте!
Давно хочу попробовать себя в роли полноценного бэкэнд разработчика, до этого писал несколько внутрифирменных сайтов на чистом php (лет 5 назад), пилил сайтики на drupal и пару интернет магазинов и opencart с небольшими доработками движков.
Сейчас на работе, весьма кстати, возникла потребность написать очередной локальный сайт - фактически вебинтерфейс для уже существующей базы sqlite, со стандартными функциями добавления/удаления/редактирования записей, системой поиска и фильтрации, разграничения доступа по пользователям + возможность слияния с другой подобной базой sqlite, но это в перспективе.
Имхо хорошая возможность подтянуть навыки на реальном проекте. Писать на голом языке без фреймворков оказалось познавательно, но очень неэффективно по времени. Поэтому сейчас подбираю фреймоворк.
Успел поверхностно ознакомиться с django и laravel, и понял, что с ними все на порядки быстрее и надежнее, с моими велосипедами рядом не лежало :) Но что выбрать из них не знаю, т.к. реального опыта нет, а фреймворков куча и под тот и под другой языки.
В дальнейшем хотелось бы заниматься данным направлением в формате фриланса, т.к. живу хоть и в городе-миллионнике , но с весьма неразвитым рынком IT-услуг, и найти работу программиста в вебе тут можно только с PHP, соответственно стандартный "уездный" оклад в комплекте.
Знания python и php сейчас на примерно одинаковом уровне, можно сказать начальном, т.к. питон не так давно начал осваивать (начитавшись тостера в том числе :)), а php за несколько лет успел подзабыть.
До этого писал на с++, java, знаю ООП, имею представление о модели MVC, так что думаю смогу выйти на приемлемый уровень довольно быстро.
Если коротко:
знаю на начальном уровне python и php, хочу выбрать фреймоворк, с которым комфортно работать на фрилансе. Опыт программирования кое-какой есть. Планирую обкатать фреймворк на небольшом реальном проекте. Какой фреймворк выбрать с прицелом на фриланс?
Один язык/фреймворк вам всё-равно не получится использовать. Но, между PHP и чем-угодно, я бы выбрал что угодно. Попробуйте джангу или рельсы. В джанге, напирмер, sqlite, права доступа, пользователи, миграции и много ещё чего идут из коробки.
python няшный но не java-подобный, ruby похож на перл (ну и да, Django c SQLAlchemy в принципе съедобен, а вот RoR я не перевариваю). PHP исправляется (у него было очень темное прошлое наполеннное наркотиками). Так что не стоит так уж категорично говорить что что угодно лучше PHP.
Если честно, я ничего против PHP не имею, пока писал на нем отторжения не было. Вот что реально вызвало отторжение, так это программирование для 1с, вообще дичь какая-то :)
German Jet: сколько вам нужно вакансий? Я вам скажу одна. И тут уже существующая разница роли не играет. Разработчиков тоже разное количество. Конкурс одинаковый
А насчет количества вакансий, я тут недавно провел мини-исследование на upwork, вначале взял просто число вакансий и число фрилансеров и тупо поделил для оценки соотношения.
Вышло, что конкуренция в PHP, Python и Ruby на тот момент (4.07.15) примерно одинаковая - на один заказ приходится ~37 исполнителей.
А потом, полазив по upwork'у, заметил что там есть фильтры, которые дают доп. информацию, в частности по количеству отработанных часов, градация там такая: 1) отработал хотя бы 1 час, 2) отработал больше 100 часов, 3) Отработал более 1000 часов. Там же имеется общее количество фрилансеров которые указали у себя тот или иной язык. Итак, сложив все 3 вышеперечисленные категории мы получим людей, которые реально хоть что-то сделали на бирже. Поделив это на число заказов получим уже более интересную картину:
PHP ~16 исполнителей на заказ
Python ~14.5 исполнителей на заказ (ну да, полтора рудокопа, но для оценки соотношения так лучше имхо :))
Ruby ~20.5 исполнителей на заказ
Исследование ни на что не претендует, не имеет накопленной статистики и отражает положение на конкретный момент времени.
Def123: Ну согласитесь что не очень большая разница быль лучшем из 20 или лучшим из 16, если бы на ror было бы 500 человек на место, это было бы уже страшно. Тем более, выборка не учитывает сколько из этих проектов хороши(интересны, хорошо оплачиваются) и сколько разработчиков готовы вести эти сложные/ихорошие проекты. Да и upWork не единственное место в мире где можно работать.
Помимо MVC есть столько прекрасных абривиатур... ADR, DDD, CQRS... И тут laravel выигрывает, так как можно выкинуть эту поделку под названием элеквент и заменить его православной доктриной, а с нормальным ORM и нормальным IoC (а в ларавеле он норм) можно уже жить.
Если выбирать для WEB и под фриланс (и на перспективу) - то PHP и Symfony2 ну или Laravel + Doctrine.
Mikhail Osher: тем что это active record и да это доволи таки холиварная тема. Для большинства задач современных AR подходит норм, но хоть что-то сложнее и уже приходится городить прослойки отделяющие AR от бизнес сущностей.
Сергей Протько ой ой ой... Я бы не стал называть IoC, сотворенный янки нормой. Тот еще кусок амна. Особенно, по сравнению с IoC французика. Да и все остальное у янки тоже кусок амна.
За пол года работы с блюравелем прилось почти все переписать. Не переписали пока только то, до чего руки не дошли.
Сергей Протько просто я бы не стал называть View::render() или Log::debug() такими громкими словами, как DI. Базовый функционал шалавеля настолько скуден, что через месяц быстрой разработки понимаешь, что надо все к чертям переписывать. Например, использовать несколько каналов монолога невозможно. Сделав свой провайдер для логгера понимашь, что от него зависит мейлер, который тоже перепысываешь, различные способы сериализации сущностей с помощью toArray() сделать невозможно, то и дело натыкаешься на циклические ссылки, которые и с помощью визитора не разрешить, ибо нет IdentityMap.
И быстрая разработка оборачивается пословицей: "скупой платит дважды". Мне не дано понять, что люди находят в нем, кроме красиво написанных маркетинговых статей.
keltanas: воу воу, это статическая обертка над контейнером, не более, никакого отношения к самому контейнеру не имеющая. С Laravel5 можно нормально работать с зависимостями (вроде как и в Laravel4 тоже но в 5-ом оно как-то приятнее).
Что до всего остального - совсем не понимаю о чем вы говорите. Вопервых я не понимаю зачем нужно делать два канала для логгера. Все остальное ваше перечисленное вообще никакого отношения к IoC не имеет.
Простой
