Разное

пишет ли softtime только о php или возможно будут книги о других языках, например, ruby. Интересно было бы почитать в вашем исполнении...

Лучше бы о Python

Книг о python на русском языке хватает, а о ruby книг мало и они старые.

Какие книги? Форум еле дышит. Форум и книги вроде бы свою роль уже выполнили. К тому же писались книги не одним автором. После ухода МВ Игорь, скорее всего, в одиночку писать ничего не будет...

PS хотя статьи о том, как установить Python+Сервер+Mysql или Ruby+Сервер+Mysql на компьютер Macintosh не помешали бы. Я их не нашел даже на английском.

>После ухода МВ Игорь, скорее всего, в одиночку писать ничего не будет...

что больше некого взять в соавторы? да и многие книги пишутся одним автором

МВ заменить очень сложно. Я бы сам рад книги от них что-нибудь почитать. Недавно их самоучитель php в электронном виде купил и перечитал.

Антон, книга берет где-то пол года, заработать на ней можно ну скажем 3000$ при хорошем раскладе... Раньше время на это было, сейчас уже нет. Книгу написать бы я мог и по Ruby или по Rails в том числе, на котором сейчас программирую 90% времени. Просто при текущем временном раскладе писать её буду года 4, точнее постоянно переписывать (а это неизбежные ошибки), так как в ruby и рельсах сейчас изменения как PHP разлива 2004 года. Если скажем так, у меня не будет над чем работать и не будет проектов и постоянного цейтнота, да возможно что-то напишу. КМВ позволял мне много возиться с форумом и писать книги, хотя последние годы часто высказывал, что нужно больше обращать внимания на дела, а не на форум, который прибыли не приносит. Теперь вот приходится так и поступать.

Про установку Ruby я начинал писать статью, к сожалению, не закончил http://softtime.info/view/Ruby. На маке у вас должен стоять Ruby 2.0.0. наберите ruby -v. Лучше конечно ставить через rvm (http://rvm.io) - профессионалы работают через него. С сервером вроде Apache интеграции как правило нет (есть passenger, но не советую), используется сервер написанный на ruby (unicorn, thin - это гемы (библиотеки), управление которыми через rubygems и команду bundle) для отдачи динамики, поверх которого используется nginx для отдачи статики. Кэш ложат в memcached или лучше в redis, получается довольно быстро. На самом деле инструкцию по развертыванию этого добра я писал не раз, руки не доходят оформить в виде статьи. Идеально, конечно и самоучитель написать, но это потребует времени (а тут опять все поменялось, рельсы 4 вышли, ruby - 2.1.0).

т.е. среда разработки ruby и php среды могут быть полностью разделены на маке и на пк? А что же с базой данных?

Да, вполне. Правда если пользоваться фремворком Ruby on Rails то пользоваться произвольной базой данных будет не очень удобно, хотя возможно. В рельсах вообще все трудно, что не укладывается в так называемый Rails Way. Т.е. плевать против ветра бывает очень и очень накладно. Впрочем так можно сказать практически о любом фреймворке.

>если пользоваться фремворком Ruby on Rails то пользоваться произвольной базой данных будет не очень удобно

А что там за база?

Какую захотите, я MySql использую, рельсовики любят PostgreeSQL, a вообще можно использовать любую дазу данных.

А чем Ruby лучше php? В Ruby есть gdlib?

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

Ruby (хорошее, лучше, чем в PHP):
- поддерживает utf-8 нативно на уровне ядра;
- полностью объектно-ориентированный и это хороший ООП, с перегрузкой операторов, хотя местами не без странностей (язык полностью объектно-ориентированный, все есть объект, как Smalltalk).
- исключительная поддержка обработки списков, часто называют современным LISP и это действительно так, не для красного словца. Например, ruby-сты почти никогда не пользуются операторами цикла, но в то же время не прибегают к рекурсии, как многие функциональные языки - поищите такое среди других языков...
- сообщество более компактное и сосредоточено на единых целях, например, фреймворков всего несколько и 95% сообщества заняты Ruby on Rails, который летает, плавает, стреляет. В PHP фреймворков миллион и небольшие группы заняты каждый своим фреймворком, иногда с гордостью заявляя, что они реализовали миграции как в RoR... RoR - это очень изящная и продуманная штука, действительно интересная.
- Ruby изящнее PHP, на мой конечно, субъективный взгляд. Хотя вы сами про вакханалию в синтаксисе PHP думаю в курсе :)

