• Откуда информация о быстрой порче SSD?

    @Erelecano
    Админю сервера, починяю примуса.
    Байки из прошлого, которые повторяют недалекие люди.
    Для старых SSD байки про перезапись были справедливы, но это касалось самых первых SSD.
    SSD последних 4 лет надежней хардов. Я с 1 января 2013 года использую SSD в качестве основного системного диска, на нем же живет и своп. За это время я похоронил два жестких диска(один WD и один Toshiba), а SSD по прежнему живет и не кашляет.
    Ответ написан
  • Знания Junior php разработчика?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    что должен знать идеальный джуниор (мое личное мнение):

    - Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
    - GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
    - Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
    - PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
    - Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
    - Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
    - Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
    - Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
    - Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
    - Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
    - Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
    - Уметь дебажить. xdebug, blackfire и тд.

    В целом где-то за годик весь этот список можно влегкую покрыть с нуля.

    p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

    Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.
    Ответ написан
  • Как выбирать направление архитектуры ООП приложения?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    и как отдельный класс-синглтон


    Зачем? Зачем сингелтон? Ответте на вопрос когда это нужно?

    Есть ли практики, которым следует придерживаться, чтобы сделать правильную и простую архитектуру?


    - Разделение ответственности - важный принцип инженерного дела в принципе.
    - Принципы SOLID - хорошо дают понять как работать с зависимостями и делать декомпозицию системы. Сильно пересекается с инкапсуляцией, полиморфизмом и разделением ответственности.
    - Паттерны GRASP - эдакая смесь принципов и паттернов, описывают нюансы цикла жизни объектов и их взаимодействия друг с другом.
    - Закон Деметры - про инкапсуляцию.
    - CQRS - подход по разделению операций записи и операций чтения. Естественно подход такой не работает если вам надо реализовать атомарную запись и чтение, но это минимальный набор задач.
    - Рефакторинг. Он нужен всегда. Его нужно делать по чуть-чуть когда видно что "уже мешает" или "можно было сделать лучше". Ну то есть это не переписывание всего и вся большими кусками, а маленькие изменения которые с течением времени эволюционно меняют архитектуру проекта. Возможно только если код покрыт тестами, это отдельная жирная тема.

    Не нужно знать "архитектуры", они являются лишь результатом соблюдение принципов. И уж тем более "паттерны" это лишь элементы архитектуры. Не нужно на них зацикливаться, это лишь словарь.

    https://en.wikipedia.org/wiki/Category:Programming...
    Ответ написан
  • Где осуществлять валидацию пользовательского ввода в архитектуре MVC?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Давайте размышлять что такое валидация и зачем она нам нужна:

    Нам нужно проверять, не нарушаются ли пред-условия для действий или инварианты состояний. Например - пользователь всегда должен иметь email - такие правила можно запихивать на уровне конструктора класса пользователя. Тогда у нас не будет физически возможности "создать" пользователя не указав email. Что бы убедиться что переданная строка email - мы можем опять же завернуть "примитив" в свой тип Email, таким образов сделав подтип строк, который гарантирует нам, что любая штука относящаяся к этому типу будет являться email-ом.

    Такие правила как "у пользователя должен быть уникальный email" могут быть проверены только там, где достаточно информации. Например - некий репозиторий пользователей, или DAO. При попытке "сохранить" мы уже делаем проверку. Или мы можем делать это просто повесив ограничение на уникальность на уровне базы данных. Это уже не столь важно.

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

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

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

    Словом... тут нужно исходить не из "где это делается в MVC" а из "а кому это нужно и какие цели вы приследуете".

    Если что, MVC это не все приложение, это лишь способ разделить ответственность. Приложение ничего не должно знать о UI и все. То есть валидация входящих данных вполне может лежать на уровне контроллера поскольку это ему нужно сформировать список ошибок и запихнуть их к полям формы. С другой стороны, часть валидации может происходить вообще вне "MVC", где-то внутри, на уровне модели предметной области.

    Нельзя из букв "M", "V" и "C" составить слово вечность. Именно по этой причине MVC как подход для организации GUI уже лет 20 как не используется в чистом виде.
    Ответ написан
  • Где и как хранить тестовые сайты?

    @tagplus5
    Сервер на digitalocean
    - направляем на него домен *.site.com
    - каждый проект в своем docker контейнере со своим окружением
    - docker контейнер с nginx (прописываем поддомены)
    - контейнер/ы c бд.

    Разворачивать можно с помощью git ruhighload.com/post/Git+%D0%B4%D0%BB%D1%8F+%D1%80%...

    Если много новых проектов, можно сделать автосоздание поддомена для каждого нового контейнера.
    Ответ написан
  • Чем делать "домашние" backup'ы?

    dmitry-polushkin
    @dmitry-polushkin
    Инженер программного обеспечения
    Если есть несколько машин, то лучше поставить на них https://syncthing.net/
    Плюсы:

    1. Быстро - p2p протокол
    2. Надёжно - версионность
    3. Безопасность - стойкое шифрование
    4. Легко - установка за 5 минут даже 80 летним дедушкой
    5. Открыто - участвуйте в разработке / доработке
    6. Просто - есть веб интерфейс
    7. Дедубликация данных


    В общем, наш ответ: syncthing для домашних файлов.
    Ответ написан
  • Как эффективнее всего изучать yii2?

    @vkdv
    Прости что лезу не в свое дело, но мое мнение, что yii2 лучше вообще не изучать. Изучай Laravel/Symphony etc

    Приведу несколько аргументов (в сравнении с laravel):

    1) Yii2 довольно слабо следует принципам SOLID и более того, не предоставляет в достаточной мере архитектурного решения разработчику, чтобы он сам им следовал
    2) Yii2 Костылен, а его исходники мягко говоря не очень. Например behaviors (костыль) против middlware(прозрачное решение)
    3) Yii2 Имеет устаревшие сервисы из коробки относительно Laravel , который развивается куда более активно.
    Помимо прочего в Laravel намного больше готовых сервисов (Elixir , scheduling, Queue , Blade, Storage, Broadcast , Notifications) Вместо этого в yii2 есть только bower assets - который представляет с собой дикий костыль и откровенно ужасен, да еще и не безопасен, а также вроде в yii2 есть сервис для работы с файловой системой, но я с ним не работал. Остальные сервисы типа bootstrap , console etc есть и там и там
    4) Магия Yii2 не способствует контролю за кодом и прозрачности
    5) Yii2 имеет довольно плохо продуманную архитектуру, о чем говорит например тот факт, что jquery вшит в ядро фреймворка (возможно и некоторые другие ассеты) и это очень странно. Особенно когда тебе нужно запускать консольные приложения
    6) ActiveRecord в yii2 доволбно запутан, по сравнению с https://laravel.com/docs/5.3/queries (кончено это субъективно)
    7) Yii2 не особо популярен в мире, у него плохая документация и я думаю он серьезно отстоет от конкурентов.

    Есть конечно у него и плюсы, например он быстрее laravel и у него есть поддержка модулей(что решается в laravel подключением пакета)
    Ответ написан
  • Как эффективнее всего изучать yii2?

    slo_nik
    @slo_nik Куратор тега Yii
    Добрый день.
    Читать документацию, смотреть проекты на github, пытаться написать своё решение для какой-либо задачи....
    Вот несколько ссылок, которые Вам помогут:
    1) rmcreative.ru (блог одного из разработчиков yii2)
    2) https://github.com/samdark/yii2-cookbook (рецепты от того же разработчика)
    3) www.elisdn.ru/blog/tag/Yii2 (один из блогов, где можно учиться работать с yii2)
    4) https://github.com/yiisoft/yii2/tree/master/docs/g... (документация на русском от разработчиков yii2)
    Ответ написан
  • Как подходить к решению нетривиальных задач?

    Привет.

    Всегда использую модель боли:

    1) Смотришь задачу
    2) Пытаешься её решить
    3) Понимаешь, что ты тупой идиот, который ничего не может.
    4) Поднимаешь в помощь гугл
    5) Поднимаешь в помощь литературу
    6) Спрашиваешь ребят на тему: "почему так, а не иначе".
    7) Выполняешь задание, осознавая, что ты тупой, раз на решение этой задачи тебе пришлось потратить столько времени.

    Повторить до бесконечности, и ты станешь профи.
    Ответ написан
  • Как правильно управлять парком серверов Unix?

    @dyasny
    1. во первых не стоит городить зоопарк дистров, надо остановиться на одном и использовать его везде. А дальше для обновлений есть куча варинтов, от yum-updatesd, до ansible yum: name="*" state=latest и до satellite/spacewalk и т.п. Там управление уже не только уровнем апдейтов но и их разновидностями ()безопасность, системное ПО, приложения и т.д.
    2. IPA закрывает все эти вопросы.
    3. тоже IPA, хотя можно прикрутить любой LDAP или NIS
    4. так же как и в винде - проверяемся на тестовом стенде перед запуском апдейтов в продакшен. еще можно снять lvm snapshot, накатить, и откатиться если что, но это потребует даунтайм.
    Ответ написан
  • Как правильно управлять парком серверов Unix?

    igortiunov
    @igortiunov
    Приветствую.
    Прежде всего, не стоит представлять себе решение задачи, как "большую кнопку", т.к. наши представления об управлении инфраструкурой несколько извращены опытом работы с продуктами MS. Интерфейс скрывает от нас стек ПО используемого для достижения цели. Например, WSUS. Под его капотом находится набор служб, каждая из которых играет определенную роль - bits для загрузки на сервер и доставки пакетов на клиента, веб-сервер для управляющих команд, база данных для хранения состояния клиентов и исправлений, .net приложение, обьединяющее все это. Для парка nix машин вам предстоит построить подобную архитектуру самому, выбирая каждый раз инструмент, который будет играть ту или иную роль.
    На втором шаге вам нужно посмотреть на задачу. Если у вас десяток инфраструктурных серверов, то Ansible действительно неплохой выбор. Но только не "скрипт". "Скрипт" - это язык, который говорит как достичь результата. Но инструменты управления конфигурацией избавляют вас от этого, с помощью декларативного языка вы описываете сам конечный результат(это ключевой момент) и не задумывайтесь о том, какой дистрибутив (читай менеджер пакетов, расположение конфигурационного файла) установлен на управляемой системе.
    Если вам нужно дать доступ большому количеству пользователей к большому количеству машин, то на первом шаге вам нужно выбрать два инструмента:
    1. управление конфигурацией.
    2. управление sudo.
    Первый инструмент с натяжкой может предоставить вам возможность решить пункт 2, т.к. в этом втором пункте вам нужно управлять теми самыми политиками: группе пользователей дать доступ на группу машин и разрешить выполнять группу команд. Здесь в игру вступает Identity Manager и этот вопрос для меня по крайней мере, открыт. Текущие тенденции ведут к развертыванию двух каталогов (MS AD и каталог для парка NIX), но не берусь сказать насколько это правильно. Обойтись без второго каталога можно и, если отбросить шелуху, то ключевой проблемой, в таком случае, является сопоставление идентификаторов безопасности пользователей в MS AD и в nix системах (просто когда один домен, сложнее когда лес, совсем не просто в случае созданных вручную доверительных отношений). Раньше этот вопрос решал winbind с набором библиотек, реализующих тот или иной алгоритм сопоставления, теперь это SSSD, реализующий два алгоритма. Опять же вопрос с выполнением привилегированных команд в такой конфигурации не решается. RedHat предлагает скомпанованные в единый продукт инструменты, которые, якобы эти задачи решают. Поддержкак от этого самого редахата стоит бешеных для нас денег, но вы посмотрите из чего состоят такие решения как Sattelit и IdM, это открытые продукты (FreeIPA, candlepin, pulp, katello, puppet и, наконец, foreman.) которые, возможно вам и нужны.
    Ответ написан
  • Как правильно управлять парком серверов Unix?

    @bankinobi
    как происходит обновление в линукс, если в сети есть разные версии линукса, редхат, дебиан, с разными версиями ядра, по.?

    сначало на тесте, потом на продакшене.
    yum update/upgrade
    apt-get update/upgrade
    допустим крутиться сервер, выпустили обновление, стоит ли обновлять ядро? ведь при обновлении есть вероятность что не будет работать субд.

    для этого есть тестовые сервера, на котором проверяются обновления для ОС и СУБД.
    лдап, имитация АД, это костыль.

    почему считаете, что лдап - это костыль? Потому что не от MSofta?
    Тот же 389 Directory Server ведет историю с 1995 года.
    Имеет довольно продвинутый web- и cmd-интерфейсы с достаточным функционалом.

    А что б получить дружественный ответ, надо задавать дружественный вопрос.
    Ответ написан
  • Как удобнее классифицировать(законспектировать) то, что выучил?

    @Ko1
    Мной проверенный способ сделать майнд-карту, структурируется и запоминается легко. В общем в одном посте очень сложно объяснить какая мощная вещь, майнд-карты, если вам интересны инструменты, то используйте XMind, его возможностей мне достаточно. Лично я использую из для учебы в университете и для самообучения, очень хорошо помогает структурировать инфу.
    Ответ написан
  • Оптимизация nginx, php-fpm, postgresql под высокую нагрузку?

    @eoffsock
    Кодер (Rails)
    По postgresql есть хорошая вещь: postgresql.leopard.in.ua

    По остальному есть вот материал: ruhighload.com/server
    Там постольку поскольку, конечно, но может найтись полезное.

    По php я думаю тут еще подскажут, тут я не спец.
    Ответ написан
  • Как анализировать вакансии front/-backend разработчиков?

    Забей.
    Я сейчас работаю на должности фронт енд где было указано, что нужен angular (я его знать не знаю). И ничего, работаю, пишу велосипеды, всех всё устраивает.
    Ответ написан
  • Как анализировать вакансии front/-backend разработчиков?

    DevMan
    @DevMan Куратор тега Карьера
    не стоит удивляться: в таких вакансиях расставляют требования точно так же как и вы теги к своему вопросу.
    Ответ написан
  • Как анализировать вакансии front/-backend разработчиков?

    opium
    @opium
    Просто люблю качественно работать
    семи пядей во лбу не надо иметь чтобы понять
    1)нужен опыт работы с реляционной бд, запросы на работе не сложные и подойдет любая из перечисленных, зная один писать запросы можно под любой
    2)нужен опыт программирования под джаву в одной из этих иде так как разработчики в компании используют их а не нетбинс
    3)нужен опыт работы с системами контроля версий, скорее всего есть легаси проекты используюбщие свн и все новые проекты на гите. знаю один второй освоить не проблема
    Ответ написан