• Как на php проверить валидность SSL?

    zorca
    @zorca
    <?php
    $g = stream_context_create (array("ssl" => array("capture_peer_cert" => true)));
    $r = fopen("https://www.google.com/", "rb", false, $g);
    $cert = stream_context_get_params($r);
    $certinfo = openssl_x509_parse($cert['options']['ssl']['peer_certificate']);
    echo "Certificate info: <pre>". print_r($certinfo, true) ."</pre>";
    Ответ написан
    Комментировать
  • Как в linux узнать какой именно процесс попал в swap

    lirvux
    @lirvux
    в top:
    жмем f — появляется настройка колонок для вывода
    жмем p — включаем колонку со свопом.

    в htop:
    жмем f2, идем в columns, два раза в право, выбираем nswap и жмем f5
    Ответ написан
    3 комментария
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    go3l337
    @go3l337
    После прочтения все вопросы должны отпасть, для практики попробуй разобраться в архитектуре фреймворка, Yii например,
    Ответ написан
    3 комментария
  • PHP vs. all. Имеет ли смысл учить (параллельно) что-то еще?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    но код, особенно после C++, не вызывает каких-то положительных эмоций.

    А у меня не вызывает положительных эмоций код на C++. Да и код разный бывает. 90% кода на PHP у меня так же не вызывают положительных эмоций, но писать на нем нормально более чем можно.

    1) под фразой "php умирает" позразумевает его модель работы. После каждого запроса он умирает, то есть воркер отчищается и запускается по сути заного. Это существенно упрощает работу (у вас хоть сегфлоты могут быть всеравно весь сервак не умрет), а так же масштабирование (за счет отсутствия у самого PHP состояния между запросами, сессии мы не берем в расчет), но существенно бьет по производительности. К счастью с PHP 5.3 писать демоны на PHP не так уж страшно.

    Если же посмотреть рынок и динамику развития сообщества - PHP живее всех живых.

    2) PHP не такой уж стремный язык. Я не считаю "не консистентные названия функций" таким уж прям фактором влияющим на выбор языка. С моей точки зрения Ruby уродливая отрыжка, попытка сделать объектно-ориентированный перл (это лично мое мнение, мне не приятно работать с ruby, пусть меня за это простят), но за счет того, насколько сообщество ruby-разработчиков ценит и понимает цели бизнеса, насколько уважает тестирование своих решений и т.д... словом PHP комьюнити в этом плане еще расти и расти. Но прогресс виден.

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

    3) нет. Шансов на нормальном уровне с нуля изучить еще один язык программирования и к тому же фреймворк - почти нет. Да и в этом нет смысла.

    4) судя по вопросу вы уже определились для себя. Дальнейшая дискуссия не имеет смысла. Разбирайтесь. Но если брать шаред хостинги то PHP это пожалуй единственный адекватный вариант на сегодняшний день (если не брать в расчет что шаред хостинги как таковые это не очень адекватный вариант).

    5) все зависит от вас. Хорошие разработчики зарабатывают примерно одинаково вне зависимости на каком языке программирования они работают. Они просто хорошие разработчики и таких всегда мало.

    6) как хотите.

    И так...

    Язык программирования - это лишь инструмент для решения задач. Фреймворки - это так же просто инструменты для решения задач. Что важно - уметь задачи решать. И решать эффективно. Понимать что кривыми решениями вы увеличиваете риски для бизнеса.

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

    Ruby например бизнес (и стартапы в особенности) выбирает не потому что это хороший язык, а потому что Ruby комьюнити в среднем больше приспособлено для эффективного решения задач бизнеса. Что говорить когда у них любовь тестирования прививают с первых дней знакомства с языком?

    Не учите язык программирования. Учитесь разработке с применением этого языка. И тогда все будет намного проще.

    p.s. Haters gonna hate
    Ответ написан
    4 комментария
  • Насколько "быдлокодерским" подходом является хранение сериализованных массивов в SQL?

    Весьма глупо оценивать "говнокодерность" вашего подхода только потому, что вы храните массив в ненормализованном виде. Чтобы это увидеть, достаточно вспомнить само понятие нормализованных данных и подумать о его сути. Вот вам пример в лоб: вы же почему-то не говорите, что хранить строку в БД это плохо. А ее, в теории, можно представить как массив символов и нормализовать так, что одна строка некоторой таблицы будет хрнить ОДИН символ. Чушь, скажете вы? Да, для большинства задач это чушь (хотя, возможно не для всех). Просто потому, что НИКОМУ не нужно извлекать из базы ЧАСТЬ строки, какое-либ подмножество ее символов. В большинстве задач строка берется как атомарное (!) значение и именно _поэтому_ ее никто не пытается хранить посимвольно. У нас есть лишь один полезный критерий - что для вашей задачи есть атомарные значения? Все. Если вы ваш массив всегда будуте записывать и извлекать сразу целиком, то и хранить его как единственное значение в поле одной записи - совершенно не проблема.
    Почему-то все считают, что пока не нормализуешь "до чертиков", спроектированная база никуда не годится. Да, конечно нормализация важна, есть смысл даже нормализовать "с запасом", как уже сказали выше - на случай, если какие-то данные впоследствии также будут фильтроваться и обрабатываться на уровне БД с помощью SQL. Однако если вы четко осознаете, что в ближайшем будущем вы не собираетесь работать с массивом поэлементно (на уровне SQL), то хранить его целиком пойдет только пользу.
    Все же юзают JSON и XML-типы данных в SQL базах, и ничего. И блобы юзают. Потому что если проектировщик знает, что планируется обрабатывать в запросах, а что - нет, то он знает и до какой степени нужно нормализовать данные.
    trevoga_su привел великолепный пример с конфигом пользователя. Зачем пытаться его навороченную структуру (например, иерархическую) спроецировать на реляционную БД, если проще хранить его в естественном виде (JSON/XML/plaintext) и писать в БД целиком?
    P.S. Массив кстати можно хранить не в текстовом виде, а в двоичном в BLOB-е, тогда и места займет меньше, и никаких вопросов с кодировками.
    Ответ написан
    1 комментарий
  • Какую литературу выбрать для глобального понимания, как работают ЯП и компьютер?

    @Kyberman
    "Архитектура компьютера" Таненбаума
    Ответ написан
    Комментировать
  • Какой шаблонизатор взять для нового проекта на php?

    Хороший шаблонизатор, идеально интегрирующийся с PHP называется… PHP :) В шаблонах удобно использование альтернативного синтаксиса.
    Ответ написан
    4 комментария