На мой взгляд, у каждого успешного инструмента есть две фазы:
1) Когда пачками добавляются новые фичи, и это всем весело… именно эту фазу педалирует автор статьи.
2) Когда инструмент используется для зарабатывания денег на коммерческих проектах. На этой фазе мало кому весело от появления новых фич, изменений в API и прочем. В этой фазе превалирует девиз «новые фичи — для новых проектов», а для существующих проектов должны быть очень весомые аргументы, чтобы затевать апгрейд. К примеру, в крупном проекте менять Jammit на Asset Pipeline и переписывать весь JavaScript на CoffeeScript практически никто не будет, т.к. во-первых это не несёт существенного профита, а во-вторых ни фига не весело…
В итоге кол-во существующих крупных проектов со временем достигает критического размера и те, кто раньше активно вводил новые фичи, становятся противниками дальнейших изменений. Грубо говоря, элитарная часть сообщества успокаивается, порог допуска к принятию решений повышается, а процедура введения новых фич максимально бюрократизируется. Это относится к любому ЯП, фреймворку и т.д.
P.S. Студентам, конечно, интереснее и полезнее возиться с проектами, у которых есть шашечки… Что не отменяет изучение и проверенных временем инструментов. Практикующим программистам сложнее находить время и желание для освоения каждого нового инструмента, поэтому и возникают разрывы и пропасти на последовательности принятия инноваций.
Я вот никогда не понимал желания использовать Python или Ruby для научных расчётов. Есть же Mapple, Matlab и другие специализированные инструменты для этих целей.
В конце концов язык программирования — это лишь средство… и знание Python/Ruby — вовсе не повод пытаться заниматься научными расчётами с их помощью
Функционал — это не самоцель.
Профессиональные программисты очень принципиальны и одним из их базовых принципов является YAGNI
Когда программист реализует неоговоренный функционал по собственной прихоти — это признак дилетантства, а не профессиональной гордости. Программист может решать как делать оговоренный функционал, но не должен решать что (какой набор фич) делать.
То, что Вы написали, никак не противоречит моему высказыванию…
За исключением терминологии.
В 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 — просто близнецы-братья :-)
1) Когда пачками добавляются новые фичи, и это всем весело… именно эту фазу педалирует автор статьи.
2) Когда инструмент используется для зарабатывания денег на коммерческих проектах. На этой фазе мало кому весело от появления новых фич, изменений в API и прочем. В этой фазе превалирует девиз «новые фичи — для новых проектов», а для существующих проектов должны быть очень весомые аргументы, чтобы затевать апгрейд. К примеру, в крупном проекте менять Jammit на Asset Pipeline и переписывать весь JavaScript на CoffeeScript практически никто не будет, т.к. во-первых это не несёт существенного профита, а во-вторых ни фига не весело…
В итоге кол-во существующих крупных проектов со временем достигает критического размера и те, кто раньше активно вводил новые фичи, становятся противниками дальнейших изменений. Грубо говоря, элитарная часть сообщества успокаивается, порог допуска к принятию решений повышается, а процедура введения новых фич максимально бюрократизируется. Это относится к любому ЯП, фреймворку и т.д.
P.S. Студентам, конечно, интереснее и полезнее возиться с проектами, у которых есть шашечки… Что не отменяет изучение и проверенных временем инструментов. Практикующим программистам сложнее находить время и желание для освоения каждого нового инструмента, поэтому и возникают разрывы и пропасти на последовательности принятия инноваций.
В конце концов язык программирования — это лишь средство… и знание Python/Ruby — вовсе не повод пытаться заниматься научными расчётами с их помощью
Профессиональные программисты очень принципиальны и одним из их базовых принципов является YAGNI
Когда программист реализует неоговоренный функционал по собственной прихоти — это признак дилетантства, а не профессиональной гордости. Программист может решать как делать оговоренный функционал, но не должен решать что (какой набор фич) делать.
Как должен выглядеть интерфейс пользователя это не программисту решать, эта задача вне его компетенции.
> Ну, по причине, например, собственной гордости или как это назвать.
Я бы назвал эту причину раздутым самомнением.
За исключением терминологии.
В 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 — просто близнецы-братья :-)