Владимир Кочергин

1) Документируй
2) Абстрагируйся всегда максимально
3) Пиши классы по принципу "черного ящика"
4) Один класс решает одну конкретную задачу, не стоит городить комбайны.

В школах и институтах учили строить алгоритмы, еще когда рисовали блок-схемы.
Это не зависит от языка программирования - нужно просто составить алгоритм для решения задачи. Изучая различные аспекты языка программирования, различные библиотеки, фреймворки и так далее вы просто приобретаете знания о дополнительных инструментах, которым нужно пользоваться для решения задачи.

Но само решение придумывает программист, а не язык программирования.

Чтобы повысить эффективность ваших практических занятий - придумайте или найдите задачи, смысл которых понятен и интересен прежде всего вам самим. Чтобы вы понимали какой результат вам нужен. Возможно вы даже измените свое мнение о результате.

Например, взять какую-нибудь игрушку с множеством товара и найти самый выгодный или дешевый товар. Вам будет понятна цель - найти нужный вам товар
При этом не будет важно в каком виде - в виде веб-странички, в виде простого текста на экран, или в виде заполненной таблички в базе данных.
При этом не будет важно какими инструментами вам нужно воспользоваться.
Главное, что вы осознаете что именно хотите получить. И пишете программу, которая выдает вам результат, используя имеющиеся знания.
Чем больше знаний, тем удобнее в конечном счете пользоваться тем что вы написали и тем быстрее и проще вам это писать.

Можно читать книги, можно все время мониторить актуальные тенденции, но общения с более опытными товарищами ничто не заменит. Если не удается устроиться в компанию с сильным IT коллективом, то хотя бы на форумах почаще спрашивать "а вот так делать правильно? " или "а этот подход еще актуален?", а не удовлетворяться тем, что код компилируется и запускается. Иначе рост во многом будет в ширину, а не глубину.
Особенно это касается вопросов, связанных не просто с написанием работающего кода, а с идеологией приложения (архитектура, ООП, масштабируемость и т д).

На сегодняшний день проблема состоит не в нехватке информации, а наоборот, в ее избытке, а отфильтровать ее не всегда хватает знаний/опыта. Курсы Евгения Попова так популярны не потому, что люди дураки, а потому, что хорошо распиарены. Или вот я осваиваю ASP.NET MVC, нашел, как мне показалось, удобную штуку - генерацию edmx, но добрые люди на metanit.ru меня просветили, что для серьезных приложений нужно использовать Code First, иначе бы до сих пор так писал.

Если полагаться только на самообразование, то есть риск получить нехилые такие пробелы в базовых вещах. Лично знаю людей, которые написали не одно приложение по работе с БД, неплохо знают SQL, умеют писать хранимые процедуры, но когда я упомянул слова "нормализация" и "3-я нормальная форма", вполне искренне меня спросили "что это?"

Стоит ли учить язык Ruby и фреймворк Ruby on Rails в 2016 году?

Зависит от ваших целей. Лично мне было просто интересно изучать этот язык и мне он нравится.

В мире PHP активно развивается много отличных фреймворков и библиотек. В JavaScript вообще каждый день революция, новые подходы и фреймворки растут как грибы после дождя.
А вот про Ruby и Ruby on Rails давно ничего не слышно.

В мире Ruby тоже есть неплохие библиотеки и фреймворки. Например, hanami (hanamirb.org) или занимательный volt (https://github.com/voltrb/volt) у которого как на клиенте, так и на сервере используется ruby код. Правда Rails довольно сильно притягивает всех своей гравитацией, к слову, в этом месяце обещали релизнуть Rails 5 с поддержкой общения с клиентом через websocket — ждём-с.

В целом, ещё Ruby используется для Chef (автоматизация серверов), homebrew (пакетный менеджер в маках), cocoapods для разработки OS X приложений, vagrant для управления виртуальными машинами разработки, jekyll/middleman/octopress — для генерации статических сайтов, известные sass/scss тоже на ruby, хоть теперь уже и есть реализации на других языках.

Ещё, сравнительно недавно вылез на стол и начал танцевать, соблазняя возможностью компиляции кода — руби-косплеер Crystal (https://github.com/crystal-lang/crystal). И есть RubyMotion — фреймворк для создания OS X/iOS/Android приложений на Ruby (www.rubymotion.com).

Тут можно посмотреть список популярных библиотек — https://github.com/markets/awesome-ruby

В общем, смотрите сами. Да, язык сейчас не на вершине волны, но он развивается и говорить о смерти пациента рано.

Работать малой командой это счастье. Когда все работают :) и есть результат.

Чтобы зарабатывать нужны заказы, чтобы были заказы нужна репутация, чтобы была репутация, нужны знания и опыт, а чтобы они появились, нужны... заказы. Замкнутый круг.

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

Далее тезисно, не в порядке приоритетов, а как вспоминается:

0) Нужна специализация у каждого и у команды (пишу как видится с учетом размера вашей команды).
* тим лидер или старший разработчик. Он будет задавать стандарты качества и контролировать работу. Будет отвечать за архитектуру.
* разработчик-верстальщик
* разработчик-админ
* разработчик-базовик
* манагер и если людей мало, он же продажник. Должен знать все CMS, что вы будете применять. Чтобы мог без запинки показать клиенту, как создавать публикацию, редактировать и проч.

