• Влияет ли SSL сертификат от Let’s Encrypt на ранжирование в Google?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Руководитель ... сказал за-за этих сертификатов Google понизит в выдаче сайт.

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

    пруфы нужны. Может есть какой-то комментарий Google на этот счёт?

    Пруфы нужно не с вас спрашивать, а с вашего руководителя.

    По сути:

    1. Не важно кем выдан сертификат, пока он подписан действительным рутом. Все валидные сертификаты одинаковы с точки зрения поисковика.
    2. Сертификаты Let'sEncrypt имеют кросс-подпись IdenTrust, то есть подтверждены другим (и серьезным) authority.
    3. Гугл (как и многие другие) непосредственный спонсор Let's Encrypt, да еще и имеет самый высокий статус - Платинум спонсор.
    4. Вот тут Google Cloud Services предлагают своим облачным клиентам сертификаты Let's Encrypt. Интересно, почему?
    5. А вот тут Google черным по белому поддерживает:

    Ongoing efforts to bring encryption to everyone

    To help site owners migrate (or originally create!) their sites on HTTPS, we want to make sure the process is as simple and cheap as possible. Let’s Encrypt is a free and automated certificate authority that makes securing your website cheap and easy. Google Chrome remains a Platinum sponsor of Let’s Encrypt in 2017, and has committed to continue that support next year.
    Ответ написан
    Комментировать
  • Как пишутся Single page application из модулей?

    27cm
    @27cm
    TODO: Написать статус
    Разберём подробнее, что происходит:

    1. main.js
    require([
        'backbone', 
        'views/app', 
        'routers/router'], 
    function (Backbone, AppView, Workspace) {
    	// ...
    	new AppView();
    });

    Мы просто создаём представление AppView. Да мы вроде бы ничего в него не передаём при создании. Значит нужно идти дальше и разбираться, что происходит во views/app.

    2. views/app.js
    И вот тут мы уже видим в зависимостях и коллекцию todo моделей, и внутреннее представление для элемента todo:
    define([
        'jquery',
        'underscore',
        'backbone',
        'collections/todos',              // <= Коллекция Todos
        'views/todos',                    // <= Представление для элемента todo
        'text!templates/stats.html',
        'common'
    ], function ($, _, Backbone, Todos, TodoView, statsTemplate, Common) {
        var AppView = Backbone.View.extend({
            // ...
        });
        return AppView;
    });


    Вот к какому выводу можно прийти:
    Представление views/app создаётся только один раз. В нём жестко прописана зависимость от конкретной одной-единственной коллекции collections/todos, поэтому ничего передавать внутрь не нужно. Если бы у нас было несколько несвязных списков todo, пришлось бы убрать эту жесткую зависимость от коллекции collections/todos в views/app, и тогда мы бы действительно создавали несколько AppView, передавая в каждый свой экземпляр коллекции collections/todos.

    3. views/app.js
    Заглянув внутрь AppView, найдём пример создания нового представления TodoView с передачей внутрь новой модели:

    4. collections/todos.js
    Аналогично можно заглянуть внутрь коллекции collections/todos и увидеть там зависимость от models/todo и рассмотреть, как она там используется.
    Ответ написан
    3 комментария
  • Опишите тезисно, как сегодня должен быть сверстан хороший сайт?

    In4in
    @In4in
    °•× JavaScript Developer ^_^ ו°
    • БЭМ. Независимые блоки.
    • Препроцессоры
    • Постпроцессоры
    • Семантическая верстка
    • Целиком и полностью адаптивная верстка
    • Грамотное использование тегов HTML5
    • Оптимизация скорости загрузки страниц
    • Меньше бессмысленных JS-плагинов и библиотек
    • Относительная кроссбраузерность
    • Деление сайта на 2 версии - сжатую (без мусора и воды, ту, что реально сервер будет отдавать) и обычную (для человеко-понятного редактирования).
    • И еще: Тык
    Ответ написан
    9 комментариев
  • Как получить превью статьи по ссылке с помощью js?

    art1z
    @art1z
    Программист-многостаночник в EffectiveSoft
    Задача, на самом деле, очень не тривиальная. Когда-то пришлось писать краулер HTML контента. По пунктам:
    1. Из JS получить контент произвольной страницы в общем случае не получится - CORS, самый рабочий вариант - делать серверный прокси и в нем же парсить HTML контент
    2. Скриншот страницы легко делается с помощью phantomjs (https://github.com/brenden/node-webshot)
    3. И готовьтесб сразу к тому, что парсинг HTML (очистка от навигации, рекламы и прочего мусора) здесь будет самой сложной задачей
    Ответ написан
    Комментировать
  • Какой годный file uploader?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    Вот хороший: www.dropzonejs.com
    А вообще, можно потыкать например тут: www.unheap.com/?s=upload
    Ответ написан
    Комментировать
  • Как вы начинаете вёрстку сайта?

    Igor-Maf
    @Igor-Maf
    Senior Front End developer
    1. Настраиваю gulp на основные таски (конкатенация, минимизация, удаление неиспользуемого, кросс-браузерность, sass и т.д.)
    2. Подключаю через bower необходимые "модули", например, normalize.css или фрэймворк
    3. Выстраиваю архитектуру кода (просто независимые блоки в отдельную директорию, например, "modules", или "pages" для стилей особенностей отдельных страниц), в корне css главный файл стилей, в котором осуществляется импорт всех модулей (например, файл с переменными цветовой палитры или файл с mixin-ами).
    4. Подключаю необходимые шрифты, в основном, через специальный миксин.
    5. В главном файле стилей описываю основные стили для типографики, в общем всё, что связано с селекторами типа.
    6. Если дизайнер предоставляет styleguide, то начинаю верстать страницу именно с него, а именно, по независимым блокам (где это возможно, от меньшего к большему) используя БЭМ методологию.
    7. По ходу дописываю задачи для менеджера задач, например, для скриптов или картинок, собираю необходимый package.json, bower.json.
    8. Собственно этап по-блочной верстки.
    9. Собираю конструктор из готовых блоков и элементов соответственно макету.
    10. Проверяю кроссбраузерность, pixel perfect.
    11. Этап исправления деталей

    Исходя из формулировки вопроса ответ:
    поэтапно, сначала описываю структуру одного блока, пишу ему стили, перехожу к следующему.
    Ответ написан
    Комментировать
  • Для чего используется golang?

    XXX
    @XXX
    Решение где-то рядом
    К ответу Артема можно добавить, что например Go активно используют такие компании как digital ocean, на хабре есть интервью с Моисеем Урецким, сооснователем и директором Digital Ocean, он очень хорошо отзывается о Go.

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

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

    По сути, мы прошли через все муки роста, наша работа не ограничивалась созданием новых фишек и допиливанием продукта. Например, планирование выглядело следующим образом: мы оценивали свои масштабы, умножали их на десять и уже на эту цифру опирались, работая со своей архитектурой. И почти каждый раз, когда мы практиковали это «упражнение», Go вписывался идеально. К тому же люди, которым интересен Go, как правило, очень хорошие разработчики, и им интересны те проблемы, над которыми работаем мы. Благодаря этому мы смогли набрать большую команду отличных инженеров, готовую как поддерживать существующие продукты, так и делать новые.
    Ответ написан
    1 комментарий
  • Для чего используется golang?

    artem_kovardin
    @artem_kovardin
    Go отлично подходит для сетевого программирования. Сравнительно небольшие усилия нужны для написания довольно приличного клиент-серверного приложения (consul, etcd).

    Кроме того, скорость и маленькое потребление памяти позволяют применять Go для обработки большого количества информации, подсчета статистики, написания парсеров/кравлеров. Тут очень сильно способствует возможность простого распараллеливания.

    Go применяется для написания девопс и админских инструментов (Docker, CoreOS) которые легко использовать, так как все компилируется в один бинарник и линкуется статично.

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

    dunmaksim
    @dunmaksim
    Технический писатель
    1. Создаю каталог для проекта
    2. Инициализирую Bower
    3. Устанавливаю нужные пакеты, например, Twitter Bootstrap, Angular, jQuery и т.д.
    4. Ставлю Grunt, плагины для него и т.д.
    5. Запускаю EMACS и создаю index.html
    6. С помощью Emmet создаю шаблон, который уже начинаю заполнять.
    7. В каталоге src создаю папки less, js и т.д.
    8. Попутно пишу задачи для Grunt
    9. Если в выбранном фреймворке не хватает какого-либо класса для стилизации элемента, сначала описываю стили прямо в шаблоне, в свойстве style. Затем при необходимости выношу их оттуда в LESS в виде одного или нескольких классов.
    10. ??????????
    11. PROFIT!!!
    Ответ написан
    15 комментариев
  • С чего начать обучение для фриланса?

    kumaxim
    @kumaxim
    Web-программист
    И так, с чего начать обучение:
    1.Самый низкий порог вхождения у языка PHP. Начинайте именно с него
    2.Изучите популярные CMS: WP, DLE, Joomla и т.д. Очень много заказов есть типа "Создать сайт", причем экзотики в 2 из 3 проектах не нужно. Здесь минус в том, что школоты тут полно и цену они сбивают весьма сильно...
    3.Далее категория заказов "А можно ли сделать вот так". Сводится все это к разработке/переработке модулей на все тех же CMS. Нужно учить PHP + API этих самых CMS. Возьмите один движок и копайте по нему в эту область, не рвитесь сразу за всеми. Порог вхождения тут тоже не велик, но здесь больше голодные студенты обитают
    4.Когда перерастете уровень дополнений/модулей, переходите к фреймворкам. Сейчас самый популярный Yii. Фреймворк позволяет Вам делать какие-то уникальные приложения, которые достаточно тяжело реализовать на готовых системах. Здесь ценник по существеннее, чем в первых двух, т.к. школота в силу своих умственных способностей сюда влезть не может.

    Теперь расскажу как вообще этому обучаться на своем примере. Я делаю так:
    1.Открываю тоненькую книжечку по языку(листов 100, не более), смотрю на основы
    2.Делаю примеры из этой книжке в IDE/блокноте. Это дает мне определенную базу
    3.Далее у меня есть список из примерно 20 задач(любую методичку по программированию откройте), которые я всегда делаю на новом языке. Это позволяет мне "привыкнуть" к новому коду и начать изучать стандартную библиотеку языка
    4.Затем я начинаю брать низкобюджетные заказы на фрилансе по этому языку
    5.После этого начинаю учить самый популярный фреймворк языка, опять же на низкобюджетных проектах.
    6.Сделать с 12-15 проектов я могу уже браться за что-то более менее серьезное с почасовой оплатой на фултайме.

    Вот это мой путь. По срокам - базу я себе нарабатываю за 1,5-2 месяца, на это время у Вас должна быть какая-то "подушка".

    P.S. надеюсь помог. ))
    Ответ написан
    7 комментариев
  • Ruby or Python?

    yokotoka
    @yokotoka
    Python guru
    Я стоял перед тем же выбором лет 6 назад и выбрал Python. Не пожалел. Он достаточно универсален, чтобы писать на нём не только сайты. Ruby, к сожалению, больше RoR-язык, чем язык общего назначения. Очень мало софта вне RoR у него и назначение очень узкое, хотя сам язык прикольный. Python же используется очень много где вне веба - начиная от микроконтроллеров, заканчивая сложными научными расчётами.

    И ещё, немного личного. Я ненавижу Django. Это один из самых худших веб-фреймворков, по странному стечению обстоятельств, оказавшийся в тренде. Он, заточенный под газетные сайтики и бложики, с тяжёлым синдромом велосипедостроения и Not Invented Here, лепится всюду, куда стоит и, особенно, куда не стоит. И это нелепо смотрится (особенно в нём убог ORM в сравнении с той же SQLAlchemy). Есть много более удачные примеры для многих применений (Flask, Pyramid). Если возьмётесь делать веб-приложение, а не сайт-визитку/блог (который лучше вообще делать на php и Wordpress), присмотритесь к ним повнимательнее.

    UPD: А вообще, создаётся ощущение, что сейчас лучше всего учить JS, хотя он плох почти всем, что в нём есть. :) Go, Rust интересны, но пока слишком незрелые. Тут ещё C#/.NET со своими open source движениями начинают смотреться неплохо. Ну и всегда есть Java для любителей винтажа и максимальной кроссплатформенности (с матюками). В общем, сложное сейчас время. :)
    Ответ написан
    5 комментариев
  • Какой двигатель выбрать для Landing Page?

    68747470733a2f2f7261772e6769746875622e63
    Используй fullPage.js
    Вот пример реализации лендинга на этой js плагине example Apple

    Сам по себе плагин популярный, вот несколько примеров сделанных на этом движке:
    dasselundwagner.com
    onlinedepartment.nl
    rocketbank.ru
    Последний пример как раз лендинг.
    Ответ написан
    1 комментарий
  • Правильное хранение изображений на сервере

    afiskon
    @afiskon
    У вас есть множество серверов для хранения картинок. Возможно. тех же самых, на которых работают и скрипты, не важно. Вы на этих серверах держите специальную приложеньку для заливки картинок. Когда приходит картинка, выбираете случайным образом один из серверов (держите список в MySQL/Redis/неважно), заливаете картинку, получаете обратно ссылку. В базу пишите ссылку img123.myproject.com/123/45/38475.jpg.

    Если сервер дохнет, поднимаете новый, присваиваете ему имя img123.myproject.com, восстанавливаетесь из бэкапа, снова все работает. Раздавать картинки, разумеется, нужно не через приложеньку, а напрямую через nginx.

    А еще для хранения картинок неплохо подходит Riak. Плюс в том, что вы получите шардинг, решардинг и репликацию из коробки и особо думать ни о чем не надо.
    Ответ написан
    Комментировать
  • Краудфаундинг в Украине?

    @Robotex
    Indiegogo выплачивает деньги на ваш банковский счет. Можно и в украинском банке.

    Еще в Украине есть свой сервис "Спільнокошт": biggggidea.com/
    Ответ написан
    Комментировать
  • Подсоветуйте фреймворк для node?

    MarcusAurelius
    @MarcusAurelius Куратор тега Node.js
    автор Impress Application Server для Node.js
    Как основной автор Impress, не буду я его советовать, но вот несколько слов скажу, чтобы не было лишних ожиданий от фреймворка. И дам советы, которые на любом фреймворке помогут Вам написать хороший проект.

    Ответы:

    agentx001:
    Сильно много мне не нужно, MVC да рендринг страниц на сервере.

    Что такое MVC нет общего мнения, так случается, что каждый поймет это по-разному, потом напишет что-попало, и назовет это MVC. Так вот, Impress это не MVC, если понимать MVC, как отдельное написание контроллеров, моделей и представлений. Не будем обсуждать, что такое MVC, это очень затертый термин, и мы запутаемся в домыслах, которые вокруг него нагромождены. Лучше я скажу, что ждать от фреймворка: Impress, сам по себе, это универсальный контроллер, он как раз написан для того, чтобы не писать контроллеров. В нем есть реализация представления — это рендереры, один из рендереров — это шаблонизатор (с его помощью можно рендерить не только HTML, но и CSV, CSS, TXT и что угодно), но есть еще рендерер для JSON, он совсем простой, можно дописывать другие рендереры, для других форматов данных, если шаблонизация не подходит, например, для бинарных данных. Еще в Impress есть реализация логики приложений — которая разделяется на три части: (а) логику модели данных предметной области, (б) логику представления, т.е. логику рендеринга, (в) логику библиотек общего назначения, не связанных с предметной областью. Логика предметной области — это бизнес-логика приложения, например: алгоритм вычисления маршрута доставки груза, для системы крекинга грузов. Логика рендеринга — это если нужно сформировать данные для рендеринга при помощи императивного кода (т.е. при помощи обычного алгоритмического программирования с условиями, циклами и вызывами), а не только при помощи декларативных шаблонов и декларативных условий в них. Логика библиотек общего назначения — это все универсальные задачи, которые могут быть переиспользованы в других проектах, например, генерация DOCX документа, валидация данных, чтение количества кадров из анимированного GIFа и т.д. Все эти три вида логики (кода), гораздо важнее отделать друг от друга, чем модель от представления. А вот отделать представление от логики представления — это вообще страшная ересь, в которую впадают многие MVC-фреймворки.

    agentx001:
    Понравился этот новенький impress, но не стремлюсь использовать самопальный продукт, могущий в любой момент свернуться и даже не имеющий документации…

    Кроме самописных Вы еще какие знаете? Может есть какие-то автоматически писанные или сгенерированные? Есть статьи, есть примеры, часть API уже документирована, например, вот тут: impress/wiki. Скоро будут скринкасты, я уже об этом говорил. И в Impress очень мало кода, ядро весит 43кб. Код написан аккуратно, его можно прочитать за 5 дней, если читать по 5 страниц на ночь. Примеры готового веб-приложения (админ-панель для БД MySQL и MongoDB) даются вместе с системой и описываются тут: http://habrahabr.ru/post/192302/

    rozhik:
    По поводу критики impress — я бы таки выбрал другой. Очень странная архитектура, если он выживет — то явно поменяет не только половину апи — но и принципы расположения файлов.

    Фреймворк не на пустом месте появился, файловые структуры, как и API, созданы как портированные на ноду, наработки моей команды за последние 15 лет на Delphi, C#, PHP и JavaScript. Структура каталогов и API будут наращиваться, но не переделываться кардинально, я уже нашел для себя золотую середину в архитектуре систем. Вот что будет меняться в ближайшие месяцы — это формат конфига, т.е. Impress же не просто фреймворк, это сервер приложений, и он может сразу обслуживать несколько приложений (на разных доменах). Для этого, конфиг будет разделен на основные настройки и отдельную конфигурацию, для каждого приложения. Но конфиг не вилик, его разнести на несколько файлов — не проблема, при чем, структура конфига не сильно изменится.

    Советы:

    1. Если у Вас сайт, то рендерите шаблоны на сервере, но если у Вас приложение, то сделайте одну страницу (ну или несколько основных страниц), и на сервере сделайте API на AJAX и JSON. Присылайте данные в клиентское приложение, будь то веб-приложение или мобильное приложение для iOS или Android или оконное приложение, на любом языке. Это гораздо универсальные и удобнее для интеграции и поддержки.

    2. Используйте оперативную память, не лазьте в базу данных постоянно. Нода — это великолепная возможность писать быстрые приложения, и даже не из-за того, что она не блокирующая, за последний год я понял, что правильное использование памяти гораздо более ускоряет, Вам даже не нужно делать операции ввода-вывода в реальном времени, все они могут быть отложенные (ленивые, лэйзи). Вместо этого, разворачивайте данные в память приложения, стройте хеши, объекты, массивы. Не нужно бояться, что нода запущена в несколько процессов, и запросы одного пользователя могут приходить в разные процессы и находить там разные структуры данных. Это можно решить, делая «прилипание» клиентов по IP адресу или по Cookie при помощи балансировщика, к отдельному процессу ноды. В Impress такой балансировщик есть встроенный, можно использовать nginx или сервисы Вашего дата-центра, для больших проектов можно и нужно привлекать аппаратные балансировщики. Между разными процессами так же можно взаимодействовать через ZeroMQ, TCP, HTTP, IPC и еще что-угодно. Таким образом, данные разных процессов, в зависимости от того, что это за данные, могут или дублироваться в памяти (кешироваться, если это общие данные) или быть разделены на «прилепленные» сессии или синхронизироваться между собой через межпроцессовое взаимодействие.

    3. Не очаровывайтесь технологиями, берите их как можно меньше, и лучше копайте вглубь, чем по верхам. Для ноды сейчас очень большое разнообразие всего написано, и есть какая-то общая тенденция, поподключать в проект сто модулей, которые делают совершенно плевые вещи, а те тянут за собой еще какие-то зависимости и потом оно расползается и становится совершенно неконтролируемым. Подумайте 100 раз перез тем, как написать require, а если есть несколько альтернатив, то потратьте немного времени чтобы пощупать их код, протестировать производительности и удобство, это сэкономит потом много времени.
    Ответ написан
    3 комментария
  • Node.js в качестве server-side для enterprise приложения?

    Stdit
    @Stdit
    По моему опыту, nodejs — удобная, стабильная и быстрая штука, имеющая отличное сообщество и много хороших библиотек в npm. Преимущества можно перечислять долго, лучше сразу перейти к проблемам.

    — Сложно найти готовых к работе толковых программистов, даже среди фронтендщиков. Но можно обучить. На обучение и понимание среды nodejs, API, асинхронности, замыканий, калбэков, событий, функционального подхода — уходит примерно месяц-два.
    — Библиотеки из форнтендов использовать можно, но только если они грамотно написаны и оптимизированы для перманентной работы. Иначе есть риск, что они сожрут всю память или повесятся.
    — Сервер nodejs обычно однопоточный, со всеми вытекающими. Имеется возможность форкать и открывать дочерные процессы, на это нужны дополнительные затраты труда. Но это требуется только в исключительных случаях.
    — Код пишется в основном легко, если следовать чёткому стандарту, который обычно навязывается используемым фреймворком. Однако javascript, ввиду своей нестрогости, неустойчив к коррозии, в спешке или по неопытности можно наделать рака и превратить жизнь своей команды в ад.
    — При сложной логике со множеством вызовов можно без злого умысла нагородить «лестниц» из калбеков. Однако, проблема решается разными вариантами библиотек управления задачами (async, Q, и т.д.). Вообще лучше делать максимальную декомпозицию кода, создавать бесчисленные функции внутри функций — не очень хорошая практика.

    По поводу камней:
    — Обычно, всякие руководства и мануалы типа «hello world» используют один сокет для соединения с БД. На практике оказалось, что если этот сокет зависает под тяжёлым запросом, то все остальные запросы прилежно ждут его освобождения. Поэтому первое, что нужно сделать в новом проекте — это подключить database connection pool.
    — Случилось так, что количество одновременных подключений к серверу перевалило за тысячу, и внезапно возникли необъяснимые аномалии и отказы. Как выяснилось, страшного ничего не произошло, и нужно было просто в операционной системе разрешить открывать на порядок больше файловых/сокетных дескрипторов.
    — Память для nodejs лучше ограничивать ключами запуска и отдавать больше для БД (если они на одной машине). В противном случае nodejs не спешит запусктать сборщик мусора (это ведь затратная операция) и разрастается.
    — Перезагрузки nodejs из-за внезапных падений от багов решаются специальными библиотеками, например forever.
    — Чтобы nodejs не вылетал из-за исключений, нужно ставить глобальный обработчик uncaughtException, который пишет их в лог или сразу шлёт на мыло ответственному лицу.
    — Нужно не забывать отвязыватсь обработчики от событий по окончании работы подписанного на событие объекта (removeListener()).

    По поводу фреймворков, используем express, потому что он красивый, простой и мы к нему привыкли.
    Ответ написан
    2 комментария