sidny_vicious

Есть два вида приложений:
1. Не используют дополнительные устройства (камера, гироскоп и т.д.)
2. Используют ресурсы смартфона

Первый вариант можно портировать без особых сложностей, но нужно будет добавить всю необходимую информацию: разрешения, данные о приложении. Сделать так, чтобы оно соответствовало стандартам и требованиям PlayStore. Также нужно будет его пересобрать для устройства , либо конвертировать jar файл в apk.

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

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

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

Пример из моей рабочей практики:
В компанию взяли двух студентов на практику. У одного средний бал зачетки 4,8 - отличник, а у другого 3.4 - троечник.
Отличник на собеседовании блистал техническими знаниями, показывал какой он хороший, задачки несколькими способами решил и тому подобное. Троечник решил задачи и более-менее рассказал о технологиях.
А в работе всплыло следующее: отличник не смог разобраться в готовом коде. Он все время писал свои проекты и чужого кода в глаза не видел. Как результат долгое выполнение задач, изобретение велосипедов и попытка переделывания проекта под код своего вида, что пресекалось тим-лидом.
Троечник же спокойно смог вникнуть в процесс, находил решения в интернете, сдавал вовремя задачи. Вроде бы и учился на тройки и знаний меньше, но теперь работает в компании и делает успехи, а отличнику в работе было отказано.

Аккуратнее стоит быть со своими желаниями.
У меня друг работал руководителем проектов в телекоме. Компанию называть не буду, но крупный поставщик мобильной связи. И его часто отправляли в командировки. И вот что он рассказал:
1. Чаще всего ездишь по России, причем туда, куда директор фирмы не поехал бы.
2. Часто заказчики встречают тебя на абум и без особого энтузиазма и соответственно комфорта.
3. Сейчас активно развивается связь и командировки уже не так нужны. заказчики воспринимают их как зло, а компания как лишние траты.
4. Часто в командировках не хватает времени на отдых - это работа, много работы. Сроки сжатые, дел по горло, на отдых времени нет.

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

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

Мой тебе совет от бывшего .Net Junior'а: напиши что-нибудь законченное и решающее определенную задачу. Например, я писал rest сервис проверки товаров: 1 контроллер, 4 вида запросов и простая таблица в БД. Главное чтобы это работало.
Тебе нужно показать, что ты умеешь решать задачу удобным тебе способом.

Чего ждут от Trainee .Net девелопера?

Умения работать с технологиями на базовом уровне и их понимания.

А вообще не смотри на то, что должен уметь Junior или Trainee. Смотри на то, что должен уметь Middle и стремись к этому. Лучше показать свои навыки по полной, а не соответствовать требованиям вакансии.

Апплеты давно не стоит использовать. Это медленно и долго. Их время прошло. Сейчас можно сделать тоже самое более быстро и просто.
Апплеты - мертвая технология.

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

Как стоит делать?

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

Изучить нужно базовые библиотеки для работы с сокетами и данными, а также файловой системой. Для более продвинутого сервера стоит познакомиться с потоками, чтобы можно было делать параллельную обработку запросов.
Еще полезно прочитать про Http протокол и принцип работы сервера.
Вот пример сервера https://github.com/egor1996em/WebServer