Чтобы понять, какой именно вариант работает в каждом конкретном случае, надо сравнивать не один случай -0.5, а несколько: например: -1.5, -0.5, +0.5, +1.5.
Тогда получается соответственно для этих значений (в том же порядке, что у Вас; Exasol не знаю, пропускаю):
PHP round(): -2, -1, 1, 2 (середина — от нуля)
Javascript Math.round(): -1, 0, 1, 2 (середина — к +INF)
Java Math.round(): -1, 0, 1, 2 (середина — к +INF)
(но рядом есть rint(), который округляет середину к чётному: -2, 0, 0, 2)
MySQL select round(): -2, -1, 1, 2 (середина — от нуля)
C round(): -2, -1, 1, 2 (середина — от нуля)
R round(): -2, 0, 0, 2 (середина — к чётному)
Erlang round(): -2, -1, 1, 2 (середина — от нуля)
Кроме того:
Python3 round(): -2, 0, 0, 2 (середина — к чётному)
Perl POSIX::round: как в C (середина — от нуля)
как видите, до сих пор ни одного случая ни «середина к нулю», ни «середина к меньшему». Особый случай — Java и склонировавший её Javascript, где, наоборот, середина — к +INF (интересно, кто и зачем такое выбрал?)
Округление к меньшему по модулю имеет вот такое замечательное свойство: round(x) + round(-x) == 0
Округление к чётному, к нечётному, к нулю (к меньшему по модулю) и от нуля — все одновременно имеют это свойство.
В большинстве случаев, встречается округление к меньшему как поведение по умолчанию.
Хм… вообще-то в большинстве случаев или к ближайшему, а середину — от нуля (как в обсуждаемой реализации), или к ближайшему, а посредине — к чётному (банкирское, оно же гауссово округление). В школе нас учили единственному варианту, что округление — к ближайшему, а середину — от нуля.
В терминах IEEE754-2008 это соответственно roundToNearestTiesAway и roundToNearestTiesToEven.
Статья на вики
Статья хорошая как вводной обзор, но сильно неполная.
Нет, например, фоннеймановского округления, про которое см. документацию IBM:
Round to prepare for shorter precision: For a BFP or HFP permissible set (двоичная арифметика), the candidate selected is the one whose voting digit has an odd value. For a DFP permissible set (десятичная арифметика), the candidate that is smaller in magnitude is selected, unless its voting digit has a value of either 0 or 5; in that case, the candidate that is greater in magnitude is selected.
И то, что даже при подобной формальной анонимности (ник вместо паспорта) можно оценивать других участников и ценность их мнения/позиции/оценки по известным проявлениям (статьи, комментарии). Будет не просто Crazy23, а, например, тот Crazy23, который много и по делу пишет про Javascript, зато регулярно несёт откровенную чушь про компьютеры 60-х; ездит на Уазике на дачу, пьёт ром и выступает за усиление контроля в Интернете. В этом смысле каждый из нас может знать — существенного для обсуждаемого предмета — про такого другого участника больше и важнее, чем про абсолютно неанонимного коллегу по работе, и соответственно ценить (или не ценить) его мнение и оценку.
Репутация такого своего аватара в Интернете и на конкретном форуме — может быть ничуть не менее важна, чем в реальном мире.
Представляю, что бы могло начаться, если б можно было просмотреть списки минусовавших и плюсовавших.
На RSDN такие списки открыты, и ничего не "начинается"; иногда бывают эксцессы типа "пошёл ставить оппоненту минусы вообще на всё" или взаимных войн двух подписчиков в одной теме, но они достаточно редки (и могут происходить независимо от видимости оценок).
Даже если учесть, что хабр, в отличие от RSDN, коммерческий проект — есть пример того, что небо не упало и не собирается (а оценка комментария, в отличие от вклада в карму, вряд ли вызовет последствия типа "устранили хорошего автора").
Ещё его преимущество — можно отличить ситуации, когда -10 собрано как +0 и -10, и когда это +100500 -100510. Здесь же количество оценивших никак не отражается (насколько мне известно), и это низводит осмысленность такой оценки до минимума.
Хотя, может быть, таким образом, уменьшилось бы количество минусов у коментариев, не нарушающих правила хабра, но противоположных, по содержанию, мнению минусующих.
Насколько я понимаю, это и есть то, зачем минус придумали — явное несогласие с мнением? Потому что за нарушение правил скорее должно следовать редактирование или стирание (а для простого участника — жалоба модератору)...
По крайней мере у round() в C такое же правило — цитирую по линуксовому ману:
These functions round x to the nearest integer, but round halfway cases away from zero (regardless of the current rounding direction, see fenv(3)), instead of to the nearest even integer like rint(3). For example, round(0.5) is 1.0, and round(-0.5) is -1.0.
В доступных текстах стандартов то же самое по сути.
Так что если это решение не идеальное, то по крайней мере традиционное.
(В идеале, я бы предпочёл видеть или дополнительный параметр направления округления, или раздельные функции для каждого режима округления. Но сейчас и введение только одного варианта — уже успех.)
Свободность ПО, конечно, сама по себе не панацея — ошибки проектирования типа «указатель всегда влезет в int» могут привести к необходимости столь же серьёзной перетряски кода, как и в случае проприетарного. Столь активная на хабре PVS-Studio «выехала» как раз на процессе перевода под 64 бита с поиском всех сопутствующих плюх.
А вот то, что процесс перехода на 64 бита прошёл в мире Linux/FreeBSD/etc. на несколько лет раньше и более спокойно — факт тут более существенный. Например, этому поспособствовала архитектура Alpha. Нам такая машинка досталась в 99-м и мы под неё долго пытались запустить всякие postfix и mysql, писали жалобы и слали патчи, но первый год дожидались только воплей типа «что у вас за хрень, как такое может быть?» (Обычный системный софт состава типичного юникса уже прошёл этот этап, c ним проблем не было.) К чести авторов, они быстро раскачались, и к 2002 уже основной софт весь умел что надо — это когда мучения ширнармасс под Windows только-только начинались.
если вы распаяли только 2 гб озу, ну зачееем там х64 ось… Ну не понимаю я…
ОС нормально и удобно работает, когда она может дважды замапить в виртуальную память все доступные ресурсы пространства памяти (включая RAM, ROM, управление устройствами). Если это недоступно, начинаются игры с двойной буферизацией и постоянным гонянием байтиков. Чем теснее, тем больше переключений промежуточных буферов и тем больше торможения.
Поэтому при 2GB RAM использование 64-битной виртуальной адресации становится уже безусловно необходимым для нормальной работы. Это ещё при 1GB можно было выбирать...
как и предложение спутникового Интернет, когда запросный канал был наземный, а входящий через спутник :)
Да, это был один из дешёвых и успешных вариантов. Запросного тонкого хватало, и передающая тарелка была не нужна; приёмная была не сильно дороже обычной телевизионной.
Вот канал шведы-LN был через спец-спутник — полумёртвую, со слабым сигналом, без топлива для коррекции и потому болтающуюся на орбите в пределах градуса, древнюю "Коламбию" — и потому принимался/передавался через 7-метровую тарелку с активным наведением по расчётам его траектории. Но эти разовые капзатраты оказались сильно меньше стоимости канала на чём-то более устойчивым. Тот спутник утопили через 4 месяца, как мы с него слезли :)
> В 2001 году емкость внешних (зарубежных) каналов «Укртелекома» становится равной 82 Мбит / с, в сравнении с 8 Мбит / с, которые приходились на всех остальных Интернет-операторов
Вы считаете только наземные каналы. Но были спутниковые. Например, LuckyNet (я там работал тогда) разогнал в несколько этапов свой канал до 50Mbit/s, значительную часть которых перераздавал снова через спутник(!) и это активно потреблялось; а остальное ещё и перепродавалось по Киеву. И он был не один такой. Всё это активно просуществовало до 2005-го, когда начало резко сокращаться в новых условиях (см. ниже).
Вы там пишете
> так как альтернатива — спутниковый Интернет, являлась более дорогой и нестабильной
это явно неверно — спутниковый был в разы дешевле (я имею в виду не персональную антенну у абонента, а приём и перераздачу местным провайдером); и стабильность тоже была неплохая, проблемы в основном в задержке, которая уже существенно мешала даже сёрфингу, а многие более интерактивные сервисы через него совсем не хотели работать.
Также были каналы через телевизионщиков, через свободные частотные полосы релеек, а затем через цифровые каналы той же передачи — набиралось ещё под 40 Mbit/s, насколько мне помнится (тут надо уточнять). Их преимуществом было отсутствие спутниковых задержек, недостатком — привязка к Москве вместо Европы, относительно высокая цена и ограниченность ресурса (за который конкурировали не только Интернет-поставщики, но и канальщики стиля Совама).
> Потому провайдеры начинают развивать свои опорные сети и внешние каналы связи, хотя «Укртелеком» всячески препятствует этому.
Причём совершенно нерыночными методами. Закончила это Оранжевая революция. Силы той группировки оказалось недостаточно, и летом 2005-го одновременно объявили 2 новых канала — 51Mbit/s + 155Mbit/s — через западную границу, через железнодорожников и трубопроводников (Укртелеком никак не мог препятствовать им класть собственные каналы, оставался только вопрос использования этого).
В течение полугода цены на внешний трафик упали в 4-5 раз, потом ещё падали, с введением новых каналов. Это дало последствия:
1. Изменилась структура цены для конечных абонентов — если до того, грубо говоря, 80% цены это был внешний трафик, после этого те же 80% тратились на локальную раздачу.
2. Вымерли сверхпопулярные до того WWW-прокси. Фактор цены трафика тут не единственный — ещё сильно повлияло изменение характера контекта на преобладание динамического.
3. В течение пары лет сошло на «нет» разделение тарификации трафика на украинский (через UA-IX, а также через UTC-IX, пока последняя существовала) и мировой.
4. Состоялась шумная попытка развалить UA-IX одновременным выходом, аналогично успешно состоявшемуся на 3 года раньше сценарию на московской M9. По слухам, её планировали одновременно WNet, Volia и Adamant. Но два последних «спрыгнули с поезда» в последний момент, а WNet попытался довести до конца, пользуясь положением главного трафикогенератора. Но не выгорело — раздача трафика утекла с него.
5. Пошло взрывное развитие локалок-домосетей системы «эзернет хоть какого-то качества в любую квартиру», бо́льшая часть которых живёт и теперь, устаканив сервис и в основном объединясь в более крупные структуры.
6. Оказались невыгодны и «убиты» внешние спутниковые каналы, как тот же LuckyNetʼовский. Дальше Укртелеком зашевелился и начал обеспечивать раздачу по стране, включая заводы в диких полях, за приемлемую цену — это добило и внутреннюю перераздачу (к 2008 оставались от неё жалкие огрызки).
Вот это всё вместе действительно стало переломом к нормальному современному состоянию.
> а летом 2001, чтоб задавить конкурентов, вводит тарификацию городской телефонной связи сразу после завершения перехода с аналоговых телефонных линий на цифровые, что сделало услугу конкурентов автоматически дороже. Сам же «Укртелеком», спустя время, предлагает доступ в Интернет «бесплатно», в обмен на оплату услуг городской телефонной связи, порядка 3,6 грн / час ($0,72 / час), тем самым изменив правила игры на рынке коммутируемого соединения.
Да, это был очень сильный удар. Но спасало то, что у Укртелекома не было никакого сервиса, кроме голого IP, и «никакая» поддержка.
> а карта с неограниченным доступом в Интернет только в выходные дни в течении месяца — стоила в районе 48 гривен ($9,6), в остальное время доступ предлагался почасовой, причём доступ ночью был вдвое дешевле дневного
LuckyNet несколько лет работал по правилу «с 02:00 до 08:00 всё бесплатно». Это привлекало даже тех, кто реально того ночного времени не использовал :)
> В 2003-2004 годах происходит активное развитие рынка широкополосного доступа к Интернет в г. Киеве.
> Потому популярности начинают набирать домашние сети, предлагающие трафик дешевле и на большей скорости,
Всё так — хотя по-крупному они развернулись (см. выше) уже с 2005-го.
> Однако присутствовала сложность для новых провайдеров-участников — необходимо было получить одобрение от всех текущих участников
Не всех, а 75%. Хотя это тоже серьёзный фактор — были желающие, которым долго отказывали — за какие-то старые грехи.
Ещё была UTC-IX — укртелекомовская аналогичная обменка — прожившая где-то до 2004-го. Доступ был закрытый, на уровне политических отношений руководства. LN туда попал сильно не сразу, но оказалось выгодно.
В районе 2006-го сформировали ещё одну обменку без имени на Гайдара, куда было сильно легче дотянуться, чем на L9. В отличие от UA-IX с её обязательным все-ко-всем, на Гайдара была более традиционной — только точкой физического соединения без общего договора — поэтому у неё и нет звучного имени.
> и после дотянуть свои волоконно-оптические линии связи до Леонтовича 9 (центр Киева), где располагалась точка обмена физически.
Уже давно было не обязательно свои — были и по 2-3 слоя субаренды каналов и потоков. Мы подключались, кажется, через транспорт от DG.
> и таким вариантом стало пользоваться большинство киевских абонентов, так как кабель от «Воли» был практически в каждой квартире.
Да, это получился великолепный вариант. Интересно, что руководство «Воли» несколько лет сопротивлялось такому прогрессу, считая его непрофильным и невыгодным; пока его не продавил А.В.Сорока (ранее из Global Ukraine и Укрсата).
> Безлимит «Украины» пришлось отменить и с марта 2005 года появляются тарифы с разделением на украинский трафик и зарубежный,
Это забавный был период — деление трафика в тарифах было введено буквально за три месяца до того, как факторы, которые принудили к нему, перестали действовать (см. выше про внешние каналы). Но инерция тянула его ещё с год.
> Крупнейшая сеть IPNet, предоставляющая доступ в Интернет в Оболонском районе столицы вводит VPN-запрет, заставляя клиентов подписывать «приложение к договору»,
Угу, помню эту войну :) в результате у IPNet ничего не получилось, потому что были реализованы методы строить VPN через что угодно, вплоть до DNS и ICMP.
Так что только сработала только победа в выходе в мир.
Вынужден повториться: я работал именно с такой организацией.
Видишь просто несоответствие стиля, недочёты, не влияющие на работу, но которые могут вылезти потом => ставь -1.
Видишь, что сломается в принципе => ставь -2 (срабатывает запрет, пока отметка не будет снята).
Если не поставил, пропустил коммит => принимаешь долю ответственности.
Если именно у вас так не делают, это не значит, что не делают нигде.
И я считаю, что так в очень многих случаях правильно — когда работающие над некоторым участком кода обязаны участвовать в ревью любого изменения этого участка. Иначе слишком легко оторваться от знания, что там происходит.
Да, не в 100% случаев. Точную цифру бы не дал. Но полагаю, что на большинство случаев.
Код-ревьювер — твой партнер, а не учитель и не ментор. Он не имеет права требовать каких-то изменений.
В командной работе такие принципы часто не применяются, и какие-то коллеги не просто имеют право требовать изменения — они обязаны это делать, если видят несоответствие задаче, ТЗ, стилю и так далее. И по итогу этого всего они обязаны поставить свою оценку и отвечают за неё — если пропущен откровенно плохой коммит, по разбору пострадают и они.
Типовой стиль Gerrit, например, настроен на это — для допуска ревью к коммиту кто-то должен поставить +2 на "Review". В принципе, можно поставить самому себе :), но будет заметно.
Польза от такого подхода достаточно очевидна — новые правки будут хотя бы известны команде и, если она приняла их — то они соответствуют (хотя бы частично) ожиданиям и требованиям. Недостатки тоже понятны: размывание ответственности, задержки на сбор оценок — но при нормальной дисциплине работы они не мешают.
новости с другой планеты какие-то.
Ну я на этой планете несколько лет работал. И уверен, даже среди читателей этой статьи таких найдётся немало. И не скажу, что это было как-то ужасно — наоборот, (повторюсь) польза была видна всем.
Повезло и этот код никому трогать не нужно? Ну и отлично — пусть остаётся грязным. Раз его никто не трогает, то он никому и не мешает.
На это есть известный довод, что на 1 написание кода приходится N (обычно говорят про 10) чтений кода, и ждать рефакторинга, чтобы его исправить — означает попусту тратить будущее время коллег.
А ещё есть "теория разбитых окон", которая говорит, что если появляется несколько мест такого безобразия, то скоро весь проект станет таким.
В соседнем проекте я такое наблюдаю — народ уже давно плюнул на идею что-то исправить и пишет такое, что волосы дыбом лезут.
Тогда получается соответственно для этих значений (в том же порядке, что у Вас; Exasol не знаю, пропускаю):
PHP round(): -2, -1, 1, 2 (середина — от нуля)
Javascript Math.round(): -1, 0, 1, 2 (середина — к +INF)
Java Math.round(): -1, 0, 1, 2 (середина — к +INF)
(но рядом есть rint(), который округляет середину к чётному: -2, 0, 0, 2)
MySQL select round(): -2, -1, 1, 2 (середина — от нуля)
C round(): -2, -1, 1, 2 (середина — от нуля)
R round(): -2, 0, 0, 2 (середина — к чётному)
Erlang round(): -2, -1, 1, 2 (середина — от нуля)
Кроме того:
Python3 round(): -2, 0, 0, 2 (середина — к чётному)
Perl POSIX::round: как в C (середина — от нуля)
как видите, до сих пор ни одного случая ни «середина к нулю», ни «середина к меньшему». Особый случай — Java и склонировавший её Javascript, где, наоборот, середина — к +INF (интересно, кто и зачем такое выбрал?)
Округление к чётному, к нечётному, к нулю (к меньшему по модулю) и от нуля — все одновременно имеют это свойство.
Хм… вообще-то в большинстве случаев или к ближайшему, а середину — от нуля (как в обсуждаемой реализации), или к ближайшему, а посредине — к чётному (банкирское, оно же гауссово округление). В школе нас учили единственному варианту, что округление — к ближайшему, а середину — от нуля.
В терминах IEEE754-2008 это соответственно roundToNearestTiesAway и roundToNearestTiesToEven.
Статья хорошая как вводной обзор, но сильно неполная.
Нет, например, фоннеймановского округления, про которое см. документацию IBM:
Round to prepare for shorter precision: For a BFP or HFP permissible set (двоичная арифметика), the candidate selected is the one whose voting digit has an odd value. For a DFP permissible set (десятичная арифметика), the candidate that is smaller in magnitude is selected, unless its voting digit has a value of either 0 or 5; in that case, the candidate that is greater in magnitude is selected.
+100. Анонимизация оценки имеет смысл только в особых случаях вроде грубого нарушения правил, иначе она работает против дискуссии.
И то, что даже при подобной формальной анонимности (ник вместо паспорта) можно оценивать других участников и ценность их мнения/позиции/оценки по известным проявлениям (статьи, комментарии). Будет не просто Crazy23, а, например, тот Crazy23, который много и по делу пишет про Javascript, зато регулярно несёт откровенную чушь про компьютеры 60-х; ездит на Уазике на дачу, пьёт ром и выступает за усиление контроля в Интернете. В этом смысле каждый из нас может знать — существенного для обсуждаемого предмета — про такого другого участника больше и важнее, чем про абсолютно неанонимного коллегу по работе, и соответственно ценить (или не ценить) его мнение и оценку.
Репутация такого своего аватара в Интернете и на конкретном форуме — может быть ничуть не менее важна, чем в реальном мире.
На RSDN такие списки открыты, и ничего не "начинается"; иногда бывают эксцессы типа "пошёл ставить оппоненту минусы вообще на всё" или взаимных войн двух подписчиков в одной теме, но они достаточно редки (и могут происходить независимо от видимости оценок).
Даже если учесть, что хабр, в отличие от RSDN, коммерческий проект — есть пример того, что небо не упало и не собирается (а оценка комментария, в отличие от вклада в карму, вряд ли вызовет последствия типа "устранили хорошего автора").
Ещё его преимущество — можно отличить ситуации, когда -10 собрано как +0 и -10, и когда это +100500 -100510. Здесь же количество оценивших никак не отражается (насколько мне известно), и это низводит осмысленность такой оценки до минимума.
Насколько я понимаю, это и есть то, зачем минус придумали — явное несогласие с мнением? Потому что за нарушение правил скорее должно следовать редактирование или стирание (а для простого участника — жалоба модератору)...
Так и есть (по крайней мере в double == float64).
По крайней мере у round() в C такое же правило — цитирую по линуксовому ману:
These functions round x to the nearest integer, but round halfway cases away from zero (regardless of the current rounding direction, see fenv(3)), instead of to the nearest even integer like rint(3). For example, round(0.5) is 1.0, and round(-0.5) is -1.0.
В доступных текстах стандартов то же самое по сути.
Так что если это решение не идеальное, то по крайней мере традиционное.
(В идеале, я бы предпочёл видеть или дополнительный параметр направления округления, или раздельные функции для каждого режима округления. Но сейчас и введение только одного варианта — уже успех.)
А вот то, что процесс перехода на 64 бита прошёл в мире Linux/FreeBSD/etc. на несколько лет раньше и более спокойно — факт тут более существенный. Например, этому поспособствовала архитектура Alpha. Нам такая машинка досталась в 99-м и мы под неё долго пытались запустить всякие postfix и mysql, писали жалобы и слали патчи, но первый год дожидались только воплей типа «что у вас за хрень, как такое может быть?» (Обычный системный софт состава типичного юникса уже прошёл этот этап, c ним проблем не было.) К чести авторов, они быстро раскачались, и к 2002 уже основной софт весь умел что надо — это когда мучения ширнармасс под Windows только-только начинались.
ОС нормально и удобно работает, когда она может дважды замапить в виртуальную память все доступные ресурсы пространства памяти (включая RAM, ROM, управление устройствами). Если это недоступно, начинаются игры с двойной буферизацией и постоянным гонянием байтиков. Чем теснее, тем больше переключений промежуточных буферов и тем больше торможения.
Поэтому при 2GB RAM использование 64-битной виртуальной адресации становится уже безусловно необходимым для нормальной работы. Это ещё при 1GB можно было выбирать...
Да, это был один из дешёвых и успешных вариантов. Запросного тонкого хватало, и передающая тарелка была не нужна; приёмная была не сильно дороже обычной телевизионной.
Вот канал шведы-LN был через спец-спутник — полумёртвую, со слабым сигналом, без топлива для коррекции и потому болтающуюся на орбите в пределах градуса, древнюю "Коламбию" — и потому принимался/передавался через 7-метровую тарелку с активным наведением по расчётам его траектории. Но эти разовые капзатраты оказались сильно меньше стоимости канала на чём-то более устойчивым. Тот спутник утопили через 4 месяца, как мы с него слезли :)
> В 2001 году емкость внешних (зарубежных) каналов «Укртелекома» становится равной 82 Мбит / с, в сравнении с 8 Мбит / с, которые приходились на всех остальных Интернет-операторов
Вы считаете только наземные каналы. Но были спутниковые. Например, LuckyNet (я там работал тогда) разогнал в несколько этапов свой канал до 50Mbit/s, значительную часть которых перераздавал снова через спутник(!) и это активно потреблялось; а остальное ещё и перепродавалось по Киеву. И он был не один такой. Всё это активно просуществовало до 2005-го, когда начало резко сокращаться в новых условиях (см. ниже).
Вы там пишете
> так как альтернатива — спутниковый Интернет, являлась более дорогой и нестабильной
это явно неверно — спутниковый был в разы дешевле (я имею в виду не персональную антенну у абонента, а приём и перераздачу местным провайдером); и стабильность тоже была неплохая, проблемы в основном в задержке, которая уже существенно мешала даже сёрфингу, а многие более интерактивные сервисы через него совсем не хотели работать.
Также были каналы через телевизионщиков, через свободные частотные полосы релеек, а затем через цифровые каналы той же передачи — набиралось ещё под 40 Mbit/s, насколько мне помнится (тут надо уточнять). Их преимуществом было отсутствие спутниковых задержек, недостатком — привязка к Москве вместо Европы, относительно высокая цена и ограниченность ресурса (за который конкурировали не только Интернет-поставщики, но и канальщики стиля Совама).
> Потому провайдеры начинают развивать свои опорные сети и внешние каналы связи, хотя «Укртелеком» всячески препятствует этому.
Причём совершенно нерыночными методами. Закончила это Оранжевая революция. Силы той группировки оказалось недостаточно, и летом 2005-го одновременно объявили 2 новых канала — 51Mbit/s + 155Mbit/s — через западную границу, через железнодорожников и трубопроводников (Укртелеком никак не мог препятствовать им класть собственные каналы, оставался только вопрос использования этого).
В течение полугода цены на внешний трафик упали в 4-5 раз, потом ещё падали, с введением новых каналов. Это дало последствия:
1. Изменилась структура цены для конечных абонентов — если до того, грубо говоря, 80% цены это был внешний трафик, после этого те же 80% тратились на локальную раздачу.
2. Вымерли сверхпопулярные до того WWW-прокси. Фактор цены трафика тут не единственный — ещё сильно повлияло изменение характера контекта на преобладание динамического.
3. В течение пары лет сошло на «нет» разделение тарификации трафика на украинский (через UA-IX, а также через UTC-IX, пока последняя существовала) и мировой.
4. Состоялась шумная попытка развалить UA-IX одновременным выходом, аналогично успешно состоявшемуся на 3 года раньше сценарию на московской M9. По слухам, её планировали одновременно WNet, Volia и Adamant. Но два последних «спрыгнули с поезда» в последний момент, а WNet попытался довести до конца, пользуясь положением главного трафикогенератора. Но не выгорело — раздача трафика утекла с него.
5. Пошло взрывное развитие локалок-домосетей системы «эзернет хоть какого-то качества в любую квартиру», бо́льшая часть которых живёт и теперь, устаканив сервис и в основном объединясь в более крупные структуры.
6. Оказались невыгодны и «убиты» внешние спутниковые каналы, как тот же LuckyNetʼовский. Дальше Укртелеком зашевелился и начал обеспечивать раздачу по стране, включая заводы в диких полях, за приемлемую цену — это добило и внутреннюю перераздачу (к 2008 оставались от неё жалкие огрызки).
Вот это всё вместе действительно стало переломом к нормальному современному состоянию.
> а летом 2001, чтоб задавить конкурентов, вводит тарификацию городской телефонной связи сразу после завершения перехода с аналоговых телефонных линий на цифровые, что сделало услугу конкурентов автоматически дороже. Сам же «Укртелеком», спустя время, предлагает доступ в Интернет «бесплатно», в обмен на оплату услуг городской телефонной связи, порядка 3,6 грн / час ($0,72 / час), тем самым изменив правила игры на рынке коммутируемого соединения.
Да, это был очень сильный удар. Но спасало то, что у Укртелекома не было никакого сервиса, кроме голого IP, и «никакая» поддержка.
> а карта с неограниченным доступом в Интернет только в выходные дни в течении месяца — стоила в районе 48 гривен ($9,6), в остальное время доступ предлагался почасовой, причём доступ ночью был вдвое дешевле дневного
LuckyNet несколько лет работал по правилу «с 02:00 до 08:00 всё бесплатно». Это привлекало даже тех, кто реально того ночного времени не использовал :)
> В 2003-2004 годах происходит активное развитие рынка широкополосного доступа к Интернет в г. Киеве.
> Потому популярности начинают набирать домашние сети, предлагающие трафик дешевле и на большей скорости,
Всё так — хотя по-крупному они развернулись (см. выше) уже с 2005-го.
> Однако присутствовала сложность для новых провайдеров-участников — необходимо было получить одобрение от всех текущих участников
Не всех, а 75%. Хотя это тоже серьёзный фактор — были желающие, которым долго отказывали — за какие-то старые грехи.
Ещё была UTC-IX — укртелекомовская аналогичная обменка — прожившая где-то до 2004-го. Доступ был закрытый, на уровне политических отношений руководства. LN туда попал сильно не сразу, но оказалось выгодно.
В районе 2006-го сформировали ещё одну обменку без имени на Гайдара, куда было сильно легче дотянуться, чем на L9. В отличие от UA-IX с её обязательным все-ко-всем, на Гайдара была более традиционной — только точкой физического соединения без общего договора — поэтому у неё и нет звучного имени.
> и после дотянуть свои волоконно-оптические линии связи до Леонтовича 9 (центр Киева), где располагалась точка обмена физически.
Уже давно было не обязательно свои — были и по 2-3 слоя субаренды каналов и потоков. Мы подключались, кажется, через транспорт от DG.
> и таким вариантом стало пользоваться большинство киевских абонентов, так как кабель от «Воли» был практически в каждой квартире.
Да, это получился великолепный вариант. Интересно, что руководство «Воли» несколько лет сопротивлялось такому прогрессу, считая его непрофильным и невыгодным; пока его не продавил А.В.Сорока (ранее из Global Ukraine и Укрсата).
> Безлимит «Украины» пришлось отменить и с марта 2005 года появляются тарифы с разделением на украинский трафик и зарубежный,
Это забавный был период — деление трафика в тарифах было введено буквально за три месяца до того, как факторы, которые принудили к нему, перестали действовать (см. выше про внешние каналы). Но инерция тянула его ещё с год.
> Крупнейшая сеть IPNet, предоставляющая доступ в Интернет в Оболонском районе столицы вводит VPN-запрет, заставляя клиентов подписывать «приложение к договору»,
Угу, помню эту войну :) в результате у IPNet ничего не получилось, потому что были реализованы методы строить VPN через что угодно, вплоть до DNS и ICMP.
Так что только сработала только победа в выходе в мир.
Видишь просто несоответствие стиля, недочёты, не влияющие на работу, но которые могут вылезти потом => ставь -1.
Видишь, что сломается в принципе => ставь -2 (срабатывает запрет, пока отметка не будет снята).
Если не поставил, пропустил коммит => принимаешь долю ответственности.
Если именно у вас так не делают, это не значит, что не делают нигде.
И я считаю, что так в очень многих случаях правильно — когда работающие над некоторым участком кода обязаны участвовать в ревью любого изменения этого участка. Иначе слишком легко оторваться от знания, что там происходит.
Да, не в 100% случаев. Точную цифру бы не дал. Но полагаю, что на большинство случаев.
В командной работе такие принципы часто не применяются, и какие-то коллеги не просто имеют право требовать изменения — они обязаны это делать, если видят несоответствие задаче, ТЗ, стилю и так далее. И по итогу этого всего они обязаны поставить свою оценку и отвечают за неё — если пропущен откровенно плохой коммит, по разбору пострадают и они.
Типовой стиль Gerrit, например, настроен на это — для допуска ревью к коммиту кто-то должен поставить +2 на "Review". В принципе, можно поставить самому себе :), но будет заметно.
Польза от такого подхода достаточно очевидна — новые правки будут хотя бы известны команде и, если она приняла их — то они соответствуют (хотя бы частично) ожиданиям и требованиям. Недостатки тоже понятны: размывание ответственности, задержки на сбор оценок — но при нормальной дисциплине работы они не мешают.
Ну я на этой планете несколько лет работал. И уверен, даже среди читателей этой статьи таких найдётся немало. И не скажу, что это было как-то ужасно — наоборот, (повторюсь) польза была видна всем.
На это есть известный довод, что на 1 написание кода приходится N (обычно говорят про 10) чтений кода, и ждать рефакторинга, чтобы его исправить — означает попусту тратить будущее время коллег.
А ещё есть "теория разбитых окон", которая говорит, что если появляется несколько мест такого безобразия, то скоро весь проект станет таким.
В соседнем проекте я такое наблюдаю — народ уже давно плюнул на идею что-то исправить и пишет такое, что волосы дыбом лезут.