Задать вопрос
  • Как не заплыть жиром, работая удаленно программистом?

    akubintsev
    @akubintsev
    Опытный backend разработчик
    Я уже более 2-х лет активно тренируюсь и могу поделиться опытом.

    Спортзал - штука очень спорная. Я не верю в то, что можно заниматься бесконечно долго по одной и той же схеме без утомления. В моём случае получался такой расклад, чтобы пойти потренироваться:
    - собрать сумку с необходимыми вещами для тренировки
    - добраться до спортзала
    - переодеться
    Только на этот этап можно потратить порядка часа.
    Далее сама тренировка около 1 часа.
    Затем душ, переодевание и обратный путь и вынуть просушиться вещи - ещё час.

    Итого: чтобы потренироваться пойти в спортзал нужно заложить 3 часа времени. А если ещё график не очень гибкий, то можно и в час пик попасть, когда зал переполнен и это вызывает неудобства из-за плотного графика упражнений.

    Лучше всего ориентироваться на домашние и уличные тренировки. Плюс тут несомненный в том, что как только появилось желание подвигаться - пошёл и поделал упражнения. Ещё один: можно делать несколько тренировок в день с минимальными затратами времени.

    Главный секрет поддержания интереса к тренировкам - научиться получать удовольствие от них. Для этого нужна непринужденная атмосфера и медленное сосредоточенное выполнение.

    Есть замечательная книжка Пола Уейда "Тренировка заключенных", где очень системно описаны группы упражнений для любого уровня подготовленности и практически в любых окружающих условиях.

    Но это только то, что касается силового тренинга.
    Я считаю, что есть смысл хотя бы 1-2 раза в неделю выполнять аэробную тренировку: бег, велосипед и т.п. В спортзале это делать чрезвычайно быстро надоедает - вокруг только серые стены, никакой реальной движухи. Через месяц уже тошно становится от беговой дорожки или велотренажера.

    Наверное еще добавлю, что на первых порах очень важно придерживаться плана тренировок. Это касается и графика по дням недели, и по составу. Где-нибудь через полгода-год можно уже импровизировать.

    Что касается питания. На мой взгляд самой прогрессивной диетой сегодня является LCHF. Суть сводится к уменьшению потребления быстрых и медленных углеводов до нуля, а калорийность обеспечивать жиром. Соответственно, белок само собой тоже нужен. Хороша она тем, что организм не ощущает каких-то лишений, голода нет. Жиры очень долго расщепляются, а без углеводов излишки будут выводиться организмом, вместо переноса в жировую ткань.
    Градации потребления пищи в зависимости от времени суток считаю профанацией. Можно разве что избегать питания тяжелой пищей менее, чем за 2 часа до сна.
    Ответ написан
    9 комментариев
  • Расскажите про лучшие практики построения простых веб приложений на PHP+JS+jQuery?

    @egorinsk
    AJAX-приложения делаются не так и давно, потому найти собранные воедино best practices не так-то просто. Многие наработки просто не выложены в паблик, а используются разработчиками для каких-то своих проектов. Потому надо проявить старание и разобраться самому.

    Сначала посмотрите на то, что делают другие. Но здесь важно не брать плохие примеры (например, монстров типа Zend Framework и ExtJS. jQueryUI, кстати тоже уродливая вещь — вы его исходники смотрели?) Посмотрите, как написан клайентсайд у вконтакта. Посмотрите у фейсбука (хотя там код пожат, но разобраться можно). Посмотрите библиотеку Zforms. Посмотрите Google Closure Library (у Гугла есть чему поучиться, особенно в плане организации кода, посмотрите обязательно).

    Вообще, смотреть чужой код полезно. он не всегда хорошо написан, но даже в этом случае — это повод для размышлений на тему «а как правильно?».

    Теперь о теории. При построении более-менее сложных AJAX-приложений приходится решать примерно те же проблемы, что и на серверной части, а именно:

    — разделение кода на слабосвязанные компоненты (чтобы, меняя один из них, не ломать все остальное). Сюда входит как организация 3-звенной архитектуры (например, MVC), так и разбиение на модули, динамическая подгрузка модулей (посмотрите yepnope.js и сделайте то же, но проще). Выбор средства взаимодействия модулей — Dependency Injection или система событий (паттерн Observer). Мне больше нравится Observer.

    — организация хранилища данных — нужен какой-то модуль для получения данных с сервера с кешированием, проверкой актуальности, возможно с блокировками и нотификацией об изменениях. Посмотрите, например, как ведет себя Гугл Докс если открыть в 2 окнах 1 документ и править его. Нужна серверная половинка для приема/валидации/выдачи данных.

    — организация View: это решение вопроса о выборе шаблонов (jQuery Templates для начинающего — вполне пойдут), создание системы виджетов (чтобы например можно было вставить виджет графика в виджет формы и все работало) — я не знаю, правда, ни одной нормальной библиотеки виджетов, пишите сами.

    — роутер и контроллер — ну это элементарно пишется без всяких библиотек. Не знаете, как — посмотрите, как сделано у вконтакта.

    — повторное использование кода — копипаст недопустим.

    Также, есть проблемы специфичные именно для клиентсайда:

    — необходимость уменьшения числа запросов (неправильно: грузим диалог, обнаруживаем, что ему нужны CSS и JS файлы и грузим их) — лучше это делать одним запросом. То же про запросы к хранилищу: выбирайте все одним запросом. Несколько AJAX-запросов — это треш и ужас, особенно при пинге 100-200 мс.

    — необходимость минимизации объема и скорости работы JS-кода. Ради нее надо отказываться от тяжелых/перегруженных библиотек типа ExtJS, kendo и jQueryUI.

    — склеивание/сжатие JS файлов — элементарщина, можно склеивать хоть bash-скриптами (или make), плюс можно применить тулзы типа Google Closure Compiler. Разберитесь, как они работают.

    — необходимость создания адаптивной верстки — для этого есть библиотеки типа Modernizr, но по моему, это перегруженный монстр. Мне, например, хватает простого инлайн-скрипта, включаемого сразу после body, который ставит классы with/without-js, with-css3, with-ie, в итоге пользователи современных браузеров экономят трафик и видят rounded corners и CSS gradients, а пользователи ИЕ скачивают их в виде картинок.

    А, вот скрипт, если кому интересно: paste2.org/p/1947136

    — необходимость поддержки навигации средствами браузера — посмотрите библиотеку history.js (хотя имхо, ее тоже стоило бы урезать раза в 2-3, там много лишнего).

    Ну и для закрепления знаний нужна естественно практика.

    Напишите

    1) свой грид (грид — это в данном случае виджет, который отображает в виде таблицы какие-то данные), с сортировкой, фильтром и постраничным просмотром. Все должно работать через AJAX (а если яваскрипт отключен, то классическим методом). Если таблица помещается на экран без постраничной навигации, сортировки и фильтрация должны выполняться 100% на клиенте. Добавьте кеширование (при открытии уже закешированных данных они отображаются из кеша и посылается запрос на проверку их актуальности).

    2) Сделайте форму редактирования/добавления данных в этот грид с валидацией.

    3) А теперь сделайте так, чтобы он работал при пропадающем интернете (то есть, вы добавляете какие-то данные, они сохраняются, выживают при закрытии браузера и отправляются, когда соединение восстанавливается)

    4) если не испытываете отрицательных эмоций по отношению к вконтакту — решите эту задачу: vk.com/page-1_42054413. Она хорошо подходит для отработки навыков разработки AJAX-приложений.

    Что касается PHP, в AJAX-приложении он просто служит бекендом и умным хранилищем данных, не более. Слепите простейший ORM, его вполне хватит.

    P.S. И никогда не повтоярйте ошибок, которые делают косолапые разработчики Хабра. Размер textarea для комментариев должен вмещать минимум 20-25 строк.
    Ответ написан
    1 комментарий
  • Корректно ли использовать SVG, закодированные в base64?

    Moskus
    @Moskus
    Если вы говорите об использовании схемы data:uri , то вопрос тут не в "корректности", а в производительности, а также том, для чего вообще вы это делаете.
    Собственно, вероятность того, что это не будет работать, определяется а) поддержкой data:uri самим browser-ом caniuse.com/#feat=datauri и б) поддержкой SVG caniuse.com/#feat=svg
    Вопрос "где хранится" - непонятен. Если вы уже вставили закодированную картинку в CSS или HTML, то там она и хранится.
    Имейте в виду, что если вы не предъявляете каких-то специальных требований к работе страниц, лучше не использовать это, потому что оно только сильнее все тормозит.
    Специальные требования могут включать в себя полную переносимость страницы (т.е. отсутствие внешних ссылок, когда абсолютно все, от самого HTML до скриптов, стилей и картинок, хранится в одном файле), какие-то особые условия, связанные с HTTP-запросами (экзотические настройки сервера, который отдает один запрос одному клиенту, но по широкому каналу, например) и так далее. Иногда это можно использовать для каких-то совсем маленьких элементов, когда есть риск, что сервер отдаст их последними, а без них рушится все отображение.

    Я эти фокусы использовал в свое время только для формирования бланков, которые пользователь мог бы сохранять и смотреть оффлайн. Некая замена PDF.
    Ответ написан
    2 комментария
  • Как перевести Unified строку в символ юникода (emoji)?

    standy
    @standy
    1. Вы можете использовать этот символ как есть: "" (с дефолтным шрифтом символ не видно, но он есть)

    2. В строках javascript можно использовать юникод символы в виде "\u25B2", где после \u идет ровно 4 символа. Так как символ юникода "1f606" находится в расширенной области, и кодируется так называемой суррогатной парой.
    Вот из этой статьи (Parsing emoji Unicode in JavaScript) я нашел такой метод, для поиска суррогатных пар:
    function findSurrogatePair(point) {
      // assumes point > 0xffff
      var offset = point - 0x10000,
          lead = 0xd800 + (offset >> 10),
          trail = 0xdc00 + (offset & 0x3ff);
      return [lead.toString(16), trail.toString(16)];
    }
    
    // find pair for U+1F600
    findSurrogatePair(0x1f600); // ["d83d", "de00"]
    
    // ваш символ:
    findSurrogatePair(0x1f606); // ["d83d", "de06"]

    Так что ваш символ можно записать как "\ud83d\ude06"

    Далее требуется заменить последовательность "1f606" на наш символ, это легко делается командой
    string.replace(/1f606/g, "\ud83d\ude06");
    Ответ написан
    1 комментарий
  • Что быстрее и менее нагруженно JOIN или WHERE IN?

    @1001001
    EXPLAIN вам в помощь. Вероятно план запроса будет одинаков.
    Ответ написан
    1 комментарий
  • Nginx Как сделать мобильную версию сайта?

    @criminalist
    Ага послушал советчика вроде Вас, теперь делаю третий шаблон потому что адаптивная верстка оказалось очень тяжелой и поисковики отказались ее принимать, но это уже отдельный разговор.
    Я понял что нужны отдельные версии мобильная и для пк.
    Ответ написан
    Комментировать
  • Веб сервер под фото. Какую архитектуру хранения выбрать с учетом масштабирования?

    @reallord
    Если миграция фото не предполагается, то Ваш вариант вполне надежен. При массовой миграции с сервера на сервер надо будет только сделать UPDATE колонки с названием сервера.

    Если надо удалять/перемещать/добавлять файлы между серверами, то надо еще писать обработчик, котороый следит за местом на серверах и приоретизирует запись текущей фотки на нужный сервер на котором низкая загрузка IO и есть место. Аля балансировщик нагрузки.
    Ответ написан
    3 комментария
  • Веб сервер под фото. Какую архитектуру хранения выбрать с учетом масштабирования?

    SashokSmir
    @SashokSmir
    Инженер
    Лучше сделать немного иначе. Сделать узел — входной узел для статики. Этот входной узел требует мало ресурсов, но позволит сделать интерфейс для всей вашей системы, с помощью которого вы избежите многих проблем в будете и сможете легко масштабироваться.

    Все запросы на доступ к статическим файлам нужно отправлять на этот узел, например, files.example.com. Тот, кто отправлят запрос даже не знает на каком сервере и т.д. находится файл и ему это не нужно знать.

    Именно этот узел ведет учет файлов и знает на каком именно сервере у вас находится файл. Ваше приложение (сайт) посылает запрос на узел (files.example.com) на доступ к определенному файлу и этот узел смотрит у себя в базе где именно находится этот файл (на каком сервере и по какому адресу) и в ответ отдает этот адрес, например, srv01.files.example.com/f/405/502.jpg

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

    В будущем для надежности можно сделать зеркальные узлы.
    Ответ написан
    1 комментарий
  • Статичный IP дома под веб сервер. Как настроить? Нужен ли проброс портов?

    TrueBers
    @TrueBers
    Гуглю за еду
    В случае с IPv4, на компе вы получите только адрес внутренней сети. Внешний на комп можно получить, если провайдер выдаёт IPv6-префиксы. Префикс можно анонсировать и раздавать любым устройствам.
    На роутере у вас NAT, скорее всего. На нём нужно пробросить нужные порты на внутренний адрес сервера.
    Ответ написан
    7 комментариев
  • Статичный IP дома под веб сервер. Как настроить? Нужен ли проброс портов?

    Jump
    @Jump
    Системный администратор со стажем.
    Для начала нужно определиться с терминологией - что значит статичный IP в вашем понимании?
    Есть белые(реальные) адреса - те самые которые маршрутизируются в глобальной сети.
    Есть серые(частные) адреса - те которые не маршрутизируются в глобальную сеть, и соответственно доступ к ним не возможен.
    И те и другие могут быть статическими(не меняются) и динамическими(меняются при каждом подключении).

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

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

    Я надеялся получить IP на компе, а не на маршрутизаторе, было бы меньше гемора...
    Белый адрес лучше держать на своем маршрутизаторе - удобнее и безопаснее.
    Ответ написан
    3 комментария