Как стать автором
Обновить
383
159
Дмитрий Брайт @Bright_Translate

Переводчик

Отправить сообщение

Не бойтесь бросать свои пет-проекты

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров3K


Веб-индустрия переполнена историями о пет-проектах, которые переросли в успешный бизнес. Вот и я нередко увлекаюсь какими-нибудь идеями после основной работы. И хотя это определённо заманчивая перспектива, работа над личным проектом не всегда столь лучезарна – порой они просто не выгорают. Если вы читаете эту статью, то есть вероятность, что вы недавно отказались (или подумываете отказаться) от своего пет-проекта. В таком положении находились многие из нас. Да что тут говорить, заброшенные личные проекты даже стали своего рода мемом в среде разработчиков.

Тем не менее ко мне часто обращаются начинающие программисты за советом, и в последнее время их всё чаще беспокоит то, что у них не получается реализовывать пет-проекты так быстро или так часто, как хотелось бы. И такая тревожность абсолютно понятна. Когда в среде разработки господствует культура сверхактивности и концепция «непрерывной поставки», а на технических собеседованиях кандидатов зачастую оценивают на основе результатов их «внештатного программирования» (имеются в виду хакатоны, клубы программистов и прочее, — прим. пер.), заброшенные пет-проекты перестают казаться чем-то забавным. И мне это не нравится.

Мы слышим столько историй об успешных личных проектах, но что, если более открыто говорить о тех, которые провалились? Многие из нас проводят ретроспективный анализ на работе, но не в отношении пет-проектов. А почему бы нам не пролить свет на всё то время, которое было вложено в начинания, которые так и не ожили? На заброшенное ПО, которое в своё время казалось хорошей идеей. По нашим средам разработки до сих пор скитаются духи захороненных каталогов node_modules.

И здесь я хочу рассказать о своём недавнем пет-проекте, который забросил в тот же день, в который запустил.
Читать дальше →
Всего голосов 25: ↑26 и ↓-1+27
Комментарии10

Эффект Монреаля: почему языкам программирования нужен Царь стилей

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров9.1K

Давайте представим нереалистичный сценарий, где вы выбираете язык программирования для проекта, который в перспективе станет очень большим. Допустим, это будет набор сервисов в монорепозитории, над которыми работает более 100 человек. Чтобы сделать этот сценарий ещё менее реалистичным, предположим, что вы игнорируете типичные ограничения, например, не учитываете, сможете ли использовать сборщик мусора, и впишется ли поставленная задача в конкретный стек технологий.

Пусть это будет мысленный эксперимент. Подыграйте мне. Если вы читали мою прошлую статью (англ.), то должны правильно предположить, что я бы предпочёл экспрессивный язык, ориентированный на профессионалов. Так и есть. Но в гибком языке программирования есть серьёзная проблема с масштабированием – слишком много стилей оформления кода и способов его написания. В итоге просто не обойтись без руководств по стилю, которые помогут сориентироваться в правильной реализации.

Какое подмножество C++ или Kotlin вы используете? Что вы предпочтёте: project.toml или requirements.txt? Теперь у вашего языка есть возможность поэтапной типизации с помощью аннотаций типов. Хотите ей воспользоваться? Как вы реализуете конкурентность: с помощью многопоточности, Tokio или std::async?

Чем более экспрессивный язык, тем сложнее всё становится. И здесь на сцену выходит Go. И речь не только о gofmt, но и о его стандартной библиотеке и согласованности. В Kotlin вам приходится гадать, что лучше использовать для ошибок: исключения или объекты Result? В случае же Go вам всё ясно – ищем err. Да, это многословно, но зато предсказуемо.

Экспрессивные языки прекрасны, но часто создают путаницу. Вы можете использовать богатый и комплексный язык, поддерживающий миллион способов реализации одного и того же. Именно это я хочу вам показать. Как же сохранить всю эту мощь, но уменьшить беспорядок? Как избежать возникновения 500 поддиалектов? Но прежде, чем переходить к решениям, обсудим Scala.
Читать дальше →
Всего голосов 49: ↑51 и ↓-2+53
Комментарии21

Этот опасный рефакторинг

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров6.2K

Ошибки во время рефакторинга могут дорого обойтись. Модернизация, ведущая к отказу системы, или внесение новой функциональности параллельно с ошибочными правками явно принесут вред. Но степень вреда может быть разной.
Читать дальше →
Всего голосов 41: ↑39 и ↓2+37
Комментарии19

Делаем код-ревью правильно

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров19K

