Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 218
Я ничего не понял, но мне теперь тоже интересно.
Сначала подумал, что, возможно, их JS-шаблонизатор требует, чтоб строки локализации присутствовали в глобальном объекте. Посмотрел повнимательнее — там еще куча глобальных функций. Воможно, версия про студентов первого курса не так уж далека от истины…
Как они говорят. Студентов с исключительно красным дипломом
Большинство студентов с красными дипломами и кучей выигранных олимпиад плохо пишут реальный код.
Это точно, сам себя не похвалишь — никто не похвалит и не оценит ^_^
А если не про себя, то я знаю парочку таких.
Это вы по Фрейду так отреагировали?
Я лично тоже знаю людей, вообще без айти образования, которые пишут, может быть, и не как боги, но довольно профессионально.
Я лично тоже знаю людей, вообще без айти образования, которые пишут, может быть, и не как боги, но довольно профессионально.
Это хорошо, что они работают в области чисто-IT. Ибо когда такие гении вылезают в реальный мир, кодируют «что сказали как сказали» без понимания как оно должно работать, на выходе получается нечто, что отлаживать долго и нудно.
Без знания физики и математики пытаются кодировать мат.модель физ.процесса. Итог — плачевен.
Без знания физики и математики пытаются кодировать мат.модель физ.процесса. Итог — плачевен.
Мне сложно представить зачем может потребоваться знание моделей физ. процессов в социальной сети. Это я к тому что мы говорили про студентов с красным дипломом которые работают в VK
Например, случайные процессы и понимание пуассоновского распределения при проектировании нагрузки.
Это скорее пример только для того что бы привести его. В реальных условиях для моделирования случайного процесса (случайного выполнения данных) будет достаточно функции rand()
вот именно, что пользуются равномерным там, где нужна гауссиана. И потом удивляются, а «почему упало под нагрузкой? мы же тестировали на десятикратном запасе!»
Приведите пожалуйста пример сайта где может потребоваться использование распределения гауссиана.
Я же сказал — моделирование нагрузки на сайт.
Вам не кажется что моделированием нагрузки на сайт должен заниматься не рядовой программист? И вообще эти должен заниматься отдельный отдел. Мало того им совершенно не обязательно знать физику. Им достаточно знать что для моделирования нагрузки на сайт нужно использовать распределение Гауса. С другой стороны зная физику программист еще должен понять что тут нужно применить гауссиану, а не обычный rand.
Также можно навести пример где от программиста потребуются превосходные знания русского языка. Например при написании синонимайзера. Но все вышеперечисленное позволяет сказать только такую фразу «иногда от программиста могут потребоваться знания различных дисциплин». Но никак не такую «программист должен превосходно знать физику, математику, биологию, химию, русский и английский языки»
Вот именно поэтому, высшее образование и есть большой плюс — у человека как раз есть кругозор и широкая база. В отличие от самоучек, которые зачастую глубокие знания в области, в которой вертятся долго, и полный вакуум вокруг.
Кстати, как правило вопиющая безграмотность выливается в такую же безграмотность и в работе…
Кстати, как правило вопиющая безграмотность выливается в такую же безграмотность и в работе…
Высшее образование из другой сферы у самоучки в IT вполне себе частое явление.
xD
Господа, помните цитату в пикнике на обочине стругацких — мы забиваем гвозди микроскопом.
Очень не хочу кого-то обижать, но
Мы пользуемся такой методологией, которую сами сможем «потянуть».
Как обычно говорят, мне математика в жизни не пригодилась, нах я изучал какую-нибудь тригонометрию или топологию.
Люди так говорят, так как условно могут быть разделены по мотивации и мировоззрению на:
1)люди, которые никогда не удивляются;
2) люди, которые удивляются, но не задумываются над удивившим их явлением;
3) люди, которые, удивившись, спрашивают «а почему?»;
4) люди, которые, удивившись, обращаются к числу и мере.
Так вот, господа, если вы не обладаете обширной методологией со множеством инструментов(потому что вам это не интересно), и вам не известно, что Перельман в нашумевших публикациях подписывался не Григорий, а просто Гриша(как пример что может интересовать), и вы даже не в силах/ не хотите увидеть например квадратичную зависимость или фракталы вокруг себя, не стоит утверждать, что какая-либо наука говно или ничему полезному не учит. Просто, возможно, это не ваше призвание. Мы все разные — это наша сила как вида. Мир всем)
Очень не хочу кого-то обижать, но
Мы пользуемся такой методологией, которую сами сможем «потянуть».
Как обычно говорят, мне математика в жизни не пригодилась, нах я изучал какую-нибудь тригонометрию или топологию.
Люди так говорят, так как условно могут быть разделены по мотивации и мировоззрению на:
1)люди, которые никогда не удивляются;
2) люди, которые удивляются, но не задумываются над удивившим их явлением;
3) люди, которые, удивившись, спрашивают «а почему?»;
4) люди, которые, удивившись, обращаются к числу и мере.
Так вот, господа, если вы не обладаете обширной методологией со множеством инструментов(потому что вам это не интересно), и вам не известно, что Перельман в нашумевших публикациях подписывался не Григорий, а просто Гриша(как пример что может интересовать), и вы даже не в силах/ не хотите увидеть например квадратичную зависимость или фракталы вокруг себя, не стоит утверждать, что какая-либо наука говно или ничему полезному не учит. Просто, возможно, это не ваше призвание. Мы все разные — это наша сила как вида. Мир всем)
А как вы перескочили с пуассоновского процесса на нормальное распределение? Экспоненциальное же. Или речь о ЦПТ?
Пуассон — для событий «пришел новый пользователь» при обычном поведении.
Когда идёт нагрузочное тестирование вида «в XX у нас ожидается внезапный наплыв людей» — этот наплыв уже надо нормалью моделировать, ибо есть четко выраженное МО…
А я видел как рассуждали: «Ну по счетчику у нас 3000 человек в день, значит надо чтоб сайт держал 2 человека в минуту» => брали VDS на 256 RAM и 300MHz CPU. Потом удивлялись почему всё падало…
Когда идёт нагрузочное тестирование вида «в XX у нас ожидается внезапный наплыв людей» — этот наплыв уже надо нормалью моделировать, ибо есть четко выраженное МО…
А я видел как рассуждали: «Ну по счетчику у нас 3000 человек в день, значит надо чтоб сайт держал 2 человека в минуту» => брали VDS на 256 RAM и 300MHz CPU. Потом удивлялись почему всё падало…
Я согласен с тем что по среднему считать нельзя. Все зависит от дисперсии входящего потока пользователей. Мое замечание было по поводу того, что в теории массового обслуживания нормальное распределение встречается крайне редко. С расчетом пиковой нагрузки не знаком. Буду благодарен если скинете материал на эту тему.
Строго говоря, почти во всех случаях МО правильнее брать пуассона.
Но если мы считаем «идеальную» систему, когда время обслуживания не зависит от числа пришедших пользователей, время обработки одного пользователя — таки нормальное распределение, дальше от которого начинаются пляски.
Плюс, если мы знаем, что что начало будет в X часов, вероятность отклонения от этого самого X как раз вполне себе описывается нормальным — почти все придут в течение +-10 минут от момента X, вероятность «самых умных» которые придут по-раньше и тех кто опоздает примерно равно — всё вполне себе позволяет симулякрить по нормальному.
Фактические данные, которые я рассматривал, вполне укладывались (дов. 0.96).
Но если мы считаем «идеальную» систему, когда время обслуживания не зависит от числа пришедших пользователей, время обработки одного пользователя — таки нормальное распределение, дальше от которого начинаются пляски.
Плюс, если мы знаем, что что начало будет в X часов, вероятность отклонения от этого самого X как раз вполне себе описывается нормальным — почти все придут в течение +-10 минут от момента X, вероятность «самых умных» которые придут по-раньше и тех кто опоздает примерно равно — всё вполне себе позволяет симулякрить по нормальному.
Фактические данные, которые я рассматривал, вполне укладывались (дов. 0.96).
Странно. У меня нет ВО, я дизайнер, и при этом понимаю, о чем вы тут пишете и вашу аргументацию…
И, при необходимости, пользуясь накопленными в интернете знаниями, смог бы реализовать нормальное распределение на C. (Это насчет кругозора.)
Мне кажется, роль ВО «слегка» преувеличена. Математику, напрмер, спокойно можно освоить самостоятельно, посмотрев курс лекций из какого-нибудь университета или просто по книгам.
И, при необходимости, пользуясь накопленными в интернете знаниями, смог бы реализовать нормальное распределение на C. (Это насчет кругозора.)
Мне кажется, роль ВО «слегка» преувеличена. Математику, напрмер, спокойно можно освоить самостоятельно, посмотрев курс лекций из какого-нибудь университета или просто по книгам.
чтобы так не рассуждать, нужно просто немного думать. Не считаю что нужно знать истинные причины физических явлений чтобы выбирая сервер, считать не так как в вашем примере.
простите, мимо, это на коммент выше.
>Мне сложно представить зачем может потребоваться знание моделей физ. процессов в социальной сети.
А на Udacity целый курс запилили по алгоритмам как раз применительно к соц сетям. Вот дураки то, не понимают, что в соцсетях алгоритмы не нужны…
А на Udacity целый курс запилили по алгоритмам как раз применительно к соц сетям. Вот дураки то, не понимают, что в соцсетях алгоритмы не нужны…
Сарказм тут неуместен. После вашего комментария мне не стало проще представить место где может потребоваться знание физических моделей на большинстве сайтов и в соц. сетях в частности.
Глобально, в тестировании нагрузки и т.д. как навел уважаемый datacompboy можно. Для какого то анализа тоже. Но (утрируя) анализировать можно не зная программирования вообще.
Глобально, в тестировании нагрузки и т.д. как навел уважаемый datacompboy можно. Для какого то анализа тоже. Но (утрируя) анализировать можно не зная программирования вообще.
для соцсетей нужна дискретная математика, теория графов, недурным будет реляционное исчисление, общая алгебра.
но да, можно лабать на коленке вывод формы приёма платежей и без всего этого.
но да, можно лабать на коленке вывод формы приёма платежей и без всего этого.
В целом мне кажется оптимальным такой процесс разработки. Поступает задание на создание какого то модуля проекта. В процессе выясняется что будут использоваться физические модели. Нанимается проФФесор который доступным языком вводит в курс дела программистов и курирует процесс, в тех рамках которые ему позволены. Также если будет писаться модель взаимодействия бойцов дзюдо будет приглашен соответствующий человек.
В идеале конечно хорошо если все это знаю свои люди. Вообще очень хорошо если есть человек который знает все.
В идеале конечно хорошо если все это знаю свои люди. Вообще очень хорошо если есть человек который знает все.
>Нанимается проФФесор который доступным языком вводит в курс дела программистов и курирует процесс
Ага, нужно написать навигационную софтину, нанимаются пара университетских преподавателей, которые вначале читают сжатый курс дискретки, графов и алгоритмов. И только потом, через пару месяцев, программеры приступают к написанию софта:D
Плюсы высшего образования в том, что:
а) Оно даёт некоторую базу фундаментальных знаний
б) Оно учит человека учится — добывать знания
Безусловно, есть самородки, которым универ не нужен, они и без него способны получить эти скиллы, но таких — единицы.
Ага, нужно написать навигационную софтину, нанимаются пара университетских преподавателей, которые вначале читают сжатый курс дискретки, графов и алгоритмов. И только потом, через пару месяцев, программеры приступают к написанию софта:D
Плюсы высшего образования в том, что:
а) Оно даёт некоторую базу фундаментальных знаний
б) Оно учит человека учится — добывать знания
Безусловно, есть самородки, которым универ не нужен, они и без него способны получить эти скиллы, но таких — единицы.
Это из другой оперы. Вы говорите про узконаправленное программирование. Скажем так. Если вы разрабатыванием навигационные софтины где значительную часть времени нужно разбираться с сложнейшими алгоритмами вы должны нанимать программистов профессионалов в этой области. Высшее образование тут ни причем. Оно тут вообще ни причем. Я учился на физмате с углубленным изучением физики. И как можно судить с моего раннего комментария, я ее призабыл. Потому я никак не попаду в группу программистов подходящих для тех целей.
Вашу позицию я понимаю. Вы берете пример где требование к сторонним знаниям от программиста необходимо. И с этой позиции говорите про преимущество этих знаний всем программистам. Но опять же можно с легкостью привести пример где от программиста будет требоваться отличное знание женского тела. И с этой позиции утверждать что отличное знание женского тела необходимо программистам.
Вашу позицию я понимаю. Вы берете пример где требование к сторонним знаниям от программиста необходимо. И с этой позиции говорите про преимущество этих знаний всем программистам. Но опять же можно с легкостью привести пример где от программиста будет требоваться отличное знание женского тела. И с этой позиции утверждать что отличное знание женского тела необходимо программистам.
> вы должны нанимать программистов профессионалов в этой области. Высшее образование тут ни причем. Оно тут вообще ни причем.
Т.е. вы считаете, что подобным профессионалом сможет стать любой, в том числе и тот, у кого нет ВО?
>Я учился на физмате с углубленным изучением физики. И как можно судить с моего раннего комментария, я ее призабыл. Потому я никак не попаду в группу программистов подходящих для тех целей.
А причём тут физика вообще? Там, как и в большинстве задач — математика.
>И с этой позиции говорите про преимущество этих знаний всем программистам
Я говорю, что у человека с ВО будет преимущество по _получению_ новых знаний.
>Но опять же можно с легкостью привести пример где от программиста будет требоваться отличное знание женского тела
Ну так приведите такой пример:)
Т.е. вы считаете, что подобным профессионалом сможет стать любой, в том числе и тот, у кого нет ВО?
>Я учился на физмате с углубленным изучением физики. И как можно судить с моего раннего комментария, я ее призабыл. Потому я никак не попаду в группу программистов подходящих для тех целей.
А причём тут физика вообще? Там, как и в большинстве задач — математика.
>И с этой позиции говорите про преимущество этих знаний всем программистам
Я говорю, что у человека с ВО будет преимущество по _получению_ новых знаний.
>Но опять же можно с легкостью привести пример где от программиста будет требоваться отличное знание женского тела
Ну так приведите такой пример:)
Мне кажется что мы все дальше отходим от основной темы.
1) Это выходит за рамки спора. Я говорю что программисту не обязательно разбираться в физике что бы быть отличным программистом.
2) Но мы изначально говорили про физику. И мой ранний комент был про термин используемый в физике. Хотя в математике этот алгоритм тоже используется.
3) А я говорю что не факт. В университете приучают изучать то что тебе дают. А вот к самостоятельному обучению приучится можно только самому.
4) Да к примеру сайт по подбору ночных бабочек. С подбором бюстов, объема груди и т.д. И разделение бюста проходит в несколько этапов. И все различные варианты нужно поделить по нескольким категориям. Что бы это удовлетворяло клиента. Или сайт по покрою свадебных платьев. Где на основе фигуры девушки нужно вычислять объем затраченных материалов. А на основе уже заполненных вариантов подбирать предположительные параметры.
1) Это выходит за рамки спора. Я говорю что программисту не обязательно разбираться в физике что бы быть отличным программистом.
2) Но мы изначально говорили про физику. И мой ранний комент был про термин используемый в физике. Хотя в математике этот алгоритм тоже используется.
3) А я говорю что не факт. В университете приучают изучать то что тебе дают. А вот к самостоятельному обучению приучится можно только самому.
4) Да к примеру сайт по подбору ночных бабочек. С подбором бюстов, объема груди и т.д. И разделение бюста проходит в несколько этапов. И все различные варианты нужно поделить по нескольким категориям. Что бы это удовлетворяло клиента. Или сайт по покрою свадебных платьев. Где на основе фигуры девушки нужно вычислять объем затраченных материалов. А на основе уже заполненных вариантов подбирать предположительные параметры.
Понимание и умение: ksoftware.livejournal.com/221469.html
Мне всегда очень хочется поставить точку в подобных холиварах про образование(был как-то пост ).
вот что я думаю, поправьте, пожалуйста, если найдете ошибку в умозаключениях:
«Умность» человека имхо считаю прямо пропорционалной развитости методологи (совокупности инструментов дата майнинга и дата процессинга и тп).
Дальше все просто — перечисляем факторы, которые влияют на развитие методологии в кокрентном примере. Можно их статистически «взесить» и тп. для кого-то — это школа/университет, для кого-то это отличный коллега на работе, для кого-то папа-ядерщик и тд — таким образом мы и получаем такую вариативность, причем у веса факторов будут для всех разные. И в каждом конкретном случае, будет что-то свое. Надеюсь понятна мысль.
То есть исходя из вышесказанного, мне кажется, что однозначно утверждать умен/профессионален и тп ли человек судя по его диплому или его отсуствию не следует так как мы не знаем что повлияло на ителлектуально развитие человека.
как то так.
вот что я думаю, поправьте, пожалуйста, если найдете ошибку в умозаключениях:
«Умность» человека имхо считаю прямо пропорционалной развитости методологи (совокупности инструментов дата майнинга и дата процессинга и тп).
Дальше все просто — перечисляем факторы, которые влияют на развитие методологии в кокрентном примере. Можно их статистически «взесить» и тп. для кого-то — это школа/университет, для кого-то это отличный коллега на работе, для кого-то папа-ядерщик и тд — таким образом мы и получаем такую вариативность, причем у веса факторов будут для всех разные. И в каждом конкретном случае, будет что-то свое. Надеюсь понятна мысль.
То есть исходя из вышесказанного, мне кажется, что однозначно утверждать умен/профессионален и тп ли человек судя по его диплому или его отсуствию не следует так как мы не знаем что повлияло на ителлектуально развитие человека.
как то так.
А знания физики и математики мало помогут в реализации рабочих процессов обработки данных для банка. Тоже реальный мир, кстати.
Это я к тому, что в каждом домене нужны свои знания, и превосходные знания физики и математики, данные образованием, очень часто просто не нужны.
Это я к тому, что в каждом домене нужны свои знания, и превосходные знания физики и математики, данные образованием, очень часто просто не нужны.
Студент с дипломом — оксюморон какой-то. Либо диплом уже есть, либо студент.
> Воможно, версия про студентов первого курса не так уж далека от истины
Только вот на практике, это один из самых шустро работающих сайтов мне известных (:
Только вот на практике, это один из самых шустро работающих сайтов мне известных (:
Посетите мой сайт =)
у вконтакте не наблюдал картинки «лоадинг», когда переходишь со страницы на страницу :-)
Это было моим упущением во время проектировки на ранней стадии. Но время подгрузок занимает не больше чем у вк, а то и быстрее. Сейчас с другом пишем новую версию, там будет всё правильно.
В действительности убрана. Картинка загрузки осталась лишь при начальной загрузке сайта и смены языка. Возможно закешировало у вас, в хроме почему-то так случается, хотя я версию файла сменил. Если что, напишите мне в лс, буду разбираться в чём дело.
Если что-то не так с переводами на английском, будьте добры указать, нас всего двое, лингвиста нет, своими силами переводили. Большое спасибо за отзыв )
Если что-то не так с переводами на английском, будьте добры указать, нас всего двое, лингвиста нет, своими силами переводили. Большое спасибо за отзыв )
Я сайт начинал писать 3 года назад, на разной степени своего опыта. Когда я начинал, тогда даже window.onHashChange не все браузеры поддерживали, я писал эмулятор. В то время из динамических сайтов был только девиантарт и гмэйл. Тогда же я и игрался с гистори апи, но так как поддержка ограничивалась только хромом, я оставил на потом. В новой версии, которую сейчас пишу, я ещё не решился его использовать, мне не нравится, что при ручной смене адреса произойдёт релоад страницы. В любом случае, внедрение гистори апи займёт не больше 10 строк. Кстати, сейчас он тоже используется, если зайти на сайт без хеша.
Может, это поможет вам определиться)
javascript.ru/forum/project/21077-history-rassshirenie-dlya-brauzerov-ne-podderzhivayushhikh-pushstate-replacestate.html
javascript.ru/forum/project/21077-history-rassshirenie-dlya-brauzerov-ne-podderzhivayushhikh-pushstate-replacestate.html
Ради интереса, решил картинку с загрузкой завалить.
У вас тоже 40 миллионов посетителей в сутки?
У них тоже одна вдска на хецнере?
Путь от одной VDS'ки в хецнере до 40 миллионов в сутки далеко не такой горизонтальный, как может показаться на первый взгляд.
99% блогов на любой цмс с посещением >= 0 грузятся далеко не 20-100 мс на страницу.
Но я не о том. Фактически любой сайт, сделанный на аджакс, априори будет быстрее статического.
Нет, потому что передача данных об объектах, над которыми происходят операции внутри системы, может потребовать дополнительных запросов.
Если за один запрос станицы, делается больше одного запроса к серверу, значит что-то не так с архитектурой приложения. В любом случае, можно сделать\скомпоновать мультизапрос.
Простой пример: вы оставляете комментарий на хабре. Post запрос в комментарии, обновление остальных комментариев — get запрос к коллекции комментариев. Ибо согласно рест post#comments должен вернуть 201, и не должен содержать никаких других объектов кроме созданного комментария.
Что такое мультизапрос?
Что такое мультизапрос?
Видимо, это способ получить несколько разных объектов в одном запросе, указав в качестве аргумента URL к каждому из них
JSON RPC 2.0 во все поля.
Ну а поскольку сервер должен вернуть результаты обработки всех объектов, какова скорость выполнения такого мультизапроса? Т.о. вся прелесть аякса умирает под JSON-RPC мультизапросами.
скорость выполнения запроса целиком и полностью зависит от реализации вашего бэкэнда.
Скорость выполнения мультизапроса зависит от скорости выполнения самого медленного запроса.
А вы просто не засовывайте заведомо медленные запросы к коротким. Или перейдите на асинхронный обмен сообщения между клиентом и сервером.
1. т.е. перед отправкой запроса я должен предположить скорость выполнения каждого запроса, потом я все короткие запросы должен завернуть в мультизапрос, а медленный запрос отправить отдельно? На мой взгляд слишком сложно и неоднозначно.
2. Зачем тогда мультизапрос, если каждый запрос выполняется асинхронно?
3. Тогда JSON-RPC не обязателен, но возможен, но зачем тогда мультизапрос?
4. Тогда нужно WEB-Sockets, если обмен сообщениями полнодуплексный.
Зачем усложнять себе жизнь, когда можно пользоваться обычным Ajax-ом, с обычным нативным JSON-ом.
«JSON RPC 2.0 во все поля»(объекты, вы видимо все таки имели в виду) в подавляющем большинстве случаев решает задачу не быстрее, серверная и клиентская стороны стоновятся в разы сложнее, когда достаточно REST с прямой диспетчериазацией к обработчику конкретного объекта, и с указанием цели запроса еще на стороне клиента(URL). Т.о. я вижу применение JSON-RPC с мультизапросами крайне специфическим решением, даже не могу представить где такое нужно применять.
2. Зачем тогда мультизапрос, если каждый запрос выполняется асинхронно?
3. Тогда JSON-RPC не обязателен, но возможен, но зачем тогда мультизапрос?
4. Тогда нужно WEB-Sockets, если обмен сообщениями полнодуплексный.
Зачем усложнять себе жизнь, когда можно пользоваться обычным Ajax-ом, с обычным нативным JSON-ом.
«JSON RPC 2.0 во все поля»(объекты, вы видимо все таки имели в виду) в подавляющем большинстве случаев решает задачу не быстрее, серверная и клиентская стороны стоновятся в разы сложнее, когда достаточно REST с прямой диспетчериазацией к обработчику конкретного объекта, и с указанием цели запроса еще на стороне клиента(URL). Т.о. я вижу применение JSON-RPC с мультизапросами крайне специфическим решением, даже не могу представить где такое нужно применять.
1. Да, для этого нужен Front-end Engineer, а не мальчик/девушка верстальщик со знанием jQuery
2. Чтобы отправить их сразу много, возвращать из можно группами. Вам никто не запрещает придумывать, что-то свое.
3. Был вопрос про несколько запросов в одном, на него ответил.
4. Да. Нужны. Они есть. И легко эмулируются на флеше.
> Зачем усложнять себе жизнь, когда можно пользоваться обычным Ajax-ом, с обычным нативным JSON-ом.
Допустим то, что AJAX это XML? И то что надо планировать архитектуру клиентского приложения так или иначе? Проводить тесты и смотреть как лучше?
> объекты, вы видимо все таки имели в виду
Выражение такое.
> Т.о. я вижу применение JSON-RPC с мультизапросами крайне специфическим решением, даже не могу представить где такое нужно применять.
Вся суть JSON-RPC в том, что есть некий стандарт. REST это отсебятина и чистый REST дальше CRUD'ов не натянуть в реальной жизни. Допустим я обновил 10 записей разом, мне делать 10 HTTP запросов? А согласно договоренности я должен предоставить весь документ целиком — 10 толстый запросов. (PATCH метод же еще не в спецификации)
2. Чтобы отправить их сразу много, возвращать из можно группами. Вам никто не запрещает придумывать, что-то свое.
3. Был вопрос про несколько запросов в одном, на него ответил.
4. Да. Нужны. Они есть. И легко эмулируются на флеше.
> Зачем усложнять себе жизнь, когда можно пользоваться обычным Ajax-ом, с обычным нативным JSON-ом.
Допустим то, что AJAX это XML? И то что надо планировать архитектуру клиентского приложения так или иначе? Проводить тесты и смотреть как лучше?
> объекты, вы видимо все таки имели в виду
Выражение такое.
> Т.о. я вижу применение JSON-RPC с мультизапросами крайне специфическим решением, даже не могу представить где такое нужно применять.
Вся суть JSON-RPC в том, что есть некий стандарт. REST это отсебятина и чистый REST дальше CRUD'ов не натянуть в реальной жизни. Допустим я обновил 10 записей разом, мне делать 10 HTTP запросов? А согласно договоренности я должен предоставить весь документ целиком — 10 толстый запросов. (PATCH метод же еще не в спецификации)
1. Зачем вычислять заранее скорость выполнения запроса, если запрос в любом случае придется отправить, так или иначе?
4. Во первых, флеш не поддерживается минимум 10 миллионами устройств. Во вторых, web-sockets нужен в редких случаях, когда клиент должен ожидать не инициированного клиентом сообщения с сервера. 1 из 50 приложений, как мне кажется требуют такой функционал.
REST разрешает обновлять 10 записей разом. Хачу другой пример :)
4. Во первых, флеш не поддерживается минимум 10 миллионами устройств. Во вторых, web-sockets нужен в редких случаях, когда клиент должен ожидать не инициированного клиентом сообщения с сервера. 1 из 50 приложений, как мне кажется требуют такой функционал.
REST разрешает обновлять 10 записей разом. Хачу другой пример :)
1. Затем, что надо думать головой прежде чем поставить сервер в тупик.
4. И почему я это ожидал? Теперь скажите сколько из тех устройств, что не может во флэш не умеет в вэбсокеты? long-polling никто не отменял.
> Во вторых, web-sockets нужен в редких случаях, когда клиент должен ожидать не инициированного клиентом сообщения с сервера. 1 из 50 приложений, как мне кажется требуют такой функционал.
Это если мыслить как вы. Я бы сделал фулл-дуплекс работу с бэкэндом.
> REST разрешает обновлять 10 записей разом. Хачу другой пример :)
С каких пор? В православном ресте так нельзя. Пример: мне нужно изменить статус какого-то объекта (допустим виртуальной машины) — хочу ее выключить, хочу ее перезагрузить. Обе операции требуют состояния, REST это запрещает. Где ваш бог теперь?
4. И почему я это ожидал? Теперь скажите сколько из тех устройств, что не может во флэш не умеет в вэбсокеты? long-polling никто не отменял.
> Во вторых, web-sockets нужен в редких случаях, когда клиент должен ожидать не инициированного клиентом сообщения с сервера. 1 из 50 приложений, как мне кажется требуют такой функционал.
Это если мыслить как вы. Я бы сделал фулл-дуплекс работу с бэкэндом.
> REST разрешает обновлять 10 записей разом. Хачу другой пример :)
С каких пор? В православном ресте так нельзя. Пример: мне нужно изменить статус какого-то объекта (допустим виртуальной машины) — хочу ее выключить, хочу ее перезагрузить. Обе операции требуют состояния, REST это запрещает. Где ваш бог теперь?
1. Как вы поставите сервер в тупик штатным запросом? Пользователь не думает когда формирует данные для запроса. Эта защита должна быть на бэкенде.
> Это если мыслить как вы. Я бы сделал фулл-дуплекс работу с бэкэндом.
Это клиова да, но зачем же эмалированные гвозди и наномолоток для сборки табуреток?
> С каких пор?
PUT /resouces/1 для объекта
PUT /resouces для коллекции
разве это не православный рест?
В вашем примере для виртуальной машины — последовательное изменение состояний между состояниями состоянием выключено и перезагружено. Как ваша машина может находиться сразу в двух состояних? Ересь какаята :) Только анафема, только хардкор :)
> Это если мыслить как вы. Я бы сделал фулл-дуплекс работу с бэкэндом.
Это клиова да, но зачем же эмалированные гвозди и наномолоток для сборки табуреток?
> С каких пор?
PUT /resouces/1 для объекта
PUT /resouces для коллекции
разве это не православный рест?
В вашем примере для виртуальной машины — последовательное изменение состояний между состояниями состоянием выключено и перезагружено. Как ваша машина может находиться сразу в двух состояних? Ересь какаята :) Только анафема, только хардкор :)
1. Фронт-енд надо продумывать тоже. Что есть штатный запрос? Есть запросы которые занимают дольше времени чем большая часть запросов.
> Это клиова да, но зачем же эмалированные гвозди и наномолоток для сборки табуреток?
Я не собираю табуретки, вот в чем дело.
> разве это не православный рест?
Нет.
> В вашем примере для виртуальной машины — последовательное изменение состояний между состояниями состоянием выключено и перезагружено. Как ваша машина может находиться сразу в двух состояних? Ересь какаята :) Только анафема, только хардкор :)
Это два разных действия. Они оба не возможны в православном REST'е.
> Это клиова да, но зачем же эмалированные гвозди и наномолоток для сборки табуреток?
Я не собираю табуретки, вот в чем дело.
> разве это не православный рест?
Нет.
> В вашем примере для виртуальной машины — последовательное изменение состояний между состояниями состоянием выключено и перезагружено. Как ваша машина может находиться сразу в двух состояних? Ересь какаята :) Только анафема, только хардкор :)
Это два разных действия. Они оба не возможны в православном REST'е.
1. Есть, от них никуда не деться, их все равно придется отправлять, как проектирование фронтенда поможет избавиться от запроса ставящего сервер в тупик кроме как не формировать такой запрос вообще?
> Я не собираю табуретки, вот в чем дело.
Вы один из 100, ваши навыки вызывают зависть, но в в 49 случаях из 50 они не нужны. Значит — ваше решение не подходит для большинства табуреток.
> Это два разных действия. Они оба не возможны в православном REST'е.
Два запроса, один на down, второй на restart, или наоборот.
> Обе операции требуют состояния.
Видимо у меня недостаточно формальных признаков, чтобы сформировать частную ассоциацию с этими событиями. Как мне кажется машина может находиться в одно время в одном состоянии. Все изменения состояний возможы: работает -> перезапускается, работает -> шатдаунится, рестартится -> шатдаунится, шатданится -> (рестарт) -> шатдаунится.
Чего вы недорассказали в вашем примере, чтобы я увидел единственную возможную реализацию решения, не иначе как через JSON-RPC?
> Я не собираю табуретки, вот в чем дело.
Вы один из 100, ваши навыки вызывают зависть, но в в 49 случаях из 50 они не нужны. Значит — ваше решение не подходит для большинства табуреток.
> Это два разных действия. Они оба не возможны в православном REST'е.
Два запроса, один на down, второй на restart, или наоборот.
> Обе операции требуют состояния.
Видимо у меня недостаточно формальных признаков, чтобы сформировать частную ассоциацию с этими событиями. Как мне кажется машина может находиться в одно время в одном состоянии. Все изменения состояний возможы: работает -> перезапускается, работает -> шатдаунится, рестартится -> шатдаунится, шатданится -> (рестарт) -> шатдаунится.
Чего вы недорассказали в вашем примере, чтобы я увидел единственную возможную реализацию решения, не иначе как через JSON-RPC?
> 1. Есть, от них никуда не деться, их все равно придется отправлять, как проектирование фронтенда поможет избавиться от запроса ставящего сервер в тупик кроме как не формировать такой запрос вообще?
А он есть и он должен быть выполнен, но он может быть выполнен в бэграунде, а клиент должен иметь возможность получить статус. Клиент так же должен иметь возможность обновить данные если коллекция была обновлена кем-то другим.
> Два запроса, один на down, второй на restart, или наоборот.
Как вы сделаете рестарт без состояния? или как вы выключите без состояния? Согласно принципам REST запрос на один и тот же поинт должен приводить к одним и тем же результатам. Тоесть состояния нет.
> Вы один из 100, ваши навыки вызывают зависть, но в в 49 случаях из 50 они не нужны. Значит — ваше решение не подходит для большинства табуреток.
в 27/50 случаев хватило бы статического сайта, но мы же так не делаем? Но мы же сейчас говорим про вэб сервисы и мобильные приложения?
> Чего вы недорассказали в вашем примере, чтобы я увидел единственную возможную реализацию решения, не иначе как через JSON-RPC?
Я про JSON-RPC уже не говорю. Я говорю про фатальный (tm) недостаток REST. От православного REST кроме как использование HTTP методов как глаголы и задание URI для ресурсов взять больше нечего.
> Чего вы недорассказали в вашем примере, чтобы я увидел единственную возможную реализацию решения, не иначе как через JSON-RPC?
Вы просто не понимаете, что вы говорите о не-православном REST. Православный REST это web интерфейс для CRUDов.
А он есть и он должен быть выполнен, но он может быть выполнен в бэграунде, а клиент должен иметь возможность получить статус. Клиент так же должен иметь возможность обновить данные если коллекция была обновлена кем-то другим.
> Два запроса, один на down, второй на restart, или наоборот.
Как вы сделаете рестарт без состояния? или как вы выключите без состояния? Согласно принципам REST запрос на один и тот же поинт должен приводить к одним и тем же результатам. Тоесть состояния нет.
> Вы один из 100, ваши навыки вызывают зависть, но в в 49 случаях из 50 они не нужны. Значит — ваше решение не подходит для большинства табуреток.
в 27/50 случаев хватило бы статического сайта, но мы же так не делаем? Но мы же сейчас говорим про вэб сервисы и мобильные приложения?
> Чего вы недорассказали в вашем примере, чтобы я увидел единственную возможную реализацию решения, не иначе как через JSON-RPC?
Я про JSON-RPC уже не говорю. Я говорю про фатальный (tm) недостаток REST. От православного REST кроме как использование HTTP методов как глаголы и задание URI для ресурсов взять больше нечего.
> Чего вы недорассказали в вашем примере, чтобы я увидел единственную возможную реализацию решения, не иначе как через JSON-RPC?
Вы просто не понимаете, что вы говорите о не-православном REST. Православный REST это web интерфейс для CRUDов.
1. Окай. Клиенту вернется статус, фронтент будет ожидать появления этого статуса независимо от того решени ли это REST-ом или JSON-RPC не вижу разницы.
> Согласно принципам REST запрос на один и тот же поинт должен приводить к одним и тем же результатам.
Нет, результатом может быть как 402, 500 так и 200, и 201. Что мы понимаем под результатом? GET на поинт даст нам статус. PUT на объект с неожиданным статусом вернет нам 402 с коллекцией ошибок.
> в 27/50 случаев хватило бы статического сайта, но мы же так не делаем? Но мы же сейчас говорим про вэб сервисы и мобильные приложения?
> в 27/50 случаев хватило бы статического сайта, но мы же так не делаем? Но мы же сейчас говорим про вэб сервисы и мобильные приложения?
Не совсем, началось все с:
>>> Если за один запрос станицы, делается больше одного запроса к серверу, значит что-то не так с архитектурой приложения. В любом случае, можно сделать\скомпоновать мультизапрос.
У меня везде православный рест.
/me пожимает плечами и ничего не может понять
POST /cars(.:format) cars#create — CRUD? CRUD!
POST /cars/:car_id/proposal(.:format) proposals#create — CURD? CRUD!
GET /cars/:car_id/proposal(.:format) proposals#show — CRUD?
Чего вам не хватает в REST?
> Согласно принципам REST запрос на один и тот же поинт должен приводить к одним и тем же результатам.
Нет, результатом может быть как 402, 500 так и 200, и 201. Что мы понимаем под результатом? GET на поинт даст нам статус. PUT на объект с неожиданным статусом вернет нам 402 с коллекцией ошибок.
> в 27/50 случаев хватило бы статического сайта, но мы же так не делаем? Но мы же сейчас говорим про вэб сервисы и мобильные приложения?
> в 27/50 случаев хватило бы статического сайта, но мы же так не делаем? Но мы же сейчас говорим про вэб сервисы и мобильные приложения?
Не совсем, началось все с:
>>> Если за один запрос станицы, делается больше одного запроса к серверу, значит что-то не так с архитектурой приложения. В любом случае, можно сделать\скомпоновать мультизапрос.
У меня везде православный рест.
/me пожимает плечами и ничего не может понять
POST /cars(.:format) cars#create — CRUD? CRUD!
POST /cars/:car_id/proposal(.:format) proposals#create — CURD? CRUD!
GET /cars/:car_id/proposal(.:format) proposals#show — CRUD?
Чего вам не хватает в REST?
А это кого-то волнует при таком времени суммарной загрузки?
www.webpagetest.org/result/121024_NF_6Y2/
www.webpagetest.org/result/121024_NF_6Y2/
Только вот памяти этот шустряк жрёт как не в себя. Раз в день стабильно приходится убивать процесс со вкладкой вк.
В хроме вырастает до 600Мб, в Лисе до 450.
В хроме вырастает до 600Мб, в Лисе до 450.
Загружается быстро, но тормозит и памяти жрет охренеть как. В опере ютуб лагает, если открыта вкладка с контактом. Закрываешь вкладку и лаги прекращаются. Второго такого сайта я не видел.
Ну вот не нужно сразу на студентов(и на первом курсе я так не делал), я допустим глобальные переменные делаю только под страхом смерти при крайней необходимости. Мне кажется достаточно одной книги по js что бы понять что так делать не нужно.
П.с Вот я нашел этот демонский файл где обьявлены глобальные переменные vk.com/js/lang0_0.js?6348.
П.с Вот я нашел этот демонский файл где обьявлены глобальные переменные vk.com/js/lang0_0.js?6348.
Ну вы же понимаете, что когда кто-то говорит «индусский код», это не не обязательно значит, что говорящий содрогается в приступе жесточайшей ксенофобии. Просто такое выражение.
Так было бы лучше (мне кажется):
Че за бред О_О?
П.с Не пойму одного, почему они сделали один объект, а все эти переменные не сделали свойствами?
Че за бред О_О?
П.с Не пойму одного, почему они сделали один объект, а все эти переменные не сделали свойствами?
А вот если задуматься… Зачем им делать ещё один объект, если уже есть window?
Что бы потом не было гемороя с глобальными переменными.
И плюс его нельзя сжать.
У них вообще ничего не обфусцируется, так что им наплевать)
Ну как я вижу у них все через опу, теперь я понимаю откуда такие сумасшедшие утечки памяти за ночь(если оставить открытую страницу).
Кстати насчет объекта и глобальных переменных, вот в коменнтах увидел хороший пример jsperf.com/global-variablestest
В книгах про js рассматривается немного другой кейс в плане глобальных переменных, а в данном случае — это лэнги для шаблонизации.
Пользуясь случаем хотел спросить про размещение вызовов функций через свойства элементов. Может это их серверный фреймворк генерирует… Потому что onclick=«return (checkEvent(event) || browser.msie6)? true: cancelEvent(event)» выглядит мягко говоря необычно. Есть ли преимущество такого использования?
Я думаю, сначала написали «абы как», а потом уже «че исправлять, работает же», и обросло все сверху.
По сути ведь эти константы «студент(ка)», «бакалавр» и т.п. нужны только в нескольких разделах сайта, так что попахивает это чем-то нехорошим.
По сути ведь эти константы «студент(ка)», «бакалавр» и т.п. нужны только в нескольких разделах сайта, так что попахивает это чем-то нехорошим.
Я думаю они это вполне сознательно сделали.
Если все функции требуют этих строк, то почему бы и не сделать их глобальными? Альтернатива в виде передачи объекта с коллекцией строк во всех вызовах тоже не особо красивая.
Единственное, могли бы завернуть в какой-то глобальный массив или объект, а не прям в window.
Если все функции требуют этих строк, то почему бы и не сделать их глобальными? Альтернатива в виде передачи объекта с коллекцией строк во всех вызовах тоже не особо красивая.
Единственное, могли бы завернуть в какой-то глобальный массив или объект, а не прям в window.
Кто-то забыл «var» :)
Как минимум много глобальных переменных негативно влияют на производительность. В общем, действительно странно, то ли есть какой-то профит, то ли лауреаты премий настолько лауреаты.
Количество глобальных переменных практически ни как не влияет на производительность. Утверждение, что доступ к глобальным переменным медленный, чем к локальным тоже не всегда верен. Глобальных переменных стоит избегать скорее из-за того, что это плохой стиль.
Обильное использование глобальных переменных — не просто плохой стиль, а отличная возможность переопределить нечто, и потом о-о-о-очень долго дебажиться. Особенно шикарно, когда над кодом работает больше одного человека.
А Вы уверены что для над этим сайтом по настоящему работает больше одного человека? :)
> Обильное использование глобальных переменных — не просто плохой стиль, а отличная возможность переопределить нечто, и потом о-о-о-очень долго дебажиться.
Если у них там только лейблы, то что они могут случайно переопределить?
Если у них там только лейблы, то что они могут случайно переопределить?
Поиск переменной — не бесплатная операция. Вот я накидал пример на JsPerf. А когда мы в нескольких скоупах и делаем безобидное === undefined, не передав его как несуществующий последний параметр функции, то в поисках переменной обойдутся все замыкания вплоть до window.
Оставлю это здесь vk.com/wall922821_674
Мне теперь тоже интересно, правы ли вы, и что за, собственно, нафиг? :-)
Но раз вы решили написать пост, мне кажется, надо было хотя бы в паре абзацев поконкретней для «нубов»(читай меня), чем вреден такой код, что такое closure и т.п. :-)
Может, Дуров, прочитав ваши доводы, удивится, проникнется и все переделает
Но раз вы решили написать пост, мне кажется, надо было хотя бы в паре абзацев поконкретней для «нубов»(читай меня), чем вреден такой код, что такое closure и т.п. :-)
Паша, что скорее всего, уже давно не кодит ничего )
В декабре учил Objective C. Так что может быть и кодит.
Скорее его брат.
Сlosure это замыкания. Если упрощенно это функция внутри функции. Не то чтобы ключевой момент яваскрипта, иногда бывает удобно.
Насчет «такого кода». Глобальные переменные сильно затрудняют понимание и сильно ухудшают читабельность кода, создают проблемы в тестировании, усложняют масштабирование и кроме того они банально ухудшают производительность.
Вообще это не значит, что глобальные переменные — зло, нет, например в небольших приложениях это ок, кроме того иногда чтобы не использовать глобальную переменную люди выстраивают такие конструкции, что лучше б они её таки использовали)
Насчет «такого кода». Глобальные переменные сильно затрудняют понимание и сильно ухудшают читабельность кода, создают проблемы в тестировании, усложняют масштабирование и кроме того они банально ухудшают производительность.
Вообще это не значит, что глобальные переменные — зло, нет, например в небольших приложениях это ок, кроме того иногда чтобы не использовать глобальную переменную люди выстраивают такие конструкции, что лучше б они её таки использовали)
Я думаю под Сlosure имелось ввиду обфускатор Google Сlosure.
> Насчет «такого кода». Глобальные переменные сильно затрудняют понимание и сильно ухудшают читабельность кода, создают проблемы в тестировании, усложняют масштабирование и кроме того они банально ухудшают производительность.
Как я понял, у них глобальные переменные только для лейблов, так что половина проблем этим решается, случайно что-то переписать или как-то еще запутаться не получится.
И насчет производительности не уверен, если альтернатива во все функции передавать объект с коллекцией строк, то глобальные переменные могут и быстрее работать.
Как я понял, у них глобальные переменные только для лейблов, так что половина проблем этим решается, случайно что-то переписать или как-то еще запутаться не получится.
И насчет производительности не уверен, если альтернатива во все функции передавать объект с коллекцией строк, то глобальные переменные могут и быстрее работать.
Вероятно, использование глобального хранилища нужно для сохранения состояний переменных при ajax-переходах между страницами. Переводы же просто передаются один раз при первом запросе всей страницы с сервера.
Ну так можно было бы глобальный массив Langs сделать, и туда все стринги кинуть?
Простите, а в чем была бы разница для производительности, глобальный массив, или много глобальных переменных?
Как минимум не нарвёшься на зарезервированное название. Сейчас не могу найти, но был тест, где большое количество глобальных переменных не лучшим образом сказывалось на производительности.
А ещё это тоже самое что писать код красиво, используя классы, неймспейсы, или писать простыню процедурного кода.
Да уж, боюсь представить, что у них творится в реализации функций vk api.
Мы у себя так сделали:
var tr;
tr.get=function(what){
if (tr.hasOwnProperty(what)) return tr[what];
else return what
}
Поэтому не факт, что так хуже. По памяти тоже, если б в какой-нить объект запихать. По скорости быстрее.
А вот в шаблонах такие переменные идеально использовать. Кто не заметил — это локализация вытащенная в глобальный scope.
Btw измерил бы кто, а то мы тут вилами на воде:
* взять три варианта — 100 переменных, хотя нет — даже 1000 переменных в глобальном скопе (window) или вообще взять node.js; столько же в одном глобальном массиве; и уже они же в объекте (пусть объект ВНЕЗАПНО называется "_")
* 10000 раз генерить некий текст, не записывая его в DOM
* каждый раз случайно выбирать переменную — пусть они будут к примеру key1, key2, ..., key1000
* доложить результаты
Вдруг мы чего-то не замечаем и это на самом деле гениально? :)
Поймите правильно.
Совет о НЕзасорении глобального пространства имён ориентирован в основном на разработчиков библиотек.
Производительность тоже, конечно, актуальна, но не настолько.
То есть, если вы пишете конечное приложение (сайт), то можно забить на часть рекомендаций. Зависит от условий.
Совет о НЕзасорении глобального пространства имён ориентирован в основном на разработчиков библиотек.
Производительность тоже, конечно, актуальна, но не настолько.
То есть, если вы пишете конечное приложение (сайт), то можно забить на часть рекомендаций. Зависит от условий.
>Сначала я удивился отсутствию jquery.
Насколько я помню, ВКонтакте принципиально не использует чужой код, фреймворки, и так далее.
Насколько я помню, ВКонтакте принципиально не использует чужой код, фреймворки, и так далее.
«так же я свято верю в то, что нельзя засорять window большим количеством глобальных объектов, это так же может сказаться на производительности и «качестве»» — в разработке софта свято верить не надо, надо делать, думать и проверять.
А чем, конкретно, не угодил глобалскоуп на сайте, где гарантированно не появится никакого левого js кода, который где-то с чем-то может пересечься?
Это я все к тому, что кроме тезиса «глобальные переменные зло», который верен в большинстве случаев, надо еще понимать почему это происходит. А в какиз случаях это может быть и не так.
А чем, конкретно, не угодил глобалскоуп на сайте, где гарантированно не появится никакого левого js кода, который где-то с чем-то может пересечься?
Это я все к тому, что кроме тезиса «глобальные переменные зло», который верен в большинстве случаев, надо еще понимать почему это происходит. А в какиз случаях это может быть и не так.
Во-первых, большое количество глобальных объектов — зло, независимо от проекта. Просто потому, что разработчик конкретного фрагмента кода не представляет себе всю номенклатуру глобальных переменных и функций, и, даже если она (номенклатура) где-то документирована (а это вряд ли), найти что-то в ней невозможно. Вчера разработчик ленты добавил в window строку «all» — всё, сегодня разработчик какого-нибудь видео радостно её заюзал, завтра разработчик ленты решил, что эта строка ему больше не нужна и грохнул её. Нет разделения по namespace-ам — нет ответственности.
На эти грабли наступил всеми нами любимый PHP, засравший своё глобальное пространство 100500 сигнатурами функций типа str_replace, str_ireplace, preg_replace, ereg_replace, etc. И за это — сюрприз — многие его и не любят.
Во-вторых, как вконтактовский код легко попадает на чужие сайты (начиная с кнопки «Like»), так и чужой код может легко попасть на страницы вконтакта (если завтра вконтакт разрешит виджеты или html5-баннеры компаниям-партнерам). И вот у ВК начнутся некислые проблемы.
Ну и, в-третьих, когда они таки решат побороться со своим глобальным зоопаркам, им придётся потратить пару человеко-месяцев на приведение всего это трэша в нормальное состояние.
В общем-то, они не первые на эти грабли наступают, не они и последние. Пару лет назад на Картахmail.ru был точно такой же трэш и угар в window. Можно спросить местных мэйлрушников, во что им встало причесать код.
На эти грабли наступил всеми нами любимый PHP, засравший своё глобальное пространство 100500 сигнатурами функций типа str_replace, str_ireplace, preg_replace, ereg_replace, etc. И за это — сюрприз — многие его и не любят.
Во-вторых, как вконтактовский код легко попадает на чужие сайты (начиная с кнопки «Like»), так и чужой код может легко попасть на страницы вконтакта (если завтра вконтакт разрешит виджеты или html5-баннеры компаниям-партнерам). И вот у ВК начнутся некислые проблемы.
Ну и, в-третьих, когда они таки решат побороться со своим глобальным зоопаркам, им придётся потратить пару человеко-месяцев на приведение всего это трэша в нормальное состояние.
В общем-то, они не первые на эти грабли наступают, не они и последние. Пару лет назад на Картахmail.ru был точно такой же трэш и угар в window. Можно спросить местных мэйлрушников, во что им встало причесать код.
если завтра вконтакт разрешит виджеты или html5-баннерыПолагаю, в таком случае, они воспользуются iframe-ми. Мало ли чего там партнёр нагородит в своём баннере.
Антитезисы вашим тезисам:
1. Код вконтакте используется только на вконтакте и больше нигде.
2. Код не попадает на чужие сайты. Там iframe и его пространство имён никак не пересекается с основным. Интеграция кода, о чём вы сказали в смежном коменте никак не пересекается с тем, что у них на сайте.
3. Назовите причину зачем им это делать, если и так всё прекрасно работает?
4. mailru !== vk ни по скорости, ни корректности работы
пс. я не защищаю их, просто не понимаю зачем искать плохое в том, что хорошо работает? Ведь лучшее — враг хорошего. Я думаю, что там не глупые люди сидят и согласовывают свои действия, есть один основной ответственный за код, который решает что можно убрать. В больших софтверных компаниях именно так поступают.
1. Код вконтакте используется только на вконтакте и больше нигде.
2. Код не попадает на чужие сайты. Там iframe и его пространство имён никак не пересекается с основным. Интеграция кода, о чём вы сказали в смежном коменте никак не пересекается с тем, что у них на сайте.
3. Назовите причину зачем им это делать, если и так всё прекрасно работает?
4. mailru !== vk ни по скорости, ни корректности работы
пс. я не защищаю их, просто не понимаю зачем искать плохое в том, что хорошо работает? Ведь лучшее — враг хорошего. Я думаю, что там не глупые люди сидят и согласовывают свои действия, есть один основной ответственный за код, который решает что можно убрать. В больших софтверных компаниях именно так поступают.
Я что-то не увидел антитезисов.
1. Я писал о том, что разработчик (вконтакте) не может полностью контролировать свой участок работы, поскольку все переменные и функции свалены без разбору в глобальный неймспейс (и, вероятно, недокументированы). Из этого следует, что ни одной из этих функций/переменных пользоваться нельзя (непонятно, кто её заводил, кто за неё отвечает, в какой момент она может исчезнуть/измениться). Код в итоге несегментирован и потенциально багоопасен.
Не понял, каким образом то, что код вконтакте используется только вконтакте, является антитезисом.
2. Код попадает на чужие сайты в виде js-скрипта, который уже создаёт ифрейм. Во-первых, скрипт загрузчика не может реюзать ничего из кода ВК (из-за херовой тонны глобальных переменных), во-вторых, ВК создаёт себе кучу проблем на ровном месте с этими фреймами (большинство АПИ как-то и без фреймов обходится, см. любое картографическое).
Чужой же код может появиться на сайте ВК тоже легко, если ВК решит купить какой-нибудь стартап и внедрить его у себя — интегрировать сторонний код в портянку глобальных функций будет ой как сложно.
3. Затем, что, рано или поздно, у них появится внутреннее (а, со временем, и внешнее) АПИ. И им придётся причесать код, иначе у них будут геометрически прогрессировать проблемы с внедрением новых разделов и фич, а также со встраиванием себя на сторонние и партнерские сайты.
4. Я, вроде бы, не говорил, что мэйлру == вк. Я просто написал, что многие компании наступили на те же грабли и переписывали свой js-код в нормальный вид. Карты.мэйл.ру, например, полагаю, именно по этой причине не выпустили до сих пор АПИ. У Овимапса, например, то же самое было — килограмм говна в глобальной области, который им пришлось переработать при выпуске АПИ.
1. Я писал о том, что разработчик (вконтакте) не может полностью контролировать свой участок работы, поскольку все переменные и функции свалены без разбору в глобальный неймспейс (и, вероятно, недокументированы). Из этого следует, что ни одной из этих функций/переменных пользоваться нельзя (непонятно, кто её заводил, кто за неё отвечает, в какой момент она может исчезнуть/измениться). Код в итоге несегментирован и потенциально багоопасен.
Не понял, каким образом то, что код вконтакте используется только вконтакте, является антитезисом.
2. Код попадает на чужие сайты в виде js-скрипта, который уже создаёт ифрейм. Во-первых, скрипт загрузчика не может реюзать ничего из кода ВК (из-за херовой тонны глобальных переменных), во-вторых, ВК создаёт себе кучу проблем на ровном месте с этими фреймами (большинство АПИ как-то и без фреймов обходится, см. любое картографическое).
Чужой же код может появиться на сайте ВК тоже легко, если ВК решит купить какой-нибудь стартап и внедрить его у себя — интегрировать сторонний код в портянку глобальных функций будет ой как сложно.
3. Затем, что, рано или поздно, у них появится внутреннее (а, со временем, и внешнее) АПИ. И им придётся причесать код, иначе у них будут геометрически прогрессировать проблемы с внедрением новых разделов и фич, а также со встраиванием себя на сторонние и партнерские сайты.
4. Я, вроде бы, не говорил, что мэйлру == вк. Я просто написал, что многие компании наступили на те же грабли и переписывали свой js-код в нормальный вид. Карты.мэйл.ру, например, полагаю, именно по этой причине не выпустили до сих пор АПИ. У Овимапса, например, то же самое было — килограмм говна в глобальной области, который им пришлось переработать при выпуске АПИ.
Пункты понятны. Непонятно почему группа Вконтакте поступает иначе.
Давайте я тогда попробую. Это будет достаточно имхо, но всё-таки)
1) Я искренне подозреваю, что группы, разрабатывающие разные модули сайта, всё-таки согласовывают действия, и глобалка не засоряется просто так, а засоряется по какому-то плану) К тому же, вряд ли разработчик какого-нибудь видеоплеера, увидев неизвестную ему глобальную переменную, станет её использовать, не выяснив, что это за переменная, где объявлена, какие будут проблемы при использовани. Хотя бы из соображений здравого смысла)
2) В ифреймы они могут отдавать код без этих строк с переводом. Поэтому код загрузчика, я думаю, вполне себе может реюзать код вк.
3) В принципе, в коде вк весьма заметно, что такой срач глобальных переменных там происходит только для строк с переводом. В остальном всё весьма структурировано))
4) А вот насчёт мейла ничего не скажу — вк одна компания, мейл другая, условия у них разные)
1) Я искренне подозреваю, что группы, разрабатывающие разные модули сайта, всё-таки согласовывают действия, и глобалка не засоряется просто так, а засоряется по какому-то плану) К тому же, вряд ли разработчик какого-нибудь видеоплеера, увидев неизвестную ему глобальную переменную, станет её использовать, не выяснив, что это за переменная, где объявлена, какие будут проблемы при использовани. Хотя бы из соображений здравого смысла)
2) В ифреймы они могут отдавать код без этих строк с переводом. Поэтому код загрузчика, я думаю, вполне себе может реюзать код вк.
3) В принципе, в коде вк весьма заметно, что такой срач глобальных переменных там происходит только для строк с переводом. В остальном всё весьма структурировано))
4) А вот насчёт мейла ничего не скажу — вк одна компания, мейл другая, условия у них разные)
> Вчера разработчик ленты добавил в window строку «all» — всё, сегодня разработчик какого-нибудь видео радостно её заюзал, завтра разработчик ленты решил, что эта строка ему больше не нужна и грохнул её. Нет разделения по namespace-ам — нет ответственности.
Постойте, вы что, предлагаете для каждого модуля делать свои локализованные лейблы и везде их дублировать? O.o
А как это потом переводить, чтобы это все было в одном стиле?
Если проект разрабатывается и локализуется в одном месте, то как раз логично делать (и везде вроде и так делают) глобальную локализацию.
А если локализация глобальная, то почему бы ей не хранится в глобальных переменных?
Постойте, вы что, предлагаете для каждого модуля делать свои локализованные лейблы и везде их дублировать? O.o
А как это потом переводить, чтобы это все было в одном стиле?
Если проект разрабатывается и локализуется в одном месте, то как раз логично делать (и везде вроде и так делают) глобальную локализацию.
А если локализация глобальная, то почему бы ей не хранится в глобальных переменных?
Постойте, вы что, предлагаете для каждого модуля делать свои локализованные лейблы и везде их дублировать? O.o
А в вашем проекте что, не так? о_О
> А в вашем проекте что, не так?
Конечно. И почти во всех проектах, что я видел локализация хранится в одном месте.
Интерфейс для юзера ведь глобальный, а с вашим подходом вы получите в одном модуле кнопку «отправить», в другом модуле будет кнопка «готово», в другом «отправка» итд. При том, что все эти кнопки делают одну функцию и должны называться одинаково по всему сайту.
Вообще программер даже не должен выбирать как что называется, это делает специалист по юзабилити, разработчик интерфейса, переводчик, а программер просто использует готовую глобальную переменную и соответственно как-то изменить или испортить ее он не может.
Конечно. И почти во всех проектах, что я видел локализация хранится в одном месте.
Интерфейс для юзера ведь глобальный, а с вашим подходом вы получите в одном модуле кнопку «отправить», в другом модуле будет кнопка «готово», в другом «отправка» итд. При том, что все эти кнопки делают одну функцию и должны называться одинаково по всему сайту.
Вообще программер даже не должен выбирать как что называется, это делает специалист по юзабилити, разработчик интерфейса, переводчик, а программер просто использует готовую глобальную переменную и соответственно как-то изменить или испортить ее он не может.
Если надпись на кнопке ДОЛЖНА быть одинакова для всех разделов сайта — то можно для таких строк выделить отдельный неймспейс, типа locale.common.
Если же так случилось, что два раздела сайта случайно используют одну и ту же фразу — это не повод шарить один ключ; завтра один из разделов захочет написать там другую фразу.
Если же так случилось, что два раздела сайта случайно используют одну и ту же фразу — это не повод шарить один ключ; завтра один из разделов захочет написать там другую фразу.
>Если надпись на кнопке ДОЛЖНА быть одинакова для всех разделов сайта — то можно для таких строк выделить отдельный неймспейс, типа locale.common.
Ну да, должна, все элементы интерфейса с одинаковыми функциями должны называться одинаково, вроде бы очевидно.
А зачем делать отдельный неймспейс для глобального контекста? Глобальный неймспейс уже и так есть.
>Если же так случилось, что два раздела сайта случайно используют одну и ту же фразу — это не повод шарить один ключ; завтра один из разделов захочет написать там другую фразу.
«Случайно» одну фразу они использовать не могут. Все фразы и надписи для сайта разрабатываются в одном месте для единого стиля интерфейса.
Если в одном из разделов поменяется фраза, то они используют новый ключ конечно же. И этот ключ не разработчик этого раздела придумает, а ему дадут ключ нового лейбла, который будет согласован со всем остальным сайтом.
Разработчик не должен заниматься придумыванием интерфейса для своего модуля, иначе получится не сайт, а сборная солянка.
Ну да, должна, все элементы интерфейса с одинаковыми функциями должны называться одинаково, вроде бы очевидно.
А зачем делать отдельный неймспейс для глобального контекста? Глобальный неймспейс уже и так есть.
>Если же так случилось, что два раздела сайта случайно используют одну и ту же фразу — это не повод шарить один ключ; завтра один из разделов захочет написать там другую фразу.
«Случайно» одну фразу они использовать не могут. Все фразы и надписи для сайта разрабатываются в одном месте для единого стиля интерфейса.
Если в одном из разделов поменяется фраза, то они используют новый ключ конечно же. И этот ключ не разработчик этого раздела придумает, а ему дадут ключ нового лейбла, который будет согласован со всем остальным сайтом.
Разработчик не должен заниматься придумыванием интерфейса для своего модуля, иначе получится не сайт, а сборная солянка.
И как написал в другом комментарии, почему я думаю они не делают отдельный неймспейс для лейблов – в интерфейсе везде идет работа с лейблами, а добавления неймспейса будет увеличивать размер кода, если его не обфусцировать конечно.
Уважаемый, а кто Вам сказал, что они там сидят и руками пишут
window.my_cool_var = «bla-bla-bla...»?
Вы слышали что-нибудь про средства контроля и генерации javascript кода, коих сейчас есть масса самых разных?
И самое главное, нельзя переносить подходы, привычные для своей домашний странички, на сайты с 40 млн посетителей в день. Они там могут работать с точностью до наоборот. Это я могу сказать, как человек, чей код крутился одно время на Рамблере, как раз в составе одной партнерки.
А в общем, насчет пагубности зоопарка глобалсов я полностью согласен. Просто это не должно быть догмой или каргокультом.
window.my_cool_var = «bla-bla-bla...»?
Вы слышали что-нибудь про средства контроля и генерации javascript кода, коих сейчас есть масса самых разных?
И самое главное, нельзя переносить подходы, привычные для своей домашний странички, на сайты с 40 млн посетителей в день. Они там могут работать с точностью до наоборот. Это я могу сказать, как человек, чей код крутился одно время на Рамблере, как раз в составе одной партнерки.
А в общем, насчет пагубности зоопарка глобалсов я полностью согласен. Просто это не должно быть догмой или каргокультом.
Вспомнилась цитата.
Subvert the paradigm ©
Subvert the paradigm ©
Приключение Алисы в Стране чудес.
Окей, давайте вкратце:
Все объекты это хэши, сложность алгоритма по нахождению элемента O(1), т.е. неважно сколько у нас элементов там находится.
Функции к которым явно не задан контекст получат window в качестве this, а это значит что не будет происходить перебор скопов и не будет на это оверхэда.
Хранить так переменные «обычно» вредно из-за невозможности гарантировать что другой код не вызовет конфликт с вашим. Перед такими смелыми дейсвтиями нужно согласовать все «за» и «против» со всей коммандой.
Варианты как такое произошло:
Реально договорились со всеми.
Утекло.
В каком-то месте автоматически разруливаются все занятые ключи в глобальном скопе на этапе сборки.
Так сложилось исторически.
Никто не подумал о конфликтах.
Есть специальный человек у которого все спрашивают: «А можно я вот эту переменную займу?».
Есть специальная база данных (может просто страничка wiki), где все дружно проверяют какие переменные заняты, а какие можно занять.
Имхо не от великого ума такое решение пришло.
Окей, давайте вкратце:
Все объекты это хэши, сложность алгоритма по нахождению элемента O(1), т.е. неважно сколько у нас элементов там находится.
Функции к которым явно не задан контекст получат window в качестве this, а это значит что не будет происходить перебор скопов и не будет на это оверхэда.
Хранить так переменные «обычно» вредно из-за невозможности гарантировать что другой код не вызовет конфликт с вашим. Перед такими смелыми дейсвтиями нужно согласовать все «за» и «против» со всей коммандой.
Варианты как такое произошло:
Реально договорились со всеми.
Утекло.
В каком-то месте автоматически разруливаются все занятые ключи в глобальном скопе на этапе сборки.
Так сложилось исторически.
Никто не подумал о конфликтах.
Есть специальный человек у которого все спрашивают: «А можно я вот эту переменную займу?».
Есть специальная база данных (может просто страничка wiki), где все дружно проверяют какие переменные заняты, а какие можно занять.
Имхо не от великого ума такое решение пришло.
Сложность выборки в худшем случае O(n) все же.
Не на столько там всё плохо.
Ой да ладно, вы предполагаете, что коллизия по хэшу произойдёт n раз от всех элементов на фиксированном списке ключей? В данном случае данные даже не могут быть «плохими». Они всегда одинаковые и сложность предсказуема.
> Хранить так переменные «обычно» вредно из-за невозможности гарантировать что другой код не вызовет конфликт с вашим.
Вы забываете, что там хранятся не просто переменные, а локализованные лейблы для интерфейса.
Они по определению должны быть глобальными, чтобы
1. Не было избыточности
2. Чтобы они были в одном стиле, иначе в разных модулях одинаковые по смыслу кнопки будут названы по-разному (а при переводе это все усугубится).
Так вот, если у нас глобальные лейблы, то чем плохо хранить их в глобальном неймспейсе?
Вы забываете, что там хранятся не просто переменные, а локализованные лейблы для интерфейса.
Они по определению должны быть глобальными, чтобы
1. Не было избыточности
2. Чтобы они были в одном стиле, иначе в разных модулях одинаковые по смыслу кнопки будут названы по-разному (а при переводе это все усугубится).
Так вот, если у нас глобальные лейблы, то чем плохо хранить их в глобальном неймспейсе?
У нас в руках прекрасный язык с замыканиями. все эти переменные можно было замкнуть в функции gettext, которую сделать глобальной, например:
Это такое традиционное решение, что странно видеть другую реализацию.
var gettext = (function(){
var i18n = {
mynameis: 'Моё имя ",
gender: "Пол",
...
};
return function ( text ) {
return i18n[ text ];
}
})();
Это такое традиционное решение, что странно видеть другую реализацию.
Это понятно, что можно было в глобальный массив завернуть, в функцию или в объект.
Это скорее дело вкуса, в принципе от этого ничего не поменяется – все равно будет хранится в глобальном неймспейсе и если они там кроме лейблов ничего не хранят, то для них в принципе нет разницы, через обычные переменные делать или через функцию.
И это для уменьшения размера кода имеет значение, они же обфускацией не занимаются, а написать просто переменную будет короче, чем вызов функции. А учитывая, что лейблы используются во всем интерфейсе, экономия может быть значительной.
Это скорее дело вкуса, в принципе от этого ничего не поменяется – все равно будет хранится в глобальном неймспейсе и если они там кроме лейблов ничего не хранят, то для них в принципе нет разницы, через обычные переменные делать или через функцию.
И это для уменьшения размера кода имеет значение, они же обфускацией не занимаются, а написать просто переменную будет короче, чем вызов функции. А учитывая, что лейблы используются во всем интерфейсе, экономия может быть значительной.
Еще дополню, глобальная функция может быть традиционным решение, потому что переменные проще переопределить, чем функцию. Но если разработчик не занимается созданием глобальных лейблов для интерфейса (а он не должен), то такой проблемы в принципе не стоит.
А на функцию кроме размера кода для ее вызова также тратиться и оверхэд по самому вызову.
А на функцию кроме размера кода для ее вызова также тратиться и оверхэд по самому вызову.
Я конечно жуткий дилетант, но все-таки спрошу (не пинайте сильно).
Может быть это как-то связанно с тем, что при переходе с одной странички на другую не прерывается проигрываемая музыка? Может быть страницы каким-то хитрым образом скриптами собираются?
Может быть это как-то связанно с тем, что при переходе с одной странички на другую не прерывается проигрываемая музыка? Может быть страницы каким-то хитрым образом скриптами собираются?
А вы спросите у группы поддержки ВК, они всем отвечают. Могут даже у программистов напрямую спросить :)
js кешируется — значит так нужно. Вохможно данное решение является средством борьбы с излишней нагрузкой на весь VK.
я рылся в их клиентском коде, и что я могу скзаать — хоть интерфейс достаточно вылизан и его поведение тоже, но качество кода клиентского — отстой лютый. можете не попеременным посмотреть а по не обфусцированным файлам (они не обфусцируют их).
Ты, видимо, ещё гугл-календарь не видел
Есть два типа программистов — те, кто пишут для охрененно крупных проектов охрененно рабочие вещи, и те, кто хвалится ультра-агиле-юниттестовым-красивым кодом который пишется для проектов или своих или которые никто не знает. Почему так происходит — хз, но на практике почему-то всегда так.
Знали бы вы как система Укртелекома написана или Киевстара внутренняя…
Это феномен из серии «почему все, кто точно знают как управлять государством уже работают таксистами или парикмахерами». Да, я знаю что получу за высказывание этого мнения на Хабре. Нашел блин место :)
Знали бы вы как система Укртелекома написана или Киевстара внутренняя…
Это феномен из серии «почему все, кто точно знают как управлять государством уже работают таксистами или парикмахерами». Да, я знаю что получу за высказывание этого мнения на Хабре. Нашел блин место :)
Поддержу, сперва приложение должно работать, а лишь затем красиво выглядеть.
ок, а как вы отнесетесь к тому, что там например для сообщений для каждого виджета — своя отдельная модель, и когда отправляешь в одном виджете в другом не появляется просто потому что модель данных разная? и таких примеров там много. да в первую очередь должно работать, но все же такие мелочи очень бесят, или всякие зависшие счетчики или подобное, и это всё просто потому что нету структуры.
а так всегда да в первую очередь должно быть programming-motherfucker.com/
а так всегда да в первую очередь должно быть programming-motherfucker.com/
Теперь все понятно, пойдем говнокодить, а потом искать людей с «умением разбираться в чужом коде» — тогда проект точно станет успешным!
Пипец тезис. Если в вашей компании нету людей, которые пишут нормальный код и создают нормальную архитектуру, за приемлемые сроки, это ваши проблемы. Не надо экстраполировавть. Я лично знаю людей, которые делают нормальные вещи в больших проектах.
Пипец тезис. Если в вашей компании нету людей, которые пишут нормальный код и создают нормальную архитектуру, за приемлемые сроки, это ваши проблемы. Не надо экстраполировавть. Я лично знаю людей, которые делают нормальные вещи в больших проектах.
А вы напишите статью «Охрененно рабочая вещь!» и начните её вот с этой простыни, что в топике.
Определённые недостатки проекта его не убивают, но и недостатками они от этого быть не перестают.
Вы наверное не хотели дать положительную оценку 1000+ глобальных функций и переменных, которые мы там видим? Не стоит так делать, вроде бы все с этим согласны. А если стоит – расскажите нам почему, я, например, с интересом послушаю.
То, что программист пишет для охрененно крупных проектов на самом деле говорит об этом программисте очень мало. Так что и делить их по принципу величины проектов – на мой взгляд, дело довольно бессмысленное.
Определённые недостатки проекта его не убивают, но и недостатками они от этого быть не перестают.
Вы наверное не хотели дать положительную оценку 1000+ глобальных функций и переменных, которые мы там видим? Не стоит так делать, вроде бы все с этим согласны. А если стоит – расскажите нам почему, я, например, с интересом послушаю.
То, что программист пишет для охрененно крупных проектов на самом деле говорит об этом программисте очень мало. Так что и делить их по принципу величины проектов – на мой взгляд, дело довольно бессмысленное.
Рейтинг этого коммента полностью описывает аудиторию хабра — толпа говнокодеров, которая тешит своё самолюбие мантрой «а зато наш код работает на реальных проектах».
Очень печально, что это так. Давайте, минусуйте.
Очень печально, что это так. Давайте, минусуйте.
Красиво быть должно. Но красота не должна быть на первом месте.
Разрыв шаблона, наверное, будет у автора примерно вот такого кода в команде Вконтакта:
Экстраполируем это на 1К+ вариантов названий функций.
var captcha_send = function(){
...
_some_handler.html( captcha_send );
}
captcha_send();
Экстраполируем это на 1К+ вариантов названий функций.
Переменные, как уже заметили выше, создаются в файле локализации (без конструкции var).
Да и к тому же, у них там практически всё в window.* пишется и к нему же обращается)
Поиск строк вообще ищется в разных местах:
А зачем? События у них все в onclick, onmouseover, onmouseout и т.д. Элементы получают через ge(el), создают через ce(tagName, attr, style), удаляют через re(el) (getElement/createElement/removeElement) :)
Да и к тому же, у них там практически всё в window.* пишется и к нему же обращается)
Поиск строк вообще ищется в разных местах:
function getLang() {
try {
var args = Array.prototype.slice.call(arguments);
var key = args.shift();
if (!key) return '...';
var val = (window.cur.lang && window.cur.lang[key]) || (window.lang && window.lang[key]) || (window.langpack && window.langpack[key]) || window[key];
if (!val) {
var res = key.split('_');
res.shift();
return res.join(' ');
}
if (isFunction(val)) {
return val.apply(null, args);
} else if (args[0] !== undefined || isArray(val)) {
return langNumeric(args[0], val, args[1]);
} else {
return val;
}
} catch(e) {
debugLog('lang error:' + e.message + '(' + Array.prototype.slice.call(arguments).join(', ') + ')');
}
}
Сначала я удивился отсутствию jquery.
А зачем? События у них все в onclick, onmouseover, onmouseout и т.д. Элементы получают через ge(el), создают через ce(tagName, attr, style), удаляют через re(el) (getElement/createElement/removeElement) :)
Я что-то не пойму, из-за чего весь сыр-бор.
Проект работает? Работает.
Заказчик доволен? Очевидно, щастлив.
Тогда в чем вопрос? Красоту кода оценит только тот, кто с кодом будет работать.
Пусть тем, кому этот код поддерживать, за голову хватаются. Все остальное сводится к поговорке «If you're so clever, show me your money».
Проект работает? Работает.
Заказчик доволен? Очевидно, щастлив.
Тогда в чем вопрос? Красоту кода оценит только тот, кто с кодом будет работать.
Пусть тем, кому этот код поддерживать, за голову хватаются. Все остальное сводится к поговорке «If you're so clever, show me your money».
«Пишите код так, как будто поддерживать его будет психический больной маньяк, который знает где вы живёте»
Когда код мой или мне его поддерживать — я с Макконнеллом только соглашусь.
Весь сыр-бор из-за того, что хочется быть психом-маньяком, да адреса не знаешь…
Ну я не рвусь работать в команде ВК, и мое самолюбие не задето от того, что проект с кривым кодом на фронтенде (о ужас) оказался успешен. ЧЯДНТ? :)
ЧЯДНТ?
Неправильно понимаете суть «сыр-бора». Да дело не в самом ВК, а в отношении людей к говнокоду.
Вы почитайте комментарии — люди готовы наплевать на всё ради «успешности проекта».
Самое печальное, что проблемы в коде, к которым уже привыкли, многие перестают считать проблемами, а новички на проекте вообще считают это правильным шаблоном проектирования. Так и рождается «энтерпрайз».
И я считаю что любой специалист, который видит проблему, должен обращать на неё внимание, иначе этот снежный ком будет расти и дальше. И если кто-то указал на проблему, нужно не оправдываться, а просто принять во внимание, а если не согласны, попросить рассказать в чем проблема и как её избежать.
Это банальный профессиональный этикет.
Вы почитайте комментарии — люди готовы наплевать на всё ради «успешности проекта».
Успешный проект и идеальный код — вещи ортогональные. Разница лишь в том, что за успешный проект платят, а за идеальный код — не факт.
И я считаю что любой специалист, который видит проблему, должен обращать на неё внимание, иначе этот снежный ком будет расти и дальше.
Снежный ком будет расти с падением порога вхождения в профессию. Это системная проблема веб-программирования.
А размахивать кулаками в отсутствие оппонента — тут никаким этикетом и не пахнет, не льстите себе.
Успешный проект и идеальный код — вещи ортогональные. Разница лишь в том, что за успешный проект платят, а за идеальный код — не факт.
И я считаю что любой специалист, который видит проблему, должен обращать на неё внимание, иначе этот снежный ком будет расти и дальше.
Снежный ком будет расти с падением порога вхождения в профессию. Это системная проблема веб-программирования.
А размахивать кулаками в отсутствие оппонента — тут никаким этикетом и не пахнет, не льстите себе.
Успешный проект и идеальный код — вещи ортогональные. Разница лишь в том, что за успешный проект платят, а за идеальный код — не факт.
Вклад в качество кода оправдывается сроком его поддержки. Если «сдал и забыл», то пожалуйста, если требуется поддержка и развитие втечении многих лет, вклад в качество кода оправдывает себя всегда.
И да, я был некорректен, когда не уточнил вопрос о поддержке кода.
Вопрос связан с потерей контроля над кодом и если проект маленький, возможно вам и не удасться его потерять при самых плохих обстоятельствах.
А размахивать кулаками в отсутствие оппонента — тут никаким этикетом и не пахнет, не льстите себе.
Ну как же?! Тут много оппонентов, и от разработки ВК во многих тредах уже ушли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Странные глобальные переменные в VK.com, зачем?