О чём эта статья

Это не история успеха, потому что в Амазон меня не взяли, но и не история полного лузера, который бомбит из-за своей тупости, ибо позже я прошел в Майкрософт, о чем будет отдельный пост. 

Это история о моем опыте собеседования в Амазоне, почему мне в целом не понравилось по сравнению с другими FAANG. Так же тут будут ответы на “а что конкретно спрашивали на интервью, какие были задачки, что на систем дизайне было”, потому что мне не дали подписать NDA, все с пруфами, скринами и прочее.

В общем и целом, статья будет о моем опыте, какие были интервью, что было сложного, что не очень, как я готовился, и какая доля везения в этом всем.

Начало, предложение от Amazon

В один прекрасный день 6 сентября, мне пришел такой сообщение в Линкедин.

Когда я говорю о неэффективности популярных блокчейнов; или упоминаю то, что мы, похоже, мчимся к web3, централизованному настолько, что это бросает вызов крепкой хватке больших технологических компаний современного веба; или указываю на то, что почему-то никому не удалось найти хороший способ применения блокчейна, который был бы лучше, чем альтернативные варианты его не использующие, я часто слышу: «Это ещё ранние дни», «Всё только начинается», «Дай ему шанс», «Люди всё ещё разбираются во всех этих блокчейн-технологиях, устраняя их недостатки»...

Привет! Меня зовут Кирилл Небогин, я руковожу разработкой блокчейн-платформы в Waves Enterprise. Мы привыкли, что новости о блокчейне обычно связаны с рынком криптовалют. Но есть и другие интересные сценарии применения блокчейна, на которых мы в компании и фокусируемся. В этой статье на примере истории нашей платформы я расскажу, как блокчейн приходит в бизнес, в государственные проекты и какие технические (и не только) сложности с этим связаны.

Основатель Signal написал на прошлой неделе сильный текст о проблемах web3 и, в частности, NFT.

Привожу краткое саммари статьи + дискуссии о перспективах самой модной (по ожиданиям венчурных капиталистов) темы 2022 года. Высказались в том числе фаундер Metamask и создатель Ethereum.

И зову вместе разбираться, обоснован ли хайп.

Proof of Stake (PoS) – это мошенничество. Когда я говорю это, я имею в виду, что PoS 1) заявлен как система консенсуса, и 2) фактически неспособен на самом деле обеспечить консенсус.

Несмотря на то, что я считаю себя криптографом, меня не особенно привлекает слово "крипто". Не думаю, что я уже староват, но я гораздо чаще кликаю на мемы в духе "Интернет всё помнит" о том, как "крипто" раньше означало "криптография", чем на последние новости об NFT.

Но учитывая всё то внимание, которое в последнее время уделяется тому, что сейчас называют web3, я решил более тщательно изучить всё происходящее в этой сфере, чтобы точно ничего не упустить...

Мне понравился опыт прошлого расследования по фейсбуку, и я решил организовать очередную серию, теперь про Amazon. Для нетерпеливых — в самом конце статьи описан итоговый вариант архитектуры Amazon S3 и проанализированы его свойства.

Не так давно Амазон объявил о переходе S3 с модели eventual consistency на strong consistency, то есть, предоставления гарантии read-after-write, чтения того, что было только что записано. Сообщество отреагировало, но как-то очень вяло: Amazon S3 Now Delivers Strong Read-After-Write Consistency

Первое, что лично мне подумалось в ответ на эти новости: а как же теорема CAP?

Сейчас регулярно выходят анонсы про NFT-metaverse-блокчейн-игры, которые привлекали инвестиции в миллионы долларов по оценке в миллиарды, но при изучении проектов там оказываются либо плашки Coming Soon, либо продажа JPG-картинок на аукционах NFT-токенов, либо централизованные проекты с гомеопатическими дозами блокчейна. Перед тем, как окрестить это всё пузырем хайпа, но я решил разобраться в технологическом стеке самостоятельно и сделать свою блокчейн-игру с NFT, потратив минимум ресурсов. Читайте под катом как у меня это получилось всего за 2 дня, а также покупайте мои NFT (нет).

С появлением онлайн-кинотеатров и стриминговых сервисов популярность торрент-клиентов пошла на спад, однако на момент публикации с помощью торрента файлы скачивают за день около четырех процентов всех пользователей Интернета (это более 100 миллионов человек). 

В данной статье я проведу небольшой обзор P2P(пиринговых) файлообменных протоколов, Napster, Gnutella и BitTorrent. В этой последовательности они появились, и каждый был вдохновлён предыдущим, взял от него лучшее и добавил своё. Каждый из этих протоколов в своё время был прорывом в обмене файлами.

В последнее время появляется все больше новостей о революционных достижениях в области квантовых вычислений, которые могут заметно повлиять на наши представления о стойкости криптографических алгоритмов. Это накладывает определенные ограничения на развитие технологий распределенных баз данных, состоящих из цепочек блоков, связанных хеш-суммой, так называемого блокчейна. 

Но представляют ли эти достижения реальную опасность для блокчейна будущего? Нужно ли бежать обналичивать свои биткоины и прятать их под бабушкин матрас при первой новости о создании рабочего квантового компьютера? Скорее всего нет и вот почему.

Привет Хабр. 

В прошлых статьях мы научились генерировать 10 000 изображений для нашей NFT коллекции с помощью Golang, а также загрузили все сгенерированные изображения в децентрализованное хранилище IPFS.