В начале своей карьеры я как-то работал над одним заказом, создавая платформу сентимент-анализа для социальных сетей. В то время Twitter ещё был Twitter’ом. Наша команда состояла из семи человек, среди которых я был джуниором. Мы были молоды и полны энтузиазма. Наш девиз можно было описать как: «Мы гибкие, быстрые и всё ломаем!». Да, мы действительно гордились своей скоростью. Код-ревью? Я вас умоляю. Мы считали эту практику бюрократическим пережитком корпоративного мира.

И что вы думаете? Через несколько месяцев наша база кода стала подобна минному полю. Причём баги нас волновали меньше всего, хотя их была уйма. Реальная проблема заключалась в том, что никто не мог понять код, написанный другими. У нас во многих местах дублировалась логика, и в модулях использовались разные стили кода. Всё было очень печально.

Тогда до нас дошло! Нужно взять всё под контроль. Код-ревью реально помогают сохранять код читаемым, обслуживаемым и масштабируемым.

Итак, в двух словах: если вы не проводите код-ревью, или делаете их «для галочки», то обрекаете себя на боль, пусть не сразу, но в конечном итоге однозначно. Это можно сравнить с возведением дома на фундаменте из песка. Какое-то время он, может, и простоит, но явно недолго. А в мире стартапов второго шанса у вас может уже не быть.
Читать дальше →
Всего голосов 73: ↑71 и ↓2+69
Комментарии24

Как я выиграл Хакатон, едва не потеряв рассудок

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров12K

Несколько недель назад мы с моим другом Беном выиграли JumboHack, Хакатон, проводившийся в Университете Тафтса. Нашим проектом было приложение, которое в стиле Spotify Wrapped генерирует отчёт по питанию в университетских столовых среди студентов на основе данных из раздела «Meal Plan» портала оплаты услуг. Благодаря грамотному продвижению проекта Беном, мы смогли буквально за пару дней привлечь к использованию нашего приложения сотни студентов. В итоге мы победили в общей номинации, а также в номинации «самый завершённый проект» и стали абсолютными победителями конкурса.

Живое демо нашего проекта доступно здесь.
Читать дальше →
Всего голосов 40: ↑38 и ↓2+36
Комментарии8

Реверс-инжиниринг сигнала автомобильного брелка

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров12K

Я уже пару лет как изучаю протоколы радиосвязи. Началось это с момента, когда я из любопытства решил поэкспериментировать с USB-донглом RTL-SDR. Мне всегда хотелось понять, как передаются данные в пультах дистанционного управления (в частности, автомобильных брелках), попробовать перехватить их сигнал и выяснить, какие ещё в этом случае есть векторы атаки.

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

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

Ещё одной целью, пожалуй, будет доказательство, что большинство машин не так уж просто угнать посредством перехвата сигнала (разве что Honda, хах), несмотря на то, что недавно в Канаде запретили якобы опасный Flipper Zero, который можно собрать из дешёвых модулей беспроводной связи.
Читать дальше →
Всего голосов 75: ↑75 и ↓0+75
Комментарии21

Охота на недостающий тип данных

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров14K
Направленный граф — это набор узлов, связанных стрелками (рёбрами). Как узлы, так и рёбра могут содержать данные. Вот несколько примеров:

Все графы созданы с помощью graphviz (источник)

В сфере разработки ПО графы используются повсеместно:

  1. Зависимости пакетов, как и импорт модулей, формируют направленные графы.
  2. Интернет — это граф, состоящий из ссылок между веб-страницами.
  3. При проверке моделей анализ выполняется путём изучения «пространства состояний» всех возможных конфигураций. Узлы — это состояния, а рёбра — это допустимые переходы между ними.
  4. Реляционные базы данных — это графы, в которых узлы являются записями, а рёбра — внешними ключами.
  5. Графы — это обобщение связанных списков, двоичных деревьев и хэш-таблиц.1

Кроме того, графы также широко используются в бизнес-логике. Научные работы со ссылками формируют графы цитат. Транспортные сети представляют графы маршрутов. Социальные сети — это графы связей. Если вы работаете в сфере разработки, то рано или поздно встретитесь с графами.

