1. Какой редактор кода или IDE использовать?

Любой. В комментариях читал, как один Человечище писал код фломастером на обоях. Говорит, очень удобно сворачивать код, прям сматываешь рулончиком.

Попробуйте разные инструменты и остановитесь на удобном для вас. Если вы учитесь программировать — вам не надо vim. Воспользуйтесь VS Code / PyCharm / любым другим популярным инструментом.

2. Какой язык программирования (ЯП) лучший?

Ответ на абстрактный вопрос тоже абстрактный — вообще пофик. Серьёзно. Все языки программирования великолепны. Brainfuck вот есть. Шучу. Если вы спрашиваете этот вопрос, Brainfuck вам пока рано.

Что сделает этот вопрос неабстрактным? Конкретика. Какой ЯП лучше для системного программирования? Какой ЯП лучше для веб-разработки? Какой ЯП лучше для скриптовых задач? Какой ЯП лучше для разработки DevOps инструментов? Какой ЯП лучше для написания 1С приложений? Какой ЯП лучше для поддержки приложения, написанного на Python?

Всё это про то, что под каждую задачу есть свои инструменты. Гвозди забиваем молотком, дырки (отверстия, прости господи, отверстия!) сверлим дрелью. Для iOS пишут на Swift и изучать Python, чтобы писать iOS приложения так себе затейка, прямо скажем.

Степень абстрактности снизилась. Но лучше добавить ещё конкретики. Такой как бюджет на задачу, если мы выбираем ЯП для своего проекта. Такой как наличие или отсутствие под рукой готовых специалистов под тот или иной ЯП. Такой как — что мы хотим делать с полученным кодом, надо ли нам его будет продавать, поддерживать, расширять. Это комплексный большой вопрос.

3. Какой ЯП учить?

И на этот вопрос нет едино верного ответа. Порекомендовать учить популярный ЯП? С одной стороны да, с другой — можно наоборот выучить непопулярный и пойти за кучу денег поддерживать код, написанный десятки лет назад в каком-то банковском решении. Опять же — нужна конкретика, что вы хотите от себя, жизни, ЯП.

Рекомендовать учить первым ЯП скриптовый ЯП, скажем, Python? Найдутся те, кто скажут (и небезосновательно скажут), что лучше будет на старте сразу понять работу компьютера, структур данных, памяти, эффективности программ на более низкоуровневом языке.

Любой ответ не единственно верный.

И с этой точки зрения — какая разница, с чего начать? Начните с питона. Популярный, простой, пишут на нём веб, data science, все скриптовые задачи. Алгоритмы, структуры данных, память и эффективность ПО догоните потом, опять же, если захотите/заставят идти дальше.

4. Мышь или клавиатура?

Мышь, разумеется. Единственный вопрос мироздания с явным однозначным ответом.

5. PHP =  говнокод?

Я писал много-много лет на PHP. Это мой первый ЯП, на котором я писал основательно, и я его люблю. Но не пишу на нём давно. Там взрослый серьёзный ООП, на PHP написано куча кода, проектов, которые еще долго надо поддерживать. Стоит ли начинать свой путь с PHP сейчас? Мой ответ нет. Но PHP не равно говнокод по умолчанию. Хотя возможно количество плохого кода на PHP и больше, чем в других ЯП.

Страшная тайна (которую все знают) — качество кода определяется скиллом разработчика, а не ЯП, на котором код написан. Побьёт каратист боксёра или борец всех заборет? Решает скилл бойца, как бы кому не хотелось услышать что-то другое. А коли боец реально боец, то, занимаясь одним видом единоборств, он будет посматривать и на другие виды, и думать, какие где есть плюсы-минусы и что где можно противопоставить. Так же и с ЯП. Коли вы действительно развиваетесь, то, повторюсь, у вас будет больше одного ЯП со временем в наборе.

Я видел и, хочется верить, иногда писал прекрасный код на PHP.

6. Python = код прекрасней фиалки на рассвете?

Нннннет! Через меня прошло почти 700 студентов на курсе и я прочёл много плохого кода на Python. Я его видел! Он есть, он существует! Это не выдумка! Чесслово! Когда новичок начинает писать код на любом ЯП, он пишет плохой код. Помните? Сначала ползаем, потом ходим, потом бегаем. Сначала надо, чтобы код решал задачу, и только потом (возможно) начинаем задумываться над качеством кода.

Люди, которые только начали ходить, бегают так себе. Люди, которые только начали писать код, пишут его так себе. Это нормально. Но эти люди уже ступили на правильную дорогу и это главное. А дальше, как писал выше — путь саморазвития через работу и перенятие опыта у других. Не боги горшки обжигают.