>В Ruby есть gdlib?
Можно поискать, хотя я сам использую ImageMagic. На самом деле в Ruby огромное количество гемов, которые вы включаете в Gemfile и они автоматически подтягиваются к вам в проект будь то на машине разработке или на продакшен-сервере. Если вы когда-нибудь пользовались PEAR - это бледное подобие гемов Ruby. А вот если пользовались пакетами ubuntu - это очень похоже - также бронебойно, надежно и здорово (только в гемах у вас более гибкое управление версиями).

А хостинг? Можно найти хостинг на ruby за 2500 в год? Эту сумму мы и наши заказчики платят за хостинг php/mysql, если это маленький или средний проект.

Хостинг для RoR - это фактически голая VDS, куда вы разворачиваете проект (нет проблем с любым нужным ПО, ставите, что вам нужно, но есть проблемы с его настройкой, резервированием и почтой, впрочем существуют хостинги в районе 7$ в месяц, где уже все сделано, но уже за рубежом, в РФ ruby-хостинг не очень распространен). Порог входа, количество телодвижений и необходимый багаж знаний при работе в Web на Ruby, выше, чем на PHP - это наверное следует отнести к недостаткам. Развернув Ruby проект хотя бы один раз, вы убедитесь, что хостинг вам в общем уже не нужен - вы можете делать все тоже самое что они, максимум, что вам может потребоваться - облачный хостинг, все-таки самому OpenStack ковырять требует много времени и усилий (по крайней мере мне).

КМВ позволял мне много возиться с форумом и писать книги

А ведь хорошее было время! Приятно впомнить...

Я тогда свой день начинал с Вашего сайта. И потом заходил раз двадцать.

Ага, интересно было...

Я тогда свой день начинал с Вашего сайта. И потом заходил раз двадцать.

У меня также было.

Игорь, а сколько времени примерно потребовала бы для написания с нуля книга типа Практики создания сайтов?

Первое издание - 4 месяца, перед ней был написан Самоучитель 5, другая объемная книга MySQL 5 тоже не была написана с нуля. Т.е. мы уже были тренированы, у нас частично был материал для этой книги. С нуля 1000 страничную книгу никому не советую писать. Лучше перед этим написать 400-500 страничную книгу похожей тематики. Ну и вообще вот так с места в карьер тоже лучше не пускаться, блог, форум на протяжении года или двух, т.е. размеренная тренировка, как и в любом другом деле. Сейчас бы уже такую книгу писал бы дольше, хотя если бы, бы у меня 90% времени уходило на книгу, как тогда, может и уложился бы в 4 месяца - но 90% полностью на книгу - это для меня сейчас фантастика, плюс, писал бы скорее всего один, плюс уже вряд ли буду до 5 утра засиживаться над текстами, как бывало - после 20 книг процесс уже не так захватывает, как раньше. В общем 4 месяца на 1000 страничную книгу уже вряд ли бы стал отводить, хотя это возможно, и возможно для любого из тех, кто читает форум - ничего там фантастично сложного нет. Более того, чем короче цикл разработки книги, тем она получается более целостная по стилю.

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

Cheops, а что если попробовать скинуться всем по типу краудфандинга на написание книги? Я думаю могли бы неплохую сумму собрать. Для начала хотя бы на какую-нибудь небольшую книгу, да вон даже по тому же PHP с учётом всех нововведений и его промышленному применению.
Хотя естественно очень бы хотелось увидеть книгу по RoR, причём с активным форумом...

