Все потоки

Как я познакомился с Мурмулятором? Я искал какой-то недорогой одноплатный компьютер для запуска эмуляторов ретро-компов.Чем меня не устраивало использование эмуляторов на "настоящем" компьютере? Ничем. Просто хотелось отдельное устройство. Я рассматривал вариант покупки старого ноута специально под эту задачу, потом смотрел на Raspberry Pi 400, Orange Pi и на прочие одноплатники. В процессе поисков я наткнулся на видео самостоятельной сборки оригинального одноплатника с бюджетом в $5. Понятно, что впоследствии я в эту сумму и близко не вложился, но данное изделие меня всё-таки зацепило. Вот так у меня и появился первый ZX Murmulator.

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

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

Мир существует по правилам, независимо от того, знаем мы эти правила или нет. И этих правил неисчислимое множество. И алгоритомов классификации-прогнозирования неисчислимое множество.

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

Все написанное выше касается и нейронных сеток, трансформаторов или других вариантов нейросеток.

И решением для реального AGI будет комплекс алгоритмов. Такой комплекс, которого будет достаточно, чтобы он смог дальше изобретать и встраивать в себя новые кусочки алгоритмов прогнозирования.

Привет всем! Меня зовут Ш. Сергей!

Я очень не хотел создавать подобные темы. И уже есть темы которые я уже создавал и там многое уже написано. А так же есть множество подобных тем, где люди написали больше меня и вероятно для кого-то более полезно чем я. Это и не удивительно, ведь я программист на Pascal/Assembler, от которых сейчас многие открещиваются как только могут.

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

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

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

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

Так как я предпочитаю использовать JavaScript и на фронте, и на бэке, то среда существования для бота была определена сразу же - nodejs. Осталось определиться с библиотекой - Telegraf или grammY? Так как у второй в примере использовался кошерный import, а у первой - старомодный require, я выбрал grammY.

Под катом - пример телеграм-бота в виде nodejs-приложения с использованием библиотеки grammY, который запускается как в режиме long pooling, так и в режиме webhook, созданный с применением моей любимой технологии - внедрения зависимостей через конструктор (TL;DR).

Многие знакомы с ELF-файлами и их структурой. Поговорим о программерах. Программер – это файл в формате ELF (расширение может быть BIN, MBN или ELF), который предназначен для  работы с памятью смартфонов на Android с процессорами от Qualcomm в режиме аварийной загрузки (EDL mode – emergency download, 9008). Также его некоторые называют «пожарный шланг» (от английского firehose) или просто «шланг». Файл представляет из себя контейнер с набором команд для базовой работы с памятью, которые подписаны цепочкой сертификатов. Иногда возникает необходимость подобрать для своего устройства подходящий программер. Вот и попробуем разобраться в этом.

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

Идея понятна - заменить генераторы частоты, терминалы RS-485 и CAN одним самодостаточным прибором. В этой статье расскажу о том, что за девайс я собрал.

Работая QA я часто слышала в голове голос «а ты точно все проверила?» и иногда он бывает полезен, но чаще вредит.

Ниже я пущусь в рассуждения о том чего больше: вреда или пользы и попробую сформулировать панацею для этого голоса.

Позитивное вперед. Плюсы таракана «а все ли ты проверила».

🔹В статье приведен краткий обзор термина «среда общих данных» (СОД) и история развития этого понятия. В основной части дается информация об имеющихся вариантах организации СОД, исторически сформировавшихся в строительной отрасли и получивших свое развитие.

🔹Автором предлагается теория уровней развития СОД, какими они были ранее и что ждет их в будущем. Показаны общие требования со стороны отрасли, предъявляемые к СОД и что необходимо делать для приближения, и достижения успешного результата применения СОД – повышение эффективности работ в строительных проектах на всех стадиях.

Создаем и тестируем простейший API.

Что будет выполнено в ходе данной статьи:

1. Будет создан простейший API сервер на NodeJS для запуска локально.
2. Будут написаны автотесты, на Playwright + Typescript, покрывающие простые запросы GET, POST, PUT, PATCH, DELETE.
3. Выполнены негативные тесты с получением ошибок, последующим анализом и устранением.

Почему-то про эту «фичу» не любят распространяться опытные коллеги, а первая встреча с таким в вашем проекте гарантирует бессонные ночи и разбитые об стенку лбы и клавиатуры. Читайте и берегите нервы, говорят они не восстанавливаются.

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

Если вы следите за новостями безопасности, то, возможно, сразу вспомните атаку на репозиторий liblzma/xz‑utils в начале этого года, конечной целью которой был бэкдор в OpenSSH. Однако ниже мы обсудим не случай с xz‑utils, ведь мало кто помнит, что бэкдор в xz‑utils на самом деле второй широко известной попыткой внедрения бэкдора в OpenSSH. Впервые это произошло более 22 лет назад, в 2002 году. Эта статья рассказывает историю того бэкдора и тому, чему можно научиться из атаки, произошедшей более двух десятилетий назад.

Это история разработки B2B решения для планшетов, чтобы увеличить их востребованность в сфере образования. Вначале мы совершили все возможные ошибки: считали себя самыми умными, путались в «болях» целевой аудитории вместе с фокус-группой. Всё нравилось менеджерам, разработчикам и, главное, начальству. Затем пилот решения дошёл до пользователей и пришло время отваги для осознания наших заблуждений.

Как работают шейдеры в GMS2? Как их писать и использовать? Что означают термины attribute, varying и uniform? Какой тип шейдера выбрать? Почему шейдер всегда состоит из двух файлов? Чем отличается вершинный шейдер от фрагментного? И причём здесь треугольники?

Всем привет!

Меня зовут Ваня Назаров, я работаю менеджером проектов в Ozon Tech.

Одна из основных моих обязанностей — поддержание функции руководителя департамента одного из направлений работы всего Ozon.

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

В термин «функция» я закладываю смысл какой-либо прямой деятельности руководителя.

Давайте вместе попробуем разобраться и понять, есть ли подводные камни в этом вопросе и, если есть, то какие.

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

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

Протокол — это набор правил и стандартов, определяющих, как данные передаются и обрабатываются в сети.

Так вот, клиент и сервер взаимодействуют с помощью стандартных протоколов, таких как HTTP, FTP или более низкоуровневых — TCP или UDP. Протокол обычно выбирается под тип услуги, которую оказывают сервера...

Вслед за Альфредом Тарским поинтересуемся: можно ли доказать любое школьное тождество с помощью программы?

_{Этот пост в оригинале (eng) https://www.setproduct.com/blog/dark-side-of-figmas-updates}

Глава 1: В какой‑то момент всё пошло не так

Смотря недавнюю конференцию CONFIG24, я не мог избавиться от неприятного зуда.

Чем сильнее зуд одолевал меня, тем больше приходило осознание – приоритеты Figma сместились с улучшения сервиса на увеличение прибыли.

Я неустанно задавал вопросы:

Что произошло с Figma, которую мы все так горячо любили?
Почему в приоритете деньги, а не список фич от пользователей, которые мы просим?
И если Фигма - ФСЁ, то что это сулит дизайн-инструментам в будущем?

Провал сделки с Adobe, похоже, стал переломным моментом.

Фокус Figma на создании функций с использованием искусственного интеллекта для увеличения количества пользователей - крутой поворот от первоначальной концепции сервиса.

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

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