Пожалуй это самый крутой учебный материал по Flask и Python, который я только видел.
Но у меня несколько отвелечённый вопрос — может быть кто-нибудь знает что-то подобное для PHP и какого-нибудь его фреймворка? Что бы человеку, знающему синтаксис языка, можно было пройти весь путь от проектирования приложения до деплоя.
Было видео на Youtube, ссылку, к сожалению, не могу найти, в котором говорилось что «best practices» написано с прицелом на начинающих разработчиков, что бы не грузить их академичностью подхода фреймворка.
В тех же практиках рекомендуется использовать YAML для задания сервисов, мол, так проще читать и в дальнейшем поддерживать. Однако более продвинутый подход предполагает всё таки XML для этих целей. Как минимум потому что благодаря IDE можно проверять корректность и валидность документа.
Кстати, раз вы упомянули разные composer.json в зависимости от окржужения. Есть какой-нибудь рецепт как это организовать? Исключать сам composer.json и вместо него коммитить некий composer.json.dist?
И получается, что бы в проекте inikulin/nourriture получить изменения, которые были сделаны в inikulin/gluten мне нужно сначала закоммитить и только после этого они подтягиваются композером.
По ссылке что вы дали автор пишет что можно сделать симлинк на репозиторий. Но этот метод, я так понимаю, в Windows не работает.
С одной стороны, конечно, здорово. С другой — доставляет определённое неудобство.
К примеру сейчас я веду работу над двумя пакетами. Одни использует в качестве зависимости второй. Получается что после того как я внёс изменения в пакет, то мне нужно закоммитить эти изменения и выполнить composer update в другом пакете.
Можно, конечно, использовать симлинки, но это как-то… неправильно, что ли.
Кто-нибудь в курсе как в новую версию вписывается разработка собственных пакетов? Раньше можно было мучать workbench. Я верно понял что его «выпилили» и предлагают новые пакеты устанавливать через composer?
Это, конечно, моё сугубо личное мнение, но статья не рассказывает ничего такого чего не было бы в официальной документации.
Лично мне было бы интересно увидеть статью где показывалось более продвинутое использование сервис провайдера и приводился функционал, который бы позволял регистрировать свои сервисы.
Плюс, это уж точно вопрос религии, но зачем создавать пространства имён только для того что бы затем в composer.json свести всё на нет подлючив целую папку. Имхо, PSR-0 и PSR-4 решают вопрос загрузки классов намного более гибче и изящнее.
С файлом рутингов та же схема. Это, конечно, вкусовщина, но мне кажется более правильный подход — подключать рутинг в методе register вашего провайдера.
Шрифты это, конечно, отдельная боль. Но у автора Powerline есть отдельный проект powerline-fonts где можно взять уже пропатченные шрифты. Мой любимый — AnonymousPro.
А по поводу скорость работы — не знаю. Мне кажется что при современных мощностях это становится менее актуальным.
Ну прежде всего не стоит мешать в одну кучу html, php, js и css. У каждого своя область использования и следовательно разные подходы к разработке. То что прокатит в html в js может выйти боком.
Ваш подход к рефакторингу по префиксам и постфиксам будет работать ровно до тех пор пока не найдётся «умник» решивший что неплохо бы иметь перменную cl_container, которая как нельзя лучше отображает что в ней содержится результат селекта по данному классу. var cl_container = document.getElementsByClassName('cl_continer')
Да, тут можно поспорить что перменная содержащая массит должна быть во множественном числе (cl_containres) или если, к примеру, использовался jQ, то надо было написать как $cl_container.
Вобщем к чему я всё это? Вы верно напсали в конце статьи что нужно обучать работать с новым сопособом наименования. А это невсегда приемлимо. Но вы — молодец. Серьёзно, без сарказма. Имхо то что вы пытаетесь сделать — разработать стандарт для наименования. И это отлично. Ну а то что он не принят хабром… Можно посмотреть на то что делает PHP-FIG. К ним была масса претензий что они выбрали 4 пробела вместо одной табуляции. И что, от этого они стали хуже? Нет. Они просто не такие как кто-то привык.
Единственное, множество стандартов этого хорошо. Плохо когда они все пытаются уместиться в одном проекте (или даже одном файле)
Не надо открывать и пробегаться. Есть же регулярки.
Например такая class="[^"]*?(container\b)
Хотя да, выше вы уже писали что в вашем случае «не надо городить большие регулярки». Но лично моё имхо что нет большой разницы между ((?:cl_)container) и тем что я написал.
Тот пароль, который нужен «прямо сейчас» надо запоминать, а не беспечно полагаться на менеджер паролей. Я использую ластпасс для всяческих регистраций на форумах где не хочу помнить пароль. Но пароль от Evernote, GetPocket, Google я помню (однако это не исключает того что я их не храню в ластпассе).
Таким образом если мне нужен пароль, который мне действительно нужен — то ластпасс я буду использовать только для быстроты его получения.
Хотя и тут можно возразить. Мол, смарт разрядился, ноут заглючил, ласпасс лежит, а в добавок ещё и провал памяти. Случай не надуманный — до сих пор не понимаю как однажды умудрился просто не вспомнить пароль, который вводил по несколько раз за день.
Как уже говорили раньше — серебрянной пули не существует.
Имхо если нужно структурировать данные для принятия решения, то делать это надо правильно, а не складывать мокрое с синим.
Например, если мне нужен облачный сервис с онлайн-редактированием документов, то данный параметр должен быть у всех кандидатах. А то получается что одному я за него плюсы начислил, а другой остался в пролёте не смотря на то что у него тоже есть эта услуга, но, допустим, за дополнительные 2 бакса.
Но у меня несколько отвелечённый вопрос — может быть кто-нибудь знает что-то подобное для PHP и какого-нибудь его фреймворка? Что бы человеку, знающему синтаксис языка, можно было пройти весь путь от проектирования приложения до деплоя.
В официальной документации пишут что
В тех же практиках рекомендуется использовать YAML для задания сервисов, мол, так проще читать и в дальнейшем поддерживать. Однако более продвинутый подход предполагает всё таки XML для этих целей. Как минимум потому что благодаря IDE можно проверять корректность и валидность документа.
Кстати, раз вы упомянули разные composer.json в зависимости от окржужения. Есть какой-нибудь рецепт как это организовать? Исключать сам composer.json и вместо него коммитить некий composer.json.dist?
И получается, что бы в проекте inikulin/nourriture получить изменения, которые были сделаны в inikulin/gluten мне нужно сначала закоммитить и только после этого они подтягиваются композером.
По ссылке что вы дали автор пишет что можно сделать симлинк на репозиторий. Но этот метод, я так понимаю, в Windows не работает.
К примеру сейчас я веду работу над двумя пакетами. Одни использует в качестве зависимости второй. Получается что после того как я внёс изменения в пакет, то мне нужно закоммитить эти изменения и выполнить composer update в другом пакете.
Можно, конечно, использовать симлинки, но это как-то… неправильно, что ли.
Лично мне было бы интересно увидеть статью где показывалось более продвинутое использование сервис провайдера и приводился функционал, который бы позволял регистрировать свои сервисы.
Плюс, это уж точно вопрос религии, но зачем создавать пространства имён только для того что бы затем в composer.json свести всё на нет подлючив целую папку. Имхо, PSR-0 и PSR-4 решают вопрос загрузки классов намного более гибче и изящнее.
С файлом рутингов та же схема. Это, конечно, вкусовщина, но мне кажется более правильный подход — подключать рутинг в методе register вашего провайдера.
"autoload": { "classmap": [ "src/Illuminate/Queue/IlluminateQueueClosure.php" ], "files": [ "src/Illuminate/Support/helpers.php" ], "psr-0": { "Illuminate": "src/" } },А по поводу скорость работы — не знаю. Мне кажется что при современных мощностях это становится менее актуальным.
Кстати, раз уж вы затачиваете vimrc на работу с Python, то возможно имеет смысл использовать не airline, а powerline. Ну так, чисто для единообразия.
set noerrorbellsоставляет только одни режимВаш подход к рефакторингу по префиксам и постфиксам будет работать ровно до тех пор пока не найдётся «умник» решивший что неплохо бы иметь перменную cl_container, которая как нельзя лучше отображает что в ней содержится результат селекта по данному классу. var cl_container = document.getElementsByClassName('cl_continer')
Да, тут можно поспорить что перменная содержащая массит должна быть во множественном числе (cl_containres) или если, к примеру, использовался jQ, то надо было написать как $cl_container.
Вобщем к чему я всё это? Вы верно напсали в конце статьи что нужно обучать работать с новым сопособом наименования. А это невсегда приемлимо. Но вы — молодец. Серьёзно, без сарказма. Имхо то что вы пытаетесь сделать — разработать стандарт для наименования. И это отлично. Ну а то что он не принят хабром… Можно посмотреть на то что делает PHP-FIG. К ним была масса претензий что они выбрали 4 пробела вместо одной табуляции. И что, от этого они стали хуже? Нет. Они просто не такие как кто-то привык.
Единственное, множество стандартов этого хорошо. Плохо когда они все пытаются уместиться в одном проекте (или даже одном файле)
Например такая
class="[^"]*?(container\b)Хотя да, выше вы уже писали что в вашем случае «не надо городить большие регулярки». Но лично моё имхо что нет большой разницы между ((?:cl_)container) и тем что я написал.
Ошибся веткой.Таким образом если мне нужен пароль, который мне действительно нужен — то ластпасс я буду использовать только для быстроты его получения.
Хотя и тут можно возразить. Мол, смарт разрядился, ноут заглючил, ласпасс лежит, а в добавок ещё и провал памяти. Случай не надуманный — до сих пор не понимаю как однажды умудрился просто не вспомнить пароль, который вводил по несколько раз за день.
Как уже говорили раньше — серебрянной пули не существует.
Например, если мне нужен облачный сервис с онлайн-редактированием документов, то данный параметр должен быть у всех кандидатах. А то получается что одному я за него плюсы начислил, а другой остался в пролёте не смотря на то что у него тоже есть эта услуга, но, допустим, за дополнительные 2 бакса.
Лично мне больше нравится вариант от bling. Форкнул его и теперь подстраиваю под себя.
Некоторые отметил для себя как обязательные к приобретению.
npm install -g generator-n