Программирование *

Автоклейм токенов в Hamster Kombat и HOT Wallet

Возможно я уже кому-то надоел своими попытками автоматизации всякого web3 скама (а может и нет), но в этот раз я написал небольшую, и очень легковесную программу, которая занимается автоматическим клеймом токенов в Hamster Kombat и HOT Wallet. И, как начинающий программист, я не могу не поделиться своим 'шедевром'.

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

Репозиторий - autoclaimer

Пулл реквесты приветствуются.

Оказывается не так давно Jetbrains запретили пользователям из РФ (и видимо из РБ) скачивать и обновлять свою IntelliJ Ultimate. Подозреваю, что это же относится и к другим их продуктам.
Попытка скачать среду разработки с сайта приводит к ошибке ниже:

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

Как открыть Hamster Kombat в браузере Chrome без скриптов

1. Установить расширение Resource Override

2. Установить перенаправление с URL https://hamsterkombat.io/js/telegram-web-app.js на https://ktnff.tech/hamsterkombat/telegram-web-app.js (как на скриншоте).

3. Открыть в браузере web версию telegram и октрыть хомяка.

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

Однако, ваш аккаунт могут забанить за роботность, если злоупотреблять запросами. Но более вероятный вариант, хомяк- это мусор, в котором вы просто потратите своё время.

Разработчики обновили плагин vscode-pets (VS Code Pets) для Visual Studio Code. Проект добавляет в редактор кода котиков, собак, уток, скрепыша и змейку (специально для программистов на Python). Миловидные зверьки бегают по окну приложения, ищут баги и создают хорошее настроение во время написания кода. Цифровые помощники могут взаимодействовать с пользователем с помощью мыши, а с помощью команды vscode-pets.throw-ball с ними можно поиграть.

Всем привет!

Недавно посмотрел интересное видео про управление техдолгом https://youtu.be/pvZDcytPU3w

На самом деле видео не про управление техдолгом в целом. Там нет архитектурного техдолга, технологического. Оно про техдолг, возникающий при реализации конкретной фичи - когда появляется TODO в коде.

Речь идет о извечной проблеме разработчика - "сделать все идеально". Но идеально может потребовать дни или даже недели. А у нас Agile, спринты в 2 недели, бизнес ждет свою фичу.
Что предлагается:

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

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

3. расставить по коду подробные TODO, рассказать команде что сделано, а что нет и почему, и влить доработку. Т.об. мы гарантировано получаем большую прозрачность. А если правильно удалось определить, что блокер для команды - еще и лучший Lead Time.

4. далее некий робот сканирует код, находит TODO и делает из них таски в вашем трекере

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

   Самое интересное - для одной и той же задачи пункты 1-5 могут повторяться. Наверное, если это происходит в 5-й раз - стоит детальнее взглянуть на задачу. Похоже она сильно влияет на архитектуру.

   Итого - идея мне нравится!

Разработчик утилиты Neofetch и системы KISS Linux оставил программирование и стал фермером. Репозитории всех своих проектов он перевёл в публичный архив, а в описании профиля указал «Have taken up farming».

Последняя версия Neofetch вышла в августе 2020 года. С тех пор утилиту не обновляли. Все репозитории организации KISS Linux также перевели в архив.

Где вы будете в следующий четверг? Мы — на GigaConf!

27 июня в креативном пространстве «Дизайн-завод» в Москве соберутся инженеры и разработчики из ведущих технологических компаний: Ozon Банк, Сбер, Huawei, Positive Technologies, МТС Digital, Альфа-банк и Cloud.ru в том числе😉.

На конференции наши эксперты расскажут про:

• платформу для достижения технологического суверенитета, спикер — Михаил Сайнуков;

• секреты разработки и развертывания cloud native-приложений и микросервисов на базе serverless-технологии, спикер — Михаил Бондаревский;

• опыт создания платформы данных с нуля, спикер — Ася Грибанова;

• обучение и инференс больших языковых моделей — как эффективно использовать дорогостоящие GPU-ресурсы, опыт успешного и неудачного применения LLM. Спикер — Дмитрий Юдин;

• внедрение DevSecOps, которое не увеличит время релизов — как добились сканирования кодовой базы в 20 тысяч строк за 30 секунд, с какими проблемами столкнулись и как их решили. Спикеры — Алексей Подольский и Сергей Губарев.

А программу GigaConf откроют старший вице-президент Сбера Андрей Белевцев, лидер сообщества MindSpore Hu Xiaoman, управляющий директор SberDevices Сергей Марков, а также специальный гость — министр цифрового развития Максут Шадаев.

📅 Когда: 27 июня в 10:00 мск — офлайн и 11:00 — онлайн

👉Зарегистрироваться

Будем рады встрече на GigaConf!

Интересное в блоге:

• Что такое free tier и какие облачные ресурсы вы можете бесплатно использовать прямо сейчас

• Запускаем кластер OpenSearch для централизованного хранения лог

