Если тестировалось один sessionid то нет ничего удивительного, файл кешируется на уровне ОС и на уровне диска. Т.е. по факту все читалось из памяти. Что редис, что файл. Почему постгрес так тупил загадка.
Файл по прежнему доступен по ссылке любому пользователю.
Прописать запреты в robots.txt это хорошо, но не достаточно. Уязвимость не закрыли, а только, чуток замаскировали.
Переписка рука-лицо.
Недавно же была утечка тысяч контактов с fl.
Ну с таким уровнем технарей и отношением саппорта не удивительно.
30 миллионов это не большие объемы, любая БД (MySQL/Postrges/MongoDB) это тянет безе проблем. У вас видимо либо проблемы с индексами, либо за запросами.
Я вот поставил докер, прошел туториал. Но пока не понимаю как он может быть полезен в разработке.
Писать команды вида «docker run learn/tutorial apt-get install -y ping» кажется не очень удобно, а ssh не рекомендуется юзать.
С вагрантом все понятно, это удобная обертка для виртуальных машин. Хотя я тоже долго не мог понять зачем он нужен. Потом понял. Скачать образ линукса и подключить к virtualbox не сильно сложная задача, но с вагрантом это делается одной командой из консоли. Очень удобно.
Да нет, поможет. Хардкорное TDD вообще редко используют в статических языках, потому что не нужно. Тесты пишут уже после кода. Дилемма простая, в статике ты описываешь типы и пишешь мало тестов, а в динамике ты пишешь много тестов, очень много тестов, нужно больше тестов. И в чем профит, в экономии времени? Так в динамике время реально экономится, когда тестов не пишешь вообще :) А если их писать, то времени приходится тратить больше, чем на типы… Это хорошо видно по распределению проектов — динамика в основном используется как CRUD примочка к базе, которой упасть в принципе не страшно, для скриптов автоматизации, для прототипов и расчетов… А статика — когда куча умных перцев готовит проект на годы. И первоначальные затраты времени окупаются сторицей. Я ничего не проповедую, говорю как есть просто. У меня специфика такая, что я за динамическими языками провожу больше времени, мне холиварить вообще не о чем.
Кажется мы тут уже ушли в другую тему «Писать тесты или не писать».
TDD (здесь я имею ввиду не именно TDD, а любые методики написания тестов) не используют в двух случаях, первый случай — это когда не умеют писать тесты, а второй случай когда затраты на тесты не окупятся, т.к. это какой-то одноразовый не критичный код.
У меня в проектах полно тестов, но там нет каких-то специфических тестов связанных с типизацией.
Вот выше в статье например пример с вычислением чисел фибоначи. Чтобы определить, что эта функция работает, статическая типизация никак не поможет. Мы напишем функцию которая будет всегда возвращять ноль и она спокойно скомпилируется Чтобы убедится что функция работает, нужны юнит тесты. А они нам заодно и будут гарантией от очепяток и забытых импортов, в случае динамического языка. Но тут нет никакой разницы можду статическим и динамическим, набор тестов будет один и тот же.
В чем экономия времени. Очень просто.
Вот мы написали тест и функцию. А потом нам понадобилось изменить реализацию, например сделать рефакторинг или оптимизировать по скорости или выпились из кода устаревушю библиотеку. Если тестов нет, то придется заного проходить весь цикл тестирования, а если тесты есть, то этого не требуется.
Про unsafe_string тут опять не понятно, при чем тут типизация.
Вот смотри если ты не используешь TDD то программа у тебя упадет в любом случае, и тут никакая статическая типизация не поможет. А если используешь то очепятка или забытый импорт отловится на этапе запуска тестов.
Кроме того, чтобы допустить очепятку нужно неплохо постараться, быть упертым и уверенно идти к этой цели — игнорировать автодополнение и игнорировать варинги среды разработки.
Да я много слышал подобных рассуждений, от людей которые проповедуют статическую типизацию. На деле таких ошибок почти никогда не происходит. Зато я постаянно вижу стэктрэйсы от всяких API на Яве, в том числе в досаточно серьзеных проектах. Почему-то не спасает их статическая типизация.
Грамотное применение типов может уменьшить число тестов в разы. Зачем мне делать assert(x.length=y.length), если у меня по системе типов в функцию передается список пар [(x,y)]?
Еще раз перечитал. Теперь понял о чем ты.
Но тут вовсе нет разницы, кто тебе мешает в языке с динамической типизацией передать список пар.
Так например работает конструктор dict в питоне — получает список пар (и не обязательно список а любой итерируемый объект). И что неужели тут случются какие-то проблемы?
Если мы передаем два списка произвольной длинны, то в любом случае придется проверить их длинну.
А если список ровно из N элементов, то может быть в этом случае при статической типизации уберется ассерт, но добавятся аннотации.
Не вижу тут явного преимущества.
Статическая типизация сама по себе врядли кого-то волнует.
не нужно писать тесты на такие мелочи, как опечатки,
Статическая типизация не отменяет надобность в написании тестов. Никто не пишет тесты на очепятки, пишут тесты на функции например, если в функции очепятка, то тест не пройдет.
Scenario. The benchmark acts as a WSGI server and performs a GET request directly on each framework's app. Each app parses a route template with a single embedded parameter, reads a query parameter and a header from the request data, sets an x-header on the response, and finally returns a 10 KiB plain-text body, randomly generated.
Бенчмарки хелоу вордлов не показательны. Я вполне могу поверить в эти цифры, но тут меряется не то что следует мерять. Задержки в реальном проекте будут не в интерфейсе между веб сервеом и приложением, а в внутри контроллера приложения, где будет какая-то логика для проекта — например обращние к БД. С учетом этого переписывание проекта с Django на Flask или c Flask на Falcon, не даст хоть сколько нибудь заметного выигрыша в производительности. Сорее всего будет разница до 5-10%. Причем разница будет больше чем больше будет rps, а чем больше в нашем проекте rps, тем меньше нас волнует производительность. Если вас действительно волнует производительность, то для веб проекта в общем случае скорее нужен асинхронный фреймоврк, например Tornado.
Да и вообще это все не показательно. Выбирая микрофреймворки из соображений «производительности» это очевидная преждевременная оптимизациия. Более того, это оптимизация не того, что следует оптимизировать, это не узкое место. Если у вас такой кроутой сайт, что вам пришлось столкнуться с большой нагрузкой, то вы можете выжать сколько угодно rps на любом фреймворке, главное правильно построить архитектуру. А если у вас такой проект, то скорость разработки скорее всего важнее, чем затраты на покупку пары лишних серверов и мучения с отсутствием нужных библиотек в микрофреймворках.
PYTHONPATH это другое, я его никогда не устанавливаю лишь в некоторых случаях для отладки, но и это обычно не нужно, к томуже в питоне есть vitrualenv.
Я пытался понять все это, официальную документацию читал. Но чесно говоря так и не понял, почему я не могу в любой произвольной папке создать и скомпилить программу на go. Допустим у меня есть некий проект на питоне, и вот где-то мне не хватило производительности и я решил переписать какой-то отдельный скрипт на go, почему бы мне хранить эту тулзу в внутри своего проекта. Кажется подход go предполагает, что я на любой чих буду писать какие-то универсальные тулзы или библиотеки. Но мне это не нужно. Допустим у меня есть еще другой проект в котором мне нужна аналогичная тулза с некоторыми отличиями. И вот в воркспесе go у меня появляются уже две тулзы с практически одинаковыми названиями. Тут уже придется добавлять префиксы, в каком проекте это используется.
Прописать запреты в robots.txt это хорошо, но не достаточно. Уязвимость не закрыли, а только, чуток замаскировали.
Переписка рука-лицо.
Недавно же была утечка тысяч контактов с fl.
Ну с таким уровнем технарей и отношением саппорта не удивительно.
Писать команды вида «docker run learn/tutorial apt-get install -y ping» кажется не очень удобно, а ssh не рекомендуется юзать.
С вагрантом все понятно, это удобная обертка для виртуальных машин. Хотя я тоже долго не мог понять зачем он нужен. Потом понял. Скачать образ линукса и подключить к virtualbox не сильно сложная задача, но с вагрантом это делается одной командой из консоли. Очень удобно.
Нажимем ctrl+shift+r и код форматируется.
А еще есть pytest-pep8
Кажется мы тут уже ушли в другую тему «Писать тесты или не писать».
TDD (здесь я имею ввиду не именно TDD, а любые методики написания тестов) не используют в двух случаях, первый случай — это когда не умеют писать тесты, а второй случай когда затраты на тесты не окупятся, т.к. это какой-то одноразовый не критичный код.
У меня в проектах полно тестов, но там нет каких-то специфических тестов связанных с типизацией.
Вот выше в статье например пример с вычислением чисел фибоначи. Чтобы определить, что эта функция работает, статическая типизация никак не поможет. Мы напишем функцию которая будет всегда возвращять ноль и она спокойно скомпилируется Чтобы убедится что функция работает, нужны юнит тесты. А они нам заодно и будут гарантией от очепяток и забытых импортов, в случае динамического языка. Но тут нет никакой разницы можду статическим и динамическим, набор тестов будет один и тот же.
В чем экономия времени. Очень просто.
Вот мы написали тест и функцию. А потом нам понадобилось изменить реализацию, например сделать рефакторинг или оптимизировать по скорости или выпились из кода устаревушю библиотеку. Если тестов нет, то придется заного проходить весь цикл тестирования, а если тесты есть, то этого не требуется.
Вот смотри если ты не используешь TDD то программа у тебя упадет в любом случае, и тут никакая статическая типизация не поможет. А если используешь то очепятка или забытый импорт отловится на этапе запуска тестов.
Кроме того, чтобы допустить очепятку нужно неплохо постараться, быть упертым и уверенно идти к этой цели — игнорировать автодополнение и игнорировать варинги среды разработки.
Да я много слышал подобных рассуждений, от людей которые проповедуют статическую типизацию. На деле таких ошибок почти никогда не происходит. Зато я постаянно вижу стэктрэйсы от всяких API на Яве, в том числе в досаточно серьзеных проектах. Почему-то не спасает их статическая типизация.
Еще раз перечитал. Теперь понял о чем ты.
Но тут вовсе нет разницы, кто тебе мешает в языке с динамической типизацией передать список пар.
Так например работает конструктор dict в питоне — получает список пар (и не обязательно список а любой итерируемый объект). И что неужели тут случются какие-то проблемы?
А если список ровно из N элементов, то может быть в этом случае при статической типизации уберется ассерт, но добавятся аннотации.
Не вижу тут явного преимущества.
Статическая типизация не отменяет надобность в написании тестов. Никто не пишет тесты на очепятки, пишут тесты на функции например, если в функции очепятка, то тест не пройдет.
Можно заменить слово «переписывать» на «выбирать».
Да и вообще это все не показательно. Выбирая микрофреймворки из соображений «производительности» это очевидная преждевременная оптимизациия. Более того, это оптимизация не того, что следует оптимизировать, это не узкое место. Если у вас такой кроутой сайт, что вам пришлось столкнуться с большой нагрузкой, то вы можете выжать сколько угодно rps на любом фреймворке, главное правильно построить архитектуру. А если у вас такой проект, то скорость разработки скорее всего важнее, чем затраты на покупку пары лишних серверов и мучения с отсутствием нужных библиотек в микрофреймворках.
go get не работает вне GOPATH.