Меня часто спрашивают: с чего начинать изучение программирования? Я всегда предлагаю ответить на вопрос: а зачем оно вам и насколько глубоко вы готовы погружаться в мир IT?

Впрочем, в большинстве случаев, совет один: начните с изучения основ Python. Да, он медленный, да, он довольно укуренный (не зря его голландец создал!). Но он даёт главное - быстрый результат. А также поддерживает интерес к кодингу.

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

А уже после первичного знакомства с программированием, получив уверенность в своих силах, можно искать другие варианты. Хотите стать веб программистом учите js+html+css, тестировщиком - Java или Python.

Если же хочется более глубоких знаний, тогда ваш выбор C# или Java на серьезном уровне, а для совсем упоротых - С++.

Eshu Marabo

Не, я увы не такой, тайным знанием плюсов не владею(

#телеграм
Некоторое время назад бот, используемый нами в Сионе для обратной связи с читателями весело отрекламировал, как будто от нашего имени, ставки на спорт. Я и так ковыряюсь в телеграмных ботах, по такому случаю сделал бота для обратной связи. Ботов я пишу на c#, точнее - .net core.

Что из себя представляет подобный бот? Ему пишут читатели, он пересылает все сообщения, которые отправляются ему, в группу, где сидят авторы канала. Если кто-то отвечает на пересланное ботом сообщение, текст ответа передается читателю. Все достаточно просто, но есть несколько узких мест. Например, API телеграм ботов может переваривать не более 30 сообщений от бота в секунду, притом 1 сообщение в секунду одному человеку и не более 20 сообщений в минуту от бота в групповые чаты.

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

#телеграм
Одно из узких мест при ботописании – отправка сообщений, которая может занимать длительное время. Предположим, пришлось отправлять 10 сообщений одному человеку подряд. Интенсивность отправки – на грани лимита, уходить на сервера телеграма сообщения будут с разной скоростью, и может так сложиться, что случается уход нескольких сообщений одновременно => превышение лимита API, => санкции. Напомню, это делалось для бота-проверки слитости ТГ акков, где планируется работа на предельной нагрузке в течении долгого времени.

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

Вот условие задачи: есть буфер, из которого раз в секунду происходит попытка отправления 30 сообщений. Если сообщение еще не отправлено, он его не трогает, если уже отправлено - заменяет на новое и отсылает. Если поставить в тесте равномерное распределение времени ухода сообщения от 0 до 2 секунд, сколько должна быть средняя скорость отправки относительно ситуации, когда сообщения уходят мгновенно?

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

Интернет вещей: истинная опасность технологии 5G

Одной из технологий, с которыми часто связывают будущее, является интернет вещей - его развитие возможно, в том числе, благодаря скоростному 5G-интернету.

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

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

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

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

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

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

Про приватность можно и не говорить: Google/Apple уже знают о нас многое, ну а с развитым интернетом вещей осведомленность "большого брата" будет практчиески тотальной.

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

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

Eshu Marabo

Потыкав палочкой в PostgreSQL, поиграшись в создание таблиц и баз, я уперся в то, что ответы на мои вопросы вида "как сделать все по феншую" перестали гуглиться, потому засел за документацию. Огромный респект компании Postgrespro за качественный перевод официальной документации размером в... 2656 страниц. И все они написаны на первый взгляд нормальным языком, да еще пронизаны плотной сетью гиперссылок, что делает процесс изучения крайне удобным.

Текст задачки из прошлого поста: Ecть буфер, из которого раз в секунду происходит попытка отправления 30 сообщений. Если сообщение еще не отправлено, он его не трогает, если уже отправлено - заменяет на новое и отсылает. Если поставить в тесте равномерное распределение времени ухода сообщения от 0 до 2 секунд, сколько должна быть средняя скорость отправки относительно ситуации, когда сообщения уходят мгновенно?

Напрашивается ответ: она должна составить 15 в секунду, т.е. 0.5 от максимума, что на практике оказалось неверно.

Рассмотрим работу отправителя сообщений по шагам:
1. Положили в буфер 30 сообщений, выдали команду "отправить"
2. Через секунду ушла половина сообщений - 15 штук, 15 штук остались зависшими, т.е. 50%. На место ушедших поставили новые, нажали "отправить"
3. В третий такт ушли оставшиеся 15 сообщений со стартовой загрузки и половина от помещенных в буфер в прошлый такт, т.е. в сумме 75%. Помещаем на их места новые, жмем "отправить".
4. В четвертый такт уходит 25% (хвост со 2 такта) + (75%/2 c 3 такта), т.е. всего - 62.5%. Их места занимают новые, отправляются.
5. В пятый такт уходил 37.5% остатков с 3 такта + половина с прошлого такта, итого 68.75%.

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

​​В настоящий момент я изучаю опенсорсную систему управления базами данных (СУБД) PostgreSQL. Прародитель этого проекта появился еще в 1986 году в университете Беркли. Постепенно он вышел за пределы альма матер и стал развиваться сообществом по всему миру по принципу Open Source.

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

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

Так что многие опенсорсные разработки полностью контролируют какие-либо корпорации. В PostgreSQL положение дел в общем-то нетипичное для проекта такого масштаба: развитие контролируется не какой-то одной компанией, а сообществом, состоящим, в том числе, из представителей трех коммерческих организаций: Fujitsu, 2ndQuadrant и российской Postrges Pro о которой я упоминал ранее.

Все компании продают свои версии PostgreSQl, адаптированные под разные рынки, но при этом развивают и материнский проект, добавляя в него новые наработки из своих продуктов. За счет этого, бесплатная PostgreSQL может тягаться со своими конкурентами от именитых корпораций добра: Microsoft и Oracle и находит применение в очень крупных проектах, например в Yandex и Avito.

Не могу не отвесить отдельный поклон компании Postgre Pro: переведенная на русский язык полная документация на проект, а также обучающие материалы прекрасны.

Eshu Marabo

Начал читать книгу Конкуррентность в c#. Конкуррентность - это стрррашные вещи, типа многопоточности, асинхронности и параллелизма.

Осилив введение и дойдя до благодарностей малость выпал в осадок. Читаю дальше.

Разгораются страсти вокруг регистрации российской вакцины от коронавируса. Чего стоит хотя бы широко разошедшийся заголовок "в США отказались применять российскую вакцину даже на обезьянах".

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

Тем не менее, в самом факте широкого использования экспериментальной вакцины нет ничего необычного: в 2018 г. вспышка лихорадки Эбола в Западной Африке была вовремя остановлена с помощью недотестированных вакцин.

На кону - огромные деньги для и слава спасителя человечества от кошмарной ковидлы. В "гонке вакцин" участвуют крупнейшие мировые фармкомпании, сейчас испытываются множество вакцин против COVID-19, но никто пока не объявлял о выходе препарата на рынок или о широких испытаниях на тысячах добровольцев. Побочные действия есть у всех вакцин, как и у любого препарата.

Вакцина "Гам-КОВИД-Вак" против коронавирусной инфекции - разработка института им. Гамалеи. Примечательно, что большинство препаратов, разработанных в нем, не были признаны международным медицинским сообществом и нашли применение только в России и странах бывшего СНГ.

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

Что касается вопроса "прививаться или нет?" я бы посоветовал найти неангажированного специалиста (ваш участковый терапевт не лучшая кандидатура) и совместно с ним принять решение, учитывая ваши факторы риска.

Eshu Marabo

Дополню написанный некоторое время назад пост.

Вкратце, при ребрендинге Красного Сиона в Русский Футуризм я решал проблему массового изменения ссылок на наши посты, опубликованные ранее.

Телеграм ест форматирование текста (зачеркнутый, жирный и т.д) в виде html или Markdown разметки.

При этом, уже существующее сообщение в телеграме из кода выглядит как текст, к которому прилагаются Entities - описания, где указано, что с символа номер 10 следующие 6 символов - жирный, гиперссылка или другой вид форматирования.

Действие редактирования сообщения - это по сути отправка нового сообщения на место старого. Соответственно, чтобы выборочно поправить форматирование текста (те же гиперссылки), нужно на основании Entities воссоздать разметку текста текст, внести изменения (поменять в ссылке "redzion" на "rufuturism") и отправить сообщение. Изначально я подумал: зачем мне html, сделаю модно и молодежно, в макрдауне.

Вот тут-то всплыло несколько подводных камней:
1. Маркдаун, который ест телеграм - какой-то особенный, не соответствующий официальной спецификации.

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

3. Спецсимвол (\n, перенос строки) посреди выделения разбивает разметку, потому нужно разбивать её на два куска, до и после него.

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

Отдельная тема - виды форматирования, поддерживаемые телеграмом. Так, например, ссылка на пользователя, у которого нету username-а (обращение через @), выглядит как гиперссылка из его имени с адресом tg://user?id=1234, где 1234 - user_id. Есть еще некий формат "pre", который должен поддерживаться телеграмом. В функцию для воссоздания разметки для него я сделал, но способа ввести текст в этом формате со стандартных клиентов, чтобы посмотреть как он выглядит, я не нашел.

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

​​При написании кода на страшных и несовременных языках С/С++ есть понятное правило: память занял - попользовал - уберись за собой, освободи её.

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

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

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

При обучении программированию в рядовых ВУЗах, принципам работы сборщиков мусора внимания не уделяется: упомянули на лекции и пошли дальше.

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

https://www.tg-me.com/ssleg/153

Стандарты - нестандартные, системы - безсистемные, пространство - неевклидово, хрен знает, чье оно (с)

А теперь попробуй из кода сделать зачеркнутый шрифт в маркдауне.

В чате Типичного Программиста человек скинул вступительные вопросы на IT магистратуру в Украине.

Перевод:
Сколько объектов и сколько ссылок создается в приведенном фрагменте кода на языке Python?

n=100
m=n

A) один объект, одна ссылка
B) один объект, две ссылки
C) два объекта, одна ссылка
D) два объекта, две ссылки

