Удивляюсь, почему среди саксов так много дрочеров на VSCode

org-mode не нужен, есть markdown

Таблицы? Таймеры? Теги? Статусы выполнения? Приоритеты? Агенда? Исполняемые блоки кода?

Не, не слышали %)

Таблицы есть

Таймеры? Теги? Статусы выполнения? Приоритеты? Агенда? Исполняемые блоки кода?

А нафига оно нужно?

так как нарушают KISS

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

Маркдаун орг-мод не заменяет никак, да еще и состоит из кучи умеренно совместимых диалектов, а все вимные модули под vscode я тыкал. Ужасно. И лучше вряд-ли будет, ибо просто плагинчики-с.

Думеры - поколеие игры DOOM. Бумеры - поколение жвачки BOOMER, Зумеры - поколение мессенджера ZOOM

А Шумеры?

Таблицы есть

Врукопашную, ага. И у каждого егора своя разновидность.

ненужно!

Впрочем, ничего нового %)

Ты ЛОР перепутал с передачей «сам себе режиссер»? Что это за детские приколы со «слабо»?

А что за ахинею ты несешь с «архитектурой» и SOA? Как это поможет уменьшить объем исходников?

А нафига оно нужно?

Обычно это работает так: сначала вы задумываетесь «зачем это нужно?», потом читаете руководство пользователя, потом начинаете применять то, что поняли, а потом не можете без этого обойтись.

Прозвучит кощунственно, но я буквально вчера снес онтопик в пользу WSL2 и VSCode с его Remote Development.

Скатертью дорога.

Зачем ты открываешь исходники всех проектов одновременно? Или у вас все-таки огромный монолит на вебсфере? ;)

Ну вот. Линуксокапец начался, а никто не паникует. Зачем тогда линь, если за четыре года MS убила Linux на десктопах девелоперов? Останутся только старички и арчешкольники. Всё это за собой потащит обходимость разработки дров и профессионального софта, ибо зачем.

Дык Android разработчики тоже на десктоп не ставят, если ты понимаешь, о чем я.

Зачем ты открываешь исходники всех проектов одновременно?

Что значит «всех проектов одновременно»? Проект состоит из кучи разных компонент и зависимых библиотек, очевидно, я хочу это всё видеть сразу и одновременно в IDE со всеми исходниками.

Или у вас все-таки огромный монолит на вебсфере? ;)

Я далек от java-мира.

дают вечную лицуху при покупке на год

Проект состоит из кучи разных компонент и зависимых библиотек, очевидно, я хочу это всё видеть сразу и одновременно в IDE со всеми исходниками.

Ну т.е. монолит. Потому что в нормальной SOA тебе не уперлись соседние компоненты - для этого есть контракты.

Я далек от java-мира.

Какой-то странный у тебя «enterpriZe». Хотя я глянул твои треды - ты энтерпрайзом яндекс называешь, оказывается.

Потому что в нормальной SOA тебе не уперлись соседние компоненты - для этого есть контракты.

С чего это не уперлись? Я могу вносить изменения в какие угодно компоненты, в том числе и в соседние. Как мне поможет «SOA» и «контракты»? Внезапно, есть толстые компоненты, которые есть в зависимостях у всего, тривиальный пример – libc и stdc++.

Хотя я глянул твои треды - ты энтерпрайзом яндекс называешь, оказывается.

А что такое «энтерпрайз»? Рисование веб-формочек к БД на java? Да, я далек от такого «энтерпрайза».

А если религия запрещает за софт платить?

По вопросам религии - в церковь, а люди зарабатывают деньги. Ну в смысле люди, а не лор-овцы.

За употребление этого слова не в отношении машин марки «BMW» скидывать в кислотную калабаню!

А как же настоящие престарелые бейби-бумеры?

Не-а, деньги выше идеи только у скотины, но не у человека.

Хотя, конечно, она тоже посредственная в сравнении с каким-нибудь вимом или сублимом

Ну-ну, в виме подсветка синтаксиса регулярками, на крупных файлах задыхается ;) Особенно для языков из списка:

