⚡ Kotobotov ⚡

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

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

>не нравится как он написан
пффф а ты что думал, в сказку попал? тебе и не должно нравиться, это для бизнеса где-то на 25 месте находится.
-----
чесно говоря я вообще не слышал чтоб реально на практике УМЛ использовали, для проектирования (хотя тема когда-то и была на хайпе).
Ну да на черновиках набрасывают общие идеи, сам код также может быть тем черновиком для идей, но это всего-лишь черновик.
=======
>"Давай декомпозируем на задачи и начнем делать. По ходу реализации разберемся"
очень грамотный, взвешенный подход. Основная проблема не опытных людей, попытка сразу выдать идеальный результат в вакууме, люди которые поопытнее знают что это сделать не возможно, а попытка идеальной проектировки приведет только к переусложнению и ухудшит разработку и вместо того чтоб гибко подгонять решение под постепенные уточнения, вы будете стремится все подогнать под рамки какой-то первой "идеальной" идеи реализации, на основе первого восприятия задачи (которое часто ошибочно).

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

хорошо что ты пытаешься улучшать свои решения, ни одно решение не получается делать сразу отличнейшим, это всегда путь через улучшения.
В российских компаниях просто какой-то ад творится в стандартах работы с кандидатами, дать тестовое задание (на которое соискатель неделю потратит) и потом даже ему не ответить - это вполне себе распространенная практика.
Мой совет: никогда больше не делать никаких тестовых заданий, они бесполезны для трудоустройства (да и для обучения развивать их бесполезно, тк это просто какие-то ненужные отдельные задачки в вакууме, а не полноценный проект).
Развивайте свои проекты, участвуйте в чужих опен сорс проектах, участвуйте в соревнованиях и тд -> это ВСЕГДА дает намного больше пользы. А кто захочет вас на "тестовое натянуть" - отправляйте им ссылки на готовые работы, такая схема более эффективна.
Иначе вы погрязните в бесконечных, никому не нужных тестовых заданиях.

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

Первый пример ориентируется на упрощение НО тогда если у тебя существует только ОДНО поле для категории (айди), тогда ты просто пишешь -> {"category": 1} (без айди в имени)
тоесть если и упрощать, так все упрощать, включая названия.
Но скорее всего у категории существует не только идентификатор но также еще и название, что не упростить в одном поле, значит все равно нужно выводить как во втором варианте обьект category, с двумя полями id, и name
просто же выводить обьект с одним вложенным полем - это ненужная избыточность, такое лучше заменить на первый вариант.
-------
по поводу: POST в одном формате, а при GET отдают в другом.
за такое просто в морду бить надо, тк это подразумевает разработчику необходимость создания 2х разных представлений для структур данных одного и тогоже обьекта.

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

да собираются данные заранее, парсятся все подряд запросы, по ним собирается статистика

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

По поводу оплаты произведенного вашего труда, уверен получить за труд оплату - справедливое требование, даже если этот труд кому-то не понадобился
вы же не товар продаете, а труд. вы имеете полное право получать оплату за этот труд, это право закреплено ( статья 37 конституции РФ, пункт 3 цитирую:
Каждый имеет право на труд . . . а вознаграждение за труд без какой бы то ни было дискриминации и не ниже установленного федеральным законом минимального размера оплаты труда).

мошенничество - (думаю до тысяч до 10 даже никто разговаривать не будет по этому поводу, но не уверен)
реально, договора нет, что-то вменить крайне сложно, нужно ну как минимум штук 10 может заявлений на тебя иметь. Тогда будет системность в обмане чтоб это как-то было похоже на мошенничество, а не просто на неудовлетворенного клиента.

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

затравит в интернете? - что за глупости, да всем вообще на срать (ему еще самому скажут, что он мудак).

JS

>Задач множество, каких-то типовых нет.
если задачи уникальные, то все ваши планы по разработке - очковтирательство.

>переход всей разработки на SCRUM, только после того , как мы сможем на цифрах показать выгоду
ваше мышление еще не готово переходить на гибкие методологии.
Многие вещи в цифрах не считаются.
Вам предлагают посчитать в цифрах следующее: идти в магазин ориентируясь на местности или идти в магазин с закрытыми глазами по карте которую вы нарисовали у себя дома, при этом вы никогда не ходили до этого в магазин и вообще не знаете есть ли он там.
По плану и там и там одинаково эффективно вы должны дойти, а в реальности с закрытыми глазами вас через 15 минут пути машина собьет, или вы просто шею сломаете зайдя не туда.
========
Суть в том чтоб за 2 года запланированной разработки, не прийти в помойную яму вместо магазина.
Попытаться все спланировать и посчитать итог работ - это опять из ватерфола, вы живете в недетерминированном мире в котором вы НЕ можете все вокруг посчитать и проконтролировать, вы либо это принимаете и начинаете по другому мыслить и действовать (на основе обратной связи) , либо дальше занимаетесь очковтирательством.
П. С.
бизнес не любит неопределенности, любят гарантии и точные ответы - поэтому заказчик будет все равно ТРЕБОВАТЬ чтоб ему в очки втирали дичь, по поводу обьемов работ и сроков, это основная проблема внедрения гибких методологий, привычка и не желание людей по другому мыслить.

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

можете смело подписывать, у этих ребят нет никаких реальных вариантов с вас в России взыскать эти 5К, в чем бы вы не были "виноваты".

отсутствие вариантов для заработка, нищета.
типа Белоруссия - только в 100 раз больше по населению.
соответственно на фрилансе индусов больше чем белорусов раз в 100.