еще опыт важен. nepster09 пишет, что в данном случае первый раз в жизни рисовал линии на канвасе через ангуляр. это обучение в чистом виде, а не производство. тут оценки будут состоятельны, разве что в дневнике. а так, сколько не оценивай, надо умножать на 3.1415. ну т.е. если б довелось решать задачу повторно, он бы наверняка уложился в рассчитанную оценку. ведь так?)
автор — дизайнер, а не программист. у них иная специфика. борьба идет со «сделать как лучше», а не «чтобы хоть как-то заработало». они могут остановиться в любой момент, продать пустое место как креатив, и т.п… отсюда time-boxing, да, рулит. :)
Например, роботу дается для анализа много страниц сервисов Яндекса, и он понимает, что на них на всех снизу есть ссылка «О компании»
…
/html/body/div/table/tbody/tr/td/div/ul/li/span/a вместо
верстка однотипных блоков может быть различной на разных сервисах (<a>О компании</a>, <b>О компании</b>) — её делали разные люди, в разное время, используя разные фреймворки. или просто один и тот же блок находится в разных состояниях (ссылка на текущую страницу — не ссылка). как вы это учитываете?
совпадения по именам функций это совсем не повод так делать. вносить расширения в прототипы — задача специализированных полифилов, которые обязаны до мелочей следовать стандартам.
поведение отдельных функций в библиотеке может в каких-то деталях отличаться от одноименных методов стандартных объектов (не со зла, конечно, а для общего блага — ленивость, расширенный интерфейс, и т.п.).и покуда библиотека не лезет в прототипы, это вполне допустимо.
в документации почему-то про это не пишут — функции _.max() и _.min(), что в underscore, что в lodash понимают только числа, а не вообще. т.е. их нельзя использовать, например, чтобы найти в коллекции максимальную строку — получается ерунда. все потому, что. авторы underscore пытаются изобразить конкретно Math.min, и Math.max, а авторы lodash изображают underscore.
мне показалось, что они пытаются что-то защитить таким образом. но вряд-ли дело в двух разбитых «ап стену» машинах на скорости 180 км/ч.
очень похоже, что штуки предназначены для дополнительной защиты этих самых сменных аккумуляторов, либо систем их крепления, от всяческого дорожного мусора, воды и грязи, которые им могут вредить и сокращать срок службы. по всей видимости, это недешевые штуки, которые на «заправках» они меняют за так. следовательно, должны быть заинтересованы, чтобы аккумуляторы служили как можно более вечно. вот и предлагают как бесплатный апгрейд всем, а не улучшательный допник для параноиков.
для nss/getnssent_r.c анализатор написал ерунду, и у вас код отквочен не правильно:
смотрим
127 int
128 __nss_getent_r (const char *getent_func_name,
129 const char *setent_func_name,
130 db_lookup_function lookup_fct,
131 service_user **nip, service_user **startp,
132 service_user **last_nip, int *stayopen_tmp, int res,
133 void *resbuf, char *buffer, size_t buflen,
134 void **result, int *h_errnop)
....
144 if (res && __res_maybe_init (&_res, 0) == -1)
145 {
146 *h_errnop = NETDB_INTERNAL;
147 *result = NULL;
148 return errno;
149 }
150
...
159 while (! no_more)
160 {
161 int is_last_nip = *nip == *last_nip;
162
163 status = DL_CALL_FCT (fct.f,
164 (resbuf, buffer, buflen, &errno, &h_errno));
165
166 /* The status is NSS_STATUS_TRYAGAIN and errno is ERANGE the
167 provided buffer is too small. In this case we should give
168 the user the possibility to enlarge the buffer and we should
169 not simply go on with the next service (even if the TRYAGAIN
170 action tells us so). */
171 if (status == NSS_STATUS_TRYAGAIN
172 && (h_errnop == NULL || *h_errnop == NETDB_INTERNAL)
173 && errno == ERANGE)
174 break;
тут видно, что в первом случае (145) присваивается значение, в указатель, пришедший в функцию в качестве параметра. он не может быть NULL по соглашению. в 163 этот указатель передается по ссылке функции DL_CALL_FCT, и в 172 проверяется уже новое значение, возвращаемое этой функцией.
sunrpc/clnt_raw.c это пропиетарное наследие от уже вымерших мамонтов. по умолчанию не компилируется. тут анализатор занимается археологией — в самом деле, поучительно.
2012-05-10 Andreas Jaeger Make sunrpc code usable again
2011-04-17 Ulrich Drepper Obsolete RPC implementation in libc.
2010-08-19 Ulrich Drepper Once again change RPC copyright notices.
2010-06-28 Ulrich Drepper Revert «Sun agreed to a change of the license for the…
2009-05-21 Ulrich Drepper Sun agreed to a change of the license for the RPC code…
…
1995-02-18 Roland McGrath initial import
кстати, в текущей ревизии в копирайтах значится Oracle.
в коде все четко и однозначно. сей кусок для людей предназначен, а не анализаторов — опенсорс же. ну да, в статье это представлено в духе «скандалы-интриги-расследования», видимо чтобы читать веселее было. :)
ок) вы ведь уже объяснили зачем это было нужно «картам», и почему появился YM. вы классные (мм, история enb vs bem make вообще эпична). ни кто не сомневается, что ради правильной цели, у вашей команды вместе с Яндексом, хватит ресурсов и на то, чтобы переписать пол гитхаба как вам захочется, если вдруг. я серьезно.
тут уже несколько раз объясняли, что нарушение абстракции это таскать лоадер в зависимостях модуля, т.к. система загрузки модулей должна абстрагировать код от этого. нарушение абстракции это смешивание логики загрузки кода, конструирования и разруливания порядка инстанцирования объектов в одну кучу. но, как оказывается, в некоторых случаях из подобных фокусов можно извлечь определенную практическую пользу. за что еще раз вам респект.
а 'promise!anyName', это не два отдельных слова, а «такое-вот-имя-модуля-целиком» — синтаксический компромисс в именовании, благодаря которому модули могут резовлить реализацию разными способами. «tpl!name», «ym!name» и т.п. главное, что результат для клиента не отличим. так что тут как раз все правильно.
вообще. на мой взгляд, основная ценность систем подобного уровня не в наличии какой-либо «клиллер-фичи», а в возможности интеграции как можно большего количества различных решений между собой наименьшей кровью. поэтому, в целом, соглашения рулят.
вы несомненно молодцы, что сумели стандартизировать этот момент внутри Яндекса. CommonJS/AMD решают схожую задачу, но не в масштабах отдельной компании, а для всего мира. это на порядок сложнее, отсюда больше компромиссов. зря вы ставите в один ранг с CommonJS и AMD, противопоставляя YM — это лишь сбивает с толку и провоцирует бесполезный флейм.
вероятность встретить за пределами яндексных инкубаторов, на открытом воздухе, код, завернутый в YM, такая же как увидеть в лесу динозавра. и год тому назад, когда он заопенсорсился, и сейчас. как только я перестал заниматься околояндексной разработкой, в коде не осталось практически ни чего из этого великолепия. потому, что во всем остальном мире — другие соглашения. за пределами Яндекса YM — лишь элегантное решение частной задачи, коих тысячи. как видите есть альтернативы.
CommonJS и AMD это общепринятые вещи — в смысле использования в проектах, рецептов и инструментов для комбинирования с другими технологиями, поддержки, документации. YM как еще один стандарт — не нужен (имхо). в этом смысле, было бы гораздо полезнее, если бы вы делились с сообществом своими революционными идеями, не в виде альтернатив (это лишь все усложняет), а коммитами в общепринятые технологии.
верстка однотипных блоков может быть различной на разных сервисах (
<a>О компании</a>,<b>О компании</b>) — её делали разные люди, в разное время, используя разные фреймворки. или просто один и тот же блок находится в разных состояниях (ссылка на текущую страницу — не ссылка). как вы это учитываете?отлично сказано! можно я это где-то запишу и буду цитировать?
из документации не очевидно, почему именно такой результат. тем не менее, разработчики underscore считают это поведение правильным.
в трекере мне предложили вот такой вариант для нахождения максимальной строки:
А, собственно, что Вы предлагаете, пока не понятно.
поведение отдельных функций в библиотеке может в каких-то деталях отличаться от одноименных методов стандартных объектов (не со зла, конечно, а для общего блага — ленивость, расширенный интерфейс, и т.п.).и покуда библиотека не лезет в прототипы, это вполне допустимо.
очень похоже, что штуки предназначены для дополнительной защиты этих самых сменных аккумуляторов, либо систем их крепления, от всяческого дорожного мусора, воды и грязи, которые им могут вредить и сокращать срок службы. по всей видимости, это недешевые штуки, которые на «заправках» они меняют за так. следовательно, должны быть заинтересованы, чтобы аккумуляторы служили как можно более вечно. вот и предлагают как бесплатный апгрейд всем, а не улучшательный допник для параноиков.
тут видно, что в первом случае (145) присваивается значение, в указатель, пришедший в функцию в качестве параметра. он не может быть NULL по соглашению. в 163 этот указатель передается по ссылке функции DL_CALL_FCT, и в 172 проверяется уже новое значение, возвращаемое этой функцией.
там история коммитов выглядит интереснее, чем сам код:
кстати, в текущей ревизии в копирайтах значится Oracle.
тут уже несколько раз объясняли, что нарушение абстракции это таскать лоадер в зависимостях модуля, т.к. система загрузки модулей должна абстрагировать код от этого. нарушение абстракции это смешивание логики загрузки кода, конструирования и разруливания порядка инстанцирования объектов в одну кучу. но, как оказывается, в некоторых случаях из подобных фокусов можно извлечь определенную практическую пользу. за что еще раз вам респект.
а 'promise!anyName', это не два отдельных слова, а «такое-вот-имя-модуля-целиком» — синтаксический компромисс в именовании, благодаря которому модули могут резовлить реализацию разными способами. «tpl!name», «ym!name» и т.п. главное, что результат для клиента не отличим. так что тут как раз все правильно.
вообще. на мой взгляд, основная ценность систем подобного уровня не в наличии какой-либо «клиллер-фичи», а в возможности интеграции как можно большего количества различных решений между собой наименьшей кровью. поэтому, в целом, соглашения рулят.
вы несомненно молодцы, что сумели стандартизировать этот момент внутри Яндекса. CommonJS/AMD решают схожую задачу, но не в масштабах отдельной компании, а для всего мира. это на порядок сложнее, отсюда больше компромиссов. зря вы ставите в один ранг с CommonJS и AMD, противопоставляя YM — это лишь сбивает с толку и провоцирует бесполезный флейм.
вероятность встретить за пределами яндексных инкубаторов, на открытом воздухе, код, завернутый в YM, такая же как увидеть в лесу динозавра. и год тому назад, когда он заопенсорсился, и сейчас. как только я перестал заниматься околояндексной разработкой, в коде не осталось практически ни чего из этого великолепия. потому, что во всем остальном мире — другие соглашения. за пределами Яндекса YM — лишь элегантное решение частной задачи, коих тысячи. как видите есть альтернативы.
CommonJS и AMD это общепринятые вещи — в смысле использования в проектах, рецептов и инструментов для комбинирования с другими технологиями, поддержки, документации. YM как еще один стандарт — не нужен (имхо). в этом смысле, было бы гораздо полезнее, если бы вы делились с сообществом своими революционными идеями, не в виде альтернатив (это лишь все усложняет), а коммитами в общепринятые технологии.