#алгоптимизируй #отботизируй

Вставать на его место с кратным повышением зп, это же очевидно.

И снова здрасвуйте)

Через DataTemplate.


В зависимости от того что будет в data context будуть использоватся разные контролы.

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

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

Изучайте книги по выбранной тематике (неплохой способ выбрать хороший учебник - посмотреть отзывы на Amazon, там обычно очень подробно расписывают как плюсы, так и минусы), изучайте документацию по выбранной технологии, и пишите-пишите-пишите. Написали - посмотрели, проанализировали. Как оно работает, понятно ли структурирован код, можно ли будет его в последствии расширить? Нужно ли его вообще будет потом расширять, или же это компонент, который будет написан один раз, и потом не будет изменяться? Какие-то из рекомендаций, указанных в книгах/документации, окажутся вредными - вы и сами это впоследствии поймёте, наткнувшись на проблемы, вызванные этими рекомендациями.
Подпишитесь в Твиттере на известных в вашей среде людей (тут я ничем помочь не могу, известных Android-программистов знаю, а по вебу помочь не смогу), они обычно подкидывают много интересной пищи для размышления.
Поищите подкасты по выбранной технологии, начните смотреть видео с конференций, подпишитесь на Хабре на нужные топики.
Ещё хороший способ понять чего не хватает - походить по собеседованиям (в вашей ситуации он, правда, слабо применим, так как город по вашим словам небольшой). Я таким образом нашёл несколько тем, в которых я "плаваю", и которые при этом очень нужны в реальной работе.
На гитхабе можно найти хорошие проекты, посмотреть как они структурированы, как происходит работа над проектом, какова структура коммитов, и так далее.
Ещё потенциально полезная тема - еженедельные дайджесты вроде такого, в которых расписываются текущие тенденции. Подпишитесь и читайте.

Главное при этом - постоянно анализировать входящую информацию, учиться отделять зёрна от плевел, и тогда всё у вас получится.

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

Попробуйте написать в саппорт.

А я опытом поделиться хотел.
Задачка была, наверное, банальная: надо было сделать проброс портов на Микротике на внутренние ресурсы сети, но так, чтобы на эти внутренние ресурсы сети можно было заходить по интернетовскому доменному имени Микротика как из интернета, так и внутри сети. Обычный проброс портов "в лоб" работает только для обращений из интернета. При обращении внутри локальной сети по внешнему доменному имени получаем обломс. В интернетах нашлось 2 решения: одно - прописать на DNS Микротика "Static DNS" domain.name -> Внутренний_IP_адрес_ресурса, и тогда все обращения по доменному имени внутри сети будут направляться на этот внутренний ресурс. Но это не подходит, когда внутренних ресурсов несколько, а не один, ведь "Static DNS" мы можем написать только для одного ресурса. Второе решение - Hairpin NAT, описанное в Wiki wiki.mikrotik.com/wiki/Hairpin_NAT . Однако с ним тоже проблемы, если внешний IP адрес является динамическим и часто меняется (с доменным именем от dyndns, например). В Hairpin NAT, описанном в Wiki, в правилах NAT необходимо указывать внешний IP, что неприемлемо, когда он часто меняется. Поразмыслив, я придумал следующее "идеальное" решение, объединившее оба способа в один:

/ip dns static
add address=192.168.88.1 name=myname.dyndns.org

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=ether1-gateway (это стандартный маскарадинг, обычно присутствующий в конфигурации по умолчанию)

add action=dst-nat chain=dstnat comment=RDP dst-address-type=local dst-port=3389 protocol=tcp to-addresses=192.168.88.2
add action=masquerade chain=srcnat dst-address=192.168.88.2 dst-port=3389 out-interface=bridge-local protocol=tcp src-address=192.168.88.0/24
(по 2 таких строчки на каждый порт-форвардинг)

Т.е. прописываем в статический DNS сопоставление доменному имени внутреннего IP адреса роутера (а не внутреннего ресурса!). Любой клиент внутри сети будет попадать на роутер по доменному имени.
Прописываем по 2 правила для каждого форвардинга - одно для маппинга, второе для маскарадинга. Таким образом мы избавляемся от необходимости непременно указывать внешний IP адрес в правилах NAT, который у нас часто меняется.

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