• Как делаются авторизации только по Apple ID?

    Noizefan
    @Noizefan
    Это называется не Apple ID, а Touch ID и Face ID - технологии биометрической авторизации личности в системе. У системы есть так называемый API - интерфейс для взаимодействия с системой, создан он специально для разработчиков - что бы они могли использовать систему на все сто процентов. Touch ID и Face ID - как раз и есть части этого интерфейса. Биометрию реализуют одноименные датчики - Face ID и Touch ID. Сканер в кнопке создаёт математическое представление твоего отпечатка пальца и процессор проводит вычисления для идентификации. Из всеобщеизвестных фактов позволяю себе предположить, что сканеры являются грубо говоря обычными датчиками и нейросетями. Ничего сложного в этом нет - Apple могут хоть алкотестер к трубе присобачить и авторизовывать только по наличию определённой степени опьянения в тебе и твоей крови. Их софт, их железо - делают что угодно, собственно, в подробностях никто и особенно они тебе не расскажут, как работают такие технологии.
    Ответ написан
    5 комментариев
  • Какой JS фреймворк выбрать для full-stack?

    @itexams
    Не рекомендую использовать Метеор. Это инструмент в первую очередь для прототипирования, а не для продакшн. Столкнулись с этим на проекте, который начал расти из прототипа в приложение, которым активно пользовались одновременно несколько человек - загружали картинки и их разметки.

    Как итог - 100% загрузка памяти и адские тормоза. В итоге с метеором пришлось расстаться.
    Ответ написан
    Комментировать
  • Какую прочитать книгу/курс по проектированию баз данных?

    myjcom
    @myjcom
    плохо ищете )
    Поиски литературы почему-то не увенчались успехом, пара унылых статей на хабре, море старой литературы старше 15 лет и курсы для новичков на udemy где описывается разница между insert и select.


    все есть:

    SQL Queries for Mere Mortals, 4th Edition
    Год издания: 2018
    Автор: Viescas J.
    Жанр или тематика: Базы данных
    Издательство: Addison-Wesley Professional
    ISBN: 978-0134858333
    Язык: Английский

    Effective SQL: 61 Specific Ways to Write Better SQL
    Год издания: 2017
    Автор: Clothier B., Steele D., Viescas J.
    Издательство: Addison-Wesley
    ISBN: 978-0-13-457889-7
    Язык: Английский

    PostgreSQL Up and Running, 3rd Edition
    Год издания: 2018
    Автор: Obe R., Hsu L.
    Издательство: O'Reilly Media
    ISBN: 978-1-491-96341-8
    Язык: Английский

    PostgreSQL 9.6 High Performance
    Год издания: 2017
    Автор: Ahmed I., Smith G.
    Издательство: Packt Publishing
    ISBN: 9781784392970
    Язык: Английский

    PostgreSQL High Availability Cookbook
    Год издания: 2017
    Автор: Thomas S.M.
    Издательство: Packt
    ISBN: 978-1-78712-553-7
    Язык: Английский

    PostgreSQL 10 High Performance
    Год издания: 2018
    Автор: Ibrar Ahmed, Gregory Smith, Enrico Pirozzi
    Издательство: Packt Publishing Ltd.
    ISBN: 9781788474481
    Язык: Английский

    Database Systems: Design, Implementation and Management
    Год издания: 2017
    Автор: Coronel С., Morris S.
    Издательство: Cengage Learning
    ISBN: 978-1-305-62748-2
    Язык: Английский

    Designing Data-Intensive Applications / Высоконагруженные приложения. Программирование, масштабирование, поддержка.
    Год издания: 2018
    Автор: Martin Kleppmann / Клеппман Мартин
    Издательство: Питер
    ISBN: 978-5-4461-0512-0
    Язык: Русский

    Refactoring SQL Applications / Рефакторинг SQL-приложений
    Год: 2009
    Автор: Stephane Faroult / Стефан Фаро, Pascal L'Hermite / Паскаль Лерми
    Издательство: Символ
    ISBN: 978-5-93286-145-5, 978-0-596-51497-6
    Язык: Русский

    и даже ISO/IEC 9075:2011 буржуйский можно найти в pdf
    Ответ написан
    2 комментария
  • Выбор Macbook Pro для дизайна и xCode - 15" 2015 против 13" 2016-17 и 15" 2016?

    tegrato
    @tegrato
    13 дюймов даже для xCode бывает маловато - приходится порой боковые панели скрывать. Если хочется полегче и покомпактнее, то 13 хватит, в принципе.
    Как-то использовал Mac mini с 24' монитором Dell Ultra Sharp - вот это песня! Все умещается :)

    Для дизайна 13 точно мало. Надо 15, а лучше 17.
    Ответ написан
    Комментировать
  • Где можно найти и посмотреть "хорошие практики" на React?

    maxfarseer
    @maxfarseer
    https://maxpfrontend.ru, обучаю реакту и компании
    Можете подчерпнуть хорошие практики из текстовых версий вебинаров или из вебинаров.
    Ответ написан
    Комментировать
  • Где можно найти и посмотреть "хорошие практики" на React?

    rockon404
    @rockon404 Куратор тега React
    Frontend Developer
    Гайдлайн от airbnb по оформлению кода.
    Куча полезных ссылок по react + redux.
    Ответ написан
    Комментировать
  • Дизайн сайтов и ретина, как у вас это получается?

    mitchmurder
    @mitchmurder
    web/ui/graphic designer
    скрипя зубы
    успокаивая себя что это самый лучший в мире амейзинг лептоп
    Ответ написан
    Комментировать
  • Выбор Macbook Pro для дизайна и xCode - 15" 2015 против 13" 2016-17 и 15" 2016?

    lamer350
    @lamer350
    กำลังสูงสุด
    Сергей, поделюсь своим мнением, надеюсь вам поможет с выбором!
    На данный момент в семье 2 макбука 15" 2016го и 13" 2015го. Если кратко, я не советую брать ни один из них! Давайте разберемся.
    1. Вам как дизайнеру 13ку не стоит рассматривать в принципе если вы работаете с приложениями adobe (а если вы сейчас на винде, то скорее всего так и есть). В фотошопе например вовсе нельзя сузить боковые панели, в итоге у вас останется 2/3 рабочего пространства. В 100% масштабе не помещается лист в 1200 пикселей даже... Мне это крайне не удобно было на 13ке.
    2. Я не знаю как люди выживают с i5, если вы делаете моушен в каком либо виде - вам его точно будет мало! Дискретного видео на 13ках вовсе нет, только встройка!

    Касательно качества - в моделей до 15го года (включительно) все макбуки имеют проблему с отслоением антибликовой пленки, погуглите. Да, Apple потом заменит вам екран по гаранатии, но это только в официальном СЦ и ждать нужно будет не одну неделю. У меня с 13кой такая же проблема, благо пока только по краям. В отсальном никаких проблем нет.

    Что касается 16-17го года макбуков.
    1. Екран не сказал бы что чем то лучше, если поставить рядом 15й год и 16й - возможно разница будет заметна на максимальной яркости, в целом при работе вообще разницы нет!
    2. Все модели этих годов имеют проблемы с клавиатурой, в частности залипание клавиш! У меня лично это было один раз за 1,5 года владения, как то попал волос из бороды под кнопку и не мог выдуть его сжатым воздухом, пришлось снимать кнопку - у меня благо это вышло, но в 50% случаях кнопки ломаются (там очень маленькие крепления механизма), в сервисе замена стоит 15$ но ставят китайские - они настолько плохие по качеству что у некоторых людей в какойто момент просто по нажатию отваливаются!... Но я клавиатуру протираю по 3 раза на день, не кушаю за ноутом! Если вы любите баловать себя вкусняшками на рабочем месте - этот ноут точно не для вас, тогда только 15й год!
    3. 16й год на сколько я помню был проблемный на видеокарты, у многих они отваливались. Много блогеров страдало (видимо из за перегрева при нагрузке с монтированием видео), потому опять же - если вы делаете какие либо анимации интерфейса - лучше не покупать 16й год, либо 17 либо 18!
    4. У меня на 15ке 16го года есть подлагивания в анимации интерфейса. В ноутбуке 2 видеокарты, онда встройка HD530, вторая Radeon 450 Pro. Система устроена таким образом что если нет нагрузки на видеокарту - используется встройка HD530 и вот на ней есть фризы в анимации интерфейса Mac OS (не зависимо от версии, это было и на 10.12 и на 10.13 и сейчас на 10.14), это у всех так (я лично проверял на 5 машинах у друзей и магазинах), к слову на 13ке 15го года таких фризов нет, хотя там встройка еще слабее. Я так полагаю что просто у меня HD530 не справляется с разрешением. Потому я просто отключил встройку и у меня постоянно включена Radeon 450 Pro... Для перфекциониста только так можно жить с моделью 2016го года :) На 17ках не смотрел, там другая уже встройка и надеюсь что таких косяков там нет. Надо будет проверить как нибудь, а то это я заметил еще при покупке ноута в прошлом году и тогда бегал тестил, думал что у меня тоже проблема с видеокартой)

    Но что я хочу сказать по итогу! Не берите 15ку 16го или 17го года так же!
    Я понимаю что у вас есть только 2200 сейчас, но может стоит подождать месяц и купить модель 2018го года? Вы купите себе ноут на 3-5 лет, я думаю оно будет того стоить! 18й год макбуки стали мощнее, на целы 30%! там уже LPDDR4 (до 17го года LPDDR3), а самое главное - исправили проблему с залипающей клавиатурой! Сейчас получается 18й год - это устройство с избавлением всех косяков 2х предыдущих поколений!
    Новый макбук в США стоит 2400$ всего. Лететь за ним конечно можно и самому при возможно, NY прекрасный город) Но может кто из знакомых будет лететь, может в еропу - например в Польше с возвратом налога он обойдется в 2650$, а если захотеть то за 100$ можно самому слетать в Варшаву, и погуляете и Макбук дешевле купите)
    Ответ написан
    61 комментарий
  • Какая реальная автономность Macbook Pro 13" 2017 без тачбара?

    maestrro712
    @maestrro712
     iOS Developer
    Имею опыт использования двух таких машин:
    1) Жена около года юзает самую простую машинку из линейки. Без подзарядки может использовать его весь день (часов 6-8 точно). Задачи офисного плана, но при весьма небрежном отношении к ресурсам: по два браузера с 20+ вкладок, несколько открытых документов word/excel, куча вкладок в preview, несколько мессенджеров и тд. Спустя где-то 8-9 месяцев после покупки начал туго нажиматься пробел, остальные клавиши живут нормально пока.
    2) Сам получил на работе такую прошку в топовой конфигурации без тачбара (core i7, 16 gb ram) месяц с небольшим назад. Работаю в основном от розетки, полностью сажать батарею не доводилось. Могу сказать, что час активной работы в xcode + несколько девелоперских тулов (симулятор, zeplin, charles, postman) сажают батарею на 10-15%. Скорость работы меня более чем устраивает. Удивительно, что при одинаковом объеме оперативки и меньшей частоте процессора (2.5 против 3), этот ноутбук собирает мой рабочий проект в 1,5 раза быстрее, чем предыдущий мак.
    Ответ написан
    Комментировать
  • Как работать в фотошопе на ретина?

    mixail_fet
    @mixail_fet
    Дизайнер веб-интерфейсов
    Очень хорошо об этом написано на официальном сайте Adobe

    Однако кроме этого, хотелось бы отметить, что даже пользователям Windows нужно учитывать размер макета 2x, так как макет все равно будет верстаться под ретина дисплеи. В этом случае, крайне не рекомендую для разработки web макетов использовать фотошоп. Если у вас Mac, то лучше использовать Скетч, если сразу Mac и Windows - используйте Figma. Там поумолчанию предусмотрена возможность, экспорта всех деталей в разрешение 2x.
    Ответ написан
  • Какой стек выбрать для не сложного многопользовательского SPA?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    При этом, как Вы понимаете, нет цели изучить весь язык, стать супер-программистом.

    Конкретно из-за этой строчки, то как вы хотите добиться результата - не имеет смысла.
    Это тоже самое, что хотеть написать "абстрактную войну и мир", без знания языка.

    вносит и читает периодически разного рода простые данные

    Любая web-система оперирует разного рода простыми данными, в смысле вообще любая. Да, даже google
    смотрит такую же простую аналитику, построенную арифметически на этих данных

    Аналитика строится на базе большого набора данных

    Рекомендую не использовать слово "просто", оно вводит в заблуждение прежде всего вас.

    Или же брать Angular (который именно под SPA и заточен)

    У вас данные должны будут где-то храниться, SPA не решает эту задачу

    По пробуйте следующий стек:
    - LAMP
    - Yii2
    - JS
    - Vue
    - Webpack
    - Gulp

    Ваш проект может занять несколько лет вашей full-time работы, будьте к этому готовы.

    Я из тех людей, которые считают что "хочешь сделать хорошо, сделай это сам"

    Сколько железа вы уже выплавили самостоятельно?))
    Ответ написан
    1 комментарий
  • Какой стек выбрать для не сложного многопользовательского SPA?

    delphinpro
    @delphinpro Куратор тега JavaScript
    frontend developer
    В частности я не могу определиться:
    1. Делать проект на "чистом" LAMP + JS
    2. Или же брать Angular (который именно под SPA и заточен)


    Тут и думать нечего — нужно брать фреймворк (п.2).
    Я бы взял Vue, он попроще в понимании.
    Ответ написан
    2 комментария
  • Какой стек выбрать для не сложного многопользовательского SPA?

    rockon404
    @rockon404
    Frontend Developer
    Для вашей задачи можно использовать React/Vue + Webpack + Koa + ReactNative/Weex + MongoDB/MySQL/GraphQL + Docker + Nginx + Git.
    1. На React вы сможете написать как само веб приложение, так и нативные мобильные клиенты под Android и IOS с помощью React Native. Можно выбрать Vue - он проще для новичка и на нем также можно писать нативные мобильные приложения c Weex. Использовать Angular не советую, так как порог вхождения у него выше, а грамотную архитектуру написать сложнее. Тут нужен опыт или советы опытного разработчика.
    2. Webpack. Как не крути, а со сборкой фронтенда вам придется разобраться. В современной разработке без этого никуда. Использовать решения вроде create-react-app, лично я не советую. Как альтернативу для быстрого старта, лучше выбрать ReKit. Это тулкит для разработки на React, содержащий в себе полноценную IDE, начальную структуру проекта с роутингом и Redux, DevServer, HMR, инструменты для тестирования и много других интересных фич, вроде аналитики. Еще в сгенерированном проекте полностью отсутствует вендорная магия, вроде react-scripts в create-react-app и у вас не будет каких либо проблем с миграцией.
    3. Если выберите Koa для сервера, вам, как минимум, не придется изучать еще один ЯП. API накидать на нем плевое дело для опытного разработчика, вам же придется изучать статьи и репозитории с примерами на github. Можно выбрать Express это предшественник Koa, и в силу возраста, статей и ответов на типовые вопросы на stackoverflow для него больше.
    4. Выбор БД не принципиален.
    5. Использование Docker так же не обязательно, но разобравшись сразу, вы во многом облегчите себе жизнь и не столкнетесь с ситуацией, что ваш проект который вроде работал локально, не хочет заводиться на удаленном сервере.
    Ну Nginx и Git думаю в представлении и обосновании мотивации к использованию не нуждаются.
    Так же, возможно, хорошим решением будет использование облачных сервисов вроде Amazon Web Services

    Прежде чем браться изучать эти инструменты вам обязательно надо хорошо изучить JavaScript, HTML и CSS.

    По приложению вам понадобится:
    1. Веб сайт с описанием сервиса и формой входа/регистрации
    2. Клиентское приложение
    3. Админка
    4. Мобильные приложения

    Потратьте время на пользовательские истории, UML диаграммы и схемы интерфейсов. Используйте трекер задач.

    Мое мнение, чтобы изучить все вышеперечисленное, а начинать вам, судя по всему, придется начать с основ JavaScript, HTML и CSS, уйдет уйма времени. Чтобы после изучения всего вышеперечисленного, научиться на всем этом писать хороший код, уйдет еще больше времени. Одно дело изучить инструменты, совсем другое научиться писать хороший код, решать типовые задачи, организовывать архитектуру. А решать задачи всех планов, вам придется как по фронтенду, так и по бекенду.

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

    Если на рынке уже есть сильный конкурент и ваш сервис просто будет повторять его бизнес модель, то он вряд ли взлетит, только потратите силы и время. Обязательно изучите рынок прежде чем, что-либо предпринимать.
    Ответ написан
    2 комментария
  • Как построить Single Page Application на ASP.NET?

    ilyatrifonov
    @ilyatrifonov Автор вопроса
    В общем использовать ASP.NET MVC для SPA приложений - так себе идея. Самая идеальная связка (в окружении ASP.NET) - ASP.NET Core Web API + отдельный Angular/React проект, который умеет собираться в папку wwwroot Web API проекта для продакшена. Конкретно такой вариант реализации обсуждался вот здесь. Вкратце: создаете Web API проект (где держите запросы, которые будут отдавать или записывать нужные данные) и создаете Angular/React/ЛюбойДругойФреймворк проект, который полностью отвечает за веб-интерфейс; настраиваете прокси для запросов (чтобы дергать API методы с отдельного проекта во время разработки); учите ваш сборщик собирать проект в папку wwwroot; профит:). В итоге имеем два проекта, которые во время разработки общаются с двух разных портов, а в продакшене один проект, который открывает страничку index.html со всей логикой из wwwroot.
    Ответ написан
    Комментировать
  • Как создать web виджет для сайтов?

    @Kirill-Gorelov
    С ума с IT
    Как писали выше, да, можно и айфрэйм, но у него есть недостаток. Он может неработать не на всех клиентах.
    На счет скрипта, я считаю это самый оптимальный вариант, хоть и сложнее.
    Мы однажды реализовывали виджет, только немного другой. Опишу как это делали мы.
    Пользователь должен был разместить некий div куда должен был подгружаться наш виджет. И подключал один файл js, который за все отвечал. То есть он добавлял свои стили, проверял на странице jquery и если нету, то подключал,
    Так же он подключал я.карты.
    В тот div, который разместили изначально постепенно наполнялся нужным нам видом.
    И В общей картине генерировался целый виджет.
    Так же предусмотрели вирсионность виджета, что бы у пользователей, которые уже поставили виджет ничего не снеслось после обновления кода.
    Да, достаточно не легко, но сделали и работает.
    Ответ написан
    2 комментария
  • Как лучше реализовать хранение данных в БД? Какой стек технологий выбрать?

    XXXXPro
    @XXXXPro
    Fullstack Web developer
    А зачем такое делать на NoSQL? Тут реляционные базы вполне подходят.
    Я бы вообще ограничился тремя таблицами:
    1) сайт
    2) товар вообще (по сути, там хранится только его id и наименование)
    3) товар на конкретном сайте (тут хранится id товара, id сайта, цена, дата парсинга).
    Ответ написан
    7 комментариев
  • Можно ли разобраться в ООП в ходе изучения YII2?

    gzhegow
    @gzhegow
    aka "ОбнимиБизнесмена"
    Да как сказать Yii - это ящик с гаечными ключами. Можно ли по ящику понять - зачем ключи? Ну можно, если долго ключи использовать как пишут разработчики - то и поймешь со временем, но есть риск провалится в "делаю как сказали, почему - не знаю".

    Коли про ООП вопрос: разработчикам нужно было писать меньше повторяющегося кода, чтобы не менять одно и то же по 10 раз. Давай по-порядку.

    Представь ассоциативный массив (ключ-значение).
    Теперь представь функцию, любую, пусть будет abs() - число по модулю.
    А теперь забрось эту функцию в свой массив на место какого-нибудь ключа, то есть у тебя как будто получится $array["abs"], где лежит сама функция.

    В чем отличие функции от других данных? Данные ты можешь записать, а можешь считать. А функцию ты еще и выполнить можешь. Таким образом когда ты ее вкинул в массив, у тебя лежит не функция там, а ее заготовка, под выполнение. И ты можешь ее вызвать но уже не как abs(), а как $arr['abs']() - что будет выглядеть одинаково (под капотом все сложнее, но пока забей, оно тебе не надо)

    А теперь представь что у тебя есть десять таких массивов $arr. И что, в каждый теперь совать функцию, которую ты только что запихнул в первый? Нет, зачем. Для этого существуют "классы" - которые описывают внешний вид будущего "массива".

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

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

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

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

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

    Прежде чем считать, что ты не сможешь без ООП тебе нужно понять, что любая вещь МОЖЕТ быть сделана без ООП. Просто количество путаницы если ты бросишь этот код и вернешься к нему через месяц и уже не помнишь что где и когда - будет больше. Классы создают некую описательную структуру того, что происходит и оттого часто в крупных проектах писать на ООП длиннее дольше и тяжелее, чем без ООП.

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

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

    Я не про то, что типа "еще рано" и тд. Я про то, что есть куча вещей в которое можно отдать время, более интересных и полезных, чем погружаться с башкой в эту муть, которая на деле кроме чувства мнимого превосходства тебе ничего не даст. Просто делай как удобно, и только когда решишь своим массивам задавать поведение - типа "при присвоении ключа в поле `name` автоматически создать поле `code` с таким-то содержимым" - вот тогда реально можешь повкуривать что тут еще можно мутить.
    Ответ написан
    23 комментария
  • Почему gzip не ускоряет время загрузки сайта?

    Вопрос - почему время загрузки страницы не ускорилось?


    Ну наверно потому, что у Вас неправильно настроено сжатие gzip.
    Например писать gzip_types image/png image/jpeg бессмысленно, т.к. бинарные данные картинок итак сжаты и никакого выигрыша Вы не получите.

    Правильно написать так:

    http {
       ....
       gzip on;
       gzip_http_version 1.0;
       gzip_min_length 512;
       gzip_buffers 64 8k;
       gzip_comp_level 5;
       gzip_proxied any;
       gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
       ...
    }


    В секции server { } можете ничего не писать если не планируете менять параметры.

    Потом берем curl и проверяем:
    curl -H "Accept-Encoding: gzip,deflate" -I http://mysite.ru/index.html


    получаем ответ

    HTTP/1.1 200 OK
    Server: nginx
    Date: Fri, 24 Nov 2017 11:32:00 GMT
    Content-Type: text/html
    Last-Modified: Tue, 12 Apr 2016 06:48:17 GMT
    Connection: keep-alive
    ETag: W/"570c9a31-576"
    Content-Encoding: gzip


    Обращаем внимание на поле Content-Encoding

    Для теста из консоли берем утилиту Apache Benchmark:
    ab -n 1 -H "Accept-Encoding: gzip,deflate" http://mysite.ru/index.html


    Смотрим на поля помеченные жирным, при выключенном gzip они увеличиваются.

    Concurrency Level: 1
    Time taken for tests: 0.128 seconds
    Complete requests: 1
    Failed requests: 0
    Total transferred: 3405 bytes
    HTML transferred: 3025 bytes
    Requests per second: 7.80 [#/sec] (mean)
    Time per request: 128.249 [ms] (mean)
    Time per request: 128.249 [ms] (mean, across all concurrent requests)
    Transfer rate: 25.93 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 90 90 0.0 90 90
    Processing: 38 38 0.0 38 38
    Waiting: 38 38 0.0 38 38
    Total: 128 128 0.0 128 128


    Ну и берем Firefox и смотрим там поля Передано и Размер, если сжатие работает, то Передано должно быть меньше Размер.
    Ответ написан
    1 комментарий
  • Совместимы ли хороший рейт, фултайм и long-term на фрилансе/удалёнке?

    @argentina
    Совместимы, работаю full-time на удаленке, фиксированная месячная зп - $5200.
    Во время подписания договора оговаривали что мой рабочий день будет составлять 8 часов, я же непосредственно на работу трачу 5-6 часов, заказчик более чем доволен объемом работы, который я выдаю за это время.
    P.S. Я мобильщик, отдельные знакомые бэкендщики (PHP/RoR) получают поболее.
    Ответ написан
    2 комментария
  • Совместимы ли хороший рейт, фултайм и long-term на фрилансе/удалёнке?

    SV0L0Ch
    @SV0L0Ch
    Разработчик специализируюсь на Bitrix и Wordpress
    Как уже писали выше время в офисе и на удаленке считается по разному.
    В офисе вам платят за то чтобы вы 8 часов просидели на месте и сделали некий объем задач. При этом в 8 часов могут входить перекуры, обеды, общение с коллегами, совещания итп.
    При работе на удаленке обычно считается только время непосредственно на работу с задачей или кодом.
    В результате что в офисе, что на удаленке вы тратите примерно 5 часов именно на работу и еще 3-4 часа на организационные моменты, например, переписка с заказчиками, комментарии к задачам, итп.
    Я когда ушел на фриланс сперва долго переживал, что как не старайся за день обычно выходит максимум 6 часов. Потом начал трекать все чем занимаюсь, пересчитал и оказалось что от двух часов в день может уходить просто на обсуждение с заказчиками каких-то вопросов по задачам.
    В итоге как уже писали выше переделал план на минимум 4 часа в день и стало проще.

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