Андрей

всем привет, вижу, что ветка довольно старая, но все таки свои 5копеек вставлю.
Я считаю, что два самых прибыльных метода монетизации- это продажа внутриигровой валюты и реклама. По своему опыту скажу, что монетизировать аппы через рекламу не есть самый простой вариант, но зато самый быстрый и прибыльный. Не самый простой в плане того, что надо очень грамотно подойти к вопросу выбора, как типа рекламы (баннер, интерстишл, видео), так и места в своем приложении в котором эту рекламу, собственно, показывать собираетесь. Это по сути самое важное, потому что если этого грамотно не сделать - можно нахватать кучу отказов в стате.
Из рекламных сетей сразу же хотелось попробовать медиацию. Свою игру я запустил в январе и ориентируясь на отзывы подключил к ней Admob. Поначалу использовал только баннеры и рез-ты были не очень: в сред. 500К показов и всего $1K в месяц. Потом помимо баннеров стал использовать интерстишл и результаты заметно улучшились: в месяц уже выходило порядка $3,5-4000. По отзывам Admob вроде как считался крутой медиацией, но в июне я наткнулся на другой сервис -Appodeal. Захотелось их попробовать -потому что у них есть возможность использовать кучу сетей, да еще и подключить свой адмобский аккаунт- получается что-то вроде "медиации в медиации", так что при любом раскладе ты ничего не теряешь... отдельно хочется отметить их суппорт, который помог реализовать еще и показы видеорекламы в моей игре (rewarded video). Теперь по одним интерстишлам в месяц получается около 900К показов в месяц. В целом доход с моей игры за сентябрь составил $10.1K, так что выгода на мой взгляд очевидна:) Возможно в след году опробую еще какой-нибудь сервис, но пока достойной замены я не вижу.

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

вобщем, че вы много написали.
Все просто если Модуль банк.
1. открываете счет в модуль банке и валютный счет
2. покупаете патент, основная система УСН!!!(очень выгодно)
3. В модуле есть инструкиция по документам с Апворк для модуля
4. По вопросам пишите им в поддержку, отвечают очень качественно
5. Все сертификаты, скрины и т.п. от апворка заполняете так, чтоб все сходилсь.

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

Хахаха, порвало пока читал)
Очень забавная история.

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

2) В разы проще сделать рефаунд и удалить отзыв и просто забыть, поверьте - время лечит и всех отпускает

3) На самом деле нету в таком отзывы катастрофы - да, это не супер, но и не конец света. Я 100 раз видел как с плохими отзывами берут фрилансеров и без всяких проблем

4)

5) Отомсти говнюку и накатай в ответ отзывок на всю жизнь

Лет 7-8 назад купил один Synology, потом другой. Но перестала устраивать скорость работы, а быстрые дОроги.
Начал искать нечто похожее, плюнул, взял миниАТХ-плату засунул ее в небольшой корпус, поставил Ubuntu.
Тянет все сервисы на отлично, web, ftp, media-server, cod4-server, samba... Рекомендую.

Собрать CEPH storage с бекендом bluestore минимум на пяти серверах с фактором репликации 3. Потребуется 100Tb сырого дискового пространства. Контрольные сверяются как на сети, так и при хранении на дисках.

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

Во вторых, отдельные воркеры в Apache нужны только для тех бэкэндов, которым это нужно.
Если вы хотите максимизировать число параллельно выполняемых бэкэндом запросов, то, очевидно, что нужно искать другой путь, без воркеров Apache. Например, https://habrahabr.ru/company/itsumma/blog/337346/

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

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

В пятых, неквалифицированному программисту не поможет никакой волшебный инструмент.

В шестых, при прочих равных (при одинаково хорошем познании программиста в обеих системах) - JVM будет завсегда быстрее. Ибо она и от С-то отстает ненамного.

В седьмых, но нельзя не обратить внимание на тот факт, что используя Ноду можно обойтись знанием одного языка. Собственно, взлет Ноды именно этим и обусловлен. Что множество фронтендеров, которые желают писать бэкенд. И написали уже для нее кучу вспомогательных инструментов/библиотек и пр. Более ничего такого особо волшебного в Ноде нет.

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

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

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

Если уж так хочется бложик, то я бы оставил его в покое в виде самостоятельного сервиса, а в качестве других сервисов сделал бы:
- уведомления о новых комментариях/постах в мессенджер/почту (как раз хорошо будет через MQ общаться с основным сервисом);
- какую-нибудь аналитику элементарную, которая независимо собирается, например по посетителям, телеметрию короче;
- сервис автопостов - заказываешь пост с нужным содержимым на указанную дату и время, этот сервис пользуется API основного сервиса бложика и постит что-либо без вашего участия.

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

