DjangoBB LoFi version

Начало » Центр помощи » ДОПОМОЖІТЬ БУДЬ ЛАСКА

1 2 3 4

py.user.next

Май 8, 2021 15:10:07

Думаю, у тебя идёт смесь разных тем при изучении. Это якобы экономит время обучения и тому подобное. Из-за этого ты не можешь ни одну из них полностью изучить, так как другие темы мешают. Это вредно потому, что будешь изучать всё и будешь знать всё это поверхностно. Тебя спросят Гит, ты его функции поверхностно назовёшь, а глубже ты не знаешь. Тебя спросят IDE, ты её функции поверхностно назовёшь, а глубже ты её не знаешь. Тебя спросят про тесты, ты их поверхностно назовёшь, а глубже ты их не знаешь. Тут понятие “спросят” означает, что они тебе понадобятся где-то, а понятие “не знаешь” означает, что ты не сможешь продвинуться в каком-то деле. Это как знать половину таблицы умножения только. Это нормально и экономит память и время изучения очень классно на первый взгляд, но когда сталкиваешься с примерами в старших классах, молишься, чтобы там сложных цифр не было из той части таблицы умножения. И когда они там появляются, ты пример решить не можешь, хотя знаешь, как он решается вообще. А проблема в том, что ты не можешь перемножить числа, а калькулятор сломался или забыт дома. Вот какая-нибудь мелочь затормозит тебе весь процесс.
Пример:
Не знаешь, как какие-то ветки слить в Гите - и придётся весь проект многогодичный выбрасывать, придётся его превращать в сегодняшний, сделанный за один день. Естественно, вся история улетела, все многостраничные описания в коммитах улетели. Вот Линус Торвальдс любит по несколько страниц в одном коммите написать ценной информации всякой. Сидишь, читаешь один коммит полдня. Вот это всё может пропасть только из-за незнания того, как в Гите что-то там выдрать из проекта. Мне так пришлось один проект переначинать свой. По неопытности туда пароль занёс и вырезать его так и не смог из структуры репозитория через пару прошедших лет. Гит просто отказывался выполнять операцию по переделке этих деревьев. Там нужно было сам коммит раскладывать на части, так как он таким, собранным объектом является из разных кусочков, потом переделывать содержимое, а потом это обратно собирать и закоммичивать этот видоизменённый коммит заново. А чтобы выполнить эту операцию, нужно было более глубокое понимание Гита, которого у меня не было тогда, больше всяких знаний. И времени на это не было, чтобы всё это изучать сидеть. Пришлось всю эту историю проекта коммитов на триста со всеми объяснениями в коммитах (где, что и почему делал) удалить, а потом создавать проект типа “здрасьти, я проект, сделанный за один день”. Просто историю проекта не проследишь. А в коммитах бывают многие мысли про плюсы и минусы решений.
Почитай просто какой-нибуд репозиторий типа линуксового ядра, там много всякой инфы в коммитах. Там же и учишься их писать правильно

, потому что многие ребятки ничего умного выдавить из себя не могут, только “пофиксил баг” или “добавил файл”. Очень часто такие говнорепозитории можно увидеть на GitHub'е. Человек пишет библиотеку или ещё что-нибудь, а работать с ним вместе бессмысленно, так как у него мозгов нет, чтобы просто объяснить, что он делает, и по коммитам его это очень хорошо видно. Так он и заканчивает обычно - с дохлым проектом, который никому не нужен, потому что никто не будет разбираться, как он там работает.

Ocean
Я хочу для практики тесты и к простым писать сейчас, чтобы навык до автоматизма довести и библиотеку освоить хорошо, и кейсы уметь годные.

Да хочется всё и сразу. Не, может показаться, что это простая тема. Но это не простая тема. Там за этим стоит математика. И чем лучше ты видишь эту математику за тестами, тем чище у тебя тесты. Тесты тоже можно дерьмово написать. Наличие тестов ни о чём не говорит. Они банально могут нихера не проверять. Тесты есть, они пишут, что всё окей, а там дрова. Мало ли что они пишут.

Поэтому будешь плохие тесты писать. Вот как задачи решаешь “я решила! я решила! у меня всё написано!”, вот так же и тесты будешь писать “у меня всё правильно! у меня всё правильно! у меня тесты показывают OK везде!”.

Ocean
Я так с гитом работать училась и с виртуальными окружениями. Коммитила всякую фигню, чтобы последовательность действий до автоматизма запомнилась и я в ступор не впадала при необходимости

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

То есть изучать и тесты, и Гит в одно и то же время - ну, такое. Это как взять с собой в бассейн велосипед. Можно же ехать по дну бассейна на велосипеде и заодно руками там разные стили плавания осваивать. Так ты научишься ездить без рук на велосипеде и потренируешься плавать разными стилями. Ага. Ну, кажется так-то логично всё. А ещё виртуальное окружение, конечно же, как мы про него забыли. Добавим ко всему этому акваланг ещё. Дело же как раз на глубине будет происходить и там можно аквалангизму поучиться.

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

Ocean
Я сначала писала ну как давно на паскале учили, не вникая особо в нейминги

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

Ocean
Тут сразу спрошу, раз речь про доки зашла: я уже тренируюсь докстринги писать. Чтобы нарабатывать навык, а не потом страдать, как с именами. Это рано еще?
Примерно в таком духе:
  
def cube_lateral_area(edge):
    """Calculate area of a cube lateral surface using cube's edge size
 
    :argument: edge(int): size of cube edge
    :return: (int): a cube lateral surface area
    """
    return 4 * edge **2