7. А что вообще важно?

Важно работать, развиваться и не трындеть. И всё будет чётенько. Инфа сотка.

И использовать мышь, конечно.

file_content = file_get_contents("./localfile.txt")
webpage_content = file_get_contents("https://ya.ru")

Удобненько. В Python во всех материалах показывают чтение текстового файла так:

with open("./localfile.txt", "r") as f:
    file_content = f.read()

Больше кода, две строки, табуляция — меньше удовольствия. Однако есть ещё вот такой вариант:

from pathlib import Path

file_contents = Path("./localfile.txt").read_text()

file_contents = Path("./localfile.txt").write_text("some string")

Мне нравится такой вариант. Да, pathlib импортировать надо, но его всё равно часто надо импортировать при работе с путями к файлам. Скажем, во многих материалах для получения склейки пути используется конструкция os.path.join(), то есть, чтобы получить путь "current/file.txt" в *nix или "current\file.txt" в Windows пишут os.path.join("current", "file.txt"). И вот то же самое можно сделать с Path таким образом: Path("current", "file.txt"). Импортировали Path и удобно читаем файл:

import json
from pathlib import Path

from django.conf import settings

users = json.loads(Path(settings.BASE_DIR, "users.json").read_text())

Аналогичное без Path:

import json
import os

from django.conf import settings

with open(os.path.join(settings.BASE_DIR, "users.json"), "r") as f:
    users = json.load(f)

Первый вариант с Path мне нравится определённо больше.

Кстати, можно и так пути склеивать (аналогично будет подставляться правильный разделитель директорий для текущей ОС):

html_path = Path("www") / "html"  # "www/html" in *nix

Вообще в pathlib удобностей много, например:

• Получить текущую директорию: Path.cwd() (от current working directory)
• Проверить существование файла/директории: Path.exists("/home/user/filename")
• Найти все .py файлы в текущей директории на любом уровне вложенности: Path(".").glob("**/*.py")
• Итерироваться по директории: Path("./dir").iterdir()
• Получить родителя директории: Path("/var/www/html/file.txt").parent, результатом будет путь "/var/www/html/". Подняться на 3 уровня вверх: Path("/var/www/html/file.txt").parents[2], результатом будет путь: /var.

Софт для написания и ведения текстовых заметок для меня — это очень важная часть моей жизни. Важнейшая. Надо что-то сохранить, чтобы потом быстро найти? Записал в заметки. Часто требующаяся информация, реквизиты и тп? Записал в заметки. Надо написать сценарий на Youtube или текст поста? Конечно, в заметки. Накидать туториал по настройке какой-то штуки? Привет, заметки. Написать партнёрам схему интеграции с нами? Заметки, расшарить ссылку, готово.

Пользовался долго Evernote, потом Notion, но, как минимум, пользоваться ими сейчас в РФ небезопасно, так как ты не владеешь своими данными, можно проснуться однажды и прочесть новость, что Evernote/Notion/кто угодно принял решение остановить работу с россиянами и заодно удалить к херам собачьим все их данные, потому что как бы ну а чо нет. Рыбаков рассказывал (и у меня нет причин ему не верить), как люди потеряли доступ к своим моделям и чертежам в САПРах, которые лежали в корпоративных облаках. Вжух и результаты многолетней работы испарились:)

Поэтому сейчас надо хранить важные данные локально. Заметки — Markdown файлы, для синхронизации которых можно использовать, например, git или Syncthing. Такие файлы можно писать и читать в любом текстовом редакторе, абсолютно любом.

Но — хочется ведь удобно. Чтобы эстетически приятно. Чтобы шрифты кириллические и английские нормально работали и тп.

И я вчера потратил много времени, перебирая разные варианты. Typora, iA Writer, Zettlr, Bear, Ulysses и много других. Лучший вариант с гигантским отрывом — Obsidian. Вообще эта программа позиционируется для ведения картотеки по модной нынче методологии Zettelkasten, но это всё опционально. У Obsidian просто есть всё нужное лично мне и оно отлично работает.

Фичи

Vim-mode включается просто из настроек без плагинов:)

Много тем. Я поставил тему Minimal и светлый вариант интерфейса, на первом скриншоте выше.

Корректно работающая подстветка синтаксиса разных языков программирования в блоках с кодом!

Экспорт заметки в опрятно и приятно выглядящий PDF документ, который можно отправить кому-то файлом.

Структура заметок — любая, хоть плоская, хоть сам разнеси по папкам, хоть по тегам. Заметки можно связывать друг с другом, образуя граф (это для картотеки, кому нужно — я пока не планирую строить именно картотеку).

