Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
FROM users
SELECT email, age ;
Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь. Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например. Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
Видимо придирка к «распределение… описывается», я бы сказал «данные распределены вдоль прямой», но я ни разу не переводчик. Ну и в целом «алгоритмы данных предполагают» звучит довольно необычно :-)
Но как быть простому смертному? Простому, нормальному парню, который в гробу видал все эти технологии. Парню, который не торчит от новой операционки, или сраного гаджета.
Как вариант — смириться с недостатком мозгов и найти менее требовательную профессию. В депутаты можно пойти, ограничительные законы писать. Заодно можно с легкостью отыграться на этих мерзких «ботанах».
Размазывать сопли о прокуренную жилетку хабра — не вариант. А то так и будет — «жизнь заставила быть программистом», а хочется «тискать девочек во дворах» и прочее нытье. Следуйте моде: nodejs, mongodb — читать много не надо и девочкам в клубах будет что рассказать.
Как правило, такие туториалы предназначаются для самого начального уровня, чтобы можно было быстро вовлечь человека. Рассматривать здесь вопросы настройки продакшена совершенно не к месту. К тому же из начала статьи понятно, что текст от новичка к совсем новичку.
Про respond_to никто не забывает. Полезная штука. Но, к сожалению, тоже не универсальная.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
А разгадка одна — желание сделать код как можно более легким для поддержания. CanCan — норм, когда речь идет о простых вещах. Сложные контроллеры порождают кучу условных фильтров, мусорных спецификаций (типа блоков respond_to) и соотношение неполезного кода к полезному становится не в пользу последнего. Некоторых людей это раздражает.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
Да, да. Аджайл — это дисциплина (а, RUP видимо — вершина безалаберностью). Всегда казалось, что аджайл — это гибкость, свобода. Жертвуем строгостью процесса, ради более эффективной работы. Individuals and interactions over processes and tools и все такое.
Но, проповедники налегают. В общем, комментарии выше вскрывают проблемы в полной мере, почти нечего добавить.
Развернутый ответ на этот вопрос заслуживает отдельного топика. Почему-то его задают чаще всего (вместе с «а что будете делать, если на вас наедут?» :-)
Если кратко, будем бороться комплексно: продуманное управление репутацией пользователя, ручной модерацией, будем давать слово бизнесу и будем учить его работать с такими отзывами.
К сожалению, это не самая тяжелая задача, которую нам предстоит решить.
Тогда надо работать над тем, чтобы поход к руководителю не был неприятной, стрессовой ситуацией. Уходить от «жалоб» и «попрощайничества» к чему-то более конструктивному.
Разработчики достаточно профессиональны и хорошо мотивированы
Есть доверие между заказчиком и исполнителем (или это работа над собственным продуктом)
тогда описанный подход может дать хороший результат с минимумом затрат на побочную деятельность.
В комментариях часто прослеживаются вопросы — «а если разработчики то..., а если это...». Да, если разработчики не опытны, не понимают что и зачем они делают или не хотят сами это сделать — то да, нужно пасти. В другом случае — достаточно периодически корректировать и не мешать.
Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь.
Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например.
Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
О, не знал о таком проекте, выглядит очень круто, спасибо за наводку!
Спасибо :-)
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
В любом случае спасибо за труд!
Как вариант — смириться с недостатком мозгов и найти менее требовательную профессию. В депутаты можно пойти, ограничительные законы писать. Заодно можно с легкостью отыграться на этих мерзких «ботанах».
Размазывать сопли о прокуренную жилетку хабра — не вариант. А то так и будет — «жизнь заставила быть программистом», а хочется «тискать девочек во дворах» и прочее нытье. Следуйте моде: nodejs, mongodb — читать много не надо и девочкам в клубах будет что рассказать.
P.S. Заранее прощу прощения за убитое время.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
Но, проповедники налегают. В общем, комментарии выше вскрывают проблемы в полной мере, почти нечего добавить.
Если кратко, будем бороться комплексно: продуманное управление репутацией пользователя, ручной модерацией, будем давать слово бизнесу и будем учить его работать с такими отзывами.
К сожалению, это не самая тяжелая задача, которую нам предстоит решить.
- Разработчики достаточно профессиональны и хорошо мотивированы
- Есть доверие между заказчиком и исполнителем (или это работа над собственным продуктом)
тогда описанный подход может дать хороший результат с минимумом затрат на побочную деятельность.В комментариях часто прослеживаются вопросы — «а если разработчики то..., а если это...». Да, если разработчики не опытны, не понимают что и зачем они делают или не хотят сами это сделать — то да, нужно пасти. В другом случае — достаточно периодически корректировать и не мешать.