Этот стиль пришёл с Java. Java - это другой язык. Он по-другому сделан, поэтому тащить что-то из Java в Python не надо. В Java нужно всегда знать, какой у тебя тип там передаётся или возвращается. А в Python не надо никогда знать про то, какой тип передаётся или возвращается. Поэтому вот этот стиль сделан под IDE, под Java-программистов, которым без типов ничего не понятно, под что угодно. Но к питону он отношения не имеет.

Ocean
Вот когда нет определенного имени переменной у того, что функция возвращает, но я хочу тип возвращаемого указать как правильно это сделать?

Хочешь написать, что возвращается, - пишешь своими словами.
Например

  
import math
help(math.cos)

cos(...)
    cos(x)
    
    Return the cosine of x (measured in radians).

  
import re
help(re.search)

search(pattern, string, flags=0)
    Scan through string looking for a match to the pattern, returning
    a match object, or None if no match was found.

Никаких типов тут нет, никаких маркеров идешных тут нет. Просто пишут понятно и всё. А вот эта хрень - пометь это, пометь то, уточни это, уточни то - это всё притащено снаружи, с других языков. Типа умные ребятки решили засрать питон своими умностями и превратить его в C++ очередной, в котором они сами уже сто раз потерялись из-за загрязнённого синтаксиса. Ещё соревнуются между собой, кто лучше эту синтаксическую помойку знает

Не имея ни одной программы, сидят и соревнуются в знаниях синтаксиса годами.

Ocean
в задании коварно дан коэф с именем l, который я не восприняла проблемой, глядя на само задание, но в процессе решения IDE мне напомнила, что это же ambiguous variable и нарушает договоренности о стиле кода! Теперь я это запомню осознанно

Это нужно узнавать не из IDE, это нужно узнавать из PEP8 и подобных руководств (они в разных языках бывают, называются “стилевые руководства”). Его нужно заучивать и потом наизусть знать. Иначе IDE может тебе не показать, что там есть какая-то ошибка, а она там в это время будет. Тебе будет казаться просто, что там всё правильно. А IDE может вообще не обрабатывать какие-то случаи, потому что она не обязана их обрабатывать. Особенно какие-нибудь замороченные случаи, где глубокая семантика. Слишком дорого её бывает реализовывать по времени, поэтому идешники - разработчики IDE - её могут проигнорировать, причём она будет стоять в PEP или его аналоге чуть ли не на центральном месте.

Ocean
мне пришлось вспомнить и проверить встроенные функции python и осознанно импортировать нужные логарифмы из math

Их не надо импортировать. Надо импортировать модуль, а потом обращаться к ним по имени модуля.
Есть несколько косинусов. Они все называются cos().

  
>>> import math
>>> import cmath
>>> 
>>> math.cos
<built-in function cos>
>>> cmath.cos
<built-in function cos>
>>> 
>>> math.sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> cmath.sqrt(-1)
1j
>>>

Ну, ты просто закоммитишь такие имена заимпортированные, а потом надо будет делать функцию какую-нибудь с таким же именем и придётся сначала всё переписывать по всему коду, а затем перекоммичивать эти переписанные имена в связи с импортом модуля и использованием его как пространства имён для этих функций или переменных. Фактически при импорте модуля тебя придётся отредактировать все функции, в которых эти заимпортированные функции используются. И после этого ты не сможешь откатывать коммиты в репозитории, потому что всё по десять раз переписано в одном месте. Например, у тебя в коммите добавляется функция такая-то. Ты не можешь его отменить, переместить хронологически, склеить с другим коммитом и так далее. Почему? Потому что сверху на содержимое этого коммита прилеплено какое-то изменение внутри этой функции, которая закоммичена этим коммитом. Бывает всякое при работе с репозиторием. Бывает, что переделываешь эти ветки сидишь, чтобы просто бардак убрать в репозитории, и не можешь этот один коммит перебросить из одной чистенькой ветки в другую, потому что он зацеплен за что-то. Короче, грязные репозитории, переполненные лишними коммитами, бывают. И это трэш полный, потому что это всё потом тянется и хранится. И ты не можешь почистить такие репозитории из-за кучи вот таких ненужных правок, которых можно было бы избежать, соблюдая просто все правила изначально. Про такие репозитории и говорят потом “ну, а что мы сделаем? вот эта грязная куча из коммитов не подлежит очистке, ещё сломается что-нибудь”. И потом тянут туда-сюда мегабайты, гигабайты всякой ненужной херни, копируя это по сто раз.

Ocean
У меня была еще одна группа “нелюбимых” задач: про побитовые операторы и переводы из одной системы счисления в другую.

Битовые операции очень важны. Все устройства, порты, сетевые пакеты, заголовки файлов (архивы, экзешники, графика, базы данных, файловые системы) хранят и передают информацию в виде битов. Допустим, у тебя есть опции какой-то фигни в программе, хранить ты их будешь в одном числе в виде битовых флажков. Никто не делает 100500 переменных, чтобы все опции хранить в виде True/False. Просто в одном числе хранятся все опции и это число потом быстро везде передаётся, пересылается по сети, по кабелю и так далее.
Системы счисления просто учат тебя работать с числами, как и множество других задач числодробительных. Это даёт мышление алгоритмами. Это учит работать с полиномами как с массивами немножко. На полиномах вообще много чего построено. Вся эта графика ужатая - это всё полиномы.

Ocean
Я год не могла понять в чем проблема с Pycharm

Начинать надо с блокнота. А Pycharm может пропасть. Как только она пропадёт, ты останешься полностью без рук. Подключишься на сервер, там нужно будет с кодом поработать, а Pycharm не запускается, так как оконной системы нет. Зато куча блокнотов консольных доступна практически отовсюду, а ты в них работать не умеешь, потому что они там за тобой сопельки не подтирают, тут за тобой сопельки не подтирают и думать обо всём теперь нужно самому (раньше за тебя среда думала), а у тебя нет этих навыков. В итоге вся твоя работа разваливается. Как с невыученной таблицей умножения - стопор и всё.