Может будет быстрее скинуться на переводчика с английского, чтоб он перевёл уже написанную книгу про ruby? Нужно спрашивать разрешение у издательства и автора, не знаю.

Книги уже переведены другими... сообщества нет. Когда начинал, тоже сталкивался с этим - нет места скопления российских ruby-разработчиков. Если что-то ищешь - нужно сразу искать на английском, и спрашивать на английском. В общем происходит то, что должно было происходить. Я себя начинаю ловить на том, что книг на английском читаю больше, чем на русском.

Время не всегда можно обменять на деньги. Если проект начат, он должен быть завершен. Из плохого, у меня на ближайший год все расписано. Из хорошего, я вынужден сейчас писать очень много тех.документации причем для людей в глаза не видевших RoR. Возможно со временем удастся её оформить в виде книги.

а самое страшное, они не помнят с какими сложностями сталкиваются новички и не могут эти сложности адекватно осветить.

Когда я впервые соприкоснулся с РНР (на этом сайте), то даже постеснялся задать свой вопрос на самом форуме и написал одному из форумчан в личку. Вопрос касался того, сложно ли сделать запись в файл. И получил такой ответ: "Да вопщем то не очень сложно" (и код).

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

Супруга смеется: отдай его в типографию - вот и будет книга для новичков!

>Супруга смеется: отдай его в типографию - вот и будет книга для новичков!
Кстати, да, это была бы отличная книга, там онтология всех страхов и причин. Когда начинаешь, они очень велики, вплоть до того, что не пользуешься каким-нибудь оператором несколько лет из-за того, что не получилось в первый раз, а задачу нужно было решить и она была решена каким-то вычурным и хитрым способом. Об этом в книгах не пишут, но все с этим сталкиваются.

Я Вас еще больше рассмешу, приведя тормозивший меня пример из Вашего Самоучиталя (это есть практически во всех других книгах).

Функция strpos Эта функция возвращает позицию в строке, с которой начинается переданная ей подстрока.

Но ведь возвратить можно только то, что взял!
Взял велосипед покататься - его и вернул.
Взял зонтик от дождя - верни зонтик.
Нельзя взять зонт, а вернуть сигареты!

А если отдаешь одно, а получаешь другое, то это не возвращение.

К примеру, человек отдает свой труд, а получает зарплату.
Представляете, если бы над кассой была надпись:
"Возврат зарплаты с 10:00 да 15:00".

Сейчас, конечно, то давнее кажется смешным...

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

Сам по себе ruby не так часто используется как фреймворки на его основе. В частности Ruby On Rails. Cам переехал на него год-полтора назад. Изучал с нуля.

Этапы были такие

1. Книга "Rails 4. Гибкая разработка веб-приложений" http://www.ozon.ru/context/detail/id/26011201/ - cобственно с неё всё и началось. Во время очередной прогулки по книжному увидел её на полке и тут же накатило желание изучить что-то новое, так как от php к тому времени уже воротило :)

Книга весьма неоднозначная (ощущается сумбур в изложении, когда первую половину мы пишем интернет-магазин, а вторую нам объясняют что мы только что делали). Но лучше на русском нет.

Главное на этом этапе - не плюнуть на это дело из-за специфического (на вкус php программиста) синтаксиса руби :) Я лично где-то с третьего раза заставил себя всё-таки разобраться с ним. Сейчас всё кажется удобным и логичным.

2. Очень помогли курсы https://www.codeschool.com/paths/ruby. Но тут надо знать английский и денег немного заплатить :) Но сам факт оплаты очень дисциплинирует и за месяц (29$) вполне можно пройти весь путь.

3. Стартуем учебный проект. Просто

rails new myapp rails -s

и вперёд.

В процессе просто незаменим сайт http://rusrails.ru/ - перевод документации.

