Я не вижу, чем это проще, нежели организовать код правильно, чтобы запись файлов осуществлялась внутри транзакции БД. Вы предлагаете дополнить проект новыми сущностями, при том, что по итогу гарантий это дает даже меньше.
Это может быть опасно, поскольку неизвесно, сколько точно должна длиться загрузка. Лимитов на размер файлов тут нет, теоретически пользователь может из тайги по GPRS 100-гиговый рип "аватара 2" качать. А если автор запилит еще и возобновление загрузки после обрыва соединения, то вообще.
Это обертка, насколько я помню, над тред-пулом. То есть реальной кооперативной многозадачности там нет, только ее видимость. Альтернатив, к сожалению, не знаю.
Что будет, если в процессе загрузки данных в файл выключится электричество на сервере? На диске окажется битый файл, а в БД о нем записей не будет. Со временем при постоянном пользовании сервисом такие файлы неизбежно будут возникать и накапливаться. Одно из возможных решений - писать в файл внутри транзакции БД. Но это порождает риск долгих транзакций, от которого можно избавиться, если хранить не файлы целиком, а чанки (также это может частично решить проблему с фрагментацией диска).
await request.content.read() будто бы таки считывает файл в память полностью, после чего уже записывает на диск. То есть не соблюдается главная гарантия вашего сервиса - что он не держит файлы в памяти целиком.
aiofiles - немного сомнительная библиотека.
Не вижу возможности параметризовать сервис при помощи переменных окружения.
Нет возможности запуска в контейнере.
Инициализация движка БД выглядит странно. Если по итогу все равно создается глобальная переменная, зачем это пихать в функцию?
Дней лет наших — семьдесят лет, а при большей крепости — восемьдесят лет; и самая лучшая пора их — труд и болезнь, ибо проходят быстро, и мы летим. Псалтирь 89:10
С ростом продолжительности жизни есть некоторые проблемки. Те графики, на которые обычно указывают имморталисты, обычно иллюстрируют лишь уменьшение младенческой смертности. Именно этому фактору мы обязаны резким увеличением продолжительности, к примеру, в России за последние 20 лет. Но мертвые младенцы, уж простите мне мой французский — ограниченный ресурс, рано или поздно их количество будет сведено до нуля, ну или до возможного минимума.
Если мы посмотрим на динамику ожидаемой продолжительность жизни 45-летнего человека за последние примерно 50 лет, мы увидим для развитых стран рост всего примерно на 5 лет. При всех хваленых достижениях науки и медицины за это время, включая прорывы в лечении рака, пересадку органов, новейшие формы антибиотиков и наличие дефибрилляторов на стенах в общественных местах, повальную вакцинацию. 5 лет за 50 лет, причем кривизна графика совсем не выглядит нарастающей, поэтому вряд ли стоит ожидать роста более чем на 10 лет за ближайшие 100 лет. Лично я полагаю даже эту оценку преувеличенной, поскольку она исходит из того, все плоды в области продления жизни висят примерно на одной высоте, в то время как опыт подсказывает, что сначала срываются самые низковисящие, а далее по мере роста высоты висения плода частота их срывания уменьшается. Иначе говоря, приводящие к значимому росту продолжительности жизни открытия будут, вероятно, совершаться все реже и реже. Кроме того, рост продолжительности жизни до сих пор сопровождался ростом доли населения, работающей в медицине. Но рано или поздно, этот рост также обязан будет прекратиться, просто потому, что в этом показателе нельзя прыгнуть выше 100%.
Если опустить главную предпосылку автора и посмотреть на саму идею, тут тоже видятся несколько вопросов.
Во-первых, не очевидно, как именно орбитальная станция решает проблему сверхновых, о которой как об одной из угроз упоминает сам автор.
Во-вторых, на орбите, пусть и не сильно, но увеличивается воздействие космического излучения. На масштабе тысячелетий (если мы просто примем рост продолжительности жизни до таких величин за данность) это должно оказывать значимое воздействие на вероятность всяких неприятностей со здоровьем.
В третьих, по-прежнему не очевидно, как переезд на орбитальные станции решает проблему, которую исходно решал Маск — монопланетарность нашего вида. Орбитальные станции все равно крутятся вокруг одной планеты, и смерть планеты означает смерть обитателей станции, пусть и отсроченную.
В четвертых, пусть об этом уже и писали выше, но все же продублирую — жизнь на орбитальной станции не понижает, а повышает астероидную угрозу. Вы начинаете ловить собою те астероиды, которые до вас бы не долетели, будь вы на поверхности Земли, т.к. они сгорели бы в атмосфере. Причем каждый пойманный астероид принесет вам гораздо больше повреждений. Никакие лазеры тут не помогут даже теоретически, да и увороты от астероидов огромной миллионтонной станции мне представляются с трудом.
В пятых, не понятно, как ракеты Маска должны помочь нам построить гигантскую станцию. Есть причины, по которым современные станции выглядят так, как выглядят. Их строят из цилиндров, диаметр которых соответствует диаметру ракет, которыми их доставляют. И этот принцип вряд ли когда-то получится обойти. Да, ракеты Маска, возможно, помогут увеличить количество этих цилиндров (на самом деле — еще большой вопрос), но принципиальная схема космической станции останется примерно той же — кучка состыкованных цилиндров. Более крупные проекты станций вроде тех, что мы видели в фильмах вроде Элизиума требуют принципиально иного подхода к геометрии доставляемых на орбиту блоков и скорее всего не реализуемы никакими технологиями, являющимися максимизацией возможностей текущих (более совершенные ракеты на ископаемом топливе, и т.д.).
Есть и куча других проблем, возникающих по мере увеличения орбитальной станции. Я не думаю, что их всех имеет смысл пытаться здесь перечислять, хотя бы потому, что человечество в его текущем состоянии находится на грани способности поддерживать на орбите даже одну убогую космическую станцию вроде МКС. Реалистичность даже постройки второй такой же станции сегодня под большим вопросам, а мы тут всякие элизиумы обсуждаем.
Это полезное дело, но я бы добавил как минимум реализации базовых алгоритмов поиска кратчайших путей (дейкстру, А* и более сложные) и максимальных потоков, если библиотека претендует на универсальную полезность.
Ну и код, на мой взгляд, следует делать более "общим". В частности, функции поиска должны принимать не конкретные значения для сравнения, а другие функции, которые внутри себя сами способны определить искомые вершины. Ну и сами вершины тоже можно сделать более универсальными, храня внутри них только указатели на любые структуры данных. Также более универсальными можно сделать связи. Дело в том, что связи могут хранить и другие атрибуты, кроме "веса".
Кроме того, я вижу, что вы используете флаги посещенности для вершин. Такой подход не масштабируется на более чем 1 поток. Существует альтернативный вариант - при обходах создавать в каждом потоке по независимому стеку посещенных вершин. У вашего способа тоже есть свои плюсы, поэтому идеальная библиотека, по-моему, должна отдавать выбор пользователю. При инициализации графа он должен иметь возможность выбрать то, как будет храниться информация о посещенных вершинах.
И последнее, я рекомендую уделить больше внимания тестам вашего кода.
Только непонятно, как это ускоряет изучение английского? В изучении языка очень мало абстракций, то есть ситуаций, когда можно выделить "основную мысль" и затем ее развернуть. Изучение языка по большей части - запоминание мелких атомарных фрагментов чего-либо + навыки вроде распознавания речи на слух.
Я был примерно на 2-3 сотнях собеседований. Из них наличие у меня гитхаба (довольно активного) замечали ну может раз 5, и ни разу это не было решающим фактором в решении об оффере, по крайней мере мне никто не признавался.
Допустим, в сообщении число. Как оно будет сериализовано?
А как еще могут сериализоваться примитивные типы с помощью pydantic, кроме как через json?
То есть pydantic умеет работать, к примеру, с protobuf? Не слышал про такое.
А как быть, если сообщения не в формате json?
Я не вижу, чем это проще, нежели организовать код правильно, чтобы запись файлов осуществлялась внутри транзакции БД. Вы предлагаете дополнить проект новыми сущностями, при том, что по итогу гарантий это дает даже меньше.
Это может быть опасно, поскольку неизвесно, сколько точно должна длиться загрузка. Лимитов на размер файлов тут нет, теоретически пользователь может из тайги по GPRS 100-гиговый рип "аватара 2" качать. А если автор запилит еще и возобновление загрузки после обрыва соединения, то вообще.
Это обертка, насколько я помню, над тред-пулом. То есть реальной кооперативной многозадачности там нет, только ее видимость. Альтернатив, к сожалению, не знаю.
В целом сервис выглядит хорошо, но:
Не хватает тестов.
Не предусмотрены репликация / шардирование.
Что будет, если в процессе загрузки данных в файл выключится электричество на сервере? На диске окажется битый файл, а в БД о нем записей не будет. Со временем при постоянном пользовании сервисом такие файлы неизбежно будут возникать и накапливаться. Одно из возможных решений - писать в файл внутри транзакции БД. Но это порождает риск долгих транзакций, от которого можно избавиться, если хранить не файлы целиком, а чанки (также это может частично решить проблему с фрагментацией диска).
await request.content.read()будто бы таки считывает файл в память полностью, после чего уже записывает на диск. То есть не соблюдается главная гарантия вашего сервиса - что он не держит файлы в памяти целиком.aiofiles- немного сомнительная библиотека.Не вижу возможности параметризовать сервис при помощи переменных окружения.
Нет возможности запуска в контейнере.
Инициализация движка БД выглядит странно. Если по итогу все равно создается глобальная переменная, зачем это пихать в функцию?
Можно использовать polog в асинхронном режиме.
С ростом продолжительности жизни есть некоторые проблемки. Те графики, на которые обычно указывают имморталисты, обычно иллюстрируют лишь уменьшение младенческой смертности. Именно этому фактору мы обязаны резким увеличением продолжительности, к примеру, в России за последние 20 лет. Но мертвые младенцы, уж простите мне мой французский — ограниченный ресурс, рано или поздно их количество будет сведено до нуля, ну или до возможного минимума.
Если мы посмотрим на динамику ожидаемой продолжительность жизни 45-летнего человека за последние примерно 50 лет, мы увидим для развитых стран рост всего примерно на 5 лет. При всех хваленых достижениях науки и медицины за это время, включая прорывы в лечении рака, пересадку органов, новейшие формы антибиотиков и наличие дефибрилляторов на стенах в общественных местах, повальную вакцинацию. 5 лет за 50 лет, причем кривизна графика совсем не выглядит нарастающей, поэтому вряд ли стоит ожидать роста более чем на 10 лет за ближайшие 100 лет. Лично я полагаю даже эту оценку преувеличенной, поскольку она исходит из того, все плоды в области продления жизни висят примерно на одной высоте, в то время как опыт подсказывает, что сначала срываются самые низковисящие, а далее по мере роста высоты висения плода частота их срывания уменьшается. Иначе говоря, приводящие к значимому росту продолжительности жизни открытия будут, вероятно, совершаться все реже и реже. Кроме того, рост продолжительности жизни до сих пор сопровождался ростом доли населения, работающей в медицине. Но рано или поздно, этот рост также обязан будет прекратиться, просто потому, что в этом показателе нельзя прыгнуть выше 100%.
Если опустить главную предпосылку автора и посмотреть на саму идею, тут тоже видятся несколько вопросов.
Во-первых, не очевидно, как именно орбитальная станция решает проблему сверхновых, о которой как об одной из угроз упоминает сам автор.
Во-вторых, на орбите, пусть и не сильно, но увеличивается воздействие космического излучения. На масштабе тысячелетий (если мы просто примем рост продолжительности жизни до таких величин за данность) это должно оказывать значимое воздействие на вероятность всяких неприятностей со здоровьем.
В третьих, по-прежнему не очевидно, как переезд на орбитальные станции решает проблему, которую исходно решал Маск — монопланетарность нашего вида. Орбитальные станции все равно крутятся вокруг одной планеты, и смерть планеты означает смерть обитателей станции, пусть и отсроченную.
В четвертых, пусть об этом уже и писали выше, но все же продублирую — жизнь на орбитальной станции не понижает, а повышает астероидную угрозу. Вы начинаете ловить собою те астероиды, которые до вас бы не долетели, будь вы на поверхности Земли, т.к. они сгорели бы в атмосфере. Причем каждый пойманный астероид принесет вам гораздо больше повреждений. Никакие лазеры тут не помогут даже теоретически, да и увороты от астероидов огромной миллионтонной станции мне представляются с трудом.
В пятых, не понятно, как ракеты Маска должны помочь нам построить гигантскую станцию. Есть причины, по которым современные станции выглядят так, как выглядят. Их строят из цилиндров, диаметр которых соответствует диаметру ракет, которыми их доставляют. И этот принцип вряд ли когда-то получится обойти. Да, ракеты Маска, возможно, помогут увеличить количество этих цилиндров (на самом деле — еще большой вопрос), но принципиальная схема космической станции останется примерно той же — кучка состыкованных цилиндров. Более крупные проекты станций вроде тех, что мы видели в фильмах вроде Элизиума требуют принципиально иного подхода к геометрии доставляемых на орбиту блоков и скорее всего не реализуемы никакими технологиями, являющимися максимизацией возможностей текущих (более совершенные ракеты на ископаемом топливе, и т.д.).
Есть и куча других проблем, возникающих по мере увеличения орбитальной станции. Я не думаю, что их всех имеет смысл пытаться здесь перечислять, хотя бы потому, что человечество в его текущем состоянии находится на грани способности поддерживать на орбите даже одну убогую космическую станцию вроде МКС. Реалистичность даже постройки второй такой же станции сегодня под большим вопросам, а мы тут всякие элизиумы обсуждаем.
Так это по старому стилю.
Последняя ссылка на предзаказ не активна.
Это полезное дело, но я бы добавил как минимум реализации базовых алгоритмов поиска кратчайших путей (дейкстру, А* и более сложные) и максимальных потоков, если библиотека претендует на универсальную полезность.
Ну и код, на мой взгляд, следует делать более "общим". В частности, функции поиска должны принимать не конкретные значения для сравнения, а другие функции, которые внутри себя сами способны определить искомые вершины. Ну и сами вершины тоже можно сделать более универсальными, храня внутри них только указатели на любые структуры данных. Также более универсальными можно сделать связи. Дело в том, что связи могут хранить и другие атрибуты, кроме "веса".
Кроме того, я вижу, что вы используете флаги посещенности для вершин. Такой подход не масштабируется на более чем 1 поток. Существует альтернативный вариант - при обходах создавать в каждом потоке по независимому стеку посещенных вершин. У вашего способа тоже есть свои плюсы, поэтому идеальная библиотека, по-моему, должна отдавать выбор пользователю. При инициализации графа он должен иметь возможность выбрать то, как будет храниться информация о посещенных вершинах.
И последнее, я рекомендую уделить больше внимания тестам вашего кода.
Актуальная тема.
Такая же тема, 1 в 1.
Только непонятно, как это ускоряет изучение английского? В изучении языка очень мало абстракций, то есть ситуаций, когда можно выделить "основную мысль" и затем ее развернуть. Изучение языка по большей части - запоминание мелких атомарных фрагментов чего-либо + навыки вроде распознавания речи на слух.
Редкий случай, когда статья оказалась лучше, чем то, что я ожидал, исходя из названия.
Я был примерно на 2-3 сотнях собеседований. Из них наличие у меня гитхаба (довольно активного) замечали ну может раз 5, и ни разу это не было решающим фактором в решении об оффере, по крайней мере мне никто не признавался.
Не знал, что у этого есть название. А вы можете посоветовать готовые хорошие средства автоматизации такой работы?
Но ведь жсоны чаще имеют древовидную структуру, чем шахматовидную.