Спасибо за статью. Мне кажется, могут быть еще решения. Например у нас таблица размеров в 50 колонок и 100 строк. Можно ее отобразить целиком в мелком масштабе и сделать к ней линзу. Водишь пальцев и увеличенно видишь.
Карточка - это когда есть длиннная. И чтобы не мотать бесконечно на телефоне по горизонтали, с его узким по вертикали экраном, ее переделывают в карточку. Помотал предварительно, нажал по строке и перешел в ее карточный вид.
Очевидно, что пока вы не сталкивались с задачей, вам описание решений не будет понятным в принципе.
Вот не надо сравнивать горы изобретений с горами мусора, чудовищная подмена понятий. Идеи человечество может переиспользовать тысячелетиями. Много разных идей помогают придумать другие новые идеи на стыке старых. Ваш подход можно распространить на математиков, что они исписывают бумагу, мел и прочее и создают кучу ненужных черновиков и инфантильный хаос бесчисленного количества теорем, среди которых можно заблудиться. Но это же бред.
В общем, ничего сложного как раз нет, если протрезветь.
У меня тоже похожая история, я примерно год назад прочитал подобную статьюи и загорелся идеей запускать микропроекты раз в месяц. Но меня хватило только одну максимально слабую идею. Я сделал телеграм-бота для ведения задач: https://t.me/simple_taskbot
Потом я целый год не мог запускать новые проекты - не было идей и не было мотивации. Сейчас вот недавно опять взялся за создание проектов, сначала сделал небольшую экономическую игру https://t.me/prokat_game_bot - на нее ушло три недели времени при 2 днях работы.
Микросервисы не такая уж и сложная штука, не надо демонизировать. Их можно практически и со старта делать. Сейчас не 2010-й год, сейчас уже большинство программистов умеют их готовить. И это не стоит практически ничего, если в кубер не затаскивать.
Нагрузка на запись через слейвы не масштабируется. Знаю случаи, когда использовали сервера на 512 Гб оперативы, чтобы хоть как-то тащить дальше монолит.
Считайте это заявление автора гипотезой или предположением. Более того, апоптоз на уровне особей и популяции давно известен. Больные особи, чтобы не заржать популяцию умирают быстрее, чем достигают предела износа организма. Иначе бы по улицам ходили или ползали гниющие и разваливаюшиеся тела.
Зачем? Тут много вариантов ответов. Во-первых, другие так делают. Во-вторых, уровень читателей хабра сильно разный, а вы пытаетесь судить по своим меркам. В-третьих, я хоть и написал 5 ботов на шарпе, но мне пара строчек из исходников была полезна, там где изменился интерфейс либы. В-четвертых, начинающим авторам где-то надо набирать опыт и обратную связь. В-пятых, нашлось достаточно людей проголсовавших за эту статью, чтобы она попала в ленту. В-шестых, кому надо и так смогут разбить длинный метод или написать тесты по надобности. В-седьмых, в правилах хабра нет описанных вами требований к уровню кода. В-восьмых, есть цель повествования и всякие артефакты в виде тестов создают побочную нецелевую нагрузку.
Для MVP в самый раз. После 10 лет структурирования кода теперь учусь наоборот писать просто меньше кода, и меньше принимать инженерных решений. Это позволяет кратно увеличить количество создаваемых MVP и протестированных гипотез и созданных продуктов. А чистый структурированный код мертвых и не взлетевших идей не нужен никому.
Я сознательно сделал одну большую систему на REST и не жалею. У каждого подхода есть свои недостатки к которым можно сделать соответствующие подпорки. Например, в критичных местах прописать механизмы повторных запросов.
Более того, на рынке даже существуют специальные готовые сетевые решения, которые решают проблему обрывов, например Istio для докера.
Асинхронные сообщения я тоже использую, там где скорость достижения согласованности не принципиальна.
Было бы более грамотно всё-таки более непредвзято посмотреть на обе альтернативы и описать плюсы и минусы каждой.
Также, думаю, можно в условиях уменьшенного масштаба изучаемые строки и столбцы делать чуть крупнее, в 2-3 раза.
Спасибо за статью. Мне кажется, могут быть еще решения. Например у нас таблица размеров в 50 колонок и 100 строк. Можно ее отобразить целиком в мелком масштабе и сделать к ней линзу. Водишь пальцев и увеличенно видишь.
В телефоне никак не будет удобно рассматривать таблицу в которой 20-30 колонок, или вдруг даже 50.
Карточка - это когда есть длиннная. И чтобы не мотать бесконечно на телефоне по горизонтали, с его узким по вертикали экраном, ее переделывают в карточку. Помотал предварительно, нажал по строке и перешел в ее карточный вид.
Очевидно, что пока вы не сталкивались с задачей, вам описание решений не будет понятным в принципе.
Вот не надо сравнивать горы изобретений с горами мусора, чудовищная подмена понятий. Идеи человечество может переиспользовать тысячелетиями. Много разных идей помогают придумать другие новые идеи на стыке старых. Ваш подход можно распространить на математиков, что они исписывают бумагу, мел и прочее и создают кучу ненужных черновиков и инфантильный хаос бесчисленного количества теорем, среди которых можно заблудиться. Но это же бред.
В общем, ничего сложного как раз нет, если протрезветь.
На самом деле я этого переведенного автора еще год назад читал на vc.ru
У меня тоже похожая история, я примерно год назад прочитал подобную статьюи и загорелся идеей запускать микропроекты раз в месяц. Но меня хватило только одну максимально слабую идею. Я сделал телеграм-бота для ведения задач: https://t.me/simple_taskbot
Потом я целый год не мог запускать новые проекты - не было идей и не было мотивации. Сейчас вот недавно опять взялся за создание проектов, сначала сделал небольшую экономическую игру https://t.me/prokat_game_bot - на нее ушло три недели времени при 2 днях работы.
Еще две недели у меня ушло для бота для нетворкинга: https://t.me/yabanci2_com_bot
И сейчас у меня впереди еще куча идей - аналитика продаж для Озона, бот для CRM, бот с психологическими тестами, и так далее.
Но вот до каких-то доходов по-видимому еще очень далеко. Но вдруг где-то повезет.
Продакшен база звучит лучше, чем продуктовая, особенно если в ней храняться не продукты питания.
Микросервисы не такая уж и сложная штука, не надо демонизировать. Их можно практически и со старта делать. Сейчас не 2010-й год, сейчас уже большинство программистов умеют их готовить. И это не стоит практически ничего, если в кубер не затаскивать.
Нагрузка на запись через слейвы не масштабируется. Знаю случаи, когда использовали сервера на 512 Гб оперативы, чтобы хоть как-то тащить дальше монолит.
Считайте это заявление автора гипотезой или предположением. Более того, апоптоз на уровне особей и популяции давно известен. Больные особи, чтобы не заржать популяцию умирают быстрее, чем достигают предела износа организма. Иначе бы по улицам ходили или ползали гниющие и разваливаюшиеся тела.
Зачем? Тут много вариантов ответов. Во-первых, другие так делают. Во-вторых, уровень читателей хабра сильно разный, а вы пытаетесь судить по своим меркам. В-третьих, я хоть и написал 5 ботов на шарпе, но мне пара строчек из исходников была полезна, там где изменился интерфейс либы. В-четвертых, начинающим авторам где-то надо набирать опыт и обратную связь. В-пятых, нашлось достаточно людей проголсовавших за эту статью, чтобы она попала в ленту. В-шестых, кому надо и так смогут разбить длинный метод или написать тесты по надобности. В-седьмых, в правилах хабра нет описанных вами требований к уровню кода. В-восьмых, есть цель повествования и всякие артефакты в виде тестов создают побочную нецелевую нагрузку.
Для MVP в самый раз. После 10 лет структурирования кода теперь учусь наоборот писать просто меньше кода, и меньше принимать инженерных решений. Это позволяет кратно увеличить количество создаваемых MVP и протестированных гипотез и созданных продуктов. А чистый структурированный код мертвых и не взлетевших идей не нужен никому.
Для задач обучения нейросетей наверное подходит, да и вообще, CUDA кроме игр в математике и других расчетах теперь много где используется.
Для майнинга битка видяхи не подходят, там только асики. В эфириуме майнинг отменили, и теперь он остался только в мелких проектах.
Собирать точно можно, я давно собираю дотнет-приложения под линуксом.
Для линукса есть Visual Studio Code
Я сознательно сделал одну большую систему на REST и не жалею. У каждого подхода есть свои недостатки к которым можно сделать соответствующие подпорки. Например, в критичных местах прописать механизмы повторных запросов.
Более того, на рынке даже существуют специальные готовые сетевые решения, которые решают проблему обрывов, например Istio для докера.
Асинхронные сообщения я тоже использую, там где скорость достижения согласованности не принципиальна.
Было бы более грамотно всё-таки более непредвзято посмотреть на обе альтернативы и описать плюсы и минусы каждой.
Я пока не опытен в этом плане, я даже не знал, что будут запои. По мере поступления проблем буду пробовать их решать.
О, как раз думаю сделать клуб для совместного самообучения.
Наверное это может выглядеть аналогичено тому как реализуется Lazy Load. Как вариант, в интерфейсе это может выглядеть так:
public RegisteredUser Register(IWouldAbsorbedHere<UnregisteredUser> user)