В случае разработки на заказ я бы советовал вместо УСН узнать сколько стоит патент (ПСН) на этот ОКВЭД в вашем регионе - это может оказаться выгоднее. Не везде правда. В москве патент на год стоит 300тр, в Санкт-Петербурге 60тр, в других городах - еще как-то, ли вообще вообще нет возможности взять патент.
LBC: насколько я понимаю, тут рассматривается вопрос сведения автономного дебета с кредитом. Если есть кто-то, кто обеспечивает, то это скорее развлечение. Тогда можно программировать просто в удовольствие. $1000 за полгода это что-то около 10 000 рублей в месяц. По факту полгода надо еще где-то жить и что-то есть. Коммерчески невыгодный стартап, думается, не окупил себя :)
Алексей Бурлака: ну и правильно. Ничто так не учит, как выведение проекта из грязи в князи без лишних революций и шапкозакидательств. :)
Кстати, на мой взгляд, клиенту лучше доносить информацию об улучшениях. Просто можно использовать форму подачи соответствующую. Например, "в рамках работы над текущими задачами также были произведены улучшения в имеющемся коде, что дало улучшения по скорости / стабильности / масштабируемости / поддерживаемости и тп (см. -ilities https://en.wikipedia.org/wiki/Non-functional_requi... кода. Клиент обычно рад, что эти вещи по ходу обычной плановой работы - тоже под контролем и улучшаются.
Ironicman: компактность в ущерб читаемости - зло :) А зачем вам именно с помощью одного LINQ выражения писать эту логику?
Напишите тут не сокращая (с осмысленными именованиями переменных) все выражение, я попробую показать вам как отформатировать это так, чтобы выглядело не "дико" и читалось внятно.
Дмитрий Петров: для CRUD через EF обычно пишется с десяток хелпер методов (как extensions, например) - не так сложно. Задача разовая. Кеширование в MVC (если пользуетесь API) лучше делать пометив Controller actions методы атрибутами типа https://github.com/filipw/Strathweb.CacheOutput
Это верно. Когда заказчик сам что-то когда-то кодил, и мешает работать. Микроменеджмент. В этом случае работа будет сводиться к угадыванию мыслей клиента - какой код и метод решения он считает правильным. Морока. Хотя если вы нормально переносите переписывание логики по пять раз и возврату на шестом круге к вашему исходному решению, то жить можно. :D
bitchwherr: я не соглашусь с мнениями, высказанными в статье. В продуктовых компаниях очень часто возникает некая своя "исторически сложившаяся" модель работы. Для обучения и входа в профессию я бы, напротив, рекоммендовал именно аутсорс компании. В них вы сможете поработать на разных проектах для разных клиентов компании. Это позволит получить представление о том, как может строится работа - разые варианты. У вас сформируется свое мнение о том, что хорошо и что не очень. В продуктовой компании этого нет. Наша профессия (по личному опыту и историям моих знакомых) не часто позволяет оставаться на одном месте всю жизнь :) Поэтому знакомство с вариантами даст больше опыта и необходимых для дальнейшего развития навыков. Но моя позиция, разумеется, всего лишь одна из возможных. Решайте сами.
AquariusStar: когда я менял сферу деятельности с геолога на программиста и писал в рамках диссертации по геологии программку для геологического моделирования, я начал делать это на С++. Провозился изрядно, хотя там не было чего-то слишком сложного - десктопное приложение и 2D рисование. Как раз тогда появился С# и я попробовал решить задачу на этой платформе. То на что уходили недели в плюсах, делалось на дотнете за дни. С тех пор я и продолжил работать с дотнет и отлично себя чувствую, хотя иногда приходится под задачу воспользоваться всякими прочими языками и инструментами. Мне дотнет нравится тем, что вся экосистема довольно консистентна и изучение новых областей разработки (с веба на мобильную, или еще какую-то) не требует больших усилий - все интуитивно понятно. В той же Java экосистеме (очень похожа на дотнет) раньше было несколько производителей всяких базовых библиотек и какждый норовил все сделать по своему. Сочетать их было сложно. В дотнете даже когда компоненты разработаны не Майкрософт, а сторонними компаниями - все обычно консистентно и сделано согласно рекоммендациям Майкрософт. Не приходится для какждого нового фреймворка долго и нудно разбираться в сути его концепции.
Schullz: поддержка С++ в студии гораздо меньше и большое количество инструментов, доступных при C# разработке, для плюсов не поддерживаются или работают нестабильно. С++ Team в Microsoft активно работает последние 3-4 года над раенимацией популярности С++ в сообществе разработчиков, но пока значительно отстает эта экосистема все равно. Если работать в Visual Studio, то C# - это must have, C++ nice to have, но можно и обойтись. По крайней мере на этапе обучения и входа в индустрию - точно.
BloodyBlade: тогда все правильно - отделить UI от логики через API. Основной риск в таких случаях, что в какой-то момент понадобится, чтобы для некоторых UI - были особенности в базе и какая-то специфичная логика в API. Потому я бы советовал в служебной базе предусмотреть такую вещь как версия базы, а для специфичной логики в API - либо выносить специфику в отдельные API проекты, которые будут также использовать базовый API + еще свое что-то, А лучше вообще API изначально проектировать как набор мелких сервисов (пакетов), тогда комбинируя их можно более гибко управлять доступным функционалом. Подход называется micro services - почитайте про них. Версионность API также надо учесть - обязательно будет ситуация когда 10 сайтов должны использовать старую версию API а десять других - новую.
