Ворклог что это

Введение

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

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

Роль заказчика в проекте

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

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

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

Процессы, в которые должен быть вовлечен заказчик

Формирование общего скоупа работ

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

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

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

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

Составление роадмапа

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

ВАЖНО: Роадмап — это гибкий инструмент, поэтому дедлайны и набор функционала могут меняться в зависимости от скорости работы команды, требований пользователей и других внешних факторов. Его основная цель — видение дальнейшего развития продукта.

Расстановка приоритетов

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

ВАЖНО: Приоритеты могут выставляться как отдельным задачам, так и логически цельному функционалу — фичам. Например, если функционал решает основную проблему пользователя, то ставится высокий приоритет, а если он из серии “было бы здорово сделать, но неизвестно, будет ли этим кто-то пользоваться” — низкий.

Планирование спринтов

Для того, чтобы постоянно видеть прогресс, а также безболезненно менять направление работы проекта, разработка делится на короткие итерации в 1–2 недели (спринты).

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

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

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

Демонстрации

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

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

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

Приемка задач

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

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

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

Написание тестов

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

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

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

Общая коммуникация

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

Обычно есть 4 основных источника коммуникации между участниками проекта:

• Slack/Skype: в них команда отписывает ежедневные стендапы, договаривается о встречах, обсуждает задачи в проекте и проблемы. Структура каналов обсуждается индивидуально для каждого проекта.
• JIRA(или другой таск-менеджер): здесь ведутся все задачи и описывается процесс работы по ним. Вся работа ведется в рамках какой-либо задачи. Если задача не была создана в таск менеджере, есть очень большая вероятность того, что она выполняться не будет. Проектное окружение должно быть одно, в нем централизованно будут храниться все задачи. Это нужно, чтобы не потерять задачи в разных документах, а вся команда понимает, что им предстоит делать в будущем.
• Email используется исключительно для отправки отчетов или других официальных проектных документов. После каждого отправленного отчета необходимо назначить личную встречу либо созвониться, чтобы обсудить детали и провести анализ.
• Созвоны / личные встречи необходимы для длительных обсуждений. Состав команды определяется в зависимости от темы обсуждения. Например, для планирование задач, обсуждение идей для нового функционала может привлекаться вся команда. Для того чтобы обсудить отчет по работе или подготовить задачи в бэклог будет достаточно проектного менеджера и тимлида. Перед встречей или созвоном необходимо отправить всем участникам план разговора, чтобы у каждого была возможность подготовиться.

ВАЖНО: после каждого созвона или встречи должен быть документ, подтвержденный всеми участниками. Это нужно для того чтобы убедиться, что все получили важную информацию и восприняли ее корректно, без искажений. Также документация гарантирует, что участники, не присутствующие на встрече в курсе событий. Созвоны необходимы в критичных ситуациях, например, когда какие-то проблемы возникают в продуктовой среде. Для этого необходимо проговаривать, где менеджер сможет с вами связаться в срочном порядке.

Что заказчик может требовать от команды

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

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

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

Ежедневные стендапы

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

Например, разработчик не понимает, какие задачи ему нужно делать. Это может быть сигналом того, что планирование было организовано неправильно. Чтобы решить проблему, нужно вместе с проектным менеджером проанализировать, что именно пошло не так, и исправить при следующем планировании. Или, например, разработчик пишет, что заболел — в таком случае будет вполне ожидаемо, что сроки сдвигаются. Технические трудности обычно решаются внутри команды.

За написанием стендапов разработчиками обычно следят проектные менеджеры. Мы в Mad Devs за эффективное использование времени и развитие наших сотрудников, поэтому для решения рутинных задач менеджера создали бота Комедиана.

Ворклоги

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

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

Инструменты для ежедневного мониторинга задач

Базовый мониторинг может основываться на чтении стендапов, однако, зачастую этого недостаточно. В дополнении к стендапам можно настроить фильтры или доски в жире так, чтобы система сама уведомляла вас об изменениях в проекте. Например, можно попросить менеджера настроить отправку уведомлений на почту со списком задач, обновленных в течение 24 часов или можно синхронизировать JIRA и gitlab со Slack: так вы сможете получать уведомления о коммитах, изменениях статуса задач, а также других событиях в зависимости от ваших пожеланий.

Отчеты

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

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

Донесение проблем и их решение

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

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