Я вижу графы повсюду и использую их для анализа всевозможных систем. В то же время я побаиваюсь использовать их в коде. Какой из популярных языков программирования ни возьми, поддержка графов в них практически отсутствует. Ни в одном её нет в виде встроенного типа, очень мало где они прописаны в стандартной библиотеке, и у многих языков нет для этой функциональности надёжного стороннего пакета. Чаще всего мне приходится создавать графы с нуля. Существует большой разрыв между тем, как часто инженерам ПО могут понадобиться графы и тем, в какой степени экосистема их поддерживает. Где все графовые типы?
Читать дальше →
Всего голосов 73: ↑71 и ↓2+69
Комментарии21

Как я случайно превратила свой сокращатель ссылок в приманку для мошенников

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров59K

Пару месяцев назад я запустила сервис y.gy, навороченный сокращатель URL. Вызвано это было личной нуждой: в другом моём проекте, getwaitlist.com, используется множество реферальных ссылок, а доступные сервисы сокращения url не внушали мне доверия. В итоге я решила создать собственный инструмент, который наверняка окажется полезен не только мне.

Я разработала лучший в своём роде сокращатель со всеми возможными примочками, начиная с обширной кастомизации и заканчивая хорошей аналитикой трафика. Это всё, что мне было нужно. По аналогии со многими аналогичными инструментами я разместила интерфейс «Shorten Link» по центру домашней страницы. Регистрация для использования сервиса не требуется. Я сделала доступ бесплатным и неограниченным, опираясь на принцип: «бесплатность – лучшая маркетинговая стратегия». Закончив с настройкой, я без громких заявлений сделала релиз и начала потихоньку продвигать свой проект.
Читать дальше →
Всего голосов 146: ↑142 и ↓4+138
Комментарии70

Как работает код, который спит месяц

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров12K

В первой части этого небольшого цикла статей мы говорили о том, что механизм устойчивого выполнения (durable execution) сохраняет состояние программы в журнале, а также о связанных с этим сложностях в случае обновлений служебного кода, ведущих к утрате журналом актуальности. Мы увидели, что ограничение времени выполнения обработчика существенно облегчает эту проблему. Но… не ведёт ли это к потере одного из наиболее интересных свойств устойчивого выполнения — возможности создавать бизнес-процессы, работающие с длительными паузами? В Restate мы считаем, что при использовании правильных примитивов можно ничего не потерять.

Тем не менее, если вы любите писать код с долгими периодами ожидания, потому что он хорошо согласуется с вашей моделью мышления, то Restate поможет вам реализовать это в полной мере. Если же вы цените устойчивое выполнение, но скептично относитесь к долго выполняющимся обработчикам и проблемам с их версионированием, то для этого есть решение. Ниже описаны несколько способов получить те же свойства путём добавления в этот механизм устойчивого обмена сообщениями и состояния.
Читать дальше →
Всего голосов 47: ↑43 и ↓4+39
Комментарии10

Иммутабельность в механизме Durable Execution: проблемы и решение

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров2K

За последние годы мы наблюдаем всплеск разработки инструментов и платформ, обеспечивающих Durable Execution (устойчивое выполнение). Немного поясню его принцип.

Компьютеры на сегодня достигли таких скоростей, что могут записывать результат каждой нетривиальной задачи в постоянное хранилище. Это, в свою очередь, позволяет им прекрасно восстанавливаться после временного сбоя путём повторного выполнения по журналу всех завершённых задач до момента этого сбоя. Выполнив эти задачи, система спокойно продолжает работу с точки, где она была прервана. При достаточном внимании и осторожности такой механизм можно реализовать с минимальным влиянием на модель программирования или производительность, что, безусловно, очень ценно. Не так ли?
Читать дальше →
Всего голосов 42: ↑41 и ↓1+40
Комментарии0

Насколько потолстел JavaScript к 2024 году?

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров32K

Я немного отстал от современных тенденций фронтенд-разработки. Помню, были статьи на тему раздутия веб-среды, в которых писали, что средний размер страницы начал достигать нескольких мегабайтов!

И всё это время я жил с мыслью, что если средний размер страницы равен, скажем, 3 МБ, то JS-бандл должен составлять около 1 МБ. Естественно, основную часть объёма должно занимать содержимое, не так ли?

Что ж, проверить это можно лишь экспериментальным путём, чем я и займусь! Эту статью я пишу в 2024 году и думаю, что через пару лет эксперимент неплохо бы повторить.
Читать дальше →
Всего голосов 160: ↑157 и ↓3+154
Комментарии159

Разработчик-универсал под видом специалиста

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров16K

С тех пор, как я начал работать на себя, заключая контракты, меня постоянно тяготило то, что, будучи разработчиком-универсалом, на рынке труда мне приходится позиционировать себя как узкого специалиста. Я уже много лет хотел написать об этом и даже делал кое-какие заметки. Решающим же толчком послужила встреченная мной недавно статья Бена Коллинса-Сассмана, хоть она и затрагивает эту тему лишь косвенно.

