Алгоритм Дейкстры долгое время считался самым эффективным способом обхода графа. Теперь исследователи доказали, что он «универсально оптимален». 

Если вы долгое время ездите по одному и тому же маршруту, вы, вероятно, считаете его лучшим. Но «лучший» — это относительное понятие. Возможно, однажды произойдёт авария или дорога будет перекрыта, и ваш самый быстрый маршрут станет самым медленным. 

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

Сегодня обсудим вторую книгу перевода третьего оригинального издания «Искусства схемотехники» от издательства «БИНОМ», которая недавно появилась в продаже на сайте издательства. Первую книгу мы обсудили в предыдущей статье.

Я прошел путь в IT: около 5 лет был разработчиком, а последние 6 лет — DevOps‑инженер. Но сегодня я хочу поговорить о другом. По‑настоящему задуматься о жизни меня заставил серьезный кризис, когда одновременно случились развод, увольнение и всплыли детские травмы. И знаете, тот случай когда психология мне помогла.

Здесь не будет технических деталей. Скорее только психологический аспект и моё видение. Так что я понял о карьере в айти и отношениях на личном опыте?

Уже пара тысяч человек успели поработать с упражнениями по SystemVerilog и FPGA из репозитория BGM - basics-graphics-music. Они используются в Школе Синтеза Цифровых Схем в России и Беларуси, а также на Verilog Meetup в Silicon Valley, а предыдущие версии использовались на семинарах в Украине, Казахстане, Киргизии, Грузии, Армении и Азербайджане.

Прошлым летом мы перенесли два упражнения из BGM и одно упражнение из systemverilog-homework в инфраструктуру Tiny Tapeout для проектирования ASIC. Tiny Tapeout - это компания, которая работает с eFabless и фабрикой Skywater и позволяет студентам и любителям сделать собственные микросхемы за карманные деньги.

И вот сейчас хотелось бы интегрировать BGM и Tiny Tapeout всерьез, для планируемого семинара в Мексике. Идея простая: группа из 30 студентов упражняется неделю на верилоге на платах Tang Nano 9K с графическими экранчиками и интерфейсными модулями TM1638. А потом их дизайны переносятся в репозитории на основе варианта темплейта от Tiny Tapeout - и мы вместе оформляем заказ на производство чипа на фабрике.

А какое участие я хочу от вас? А вот какое:

Примеры в параллельном переводе — Что привносится в чтение?— Что и как читать? Отрывки из Шекспира — Попытки чтения на совсем незнакомых языках — Где читать? Печатные и онлайн ресурсы — Заключение

Примеры из Улисса

В первый раз в параллельном переводе я прочел роман Улисс (Ulysses).

Это толстый модернистский роман ирландца Джеймса Джойса, написанный по⁠-⁠английски в начале прошлого века.

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

Пример 1

Начало третьей главы Улисса, последней в предисловии, самой запутанной:

«Неотменимая модальность зримого. Хотя бы это, если не больше, говорят моей мысли мои глаза. Я здесь, чтобы прочесть отметы сути вещей: всех этих водорослей, мальков, подступающего прилива, того вон ржавого сапога. —»

Оригинал:

«Ineluctable modality of the visible: at least that if no more, thought through my eyes. Signatures of all things I am here to read, seaspawn and seawrack, the nearing tide, that rusty boot.»

Здесь, в отличии от перевода, хотя бы видна какая⁠-⁠то красивость, ради чего затевался этот сырбор: гармоничное «thought through», а еще «seaspawn and seawrack» / «водоросли, мальки» — даже если не знать конкретных значений этих слов, за счет повторения корня «sea» рождается образ моря, и с первого абзаца понятно, где стоит герой. Это такой способ избежать утилитарщины в описании сцены. Хочется сказать, что «видел перед собой море», но как⁠-⁠то иначе, сохранив протяженность фразы. В переводе же пройдет еще четыре абзаца до первого появления корня «мор».

Для сравнения первый абзац четвертой главы:

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

Пример 2