Ну AWS это всего-лишь сервис. В чем смысл SOA? Что вы пишете свой код так, чтобы он не был Жестко привязан к провайдеру сервиса. Чтобы провайдеров можно было лекго менять. Разбейте Ваше приложение на такие компоненты, чтобы в любой момент их можно было перенести куда Вам угодно в течении дня.
Мы используем для этого Ansible - система провижионинга. Мы ей "говорим" вот тебе ip сервера, логин, ключи - подними там наше приложение, ( Как поднимать, придется написать конфиг, и это занимает время, закто какой результат) И ансибле разворачивает там наше приложение. Завтра если нам не нравится Amazon, мы покупаем другую vps и указываем другой доступ - и вуаля - наше приложение за полчаса уже на другом сервис провайдере.
Конечно ansible это всего лишь инструмент - основную мысль вы уловили - архитектура такая, в котором приложение не зависит от провайдера. Если сегодня Вас амазон устраивает - используйте.

Нужно позволить всякому шлаку проплыть мимо вас. Не нужно вкладывать много времени в изучение того, что завтра изменится. Лучше тратить время на фундаментальные вещи, срок жизни которых больше 5-10 лет.
Примеры:

• Реляционные СУБД. Я использую их уже лет 10, и ничего принципиально нового (с точки зрения разработчика) в них не появилось. Я как изучил SQL 10 лет назад, так и пользуюсь им до сих пор. В тоже время, я знаю достаточно хипстеров, которые каждый день пишут на новом фреймворке и при этом не смогут составить запрос с joinами. Изучайте реляционные базы данных и SQL - они будут жить еще лет 20-ть;
  
• ООП. У меня на полке лежит книга банды 4-х, которую я купил давно. Мне не нужно каждый год покупать новый экземпляр из-за того, что шаблоны проектирования вдруг взяли и "устарели". Изучайте ООП. Оно будет актуальным еще очень долгое время;
  
• Регулярные выражения;
  
• Командные оболочки sh/bash;
  
• и т.д.
  

Короче говоря, не тратьте время на синтаксис, тратьте его на семантику.

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

Хочешь быстро выкачивать в продакшен? Вруби режим Vanille. Пиши, параллельно свой проект. Зацепись за один язык как основной и дальше учи всё в нем вдоль и поперёк. Затем, как всё выучишь, хватай самый сложный фраемворк и от сложного к простому начинаешь разбирать. Это мой подход.
Для наглядной статистики: я врач, у меня 8 часовой рабочий день. С сентября 2016 начал изучать PHP и JavaScript. С 1 января по 9 января 2017 пишу програму которая помогала мне писать истории больных. Сейчас программа пользуется популярностью и ей пользуется вся ординаторская. Сейчас проект переписывается на Symfony 3.
Что мне понадобилось: время после работы, интернет.

Ровно по этому вопросу есть видео, в котором Heinz Kabutz все подробно рассказывает:
https://www.youtube.com/watch?v=uKc0Gx_lPsg

1. Получение четкой задачи.
2. Согласование сроков.
3. Получение предоплаты.
4. Работа в срок.
5. Сдача.
6. Получение оплаты.

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

Также интересует насколько хорошая практика делать правки прямо на сервере

Ну как она может быть хорошей, сами-то подумайте? Откатывать потом из бэкапа хостера? А если там один архив на десяток сайтов?
Вариантов может быть много, но копия "как было" всяко должна остаться.
Обычно к таким запасным копиям пишу срок хранения. Типа "project-name-backup-delete-09-2017".

Мне 35 лет, и по-настоящему фул-тайм в ИТ я работаю только второй год. (Правда, первый настоящий год был 10 лет назад, и уже тогда у меня было лет 10 любительского программирования, а следующие 10 лет я время-от-времени фрилансил - ну, по принципу: "две недели поработал, два месяца отдыхаю", и в частности, в рамках этого фриланса 3 года делал домашки, контрольные и курсовые по программированию парочке американских студентов). Но в целом у меня, согласись, поздний старт.
Так что не робей! Выучи Java (это самое востребованное в Мск), походи по собеседованиям (с обязательной работой над ошибками после каждого собеседования), и тебя возьмут. Тем более, что в мире Java полным-полно не только 23 синьоров и 40-летних миддлов, но и 30-летних джунов, из-за женитьбы перешедших из голодной пыхи и изменчивого веба в мир корпоративной стабильности.