Так вы бы сделали публичное API, тогда бы и говорили, что не против развития сторонних клиентов.
А то обещания про «скоро будет webdav» слышим уже сколько, подскажите, лет? В иных местностях так долго тянущих с обещаниями людей порой и обидными словами могут назвать, сами понимаете.
Почему не сказать правду: "мы, как компания, забили на развитие облака, нам, как сотрудникам, не жалко, но ресурсов нам, как разработчикам, на развитие что webdav, что api мы, как компания, просто не даем" — всем было бы лучше же?
Про смайлики — помните, был анекдот про порутчика Ржевского, мол, все шутки пронумеровать и говорить только номер той, что хотите отпустить? Так вот и все смайлики мира, все библиотеки, все даже фразы в блоках и твитах пронумеровать, и придумать расширение для html, которое вместо ссылки на графический смайлик или вместо указания фразы текстом просто будет на номер в метатаблице ссылаться! Мы не победим, пока не возьмемся за дело всерьез, это же понятно — так что старые браузеры нужно будет удалить, а вот тогда новые уже будут заменять контент «по номерам» как надо )))
А если серьезно, вы поизучайте свой кеш. Да, jquery невелика (хотя как посмотреть!), но и экономия, кроме лишнего запроса, будет не смертельна. А вот вы посмотрите, каков размер кеша в вашем ПК, а каков в вашем телефоне, потом прикиньте, какой из вариантов jqeury туда надо поместить, чтобы многие сайты им воспользовались, и осознайте, сколько, глядя на объем запрашиваемых файлов любого современного сайта, вы каждым кликом по ссылке в вебе в кеше заменяете/удаляете.
CDN только Гугла отдает 54 (!!) версии jquery, да еще умножьте на 2 (протоколы поддерживаются и http, и https), да еще, наверное, у них есть и «просто», и «min»-версии. Таким CDN далеко не один, а минимум штуки 4-5 (я про самые популярные). Итого, если я зашел на один сайт, где с CDN грузилась jquery, а потом сразу на другой (где тоже jquery и тоже с CDN), то имеем вероятность примерно 1/500 — 1/1000, что библиотека jquery там и там — одна и та же, и на втором сайте не будет грузиться, т.к. загрузилась на первом. Это при условии, что кеш вообще объемен, и что-то хранит. Ну и да, теперь давайте подумаем, сколько в вашем кеше только под разные версии jqeury отведено места ))
Скажем прямо: идея унификации хороша, но в реальном мире проще не городить огороды. Вы боретесь с лишним http-запросом? Попросите сначала Яндекс с Гулом в своих счетчиках посещений сайта не делать столько http-перенаправлений :) — пользы для людей будет больше!
Увы, как часто мы видим такого рода презентации новых технологий, которые в силу разных причин стандартом так и не становятся. И потом имеем две-три, скажем, игры, которые умеют хоть что-то делать при помощи этой технологии (Thief как пример — запилили один эффект аппаратно через новое API — мало ли было причин, может, и потестить хотели, но переводить всю игру на новый подход и сил и денег просто жаль), а через пару лет про это API только и почитаем, что это была неудавшаяся попытка…
> Владельцам малых сайтов часто приходится выбирать: либо подключать jQuery и/или подобные ей библиотеки с CDN (гугловского, например),
> или со своего домена.
> В первом случае уменьшается время загрузки сайта (в том числе первичной, т.е. при первом заходе посетителя на сайт) за счёт того,
> что файл с серверов Гугла с большой долей вероятности уже есть в кэше браузера.
Шанс того, что кеш браузера, заваленный добром от недавно просмотренных десятков сайтов, будет содержать именно тот файл с CDN, который лично данному сайту необходим, крайне невелик. Но пусть это не 1%, пусть целых 5% — т.е. у одного из 20 человек именно этот файл будет доступен на 0.2 сек быстрее.
Зато у 19 из 20 будут лишние задержки на DNS-поиск, возможное установление https-соединения с дополнительным хостом, плюс имеем риск недоступности файла с CDN — в общем, 19 из 20 посетителей имеют шанс получить ухудшение вместо улучшения.
Как по мне, так не та статистика, за которую надо владельцу малого и/или малопосещаемого сайта держаться. Лучше положить файлы js и стилей себе на сервер, объединить их и минифицировать, настроить сжатие (в идеале — gzip_static), настроить кеширование — положительный эффект будет куда большим!
А версионирование файлов легко и непринужденное делается через указание версии в URI файла (а не в GET-параметре, как это любят неотключаемо делать мамонты вроде Битрикса). Хоть в виде http://domain.tld/files/js/VERSION/file.js, хоть в виде http://domain.tld/files/js/file-VERSION.js — настроить веб-сервер на отдачу в каждом случае файла, лежащего по факту в /files/js/file.js (т.е. на игнорирование часто VERSION) несложно, а польза безо всяких расширений языка разметки (и реализации поддержки расширения в браузере) несомненна.
И, да, заголовок etag как раз и придуман для реализации того, что вы в своем предложении упоминаете. Только куда более прозрачно и с меньшим влиянием на процесс создания html-кода страницы.
Согласен. Но уж если на ресурсах, которые делают вид, что заботятся о юзерах, такое сплошь и рядом, то на кого равняться? Взгляните на этот пост с мобильного, далеко ходить не будем )
Глядя на первую иллюстрацию в тексте (https://habrastorage.org/files/546/3b7/f92/5463b7f9246a44bbb809eac54cc853b8.png) могу сказать, что самая правая версия (подписанная 400px) — позор, как можно не экономить место на экране юзера!
Под заголовком, где крупные буквы с минимальным интерлиньяжем совсем не радуют глаз (заголовок «не читается», но по высоте занимает полэкрана!) мы видим три явно служебные ссылки, которые (как неожиданно!) занимают остаток экранчика.
В общем, делая версии для каждого размера, надо думать о человеке, а не о мифическом покрытии всех разрешений и не о доходах (это шпилька в сторону «мобилоделателей», которые еще треть страницы на мобильнике баннером занимать умудряются)!
P.S. Лично меня в «мобильных» версиях и адаптивной верстке больше беспокоит, что в них нельзя масштаб менять пальцами — автор свято верит, что он выбрал наилучшие размеры шрифтов, и не оставляет варианта зума-анзума. Лично мне куда приятнее включать (если есть возможность) «десктопный вид» сайтов, и уже с зумом и протяжкой через экран читать — получается куда понятнее, удобнее, да и сайты, привычные с десктопа, быстрее в обращении оказываются, все уже знаешь, где находится.
Будем надеяться, что братья-китайцы не глупее нас оказались при просчете таких последствий. Да и если говорить прямо, на то оно и испытание нового вида транспорта, чтобы понять, какие с ним проблемы.
А я вот думаю, что для туристов этакая махина может неплохим объектом стать.
> Плюсы: относительно недорогой, возможность замены дисков hot-swap, собственный программный RAID.
Собственный RAID — это неплохо. Собственный программный RAID — это зло. Вы потенциально не воткнете эти диски в обычный ПК, да и в чужой NAS можете не воткнуть, потому что заранее неизвестно, какой формат этого «программного RAID». И даже если сегодня он совместим с ОС на ПК, то после обновления firmware что-то может и измениться. В общем, вопрос тонкий. Можно только молиться на производителя NAS, что они будут делать все на базе стандартных линуксовых решений, и зеркало под линуксом увидится (про эту модель не скажу, так ли это).
Идеально еще одну такую коробку в ЗИП иметь, или уже, и правда, собирать все на базе любимой ОС и обычного «писюка» (только выбрать вариант, чтобы дисков влезало побольше) — оно будет понятнее в обслуживании.
Вы, похоже, подходите с точки зрения «раз я легко запоминаю, то и другие справятся, а кто не справится — тех меньшинство (потому что я не могу быть не в большинстве)». Как вы определили «незначительность» среди клиентов? )
Вы забываете другое: во-первых, чтобы зайти в приложение, печатать цифры логина и цифры пароля каждый раз — это много цифр. Это якобы безопаснее, но по факту провоцирует безопасность эту нарушать. «Это юзеры сами нарушили», я знаю.
Во-вторых, вход в интернет-банк лично для меня — занятие не ежедневное. Цифры логина и цифры пароля постоянно держать в голове от этого не очень получается: они просто не нужны так часто.
В-третьих, банк, в отличии от Вас, думает о всех пользователях, даже о тех, кто не в том подмножестве, где Вы.
Я бы предпочел вариант с выбором своего логина и своего пароля. Меня бы это устроило, я бы символы вписал. Вас бы это тоже устроило, правда же?
Этакий тип статей, где каждый плюс и минус обсуждаемого трактуется только в смысле, что «и это тоже хорошо».
Условно (не про это приложение): приложение не грузится — о, хорошо, оно не будет мешать. Приложение спрашивает пароль постоянно — о, это не проблема, это безопасность. И пр.
Статья хорошая, с этими оговорками. Только я не понял, какая связь между рассказом о приложении и о том, как в чате милые девушки толково помогают? Банк в этом смысле, и правда, старается идти навстречу клиенту ) Но я бы в чате аватарку девушки сделал поулыбчивее :)
Честно говоря, приложение Сбера получше будет: крупнее надписи, удобнее вход. С логином в Альфе вообще сложно как-то, дается логин и пароль цифровой, на символьный не сменить, а такую цепочку цифр (я про логин) не запомнить. Получается, что единственный доступный вариант — использовать вариант «сохранить логин» (т.е. он не будет спрашиваться при каждом входе, нужно будет только пароль вводить), но тогда его вообще можно было бы убрать, оставив крупный нумпад для ввода пароля (сравните ввод его в приложении Сбера и в приложении Альфы).
Это все — мелочи. Спасибо, что ПО развиваете, и что стараетесь к людям относиться по-человечески. Но вот со статьей получилось странно: начали с разговора, что от программы не воротит, а закончили чатом и личным общением с девушками. Вы бы после такого описания, скажем, автомобиля машину бы не купили, правда? Но в зачем PR-отделу пойдет, другое дело, что банк старается быть ближе к клиентам, а клиенты такую «развесистую клюкву» читать бы вряд ли хотели.
А то обещания про «скоро будет webdav» слышим уже сколько, подскажите, лет? В иных местностях так долго тянущих с обещаниями людей порой и обидными словами могут назвать, сами понимаете.
Почему не сказать правду: "мы, как компания, забили на развитие облака, нам, как сотрудникам, не жалко, но ресурсов нам, как разработчикам, на развитие что webdav, что api мы, как компания, просто не даем" — всем было бы лучше же?
А если серьезно, вы поизучайте свой кеш. Да, jquery невелика (хотя как посмотреть!), но и экономия, кроме лишнего запроса, будет не смертельна. А вот вы посмотрите, каков размер кеша в вашем ПК, а каков в вашем телефоне, потом прикиньте, какой из вариантов jqeury туда надо поместить, чтобы многие сайты им воспользовались, и осознайте, сколько, глядя на объем запрашиваемых файлов любого современного сайта, вы каждым кликом по ссылке в вебе в кеше заменяете/удаляете.
CDN только Гугла отдает 54 (!!) версии jquery, да еще умножьте на 2 (протоколы поддерживаются и http, и https), да еще, наверное, у них есть и «просто», и «min»-версии. Таким CDN далеко не один, а минимум штуки 4-5 (я про самые популярные). Итого, если я зашел на один сайт, где с CDN грузилась jquery, а потом сразу на другой (где тоже jquery и тоже с CDN), то имеем вероятность примерно 1/500 — 1/1000, что библиотека jquery там и там — одна и та же, и на втором сайте не будет грузиться, т.к. загрузилась на первом. Это при условии, что кеш вообще объемен, и что-то хранит. Ну и да, теперь давайте подумаем, сколько в вашем кеше только под разные версии jqeury отведено места ))
Скажем прямо: идея унификации хороша, но в реальном мире проще не городить огороды. Вы боретесь с лишним http-запросом? Попросите сначала Яндекс с Гулом в своих счетчиках посещений сайта не делать столько http-перенаправлений :) — пользы для людей будет больше!
> или со своего домена.
> В первом случае уменьшается время загрузки сайта (в том числе первичной, т.е. при первом заходе посетителя на сайт) за счёт того,
> что файл с серверов Гугла с большой долей вероятности уже есть в кэше браузера.
Шанс того, что кеш браузера, заваленный добром от недавно просмотренных десятков сайтов, будет содержать именно тот файл с CDN, который лично данному сайту необходим, крайне невелик. Но пусть это не 1%, пусть целых 5% — т.е. у одного из 20 человек именно этот файл будет доступен на 0.2 сек быстрее.
Зато у 19 из 20 будут лишние задержки на DNS-поиск, возможное установление https-соединения с дополнительным хостом, плюс имеем риск недоступности файла с CDN — в общем, 19 из 20 посетителей имеют шанс получить ухудшение вместо улучшения.
Как по мне, так не та статистика, за которую надо владельцу малого и/или малопосещаемого сайта держаться. Лучше положить файлы js и стилей себе на сервер, объединить их и минифицировать, настроить сжатие (в идеале — gzip_static), настроить кеширование — положительный эффект будет куда большим!
А версионирование файлов легко и непринужденное делается через указание версии в URI файла (а не в GET-параметре, как это любят неотключаемо делать мамонты вроде Битрикса). Хоть в виде http://domain.tld/files/js/VERSION/file.js, хоть в виде http://domain.tld/files/js/file-VERSION.js — настроить веб-сервер на отдачу в каждом случае файла, лежащего по факту в /files/js/file.js (т.е. на игнорирование часто VERSION) несложно, а польза безо всяких расширений языка разметки (и реализации поддержки расширения в браузере) несомненна.
И, да, заголовок etag как раз и придуман для реализации того, что вы в своем предложении упоминаете. Только куда более прозрачно и с меньшим влиянием на процесс создания html-кода страницы.
Под заголовком, где крупные буквы с минимальным интерлиньяжем совсем не радуют глаз (заголовок «не читается», но по высоте занимает полэкрана!) мы видим три явно служебные ссылки, которые (как неожиданно!) занимают остаток экранчика.
В общем, делая версии для каждого размера, надо думать о человеке, а не о мифическом покрытии всех разрешений и не о доходах (это шпилька в сторону «мобилоделателей», которые еще треть страницы на мобильнике баннером занимать умудряются)!
P.S. Лично меня в «мобильных» версиях и адаптивной верстке больше беспокоит, что в них нельзя масштаб менять пальцами — автор свято верит, что он выбрал наилучшие размеры шрифтов, и не оставляет варианта зума-анзума. Лично мне куда приятнее включать (если есть возможность) «десктопный вид» сайтов, и уже с зумом и протяжкой через экран читать — получается куда понятнее, удобнее, да и сайты, привычные с десктопа, быстрее в обращении оказываются, все уже знаешь, где находится.
Первый турист, поехавший в Антарктиду, с фотографировавший человека на фоне снега, может помешать делать то же тысячам других людей.
Впрочем, зачем в Антарктиду ехать. Фото на фоне ковра на стене — это тоже повод для копирайта!
А я вот думаю, что для туристов этакая махина может неплохим объектом стать.
> Плюсы: относительно недорогой, возможность замены дисков hot-swap, собственный программный RAID.
Собственный RAID — это неплохо. Собственный программный RAID — это зло. Вы потенциально не воткнете эти диски в обычный ПК, да и в чужой NAS можете не воткнуть, потому что заранее неизвестно, какой формат этого «программного RAID». И даже если сегодня он совместим с ОС на ПК, то после обновления firmware что-то может и измениться. В общем, вопрос тонкий. Можно только молиться на производителя NAS, что они будут делать все на базе стандартных линуксовых решений, и зеркало под линуксом увидится (про эту модель не скажу, так ли это).
Идеально еще одну такую коробку в ЗИП иметь, или уже, и правда, собирать все на базе любимой ОС и обычного «писюка» (только выбрать вариант, чтобы дисков влезало побольше) — оно будет понятнее в обслуживании.
Правда.
Тач — это на устройствах, где есть сенсор.
Вы забываете другое: во-первых, чтобы зайти в приложение, печатать цифры логина и цифры пароля каждый раз — это много цифр. Это якобы безопаснее, но по факту провоцирует безопасность эту нарушать. «Это юзеры сами нарушили», я знаю.
Во-вторых, вход в интернет-банк лично для меня — занятие не ежедневное. Цифры логина и цифры пароля постоянно держать в голове от этого не очень получается: они просто не нужны так часто.
В-третьих, банк, в отличии от Вас, думает о всех пользователях, даже о тех, кто не в том подмножестве, где Вы.
Я бы предпочел вариант с выбором своего логина и своего пароля. Меня бы это устроило, я бы символы вписал. Вас бы это тоже устроило, правда же?
Условно (не про это приложение): приложение не грузится — о, хорошо, оно не будет мешать. Приложение спрашивает пароль постоянно — о, это не проблема, это безопасность. И пр.
Статья хорошая, с этими оговорками. Только я не понял, какая связь между рассказом о приложении и о том, как в чате милые девушки толково помогают? Банк в этом смысле, и правда, старается идти навстречу клиенту ) Но я бы в чате аватарку девушки сделал поулыбчивее :)
Честно говоря, приложение Сбера получше будет: крупнее надписи, удобнее вход. С логином в Альфе вообще сложно как-то, дается логин и пароль цифровой, на символьный не сменить, а такую цепочку цифр (я про логин) не запомнить. Получается, что единственный доступный вариант — использовать вариант «сохранить логин» (т.е. он не будет спрашиваться при каждом входе, нужно будет только пароль вводить), но тогда его вообще можно было бы убрать, оставив крупный нумпад для ввода пароля (сравните ввод его в приложении Сбера и в приложении Альфы).
Это все — мелочи. Спасибо, что ПО развиваете, и что стараетесь к людям относиться по-человечески. Но вот со статьей получилось странно: начали с разговора, что от программы не воротит, а закончили чатом и личным общением с девушками. Вы бы после такого описания, скажем, автомобиля машину бы не купили, правда? Но в зачем PR-отделу пойдет, другое дело, что банк старается быть ближе к клиентам, а клиенты такую «развесистую клюкву» читать бы вряд ли хотели.