Именно поэтому я и придерживаюсь точки зрения, что нужно учиться только у native speakers
Собственно, так и делаю. Не уроки у них беру, а просто общаюсь повседневно – соответственно, нарабатывается некоторая "чуйка" на естественность речи. У автора, к сожалению, построение предложений очень натужное – это во всех её статьях просматривается. С таким уровнем учить других не следует ни в коем случае.
Чисто интуитивно, мне кажется a better stability более корректной формой,
Да. Или уж the better – если пишущий хочет донести свою уверенность в неоспоримом превосходстве. Не думаю, что натив мог бы написать такое предложение вообще без артикля.
Слово "stability" неисчисляемое (uncountable), поэтому неопределенный артикль перед ним не нужен
Вы совсем не чувствуете язык. В данном случае степень улучшения неизвестна, поэтому неопределённый артикль. Просто наберите в поиске "for a better" и получите целую пачку ссылок типа for a better life, for a better world и т.п. – все неисчисляемые.
Дополню: в данном случае, кстати, всё не так уж однозначно, допустимо было бы написать и for the better – если пишущий уверен, что преимущество общепризнано и неоспоримо.
Просто удивительно, какое чудовищное количество времени и усилий тратится на переделку того, что и так работает. Я каждый новый релиз ставлю с некоторой опаской: а не поломали ли привычный интерфейс до такой степени, что придётся менять все привычки.
Проблема Android в том, что всегда считался догоняющим в массовом понимании пользователей, в то время как iOS подавалась как более красивая, эстетичная и дорогая, имеющая более плавные анимации при взаимодействии система.
Наверное, я не массовый пользователь. К эппловским гуям так и не смог адаптироваться – неудобно мне. Использовать иногда приходится, по долгу службы – но радости не доставляет, совсем.
Можно и за год перегореть, тут от усилий работодателя много зависит.
Насколько я помню, крепостное право отменили в 1861 году. Не нравится работодатель – уходите к другому. Только не надо рассказывать, что все они одинаковы, только и мечтают о том, как бы из работников побольше соков выпить. Это не так.
Написать несложно, только результаты вам потом надо из рекрдсета вытащить, запихнуть в ДТО, привести все типы, и т.д.
Так для этого делается один метод по сути, который принимает на вход строку запроса, список его параметров и тот самый ДТО, который нужно заполнить. Реально чуть сложнее, но всё равно делается один раз.
Для простых применений, которых в практике большинство
Так в том-то и противоречие. Вроде написать
SELECT * FROM users;
и так несложно, и никакого особого бойлерплэйта не требует. А вот в сложных случаях, во-первых, ОРМ реализация становится крайне запутанной; во-вторых, вообще непонятно, как её оптимизировать. У меня, например, сидит классный DBA, который может выдернуть из кода любой запрос, погонять его в шелле, подкрутить SQL, добавить индексы и вообще всё, что угодно с ним сделать, и тут же вернуть оптимизированную версию обратно. Если же это ОРМ, то ему для начала пришлось бы преобразовывать код в сырой SQL – и при этом нигде не ошибиться, потом оптимизировать, а потом переносить обратно в формат ОРМ. Очень много ненужных телодвижений и возможностей для ошибки.
А то выгорание это только в айти. Не надо думать что если, айтишка то сразу возможно модное слово выгорание.
Я уже написал, что думаю. "Выгорают" те, кто занимается не своим делом. Или те, кто в принципе считает, что выходя на работу, делают одолжение работодателю самим фактом своего присутствия – а когда выясняется, что от них ещё и каких-то результатов ожидают, это напрочь ломает их картину мира.
Собрались в зуме несколько человек, которые преодолели пятилетний рубеж в ИТ
Полагаю, если бы,собрались те, кто преодолел рубеж лет хотя бы в 15 (и лучше не в зуме, а за чашечкой пива), у них нашлись бы более интересные темы, чем "выгорание". Каждому своё: если вы "выгорели" за такой срок – это вообще не ваша сфера деятельности, ищите другую.
Понятия не имею 🙂 Не использовали мы его. Пишут, что готов, а как на практике – смотреть нужно. Веб тоже вроде как готов, и у нас даже частично в продакшн – но таки чуть сыроват ещё. Вот только что новую версию выкатили, посмотрим.
Только для этого нужно тестировать, а это уже после компиляции и цикл разработки дольше.
Да ладно. Вот SQL как раз можно в любой момент проверить – причём не только на синтаксис, а ещё и на логическую правильность. Заходишь в шелл тестовой базы, запускаешь свой запрос и смотришь, что вернул. В случае же с ОРМ результат можно будет увидеть только после сборки, и если ошибся, придётся снова пересобирать всё, или как минимум, какую-то часть проекта. Так что где тут бензопила (вжик...), а где топор – вовсе не так однозначно.
код гарантирует синтаксически верный запрос, а также проверку типов, ещё на этапе компиляции.
Ошибку синтаксиса SQL, наверное, тоже непросто пропустить – если код хоть как-то тестируется. Проверка типов – замечательно. Но не получается, что снимаем одну проблему, а взамен получаем кучу других? На том же хабре весьма регулярно появляются статьи об их успешном (или не очень) преодолении. Как вот эта, например. Никого не отговариваю, просто интересно.
да хоть с помощью сырого SQL
Вот это, по-моему, звучит совсем нехорошо. Если технология не позволяет получить нужный результат, надо брать другую, а не зоопарк устраивать.
Вот честно, не понимаю я смысла в ОРМ. В частности, в примерах автора SQL читается намного лучше, чем эквивалентный ему код – при том, что запросы все очень простые. Как уложить в ОРМ по-настоящему сложный запрос и не сойти с ума (особенно на этапе поддержки, когда понадобится его чуток поменять) – для меня загадка. А полный перевод сколько-нибудь сложного проекта на другую базу нужен примерно никогда. Оно точно того сто̀ит?
Собственно, так и делаю. Не уроки у них беру, а просто общаюсь повседневно – соответственно, нарабатывается некоторая "чуйка" на естественность речи. У автора, к сожалению, построение предложений очень натужное – это во всех её статьях просматривается. С таким уровнем учить других не следует ни в коем случае.
Да. Или уж the better – если пишущий хочет донести свою уверенность в неоспоримом превосходстве. Не думаю, что натив мог бы написать такое предложение вообще без артикля.
Этого далеко не всегда достаточно. Например:
— How many?
— A few.
И множество других случаев. Например, этот.
Вы совсем не чувствуете язык. В данном случае степень улучшения неизвестна, поэтому неопределённый артикль. Просто наберите в поиске "for a better" и получите целую пачку ссылок типа for a better life, for a better world и т.п. – все неисчисляемые.
Дополню: в данном случае, кстати, всё не так уж однозначно, допустимо было бы написать и for the better – если пишущий уверен, что преимущество общепризнано и неоспоримо.
Many servers run on Linux for a better stability.
Выглядят похоже – управляются по-разному. За MIUI не скажу, не пользовался.
Просто удивительно, какое чудовищное количество времени и усилий тратится на переделку того, что и так работает. Я каждый новый релиз ставлю с некоторой опаской: а не поломали ли привычный интерфейс до такой степени, что придётся менять все привычки.
Наверное, я не массовый пользователь. К эппловским гуям так и не смог адаптироваться – неудобно мне. Использовать иногда приходится, по долгу службы – но радости не доставляет, совсем.
Надо же. Мы так делаем уже лет... и не вспомню, сколько. 15, 20? Примерно всегда, в общем. Знал бы, что это такая горячая тема, давно бы поделился.
Вы вообще статью-то прочитали? Или хотя бы комментарии, с которыми спорите? Напомню, господам зумерам
Насколько я помню, крепостное право отменили в 1861 году. Не нравится работодатель – уходите к другому. Только не надо рассказывать, что все они одинаковы, только и мечтают о том, как бы из работников побольше соков выпить. Это не так.
Так для этого делается один метод по сути, который принимает на вход строку запроса, список его параметров и тот самый ДТО, который нужно заполнить. Реально чуть сложнее, но всё равно делается один раз.
Так в том-то и противоречие. Вроде написать
и так несложно, и никакого особого бойлерплэйта не требует. А вот в сложных случаях, во-первых, ОРМ реализация становится крайне запутанной; во-вторых, вообще непонятно, как её оптимизировать. У меня, например, сидит классный DBA, который может выдернуть из кода любой запрос, погонять его в шелле, подкрутить SQL, добавить индексы и вообще всё, что угодно с ним сделать, и тут же вернуть оптимизированную версию обратно. Если же это ОРМ, то ему для начала пришлось бы преобразовывать код в сырой SQL – и при этом нигде не ошибиться, потом оптимизировать, а потом переносить обратно в формат ОРМ. Очень много ненужных телодвижений и возможностей для ошибки.
Не бо̀льшая часть, а вообще все. Рабство вроде давно отменили.
Это Вы о пяти зумерах с пятилетним стажем? Статья вроде об их ощущениях. Которые откровенно пишут, что им:
Я уже написал, что думаю. "Выгорают" те, кто занимается не своим делом. Или те, кто в принципе считает, что выходя на работу, делают одолжение работодателю самим фактом своего присутствия – а когда выясняется, что от них ещё и каких-то результатов ожидают, это напрочь ломает их картину мира.
От вида деятельности не зависит.
Полагаю, если бы,собрались те, кто преодолел рубеж лет хотя бы в 15 (и лучше не в зуме, а за чашечкой пива), у них нашлись бы более интересные темы, чем "выгорание". Каждому своё: если вы "выгорели" за такой срок – это вообще не ваша сфера деятельности, ищите другую.
Понятия не имею 🙂 Не использовали мы его. Пишут, что готов, а как на практике – смотреть нужно. Веб тоже вроде как готов, и у нас даже частично в продакшн – но таки чуть сыроват ещё. Вот только что новую версию выкатили, посмотрим.
Да ладно. Вот SQL как раз можно в любой момент проверить – причём не только на синтаксис, а ещё и на логическую правильность. Заходишь в шелл тестовой базы, запускаешь свой запрос и смотришь, что вернул. В случае же с ОРМ результат можно будет увидеть только после сборки, и если ошибся, придётся снова пересобирать всё, или как минимум, какую-то часть проекта. Так что где тут бензопила (вжик...), а где топор – вовсе не так однозначно.
Ошибку синтаксиса SQL, наверное, тоже непросто пропустить – если код хоть как-то тестируется. Проверка типов – замечательно. Но не получается, что снимаем одну проблему, а взамен получаем кучу других? На том же хабре весьма регулярно появляются статьи об их успешном (или не очень) преодолении. Как вот эта, например.
Никого не отговариваю, просто интересно.
Вот это, по-моему, звучит совсем нехорошо. Если технология не позволяет получить нужный результат, надо брать другую, а не зоопарк устраивать.
Так по-моему, на джаве уже и не пишут иначе, независимо от сложности. Нужна база – цепляй ОРМ. Могу ошибаться, конечно – давненько с ней дела не имел.
Вот честно, не понимаю я смысла в ОРМ. В частности, в примерах автора SQL читается намного лучше, чем эквивалентный ему код – при том, что запросы все очень простые. Как уложить в ОРМ по-настоящему сложный запрос и не сойти с ума (особенно на этапе поддержки, когда понадобится его чуток поменять) – для меня загадка. А полный перевод сколько-нибудь сложного проекта на другую базу нужен примерно никогда. Оно точно того сто̀ит?
Я же специально уточнил: на естественных ландшафтах. А уж кого на Ваших работах называют менеджерами, не в курсе.