// Online Java - IDE, Code Editor, Compiler
// Online Java is a quick and easy tool that helps you to build, compile, test your programs online.
// Write your Java code here
public class Main {
public static void main(String[] args) {
// System.out.println(“Hello JDFREE-40”);
// System.out.println(12+30);
String CatName
CatName = “Уличный кот”;
System out println("Это обычный " + catName);
}
}
В роли графической оболочки выступает Pantheon. Она использует библиотеки GTK и выглядит довольно приятно. Среди разработчиков немало дизайнеров, поэтому им удалось создать красивую, но нефункциональную систему.
Это китайский дистрибутив, но имеющий локализацию на другие языки. Используется оболочка собственной разработки – Deepin Desktop Environment. Она использует библиотеки Qt, а для вёрстки HTML5 и движок Chromium.
Zorin OS основывается на Ubuntu и использует переработанную оболочку GNOME. Базовая версия (Core) не позволяет включить оформление, напоминающее macOS, это доступно только в платной Ultimate. Хотя как по мне больше похож на 10 Windows.
Вариация Ubuntu с оболочкой Mate примечательна тем, что в неt добавлено множество конфигураций панели. Есть такие темы, как Redmond, Cupertino и другие. Именно Cupertino позволяет преобразить систему, сделав её похожей на macOS.
Не могла не заметить одну херню при регистрации, а чего Вы регистр ников не сделал нормальный?
И где флудилка?
В России планируется увеличить утилизационный сбор для автомобилей с мощностью двигателя выше 160 лошадиных сил - для таких машин ставка утильсбора может существенно вырасти уже с ноября 2025 года, особенно при ввозе физлицами, а не дилерами.
Повышение связано с необходимостью пополнения бюджета и поддержки российского автопрома - власти рассчитывают собрать дополнительно 40–60 млрд рублей в год. Теперь льготные ставки для ввоза мощных авто (свыше 160 л.с.) отменяются, и для них будет действовать коммерческий (прогрессивный) утильсбор. Автомобили с такой мощностью лишаются льгот, которыми раньше пользовались при ввозе новых авто до 3 литров.
Детали по ставкам
Пока точные значения новых ставок не утверждены, но обсуждается их существенное увеличение — базовая ставка будет рассчитываться по типу и объему двигателя, а затем умножаться на коэффициент по мощности.
Для авто мощнее 160 л.с. льготный утильсбор (3400–5200 рублей) отменяется, и будет введён прогрессивный расчет, который может доходить до нескольких десятков тысяч (а по некоторым источникам - даже сотен тысяч) рублей за мощный автомобиль.
Важно знать
Нововведение, как планируется, должно вступить в силу с ноября 2025 года, но финальное решение и конкретные цифры будут объявлены дополнительно.
Транспортный налог также растёт по мощности отдельных авто, но повышение ставок для большинства населения коснётся лишь тех, кто владеет машинами с мощностью выше 160 л.с…
Если планируется приобретение или ввоз мощного автомобиля (свыше 160 л.с.), стоит готовиться к значительным дополнительным тратам на утильсбор и транспортный налог.
Владельцев обычных авто (до 160 л.с.) изменения пока не затронут: для них сохранены льготные ставки и условия.
Налог касается именно утилизационного сбора, не самого транспортного сбора — теперь дорогие и мощные авто будут обходиться на порядок дороже при покупке и таможенном оформлении.
Сейчас Exeed TXL стоит от примерно 3.6 до 4.2 млн рублей за новые автомобили 2025 года в зависимости от комплектации и региона продажи. Например, комплектация Business начинается от 3.6 млн, Prestige - от 3.77 млн, Premium - от 3.88 млн, Flagship - от 4.23 млн рублей.
После повышения утильсбора
С ноября 2025 года для автомобилей мощнее 160 л.с. (Exeed TXL оснащается двигателями 194–197 л.с.) утильсбор для физических лиц может вырасти в разы, по некоторым оценкам - дополнительно придется платить от 100 тысяч до 400 тысяч рублей, а на отдельные модели - даже больше. Точный размер будет зависеть от двигателя и применяемого коэффициента, но эксперты ожидают рост стоимости новых Exeed TXL ближе к 4.5–4.7 млн рублей и выше (для базовых версий).
| Комплектация | Цена сентябрь 2025 | Прогноз после ноября 2025 |
|---|---|---|
| Business | 3 600 000 ₽ | ~4 500 000–4 700 000 ₽ |
| Prestige | 3 770 000 ₽ | ~4 650 000–4 850 000 ₽ |
| Premium | 3 880 000 ₽ | ~4 750 000–5 000 000 ₽ |
| Flagship | 4 230 000 ₽ | ~5 100 000–5 400 000 ₽ |
Итого, если планируется покупка Exeed TXL, до ноября 2025 года цена будет заметно ниже - примерно на 500–800 тысяч рублей. И это лишь пример одной марки автомобилей.
Очень надеюсь что раздел маркетинга на нашем форуме будет полезен читателям, а особенно новичкам в этом деле. Сам недавно столкнулся с такой тематикой как Матчинг, и во что мне удалось разузнать.
Матчинг товаров - это процесс автоматического или ручного сопоставления и идентификации одинаковых или схожих товарных позиций в каталогах разных продавцов, маркетплейсов или систем учёта. Цель матчинга - определить, что разные карточки товара на различных витринах, прайс-листах или базах данных относятся к одному и тому же реальному продукту, даже если их названия или описания различаются.
Как работает матчинг товаров
Зачем нужен матчинг товаров
Особенности и нюансы
Таким образом, матчинг товаров - важный инструмент для e-commerce, маркетплейсов и крупных интернет-магазинов, обеспечивающий корректное сопоставление ассортимента и эффективный обмен данными между разными системами.
ECMAScript представляет собой официальный стандарт, определяющий синтаксис, типы данных, операторы, объекты и методы скриптового языка программирования. JavaScript является наиболее популярной реализацией этого стандарта, но важно понимать ключевое различие: ECMAScript — это спецификация (чертеж), а JavaScript — это готовый язык программирования, построенный на основе этой спецификации.
Взаимосвязь между ECMAScript, JavaScript и экосистемой браузеров
ECMAScript был создан в 1997 году организацией ECMA International для стандартизации JavaScript, который изначально разрабатывался компанией Netscape. Стандарт получил официальное название ECMA-262 и был необходим для обеспечения совместимости между различными реализациями языка в разных браузерах.
Стандартизация синтаксиса — обеспечение единообразного поведения языка во всех реализациях
Совместимость — гарантия того, что код будет работать одинаково в разных браузерах и средах выполнения
Эволюция языка — управляемое развитие новых возможностей через процесс TC39
Экосистема — создание основы для инструментов разработки, библиотек и фреймворков
Эволюция ECMAScript: хронология версий и ключевых особенностей (1997-2025)
ECMAScript 1 (1997) — первое издание стандарта, основанное на JavaScript 1.1 из Netscape Navigator 3.0, определило базовую архитектуру языка.
ECMAScript 2 (1998) — редакционные изменения для обеспечения соответствия стандарту ISO/IEC 16262.
ECMAScript 3 (1999) — значительное обновление, добавившее регулярные выражения, обработку исключений try/catch, улучшенную работу со строками и более строгое определение ошибок. Эта версия получила широкое распространение и поддерживалась всеми основными браузерами.
ECMAScript 4 (заброшен в 2003) — амбициозная версия, которая так и не была выпущена из-за разногласий в комитете по поводу сложности языка. Многие предложенные функции были позже включены в ES6.
ECMAScript 5 (2009) — после долгого перерыва был выпущен значительно переработанный стандарт, добавивший строгий режим (strict mode), поддержку JSON, новые методы массивов (forEach, map, filter, reduce) и улучшенную рефлексию объектов.
ECMAScript 5.1 (2011) — незначительные изменения для поддержания соответствия ISO/IEC 16262:2011.
ECMAScript 2015 (ES6) стал переломным моментом в истории JavaScript. После шестилетней разработки была выпущена версия с революционными нововведениями:
С 2016 года ECMAScript стал выходить ежегодно с меньшими, но регулярными обновлениями:
ECMAScript 2016 — оператор возведения в степень (**) и Array.includes().
ECMAScript 2017 — ключевые слова async/await для упрощения асинхронного кода, Object.values()/Object.entries(), методы строк padStart()/padEnd().
// ES2017 async/await
async function fetchData() {
const response = await fetch('/api/data');
const data = await response.json();
return data;
}
ECMAScript 2018 — rest/spread для объектов, асинхронные итераторы, Promise.finally().
ECMAScript 2019 — Array.flat()/flatMap(), Object.fromEntries(), необязательное связывание catch.
ECMAScript 2020 — две революционные функции: optional chaining (?.) и nullish coalescing (??), также BigInt и Promise.allSettled().
// ES2020 Optional Chaining и Nullish Coalescing
const userName = user?.profile?.name ?? 'Anonymous';
const count = data?.items?.length ?? 0;
ECMAScript 2021 — логические операторы присваивания (&&=, ||=, ??=), String.replaceAll(), числовые разделители.
ECMAScript 2022 — top-level await, приватные поля классов, статические блоки инициализации, Error.cause.
ECMAScript 2023 — не мутирующие методы массивов (toSorted(), toReversed(), toSpliced()), findLast()/findLastIndex().
ECMAScript 2024 — новый флаг RegExp /v, методы Object.groupBy() и Map.groupBy(), Promise.withResolvers().
ECMAScript 2025 — помощники итераторов, новые методы Set (union(), intersection(), difference()), атрибуты импорта, RegExp.escape().
Матрица функций ECMAScript: эволюция возможностей по версиям
Процесс стандартизации TC39: от идеи до стандарта ECMAScript
Комитет TC39 (39-й технический комитет ECMA International) отвечает за эволюцию ECMAScript. Процесс стандартизации состоит из пяти этапов:
Stage 0 (Strawperson) — начальная идея, представленная членом TC39 или зарегистрированным участником.
Stage 1 (Proposal) — формальное предложение с описанием проблемы, решения и назначенным чемпионом.
Stage 2 (Draft) — начальный черновик спецификации на языке ECMAScript с экспериментальной реализацией.
Stage 3 (Candidate) — практически финальное предложение, готовое для отзывов от реализаций и пользователей.
Stage 4 (Finished) — предложение готово к включению в следующий стандарт.
Следующие версии ECMAScript будут развиваться в нескольких ключевых направлениях:
Улучшение производительности — оптимизации для современных JavaScript-движков
Расширение типизации — возможные улучшения для лучшей интеграции с TypeScript
Новые API — дополнительные встроенные методы для работы с данными
Асинхронность — дальнейшие улучшения асинхронного программирования
Различные браузеры реализуют поддержку ECMAScript через JavaScript-движки:
V8 (Chrome, Node.js, Edge) — быстрое внедрение новых функций
SpiderMonkey (Firefox) — активная поддержка экспериментальных функций
JavaScriptCore (Safari) — консервативный подход к новым функциям
Chakra (старый Edge) — постепенно заменяется V8
Для обеспечения совместимости разработчики используют инструменты транспиляции, такие как Babel, которые преобразуют современный JavaScript-код в версии, поддерживаемые старыми браузерами.
ES2015+ для современной разработки — использование классов, модулей, async/await
ES2020+ для продуктивности — optional chaining и nullish coalescing значительно упрощают код
ES2022+ для продвинутых команд — приватные поля классов и top-level await
Babel — транспиляция для поддержки старых браузеров
TypeScript — надстройка над ECMAScript с статической типизацией
ESLint — проверка соответствия стандартам ECMAScript
Полифилы — добавление поддержки новых функций в старые среды
ECMAScript продолжает активно развиваться, ежегодно добавляя новые возможности для разработчиков. Понимание эволюции стандарта помогает писать более современный, читаемый и эффективный JavaScript-код, оставаясь при этом совместимым с существующими системами и браузерами.
В последние годы стало чуть ли не главным трендом в backend-разработке - микросервисной архитектуре. Если вы хоть раз слышали фразы вроде «у нас всё на микросервисах» или «мы уходим от монолита», то мои умозаключения как раз для вас. Я постараюсь объяснить все максимально человечно, без заумных терминов, но с пользой.
Представим себе ассоциацию помойного ведра. Один. Цельный. Все в нем: пластик, органика и прочее - все перемешано и держится вместе.
Это и есть монолитное приложение. Всё работает в одном процессе, одна база данных, один деплой, одна команда (или одна помойка 
).
А теперь представим, что мы эту помойку разделили на разные контейнера, одна для пластика, другая для органики и так далее. Каждый мусор можно выкидывать отдельно, не скидывая все одну помойку. Вот это и есть микросервисы - небольшие, независимые сервисы, каждый из которых отвечает за свою конкретную задачу.
Например:
Каждый из них — это отдельное приложение со своей логикой, своей базой данных (иногда), своим API и своей жизнью.
Все просто: монолиты - это удобно в начале, но когда проект растёт, они становятся монстром.
Мы хотим исправить баг в модуле оплаты, но чтобы выкатить фикс - нужно пересобирать и перезапускать ВСЁ приложение. Или мы хотим масштабировать только модуль чата - но масштабируете всё, потому что оно все в одном. Или у нас 50 разработчиков, и все правят один и тот же код - конфликты, задержки, хаос.
Микросервисы решают эти проблемы:
Независимость - можно менять, тестировать и деплоить каждый сервис отдельно.
Масштабируемость - можно масштабировать только то, что реально нагружено.
Технологическая свобода - каждый сервис может быть написан на своем стеке (Python, Go, Node.js - да что угодно).
Устойчивость - если упал один сервис, не обязательно падает всё приложение.
Командная автономия - разные команды могут работать над разными сервисами без постоянных конфликтов.
Конечно, нет 
Микросервисы - это не волшебная таблетка, а скорее обмен одних проблем на другие. Если монолит - это один большой камень, который тяжело двигать, то микросервисы - это мешок с мелкими камнями, которые более менее можно перетаскивать.
А теперь о плохом подробнее:
Щас сюда должен прийти @Jspi и закидать меня х*ями в панамку сказав используй FSD 
По моему личному опыту: не начинайте с микросервисов!
Если вы делаете MVP, стартап или небольшой проект монолит полюбому ваш друг. Он проще, быстрее, дешевле в поддержке. Микросервисы - это инвестиция, которая окупается, когда проект уже вырос и стал сложным, тогда есть смысл разбивать код на части.
Правило большого пальца: если у вас больше 3-5 команд, которые постоянно сталкиваются в коде, или если часть системы явно требует отдельного масштабирования - тогда можно задуматься о разделении. Если же Вы пилите в несколько разрабов то микросервисы точно не нужны.
И когда ваш проект уже подрос и справляться с архитектурой становится сложно, вот тогда начинайте к подходу через микросервисы. Начните с одного-двух сервисов. Постепенно, иначе рискуете утонуть.
Микросервисы - это мощный инструмент, но не для всех и не всегда. Они дают свободу, гибкость и масштабируемость, но требуют зрелости команды, инфраструктуры и всех. прочих процессов.
Не гонитесь за модой. Сначала решайте бизнес-задачу. А потом уже думайте, как ее лучше поддерживать и развивать.
Современные приложения должны прозрачно обрабатывать ограничения размера изображений, обеспечивая бесперебойное взаимодействие с пользователем.
imgcap реализует интеллектуальное автоматическое сжатие, учитывающее ограничения размера файла и сохраняющее оптимальное качество изображения, что обеспечивает плавный и беспроблемный процесс загрузки, соответствующий принципам эффективного взаимодействия человека и компьютера.
// До: Пользователь видит ошибку и уходит разочарованный
❌ "File too large: Image upload size cannot exceed 2MB"
// После: Плавное автоматическое сжатие
✅ await imgcap(userPhoto, { targetSize: 2 * 1024 * 1024 })
Automatically compress images to approximate target file size using binary search algorithm. - molvqingtai/imgcap
GitHub (github.com)
Захотел я значит приобрести себе второй монитор что бы удобнее было работать, и задался вопросов - а что если я подключу два монитора они оба full hd 1920x1280, но у одного 76 Гц, а у другого 180 Гц.
Прочитал про саму ОС Windows, и оказывается современные операционные системы, включая Windows 10/11, поддерживают работу с мониторами разных частот обновления одновременно. Каждый монитор будет работать на своей максимальной поддерживаемой частоте 75 Гц на одном и 180 Гц на другом.
Но существуют и возможные проблемы при запуске игр и приложений. При запуске игр на мониторе с частотой 180 Гц будет заметна более плавная картинка по сравнению с 75 Гц монитором. Однако могут возникать следующие проблемы:
Ну и конечно тут многое зависит все от видео карты, хотя сейчас наверное все сидят на NVIDIA. А драйверы NVIDIA автоматически снижают частоту основного монитора до частоты второго. Потребуется вручную восстановить высокую частоту в настройках дисплея после подключения второго монитора.
Из рекомендаций:
Ну а если ничего не помогает то пробуем классику с перезапуском компа, возможно потребуется установить одинаковую частоту для диагностики.
Доброго времени суток!
Я в React месяц, ну, может, чуть больше.
Имеет ли смысл многоуровневая вложенность компонентов, если, например, данные передаются вверх через пару-тройку уровней?
Так файлы короче, но страшно становится, если через useState-ы ререндерить родителей по такой лестнице…
Была идея вообще в хранилище построить нечто вроде описательной структуры, чтобы все связи шли через state-ы, ну типа как объекты в Vue.
В принципе, это мое первое приложение, и я готов к тому, что оптимально не будет, лишь бы работало с приемлемым гемором при поддержке…
Но… Может кто-то порекомендует, как лучше построить иерархию, чтобы, для первого раза, не так напряжно?
С уважением.
Python предлагает несколько встроенных структур данных, каждая из которых имеет свои уникальные особенности и области применения. В этом руководстве мы подробно рассмотрим три основные структуры: списки, кортежи и словари. Понимание их различий и правильное использование критически важно для написания эффективного кода.
Визуализация структур данных Python: списки, кортежи, словари
Список представляет собой упорядоченную изменяемую коллекцию элементов, которая может содержать данные любых типов. Списки являются одной из наиболее часто используемых структур данных в Python благодаря своей гибкости и функциональности.
Списки создаются с помощью квадратных скобок [] или функции list():
# Различные способы создания списков
numbers = [1, 2, 3, 4, 5]
mixed_list = [1, "hello", 3.14, True]
empty_list = []
from_function = list(range(5)) # [0, 1, 2, 3, 4]
Основные операции включают добавление, удаление и доступ к элементам:
# Доступ по индексу
print(numbers[^0]) # 1 (первый элемент)
print(numbers[-1]) # 5 (последний элемент)
# Добавление элементов
numbers.append(6) # Добавить в конец
numbers.insert(2, 10) # Вставить на позицию 2
# Удаление элементов
numbers.remove(10) # Удалить первое вхождение значения
last_item = numbers.pop() # Удалить и вернуть последний элемент
# Срезы (slicing)
subset = numbers[1:4] # Элементы с индекса 1 по 3
Списки поддерживают множество полезных методов для работы с данными, включая сортировку, реверсирование и поиск элементов.
Кортежи похожи на списки, но являются неизменяемыми структурами данных. Это означает, что после создания кортежа его содержимое нельзя изменить. Кортежи используются когда нужна гарантия сохранности данных или для представления структурированной информации.
Кортежи создаются с помощью круглых скобок () или функции tuple():
# Создание кортежей
coordinates = (10, 20)
rgb_color = (255, 128, 0)
single_tuple = (42,) # Запятая обязательна для одного элемента!
# Создание без скобок
point = 10, 20, 30 # Автоматически создается кортеж
Ключевая особенность кортежей - распаковка (unpacking), которая позволяет присваивать значения нескольким переменным одновременно:
# Распаковка кортежа
x, y = coordinates
r, g, b = rgb_color
# Обмен значений переменных
a, b = 1, 2
a, b = b, a # Теперь a = 2, b = 1
Попытка изменить элемент кортежа приведет к ошибке TypeError, что делает кортежи идеальными для хранения констант и неизменяемых данных.
Словарь - это неупорядоченная изменяемая коллекция пар “ключ-значение”. Словари обеспечивают быстрый доступ к данным по уникальному ключу и являются одной из самых эффективных структур для поиска информации.
Словари создаются с помощью фигурных скобок {} или функции dict():
# Создание словарей
student = {
"имя": "Анна",
"возраст": 22,
"специальность": "Программирование"
}
# Альтернативные способы создания
grades = dict(математика=5, физика=4, информатика=5)
empty_dict = {}
from_pairs = dict([('a', 1), ('b', 2)])
Основные операции включают доступ, добавление и изменение элементов:
# Доступ к значениям
name = student["имя"] # Прямой доступ
age = student.get("возраст", 0) # Безопасный доступ с значением по умолчанию
# Добавление и изменение
student["курс"] = 3 # Добавление нового ключа
student["возраст"] = 23 # Изменение существующего значения
# Получение всех ключей, значений и пар
keys = list(student.keys())
values = list(student.values())
items = list(student.items())
Различные структуры данных имеют разную временную сложность для основных операций. Это критически важно при работе с большими объемами данных:
| Операция | Список | Кортеж | Словарь |
|---|---|---|---|
| Доступ по индексу/ключу | O(1) | O(1) | O(1) |
| Поиск элемента | O(n) | O(n) | O(1) |
| Вставка в конец | O(1) | - | O(1) |
| Вставка в середину | O(n) | - | O(1) |
| Удаление элемента | O(n) | - | O(1) |
Диаграмма сравнения производительности поиска элементов в списках и словарях Python
Диаграмма наглядно демонстрирует, что словари значительно превосходят списки по скорости поиска элементов, особенно при работе с большими наборами данных. Это делает словари оптимальным выбором для задач, требующих частого поиска информации.
Списки идеально подходят для реализации очередей задач, стеков и других структур, где важен порядок элементов:
tasks = []
def add_task(task):
tasks.append(task)
print(f"Добавлена задача: {task}")
def complete_task():
if tasks:
completed = tasks.pop(0) # Удаляем первую задачу
print(f"Выполнена задача: {completed}")
return completed
# Использование
add_task("Написать код")
add_task("Провести тестирование")
complete_task() # Выполнена задача: Написать код
Кортежи отлично подходят для хранения настроек, координат и других неизменяемых данных:
# RGB цвета как константы
RED = (255, 0, 0)
GREEN = (0, 255, 0)
BLUE = (0, 0, 255)
def mix_colors(color1, color2):
"""Смешивание двух RGB цветов"""
r = (color1[^0] + color2[^0]) // 2
g = (color1[^1] + color2[^1]) // 2
b = (color1[^2] + color2[^2]) // 2
return (r, g, b)
mixed = mix_colors(RED, BLUE) # (127, 0, 127)
Словари превосходно справляются с задачами, требующими быстрого доступа к структурированным данным:
user_profiles = {}
def create_user(user_id, name, email):
user_profiles[user_id] = {
"name": name,
"email": email,
"posts": [],
"friends": set(),
"settings": {"notifications": True, "privacy": "public"}
}
def get_user_stats(user_id):
if user_id in user_profiles:
user = user_profiles[user_id]
return {
"posts_count": len(user["posts"]),
"friends_count": len(user["friends"]),
"name": user["name"]
}
При выборе структуры данных следует учитывать несколько ключевых факторов:
Используйте списки, когда:
Используйте кортежи, когда:
Используйте словари, когда:
Правильный выбор структуры данных может кардинально повлиять на производительность программы. Словари обеспечивают O(1) сложность для большинства операций, в то время как поиск в списках имеет O(n) сложность, что становится критично при работе с тысячами элементов.
Понимание особенностей каждой структуры данных и их правильное применение является основой для написания эффективного и читаемого кода на Python. Эти фундаментальные знания помогут вам создавать более производительные и надежные приложения.
Для удаления npm-пакетов из package.json нужно использовать команду npm uninstall - это удалит запись о пакете из секций dependencies, devDependencies, optionalDependencies и сам пакет из node_modules.
Как удалить пакет из package.json:
Обычный пакет:
npm uninstall название_пакетаЕсли пакет был dev-зависимостью:
npm uninstall -D название_пакетаnpm uninstall --save-dev название_пакетаdevDependencies.Если пакет был optional-зависимостью:
npm uninstall -O название_пакетаnpm uninstall --save-optional название_пакетаoptionalDependencies.Эти манипуляции удаляют пакет и его зависимости — записи исчезают из package.json, а сам модуль пропадает из node_modules.
C:\Users\user\PycharmProjects\PythonProject4\гп.py:205: PTBUserWarning: If ‘per_message=True’, all entry points, state handlers, and fallbacks must be ‘CallbackQueryHandler’, since no other handlers have a message context. Read this FAQ entry to learn more about the per_* settings: https://github.com/python-telegram-bot/python-telegram-bot/wiki/Frequently-Asked-Questions#what-do-the-per_-settings-in-conversationhandler-do.
conv_handler = ConversationHandler(
не могу понять как решить ошибку пишу бота первое сообщение приходит и никак
как только проверяю ничего не приходит кроме приветственного сообщения и не нажимается
Welcome to ProgrammingHumor — Where Code Meets Comedy!
You’ve stumbled into the sacred digital watering hole for devs who can laugh at themselves — whether it’s about infinite loops, cryptic error messages, caffeine-fueled all-nighters, or that one language we all pretend to understand (cough JavaScript cough).
What belongs here?
Programming memes that hit too close to home
Hilarious code comments you found (or wrote at 3 AM)
Screenshots of epic fails, weird bugs, or Stack Overflow desperation
Jokes about deadlines, merge conflicts, and “it works on my machine”
Dev life stories that make your teammates nod… then cry-laugh
What doesn’t?
Toxicity, hate, or personal attacks
Spam, AI-generated “jokes,” or low-effort copypastas
Taking yourself too seriously (this is the internet — chill 
)
Pro tip: If your post gets 3+ upvotes, you’re not alone in your pain. If it gets zero… well, maybe you’re writing in Perl. Or COBOL. We still love you.
Drop your funniest finds, upvote the gems, tag your suffering coworkers — and remember: if your code compiled and you laughed today, that’s a win.
#ProgrammingHumor #DevLife #CodeAndChuckles #ItWorksOnMyMachine #LaughAtYourOwnCode
Let me know if you want to tweak the tone — more sarcastic, corporate, geeky, or meme-heavy — I’ve got versions for every vibe 
Искусственный интеллект сегодня - больше чем просто тренд. Это мост между биологией и технологиями. Погружаясь в его изучение, я всё чаще нахожу параллели с работой человеческого мозга. Одна из таких фундаментальных идей и легла в основу моего небольшого текста.
Сразу хочу подметить, вся мысль/теория или называйте ее как хотите исконно лишь мое соображение мыслей. Но главным редактором текста что бы проще ее сформулировать и донести корректно, конечно же выступает ИИ
Но не полностью, если Вы внимательны то поймете где я оставил частичку себя
Чтобы понять связь, начнём с основ нейробиологии (но я бы это назвал все же физиологией). Наш мозг можно представить как трехуровневую систему обработки информации:
Большие полушария (кора головного мозга) - отвечают за высшие функции: сознание, мышление, сложные вычисления. Проще говоря захотел встать - встал.
Мозжечок - координирует движения и отработанные, «автоматические» навыки. По другому я бы их назвал рефлекторными.
Спинной мозг - является главным «кабелем», передающим сигналы от периферийных датчиков(органов чувств) к мозгу и обратно к мышцам. Или по другому - внешние факторы.
Процесс обучения у человека основан на многократном повторении. Нервные пути, по которым проходит сигнал, укрепляются с каждой новой итерацией. Сначала действие даётся тяжело (вспомните, как вы впервые сели за велосипед или клавиатуру), но с каждым разом оно требует всё меньше сознательных усилий, пока не становится автоматическим или более осознанным.
Я осознал это на личном примере: За компьютером я сижу наверное с лет 14, а сейчас мне почти уже 30, и вот почти уже 16 лет вслепую, я не задумываюсь о расположении клавиш печатаю по клавиатуре, лишь изредка поглядываю если совсем не уверен.
И я это не в коем случае не выдумал, а лишь привел параллель.
А теперь возьмем нейронные сети искусственного интеллекта, и их обучение. Как же они это делают? Если вы изучали нейронки то наверняка знаете про такое обучение как градиентный спуск.
Если кратко, процесс обучения ИИ - это не запись готовых ответов, а тонкая настройка «синаптических весов» (коэффициентов связей между искусственными нейронами). Сеть на каждом шаге (итерации) делает прогноз, вычисляет ошибку и крошечные корректировки в обратном направлении, минимизируя эту ошибку в следующий раз. Это своего рода «цифровое повторение».
Математика царица наук, и прав был Гаусс.
Так к чему же все эти сравнения и мои исследования? К гениальному озарению конечно же. А точнее к ее истокам, к фундаменту осознания и познания, а не просто Ща поставлю TensorFlow и погоню свою нейронку делать.
Мы смогли деконструировать биологический процесс обучения, описать его на универсальном языке математики и воссоздать его в виде компьютерного алгоритма. Искусственный интеллект - это не просто технологический прорыв. Это доказательство того, что самые сложные процессы нашей собственной природы можно понять, смоделировать и применить.
По сути мы не изобрели новый способ обучения. Мы открыли и формализовали тот, что всегда использовала мать природа.
Столкнулся с проблемой как в таблицах гугла заменить множественные пробелы во всем документе, рассказываю:
Быстрый способ через Найти и заменить:
\s\s+
Это удалит все лишние пробелы между словами и оставит только по одному.
Если нужно формулой в ячейке
Можно использовать формулу (допустим, для A1):
=REGEXREPLACE(A1; "\s+"; " ")
Эта формула заменяет любые повторяющиеся пробелы одним.
Результат: во всем документе пробелы между словами будут одинарными, лишние пробелы удалены.
Я каждый раз забываю как делать новый проект на python через venv. По этому для себя и для кого-то еще сделаю заметку.
Возможно эту заметку будут читать новички, по этому начну с банальщины.
Создаем папку проекта:
mkdir my_project && cd my_project
Создаем виртуальное окружение:
python3 -m venv venv
Активируем окружение:
source venv/bin/activate
Далее приступаем к работе, устанавливаем пакеты и так далее.
Когда работа завершена деактивируем окружение:
deactivate
Ну или можно вообще делать все в одну строчку:
mkdir PROJECT_NAME && cd PROJECT_NAME && python3 -m venv venv && source venv/bin/activate
Меняем имя только проекта.
Пользователи в Сети:
Статистика:
© 2024 - 2025 ExLends, Inc. Все права защищены.