«What sound accompanied the union of their tangent, the disunion of their (respectively) centrifugal and centripetal hand? The sound of the peal of the hour of the night by the chime of the bells in the church of Saint George»

«Какие звуки сопровождали соединение их касательных и разъединение их (соответственно) центробежной и центростремительной рук? Звуки колоколов, отбивавших ночные часы на колокольне церкви Святого Георгия.»

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

Пример 3. В редакции газеты Моллой декламирует часть из лучшей на его памяти речи в суде.

Cовмещаем Vless, WebSocket, VPN и сайт на одном порту средствами Haproxy, создаем альтернативу VPN на основе WebSocket.

Sh (от shell) является обязательным командным интерпретатором для UNIX‑совместимых систем по стандарту POSIX. Однако по возможностям он ограничен, поэтому зачастую вместо него используются более богатые возможностями командные интепретаторы, такие как Bash или Ksh. Ksh обычно используется в операционных системах семейства BSD, в то время как Bash — в операционных системах семейства Linux. Командные интерпретаторы облегчают решение мелких задач, связанных с работой с процессами и файловой системой. В данной статье будут рассматриваться операционные системы Linux, поэтому речь пойдёт о Bash.

Python, в свою очередь, является полноценным интерпретируемым языком программирования, и он также нередко используется для написания скриптов или решения мелких прикладных задач при работе с операционной системой. Современную UNIX‑подобную систему сложно представить как без Sh, так и без Python, если только это не устройство с минималистичной ОС вроде маршрутизатора. Например, в Ubuntu Oracular пакет python3 удалить не получится хотя бы потому, что от него зависит пакет grub‑common, от которого, в свою очередь зависят пакеты grub2-common и, соответственно, grub‑pc, то есть непосредственно загрузчик операционной системы. Таким образом, Python 3 можно смело использовать как замену Bash в случае необходимости.

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

Своим постом автор Jenny Jam* пытается заполнить этот пробел. Он рассуждает, когда C — идеальный выбор, а когда лучше обратиться к другим языкам. Описывает, как настроить среду разработки и выбрать инструменты, разобраться в версиях, особенностях сборки и тонкостях работы с библиотеками.

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

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

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

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

Асинхронный код часто становится камнем преткновения для начинающих разработчиков. Почему функции выполняются не в том порядке, зачем нужны промисы, и что делает async/await? В статье я простыми словами объясняю:

• Как работает Event Loop и почему это важно.
• Какие ошибки чаще всего допускают джуны при работе с асинхронностью.
• Как научиться писать понятный и предсказуемый асинхронный код.

Если асинхронность вызывает больше вопросов, чем ответов, загляните в статью - там всё по шагам. 🙂

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

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

17.10.2024 на сайте Academia.edu опубликована статья «A new inherent approach to solving the Collatz 3n+1 problem and its analogues» [1]. Вторая ссылка для тех, кому проще читать по-русски «Новый внутренне присущий подход к решению проблемы Коллатца 3n+1 и ее аналогов» [2].

Английская версия исходно предназначалась для платформы препринтов arXiv, но там предложили сначала опубликоваться в рецензируемом математическом журнале. Попытки зайти на другие платформы HAL, Qeios и ResearchGate разбились о требование наличия аффилиации, которой у независимого исследователя нет.

Процесс отнял почти два месяца — больше, чем само исследование от идеи до текста. В итоге статья оказалась на свободной от «фейсконтроля» площадке Academia. Думаю, прочитать ее будет полезно всем интересующимся гипотезой Коллатца. Эксклюзивно для Хабра этот короткий текст, резюмирующий содержание и смысл публикации.

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

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

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

И в эту минуту я чувствую как начинают шевелиться волосы на моей голове. От шока, что не понимаю, чтоэто такое.

Потом подумал, что он, наверное, это где‑то объяснил, а я пропустил. Проверил предыдущие страницы, не нашёл. Может он потом объяснит, бывают же такие преподы, сначала что‑то скажет, а потом разберёт. Посмотрел вперёд, не нашёл тоже.

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

