Кстати да

Эволюционный подход, без проб и ошибок и руби бы не было

Иногда так проверяют удобство и выгоду разных подходов

Делайте это в разных проектах

Эволюционный подход, без проб и ошибок и руби бы не было

Ой не грвори мне про эволюционный подход

Делайте это в разных проектах

Разные контексты, и не всегда есть несколько проектов

Он рождает чудовищ

Ой не грвори мне про эволюционный подход

Не все человеком становятся из обезьяны, да

Он рождает чудовищ

Либо они приспособлены к жизни, либо умирают

#hanami А философия Ханами предполагает написание кастомной мемоизации, чтобы не делать лишние запросы в БД? Т.е. нормально писать внутри Entity проверку "если ассоциация пустая, то пробуем её сначала прогрузить из БД, иначе берём загруженную"? и везде используем этот метод. Или же не паримся и всегда, когда нужно поработать с некой моделью, просто загружаем её из БД отдельным запросом?

Либо они приспособлены к жизни, либо умирают

Нет, они будут жить и развиваться

Нет, они будут жить и развиваться

Что входит в первый вариант

Но это будут бактерии по ободком унитаза

Но это будут бактерии по ободком унитаза

Хреновая аналогия для одного проекта

Хреновая аналогия для одного проекта

Охуенная аналогия

У меня тут как раз такой случай

Проект — это одна вещь, бактерии — это множество. Чё ты несёшь

Не нравится проект — не берись. Никто не будет браться — "чудовище" умрёт. Готов браться — значит, оно может жить

Не нравится проект — не берись. Никто не будет браться — "чудовище" умрёт. Готов браться — значит, оно может жить

Хаха

Аналогия не в том что это бактерии

И в том что их много

Я так 2 года чудовищу пластическую операцию делал

Я так 2 года чудовищу пластическую операцию делал

Счастлив был? :)

Там было всё замечательно - кроме проекта

:D

Делайте это в разных проектах

Проверка разных подходов в разных условиях/средах(читать как проектах) может дать необъективную оценку в итоге ?

Не нравится проект — не берись. Никто не будет браться — "чудовище" умрёт. Готов браться — значит, оно может жить

Просто складывается ощущение что ты в каком-то выдуманном мире живешь

Проверка разных подходов в разных условиях/средах(читать как проектах) может дать необъективную оценку в итоге ?

Там по любому будет субьективная оценка

Проверка разных подходов в разных условиях/средах(читать как проектах) может дать необъективную оценку в итоге ?

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

Вот поэтому и проверяют в одном проекте))

В одном обычно если работает в итоге - всё, стабл версия, никому не трогать

Пишем в изначальном стиле, легаси и тп

А потом с ноля переписывают

Вот поэтому и проверяют в одном проекте))

В большинстве случаев это не эксперименты

Исключения - большие проекты с лямом строк кода

А просто распиздяйство

Просто складывается ощущение что ты в каком-то выдуманном мире живешь

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

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

Тебе еще и все разжевывать :)

#hanami А философия Ханами предполагает написание кастомной мемоизации, чтобы не делать лишние запросы в БД? Т.е. нормально писать внутри Entity проверку "если ассоциация пустая, то пробуем её сначала прогрузить из БД, иначе берём загруженную"? и везде используем этот метод. Или же не паримся и всегда, когда нужно поработать с некой моделью, просто загружаем её из БД отдельным запросом?

меня просто удивляет, что со всей свободой руби код там лучше чем то, что я вижу в пиотне, с его import this и философией явности, питонвей и тд

меня просто удивляет, что со всей свободой руби код там лучше чем то, что я вижу в пиотне, с его import this и философией явности, питонвей и тд

найди проект на синатре

Тебе еще и все разжевывать :)

не, можешь просто говно набрасывать, но тогда и цена твоим словам будет ниже

найди проект на синатре

на синатре регулярно пишут сорт оф

наколеночное и простое..

ненаколеночное

не, можешь просто говно набрасывать, но тогда и цена твоим словам будет ниже

Ок, я согласен, очевидные вещи разъяснять я не берусь.

ребят, никогда не сталкивался, но позабавило. irb 2.4.1 irb(main):001:0> a NameError: undefined local variable or method `a' for main:Object from (irb):1 from /home/dmitry/.rbenv/versions/2.4.1/bin/irb:11:in `<main>' irb(main):002:0> b NameError: undefined local variable or method `b' for main:Object from (irb):2 from /home/dmitry/.rbenv/versions/2.4.1/bin/irb:11:in `<main>' irb(main):003:0> a = b NameError: undefined local variable or method `b' for main:Object from (irb):3 from /home/dmitry/.rbenv/versions/2.4.1/bin/irb:11:in `<main>' irb(main):004:0> b = a => nil