root@localhost:~# ls -lS /usr/share/vim/vim82/syntax/|head -n 20
итого 6836
-rw-r--r-- 1 root root 246745 мая 12 05:37 xs.vim
-rw-r--r-- 1 root root 132809 мая 12 05:37 typescriptcommon.vim
-rw-r--r-- 1 root root  92737 мая 12 05:37 pfmain.vim
-rw-r--r-- 1 root root  87942 мая 12 05:37 redif.vim
-rw-r--r-- 1 root root  81396 мая 12 05:37 neomuttrc.vim
-rw-r--r-- 1 root root  80913 мая 12 05:37 php.vim
-rw-r--r-- 1 root root  75419 мая 12 05:37 2html.vim
-rw-r--r-- 1 root root  74130 мая 12 05:37 perl6.vim
-rw-r--r-- 1 root root  73595 мая 12 05:37 baan.vim
-rw-r--r-- 1 root root  73423 мая 12 05:37 vim.vim
-rw-r--r-- 1 root root  65812 мая 12 05:37 muttrc.vim
-rw-r--r-- 1 root root  64490 мая 12 05:37 tex.vim
-rw-r--r-- 1 root root  48014 мая 12 05:37 autoit.vim
-rw-r--r-- 1 root root  46511 мая 12 05:37 xmodmap.vim
-rw-r--r-- 1 root root  46133 мая 12 05:37 postscr.vim
-rw-r--r-- 1 root root  44530 мая 12 05:37 mp.vim
-rw-r--r-- 1 root root  44450 мая 12 05:37 hollywood.vim
-rw-r--r-- 1 root root  43377 мая 12 05:37 sh.vim
-rw-r--r-- 1 root root  42148 мая 12 05:37 cmake.vim

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

Революционер — это один заводятел, а поддерживают идею миллионы нищих мух. И сила именно в мухах, ибо один революционер революцию не потянет, максимум яйца к мостовой может прибить. А вот финансировать всех мух совершенно не обязательно, даже наоборот — они сами бабло потащат, если проникнутся.

то вашего архитектора давно пора погнать ссаными тряпками

То-то в гугле и оракле про это не знают. SOA в GUI и СУБД просто не работает.

Но без обновлений.

И что есть не платящие подписку?

У меня у детишек 2 образовательные лицензии я не жужжу.

Но все кто без этой хрени не может программировать - платят.

А я думал благодаря спринг - буту?!

Намедни кадрам дали задачу побыстрому сделать дашбоард для отслеживания процессов движения денег.

Начли рисовать микросервисы на СПБ, с сприг-интегрэйшн, Кафка, МонгоДБ и UI на Splunk

Я слегка обуел и говорю может сделать одно приложение на коленке ибо просят быстро.

Не-не-не что ты понимаешь и ты вообще контрактор а нам нужно Fault tolerance, horizontal & vertical scaling да и микросервисы это же рекомендация на все случаи жизни!!!

Может хоть Кафку выкиньте?

Не-не-не! что ты понимаешь и ты вообще контрактор а нам нужно Fault tolerance, horizontal & vertical scaling!

В результате эта поделка не могла работать паралельно на 2х инстансах, так как полудурки никак не отслеживали что что файлы прочитаны а копии которые не разруливались и были бы дубликатами на экране отрисованном в Спланк.

Так как ci/cd пулил в продакшн на 2 инстанса в разных датацентрах, то они звали девопсов, чтобы те прибили один инстанс.

И так-же на всех этапах продвижения сообщения по цепочке. Мне даже не удалось их уговорить не прибивать второй инстанс consumer кафки.

Ожидаемо через 3 месяца трэйдеры послали их на юг, так как они ожидали что все будет сделано за пол года максимум, а они за 3 месяца дай бог 10% сделали.

Идею никто не винил, поверьте.

Жаба имеет тенденцию собирать прораммистов не понимающих как это все работает и зачем предназначено.

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

А оно вот оно как…

Ожидаемо через 3 месяца трэйдеры послали их на юг, так как они ожидали что все будет сделано за пол года максимум, а они за 3 месяца дай бог 10% сделали