Директориями и md файлами можно управлять удобно из командной строки инструментами *nix или любыми скриптами, скажем, Python. Если понадобится с файлами пакетно что-то сделать — да пожалуйста. Всё в твоих руках.

Так заметки это просто текст, который индексируется в том числе родным инструментом Mac OS, заметки можно искать просто в Spotlight!

Есть поиск заметок и в Obsidian и он отлично работает.

Синхронизируй заметки как угодно, например, с помощью Syncthing.

Много настроек, реально много настроек.

Работает на Electron, но работает хорошо — быстрый запуск, есть hotkeys, не вижу тормозов (во всяком случае пока).

Есть мобильное приложение.

Очень доволен. Буду переносить заметки сюда.

Тормознуть на улице бегущего куда-то человека и неторопливым тоном начать грузить: «Извини, что отвлекаю, но тут такое дело, вопрос очень важный, прошу понять, тут просто дело в том, что мне написала тетя Маша и попросила привезти варенье, она просто очень любит варенье, ну вы знаете про варенье, да? Такая сладкая вкусная штука. Ну вот, и она в общем варенье попросила привезти, клубничное. Она любит. Клубника, говорит, ваще полезная, хорошая, мы, кстати, на даче выращиваем. У нас дача тут в соседнем регионе, там прям хорошо. Птички летом поют, клубничка опять же. Ну вот. И тетя Маша, она на улице Ленина живёт вроде, хотя я чёт и не уверен. Подскажите, пожалуйста, вы тетю Машу не знаете? Нет? Ну плоооохо! Ну а хотя бы где тут улица Ленина?»

Такой монолог вывалить прохожему — это ненормально. Почему?

1. Тонна лишней информации. Зачем человеку знать ее? Это упрощает или усложняет ему жизнь, увеличивает или уменьшает желание помочь?
2. Долго. Вопрошающий не ценит время собеседника, проявляя тем самым к нему неуважение.
3. Как сделать помощь вам легкой? Посмотреть самому на карте, где улица Ленина, и спросить стоящего на светофоре человека, не бегущего сейчас, короткий вопрос: «Подскажите, а улица Ленина это вот за тем домом, да?»

Помочь с кодом

Если вы просите помочь с кодом — сделайте так, чтобы помочь вам было легко. Если ваш вопрос про вот эти 3 строки кода, незачем отправлять человеку проект на сотни строк кода. Зачем ему это знать? Никто не захочет вникать в то, что является лишним.

Потрудитесь потратить время, сформулировав свой вопрос предельно чётко и понятно, сделайте всё возможное, чтобы помогающему было предельно очевидно, что вы спрашиваете.

Потрудитесь, чтобы смысл кода был понятен. Подумайте над именованием переменных в коде. Отформатиуйте его нормально.

def pv(v, p):
    if p == "f":
        return v >= 56.5
    elif p == "m":
        return v>= 61.5

Вы действительно думаете, что кто-то захочет в этом копаться? Это только вы обладаете тайным знанием, что pv — это (внезапно!) пенсионный возраст, v это возраст, а p это пол.

Вот так — не будет ли проще помогающему понять, о чём тут речь?

from typing import Literal

def is_person_retiree(age_years: int, sex: Literal["f", "m"]):
    if sex == "f":
        return age_years >= 56.5
    elif sex == "m":
        return age_years>= 61.5

Да, надо подумать. Возможно залезть в русско-английский переводчик. Натыкать больше буковок на клавиатуре. Жизнь боль.

Дайте необходимую информацию

Информации, которую вы дали, должно быть ровно столько, сколько нужно. Если вопрос про 3 строки кода — незачем давать из 500. Но с другой стороны — 2 строки будет мало, и 1 мало. Вопрос по трем, дайте три.

Лишняя информация не нужна. Необходимая информация нужна. Потрудитесь отделить одно от другого и дать всё нужное и не больше.

Голосовые сообщения

Отправить голосовуху с вопросом незнакомому человеку — это из той же серии. Слушать 2 минуты охи-вздохи-чавки или прочесть 3 строки четкого вопроса текстом — что увеличит шанс, что вам ответят?

Голосовуха вообще это хоть как-то может быть оправдано в единственном варианте, когда руководитель что-то просит сделать своего сотрудника и пишет голосовуху. Потому что время руководителя дороже времени сотрудника. Возможно для родных или старых друзей это допустимо.

