Виктор П.

Когда-то давно тоже был опыт создания сайтов по ТЗ и это была боль - приходилось делать долгосрочные эстимейты (которые никто никогда не угадывал), тратить кучу времени на ТЗ, чтобы не пропустить ни одной детали, затыкать заказчику рот этим ТЗ когда он через месяц менял свое мнение.... ну и т.д.
С тех пор только спринты - в начале приблизительно оцениваем сложность проекта чтобы определиться с инструментами разработки и обязуемся через N недель выдать MVP. А дальше "любой каприз за Ваши деньги" - новые фичи == новые спринты == платите. Клиенту останавливаться после первого же спринта смысла нет - он заинтересован в готовом продукте, а смена исполнителя это доп. траты. В то же время и у клиента и у исполнителя есть шанс не продолжать сотрудничество после определенного спринта если вдруг испортятся отношения. Клиент сам рассчитывает за что он платит и когда остановиться.
Я правда уточню, что в последнее время я работаю в большой компании и в моем случае "клиенты" - это стейкхолдеры, которые работают в этой же компании. Но в данном случае они мало отличаются от "аутсорсного" клиента, потому что они являются заказчиками проекта, у них есть определенный бюджет и наше сотрудничество выглядит именно так как я описал выше.

Подтролливают тебя немного =)

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

Вот, например, забавный вариант: Казахстан/Астана. Молодой, современный город. В прошлом году прожил там 5 месяцев случайно, и, надо сказать, в восторге. Сам из СПб, сравниваю с ним.
Страна мусульманская, но это заметно только тем, что синьки по улицам не шатается и гопотни во дворах не сидит. Ночью в любое время прогуляться приятно. Малышня без присмотра взрослых и мамы с колясками гуляют до 2 ночи. Люди сами по себе добрей, чем в СПб. У меня по возвращении был культурный шок. Неделю дома сидел - выходить не хотелось.
Цены низкие на все. Питаться - практически бесплатно. Самый лучший шашлык в моей жизни попробовал именно там, в отличном ресторане, в который местные не ходят, т.к. дорого. Шашлык обошелся в 150 рублей.
Транспорт - автобусы. Но за 5 месяцев я ездил на автобусе 1 раз. Потому что убер "бесплатный". Однажды довелось проехать весь город по диагонали на Порше Кайен за 100 рублей! Это убер икс, не блэк.
Казашки очень красивые девушки и любят "фарангов" =)
Климат/погода прекрасные. Один нюанс - нет демисезонов. Лето, а потом сразу снежок пошел =)
Жилье - по разному. Я немного жировал и снимал огромную светлую новую квартиру в неплохом районе. По деньгам где-то 30к+ выходило. Интернет шикарнейший. Во время моего там прибывания проходила выставка Экспо 2017, поэтому цены были очень высокие. Выставка кончилась, должны были сильно упасть.
В общем, на $1000 там можно жить очень комфортно. Заморочка одна - виза. Въезд без визы, на 1 месяц. Потом надо идти в миграционку с хозяином квартиры ( надо договориться с ним, чтоб сделал тебе гостевую визу ). Ее продляют до 3х месяцев ( то есть первый + еще 2 ). Потом по-любому бордер-ран нужен. Ну и по новой. Заморочек никаких.

Тайланд ( сейчас тут как раз, уже 4 месяца ). На $1000 вполне можно жить. Все упирается в желаемый уровень комфорта и любовь к транжирству денег =) Паттайю не советую. Мое мнение - помойка полная. Куча прекрасных мест. В качестве бюджетного варианта посоветовал бы Краби попробовать. В Краби мало пляжей, делать особо нечего, но спокойно и дешево. Самое то, чтоб начать. И чтоб на байке научиться кататься - там движение хорошее, спокойное, дороги кайф. Домик можно снять тыщ за 8-9 бат неплохой ( в рублях, грубо, х2 ). Считай в 20к уложишься. Важно, чтоб с кухней. Тайская еда осточертеет, начнешь по дорогим рестикам ходить. Я вот в какой-то момент по 1-2к бат в день на хавку сливать начал =) Ужас. Байк на месяц 3к бат. Безнин дешевый, байк почти не ест. Похавать самому - зависит. Можно и в 100бт уложиться. Средняк для пацана, я бы сказал, 200-250бт, если с пивом ( в рестиках дороже в 2 раза, нежели в магазе ). Питаться дома дешевле, большие магазины есть, чтоб затариваться. В общем - на $1000 прожить вполне можно, если не загуливать особо. А вот загулять тебе может быть очень несложно. Тайку в постель заполучить тут сильно проще ( и дешевле ), чем в России симотную девку в кино с рестиком сводить без каких-либо дальнейших перспектив. Так что - самодисциплина прежде всего =)
Если хочется чего-то пошумней, чтоб движухи побольше - Пхукет или Самуи можно попробовать. Пхукет - дорогой с туристической стороны ( на западе острова ), а вот если поселиться в Равайе - можно тоже очень бюджетно. Есть хорошие кондоминиумы, где отличнейшие квартирки по 8-9к бат. Но действительно очень хорошие и с кухней. Самуи считается дорогим местом, но "места надо знать". Туристам простым жилье загоняют за большие деньги, зная места можно снять прекрасный дом за 10-15к бат. Дом! С кондеем, гигантским балконом, 2-3 комнатами и т.д. На Самуи тьма русских ( больше чем тайцев по ощущениям ), русские всех сортов - от быдо-нариков-бухариков, до семей с кучей детишек и т.д. Кому-то наличие соотечественников плюс, кому-то минус. Но в твоем случае может плюс - больше помощи, советов, поддержки и т.д. Не так сложно начинать бродяжничать будет =)

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