Просто еще одно подтверждение очевидного факта: микросервисы делают простую задачу сложной, а сложную — неподъемной. Хочешь сделать быстрый и рабочий вариант — не выеживайся и делай монолит, потому что каждый дополнительный сервис удвоит время разработки до стабильного состояния.

Жаба имеет тенденцию собирать прораммистов не понимающих как это все работает и зачем предназначено

Примерно 95-98% людей живут по принципу подражания и на полном серьезе путают механическое повторение с пониманием принципов. Поскольку их тупо много, то это как слепцы. которые друг другу рассказывают, что такое солнце: «солнце — это когда тепло», «нет, стоял под солнцем у дерева, и мне не было тепло. Солнце — это когда поют птицы».

Другое дело, что подражатель не будет писать в 2020 на каком-нибудь лиспе, потому лисп не собирает подражателей. Но создавать проект на лиспе — это тоже сомнительная затея. В итоге для средней прогерской конторы успех зависит ровно от того, найдет ли руководство людей, которые смогут принимать решения на основе собственного опыта и доносить это решение до подражателей.

Закончить хотелось бы цитатой Дейкстры:

The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.

Dijkstra (2000) «Answers to questions from students of Software Engineering» (EWD 1305).

Это неизбежное следствие: если у вас есть людей, которые всю жизнь кому-то подражают, то неизбежно придут люди, которые будут продавать образец для подражания.

А Шумеры?

Ну это очень сильно давно было, еще до фон Неймана. Шумели, наверное, много.

Хелловорлдов юноши наклепали много, а вот magit

Справедливости ради, встроенная поддержка гита там вполне юзабельная, особенно если Git graph добавить.

в виме подсветка синтаксиса регулярками, на крупных файлах задыхается

Так тормозит подсветка, а не вим. Её можно отключить, и все будет летать. А вот поможет ли такой фокус жирноide или сабжу?

Просто еще одно подтверждение очевидного факта: микросервисы делают простую задачу сложной, а сложную — неподъемной.

Вы, пожалуйста, не делайте неверные выводы из простых предложений.

Микросервисы очень нужная вещь.

Хочешь сделать быстрый и рабочий вариант — не выеживайся и делай монолит

Очевидно вы не писали больших приложений.

Микросервисы очень нужная вещь

А я не спорю. Каким образом это противоречит тезису «микросервисы делают простую задачу сложной, а сложную — неподъемной»?

Очевидно вы не писали больших приложений

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

«микросервисы делают простую задачу сложной, а сложную — неподъемной»?

Тем что микросервисы делают обратное.

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

Упрощение достигается некоторым объёмом дополнительной работы и появлением дополнительных абстракций и некоторым усложнением архитектуры.

Т.е. для очень маленького приложения это не имеет смысла так как дополнительный объём работ и необходимость понимать что делаете может сделать из маленького приложения (при непонимании того что делаете) монстра, которого я и описал.

Очевидно, писал.

Мне как раз очевидно обратное. Иначе бы вы не выступали за монолит.

Я с ними повозился достаточно.

Упрощают приложение и делают возможным нескольким группам работать над одним проектом одновременно

Ну, и что, в твоем случае упростили?

Упрощение достигается некоторым объёмом дополнительной работы и появлением дополнительных абстракций и некоторым усложнением архитектуры

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

дополнительный объём работ и необходимость понимать что делаете может сделать из маленького приложения (при непонимании того что делаете) монстра, которого я и описал

Эм-м-м... то есть, к микросервисам можно допускать только самых продвинутых прогеров? Разве это не автоматическая констатация излишней сложности?

IDEA определённо поможет, над латенси ввода текста там хорошо поработали. Тормозит она от другого. Беда в том, что если открутить от IDE плюшки IDE, то это уже будет не IDE.

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

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

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

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

А, да, они в составе 7 человек писали в течении двух лет, а у нас было 4 человека, потратили шесть месяцев.