MTS AI выводит на рынок ассистента для разработчиков — ИИ-сервис Kodify, созданный на базе собственной большой языковой модели (Large Language Model, LLM) Cotype.

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

Модель не требует дообучения и доступна клиентам сразу после установки. Kodify поддерживает наиболее популярные среды разработки и генерирует код на Python и Java. По запросу клиента разработчики MTS AI могут добавить поддержку Go и других популярных языков программирования. Также Kodify может перевести код с одного языка на другой — например, для оптимизации устаревшего софта или интеграции с другим проектом.

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

Kodify можно запустить в формате on-premise на инфраструктуре заказчика — вся обработка и генерация кода будет происходить только в контуре компании. «Это также позволит дополнительно обучить нейросеть на собственных примерах и полностью управлять источниками информации», — пояснил в MTS AI.

Всем привет!

TDD конечно крутая штука в плане правильного проектирования сервиса. Правильное проектирование - имеется в виду получить публичное Java API, удобное для использования, если не с первого раза, то с меньшим количеством итераций.

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

Что там может быть:

• входные данные -> выходные данные

• обработка возможных исключений

• повторный запуск: идемпотентность, докат или ошибка

• параллельный запуск

• поведение при различных значениях настроек

• поведение при различных настройках кодировки, языка, часового пояса, файловой системы

• эффекты из-за отсутствия транзакционности (там где ее нет) ...

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

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

Нужны ли iOS-разработчики в 2024 году и какие навыки пригодятся джуниорам? Команда Практикума провела исследование рынка труда, тут резюмируем ключевые выводы:

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

• Перед собеседованием важно повторить основы (например, по подборкам вопросов на собеседовании для iOS-разработчиков), а также проверить свой профиль на GitHub — закрыть слабые места и подготовиться к вопросам о проектах.

• Софтскилы для джуниора не менее важны, чем знание Swift. Неумение рассуждать или агрессивное поведение на собеседовании практически гарантируют отказ работодателя, а чрезмерное волнение может помешать кандидату показать лучшие результаты. Чтобы этого избежать, можно посмотреть собеседования на YouTube или попросить знакомого разработчика провести тестовое интервью.

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

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

→ Познакомитесь с языком Swift и запустите своё первое приложение в Xcode — игру Pong. 15 часов курса «iOS-разработчик» бесплатно.

Amazon опубликовал открытый игровой движок Open 3D Engine на базе технологий CryEngine (opennet.ru)

Для симуляции физических процессов поддерживаются NVIDIA PhysX, NVIDIA Cloth, NVIDIA Blast и AMD TressFX. Имеется встроенная сетевая подсистема с поддержкой сжатия и шифрования трафика, симуляции сетевых проблем, средствами для репликации данных и синхронизации потоков. Поддерживается универсальный mesh-формат для игровых ресурсов, автоматизация генерации ресурсов на языке Python и загрузка ресурсов в асинхронном режиме.

Всем привет!

Наткнулся на интересную статью про различные типы разработчиков https://habr.com/ru/articles/135865/ Тут не про уровень - джун, миддл, сеньор, - а про разные названия должностей и что за этим стоит. Кодер, хакер, разработчик, инженер, архитектор...
В целом классификация норм, но хотел бы подсветить пару моментов.

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

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

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

Разница между разработчиком и инженером. На первый взгляд особой разницы не видно. Очевидно, что диплом не делает инженера лучшим спецом, чем разработчик. Но рассмотрим ПО для критической инфраструктуры: авиаперевозки, космос, атомные станции, медицина.
ПО нужно сертифицировать. А раз так, то и сертификация разработчика, который это ПО пишет, выглядит логичной. Как минимум есть подтверждение, что он сдавал экзамен по чему-то важному, что требуется в данной отрасли. Но речь именно про специализированные экзамены, а не про программирование на Java или не дай бог Pascal)

Но первая мысль, которая мне пришла в голову после прочтения - главное, чтобы ChatGPT не сделал из разработчика кодера)))

И вообще любая привязка к чужим библиотекам это очень порочная практика.

Мы провели исследование  и выяснили, что курс «Управление командой разработки» подходит руководителей DevOps, QA, DS и аналитиков. Сейчас 12% покупателей курса — проджект-менеджеры, а 14% — тимлиды различных направлений.

Приоритеты менеджеров:

• Стать более технически подкованными, чтобы лучше понимать разработчиков;

• Частично или полностью заменить тимлида, если в компании нет отдельной позиции;

• Стать увереннее, объективно оценивать свои навыки;

• Научиться оценивать время на выполнение задач;

• Повысить авторитет среди разработчиков.

Приоритеты тимлидов DevOps, QA, DS и аналитиков:

• Лучше справляться с текущей ролью (нет цели начать руководить разработчиками);

• Улучшить навыки управления и систематизировать знания;

• Проработать слабые стороны;

• Убедиться в своём подходе, не опираться на интуитивные решения. 

Для прохождения курса не требуются навыки программирования. Много внимания уделяется мягким навыкам с примерами из жизни руководителя разработчиков и тому, как:

