Information
- Rating
- Does not participate
- Location
- Хабаровск, Хабаровский край, Россия
- Date of birth
- Registered
- Activity
Specialization
Software Developer, Application Developer
Lead
From 500,000 ₽
C#
Software development
Algorithms and data structures
WPF
MVVM
Multiple thread
Windows Forms
Visual Studio
XAML
SOLID
У меня деструкция стекловидного тела, и я постепенно перешел на тёмную тему везде, где можно(в хроме кстати есть экспериментальный флаг, который любой сайт переводит в тёмную тему). Сейчас приложения без тёмной темы воспринимаются как что-то, что хочется закрыть как можно скорей. Обычно при этом еще значительно убавляю яркость, и это не решает проблемы
Видел Cadl от Microsoft, но ещё не пробовал. Обещают решение многих проблем с OpenAPI
Небольшое улучшение - сейчас для SourceLink лучше использовать этот пакет. Он установит все необходимые свойства для всех CI окружений в одну строчку. https://github.com/dotnet/reproducible-builds
Вариант с ручным созданием .nuspec файла устарел, сейчас SDK-like проекты генерируют его автоматически на основе MSBuild свойств:
https://docs.microsoft.com/ru-ru/nuget/create-packages/creating-a-package-msbuild
Я в итоге для себя решил проблему с версионированием с помощью Conventional Commits спецификации. Сделал пакет, который автоматически присваивает версии, основываясь на feat:/fix:/BREAKING CHANGE префиксах к коммитам и вашей истории в git. Работает в том числе локально.
Вот здесь можно подсмотреть target, который переопределяет версию пакета во время сборки, его можно переписать на ваши условия:
https://github.com/HavenDV/ConventionalCommitsGitInfo/blob/main/src/libs/ConventionalCommitsGitInfo/build/ConventionalCommitsGitInfo.targets
Когда то пытался сделать что-то похожее, с указаний версий и зависимостей методов в CDATA. Добавление методов происходило через авто-дополнение с помощью расширения.
https://github.com/HavenDV/OneCode
https://github.com/HavenDV/CSharpUtilities/blob/master/NetStandard20/Utilities/ResourcesUtilities.cs
Но в итоге понял, что это того не стоит. Сейчас многие из этих extensions использую в генераторах, которые добавляют его при необходимости, например: https://github.com/HavenDV/H.Resources.Generator
Рассматривали ли вы Uno/Avalonia и что заставило вас отказаться от них, если да? Они позволяют реализовать кроссплатформенное приложение только в рамках C#, включая WebAssembly приложение.
А был еще третий вариант - делать PR во Flutter. И себе помогли бы, и другим людям тоже. Хотя переписывать всегда проще, да.
Мои рекомендации:
Для работы с xaml(любым, не только WPF) - https://github.com/Xavalon/XamlStyler - Форматирует ваш .xaml код согласно вашей конфигурации - https://github.com/Xavalon/XamlStyler/wiki/External-Configurations. Делает это по Ctrl+S при работе с .xaml, очень удобно.
Начните разделять понятия View и Control - View это какой-то специфичный для конкретного приложения UserControl или Window, который имеет ViewModel. А Control имеет только bindable Dependency Properties, и может быть перенесен из проекта в проект.
WPF и Material Design in XAML поддерживают отдельную валидацию для каждого контрола потому что ReactiveValidationObject реализует INotifyDataErrorInfo. Нет необходимости создавать отдельный контрол для вывода ошибок(если это не обусловлено дизайном, конечно). Есть минус - не поддерживаются code-behind биндинги. Для настройки отображения ошибки есть material:ValidationAssist.
Не хочу никого обидеть, но текст, по характеру изложения, очень похож на рассказ "Цветы для Элджернона". Возможно в этом и причина
В прошлом году находил баг, который позволял обменивать валюту так, что зачисление происходило несколько раз подряд.
В простом случае, можно использовать GitHub Issues) там есть двунаправленные ссылки и метки.
С другой стороны, как разработчик(к Яндексу не имею никакого отношения, работаю на фрилансе), я бы:
1. Расставлял приоритеты, учитывая ожидаемое количество пользователей на платформе, стоимость подписки(199р), стоимость часа разработчика и количество времени на разработку, 2. Определял бы платформы, которые окупятся быстрее.
3. Реализовывал бы их в первую очередь.
Очевидно, ваши платформы далеко не первые в списке. При этом стоимость подписки «общая» для всех пользователей, и учитываются именно интересы большинства.
Ну и к слову, 200р — это 3-6 минут работы по стоимости часа хорошего разработчика, особенно учитывая узкую направленность некоторых платформ.
P.S. Добавьте MSBuild свойство для вашего NuGet проекта, таким образом автоматически выставляются приватные ассеты при установке.
Ну и по вкусу чтобы избежать предупреждения об отсутствии библиотек в папке lib при генерации пакета.
Это как в знаменитом баше:
«Господа студенты, не учитесь, пожалуйста! Старайтесь как можно больше получить на халяву! Чем меньше вы знаете по окончании института, тем более ценен я как специалист и тем большую зарплату я могу потребовать за свои услуги!»
Это как в знаменитом баше:
«Господа студенты, не учитесь, пожалуйста! Старайтесь как можно больше получить на халяву! Чем меньше вы знаете по окончании института, тем более ценен я как специалист и тем большую зарплату я могу потребовать за свои услуги!»
Я потому и закончил этим заниматься, что к нашим уловкам к концу 2019 приспособились и аккаунты начали жить не больше месяца. А резали ставки примерно через неделю.
Но в целом, некоторые моменты:
1. Время ставок — бот был активен в случайный промежуток времени с 06.00-08.00 — до 22.00-24.00. Каждый день — разный. Но это очень большой промежуток, сейчас я не рекомендую ставить больше 4 часов в сутки.
2. Есть ValueBets, а есть SureBets — мы в основном ставили на SureBets против определенных букмекеров(Pinnacle и парочка еще). Суть в том, что завышенный коэффициент обычно был как раз у второго букмекера.
3. После появления новой вилки — ставили не ранее, чем через 5-10 секунд. Она могла поменяться/быть ошибочной.
4. Брали SureBets и ValueBets в диапазоне 1.5 — 6%.
5. Ставили только целые ставки, кратные 1 или 5(1, 2, 5, 10, 20, 25).
6. Не ставили максимумы, просто округляли до ближайшего кратного.
7. Старались использовать реальные IP адреса вместо прокси.
8. Не ставили на противоположные события — это красный флаг.
9. Использовали C# + CefSharp + выполнение js. Старались сделать браузер максимально похожим на chrome снаружи.
Средняя сумма ставок была около 5 миллионов $/месяц(300-400 активных ботов постоянно).
Прибыль — около 6%.
Бизнес модель приложения — мы продавали доступ к боту как сервису и брали процент от прибыли.
Аккаунты банили примерно через полгода, при максимальных ставках он успевал принести до 6000 долларов прибыли(500-1000$ в месяц). Там были специальные условия, чтобы прожить максимально долго и не выделяться среди вилочников.
Основной доход шел от Bet365. Они позволяли выводить деньги даже после полной блокировки аккаунта(чтобы не портить себе репутацию).