Самое прикольное в этом вопросе... что ни один из вариантов неправилен (по крайней мере для стандартного интерпретатора CPython).

CPython заранее создает и хранит объекты под числа в диапазоне [-5, 256], потому именно этот код создаст только две ссылки, притом на уже существующий объект, в котором хранится число 100.

Пруфы: ссылка на обсуждение целых чисел в питоне на Stackoverflow, и код объекта, представляющего целое число на гитхабе.

Как я понимаю, в случае, если бы было число вне этого диапазона, был бы создан один объект (само число) и две ссылки (т.е. вариант B)

В общем, вопрос "Что курил голландец Гвидо Ван Россум, когда придумывал питон?" остается открытым.
#python

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

"Олдскульная" система разработки ПО начинается с того, что программисты сидят и пишут код. В конце определенного отрезка времени — спринта — всё написанное собирается в единое обновление. Обновление проверяется тестировщиками, и, если всё ок, «выкатывается» на пробу заказчику, и, если все в порядке, так или иначе поставляется клиентам.

Процесс проверки такого обновления тестировщиками и заказчиком занимает огромное количество человеко-часов. При этом никто не застрахован от проникновения к конечному пользователю каких-либо критических багов.

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

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

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

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

Казалось бы, тестировщики в скором времени начнут вымирать: большая часть тестов пишется программистами, тестирование автоматизировано. Но всё не так ужасно: системные администраторы ведь не вымерли, а превратились в devops-ов и в специалистов по информационной безопасности. Так и тестировщики – просто сольются до неразличимости с программистами, но без работы не останутся.

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