• Управлять ресурсами и временем. Делегировать, планировать, находить баланс;

• Нанимать, адаптировать и мотивировать сотрудников, давать обратную связь;

• Ставить выполнение задач на поток, применять Scrum и Kanban;

• Проводить встречи результативно, находить подход ко всем в команде, взаимодействовать с заказчиками, решать конфликты.

В США разработчикам в экспериментальных целях платят, чтобы они программировали в режиме изменённого сознания (фактически накуренными). В Университете Мичигана проводят исследование «Накуренный во время программирования».

В рамках этого мероприятия планируется изучить влияние определенных веществ на продуктивность. За это платят $80. Для участия надо быть старше 21 года и знать Python.

Ранее исследование показало, что 59% респондентов уже кодили на работе под кайфом или в состоянии алкогольного опьянения.

Что почитать начинающим разработчикам на Go

Привет, Хабр! Меня зовут Алексей Артамонов, я лид команды интеграции в «Островке». Сделал подборку, что можно почитать для старта работы с Go:

• «The Go programming language» — азы для старта. Хотя синтаксис в Go простой, важно уметь из этих простых вещей собирать сложные конструкции. 

• Effective Go — практическое пособие для создания тех самых сложных конструкций.

• «Сто ошибок в Go» — ещё одна хорошая книга. Заход со стороны «как делать не надо».

• В различных обучающих программах очень много внимания уделяют монолитам, микросервисам и в принципе архитектуре. Но правда в том, что джун или мидл вряд ли столкнётся со столь глобальными задачами. Ему важнее уметь разбить свою логику по классам, пакетам, модулям. Важно писать качественный код. Для этого обязательно рекомендую книгу «Good code, bad code».

• Много полезного в книге «Принципы юнит-тестирования». Хорошие юнит-тесты неразрывно связаны с тем, как приложение разбито на модули, какие есть связи и зависимости.

• Два блога-рассылки: GoLang Blog и Awesome Go Weekly.

• Подкасты довольно сложны для восприятия в фоновом режиме. Особенно для новичков. Но если очень хочется: GoTime, GoPodcast и GoGetPodcast.

Обучение пройдёт легче, если уже знать какой-нибудь язык программирования. К примеру, в «Островке» два главных языка — Python и, собственно, Go. Главный секрет — желание и практика. Если хочешь стать программистом — надо сесть и начать кодить. Ни одна книга без практики не поможет стать программистом.

Разбор доклада Артёма Арутюняна про Архитектуру и Реактивное Программирование

Топ перлов:

• Реактивное программирование - это программирование на событиях.

• Реактивность нужна между модулями, а внутри - не нужна.

• По одному лишь графу связей можно понять правильно произведена декомпозиция или нет.

Мета: Копилка благодарностей, Новости, Форум

Всем привет!

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

• корпоративные архитекторы, выравнивающие архитектурные шаблоны

• внутренние платформы, обязательные к использованию внутри компании и реализующие единообразно нефункциональные требования

• техрадар как способ ограничить технологический стек

• единые практики найма и онбординга

• корпоративная модель данных — как антипод принципа DDD, когда существует некая общая для организации единственно верная доменная модель...

Так вот — что мне нравится в парадигме DDD, что она говорит — не надо бороться, надо принять как данность, расслабиться и получать удовольствие от своего ограниченного контекста). Ремарка – речь про применение закона в проектировании ПО.

Всем привет!

Разработка ПО - очень динамичная сфера. Мэйнфреймы, ассемблер, CSV, RDBMS, C, Delphi, Java, REST, MQ, git, DevOps, Docker, k8s, Kafka, noSQL, microservices, reactive programming, DataLake, GitOps, ChatGPT...
Но есть вещи, которые не меняются. 1967 год, сформулирован закон Конвея - Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации. Причем если верить wiki, а в данном случае IMHO это можно делать, закон был доказан, видимо на исследовании реальных компаний.
Так вот, читаю сейчас одну интересную книгу про внедрение DDD - Domain Driven Development, 2022 года выпуска. В главе про внедрение вижу такой совет - начать с того, что определить бизнесовые поддомены в компании, на основании которых будут строится ограниченные контексты - одна из ключевых сущностей DDD. Как их проще всего определить? Рекомендуется посмотреть на структуру организации. Закон Конвея в DDD)

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

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

В обновлении я добавил такое как:

• Возможность разобрать блоки обратно в материалы

• Добавил множество строительных блоков и блоков интерьера

• Переписал процедурный генератор мира и добавил новые структуры

• Добавил рабочие инструменты и обновил принцип добычи материалов, теперь вам нужно иметь кирку, чтобы добывать камень, вам нужно иметь топор, чтобы добывать древесину

• Написал систему проигрывания саундтреков

• Теперь обновления мира из новых версий игры вносятся в старый игровой мир, таким образом все новые структуры будут доступны также и в старом мире

• Провел оптимизацию рисовку игрового мира

• Теперь игра доступна не только для Windows, но еще и для Linux

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