Этот момент, когда твой начальник смог найти на картинке 3 покемонов, а ты ни одного.
Сегодня празднуется всемирный день эмодзи - маленьких смайликов с изображением улыбки, танцующей женщины и какульки.
Что хотелось бы сказать по этому поводу: с начала 21 века в жизнь воплотилось много реально хороших и полезных идей.
Бионические протезы, коммерческие космические программы, электрокары, массовое удешевление компьютеров, носимая электроника (расскажи мне в 2001, что я почту с часов буду проверять, я б не поверил), посадка зонда Розетта (https://ru.m.wikipedia.org/wiki/%D0%A0%D0%BE%D0%B7%D0%B5%D1%82%D1%82%D0%B0_(%D0%BA%D0%BE%D1%81%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D0%BF%D0%BF%D0%B0%D1%80%D0%B0%D1%82) и многое другое.
Но мы будем праздновать день эмодзи (хотя у нас есть день смайлика).
Что хотелось бы сказать по этому поводу: с начала 21 века в жизнь воплотилось много реально хороших и полезных идей.
Бионические протезы, коммерческие космические программы, электрокары, массовое удешевление компьютеров, носимая электроника (расскажи мне в 2001, что я почту с часов буду проверять, я б не поверил), посадка зонда Розетта (https://ru.m.wikipedia.org/wiki/%D0%A0%D0%BE%D0%B7%D0%B5%D1%82%D1%82%D0%B0_(%D0%BA%D0%BE%D1%81%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D0%BF%D0%BF%D0%B0%D1%80%D0%B0%D1%82) и многое другое.
Но мы будем праздновать день эмодзи (хотя у нас есть день смайлика).
Wikipedia
Розетта (космический аппарат)
космический аппарат, предназначенный для исследования кометы
А тем, кому не интересна история смайликов, могу посоветовать годный репозиторий хороших книжек про программирование: https://github.com/EbookFoundation/free-programming-books/blob/master/free-programming-books.md
Не могу пока найти пруфов на это, а впрочем и не важно.
Один приятель расказал байку, мол в штатах у бомжей есть экуайринг и они милостыню на свой банковский счет переводят.
Что же касается ИИ на службе у прыщавых задротов.
Будь я админом какого-нибудь паблика ВК с сиськами, я без исключений заведу такого бота. Это же уникальный контент!
Про бота-бомжа могу сказать только одно - через пару десятков лет жду робобомжей на улицах.
Один приятель расказал байку, мол в штатах у бомжей есть экуайринг и они милостыню на свой банковский счет переводят.
Что же касается ИИ на службе у прыщавых задротов.
Будь я админом какого-нибудь паблика ВК с сиськами, я без исключений заведу такого бота. Это же уникальный контент!
Про бота-бомжа могу сказать только одно - через пару десятков лет жду робобомжей на улицах.
Я уже говорил, что держу этот канал подальше от политоты?
Вот недавно одному ловцу покемонов предъявили за оскорбление чувств верующих, и теперь он получил статус террориста со всеми вытекающими (например заблокированными банковскими счетами).
Что тут можно сказать? Добро пожаловать в увлекательный мир даркнета и биткоинов, бро.
Я уже писал о том, что прогресс двигает не только человеческая лень и жажда познания (или наживы), но и многочисленные препятствия.
Если лишить человека возможности вести коммерческую деятельность по правилам, то он неизбежно найдет способ решить свою проблему. И тот же пресловутый Тор из пристанища анонимов, наемных убийц, наркодилеров, мамкиных хакеров и прочих маргиналов превращается в этакое пристанище для отвергнутых блогеров.
Не удивлюсь, если Ловец Покемонов затащит туда своих фанатов, и школьники будут тратить родительские деньги не на игрушки, а на криптовалюты. Вот это будет реально весело, потому что за Покемоноловом туда потянутся и другие "лидеры мнений".
What a time to be alive.
Вот недавно одному ловцу покемонов предъявили за оскорбление чувств верующих, и теперь он получил статус террориста со всеми вытекающими (например заблокированными банковскими счетами).
Что тут можно сказать? Добро пожаловать в увлекательный мир даркнета и биткоинов, бро.
Я уже писал о том, что прогресс двигает не только человеческая лень и жажда познания (или наживы), но и многочисленные препятствия.
Если лишить человека возможности вести коммерческую деятельность по правилам, то он неизбежно найдет способ решить свою проблему. И тот же пресловутый Тор из пристанища анонимов, наемных убийц, наркодилеров, мамкиных хакеров и прочих маргиналов превращается в этакое пристанище для отвергнутых блогеров.
Не удивлюсь, если Ловец Покемонов затащит туда своих фанатов, и школьники будут тратить родительские деньги не на игрушки, а на криптовалюты. Вот это будет реально весело, потому что за Покемоноловом туда потянутся и другие "лидеры мнений".
What a time to be alive.
Ребятки, у меня небольшой творческий кризис - я не знаю о чем писать, а в стране первого мира ровным счетом не произошло ничего интересного, о чем стоило бы сказать.
Если у кого есть идеи, о чем хотелось почитать (технологии, управление проектами и прочие смехуечки) - стреляйте письмом на адрес thomas.storm@protonmail.com
Ну или пишите в ТГ, кто меня знает лично.
А пока небольшой анонс - наша контора ищет 2 виндовых инжей (один по Active Directory, другой по SCCM) и сетевика. Если есть человек с мозгами и аглицким языком, шлите на адрес выше резюме.
Всем любви.
Если у кого есть идеи, о чем хотелось почитать (технологии, управление проектами и прочие смехуечки) - стреляйте письмом на адрес thomas.storm@protonmail.com
Ну или пишите в ТГ, кто меня знает лично.
А пока небольшой анонс - наша контора ищет 2 виндовых инжей (один по Active Directory, другой по SCCM) и сетевика. Если есть человек с мозгами и аглицким языком, шлите на адрес выше резюме.
Всем любви.
👍1
Я с приятелями люблю спорить о всякого рода гуманитарной фигне. Так, например, я с пеной у рта доказывал, что называть человека “ресурсом” нельзя, мы же люди, у нас есть чувства и все такое.
В конторе у нас Скрам. Это, кто не знает, одна из самых популярных реализаций этих ваших Agile.
Скрамят у нас все и вся: от дизайнеров и контент-менеджеров до архитекторов и прогеров. Единственные отделы, где скрама нет - техподдержка, hr и бухгалтерия (хотя я уверен, и им пытались это втюхать).
Как так вообще получилось? Несколько лет назад генеральный решил, что контора станет пионером технологий и методологий.
По такому поводу на ютубе до сих пор висит бородатый видос, где наш, тогда еще чисто голландский, ИТ департамент говорит о преимуществах Скрам (https://youtu.be/FHHSlJQS5nY).
Тут надо еще сказать про компанию: начинаясь как маленький интернет магазин mp3 плееров, контора начала активно и быстро расти, благо ее рассвет пришелся на бум доткомов. Таким образом компания до сих пор, имея все отличительные черты махрового энтерпрайза, ведет себя как стартап. И как любой уважающий себя стартап она примеряет на себе все новое, не боясь никаких последствий. Одним из таких нововведений и стал Скрам, на который посадили всех.
В конторе у нас Скрам. Это, кто не знает, одна из самых популярных реализаций этих ваших Agile.
Скрамят у нас все и вся: от дизайнеров и контент-менеджеров до архитекторов и прогеров. Единственные отделы, где скрама нет - техподдержка, hr и бухгалтерия (хотя я уверен, и им пытались это втюхать).
Как так вообще получилось? Несколько лет назад генеральный решил, что контора станет пионером технологий и методологий.
По такому поводу на ютубе до сих пор висит бородатый видос, где наш, тогда еще чисто голландский, ИТ департамент говорит о преимуществах Скрам (https://youtu.be/FHHSlJQS5nY).
Тут надо еще сказать про компанию: начинаясь как маленький интернет магазин mp3 плееров, контора начала активно и быстро расти, благо ее рассвет пришелся на бум доткомов. Таким образом компания до сих пор, имея все отличительные черты махрового энтерпрайза, ведет себя как стартап. И как любой уважающий себя стартап она примеряет на себе все новое, не боясь никаких последствий. Одним из таких нововведений и стал Скрам, на который посадили всех.
YouTube
Referentie: Scrum implementatie
ISense Prowareness heeft webshop gigant Coolblue geholpen bij 'elke dag een beetje beter'. Deze biedt in drie minuten een prima inzicht in het doorlopen van ...
Что у нас это в принципе представляет: есть продукт (или несколько продуктов) и есть команда из разных специалистов (в моем случае инженер-линуксоид, мультифункциональный скрам-мастер и мужик, который на SCCM собаку съел). Продуктов у нас несколько, начиная от всего, что связано с автоматизацией рабочего места (почта, программы по умолчанию, да даже как вам компьютер приготовить), заканчивая системами для collaboration (JIRA, Confluence, Slack, Google Apps и так далее).
Каждый продукт - это один большой проект длиной в бесконечность и каждое требование, называемое user story, идет в беклог (список историй от людей). Специально обученный проджект менеджер, именуемый product owner, расставляет приоритеты историям, планирует будущие спринты (о них чуть позже), общается с потенциальными заказчиками и помогает перевести запрос с человеческого на итшнический.
Когда набор историй готов, вся команда дружно собирается и разговаривает. Разговаривает много, с толком и без, со смыслом и без, но в итоге договаривается какие задачи можно сделать, а какие нет.
Все подтвержденные задачи формируются в спринт - двухнедельный этап проекта, с задачами по приоритету сверху вниз. Задача команды - выполнить все задачи в строго отведенный двух (или более - это уже как кто практикует) недельный срок.
У каждой задачи есть story point'ы - абстрактная мера измерения, сколько "усилий" уйдет на задачу. Если слишком высокая оценка - смотрят, еще раз обсуждают, разбивают на части по возможности.
Приправьте это ежедневными планерками, "оценочными" болтальными встречами и целым днем закрытия/открытия спринта - вот вам и Скрам.
Каждый продукт - это один большой проект длиной в бесконечность и каждое требование, называемое user story, идет в беклог (список историй от людей). Специально обученный проджект менеджер, именуемый product owner, расставляет приоритеты историям, планирует будущие спринты (о них чуть позже), общается с потенциальными заказчиками и помогает перевести запрос с человеческого на итшнический.
Когда набор историй готов, вся команда дружно собирается и разговаривает. Разговаривает много, с толком и без, со смыслом и без, но в итоге договаривается какие задачи можно сделать, а какие нет.
Все подтвержденные задачи формируются в спринт - двухнедельный этап проекта, с задачами по приоритету сверху вниз. Задача команды - выполнить все задачи в строго отведенный двух (или более - это уже как кто практикует) недельный срок.
У каждой задачи есть story point'ы - абстрактная мера измерения, сколько "усилий" уйдет на задачу. Если слишком высокая оценка - смотрят, еще раз обсуждают, разбивают на части по возможности.
Приправьте это ежедневными планерками, "оценочными" болтальными встречами и целым днем закрытия/открытия спринта - вот вам и Скрам.
С "что это" разобрались, теперь "зачем это".
Изначально классические методологии управления проектами базировались на строгом соблюдении требований. То есть заказчик подписывает бумажку со списком задач к реализации, а исполнитель обязуется выполнить все в срок.
Ничего плохого в этом нет, но заказчик нет-нет да откажется от какой-то из фич, а другие нужны будут ему раньше.
Из этого родился Agile Manifesto (http://agilemanifesto.org/), люди видели во всем этом большую проблему и пришли с манифестом - мол вот как надо и давайте все вместе будет так делать.
Разница в том, что Agile - это не методология, а культура разработки, на основе которой и появились методологии. Scrum, Kanban, XP и прочие - все это результат внедрения культуры в процесс.
У каждой "гибкой" методологии есть свои преимущества и недостатки. Я не буду покрывать все, так как мы говорим только о Скрам.
Скрам безусловно подойдет командам разработки, которые делают продукт для массового пользования. Когда ваш условный клиент это любой пользователь интернета, объем хотелок может быть просто огромным, и в этом плане Скрам с "беклогом" подходит как нельзя лучше.
Что так же важно, работая по гибкой методике, будучи готовыми перелопатить весь продукт с нуля, вы пишете приложение, взяв за основу правило: "продукт должен быть максимально гибким и расширяемым."
Другим преимуществом является скорость доставки. Вы доставляете не 10 фич через год, а по 2-3 фичи каждый месяц (в зависимости от сложности).
Но у Скрама есть и недостатки. Так, например, ваша команда должна быть кросс-функциональной, что с одной стороны хорошо, но с другой - недостижимо. У вас не может быть разработчика с навыками сисадмина, дизайнера и тестироващика одновременно. Он может "что-то понимать" в этом, но экспертную оценку дать не может по умолчанию. Другой недостаток - строгое соблюдение всех процессов - все без исключения митинги должны быть вовремя, на них должны присутствовать все без исключения. Поверьте, поначалу это кажется нормальным, но в какой-то момент вечные болталки утомляют (разрабы интроверты меня поймут).
Но это уже условности, да и несерьезно жаловаться на календарь полный митингов и синков. Реальная проблема Скрама - не все можно под него подстроить, особенно когда речь идет об инженерном внедрении, а не о разработке.
Скрам хорош, когда у вас маленький продукт, и вы не знаете, что из него вырастет. Другое дело, когда вы внедряете готовый коробочный продукт. Вот, например, SCCM как в нашем случае. Наша проблема была в том, что первые спринты у нас были чистые итерации по установке, настройке и пусконаладке. Итог спринта Скрам - появляется что-то, чем можно пользоваться. У нас же 4 спринта (2 месяца) заняло эту махину собрать, поставить и хоть как-то запустить. Ни о каких deliverables речи и не могло быть.
И в принципе мы не одни такие. Другие инженерные группы (ребята по мониторингу, инженеры-инфраструктурщики, админы баз данных) страдают не меньше нашего, поскольку показывать буквально нечего.
- Что вы сделали?
- Мы обновили прошику роутеров ядра.
- Что мы от этого получаем?
Да ничего вы не получаете, аптайм больше будет. :)
Хотя если вы спросите меня, гибкие методики лучше чем классика, хотя я терпеть не могу Скрам (мне больше Канбан по душе).
Изначально классические методологии управления проектами базировались на строгом соблюдении требований. То есть заказчик подписывает бумажку со списком задач к реализации, а исполнитель обязуется выполнить все в срок.
Ничего плохого в этом нет, но заказчик нет-нет да откажется от какой-то из фич, а другие нужны будут ему раньше.
Из этого родился Agile Manifesto (http://agilemanifesto.org/), люди видели во всем этом большую проблему и пришли с манифестом - мол вот как надо и давайте все вместе будет так делать.
Разница в том, что Agile - это не методология, а культура разработки, на основе которой и появились методологии. Scrum, Kanban, XP и прочие - все это результат внедрения культуры в процесс.
У каждой "гибкой" методологии есть свои преимущества и недостатки. Я не буду покрывать все, так как мы говорим только о Скрам.
Скрам безусловно подойдет командам разработки, которые делают продукт для массового пользования. Когда ваш условный клиент это любой пользователь интернета, объем хотелок может быть просто огромным, и в этом плане Скрам с "беклогом" подходит как нельзя лучше.
Что так же важно, работая по гибкой методике, будучи готовыми перелопатить весь продукт с нуля, вы пишете приложение, взяв за основу правило: "продукт должен быть максимально гибким и расширяемым."
Другим преимуществом является скорость доставки. Вы доставляете не 10 фич через год, а по 2-3 фичи каждый месяц (в зависимости от сложности).
Но у Скрама есть и недостатки. Так, например, ваша команда должна быть кросс-функциональной, что с одной стороны хорошо, но с другой - недостижимо. У вас не может быть разработчика с навыками сисадмина, дизайнера и тестироващика одновременно. Он может "что-то понимать" в этом, но экспертную оценку дать не может по умолчанию. Другой недостаток - строгое соблюдение всех процессов - все без исключения митинги должны быть вовремя, на них должны присутствовать все без исключения. Поверьте, поначалу это кажется нормальным, но в какой-то момент вечные болталки утомляют (разрабы интроверты меня поймут).
Но это уже условности, да и несерьезно жаловаться на календарь полный митингов и синков. Реальная проблема Скрама - не все можно под него подстроить, особенно когда речь идет об инженерном внедрении, а не о разработке.
Скрам хорош, когда у вас маленький продукт, и вы не знаете, что из него вырастет. Другое дело, когда вы внедряете готовый коробочный продукт. Вот, например, SCCM как в нашем случае. Наша проблема была в том, что первые спринты у нас были чистые итерации по установке, настройке и пусконаладке. Итог спринта Скрам - появляется что-то, чем можно пользоваться. У нас же 4 спринта (2 месяца) заняло эту махину собрать, поставить и хоть как-то запустить. Ни о каких deliverables речи и не могло быть.
И в принципе мы не одни такие. Другие инженерные группы (ребята по мониторингу, инженеры-инфраструктурщики, админы баз данных) страдают не меньше нашего, поскольку показывать буквально нечего.
- Что вы сделали?
- Мы обновили прошику роутеров ядра.
- Что мы от этого получаем?
Да ничего вы не получаете, аптайм больше будет. :)
Хотя если вы спросите меня, гибкие методики лучше чем классика, хотя я терпеть не могу Скрам (мне больше Канбан по душе).
agilemanifesto.org
Manifesto for Agile Software Development
We are uncovering better ways of developing software
by doing it and helping others do it. These are our
values and principles.
by doing it and helping others do it. These are our
values and principles.
https://www.ucheba.ru/article/5115?utm_referrer=https%3A%2F%2Fzen.yandex.com
Обожаю такие статьи. Про ИТ все как всегда, ИТшник он интроверт, но вот это добило.
"Системным администраторам все-таки приходится коммуницировать с людьми, но программисты могут работать в офисе по индивидуальному графику (например, даже глубокой ночью) или удаленно. Из интровертов-технарей также получаются хорошие верстальщики и тестировщики."
Во-первых, системный администратор (который отвечает за серверы) с людьми общается редко (я об этом в своем самом первом посте писал), а тот кто общается много, это хэлпдеск, и к системному администратору он не имеет никакого отношения.
Во-вторых, большинство программистов сейчас так или иначе работает по модным методикам и разговаривает много. Очень много. Причем не только друг с другом, но и с руководителями проектов, тимлидами, пользователями и прочими.
В-третьих, конечно программист может работать по индивидуальному графику, удаленно по ночам и т.д. (таких в мире аж целых пара процентов, все остальные работают по классике с 9 до 18), но каким образом это зависит от его интраверсии - непонятно. Прогер такая же творческая личность и пашет тогда, когда припрет, и точно так же работают дизайнеры, писатели, журналисты и художники.
Мария Рамзаева, зачем вводите молодежь в заблуждение?
Запомни, студент, мир ИТ полон не только модных рюшечек и сложных задач с неадекватными сроками, но и людьми, которым очень интересно, почему у тебя на одном экране вКонтакте, а на другой буквы какие-то непонятные.
Обожаю такие статьи. Про ИТ все как всегда, ИТшник он интроверт, но вот это добило.
"Системным администраторам все-таки приходится коммуницировать с людьми, но программисты могут работать в офисе по индивидуальному графику (например, даже глубокой ночью) или удаленно. Из интровертов-технарей также получаются хорошие верстальщики и тестировщики."
Во-первых, системный администратор (который отвечает за серверы) с людьми общается редко (я об этом в своем самом первом посте писал), а тот кто общается много, это хэлпдеск, и к системному администратору он не имеет никакого отношения.
Во-вторых, большинство программистов сейчас так или иначе работает по модным методикам и разговаривает много. Очень много. Причем не только друг с другом, но и с руководителями проектов, тимлидами, пользователями и прочими.
В-третьих, конечно программист может работать по индивидуальному графику, удаленно по ночам и т.д. (таких в мире аж целых пара процентов, все остальные работают по классике с 9 до 18), но каким образом это зависит от его интраверсии - непонятно. Прогер такая же творческая личность и пашет тогда, когда припрет, и точно так же работают дизайнеры, писатели, журналисты и художники.
Мария Рамзаева, зачем вводите молодежь в заблуждение?
Запомни, студент, мир ИТ полон не только модных рюшечек и сложных задач с неадекватными сроками, но и людьми, которым очень интересно, почему у тебя на одном экране вКонтакте, а на другой буквы какие-то непонятные.
www.ucheba.ru
Где работать интроверту
7 сфер, где нужны люди, не склонные к общению.
Вчера имел удовольствие поиграться с такой прекрасной штукой, как "Машина морали" - проект МИТ (http://moralmachine.mit.edu/), в котором пользователю предлагаются разные сценарии с участием беспилотных авто, эмулирующие катастрофу.
В каждом вопросе показывается два сценария аварии, где кто-то гарантированно погибает, и пользователю предлагается выбрать, кто должен умереть. Создатели проекта заявляют, что собранные ответы будут использованы для ИИ автопилота.
Вопрос решения, которое принимает беспилотный автомобиль в случае гарантированной аварии, рассматривается давно и мучает немалое количество ученых и инженеров со всего мира. Кого сбивать? Ребенка или женщину? 10 женщин или 10 мужчин? Богатого или бедного? На такие вопросы и нужно отвечать пользователю.
Безусловно эту тему надо обсуждать и поднимать каждый раз, когда решения ИТ проникают в жизнь простых людей и общества.
Но я, как инженер, не понимаю риторики.
Когда я проектирую решение, я в первую очередь рассматриваю различные риски и способы их ликвидации, но помимо этого - как сделать так, чтобы решение не ломалось в принципе. Если я буду проектировать беспилотное авто, первое, на чем я буду фокусироваться - это недопущение подобных дилемм .
Задача беспилотного автомобился не определять, кто должен жить, а кто нет. Его задача - не допускать смертей в принципе.
В каждом вопросе показывается два сценария аварии, где кто-то гарантированно погибает, и пользователю предлагается выбрать, кто должен умереть. Создатели проекта заявляют, что собранные ответы будут использованы для ИИ автопилота.
Вопрос решения, которое принимает беспилотный автомобиль в случае гарантированной аварии, рассматривается давно и мучает немалое количество ученых и инженеров со всего мира. Кого сбивать? Ребенка или женщину? 10 женщин или 10 мужчин? Богатого или бедного? На такие вопросы и нужно отвечать пользователю.
Безусловно эту тему надо обсуждать и поднимать каждый раз, когда решения ИТ проникают в жизнь простых людей и общества.
Но я, как инженер, не понимаю риторики.
Когда я проектирую решение, я в первую очередь рассматриваю различные риски и способы их ликвидации, но помимо этого - как сделать так, чтобы решение не ломалось в принципе. Если я буду проектировать беспилотное авто, первое, на чем я буду фокусироваться - это недопущение подобных дилемм .
Задача беспилотного автомобился не определять, кто должен жить, а кто нет. Его задача - не допускать смертей в принципе.
Moral Machine
A platform for public participation in and discussion of the human perspective on machine-made moral decisions
Сейчас вспомнил одну историю про гигантский факап компании Amazon Web Services (провайдер облачных услуг).
У Амазона есть сервис под названием S3 (Simple Storage Service) - облачное хранилище с неограниченным объемом данных. Люди используют его, чтобы держать там файлики, с которыми предстоит работать людям или системам. Особенность этого сервиса с его очень приличной отказоустойчивостью в том, что данные хранилища реплицируются (читай синхронизируются) между разными датацентрами на территории так называемого региона (будь то страна или континент).
То есть если ударить бомбой по целому городу, где есть датацентр Амазона, на работе это не отразится совсем.
Круто, да? Вот ради такого стоит любить свою профессию.
Однако в 28 февраля 2017 года сервис перестал работать в регионе Северная Вирджиния, что привело к отказу огромного количества систем. Среди именитых пострадавших такие персонажи как Snapchat и Razer.
Я уже молчу про множество Internet of Things продуктов, которые критично зависели от Амазона. Дошло до абсурда, что люди не могли сменить dpi рейзеровской мыши, а у других товарищей не работал пульт от умного телевизора.
Вы просто вдумайтесь - вы не можете поменять настройки мыши, потому что в нескольких сотнях километров от вас отвалился ЦОД, да еще и не один.
У Амазона есть сервис под названием S3 (Simple Storage Service) - облачное хранилище с неограниченным объемом данных. Люди используют его, чтобы держать там файлики, с которыми предстоит работать людям или системам. Особенность этого сервиса с его очень приличной отказоустойчивостью в том, что данные хранилища реплицируются (читай синхронизируются) между разными датацентрами на территории так называемого региона (будь то страна или континент).
То есть если ударить бомбой по целому городу, где есть датацентр Амазона, на работе это не отразится совсем.
Круто, да? Вот ради такого стоит любить свою профессию.
Однако в 28 февраля 2017 года сервис перестал работать в регионе Северная Вирджиния, что привело к отказу огромного количества систем. Среди именитых пострадавших такие персонажи как Snapchat и Razer.
Я уже молчу про множество Internet of Things продуктов, которые критично зависели от Амазона. Дошло до абсурда, что люди не могли сменить dpi рейзеровской мыши, а у других товарищей не работал пульт от умного телевизора.
Вы просто вдумайтесь - вы не можете поменять настройки мыши, потому что в нескольких сотнях километров от вас отвалился ЦОД, да еще и не один.