То есть IDE после блокнота должна быть, а не вместо блокнота. Как и тесты должны быть после мозгового дебаггера, а не вместо мозгового дебаггера. Я вот твою программку тестами не обкладывал, я её просто в голове у себя запустил и всё - ошибки посыпались.

Ocean
А тут есть какая-то функция на форуме, чтобы сохранить тему в избранное. Я некоторые перечитываю и возвращаюсь к ним, но становится все сложнее их все не терять. Я нашла функцию подписки на тему, но это немного не то.

Не, тебе свои файлы надо заводить. На каждую книжку - новую директорию с файлами, на каждый ресурс - новую директорию с файлами. И там везде заметки оставлять. На книжку делается файл конспект книжки и файл прохождения книжки, также могут сохраняться какие-то картинки из книжки. Для этого всего директория и нужна, которая объединит это всё, как модуль объединяет функции воедино вокруг чего-то общего. На ресурс делается файл заметок. В файле заметок идёт адрес и информация, которая лежит по этому адресу (сохранять информацию можно целиком, а можно только описание этой информации сохранять). Адрес этого топика, например, - это число 40288. Его легко сохранить, как и список таких адресов. Ты любой топик открываешь на форуме через год-два-три и там просто число в адресной строке заменяешь на 40288. То есть это не напряжно. Можно и ссылки сразу сохранять, но они будут длиннее фигурировать и больше места занимать. И потом ты эти файлы конспектов, заметок, картинок, примеров можешь обвесить скриптами

Эти скрипты могут транслировать эти файлы в HTML-страницы, которые можно в браузере просматривать. Также их можно выкачивать скриптами куда-то автоматом и там потом просматривать. Короче, не программистское у тебя мышление пока, поэтому у тебя и организация деятельности пользовательская. Ты пользуешься только тем, что тебе дали. А сама себе дать что-то ты пока не можешь. Но программист он вот так и делает - он создаёт себе инструменты и пользуется ими, и никто ему не нужен. Я себе просто на одном форуме расширение для браузера сделал и просто оно мне всё делает и меняет, как надо мне, а причуды тамошних админов, что они там напридумывали в очередной раз, мне побоку - моё расширение сделает всё, что нужно мне.

Вот для создания директорий для всяких ресурсов можешь на облаке https://drive.google.com создать документ xls и туда сохранять ссылки и информацию. На любые ресурсы. Обычно папку делаешь для ресурса и заполняешь её документами, HTML-страницами, текстовыми файлами, картинками. Картинки тоже изготавливаешь, потому что иногда лень перенабирать какую-то информацию, проще сфотографировать экран и соединить вместе несколько картинок с формулами. Так ты сможешь смотреть и с компа там инфу, и со смартфона. Иногда нужно быстро что-то вспомнить записанное, а комп выключен. Поэтому смартфон тоже должен доступ иметь к этим данным.

Главное, всё в одном место не писать. Как учиться нужно каждой теме по отдельности, так и сохранять информацию нужно тоже для каждого ресурса по отдельности и не скупиться ни на папки, ни на файлы. Лучше раздельно всё иметь, чем в виде такой “удобной” и “экономной” каши.

Ocean

Май 8, 2021 17:59:41

py.user.next
Ну, неправильно решено.

так озадачилась
Еще не вижу ошибки, но найду ее.

Anyuta3
рано благодарить, видишь неправильное решение. py.user.next никогда не ошибается)

пы.сы. Вы там всем классом программирование прогуливаете?)

py.user.next

Май 9, 2021 01:21:19

Ocean
так озадачилась
Еще не вижу ошибки, но найду ее.

Ну да, я указывать не стал их. Я-то их вижу, мне учиться находить их не надо. А тебе надо научиться. Вот ты написала её неправильно и тебе показалось, что она правильно написана. Так что надо определить: 1) откуда они возникли, как ты их допустила; 2) почему они остались незамеченными, как ты проверяешь работу свою. Вот эти вещи надо скорректировать. И вот для этого эта задача тупая и нужна. Полезного-то она ничего не вычисляет, она просто тебя учит вот этим базовым вещам.

Ocean

Май 9, 2021 12:49:57

py.user.next
Кажется нашла и надеюсь, что все!)

Ошибки нашла в вычислении b.
а) Мой код находил l в -1 степени, потом делил полученное на 3
б) был неправильный знак степени х/6
в) вместо х/6 в степени -2, сперва 6 возводилась в степень, а потом х делился на 36. Для частного случая, когда х = 1 , а степень четная ответ случайно получается правильный просто добавлением пропущенного минуса. Но при смене набора исходных данных программа печатать ответы не перестанет, но будет выдавать говно.

Еще подумала, что ошибка что в натуральном логарифме не указала явно базу base = math.e, но проверила справку посмотрела и там четко указано, что: If the base not specified, returns the natural logarithm (base e) of x. Так что тут теперь уверена, на 100 процентов, что ошибки нет)

Нашла свой пробел в понимании как работают синусы / косинусы
В задаче градусы не указаны в условии, значит я решила, что х задан в радианах и дальше работала с радианами, не задумываясь. Но когда ты сказал об ошибках, то тут то и прилетело в голову, а надо ли мне было это переводить в градусы или нет для вычисления?
math.sin(math.degrees(x)) и math.sin(x) - это разные ответы. Как правильно, я не знаю

С косинусом та же петрушка.
я понимаю, что math.sin и math.cos берут че угодно и ответ возвращают в радианах, но не понимаю что от меня ждут в этой задаче

До этого я была уверена что радианы ок.

Что имеем в итоге: импортирование модуля math поменяла, найденные ошибки исправила. C sin/cos в непонятках

  
# Calculate y1 and y2 if x = 1, K=3, L=0.027
import math
x = 1
k = 3
el = 0.027
def calculate_a(x, k):
    a = k * math.sin(x) + math.cos(x)
    return a
