В этой статье речь про границы между теорией и практикой, и что эти границы размываются прикладными инструментами
Поэтому хочу уточнить, разве "Реляционные БД vs Linked Data", "SQL vs SPARQL" и т.д. стоит рассматривать в таком ключе?
Вот, "ORM vs ORM-like" - я понимаю как можно рассмотреть. Например, как разные реализации ORM, ORM-like способствуют нарушению границ, путанице, хаосу.
Отлично! Вы пишете именно о том, что я хотел раскрыть в статье: размытие границ между формальным и прикладным
доменный объект собирается при помощи Repository
эта формулировка больше подходит для формального определения репозитория. На прикладном уровне мы можем встретить разные реализации, у некоторых из которых общее с определениями - это только название. P.S. но это не проблема, если намерения разработчика выражены в коде явно.
5. Каждый из методов DAO работает с ORM ...
6. UseCase из трех объектов собирает один DTO ...
пункты 5, 6 и остальные - это пример возможного пайплайна по работе с данными. по статье задумывалось, что пример не будет согласован с теорией.
Про книги абсолютно вас понимаю. часто задаюсь похожими вопросами.
DAO объекты работают с данными в бд при помощи ORM
или DAO вообще не нужен, потому что реализован в ORM? значит вместо DAO называем класс Repository. правда кроме названия ничего не изменилось. так и живем :D
Думаю, вы отчасти правы. в моем понимании ORM меньше подходит под определение онтологии, чем языки запросов - с ними все понятно: и как и где применять. а вот в случае с разными ORM из-за их уникальных фишек границы размываются. Поэтому в контексте статьи хорошо рассматривать несколько разных ORM. Языки запросов, как мне кажется, выбиваются из общей идеи
это очень хорошее наблюдение, спасибо ) по возможности посмотрю
что касаемо 00-х годов - здесь эта дата больше как рубеж, после которого и началась Великая Путаница. бум дот комов в 90-х, популяризация IT - всё это внесло свой вклад. вы правы насчет появления многократных трактовок
я думаю, дело не только в многообразии определений, но и в инструментах. возможно, прикладные инструменты вносят больший хаос, чем разные определения. инструментами пользуются все, знают/используют определения - не все
успешное прохождение испытательного срока не показатель, 94-95% от трудоустроенных понятных говорунов проходит испыталку.
мне кажется тут не подсвечен вопрос того, что бизнесу не выгодно увольнять - в таком случае некоторому кол-ву людей придется признаться в своей ошибке, это невыгодно, это риск, проще тянуть лямку
100% гайд делюсь бесплатно, кажется эффективным: простой, понятный, на результат
Чекаешь рынок для следующего грейда чем текущий, 1 месяц готовишься к собесам этого грейда
Затем 1 месяц ходишь по шаражкиным конторам начиная со средней зарплаты этого грейда. На каждые 10 собесов: если оферов 0, значит понижаешь зп ожидания, если оферов 2-3 то можно повысить на 10%: тем выше процент, чем выше кол-во оферов (по статистике в среднем по больнице 17% собесов заканчиваются офером).
Затем на второй-третий месяц ты понимаешь стоимость себя и можешь собеситься в целевые конторы по типу Яндекс, озон, Авито и другие не боясь продешевишь. Если конечно есть такая цель. Или просто ходишь по собесам повышая ожидания на 5% после каждого офера и так лесенкой пока кол-во предлагаемых оферов не станет равно 0.
В данном случае лучше обращаться к статистике. Я помню только один завирусившийся мем, связанный с этим. Но опять же я все еще не нашел ответа на вопрос, чем формат работы аутстафа отличается от формата работы, когда один чел отдает работу другому, и это ничем не отличается от перекупов/перепродажников. Да, это типа осуждается, но с другой стороны ничего личного просто бизнес. А мы тут сидим воняем на ветер, что он дует. кек
Вопрос, есть какой-нибудь реальный кейс, когда нужно прибегнуть к самостоятельному написанию дескриптора?
Зачастую они уже все реализованы и лезть под капот не нужно. Или у нас уже есть для этого более явная концепция в виде геттеров и сеттеров, или декораторов, которые позволяют реализовать то же самое. Декораторы - не явное поведение, а дескрипторы ещё менее явное.
Советов как составить резюме - как грязи, а вот гайдов, как это делать максимально эффективно, единицы - смотрите Антона Назарова и Кошачью Бацылу, не пожалеете
Ключевое для меня ещё и то, что накрутчик пошёл в галеру, как писали выше, а когда крутишь надо идти в компанию побольше, где можно затерятьсяв в людях, в процессах и не сильно привлекать внимание. Ну и менеджер сразу видно такая же эффективная сова, 100к не зп мидла и тд.
Неудачное стечение обстоятельств, ошибка не выжившего) ух а сколько выживших..))
С чем связана уверенность в том, что это не ошибка выжившего. И дети действительно такие, а не их желание "быть удобными" для родителей и для всех вокруг? (p.s. почему? потому что их так воспитали)
отлично, перечитал и заметил, я к похожей мысли прихожу) 🤝
сто процентов) для полноты картины мне стоило упомянуть persistence layer и вывод, который вы пишете. была бы карма я бы лайкнул)) спасибо
Кажется, понял
В этой статье речь про границы между теорией и практикой, и что эти границы размываются прикладными инструментами
Поэтому хочу уточнить, разве "Реляционные БД vs Linked Data", "SQL vs SPARQL" и т.д. стоит рассматривать в таком ключе?
Вот, "ORM vs ORM-like" - я понимаю как можно рассмотреть. Например, как разные реализации ORM, ORM-like способствуют нарушению границ, путанице, хаосу.
Отлично! Вы пишете именно о том, что я хотел раскрыть в статье: размытие границ между формальным и прикладным
эта формулировка больше подходит для формального определения репозитория. На прикладном уровне мы можем встретить разные реализации, у некоторых из которых общее с определениями - это только название. P.S. но это не проблема, если намерения разработчика выражены в коде явно.
пункты 5, 6 и остальные - это пример возможного пайплайна по работе с данными. по статье задумывалось, что пример не будет согласован с теорией.
Про книги абсолютно вас понимаю. часто задаюсь похожими вопросами.
или DAO вообще не нужен, потому что реализован в ORM? значит вместо DAO называем класс Repository. правда кроме названия ничего не изменилось. так и живем :D
Думаю, вы отчасти правы. в моем понимании ORM меньше подходит под определение онтологии, чем языки запросов - с ними все понятно: и как и где применять. а вот в случае с разными ORM из-за их уникальных фишек границы размываются. Поэтому в контексте статьи хорошо рассматривать несколько разных ORM. Языки запросов, как мне кажется, выбиваются из общей идеи
это очень хорошее наблюдение, спасибо ) по возможности посмотрю
что касаемо 00-х годов - здесь эта дата больше как рубеж, после которого и началась Великая Путаница. бум дот комов в 90-х, популяризация IT - всё это внесло свой вклад. вы правы насчет появления многократных трактовок
я думаю, дело не только в многообразии определений, но и в инструментах. возможно, прикладные инструменты вносят больший хаос, чем разные определения. инструментами пользуются все, знают/используют определения - не все
успешное прохождение испытательного срока не показатель, 94-95% от трудоустроенных понятных говорунов проходит испыталку.
мне кажется тут не подсвечен вопрос того, что бизнесу не выгодно увольнять - в таком случае некоторому кол-ву людей придется признаться в своей ошибке, это невыгодно, это риск, проще тянуть лямку
100% гайд делюсь бесплатно, кажется эффективным: простой, понятный, на результат
Чекаешь рынок для следующего грейда чем текущий, 1 месяц готовишься к собесам этого грейда
Затем 1 месяц ходишь по шаражкиным конторам начиная со средней зарплаты этого грейда. На каждые 10 собесов: если оферов 0, значит понижаешь зп ожидания, если оферов 2-3 то можно повысить на 10%: тем выше процент, чем выше кол-во оферов (по статистике в среднем по больнице 17% собесов заканчиваются офером).
Затем на второй-третий месяц ты понимаешь стоимость себя и можешь собеситься в целевые конторы по типу Яндекс, озон, Авито и другие не боясь продешевишь. Если конечно есть такая цель. Или просто ходишь по собесам повышая ожидания на 5% после каждого офера и так лесенкой пока кол-во предлагаемых оферов не станет равно 0.
Можно повторять бесконечно
В данном случае лучше обращаться к статистике. Я помню только один завирусившийся мем, связанный с этим. Но опять же я все еще не нашел ответа на вопрос, чем формат работы аутстафа отличается от формата работы, когда один чел отдает работу другому, и это ничем не отличается от перекупов/перепродажников. Да, это типа осуждается, но с другой стороны ничего личного просто бизнес. А мы тут сидим воняем на ветер, что он дует. кек
Понял+-, спасибо, ещё раз перечитаю чтоб уложилось
Спасибо за полное погружение
Вопрос, есть какой-нибудь реальный кейс, когда нужно прибегнуть к самостоятельному написанию дескриптора?
Зачастую они уже все реализованы и лезть под капот не нужно. Или у нас уже есть для этого более явная концепция в виде геттеров и сеттеров, или декораторов, которые позволяют реализовать то же самое. Декораторы - не явное поведение, а дескрипторы ещё менее явное.
Синтетические примеры напоминают ментальную разминку.
"Джуны в среднем 90, а мидлы 180"
Ну такое.. попахивает занижением, ещё бы с ХХ взяли среднее, мидлы 2+ года так то на 200-250 сидят
Мне кажется или это реклама
Да ну бред какой-то)
Советов как составить резюме - как грязи, а вот гайдов, как это делать максимально эффективно, единицы - смотрите Антона Назарова и Кошачью Бацылу, не пожалеете
Ключевое для меня ещё и то, что накрутчик пошёл в галеру, как писали выше, а когда крутишь надо идти в компанию побольше, где можно затерятьсяв в людях, в процессах и не сильно привлекать внимание. Ну и менеджер сразу видно такая же эффективная сова, 100к не зп мидла и тд.
Неудачное стечение обстоятельств, ошибка не выжившего) ух а сколько выживших..))
Не могу сказать, чтобы здесь были описаны бестпрактис, а вот как описание выстроенного процесса - нормас, спасибо
С чем связана уверенность в том, что это не ошибка выжившего. И дети действительно такие, а не их желание "быть удобными" для родителей и для всех вокруг? (p.s. почему? потому что их так воспитали)