Ну как-же)) Машины у них заправляются галлонами бензина, ездят со спидометрами в милях и рост измеряют в футах и вес в фунтах… температура в фаренгейтах итд…
Недавно проблема такая была тоже — поставил велик на станцию а он почему-то оказался не возврат а просто заблокирован(ни перепарковать, ни забрать дальше кататься). Списали 3000 за двое суток. Потом я им написал и объяснил ситуацию. Вернули деньги.
По непонятной мне причине, часто ищут разработчика, который в совершенстве умеет применить что-то, что вышло в релиз полгода назад.
Как по мне, нормальный разработчик(любой) должен заглядывать далеко вперед и играться с альфа/бета версиями продуктов, до такой степени, что к моменту релиза новой технологии или фреймворка — он уже все это знает. Считаю очень хорошей чертой, когда разработчик не просто умеет что-то писать а еще и имеет широкий кругозор в плане технологий. Это здорово, когда разработчик активно интересуется всем вокруг своей деятельности и любит экспериментировать с чем-то новым.
У меня настройки сделаны классами с помощью django-configuraions(ну люблю я когда один файлик settings.py а не куча всяких файлов с настройкми).
Все настройки через переменные окружения(использую свой django-confy)
В uwsgi у меня отдельные секции для development и production. например:
`
[uwsgi]
; тут общие настройки
; и потом идут секции с настройками кэширования, статистики, спулера и разные другие
[production]
env = DEBUG=False
env = DJANGO_CONFIGURATION=Production
ini = :uwsgi
ini = :cache
ini = :stats
ini = :spools
disable-logging
ignore-write-errors
ignore-sigpipe
print = Loaded production settings!
[development]
logto = %dlogs/%c.uwsgi.log
env = DEBUG=True
env = DJANGO_CONFIGURATION=Development
venv = /server/.py/%c
ini = :uwsgi
ini = :cache
ini = :spools
ini = :staticfiles
py-autoreload = 2
show-config
print = Loaded development settings!
`
То есть из uwsgi передается параметр в каком режиме загружать проект.
Запускаю как-то так(содержимое Procfile):
Насчет декорирования ссылок, мне нравится как делают многие зарубежные новостные сайты.
На одном из таких сайтов я выдернул код для примера и выложил на codepen.
Ну согласитесь же, что некрасиво смотрится когда вот на картинках в примере видно как буква "у" сливается с линиями декорации.
Конечно нужны! Хочется иметь самые свежие либы и софт. А с облаками и всякими ansible/puppet итд — деплоиться не сложно. Бд все-равно отдельно и хранилище файлов тоже))
Ну я в Stylus нашел много хорошего, и выбрал его уже после того как несколько лет пользовался LESS/Sass.
Насчет отступов — я и шаблоны пишу на slm/jade в последнее время))
Python/Django,Flask или Golang, Erlang только для бэкенда с API, а фронт пишу отдельно, используя средства фронт-енд разработки и MVC-фреймворки(это я к тому, что могут возникнуть вопросы почему я пишу шаблоны на slm а не на jinja2 например)
Верно, то что имеется куча примесей в less/stylus/sass это не значит что в результате css cкомпилится с кучей этих миксинов.
Миксины имеет смысл создавать когда что-то очень часто повторяется.
Как один из наиболее наглядных примеров плюсов использования миксинов в less/stylus/sass перед использованием чистого сss это конечно использование префиксов браузеров. Например можно сделать миксин типа:
в текущей версии уже есть встроенный захват звука системы или какого-либо окна
Ааа и тут в самом начале.
Это обосновано чем-то? Или это такой перевод?
Как по мне, нормальный разработчик(любой) должен заглядывать далеко вперед и играться с альфа/бета версиями продуктов, до такой степени, что к моменту релиза новой технологии или фреймворка — он уже все это знает. Считаю очень хорошей чертой, когда разработчик не просто умеет что-то писать а еще и имеет широкий кругозор в плане технологий. Это здорово, когда разработчик активно интересуется всем вокруг своей деятельности и любит экспериментировать с чем-то новым.
На хероку, например, настройки в админке заполняются. Никакие файлы .env с настройками не нужно иметь в репозитории.
Все настройки через переменные окружения(использую свой django-confy)
В uwsgi у меня отдельные секции для development и production. например:
`
[uwsgi]
; тут общие настройки
; и потом идут секции с настройками кэширования, статистики, спулера и разные другие
[production]
env = DEBUG=False
env = DJANGO_CONFIGURATION=Production
ini = :uwsgi
ini = :cache
ini = :stats
ini = :spools
disable-logging
ignore-write-errors
ignore-sigpipe
print = Loaded production settings!
[development]
logto = %dlogs/%c.uwsgi.log
env = DEBUG=True
env = DJANGO_CONFIGURATION=Development
venv = /server/.py/%c
ini = :uwsgi
ini = :cache
ini = :spools
ini = :staticfiles
py-autoreload = 2
show-config
print = Loaded development settings!
`
То есть из uwsgi передается параметр в каком режиме загружать проект.
Запускаю как-то так(содержимое Procfile):
На одном из таких сайтов я выдернул код для примера и выложил на codepen.
Ну согласитесь же, что некрасиво смотрится когда вот на картинках в примере видно как буква "у" сливается с линиями декорации.
Насчет отступов — я и шаблоны пишу на slm/jade в последнее время))
Python/Django,Flask или Golang, Erlang только для бэкенда с API, а фронт пишу отдельно, используя средства фронт-енд разработки и MVC-фреймворки(это я к тому, что могут возникнуть вопросы почему я пишу шаблоны на slm а не на jinja2 например)
вообще у меня в gulpfile автопрефиксер для стилуса стоит:
prefixer = require 'autoprefixer-stylus'
Миксины имеет смысл создавать когда что-то очень часто повторяется.
Как один из наиболее наглядных примеров плюсов использования миксинов в less/stylus/sass перед использованием чистого сss это конечно использование префиксов браузеров. Например можно сделать миксин типа:
а не расписывать все в кучу строк для каждого браузера.
В СSS это было бы:
Тут же вся фишка не в том какой в результате CSS будет по размеру, а как быстро ты его напишешь.
Код с Sass lаже в отдельной репе