нет, не соглашусь. Даже если назвать то, что делает Карлсон "публицистикой" - он ведёт себя нечестно по отношению к читателю. Не пытается разобраться в проблеме, а, наоборот, подгоняет факты под заранее известный ответ. (примерно так же, кстати, работает лженаука - думаю, тут вполне допустима такая аналогия)
Та же ситуация с Твиттером. Ок, Дорси жалуется на вредную биржу, которая мешает делать сокращения. Хватает ли тут информации чтобы сделать выводы? Лично мне - нет. У меня сразу возникают вопросы: как эти "лишние" люди оказались в Твиттере? Чем они там сейчас занимаются?
Если это крепкие профессионалы - можно всегда выделить их в отдельный непрофильный бизнес, назвать, скажем, Кверителом - и отправить в свободное плавание. Кажется, биржи подобные трюки только приветствуют.
Если это действительно бездельники - тогда вопросы к тому, кто их нанял - и к его способности вести компанию дальше вперёд. Кажется, тут биржа будет не так уж и неправа.
Может быть "лишние" люди - это diversity-департамент, который раздражает совет директоров, но позволяет успешно торговаться на бирже. Ок, тут спорно, но я с трудом представляю, что они прям являются неподъемной абузой, тянущей Твиттер вниз. Пусть даже десяток людей на полтысячи человек - это не про "биржи заставляют вас работать неэффективно"
Итак, всего пара вопросов, чтобы разобраться в ситуации - и у читателя уже есть фактура для выводов. Но Карлсон вместо этого подгоняет условия под ответ. Я могу ошибаться, но в моё определение "журналистики" это никак не укладывается.
Там Дуров прямо цитирует Дорси: "я бы разогнал тут всех, но тогда на бирже подумают, что у нас проблемы!"
Это, конечно, манипуляция. У Дурова, очевидно, всё, что не core-team, отдано на аутсорс. В Твиттере времён Дорси явно наоборот, все нужные люди (и какая-то часть ненужных) сидят в офисе. Но Карлсон не хочет в этом разбираться, он цепляется за реплику Дурова и поворачивает в свою сторону: "Вы хотите сказать, что биржа заставляет компанию быть неэффективной?!" На что Дуров многозначительно улыбается и увиливает "ну, по крайней мере это то, что сказал Джек Дорси"
И тут окончательно становится понятно, что никакое это не интервью. Дуров продолжает рисовать образ вундеркинда-сверхчеловека (его право). А вот интервьюер вместо того, чтобы раскрыть собеседника, нагло использует его чтобы поддержать свои собственные нарративы
Мне больше всего понравился момент, где Дуров обсуждал с Дорси, что в Твиттере тоже должно быть 20-30 человек. И ведь, судя по лицу Карлсона, эта ерунда теперь разлетится по его аудитории: "Коварная Wall Street заставляет нанимать лишних людей!!!111"
Вот только что вернулся, провёл 1,5 недели в Тбилиси. Ни разу не видел надписей "русские не обслуживаются" (видимо, не там искал). И наоборот, несколько раз в кафе/барах когда видели, что я не говорю по-грузински, персонал специально искал русскоязычного официанта. Ну и английский выручает почти всегда, по ощущениям даже лучше, чем в Турции.
"...обезличенный список..." который, тем не менее, позволит "определить круг пользователей" - очень напоминает дихотомию крестика и трусов. Хотя, технически, похоже на какой-то внутренний идентификатор типа user_id (не путать с user_name!). Если это так, то откуда МТС смог по номеру телефона узнать этот идентификатор?
дальше еще смешнее: "Это не позволяет никаким третьим лицам, включая рекламодателей, узнать Ваш номер телефона" Так МТС вроде и есть рекламодатель? Значит он и так уже знает номера телефонов. Или это их от самого телеграма пытаются защитить?
Выглядит это все очень неуклюже и от этого грустно. Видимо, действительно деньги заканчиваются и нормального PR-щика, который всё объяснил бы по-человечески, из команды уже выгнали.
ну возвращаясь к российским реалиям - если впн открывает инстаграмм, то это уже не такая пустая трата денег (понятно, что может быть можно дешевле, но это часть услуги: сделаем за деньги, но удобно и просто)
А вот про ботнет - действительно не приходило в голову, спасибо!
Слушайте, а вот Explain me like I'm 5: а в чем опасность "скамерских" впн-ов? (ну кроме очевидного мошенничества с оплатой)
Общение с сайтами сейчас почти всегда защищено TLS, куки в том числе зашифрованы. Понятно, что они знают адрес сайта, куда ты ходишь и могут его слить товарищу майору. Но если использовать их только для инстаграмма/фейсбука, кажется, опасность преувеличена?
а можно с момента "раскулачивания" поподробнее? Как это у них там в Чехии работает - сажают руководителей известных компаний за госизмену? ой, это, кажется, в другой стране было
Добавлю 5 копеек. Вот тут над головами взлетают/садятся самолёты. На практике, если жить неделю в году в отеле, всё не так плохо. Но квартиру я бы там покупать не стал
Потому что целью всего этого упахивания были, соответственно, пятёрки, золотая медаль и красный диплом.
Ну в её защиту можно сказать, что условно до 21 года со всех сторон тебе буквально все - и родители, и вуз - говорят, что пятёрки = счастливое будущее. Про то, что неплохо было бы заниматься нетворкингом вместо пятёрок до меня лично начало доходить только к пятому курсу. А до кого-то так и не дошло.
да, тут "идеальное" надо было взять в кавычки - по сути, даже с такими ограничениями положительный остаток не гарантировался. А с развитием платформы параллельность работы выросла, проявились классические артефакты многопользовательской работы - и появились классические же способы борьбы с ними (блокировки, проверки остатков в конце транзакции), которыми можно пользоваться, а можно и не пользоваться, если в конкретной ситуации не надо
Это спасёт от отрицательного остатка "в конце баланса", но не поможет от минусов "в моменте": если будет 3 транзакции
+100
+400
+500
,а потом задним числом вторая транзакция поменяется на -400
мы получим отрицательный остаток после 2 действия, но положительный - на финальном итоге
Это лечится запретом изменения документов - все исправления делаются новым корректирующим документом (такое есть в ЗУП). Всё это реализуемо языком платформы - и тут совершенно не нужен предлагаемый автором "неотрицательный остаток"
Идеальное решение отрицательных остатков предлагала преснопамятная 1С 7.7 - там просто все транзакции работали в SERIALIZABLE и параллельно два раза что-то зарезервировать было невозможно. К счастью, 1С 8.х действительно стала многопользовательской, а это значит, что теоретически возможны и списания "в минус". А дальше уже в зависимости от ситуации программист должен что-то с этим делать - либо проверять остатки до и после транзакции, либо добавлять регламентную постобработку, либо просто ничего не делать (посмотрите, как работает ритейл или WMS - если товар лежит перед кассиром/кладовщиком, значит он должен его отдать, даже если программа считает, что на остатке его нет). max(остаток, 0) - частное и вредное решение, плодящее плохие паттерны проектирования
Встроенный метод распределения... а по каким критериям он будет распределять? Надо ли учитывать гипотетическое измерение "серия номенклатуры"? А если учёт по сериям не ведётся? А если списывать нужно по FIFO в привязке к партиеобразующему документу, ссылка на который лежит внутри "серии"? Эти все условия тоже нужно передавать в некий магический метод распределения? И потом гадать, как этот черный ящик, встроенный в платформу, получил нужные цифры? Нет, увольте, пусть лучше это будет написано кодом, доступным для отладки
При использовании такого метода надо учитывать, что 1С (по крайней мере при работе с MS SQL Server, в PG не изучал) переиспользует временные таблицы - со всей накопившейся структурой метаданных
С SQL Server у меня как-то был интересный случай. При помощи черной магии добавили создание колоночного (columnstore) индекса по временной таблице, участвовавшей в расчёте себестоимости. Первая итерация отрабатывала успешно, но потом начинались проблемы - построчное заполнение таблицы с columnstore-индексом начинает чудовищно тормозить, съедается весь эффект от оптимизации. Более того, из-за того, что таблица была очень простая (одна колонка со ссылками), она переиспользовалась и в других похожих запросах из той же сессии (например, при передаче массива в качестве параметра). Очень быстро все такие таблицы оказывались с columnstore-индексами, что практически парализовывало работу сессии. Вылечилось явным удалением columnstore-индекса после выполнения нужного запроса.
Я это рассказываю не для того, чтобы отвадить читателей от механики из статьи. Просто надо учитывать, что индексы могут "расползтись" и по другим запросам из сессии - не удивляйтесь, если увидите их при отладке там, где их не должно было быть.
Другими словами: "для меня RPO в 2 минуты - это допустимый сценарий" (и ещё раз: а что по этому поводу думает бизнес?)
В PG, судя по описанию, механизм работает аналогично (оно и понятно, идея-то простая). Поэтому первоначальный вопрос должен стоять так же: могу ли я (и бизнес!) позволить себе безвозвратную потерю нескольких последних минут работы пользователей? А дальше уже - детали реализации.
DD в SQL Server увеличивает риски в сценарии "выдернули вилку из розетки". И только. В классическом варианте закоммиченные транзакции сразу попадают на диск (в лог транзакций) и если серсис СУБД резко остановится, их можно будет восстановить по логу. В случае DD есть риск, что транзакции не попадут в лог и будут утеряны навсегда
По сути, тут идёт размен RPO на скорость параллельной работы пользователей. По моему опыту, в OLTP чаще выбирали RPO, но кто-то может позволить себе повысить риски за счёт общего ускорения. В любом случае, это нужно обсуждать с бизнесом
нет, не соглашусь. Даже если назвать то, что делает Карлсон "публицистикой" - он ведёт себя нечестно по отношению к читателю. Не пытается разобраться в проблеме, а, наоборот, подгоняет факты под заранее известный ответ. (примерно так же, кстати, работает лженаука - думаю, тут вполне допустима такая аналогия)
Та же ситуация с Твиттером. Ок, Дорси жалуется на вредную биржу, которая мешает делать сокращения. Хватает ли тут информации чтобы сделать выводы? Лично мне - нет. У меня сразу возникают вопросы: как эти "лишние" люди оказались в Твиттере? Чем они там сейчас занимаются?
Если это крепкие профессионалы - можно всегда выделить их в отдельный непрофильный бизнес, назвать, скажем, Кверителом - и отправить в свободное плавание. Кажется, биржи подобные трюки только приветствуют.
Если это действительно бездельники - тогда вопросы к тому, кто их нанял - и к его способности вести компанию дальше вперёд. Кажется, тут биржа будет не так уж и неправа.
Может быть "лишние" люди - это diversity-департамент, который раздражает совет директоров, но позволяет успешно торговаться на бирже. Ок, тут спорно, но я с трудом представляю, что они прям являются неподъемной абузой, тянущей Твиттер вниз. Пусть даже десяток людей на полтысячи человек - это не про "биржи заставляют вас работать неэффективно"
Итак, всего пара вопросов, чтобы разобраться в ситуации - и у читателя уже есть фактура для выводов. Но Карлсон вместо этого подгоняет условия под ответ. Я могу ошибаться, но в моё определение "журналистики" это никак не укладывается.
это не делает их правыми) и уже наше право - указывать им на нечистоплотность
ну если Такер продолжает называть себя журналистом, а не пропагандистом - то нет)
Там Дуров прямо цитирует Дорси: "я бы разогнал тут всех, но тогда на бирже подумают, что у нас проблемы!"
Это, конечно, манипуляция. У Дурова, очевидно, всё, что не core-team, отдано на аутсорс. В Твиттере времён Дорси явно наоборот, все нужные люди (и какая-то часть ненужных) сидят в офисе. Но Карлсон не хочет в этом разбираться, он цепляется за реплику Дурова и поворачивает в свою сторону: "Вы хотите сказать, что биржа заставляет компанию быть неэффективной?!" На что Дуров многозначительно улыбается и увиливает "ну, по крайней мере это то, что сказал Джек Дорси"
И тут окончательно становится понятно, что никакое это не интервью. Дуров продолжает рисовать образ вундеркинда-сверхчеловека (его право). А вот интервьюер вместо того, чтобы раскрыть собеседника, нагло использует его чтобы поддержать свои собственные нарративы
Мне больше всего понравился момент, где Дуров обсуждал с Дорси, что в Твиттере тоже должно быть 20-30 человек. И ведь, судя по лицу Карлсона, эта ерунда теперь разлетится по его аудитории: "Коварная Wall Street заставляет нанимать лишних людей!!!111"
Вот только что вернулся, провёл 1,5 недели в Тбилиси. Ни разу не видел надписей "русские не обслуживаются" (видимо, не там искал). И наоборот, несколько раз в кафе/барах когда видели, что я не говорю по-грузински, персонал специально искал русскоязычного официанта. Ну и английский выручает почти всегда, по ощущениям даже лучше, чем в Турции.
Что-то правда одни вопросы от такого объяснения.
"...обезличенный список..." который, тем не менее, позволит "определить круг пользователей" - очень напоминает дихотомию крестика и трусов. Хотя, технически, похоже на какой-то внутренний идентификатор типа user_id (не путать с user_name!). Если это так, то откуда МТС смог по номеру телефона узнать этот идентификатор?
дальше еще смешнее:
"Это не позволяет никаким третьим лицам, включая рекламодателей, узнать Ваш номер телефона" Так МТС вроде и есть рекламодатель? Значит он и так уже знает номера телефонов. Или это их от самого телеграма пытаются защитить?
Выглядит это все очень неуклюже и от этого грустно. Видимо, действительно деньги заканчиваются и нормального PR-щика, который всё объяснил бы по-человечески, из команды уже выгнали.
ну возвращаясь к российским реалиям - если впн открывает инстаграмм, то это уже не такая пустая трата денег (понятно, что может быть можно дешевле, но это часть услуги: сделаем за деньги, но удобно и просто)
А вот про ботнет - действительно не приходило в голову, спасибо!
Слушайте, а вот Explain me like I'm 5: а в чем опасность "скамерских" впн-ов? (ну кроме очевидного мошенничества с оплатой)
Общение с сайтами сейчас почти всегда защищено TLS, куки в том числе зашифрованы. Понятно, что они знают адрес сайта, куда ты ходишь и могут его слить товарищу майору. Но если использовать их только для инстаграмма/фейсбука, кажется, опасность преувеличена?
а можно с момента "раскулачивания" поподробнее? Как это у них там в Чехии работает - сажают руководителей известных компаний за госизмену? ой, это, кажется, в другой стране было
Добавлю 5 копеек. Вот тут над головами взлетают/садятся самолёты. На практике, если жить неделю в году в отеле, всё не так плохо. Но квартиру я бы там покупать не стал
У Sony есть Wena. Но, к сожалению, только в японии. https://www.ixbt.com/news/2020/10/02/sony-sony-wena-3.html
Ну в её защиту можно сказать, что условно до 21 года со всех сторон тебе буквально все - и родители, и вуз - говорят, что пятёрки = счастливое будущее. Про то, что неплохо было бы заниматься нетворкингом вместо пятёрок до меня лично начало доходить только к пятому курсу. А до кого-то так и не дошло.
да, тут "идеальное" надо было взять в кавычки - по сути, даже с такими ограничениями положительный остаток не гарантировался. А с развитием платформы параллельность работы выросла, проявились классические артефакты многопользовательской работы - и появились классические же способы борьбы с ними (блокировки, проверки остатков в конце транзакции), которыми можно пользоваться, а можно и не пользоваться, если в конкретной ситуации не надо
Это спасёт от отрицательного остатка "в конце баланса", но не поможет от минусов "в моменте": если будет 3 транзакции
+100
+400
+500
,а потом задним числом вторая транзакция поменяется на -400
мы получим отрицательный остаток после 2 действия, но положительный - на финальном итоге
Это лечится запретом изменения документов - все исправления делаются новым корректирующим документом (такое есть в ЗУП). Всё это реализуемо языком платформы - и тут совершенно не нужен предлагаемый автором "неотрицательный остаток"
Какие-то странные решения выдуманных проблем.
Идеальное решение отрицательных остатков предлагала преснопамятная 1С 7.7 - там просто все транзакции работали в SERIALIZABLE и параллельно два раза что-то зарезервировать было невозможно. К счастью, 1С 8.х действительно стала многопользовательской, а это значит, что теоретически возможны и списания "в минус". А дальше уже в зависимости от ситуации программист должен что-то с этим делать - либо проверять остатки до и после транзакции, либо добавлять регламентную постобработку, либо просто ничего не делать (посмотрите, как работает ритейл или WMS - если товар лежит перед кассиром/кладовщиком, значит он должен его отдать, даже если программа считает, что на остатке его нет). max(остаток, 0) - частное и вредное решение, плодящее плохие паттерны проектирования
Встроенный метод распределения... а по каким критериям он будет распределять? Надо ли учитывать гипотетическое измерение "серия номенклатуры"? А если учёт по сериям не ведётся? А если списывать нужно по FIFO в привязке к партиеобразующему документу, ссылка на который лежит внутри "серии"? Эти все условия тоже нужно передавать в некий магический метод распределения? И потом гадать, как этот черный ящик, встроенный в платформу, получил нужные цифры? Нет, увольте, пусть лучше это будет написано кодом, доступным для отладки
При использовании такого метода надо учитывать, что 1С (по крайней мере при работе с MS SQL Server, в PG не изучал) переиспользует временные таблицы - со всей накопившейся структурой метаданных
С SQL Server у меня как-то был интересный случай. При помощи черной магии добавили создание колоночного (columnstore) индекса по временной таблице, участвовавшей в расчёте себестоимости. Первая итерация отрабатывала успешно, но потом начинались проблемы - построчное заполнение таблицы с columnstore-индексом начинает чудовищно тормозить, съедается весь эффект от оптимизации. Более того, из-за того, что таблица была очень простая (одна колонка со ссылками), она переиспользовалась и в других похожих запросах из той же сессии (например, при передаче массива в качестве параметра). Очень быстро все такие таблицы оказывались с columnstore-индексами, что практически парализовывало работу сессии. Вылечилось явным удалением columnstore-индекса после выполнения нужного запроса.
Я это рассказываю не для того, чтобы отвадить читателей от механики из статьи. Просто надо учитывать, что индексы могут "расползтись" и по другим запросам из сессии - не удивляйтесь, если увидите их при отладке там, где их не должно было быть.
Конкурс: думаю, это 2 абзаца с описанием аукциона (" Такой формат аукциона... " и далее)
Другими словами: "для меня RPO в 2 минуты - это допустимый сценарий" (и ещё раз: а что по этому поводу думает бизнес?)
В PG, судя по описанию, механизм работает аналогично (оно и понятно, идея-то простая). Поэтому первоначальный вопрос должен стоять так же: могу ли я (и бизнес!) позволить себе безвозвратную потерю нескольких последних минут работы пользователей? А дальше уже - детали реализации.
DD в SQL Server увеличивает риски в сценарии "выдернули вилку из розетки". И только. В классическом варианте закоммиченные транзакции сразу попадают на диск (в лог транзакций) и если серсис СУБД резко остановится, их можно будет восстановить по логу. В случае DD есть риск, что транзакции не попадут в лог и будут утеряны навсегда
По сути, тут идёт размен RPO на скорость параллельной работы пользователей. По моему опыту, в OLTP чаще выбирали RPO, но кто-то может позволить себе повысить риски за счёт общего ускорения. В любом случае, это нужно обсуждать с бизнесом