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

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

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

Бывают ситуации, когда жизненные обстоятельства не позволяют использовать ChatGPT и приходится разворачивать LLM локально. Там можно остаться и без AI, а этого мужики точно не поймут. Есть ли какие-то способы решения этой проблемы?

Если у вас такая ситуация – можете выдохнуть, решение есть.

40 лет назад, в 1984 году, две советские автоматические межпланетные станции «Вега-1» и «Вега-2» были отправлены к Венере. Это стало финальным этапом беспрецедентного космического проекта длиной в 20 лет, в котором участвовали десятки автоматических аппаратов. В ходе проекта были получены единственные до сих пор (!) снимки поверхности планеты и изучен состав венерианской атмосферы. Как показывает практика, все знают про марсоходы NASA и прожекты Илона Маска, но мало кто помнит про космическую программу «Венера» в СССР.

В День космонавтики рассказываем эту удивительную историю.

Хочу поделиться своим опытом участия в программе баг-хантинга ГК Астра (да, да - именно той, которая недавно совершила каминг‑аут IPO) на платформе BI.ZONE Bug Bounty.

Фараон, вышедший в далеком 1999 году был одной из первых игр, которые предлагали поэтапное строительство зданий. Да которые еще и требовали наличие разных ресурсов. Навскидку могу припомнить серию Settlers, Majesty и может еще парочку. После Цезарь III, исхоженного вдоль и поперек, где основным ресурсом при постройке зданий были монеты, это было действительно удивительно и ново. Особым удовольствием было наблюдать, как город живет своей жизнью в процессе постройки монументов, помню просто построил минимальную необходимую инфраструктуру для монумента и просто наблюдал как архитекторы жаловались на недостаток материалов, рабы бегали то на фермы, то на строительную площадку, торговцы периодически продавали кирпичи. Ну и остальной город, конечно, жил своей жизнью, можно даже забыть на какое время про отдельные части города, игра все равно не остановится, и тут понимаешь почему игра до сих пор остается одним из лучших градостроев: отличительная особенность серии — «баланс», баланс отточенный в мелочах. Восстанавливая эту часть игры, я не перестаю удивляться как это все было реализовано на тех аппаратных средствах, замечу, очень и очень небольших, 64Мб оперативки было далеко не у всех. Одним из нововведений монументов было то, что они были составными зданиями, отдельные части могли быть заменены на другие, что в общем давало возможность из одного набора текстур создавать разные по виду здания. Это сейчас кажется, что такой подход есть в любой игре, но в 99 такой механикой могли похвастаться немногие. Сначала я пытался восстановить оригинальный алгоритм отрисовки, но быстро понял, что столько if не осиливаю не только я, но и компилятор, пришлось велосипедить.

В прошлый раз здорово пообсуждали тему намагничивания неодима вот тут. Но нерассказанной осталась история одной катушки. Не той, которую скрутило всмятку на первых этапах испытаний, а той, которая была задизайнена после такого эпичного фейла. В принципе, изделие должно было получиться простым: 20 витков эмальпровода, сложенного вчетверо, в два слоя, на каркасе диаметром 50мм и такой же примерно высоты. Но был нюанс — при прохождении тока 10кА (кило‑Ампер, значит), первое решение «по‑простому» быстро схлопывается из‑за возникающих в проводниках Амперовых сил. Так что надо было придумать что‑то покрепче и намотанное поплотнее, дабы не дать возможности проводникам перемещаться по катушке во время рабочего импульса.

Импульсный (пере-)магничиватель для неодимовых магнитов (из HDD). Много конденсаторов, толстый тиристор, пыщ-пыдыщ, всё как мы любим.

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

Задача выяснить, как влияет “быстрая” зарядка на скорость деградации Li-ion аккумуляторов в устройствах с высоким током потребления.

В рамках исследования провел ряд экспериментов. Эксперимент заключается в зарядке аккумулятора током в 4-5 раз выше номинального. Номинальный ток заряда для исследуемых аккумуляторов от 2 до 5А, я буду использовать ток 20А.
В результате эксперимента будет видно, как “быстрая” зарядка увеличивает скорость деградации аккумуляторов.

В качестве испытуемых выбраны Li-ion аккумуляторы Sanyo NSX и LG 18650HG2 в формфакторе 18650.Выбор формфактора обусловлен тем, что именно данный они чаще всего применяется в устройствах с высоким током потребления. А именно: аккумуляторный электроинструмент, электронные сигареты, мощные фонари и некоторые виды электротранспорта.

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

Вы, наверняка, помните отличный цикл статей на Хабре в прошлом году от пользователя MiraclePtr, который рассказывал о разных методах блокировок, о разных методах обхода блокировок, о разных клиентах и серверах для обходов блокировок, и о разных способах их настройки (раз, два, три, четыре, пять, шесть, семь, восемь, десять, десять, и вроде были еще другие), и можете спросить, а зачем еще одна? Есть две основные причины для этого.