У Вас не правильный подход. Во первых забудьте про Thread и используйте TPL. Во вторых для распараллеливания запросов в цикле есть замечательный метод Parallel.ForEach. В третьих для ожидания выполнения всех параллельных задач есть Task.WaitAll.
В общем Вы можете создать список Task-ов и запихнуть их в Task.WaitAll, но лучше пройдитесь параллельным форичем по Вашему периоду и внутри запускайте Ваши методы. Код за форичем будет ожидать завершения всех потоков в цикле.

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

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

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

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

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

На самом деле, если отбросить лобби и прочие теории заговора, есть одно (не моё), но подслушанное мнение:
На C# любую вещь, можно сделать нормально одним, максимум двумя, нормальными способами. На Java это может быть 20 различных (и даже, в какой-то мере, нормальных) способов. Учиться на этом можно, но на C# проще.

Потому что C# миленький

будет жить своей жизнью, независимо от меня

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

3D графику позволить себе не могу

поищите начинающих художников

в виде обычных графиков и цифр

их еще сложнее придумать

Город будет иметь небольшие окрестности, в которых необходимо реализовать рост растительности и активность некой фауны.

и как она буде симулироваться? Есть уже соотношения, сколько нужно вырастить деревьев и живности за один тик?

При добыче ресурсов, охоте, остаток должен высчитываться дабы исключить бесконечные ресурсы.

ага и потом все умрут от голода или все заполонят лисицы

Начать вам стоит с создания своей версии игры Life
Там поймете в чем суть и проблематика вашей затеи
Сразу определитесь, как будут взаимоействовать между собой игроки и будут ли
Несколько серверов не понадобится - для обсчета симуляции много ресурсов не требуется (если не написать фигни вместо кода)

Фреймворк в данной задаче не сильно поможет, если только не сумеете спроектировать все так, чтоб валидации и сохранение через него проходили

Заказчик хочет чтобы разработчик сделал сложное приложение.

Причина 1: обычно заказчик хочет, но не знает чего конкретно. Фишка в том, что разработка приложения, у которого ещё нет аналога - это... не только разработка приложения. Это ещё и выяснение того, что действительно нужно, начиная с пожеланий по UX, и заканчивая оптимизацией бизнес-процессов во всей компании (это когда заказчик внезапно говорит "слушайте, и правда, на кой чёрт мы печатаем эту накладную каждый раз").

КПД получается крайне низок.

Причина 2: вы не учитываете причину 1 при расчёте КПД и думаете, что проделали мало работы. Да, приложение ещё не готово или делается очень долго, но это не потому что вы мало работаете, а потому что работы намного больше, чем казалось.

но идёт на удаление или переделку из-за того, что что-то не так.

Причина/особенность 3: иногда это неизбежно: бизнес меняется, потребности - тоже.
Иногда этого можно избежать, не заводя требования слишком "далеко" - очевидно, нет смысла реализовывать то, что УЖЕ СЕЙЧАС кажется неподходящим под требования, НО это далеко не всегда вовремя замечают. Над проектом работает много людей, у всех немного разные представления о задаче, или ещё хуже: не все и далеко не всегда говорят о проблемах с системой, которые уже виднеются "на горизонте", говоря что "в ТЗ всё написано, а мы делаем по ТЗ". Можете погуглить статьи о стоимости ошибок на разных этапах разработки.

