• Верстка писем. В чем нюанс?

    Raxen
    @Raxen
    TechLead Frontend Developer, Beeline
    Это старая известная фишка gmail, он адаптирует письма по своей никому неизвестной логике.
    Есть два способа решить этот момент: костыльный и геморройный
    1. Костыльный -
    В конце письма делаем невидимый блок на всю ширину письма (700пкс)
    <div align="center" style="display:none;text-align:center;white-space:nowrap;font:15px courier;color:#f3f3f5">- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -</div>

    2. Геморройный -
    Необходимо ко всем элементам, который gmail адаптирует (в основном блоки с текстом) прописать размер шрифта в !important и переносы убрать - white-space: nowrap;
    Буржуины предлагают еще способ использовать прозрачную картинку -
    <style>
    @media only screen and (max-width: 600px) {
      *[class="gmail-fix"] {
        display: none !important;
      }
    }
    </style>
    <tr class="gmail-fix">
        <td>
          <table cellpadding="0" cellspacing="0" border="0" align="center" width="600">
            <tr>
              <td cellpadding="0" cellspacing="0" border="0" height="1"; style="line-height: 1px; min-width: 600px;">
                <img src="spacer.gif" width="600" height="1" style="display: block; max-height: 1px; min-height: 1px; min-width: 600px; width: 600px;"/>
                </td>
              </tr>
          </table>
        </td>
      </tr>

    Последний не проверял, но есть у меня мнение, что gmail выпиливает css код в тегах < style >
    Ответ написан
    1 комментарий
  • Как назвать изображения в БД?

    dizballanze
    @dizballanze
    Software developer at Yandex
    Чем меньше храните - тем проще будет что-то переделать.
    Чем больше храните - тем меньше логики для генерации полного урла.
    Мне кажется лучше всего хранить или только навание файла или название файла + название сгенерированных директорий (если изображения шардятся по папкам 01/some_img.jpg).
    Ответ написан
    2 комментария
  • Как вывести картинки в php?

    В любой непонятной ситуации делай var_dump(); :)=)
    Ответ написан
    1 комментарий
  • Как на bash переименовать все .txt файлы в папке?

    Scorpi
    @Scorpi
    for file in *.txt
    do
      mv "$file" "new_name"
    done
    Ответ написан
    Комментировать
  • Есть ли подводный камень у данной конструкции?

    в первом варианте по-любому надо скобки.

    второй вообще hernia какая-то.

    вообще достаточно часто используется тернарный оператор, типа
    $x = isset($x) ? $x : $default;

    ну, это если не получается использовать параметр по умолчанию в сигнатуре функции.
    Ответ написан
  • Как вникнуть в тонкости back end разработки?

    Stac
    @Stac
    Серверные скрипты в своем простейшем случае (PHP, Perl, CGI-скрипты на любых других языках) весьма похожи на неинтерактивные консольные программы (утилиты командной строки).

    Они принимают данные на вход через заголовки и тело HTTP-запроса, что-то быстро делают и выводят результат [в браузер].

    PHP или CGI-скрипт вызывается вебсервером (программой) в процессе отбработки входящего запроса (request) . Он же получает результат работы скрипта и фактичеки возвращает браузеру в ответном HTTP-запросе (response).

    HTTP-запросы это чистый текст с минимальной структурой, с которой имеет смысл ознакомиться.

    В некоторых технологических стеках сама прикладная программа и является вебсервером (например, node.js и Ruby On Rails - впрочем, не влададею эти технологиями, могу ошибаться).
    Но даже в этом случае прикладной программист не работает пакетами и битами (может, если захочет, но на практике это не нужно).

    Прикладная среда выполнения (вебсервер или фреймфорк), приняв запрос, дает программисту доступ к его элементам через глобальные переменные или объекты, в зависимости от того, как принято в конкретном языке программирования.
    Для PHP это глобальные переменные (ассоциативные массивы) $_SERVER, $_REQUEST и др. В первой можно найти некоторые HTTP-заголовки, кое-какие данные о сервере и удаленном клиенте (IP адрес, например). Во второй собраны все входные данные, переданные через URL (site.ru/page.php?key=value&key2=value2), в теле POST запроса, через куки (фактически HTTP-заголовки специального формата) и переменные окружения [операционной системы].

    Различные фреймворки могут иметь классы и объекты с именами типа Request.

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

    Если данных очень много и их не просто надо читать, но для начала найти какие-то фрагменты (конкретные строки таблицы, поля объекта) по каким-то критериям, а потом, возможно, как-то обработать, то можно использовать СУБД.

    СУБД бывают встроенные и клиент-серврные.
    Пример встроенной это SQLITE, которая встроена в PHP как модуль расширения. Она также используется в iOS, Android, браузерах Firefox, Chrome и многих-многих других программах.

    Клиент-серверные чаще всего это MySQL (даже чаще чем надо), PostreSQL, MS SQL Server, Mongo DB, есть куча других.

    Серверная часть такой СУБД работает как отдельный сервер (программа), возможно на отдельном сервере (компьютере). Клиентская часть это модуль в среде исполнения (расшириние PHP, библиотека функций) или может условно отсутствовать, если СУБД имеет HTTP API. В этом случае клиентскую часть пишет прикладной программист на своем языке.

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

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

    Все операции на сервере происходят по необходимости, мы открываем соединение с БД по необходимости, принимаем запрос по необходимости, говорим что переменая имеет тип int unsigned исходя из необходимости.


    Нет какой-то абстрактной необходимости. Первопричина всего (на прикладном уровне) - входящий запрос. Вебсервер ожидает постоянно входящие запросы (слушает TCP-порт).
    Вот запрос пришел. Сервер согласно своим настройкам определяет, может ли он сам его обработать (например, "отдать статику") или он должен передать запрос другому обработчику по цепочке. Таким обработчиком может быть, например, PHP.
    Вебсервер запускает интерпретатор PHP и передает запрос ему.
    PHP определяет (в общем, по ссылке, которая есть в параметрах запроса), какой PHP-скрипт надо выполнить, ищет его и выполняет. Результат работы скрипта - HTTP-response (фактичеки это plain text, содержащий служебные заголовки, в т.ч. куки и тело с HTML / XML / JSON, etc. ) - отдается обратно вебсерверу, он возвращает его туда, откуда пришел запрос (на IP адрес и порт), часто в браузер.

    В других технологических стеках алгоритм обработки HTTP-запроса может отличаться от описанного. Как правило, чем больше он отличается, тем лучше этот стек, чем PHP (в смысле производительности).

    Мы, прикладные программисты, не опускаемся ниже HTTP-протокола. А используя фреймворки, даже HTTP можем не касаться, хотя знать и понимать его надо.
    Т.е. до всех этих TCP-портов и настроек сервера нам, как праивило, дела нет (пока все работает).
    Первое - удел скорее системных программистов, второе - сисадминов или модных ныне девопсов.

    Что почитать, чтобы лучше понять операции на бэке, которые не поймешь сразу ...


    Еща раз-два прочтите мой ответ. Если не помогло - возьмите любую книжку по PHP. В начале должно быть описано взаимодействие браузера и вебсервера. Потом и про язык можно чуть-чуть почичать.

    Сейчас PHP все еще самый простой путь в back-end разработку. А раз вы упоминаете про int unsigned, то вам будет привычен и его Си-подобный синтаксис. Типа данных такого, однако, в PHP нет.
    Ответ написан
    2 комментария
  • Что такое полиморфные связи?

    greabock
    @greabock
    Могу
    Предположим, что у Вас есть комментарий, который может относится к посту(пользователя), а может относится к статье блога.
    тогда у Вас таблица может выглядеть примерно так:
    comment_id | parent_id | morph| comment_content | author

    где:
    comment_id - идентификатор самого коммента
    parent_id - идентификатор сущности к которой он относится
    morph - тип сущности, к которой относится этот комментарий.
    comment_content, author - тут я думаю понятно
    тогда записи могут выглядеть так:
    comment_id | parent_id | morph   | comment_content | author
    ---------------------------------------------------------------
      1        |   1       | post    | бла бла бла     | vasya
    ---------------------------------------------------------------
      2        |   1       | article | бла бла бла     | vasya
    ---------------------------------------------------------------

    при чем, несмтря на то, что parent_id у них одинаковый, в первом случае он относится к id в таблице post, а во втором к article
    Это и называется полиморфической связью.

    пример приведу на фреймворке laravel для php (но ORM там очень схож с Rails, так-что проблем возникнуть не должно)
    Модель комментария будет выглядеть приблизительно так:

    class Comment extends Eloquent {
    
     public function morph()
      {
         return $this->morphTo();
      }
    
    }

    а модели поста и статьи:

    class Post extends Eloquent {
    
      public function photos()
      {
        return $this->morphMany('post', 'morph');
      }
    
    }

    class Article extends Eloquent {
    
      public function photos()
      {
        return $this->morphMany('article', 'morph');
      }
    
    }

    вроде бы ничего не напутал...
    Ответ написан
    1 комментарий
  • Что такое полиморфные связи?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    habrahabr.ru/post/79431 - читаем и осознаем примеры.

    По сути это все тоже старое доброе наследование, когда у нас несколько типов записей хранятся в одной таблице и разделаются полем type. Можно в нескольких таблицах хранить и общие поля в базовую таблицу выносить... суть примерно в этом.
    Ответ написан
    4 комментария