Ниже я опишу сложности, с которыми мне приходилось сталкиваться. Надеюсь, эта информация окажется полезной для других вольных авантюристов. Прошу учесть, что статья отражает преимущественно мой личный опыт, так что делайте на это скидку.
Читать дальше →
Всего голосов 70: ↑65 и ↓5+60
Комментарии11

Труд разработчиков открытого ПО заслуживает оплаты

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров9.8K

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

Недавно в сердцах я написал на Mastodon такой пост:

«Мы считаем, что сфера опенсорса должна быть жизнеспособной, а труд мейнтейнеров должен оплачиваться!»

Мейнтейнер: *вносит коммерческие возможности*
Мы: «Не таким образом».

Мейнтейнер: *работает на крупную технологическую корпорацию*
Мы: «Не таким образом».

Мейнтейнер: *привлекает инвестирование*
Мы: «Не таким образом».

Эта моя публикация вызвала вирусную реакцию, получив множество встречных аргументов и критики (а также немало согласия, и это приятно). Думаю, часть критических ответов объясняется моим намеренно вольным изложением и придирчивостью читателей к терминологии, но некоторые всё же стали следствием искреннего недопонимания моих язвительных высказываний. Я сам виноват, что поднял этот вопрос без должной ясности вместо того, чтобы говорить прямо. Поэтому в текущей статье я выражу свои размышления в виде более рассудительной и развёрнутой тирады.

Мой основной посыл в том, что труд специалистов, работающих в сфере опенсорса, заслуживает оплаты. Без исключений. Нам следует перестать критиковать идею оплаты труда мейнтейнеров и начать её ценить. Да, все используемые для этого механизмы в том или ином смысле несовершенны, но лишь потому, что сам мир таков. И дело не в том, что люди берут деньги. Наезжать на мейнтейнеров, которые нашли способ устроить себе жизнь, неправильно.
Читать дальше →
Всего голосов 81: ↑74 и ↓7+67
Комментарии98

Не стоит недооценивать HTML

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров23K

«HTML – это просто», «Разрабатывать фронтенд проще, чем бэкенд», «После реализации бэкенда обновление UI не должно составлять труда», – за время работы в сфере веб-разработки вокруг меня то и дело звучали эти и другие аналогичные утверждения.

И очень часто они вызывали у меня грусть.

Дело в том, что бо́льшую часть времени я проводила за написанием фронтенда, включая работу с HTML, CSS и JavaScript (по факту в основном TypeScript). Когда кто-нибудь говорит мне о «простоте» моей работы, я начинаю думать, что мои навыки не представляют высокой ценности, и меня может легко заменить любой разработчик…

В статье же я решила описать свои размышления, которые рождались в течение последних двух лет во время работы с людьми из разных команд с разным опытом в HTML-разработке и фронтенд-технологиях в целом. Здесь я озвучу несколько основных своих вопросов «Почему?», сопроводив их возможными ответами.
Читать дальше →
Всего голосов 66: ↑63 и ↓3+60
Комментарии94

Создание PDF размером с Германию

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров24K

Сегодня утром, пролистывая ленты социальных сетей, я уже в который раз встретила утверждение, что у PDF-документа есть максимально допустимый размер.

Подобное утверждение появилось на просторах интернета ещё в 2007 году. Этот твит является характерным примером постов с аналогичным заявлением, в которых оно преподносится как твёрдый факт без каких-либо подтверждающих свидетельств или объяснений. То есть мы должны просто принять, что один PDF может покрыть лишь около половины площади Германии, и нам никак не объясняют, почему его магический предел составляет 381 километр.

Тут мне стало интересно – а создавал ли кто-нибудь такой большой PDF? Насколько это сложно? А можно ли сделать документ ещё больше?

Несколько лет назад я из праздного любопытства немного поигралась с PostScript, предшественником PDF, и это оказалось очень увлекательным! Ранее мне не доводилось изучать внутреннее устройство PDF, так что здесь у меня возник для этого хороший повод.

Приступим!
Читать дальше →
Всего голосов 126: ↑123 и ↓3+120
Комментарии57

Реверс-инжиниринг программ DOS как в старом добром 1990-м

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров7K
На видео выше я записал наглядную реализацию процесса, описанного в разделе «Сборка и установка».