Я — ведущий гейм дизайнер с опытом разработки крупных, хардкорных проектов в жанрах от MMORPG и CRPG до мобильной MOBA. Почти три года мы с лучшим другом продюсировали, дизайнили, разрабатывали и занимались живым оперированием своих серверов по игре ARK: Survival Evolved. За это время мы неплохо заработали (в среднем проект приносил $6000-12000 gross ежемесячно). Конечно же, мы столкнулись с тонной сложностей и челленджей, и выучили много уроков. В этой статье я хочу не только рассказать о нашем приключении, но и поделиться выученными уроками. Оперирование кастомных серверов огромных франшиз типа Roblox, Fortnite или Minecraft и других игр похожа на разработку игр в классическом понимании, но имеет под собой свою специфику. Этот опыт будет полезен не только моддерам, но и разработчикам и продюсерам игр. 

ARK: Survival Evolved — ММО экшен от 1 и 3-го лица с крафтом, строительством и динозаврами. На динозаврах в игре можно охотиться, можно приручать, ездить на них, разводить и воевать с другими племенами в игре, и это основная фишка, привлекающая игроков. Но настоящая основная особенность игры в том, что карты — собственно, ковчеги, объединены в кластеры, внутри которых игроки могут беспрепятственно путешествовать между карт, превращая мир игры в настоящее ММО — в отличие от большинства остальных подобных игр. Это гениальная игра, о которой невозможно рассказать в двух словах, и она доводит своих игроков до настоящей аддикции, и те проводят в ней тысячи и десятки тысяч часов.

Я работаю над созданием Graphite, источником вдохновения для которого стал внутренний инструментарий Facebook. Когда я решил создать стартап с друзьями, то никогда раньше не слышал о Mercurial, хотя всегда страстно любил инструменты разработчика. Мой предыдущий опыт разработки включал в себя личные проекты, домашнюю работу в колледже, разработку для iOS в Google и развитие инфраструктуры в Airbnb. На протяжении всей моей карьеры использование git было таким же естественным, как воздух. Он настолько популярен, что лично я считал его единственным подходящим инструментом для создания изменений в коде и управления ими.

Забавно, что специалист по Mercurial Грегори Gregory Szorc работал рядом со мной в Airbnb, хотя я знал его только как приятного коллегу, но не представлял, что он контрибьютор.

В 2021 году мои коллеги по команде Томас и Ник раскрыли мне глаза. Они пришли из Facebook и, к моему удивлению, едва знали Git. Зато они имели глубокое понимание паттернов Mercurial и рабочего процесса Facebook на основе «многослойных diff» (stacked diff). Со временем они убедили меня в полезности этого паттерна и мы развернули направление развития компании, чтобы реализовать многослойные diff для разработчиков GitHub.

Но пост посвящён не нашему стартапу. Он о важном вопросе, не дававшем мне покоя последние три года. Почему фейсбукеры не пользуются Git? Зачем они выбрали Mercurial и создали на его основе собственные рабочие процессы? Я знаю что Google не пользуется Git, но это логично, культура разработки Google возникла на пять лет раньше Git. Facebook же был основан примерно в то же время, что и создан Git, около 2004 года, и ко времени, когда Facebook начал серьёзно выбирать инструментарий для управления исходниками, Git был старше и популярнее Mercurial. Так почему же Facebook не использует Git?

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

Я понимаю, что пока, за использования VPN, аннонимайзеров и/или tor не применяют уголовные статьи, поэтому гораздо проще скачать какое нибудь приложение из магазина приложений и бесплатно воспользоваться им. Но где гарантия, что завтра они будут работать?

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

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

Так же, этот способ - достаточно дешевый (меньше чашки кофе в день) и очень быстрый с точки зрения реализации (буквально 5 минут).

Интересно?

Можно с уверенностью сказать, что с момента публикации первой версии стандарта RS‑232 в мае 1960 года и по настоящее время, было написано приблизительно 10⁹ независимых реализаций UART на всём, чём угодно. Однако, подобно «Hello world» в мире прикладного ПО, а также мигания светодиодом — «Hello world» в мире цифровой электроники (сигнализирующий об успешной настройке оборудования и среды разработки) — процесс написания UART способен проиллюстрировать особенности языка или платформы, демонстрируя применение тех или иных синтаксических конструкций для решения практических, насущных и понятных проблем.

В данном цикле статей будет рассказано про написание модуля UART на SystemVerilog, про синтез данного модуля на различных платформах и про некоторые другие аспекты применения UART в ПЛИС. Но прежде, чем писать код, поговорим про сам протокол и про особенности аппаратной части вне контекста ПЛИС.

Да вымереть не могут.

Откуда это всё пошло? Чем так условные «программисты» не угодили? И почему именно программисты?