def calculate_b(x, k, el):
    b = (el ** (-1/3) - (x/6) ** -2) * math.log(k)
    return b
def calculate_y1(a, b):
    y1 = math.log10(abs(a - 2 * b))
    return y1
def calculate_y2(a, b):
    y2 = math.log10(abs(a - b * a))
    return y2
coefficient_a = calculate_a(x, k)
coefficient_b = calculate_b(x, k, el)
root_y1 = calculate_y1(coefficient_a, coefficient_b)
root_y2 = calculate_y2(coefficient_a, coefficient_b)
print(f'a = {coefficient_a}')
print(f'b = {coefficient_b}')
print(f'y1 = {root_y1}')
print(f'y2 = {root_y2}')

Ocean

Май 9, 2021 12:51:21

py.user.next
Ну да, я указывать не стал их. Я-то их вижу, мне учиться находить их не надо. А тебе надо научиться. Вот ты написала её неправильно и тебе показалось, что она правильно написана. Так что надо определить: 1) откуда они возникли, как ты их допустила; 2) почему они остались незамеченными, как ты проверяешь работу свою. Вот эти вещи надо скорректировать. И вот для этого эта задача тупая и нужна. Полезного-то она ничего не вычисляет, она просто тебя учит вот этим базовым вещам.

Да, я поняла. Когда находишь ты и показываешь мне, то это прокачивает твой опыт больше, чем мой. Потому что я получаю готовенькое. Да, на будущее я буду знать конкретно про то, что такие ошибки бывают, но не приобрету опыт самостоятельного их нахождения и анализа. Спасибо за это!

py.user.next
Так что надо определить: 1) откуда они возникли, как ты их допустила; 2) почему они остались незамеченными, как ты проверяешь работу свою. Вот эти вещи надо скорректировать.

Ну и разбор полетов:

1) Возникли они из:
- самоуверенности, что я знаю как правильно это задавать и что я разгадала ловушки и “уроки” этой задачи
- хотя я сейчас идут так, как ты научил: проектирование, каркас, детализация поэтапная, но в процессе выполнения детализации я все равно отвлекаюсь на “всю программу” больше, чем на конкретный кусок.
- во время финального дебага, я больше занималась неймингом переменных, потому что только в конце обнаружила, что я наделала a, b в двух разных пространстах имен. На правильность работы программы не влияло, потому что переменные изолированы в своих пространствах имен, но я подумала, что это вредит читабельности и понятности решения для человека, который его не писал или для меня будущей, которая уже забудет суть задачи и станет читать просто код. Поэтому переименовала a в coefficient_a, b в coefficient_b, и сосредоточилась на том, чтобы программа не падала от позднего переименования переменных.

2) Пропустила, потому что:
- тестируя математику переносила ошибки в тесты. Я в питон консоли запускала такой же неправильный код. Он правильный только с формальной точки зрения был, но выполнял не те операции, что я думала, он выполняет
- аналитически не проверила правильность ответа, чтобы понять, что b явно будет отрицательным и вообще больше;
- в отсутствие калькулятора (тут твой гипотетический пример прям в яблочко) поленилась сделать качественные тестовые данные, посчитав на листике вручную. Ну и часть меня сильно сомневалась, что такие мои “ручные” тестовые данные будут правильными и им можно будет доверять,
- в процессе позднего ренейминга отвлеклась и не вернулась к дополнительным тестам математики. Тут снова пункт про самоуверенность сыграл. Типа задачка то простая! Для школьников. Я ж так не прогуливала сильно и не списывала никогда.

Ocean

Май 9, 2021 13:21:18

py.user.next
Да, вот она как раз показывает тебе же самой, что ты не умеешь делать. Так ты узнаёшь, что ты не умеешь делать. Пока ты не делаешь, тебе кажется, что ты умеешь делать. Это вот разница между ожиданиями и реальностью. Поэтому и нужно их все прорешивать, чтобы банально свои пробелы знать, которые скрыты от тебя. Потому что из-за когнитивных искажений мозгу кажется, что он всё знает и всё умеет.

Да. Было такое. Что “да блин, когда придется, в этом то точно разберусь. Поскакали дальше к страшному и совсем непонятному.”
Ну вот) Приперло) Не разобралась без ошибок.

py.user.next
А когда ты узнаёшь, что не умеешь, тебе, конечно, неприятно от этого, но при этом ты попадаешь в состояние “мне придётся научиться”. И тогда начинается старт обучения. Потом это неприятное состояние проходит - злость эта всякая, материть перестаёшь этот язык, эти примеры дурацкие. И потом в спокойном и чистом, просветлённом состоянии ты начинаешь учиться делать. И у тебя появляется шанс действительно научиться это делать,а не в фантазиях своих уметь это делать.

Я больше на себя всегда злилась. Но вот полезной иллюзии сейчас лишилась. Я считала, что я все таки сняла корону, когда отправилась в поход за знаниями. Но корона осталась, только выражалась в уверенности, что это точно знаю. Че тут такого то. Пффф, это просто. Оно то просто, но я на этом “просто” обосралась. Хотя в голове у себя, я считала, что я это знаю. Критически к своим знаниям не подходила.
Спасибо! Нахер все иллюзии.

py.user.next
Радость от решённой задачки и написанной программки пройдёт, а останется вот эта программа с ошибками. И их надо будет исправлять потом, так как никто их не будет исправлять и сами они тоже не исправятся. Вот такие программки у тебя накопятся и нужно будет исправлять уже не одну, а сто таких программок. Это называется технический долг. И он будет только расти и давить на тебя. Тебе будет хотеться всё бросить. Поэтому с него надо заранее снимать слои, чтобы он как можно меньше был по весу. Чем меньше он весит, тем меньше он на тебя давит. Чем меньше он на тебя давит, тем больше у тебя сил на разработку остаётся. Тебе легче. А когда тебе легко, ты легко всё делаешь. Всё делается и тебе легко.

