Задать вопрос
Профиль пользователя заблокирован сроком с 18 ноября 2017 г. и навсегда по причине: спам
  • Стоит ли использовать ооп?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    То, что легче без ооп - безусловно, для скрипта на 100 строк, это будет лишним.

    В остальном - однозначно нужно.
    ООП дает вам понятие "сущностей данных", как минимум. Можно конечно обмазываться массивами, но в этом случае лучше не используйте в лексиконе слово "безопасность".
    ООП дает разграничение обязанностей. Можно конечно нагородить 1кк функций и сварганить на их основе вермишельку, когда выльете пару ведер крови из глаз - вспомните мои слова.
    ООП дает заменяемость кода по интерфейсу (Полиморфизм), как следствие - возможность варьировать логику, без миллиона switch-case и сложных условий.
    ООП дает сокрытие данных (Инкапсуляция). Если переменную можно изменить в любом месте проекта (глобальную например) - она будет где-то изменена, вы об этом можете не узнать (или попросту забыть), как следствие ваш код будет работать не предсказуемо.
    ООП дает возможность расширять функционал порождаемых сущностей (Наследование), как следствие - DRY.

    То, что Виталий Пухов написал не верно. Легко !== правильно, удобно, человеко-понятно, тестируемо, надежно. Легко как правило писать говно. Фраза "работает же" как правило значит: "да, я понимаю, что оно хреновое, но лучше не могу".

    И писал пару робот на нём сильной разницы в скорости между ооп и не ооп проэктами не замечал.

    Вы не туда смотрите)). Производительность на stateless языке... В общем посмотрите на компилируемые))

    * Про vk вы правильно сказали, но забыли 2 важных нюанса: он писался, когда ООП в php особо не было; у них свой KPHP))
    * Для сравнения у facebook тоже свой php: hhvm, но он очень даже объектный.
    Ответ написан
    1 комментарий
  • Как правильно сделать декомпозицию приложений Django?

    Вроде простой вопрос, на который тем не менее, крайне сложно дать вразумительный ответ.
    Чем больше приложений в проекте, тем лучше?

    нет, точно также не является лучшей практикой пихать всё в одно приложение.

    Разделение на модули делается для одной простой вещи - борьба со сложностью.
    Разрабатывать и поддерживать гораздо проще несколько модулей, каждый со своим функционалом и спецификой, чем один божественный апликйешен.
    Самое очевидно разбиение, эт вынесение специфического функционала, напрямую не влияющего на функционирование "ядра", допустим отчёты(если вы не саму систему отчётов пишете), они находятся в отдельном апликешене, я в принципе вообще могу их отключить, и при этом основная функциональность никак не будет затронута.
    Затем идёт явное логическое разделение, специфический функционал/задачи, допустим работа с адресным справочником, его периодическая синхронизация и прочее, все специфические задачи работы с ним находятся в отдельным модуле, и как они реализованы не касается остальной системы, при этом сам адресный справочник уже активно используется в остальной системе.
    И самый не очевидный этап, это когда один из апликешенов становится слишком сложным, тут можно воспользоваться, как разнесением функционала по отдельным файлам внутри самого апликешена, так и попытаться разнести его по отдельным апликешенам — собственно хорошо спроектированная система где это не придётся делать.
    Ответ написан
    Комментировать
  • Как правильно сделать декомпозицию приложений Django?

    un1t
    @un1t
    Запустить приложение отдельно это отдельная тема, она требует большего уровня абстракции и универсальности, со всеми плюсами и минусами. Обычно приложения в проекте долнольно тесно связаны и выделить их отдельно не представляется возможным, по крайней мере без напильника, да и смысла нет. Количество приложений в проекте зависит от размера проекта и степени связанности логики. Ну логика выделения простая, хотя формализовать ее сложно. Если в приложении становиться очень много моделей и вьюх, то есть смысл подумать о выделении части в отдельные приложения. Или если приложения сразу видно, что совсем про разное, то можно сразу выделять.
    Ответ написан
    2 комментария
  • Какой идеальный алгоритм ведения проекта?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Какой идеальный алгоритм ведения проекта?

    Не существует.

    Как правильно вести проект

    * Договор с заказчиком
    * Предоплата итерации 0 в полном размере.
    * Итерация 0: ТЗ. ТЗ должно быть максимально подробным. В его составлении могут участвовать все члены команды. Не используйте абстрактные слова/словосочетания и их производные в ТЗ: плохой, красивый, хороший, такой же, другой, простой. Словосочетания без уточнений: параметры, настройки, информация. Вместо этого: параметры: А, Б, В. Настройки: цена (вещественное[0,∞]),...
    * Подписанное обоими сторонами ТЗ.
    * Предоплата итерации 1 в полном размере.
    * Итерация 1: дизайн. Как только заказчик скажет "да, я хочу именно это"
    * Заказчик получает на руки копию дизайна, как результат первой итерации.
    * Предоплата итерации 2 в полном размере.
    * Итерация 2: верстка. Как только заказчик скажет "да, я хочу именно это"
    * Заказчик получает на руки копию сверстанного сайта, как результат второй итерации.
    * Предоплата итерации 3 в полном размере.
    * Итерация 3: программирование. Как только заказчик скажет "да, я хочу именно это"
    * Заказчик получает на руки копию свое сайта И установку его на сервере, как результат третьей итерации.
    * Итерация 4: поддержка. Ее инициатором является заказчик. Условия сотрудничества обговариваются отдельно.

    чтобы гарантированно его не завалить

    Вы работаете с людьми, какие могут быть гарантии?))

    сдать проект через месяц

    Воу-воу-воу, сроки определяются на основании ТЗ, а не прихоти.
    Ответ написан
    Комментировать
  • Как правильно писать документацию REST API?

    dizballanze
    @dizballanze
    Software developer at Yandex
    Где писать документацию, в Google Docs, Markdown прям в репозитории или что-то еще - не важно, главное чтобы вам было удобно.
    Важно чтобы эта документация была максимально полной и точной.
    Как вариант можете посмотреть raml, если хочется специализированный формат.
    Ответ написан
    Комментировать
  • Изучение Laravel, с чего начать?

    1. Попробовать написать свою CMS на PHP с использованием MVC
    2. Ознакомиться с документацией Laravel (laravel.su/docs/5.0/installation или laravel.com/docs/5.0)
    3. Просмотреть серию видеороликов (https://laracasts.com/series/laravel-5-fundamentals - необходимы знания английского)
    4. Написать свою CMS на PHP с использованием Laravel

    Ответ написан
    Комментировать
  • Как набрать проекты для портфолио Full stack PHP developer?

    codingal
    @codingal
    Front end и не только
    Если 7 лет опыта, то потратьте выходные или неделю на хоть какое-то КРУД-приложение - что угодно, туду-лист, менеджер закладок, посмотрите на апи какого-нибудь стороннего сервиса и напишите мелкое приложение, которое оттуда будет что-то вытягивать и чтоб с фильтрами, а код на гитхаб.
    По сути, смена специализации - это ваша личная проблема, в которую заказчики вникать не обязаны.
    Покажите свой код, что вы можете и умеете делать работу, в первых заказах сыграйте на срочности - бидьте в числе первых на срочные и дорогие заказы, так вы обойдете людей с рейтингом и отзывами.
    Ответ написан
    Комментировать
  • Архитектура API на Laravel?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Может быть есть другой вариант?

    Да, есть, перестать страдать фигней с универсальными настройками раутинга (всеравно придется потом что-то докручивать) и сделать нормальную REST/JSON RPC API, со своими правилами на каждый метод API.

    laravel.com/docs/5.0/controllers#restful-resource-... - вообще имеет смысл вот такие штуки использовать.

    По версиям API - можно через мидлвэры разруливать.

    Что до {type} - вообще это не круто, если вы хотите получить json вместо xml, то просто пишите в Accept именно application/json, а не делайте кастыли в URI. Хотя это как вам удобнее конечно.
    Ответ написан
    5 комментариев
  • Как лечится кризис начинающего программиста?

    kumaxim
    @kumaxim
    Web-программист
    Господин начинающий, у Вас извращенный подход к программированию в целом.
    Программа - это способ более эффективно решить какую-то задачу... способ достижения какой-то заданной цели с меньшим количеством ресурсов.

    Возьмем, как пример, тот же бух.учет на предприятии. Как Вы думаете, почему 1С Бухгалтерия так широко распространилась в РФ и СНГ? Эта программа позволяет бухгалтеру в 2-3 клика мышки сформировать отчет для регулятора(ФНС, ПФР и т.д.), вместо того чтобы человеку сидеть руками искать платежные поручения, вычислять налоги и т.п. Софт просто подтягивает выписку из банка, анализирует ее и выдает готовую для печати бумажку, что экономит бухгалтеру сильно много времени. Расчет заплатанный налогов и отчеты в соц.фонды это вообще красота - 8 кликов мышкой и все готово :-)

    Что я описал выше? Это способ решения одной конкретной задачи с гораздо меньшим количеством ресурсов, в данном случае - времени. Эта программа экономит время на подготовку бумаг, на расчеты сумм налогов, снижает вероятность ошибки и т.д. Это ее основная ценность, которую несут ее создатели обществу

    И вот, далее Вы для себя определитесь, какая Ваша основная цель? Какой Ваш основной посыл обществу?

    Личной мой посыл - "Я помогаю людям экономить: время, деньги, нервы и т.д.".

    Как я это делаю?
    У меня сначала был маленький интернет-магазин по продаже катализаторов для бензина(в поиск "кондиционеры метала для а/м"). При соблюдении определенных условий, расход топлива на малометражках снижался от 20% до 45%
    Вторым моим проектам было небольшое мобильное приложение для отслеживания хода исполнительного производства в ФССП(для взыскательней, уже сдохло). Мне и моим знакомым(не юристы) это экономило достаточно много времени на ругань с приставами, чего они должны делать и т.д. Кто сталкивался с этой службой должен знать эффективность и оперативность их работы, особенно в регионах...
    Сейчас я пишу небольшой конструктор сайтов, который поможет одной дружественной мне веб-студии сильно оптимизировать процесс создания низкобюджетных сайтов визиток

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

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

    Если говорить о чисто практических инструментах(функции стандартной библиотеки, фреймворки и т.д.)... Лично я могу считать себя профессионалом в какой бы то ни было технологии, ни когда я прочитал 1-2 книги и/или написал 1,5 задачи оттуда же. С таким уровнем я не могу сказать что я знаю язык/технологию в принципе, просто знаком - да, но я ее не знаю. Считать себя профессионалом я могу после того как решу не менее сотни задач, используя эту технологию и написал не менее 1 млн строк кода, именно написал, а не сгенерировал rake/gii/artisan или чем-то там еще.

    Вам же я желаю не останавливаться, развивайтесь. Мастерство приходит с опытом.

    P.S.: от холиваров на тему 1С прошу всех воздержаться
    Ответ написан
    11 комментариев
  • Для чего используется golang?

    artem_kovardin
    @artem_kovardin
    Go отлично подходит для сетевого программирования. Сравнительно небольшие усилия нужны для написания довольно приличного клиент-серверного приложения (consul, etcd).

    Кроме того, скорость и маленькое потребление памяти позволяют применять Go для обработки большого количества информации, подсчета статистики, написания парсеров/кравлеров. Тут очень сильно способствует возможность простого распараллеливания.

    Go применяется для написания девопс и админских инструментов (Docker, CoreOS) которые легко использовать, так как все компилируется в один бинарник и линкуется статично.

    А вообще, заходите к нам, читайте новости и будете всегда в курсе, для чего используется Go.
    Ответ написан
    1 комментарий
  • Стоит ли учить сейчас Node.js?

    smanioso
    @smanioso
    Отмечайте ответы на свои вопросы!
    Выучите, наконец, JavaScript и отпадет необходимость "учить" node.js, io.js, jQuery и прочее-прочее-прочее...
    Ответ написан
    2 комментария
  • Почему нет вопросов по GRASP паттернам(принципам) на тостере?

    hrls
    @hrls
    Это от того, что на тостере преимущественно обитают полные нубы, которые не могут потратить полчаса на изучение проблемы и поиск решения, а предпочитают сходу задавать вопросы и получать решение, либо же кретины с вопросами вида "план обучения %PROG_LANG%" или "мне 100500 лет, я водитель такси, Java - не поздно ли?". Такие обитатели еще не доросли до GRASP.
    А по существу - GRASP действительно более абстрактные в сравнении с GoF и не настолько четко выражаются кодом. От чего и имеют область определения в головах программистов с бородами, которые и без помощи Q&A могут вспомнить примеры из личного опыта и найти решение.
    Ответ написан
    Комментировать
  • Стоит ли учить Ruby если на работе пишу на PHP?

    @Tumass
    Веб-разработчик
    Нет, не стоит распылятся. Поскольку у вас компания использует PHP и Вас устраивает данная компания, то поднимайте уровень PHP. Изучите шаблоны проектирования/архитектуру приложений. Подтяните JS, HTML если требуется.

    После этого, можно уже пробовать другие ЯП.

    Если уж очень хочется Ruby, то попробуйте найти компанию, где набирают Ruby новичков. Есть ли спрос на разработчиков без опыта в Вашем городе?
    Ответ написан
    Комментировать
  • Стоит ли учить Ruby если на работе пишу на PHP?

    banderos120
    @banderos120
    Играю на балалайке
    Хотя бы на PHP научись, то, что ты там пробовал то, пробовал это - роли не играет, и "переквалифицироваться" - это слишком громко сказано, так как и квалификации, как таковой у тебя в PHP нет. Будешь уметь правильно строить архитектуру - войдешь в другой, смежный язык, без проблем.
    Ответ написан
    Комментировать
  • Стоит ли учить Ruby если на работе пишу на PHP?

    @Ramallah
    Главное построить верно архитектуру приложения. А наговнокодить на любом языке можно.
    Учить надо хотя бы из-за того, что бы перенять некоторые приемы и расширить свой кругозор.

    По поводу PHP-кал... Жигули тоже есть кал, но на них ездят. А 7-ая версия пыхи обещает быть интересной.
    Ответ написан
    Комментировать
  • Что выбрать, Yii2 или Laravel?

    seoperin
    @seoperin Автор вопроса
    Full stack web developer. Laravel / Vue
    Всем большое спасибо за советы. Немного прояснилась ситуация с этими фреймворками. Первую попытку попробую сделать на Yii2, просто из-за более быстрого старта при моих знаниях. Когда набью руку, возможно двинусь покорять laravel или simfony.
    Ответ написан
    3 комментария
  • Что выбрать, Yii2 или Laravel?

    SamDark
    @SamDark
    Yii2 core team
    Как новичку вам будет очень полезно понять, что у фреймворка внутри и как он работает. Если залезть во внутренности Yii, вы увидите, что там документирован каждый метод, каждый класс, абстракции минимум, всё делается настолько просто, насколько это вообще возможно. Изучить именно как что работает просто.

    Если залезть в Laravel, там всё очень слоёно. Комментариев нет. Чтобы понять, как работает метод нужно частенько пролезть через 3—5 слоёв абстракции в нескольких классах.

    В документации по Laravel, кстати, использован крутой трюк. Описана лишь часть того, что вообще даёт фреймворк. Это делает доку очень компактной, лёгкой и приятной, но за остальным — либо код без комментариев читать, либо Laracasts смотреть.
    Ответ написан
    13 комментариев
  • Что выбрать, Yii2 или Laravel?

    В своё время пару лет назад тоже решал. Начал изучать с CodeIgniter для того, чтобы понять принцип работы и поближе узнать об MVC. Для понимания смысла было достаточно. Затем пробовал и Yii, и Laravel. Остановил свой выбор на Laravel ( 4 версия тогда была еще). Просто и понятно, есть хорошие уроки на scotch.io, lynda.com. Для бэкенда самое то. Для фронтенда не использую встроенный шаблонизатор blade, делаю сразу на Angular. Весьма удобное разделение фронта от бэка получилось. Laravel я доволен по прошествии уже 1.5 лет. Не нарадуюсь)
    Ответ написан
    1 комментарий