Главное с порога понять т.н. rails way - нет велосипедостроению. На всё есть готовые бандлы. Добрая половина кода генерируется сама командами из консоли.

Многие задачи могут быть решены вообще без программирования. Например полноценную админку можно развернуть одной командой

rails generate active_admin:install

Ну утрирую немного, скорее всего придётся ещё некоторую конфигурацию моделей сделать. Но в любом случае процесс генерации админа для обычного контентного сайта занимает не более получаса.

4. Процесс разработки rails приложения на локалхосте прост и приятен, так как есть встроенный сервер, который запускается одной командой.

А вот далее начинается лёгкий ад. Процесс деплоя приложения на боевой сервер весьма запутан. Особенно в плане выбора веб сервера (unicorn или passenger). Дело в том, что обычные виртуальные хостинги не предоставляют готового rails окружения. Поэтому есть два пути - настройка своего VPS либо облако (Heroku, например). Первый путь сожрёт время но сэкономит деньги, второй - наоборот.

Но есть и хорошая новость. Процесс деплоя приложения на VPS крайне подробно и хорошо расписан в этой статье: http://habrahabr.ru/post/213269/

Если деньги не проблема, то читайте эту статью про хероку: http://habrahabr.ru/post/232679/

Тут главное - не бояться. Просто настройтесь на пару часов вдумчивой работы с консолью и это окупится сторицей впоследствии. У меня теперь процесс обновления сайта выполняется одной командой "cap production deploy". Делаются комиты, push в github откуда код попадает на боевой сервер где создаётся новый snapshot (слепок) приложения. Настраиваются необходимые линки, подтягиваются медиа файлы с локалхоста (по необходимости), осуществляется миграция структуры базы, объединяются js и css файлы, с помощью модуля pagespeed автоматически переводятся в base64 картинки и т.д.

Если что-то пошло не так, то просто "cap production rollback" и всё откатилось к предыдущей версии.

Кстати, если вы работает с unix стеком, то странно на рабочей машине использовать windows. Переезжайте на linux и разные костыли уже не понадобятся.

5. Профит. Недавняя разработка прототипа довольно сложного сервиса заняла в районе 20 часов работы. На той же symfony я за это время кое-как с доктриной успевал разобраться да пару форм написать.

В общем, Rails - это, конечно, не серебряная пуля. Очень большой проект я по-прежнему пилю на symfony, так как он лучше заточен под огромные вещи. Но средние проекты и прототипы я теперь пишу только на рельсах. Чего и вам желаю :)

Если у кого есть конкретные вопросы по технологии, то задавайте - помогу чем смогу.

спасибо за информацию

>Очень большой проект я по-прежнему пилю на symfony, так как он лучше заточен под огромные вещи. Но
>средние проекты и прототипы я теперь пишу только на рельсах.
На рельсах написаны многие крупные проекты, просто на PHP у вас наверное опыт больше.

PS Сегодня завершил описание развертывания одного портала (3 сервера + git-сервер + деплой; 4 рельсы + 3 капистрано): 40 страниц. На самом деле это особенность крупных порталов, тот же деплой из под ant или puppet он ведь тоже не проще... а когда у вас десятки или не дай бог сотни серверов - вы обычным копированием не обойдетесь. Собственно деплой - это и есть признак средних и крупных проектов.

>> На рельсах написаны многие крупные проекты, просто на PHP у вас наверное опыт больше

Скорее были написаны :) Как раз потому что быстро по времени, а деньги на кучу серверов не проблема в условиях западных стартапов.

Тот же twitter когда стал реально популярным был переписан. На scala вроде.
Насчёт гитхаба не уверен, но тоже вроде бы там от рельсов мало что осталось.
Basecamp вроде держится пока на ROR, но скорее всего из-за того, что там собственно автор рельсов и заправляет.
Ну и т.д. Как только проект становится очень большим - рельсы становятся неоправданно дорогими в плане накладных расходов. И если тот же php можно разогнать используя костыли типа HHVM, то для ruby ничего такого нет, насколько я знаю.

