Разработчик с 25-летним стажем: log4j на сервере это по сути дыра с виде инъекции произвольного кода через LDAP, доставить которую можно тупо через http, например переписав тот же user-agent (чаще всего в пруфах по этой уязвимости фигурирует).
Hо вместо лечения самой дыры "разработчик с 20-летним стажем" запрещает этому вредоносному коду админскими костылями что-то там "важное за звездочками" читать? И ещё и говорит "Problem solved"?
Супер просто. Получите и распишитесь майнер|сниффер|впишите-любую-нагрузку. Не туда смотрите в общем. Это совсем не админская проблема, а именно девелоперская. И не в CI и секретах тут дело, они лишь для примера эксплуатации приведены.
Да, спасибо. И так тоже должно скомпилироваться (хоть это и банально): Comparator<String> comparing = Comparator.comparing(String::toLowerCase); comparing = comparing.reversed();
Я думаю, что именно без присваивания компилироваться не будет. C .reversed() тоже не будет.
Без .reversed(), но с контекстом - будет. С .reversed(), но в следующем операторе тоже будет (т.к. тип уже выведен).
На первый взгляд это конечно контринтуитивно, но Тагир как обычно все здорово же объяснил. Не могу отделаться от ощущения, что вы прикалываетесь. Буду, конечно, рад ошибиться.
То что вы хотите можно получить либо так Comparator.comparing(s->s.toString().toLowerCase()) //из Object либо так Comparator<String> comparator=Comparator.comparing(String::toLowerCase); //из String
В лоб (без контекста, т.е. в смысле без самого объекта) из Comparator.comparing(String::toLowerCase) компилятору ничего вывести нельзя, т.к. самих этих toLowerCase - много, и непонятно на какой именно вы ссылаетесь. А если ::length или ::hashcode или ::toString - то тут такой неоднозначности не возникает, у этих методов нет перегрузки и компилятор понимает объект какого типа имелся ввиду, и какой из методов этого объекта нужен для извлечения признака (keyExtractor).
Но вообще представить себе где может понадобиться такой код Comparator.comparing(что-угодно) без присваивания или передачи куда-либо довольно трудно. Даже наверное невозможно.
А сам ассемблер - ненужная абстракция над бинарными кодами? Получается, что лучший язык программирования - азбука Морзе. 0110100101011100101001001001010010110100101000100101 ой, т.е. .-...-..-.-.--..-.-.--.---.-.-.---..--.-.--....--...... ))))
Ну и в целом по топику, jvm/jdk их же много, на плюсах - старинная sun, а уже что-то посовременнее, типа граальвм - она вроде вся на джаве.
Да, проблема важная затронута и в ML по сути ключевая.
Но вот какое дело... Подавляющее число данных обо всех событиях человека, компании, бизнеса, сайта практически свободно доступны гигантам вроде гугла. С телефонов и аналитики сервисов такого гиганта есть просто море информации. И гео, и коммуникация, и активности, и расходы с доходами, где был, что искал, что выбрал, что лайкал... В общем ВСЁ! Эти данные структурированы, размечены, объемны. Могут быть валидированы. Любой срез в любой сфере возможен. Для экспериментов просто невероятное поле. Корпус для обучения под нужную сферу собрать - легче простого. А "простым смертным" позволено лишь архив своего собственного поведения получить. Качал как-то, то что есть у гугла на меня - даже без документов, файлов, фото и видео за гигабайт выскочило.
А по прекрасному совпадению эти же гиганты еще и лидеры ML. Итого: их мощности (датасеты) недоступны рядовым исследователям. Ну а сами рядовые исследователи свои модели все чаще в тех же облаках тех же гигантов гоняют. Свои датасеты туда льют. Удачные модели УЖЕ в облаках вероятно видны. Им. Гигантам.
Дальше несложно сложить 2+2. Это будет даже не монополия. Это что-то божественное скорее. В общем, полагаю, нас ждут удивительные времена.
Давайте я вам свое расскажу за монолиты. За то как я на них погорел. Люблю их до боли. А все почему?
Писал всегда только монолиты. Что пишу - то и люблю. Иначе вот не получается как-то.
Всегда практически все полностью сам от начала до конца, от кода до развертывания. Типа самоделкин. Ну или фуллстек, как нынче принято. Приятно. В этом есть смак. Костыли, не костыли - нет проблем. Пока помню свою же архитектуру - вопросов ноль. Паттерны - по желанию. Есть страшные magic-куски и phd-code, да не беда, замечательно же. Приятно даже иногда.
Жаба мое все уже лет 8-10. Но вот недолюбливаю спринги с хибером и вообще любые фреймворки. Почти всегда можно самому сделать все, что они предлагают, и обычно это легко и просто. Обычно легче. Обычно производительнее. Обычно понятнее. Обычно удобнее. Свои DI и IOС, свой пул препередстейтметов без вымывания кеша, причем не ручками а рефлесией наделанный - ну вот что может быть проще.
Ненавижу всякие улучшайзеры и облегчаторы. Ломбок - как пример. Предурацкая же вещица. Типа - скажем нет бойлерплейту, а на самом деле втихую он же именно его и генерит. Ну вот какой в том смысл - загадка. Макрос в IDE - влегкую такое умеет.
и т.д. и т.п. Могу долго ныть == выпендриваться.
Почему все это плохо? Да потому, в основном, что мне полсотни лет в обед погожего августовского дня было.
Я как бы не самый бестолковый, и кандидат технических, и доктор экономических, и что, я полагаю, что весьма крут и хорош? А вот ни разу. Я буду совершенно точно не у дел, и вы тоже будете точно не у дел, потому что сейчас рынку нужно другое.
Что? А вот что: круд за утро накатать, к обеду затестить, а вечером надо закрыть таску и ждать CI+CD, которые желательно, чтобы не ругнулись даже. Те кто будут этот ваш круд дергать в него никогда не заглянут. Некогда. Все в гонке.
За углом на питоне модель предсказания рынка вашего стека парни в кластере катают, а за другим углом из айфонового и флаттерного миров к вам постучали мобильные разрабы, за третьим на котлине хотят стильно-модно-молодежно, за четвертым на сях переписали узкий кусок или jvm на нейтив решили заменить. Плюс если бизнес взлетает, то надо за вечер его отмасштабировать в ширину и глубину. И? Вот и все. Вот вам они - микросервисы. Вот 12-ти факторные приложения, с очередями и реактивщиной. Вот он - 21 век, прошу любить и жаловать.
А еще, вот вам и вывод: монолиты - лепота, но увы, пока-пока. К ламповым приемникам и винилу плиз.
Просто мысль. Может тогда в самом приложении можно повесить прозрачный слой с OpenGL над вьюшкой с картами? Нижний идёт к Яндексу, верхний на ваш rest к базе. Андроид толком не знаю, но представляется маловероятным, что это невозможно.
Кроссплатформенность конечно улетит в даль далёкую и для браузера/айфона будет(ут) уже другое(ие) решение(я). Поэтому бек скорее всего не сильно полегчает. Но на войне как на войне, оптимизации - это почти всегда адский ад, зоопарк и раздутый код.
Так ведь есть же syncthing — готовое простое решение. Без рута, за 5 минут всего, с UI для домохозяек, опенсорс и т.д и т.п. Но правда в телевизор все сбрасываю с винтом подключенным по USB, а не в старый телефон. Но уверен, что старый телефон был бы не хуже, в телеке процессор совсем печальный, и даже он пока справляется.
Кажется блок-схемы изначально были придуманы чтобы всех бесить. Как и рамочки по ЕСКД и прочая дичь. Все это добро — на месте. ВУЗы — просто погибают. Видно изнутри очень четко, я все еще пытаюсь там "сеять разумное" и прямо вот беда в этой части. Государство — это ужас.
Очевидны и ясны ошибки проектирования системы образования вообще-то. И на уровне отбора кадров, и на уровне финансирования, и в плане целеполагания. Три толковых спеца легко и просто заменят кафедру на 30 человек, ну уж в IT — точно. Автотесты+видео+текст+лайвкодинг — и очень многое можно сделать.
Но кто-то из распорядителей финансовыми потоками должен
а) определить что эти трое вместо 30 — это реально спецы
б) отдать весь зарплатный фонд именно им, а не экономить на сокращениях.
Т.е. зп поднимать нужно в 10 раз, сокращая попутно море тётушек и дедушек. И вот тогда волшебство — если условный тимлид/синьор видит, что вот тут зп выше чем у него, легко понять куда он пойдет впахивать. В ВУЗ. И через пару лет — гарантия результата. Правда тётушкам и дедушкам кушать станет нечего.
Но… все как есть так есть. И скорее всего таковым оно и останется...
Зарядка не стоит в общем-то ничего. Уже скоро 10 лет как я беру лампочку ближнего света или от фильмоскопа на 6 вольт, 3-4 мощных диода (падение 0.7V на каждом) и БП от ноута на 19V — соединяете все это дело последовательно и вуаля — заряжайте сколько душе угодно. Крутые зарядники сделают конечно получше, но лишь на 5-10% да и то не факт.
И ключевой момент: обязательно выключить при достижении максимально рекомендованного производителем АКБ напряжения. Для приведенной Ca-Ca это 16V и это важно. Ca-Ca это вообще важно. Другой акк так убьете.
В современном Skype нет UML и внятного проектирования, а в Telegram очевидно есть. Сравнить нетрудно. И совершенно ясно, что грамотно спроектированная система заведомо лучше тупо нашлепанной по фидбекам. Причем фидбек в грамотно спроектированной системе даже не исключается.
Но! Бизнес - это не инженерия. По крайней мере современный его этап. Суть не в UML, а в инженерном или маркетинговом подходе. Маркетологи почти всегда побеждают инженеров, пока продукт покупают люди. Сделать крутой продукт это 5 процентов работы. Раскрутить и продать - вот где реальные события разворачиваются.
А значит - UML неизбежно мертв. Пока в строгих нотациях пилится архитектурно красивое решение у маркетологов (читай бизнеса) уже три раза концепция продукта поменялась. UML просто не успевает в этой дикой гонке. Даже не UML, а инженерия.
Выход есть - фреймворки. Набор кубиков на все случаи жизни. Условный Spring на backend все больше и все страньше. Но он решает проблему скорости. Скорости разработки. На frontend та же история, тоже фреймворки. И все. UML мертв.
А вы заголовок статьи читали? Парадоксально, но в нем обычно автор отражает, то о чем собственно статья ;)
Разработчик с 25-летним стажем: log4j на сервере это по сути дыра с виде инъекции произвольного кода через LDAP, доставить которую можно тупо через http, например переписав тот же user-agent (чаще всего в пруфах по этой уязвимости фигурирует).
Hо вместо лечения самой дыры "разработчик с 20-летним стажем" запрещает этому вредоносному коду админскими костылями что-то там "важное за звездочками" читать? И ещё и говорит "Problem solved"?
Супер просто. Получите и распишитесь майнер|сниффер|впишите-любую-нагрузку. Не туда смотрите в общем. Это совсем не админская проблема, а именно девелоперская. И не в CI и секретах тут дело, они лишь для примера эксплуатации приведены.
Chromecast + конвертор в VGA.
Да, спасибо. И так тоже должно скомпилироваться (хоть это и банально):
Comparator<String> comparing = Comparator.comparing(String::toLowerCase);
comparing = comparing.reversed();
Я думаю, что именно без присваивания компилироваться не будет. C .reversed() тоже не будет.
Без .reversed(), но с контекстом - будет. С .reversed(), но в следующем операторе тоже будет (т.к. тип уже выведен).
На первый взгляд это конечно контринтуитивно, но Тагир как обычно все здорово же объяснил. Не могу отделаться от ощущения, что вы прикалываетесь. Буду, конечно, рад ошибиться.
Тьфутынуты. Я уж было подумал человек реально не понимает, что происходит, а вы тут рофлите в междусобойчиках. Нехорошо :D
То что вы хотите можно получить либо так
Comparator.comparing(s->s.toString().toLowerCase()) //из Object
либо так
Comparator<String> comparator=Comparator.comparing(String::toLowerCase); //из String
В лоб (без контекста, т.е. в смысле без самого объекта) из Comparator.comparing(String::toLowerCase) компилятору ничего вывести нельзя, т.к. самих этих toLowerCase - много, и непонятно на какой именно вы ссылаетесь. А если ::length или ::hashcode или ::toString - то тут такой неоднозначности не возникает, у этих методов нет перегрузки и компилятор понимает объект какого типа имелся ввиду, и какой из методов этого объекта нужен для извлечения признака (keyExtractor).
Но вообще представить себе где может понадобиться такой код Comparator.comparing(что-угодно) без присваивания или передачи куда-либо довольно трудно. Даже наверное невозможно.
Hotspot так называется потому что.... (и дальше ответ на ваш вопрос)
А сам ассемблер - ненужная абстракция над бинарными кодами?
Получается, что лучший язык программирования - азбука Морзе.
0110100101011100101001001001010010110100101000100101 ой, т.е.
.-...-..-.-.--..-.-.--.---.-.-.---..--.-.--....--...... ))))
Ну и в целом по топику, jvm/jdk их же много, на плюсах - старинная sun, а уже что-то посовременнее, типа граальвм - она вроде вся на джаве.
Да, проблема важная затронута и в ML по сути ключевая.
Но вот какое дело... Подавляющее число данных обо всех событиях человека, компании, бизнеса, сайта практически свободно доступны гигантам вроде гугла. С телефонов и аналитики сервисов такого гиганта есть просто море информации. И гео, и коммуникация, и активности, и расходы с доходами, где был, что искал, что выбрал, что лайкал... В общем ВСЁ! Эти данные структурированы, размечены, объемны. Могут быть валидированы. Любой срез в любой сфере возможен. Для экспериментов просто невероятное поле. Корпус для обучения под нужную сферу собрать - легче простого. А "простым смертным" позволено лишь архив своего собственного поведения получить. Качал как-то, то что есть у гугла на меня - даже без документов, файлов, фото и видео за гигабайт выскочило.
А по прекрасному совпадению эти же гиганты еще и лидеры ML. Итого: их мощности (датасеты) недоступны рядовым исследователям. Ну а сами рядовые исследователи свои модели все чаще в тех же облаках тех же гигантов гоняют. Свои датасеты туда льют. Удачные модели УЖЕ в облаках вероятно видны. Им. Гигантам.
Дальше несложно сложить 2+2. Это будет даже не монополия. Это что-то божественное скорее. В общем, полагаю, нас ждут удивительные времена.
Давайте я вам свое расскажу за монолиты. За то как я на них погорел. Люблю их до боли. А все почему?
Писал всегда только монолиты. Что пишу - то и люблю. Иначе вот не получается как-то.
Всегда практически все полностью сам от начала до конца, от кода до развертывания. Типа самоделкин. Ну или фуллстек, как нынче принято. Приятно. В этом есть смак. Костыли, не костыли - нет проблем. Пока помню свою же архитектуру - вопросов ноль. Паттерны - по желанию. Есть страшные magic-куски и phd-code, да не беда, замечательно же. Приятно даже иногда.
Жаба мое все уже лет 8-10. Но вот недолюбливаю спринги с хибером и вообще любые фреймворки. Почти всегда можно самому сделать все, что они предлагают, и обычно это легко и просто. Обычно легче. Обычно производительнее. Обычно понятнее. Обычно удобнее. Свои DI и IOС, свой пул препередстейтметов без вымывания кеша, причем не ручками а рефлесией наделанный - ну вот что может быть проще.
Ненавижу всякие улучшайзеры и облегчаторы. Ломбок - как пример. Предурацкая же вещица. Типа - скажем нет бойлерплейту, а на самом деле втихую он же именно его и генерит. Ну вот какой в том смысл - загадка. Макрос в IDE - влегкую такое умеет.
и т.д. и т.п. Могу долго ныть == выпендриваться.
Почему все это плохо? Да потому, в основном, что мне полсотни лет в обед погожего августовского дня было.
Я как бы не самый бестолковый, и кандидат технических, и доктор экономических, и что, я полагаю, что весьма крут и хорош? А вот ни разу. Я буду совершенно точно не у дел, и вы тоже будете точно не у дел, потому что сейчас рынку нужно другое.
Что? А вот что: круд за утро накатать, к обеду затестить, а вечером надо закрыть таску и ждать CI+CD, которые желательно, чтобы не ругнулись даже. Те кто будут этот ваш круд дергать в него никогда не заглянут. Некогда. Все в гонке.
За углом на питоне модель предсказания рынка вашего стека парни в кластере катают, а за другим углом из айфонового и флаттерного миров к вам постучали мобильные разрабы, за третьим на котлине хотят стильно-модно-молодежно, за четвертым на сях переписали узкий кусок или jvm на нейтив решили заменить. Плюс если бизнес взлетает, то надо за вечер его отмасштабировать в ширину и глубину. И? Вот и все. Вот вам они - микросервисы. Вот 12-ти факторные приложения, с очередями и реактивщиной. Вот он - 21 век, прошу любить и жаловать.
А еще, вот вам и вывод: монолиты - лепота, но увы, пока-пока. К ламповым приемникам и винилу плиз.
Просто мысль. Может тогда в самом приложении можно повесить прозрачный слой с OpenGL над вьюшкой с картами? Нижний идёт к Яндексу, верхний на ваш rest к базе. Андроид толком не знаю, но представляется маловероятным, что это невозможно.
Кроссплатформенность конечно улетит в даль далёкую и для браузера/айфона будет(ут) уже другое(ие) решение(я). Поэтому бек скорее всего не сильно полегчает. Но на войне как на войне, оптимизации - это почти всегда адский ад, зоопарк и раздутый код.
Так ведь есть же syncthing — готовое простое решение. Без рута, за 5 минут всего, с UI для домохозяек, опенсорс и т.д и т.п. Но правда в телевизор все сбрасываю с винтом подключенным по USB, а не в старый телефон. Но уверен, что старый телефон был бы не хуже, в телеке процессор совсем печальный, и даже он пока справляется.
Кажется блок-схемы изначально были придуманы чтобы всех бесить. Как и рамочки по ЕСКД и прочая дичь. Все это добро — на месте. ВУЗы — просто погибают. Видно изнутри очень четко, я все еще пытаюсь там "сеять разумное" и прямо вот беда в этой части. Государство — это ужас.
Очевидны и ясны ошибки проектирования системы образования вообще-то. И на уровне отбора кадров, и на уровне финансирования, и в плане целеполагания. Три толковых спеца легко и просто заменят кафедру на 30 человек, ну уж в IT — точно. Автотесты+видео+текст+лайвкодинг — и очень многое можно сделать.
Но кто-то из распорядителей финансовыми потоками должен
а) определить что эти трое вместо 30 — это реально спецы
б) отдать весь зарплатный фонд именно им, а не экономить на сокращениях.
Т.е. зп поднимать нужно в 10 раз, сокращая попутно море тётушек и дедушек. И вот тогда волшебство — если условный тимлид/синьор видит, что вот тут зп выше чем у него, легко понять куда он пойдет впахивать. В ВУЗ. И через пару лет — гарантия результата. Правда тётушкам и дедушкам кушать станет нечего.
Но… все как есть так есть. И скорее всего таковым оно и останется...
Смотря какой ВУЗ вообще-то. В русскоязычной части, например, ИТМО может очень сильно изменить вашу точку зрения. Не говоря уже про ВУЗы планеты.
Безусловно
Зарядка не стоит в общем-то ничего. Уже скоро 10 лет как я беру лампочку ближнего света или от фильмоскопа на 6 вольт, 3-4 мощных диода (падение 0.7V на каждом) и БП от ноута на 19V — соединяете все это дело последовательно и вуаля — заряжайте сколько душе угодно. Крутые зарядники сделают конечно получше, но лишь на 5-10% да и то не факт.
И ключевой момент: обязательно выключить при достижении максимально рекомендованного производителем АКБ напряжения. Для приведенной Ca-Ca это 16V и это важно. Ca-Ca это вообще важно. Другой акк так убьете.
В современном Skype нет UML и внятного проектирования, а в Telegram очевидно есть. Сравнить нетрудно. И совершенно ясно, что грамотно спроектированная система заведомо лучше тупо нашлепанной по фидбекам. Причем фидбек в грамотно спроектированной системе даже не исключается.
Но! Бизнес - это не инженерия. По крайней мере современный его этап. Суть не в UML, а в инженерном или маркетинговом подходе. Маркетологи почти всегда побеждают инженеров, пока продукт покупают люди. Сделать крутой продукт это 5 процентов работы. Раскрутить и продать - вот где реальные события разворачиваются.
А значит - UML неизбежно мертв. Пока в строгих нотациях пилится архитектурно красивое решение у маркетологов (читай бизнеса) уже три раза концепция продукта поменялась. UML просто не успевает в этой дикой гонке. Даже не UML, а инженерия.
Выход есть - фреймворки. Набор кубиков на все случаи жизни. Условный Spring на backend все больше и все страньше. Но он решает проблему скорости. Скорости разработки. На frontend та же история, тоже фреймворки. И все. UML мертв.
Я же просто пошутил ;). Но познание и даже самопознание (в полном объеме) — да, невозможны, тут я с вами полностью согласен. И не я один.
А ваша статья реально классная!
Краткое содержание: сферический конь в вакууме как инструмент познания самого сферического коня в вакууме сферическими конями в вакууме.
Вывод: сферический конь объективно существует, описывает все, но пока не найден. Он же есть Бог и формула. Формула всего.
Это перестанет быть шуткой если вам много лет и/или вы действительно много учились. Скорее всего. Но не факт :)