Задать вопрос
  • Как научиться проектировать ПО?

    Ranwise
    @Ranwise
    может подойдут книги типа

    Agile оценка и планирование проектов, Кон Майк - 2018
    Постигая Agile. Ценности, принципы, методологии, Э.Стеллман, Д.Грин - 2018
    Ответ написан
    Комментировать
  • Как научиться проектировать ПО?

    @nexus478
    Проектирование приложений можно условно разбить на 2 уровня:
    1. Уровень проекта.
    Сюда входит понимание того, как приложение должно выглядеть в целом и из каких компонентов состоять, а также по каким принципам оно собирается взаимодействовать с внешним миром (если есть такая необходимость). Компоненты зависят от выбранной архитектуры - в случае монолитного приложения вам требуется понимать, как разбивать его на слои и в чем ответственность каждого слоя; в случае микросервисов вы также должны понимать, как очерчивать зоны ответственности и определять протоколы взаимодействия между ними.
    В вашем случае я думаю вряд ли микросервисы будут актуальны (они для больших проектов), поэтому у вас скорее всего будут небольшие монолитные приложения.
    Книги о том, как проектировать приложения на общем уровне:
    1. Роберт Мартин. Чистая архитектура - очень короткая и простая книга, рекомендую начать с неё.
    2. Эрик Эванс. Предметно-ориентированное проектирование (принципы + стратегические шаблоны).
    3. Мартин Фаулер. Архитектура корпоративных приложений (часть 1).

    Уровень 2. Уровень модулей (классов).
    Когда вы спроектировали компоненты, из которых состоит ваше приложение, теперь надо спроектировать их внутренности - то есть разбить на более мелкие и конкретные модули. Тут вам пригодятся принципы объектно-ориентированное проектирования, принципы SOLID, паттерны.
    Книги по уровню 2.
    1. Банда четырех. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. Тут важно не только сами паттерны, но принципы, по которым они строятся. Концентрируйтесь на принципах.
    2. Роберт Мартин. Принципы, паттерны и методики гибкой разработки на языке C#. Тут более подробно рассматривается объектно-ориентированный дизайн и принципы SOLID в сравнении с его "Чистой архитектурой".
    3. Эрик Эванс. Предметно-ориентированное проектирование (тактические шаблоны).
    4. Мартин Фаулер. Архитектура корпоративных приложений (часть 2).
    5. Стивен Макконел. Совершенный код (сконцентрируйтесь на понимании Главного Технического Императива!).

    Этих книг вам будет достаточно, чтобы ориентироваться в проектировании приложений, всё остальное решает практика. Рисуйте схемы, концентрируйтесь на ответственности компонентов и их интерфейсах, учитесь отбрасывать ненужные детали реализации.
    Ответ написан
    1 комментарий
  • Как практиковаться в веб разработке?

    @baitarakhov
    Учеба учебой, но скоро наступит момент, когда ты захочешь активно использовать свои новые навыки на практике, и что немаловажно - начать зарабатывать на этом. Для получения первого интересного проекта за деньги, тебе потребуется как минимум эстетически красиво оформленное портфолио.

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

    Ссылки:
    Почему дизайн-системы терпят неудачу и как застави...
    Cоздание дизайн-систем с помощью Atomic Design
    Создание дизайн системы (пошаговое руководство)
    Каталог отечественных компонентных дизайн-систем, ...
    Ответ написан
    Комментировать
  • Как сделать, чтобы скрипт выполнялся после загрузки страницы?

    Можно например подписаться на событие onload у объекта window.
    window.onload = function() {};
    Ответ написан
    4 комментария
  • Как закрыть досуп горе хакерам?

    1. Сменить 22 порт
    2. Запретить вход от root /etc/ssh/sshd_config:
    # Authentication:
    LoginGraceTime 20
    #PermitRootLogin without-password
    PermitRootLogin no
    StrictModes yes
    #SSH разрешен только пользователям:
    AllowUsers bla-bla-bla(тут пользователь, которым ты коннектишься)
    #время закрытия неработающей сессии
    ClientAliveInterval 300
    ClientAliveCountMax 0
    3. Fail2ban
    Ответ написан
    Комментировать
  • Как в python3 (модуль sqlite3) экранировать строку для записи в базу?

    SagePtr
    @SagePtr
    Еда - это святое
    А прочитать документацию сложно?
    # Never do this -- insecure!
    symbol = 'RHAT'
    c.execute("SELECT * FROM stocks WHERE symbol = '%s'" % symbol)
    
    # Do this instead
    t = ('RHAT',)
    c.execute('SELECT * FROM stocks WHERE symbol=?', t)
    print(c.fetchone())
    
    # Larger example that inserts many records at a time
    purchases = [('2006-03-28', 'BUY', 'IBM', 1000, 45.00),
                 ('2006-04-05', 'BUY', 'MSFT', 1000, 72.00),
                 ('2006-04-06', 'SELL', 'IBM', 500, 53.00),
                ]
    c.executemany('INSERT INTO stocks VALUES (?,?,?,?,?)', purchases)
    Ответ написан
    Комментировать
  • Как реализовать скрытие пароля во время ввода на python3?

    @Bruceee
    import getpass
    
    password = getpass.getpass('Введите ваш пароль: ')
    Ответ написан
    Комментировать
  • Как вы добавляете коммиты?

    @ahosta
    Идея GIT как раз в осмысленных коммитах
    Тупые автоматические коммиты раз в час - смысла лишены.
    Чтобы всякие не умничали: на то у нас стоит программное ограничение - коммиты более 200 строк не принимаются.
    Но у нас реально совместная работа и code review.
    Если вы работаете без коллектива - делайте как бэкап. Но для этого не нужен GIT.

    Идея GIT, чтобы можно было РАЗОБРАТЬСЯ зачем делалась та или иная хрень.
    И наоборот:
    И для решения определенной проблемки какая делалась хрень.
    Ответ написан
    2 комментария
  • Как вы добавляете коммиты?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Атомарно. Часто. Любой целостный, завершенный и логический кусок или кусочек, независимо от размера. И не важно - сам пилю, или с командой. Это вопрос привычки - поначалу и лень, и смысла вроде не видишь. Со временем привыкаешь. И когда приходит время воспользоваться прелестями атомарных коммитов (а оно приходит) - откат фичи или возврат ранее откаченной (по требованию клиента), разрешение конфликтов и тд - радуешься и благодаришь себя прошлого за то, что не поленился.

    И еще, очень важно писать адекватные commit message. Никаких "minor fix" и тому подобное. По месседжу должно быть четко понятно при листании истории что к чему и зачем, без необходимости смотреть diff. В идеале, еще и привязка к issues - но это актуально в командной работе, одному не надо.

    Что касается бранчей - сильно зависит от проекта. В командной работе это либо feature branches (git flow или своя произвольная схема), либо у каждого своя ветка и там делай что хочешь. Тут смысл в первую очередь в пулл-реквестах, code review, CI и стабильном мастере, в котором всегда находится рабочий код. Если работать одному - лично я привык бранчевать каждую отдельную фичу (не фрагмент, а именно модуль, автономный кусок функциональности). Удобно на серверах чекаутить конкретный бранч, тестить, возвращаться на мастер. И это позволяет одновременно работать над несколькими фичами. Например, одну допилил, отдал на утверждение клиенту, а там есть комменты/фиксы, но ждешь какие-то материалы. Переключился на другую фичу и безопасно работаешь в другом бранче. В общем, удобно и надежно.
    Ответ написан
    Комментировать
  • Postgres обрезать строку с конца?

    gaparchi
    @gaparchi
    SELECT right(fieldname, 10) FROM tablename;
    Ответ написан
    Комментировать
  • Ищем Аналог Телеграм ChatBot и API, кто встречал?

    @bkosun
    Посмотрите Sender + Corezoid
    Ответ написан
    Комментировать
  • Нужен ли диплом девушке в IT?

    Moskus
    @Moskus
    По мотивам самого вопроса и комментариев, попытаюсь ответить подробно.

    Дипломы и аттестаты сами по себе формально требуются реально только для двух вещей:
    - работа в гос. организациях и их подрядчиках, где это - формальное официальное требование,
    - подача заявки на рабочие визы в некоторые страны, которые, таким образом, отсекают самозванцев.
    Пол работника в обоих случаях не при чем.

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

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

    Если вы действительно умеете делать то, чем хотите зарабатывать, главное - уметь это продемонстрировать и не пытаться получить работу любой ценой (из этого всегда получается что-то плохое). У вас же, пока, с уверенностью - проблема, а это даже приличного нанимателя совершенно справедливо насторожит.

    Отвечая на вопросы, заданные в ответах - да, вышка по профилю для специалиста по моделированию - возможна, только это не то, что вы думаете, а, например, классическое художественное образование (скульптура) в МГАХИ.
    Ответ написан
    Комментировать