я думаю, что если спросить мое начальство, что бы оно предпочло - сделать, чтоб работало, но некрасиво, или сделать красиво, но чтоб работало хреново, то однозначно вариант №1
ну так в каждом языке можно накопать примеров, когда язык перестает быть языком. На C, если пишем какую-нибудь научную числодробилку, придется в стиле фортрана писать с громадными отдельными массивами double-ов, в Python иногда приходится на C часть кода переписывать, да полно всякого. Конкретно в java конкретно ваш пример ложится плохо, неидиоматично, но это не значит, что его нельзя сделать.
эту задачу можно решить, не генерируя миллионы стрингов. Можно файл зачитать в память в виде массива char-ов (можно еще mmap заюзать), а строки представлять просто интами - смещениями начала и конца, написать собственные equals/hashCode/lexicographicalCompare. Такие строки, с несколькими интами, вполне можно аллоцировать/деаллоцировать, используя все тот же объектный пул. Записи, состоящие из строк, тоже можно через пул аллоцировать.
ну кстати с синхронизацией доступа без блокировок в Java действительно проще, всякие lock-free за счет гарантий ссылочной целостности и имея java.util.concurrent.atomic сильно проще писать. Я в 2012м, помнится, на C++ делал свою либу lock-free примитивов, с этим были проблемы, даже простой RCU (read-copy-update) без собственных пулов, меченых указателей и прочих танцев с бубном не получался.
С другой стороны, если приходится в Java использовать память вне кучи - тогда нет большого смысла писать на Java. Ну и вроде как можно использовать те же объектные пулы, тогда не нужно будет часто насиловать кучу и gc будет поспокойнее. Разве что тут начинается ручное управление памятью)
да необязательно даже конкурент захватит рынок. Тупо функционал может оказаться никому не нужным, и это лучше выяснить поскорее. Плюс бизнес-требования все равно уточнятся и дополнятся, так что лучше их прощупывать на поделке из говна и палок, которую выбросить не сильно жалко
вы просто писали про Европу, я думаю, там куча стран, которые используют не только латиницу, но и национальные языки, с соответствующими кодовыми таблицами
ну так это обычная метаинформация, такая же, как кодировка.
Я кстати извиняюсь, кодировка - это теперь моя больная тема. 3 года назад писал софт для государства, и вот мне в качестве тестовых данных для разработки прислали файлы в cp1251, причем никакой (!) метаинформации о кодировке не было, все чисто на соглашении. Ну и короче я ее вынес в конфиг. На тестовом стенде внезапно (!) оказалось, что половина файлов в 1251, другая половина в utf-8, причем из них половина с byte order mark, а другая без, ну и выяснилось это путем копания в hex-редакторе, конечно же, так как никто ничего не знал. Я, матерясь, налепил костыль с определением кодировки (не 100%, конечно же, но хоть так), и с горем пополам прошли тестирование. На проде оказалась utf-16-le (little, мать ее, endian!), причем выяснилось это тоже путем копания в hex-редакторе и тупо сопоставлением размера файла.
ну так поделку в виде csv файлов (кстати, с каких пор csv-файлы это что-то плохое?) тоже нужно как-то где-то деплойнуть, ничего при этом не сломав, и хотя бы простейшие тесты должны быть о том, что этот файл вообще читается, нормально парсится с учетом экранирования/обкавычивания, подпись проверяется, что там нет крякозябр из-за не той кодировки, что прочитанные данные нормально ложатся в базу и/или уходят в отраслевую ГИС в том формате, в котором она работает (и что там крякозябр тоже нет), правда ведь?
Я думаю, вы и сами не хотели бы получить мобилизационное по той причине, что в минобороны от минцифры данные ушли в cp1251, которая думает, что она utf-8, например.
Многовато мазохизма. Какая-то попытка достичь "идеальной неидеальности".
Потому что идеальный он только в вашей голове и только по вашему мнению
а еще только до внесения первых изменений. Но с другой стороны есть понятие "достаточно хороший код", которое включает в себя тесты, удобство развертывания и конфигурации. Так что ничего нет плохого в микросервисном распределенном чуде, если оно удобно. Про многопоточный монолит - кхм, серверные приложения в большинстве случаев многопоточны, и это нормально.
ага, с ним вообще не просто. С камнями проблема решается использованием истертого в порошок угля, но главная проблема, имхо - нагар, и как с ним бороться - хз.
это на единицу рабочего объема? там вроде как если давление поднять, можно более менее приемлемых результатов добиться. Ну и стирлингу не нужен котел, в этом его основной профит перед паровой машиной.
Конденсатор пара с радиатором поднял бы КПД в пару раз, заодно и дальность хода на одной заправке водой была бы побольше. Так Добль делал в 20х-30х годах. Ну и тру паровоз должен работать на угле! Только фиг его знает, как его автоматическую регулируемую подачу организовать, может быть шнек или типа того.
Ну кстати синдром самозванца таки немного есть, потому что достижения тоже есть. Также не вижу, чтобы TC занимался не своим делом, иначе у него бы просто не получалось пилить сайты с мобилы в юности и в этой же юности хорошо этим делом зарабатывать. Завышенная самооценка - это есть, но в этом также множество плюсов, завышенная самооценка позволяет метить выше и в итоге добиваться большего, даже несмотря на то, что имеет тенденцию чуть что падать с небес на землю, причиняя эмоциональную боль и страдания. Искреннее увлечение и лень - сочетаются действительно плохо, но в одной и той же голове как нефиг могут уживаться (вообще, в одной и той же голове может такая дичь уживаться, что ахнуть), причиняя страдания внутренним конфликтом.
А если откинуть занудство, то в посте есть все - и самовозвеличивание, и самоуничижение, как попытка навести во всем этом бардаке хоть какой-то порядок)
я думаю, что если спросить мое начальство, что бы оно предпочло - сделать, чтоб работало, но некрасиво, или сделать красиво, но чтоб работало хреново, то однозначно вариант №1
ну так в каждом языке можно накопать примеров, когда язык перестает быть языком. На C, если пишем какую-нибудь научную числодробилку, придется в стиле фортрана писать с громадными отдельными массивами double-ов, в Python иногда приходится на C часть кода переписывать, да полно всякого. Конкретно в java конкретно ваш пример ложится плохо, неидиоматично, но это не значит, что его нельзя сделать.
эту задачу можно решить, не генерируя миллионы стрингов. Можно файл зачитать в память в виде массива char-ов (можно еще mmap заюзать), а строки представлять просто интами - смещениями начала и конца, написать собственные equals/hashCode/lexicographicalCompare. Такие строки, с несколькими интами, вполне можно аллоцировать/деаллоцировать, используя все тот же объектный пул. Записи, состоящие из строк, тоже можно через пул аллоцировать.
на ассемблер переходить не нужно, все же другая парадигма программирования
ну кстати с синхронизацией доступа без блокировок в Java действительно проще, всякие lock-free за счет гарантий ссылочной целостности и имея java.util.concurrent.atomic сильно проще писать. Я в 2012м, помнится, на C++ делал свою либу lock-free примитивов, с этим были проблемы, даже простой RCU (read-copy-update) без собственных пулов, меченых указателей и прочих танцев с бубном не получался.
С другой стороны, если приходится в Java использовать память вне кучи - тогда нет большого смысла писать на Java. Ну и вроде как можно использовать те же объектные пулы, тогда не нужно будет часто насиловать кучу и gc будет поспокойнее. Разве что тут начинается ручное управление памятью)
да необязательно даже конкурент захватит рынок. Тупо функционал может оказаться никому не нужным, и это лучше выяснить поскорее. Плюс бизнес-требования все равно уточнятся и дополнятся, так что лучше их прощупывать на поделке из говна и палок, которую выбросить не сильно жалко
вы просто писали про Европу, я думаю, там куча стран, которые используют не только латиницу, но и национальные языки, с соответствующими кодовыми таблицами
потому что латиница везде, кроме utf-16, кодируется одними и теми же байтами
utf-8, utf-16, utf-16-le вполне себе интернациональны, так же, как и расширенный ascii
в живой разработке частенько бывает не "или", а "и": из говна и палок, и далеко не "еще вчера"
ну так это обычная метаинформация, такая же, как кодировка.
Я кстати извиняюсь, кодировка - это теперь моя больная тема. 3 года назад писал софт для государства, и вот мне в качестве тестовых данных для разработки прислали файлы в cp1251, причем никакой (!) метаинформации о кодировке не было, все чисто на соглашении. Ну и короче я ее вынес в конфиг. На тестовом стенде внезапно (!) оказалось, что половина файлов в 1251, другая половина в utf-8, причем из них половина с byte order mark, а другая без, ну и выяснилось это путем копания в hex-редакторе, конечно же, так как никто ничего не знал. Я, матерясь, налепил костыль с определением кодировки (не 100%, конечно же, но хоть так), и с горем пополам прошли тестирование. На проде оказалась utf-16-le (little, мать ее, endian!), причем выяснилось это тоже путем копания в hex-редакторе и тупо сопоставлением размера файла.
ну так поделку в виде csv файлов (кстати, с каких пор csv-файлы это что-то плохое?) тоже нужно как-то где-то деплойнуть, ничего при этом не сломав, и хотя бы простейшие тесты должны быть о том, что этот файл вообще читается, нормально парсится с учетом экранирования/обкавычивания, подпись проверяется, что там нет крякозябр из-за не той кодировки, что прочитанные данные нормально ложатся в базу и/или уходят в отраслевую ГИС в том формате, в котором она работает (и что там крякозябр тоже нет), правда ведь?
Я думаю, вы и сами не хотели бы получить мобилизационное по той причине, что в минобороны от минцифры данные ушли в cp1251, которая думает, что она utf-8, например.
Многовато мазохизма. Какая-то попытка достичь "идеальной неидеальности".
а еще только до внесения первых изменений. Но с другой стороны есть понятие "достаточно хороший код", которое включает в себя тесты, удобство развертывания и конфигурации. Так что ничего нет плохого в микросервисном распределенном чуде, если оно удобно. Про многопоточный монолит - кхм, серверные приложения в большинстве случаев многопоточны, и это нормально.
нет здесь нарциссизма. Ретроспектива обычная.
ага, с ним вообще не просто. С камнями проблема решается использованием истертого в порошок угля, но главная проблема, имхо - нагар, и как с ним бороться - хз.
это на единицу рабочего объема? там вроде как если давление поднять, можно более менее приемлемых результатов добиться. Ну и стирлингу не нужен котел, в этом его основной профит перед паровой машиной.
температура воспламенения 800-850 градусов. Там паяльная лампа нужна будет в качестве стартера)
З - зависть.
Конденсатор пара с радиатором поднял бы КПД в пару раз, заодно и дальность хода на одной заправке водой была бы побольше. Так Добль делал в 20х-30х годах. Ну и тру паровоз должен работать на угле! Только фиг его знает, как его автоматическую регулируемую подачу организовать, может быть шнек или типа того.
Но я бы скорее в сторону стирлинга смотрел.
Ну кстати синдром самозванца таки немного есть, потому что достижения тоже есть. Также не вижу, чтобы TC занимался не своим делом, иначе у него бы просто не получалось пилить сайты с мобилы в юности и в этой же юности хорошо этим делом зарабатывать. Завышенная самооценка - это есть, но в этом также множество плюсов, завышенная самооценка позволяет метить выше и в итоге добиваться большего, даже несмотря на то, что имеет тенденцию чуть что падать с небес на землю, причиняя эмоциональную боль и страдания. Искреннее увлечение и лень - сочетаются действительно плохо, но в одной и той же голове как нефиг могут уживаться (вообще, в одной и той же голове может такая дичь уживаться, что ахнуть), причиняя страдания внутренним конфликтом.
А если откинуть занудство, то в посте есть все - и самовозвеличивание, и самоуничижение, как попытка навести во всем этом бардаке хоть какой-то порядок)
epoll/kqueue/iocp не исключает использование тред пула