Причина 4: заказчик, разработчики или и те и другие не умеют останавливаться и выбирать необходимый и достаточный функционал для первого или очередного релиза. Я в последнее время убеждаюсь, что это целая наука - вовремя остановиться и не расширять список "супернужных" фич, из которых треть окажется почти невостребованными. Особенно часто это бывает, когда бизнес уже работает как-нибудь (например, на экселевских табличках или Access-овских базах), а теперь пришла пора автоматизации, но релиз постоянно откладывается, потому что "и это хочется, и то бы сразу сделать". Иными словами, иногда нужно решиться на гарантированные переделки в будущем ради релиза сейчас. Оценка возможности и стоимости таких "переделок" - т.е. подождать и переделать сейчас или зарелизиться и переделать потом (соответственно, с удорожанием "переделок") - и есть та самая наука. Разработчик обычно видит только архитектуру, и раньше понимает её недостатки/ограничения, ему сложно решиться на релиз того, что не будет идеально решать поставленную задачу.

Ремонт ЗАКОНЧИТЬ нельзя — его можно только ПРЕКРАТИТЬ.
https://www.inpearls.ru/

- © Михаил Жванецкий

1. Лет 10 строишь карьеру по найму, нарабатываешь профессиональные контакты;
2. Уводишь из конторы 1-2 жирных клиентов на себя, увольняешься, берешь в подмогу кореша и ведёте их, попутно оформив контору типа "Luxextrasupersoft";
3. Работаете хорошо, вас советуют коллегам, прилетают новые заказы/клиенты, вы с корешем уже не справляетесь, нанимаете команду, офис, диваны, все дела;
4. В фитнес-клубе знакомишься с менеджерами и предлагаешь вместе распилить it-бюджеты их контор путём аутсорса на Luxextrasupersoft;
5. Когда образуется финансовый жирок, решаешь пустить его на рекламу, нанимаешь сейлза, но быстро понимаешь, что это не так рентабельно, как наработанная за 10 лет сарафанка и откаты))

Собственно, эта схема актуальна не только для it.

да

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

А вообще, делайте хоть как нибудь. Хоть в процедурном стиле, хоть с использованием GOTO, хоть называя переменные сМиЩнЫмИ названиями. Главное начните уже писать хоть что-нибудь, если упражнения вы уже переросли. Перед тем как вы напишете что-то полезное вам ПРИДЕТСЯ прокачивать скилл на чем-то простом.

Подавляющее большинство всей литературы о программировании не о том как сделать 2+2 а о том, как сделать некий кусок работы более простым/быстрым/надежным/дешевым способом. Но никакого смысла нет в это вникать, если вы не можете написать вообще никаким.

Лично я ушел из-за неумения эффективно работать из дома. Как только этот косяк исправлю, вернусь обратно)
Из преимуществ работы в офисе я бы отметил:

- Гораздо быстрее и качественнее прокачиваешься технически
- Платят за время, проведенное на работе. Если нагрузка не слишком большая, можно выкроить время на самообразование и даже свои проекты. Получается типа коворкинга, оплачиваемого работодателем)) При всем к нему уважении.
- Начинаешь более эффективно расставлять приоритеты и распределять ресурсы - как и с помощью чего лучше решить задачу, потратив на ее решение минимальное кол-во времени и сил. Это особенно важно для людей, склонных к интеллектуализации - бесконечному поглощению информации без ее практического применения. Сидя дома я очень много изучал теории, а практики было минимум. В офисе все стало наоборот и я начал избавляться от этой патологии.
- Учишься работать через силу. Если ты с бодуна, не выспался или еще что, то ты не имеешь права сделать себе выходной. Как миленький с утра придешь на работу и досидишь там до вечера. На фрилансе я частенько забивал на работу, если был в плохом самочувствии.
- Проблемы по организации работы решает за тебя работодатель - как гора с плеч, только кодишь и все)

есть у вас пачка стандартных вопросов, пишете на них ответы. Вопросы на которых нет ответов , записываете в лог, а юзверю отвичаете "не имею ответа на ваш вопрос, обратитесь позже", потом каждых пару дней чекаете лог и пишете ответы. да дибильно , да муторно зато просто. Как вариант найдите словарь в интернете который так же пополняйте, вопросами ваши клиентов. Словарей таких дохрена, словарь типа "вопрос" => "ответ".

Семантический анализ естественных языков - одна из самых тяжелых задач в computer science. Намного тяжелее, чем ИИ для шахмат (который научился обыгрывать человека еще двадцать лет назад). В этом направлении мировая наука пока еще продвинулась совсем недалеко. Браться за это в одиночку не стоит без трех высших образований (одного из них по лингвистике).