Ну и плюс сама архитектура фреймворка не сильно располагает к разработке крупных проектов. Например актив рекордс сильно проигрывает в плане гибкости той же доктрине. Глобальная MVC архитектура не всегда удобна - трудно без создания своего гема "окуклить" сущности в рамках логического раздела (см. бандлы в symfony). Без танцев с бубном трудно настроить работу с более чем одной базой данных, не говоря уж о том, чтобы одновременно работать с реляционной и nosql (mongodb я так и не понял как подружить с mysql в рамках одного проекта). Ну и т.д.

>> Сегодня завершил описание развертывания одного портала (3 сервера + git-сервер + деплой; 4 рельсы + 3 капистрано): 40 страниц.

Ну у вас там наверное куча автоматических тестов и создания тестовых песочниц под каждый билд?

Про трудности деплоя я писал в сравнении с лёгкостью этого дела в PHP. На начальном этапе. Купил хостинг - по ftp или rsyncом по ssh копируешь файлы в public_html в и всё работает. А в рельсах без хороших знаний линукса просто не обойдёшься. Тут просто копировать не получится. Даже на "hello world" проекте :)

В рельсах порог входа сильно повыше будет.

Со всем согласен :)

кроме "Без танцев с бубном трудно настроить работу с более чем одной базой данных"
Есть гем octopus - по-моему отлично справляется, недавно строил сервис по слиянию 4-х реплик баз данных в одну - только со sphinx-ом возникли проблемы, решились одной строчкой кода.

>Ну у вас там наверное куча автоматических тестов и создания тестовых песочниц под каждый билд?
Есть такое дело

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

>> Есть гем octopus - по-моему отлично справляется, недавно строил сервис по слиянию 4-х реплик баз данных в одну

Спасибо, действительно удобно делать шардинг реляционных баз.

А mongo туда можно воткнуть? Встречались с такой задачей?

С mongo почти не работал, мне их свободный подход к проектированию схемы не очень нравится. Заранее оговорюсь есть такие задачи и проекты, особенно актуально для старапов, но отказ от жесткой схемы мне кажется выстрелом в ногу - рано или поздно это аукнется, рано или поздно придется выплачивать этот технологический долг, когда связи не в схеме, а в приложении, а еще хуже в голове разработчика.

А какую nosql базу предпочитаете тогда?

>> мне их свободный подход к проектированию схемы не очень нравится.

Вообще mongo используется для хранения готовых объектов, для которых какая-то жёсткая структура не сильно то и нужна. Особенно хорошо получается хранить какие-то нечёткие структуры данных, в которых количество полей может сильно варьироваться и поэтому классическая реляционная таблица получается сильно раздута.

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

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

Удалить, создал вместо этого ответа отдельную тему Старожилы форума.

>А какую nosql базу предпочитаете тогда?
redis

Mongo позволяет с легкостью хранить любые объекты, в том числе старого формата, отличающегося от нового и на плечи приложения ложиться определение, что перед ним, старый или новый формат. В СУБД такой номер, как правило, не прокатывает и требуется работа по конвертации в новый формат.

Redis же это вроде бы банальное key/value хранилище типа мемкеша. Нет?

>> и на плечи приложения ложиться определение, что перед ним, старый или новый формат
>> и требуется работа по конвертации в новый формат.

Получается, что какой-то адаптер писать придётся в обоих случаях?

Ага, только похитрее, поддерживает коллекции (плюс по сравнению с memcached поддерживает репликацию и сохранение на диск с последующим считыванием при старте, а может не работать с диском). Фактически да, это только для кэша, возможно чуть более интеллектуального.

>Получается, что какой-то адаптер писать придётся в обоих случаях?
Ага, но мне кажется в моем случае не удастся сделать вид, что проблемы не существует... хотя многим пожалуй это удается.