Причиной холивара часто является недооценка основных качеств процедурного программирования и ООП. Не всякий «код с классами», это обязательно ООП.
Процедурный код хорошо себя проявляет на ранних этапах разработки, т.к. на него удобно ложатся привычные подходы алгоритмического моделирования, и первые видимые результаты появляются очень быстро. Основные проблемы таких программ: низкая абстрактность и сильная связанность (так называемый «спагетти-код»). Это приводит к тому, что ранее написанный код сложно переиспользовать, а эффекты, возникающие при изменении требований и модификации кода, могут непредсказуемо распространяться по всей программе. Поэтому развивать и поддерживать такой код — нервно и дорого.
ООП предполагает построение программы как системы из независимых объектов, взаимодействующих друг с другом. С одной стороны это приводит к тому, что на начальных этапах разработки необходимы заметные вложения в анализ требований и проработку архитектуры. Но далее, разработка независимых частей, а так же их поддержка и развитие обходятся дешевле.
Поскольку время эксплуатации и развития софта обычно в десятки раз превышает время его начальной разработки, то использование ООП, в целом дает ощутимую выгоду. Собственно, за это и не любят «процедурщину» в ООП архитектуре — она несет за собой весь ворох характерных для процедурного подхода проблем, помноженный на архитектурные заморочки (так называемый «равиоли»-код), — что приводит в итоге к сильному росту затрат на поддержку.
Почему-то, ни один из них не отрабатывает ситуацию, когда у окна браузера появляется горизонтальный скролл (на демках хорошо видно несуразность, достаточно сузить окно по горизонтали). Все сильно по-разному, когда динамически меняется ширина контейнера. Ужас с позиционированием на мобильных девайсах.
увы
увидел ссылки фиолетовыми.
Или полноценная реализация полифилла для position: sticky это какой-то прямо вызов — найдется кто смелый? :)
В IE с уязвимостями в последнее время стало хорошо. Их немного больше, чем в других браузерах по причине того, что его разработка ведется гораздо активнее.
Если мерить, по-вашему, — активность разработки количеством багов, — выходит, что раньше они пилили IE круглосуточно. :)
Интересно, как в библиотеках вообще хранятся электронные версии? Ведь электронную версию, в стеллаж не поставить как книжку, а хранить информацию, наверняка, надо так же долго и надежно. Каковы объемы данных, которые должна хранить библиотека? Используются-ли какие-то типовые решения для хранения в плане инфраструктуры, софта или каждая библиотека придумывает что-то свое?
Возможно, смысл не в построении единого видеоряда, как при монтаже, а в возможности взглянуть на происходящее с разных позиций. Возможно, в такой компоновке они смогут представлять видео, снятое разными пользователями на одном мероприятии.
Хотя ansible и fig/docker решают похожие задачи, решают они их принципиально по-разному.
Ansible это универсальная штука, чтобы приводить состояние машинок в требуемое, для вашего приложения, путем дергания их внутренностей с помощью абстрактных правил по ssh. Docker собирает контейнеры «с нуля», упаковывая операционку вместе с приложением. Поэтому степень контроля тут в разы выше и есть возможности для различных оптимизаций. В целом, деплой через ansible занимает минуты, в то время как docker все делает за секунды.
Автор сильно переусердствовал с модульностью, в приложении практически нечего нет, а файлов и модулей уже...
Кстати, на ангуляре часто так и пишут: один файл — одна сущность. Это снимает часть вопросов, связанных с поддержкой кода, его тестируемостью и повторным использованием. Например, недавно была статья habrahabr.ru/post/243565/. У автора тоже что-то подобное, только все вручную. Все-таки JS менее выразительный язык, чем питон, потому код имеет тенденцию скатываться в состояние неподдерживаемого «говнокода» быстрее. Отсюда, приходится строже относится к таким вещам, как модульность.
Так же считаю излишним выносить js в отдельный шаблон и потом его подключать. В оригинале автор использует для этого templates/javascripts.html.
Мы в коммерческой разработке используем не только bower, но и много — gulp для «компиляции» статики, пост-процесснига django-шаблонов, и т.п… С одной стороны, тащить в проект уровня «hello world!» инфраструктуру кажется перебором, но с другой — к хорошему быстро привыкаешь, так что потом сложно отказываться. :) Могу предположить, что в реальных проектах у них больше одного django-шаблона, куда подключается один и тот же набор скриптов. Отсюда такое решение.
По части сети проблем нет. Все-таки по сети передаются байты, а не строки. Строки получаются лишь после интерпретации этих данных программой. Они лишь частный случай. С тем же успехом может прилететь половина байтового представления Int. Порядок интерпретации всегда на совести программы.
Новые фичи появляются во всех браузерах, и почему-то лишь в MS додумались решать вопросы интерабельности, выпиливанием из UA опознавательных знаков своего браузера. Так, что это ломает поведение существующих сайтов, искусственно создавая проблемы там, где их быть не должно. Ведь ни кто из разработчиков браузеров больше так не делает. Если бы этот метод помог решить хоть какую-то техническую задачу, давно бы уже у всех браузеров был один UA.
Единственное, что реально на данный момент сделала MS своим трюком — вновь поломала обратную совместимость с предыдущими версиями своего браузера.
В том то и дело, что IE теперь снова другой, и не старый, и не Chrome, и не Safari, и не FF (и в чем там еще обычно тестируют). Поэтому нынешний подход MS к продвижению браузера, которой вводит в заблуждение не только пользователей, но теперь и уже некогда оттестированный код, вызывает раздражение.
Вы предлагаете отменить функциональное тестирование сайта, заменив некой вероятностной оценкой, которую делают разработчики браузера, приняв на веру их «будет работать с большей вероятностью»? А может не разработчики, а отдел маркетинга? Тут выше уже писали, что браузер поддерживает не все возможности своих коллег по «интероперабельности». Любому разработчику понятно, что изменение UA приведет к тому, что логика адаптации начнет работать не правильно и неподдерживаемое обязательно отвалится, прямо на глазах у пользователя. Логично?
Наш отдел тестирования регулярно сталкивается с аномалиями на WinPhone, которых нет в других браузерах. В принципе это нормально — новый браузер, новые особенности. Так всегда бывает, нет ни какого чуда. Эти ребята за всю историю не смогли нормально обеспечить совместимость между версиями в рамках собственной же линейки — что ни релиз, то новый «правильный» подход. Теперь вот опять придумали фичу. О какой интероперабольнсти в таком случае может идти речь?
Тег на вашей графике вообще говоря не является валидным — он не содержит имени, не парсится. Вызывает склоки, Тянет гнев за нарушение W3C стандартов на себя. В результате верстка на следующем экране разъехалась
По ссылке на «стратегию интероперабельности» пишут интересные вещи. Дескать, выпиливание из User-Agent мобильного браузера упоминания про IE, привело к тому, что сайты в мобильном IE волшебным образом стали выглядеть так же модно и молодежно, как выглядят в Chrome и Safari — вместо обычной десктопной отрисовалась «симпотишная» мобильная версия. Т.е. браузер уже хороший, но имя у него плохое. Ну и они решили этот метод развивать дальше, решив лишить свой браузер любых опознавательных знаков.
Этот фокус по вытаскиванию «недокументированных» возможностей, напоминает манипуляции из ряда тех, что делают находчивые ребята, занимающиеся разлочкой в электронике. С той лишь разницей, что первые осознают, что делают все на свой страх и риск, и после таких манипуляций производитель резонно откажется от своих гарантийных обязательств.
Microsoft, продвигая такие «новшества», оказывает пользователям своих браузеров медвежью услугу. Ведь очевидно, что код на сайтах сам по себе не появляется. Если на сайте присутствует код, определяющий IE, значит для этого есть какой-то резонный смысл — либо мобильная версия не тестировалась в такой связке, либо, что еще вероятнее, имеет под IE какие-то аномалии.
Promise.all() не имеет отношения к параллелизму. Тут речь лишь о том, что порядок вычисления не важен (асинхронности в смысле). С параллелизмом в js вообще все сложно.
В jQuery реализация promise A (без плюса), от чего на практике одни минусы. Сталкивался с тем, что объекту Deferred можно сделать reject(), после чего resolve() и обещание внезапно становится выполненным.
если каждую точку в основании треугольника соединить с его вершиной, тогда в вершине треугольника будет столько же точек с сколько в его основании. т.е. количество точек в точке такое же как в отрезке. в чем подвох? %)
по идее, если по тому же принципу использовать не только суставы, но и промежутки между ними (фаланги), то на одном пальце можно считать до десяти. придется точнее целится, но в эпоху тачскринов это уже не кажется проблемой.
а кстати интересно. можете посчитать аналогичную статистику по количеству issues, комментов и участников обсуждений?
мне кажется, вывод в статье формально правильный — выкладывать проекты с мыслью, что щаз набегут разработчики и начнут делать за тебя свою работу, — наивно. но ведь гитхаб это еще и соц.сеть. код сам по себе ни что, обратная связь — бесценна. :)
Процедурный код хорошо себя проявляет на ранних этапах разработки, т.к. на него удобно ложатся привычные подходы алгоритмического моделирования, и первые видимые результаты появляются очень быстро. Основные проблемы таких программ: низкая абстрактность и сильная связанность (так называемый «спагетти-код»). Это приводит к тому, что ранее написанный код сложно переиспользовать, а эффекты, возникающие при изменении требований и модификации кода, могут непредсказуемо распространяться по всей программе. Поэтому развивать и поддерживать такой код — нервно и дорого.
ООП предполагает построение программы как системы из независимых объектов, взаимодействующих друг с другом. С одной стороны это приводит к тому, что на начальных этапах разработки необходимы заметные вложения в анализ требований и проработку архитектуры. Но далее, разработка независимых частей, а так же их поддержка и развитие обходятся дешевле.
Поскольку время эксплуатации и развития софта обычно в десятки раз превышает время его начальной разработки, то использование ООП, в целом дает ощутимую выгоду. Собственно, за это и не любят «процедурщину» в ООП архитектуре — она несет за собой весь ворох характерных для процедурного подхода проблем, помноженный на архитектурные заморочки (так называемый «равиоли»-код), — что приводит в итоге к сильному росту затрат на поддержку.
Если мерить, по-вашему, — активность разработки количеством багов, — выходит, что раньше они пилили IE круглосуточно. :)
Ansible это универсальная штука, чтобы приводить состояние машинок в требуемое, для вашего приложения, путем дергания их внутренностей с помощью абстрактных правил по ssh. Docker собирает контейнеры «с нуля», упаковывая операционку вместе с приложением. Поэтому степень контроля тут в разы выше и есть возможности для различных оптимизаций. В целом, деплой через ansible занимает минуты, в то время как docker все делает за секунды.
Кстати, на ангуляре часто так и пишут: один файл — одна сущность. Это снимает часть вопросов, связанных с поддержкой кода, его тестируемостью и повторным использованием. Например, недавно была статья habrahabr.ru/post/243565/. У автора тоже что-то подобное, только все вручную. Все-таки JS менее выразительный язык, чем питон, потому код имеет тенденцию скатываться в состояние неподдерживаемого «говнокода» быстрее. Отсюда, приходится строже относится к таким вещам, как модульность.
Мы в коммерческой разработке используем не только bower, но и много — gulp для «компиляции» статики, пост-процесснига django-шаблонов, и т.п… С одной стороны, тащить в проект уровня «hello world!» инфраструктуру кажется перебором, но с другой — к хорошему быстро привыкаешь, так что потом сложно отказываться. :) Могу предположить, что в реальных проектах у них больше одного django-шаблона, куда подключается один и тот же набор скриптов. Отсюда такое решение.
Единственное, что реально на данный момент сделала MS своим трюком — вновь поломала обратную совместимость с предыдущими версиями своего браузера.
Вы предлагаете отменить функциональное тестирование сайта, заменив некой вероятностной оценкой, которую делают разработчики браузера, приняв на веру их «будет работать с большей вероятностью»? А может не разработчики, а отдел маркетинга? Тут выше уже писали, что браузер поддерживает не все возможности своих коллег по «интероперабельности». Любому разработчику понятно, что изменение UA приведет к тому, что логика адаптации начнет работать не правильно и неподдерживаемое обязательно отвалится, прямо на глазах у пользователя. Логично?
Наш отдел тестирования регулярно сталкивается с аномалиями на WinPhone, которых нет в других браузерах. В принципе это нормально — новый браузер, новые особенности. Так всегда бывает, нет ни какого чуда. Эти ребята за всю историю не смогли нормально обеспечить совместимость между версиями в рамках собственной же линейки — что ни релиз, то новый «правильный» подход. Теперь вот опять придумали фичу. О какой интероперабольнсти в таком случае может идти речь?
Этот фокус по вытаскиванию «недокументированных» возможностей, напоминает манипуляции из ряда тех, что делают находчивые ребята, занимающиеся разлочкой в электронике. С той лишь разницей, что первые осознают, что делают все на свой страх и риск, и после таких манипуляций производитель резонно откажется от своих гарантийных обязательств.
Microsoft, продвигая такие «новшества», оказывает пользователям своих браузеров медвежью услугу. Ведь очевидно, что код на сайтах сам по себе не появляется. Если на сайте присутствует код, определяющий IE, значит для этого есть какой-то резонный смысл — либо мобильная версия не тестировалась в такой связке, либо, что еще вероятнее, имеет под IE какие-то аномалии.
В jQuery реализация promise A (без плюса), от чего на практике одни минусы. Сталкивался с тем, что объекту Deferred можно сделать reject(), после чего resolve() и обещание внезапно становится выполненным.
в pep-3107 речь идет только о синтаксисе. к статической типизации эти аннотации не имеют ни какого отношения.
на практике статический анализ (pylint тот же) решает большую часть проблем.
мне кажется, вывод в статье формально правильный — выкладывать проекты с мыслью, что щаз набегут разработчики и начнут делать за тебя свою работу, — наивно. но ведь гитхаб это еще и соц.сеть. код сам по себе ни что, обратная связь — бесценна. :)