Сообщение Re: Какая мотивация делать проекты на Ruby? от 03.12.2018 9:02
Изменено 03.12.2018 9:35 Ziaw
Re: Какая мотивация делать проекты на Ruby?
Здравствуйте, Shmj, Вы писали:
S>Хорошо, если ты хипстер и нравится, изменяя мир, писать скрипты на скорую руку — есть же хотя бы Python. Он все так в лидерах по популярности и найти разработчика не составляет большого труда.
Задача-то не найти разработчика, а сделать сервис, который потом можно будет поддерживать и дорабатывать.
S>Но Ruby? Зачем?
Попробую ответить, как человек, выбравший несколько лет назад, Руби и не пожалевший об этом. Рельсы наиболее зрелый (и до сих пор один из лидеров по фичам) веб-фреймворк.
Могу написать, почему его выбрал — я. Кроме, собственно решаемой бизнес задачи, при разработке ПО много усилий уходит на то, чтобы:
1. Код был хорошо структурирован и ответственности не расползались.
2. Код был тестируем.
3. Код был лаконичен и выполнялись принципы DRY.
4. Взаимодействие частей системы: БД, FTS, кеши, API, система безопасности, браузер не требовало низкоуровневого взаимодействия, но позволяло переходить на него при необходимости.
5. Решения большинства типовых задач были в библиотеках, которые легко прикручиваются и кастомизируются.
6. Соотношение кода бизнес-логики и программного "клея" для его написания и поддержки было высоким. Клей должен быть максимально отделен от самой логики.
7. Окружения — development/staging/production должны максимально хорошо выполнять свои задачи и минимально отличаться друг от друга для разработчика. Это противоречивые требования и разрешение этих противоречий это та сложность, с которой борются разработчики всех фреймворков.
Руби, как язык и рельсы, как фреймворк, дают сейчас, на мой взгляд, лучшие показатели по большинству этих пунктов.
Java/.NET завязаны на типизацию данных. Типы, которые в вебе приходится создавать практически на лету. Практически всегда приходится идти на компромисс и использовать типы данных, которые для данной операции не оптимальны и не безопасны. Например частичная загрузка данных и передача их на слой представления и обратно. Либо переходим на анонимные типы (или даже динамику) либо тонем в вагонах различных DTO, DI и тому подобных техник. Достаточно написать один раз слой взаимодействия логики со строгими типами и представления со строками, которые вводит пользователь, чтобы понять о чем я пишу. Их можно выбрать за возможность максимально обезопасить себя от случайного выстрела в ногу, но ценой будут постоянно ношение кевларовых сапог.
PHP — серьезный игрок на рынке разработки Web приложений. Но уровень самого языка, его библиотек и большинства программистов заметно ниже.
Python — отличный язык с кучей библиотек, но веб-фреймворки у него заметно хуже рельс. Типовых решений либо мало либо их сложно кастомизировать.
Javascript — уже несколько лет идет мода делать бэкенд на nodejs. Есть плюсы — можно типизировать то, что стоит типизировать и шарить код между клиентом и сервером. Можно писать для мобилок. Но есть и минусы — нестабильные и плохо совместимые друг с другом библиотеки, постоянная асинхронность, даже там, где она реально не нужна (то есть нужна для решения каких-то там сугубо архитектурных особенностей), серверные фреймворки все еще уступают рельсам. Нужно писать и поддерживать заметно больше кода.
Различные closure, elexir, elm, haskell, go, C++, rust и т.д., на мой взгляд, могут быть выбраны только из большой любви к самому языку и парадигме, которую он представляет. Сама разработка будет заметно дороже, зато программисты мотивированнее.
Я люблю статику, легкий рефакторинг и некоторое автоматическое доказательство корректности кода. Но бизнес требует приложения, которые меняются на каждый чих. Новое законодательство, новые процессы, не учтенные требования, запросы от маркетологов и пользователей. Все это плохо совместимо с архитектурой, которую можно продумать на этапе проектирования с учетом известных требований. Архитектура приложений должна обеспечивать дешевые и безопасные изменений, после поддержку кодовой базы и динамика, при всех ее минусах, здесь проявляет свои сильные стороны.
Кто-то скажет, что проблема в неумении правильно собирать и анализировать требования, я отвечу, что сбор требований со всех необходимых источников может быть дольше и дороже чем создание приложения на динамике и его корректировка с учетом опытной эксплуатации.
Так или иначе каждый волен сам выбрать свой путь в отрасли, благо инструментов сейчас масса.
S>Хорошо, если ты хипстер и нравится, изменяя мир, писать скрипты на скорую руку — есть же хотя бы Python. Он все так в лидерах по популярности и найти разработчика не составляет большого труда.
Задача-то не найти разработчика, а сделать сервис, который потом можно будет поддерживать и дорабатывать.
S>Но Ruby? Зачем?
Попробую ответить, как человек, выбравший несколько лет назад, Руби и не пожалевший об этом. Рельсы наиболее зрелый (и до сих пор один из лидеров по фичам) веб-фреймворк.
Могу написать, почему его выбрал — я. Кроме, собственно решаемой бизнес задачи, при разработке ПО много усилий уходит на то, чтобы:
1. Код был хорошо структурирован и ответственности не расползались.
2. Код был тестируем.
3. Код был лаконичен и выполнялись принципы DRY.
4. Взаимодействие частей системы: БД, FTS, кеши, API, система безопасности, браузер не требовало низкоуровневого взаимодействия, но позволяло переходить на него при необходимости.
5. Решения большинства типовых задач были в библиотеках, которые легко прикручиваются и кастомизируются.
6. Соотношение кода бизнес-логики и программного "клея" для его написания и поддержки было высоким. Клей должен быть максимально отделен от самой логики.
7. Окружения — development/staging/production должны максимально хорошо выполнять свои задачи и минимально отличаться друг от друга для разработчика. Это противоречивые требования и разрешение этих противоречий это та сложность, с которой борются разработчики всех фреймворков.
Руби, как язык и рельсы, как фреймворк, дают сейчас, на мой взгляд, лучшие показатели по большинству этих пунктов.
Java/.NET завязаны на типизацию данных. Типы, которые в вебе приходится создавать практически на лету. Практически всегда приходится идти на компромисс и использовать типы данных, которые для данной операции не оптимальны и не безопасны. Например частичная загрузка данных и передача их на слой представления и обратно. Либо переходим на анонимные типы (или даже динамику) либо тонем в вагонах различных DTO, DI и тому подобных техник. Достаточно написать один раз слой взаимодействия логики со строгими типами и представления со строками, которые вводит пользователь, чтобы понять о чем я пишу. Их можно выбрать за возможность максимально обезопасить себя от случайного выстрела в ногу, но ценой будут постоянно ношение кевларовых сапог.
PHP — серьезный игрок на рынке разработки Web приложений. Но уровень самого языка, его библиотек и большинства программистов заметно ниже.
Python — отличный язык с кучей библиотек, но веб-фреймворки у него заметно хуже рельс. Типовых решений либо мало либо их сложно кастомизировать.
Javascript — уже несколько лет идет мода делать бэкенд на nodejs. Есть плюсы — можно типизировать то, что стоит типизировать и шарить код между клиентом и сервером. Можно писать для мобилок. Но есть и минусы — нестабильные и плохо совместимые друг с другом библиотеки, постоянная асинхронность, даже там, где она реально не нужна (то есть нужна для решения каких-то там сугубо архитектурных особенностей), серверные фреймворки все еще уступают рельсам. Нужно писать и поддерживать заметно больше кода.
Различные closure, elexir, elm, haskell, go, C++, rust и т.д., на мой взгляд, могут быть выбраны только из большой любви к самому языку и парадигме, которую он представляет. Сама разработка будет заметно дороже, зато программисты мотивированнее.
Я люблю статику, легкий рефакторинг и некоторое автоматическое доказательство корректности кода. Но бизнес требует приложения, которые меняются на каждый чих. Новое законодательство, новые процессы, не учтенные требования, запросы от маркетологов и пользователей. Все это плохо совместимо с архитектурой, которую можно продумать на этапе проектирования с учетом известных требований. Архитектура приложений должна обеспечивать дешевые и безопасные изменений, после поддержку кодовой базы и динамика, при всех ее минусах, здесь проявляет свои сильные стороны.
Кто-то скажет, что проблема в неумении правильно собирать и анализировать требования, я отвечу, что сбор требований со всех необходимых источников может быть дольше и дороже чем создание приложения на динамике и его корректировка с учетом опытной эксплуатации.
Так или иначе каждый волен сам выбрать свой путь в отрасли, благо инструментов сейчас масса.
Re: Какая мотивация делать проекты на Ruby?
Здравствуйте, Shmj, Вы писали:
S>Хорошо, если ты хипстер и нравится, изменяя мир, писать скрипты на скорую руку — есть же хотя бы Python. Он все так в лидерах по популярности и найти разработчика не составляет большого труда.
Задача-то не найти разработчика, а сделать сервис, который потом можно будет поддерживать и дорабатывать.
S>Но Ruby? Зачем?
Попробую ответить, как человек, выбравший несколько лет назад, Руби и не пожалевший об этом. Рельсы наиболее зрелый (и до сих пор один из лидеров по фичам) веб-фреймворк.
Могу написать, почему его выбрал я. Кроме, собственно решаемой бизнес задачи, при разработке ПО много усилий уходит на то, чтобы:
1. Код был хорошо структурирован и ответственности не расползались.
2. Код был тестируем.
3. Код был лаконичен и выполнялись принципы DRY.
4. Взаимодействие частей системы: БД, FTS, кеши, API, система безопасности, браузер не требовало низкоуровневого взаимодействия, но позволяло переходить на него при необходимости.
5. Решения большинства типовых задач были в библиотеках, которые легко прикручиваются и кастомизируются.
6. Соотношение кода бизнес-логики и программного "клея" для его написания и поддержки было высоким. Клей должен быть максимально отделен от самой логики.
7. Окружения — development/staging/production должны максимально хорошо выполнять свои задачи и минимально отличаться друг от друга для разработчика. Это противоречивые требования и разрешение этих противоречий это та сложность, с которой борются разработчики всех фреймворков.
Руби, как язык и рельсы, как фреймворк, дают сейчас, на мой взгляд, лучшие показатели по большинству этих пунктов.
Java/.NET завязаны на типизацию данных. Типы, которые в вебе приходится создавать практически на лету. Практически всегда приходится идти на компромисс и использовать типы данных, которые для данной операции не оптимальны и не безопасны. Например частичная загрузка данных и передача их на слой представления и обратно. Либо переходим на анонимные типы (или даже динамику) либо тонем в вагонах различных DTO, DI и тому подобных техник. Достаточно написать один раз слой взаимодействия логики со строгими типами и представления со строками, которые вводит пользователь, чтобы понять о чем я пишу. Их можно выбрать за возможность максимально обезопасить себя от случайного выстрела в ногу, но ценой будут постоянное ношение кевларовых сапог.
PHP — серьезный игрок на рынке разработки Web приложений. Но уровень самого языка, его библиотек и большинства программистов заметно ниже.
Python — отличный язык с кучей библиотек, но веб-фреймворки у него заметно хуже рельс. Типовых решений либо мало либо их сложно кастомизировать.
Javascript — уже несколько лет идет мода делать бэкенд на nodejs. Есть плюсы — можно типизировать то, что стоит типизировать и шарить код между клиентом и сервером. Можно писать для мобилок. Но есть и минусы — нестабильные и плохо совместимые друг с другом библиотеки, постоянная асинхронность, даже там, где она реально не нужна (то есть нужна для решения каких-то там сугубо архитектурных особенностей), серверные фреймворки все еще уступают рельсам. Нужно писать и поддерживать заметно больше кода.
Различные closure, elexir, elm, haskell, go, C++, rust и т.д., на мой взгляд, могут быть выбраны только из большой любви к самому языку и парадигме, которую он представляет. Сама разработка будет заметно дороже, зато программисты мотивированнее.
Я люблю статику, легкий рефакторинг и некоторое автоматическое доказательство корректности кода. Но бизнес требует приложения, которые меняются на каждый чих. Новое законодательство, новые процессы, не учтенные требования, запросы от маркетологов и пользователей. Все это плохо совместимо с архитектурой, которую можно продумать на этапе проектирования с учетом известных требований. Архитектура приложений должна обеспечивать дешевые и безопасные изменения и последующую поддержку кодовой базы. И динамика, при всех ее минусах, здесь проявляет свои сильные стороны.
Кто-то скажет, что проблема в неумении правильно собирать и анализировать требования, я отвечу, что сбор требований со всех необходимых источников может быть дольше и дороже чем создание приложения на динамике и его корректировка с учетом опытной эксплуатации.
Так или иначе каждый волен сам выбрать свой путь в отрасли, благо инструментов сейчас масса.
S>Хорошо, если ты хипстер и нравится, изменяя мир, писать скрипты на скорую руку — есть же хотя бы Python. Он все так в лидерах по популярности и найти разработчика не составляет большого труда.
Задача-то не найти разработчика, а сделать сервис, который потом можно будет поддерживать и дорабатывать.
S>Но Ruby? Зачем?
Попробую ответить, как человек, выбравший несколько лет назад, Руби и не пожалевший об этом. Рельсы наиболее зрелый (и до сих пор один из лидеров по фичам) веб-фреймворк.
Могу написать, почему его выбрал я. Кроме, собственно решаемой бизнес задачи, при разработке ПО много усилий уходит на то, чтобы:
1. Код был хорошо структурирован и ответственности не расползались.
2. Код был тестируем.
3. Код был лаконичен и выполнялись принципы DRY.
4. Взаимодействие частей системы: БД, FTS, кеши, API, система безопасности, браузер не требовало низкоуровневого взаимодействия, но позволяло переходить на него при необходимости.
5. Решения большинства типовых задач были в библиотеках, которые легко прикручиваются и кастомизируются.
6. Соотношение кода бизнес-логики и программного "клея" для его написания и поддержки было высоким. Клей должен быть максимально отделен от самой логики.
7. Окружения — development/staging/production должны максимально хорошо выполнять свои задачи и минимально отличаться друг от друга для разработчика. Это противоречивые требования и разрешение этих противоречий это та сложность, с которой борются разработчики всех фреймворков.
Руби, как язык и рельсы, как фреймворк, дают сейчас, на мой взгляд, лучшие показатели по большинству этих пунктов.
Java/.NET завязаны на типизацию данных. Типы, которые в вебе приходится создавать практически на лету. Практически всегда приходится идти на компромисс и использовать типы данных, которые для данной операции не оптимальны и не безопасны. Например частичная загрузка данных и передача их на слой представления и обратно. Либо переходим на анонимные типы (или даже динамику) либо тонем в вагонах различных DTO, DI и тому подобных техник. Достаточно написать один раз слой взаимодействия логики со строгими типами и представления со строками, которые вводит пользователь, чтобы понять о чем я пишу. Их можно выбрать за возможность максимально обезопасить себя от случайного выстрела в ногу, но ценой будут постоянное ношение кевларовых сапог.
PHP — серьезный игрок на рынке разработки Web приложений. Но уровень самого языка, его библиотек и большинства программистов заметно ниже.
Python — отличный язык с кучей библиотек, но веб-фреймворки у него заметно хуже рельс. Типовых решений либо мало либо их сложно кастомизировать.
Javascript — уже несколько лет идет мода делать бэкенд на nodejs. Есть плюсы — можно типизировать то, что стоит типизировать и шарить код между клиентом и сервером. Можно писать для мобилок. Но есть и минусы — нестабильные и плохо совместимые друг с другом библиотеки, постоянная асинхронность, даже там, где она реально не нужна (то есть нужна для решения каких-то там сугубо архитектурных особенностей), серверные фреймворки все еще уступают рельсам. Нужно писать и поддерживать заметно больше кода.
Различные closure, elexir, elm, haskell, go, C++, rust и т.д., на мой взгляд, могут быть выбраны только из большой любви к самому языку и парадигме, которую он представляет. Сама разработка будет заметно дороже, зато программисты мотивированнее.
Я люблю статику, легкий рефакторинг и некоторое автоматическое доказательство корректности кода. Но бизнес требует приложения, которые меняются на каждый чих. Новое законодательство, новые процессы, не учтенные требования, запросы от маркетологов и пользователей. Все это плохо совместимо с архитектурой, которую можно продумать на этапе проектирования с учетом известных требований. Архитектура приложений должна обеспечивать дешевые и безопасные изменения и последующую поддержку кодовой базы. И динамика, при всех ее минусах, здесь проявляет свои сильные стороны.
Кто-то скажет, что проблема в неумении правильно собирать и анализировать требования, я отвечу, что сбор требований со всех необходимых источников может быть дольше и дороже чем создание приложения на динамике и его корректировка с учетом опытной эксплуатации.
Так или иначе каждый волен сам выбрать свой путь в отрасли, благо инструментов сейчас масса.