Я не хочу технического долга. Я поэтому решилась на форуме писать. До этого сидела и тихо говнокодила в свои папочки и подзамочную репку.
Я никогда не хотела бросить. Но ощущение, что я тупая и просто не справлюсь, да, оно было и очень сильным.
Я знаю, что никто не будет исправлять и что чудо само собой не произойдет. Я оч стеснялась, что я тупая и сидела тихо, как мышь.
Вон чуваки пишут “второй день изучаю питон, вот задачку помогите”. Да блин. Это страница 100+ в книге, где эта задачка.
Как?! Как он справляется так быстро? Что со мной не так?
Ну и всякие мысли грызли, что я никогда не смогу. Потому что вон все более успешные и умные. Что лезу туда, где мне нет места. Что мой предел - очередной говнокодер.
Сейчас я спокойна в этом плане. Буду двигаться со своей скоростью. Да, я тупая. Окей. И медленная. Окей.

Ocean

Май 9, 2021 14:22:46

py.user.next
Думаю, у тебя идёт смесь разных тем при изучении. Это якобы экономит время обучения и тому подобное. Из-за этого ты не можешь ни одну из них полностью изучить, так как другие темы мешают. Это вредно потому, что будешь изучать всё и будешь знать всё это поверхностно. …. Вот какая-нибудь мелочь затормозит тебе весь процесс.

Да! В точку! Я поэтому системно и хочу научиться. Мне настолько этого не хватает, что пипец. Но потом вокруг все жужжат, оооо программирование это про самообразование. Нахер ВУЗ. Это дисциплина, где так не надо. Самоучки рулят. За год можно стать ахрененным кодером, не тупи. Потратишь время и деньги.
Я смесь делала, чтобы получить что-то похожее на реальность. Ну знаешь, как в проектах работают. Надо ж не просто код писать, но и чужой уметь читать, уметь с гитом работать, уметь с линукс серверами работать. Дохрена всего уметь надо. А оно само не выучится.
Я ж смотрю и читаю: видяхи, статьи, книги, документацию. Оно все обрывочное и фрагментированное. Я своего монстра из обрывков и лепила. Поэтому я что-то могу решить, а потом бах и не могу уравнение без ошибки записать.
У меня с англ такая же хрень. В школе его считай не было. Я так же нахватывалась и своего монстра лепила. А когда на курсы приходишь, они тестируют и мой уровень intermediate, потому что я натренировалась понимать хорошо, бегло читаю и так далее. Но в базе у меня сраные дыры. Поэтому я сделаю ошибку в каком-то “детском” выражении или не буду знать лексику, которые все учили в 5-6 классе. Я так или иначе буду испытывать напряжение на каких-то простых фразах или вопросах. Я реально туплю в английской бытовухе и смолтоках.

py.user.next
Вот Линус Торвальдс любит по несколько страниц в одном коммите написать ценной информации всякой.

Спасибо не знала. Записала себе задачу почитать.

py.user.next
А чтобы выполнить эту операцию, нужно было более глубокое понимание Гита, которого у меня не было тогда, больше всяких знаний. И времени на это не было, чтобы всё это изучать сидеть. Пришлось всю эту историю проекта коммитов на триста со всеми объяснениями в коммитах (где, что и почему делал) удалить, а потом создавать проект типа “здрасьти, я проект, сделанный за один день”. Просто историю проекта не проследишь. А в коммитах бывают многие мысли про плюсы и минусы решений.

Блин, я так уже делала)
Испортила готовое. Конечно, не точно не в масштабе как ты сделал. Там месяц работы был де т. Хотя я считала, что невозможно испортить. Типа там же все ходы записаны.

И такое же было с миграциями в джанге. Я сделала два сервиса в докере: один контейнер с джанго, второй с бд PostgreSQL. Когда миграциями БД запортила, то не смогла исправить. Пришлось с нуля переделывать.

py.user.next
Да хочется всё и сразу. Не, может показаться, что это простая тема. Но это не простая тема. Там за этим стоит математика. И чем лучше ты видишь эту математику за тестами, тем чище у тебя тесты. Тесты тоже можно дерьмово написать. Наличие тестов ни о чём не говорит. Они банально могут нихера не проверять. Тесты есть, они пишут, что всё окей, а там дрова. Мало ли что они пишут.

Нихрена я так не считаю. Я знаю, что сложная. Поэтому и думала начать ее чем раньше, тем лучше.

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

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

py.user.next
Короче, это туфта всё. Ты ничего уметь не будешь. И эта экономия времени, ради которой этой всё делается, в итоге выльется в большие затраты времени. Потому что научиться надо будет этому всему, а учиться этому придётся с нуля или с одной тысячной.

Поняла тебя, больше никакой езды на велике под водой.

py.user.next
Именование - это сложная тема. Там много всяких стилей. Где-то их нужно менять с одного на другой и обратно. Где-то их нужно склеивать вместе. Если тебе кажется, что это простая тема - прочитал статью или главу в книге и всё знаешь, - то не, оно так не работает. Там нужно много чего прочитать и прочитать одно и то же от нескольких разных авторов, потому что кто-то что-то да забудет упомянуть. И только потом ты будешь видеть, где вот нужно это сделать, а где не нужно вот это делать, а где нужно одно заменить на другое. Всё это нужно знать к этому моменту.

Мне никогда простой темой не казалось, я по именам читаю и читаю, все равно туплю и сомневаюсь.
Придумать имя мне сложно, но стараюсь исправить это