Эта статья посвящена запуску SoftICE, популярного отладчика для DOS и Windows, в эмулированной среде MS-DOS, а также обходу недостатка Bochs, эмулятора IA-32 (x86) PC.
Весь процесс выполнялся из-под Linux. Не знаю, получится ли проделать то же самое в MacOS, не говоря уже о Windows.
Читать дальше →
Всего голосов 61: ↑60 и ↓1+59
Комментарии11

На что способен самодельный очиститель воздуха, который можно собрать за 30 секунд?

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров68K

Плохой воздух однозначно вреден, но на рынке его очистителей мы наблюдаем бардак. Каждый производитель использует свои эксклюзивные фильтры, по всей видимости, для того, чтобы клиенты были вынуждены покупать именно их. А откуда нам знать, что эти устройства вообще работают? Немногие компании публикуют лабораторные тесты. И почему какая-то большая пластиковая коробка с вентилятором и фильтром стоит аж $100-300?

Но существуют и самодельные очистители, чаще представляющие собой просто примотанный к вентилятору фильтр. Мне такая идея по душе, но в этом случае тоже нет уверенности в их эффективности. Какие-то эксперименты проводились, но недостаточно, чтобы внушить мне доверие. Поэтому я решил поэкспериментировать сам: собрал очиститель, напустил дыма и измерил, насколько эффективно он справляется с удалением мелких частиц.
Читать дальше →
Всего голосов 129: ↑124 и ↓5+119
Комментарии157

Каково это, создавать язык программирования сегодня?

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров16K

«Эта книга – классика. Относитесь к ней бережно».

Такую фразу произнёс архитектор из нашей команды, передавая мне The Dragon Book. Разработкой компиляторов я увлёкся где-то 15 лет назад ещё на заре своей карьеры. Как-то раз, читая эту книгу поздно вечером, я заснул, небрежно уронив её на пол. Надеюсь, владелец не заметил небольшую вмятину на обложке после того, как я ему её вернул.

Вышла эта книжка в 1986 году. В те времена создание компиляторов было крайне сложной задачей, требовавшей обладания различными навыками в области компьютерных наук в целом и программирования в частности. Теперь, почти четыре десятилетия спустя, этой задачей занимаюсь я. Насколько сложна она сегодня? Приглашаю вместе разобрать процесс создания языка и посмотреть, насколько современные инструменты его упростили.
Читать дальше →
Всего голосов 62: ↑59 и ↓3+56
Комментарии5

Ладья на XSS: как я хакнул chess.com детским эксплойтом

Уровень сложностиСредний
Время на прочтение10 мин
Количество просмотров29K

Шахматы – это одно из многих моих хобби, за которыми я провожу свободное время, когда не ковыряюсь с какой-нибудь электроникой. При этом играю я так себе, и когда мне изрядно надоело проигрывать, я решил заняться тем, что у меня получается гораздо лучше… хакнуть систему!

В этой статье я расскажу о том, как использовал свои знания по кибербезопасности для обнаружения XSS-уязвимости (Cross-Site Scripting, межсайтовый скриптинг) на крупнейшем шахматном сайте интернета со 100 миллионами участников – Chess.com. Но для начала небольшое вступление (в котором будет затронута немного менее серьёзная, но достаточно занятная, уязвимость OSRF (On-site Request Forgery, подделка запросов на сайте).
Читать дальше →
Всего голосов 103: ↑101 и ↓2+99
Комментарии14

Обманчиво простой и интересный RSA

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров8.3K

Недавно, читая книгу Real-World Cryptography, я узнала об атаке Блейхенбахера, иначе называемой атакой миллионом сообщений. Этот вид атаки Даниэль Блейхенбахер продемонстрировал в 1998 году, взломав RSA через функцию шифрования PKCS #1. В книге об этой атаке было сказано немного, поэтому я решила изучить её сама и в конечном итоге реализовать.

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

Вместо этого я решила реализовать RSA сама, чтобы иметь возможность развернуть слабую схему шифрования, позволяющую осуществить атаку Блейхенбахера. Пока что у меня готова реализация RSA и PKCS (уязвимой версии). На создание основы RSA ушло около часа, плюс несколько дней на отладку. И теперь она (кажется) работает. Вскоре, если звёзды сойдутся, можно будет развернуть саму атаку.
Читать дальше →
Всего голосов 42: ↑40 и ↓2+38
Комментарии19
1
23 ...

Информация

В рейтинге
16-й
Откуда
Россия
Работает в
Дата рождения
Зарегистрирован
Активность