German Jet

Что кто может сказать про TypeScript?

Учите, не пожалеете.

• типизация поставит мозги на место;
  
• фичи, связанные с типами и инкапсуляцией надстраиваются над JS, т.е. не нужно знакомиться с полностью новым синтаксисом; даже терминологически разработчики TS стараются не расходиться с JS;
  
• язык позволяет не бояться роста проекта; собственно сейчас большой объём фронтэнд-кода и заставил нас переходить на TypeScript; чем больше кода и чем больше команда, тем выгоды от TS перевешивают затраты на внедрение;
  

Минусы:

• усложнение процесса сборки, т.к. нужна компиляция (это относится к любому из не-JS языков);
  
• придётся заботиться о наличии type definitions;
  
• есть некоторые нетривиальные вопросы во взаимодействии с JS кодом. В общем-то ничего проблемного, просто нужно понимать, что как работает;
  

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

Потому что localhost отдельный у эмулятора и у системы на которой он запущен.
Обращаться нужно по IP системы (на которой запущен эмулятор) - если из эмулятора, и по IP сети присвоенной эмулятору - если из системы.

Во-первых, огромное количество сайтов всё ещё пишется без фронтенд-фреймворков. Во-вторых, Angular вполне можно использовать и с Django. В-третьих, если на фронте SPA, то на бэке можно использовать Django Rest Framework. И наконец, Django полностью синхронный. Если нужен асинхронный сервис, придётся использовать что-то другое.

Подавляющее большинство - придурки и фантазеры. Сидят и пузо чешут "вот я щаз сделаю свой фейсбук... $50 у меня есть, надо фрилансера найти", идут дают объявление, а дальше дело редко заходит.

У нас вчера был случай. Неделю переписываемся с клиентом - девушкой. Вчера прислала мужа на переговоры. Муж посидел минут 10, вообще ничего не понял и спешно убежал. Через полчаса девушка пишет "Извините, в ваших услугах не нуждаемся". Спрашиваю "Почему?", отвечает "Потому что вы ничего внятного не объяснили".

Хотя с ней план действий согласовали от и до, показали красивое портфолио и (по рекомендации) предложили пакет услуг без предоплаты на условиях "если не сработает - вы не платите".

То есть ну полный идиотизм. Это часто происходит. И, к сожалению, это нормально.

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

Кратко, вот https://developer.android.com/training/index.html

писать на джаве сразу под андроид, программ под андроид без UI изчезающе мало.
Устанавливать можно напрямую, через adb.
маркет не обязателен.

Solidity
Эфир - Биток
существование фреймворков для частного блокчейна (Hyperledger / те, что в вакансиях)
принципы консенсуса, примеры, и реализацию
и сорта вазелина

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

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

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

2. Использование готового фрейморка, с которым вы никогда не работали
Готовьтесь потратить массу времени на его изучение. Порой даже на решение тривиальных задач в некоторых фреймворках придется потратить несколько дней, если вы с этим никогда не работали. По собственному опыту могу сказать, что если сравнивать варианты (2) и (4), то готовьтесь потратить в 3 — 4 раза больше времени. Однако у этого варианта есть и плюсы: вы освоите ещё один фреймворк и в следующих проекта сможете выбирать вариант (1), другим разработчикам знакомым с данным фреймворком будет гораздо проще разобраться в коде, последующая разработка и развитие проекта существенно ускорятся.

3. Использование собственного фреймворка
Рекомендуется только строго после того, как вы несколько лет поработали с разными фреймворками, точно знаете их недостатки, четко можете сформулировать, почему в данном проекте не подходит ни одно из готовых решений. Плюсов у такого решения масса, но основной — ваш фреймворк будет оптимальным образом решать именно ваши задачи, он не будет «комбайном», пытающимся угодить всем вокруг. Но и минусов хватает, крупные фреймворки как правило развиваются огромным сообществом, сотни и тысячи разработчиков ежедневно находят и исправляют в нем ошибки, расширяют функциональные возможности, улучшают производительность, заменяют устаревшие решения на новые.

4. Вообще без фреймворка
Такой проект сильно рискует превратиться в спагетти-код. Но абсолютное большинство новичков начинает именно с этого. В этом нет ничего страшного, если это ваш первый проект, вы освоитесь с языком и его возможностями, набьете кучу шишек, и неизбежно рано или поздно перейдете к вариантами (1), (2) или (3).

1) С учебника по джаве
2) Учебники конкретно по Андроиду, затем изучение котлина по документации
3) Нужна