Нет. У ZF2 большой порог вхождения и зачастую что бы хорошо понять определенную вещь нужно обращаться к сторонним ресурсам, если прежде с текущим вопросом сталкиваться не приходилось. И ещё раз повторюсь, это не элементарно, как утверждаете Вы, особенно когда дело доходит до практики.
С чем кокнретно в рамках фреймворка вы столкнулись на что нет ответа в документации? Предметно укажите ответа на какой вопрос вы не нашли в документации я ткну вас в документации прямо на этот ответ. Пока же это всё ваши субъективные мысли.
teddy пишет:
Какое отношение документация имеет к репозиторию?
ZF претендует на промышленный стандарт в веб-разработке. И, если вы не в курсе, любые модули и расширения которые пишут под него девелоперы и которые претендуют на включение в основной репозиторий должны быть соответствующим образом документированы, что проверяется.
Далее, могу привести вам конкретный пример когда в угоду быстрой обработки запросов пишется решение обходящее логику обработки запросов и mvc-архитектуру фреймворка и предназначенное, к примеру для быстро записи/чтения из Redis. При частом возникновении подобных задач решения могут быть включены в фреймворк и расширить его. Так было со многими прикладными классами для работы к примеру с google-сервисами в том же ZF.
выбираете любой и читаете документацию по работе с ним в чем проблема?
Все сводится к отправке правильно структурированного запроса на сервер биллинговой компании и всё. Как его структурировать описано в документации.
И как ты собираешься понимать фреймворк если ты его не знаешь? Телепатия? Хм...
Документация это всё что необходимо. По Zend она всеобъемлющая и исчерпывающая что является одним из условиев включения модулей в основной репозиторий. Если не поняли ZF из неё значит опыт работы с фреймворками в целом невелик ибо ничего радикально нового Yii, Symfony и проч. не привносят, а многое и заимствуют, как к примеру Yii из ZF.
teddy пишет:
Да и вряд ли кто станет переписывать фреймворк на 90%. Он для того и написал чтоб его использовали а не переписывали.
teddy пишет:
Что касается собственного велосипеда, то скажу приблизительно так:
Свой велик можно написать, если есть время и деньги. Но вряд ли он будет мощнее и гибче чем популярный фреймворк,
Когда столкнётесь с первым нагруженным проектом с тысячами регистраций в сутки, и миллионом хостов, поймете что я имел ввиду и где что стоит переделать или оптимизировать, и на каких участках в обход реализации фреймворка.
реализуйте, посмотрим.
Я бы сказал вам про замыкания, но будет полезнее если напишете своё рабочее решение и потом спросите про оптимальное, и ещё потому что это не раздел "Напишите за меня: мне лень".
Перепишите свой код по человечески с отделением html которые цепляете в методе вывода исключения.
Проставьте все отступы как в документации и примерах.
И найдете свою ошибку.
очевидно потому что глупо оборачивать div в a. Сделайте <a class="aindiv" href="#"></a> внутри дива и задайте ему стиль как блоку с нужными размерами.
Либо задайте для img display:block; и оперируйте любыми свойствами блока
В чем проблема ?
правильно выберайте раздел для темы. Вы пишите в php.
Вы можете указать фиксированные размеры картинки и она у вас растянется и покривится согласно размерам в теге img. Но этого делать не стоит.
Очевидно это для вас, но не значит что правильно.
Многие браузеры некорректно рендерят картинку если им прописывать размеры и пропорции, которым она не соответствует да её и сложно корректно отрендерить потому что это задача не браузера и уж тем более не html, а разработчика. Вы можете увеличить, скрыть лишнюю часть картинки средствами html, но никак не внести изменения в сам файл, выполнив обрезку. Есть решение на canvas но уверен что это совершенно не то что вам требуется.
Неоднократно встречал противоположное мнение от людей того же самого московского региона. Если джун не спрашивает совета - значит он или говнокодит или ничего не делает.
Самостоятельное решение задач не значит не спрашивать совета.
К примеру старший может задать вектор, разъяснить принцип, а джун уже копает и реализовывает по конкретным примерам из кода проекта или документации. Так и было всегда.
Спрашивать никто не запрещает. Но это не значит что можно как на форуме отписать в рэдмайне "У меня чтото не работает. Пишет такой то эррор, помогите!".
Уровень конечно безусловно зависит от конкретной компании и конкретного проекта. И география тут непричем учитывая что все крупные софтверные компании имеют офисы, филиалы или аутсорсеров в российских регионах.
От специализации диплома должен быть на автомазиации работы туристских предприятий.
Изначально направления не веб. Java и C# в рамках того, как их преподают у нас в университах, то есть теория и математика, которая давно и благополучна забывлась.
Только C# потом стал учить и применять сам поэтому основы знакомы.
С пыхом также начал знакомиться с 2009 но очень ограничено. С создания системы учета заявок в лаборатории информационных ресурсов в универе где работал настройщиком видовсов и игроком в CS
после выпуска в 2010 автоматизация продаж в торговой фирме, где в числе прочего на пыхе там делали магазин аутсорсеры. Вот его доработка и изучение дали начальную базу.
С 2011 рекламное агентство + холдинг контор на аутсорсинге поддержка-разработка множества сайтиков. Тут уже и вёрстка и мускул и ajax познались глубже
С 2012 ушёл в информационное агентство. Тут интереснее - портал крупнейший в регионе, хоть какойто хайлоад, интересные разделы портала и задачи, азы ООП, десктоп Linux и проч. Ну и клиентские сайты также лабали там.
И вот с 2014 перебрался в мск. переехал как месяц уже. Пригласили поработать над популярным проектом. ООП пых, node.js, redis, mongo и уже по полной...
Ладно что тут дискутировать.
Был упомянут junior php developer и я в общих чертах описал что от него ждёт наниматель по личным наблюдениям. Если нужен на он, а "помошник программиста в веб-студии", который подцепит js-либу, сверстает шаблон, и "напишет код формы обратной связи", то так и нужно это называть.
Мы понимаем проблему работы "на будущее", но, платить зарплату программисту из своего кармана возможности нет. Поэтому ищем на таких условиях. Кроме того, при заинтересованности программиста, исполнение будет более качественным, а не "ради сиюминутных денег".
Так вы пишите объявлени е о работе! А оплаты не предлагаете, только процент от прибыли, как МММ.
Вы ищите тогда инвестора, предлагая ему долю в проекте, закреплённую договором, а не сотрудника. Есть для проектов без бюджета соответствующие сервисы - там биржи бизнесс-идей, кикстартеры и что угодно ещё.
Вы будете вкладывать деньги, а программист код писать.
Если у вас нет возможности платить разработчику о каком проекте в сфере IT вы речь вообще ведёте?
Если только первое послестартовое продвижение на рынке требует бюджета кратно превышающего бюджет разработки. Вы же не второй Вконтакте делаете? - Нет. Сток медиафайлов там или биржу фотографий с парой уникальных приблуд. Программист потратит 2 месяца, не будет спать, напишет вам проект который вы даже развернуть должным образом не сможете потому что не представляете что такое отдавать медиафайлы, какие для этого нужны мощности, железо, софт. Вам нужен будет для этого системный администратор, который купит, настроит площадку серверов с балансиром и постоянно будет на поддержке. Его вы тоже возьмёте на процент от прибыли? Заодно и хостинговую компанию тогда в Германии на такой же процент за канал и 5 юнитов в стойке?
Не увидел у тс ни слова про аутсорс. речь шла четко об устройстве в компанию как жуниор php-разработчик. Если упоминается статус специфичный для разработчика в it-компании, то об аутсорсе и тем более фрилансе речи не веду. Гдето в регионе мб требования ниже и достаточно трети учебника Попова. То что указал выше в частности справедливо для it-проектов в мск. Как раз в одном таком подбирает ведущий разработчик жуниуров и делится какие задачи им даёт и что спрашивает.
Panoptik, огромное спасибо!
Сделаю по Вашему гайду, набор мини-проектов, которые и на собеседовании можно будет показать, если дойдет до собеседования Круто
Может конечно мы в разных регионах и т.п., но наборы минипроектов и собственные поделки никого не интересуют. Интересуют действующие системы написанные по канонам ооп, а не гостевая книга в 10 строк процедурного кода.
Жуниор должен знать и уметь применять ООП и самостоятельно разбирать и понимать чужой объектный код, а также самостоятельно решать задачи не дёргая сеньёора по каждому вопросу.
Разумеется IDE SVN или GIT. (Добавление)
teddy пишет:
В начале 2013 года я даже html не знал, сегодня разрабатываю на Zend Framework 2. Делайте выводы.
Это критерием чего должно стать?
В крупных коммерческих проектах фреймворки открытыене юзаются в 100% случаях пишется свой велосипед или на 90% переделывается. Поэтому гораздо важнее не знать какой-либо фреймворк, что в сущности элементарно, а понимать как он работает и почему именно так написан и в случае необходимости писать своё более оптимальное обходное решение под проект.
Поэтомун а собеседованиях и тестовых заданиях для серьёзного проекта обычно не дают задачи в рамках каких-то коробок.
Дают задачу, к примеру, как у нас написать CRUD на классах и потом уже сеньёр или ведущих программист с вами будет общатсья по вашему коду задавать вопросы. (Добавление)
esterio пишет:
незнаю как счас, но на джуниора я попал со знаниями как сделать простой сайт в процедурном стиле, немного jQuery, знал немного GD, и XML
Смотря куда и на какой проект. Веб-студию - легко. Даже сейчас и даже в Москве. На федеральный портал - нет.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 2118
