Программист
Летом 2020 года GitHub позволила пользователям создавать персональные README-файлы и с их помощью кастомизировать свои профили. Сама платформа при создании подобного файла предлагает уже готовый шаблон, в который можно вписать свои данные. Но о какой кастомизации может идти речь, если у всех будут одинаково оформленные профили? За почти два года сообщество придумало множество различных способов выделиться и особенно оформить свою страницу на GitHub.
Опыт показывает, что разработчики редко задумываются о проблемах, которые могут возникать при многопользовательском доступе к данным. При этом практически любое web-приложение является многопользовательским и так или иначе использует блокировки при доступе к данным в БД. При неправильном использовании эти блокировки могут больно бить по пользователям, а иногда и по системе в целом. Поэтому рано или поздно каждый разработчик многопользовательских систем должен задуматься о том, как ему начать работать с БД так, чтобы пользователи не мешали другу другу. Многие считают, что это сложно, давайте вместе убедимся, что это не так.
— Ямщик, а далеко до релиза?
— Да пара вёрсток.
Докатился — пишу на Хабр о том, как писать на Хабр. Хотя причины есть — я пять лет занимаюсь этим, перевидал и перепробовал кучу инструментов, так что теперь делюсь с вами самыми лучшими.
Я расскажу о том, как прийти от HTML-разметки в Хабраредакторе к осмысленной вёрстке, быстрому оформлению постов и продуктивной совместной работе. Здесь — о моём опыте в Яндекс.Деньгах и о том, как я организовал работу над хабратекстами, чтобы не было мучительно больно.
Всем привет! Сегодня мы бы хотели рассказать об одной старой и почти всеми забытой атаке под названием DNS rebinding. Первые разговоры о ней начались еще в 2007 году, однако тогда эксперты из области практической информационной безопасности не уделяли ей должного внимания в связи с особенностями эксплуатации этой атаки, а также мало ощутимыми, как тогда казалось, последствиями. Сегодня мы попробуем убедить в обратном их и вас, в частности, продемонстрировав, что в современном мире эта атака обрела второе дыхание и более не кажется такой безобидной.
Люди, интересующиеся темой блокчейна, уже не раз слышали о проекте российско-канадского программиста Виталика Бутерина — Ethereum, а в вместе с ним и о так называемых умных контрактах. В данном цикле статей я постараюсь максимально просто описать суть Ethereum, умных контрактов, концепцию газа и показать, как пишутся умные контракты.
Если на пальцах, "умный контракт" — это некоторый код, живущий внутри блокчейна. Любой участник сети может его вызвать за небольшую плату. Эта плата и называется Gas, дословно "топливо". Зачем это нужно? Для защиты майнера от злоупотребления мошенником его ресурсов.
Немногие знают, но даже в биткоине есть возможность писать эти самые контракты, но в силу некоторых причин этим мало кто занимается. Одна из главных проблем — язык Script не Тьюринг-полный и написать что-то более менее серьезное непросто (чтобы вы понимали масштаб проблемы — нет даже возможности добавить цикл). В случае с Ethereum все чуть по другому, языки Тьюринг-полные, и есть риск, что кто-то напишет контракт вида
// Это псевдокод
foo = 0;
while (True) {
foo++;
}Понятно, что майнер, запустивший этот контракт, закончит нескоро и по факту просто потратит в никуда свои ресурсы. Вот чтобы такого не произошло, разработчики Ethereum и придумали газ — в реальности запускать код вроде того, что я написал, будет просто экономически нецелесообразно, потому что вызвавшему придется заплатить за каждое действие контракта.
Эта статья является продолжением цикла о написании умных контрактов на платформе Ethereum. В первой части я пообещал показать, как создать новую криптовалюту на Solidity (в мире блокчейна это является чем-то вроде аналога "Hello, world!"). Но на самом деле в этом нет смысла, так как об этом уже написано несколько хороших статей (пример из доков Solidity, пример с главной страницы Ethereum).
Так что я немного подумал и нашел еще один use case для умных контрактов. В данной статье я покажу, как теоретически автор трояна-шифровальщика может монетизировать свое детище, продавая ключи для расшифровки с помощью умных контрактов.
BTW все написанное ниже имеет чисто образовательный характер.