Ниже перечислю пару примеров проблем и их решений:

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

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

Заключение

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

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

Статья Ворклог реверса одной мобильной игры

Часть 1- логин сервер
Как-то раз в далеком 2017 году понадобилось мне разобрать одну популярную мобильную игру того времени- Зитву Бамков. Я уверен, многим из вас приходилось играть в нее, когда она была на пике популярности. На данный момент игра стала умирать. Разработчики отдают внутриигровые ресурсы за копеечный донат. По просьбе знакомого, и из-за обесценивания этой информации, публикую обзор полного взлома игры: от реверса, до создания альтернативного сервера и накрутки валюты гильдии, на которую даже сделали обзор некоторые ютуберы (да-да, Князь, привет). За это время у меня сохранились не все материалы, которые стоило бы использовать в статье. Поэтому в части скриншотов будет показана старая версия игры, а в части- новая. Однако мой сервер все еще работает с новой версией игры. Значит, можно надеяться, что обновления обратно совместимы

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

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

Легко заметить, что приложение написано на cocos2dx.
Например, если посмотреть smali код CastleClashActivity, можно заметить

.method public constructor ()V .locals 1 .line 50 invoke-direct , Lorg/cocos2dx/lib/Cocos2dxActivity;->()V const/4 v0, 0x0 .line 67 iput-boolean v0, p0, Lcom/igg/castleclash/CastleClashActivity;->isOfflineBack:Z .line 306 iput-boolean v0, p0, Lcom/igg/castleclash/CastleClashActivity;->isChangeAccount:Z return-void .end method

что оно наследует Cocos2dxActivity.

Cocos2dx это c++ форк игрового движка cocos2d, написанного на питоне
Если еще немного посмотреть smali код, то можно заметить, что он исключительно определяет не очень интересные функции-хелперы, и через JNI передает управление библиотеке libgame.so. Из чего можно сделать вывод, что самое интересное происходит в нативе

1. Анализ структуры траффика
Самый очевидный ход перед погружением в реверс натива. Может дать представление об устройстве механизма работы с сервером. Для этой цели буду использовать андроид приложение packet capture. Оно удобно тем, что позволяет записывать трафик только нужного приложения.

• Клиент взаимодействует с двумя серверами. Вначале стучится к логин серверу (порт 9300), у которого получает данные игрового сервера. Потом- собственно к игровому (порт 9339)
• Приложение общается с сервером через tcp сокет. Причем почему-то без ssl.
• Трафик клиента вначале идет в открытом виде, а потом начинает шифроваться. Трафик сервера всегда не зашифрован (видно по кускам строк).
• Используется little endian

2. Реверс
Нужен для анализа игровой логики

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

За взаимодействие с сервером тут отвечает класс NetMessage. Вот его методы слева направо:

За шифрование пакетов, очевидно, отвечают методы EncryptMsg, и DecryptMsg.
Посмотрим на EncryptMessage

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

Ссылка скрыта от гостей
.
Вот метод EncryptData из этой библиотеки, и кусок ELangh из игры. Почти одно и то же

