Пожалуй это самый крутой учебный материал по 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 я помню (однако это не исключает того что я их не храню в ластпассе).
Таким образом если мне нужен пароль, который мне действительно нужен — то ластпасс я буду использовать только для быстроты его получения.
Хотя и тут можно возразить. Мол, смарт разрядился, ноут заглючил, ласпасс лежит, а в добавок ещё и провал памяти. Случай не надуманный — до сих пор не понимаю как однажды умудрился просто не вспомнить пароль, который вводил по несколько раз за день.
Как уже говорили раньше — серебрянной пули не существует.
Не знаю кто как, но я зарёкся ходить к рекрутётам. Мой опыт показал что это реально пустая трата времени. Но что мне не нравится больше всего что оценка идёт очень поверхностная. Я ни разу ещё не был на интервью в HR агенстве где мне задавали бы вопросы, касающиеся технических аспектов моей работы. Конечно, автор упомянул что агент должен хотя бы интересоваться что и как происходит на позиции куда ищут кандидата. Но вот пример из моей жизни.
На моё резюме пришёл отклик от одной давольно хорошо известной в узких кругах компании. Девушка из HR этой компании сказала что так как у них большой поток соискателей, то они проводят сначала телефонное тестирование по результатам которого принимается решение о том приглашать человека на встречу или нет. Она начала задавать технические вопросы. Небольшое отступление — в компанию теребовался человек, имеющий опыт с высоконагруженными проектами. Я сразу сказал что такого опыта не имею так как максимум что было в моей жизни — одномоментные 800 коннектов.
Но что меня просто выбило из колеи так это вопрос чем MyISAM отличатеся от INNODB. Я, наверное, минуты три говорит про транзакции, про внешние ключи, про уровни блокировки в этих базах, о том как хранятся таблицы на диски. И после этого мне задают вопрос: Ну а всё же, чем они отличаются?
Я честно завис секунд на пять. Мне дали задали наводящий вопрос — Там даже слово такое есть. Вот INNODB она такая база данных? Я — транзакционная? Она — Да-да-да, тразакционная.
У меня были одни эмоции — я буквально пару минут назад сказал про транзакции, но другим словом. Сложилось впечатление что девушка сидела и по бумажке проверяла мои ответы.
И, собсвенно, после этого я задался вопросом, а стоит ли проходить интервью с человеком, которой не понимает сам вопрос? Я считаю что моё время стоит дороже этого.
ЗЫ. На собеседование меня не позвали так как на многие вопросы по выским нагрузкам не смог ответить.
Но у меня несколько отвелечённый вопрос — может быть кто-нибудь знает что-то подобное для 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. Ну так, чисто для единообразия.
Ваш подход к рефакторингу по префиксам и постфиксам будет работать ровно до тех пор пока не найдётся «умник» решивший что неплохо бы иметь перменную cl_container, которая как нельзя лучше отображает что в ней содержится результат селекта по данному классу. var cl_container = document.getElementsByClassName('cl_continer')
Да, тут можно поспорить что перменная содержащая массит должна быть во множественном числе (cl_containres) или если, к примеру, использовался jQ, то надо было написать как $cl_container.
Вобщем к чему я всё это? Вы верно напсали в конце статьи что нужно обучать работать с новым сопособом наименования. А это невсегда приемлимо. Но вы — молодец. Серьёзно, без сарказма. Имхо то что вы пытаетесь сделать — разработать стандарт для наименования. И это отлично. Ну а то что он не принят хабром… Можно посмотреть на то что делает PHP-FIG. К ним была масса претензий что они выбрали 4 пробела вместо одной табуляции. И что, от этого они стали хуже? Нет. Они просто не такие как кто-то привык.
Единственное, множество стандартов этого хорошо. Плохо когда они все пытаются уместиться в одном проекте (или даже одном файле)
Например такая
class="[^"]*?(container\b)Хотя да, выше вы уже писали что в вашем случае «не надо городить большие регулярки». Но лично моё имхо что нет большой разницы между ((?:cl_)container) и тем что я написал.
Ошибся веткой.Таким образом если мне нужен пароль, который мне действительно нужен — то ластпасс я буду использовать только для быстроты его получения.
Хотя и тут можно возразить. Мол, смарт разрядился, ноут заглючил, ласпасс лежит, а в добавок ещё и провал памяти. Случай не надуманный — до сих пор не понимаю как однажды умудрился просто не вспомнить пароль, который вводил по несколько раз за день.
Как уже говорили раньше — серебрянной пули не существует.
Лично мне больше нравится вариант от bling. Форкнул его и теперь подстраиваю под себя.
Некоторые отметил для себя как обязательные к приобретению.
npm install -g generator-n| 0.На моё резюме пришёл отклик от одной давольно хорошо известной в узких кругах компании. Девушка из HR этой компании сказала что так как у них большой поток соискателей, то они проводят сначала телефонное тестирование по результатам которого принимается решение о том приглашать человека на встречу или нет. Она начала задавать технические вопросы. Небольшое отступление — в компанию теребовался человек, имеющий опыт с высоконагруженными проектами. Я сразу сказал что такого опыта не имею так как максимум что было в моей жизни — одномоментные 800 коннектов.
Но что меня просто выбило из колеи так это вопрос чем MyISAM отличатеся от INNODB. Я, наверное, минуты три говорит про транзакции, про внешние ключи, про уровни блокировки в этих базах, о том как хранятся таблицы на диски. И после этого мне задают вопрос: Ну а всё же, чем они отличаются?
Я честно завис секунд на пять. Мне дали задали наводящий вопрос — Там даже слово такое есть. Вот INNODB она такая база данных? Я — транзакционная? Она — Да-да-да, тразакционная.
У меня были одни эмоции — я буквально пару минут назад сказал про транзакции, но другим словом. Сложилось впечатление что девушка сидела и по бумажке проверяла мои ответы.
И, собсвенно, после этого я задался вопросом, а стоит ли проходить интервью с человеком, которой не понимает сам вопрос? Я считаю что моё время стоит дороже этого.
ЗЫ. На собеседование меня не позвали так как на многие вопросы по выским нагрузкам не смог ответить.