При чем тут микросервисы, когда у тимлида/сеньоров в голове ветер и они наслушавшись мудрёных слов пытаются фигак-фигак и в продакшен. Монолит разве что костыли лепить поможет. Тут простое неосиляторство задачи.

Ну, и что, в твоем случае упростили?

Структуру обработки событий.

Сейчас на рынке труда довольно популярно брать фулстэк разрабов

Если вы на что-то намекаете, то я не понял смысла.

Эм-м-м… то есть, к микросервисам можно допускать только самых продвинутых прогеров?

Наоборот.

Сейчас на рынке труда довольно популярно брать фулстэк разрабов

Если вы на что-то намекаете, то я не понял смысла

Я намекал на то, что написаной одной функции одним разрабом удобнее, чем писание этой же функции целой толпой людей. Я неоднократно наблюдал ситуацию «сидел целый отдел любился с заданием; отдел уволили/передали задачу другому человеку — внезапно все проблемы испарились и все требования стали выполнены». Ведьмак не даст соврать. Опционально потом приходят снова «профессиональные разработчики» и загоняют проект в попу.

Эм-м-м… то есть, к микросервисам можно допускать только самых продвинутых прогеров?

Наоборот

И каким же образом «наоборот»? Да, цельный проект своим кривым кодом они не испортят, но если сделают плохо и нерабоче, то какая разница, как ваша система будет неработать? Тем более, что при наличии соответствующего таланта микросервис все равно может за-DOS-ить остальную систему гигабайтными запросами или бесконечным флудом. Ставишь ограничение на размер и частоту запросов — и ололо, система разваливается при нормальной работе. У меня в проекте индусы примерно такое получили.

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

Я намекал на то, что написаной одной функции одним разрабом удобнее, чем писание этой же функции целой толпой людей.

АХА!

Т.е. вы поняли почему монолиты трудно разрабатывать и почему они годятся только для мелких проектов которые разрабатывает один человек!

И каким же образом «наоборот»?

Таким образом что неопытному разработчику трудно разобраться в монолите с милонами строк кода.

А пару сотен строк микросервиса он осилит.

Малейшее неверное движение и монолит упал.

Фичи в микросервисы можно добавлять часто.

Выкат монолита в продакшн это событие на пару дней. И потом неделю баги ловить, откатываться.

Таким образом что неопытному разработчику трудно разобраться в монолите с милонами строк кода

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

Например, systemd — это МОДУЛЬНЫЙ МОНОЛИТ. Его модули нельзя использовать отдельно друг от друга, и, тем не менее, они разрабатываются отдельно и выполняемые ими функции более-менее закончены, хоть и бесполезны за пределами монолита.

Малейшее неверное движение и монолит упал
Фичи в микросервисы можно добавлять часто

Ты хочешь мне сказать, что кривыми руками нельзя уронить систему на микросервисах? Или хотя бы натворить дел, с которыми потом неделю будет любиться вся команда?

А пару сотен строк микросервиса он осилит

Я не знаю, на какое днище нынче катится кодинг, но в моем понимании такое пишется за обеденный перерыв. Если у тебя будет несколько сотен таких микросервисов, то есть, система МАЛОГО-СРЕДНЕГО уровня СЛОЖНОСТИ, то ты с ума сойдешь при ее поддержке. А ведь это еще детский сад, это пишется в одно рыло за пару лет.

бесплатно

почти IDE

еще и в линуксе

Sublime до сих пор живчик, на самом деле, рвет все эти атомы с vscode-ами.