Значит, игра использует des для шифрования. Но, как мы знаем, des- блочный шифр. Какой паддинг используется для данных, размер которых не кратен 8 байтам?
Как оказалось, никакого паддинга там и нет. Китайцы используют гениальное решение- шифруют packet_data[acket_data_size // 8] (в терминах питона), и дописывают в конце packet_data[packet_data_size // 8:] в исходном виде.
По-моему это очень странно. Оставим это дело на их совести

Для создания декодера пакетов осталась всего одна деталь- ключ des. Поискав по xref’ам метода Langh::InitializeK, я быстро нашел установку ключа

Им оказалась строка «L*#)@!&8».

У нас есть все для создания прокси-сервера, который будет декодировать, и логировать пакеты

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

Описываем интерфейс пакета

И три сущности: ClientPacket, EncryptedClientPacket, ServerPacket, Packet(для унификации механизма чтения и отправки пакетов. Кастится к EnctyptedClientPacket, и ServerPacket)
Делаем чтение, и отправку

Прокси логин-сервер будет состоять из двух корутин
Первая получает пакет у клиента, дешифрует (превращает EncryptedClientPacket в ClientPacket), печатает нам его содержимое и отправляет на сервер
Вторая получает пакет у сервера, печатает содержимое, и отправляет клиенту

Итоговый код прокси логин-сервера у меня выглядит так:

class LoginServer(serverIp: String = "0.0.0.0", val loginServerIp: String) : TcpServer(serverIp, LOGIN_SERVER_PORT) < var serverProcessors = listOf(LoginServerServerPacketProcessor()) var clientProcessors = listOf(LoginServerClientPacketProcessor()) override suspend fun processClient(iggChannel: IGGChannel) < val loginSocket = aSocket(ActorSelectorManager(Dispatchers.IO)).tcp() .connect(InetSocketAddress(loginServerIp, LOGIN_SERVER_PORT)) val loginChannel = IGGChannel(loginSocket) var stop = false val gameSession = GameSession() coroutineScope < launch < while (!stop) < try < var serverPacket: ServerPacket? = ServerPacket(loginChannel.readPacket()) println("Login server: $serverPacket") val packetType = serverPacket. type val processor = serverProcessors.firstOrNull < it.packetType == serverPacket. type >if (processor != null) < val newPacket = processor.process(serverPacket, gameSession) if (serverPacket.smartBuffer.unpackedItemsInfo.isNotEmpty()) < println("Login server: $") println("Login server: $") > serverPacket = newPacket > if (serverPacket == null) // Processor has drop the packet println("Login server: Packet was dropped- $packetType") else iggChannel.sendPacket(serverPacket.asPacket()) > catch (e: Exception) < stop = true iggChannel.close() >> > launch < while (!stop) < try < val encryptedClientPacket = EncryptedClientPacket(iggChannel.readPacket(), gameSession.isEncryptionEnabled) var clientPacket: ClientPacket? = ClientPacket(encryptedClientPacket) println("Login server: $clientPacket") val packetType = clientPacket. type val processor = clientProcessors.firstOrNull < it.packetType == clientPacket. type >if (processor != null) < val newPacket = processor.process(clientPacket, gameSession) if (clientPacket.smartBuffer.unpackedItemsInfo.isNotEmpty()) < println("Login server: $") println("Login server: $") > clientPacket = newPacket > if (clientPacket == null) < println("Packet was dropped: $packetType") >else < loginChannel.sendPacket(EncryptedClientPacket(clientPacket, gameSession.clientPacketSerialNum?.inc()).asPacket()) >> catch (e: Exception) < stop = true loginChannel.close() >> > > println("Disconnected") >

Адрес логин сервера клиент получает из конфига (
Ссылка скрыта от гостей

), адрес которого лежит в assets/config.xml
Деплоим свой конфиг, скопировав содержимое оригинального, c нужным адресом в секции LoginServer. Меняем адрес конфига в assets/config.xml на наш. Пересобираем приложение
В расшифрованных телах пакетов клиента в первых четырех байтах идет инкрементирующееся чисто- порядковый id отправленного пакета. К сожалению, архитектура у меня не позволяет выводить полное содержимое пакета, ибо при инжекте пакета старый порядковый id будет все ломать. Поэтому я не смог показать полные данные пакета с ним. Вот вывод моего реверс прокси. Как видите, у меня организована авторазметка пакетов

При подключении клиент сервер отправляет igg id, токен, и версию игры
В ответ логин сервер отправляет данные игрового сервера, и игровой токен

Усилитель своими руками (ворклог)

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

Электроника для усилителя

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

Радиатор найден в закромах от какого то старого усилителя. Немного пришлось кастрировать (сильно был великоват), длительным прогоном на максимальной мощности я был удовлетворён результатом. Нагрев не критический, даже я бы сказал не очень сильный и это не смотря на то — что на этом же радиаторе я разместил микросхемы стабилизатора питания для усилителя. На фото сейчас видны именно они. Всего стоит 7 шт, одна держит 1А получается вместе 7А. Усилок прожорливый при замерах показал ток потребления 5А.

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

Смонтирован усилитель, микросхема TDA 7265 схема собрана по дашиту с небольшими доработками для своих нужд, лупит честных 2х25W не HI — END конечно но для компа чтобы ухи были довольны вполне достаточно, в конце концов если захочется чего посерьёзнее то в компе есть цифровой выход, и его можно сконектить с ресивером. Реле коммутирует АС (кнопка на панели только включает релюшку). Это не безосновательно обусловлено тем — что контакт у реле более надёжный, чем у переключателя. Это я знаю уже по своему опыту.

Для наушников сделан отдельный небольшой усилок 2х5W чуток великоват по мощности конечно, но зато на 100% прокачает любые наушники, прослушивание мощных больших наушников оставило положительные впечатления, микросхема нагревается на большой громкости достаточно сильно так что потом при конечной сборке я думаю наклеить небольшой радиатор от греха. Отдельный усилок я сделал потому, что не хотел чтобы в звуковом тракте присутствовали ограничители типа резисторов и т.п. которые пришлось бы ставить если брать сигнал от основного усилителя. А тут сигнал сразу после усиления поступает на звукоизлучатели без ограничения, что положительно сказывается на качестве безусловно.

Это простая схема управления индикатором выходной мощности. Нашёл в сети случайно, сначала хотел собрать на специализированной для этого микросхеме К157ДА1, но к сожалению беготня по радиомагазинам результата не дала и я скидал схему на транзисторах. Схема от какого то совкового магнитофона.

Это плата разводки питания. Так же на ней стоят реле для коммутирования питания (я не стал заморачиваться с электронными ключами решил пойти по лёгкому пути). Стабилизаторы на самодельном радиаторе 12V для питания усилителя наушников и второй на 5V для светодиодной подсветки.

Набор деталей для блока питания. Корпус от какого то принтера найденный к «полезных вещах» дома, трансформатор подогнал корефан ( кстати ему отдельное офигительное спасибо за такой элемент..транс не смотря на свои небольшие размеры при прозвонке показал неожиданные результаты : при 25V он стабильно без нагрева фигачил 10А. ) На фото также выделяется реле стартёра от автомобиля. Тоже найдено дома, им предполагается включать усилитель с помощью компьютера. Берём с компа 12V и вуаля. Это чтобы не париться каждый раз с включением и выключением усилка, он будет управляться с компа и работать синхронно с ним. Для обычной работы без компа поставлю на задней стенке выключатель который коротит контакты реле и исключает его из схемы.

Монтаж блока питания получился очень плотный.

Корпус.

С корпусом пришлось повозиться, но так как это лицо изделия то оно того стоило.

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

Напилив детали по размерам, скрутил всё на саморезы.

Стыки перед сборкой промазал клеем для надёжности.

Вырезал отверстия для установки элементов управления и индикации.

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

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

Для крепления задней стенки установлены бруски, большой отступ от края был сделан для того — чтобы скрыть радиатор охлаждения и все элементы коммутации провода и т.п. За счёт этого усилитель можно поставить близко к стене.

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

В итоге получилась красивая полированная поверхность, которая получилась круче чем на рояле или пианино.

Контактная Панель

Выключателей и разъёмов минимум, только самое необходимое. Зачем усилку мощности лишние прибамбасы? Все настройки есть в звуковой карте компа.

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

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

Установлены так же разъёмы для наушников. Причём обязательно разных диаметров Jack 3,5 мм и Jack 6.3 мм чтобы потом не париться со всякими переходниками. С каким штекером есть наушники с таким и спокойно без заморочек- втыкаешь.

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

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

Индикатор Выходного Сигнала

Индикатор хотелось сделать похожим на индикаторы знаменитых усилков моей молодости. Вдохновившись воспоминаниями о бурных временах, приступил к работе.

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

Корпус делал из того — что попалось под руку в куче хлама на балконе.

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

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

Уже нарисовывается общая картина будущего изделия.

Примерка индикаторов. Потом они убраны подальше до конечной сборки прибора ( очень нежные детали, легко можно испортить).

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

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

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

Регулятор Громкости

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

И так к вашему вниманию — очередной изврат..

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

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

В середину на эпоксидку вклеена ручка от какого то старого магнитофона или приёмника (нашлась в закромах), она как родная подходила для переменного резистора.

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

После отвердевания проверяем на прочность как сидит эта якобы втулка. всё классно и крепко. можно продолжать дальше.

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

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

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

Первый слой краски. Включил светик, полюбоваться на результат. Остался доволен.

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

Напечатанная на глянцевой бумаге шкала помещена между 2мя листами органики, всё соединено для последующих этапов работ.

В торцы для подсветки вклеены светодиоды и всё выкрашено чтобы свет не рассеивался по корпусу и не засвечивал соседние элементы..например индикатор подсвечивается белым светом и не хотелось бы чтобы свет подмешивался.

Ножки для усилителя.

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

Делалось из того — что нашлось так же на балконе в куче хлама. Хромированная мебельная труба 25мм, органика 3мм (подогнал корефан),светики конечно ходил покупал + клей (супер-клей и эпоксидную смолу).

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

Слой органики круглой формы предусмотрен для того — чтобы потом при заливке не вытекла эпоксидка. Заготовка из трубы плотно одевается на основание.

Залит клей в формочки, и детали ждут дальнейшей обработки после отвердевания смолы.

Сам полупроводниковый элемент изначально закреплён термоклеем.

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

Так выглядит гораздо интереснее, но это ещё не всё.

Пробное включение светиков не впечатлило и было принято решение сделать рассеивающую линзу. Свет попадает на неё и рассеивается в разные стороны.

Это начальный вид без линзы.

На этом комбинированном фото виден эффект рассеивания, сделанный простой манипуляцией сверлом.

Все детали сделаны аналогичным образом.

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

Краткое описание усилителя и его характеристик:

Мощность 2х25W,сделан на микросхемах TDA 7265 — это основной усилок, TDA 1517 — это усилок для наушников 2х5W,это основные. Превосходства его конечно очевидны хотя бы уже в показателях выходной мощности. Но я его делал не только для ушей, подобные экземпляры которые есть в продаже не соответствуют моим запросам вообще. и в том числе по удобству эксплуатации. Например чтобы подключить наушники с толстым штекером Jack 6,3 мм это вообще целая эпопея с переходниками и прочей ерундой, не говоря о том что они не могут в полной мере с приличным качеством просто напросто такие наушники прокачать. Внешний вид у покупных изделий оставляет желать лучшего и такие коробочки хочется убрать под стол, чтобы их не видеть ни когда, где неудобно их включать, данный усилитель лишён этого недостатка, потому что он включается и выключается синхронно с компьютером. Вся подсветка отключается кнопкой на задней стенке дабы не мешать пользоваться компьютером в темноте, после очередного включения она автоматически включается опять. Кнопки на лицевой панели «СЕТЬ» и отключение и включение АС.

Видеообзор самодельного усилителя:

Читайте также

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

Жизнь — это движение! А тестирование — это жизнь 🙂

В продолжение темы о том, чтобы пустить Заказчиков в джиру.

Задачу в helpdesc поставили, админ сделал свой magic и появилась у Заказчиков возможность писать нам в общий доступ, так сказать. Чтобы каждый вопрос видела вся команда, а не только ее часть, подписанная на customer@support .

В итоге мы начали активно использовать галочку «Restriction to Workers», дабы попрятать комменты, не имеющие смысла для Заказчика. И даже скрыли от него закладку «Журнал работ» (где ты пишешь, сколько времени потратил и на что, и было ли это интересно), зачем ему смотреть наши ворклоги?

Однако я ходила и думала. Вот, скрыли мы свои комменты «Ага! А я говорил — потестить внимательно!!», «Да тестила я. «. В джире их не видно будет. А вдруг email нотификации придут? о_О

Не доверяю я задачкам, закрытым без тестирования ))))
В общем, думала, думала, пошла к админу, докопалась — проверял? Нет.

— Давай Никите доступ.

Прихожу к Никите:

— Поздравляю, ты — Заказчик! Ставь мне таск.
— Ок, не вопрос, под кем логиниться?

Создали таску, я пошла ее покомментила, что-то простым комментарием, что-то «спрятанным». Ну и ворклоги заполнила. Посмотрели на пришедшую почту — уф, с комментариями все хорошо. А ворклоги приходят! Кхе кхе кхе. «1 час, нейтрально, пыталась воспроизвести проблему». Ну бывает же такое, когда не воспроизводится? А представьте, такое сообщение Заказчику уйдет?

Таааак, бегом к админу! Снова magic, снова я химичу с тестовой задачкой и иду к нашему «Заказчику», который коллега.

— Ну, что пришло?
— А что, должно было что-то?
— Ага.

Смотрим. Пришло только «этот коммент будет виден» и «этот тоже».

— Ура, закрываем!
— А что, ты что-то еще писала?
— А ты под собой зайти и посмотри Activity Stream 🙂

Зашел. Похихикал :))
Читается оно снизу вверх, если что.

Мораль сей басни такова — не доверяй сторонним программам! Их тоже надо тестить.