aarifkhamdi

От одного до бесконечности.

Не забываем про документацию

PS.
Это какая-то дичь

import tkinter as tk
from tkinter import *

Проще объясню.
Предположим, гипотетическая ситуация, которой обычно объясняют зачем тебе Облако. - Есть у тебя интернет-магазин плюшевых мишек. Развернул ты сайт у себя на компьютере , который стоит в офисе в кладовке, и все хорошо, посещение сайта 1000 пользователей в день, продаешь ты свои 5 мишек в день, никаких проблем.
Но тут надвигается 8 марта, и посещаемость сайта увеличивается до 5000 в час и твой компьютер не вывозит ни по процессору, ни по диску, ни по оперативной памяти, ни по пропускной способности интернет канала, службы обрабатывающие HTTP запросы все время отваливаются, интернет-канал забит, жесткий диск молотит, но все происходит все очень медленно, а ты на этом компе еще Z отчет кассовый делаешь в конце дня, а в соседнем цехе усиленно пекли печеньки с предсказаниями в глазури, автомат в ВРУ не выдержал, и отключился вместе со всем зданием и твоим компом. ПО итогу ты к 8му марта продаешь всего 3 медведя, да и еще кассовый отчет для налоговой не сгененрировал. После подобного факапа, ты себе говоришь: "ну на следующий праздник я так не облажаюсь". Выделяешь в офисе помещение под серверную, ставишь серверную стойку, покупаешь 4 сервера полноценных и распараллеливаешь инет запросы, новая система хранения данных, источник бесперебойного питания, 2 кондиционера и интернет канал расширяешь. Итогом к 8му марта следующего года, эта конфигурация выдерживает возросшую нагрузку и ты продаешь 45 медведей к 8му марта, профит ? А вот и нет, вся эта конфигурация нужна тебе в преддверии 8го марта, а остальные, предположим 360 дней, тебе бы хватало однго старого компьютера. А серверная потребляет только электричества на 500 руб в день, а интернет канал, и обслуживание серверов итого дороже!

Так вот в облаке можно арендовать эти мощности на несколько дней, пока идет самый сенокос, а остальные дни довольствоваться слабенким виртуальным сервером за 300 руб в день.

Можем ли мы быть уверены, что в следующей конструкции обновление обязательно произойдет (считаем что SELECT вернул какие-то данные)?

Нет, не можем.
Два конкурентных запроса могут увидеть одни и те же версии строк в cte (не пересекутся на читающих блокировках даже с конкурентными писателями т.к. mvcc) и затем пойдут обновлять одни и те же строки. На блокировках обновления строк их транзакции и сериализуются. Кстати, можно и deadlock словить если строк к обновлению будет несколько и они вернутся из запроса в разном порядке.

приостановить запрос и посмотреть что будет, если произойдет X?

gdb может приостановить всё что угодно. Правда далее уже интересный момент что надо найти куда именно break point ставить.

1) На Python пишут без фреймворка под какие-то узкие, высоконагруженные и уникальные задачи. И компаний, где это реально нужно, можно пересчитать по пальцам.

2) Во всех остальных случаях практично, логично и разумно взять django/flask/aiohttp, либо если проект совсем петовский, какой-то менее популярный микро-фреймворк.

Писать прямо все самому...ну в книгах по python есть примеры, как это делается и что используется, но нафига!

Никогда не называйте файлы своего проекта так же как и импортируемые модули

asyncio.py действительно не имеет никакого run

Лол, никогда не будет таких курсов, потому что не будет трудоустройства.
Это ответ.

ОС чаще всего пишут на низкоуровневых языках, вроде C (Linux, FreeBSD), C++ (Windows), Rust (Redox). Иногда используют ассемблерные вставки.

Игры (имеются в виду 3D игры) чаще всего пишут на C++, но так же возможно на C# (Unity), JS (Unity или что-то упрощающее работу с WebGL). Хотя могут быть и другие языки (например майнкрафт написан на JAVA, а старый добрый Doom - на C). Так же понадобится язык шейдеров для программирования видеокарты, например для OpenGL и WebGL таким языком является GLSL.

Прикладной софт вообще пишется на чем угодно, выбор языка зависит от задачи. Но в некоторых сферах все же можно выделить лидеров:
Энтерпрайз решения - Java EE, реже C#
Десктопный софт под Windows - C# (реже другие языки .net платформы)
Десктопный софт под MacOS - Swift
Десктопный софт кросплатформенный - Java, Python, JS (Electron)
Мобильный софт под Андроид - Kotlin, Java
Мобильный софт под iOS - Swift
Мобильный софт кросплатформенный - C# (Xamarin), JS (Cordova, ReactNative, etc.)
Серверный софт - php, Python, Ruby, JS (node), Java, Go, Rust, ... вариантов много
Браузерный софт - JS или то что компилится в JS (чаще TypeScript)

Современные фреймворки вроде Angular/React/Vue созданы для решения одних и тех же задач. Использовать лучше тот, который больше нравится и который лучше знаете. При неумелом использовании все преимущества конкретного фреймворка меркнут, и на Vue, в таком случае, вы можете получить медленную скорость разработки, а на React неподдеживаемый код.

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

Вы добавляете контент после инициализации скрипта sdk. Естественно у вас ничего не работает.
Изучайте sdk, у них должен быть способ доступа к глобальному объекту и метод для повторного парсинга страницы. Если это можно сделать только через хук инициализации, то придется диспатчить кастомные события.

На github есть обертка react-facebook. Возможно, она вам подойдет.

shop.oreilly.com/product/0636920032519.do

Если что-то работало в одной версии и перестало в другой - можно сделать бисекцию и проверить, в каком коммите оно отвалилось