py.user.next
Этот стиль пришёл с Java. Java - это другой язык. Он по-другому сделан, поэтому тащить что-то из Java в Python не надо. В Java нужно всегда знать, какой у тебя тип там передаётся или возвращается. А в Python не надо никогда знать про то, какой тип передаётся или возвращается. Поэтому вот этот стиль сделан под IDE, под Java-программистов, которым без типов ничего не понятно, под что угодно. Но к питону он отношения не имеет.

Блин! Спасибо! Я не знала. Мне в статьях попадалось и в коде. Поэтому себе записала и так же делать стала. В справке по функциям я где-то видела возвращаемые типы и типы аргументов. Но не исключаю, что я неверно поняла смысл.

py.user.next
Хочешь написать, что возвращается, - пишешь своими словами.
Например

Спасибо! Вот опять же туплю! Я не догадалась просто посмотреть на докстринги встроенных функций или функций подключаемых модулей. После PEP 257 таскалась по всяким статьям.
Я реально туплю на таком. Надо себе на видном месте написать )) хаха
“Не знаешь, что делать читай документацию и встроенную справку!”

py.user.next
Никаких типов тут нет, никаких маркеров идешных тут нет. Просто пишут понятно и всё. А вот эта хрень - пометь это, пометь то, уточни это, уточни то - это всё притащено снаружи, с других языков. Типа умные ребятки решили засрать питон своими умностями и превратить его в C++ очередной, в котором они сами уже сто раз потерялись из-за загрязнённого синтаксиса. Ещё соревнуются между собой, кто лучше эту синтаксическую помойку знает Не имея ни одной программы, сидят и соревнуются в знаниях синтаксиса годами.

Запомнила крепко накрепко. Больше такой фигни творить не стану!

Ocean

Май 9, 2021 14:55:57

py.user.next
Это нужно узнавать не из IDE, это нужно узнавать из PEP8 и подобных руководств (они в разных языках бывают, называются “стилевые руководства”). Его нужно заучивать и потом наизусть знать. Иначе IDE может тебе не показать, что там есть какая-то ошибка, а она там в это время будет. Тебе будет казаться просто, что там всё правильно. А IDE может вообще не обрабатывать какие-то случаи, потому что она не обязана их обрабатывать. Особенно какие-нибудь замороченные случаи, где глубокая семантика. Слишком дорого её бывает реализовывать по времени, поэтому идешники - разработчики IDE - её могут проигнорировать, причём она будет стоять в PEP или его аналоге чуть ли не на центральном месте

Ну мне хотелось бы тебе сказать, что я так крута, что сама сообразила. Но это был бы наглый пиздеж. Неа, я идиотка. Не вспомнила, поэтому увидела проблему, когда меня IDE ткнул в нее носом.
Да, я понимаю, что это разница как быть грамотной и править свои ошибки словарем в ворде или где-то там.
Словарь не делает меня грамотнее. И более того, словарь пропустит мою дурь, когда само слово будет правильно написано и в нужном падеже, но смысла в предложении не будет или будет настоящая нелепость.
Это тоже пункт, где я торопилась писать код, а не изучать.
Спасибо за подсказку. Тут тоже исправлюсь. Задачу себе поставила четко.

Ocean
Их не надо импортировать. Надо импортировать модуль, а потом обращаться к ним по имени модуля.
Есть несколько косинусов. Они все называются cos().

Это я тоже не сама придумала. Как обезьяна повторяю. Прочитала статью когда-то, что типа не надо всуе тащить все огромные модули, если оттуда используешь одну или две функции.
Импортируй типа именно их и используй. И непременно каждый импорт с отдельной строки. Я заучила и выполняю. Но походу не понимаю, когда надо тащить все, а когда отдельную функцию.
Как различать? На что смотреть? Когда стоит импортировать только отдельные функции или классы?

py.user.next
Ну, ты просто закоммитишь такие имена заимпортированные, а потом надо будет делать функцию какую-нибудь с таким же именем и придётся сначала всё переписывать по всему коду, а затем перекоммичивать эти переписанные имена в связи с импортом модуля и использованием его как пространства имён для этих функций или переменных. Фактически при импорте модуля тебя придётся отредактировать все функции, в которых эти заимпортированные функции используются. И после этого ты не сможешь откатывать коммиты в репозитории, потому что всё по десять раз переписано в одном месте.

Хохо! А я наивно думала, что нельзя создавать переменные c именем sin/cos, data, datatime и все такое, ну типа по аналогии с зарезервированными именами, что в keywords и build-in-functions.
Но так то логично, что не получится заучить имена всего импортированного и предвидеть, что придется импортировать в будущем. Мало ли че там прилетит в пространство имен, кроме sin/cos. А потом по-тихому переопределится в коде и все. Хорошо, что если с ошибкой или исключением вылетать будет, а может по-тихому гадить в данные, искажая их.
а так получается, что я их использовать буду типа math.cos, то вероятность совпадений ниже.
Возможно, я math.cos сломаю, только если напилю свой класс Math, где будет функция cos. Потом создам экземпляр класса, которую я сохраню в переменную math, а затем я где то захочу для этой math использовать свой метод cos. Так! Надо будет попробовать) Сломается или все равно импортированное math.cos останется пуленепробиваемым.

py.user.next
Бывает, что переделываешь эти ветки сидишь, чтобы просто бардак убрать в репозитории, и не можешь этот один коммит перебросить из одной чистенькой ветки в другую, потому что он зацеплен за что-то. Короче, грязные репозитории, переполненные лишними коммитами, бывают. И это трэш полный, потому что это всё потом тянется и хранится. И ты не можешь почистить такие репозитории из-за кучи вот таких ненужных правок, которых можно было бы избежать, соблюдая просто все правила изначально. Про такие репозитории и говорят потом “ну, а что мы сделаем? вот эта грязная куча из коммитов не подлежит очистке, ещё сломается что-нибудь”. И потом тянут туда-сюда мегабайты, гигабайты всякой ненужной херни, копируя это по сто раз.