1) 80% времени работать над коммерческими проектам и 20% времени работать над своим проектом. Для повышения квалификации как минимум. А если выстрелит - то скоро вообще не надо будет работать с клиентами :) Когда нет заказов - все работают над "своим" проектом, повышают квалификацию, применяют и тестируют новые технологии или новые нагрузки. Если вы грамотно придумаете для себя задачу, то процесс работы над ней и результаты можно использовать для продвижения своей команды. Допустим вы взялись за разработку модуля обмена данными бухгалтерия-магазин. Посмотрите какие есть решения уже на рынке для вашей CMS. Сделайте удобнее и лучше или быстрее или тупо лучше документированное решение. Это позволит встать в "магазин" модулей для CMS и вам даст новых клиентов. Когда у вас есть узкое и качественное решение вашему продажнику проще будет разговаривать с клиентом и влезать в уже существующие айтишные инфраструктуры. Переделать онлайн магазин вам никто уже не даст, а вот заменить модуль на ваш смогут.

2) Технология производства. Особенно, если работает несколько человек. У вас должны быть единые стандарты и технологии для написания, документирования, работы с изменениями кода, своя "библиотека" решений, которые вы могли бы использовать как можно чаще. Создавать свои чеклисты для производственных этапов и по возможности автоматизировать рутинные операции.

3) Если речь идет о вебразработке, то скорее всего надо будет отлично знать до трех из самых популярных CMS. Желательно получить сертификат/статус.

4) Стандарты работы с клиентским проектом нужны. ТЗ, документация, обучение клиента и проч. Чтобы минимизировать трудозатраты или хотя бы минимизировать неоплачиваемые трузозатраты.

5) Знать английский язык на уровне чтения документации минимум.

6) и ... потихоньку добавлять себе новые направления. Уходить от чистого веба в веб+моб, или от "сайтов" в сложный е-коммерс. Идеально, когда клиентом меньше, а доходы больше. Для этого нужны глубокие знания в относительно узком направлении и два-три клиента серьезных клиента. Не старайтесь лепить много дешевых сайтов.

Короче. Особенность и преимущество малых коллективов заключается в том, что они с одной стороны вынуждены в одном человеке концентрировать несколько ролей или областей знаний, но с другой - это обеспечит более быструю работу над проектом. Правда это хорошо, когда вы не просто коллектив, а КОМАНДА.

Это так, тезисно.

Когда-то начинали с товарищем делать сайтики, только я был "программистом", а он собирал заказы. Одни из ошибок, которые позволили загнуться нашему совместному предприятию (просуществовали мы почти 2 года) - это:
- недостаточно опытный программист (это я), плюс, если брали помощников, то они были еще неопытнее меня.
- не составлялся четкий план на разработку, проектирование проекта не проводилось, из-за чего по ходу дела возникали ситуации, которые можно было решить еще на этапе проектирования, но нет, приходилось тратить время уже во-время разработки. Как следствие этого - неожиданное увеличение сроков.
- не было четких условий для заказчика, т.е. типовой договор был, но, например стоимость правок оговаривалась налету, некоторые заказчики округляли глаза и приходилось делать забеслпатно. Следствие чего заказчик был царь и бог и некоторые их долги по оплате не были отданы до сих пор.
- желание сэкономить, нет, я понимаю, что экономить нужно, но не на том, что приносит тебе доход, по-этому дизайнеры были хреновые, помощники говеные и т.д. Из-за чего заказчик был не доволен, а срок разработки проекта очень сильно увеличивался.
- заказы по сложности и требованиям несопоставимые со стоимостью, т.е. напарник брал сложные заказы за смешные деньги, сетуя на то, что город маленький (300 000 жителей) и никто платить не хочет, в итоге с созданием и доработками выплаты задерживались, следующие заказы брались , пока недоделаны предыдущие и получался ком, которые ничего хорошего не обещал.
- ну и результатом всего этого стало огромное количество долгов и плохих отзывов.
Ну вот такие были проблемы у студии "Рога и копыта" из двух человек, какие вспомнил ))
*пы.сы. не знаю, зачем это написал, просто, что-то вспомнилось.