То, что Вы написали, никак не противоречит моему высказыванию…
За исключением терминологии.
В Agile не пишут ТЗ, а пишут функциональную спецификацию на основе сценариев использования на каждую итерацию.
А то, что Вы называете «предварительное ТЗ» — это в случае плохого ТЗ — набор блоков сайта, а в случае Agile набор т.н. пользовательских историй.
Все прелести сохраняются, но уходит вся «вода», которой практически во всех ТЗ, что я видел, было больше половины. Т.е. описывается не что нужно сделать, а как это должно работать в рамках ментальной модели пользователя.
Продуманного досконального ТЗ на крупных проектах в принципе не может быть…
В статье речь идёт о проектах из серии «написали и забыли», а когда проект разрабатывается годами, крутясь на production и реагируя на просьбы пользователей и всяческие исследования, то вам неизбежно придётся постоянно дорабатывать и переделывать 80% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.
А чем Вам так не нравится первая картинка? Вполне себе рабочий, простой магазин. Полно случаев когда нужно именно это. Достаточно идиотическая ситуация, если программист будет единолично додумывать что нужно заказчику, попутно увеличив срок реализации в несколько раз. В итоге всё кончится тем, что заказчик, увидев реализацию по второй картинке, скажет «я этого не заказывал» и будет на 100% прав.
С другой стороны не менее дурацкая ситуация имеет место когда оценку сроков и бюджета делают до утверждения макетов интерфейса.
В Ruby-проектах отношение к контрибьютерам лучше.
Хотя действительно лучше начинать с небольших тикетов из issues на github-аккаунте проекта.
Ну а если вы хотите добавить новую фичу, то либо делайте её отключаемой, либо сначала обсудите это в тех же github issues или на lighthouse или на uservoice, в зависимости от проекта.
Когда Вы без спроса и согласования пытаетесь добавить новую функциональность в чужой проект, то это конечно странно само по себе, хотя иногда может прокатить, если функциональность действительно полезная.
А что мешает получить практику? Выберите один из популярных OpenSource-проектов на Rails и сделайте туда хотя бы десяток коммитов…
Это сразу увеличит Вашу привлекательность для работодателей в разы. При том что Вам это практически ничего не стоит, если квалификация позволяет включиться в разработку существующего проекта.
> В каких целях лучше применять Sinatra вместо Ruby On Rails?
Sinatra хорошо подходит для написания веб-сервисов, когда у вас нет фронтенда в виде веб-интерфейса… Ну самый распространённый пример — флеш-игра в какой-нибудь соц.сети.
Для не слишком больших веб-приложений также имеет смысл присмотреться к Padrino.
Хотя сейчас границы применимости всё больше смешиваются, в том же RoR можно использовать и Rack-вызовы напрямую, и убрать все модули, ненужные для конкретного случая, из контроллера. Т.е. по сути в большинстве случаев это уже дело вкуса… исходя из того, что вам ближе: выпиливание или допиливание, убирать ненужные модули или искать и добавлять нужные.
P.S. Любителям легковесных контроллеров стоит присмотреться к Cells, которые с недавних пор можно использовать и для внешних вызовов.
Если бы в Sinatra добавили часто используемые фичи, то это был бы не DSL, а фреймворк…
А так есть DSL и есть куча надстроек над ним, начиная от sinatra-basic-auth и до Padrino — фреймворка поверх Sinatra.
Да дело тут даже не в том будет работать омнибар или нет, а в том что это вообще очень спорный подход для определения события «загружены все важные модули». От Google было бы логичнее ожидать более качественного решения, чем использование magick timeout, хотя бы с callback на нужном событии.
Как вариант можно проверять валидность домена, вместо того чтобы проверять его HEAD-запросом… Хотя это может обидеть любителей прописать невалидные домены в /etc/hosts для своих локальных сайтов :-)
> Так что, как ни крути, а начинающий писатель на vbscript и писатель программы рассчёта траектории полёта космического аппарата, оба они программисты.
Ну из начинающего писателя на vbscript такой же программист, как из школьника с учебником биологии — врач. Всё-таки чтобы именоваться программистом надо знать как минимум пару языков программирования и хотя бы основы в области алгоритмов и структур данных.
А почему все примеры для веб-разработки? Все ООП, да ещё и все на одних и тех же базовых паттернах. Так не интересно, по сути тут нет никакого перехода, всё в рамках одной специализации. Практического толку мало, но при этом есть серьёзная опасность начать в одном фреймворке искать что-то из другого, что грозит попаданием в патовую ситуацию «а мне всегда чего-то не хватает...» ;-)
Тут ещё надо помнить, что освоить язык — это не то же самое что освоить синтаксис. Язык можно считать освоенным только когда вы можете на нём думать. В случае с языками одной парадигмы это не особо сложно, но если меняется парадигма, то это уже смена специальности, а не специализации.
«Без проблем переключиться» — это значит придти на другое место работы и сразу работать наравне с теми, кто там работает. В данных примерах так не получится, придётся проходить практически полную переквалификацию, а потом ещё заново проходить всю иерархию, начиная с джуниора, если не со стажера.
Итого переход с должности ведущего программиста на .NET на ведущего программиста на C займёт года 3 в лучшем случае, а в худшем человек вообще не сможет программировать на новом языке на столь же высоком уровне, какой у него был на привычном языке… Кстати, всё то же самое верно и при попытке перехода в другую сторону с C на C#.
> Только не забыть, что после malloc надо вызывать free, а функциям передавать this в качестве отдельного аргумента.
Ну конечно, это ж единственные отличия… А libc и .NET — просто близнецы-братья :-)
Это всего касается… или Вы действительно считаете, что человек годами программировавший на C#, без особых усилий возьмёт и за пару месяцев перейдёт на Erlang или на Haskell или на Prolog или на C? Далеко не все языки программирования базируются на ОО-парадигме. Поэтому способность мыслить объектами легко может стать непробиваемым барьером для программирования на многих языках, если человек не сможет эту способность при необходимости полностью отключать.
> в любой сфере деятельности можно прийти к выводу, что профессия, которая занимается этой деятельностью — суперобобщение.
Так и есть. Хотя автору статьи кажется, что физик — это очень конкретная специальность, но на деле специализаций у физиков гораздо больше, чем у программистов. И точно так же представитель одной специализации не может сходу подменить представителя любой другой. Точно так же есть базовые знания, общие для всех специализаций. И точно так же при необходимости квалифицированный специалист может переквалифицироваться в другую специализацию за 1-2 года, если ему до пенсии ещё далеко ;-)
В общем иерархия практически везде примерно такая: профессия — специальность — специализация.
Ну во-первых, с помощью Cells можно делать в том числе и контроллеры недоступные через HTTP. Другими словами можно просто не подключать к ним роутинг.
А во-вторых, ограничения — это контракт для разработчиков, работающих над проектом. А то Вы с такой позицией далеко в неправильное направление рискуете уйти, ведь ничто нам не помешает вызвать метод через var.send(:method), но это отнюдь не повод отказываться от объявления приватных методов; ведь ничто не помешает сохранить невалидную модель через raw SQL(если нет валидации на уровне СУБД), но это не повод не писать валидации и т.д. и т.п.
Да, практически любое ограничение можно нарушить, а изредка даже нужно, но в целом именно следование конвенциям в рамках ограничений в конечном итоге и отличает качественный код от лапшы.
Как должен выглядеть интерфейс пользователя это не программисту решать, эта задача вне его компетенции.
> Ну, по причине, например, собственной гордости или как это назвать.
Я бы назвал эту причину раздутым самомнением.
За исключением терминологии.
В Agile не пишут ТЗ, а пишут функциональную спецификацию на основе сценариев использования на каждую итерацию.
А то, что Вы называете «предварительное ТЗ» — это в случае плохого ТЗ — набор блоков сайта, а в случае Agile набор т.н. пользовательских историй.
Все прелести сохраняются, но уходит вся «вода», которой практически во всех ТЗ, что я видел, было больше половины. Т.е. описывается не что нужно сделать, а как это должно работать в рамках ментальной модели пользователя.
В статье речь идёт о проектах из серии «написали и забыли», а когда проект разрабатывается годами, крутясь на production и реагируя на просьбы пользователей и всяческие исследования, то вам неизбежно придётся постоянно дорабатывать и переделывать 80% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.
С другой стороны не менее дурацкая ситуация имеет место когда оценку сроков и бюджета делают до утверждения макетов интерфейса.
Хотя действительно лучше начинать с небольших тикетов из issues на github-аккаунте проекта.
Ну а если вы хотите добавить новую фичу, то либо делайте её отключаемой, либо сначала обсудите это в тех же github issues или на lighthouse или на uservoice, в зависимости от проекта.
Когда Вы без спроса и согласования пытаетесь добавить новую функциональность в чужой проект, то это конечно странно само по себе, хотя иногда может прокатить, если функциональность действительно полезная.
Это сразу увеличит Вашу привлекательность для работодателей в разы. При том что Вам это практически ничего не стоит, если квалификация позволяет включиться в разработку существующего проекта.
Sinatra хорошо подходит для написания веб-сервисов, когда у вас нет фронтенда в виде веб-интерфейса… Ну самый распространённый пример — флеш-игра в какой-нибудь соц.сети.
Для не слишком больших веб-приложений также имеет смысл присмотреться к Padrino.
Хотя сейчас границы применимости всё больше смешиваются, в том же RoR можно использовать и Rack-вызовы напрямую, и убрать все модули, ненужные для конкретного случая, из контроллера. Т.е. по сути в большинстве случаев это уже дело вкуса… исходя из того, что вам ближе: выпиливание или допиливание, убирать ненужные модули или искать и добавлять нужные.
P.S. Любителям легковесных контроллеров стоит присмотреться к Cells, которые с недавних пор можно использовать и для внешних вызовов.
А так есть DSL и есть куча надстроек над ним, начиная от sinatra-basic-auth и до Padrino — фреймворка поверх Sinatra.
gedit +номер_строки имя_файла
Ну из начинающего писателя на vbscript такой же программист, как из школьника с учебником биологии — врач. Всё-таки чтобы именоваться программистом надо знать как минимум пару языков программирования и хотя бы основы в области алгоритмов и структур данных.
Итого переход с должности ведущего программиста на .NET на ведущего программиста на C займёт года 3 в лучшем случае, а в худшем человек вообще не сможет программировать на новом языке на столь же высоком уровне, какой у него был на привычном языке… Кстати, всё то же самое верно и при попытке перехода в другую сторону с C на C#.
> Только не забыть, что после malloc надо вызывать free, а функциям передавать this в качестве отдельного аргумента.
Ну конечно, это ж единственные отличия… А libc и .NET — просто близнецы-братья :-)
Так и есть. Хотя автору статьи кажется, что физик — это очень конкретная специальность, но на деле специализаций у физиков гораздо больше, чем у программистов. И точно так же представитель одной специализации не может сходу подменить представителя любой другой. Точно так же есть базовые знания, общие для всех специализаций. И точно так же при необходимости квалифицированный специалист может переквалифицироваться в другую специализацию за 1-2 года, если ему до пенсии ещё далеко ;-)
В общем иерархия практически везде примерно такая: профессия — специальность — специализация.
А во-вторых, ограничения — это контракт для разработчиков, работающих над проектом. А то Вы с такой позицией далеко в неправильное направление рискуете уйти, ведь ничто нам не помешает вызвать метод через var.send(:method), но это отнюдь не повод отказываться от объявления приватных методов; ведь ничто не помешает сохранить невалидную модель через raw SQL(если нет валидации на уровне СУБД), но это не повод не писать валидации и т.д. и т.п.
Да, практически любое ограничение можно нарушить, а изредка даже нужно, но в целом именно следование конвенциям в рамках ограничений в конечном итоге и отличает качественный код от лапшы.