Вот это я пока не делала и не умею. Для меня это выглядит как фигуры высшего пилотажа.
А эти грязные почистить можно? Ну, например, каждый модуль покрыть качественными тестами на 100 процентов. Потом после изменений в репо прогонять тесты и смотреть ломается или нет? Хотя утопично. Это же все время+бабло. Плюс какой то профессионал, чтобы это все осилить. Но нахрена профику палить на это мозг и время жизни? Нет мотивации.
Если смотреть с точки зрения трудоемкости, то проще это говно сжечь и написать начисто, но не у всех хватит воли и решимости это сделать. В новом коде могут быть свои баги, которых не было в прошлом. То есть надо весь подход менять, иначе будет второй грязный репозиторий и те же проблемы на выходе.

Ocean

Май 9, 2021 15:25:29

py.user.next
Битовые операции очень важны. Все устройства, порты, сетевые пакеты, заголовки файлов (архивы, экзешники, графика, базы данных, файловые системы) хранят и передают информацию в виде битов. Допустим, у тебя есть опции какой-то фигни в программе, хранить ты их будешь в одном числе в виде битовых флажков. Никто не делает 100500 переменных, чтобы все опции хранить в виде True/False. Просто в одном числе хранятся все опции и это число потом быстро везде передаётся, пересылается по сети, по кабелю и так далее.
Системы счисления просто учат тебя работать с числами, как и множество других задач числодробительных. Это даёт мышление алгоритмами. Это учит работать с полиномами как с массивами немножко. На полиномах вообще много чего построено. Вся эта графика ужатая - это всё полиномы.

Спасибо! Буду с удовольствием решать задачи на битовые операции) Я раскаялась и в этом тоже. Нет ничего неважного, нет ничего простого. Везде нужно копать глубоко.

Просто тут получается, что я очень медленная получалась. Меня били по рукам на работе и переучивали. Ну типа херли ты тут сидишь. Это частный случай, вероятность низкая. Забиваем болт.
В дереве важен ствол и основные ветки. Мелкими ветками можно пренебречь. Пока ты делаешь идеальным каждый листик, Валечка уже сдала проект. Неидеальный, но законченный! Законченный, понимаешь! Сколько ты еще копаться будешь? Твоя зп нам обойдется больше, чем потери из-за ненайденной тобой ошибки.
Я не оправдываюсь, просто делюсь. Я начала верить, что правда за деревьями не вижу леса. Что до леса не доберусь никогда, потому что вязну во второстепенном, третьестепенном и так далее. Что надо сделать, а потом полировать. Но часто потом не наступало и не наступает. И я так заебалась от этого, что сменила работу. Думаешь легче? Хер! Просто вот хер! Кое-как работает, не трогаем! Оставить, а то вдруг сломается и будет еще хуже.
Большинство руководителей и собственников принимают такие решения. Никого не интересует монументальное или послезавтра. Типа мы ж не Боинги строим или космические аппараты, а послезавтра может и не наступить. Или послезавтра для бизнеса “будут другие вызовы и приоритеты”. Бизнесу такое не интересно, бизнес должен успешно конкурировать и блаблабла.
Для чистой науки я не пригодна ибо тупое животное даже аспирантуры не повидавшее, умом и талантами не отличаюсь.
В общем какая-то неполезная вышла, каким боком ни крути. Теперь буду копать глубоко и накопаю сколько успею. Похеру на все остальное.

py.user.next
Начинать надо с блокнота. А Pycharm может пропасть. Как только она пропадёт, ты останешься полностью без рук. Подключишься на сервер, там нужно будет с кодом поработать, а Pycharm не запускается, так как оконной системы нет. Зато куча блокнотов консольных доступна практически отовсюду, а ты в них работать не умеешь, потому что они там за тобой сопельки не подтирают, тут за тобой сопельки не подтирают и думать обо всём теперь нужно самому (раньше за тебя среда думала), а у тебя нет этих навыков. В итоге вся твоя работа разваливается. Как с невыученной таблицей умножения - стопор и всё.

Ты не поверишь) Я писала свой говнокод в блокноте, Python IDLE и потом в 2014 вроде узнала про Canopy editor. Использовала его.
Потом пересеклась с программистом. Я спросила, он сказал: “ты страдаешь херней. Бери нормальный редактор и пиши. Времена изменились, ты же не стираешь трусы на реке в проруби золой с деревянной теркой, а используешь порошок и стиралку.”
Потом пересеклась еще с одним программистом. Послушала еще про херню, которую творю. Что сама нахера-то залезаю в дебри и настойчиво жру кактусы, а уже бы проекты делала нормальные. Надо знать современные технологии и хорошо гуглить, а остальное как-то само приложится.
Потом я поговорила с третьим… Он сказал, ну те дело говорят, а ты сопли жуешь. Изучи синтаксис языка, которого выбрала. Потом что хочешь делать? Веб-приложухи? Ну, найди гайды и по гайдам херачь. Пройдешь несколько гайдов, потом в процессе разберешься и втянешься.

Вот так и докатилась до PyCharm. Они ж опытнее меня и умнее. Если спрашиваю и дали советы, то надо следовать.
И вот вся в соплях до сих пор. Таки никто не вытирает.

py.user.next
То есть IDE после блокнота должна быть, а не вместо блокнота. Как и тесты должны быть после мозгового дебаггера, а не вместо мозгового дебаггера. Я вот твою программку тестами не обкладывал, я её просто в голове у себя запустил и всё - ошибки посыпались.