А когда вы пишете незнакомому человеку вопрос/просьбу голосовухой, то, получается, что вы свое время цените сильнее, чем время того, кого просите о помощи. Когда мне такое приходит, я не ленюсь кидать в ЧС сразу. Умного это чему-то научит, глупый пусть обижается.

«+»

Или вот, пишет человек с вопросом. Было время почитать, пока ждал заказ в кафе. Ответил ему уточняющим вопросом, он мне в ответ прислал, цитата, «+». Плюсик. То есть я нашел время прочесть его 5 абзацев текста, задать 2 уточняющих вопроса, а вопрошающий не нашел времени, чтобы хотя бы написать «да» вместо «+»?

Сразу к делу

https://nometa.xyz/

Отвратительнейшее начало диалога с незнакомым человеком: «Привет, можно спросить?». Просто потеря времени, см. ссылку выше. Надо писать сразу по делу. «Привет, слушай, а как правильно сделать ____? Прочел много статей уже, но что-то никак не могу разобраться. Буду благодарен, если кинешь ссылкой.»

И без лишней информации. Только то, что относится напрямую к вопросу, кратко и по сути.

Сначала сам

Или пишут, условно — а у меня машина не едет. Ты задаешь тысячу уточняющих вопросов типа есть ли бензин (да вроде есть), не украли ли колеса (да ну не должны были) и тп, и через пол часа выясняется, что у человека и машины-то нет, потому и не едет. Не надо так. Надо сначала провести какую-то умственную работу самому, прежде чем других грузить своими проблемами.

Есть вопрос? А в гугл ходил за решением, точно ходил? А сколько времени за поиском и чтением ссылок в гугле провел, 30 сек или 5 часов?

Очевидно, что сначала надо проработать свой вопрос самому, и только потом обратиться за помощью к кому-то, кто абсолютно негарантированно, но возможно таки поможет. Если общаться умеете и спрашивать.

На самом деле очень много можно уложить в применение этих подходов.

Декларативный подход — вы декларируете то, что вам надо, не погружаетесь в детали реализации.

Если переносить это на программирование, то, скажем, задачу распарсить некий запрос на заголовок, содержащий только первую строку, и оставшееся тело запроса, можно разными способами. Можно так — даже не вынося эту логику парсинга в отдельную функцию, разместя её в составе какой-то большей функции обработки запроса:

def process_client_request(request: str):
    """какой-то длинный код тут..."""
    """teletype.in не умеет в комменты с символа диеза..."""
    delimeter_position = request.find("\n")
    header = request[:delimeter_position]
    body = request[delimeter_position:]
    """и потом тоже какой-то длинный код..."""

Грустно? Ну невесело. Много сложного кода. Какие-то индексы находятся, слайсы по ним ищутся. Там, где сложный код — больше вероятность ошибок, сложнее поддерживать код, дольше, дороже, неприятнее.

Когда мы с find ищем позицию в строке какой-то подстроки — то непонятно, зачем мы это делаем. Может, мы хотим проверить вхождение подстроки в строку. Может, мы хотим обрезать строку. Может, хотим разбить её. Может ещё что-то. Чёрт его знает, надо читать окружающий код, чтобы понять нас. Это сложно. Надо думать. Думать — тяжело.

Так лучше:

def process_client_request(request: str):
    """какой-то длинный код тут..."""
    header, body = request.split("\n", 1)
    """и потом тоже какой-то длинный код..."""

А почему так лучше?

Потому что split это понятный метод разбивки строки на подстроки, это декларативный подход, скрывающий реализацию. Это — декларативно и просто, и думать не надо, чтобы понять, что в коде происходит.

А можно ещё проще, ещё декларативнее:

def parse_request(request: str) -> tuple[str, str]:
    return request.split("\n", 1)

def process_client_request(request: str):
    """какой-то длинный код тут..."""
    header, body = parse_request(request)
    """и потом тоже какой-то длинный код..."""

Кода стало больше — но код стал лучше.

1. Читать стало проще, приятнее, понятнее. Читая строку header, body = parse_request(request), мы понимаем, что тут происходит. Тут происходит парсинг запроса, а как именно он там этот парсинг происходит сие есть дело десятое, при желании можно перейти в вызываемую функцию и почитать.
2. Ещё один плюс — возможность переиспользовать parse_request ещё где-то.
3. И ещё один — если задача изменится и нам надо будет парсить запрос как-то иначе, нам не надо будет искать этот код где-то в дебрях другого кода, он лежит себе отдельно в своей отдельной маленькой великолепной функции.

Прекрасно.

А если ещё dataclass или NamedTuple вместо tuple использовать для распаршенного запроса — так вообще будет песня:)