Написан он на c#, .Net Core + библиотека Telegram.Bot + Postgresql (адаптер со стороны шарпа - Npgsql). Итого 2600 строк кода на с# (800 - тесты и вспомогательный код) и 250 - описание БД на pl/pgsql.

Бот пересылает в группу все написанные ему в личку сообщения и отсылает писавшим ответы сидящих в группе людей.

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

Теперь в планах рефакторинг, рефакторинг и ещё раз рефакторинг: этот проект надо довести до состояния "не стыдно показать", будет частью резюме/портфолио, потому, если будут замечания - буду благодарен.

Ссылка на репозиторий:
https://github.com/vladzvx/telegrambots

#телеграм

Простейшая нейросеть (описывали ранее) —это основа, которая в реальных задачах применяется в существенно усложненном виде.

Можно выделить две самые совершенных группы: сети с памятью (LSTM и др) и сети, сверяющие данные с образами, хранящимися в их памяти (сверточные нейросети, CNN).

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

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

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

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

Eshu Marabo

В общем, теперь перенос постов из канала в привязанный чатик должен был не висеть в воздухе от имени None, а вестись от имени @GroupAnonymousBot с фиксированным id.

Впрочем, в какой-то момент фиксированный id сменился.

Что-то пошло не так (видимо волна негатива от разработчиков дошла до администрации телеги) и сейчас все вернули как было.