Вот мозговой дебаггер у меня нулевой. Я часто нахожу ошибку в момент, когда запускаю и че то отваливается. Или результат неожиданный.
Как это прокачать? Я вроде продумываю и пишу то, что продумала. Но на выходе херня.
Это придет со временем и просто продолжать или что-то особенное нужно делать?
я на все готова! Я хочу уметь в голове узнавать, что выполнит код, который передо мной.

Ocean

Май 9, 2021 15:46:45

py.user.next
Не, тебе свои файлы надо заводить.

У меня сейчас есть:
1) тетради: на каждую тему/книжку своя. И есть общая тетрадь, где мои личные гайды и шпаргалки. Допустим трахалась с докером, вникла. Записала команды, чтобы пока наизусть не запомню, у меня была шпаргалка. Ну типа знаешь, как с формулами треугольника, чтобы перед глазами для решения, пока не запомняться накрепко.
2) Приложение: asana. Там себе задачи и планы строю. ну чтобы не тратить время каждый раз. Появилось время и кодить или англ учить, а не думать… Тааааак… А чем же мне заняться? А может сегодня вот эту книжку почитать?
Открываю приложение, вижу невыполненные таски, где четко указано, что мне надо сделать. Беру и делаю одну за одной. В конце дня проверяю и составляю таски для себя будущей
3) Гуглофайлы и гуглодиректории.

py.user.next
На каждую книжку - новую директорию с файлами, на каждый ресурс - новую директорию с файлами.

Именно так.

И там везде заметки оставлять. На книжку делается файл конспект книжки и файл прохождения книжки, также могут сохраняться какие-то картинки из книжки.

Вот тут и начались сложности, потому что пометки и конспект не оч удобно. На бумагу все листинги нет смысла писать, отдельно директория + тетрадка оч неудобно. По тетрадке поиск херовый. По директориям получше, но на скринах тоже не ищет.
Сейчас нашла OneNote и понемногу пробую там обживаться. Там сейчас папка имени тебя)
Наполняю ее) Примерами кода, подсказками ответами)
Я читаю твои комменты больше одного раза) Уже есть эффект, когда возвращаюсь к ним и нахожу больше, чем увидела первый раз.

Для этого всего директория и нужна, которая объединит это всё, как модуль объединяет функции воедино вокруг чего-то общего. На ресурс делается файл заметок. В файле заметок идёт адрес и информация, которая лежит по этому адресу (сохранять информацию можно целиком, а можно только описание этой информации сохранять). Адрес этого топика, например, - это число 40288. Его легко сохранить, как и список таких адресов. Ты любой топик открываешь на форуме через год-два-три и там просто число в адресной строке заменяешь на 40288.

От это ахренненная подсказка! Очередное огромное спасибо Я еще буду номер коммента ставить. Тут нумерация в каждом топике всегда своя. А то темы, где разрастется до десятков страниц, потом листать тоже сложно. Я уже так искала твои мысли, чтобы перечитать и не могла вспомнить сходу в каком из ответов это было. Потратила минут 15, но нашла)))

То есть это не напряжно. Можно и ссылки сразу сохранять, но они будут длиннее фигурировать и больше места занимать. И потом ты эти файлы конспектов, заметок, картинок, примеров можешь обвесить скриптами Эти скрипты могут транслировать эти файлы в HTML-страницы, которые можно в браузере просматривать. Также их можно выкачивать скриптами куда-то автоматом и там потом просматривать. Короче, не программистское у тебя мышление пока, поэтому у тебя и организация деятельности пользовательская. Ты пользуешься только тем, что тебе дали. А сама себе дать что-то ты пока не можешь. Но программист он вот так и делает - он создаёт себе инструменты и пользуется ими, и никто ему не нужен. Я себе просто на одном форуме расширение для браузера сделал и просто оно мне всё делает и меняет, как надо мне, а причуды тамошних админов, что они там напридумывали в очередной раз, мне побоку - моё расширение сделает всё, что нужно мне.

Ахеренно! Вот мой пет-проект) Я хочу это сделать для себя) Это будет капец как удобно. А в процессе я узнаю дохрена нового))
Еще я пробовала хитрить) Подняла бесплатный форум на php и сделала себе из него подобие evernote. По темам кидала себе заметки, чтобы потом обработать их в задачи, конспект и так далее.

Вот для создания директорий для всяких ресурсов можешь на облаке https://drive.google.com создать документ xls и туда сохранять ссылки и информацию. На любые ресурсы. Обычно папку делаешь для ресурса и заполняешь её документами, HTML-страницами, текстовыми файлами, картинками. Картинки тоже изготавливаешь, потому что иногда лень перенабирать какую-то информацию, проще сфотографировать экран и соединить вместе несколько картинок с формулами. Так ты сможешь смотреть и с компа там инфу, и со смартфона. Иногда нужно быстро что-то вспомнить записанное, а комп выключен. Поэтому смартфон тоже должен доступ иметь к этим данным.

Да, я так делаю, все заливаю на гугл-диск. Так и спокойнее, что если с ноутом че то случится, то я знаю, что на гуглдиске все будет в сохранности, если прям глобальный факап в их датацентрах не случится
С телефона почти не могу учиться. Глаза настолько устают за день, что на телефоне все плывет. Тупо буковки уже не вижу. На ноутбуке ставлю побольше и могу еще на час или два дольше просидеть. Так что телефон только для англ. Голосовые упражнения удобно) и произношение тренируется, и глаза отдыхают

Главное, всё в одном место не писать. Как учиться нужно каждой теме по отдельности, так и сохранять информацию нужно тоже для каждого ресурса по отдельности и не скупиться ни на папки, ни на файлы. Лучше раздельно всё иметь, чем в виде такой “удобной” и “экономной” каши.

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

в каше потом ничерта не найдешь. Дольше ищешь, чем пользы получаешь от такого “копспекта”.