• Какую прочитать книгу/курс по проектированию баз данных?

    myjcom
    @myjcom
    плохо ищете )
    Поиски литературы почему-то не увенчались успехом, пара унылых статей на хабре, море старой литературы старше 15 лет и курсы для новичков на udemy где описывается разница между insert и select.


    все есть:

    SQL Queries for Mere Mortals, 4th Edition
    Год издания: 2018
    Автор: Viescas J.
    Жанр или тематика: Базы данных
    Издательство: Addison-Wesley Professional
    ISBN: 978-0134858333
    Язык: Английский

    Effective SQL: 61 Specific Ways to Write Better SQL
    Год издания: 2017
    Автор: Clothier B., Steele D., Viescas J.
    Издательство: Addison-Wesley
    ISBN: 978-0-13-457889-7
    Язык: Английский

    PostgreSQL Up and Running, 3rd Edition
    Год издания: 2018
    Автор: Obe R., Hsu L.
    Издательство: O'Reilly Media
    ISBN: 978-1-491-96341-8
    Язык: Английский

    PostgreSQL 9.6 High Performance
    Год издания: 2017
    Автор: Ahmed I., Smith G.
    Издательство: Packt Publishing
    ISBN: 9781784392970
    Язык: Английский

    PostgreSQL High Availability Cookbook
    Год издания: 2017
    Автор: Thomas S.M.
    Издательство: Packt
    ISBN: 978-1-78712-553-7
    Язык: Английский

    PostgreSQL 10 High Performance
    Год издания: 2018
    Автор: Ibrar Ahmed, Gregory Smith, Enrico Pirozzi
    Издательство: Packt Publishing Ltd.
    ISBN: 9781788474481
    Язык: Английский

    Database Systems: Design, Implementation and Management
    Год издания: 2017
    Автор: Coronel С., Morris S.
    Издательство: Cengage Learning
    ISBN: 978-1-305-62748-2
    Язык: Английский

    Designing Data-Intensive Applications / Высоконагруженные приложения. Программирование, масштабирование, поддержка.
    Год издания: 2018
    Автор: Martin Kleppmann / Клеппман Мартин
    Издательство: Питер
    ISBN: 978-5-4461-0512-0
    Язык: Русский

    Refactoring SQL Applications / Рефакторинг SQL-приложений
    Год: 2009
    Автор: Stephane Faroult / Стефан Фаро, Pascal L'Hermite / Паскаль Лерми
    Издательство: Символ
    ISBN: 978-5-93286-145-5, 978-0-596-51497-6
    Язык: Русский

    и даже ISO/IEC 9075:2011 буржуйский можно найти в pdf
    Ответ написан
    2 комментария
  • Как правильно подключить древнюю библиотеку в современный фреймворк (PHP)?

    BoShurik
    @BoShurik
    Symfony developer
    https://getcomposer.org/doc/04-schema.md#classmap
    Положить файлики библиотеки в отдельную директорию (e.g. legacy-lib/) и прописать
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        },
        "classmap": ["legacy-lib/"]
    },
    Ответ написан
    Комментировать
  • Проектирование структуры приложений для начинающего?

    @EvgeniiR
    https://github.com/EvgeniiR
    Роберт Мартин, "Чистая Архитектура", "Чистый код", "Идеальный программист"
    Макконнелл, "Совершенный код".

    Далее по ситуации, Фаулер, Эванс, Кент Бек и т.п.

    Заменять чтение книг собиранием по крупицам информации в интернете ни в коем случае не советую.
    Ответ написан
    28 комментариев
  • Почему вылазит ошибка на мобильных девайсах при SSL?

    CityCat4
    @CityCat4 Куратор тега Цифровые сертификаты
    //COPY01 EXEC PGM=IEBGENER
    Да здесь все сплошная ошибка. И даже не одна.

    Ошибка первая CERT_AUTHORITY_INVALID означает, что УЦ, выпустивший Вам сертификат, отсутствует в списке корневых УЦ, сертификаты которых являются доверенными. Поди, на LetsEncrypt брали? Уж сколько раз твердили миру - если делаете продающий сайт, да еще заточенный под мобильные устройства, закладывайте в бюджет покупку сертификата, а не то будете вот так вот спрашивать. Ваш сертификат выпустило неизвестное мобильному устройству УЦ, к которому нет доверия, соответственно нет доверия к сертификату.

    Ошибка вторая This server is vulnerable to the POODLE attack. Возникает, когда сканер безопасности видит, что сервер принимает соединения по протоколу SSLv3. Вам необходимо запретить семейство протоколов SSLv3, читайте документацию как это сделать

    Ошибка третья This server accepts RC4 cipher. Возникает, когда сервер принимает среди прочих шифров шифр RC4, который давно считается ненадежным. Необходимо так настроить шифронаборы, чтобы исключить его использование

    Ошибка четвертая :) This server does not support Forward Secrecy. Возникает, когда среди шифронаборов сервера не обнаружены наборы с PFS - Perfect Forward Secrecy. Соответственно, нужно подобрать шифронаборы так, чтобы шифры с PFS использовались. Вы, к сожалению не указали, что там у Вас - апач, nginx, поэтому примеры конфигов с шифронаборами привести не могу.
    Ответ написан
    3 комментария
  • Как использовать шаблоны проектирования в работе (php + laravel)?

    ivankomolin
    @ivankomolin
    Использование паттернов зависит не от используемого фреймворка или языка программирования, а в большей степени от задач.
    Паттерны позволяют написать более эффективный код того или иного функционала с точки зрения дальнейшей поддержки.
    Есть хороший ресурс, на котором можно ознакомиться с основными встречающимися паттернами, а также разобраться когда их следует применять, а когда нет.
    https://refactoring.guru/ru/design-patterns
    Ответ написан
    Комментировать
  • PHP vs GOLANG, парсер, на чем писать?

    dasha_programmist
    @dasha_programmist
    ex Software Engineer at Reddit TS/React/GraphQL/Go
    Если выберешь Go то посмотри в сторону пакета goquery - jquery селекторы на go. Но мне кажется удобнее всего на js (node 8), в мастер-слэйв режиме, т.е. 1 инстанс рулит/балансирует, другие инстансы-воркеры занимаются непосредственно парсингом.
    Ответ написан
    Комментировать
  • Какие книги по SOLID принципам стоит прочитать?

    @resident
    Быстрая разработка программ. Принципы, примеры, практика

    https://www.ozon.ru/context/detail/id/1573723/

    Пусть не пугает год книги, она действительно стоящая.
    Ответ написан
    Комментировать
  • Как увеличить скорость разработки и внимательность?

    Dmitry_BPW
    @Dmitry_BPW
    Есть поговорка: быстро - это медленно, но без перерывов.
    Если будешь спешить, то непременно наделаешь ошибок. А у нас работа, которая требует точности. Поэтому грамотней будет организовать свой рабочий день и не отвлекаться во время забега. Есть хорошие техники тайм-менеджмента. Например, 45\15. 45 минут работаешь, на 15 отвлекаешься. В офисе так открыто отдохнуть не получится, но можно сделать вид, что занят, а самому парить в облаках)
    Внимательность нарабатывается с опытом. Люби своё дело и тогда не нужно будет на нём концентрироваться. Это произойдёт автоматически.
    И ещё. Выше писали про ноотропы - не надо. Оно того не стоит, поверь бывалому.
    Ответ написан
    1 комментарий
  • Как увеличить скорость разработки и внимательность?

    Xenobyte
    @Xenobyte
    Насчет внимательности: https://toster.ru/answer?answer_id=690893#comments...
    По поводу скорости разработки: попробуй поработать по методологии скрама (хоть она и для команды), в начале каждого спринта берешь задачи из бэклога, планируешь их на неделю, и смотришь что успеваешь сделать, запланированное тобой должно утвердиться заказчиком (начальником), пусть делит задачи на срочные и не очень, в конце спринта сдаешь ему. В течении спринта, каждый день отчет о том, что сделал вчера, что будешь делать сегодня.
    Ответ написан
    2 комментария
  • Как увеличить скорость разработки и внимательность?

    @itvsem
    Кто владеет информацией, тот владеет миром
    Выяснилось, что есть две загвоздки: скорость работы и внимательность.

    Не думаю, что медленно печатаешь и за окном птиц считаешь).

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

    Пол года работы в сфере, это наверно еще только начало пути и естественно, что скорость и внимательность к деталям приходят только с опытом(твои коллеги могут меня поправить). А опыт набирается от качества поставленных задач, их разнообразия и руководства(если ты не сам себе ставишь задачи). Если месяц пиликать только однообразные задачи, то у тебя будет ступор с выполнением других.
    Работодатель несёт ответственность за результаты твоей работы и в первую очередь перед заказчиком. И в его интересах, зная что у тебя мало опыта, если не ежедневно, то хотя бы раз в неделю садиться рядом с фразой: Ну показывай Никит, что мы тут "наговонокодили"). А не через два месяца поставить перед фактом, что ты медленно работаешь и внимательность хромает.
    Если диалог состоялся только в таком ключе, то внимательность хромает не только у тебя.

    Совет не от программиста:
    1. Постараться смотреть на задачи более глобально: а что будет если я тут изменю, на что повлияет, где задействовано еще?; а почему мы используем в разработке эти инструменты?; а почему они лучше?; а какие есть альтернативы?; а как оцениваются твои задачи и почему так?
    2. Возможно, если еще не брался, стоит пофрилансить немного в свободное время. Беря сначала знакомые и понятные задачи, чтобы набить руку, потом что-то новое и интересное.
    Ответ написан
    6 комментариев
  • Как использовать ооп на практике?

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

    Kyarginski
    @Kyarginski
    Добрый день!

    Со своей стороны порекомендую следующие книги:
    Ответ написан
    Комментировать
  • Книги по информационной архитектуре?

    dmitriylanets
    @dmitriylanets
    веб-разработчик
    Архитектура корпоративных программных приложений https://www.ozon.ru/context/detail/id/1616782/
    Ответ написан
    Комментировать
  • Что такое дзен программирование?

    @aresouji
    Конкретных примеров нет, но:

    1) Код должен быть понятен программисту
    2) Код должен быть закоментирован
    3) Код должен быть покрыт тестами (стремится к тотальному покрытию тестами всего кода)
    4) Код должен отвечать стандартам оформления кода
    5) Код должен следовать соответствующим принципам проектирования, самые известные из которых KISS, DRY, SOLID.

    Важно понимать, что термин true code весьма прозрачен, в нем нет конкретики и он не является каким-то стандартом. Решений может быть миллион и каждое из миллиона может быть хорошим.
    Ответ написан
    3 комментария
  • Что спрашивают на позицию middle/senior php?

    drcrazy
    @drcrazy
    Спрашивают начиная с азов, мало ли что ;)

    Из того, что явно подтверждает senior level в PHP:
    1) SPL
    2) Как работает PHP - opcode cache, garbage collection, zval
    3) ООП: интерфейсы, абстракты, доступ к их членам
    4) SOLID: расшифровать и объяснить каждую букву
    5) Паттерны, и их практическое применение
    Ответ написан
    7 комментариев
  • Как правильно использовать паттерны проектирования?

    Привет, автор. Вот мои мысли по этому поводу:
    1. Понимание паттернов программирования приходит только с опытом. Чтение одной лишь книги, без практики, практически ничего вам не даст. Материал быстро забудется. Лично я прочитал примерно половину книги, после чего пришлось её на время отложить. Как я и говорил - без тренировки на примерах материал быстро забылся. Вновь вспоминаться он стал при чтении книги "Принципы, паттерны и методики гибкой разработки на языке c#". В книге достаточно много подробных примеров, и именно после их выполнения я стал осознавать суть некоторых паттернов.
    Разумеется нельзя считать, что паттерн - это какое-либо строгое правило. Часть паттернов мы реализуем сами ещё до прочтения каких-либо книг. Паттерн - это возможное и удобное решение, которое можно применить для решения какой-либо задачи. Не надо пытаться заучить паттерны или вставлять их везде, где можно. Нужно просто писать как можно больше кода, тогда уже автоматически начинаешь видеть ситуации, где можно применить паттерн.
    2. По-поводу слабой связанности. Во всех книгах, разумеется, пишут, что слабая связанность - это хорошо. Но на самом деле такая архитектура не всегда оправдана, и специалисты в области разработки ПО об этом периодически напоминают. На практике это означает то, что не нужно везде применять интерфейсы только потому, что можно это делать. Если вы уверены, что ваши классы вряд ли будут когда-либо заменены другими, то лично я считаю, что они могут быть смело использованы друг-другом без принципа инверсии зависимостей. Ну и вопрос к модульному тестированию. Разумеется сильная связанность мешает модульному тестированию, но если вы не планируете его проводить, то быть может и не стоит строить избыточные абстракции.
    Лично я также считаю, что вышесказанной в меньшей степени справедливо для прикладных и вэб-приложений (где действительно важна модульность и тестировании), и в большей степени справедливо для игровых приложений. Лично я вообще с трудом представляю игру, в которой каждый игровой объект (танк, самолёт например) будет реализовывать интерфейс, чтобы теоретически когда-нибудь мы заменили танк на био-робота. Но это так, лирика.
    3. По-поводу повторного использования. Один мой товарищ - senior developer, работавший в серьёзных организациях, говорит, что повторное использование кода - это миф. Лично я повторно использовал разве что какие-нибудь вспомогательные функции. Ну или в лучшем случае несколько классов и интерфейсов для поддержки модульности. На мой взгляд, говорить о том, что можно взять и перенести из проекта в проект всю архитектуру особо не приходится.
    4. По-поводу контроллеров. Насколько я понимаю (опыт в разработке небольшой) основной смысл делать контроллеры зависимыми от интерфейсов только в том, чтобы тестировать эти контроллеры (хотя я не совсем понимаю зачем). Контроллер - это действительно такая вещь, которая с большой вероятностью будет использоваться только на конкретном сайте. Также этот контроллер будет завязан на какой-то интерфейс, предоставляющий бизнес-логику. Опять же вероятность, что один класс бизнес-логики будет заменён другим классом с такими же методами - стремится к нулю, особенно если учитывать то, что класс бизнес-логики зависит от интерфейса, который предоставляет методы получения данных. (если вы хотите изменить способ получения данных - вы изменяете, К примеру, класс репозитория, бизнес логика остаётся той же). В связи с этим я вижу пока только одну причину завязывать контроллеры на интерфейсы, а не конкретные классы бизнес-логики - это тестирование. Вы стабите интерфейс бизнес-логики и тестируете контроллер независимо от всех остальных модулей. Если не прав, поправьте, конечно.
    Ответ написан
    5 комментариев
  • Какой php фреймворк можно понять / разобрать полностью?

    @nozzy
    Symfony, Laravel, SQL
    Рекомендую начать с Silex, использует компоненты Symfony, очень простой для понимания.
    Будешь понимать как работает Symfony, Laravel и тд.
    Ответ написан
    Комментировать
  • Какой php фреймворк можно понять / разобрать полностью?

    Maksclub
    @Maksclub Куратор тега PHP
    maksfedorov.ru
    Прямо для вас, не пропустите...!

    PRS-7 фреймворк
    В серии видео полностью разбирается создание фреймворка,
    такого «универсала» по современым стандартам, последняя серия будет изо дня в день, все с тестами и плавно из одного решения в другое, смотреть на скорости 1.25


    Кишки фрейма:
    1. HTTP Response/Request PSR-7 (и компоненты для работы с ним)
    2. Построение контроллеров и роутинга (с переходом на Aura Router)
    3. Middlewear и Pipeline (а-ля Laravel, Slim, Symfony)
    4. DI контейнер (все фреймворки)
    5. Шаблонизаторы (+ пример на Twig из Symfony)
    6. ORM не точно
    Ответ написан
    8 комментариев