Очевидно, что автору оригинала стоит познакомится с понятием площадь.
Но посыл статьи в том, что при проектировании дизайнов стоит больше внимание уделять площади, а не размерам. И за это СПАСИБО.
И за скругления, которые не скугления. И за вписывание в круг объектов сложной формы.
Это защита пользоватлей вашего сайта от внедрения MITM.
Провайдер или владелец бесплатного фай-фая в кафе/транспорте не сможет:
— узнать куда ходит клиент(ну кроме DNS)
— мофифицировать ответ сервера, например подставить рекламу.
Скорее всего гугл боится резалок рекламы или замен его рекламы, вот и продвигает https.
Но ИМХО ему тут с обычными пользователями по пути.
ИМХО получив приведенный Вами вариант ответа у сотрудника как-раз останется то самое впечатление «не выслушали».
Как по мне предпочтительней предложить выяснить преимущества и недостатки указанной технологии, сравнить с прямыми конкурентами.
Можно попросить все это оформить в документальном виде.
В результате человек который хотел только «набросить» точно также развернется и уйдет, но человек который действительно хочет что-то улучшить, не получит ощущения, что он него хотят отделаться. Он увидит, что к нему прислушиваются, доверяют провести анализ.
На втором этапе уже можно доверить разработку вариантов внедрения.
Это позволит мотивировать и удержать в компании ценного карда, а возможно даже позволит улучшить качество процессов/разработки, если вдруг его предложения действительно окажутся ценными.
Хочу подчеркнуть одну мелкую но важную деталь: я перепроверял результаты экспериментов, которые приводят на обсуждаемом сайте. Они сами выбрали wordpress, я лишь повторил тот же эксперимент но на ОДНОМ источнике, и сделал несколько дополнительных шагов.
Беда проверки с бинарными фалами — все они разные!
Я могу взять ISO образ с текстовыми файлами — такой формат данных отлично сжимается и я прогнозирую победу git-а.
С другой стороны, можно взять архивы и эту будет худший случай для гита.
Насколько я знаю у гита одна проблема с большими бинарными файлами по сравнению с svn — весь репозиторий будет у каждого клиента, а если там много несжимаемых бинарей — он будет большой. Фактически будет жраться место на компах и страдать время клонирования. LFS именно эту проблему и решает.
С другой стороны я провел кучу сравнений хранения бинарных файлов в git и svn для нашего проекта. Средний проект: пара десятков мелких файлов, десяток бинарных на 1-2 МБ, 1-2 крупных бинаря на 10-50 МБ. И в результате гит на наших файлах показывает приемлемый результат: 500 коммитов на проект, репозиторий весит в 2 раза меньше чем рабочая копия. Хранить на LFS полные копии несжатых файлов мне в этом случае кажется лишним.
Из-за специфики формата не думаю, что это будет интересно широкой публике.
Отличное замечание, но особо не влияет. svnadmin.exe pack svn 214 MB (4,644 Files, 89 Folders)
Помогло только с количеством файлов, объем незначительн вырос.
Но посыл статьи в том, что при проектировании дизайнов стоит больше внимание уделять площади, а не размерам. И за это СПАСИБО.
И за скругления, которые не скугления. И за вписывание в круг объектов сложной формы.
Провайдер или владелец бесплатного фай-фая в кафе/транспорте не сможет:
— узнать куда ходит клиент(ну кроме DNS)
— мофифицировать ответ сервера, например подставить рекламу.
Скорее всего гугл боится резалок рекламы или замен его рекламы, вот и продвигает https.
Но ИМХО ему тут с обычными пользователями по пути.
Как по мне предпочтительней предложить выяснить преимущества и недостатки указанной технологии, сравнить с прямыми конкурентами.
Можно попросить все это оформить в документальном виде.
В результате человек который хотел только «набросить» точно также развернется и уйдет, но человек который действительно хочет что-то улучшить, не получит ощущения, что он него хотят отделаться. Он увидит, что к нему прислушиваются, доверяют провести анализ.
На втором этапе уже можно доверить разработку вариантов внедрения.
Это позволит мотивировать и удержать в компании ценного карда, а возможно даже позволит улучшить качество процессов/разработки, если вдруг его предложения действительно окажутся ценными.
Они сами выбрали wordpress, я лишь повторил тот же эксперимент но на ОДНОМ источнике, и сделал несколько дополнительных шагов.
Беда проверки с бинарными фалами — все они разные!
Я могу взять ISO образ с текстовыми файлами — такой формат данных отлично сжимается и я прогнозирую победу git-а.
С другой стороны, можно взять архивы и эту будет худший случай для гита.
Насколько я знаю у гита одна проблема с большими бинарными файлами по сравнению с svn — весь репозиторий будет у каждого клиента, а если там много несжимаемых бинарей — он будет большой. Фактически будет жраться место на компах и страдать время клонирования. LFS именно эту проблему и решает.
С другой стороны я провел кучу сравнений хранения бинарных файлов в git и svn для нашего проекта. Средний проект: пара десятков мелких файлов, десяток бинарных на 1-2 МБ, 1-2 крупных бинаря на 10-50 МБ. И в результате гит на наших файлах показывает приемлемый результат: 500 коммитов на проект, репозиторий весит в 2 раза меньше чем рабочая копия. Хранить на LFS полные копии несжатых файлов мне в этом случае кажется лишним.
Из-за специфики формата не думаю, что это будет интересно широкой публике.
svnadmin.exe pack svn214 MB (4,644 Files, 89 Folders)
Помогло только с количеством файлов, объем незначительн вырос.