С тех пор, если встречается в книге, что автор научит всех, даже тех, кто «никогда не программировал», то невольно вздрагиваю, как от легкого удара электрическим током.

И самое смешное, что недавно, на современном курсе по изучению программирования, услышал то же самое. Преподаватель, как только зацепился за тип Int, тут же начал рассуждать все о тех же Int16, Int32, Int64 и т. д. Как будто он попадает в разъезженную колею и уже не может из нее выбраться.

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

Приветствуют читателей Хабра. Меня зовут Олег Иванов, последние пару лет являюсь фронтенд-разработчиком в ит-компании WMT Group. На разных этапах работы я сталкивался с , нашел способ упросить . В этой статье не будет серьёзных рассуждений, глобальных задач и историй успеха. Скандалов, интриг и расследований из глобального ит-мира тоже не планируется.

Вместо этого мы напишем функцию-счётчика на JavaScript. Несколько раз, причём всякий раз по-разному с пользой.

Казалось бы, задача простейшая, даже старый-добрый to-do list куда сложнее и заковыристее. Предложение написать функцию-счётчика на собеседованиях уже классика, которая делается на автомате. Уверен, что большинство опытных воинов фронтенда либо помнят традиционное решение, либо по памяти накатают его в течение 30 секунд. Традиционно эту задачу решают замыканием. Однако, почему именно им? А если попробовать сделать это как-то иначе? Я попробовал и реализовал счётчик несколькими разными (подчас неочевидными) способами, попутно спросив совета у нейросетей, а также подключив тяжёлую артиллерию в лице Babel, TypeScript и даже WebAssembly. Давайте посмотрим, что получилось!

Я учился в Гарварде работе мозга, и мы изучали две его части:

1. Префронтальная кора — то, что мы обычно называем мозгом и интеллектом.
2. Амигдала — это его эмоциональная часть, которая не контролируется нами в основном.

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

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

И здесь я расскажу, как именно мешает и как от этого избавиться.

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

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

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

Этот текст я посвящаю Руководителям-нытикам. Его также полезно почитать не только манагерам, он вообще посвящается любителям пострадать на тему несовершенства мира (с позиции совершенства собственного, разумеется).

Так вышло, что вас окружают дебилы.

Сотрудники не понимают, что от них нужно, хотя это должно быть очевидно даже без объяснений и напоминаний. Заказчик – конченный: не понимает очевидных вещей, ругается на ровном месте и вообще – вместо того, чтобы накинуть бюджета и не вставлять палки в колеса, как ему сказали, ходит и че-то там эскалирует про плохого менеджера на стороне исполнителя.
Ваш линейный руководитель, вместо того чтобы утешить и поддержать вас, тоже встает на сторону заказчика.
Руководство вашей компании тянет ее непойми куда, и создается ощущение, что ваша «компания, как курица без головы: бегает, машет лапами, разбрызгивая кровь, но бегать остается недолго» (реальная цитата одного недовольного, кстати).
Процессов нет и работать совершенно невозможно. Или процессы есть, но их много и они не те. Или они есть и те, но их никто не выполняет потому что см название статьи.

Короче: вы один в кольце дураков, и вас никто не понимает.

Бывало что-то подобное?

Тогда поздравляю, вы – ленивая и эгоистичная задница.

Это очередная статья посвященная софтскилам и лайфхакам в управлении, о которых не рассказывают на курсах по менеджменту. Если вам интересна эта и подобные темы – подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади» и читайте другие статьи здесь, на Хабре.

Что делать, чтобы быть более продуктивным — об этом написаны тонны литературы, от научной до художественной и даже эзотерической. Однако иногда почувствовать, что рабочий день удался, можно без стояния на гвоздях и подъема в пять утра — достаточно убрать раздражающие факторы. Мы в beeline cloud решили разобраться в исследованиях о том, что бесит разработчиков: джунов и сеньоров, в корпорациях и небольших фирмах.