Вадим Маткаримов

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

В ASP.NET Core node используется в основном для сборки и управления front-end (bundle, less и т.д.). Преимущество в том, что тем кто пишет front-end это всё хорошо знакомо, а в ASP.NET отпадает необходимость писать свои велосипеды и костыли.

Создавать по модели на каждое представление?

Модель в контексте MVC это не модель отдельных сущностей, а модель части системы (или всей системы), которая нужна для этой конкретной view. То есть представьте себе "модель" системы как нейкий объект, внутри которого есть другие объекты, которые работают с третьими и так далее. Такая вот иерархия. Так вот вьюшки выходит коннектятся каждая к своему кусочку этой иерархии, и по сути кроме этой точки соприкосновения ничего более о системе не знают. У них весьма ограниченное представление о системе и много знать им не надо.

Так вот. В REST "вьюшка" у вас - репрезентация ресурса. И они не должны (хоть и могут) быть проекцией таблиц в базе данных.

Получается на каждую сущность по 20 моделей?

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

Так же есть подход, описанный в стандарте jsonapi.org, где у вас есть дополнительные параметры в query string, которые позволяют "включать" определенные группы связанных ресурсов и т.д. Это дает нам определенную гибкость в плане работы с API но в случае например мобильных приложений есть свои нюансы.

появилась какая-то боязнь ошибиться.

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

самым простым сейчас видится апворк, хороший работник примерно за 1-3 месяца выходит в топ.
Конкуренции в топе там практически нет и все друг друга знают.

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

Я вот например начинаю сопроводительные письма с того, как будто уже начал изучать его проблему без его утверждения, вобще безотказный вариант, иногда даже сами заказчики писали мол "вы уже начали? Давайте созвонимся я не все указал в задании"

1) ну верстка это что то между дизайнером и фронтэндером, соответственно дизайн или фронтэнд
2) 4-5 отзывов достаточно

Готового провайдера для mongodb вроде нет пока.

Человек пишет, что можно без проблем подсунуть IDataAccessProvider для MongoDb. Команда разработки пока такой провайдер не написала, но планы вроде как есть. Тут можно глянуть как работать с реализацией этого интерфейса на примере PostgreSql.

Andriy 18 Oct 2015 3:19 AM #
Is support for NoSQL DBs (like at least your DocumentDB, or maybe MongoDB) going to appear in the nearest future?

Rowan Miller 19 Oct 2015 10:09 AM #
@Andriy – Yes, we prototyped a couple of non-relational providers to make sure the core architecture worked for them. Our focus for the next few months is on shipping a stable product with a limited set of providers, but we absolutely still want to build out some non-relational providers.

Контроллеры - это ваши проекции сущностей в сервисе (грубо говоря, объектов ваших классов бизнес-логики) на ресурсы веб-API, предоставляемого сервисом. Какие сущности проецировать на ресурсы, а какие - нет, целиком зависит от того, какое API вы хотите получить в конечном счете. В каких контроллерах это делать и стоит ли разбивать N контроллеров на M контроллеров - зависит от того, как вам удобно их реализовывать. Ну это примерно то же самое, что спросить "стоит ли разбивать 5 классов на 10?". У каждого контроллера - своя ответственность. Если вы четко понимаете ответственность каждого контроллера - разбивать не надо. Если вы перестали понимать и какой-то контроллер начал делать слишком много разных вещей - надо разбить.

Нужно понимать, что лучше сначала спроектировать интерфейсы взаимодействия крупных компонент: клиентов и сервисов, а потом уже эти интерфейсы реализовывать. В случае REST, вы сначала проектируете REST API, исходя из задач вашего приложения, а потом уже реализуете сервис и клиент.

методы реста post (добавление, обновление, удаление, просмотр)

вот этой фразы не понял.

В гугл-плее игру можно шарить между разными dev-аккаунтами. Соответственно вы будете видеть игру в дев.консоли и смотреть всю статистику. Думаю что в подавляющем большинстве других маркетов и агрегаторов есть такая же фича. Тут уже вопрос к издателю - захочет ли он такое делать.
Во вторых вы можете вставить свою статистику - Dev2dev, flurry, GA и собирать все что вам нужно еще и в нее.
В третьих - задайте этот вопрос своему конкретному издателю - у него могут быть свои механизмы для этого.

Umed Khudoiberdiev. Create a gulpfile and write gulp tasks using TypeScript. link

Регистрируйте ИП, однозначно.

1. Сейчас не только налоговые каникулы на 2 года, но и надзорные на 3 года. Государство готово закрыть глаза на многие вещи, так как консолидирует нацию перед бурей. Когда буря начнется, а начнется она скоро, двери закроются и будет действовать лозунг "кто не с нами, тот против нас".

2. Уже сейчас например модульбанк для вывода средств с Upwork требует сертификат доходов за год. В любой момент ЦБ может заставить остальные банки делать тоже самое. В этом случае легализовать деятельность, не спалившись что Вы как минимум год не платили налоги, Вы уже не сможете.

3. Payoneer в принципе почти так же прозрачен как счет в сбербанке.
США сливает данные российской налоговой с 2014 года rg.ru/2014/04/24/obmen-site-anons.html
В 2018 слив перейдет на новый уровень rg.ru/2015/01/20/informacia.html

4. Сейчас Вы налоговой не интересны, потому что взыскать с каждого фрилансера упущенный налог просто не рентабельно. Однако налоговая во всю строит дата-центры https://data247.ru/2013/08/07/dlya-nalogovoj-polic... Первый открылся в 2015, к 2018 налоговая будет всех крепко держать за чувствительные места www.1tv.ru/news/social/284558

С PayPal все не так однозначно, они могут сконвертировать в рубли даже если единственная валюта аккаунта это доллары.

Wire transfer единственный легальный способ.

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

Можно прислать на api-support@ok.ru письмо с id приложения и первой половиной секретного ключа.
Удалим.