ребят, никогда не сталкивался, но позабавило. irb 2.4.1 irb(main):001:0> a NameError: undefined local variable or method `a' for main:Object from (irb):1 from /home/dmitry/.rbenv/versions/2.4.1/bin/irb:11:in `<main>' irb(main):002:0> b NameError: undefined local variable or method `b' for main:Object from (irb):2 from /home/dmitry/.rbenv/versions/2.4.1/bin/irb:11:in `<main>' irb(main):003:0> a = b NameError: undefined local variable or method `b' for main:Object from (irb):3 from /home/dmitry/.rbenv/versions/2.4.1/bin/irb:11:in `<main>' irb(main):004:0> b = a => nil

да, по любой причине неудавшегося присваивания переменная становится nil

pry: main > a NameError: undefined local variable or method `a' for main:Object from (pry):34:in `<main>' pry: main > a = nil.foo NoMethodError: private method `foo' called for nil:NilClass from (pry):35:in `<main>' pry: main > a => nil

это только в pry/irb очевидно в файлах код падает на первом undefined local variable

так он и в irb по сути упал

это только в pry/irb очевидно в файлах код падает на первом undefined local variable

Переменная объявилась все равно

Дело не в irb/pry

ребят, а скиньте пожалуйста тот фановый сниппет с открытием ошибки на stackoverflow

ребят, а скиньте пожалуйста тот фановый сниппет с открытием ошибки на stackoverflow

там rescue и open

#hanami А философия Ханами предполагает написание кастомной мемоизации, чтобы не делать лишние запросы в БД? Т.е. нормально писать внутри Entity проверку "если ассоциация пустая, то пробуем её сначала прогрузить из БД, иначе берём загруженную"? и везде используем этот метод. Или же не паримся и всегда, когда нужно поработать с некой моделью, просто загружаем её из БД отдельным запросом?

последнее, ленивая загрузка это дорога боли

@flash_gordon Никита, зачем классам private методы?

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

для меня private это просто синоним @api private

это в целом про ruby private или вы в каком-то контексте общаетесь? )

я отвечал про руби)

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

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

там же написано "какой-то апи внутренний" ?

а, да ) туплю ) просто "апи внутренний" - не совсем понятно звучит, как по мне ) субъективно )

ребят, а скиньте пожалуйста тот фановый сниппет с открытием ошибки на stackoverflow

я чет задолбался его искать

для js вот https://camo.githubusercontent.com/8f214eab571dcd713891f1ec164f28b86e5ea29f/687474703a2f2f692e696d6775722e636f6d2f776c52775259692e6a7067

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

ну какой смысл писать private вообще?

ERROR: S client not available

Это ведь не про руби вопрос?

в руби или в доке? доку просто не все смотрят

в руби

чуваки тут говорят что private не нужен

Это они зря конечно

Хотя деды на древних языках писали и норм

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

ну смысл такой, что на private не распространются правила из semver, в любой момент это может поменяться

у меня private все что не паблик.

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

у меня private все что не паблик.

+

Паблик четко говорят - вот это может юзаться где-то ещё, захочешь поменять - поищи места юзания

И пофикси их

Включая всё что аффектит выше

Если же приват - не вылезаешь за пределы дерева классов

а ещё рефакторить в ide удобно, не шарится по всем файлам в поисках вызовов, которых там быть не может

IDE не нужны.

а вы ж ide не любите, я забыл, сорян

IDE не нужны.

я не успел дописать даже :/

а вы ж ide не любите, я забыл, сорян

?

IDE то конечно рефакторят, но тем не менее указание что это приват - удобнее

я если что имел в виду гемы, а не код в проектах. В проектах я предпочитаю классы, у которых есть только один метод, который вызывается извне — call. Так как это единственный интерфейс, отмечать остальные методы как private не имеет смысла

удобно

я если что имел в виду гемы, а не код в проектах. В проектах я предпочитаю классы, у которых есть только один метод, который вызывается извне — call. Так как это единственный интерфейс, отмечать остальные методы как private не имеет смысла

так кто-то будет дергать остальные публичные методы

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

к этому просто привыкнуть

ну и не так уж слохно замутить какую-нибудь мета-фигню, которая остальные методы сама закроет

ну и не так уж слохно замутить какую-нибудь мета-фигню, которая остальные методы сама закроет

ну у тебя уже в проекте будут ссылки на эти методы

и будет сложно отрефакторить

ну у тебя уже в проекте будут ссылки на эти методы

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

я если что имел в виду гемы, а не код в проектах. В проектах я предпочитаю классы, у которых есть только один метод, который вызывается извне — call. Так как это единственный интерфейс, отмечать остальные методы как private не имеет смысла

А зачем классы нужны тогда?