А популярен vscode потому, что его стали позиционировать как конструктор для неискушенных, что очень популярно всегда (см. Miranda (im агрегатор с плагинами, если кто помнит), firefox (в лучшие его годы, опять с плагинами), да тот же emacs (революция кастомизации своего времени для неискушенных своего времени). Еще eclipse надо вспомнить - на его основе туча IDE (и не только для кода) наверчено, и позиционировался так же как конструктор; и тормоз.

Короче, если хотите «универсальный всемогутер» - будет он черепахой, закономерно.

Я наконец нашёл ваши точки непонимания

1. Вы думаете что разобраться в проекте на миллион строк так же просто как в микросервисе на пару сотен строк
2. Вы думаете что ошибки в паре сотен строк делаются так же часто как и в миллионе.
3. Вы не работали над большими проектами
4. Вы не работали в больших группах

Чтобы понять где вы не правы, прочитайте тред снова.

Повторять аргументы скучно

Пардон, как-то пропустил ответ.

Вы думаете что разобраться в проекте на миллион строк так же просто как в микросервисе на пару сотен строк

Разобраться в системе из 500 микросервисов на пару сотен строк сложнее, чем разобраться в проекте на миллион строк. 200x500 = 100'000.

Вы думаете что ошибки в паре сотен строк делаются так же часто как и в миллионе

Очень хороший вопрос, в чем будет больше ошибок: в пятистах проектах по паре сотен строк, или в модульном монолите на миллион строк. Я бы не взялся заранее давать ответ.

Вы не работали над большими проектами
Вы не работали в больших группах

Какой тебе нужен проект еще больше? Гугл/инстаграм/яндекс, сотни разрабов на одном проекте?

Разобраться в системе из 500 микросервисов на пару сотен строк сложнее, чем разобраться в проекте на миллион строк. 200x500 = 100’000.

Вот еще одна точка вашего непонимания.

На досуге, подумайте почему это очень серьезная глупость.

Намек: в системе не нужно смотреть код всех сервисов, достаточно знать контракт.

в чем будет больше ошибок

Предположим одинаково.

Например 10

Для поиска в монолите вам нужно перелопатить каждый раз миллион строк.

В микросервисе по 200

Каждое падение монолита валит всю систему и только один микросервис

Откат версии, реестарт, тестирование и десятки других аргументов в пользу микросервисов

Какой тебе нужен проект еще больше? Гугл/инстаграм/яндекс, сотни разрабов на одном проекте?

Да любой. Покажите монолит у этих компаний над которым вы работали в больших группах, пожалуйста.

Намек: в системе не нужно смотреть код всех сервисов, достаточно знать контракт

Ты применяешь какие-то двойные стандарты. Почему-то у микросервисов могут быть контракты, а у монолита — нет.

А теперь прикинь, насколько весело пытаться найти любую неочевидную проблему в системе из сотен сервисов — тебе придется пересмотреть огромную кучу контрактов, и найти, какой контракт не исполняется или изначально плохо спроектирован.

И я напоминаю, что 100'000 строк — это по прежнему еще детский сад.

Для поиска в монолите вам нужно перелопатить каждый раз миллион строк.
В микросервисе по 200

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

Откат версии, реестарт, тестирование и десятки других аргументов в пользу микросервисов

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

Тестирование — это весьма ограниченный инструмент проверки работоспособности. Как грил мою любимый Дейкстра «тестирование дает возможность убедиться в наличии ошибок, но не в их отсутствии». На практике тестирование лучше работает для систем с низкой вариативностью, с жестко заданными входными и выходными параметрами. Если посмотреть на предыдущий абзац, то вырисовывается довольно четкая картина жесткой четко расписанной системы, одной из ключевых особенностей которой является невозможность перестройки онной под значительно отличающиеся требования — используя такую модель сильно проще сделать новую систему рядышком, чем пытаться переписывать старую, теряя возможность отката версий и тестирования.

Это если на секундочку забыть, что есть задачи, в которых в принципе нельзя устранить требования гибкости функций и входных-выходных параметров. И у меня есть впечатление, что нынче e;t не реализацию подстраивают под требования, а требования пытаются подстроить под реализацию.

Каждое падение монолита валит всю систему и только один микросервис

Ну вот скажи мне, что сделает с системой падение монги? Это первый вопрос. Второй вопрос: с чего ты взял, что падение монолита приводит к падению системы, а не к снижению ее производительности?

Какой тебе нужен проект еще больше? Гугл/инстаграм/яндекс, сотни разрабов на одном проекте?

Да любой. Покажите монолит у этих компаний над которым вы работали в больших группах, пожалуйста

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

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

Пока не поймете будете продолжать нести глупости.