пишу на чем попало
Контакты

Достижения

Все достижения (10)

Наибольший вклад в теги

Все теги (57)

Лучшие ответы пользователя

Все ответы (105)
  • Я не до конца понимаю ООП, что мне надо знать?

    @Stqs
    senior software developer
    на вашем примере конечно сложно аргументировать зачем нужно ооп
    но все это действительно связано с управлением сложностью и разработкой более менее больших систем

    проблема в том что мозг устроен так, что ему сложно держать в голове одновременно(объем внимания) больше 7-10 объектов
    есть конечно уникалы, да и программирование вцелом этот скил конечно развивает но если брать среднего обычного человека то это действительно так.
    Как пример - попробуйте решить задачку Эйнштейна в голове Ж) Там нет ничего сложного но нужно одновременно держать пару десятков кусочков информации в голове. БОльшинство людей это не в состоянии сделать.
    По этой же причине:
    - на рекламных плакатах вы не увидите длинных текстов - 5-7 слов максимум
    - функция из 10-20 строк легче воспринимается чем из 100-200 строк,
    - 5-7 аргументов функции легче осилить чем 27
    - 5-7 переменных в функции легче удержать в голове чем 20
    и тд и тп

    Проблема особенно актуальна в программировании
    Вы можете написать функцию как и хотели. все ок. претензий нет.
    вы напишете еще 10 функций и еще сможете понимать что там написано
    но что если их будет 100? 1000?
    Вы сможете так же быстро разбираться в том что происходит в программе? особенно после полугода перерыва например
    отсюда возник вполне естественный верхний потолок для размера программ - больше просто нереально было поддерживать. Нереально удержать в голове даже командой
    Написание кода таким способом очень плохо масштабируется

    ежели вы применяете ооп то каждый класс можно рассматривать как отдельную сущность у которой относительно небольшое количество полей/методов. то есть во-первых их теперь можно вместить в голову не принимая во внимание тонны окружающего кода, во-вторых, что самое главное, их и не нужно вмещать в голову потому что ты теперь вместо 100 функций в голове держишь картинку из 7 классов, что очень легко
    если нужно знать реализацию конкретной сущности - идешь и читаешь - она гарантированно поместится в голову
    вы можете сказать но у меня в программе может появится 100 классов или 1000 классов, что тогда? тут на помощь приходит абстрагирование
    скорее всего многие из этих 100 классов входят в какие-то(возможно абстрактные) структуры более высокого порядка, поэтому хоть классов у вас и 100 - работа с ними может быть облегчена введением классов на следующем, более высоком уровне абстракции которые работают с классами более нижнего уровня абстракции, таким образом вы опять работаете с те ми же 10 сущностями, которые отлично помещаются в голову
    это все приводит к тому что теоретически, программа на опп масштабируется бесконечно
    теряешь контроль над сложностью - абстрагируешься
    интересуют детали - опускаешься на нужный уровень и изучаешь как конкретный класс работает
    не говоря уже о бонусах которые ты получаешь имея наследование, полиморфизм и собственно инкапсуляцию

    ну и еще плюсом можно назвать то что ООП все-таки более подходит для описания того что происходит вокруг
    если мы посмотрим вокруг то все что мы видим - объекты, с какой-то внутренней сложной структурой
    мы явно можем эти объекты группировать(классы) - люди, компьютеры, машины
    мы видим что эти объекты могут взаимодействовать друг с другом через определенный интерфейс, и их совершенно не интересует как конкретный объект устроен внутри(инкапсуляция)
    то есть при ооп работа сводится к тому что бы выделить сущности которыми ты реально будет оперировать в своей программе, определить интерфейс(как они могут взаимодействовать. А дальше лишь описывать эти взаимодейсвтия. При этом вам нет необходимости держать в поле зрения все имеющиеся классы, их методы, поля, всю логику их поведения и взаимодействия,
    Ответ написан
  • Как деплоить небольшие проекты?

    @Stqs
    senior software developer
    вопросы у вас философские, на каждый можно отвести часы обсуждения
    Полноценный CI/CD поднимать не вижу смысла ввиду размеров

    вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
    какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
    единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
    с этой точки зрения мое видение примерно такое:

    1) git не есть инструмент для развертывания по, git лишь для версионирования кода
    и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
    сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
    Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
    Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
    Артефакты желательно хранить в каком-то артефактории,
    но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

    2) как только вы получили артефакт - его можно деплоить
    неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
    опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
    Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

    В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

    3) Env Variables
    когда приложение стартует - считывает все что ему нужно из переменных окружения
    деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

    Итого имеем
    - логика сборки проекта описана в Dockerfile и находится под гитом
    - логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
    - на сервере мы ничего не устанавливали совершенно кроме самого докера
    - мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
    - сервер не знает ничего о гитах
    - на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
    - имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)
    giphy.gif
    Ответ написан
  • Добавлять ли virtualenv в git?

    @Stqs
    senior software developer
    Частенько бывает что часть пакетов нужна при разработке и не нужна на продакшене. И наоборот. Поэтому желательно бы еще разделять requirements для разработки и для продакшена.
    Файлы с requirements могут включаться один в другой. Таким образом обычно зависимости можно разделить на 3 отдельных файла.
    Например:
    reqs/
    - common.txt
    - prod.txt
    - dev.txt

    common.txt будет содержать все обязательные общие зависимости. Пример с потолка:
    Django==1.8.5
    mysql-python==1.2.5


    dev.txt будет содержать пакеты специфичные только для разработки но включая common. Пример опять же с потолка:
    -r common.txt
    ipyhton
    ipdb
    django-debug-toolbar==1.4


    prod.txt тоже будет включать common но так же содержать вещи которые на продакшене обязательны а в Вашем локальном окружении не нужны вовсе:
    -r common.txt
    gunicorn==19.4.1
    whateverelse=1.0.0


    соответственно когда мы собираемся разрабатывать мы устанавливаем зависимости так
    pip install -r reqs/dev.txt
    в продакшене
    pip install -r reqs/prod.txt
    Ответ написан
  • Где взять опыт Python, как попасть на стажировку?

    @Stqs
    senior software developer
    вы к сожалению находитесь в "замкнутом круге выпускника"
    без опыта - не берут
    не берут - нет опыта

    в вашем случае все осложняется тем что вы не можете прорваться даже сквозь HR
    к сожалению они зачастую просто являются био-роботами которые надрочены на определенные keywords которые они ожидают от вас услышать
    не услышали - давай да свидания (в вашем случае - они не услышали что у вас есть опыт)

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

    про опыт
    опыт можно получить даже не работая в кампаниях
    можно поучаствовать в каком-нибудь open-source проекте
    и будет что показать и будет о чем на собеседовании поговорить
    и вообще хорошая тема для очистки кармы нещадно загрязненной 1с-ом

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

    кароче тезисно
    1) не говорим всей правды эйчарам, выставляем все хорошее, молчим про все плохое
    2) пытаемся влиться в тусовку где можно выхватить хоть какой-то референс от уже работающих людей - это уже половина успеха
    3) участвуем в opensource
    4) ну и продолжаем долбиться все кампании помельче да постремнее - задача то не работу мечты найти а просто вырваться из замкнутого круга
    Ответ написан
  • Как избежать или контролировать постоянного переписывания и улучшения своего кода?

    @Stqs
    senior software developer
    Andrew Stark,

    1) вместо переписывания всего каждую неделю нужно один раз взять и потратить эту же неделю на прочтение 1-2 книг типа "Code Complete" или "The Pragmatic Programmer: From Journeyman to Master". Это позволит вам немного расширить кругозор и даст какие-то базовые принципы "хорошего код". Это в свою очередь приведет к тому что вы изначально будете писать более хороший код и переписывать все придется реже.
    Далее с опытом придет понимание что не каждая статья на хабре является истиной в последней инстанции и не стоит сломя голову бежать и чото внедрять. Придет понимание зачем именно вам нужно это изменение. ВЫработается своя точка зрения. Все перестанет быть черно-белым. Каждый архитектурный вопрос станет "философским" и тд и тп. Но это с опытом, пока что придется по-переписывать,
    2) если вы еще учитесь - то в этом процессе в принципе нет ничего плохого.
    если в вас заговорил неупокоенный перфекционист - то это хреново, переписывать вы не закончите никогда. либо пока не наберется нужного опыта (см пункт 1)
    3) ежели вы делаете это в коммерческой разработке - то все совсем плохо
    с точки зрения любого бизнеса - абсолютно неважно насколько гениален, прост и поддержваем Ваш код. Если нет явных багов то работать он будет в общем случаем абсолютно точно так же. А то чем занимаетесь вы - пустая трата ресурсов (времени и денег)
    Ибо мудрость гласит - "пока ты спишь - враг качается"
    Если перевести на наш язык - пока ты в сотый раз переписываешь одно и тоже конкуренты уже наговнокодили и давно увели наших клиентов. Поэтому я бы посоветовал еще учитывать такой фактор - "горит ли это изменение прямо сейчас". Если не горит - сделаем когда загорит, сейчас нужно быстро в продакшн выходить и нести наработки инвесторам.

    Немного сумбурно написал
    Если в кратце:
    - вначале больше учимся чем пишем
    - перфекционизму нет предела
    - правильно приоритезируй свою работу
    - мой руки перед едой
    Ответ написан