В этой статье мне хотелось бы поделиться знаниями и опытом, а также о подводных камнях, с которыми мне пришлось столкнуться при разработке смарт-контрактов для NFT коллекций на блокчейне Ethereum.

Мы создадим типовой смарт-контракт для нашей NFT коллекции, протестируем и загрузим созданный смарт-контракт в тестовую сеть Ethereum. Но прежде, чем мы приступим к кодингу, мне хотелось бы остановиться на ERC-721 стандарте, данный стандарт описывает спецификацию NFT токенов.

Была у меня мечта - писать backend на C++. А вот разбираться в unix socket'ах, TCP, многопоточной/асинхронной обработке запросов и во многом другом совсем не хотелось. Не верил я, что до сих пор нет каких-то минималистичных фреймворков. И сегодня я вам расскажу, как можно просто сделать HTTP API микросервис на C++ с помощью фреймворка Drogon.

Привет Хабр.

В прошлой статье, мы научились генерировать изображения для NFT коллекции, а сегодня я хочу рассказать, как и куда можно опубликовать сгенерированные изображения и их метаданные.

Потратив достаточно много времени на изучение существующих NFT проектов, я был свидетелем, как разработчики публикуют свои изображения для NFT коллекций в централизованные файловые системы, такие как AWS s3, что вызывало у меня некоторое недоумение. 

На мой субъективный взгляд, главный посыл NFT токенов, именно в том, что токен и его содержимое - никто и никогда не сможет изменить, и соответственно при разработке мы должны быть максимально абстрагирован от централизованных систем. Именно поэтому, публиковать все наши файлы, мы будем в децентрализованное хранилище - IPFS.

Привет Хабр.

История началась пол года назад, когда ко мне пришел мой старый знакомый художник и предложил создать NFT коллекцию на блокчейне Ethereum. Скажу сразу, я никогда не интересовался криптой и на тот момент понятие не имел, что такое NFT и как они устроены. 

В этой статья я не буду рассказывать, что такое NFT и для чего они нужны, вместо этого я сосредоточусь на технической части, т.к. когда я начинал материала было крайне мало и приходилось додумывать некоторые решения самому.

Какой самый частый комментарий после запуска Хабра-АДМ? Верно! "Пора делать пост Хвастовства." Что ж, пора - значит пора!

Пост Хвастовства объявляется открытым!

С НАСТУПАЮЩИМ НОВЫМ 2022 ГОДОМ!

PS: А если вам кажется, что комментариев пока слишком мало, можете посмотреть, как это было в прошлых сезонах: 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020.

Обычно с помощью CDN ускоряют доставку статического контента. Спрашивается, почему бы не использовать сеть и для динамических приложений? Проблема в том, что для этого подходит далеко не каждая CDN. Как выбрать среди них правильную и на какие технологии обращать внимание — в нашем обзоре.

Проблема оракулов в блокчейн — одно из самых важных препятствий, если смарт-контракты построенные на базе сетей, таких как Ethereum, хотят достичь повсеместного применения в различных рынках и индустриях.

Смарт-контракты представляют огромный потенциал преобразить то, как независимые структуры вступают в контрактные обязательства и производят платежи. Отдельно от индустрии смарт-контрактов, мы имеем огромную традиционную цифровую экономику, состоящую из множества устройств, связанных с помощью интернета, и производящих вычисления онлайн. Производный продукт такой цифровой инфраструктуры — постоянно увеличивающийся объем данных и API, который дает представление о том как все в нашем мире работает; например, результаты поиска, выдающие самые популярные темы, или сенсоры IoT (Internet of Things или Интернет Вещей) предлагающие наиболее распространенные модели трафика.

Смарт-контракты построенные на блокчейн и традиционные базы данных и API имеют огромный потенциал для объединения в гибридные смарт-контракты и создания новой архитектуры для автоматизации баз данных. Но как связать эти два мира? В этом и заключается “Проблема оракулов” — главная тема этой статьи.

Статья разделена на пять частей:

Для кого эта статья? Эта статья, также как и первая, рассчитана на людей, работающих в сфере ИТ.  Для разработчиков, тестировщиков, менеджеров разного уровня, аналитиков и т.д. Для расширения кругозора, она также может быть полезна и всем остальным, просто, чтобы иметь представление о том, чем занимается Системный Архитектор.  Пригодится материал и тем, кто планирует развитие своей профессиональной карьеры, и тем, кто выкладывает такого рода вакансию и ищет специалиста в команду.

Что еще? Думаю что надо как то договорится о подаче материала. Здесь, как и в первой статье, я рассмотрю конкретный пример из своей практики, который, как мне кажется, максимально точно иллюстрирует специфику работу данного специалиста. Как и раньше, в заключении, попробую ответить на следующие вопросы: кто такой Системный Архитектор, какими навыками должен обладать и т.д. Поехали? 

И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

Автор выражает благодарность людям, которые помогли в написании статьи:

И в особенности Махешу Балакришнану, к числу почитателей которого я присоединился:

Ничто как фундаментальный архитектурный подход

Привет, Хабр! Меня зовут Роман, я работаю разработчиком в компании Arenadata, где мы решаем много задач, связанных с Greenplum. Как-то мне представился случай разобраться с одним непростым, но вполне типичным для этой СУБД кейсом. Необходимо было выяснить, на обработку каких запросов уходит неадекватно много системных ресурсов. В этой статье мне бы хотелось поделиться своими наработками и рассказать о трёх проверенных мной способах мониторинга утилизации системных ресурсов, потребляемых запросами в Greenplum.