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

Это статья познакомит вас с использованием возможностей Go для выполнения манипуляций с битами. Здесь мы разберём установку, очистку, инвертирование, сдвиг битов, использование техники SWAR, эффективную обработку Юникода и прочие приёмы, позволяющие повысить продуктивность программирования.

Я опубликовала в интернет-журнале статью на тему двоичного представления информации компьютерами и, среди прочих, неоднократно получала вопрос: «Почему в архитектуре x86 используются байты, состоящие именно из 8 бит, а не иного их количества?»

Я считаю, что на любой подобный вопрос можно дать два основных ответа и некую их комбинацию:

1. Так сложилось исторически, и другой размер (например, 4, 6 или 16 бит) тоже вполне сработает.
2. Восемь бит по какой-то причине является лучшим вариантом, и даже если бы история сложилась иначе, мы бы всё равно использовали именно 8-битные байты.
3. Некая комбинация этих двух версий.

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

Источник

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

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

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

Настало время для очередного бесполезного проекта.

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

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

Источник

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

Три реальные истории из жизни, показывающие возможные проблемы, вызываемые ошибками или недоработками в программном обеспечении. Первая касается продуктов Apple, вторая — устройств Android, а третья связана с багами в ПО канадского гипермаркета стройматериалов.

В последнее время я много экспериментировал с написанием кода при помощи LLM (Large Language Model, большая языковая модель). На мой взгляд, эти инструменты отлично справляются с генерацией небольших самодостаточных фрагментов. К сожалению, что-то большее уже требует человеческого участия для оценки результата LLM и предоставления дальнейших инструкций.

В большинстве случаев, когда кто-то утверждает, что «GPT написал X», человек выступает для LLM в роли своеобразного REPL (Read-Eval-Print Loop, цикл чтение-оценка-вывод), внимательно подводя модель к функциональному результату. Я нисколько не хочу принизить ценность этого процесса – очень здорово, что он работает. Но можем ли мы шагнуть дальше? Можем ли использовать LLM для генерации ВСЕГО кода сложной программы за раз без человеческого вмешательства?

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

Карманные ПК всегда занимали в моём сердце особое место. Первым был Palm III, а чуть позже я стал обладателем Sharp HC-4500. Меня заинтересовали проекты Yarh.io, и в начале этого года я задумал купить uConsole. Предполагалось, что этот девайс будет отправлен в марте, но заказ всё ещё находится на стадии подготовки. Так что, вооружившись множеством идей и сильной мотивацией, я приступил к реализации собственного проекта по сборке карманного ПК: Decktility.

SectorC (github) – это компилятор Си, написанный на ассемблере x86-16 и умещающийся в загрузочный сектор 512 байт машины x86. Он поддерживает достаточно обширную функциональность Си для создания реальных и интересных программ, являясь при этом, пожалуй, самым миниатюрным компилятором Си из когда-либо написанных.

В этой статье я углублённо сравню потребление памяти между асинхронными и многопоточными программами популярных языков вроде Rust, Go, Java, C#, Python, Node.js и Elixir.

Недавно я проводил сравнение производительности нескольких программ, предназначенных для обработки большого количества сетевых подключений. В итоге я увидел огромную разницу в потреблении этими программами памяти, порой в 20 раз и больше. Некоторые потребляли при 10К подключений чуть более 100 МБ в то время, как другие занимали почти 3 ГБ. К сожалению, эти программы были довольно сложными и также отличались своим функционалом, поэтому было бы трудно сравнить их непосредственно и сделать какие-то осмысленные выводы. Тут то у меня и возникла идея создать специальный синтетический бенчмарк.

Свой путь в сфере разработки я начала с языка PHP, но позднее в индустрии программирования акцент сместился в сторону JavaScript. Отчасти причина в том, что фронтенд-составляющая веб-среды так или иначе работает именно на JS. В этой сфере я провела последние десять лет.

Недавно мне подвернулась кое-какая работа, связанная с PHP. Поначалу я была удивлена, ведь за этим языком закрепилась дурная слава – преимущественно из-за его ассоциирования с устаревшими проектами WordPress (и всеми вытекающими из этого уязвимостями). Но WordPress – это всё же не PHP.

В общем мне стало любопытно. Кто они – те люди, которые до сих пор используют PHP? Почему они это делают? И как этот опыт можно сравнить с моим скромным миром серверных проектов на JS?

Реализация реактивности и компонуемости стандартными средствами таких фреймворков, как React, Vue и прочие, несёт собой ряд сложностей, включая необходимость настройки множества зависимостей. Но этой цели также можно достичь более простым путём, о чём и пойдёт речь в текущей статье.

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

При изучении нового языка программирования в его документации мы обычно находим таблицу, где перечислены различные операторы, которые можно использовать с числами. Помимо хорошо знакомых нам +, -, * и /, в ней всегда присутствует раздел, который многие пропускают. Я имею ввиду раздел с побитовыми операторами: <<, >>, &, ^ и |.

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

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

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

В течение последнего месяца я внимательно мониторил Mac App Store и сделал тревожное открытие. В самый разгар лихорадки вокруг OpenAI всплыло несколько приложений, которые копируют оригинальный логотип и цветовую схему OpenAI, вводя в заблуждение ничего не подозревающих пользователей Mac App Store. Но это ещё не всё – я также обнаружил, что некоторые разработчики злоупотребляют условиями Apple Developer Agreement, рассылая спам по множеству аккаунтов и заполняя магазин практически идентичными приложениями.

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

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

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

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

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

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

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

Самый быстрый способ обучения — это практика, так что приступим!

Работая со схемой, управляющей приличной силой тока, вы зачастую сталкиваетесь с полевыми транзисторами (FET, Field-Effect Transistor). Независимо от того, хотите ли вы управлять парой мощных светодиодов, двигателем или включать/отключать USB-устройство, в схеме обычно присутствует полевой транзистор, выполняющий часть ответственной работы. Вы можете не знать, как именно он функционирует, как его использовать и какие нюансы при этом учитывать — поэтому начнём с основ.