Комментарии 393
Gmail заполучил редизайн в духе Material Design
Материальным «десигном» там и не пахнет. А вот традиционной для Гугола дерьмовой реализацией — вполне.
В последнем редизайне gmail'а такое впечатление, что они просто кнопки покруглее сделали, пэддинга добавили и цвета немного поменяли. Сама структура интерфейса, вроде как, вообще не поменялась.
Текст стал не «стройным и лаконичным», а во-первых разноплановым «в табах наименования приплюснутые» (остальной текст нормальный по соотношению высота-ширина), а во-вторых оно все мыльное-мыльное.
И гугл в своих редизайнах, в общем-то, довольно вольно этим рекомендациям следует:
А потом их ставят в такие условия, что спецы быстро понимают работу системы и оптимизируются под неё (или уходят). Когда контора маленькая, то шансы сделать что-то есть, когда размер даже в процент Гугла, то руководство (даже если заинтересовано) не пойдёт к каждому, чтобы узнать что надо и не выяснит итог. Будет иерархия, каждый уровень имеет ограничение производительности и ограничение обслуживамых узлов, чем больше низовых винтиков, тем больше уровней иерархии и вносимого ими хаоса, нужен KPI (тот самый ненавидимый всеми, кроме манагеров). А манагеры не могут придумать нормальный KPI (как вариант — его нет в природе) и всё сводится к мастштабу (незаметные баги против редизайна) и картинке(подумаешь лезущие надписи и падения — тут вон какая разница).
Чтобы этих лучших спецов не получили конкуренты
Ну хоть какие то рамки приличия должны быть.
Я запилил себе в мобилу девятый ведропирог. Там естественно стоял хром.
Дык он весит 212 метров! О_о
Что в него такого засунули, что он столько весит?
Что в него такого засунули, что он столько весит?
Каким образом оно умудряется съесть 2 потока от i7-6600U (право, не самого слабого ноутбучного cpu) при банальных действиях вроде перехода из папки в папку — ума не приложу.
Yamail, rambler, afterlogick, roundcube — все летают, если perfomance-режим включен.
При этом Firefox спокойно кушает аналитику и все ок. И это на отнюдь не слабом ноуте MSI GE60 на SSD. Чем можно положить одну единственную открытую вкладку с аналитикой я хз
Ну и в принципе все действия стали сильно тупить. Переключение на другую категорию писем, открытие письма, открытие спама… Почему теперь все делается так долго? :(
Может, зависит от общего количества писем?
А вот вкладка с новым Gmail у меня сжирает примерно в 2 раза больше памяти, хотя там всего лишь список из десятка писем открыт. Даже не сами письма — просто папка с заголовками писем.
При работе правда особо не тормозит — жрет до гигабайта памяти в пике, загружает непойми какой работой 2 ядра, но со стороны взгляда пользователя работает пока относительно сносно.
>жрет до гигабайта памяти в пике…
>но со стороны взгляда пользователя работает пока относительно сносно.
ШТА??? Вы хоть сами себя слышите?
Да, ссылочка выглядит странно и подозрительно, но такая она в документации support.google.com/mail/answer/15049?hl=en
— Открыть HTML версию
— Вверху будет жёлтая плашка (но это не точно), там можно включить HTML режим по-умолчанию.
Но есть и плюсы, переключился на базовую, сразу увидел 2 важных непрочитанных письма, которые в оригинальной гмейле не рисуются, т.к. попало в другую категорию. Просто смешно.
Кстати непонятно, почему HTML-версия такая убогая. Только чтобы лучше продавать свою хреновый материал? Ведь можно нормально сделать, чтобы глаза не вытекали…
Ведь можно нормально сделать, чтобы глаза не вытекали…Но… зачем? Если для вас «looking like an ARPANET website» это проблема — ну добавьте в свой браузер стилей каких захотите.
А если вам хочется чтобы вам разжевали и в рот положили… ну так для вас работают тысячи дезигнеров и программистов… и порождают мегатонны добра, которые потом требуют от вас покупки десятков гигабайт памяти.
Не надо тут ложной дихотомии проводить, дурной прием.
Не надо тут ложной дихотомии проводить, дурной прием.Причём тут ложная дихотомия?
Рассмотрите не сам этот сайт, в отрыве от всего остального, а тенденцию.
Первый сайт: ⅔ передаваемых данных — это, собственно, то, что хотят донести до пользователя. Можно использовать 286ю с парой гигов памяти, Arachne — и всё будет нормально читаться.
Второй сайт: информация — где-то ½ передаваемых данных (на самом деле нет, смотри ниже — это дико смешно). Но вам нужна как минимум Windows98, браузер с поддержкой DHTML и 16MB памяти. И, главное — сайт перестал нести информацию, он теперь несёт видение мира какого-то «дезигнера».
Третий сайт. Полезной информации — ⅒ от передаваемых данных. И то — это достигнуто тем, что на сайте весьма немало текста. Было бы чуть меньше — получили бы, что полезных данных там 5% или ещё меньше. И никакого Windows 98! Теперь нам нужна XP, как минимум, и 128MB памяти (сама XP требует меньше, но достаточно новые Firefox или Chrome, которые могут всё это понять и изобразить, на 32MB запускать не стоит).
Вишенка на тортике: про ½ на втором сайте — это, на самом деле, я посчитал, сайт без подключённой Google Analytics! Которая тоже будет скачиваться с того же сайта и жрать ресурсы браузера. Как её учитывать — я не знаю (там 43K скачивается с Гугла, что ровно в 10 раз больше, чем всё остальное, что есть на том сайте вместе взятое).
Покажите, где на этом разжеваном сайте нужны десятки гигабайт.Так это ещё не до конца разжёванный сайт! У него ещё всё впереди! Через годик появится ещё один «ещё более лучший сайт», уже не в 60K, а в 600K (по тем временам это будет «небольшая персональная web-страничка»), потом 6MB и так далее.
А если вы думаете иначе и так уж хотите показать, что дихотомия — ложная, то объясните, пожалуйста: почему потратить в сто раз больше ресурсов, чем нужно, и передать в десять раз больше информации, чем нужно — это нормально, а вот потратить в тысячу раз больше ресурсов и передать в тысячу же раз больше данных, чем нужно (что мы на странице обновлённого GMail'а и наблюдаем) — это ужос?
Как по мне — так ложный путь начался со второго сайта: вместо того, чтобы использовать стили браузера и, если они плохи, менять их — мы передаём контроль «дезигнерам» и «аналитикам». Которые, разумеется, будут пичкать ваш сайт всякими «гениальными идеями» (весом сначала в десятки и сотни килобайт, потом в мегабайты, а со временем и гигабайты могут быть, да), пока оно не начнёт тормозить у них на машине за $10'000. Потом это чуток подрихтуют и ускорят — и вам придётся это есть. И я вижу только один способ не получить этого эффекта: не решать проблемы там, где это неуместно.
Что из всего этого выходит — отлично иллюстрируют картинки под спойлером
Но вот именно это — и приводит, через несколько итераций, к тому, что наблюдается в новой версии GMail'а.
Если бы господа дезигнеры реально хотели, чтобы все пользователи ощастливились их разработками — они могли бы сделать стандартные стили в Chrome (или Firefox или где-там ещё) такими, чтобы сайты без CSS выглядели бы «стильно, модно, молодёжно». Это потребовало бы куда меньше ресурсов — и было бы проще сделать (так как мы делаем стиль для браузера, который мы контролируем, то никакиз fallback'ов для MS IE 6 там не нужно).
Однако… это невыгодно. А вот вкручивать мегабайты кода, жрущие потом у пользователя гигабайты памяти — выгодно. Потому первое не делается, а делается второе.
А если вы думаете иначе и так уж хотите показать, что дихотомия — ложная, то объясните, пожалуйста: почему потратить в сто раз больше ресурсов, чем нужно, и передать в десять раз больше информации, чем нужно — это нормально, а вот потратить в тысячу раз больше ресурсов и передать в тысячу же раз больше данных, чем нужно (что мы на странице обновлённого GMail'а и наблюдаем) — это ужос?
Потому что это — доведение до абсурда. Есть взаимообратные свойства — чем красивее сайт, тем тяжелее он для скачивания пользователем. В качестве скалярной свертки оценки качества сайта можно брать время, за которое пользователь обрабатывает поступающие письма. Чем оно ниже — тем сайт лучше (мы про гмейл или еще нет? Я уже запутался). Поэтому возвращаясь к этому моменту:
Первый сайт: ⅔ передаваемых данных — это, собственно, то, что хотят донести до пользователя. Можно использовать 286ю с парой гигов памяти, Arachne — и всё будет нормально читаться.
Данные — это не только текст. А то мы бы так в терминалах с Turbo Vision интерфейсами и сидели. А чо, оконная подсистема это лишь способ разбазаривания ресурсов!
Как по мне — так ложный путь начался со второго сайта: вместо того, чтобы использовать стили браузера и, если они плохи, менять их — мы передаём контроль «дезигнерам» и «аналитикам».
Вы не можете поменять то, как отображает браузер. Взять то же дефолтное отображение ссылок — оно просто ужасное во всех браузерах, и менять это не будут (не хотят?). Что мне как разработчику сайта делать? Пичкать пользователей неприятным UI или в CSS поменять отображение?
Я правильно понимаю, что CSS/JS вообще придумали люди, которые не смогли заставить создателей браузеров нормально его сделать?
Заметьте, что только первый сайт выглядит так, как я ожидаю, и занимает всё доступное место. С двумя другими этого, естесвенным путём, не происходит. Вместо этого «какой-то дядя» за меня решает — как должен выглядеть текст у меня в браузере.
Отлично решил дядя, потому что он разбирается в эргономике. Вам владелец любого журнала (физического) объяснит, почему текст строками длиной в полметра (у меня 27" например), это ужас.
Но вот именно это — и приводит, через несколько итераций, к тому, что наблюдается в новой версии GMail'а.
Итераций к чему? Если к увеличению объема сайта разжиревшими фичами, то как я уже выше сказал, у этого процесса есть момент после которого новые фичи делают сайт *менее* удобным. То что кто-то не умеет в оптимизацию — их проблемы. Пара таких ошибок и пользователи уйдут на какой-нибудь протонмейл и все.
Если бы господа дезигнеры реально хотели, чтобы все пользователи ощастливились их разработками — они могли бы сделать стандартные стили в Chrome (или Firefox или где-там ещё) такими, чтобы сайты без CSS выглядели бы «стильно, модно, молодёжно»
Господа дезигнеры никак не могут влиять на хром и файрфоск. Особенно, когда им нужно, чтобы и в хроме и ФФ отображалось одинаково. А еще должно работать в браузерах IE10+, если не старше, туда стандартные стили тоже бекпортируем? Или объявим их ненужными?
А то мы бы так в терминалах с Turbo Vision интерфейсами и сидели.Я лично был бы счастлив. Единственную проблему Borland C++ 3.1 (невозможность использования режимов с размерами больше 80 столбцов и 50 строк), я думаю, со временем бы разрешили — а больше, по большому счёту, ничего и не нужно для работы.
Я не говорю, что с тех пор не появилось в разных продуктах разных полезных фич. Но вот вещей, которые нельзя было вписать в текстовый режим и Turbo Vision… я не могу придумать. Да, красивые градиенты и всякие перепархивающие финтифлюшки я нужными для работы не считаю.
А чо, оконная подсистема это лишь способ разбазаривания ресурсов!Turbo Vision, строго говоря, тоже. Turbo Pascal 6 требует заметно больше ресурсов, чем Turbo Pascal 3. Но он позволяет делать многие вещи, которые принципиально невозможны в «старой» парадигме (например открыть один и тот же документ в двух окнах, чтобы смотреть на разные его места), так что он не вполне бесполезен (забавно, кстати, что «новые технологии» примели к тому, что эта, такая простая и естественная, в многооконной среде, фича теперь мало где поддерживается).
мы про гмейл или еще нет? Я уже запутался.Про GMail. Остальные сайты — для демонстрации тенденции.
Вы не можете поменять то, как отображает браузер.Я — не могу. А Гугл — мог бы, но не хочет. Поддержка пользовательских стилей была выпилена давным-давно в пользу вот того ужаса, что мы сейчас наблюдаем в «нормальном», не «базовом» режиме.
А «базовый режим» — это реликт из другой эпохи, когда это было возможно.
Я правильно понимаю, что CSS/JS вообще придумали люди, которые не смогли заставить создателей браузеров нормально его сделать?Давайте не валить всё в одну кучу, да? CSS/JS вообще не имеют никакого отношения к происходящей вакханалии. Они придумывались другими людьми и для совсем других целей.
Что действительно начало эту безумную гонку — так это DHTML. Он превратил web-страницы из чего-то простого и разумного в нечто, что в принципе невозможно сделать эффективно. КПД использования ресурсов сразу упал ниже 1% и продолжает падать.
Причём сделано это было со вполне конкретной целью: нужно было, чтобы Internet Explorer «умел» что-то, чем Netscape Navigator нельзя было научить «в принципе». Ну а дальше — как с поджогом травы: хотели выгнать зверей на открытое пространство — а начался лесной пожар.
Вам владелец любого журнала (физического) объяснит, почему текст строками длиной в полметра (у меня 27" например), это ужас.Извините — но передо мной не журнал, а, извините, монитор. Компьютерный. И потому неплохо бы мне предоставить возможность решать — строки какого размера мне нравятся. А владельцы фурналов (физических) пусть делают то, что они знают и умеют: печатают журналы.
Если к увеличению объема сайта разжиревшими фичами, то как я уже выше сказал, у этого процесса есть момент после которого новые фичи делают сайт *менее* удобным.Вот только этот момент — он очень субъективен.
Пара таких ошибок и пользователи уйдут на какой-нибудь протонмейл и все.Вот не верится мне что-то. Пока что даже HotMail — живее всех живых (пусть его и переименовали).
Господа дезигнеры никак не могут влиять на хром и файрфоск.Вы думаете между разработчиками Chrome и GMail кто-то глухую стену построил? Сомневаюсь.
Особенно, когда им нужно, чтобы и в хроме и ФФ отображалось одинаково.В случае с YouTube это их не остановило, а в Gmail — это проблема?
А еще должно работать в браузерах IE10+, если не старше, туда стандартные стили тоже бекпортируем? Или объявим их ненужными?Можно для них оставить старую версию на первое время. Дальше уже смотреть на реакцию ощественности: если всё будет правильно — но все начнут ставить новый Chrome, чтобы пользоваться новым, более удобным, GMail'ом. Если нет и Chrome начнут убегать… значит редизайн был вообще не нужен — и на это нужно как-то отреагировать…
Я лично был бы счастлив. Единственную проблему Borland C++ 3.1 (невозможность использования режимов с размерами больше 80 столбцов и 50 строк), я думаю, со временем бы разрешили — а больше, по большому счёту, ничего и не нужно для работы.
Хорошо, что не вы задавали тенденцию, а то я даже не знаю, как бы я жил.
Я не говорю, что с тех пор не появилось в разных продуктах разных полезных фич. Но вот вещей, которые нельзя было вписать в текстовый режим и Turbo Vision… я не могу придумать. Да, красивые градиенты и всякие перепархивающие финтифлюшки я нужными для работы не считаю.
А я считаю.
Я — не могу. А Гугл — мог бы, но не хочет. Поддержка пользовательских стилей была выпилена давным-давно в пользу вот того ужаса, что мы сейчас наблюдаем в «нормальном», не «базовом» режиме.
Предлагаете пользователю каждый сайт в интернете настраивать?
Интересно, почему в десктопных приложениях такого почти нет… Ну, кроме совсем уж профессиональных, вроде IDE. Но и там кастомизация сильно ограниченнее любой страницы с css.
Давайте не валить всё в одну кучу, да? CSS/JS вообще не имеют никакого отношения к происходящей вакханалии. Они придумывались другими людьми и для совсем других целей.
Что действительно начало эту безумную гонку — так это DHTML. Он превратил web-страницы из чего-то простого и разумного в нечто, что в принципе невозможно сделать эффективно. КПД использования ресурсов сразу упал ниже 1% и продолжает падать.
Вы уж определитесь
> Dynamic HTML, or DHTML, is an umbrella term for a collection of technologies used together to create interactive and animated websites[1] by using a combination of a static markup language (such as HTML), a client-side scripting language (such as JavaScript), a presentation definition language (such as CSS), and the Document Object Model (DOM).
Альтернатива DHTML это постбек на каждое изменение страницы на сервер, я правильно понимаю? Потому что любая динамика на странице — это JS и DHTML.
Извините — но передо мной не журнал, а, извините, монитор. Компьютерный. И потому неплохо бы мне предоставить возможность решать — строки какого размера мне нравятся. А владельцы фурналов (физических) пусть делают то, что они знают и умеют: печатают журналы.
Ни один пользователь в мире не будет кастомизировать все сайты, которые посещает. Нужно зайти — и чтобы оно красиво все показывало. Не говоря о том, что многие хотят просто более быструю лошадь, как вы с примером с Turbo Vision.
Вот только этот момент — он очень субъективен.
Ну проведите экспертную оценку и сделайте объективный показатель, проблем-то. Только это не особо нужно, общий принцип понятен, а выяснять конкретную точку для каждого конкретного продукта не имеет большого смысла. Просто если сильно от оптимума отойти, продукт закроется.
Вы думаете между разработчиками Chrome и GMail кто-то глухую стену построил? Сомневаюсь.
Более чем в этом уверен.
В случае с YouTube это их не остановило, а в Gmail — это проблема?
Видимо, гугл может забить на поддержку других бразуеров, что сказать. А среднестатистический девелопер не может.
Можно для них оставить старую версию на первое время. Дальше уже смотреть на реакцию ощественности: если всё будет правильно — но все начнут ставить новый Chrome, чтобы пользоваться новым, более удобным, GMail'ом. Если нет и Chrome начнут убегать… значит редизайн был вообще не нужен — и на это нужно как-то отреагировать…
Люди еще IE9 пользуются, сам встречал реальных людей. Кто там что начнет новое ставить?
В таком случае какие у вас претензии к новому дизайна GMail? Там с градиентами всё вроде неплохо.Я не говорю, что с тех пор не появилось в разных продуктах разных полезных фич. Но вот вещей, которые нельзя было вписать в текстовый режим и Turbo Vision… я не могу придумать. Да, красивые градиенты и всякие перепархивающие финтифлюшки я нужными для работы не считаю.А я считаю.
Предлагаете пользователю каждый сайт в интернете настраивать?Воообще-то идея CSS заключалась в том, чтобы настроить все сайты под свои личные предпочтения. Один раз.
Но и там кастомизация сильно ограниченнее любой страницы с css.Что, несомненно, является преимуществом десктопных приложений.
Альтернатива DHTML это постбек на каждое изменение страницы на сервер, я правильно понимаю? Потому что любая динамика на странице — это JS и DHTML.Собственно в этом и проблема, что «любая динамика на странице — это JS и DHTML». От Turbo Vision (где, всё-таки были, хотя бы менюшки и диалоговые окна) мы вернулись, фактически, во времена BASIC, где каждая веб-страничка сама реализует «из говна и палок» все контролы: скроллбары (хотя они, вроде как в HTML даже и есть), кнопки, диалоговые окна и вообще всё-всё-всё. Дикий регресс по сравнению с операционками конца прошлого века.
Не говоря о том, что многие хотят просто более быструю лошадь, как вы с примером с Turbo Vision.Вы так и не ответили — зачем вам все эти градиенты и прочие финтифлюшки и почему, если они для вас нужны, вас не устраивает вдруг новый GMail или Google Inbox.
Более чем в этом уверенА прочём тут это? Да, Гугл не всё делает сам и, более того, драйвера для железа, используемого даже в телефонах, которые он выпускает, сам не пишет.
Но браузер-то он сам делает.
Люди еще IE9 пользуются, сам встречал реальных людей. Кто там что начнет новое ставить?Но эти же люди станут пользоваться GMail'ом если увидят новые градиенты?
В таком случае какие у вас претензии к новому дизайна GMail? Там с градиентами всё вроде неплохо.
Не надо доводить до абсурда
Воообще-то идея CSS заключалась в том, чтобы настроить все сайты под свои личные предпочтения. Один раз.
Не заключалась
Что, несомненно, является преимуществом десктопных приложений.
Свобода это рабство
Собственно в этом и проблема, что «любая динамика на странице — это JS и DHTML». От Turbo Vision (где, всё-таки были, хотя бы менюшки и диалоговые окна) мы вернулись, фактически, во времена BASIC, где каждая веб-страничка сама реализует «из говна и палок» все контролы: скроллбары (хотя они, вроде как в HTML даже и есть), кнопки, диалоговые окна и вообще всё-всё-всё. Дикий регресс по сравнению с операционками конца прошлого века.
Не помешало бы иметь нормальную модульную систему, чтобы делать распространяемые контролы, но к html это имеет мало отношения.
Вы так и не ответили — зачем вам все эти градиенты и прочие финтифлюшки и почему, если они для вас нужны, вас не устраивает вдруг новый GMail или Google Inbox.
Потому что мне приятнее работать с таким софтом, очевидно.
Та же причина, почему люди играют в графонистые игры, хотя можно было бы просто текстом описать «вы видите невероятно красивый пейзаж».
А прочём тут это? Да, Гугл не всё делает сам и, более того, драйвера для железа, используемого даже в телефонах, которые он выпускает, сам не пишет.
Но браузер-то он сам делает.
Вы статью по ссылке-то прочитали?
С одной стороны, очевидно, что андроид — ключевая платформа для Гугла и в исправление багов на нём были угроханы колоссальные средства. С другой стороны, не понятно почему они были угроханы в фиксы в кодовой базе Хромиума, а не драйверов или ОС (ведь у Гугла там достаточно высокий уровень контроля всего на всех этапах). Исправления там принесли бы пользу всему софту на андроиде, а здесь — только Хромиуму. Скорее всего дело во взаимодействии департаментов, когда программисту Хромиума проще исправить проблему у себя в коде здесь и сейчас, чем эскалировать её на 3-4 уровня вверх, потом в сторону, а потом на 3-4 уровня вниз. Людей, которым такое интересно, в любой компании меньше, чем нужно было бы.
Но эти же люди станут пользоваться GMail'ом если увидят новые градиенты?
А они пользуются новым хромом, потому что он поставляется as is, и им не надо его донастраивать. И никто в здравом уме этим заниматься не будет. Я клиентским CSS пользовался пару раз в жизни на нескольких сайтах, где разметку сделали совсем уж убогой.
И, тем не менее, компания, которая завела стандарты на десктопе снаяла такой ролик. Потому что иметь унифицированный интерфейс — это удобно. Когда ты во всех программах имеешь похожую систему меню — то тебе не нужно помнить что движение курвора вниз в Turbo Pascal — это «x», в VI — это «j», а в Emacs — вообще Ctrl-n (все клавиши невыдуманные).Что, несомненно, является преимуществом десктопных приложений.Свобода это рабство
Не помешало бы иметь нормальную модульную систему, чтобы делать распространяемые контролыПеред тем, как устраивать возню с распространяемыми контролами — неплохо бы иметь набор стандартных.
но к html это имеет мало отношения.А к чему это имеет отношение?
Потому что мне приятнее работать с таким софтом, очевидно.Тогда в чём проблема с GMail?
Вы статью по ссылке-то прочитали?Прочитал. Я там даже эту чушь комментировал. Но если вы так хотите ещё...
ведь у Гугла там достаточно высокий уровень контроля всего на всех этапахУ Гугла нет (и никогда не было) контроля над критической стадией: доставки обновлённого драйвера пользователю. Если у какого-то производителя в какой-то железке драйвер работает неправильно, то максимум, что может сделать Гугл — включить проверку в CTS — тогда в следующей версии Android (и, возможно, в следующем телефоне производителя) эти драйвера будут исправлены.
В отличие от Android — Chrome (и ChromeOS) обновляется регулярно и автоматически.
И оба этих факта (как проблемы с обновлением Android и автоматические обновление Chrome) — общеизвестны.
Потому я вообще не понимаю какого фига в разговор о GMail и Chrome вы притягиваете Android.
А они пользуются новым хромом, потому что он поставляется as is, и им не надо его донастраивать.Тогда почему новый Хром не может с собой принести нормальные компоненты, которые помогли бы реализовать нормальный интерфейс, не требующий тянуть за собой мегабайты кода?
И, тем не менее, компания, которая завела стандарты на десктопе снаяла такой ролик. Потому что иметь унифицированный интерфейс — это удобно. Когда ты во всех программах имеешь похожую систему меню — то тебе не нужно помнить что движение курвора вниз в Turbo Pascal — это «x», в VI — это «j», а в Emacs — вообще Ctrl-n (все клавиши невыдуманные).
14 стандартов.жпг
Перед тем, как устраивать возню с распространяемыми контролами — неплохо бы иметь набор стандартных.
Есть набор стандартных. Инпут, наприер, или лейбл там.
Тогда в чём проблема с GMail?
Я уже 100 раз отвечал на этот вопрос. Научитесь пожалуйста читать, что вам пишут.
Тогда почему новый Хром не может с собой принести нормальные компоненты, которые помогли бы реализовать нормальный интерфейс, не требующий тянуть за собой мегабайты кода?
Потому что никто не будет пользоваться вендоро-специфическими вещами. Вон добавляют в HTML всякие audio/video/..., ими пользуются. А brand new chrome controls будут валяться на свалке истории.
Дефолтное отображение ссылок прекрасно. Синий цвет и подчёркивание однозначно определяют ссылку среди других HTML элементов, посещённые ссылки меняют цвет, чётко показывая, что было посещено, а пунктирное выделение при фокусе идеально отображает положение этого самого фокуса. Дефолтная ссылка идеальная и эргономичная. Но потом приходят дизайнеры, и появляются ссылки как кнопки, кнопки как ссылки, а сейчас чаще всего ссылки, выглядящие как окружающий текст, где только разработчики сайта могут сразу сказать, куда можно кликать, да и то не всегда.
Я выше давал ссылку на сайт. На том же хабре цвета ссылок намного более приятные — и, конечно же, кастомные. И на гитхабе. И на SO. Да и вообще на любом сайте. Идея выделять ссылки — хорошая. Те кислотные цвета, которые выбраны в качестве дефолтных — не очень. Да и HTML без форматирования выглядит ужасно.
Вы можете уменьшить ширину окна браузера, увеличить страницу через Ctrl + +, и на ней ничего не разъедется, а прикреплённый футер, шапка и сайдбар не закроют 70% страницы.
Буквы в полэкрана мне тоже не нужны, вот в чем дело. Меня устраивает ситуация как с хабром, где текст занимает только половину экрана
Это один из самых ужасных проступков дизайнеров и маркетологов — требование, чтобы сайт везде отображался одинаково.
Дизайнеры явно с этим не согласны. У них каждый пиксель отступа обоснован каким-нибудь исследованием на тему эргономики.
И менее заметные. Вашу ссылку на сайт выше я, возможно, и не заметил из-за бледной ссылки.
Кстати, спасибо за пинок, сделал нормальные ссылки в постах на Хабре.
Достаточно заметные, хз. Не помню ни одного сайта, где ссылка была бы незаметной. Когда их делают кнопками и прочее уродство — согласен, не очень. Но когда немного меняют дефолтный цвет на менее вырвиглазный — то наоборот, улучшение.
А мне нравится. Но, к сожалению, даже неплохая структура Хабра без его стилей не читаемая. Отчасти из-за ограничений HTML, отчасти из-за того, что никто не сидит без стилей.
Ну вот пример по ссылке выше, самый оригинальный сайт на чистом HTML. Не знаю, как вам, а мне на него без слез взглянуть не получается.
Первое предложение с уменьшением окна браузера вы пропустили?
То есть я должен подстраивать размер окна хрома для каждого из полусотни табов, и еще и ресайзить после переключения между ними? Или группировать табы по окнам по ширине экрана? Эргономика такого чувствую не сильно высока.
Да чёрт с ними и с их глупыми исследованиями, которым они сами не следуют, а только декларируют следование, чтобы зарплату себе набить.
Понял, бесполезные нахлебники. Так их.
Вы их (ссылки) просто не заметили.
Ну так-то вы и обычные ссылки не все замечаете тогда :dunno:
Боюсь, теперь мы слишком удалились от этих ссылок. Вы про мозерфакингвебсайт? Мне нравится.
Идея оригинального мне нравится, но выглядит он вырвиглазно. Его наследники, пусть чутка тяжелее, воспринимать намного легче.
Хватит смахивания к правой (или левой) стороне монитора, винда выставит размер в половину экрана, что будет прямо замечательно для большинства сайтов. Тот же Хабр у вас занимает примерно столько же, только вместо пустот по бокам можно разместить что-нибудь полезное.
Не хватит, тот же гмейл мне нужен на весь экран. Хабр тоже, потому что это только глубокая ветка комментов занимает пол-экрана, а статья почти всё свободное место. Википедии, ютубы, msdn,… Вот тут и вопрос, мне при переключении между табами для каждого сайта получается надо менять размеры окна под конкретный таб? Простите, я все же думаю, что сайт должен подстраиваться под пользователя, а не наоборот. Дезигнер должен продумать, какие шрифты будут и сколько места подо что отвести, а не надеяться, что пользователь будет постоянно окно ресайзить под конкретный сайт.
Не хватит, тот же гмейл мне нужен на весь экран
На весь экран тоже без проблем — окно можно потянуть на верхнюю часть, если включён Aero Peek (хотя лично меня он бесит, я его отключаю всегда).
Ну вот пример по ссылке выше, самый оригинальный сайт на чистом HTML. Не знаю, как вам, а мне на него без слез взглянуть не получается.Там со шрифтами фигня какая-то творится и под старой оперой он очень хорошо выглядит (вероятно потому что она забила на шрифт и использует стандартный) и неплохо в IE. Только «fucking colors» и Add more contrast бесят.
Дизайнеры явно с этим не согласны. У них каждый пиксель отступа обоснован каким-нибудь исследованием на тему эргономики.Если бы всё было так сладко, как они рассказывают, то не было бы катастроф, когда выходит новый редизайн — и пользователи начинают массово сбегать.
То есть да — отступы важны и дизайн тоже важен, это объективно проверяемый факт.
Но вот рассказы про то, что дизайнеры знают как дизайн должен работать — увы, неправда. И это — тоже объективный факт.
не было бы катастроф, когда выходит новый редизайн — и пользователи начинают массово сбегать.
А их и нет.
Или вот ещё, свеженькое. Там, правда, до продажи с молотка дело не дошло и, вообще, есть шанс, что «всё обойдётся»… но рассказывать что пользователи не уходят из-за нового дизайна… не надо…
«Креативный редизайн» приводит к потере пользователей чаще, чем кажется — просто про это никому не интересно говорить (а как же бонусы? а повышения? а всякие плюшки, которых себе за «успешный запуск» выделили и потребили?), потому всплывают только случаи, когда всё уж совсем плохо.
Ну если для вас фраза Digg Redesigns, Loses More Than a Quarter of Audience и, через несколько лет, Digg.com, once thought worth millions, sold for $500K — это нормально, это так и надо…
Так это единичные случаи. Какой это процент от общего числа редизайнов?
То есть когда проект жил-жил, позябал, а потом оп-па: редизайн — и всё «попёрло».
Потому что если редизайн такого эффекта не даёт, а обрушить компанию, как мы видим, может — то нафига он вообще нужен?
Если судить по статистике, то редизайн — это такой поход в казино. Может повезти и ты получишь немного пользователей. Может не повезти — и ты их теряешь. Но иногда — выпадает «зеро» и всё накрывается медным тазом.
Как известно умные люди в казино не ходят. По крайней мере не пытаются там выиграть немного денег, когда их не хватает.
То что при этом автомобиль выглядить ещё и «стильнее» — это вишенка на тортике.
Если бы новый дизайн GMail'а весил бы меньше, чем более старый и грузился бы быстрее — я думаю недовольных было бы куда меньше.
Как металлурги выдали «на гора» сплавы, достаточные для легковушек — так задний привод стал историей. А для более мощных машин… не срастается.
Проблема в том, что если у вас привод на управляемые колёса, то возрастает (и существенно) нагрузка и, соответственно, падает надёжность. Дальше — дело за металлургами.
Именно потому переход на передний привод случился почти одновременно по всему миру. Как научились его делать — так и сделали. Это вот даже близко непохоже на обсуждаемый «редизайн»…
Кстати — вот вам неплохая заметка на эту тему: otvet.mail.ru/question/68616904. Так что я вообще не очень понимаю, про какой «переход» вы говорите, если достпны как переднеприводные, так и заднеприводные машины (ну и полноприводные как отдельный класс).
А разница в КПД (как и проблемы) — возникают при поворотах. На ровной-то дороге пофигу — тянуть или толкать. А при повороте — передний привод выгоднее, так как они движутся туда, куда нужно и мощность передают в правильном направлении.
При резком старте на детали кузова и раму идёт нагрузка на растяжение, тогда как в случае заднего привода — на сжатие.А теперь вопрос: почему мосты строят не из железа и не из бетона, а из железобетона?
P.S. Спасибо за то, что нашли ещё одно преимущество переднего привода… а теперь сделайте правильный вывод…
Я всё же считаю, что сжать — не так вредно для кузова, как растянуть, при равной силе воздействия. Разве не так?
Насчёт мостов — для жёсткости, очевидно, там сетка потому что, состоящая из ячеек. Такую конструкцию намного труднее разрушить, чем чисто бетонную. Меньше хрупкость. Железо имеет некоторую гибкость, я так понимаю, в случае сильного удара не будет эффекта раскалывания. Это как плексигласс. Верно?
Это как плексигласс. Верно?Примерно. Но вы главное упустили. Цитирую wikipedia:
При изготовлении железобетона прокладывается арматура из стали с высокой прочностью на растяжение, затем сталь натягивается специальным устройством и укладывается бетонная смесь. После схватывания сила предварительного натяжения освобождённой стальной проволоки или троса передаётся окружающему бетону, так что он оказывается сжатым. Такое создание напряжений сжатия позволяет частично или полностью устранить растягивающие напряжения от эксплуатационной нагрузки.Фишка железобетона в том, что бетон очень сложно раздавить, а сталь, наоборот, тяжело разорвать — потому в этой конструкции сталь работает на растяжение, а бетон работает на сжатие.
И это — лучший вариант для обоих материалов!
Я всё же считаю, что сжать — не так вредно для кузова, как растянуть, при равной силе воздействия. Разве не так?Не так. Как раз если бы вы почитали про железобетон и немного подумали, то поняли бы, что всё ровно наоборот. Растяжение менее вредно.
Однако есть ньюанс. Меньшие нагрузки на машине с передним приводом позволяют уменьшить толщину стали, из которой делают кузов! И даже преподнести это как конкурентное преимущество: «наш автомобиль на XX% легче при большем салоне». Однако… более тонкий стальной лист быстрее корродирует.
Я думаю именно этот эффект и приводит к тому, что вам кажется, что передний привод хуже для кузова. Нет, он как раз лучше — просто позволяет использовать чуть меньше стали… со всеми вытекающими.
Фишка железобетона в том, что бетон очень сложно раздавить, а сталь, наоборот, тяжело разорвать — потому в этой конструкции сталь работает на растяжение, а бетон работает на сжатие.
Из абзаца выше следует, что просто освобождённые стальные арматурины стремятся снова сжаться, и сжимают бетон в сотах (то есть вокруг себя). А бетон сжимается плохо, как Вы уже сказали, поэтому не происходит его разрушения. Но я не очень понимаю выигрыш от этого подхода. Если мы начнём это дело растягивать, оно будет растягиваться хуже, потому что перманентно стремится сжаться обратно?
Опять же, не все нагрузки — на растяжение. Взять тот же мост: нагрузка от пролётов и от транспорта — на растяжение. А вот удары больших волн в опоры снизу — нет. И сила льда, если он эти опоры начнёт сдавливать — тоже нет. А ещё есть сильный ветер… Но тут уже сложно, я не инженер)
Как раз если бы вы почитали про железобетон и немного подумали, то поняли бы, что всё ровно наоборот. Растяжение менее вредно.
Но автомобили не из железобетона, а из стали и алюминия…
Всё же я думаю, что передний привод в целом хуже. Даже в банальной ситуации «машина зарылась в глубокий снег» вам гораздо легче будет выехать, если у вас задний. Независимо от того, придётся ли подкапывать и подкладывать досочки. Ну и вообще когда одна пара колёс отвечает и за руление, и за крутящий момент — это не есть хорошо, имхо. Лучше разносить это на разные пары.
Простой пример — вы потеряли управление и у вас машина сорвалась в сложный занос и нет сцепления не на передней паре, ни на задней. Конечно, тут лучше всего полный привод, но задний всё же в данном случае предпочтительнее переднего: передние колёса вы можете использовать для задания направления, а задние — как ведущие, то есть у вас есть воздействие на обе пары (на заднюю — путём регулировки скорости её вращения, а значит, косвенно, и силы её сцепления с дорогой). В случае переднего привода вы задней парой вообще не управляете никак. Это плохо.
Но автомобили не из железобетона, а из стали и алюминия…И сталь и алюминий и вообще любой тонкий лист из любого малериала будет лучше переносить растяжение, чем сжатие. Железобетон позволяет эту проблему решить, но, как вы верно заметили, из железобетона автомобили не делают.
Но я не очень понимаю выигрыш от этого подхода. Если мы начнём это дело растягивать, оно будет растягиваться хуже, потому что перманентно стремится сжаться обратно?Выигрыш очень простой: любое воздейсвие (хоть сжатие, хоть растяжение, хоть изгиб) не сменит «знак» нагрузки. Сталь будет по-прежнему растягиваться (хотя, возможно, меньше, чем её «натянули» на заводе), бетон — сжиматься.
Ну и вообще когда одна пара колёс отвечает и за руление, и за крутящий момент — это не есть хорошо, имхо.Почему? Это, как раз, и есть основа, с которой все остальные преимущества переднего привода начинаются. То, что на кузов нагрузки снижаются — это мелочи. Самое главное — как раз то, что управляемые колёса становятся ведущими.
В случае переднего привода вы задней парой вообще не управляете никак.Если вы потеряли сцепление совсем — то тут уже всё. Но если рассмотреть весь спекрт возможностей… в тех местах, где машина с задним приводом уже войдёт в занос и потребует от вас из него «выруливать» машина с передним, скорее всего, просто-напросто не потеряет управление.
Пожалуй единственным реальным преимуществом заднего привода является возможность более быстрого разгона (так как в этом случае на ведущие колёса приходится большая часть эффективной массы автомобиля) — но для большинства автомобилей (кроме спортивных) в любом случае скорость разгона определяется мощностью двигателя, так что это преимущество остаётся, скорее, гипотетическим.
Даже в банальной ситуации «машина зарылась в глубокий снег» вам гораздо легче будет выехать, если у вас задний.Если у вас в городе нормально работают коммуальные службы, то это не «банальная», а «экстремальная» ситуация, извините. Для экстревалов существует полный привод.
Всё же я думаю, что передний привод в целом хуже.Если бы это было не так, то не произошло бы отказа от заднего привода. Сейчас модели с задним приводом — это уже реликты, «последние из могикан». Полный привод — да, для экстремалов или мощных машинок тут нет вариантов. Задний — уже почти ушёл в историю.
И сталь и алюминий и вообще любой тонкий лист из любого материала будет лучше переносить растяжение, чем сжатие.
Соглашусь. Но автомобиль — не лист, там конструкция очень большая и сложная, всё-таки. Так что всё равно нее всё так однозначно.
Сталь будет по-прежнему растягиваться (хотя, возможно, меньше, чем её «натянули» на заводе), бетон — сжиматься.
Мне кажется, Вы не поняли вообще принцип. Сталь, после того как бетон застыл, и её «отпустили», стремится вернуться в прежнее состояние, то есть сжимается, но бетон ей не даёт это сделать. Она, в своё очередь, прикладывает силу к бетону, сжимая его.
В итоге, если мы растянем конструкцию ещё больше, то сталь вытянется ещё несколько сильнее, чем была вытянута до этого перед заливкой. Но не порваться ей как раз поможет бетон, который держит её там, где она застыла внутри него.
Самое главное — как раз то, что управляемые колёса становятся ведущими.
Где-то это плюс (при неумелом управлении уйти в занос на заднем приводе куда легче), где-то — минус. Я не сказал бы, что управлять теми же колёсами, к которыми приложен крутящий момент — хорошая идея. Как минимум, это сильно усложняет конструкцию передней оси.
в тех местах, где машина с задним приводом уже войдёт в занос и потребует от вас из него «выруливать» машина с передним, скорее всего, просто-напросто не потеряет управление.
Тут пожалуй соглашусь. Хотя можно и с передним уйти в занос, только в этом случае у вас зад начнёт вилять.
Я кстати читал несколько лет назад, что для выхода из заноса на заднем приводе нужно отпустить газ, а на переднем — прибавить его. Что не всегда возможно в экстремальной ситуации (например, впереди машина, и на встречке машина приближается).
Если у вас в городе нормально работают коммуальные службы, то это не «банальная», а «экстремальная» ситуация, извините.
А при чём тут город? Вот возьмём к примеру проспект перед универом в Старом Петергофе (малонакселённая улица, уходящая потом к Ломоносову в виде шоссе, на которой до остановки вблизи универа почти нет домов). В снег её не чистит вообще никто, там в снегопад бывает до 3-4 см осадков. И вот в этой каше едут машины и автобусы. Я сам лично видел, как микроавтобус, пытаясь тронуться с остановки, плывёт по этой каше почти неуправляемый.
Задний — уже почти ушёл в историю
Вы забыли про городские автобусы и микроавтобусы всевозможных типов. Там почти всегда привод задний, даже у тех моделей, где двигатель спереди (я про микроавтобусы сейчас).
ru.wikipedia.org/wiki/Iveco_Daily
quto.ru/lcv/Volkswagen/Crafter/LT3f/van4d
ru.wikipedia.org/wiki/%D0%93%D0%B0%D0%B7%D0%B5%D0%BB%D1%8C_(%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%BE%D0%B1%D0%B8%D0%BB%D1%8C)
Мне кажется, Вы не поняли вообще принцип.Это вы его не поняли.
Но не порваться ей как раз поможет бетон, который держит её там, где она застыла внутри него.Нет-нет-нет. Бетон невероятно слаб к растягивающим нагрузкам. Как только его что-то начинает растягивать — он сыпется.
Всё проще. Если вы растянули прут силой, ну, скажем, 10 кг, а потом положили его в бетон и дали ему «схватится», то вы получите силу 5кг, действующую на прут и 5кг — на бетон (в разные стороны).
Прилагая на всю эту конструкцию силы до 5кг вы не порвёте прутья (они выдерживали 10кг ещё на заводе, не забыли) и не заставите бетон растягиваться (при растяжении нагрузка на бетон будет падать, при сжатии — расти, но она тоже останется в дипазоне 0-10кг).
Я не сказал бы, что управлять теми же колёсами, к которыми приложен крутящий момент — хорошая идея. Как минимум, это сильно усложняет конструкцию передней оси.Именно. Потому передний привод появился только когда появились материалы, способные это перенести.
Вы бы ещё про картерьные самосвалы вспомнили. Да, начиная с какого-то размера передний привод становится невозможно использовать, так как на задние колёса приходится сильно больше половины массы. В этом случае задний привод безальтернативен, тут и обсуждать нечего: вы просто не сможете эффективно управлять автомобилем, у которго на ведущие колёса, призванные толкать или тянуть, приходится 20% массы, а на ведомые — 80%.Задний — уже почти ушёл в историюВы забыли про городские автобусы и микроавтобусы всевозможных типов.
Речь идёт про малолитражки, где этот эффект несущественен.
Прилагая на всю эту конструкцию силы до 5кг вы не порвёте прутья (они выдерживали 10кг ещё на заводе, не забыли) и не заставите бетон растягиваться (при растяжении нагрузка на бетон будет падать, при сжатии — расти, но она тоже останется в диапазоне 0-10кг).
Так в чём профит-то получается? Что я могу нагрузить бетон до 5-7 кг, и он не рассыплется (а без стальных прутьев рассыпался бы уже на 3-4 кг, условно)?
так как на задние колёса приходится сильно больше половины массы
Для пассажирских автобусов и микроавтобусов это не так очевидно — люди по всему салону находятся относительно равномерно, а не втиснуты в энергетическую сферу, лежащую на задней площадке :)
Правда, есть ещё мотор и бензобак, которые весят очень много.
Что я могу нагрузить бетон до 5-7 кг, и он не рассыплется (а без стальных прутьев рассыпался бы уже на 3-4 кг, условно)?В том, что эти конструкция, в отличие от бетона, может выдерживать растягивающие нагрузки, которые бетон, сам по себе, почти не держит.
Я растягивающие нагрузки — это прежде всего изгиб (внутренние слои сжимаются, внешние растягиваются)
Для пассажирских автобусов и микроавтобусов это не так очевидно — люди по всему салону находятся относительно равномерно, а не втиснуты в энергетическую сферу, лежащую на задней площадке :)Какая сфера? Там задняя площадка, куча стоячих мест. Или если нет площадки — то какая-нибудь тяжеленная печка. Аспереди, с мест впереди колеса, всех прогоняют утрамбовывается дальше в салон. Так что у автобуса с пассажирами легко как раз под 80% на задние колёса получается.
Там задняя площадка, куча стоячих мест.
Она полностью забита только в час-пик. На самом деле, гораздо больше весит двигатель, расположенный сзади (так конструктивно проще ставить, легче обслуживать и чуть лучше охлаждение, я так понимаю).
Автобус часть времени вообще ездит полупустым (и для него это более частый кейс, чем для самосвалов) — но ничего плохого с ним при этом не случается.
Вы лучше покажите хоть один пример, когда радикальный редизайн так же резко привлёк пользователей.
Очевидно, редизайн сам по себе просто логически не может привлечь новых пользователей, так как чтобы увидеть редизайн, вы уже должны быть пользователем. Получается, задача редизайна — сделать уже имеющихся либо новых пользователей более лояльными.
Получается, задача редизайна — сделать уже имеющихся либо новых пользователей более лояльными.И мы уже знаем, что он с этой задачей справляется плохо. Иногда выпадает «чёрное» и вы немного улучшаете своё положение, иногда «красное» и вы его ухудшаете. А иногда (редко) выпадает «зеро» и вы теряете вообще всё.
Но при этом нормальные люди не пытаются заработать денег в казино — однако пытаются удержать клиентов делая радикальный редизайн. Почему?
И мы уже знаем, что он с этой задачей справляется плохо.
Почему же? Исходя из наблюдений — вполне хорошо справляется.
А 501е джинсы, между тем, продаются столетиями (и да — я знаю, что там пару заклёпок убрали… это не тот уровень редизайна, о котором мы говорим).
P.S. Опять-таки, если бы GMail имел опционально 10-15 «новых стильных молодёжных» дизайнов — то к нему бы тоже претензий не было. Если меня лично это не задевает, но кому-то нравится — то почему бы и нет? Но ведь всё происходит не так.
Особенно, когда им нужно, чтобы и в хроме и ФФ отображалось одинаково.
Я так понимаю, идея выше была в том, чтобы сделать стильный современный UI, и тогда, возможно, некоторые компании уже не будут гнаться за «одинаковостью во всех браузерах», то есть поменяется сам подход (как в случае с приложением, выпущенным под разные ОС, при этом не навязывающем единый UI на всех).
чем нужно, и передать в десять раз больше информации, чем нужно — это нормально, а вот потратить в тысячу раз больше ресурсов и передать в тысячу же раз больше данных, чем нужно (что мы на странице обновлённого GMail'а и наблюдаем) — это ужос?
Почему заплатить за работу 1000 тугриков — нормально, а 10 — ужос-ужос?
Вообще это не только проблема больших компаний вроде Google, но и проблема любой софтверной компании. Исправление багов — деньги не приносит, поэтому на это забивают так как нужна сиюминутная отдача, а не перспективы стабильности продукта.
То, что некоторые продукты у Гугла купленные — это нормально. У многих фирм так. Ещё чаще — покупается компания, продукт некоторое время используется… а потом переписывается на «внутренних» технологиях. Примеры — Laticce C/Microsoft C/Visual C++, PowerPoint, Google Docs… но вот конкретно GMail — был-таки написан в гугле. В рамках 20% проекта. Когда 20% проекты ещё существовали.
<At the time when Gmail was being developed, existing email services such as Yahoo! Mail and Hotmail featured extremely slow interfaces that were written in plain HTML, with almost every action by the user requiring the server to reload the entire webpage. Buchheit attempted to work around the limitations of HTML by using the highly interactive JavaScript code, an approach that ultimately came to be called AJAX (Asynchronous JavaScript and XML).Как мы дошли до жизни такой, когда AJAX, который был призван решить проблему «extremely slow interfaces» стал работать с такой скоростью, что люди готовы от него отказться и вернуться к «plain HTML» версии, которая, после всех рерганизаций, работает реально быстрее, чем этот новейший «дезигн»?
И вот сегодня имеем ситуацию, когда загрузка простого HTML весом до нескольких десятков килобайт — моментальна засчёт быстрого доступа в интернет и очень быстрого парсинга и рендеринга. Тем временем как в «полновесной версии», очевидно, куча функций сбора каких-то аналитик, визуальных эффектов, и ещё я не знаю даже чего, почему оно так лагать может. Хотя у меня, ещё раз повторю, почти не лагает (немного есть, но я думаю, это из-за обилия иконок, которые повешены на JS события наведения мыши, и всяких там градиентов).
Я бы сказал, что это проблема не софтверных компаний, а вообще любых. Нужно по-быстрому делать то что приносит деньги, иначе денег не хватит и компания закроется. Багфиксы и мелкие улучшения отнимают бесконечное количество времени при этом редко когда улучшают финансовые показатели.
А что тут удивляться, в уставе любой компании написано, что целью является извлечение прибыли. Но тут некоторым может показаться, что для компании хорошо долгосрочное планирование и прибыль. Для компании то да, но для конкретных людей инвесторов и руководителей, более интересно по-быстрому срубить бабла, и пофиг что далее будет с компанией.
может показаться, что для компании хорошо долгосрочное планирование и прибыль
Долгосрочное планирование продукта и так уже вещь достаточно призрачная, а с течением времени вообще исчезнет как класс. Допустим, с тем же джимейлом, сегодня электронная почта нужна и востребована, а завтра она может отмереть за один год, как только будет придумано что-то более удобное. Как отмерли классические мессенджеры с приходом вацапа.
Как говорится, лучше умирать на кредитной яхте, чем с миллиардами в банке. Если проект так и так умрёт в обозримом будущем — технический долг по нему не просто неизбежен, а даже приветствуется.
Для иностранных коллег — вполне стандартом являются скайп, дискорд, слак, фб, почта. Причём обычно скайп+что-то ещё из списка выше, обычно 2 позиции.
Вообще это не только проблема больших компаний вроде Google, но и проблема любой софтверной компании. Исправление багов — деньги не приносит, поэтому на это забивают так как нужна сиюминутная отдача, а не перспективы стабильности продукта.
Только такие ассоциации возникают когда смотришь на некоторые продукты крупных компаний.
И еще немой вопрос: «ну как же так». Вроде у них лучшие разработчики, практически не ограниченные ресурсы… как можно так пролюбить все полимеры, чтобы на входе было оно.
Разработчики там лучшие в том смысле, что они очень хорошо умеют решать олимпиадные задачки, разворачивать списки, балансировать деревья на доске и т.п.
А разработчик Qualcomm сортировал массив, чтобы найти минимум.
На первом отлично прошёл секции Java и Android(казалось бы что ещё надо на мобильного разработчика), но не очень алгоритмы дались. Не взяли.
Ко второму подготовился значительно лучше по алгоритмам. Но не прошёл даже скайп собеседование потому что не смог точно назвать «фичи» Андроид 7.0.
Фейспалм.
Возможно, проходя в какой-нибудь их браузер джуном и можно было бы, но это просто не интересно. Да и, говорят, Яндекс уже не торт.
Просто я не понимаю. Вы уже заглянули в голову интервьювера и поняли, с какой целью он спрашивает этот вопрос? Может тогда лучше сразу сказать «так, товарищь интервьювер, ваши вопросы фигня, вот вам список нормальных вопросов, заверенный мной. И не пробуйте увиливать, все страницы прошнурованы, а сзади скреплены печатью с моей подписью. Я их проверял, вот это — правильные вопросы».
Смешно же.
Проблем с ответом на вопрос нет. Есть проблемы с желанием отвечать на глупые вопросы.
Не отвечайте. Просто мое мнение, что подобные вопросы не коррелируют с итоговой удовлетворенностью от работы. Так что ССБЗ, все, что можно сказать.
С тем же успехом можно отказывать всем интервьюверам по четвергам. Ну, потому что почему бы и нет?
Проблем с ответом на вопрос нет. Есть проблемы с желанием отвечать на глупые вопросы.
Вам не нравится, если вы не можете точно знать, что задумал другой человек? Но это обычно дефолтное положение дел…
Нет уж, на вопросы на которые я хотел ответить — я ответил в резюме. А теперь потрудитесь задать мне свои вопросы. А я посмотрю стоит ли нам продолжать собеседование.
В резюме нет ответов на вопросы, там жизнеописание в целом. По крайней мере я не видел ни одного резюме, оформленного в виде FAQ «Что такое ООП, чем отличается абстрактный класс от интерфейса, за что отвечает I в SOLID, ...»
Вас смешно? Ну смейтесь, а я пока пойду к адекватному работодателю. Удачи вам со следующим кандадатом.
Подобный вопрос не говорит ничего о работодателе.
— P.S. на хабре есть нормальный режим комментирования, если вы не можете отказать себе в желании отвечать с помощью скобочек, не потрудитесь включить markdown-режим, пожалейте читателей.
Мое мнение, очевидно отличается от вашего.
Да пожалуйста. Это же ваш выбор
Мне ненравится строить догадки по поводу того, что задумал мой потенциальный работодатель. В личную жизнь не лезу, но в рабочих вопросах предпочитаю взаимную открытость.
Но вы же не спрашиваете, что должен показать вопрос? Просто додумываете за собеседника и обижаетесь (оскорбляетесь?).
Там ответы на вопросы: чем я занимался, в каких проектах участвовал и какие компетенции имею.
Этим компетенциям нужно на слово поверить? А то тут уже были рассказы, как сениор C# разработчики не знают, для чего virtual используется.
Говорит, что техническое собеседование проводит человек, которому абсолютно безразличен конкретный кандидат, который формально относится к своей работе и задает стереотипные вопросы, не имеющие отношения к предмету собеседования.
Или возможно говорит о том, описании вакансии не соответствует тому, чем реально придется заниматься («Вы знаете, мы не используем стандартные библиотеки. Точнее вообще не используем библиотеки, поэтому функции сортировки пишутся в каждом проекте с нуля.»). В таком случае, дальнейшее собеседование не имеет смысла.
Ну например ожидаемой реакцией может быть то, что на собеседующего посмотрят, как на идиота. Или что ему начнут на пальцах объяснять, почему это плохая идея. И еще 100500 реакций, которые собеседующий хотел бы получить таким вопросом.
Собеседование — этоне игра в одни ворота. Работодатель оценивает потенциального сотрудника, сотрудник — потенциального работодателя. Задавать вопросы, не имеющие прямого отношения к планируемым трудовым отношения — моветон.
Не в одни вопрота. Вопрос в том, насколько этот вопрос характеризует работодателя как «дурака».
По-моему опыту 99% работодателей спрашивают про SOLID и физзбазз, вне зависимости от того, насколько они реально плохие или хорошие (как выясняется впоследствии).
чтобы на входе было оно.
«Но-но! Не на входе, а на выходе!» (а)
Hover actions: Disable hover actions
Однажды в Google я получил негативный performance review. Я решил, что лучшим способом потратить мое время будет произвести рефакторинг кода, который мне достался, чтобы довести степень его покрытия тестами с 0% до 80%, попутно исправив немало багов. В итоге я получил на performance review дерьмовый отзыв, а автор оригинального говнокода — повышение.
Возьмем, к примеру, мессенджер Allo. На его разработку ушло два года, после чего компания решила приостановить разработку и заморозить проект.
Два разных отзыва, но как много в них смысла! На кой черт руководству платить и поощрять за покрытие тестов если проект потенциально может не взлететь? Разработчики забыли что они решают реальные бизнес задачи которые приносят потенциально деньги, а не играю в "забавное программирования с интересными сугубо инженерными задачами и созданием сверхидеального кода"?
Еще и жалуются что их неправильно оценили, что руководство не осознало какую же черт возьми важную вещь разработчик делает, о которой как я понял его никто не просил (Потому что если бы просили он мог сказать на своем ревью что просто выполнял задачу сверху)
Если речь идет о продуктах как gmail (крупные, если есть много пользователей) я в принципе соглашусь. Но потратить x2 времени на разработку какого-то Allo явно затея глупая. А я так понимаю в гугле достаточно много мелких "стартапов" внутри — и живут они по правилам стартапов
Но потратить x2 времени на разработку какого-то Allo явно затея глупая.Потратить x1 времени на разработку Allo, когда у тебя уже есть Hangouts, который нужно только отрефакторить, чтобы он не глючил — затея также дурацкая.
Но за написание тестов в Hagouts или Allo — не повышают, а за Allo — повышают.
То есть у нас есть не два вида деятельности, но три:
1. Писать бессмысленные сервисы типа Allo.
2. Писать тесты для бессмысленных сервисов типа Allo.
3. Рефакторить существующий и работающий Hangouts.
При этом существующие критерии приводят к тому, что делается бессмысленная деятельность первого рода, а если их изменить как предлагается — будет делаться бессмысленная деятельность второго рода (ибо приятнее же писать тесты к новому коду, чем копаться в легаси).
Как добиться того, чтобы поощрялось то, что действительно нужно компании и людям — не знает никто.
Сырой продукт массово может быть принят только если есть большой вау-эффект.
dumistoklus не факт, срок жизни ограничен, к вершине пришёл уже в возрасте и осталось не много, пока делают конечный продукт можешь уже и не уметь радоваться получаемому, потому сбагрить сейчас, получить бонусы и тратить. Взять хоть миф о надёжных немецких автомобилях — сдались (если вообще были, а не просто очень простые и делали потолще, не экономя) и уже многие годы делают как получится. Не чтобы покупали новые (эту глупость любят повторять, но покупать такое же вместо развалившегося сами не готовы), а просто из экономии, времени в том числе.
Вроде, сделав качественно на века сманишь к себе клиентов конкурентов, но затраты (и цены, как следствие) распугивают сильнее. Да и не факт что сильно лучше — собираются-то из комплектующих, производители которых могут иметь другую философию.
миф о надёжных немецких автомобилях — сдались
Может потому, что их теперь производят в Мексике и России?
Потребитель неспособен оценить износойтойкость вещи. Есть специальные лаборатории, журналы и прочее — но когда владельцы автомобилей стали покупать их для того, чтобы «просто ездить» смысл «вкладываться в качество» отпал. Стало выгодно вкладываться только и исключительно в то, что можно увидеть прямо в автосалоне… ну на тест-драве — максимум.
А для чего еще их можно покупать?Вопрос не «для чего», а «как». В 50е-60е-70е даже в США (а уж в остальных странах и подавно) для того, чтобы купить автомобиль нужно было этого хотеть. Очень хотеть. Собирать деньги годами, выписывать и читать (облизываясь) журнал «За Рулём» — вот это вот всё.
Сейчас так покупают разве что квартиру и, возможно, какие-нибудь очень серъёзные вещи (скажем «зеркалки» — и то не всегда). А раньше… так покупали многое — в том числе автомобили.
4 лет назад года назад я выкинул все «энергосберегающие» лампы и заменил их на светодиодные, снизив потребление электричества на освещение в 2 раза
Имхо напрасно)
Во-первых, светодиодные лампы могут едва заметно мерцать (глаз этого может не видеть, а мозг воспринимает). Во-вторых, их белый свет, как по мне, чуть менее приятный, чем у качественных линейных люминесцентных ламп на 4000K Polylux/Lumilux классов. Хотя жёлтые есть довольно приятные даже в недорогом сегменте (а в дорогом — и белые сносные, взять хоть новые вагоны в метро).
Брал светодиоды на 3700К
Не, чуть белее ламп накаливания — это 3000K (жёлтый с лёгким уходом в белый). 3500 — уже чисто белый, но сильно теплее нейтрального. Или некорректная маркировка у вас была, или вы просто путаете что-то)
А где вы вообще такие светодиоды нашли, не подскажете? Я в бытовых магазинах хозтоваров вижу только 4000, 4200 или 4500, причём 4200 и 4500 выглядят ещё холоднее, чем люминесцентные «энергосберегающие» лампочки с патроном — а у меня претензии даже к ним, единственные модели, которые понравились — «Cameleon» на 4200K и «Эра» на 4000K (сейчас почти не найти их уже). Последняя из этих двух — вообще прекрасна. Идеальный нейтральный белый с чуть тёплым оттенком.
Для лампы Thomson TL-60W Classic производитель заявляет мощность 6 W, световой поток 560 Lm, цветовую температуру 3000К (на упаковке ошибочно указана цветовая температура 2700K).
Так что ошибся, я имел ввиду 2700, которые на самом деле 3000 :)
Люминисцентные лампы гарантированно мерцают с частотой вашей сети.
Ну глупости-то не надо писать. Частота работы ЭПРА — порядка 40 kHz, при этом эти «мерцания» практически незаметны для глаза благодаря инертности люминофора. То же самое касается мониторов — мониторы с подсветкой на лампах всегда гарантированно проходят «карандашный» тест (даже в том случае, когда яркость подсветки регулируется с помощью ШИМ модуляции, а не более хитрыми способами) и с меньшей вероятностью вызывают проблемы со зрением.
Вам не повезло со вкусом. Сочувствую.
Почему вы считаете, что не повезло именно мне, а не вам? :)
Люминисцентные лампы гарантированно мерцают с частотой вашей сети.
даже старые с «дросселем» с вдвое большей
Не знаю, одного ли меня гугл стал откровенно раздражать. Android чуть ли не последний из продуктов Google, развитие которого вызывает оптимистичный настрой.
Во-первых, неужели только меня просто невероятно раздражает капча там, где она казалось бы не нужна и не работает "галочкой" — в поиске гугла, при переходе по ссылкам и самое главное — в проектах других компаний, на странице авторизации( за что, атлас...). Мне казалось, что в "галке" все плюсы этой капчи.
Не разглядеть букву — мелочь, по сравнению с ягодичным пожаром от посыла "вы не знаете как выглядят автобусы". Я ЗНАЮ, ТАМ НЕ БЫЛО АВТОБУСОВ11 НЕ БЫЛО!1! АФЫВА
Комментаторы верно подметили, google плюет на Material, плюет на неимоверное требование к современным web-приложениям, передать насколько раздражает использовать GMail в браузере при работе с несколькими аккаунтами просто невозможно. За такой UX в средние века сожгли бы на костре.
Хром на мобильном фактически возрадил индустрию "пишем CSS хаки для одного браузера", которая казалось бы умерла (о да, vh и fixed работающие по их собственным правилам).
Один за другим перешел на нативный поиск, отказался от хрома и даже начал использовать DuckDuckGO каждый раз, когда всплывает проклятая капча. Казалось бы миллиарды денег, а дизайнеров видимо наняли из sight-инвалидов.
неужели только меня просто невероятно раздражает капча там, где она казалось бы не нужна и не работает "галочкой" — в поиске гугла, при переходе по ссылкам и самое главное — в проектах других компаний, на странице авторизации( за что, атлас...). Мне казалось, что в "галке" все плюсы этой капчи.
Хмм, кажется только у вас в поиске гугла есть капча — а почему гугл должен отвечать за сторонние компании вообще не ясно
Что самое смешное, что сервис антикапчи берет всего лишь $2 за 1000 разгаданных капч.
Впору написать аддон для браузера, чтобы подцепить этот сервис для разгадывания капч, закинуть туда эти 2 бакса и больше не мучаться с поиском этих сраных светофоров.
Вы представляете, насколько для компании интернет подорожает, если каждому выдать по IP? :)Понятия не имею. Но если речь идёт про IPv6 — думаю ненамного. Их выделяют блоками по 18446744073709551616 штук обычно. Столько устройств у вас нет и, думаю, никогда не будет.
А насчет количества в выдаваемой подсети — там не так и много выходит, если делать по рекомендации что v6 делается на базе мака устройства. Не 255 конечно но сильно меньше чем указано выше.
uMatrix, uBlock Origin — и гугл не получает свои куки, что хорошо в плане защиты от слежки, но приводит к частому показу капчи.
Но тоже с каптчей тоже довольно часто сталкиваюсь. Правда разгадывать ее обычно не заставляет, >90% случаев ее неожиданного появления (чаще всего в поиске или гугл-переводчике) хватает просто поставить галочку «я не робот».
Если начинают абузить сильнее, то капча становится очень медленной (подгрузка новых картинок выполняется не менее 6 секунд), и нужно разгадывать минимум 3 экрана (обычно 4, иногда 5). Как правило, к моменту, когда вы завершите капчу, на сайте за это время успевает истечь время сессии для неё, и вам нужно заново пытаться ее пройти, быстрее, чтобы уложиться в отведенное время.
Самое страшное что не нашел никаких кнопок фидбека.
Ситуация: у друга не работал скайп, предложил дискорд запустить. Запускаю, он меня не логинит почему-то. Ну ок, логинюсь. И теперь пошла дискотека: сначала надо было отметить все автобусы. Потом все зебры. Потом светофоры. Потом мотоциклы. Потом снова автобусы. Потом снова переходы. Потратил я на это минут 5 точно, если не 10. И что в итоге я получил? ДА ТЫ ЧЕТ ПОДОЗРИТЕЛЬНО ВЫГЛЯДИШЬ, НЕ ПУЩУ ТЕБЯ.
Обратите внимание на красную «Please try again» внизу
Если я раньше с подозрением относился к этому электроновскому поделию, то теперь вообще за версту обходить буду. Нельзя пользоваться таким продуктами, нельзя давать положительную обратную связь.
От провайдера зависит. У всех пользователей оптики от Киевстара, с капчей просто катастрофа.
Чем чаще вызывается эта капча, тем медленнее она начинает работать. Когда задержка между появлениями картинок превышает 6 сек, капчу вообще становится ввести невозможно, т.к. сессия устаревает раньше, чем успеешь ответить.
У меня например очень часто: автомобили, дорожные знаки и витрины, изредка что-нибудь другое.
А вот «зебр» (или вообще какой-либо дорожной разметки) или светофоров вообще ни разу не припомню.
Пользуюсь Nokia 6.1 на Android One, недавно пришел апдейт на Pie. В Pie опять переделали экранные кнопки (только привык к сплитскрину жестом по кнопке переключения приложений), поломали меню Bluetooth в панели уведомлений (теперь отключать наушники нужно через 3 перехода по меню), так ещё и в дефолтном лончере добавили уродливую неотключаемую строку поиска внизу (!) экрана.
В Reddit уже разразились гневными тредами.
Скажем, если эта информация нужна 10% абонентам, а остальным 90% она не мешала, то теперь у 10% возникло неудобство на ровном месте.
У меня, к примеру, ФИО не прокручиваются и название организации звонящего не выводится, хотя эти данные в справочнике есть, и площадь под это тоже есть, но производитель посчитал что Алексей Алексеевич и так понятно кто такой, хотя у всех фамилии разные.
Кстати, у меня идея для нового востребованного мобильного приложения. Ставим приложение всем сотрудникам компании и заливаем туда логотип компании, а заодно цифровую версию визитки (для каждого сотрудника свою). Управление визитками через корпоративный главный аккаунт, который один на всю фирму.
Далее при встрече с коллегой из другой компании на выставке, в командировке или где-то ещё, а также с клиентами, сотрудник нажимает кнопку в приложении, подносит свой телефон к телефону второго человека, и его визитка передаётся по NFC.
Но для этого надо ещё приём фотографий по NFC реализовать вида «это фотка для нового контакта, имя, фамилия контакта, имя компании и его номер приложены рядом», причём из коробки во всех мобильных ОС. Раньше такое было в обычных сотовых телефонах, но там скорее всего у каждого вендора был свой протокол обмена.
P.S. Для более старых телефонов, где нет NFC (или просто для телефонов недорогого сегмента, где его почти всегда нет), хорошо бы реализовать передачу через Bluetooth как альтернативный вариант. Bluetooth правда почти у всех выключен ради экономии энергии, но и NFC обычно тоже, так что без разницы.
Что Вы имеете в виду, говоря про три подхода?
Попасть в меню синезуба, вафли и любого другого требуемого меню, чья иконка есть у Вас в шторке уведомлений, можно долгим тапом.
Но вообще, новое ведро с пирогом, конечно быстрое и плавное, но какое-то бедное на Фиат.
Перешёл на него с miui, и пока не могу привыкнуть к отсутствию многих удобных фич и жестов.
Надеюсь допилят.
Подозреваю он о том, как отключить одно устройство, не отключая блюпуп полностью. У меня кстати с недавних пор это вообще не работает на Android One. Точнее выключить-то можно, но оно само включится, когда получит запрос, поэтому за магнитолу в машине у нас с женой война :)
У меня получается один жест (свайп шторки) + долгий тап по иконке и я уже в меню, здесь можно выбирать устройство и отключать.
Будет ли реконект, не пробовал.
В miui это можно было сделать двумя свайпами (шторка+иконка) и там, прамо в шторке тыркать в нужную сеть вайфай или синезубое стройство. Чертовски удобно.
miui мне нравится всем, кроме того, что нужно постоянно после каждой обновы, рутовать мобилу, выгребать гору говна, править хост, удалять рут и так до следующей большой обновы. И нет нормального 100% переезда с одной мобилы на другую. Я бы сидел и не дёргался на допилят оси, но телефоны порой ломаются, покупаются другие и приходится опять смахивать пыль с бубна и вспоминать заклинания и движения для сокральных танцев. Задолбало.
Никакой дизайн не компенсирует тормознутость. А уж тем более наличие багов.
Ведь сам гугл топил за PageSpeed. Интересно, какой показатель PS на странице gmail?
Шутка про основной продукт Гугла, DNS-сервер 8.8.8.8
Изначально поставил bind9 для локальных доменов .devs (было .dev но он теперь зарезервирован) и сразу настроил forwarders (google DNS, yandexDNS и местные DNS) — и только тогда стало очень заметно что сайты загружаются быстрее намного. иногда вплоть до 2 секунд разница.
На обычных, простых страничках разницы почти нет(скриптом засечь можно, но субъективно разницы не заметно). Но таких в последнее время становится все меньше…
358 запросов и выкачивает 6.3MB
Как-то много для того чтобы просто проверить почту.
А если у меня оптика на 100 Гб/с от телефона отошла?
Вот еще и камент задублировать очень просто, а исправить или удалить в мобильной версии не получилось вообще…
Кажется хабр идёт по этому же пути. В новом мобильном дизайне из полезного добавился рейтинг, а на странице комментариев их количество. Но:
- основная страница загружается медленнее
- после открытия списка заголовков через пару секунд изменяется жирность шрифта заголовков и всё уплывает и меняется время на твой часовой пояс (уж неужели нельзя запомнить его в куку и на сервере отдавать в часовом поясе клиента? )
- всего 4 заголовка стало влезать на экран, против 8 раньше
- количество заголовков на странице стало больше (и страница длиннее см. предыдущий пункт), а кнопок вперёд/назад наверху так и не появилось, ну хотя бы со второй страницы, а то после выходных нередко приходиться углубляться урывками в 4+ страницы
- названий хабов не появилось, а то заголовок не всегда отражает суть
- на странице с каментами тоже все печально, сначала грузиться страница, потом отдельными запросом сами комментарии, субъективно дольше стало раза в полтора-два
Справедливости ради надо заметить что комментарии стало удобнее читать, и хоть и пользуюсь в основном в режиме чтения, но функционалу вроде добавилось для пишущих
О, очень знакомая ситуация. На прошлой работе было такое — отрефакторил говнокод, пополнил то, что они называли документацией, привёл её в удобный вид, покрыл код тестами. А потом мне заявили, что то, чем я занимаюсь на бизнес никак не влияет, дескать я протираю штаны в офисе, ну и "попросили" меня уйти
Тесты и рефакторинги, это 100% необходимая вещь, если речь идет о продукте а не одноразовом коде.
Вышеописанное вами справедливо только в том случае, если тесты не поддерживаются в актуальном состоянии, что я считаю неправильным — тесты пишутся не для красивой цифры в 100% Code coverage, а для того, чтоб проверить, что весь код и продукт в целом отвечают ТЗ. К тому же, написание тестов было прямой задачей от лидера команды разработки, так что моё удивление такому решению было возведено в квадрат.
написание тестов было прямой задачей от лидера команды разработки
Тогда странно. А тимлид то как вашу работу оценил?
Он был не согласен с решением руководства, но ничего сделать не смог по этому поводу
Можно всё сравнивать и замерять… Быть довольным, или возмущаться… Но технологии не могут оставаться без развития, или они будут вынуждены "загнуться". А, как мы знаем, свято место пусто не бывает, на их место придут 'другие'.
Ладно, почему выпускают, но почему говнокодят-то — как это вяжется с жутким отбором при приеме на работу?
Действительно. Всегда, когда читал о приёме на работу в Google, создавалось впечатление, что сам лично туда никогда бы не попал, потому что нужны неимоверные знания и навыки на уровне того, чтоб на калькуляторе суметь написать программу запуска и посадки "Апполона" на Луну, а когда пользуюсь их приложениями, всё чаще посещает мысль, что неплохо было бы, чтоб они были с открытым кодом, чтоб была возможность исправить этот неработающий как надо кусок гуано
Дизайн мне не зашел. а постоянные лаги безумно бесять.
А вообще, после exchange во все вебпочте мне чего-то нехватает.
О, это вы наверное не пользовались их альтернативным клиентом для почты — "Inbox". Вот оно точно работает вкривь и вкось, что веб-версия, что на Android. Отвратительное, тяжёлое, медленное, с кучей свистелок и перделок, которые в принципе не облегчают работу с почтой.
Однажды в Google я получил негативный performance review. Я решил, что лучшим способом потратить мое время будет произвести рефакторинг кода, который мне достался, чтобы довести степень его покрытия тестами с 0% до 80%, попутно исправив немало багов. В итоге я получил на performance review дерьмовый отзыв, а автор оригинального говнокода — повышение.
Вот она реальная квалификация сортирователей списков и любителей дурацких задачек. В больших продуктах степень покрытия тестами зачастую бывает 0%. По опыту знакомых в больших компаниях ситуация аналогичная.
В больших продуктах степень покрытия тестами зачастую бывает 0%. По опыту знакомых в больших компаниях ситуация аналогичная.
Это ни о чем не говорит, есть много причин, по которым код покрывать не требуется. Например — там мало логики, вы этот код скоро выкинете, не ожидается каких-либо рефакторингов без изменения спецификации и т.д…
При этом сама кодовая база за счет тестов растет — то есть работа получается не просто бесполезной, а вредной.
Это ни о чем не говорит, есть много причин, по которым код покрывать не требуется.
В больших проектах? Серьезно? Какие могут быть причины, кроме низкой квалификации разрабов?
Например — там мало логики, вы этот код скоро выкинете,
Это явно не про большие проекты.
не ожидается каких-либо рефакторингов без изменения спецификации и т.д
Даже если возьмем идеальный случай когда код пишется идеально без ошибок по идеальной спецификации и требования не меняются. Если говорим про долгосрочный проект, то в какой-то момент придется обновить версию языка программирования, фреймворка и все зависимости и даже версию операционной системы. И в этот момент куча всего сломается. И без тестов это просто страшно делать и этот момент будет откладываться до самого последнего момента, пока хотя бы секьюрити патчи выпускаются для фреймворка и ОС. Более того, на практике добавление нового кода зачастую совершенно нетривиальным образом может сломать старый протестированный код.
Какие могут быть причины, кроме низкой квалификации разрабов?
Я выше указал. Низкая квалификация разрабов — это, кстати, как раз причина код покрывать, а не наоборот.
Это явно не про большие проекты.
Как раз именно в больших проектах у вас могут быть огромные куски кода и даже целые подсистемы, которые не содержат какой-то нетривиальной логики. И покрытие 0 в них — вполне себе норма.
Если говорим про долгосрочный проект
Далеко не все проекты являются долгосрочными, и даже из долгосрочных — далеко не все требуют сколько-нибудь значительной поддержки после введения в эксплуатацию.
то в какой-то момент придется обновить версию языка программирования, фреймворка и все зависимости и даже версию операционной системы
Почему придется? Меня никто не заставляет обновлять библиотеки и версию фреймворка. Зачем обновлять фреймворк, если через полгода, например, разработка будет закончена? Тем более если смена версий произошла с серьезными нарушениями обратной совместимости?
Я уже не говорю о том, что для проверки работоспособности проекта и правильного взаимодействиями с внешними библиотеками вам нужно интеграционное (или е2е) тестирование (юнит-тестами такие вещи проверить просто невозможно, т.к. внешний функционал мокается), для которых понятие "покрытия кода" вообще малоосмысленно, в случае е2е кода вообще нет (есть пользовательские сценарии), покрывать нечего.
Более того, на практике добавление нового кода зачастую совершенно нетривиальным образом может сломать старый протестированный код.
Код-то сломать может, а тесты — нет, или у вас какие-то очень странные хрупкие тесты. А если тесты хрупкие — от них вреда больше чем пользы, даже если они на своем месте.
Ну и возвращаясь к исходной статье — если человеку было нечего делать, надо было обратиться к менеджеру и ознакомиться с приоритетными задачами а не отсебятину гнать и потом обижаться, что его говнокод никому не нужен оказался.
Может, это был какой-то внутренний проект, который уже был по факту закончен, обладал полным функционалом, находился в эксплуатации, прекрасно работал и его вообще не предполагалось трогать в ближайшие лет 10?
Если же были какие-то причины именно для этого кода писать тесты — почему они не были сформулированы в претензиях по ревью?
Вроде, никто здесь не говорит о том, что тесты не нужны в принципе. Тесты — это обычный инструмент. Любой инструмент может, в зависимости от ситуации, быть полезен, бесполезен, вреден.
Говорить, что "у вас покрытие 0, значит вы все говно и вообще неквалифицированы", это то же самое что сказать микробиологу: "ты молотком не пользуешься, значит балда", хотя ему в работе-то молоток совсем не нужен, он не плотник.
И в исходной ситуации мы слышали одну сторону — обиженного человека, который написал тестов, и его не оценили, но второй-то стороны нет, а ситуацию, при которой от тестов пользы — чуть менее нуля, представить себе не сложно.
Работал человек, писал, допустим, месяц тесты, которые никому не нужны были в конкретной ситуации — ему и сделали замечание на ревью. Что не так?
Если же они были нужны — он мог опротестовать решение ревьюера, но он этого не сделал. Вывод? Сам понимал, что занимался хренью.
Как бэ там другая история, чловек провел рефакторинг, сделал что-бы все стабильно работало, а его не то что-бы не оценили, а еще и унизили тем, что оценили говнокодера.
Ну так если говнокодер сделал что-то полезное (добавил фичи какие-то и т.п.), и это полезное прекрасно работало, а обиженный отрефакторил и написал тесты для кода, который в ближайшие лет 10 никто трогать не собирался — то все верно. Говнокодеру надо премию, а обиженному — по лбу, разве нет?
По поводу молотка, бред, кто пишет тесты понимает, что гораздо проще 1 раз написать тест на функцию, чем каждый раз проверять её работоспособность
Смотря какая функция, смотря какой тест, смотря какой вообще проект. Все зависит от ситуации.
Так что, нет, 0 покрытие — это не признак отсутствия квалификации. А вот категорические утверждения — как раз признак.
А кто говорит, что прекрасно работало?
А кто говорит, что нет? Почему бы не предположить, что да? Почему мы обязаны предполагать в пользу одной стороны, а не в пользу другой?
А как дальше добавлять что-то полезное, если добавляя фичу ломаются старые?
А добавлять вообще надо? Может, нет? А ломаются? А с чего вы взяли?
Есть огромное количество больших проектов, которые прекрасно живут, фичи добавляются и ничего не ломается, при этом покрытие тестами минимально.
Мы сейчас google обсуждаем, у них не может быть проекта на котором можно забить на тесты
Вы с чего взяли? Во-первых, есть куча внутренних проектов, во-вторых — даже если проектом пользуются миллионы, то вам по факту просто не нужны тесты, если разработка проекта окончена.
А полагаться на ревьювера как на истину это очень странно.
А полагаться на ревьювера как на истину это очень странно.
Точно так же как и полагаться на человека, который не доволен ревью. Я говорю лишь о том, что без уточнения конкретной ситуации вывод делать нельзя. Как ревьювер мог оказаться болваном — так им мог оказаться и сам обиженный.
Если говорим про долгосрочный проект, то в какой-то момент придется обновить версию языка программирования, фреймворка и все зависимости и даже версию операционной системы.
Зачем это может потребоваться? И почему при смене ОС или версии языка старый код должен перестать работать? Обратная совместимость же.
Обратную совместимость стараются поддерживать, но несовместимые изменения тоже вносят. Обычно сначала используют deprecated wаrning, а в следующей версии уже окончательно ломают. Но даже если вы от корки до корки прочитали release notes, это не значит то не столкнетесь с неожиданностями. Например текущий проект я начинал на Django 1.8, и потом были миграции на 1.9, 1.10. 1.11, 2.0, 2.1. и при каждой такой миграции ломалась куча всего. Боюсь представить как бы я это отлаживал без тестов, наверное так бы и остался на 1.8. Попутно обновились все прочие зависимости и уже наступил тот период когда многие проекты прекращают поддержку питона 3.5, и операционную систему пора обновить. А прошло чуть больше двух лет.
В проектах больше чем 5 тыс строк даже изменение второй цифры в версии языка или фреймворка всегда ломает кучу всего… А ведь есть еще десятки зависимостей их тоже нужно обновлять.
Просто у вас фронтендянка. Представьте себе — если речь не о фронтенде, то люди могут годами писать миллионы строк, апдейтить, и у них ничего не ломается. Это и правда удивительно :)
Просто у вас фронтендянка.
Вы что-то перепутали, у меня бакенд.
то люди могут годами писать миллионы строк, апдейтить
Верю.
и у них ничего не ломается.
Не верю.
Не верю.
И что там у вас в шарпе ломалось в последних апдейтах второй цифры, можно узнать?
И что там у вас в шарпе ломалось в последних апдейтах второй цифры, можно узнать?
К C# не имею отношения, вы снова что-то перепутали.
Давайте пройдем на гитхаб и посмотрим как поживают проекты с миллионами строк без тестов. Ссылки в студию.
К C# не имею отношения, вы снова что-то перепутали.
Ну хорошо, давайте джаву возьмем. Как там?
Давайте пройдем на гитхаб
Мы же говорим о больших проектах с длительным циклом поддержки. При чем тут гитхаб? Он сам всего лишь 10 лет назад появился.
Я уж не говорю про то, что гитхаб не представляет из себя в принципе сколько-нибудь релевантной выборки. Во-первых, там очень мало кода, во-вторых — у этого кода вполне определенный уклон.
Год назад слушал подкаст, там гуглы и фейсбуки все еще в то время сидели на 2.7, не факт что сейчас смогли обновиться.
Например — там мало логики, вы этот код скоро выкинете, не ожидается каких-либо рефакторингов без изменения спецификации и т.д…
А зачем в принципе писать такой код, который изначально задумывается как мертворождённый?
При этом сама кодовая база за счет тестов растет <...>
Тесты — это не кодовая база, от слова "вообще". Это автоматизация тех же тестов, что проводятся лапками.
В статье сказано — для повышения. Потом код выкатывается на продакшн, народ плюётся, проект отправляется на кладбище проектов, во всём винят злобный Гугл(/название_другой_компании), а разработчики расходятся кто куда (наиболее хитрые — вверх). Если проект не умер вдруг и какой новый дурак решит делать тесты вместо свистелок, то он просто сократит на себя количество претендентов на повышение. Это всё про продукты не для людей.
А зачем в принципе писать такой код, который изначально задумывается как мертворождённый?
Почему мертворожденный? Он же работает, выполняет свои задачи, значит, не мертворожденный.
Тесты — это не кодовая база, от слова "вообще".
Конечно же, кодовая база. Тесты надо писать, поддерживать, в них бывают баги и т.д…
Тесты ничем в этом плане не отличаются от "просто кода".
Это автоматизация тех же тестов, что проводятся лапками.
Автоматизация тестов, которые проводятся лапками — это e2e.
— Их надо писать — но они дают выигрыш на горизонте.
— Баги в тестах прозрачны, легко ревьювятся и редки
— Поддерживать тесты надо при изменении API в уже написанном коде. В этот момент тесты подсвечивают изменения произошедшие в контрактах. Это то же время, что вы бы провели в дебаге.
Сложный и работающий долгое время проект без изменяй и тестов — обречен на переписывание. В то же время есть вероятность что изменения в него не вносятся именно по этой причине.
— Их надо писать — но они дают выигрыш на горизонте.
Иногда дают, иногда — не дают. Если вы код править не будете, то и тесты на нем ничего вам не дадут.
— Баги в тестах прозрачны, легко ревьювятся и редки
Так же часты, как и в любом другом коде, да и вообще в точности такие же, никакой разницы по сложности обнаружения и отладки. Ну, это точно такой же обычный код, с чего бы вообще там багам отличаться?
— Поддерживать тесты надо при изменении API в уже написанном коде.
Только в том случае, если у вас тесты по черному ящику, что невозможно для юнит-тестов с моками. В случае с белым ящиком — переписываете тесты при любом рефакторинге, который не затрагивает семантику.
Сложный и работающий долгое время проект без изменяй и тестов — обречен на переписывание.
Сложный и работающий проект без изменений и тестов просто тупо работает и все, потому что написан нцать лет назад и чего бы ему не работать?
Вы поймите, что далеко не всем проектам нужен цикл поддержки с постоянным перепиливанием всего, иногда есть достаточно точное ТЗ, которое выполнено — и все, никакого функционала больше не потребуется, менять нечего.
Так же часты, как и в любом другом коде, да и вообще в точности такие же, никакой разницы по сложности обнаружения и отладки. Ну, это точно такой же обычный код, с чего бы вообще там багам отличаться?
Тем, что тесты максимально просты, с низкой цикломатикой и вариативностью, не вложенные, не используют (за исключением) массу новых типов. Не должны работать на граничных значениях элементов и как правило читабельнее кода.
Сложный и работающий проект без изменений и тестов просто тупо работает и все, потому что написан нцать лет назад и чего бы ему не работать?
Откуда у вас такая выборка? Не припомню сложных проектов которые работают и в них не фитуют. Кроме тех которые бояться трогать.
Я понимаю что простым и одноразовым проектам тесты не нужны.
Изменяемым с горизонтами год и более — нужны
Тем, что тесты максимально просты
Часто тесты значительно сложнее тестируемого кода. Ну и больше, конечно. Особенно, когда речь о юнит-тестах.
Откуда у вас такая выборка? Не припомню сложных проектов которые работают и в них не фитуют.
А зачем вам что-то фитовать в работающем проекте? Цель этого какая? Еще раз — бывают задачи которые надо просто решить и все. Если написанный код справляется с решением поставленной задачи в рамках установленных ограничений — зачем в нем что-то менять?
Изменяемым с горизонтами год и более — нужны
Так с этим никто и не спорит. С чего вы взяли, что обсуждаемый проект был именно из этих?
Гугл болен. Он слишком разросся, чтобы оставаться эффективным в чем-либо, кроме увеличения кэша на счете.
Чем меньше его продуктов вы будете использовать, тем лучше для вас: меньше нервяка, меньше утечек персональных данных, меньше стратегического риска для ваших процессов.
"Ваше присутствие не было критически важным". Что-то мне это напоминает… Много лет проработал в связи в аварийных бригадах. В тех, которые срочно чинят когда всё сломалось и все клиенты в бешенстве. Но тоже начальство не особо ценило такие заслуги. Видимо, когда человек работает с неприятными вещами — авариями, багами, это вызывает какие-то неприятные ассоциации. Вот продажник — это ценный кадр, он деньги приносит и всегда заслуживает поощрения.
Но вот отсутствие понимания системного подхода и приводит к тому, что живём от «с этим руководителем повезло, с тем — не повезло».
Вкратце. Факторы, обеспечивающие стабильность и устойчивость системы, нужно так же внимательно анализировать, как и факторы, обеспечивающие её рост. А у нас видят только последние (о, мега-бабло попёрло, сейчас купим жип и яхту!). Если наступил значительный рост (ба..., да мы уже офис в центре имеем в своём здании), то соответствующим образом нужно над стабильностью думать. Вводить нормы и метрики по багам, стабильности в CI, нефункциональным показателям ПО (не выросло ли потребление памяти, не стало ли медленнее). Но это от головы должно идти. В смысле, от владельцев бизнеса. Средний уровень управления пришёл в компанию только для максимизации своей прибыли (и тут нет ничего предосудительного).
Но всё это полная лажа. Если: а) владельцам бизнеса «итак норм», бабло течёт «в достаточной мере», а мнение леммингов — как надоедливый зуд комара (и топ-IT компании могут себе это позволить ещё на десятилетия с такой подушкой безопасности); б) владельцы всё это понимают, но в условиях внешней политической конъюктуры живут днём сегодняшним, потому что «завтра может и не быть», так что «утром деньги, вечером… может и стулья поставлять не придётся».
Но это всё хорошо, а где решение? Давайте напишем в гугель петицию, давайте загрузим какой-нить плагин в браузер, который будет в фоновом режиме перезагружать их чудесный интерфейс раз в минуту, чтоб у них там сервера вспотели, давайте продвинем на том же ютюбе издевательское видео «как хреново написан gmail», где будем обидно высмеивать компанию и разработчиков с выводом «и вот этим клешнегуким вы готовы доверять свои персональные данные и фото?!» Давайте предложим альтернативный клиент для gmail, типа gmails.ru/com, который для гугла будет просто почтовым клиентом, а для пользователя будет рисовать простейший быстрый интерфейс в 2 запроса и без трекеров… Ну что-то реально делать то надо, а не просто поговорили и разошлись.
Может все дело в профориентации. Задача разработчиков выкатывать фичи в прод. Логично, что их перфоманс этим и измеряется. Фиксить баги и доводить код до совершенство дело саппортовых команд. Не знаю как конкретно в Гугл, в больших компаниях обычно так. Возможно недовольным ребятам, ввиду их чисто человеческих качеств, стоило просто перейти в саппорт.
358 запросов и выкачивает 6.3MB
У меня 300 запросов и 33,16 МЬ / 12,29 передано. Полная загрузка за 21 секунду.
Это я не просто зашёл в свой почтовый ящик. В письма не переходил и не отправлял…
С выключенным чатом — 200 запросов, 1.5Мб (!), с включенным — 358, 8.4 Мб.
Я не знаю кто в здравом уме станет его использовать в своем проекте, зная его размер.
По вашей ссылке нажимаете "Select this font", внизу появляется список шрифтов, где вы можете нажать "Customize" и выбрать какие веса и языки включить.
Никаких сторонних сервисов не нужно.
По сути получается google своими же руками создает большие возможности для конкурентов, получить новую аудиторию.
Лично я отказался от chrome потому что дизайн меняется а вот качество работы напрягает, часто вылетает, виснет.
отличная работоспособность Snow Leopard и последовавшей за ней Lionвот не сказал бы…
Snow Leopard медленее Tiger (это еще и потеряв поддержку PowerPC)
а Lion медленнее Mountain Lion
лично наблюдал и на своих маках, и у знакомых
А вот Lion да… было ощущение что после загрузки будет черный экран и надпись «42» с последующим взрывом
и достаточно фичастый (поддержка интела, серверный вариант...).
В леопарде из существенного — Time Machine,
бантики для файндера и прочие меня не впечатлили (дуалбут — бесполезен для меня),
а вот тупки были больше ;)
А еще мне тигр запомнился по видео :)
Я помню ситуацию, когда в одной большой конторе performance-команда, замучившись чинить одни и те же баги в каждом релизе, сделала презентацию для коллег с примерами говнокода и соответствующими примерами «как надо было». В результате — команду разогнали «за пренебрежение к коллегам»
и вызвать «крэш» вкладки с черновикомя думал, это у меня одного такое, до сих пор грешил на разработчиков Хабра
Она лучше знает, чем для тебя является добро. А ты не спорь, иначе станешь нецелевой аудиторией.
P.S. Отказался от нового дизайна гугла вообще. Перешел на lite html-версию. Неудобно стало, зато не тормозит!
Старая версия тоже не то чтобы летала, тот же Яндекс и мейл.ру пошустрее будут. Но новая не стала сильно медленнее старой, если только процентов на 10-15.
Или у меня не 16 гигов оперативки, а 8
Или потому что у меня открытые 200 вкладок в браузере — это нормальное дело? Это не считая еще кучи запущенного софта.
А можно быть просто у гугла говнокод?
А ещё добавили сверху пункт в меню, который очень мешает при сохранении изображений (я люблю это делать контекстным меню, а не с клавиатуры, когда картинка открыта в фулскрине). В итоге нужный пункт стал то ли вторым, то ли третьим, а был самым верхним — это очень сильно замедляет прицеливание и наведение, когда надо мышь после клика ещё вести вниз бог знает сколько и целиться.
Я в итоге с горем пополам перепилил версию 49 на уровне двоичного кода, используя IDA Pro, и выпилил отображение тех двух пунктов в контекстном меню, но стоило это почти недели времени и кучи убитых нервных клеток. Заодно убрал и предупреждения о необходимости обновления (но там-то всё было просто, был готовый рецепт, что именно на что заменить, да и я ещё 1-2 варианта нашёл, как можно это сделать даже чуть изящнее).
Но всё равно мне кажется, что как минимум 47-ая работает медленнее (особенно при сохранении файла на диск в папку с очень большим числом изображений). Есть какой-то такой подвис (при этом жёсткий диск не активен если верить ушам), которого в 45-ой нет. 49-ая, кстати, в этом плане ведёт себя лучше.
Я просто оставлю это здесь для тех, кому лень открывать профайлер..
Открытие страницы:
Открытие письма:
Всё это на моём не самом медленном ноуте, чтобы нарисовать 25 строчек писем в компактном виде, десяток кнопочек, меню на 10 пунктов и 20 контактов. Грамотное использование технологий позволило бы ему открываться и работать на порядок быстрее. Сравните, например, с этим:
я не могу не пользоваться почтой gmail, т.к. она хороша, но пользуюсь я исключительно браузерной версией. мне насадили новейший дизайн вместо нового (много таких случаев), но оставили выбор, которым я и пользуюсь: при такой долгой загрузке и любой скорости интернета можно успеть нажать в правом нижнем углу надпись
Loading standard view | Load basic HTML (for slow connections)
и меня этот вариант устраивает, хоть и вид у него из 2000-х. Боюсь, только, что я уже старпер и мне стыдно признаваться о таких вещах.
То есть теперь нельзя просто так взять удалить письмо и сразу закрыть вкладку. При следующем заходе удалённое письмо опять появится! Теперь нужно удалить, подождать несколько секунд и вот потом уже можно закрыть вкладку… это фэйл.
Так что я с приходом нового дизайна тоже стал пользоваться классическим html вариантом.
Почему новый дизайн Gmail такой медленный?