Перейти к содержимому


Ads
Фотография
  • Авторизуйтесь для ответа в теме
Сообщений в теме: 24

#1 _Mr.Cherry_

_Mr.Cherry_

    Небожитель

  • Небожитель
  • PipPipPipPipPip
  • 6 743 сообщений

Отправлено 22.12.2013, 12:57

Требуется Ruby On Rails разработчик на крупный долгосрочный проект на полную занятость. Возможно участие в различных проектах.

Пока удалёнкой из дома. Офис будет в январе-феврале.

 

Требуется:

  • Ruby 2 — будет надобность и на руби без рельс кодить.
  • Ruby On Rails 3/4 — пока проект на третьих рельсах, позже будет переводится на четвёртые. Новые проекты тоже на четвёртых будут.
  • MySQL 5 - хранимые процедуры, триггеры, эвенты, разные движки и т.п.
  • HTML5, CSS3, JavaScript (чистый и jQuery) - грамотная современная кроссбраузерная вёрстка. Необходимо также знать чистый JavaScript.
  • SCSS, HAML, CoffeeScript - синтаксический сахар, весь проект на этом.
  • GIT - желательно уметь обращаться с разными ветками, знать про git cherry-pick и т.п.
  • SSH - умение зайти удалённо на сервер Debian Linux, перезагрузить различные сервисы, установить доп. ПО и т.п.

Оклад:

30-50 т.р. в месяц, в зависимости от уровня.

 

 

Альтернативный вариант:

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

 

Требования к разработчикам на переобучение:

  • PHP / Python / другие — знание любого современного языка для веб-разработки.
  • MVC-фреймворки — знание, понимание, опыт работы с MVC-фреймворками(Yii, Kohana, Django и т.д.)
  • MySQL 5 или другая СУБД - хранимые процедуры, триггеры, эвенты, разные движки и т.п.
  • HTML5, CSS3, JavaScript (чистый и jQuery) - грамотная современная кроссбраузерная вёрстка. Необходимо также знать чистый JavaScript.
  • GIT - желательно уметь обращаться с разными ветками, знать про git cherry-pick и т.п.
  • SSH - умение зайти удалённо на сервер Debian Linux, перезагрузить различные сервисы, установить доп. ПО и т.п.

 

Свои резюме присылать на cherashev.f@gmail.com.


Сообщение отредактировал _Mr.Cherry_: 22.12.2013, 12:58


#2 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 635 сообщений

Отправлено 05.01.2014, 16:47

Знаю Java (Java SE в области JDBC, Swing; немного Java EE в области JSP/Servlets и JSF), HTML4/CSS2, Mercurial, SSH. Сколько продлится переобучение на RoR?
Пройдя огонь, воду и медные трубы, становится как-то всё ни жарко, ни холодно и по барабану.

#3 _Mr.Cherry_

_Mr.Cherry_

    Небожитель

  • Небожитель
  • PipPipPipPipPip
  • 6 743 сообщений

Отправлено 09.01.2014, 11:12

Знаю Java (Java SE в области JDBC, Swing; немного Java EE в области JSP/Servlets и JSF), HTML4/CSS2, Mercurial, SSH. Сколько продлится переобучение на RoR?

 

Подозреваю, что долго будет переобучать.
Вопросы:
1) Какое кол-во опыта в серверной разработке на Java? Есть ли опыт работы с паттернами MVC и ActiveRecord?
2) Что по поводу работы с БД? Есть ли опыт продвинутой работы с MySQL или другими СУБД?
3) Судя по написанному HTML4/CSS2 - опыта в html-вёрстке маловато. Я прав?
4) Что по поводу JavaScript? jQuery?


#4 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 635 сообщений

Отправлено 09.01.2014, 13:35

Подозреваю, что долго будет переобучать.
Вопросы:
1) Какое кол-во опыта в серверной разработке на Java? Есть ли опыт работы с паттернами MVC и ActiveRecord?
2) Что по поводу работы с БД? Есть ли опыт продвинутой работы с MySQL или другими СУБД?
3) Судя по написанному HTML4/CSS2 - опыта в html-вёрстке маловато. Я прав?
4) Что по поводу JavaScript? jQuery?


1) В человеко-часах, потраченных на разработку, или в количестве выпущенных продуктов?
Паттерн MVC многими считается "антипаттерном", так как на довольно простую модель прямо-таки обрушивается водопад сильно связного кода с контроллером и отображением. Если бы не IoC (Inversion of Control), то в Java EE давно бы всё остановилось, а сама платформа рассматривалась бы как "унаследованная".

ActiveRecord в Java EE ранее реализовались Entity Bean EJB, но сама техника CRUD (Создание, чтение, обновление, удаление) для них считалась переусложнённой, громоздкой. С популяризацией лёгких ORM-фреймворков Hibernate и развитие Spring подтолкнуло отрасль к легковесным решениям, и в Java EE появилась замена Entity Bean EJB — JPA и CDI.

2) Работа с СУБД из Java происходит только через JDBC. Уникальные возможности отдельно взятых СУБД не берутся в расчёт этим "фасадом", да и сами прикладные программисты не склонны работать с каждой СУБД уникальным для неё образом. Этим достигается прозрачная переносимость приложений с одной СУБД на другую. Например, в целях тестирования приложения может использоваться СУБД в оперативной памяти (H2, например), а в нагрузочных тестах и в продакшене, понятно, может быть уже боевая СУБД типа PostgreSQL или MySQL. (Лично я на производстве отдам предпочтение работе с PostgreSQL).

3) Опыт в HTML4/CSS2 у меня есть в виде самостоятельно свёрстанного (в блокноте с подсветкой тэгов) информационного сайта на фреймах. Есть файловый архив этого сайта. Развёрнутый контент занимает 4МБ, 51 файлов .html. Это "маловато"?

4) Не увлекался JavaScript и jQuery. Но если будет поставлена задача, то смог бы изучить и использовать.
Пройдя огонь, воду и медные трубы, становится как-то всё ни жарко, ни холодно и по барабану.

#5 _Mr.Cherry_

_Mr.Cherry_

    Небожитель

  • Небожитель
  • PipPipPipPipPip
  • 6 743 сообщений

Отправлено 09.01.2014, 13:56

 

Подозреваю, что долго будет переобучать.
Вопросы:
1) Какое кол-во опыта в серверной разработке на Java? Есть ли опыт работы с паттернами MVC и ActiveRecord?
2) Что по поводу работы с БД? Есть ли опыт продвинутой работы с MySQL или другими СУБД?
3) Судя по написанному HTML4/CSS2 - опыта в html-вёрстке маловато. Я прав?
4) Что по поводу JavaScript? jQuery?


1) В человеко-часах, потраченных на разработку, или в количестве выпущенных продуктов?
Паттерн MVC многими считается "антипаттерном", так как на довольно простую модель прямо-таки обрушивается водопад сильно связного кода с контроллером и отображением. Если бы не IoC (Inversion of Control), то в Java EE давно бы всё остановилось, а сама платформа рассматривалась бы как "унаследованная".

ActiveRecord в Java EE ранее реализовались Entity Bean EJB, но сама техника CRUD (Создание, чтение, обновление, удаление) для них считалась переусложнённой, громоздкой. С популяризацией лёгких ORM-фреймворков Hibernate и развитие Spring подтолкнуло отрасль к легковесным решениям, и в Java EE появилась замена Entity Bean EJB — JPA и CDI.

2) Работа с СУБД из Java происходит только через JDBC. Уникальные возможности отдельно взятых СУБД не берутся в расчёт этим "фасадом", да и сами прикладные программисты не склонны работать с каждой СУБД уникальным для неё образом. Этим достигается прозрачная переносимость приложений с одной СУБД на другую. Например, в целях тестирования приложения может использоваться СУБД в оперативной памяти (H2, например), а в нагрузочных тестах и в продакшене, понятно, может быть уже боевая СУБД типа PostgreSQL или MySQL. (Лично я на производстве отдам предпочтение работе с PostgreSQL).

3) Опыт в HTML4/CSS2 у меня есть в виде самостоятельно свёрстанного (в блокноте с подсветкой тэгов) информационного сайта на фреймах. Есть файловый архив этого сайта. Развёрнутый контент занимает 4МБ, 51 файлов .html. Это "маловато"?

4) Не увлекался JavaScript и jQuery. Но если будет поставлена задача, то смог бы изучить и использовать.

 

 

1) В кол-ве лет в веб-индустрии, в приблизительном кол-ве выпущенных веб-проектов.

Эта тема не посвящена сравнению Java и Ruby. Тема посвящена поиску разработчика для работы с фреймворком Ruby On Rails, разработка в котором ведётся с использованием MVC и ActiveRecord. Поэтому повторю вопрос - есть ли понимание и опыт реальной работы с MVC и ActiveRecord?

 

2) На данный момент, в текущем проекте используется именно MySQL. Причём, очень много завязано на отдельные её особенности, которые в других СУБД реализуются иначе. Тем не менее, большая проекта работает через классы рельс, которые изолированы от выбора конкретной СУБД.

 

3) Это даже мешать будет. Я так подозреваю, что вёрстка на таблицах была?



#6 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 635 сообщений

Отправлено 09.01.2014, 14:13

1) В "веб-индустрии" с 2001 года. Реально выпущен и поддерживался один продукт, не считая блога. Понимание MVC и ActiveRecord есть, а вот опыта маловато.

2) А что за особенности? Неужто хранимые процедуры и триггеры?

3) Чем будет мешать опыт ручной вёрстки HTML? (Вот так новость!) Вёрстка была на фреймах. Разделение окна web-сайта осуществлялась фреймами с неподвижными границами областей. Это дало возможность эффективного (почти без оверхеда для служебной информации) представления текстовой информации, возможности по расширению и сопровождению сайта.
Пройдя огонь, воду и медные трубы, становится как-то всё ни жарко, ни холодно и по барабану.

#7 true

true

    Небожитель

  • Небожитель
  • PipPipPipPipPipPip
  • 11 630 сообщений

Отправлено 09.01.2014, 19:41

Сем лет лабаю код на PHP, и вот что мне интересно

MySQL 5 - хранимые процедуры, триггеры, эвенты, разные движки и т.п.

эвенты? wtf? ни разу не нужны были, хранимые процеруры за все время написал может быть одну, триггеры, ну десяток было. вопрос даже в том, нахрена это все нужно в среднестатическом проекте, если все идет через ORM?

HTML5, CSS3, JavaScript (чистый и jQuery) - грамотная современная кроссбраузерная вёрстка. Необходимо также знать чистый JavaScript.

в этой строчке - это вообще два отдельных человека по-хорошему, да, бывает один, но качество скорее фуфло. смешивать разработчкика бекенда и фронтенда? ну не знаю, тех кто и в том и в том хорош, скорее очень мало smile.png я могу писать на JS, но в гробу я его видел. Аналогично скажет JS разработчик

SCSS, HAML, CoffeeScript - синтаксический сахар, весь проект на этом.

опять таки в среднем проекте нахера? я понимаю если это коробочный проект, который под отдельного заказчика билдится, но в целом то? модые технологии? smile.png)

GIT - желательно уметь обращаться с разными ветками, знать про git cherry-pick и т.п.

git cherry-pick слышал, но ни разу не юзал smile.png

SSH - умение зайти удалённо на сервер Debian Linux, перезагрузить различные сервисы, установить доп. ПО и т.п.
С приходом опыта многие задачи становятся нам не только по плечу, но и глубоко по %%%.

#8 _Mr.Cherry_

_Mr.Cherry_

    Небожитель

  • Небожитель
  • PipPipPipPipPip
  • 6 743 сообщений

Отправлено 09.01.2014, 20:08

эвенты? wtf? ни разу не нужны были, хранимые процеруры за все время написал может быть одну, триггеры, ну десяток было. вопрос даже в том, нахрена это все нужно в среднестатическом проекте, если все идет через ORM?

 

1. Кто сказал, что проект среднестатистический? Кто сказал, что всё через ORM?

Для некоторых целей используется всё то, что я упоминал. И отлично влияет на производительность. Некоторые вещи потом перенесётся из процедур, в рельсы. Но некоторые нет.

 

 

 

в этой строчке - это вообще два отдельных человека по-хорошему, да, бывает один, но качество скорее фуфло. смешивать разработчкика бекенда и фронтенда? ну не знаю, тех кто и в том и в том хорош, скорее очень мало smile.png я могу писать на JS, но в гробу я его видел. Аналогично скажет JS разработчик

 

2. Всё реально. Мне довелось в обоих ролях поработать. Не думаю, что мне одному. Ну фронтэнда у нас маловато, в основном дела по бэкенду сейчас.

 

опять таки в среднем проекте нахера? я понимаю если это коробочный проект, который под отдельного заказчика билдится, но в целом то? модые технологии? 

 

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

 

git cherry-pick слышал, но ни разу не юзал

 

4. Как так? Ну меня жизнь заставила ^_^

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

git cherry-pick как пример. Имеется ввиду хорошее знание git. Разные ветки, их мёрдж, rebase, stash, cherry-pick, git amend. Без этого всего тяжко живётся.

 



#9 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 635 сообщений

Отправлено 09.01.2014, 20:09

Вот именно — смешивать ORM-фреймворк и индивидуальные особенности СУБД — мазохизм.

 

Мешать в кучу требования для одного человека разработки дизайна/вёрстки и сопровождения бизнес-логики (JavaScript с  RoR) — мазохизм. Внешним видом (юзабилити) должен заниматься отдельный человек, бизнес-логикой другой. Если часть бизнес-логики должна присутствовать на клиенте, то этот слой должен браться во внимание тем, кто пишет бизнес-логику на сервере, и не менять публичный серверный API к приложению без согласования с разработчиком клиентского приложения.


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

#10 _Mr.Cherry_

_Mr.Cherry_

    Небожитель

  • Небожитель
  • PipPipPipPipPip
  • 6 743 сообщений

Отправлено 09.01.2014, 20:16

1) В "веб-индустрии" с 2001 года. Реально выпущен и поддерживался один продукт, не считая блога. Понимание MVC и ActiveRecord есть, а вот опыта маловато.

2) А что за особенности? Неужто хранимые процедуры и триггеры?

3) Чем будет мешать опыт ручной вёрстки HTML? (Вот так новость!) Вёрстка была на фреймах. Разделение окна web-сайта осуществлялась фреймами с неподвижными границами областей. Это дало возможность эффективного (почти без оверхеда для служебной информации) представления текстовой информации, возможности по расширению и сопровождению сайта.

 

1) Один веб-проект это как-то маловато. Желательно иметь причастность хотя-бы к нескольким. Обучить то возможно, но времени сейчас не так много.

 

2) Да. Используются эти особенности к месту, где это целесообразно. Большая часть через ORM.

 

3) HTML4 на фреймах - это как раз 2001 год. Мне необходим HTML5 и 2014 год. Хотя бы понимание современных технологий. 

 

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



#11 Elliath

Elliath

    Аксакал

  • Почетный житель
  • PipPipPipPip
  • 1 846 сообщений

Отправлено 09.01.2014, 20:19

Вангую, что ребята просекли фишку в том, что можно за бугром найти заказчиков за 20-40 баксов в час, нанять тут наших рэбэ-кодеров за 30-50 тыщ и продавать их труд зарубеж с маржей в 100% :)

Отличный бизнес-план, но вот одна проблемка есть: свободных разработчиков на руби вообще нет (если они, конечно, вменяемые) %)



#12 Sergey Kalinin

Sergey Kalinin

    Ампиратор

  • Забанен
  • 3 429 сообщений

Отправлено 09.01.2014, 20:29

2. Всё реально. Мне довелось в обоих ролях поработать

 

и можно результаты посмотреть?


"Людей я люблю, но их надо п****ть"©Александр Баширов

#13 _Mr.Cherry_

_Mr.Cherry_

    Небожитель

  • Небожитель
  • PipPipPipPipPip
  • 6 743 сообщений

Отправлено 09.01.2014, 20:35

Вангую, что ребята просекли фишку в том, что можно за бугром найти заказчиков за 20-40 баксов в час, нанять тут наших рэбэ-кодеров за 30-50 тыщ и продавать их труд зарубеж с маржей в 100%

 

 

Этот проект российский. 30-50 тр для Саранска - неплохой оклад. По моим данным, в местных компашках этой сферы — ЗП обычно на 30-40 останавливается.

 

 

Отличный бизнес-план, но вот одна проблемка есть: свободных разработчиков на руби вообще нет (если они, конечно, вменяемые) %)

 

 

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

 

и можно результаты посмотреть?

 

Это тут причём?)) Сейчас начнём обсуждать мои навыки? Я не для этого тему открывал.

 

 

Господа, я ценю наше занимательное общение. =)

Но может всё-таки не будем превращать тему, посвященную поиску сотрудника с заявленными характеристиками, в холивар или просто пустой трёп?



#14 Elliath

Elliath

    Аксакал

  • Почетный житель
  • PipPipPipPip
  • 1 846 сообщений

Отправлено 09.01.2014, 20:49

 

Вангую, что ребята просекли фишку в том, что можно за бугром найти заказчиков за 20-40 баксов в час, нанять тут наших рэбэ-кодеров за 30-50 тыщ и продавать их труд зарубеж с маржей в 100%

 

 

Этот проект российский. 30-50 тр для Саранска - неплохой оклад. По моим данным, в местных компашках этой сферы — ЗП обычно на 30-40 останавливается.

 

 

Отличный бизнес-план, но вот одна проблемка есть: свободных разработчиков на руби вообще нет (если они, конечно, вменяемые) %)

 

 

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

 

и можно результаты посмотреть?

 

Это тут причём?)) Сейчас начнём обсуждать мои навыки? Я не для этого тему открывал.

 

 

Господа, я ценю наше занимательное общение. =)

Но может всё-таки не будем превращать тему, посвященную поиску сотрудника с заявленными характеристиками, в холивар или просто пустой трёп?

 

 

Да ладно уж, зато тема всегда в топе )

 

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

Ну а про 30-40 - это в первую очередь из-за самих работников, у меня многие знакомые на полставки работают из-за того, что еще учатся или еще где-то заняты



#15 true

true

    Небожитель

  • Небожитель
  • PipPipPipPipPipPip
  • 11 630 сообщений

Отправлено 09.01.2014, 20:59

1. Кто сказал, что проект среднестатистический? Кто сказал, что всё через ORM?
Для некоторых целей используется всё то, что я упоминал. И отлично влияет на производительность. Некоторые вещи потом перенесётся из процедур, в рельсы. Но некоторые нет.

навскидку, если в целях производительности идет отказ от ORM, то или идет нормальная такая выборка по нормально так нормализованным данным smile.png если в одном проекте, то на ORM, то без ORM, то хочется вырвать руки - все должно быть максимально просто.
 

2. Всё реально. Мне довелось в обоих ролях поработать. Не думаю, что мне одному. Ну фронтэнда у нас маловато, в основном дела по бэкенду сейчас.

я не сказал, что это нереально smile.png я лишь сказал, что разработчик бекэнда не будет так эффективен на фронтенде и поэтому стараются разделять эти две сучности smile.png другое дело, что часто не выгодно брать на фултайм разработчика JS и верстака, так как сервис то ты пилишь один, а не кучу, поэтому загрузки у них не будет и поэтому тебе приходится совмещать. еще один фактор, что фрилансеры делают на *цензура*сь, т.е. качество кода желает лучшего.
 
 

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


мм... глядя на жизненный цикл разработки, я вижу, что появляется дизайн и практически не меняется к финишу, поэтому не очень понимаю зачем перебилдивать css и js, если в целом требования остаются такими же - один раз сбилдил, например, тот же бутстрап и пошел гулять. зачем билдить постоянно?
 

4. Как так? Ну меня жизнь заставила happy.png
Вспоминаю как я кучу геморроя доставил коллеге из-за слабого понимания git. И желательно чтобы мне такого геморроя не пришлось разгр*цензура*.
git cherry-pick как пример. Имеется ввиду хорошее знание git. Разные ветки, их мёрдж, rebase, stash, cherry-pick, git amend. Без этого всего тяжко живётся.

обычно гемморой - это следствие того, что не правильно очередность задач при разработке поставлена, ты бы на SVN посидел, вот там поседеть можно при tree conflict, а на git даже ничего такого не припомню

1) Один веб-проект это как-то маловато. Желательно иметь причастность хотя-бы к нескольким. Обучить то возможно, но времени сейчас не так много.
  
П.С. Желаемо найти универсального разработчика, коим сам являюсь. Если такого не получится найти - предпочтение уходит в сторону подходящего бэкенд-разработчика, имеющего некоторый опыт в разработке серверной части для веб-приложений. Ибо в данный момент работ по фронтэнду не так много.


я может быть повторюсь, но за 7 лет, сейчас сижу только на втором более проекте smile.png

p.s.
ты прям повторил мои слова, почему нужен универсал и почему это не два человека )))

Вангую, что ребята просекли фишку в том, что можно за бугром найти заказчиков за 20-40 баксов в час, нанять тут наших рэбэ-кодеров за 30-50 тыщ и продавать их труд зарубеж с маржей в 100% smile.png
Отличный бизнес-план, но вот одна проблемка есть: свободных разработчиков на руби вообще нет (если они, конечно, вменяемые) %)

Да не, рубистам можно найти и в РФ работу за сравнимые деньги, другой вопрос что зп им раздули и голову надо оторвать тому, кто принял решение писать на руби, а не на том же PHP, бюджет раздули на разработку на ровном месте, специалистом нет, а проект пилить надо )))

Сообщение отредактировал true: 09.01.2014, 20:50

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

#16 _Mr.Cherry_

_Mr.Cherry_

    Небожитель

  • Небожитель
  • PipPipPipPipPip
  • 6 743 сообщений

Отправлено 09.01.2014, 21:39

 

 

навскидку, если в целях производительности идет отказ от ORM, то или идет нормальная такая выборка по нормально так нормализованным данным smile.png если в одном проекте, то на ORM, то без ORM, то хочется вырвать руки - все должно быть максимально просто.

 

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

 

я не сказал, что это нереально smile.png я лишь сказал, что разработчик бекэнда не будет так эффективен на фронтенде и поэтому стараются разделять эти две сучности smile.png другое дело, что часто не выгодно брать на фултайм разработчика JS и верстака, так как сервис то ты пилишь один, а не кучу, поэтому загрузки у них не будет и поэтому тебе приходится совмещать. еще один фактор, что фрилансеры делают на *цензура*сь, т.е. качество кода желает лучшего.

 

Всё правильно. Будет достаточно работы для фронтэндера - будем искать чистокровного фронтэндера.

 

мм... глядя на жизненный цикл разработки, я вижу, что появляется дизайн и практически не меняется к финишу, поэтому не очень понимаю зачем перебилдивать css и js, если в целом требования остаются такими же - один раз сбилдил, например, тот же бутстрап и пошел гулять. зачем билдить постоянно?

 

Нет, некоторые проекты постоянно меняются на ходу. Уже много раз сталкивался с тем, что практически невозможно всё предугадать изначально. А у нас вообще фичи на ходу придумываются, которых раньше не было в мыслях. Дизайн от этого страдает. Вот логику допилим до конца - будет редизайн. Тем не менее. Потом правки будет удобнее вносить в рубиподбный coffeescript, а не js. А HAML будет удобнее править, чем возится с HTML. Многое вообще удобнее делать уже на работающем движке, а не заранее. Ибо если сделать заранее - потом придётся переделывать под движок. Мысли не с потолка, а из реалий.

 

обычно гемморой - это следствие того, что не правильно очередность задач при разработке поставлена, ты бы на SVN посидел, вот там поседеть можно при tree conflict, а на git даже ничего такого не припомню

 

Если несколько человек работают над одним проектом - конфликтов не избежать. SVN мне ранее уже нервы ел, больше не хочу)

Но и с гитом проблемы не минуемы. Я с ними не раз сталкивался.

 

Да не, рубистам можно найти и в РФ работу за сравнимые деньги, другой вопрос что зп им раздули и голову надо оторвать тому, кто принял решение писать на руби, а не на том же PHP, бюджет раздули на разработку на ровном месте, специалистом нет, а проект пилить надо )))

 

 

ЗП рубистам выше, чем пхпэшникам не на пустом месте. Не так много пхпэшников, реально сравнимых по скиллу. И то они скорее по привычке не желают ни на что переходить, просто потому что лень или страх не найти работу.

Изначально я был пхпэшником. Потом пересел на руби. Потом дали проект на пхп. Я страдал несколько месяцев. Боль проникала меня насквозь каждый день. Это казалось попыткой бежать в деревенных ботинках, после современных удобных кроссовок. А ведь даже и не знал раньше удобство кроссовок, пока не попробовал.

И вот люди в деревянных ботинках стоят смотрят на кроссовки, примерить не желают, но плюются.



#17 true

true

    Небожитель

  • Небожитель
  • PipPipPipPipPipPip
  • 11 630 сообщений

Отправлено 09.01.2014, 22:24

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

знаешь, я тебе пока ответ писал выше у меня сервак на работе прилег, тупо из-за того, что там данных стало в базе дофига. выборка идет тупо одним селектом без джойнов, по индексу с небольшим ордером, в таблице 1 лям записей, поэтому в ускорение "тут без ORM" я не верю smile.png) под нагрузкой ломается все

 

Нет, некоторые проекты постоянно меняются на ходу. Уже много раз сталкивался с тем, что практически невозможно всё предугадать изначально. А у нас вообще фичи на ходу придумываются, которых раньше не было в мыслях. Дизайн от этого страдает. Вот логику допилим до конца - будет редизайн. Тем не менее. Потом правки будет удобнее вносить в рубиподбный coffeescript, а не js. А HAML будет удобнее править, чем возится с HTML. Многое вообще удобнее делать уже на работающем движке, а не заранее. Ибо если сделать заранее - потом придётся переделывать под движок. Мысли не с потолка, а из реалий.

 

 

это скорее всего говорит о том, что дизайн рисуют программисты :) я представляю, как вы потом идете в вебстудию, заказываете дизайн и одно из требований - HAML :) ценник наверное взлетит до небес )


ЗП рубистам выше, чем пхпэшникам не на пустом месте. Не так много пхпэшников, реально сравнимых по скиллу. И то они скорее по привычке не желают ни на что переходить, просто потому что лень или страх не найти работу.

Изначально я был пхпэшником. Потом пересел на руби. Потом дали проект на пхп. Я страдал несколько месяцев. Боль проникала меня насквозь каждый день. Это казалось попыткой бежать в деревенных ботинках, после современных удобных кроссовок. А ведь даже и не знал раньше удобство кроссовок, пока не попробовал.

И вот люди в деревянных ботинках стоят смотрят на кроссовки, примерить не желают, но плюются.

 

блеаааа ))))  скилл в чем мерять будем? :D ты считаешь, что это обоснование высокой зарплаты?

 

обоснование только одно - можешь ты сделать работу или нет,  а то, что какой-то кент хочет зп выше только потому, что он в модных кроссовках к делу не относится )))

 

p.s.

и ладно бы питон привел в пример, мда....


Сообщение отредактировал true: 09.01.2014, 22:06

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

#18 _Mr.Cherry_

_Mr.Cherry_

    Небожитель

  • Небожитель
  • PipPipPipPipPip
  • 6 743 сообщений

Отправлено 09.01.2014, 23:14

знаешь, я тебе пока ответ писал выше у меня сервак на работе прилег, тупо из-за того, что там данных стало в базе дофига. выборка идет тупо одним селектом без джойнов, по индексу с небольшим ордером, в таблице 1 лям записей, поэтому в ускорение "тут без ORM" я не верю smile.png) под нагрузкой ломается все

 

У меня в табличке было 2,5 млн записей. Регулярный таск делал один большой запрос по куче таблиц, включая эту. С помощью некоторых манипуляций, я добился ускорения этого запроса в несколько раз. Потом накрутил архивирование устаревших данных в ARCHIVE таблицу. Благодаря чему у меня куча полу-ненужных данных лежит не в таблице, где индексы больше данных весят, а в архивной таблице. Да много всякой фигни, где знание особенности СУБД поможет.

 

это скорее всего говорит о том, что дизайн рисуют программисты smile.png я представляю, как вы потом идете в вебстудию, заказываете дизайн и одно из требований - HAML smile.png ценник наверное взлетит до небес )

 

Причем тут дизайн? Дизайн рисовала веб-студия, выдала в html/css. Я взял конвертер html to haml и получил haml, с которым и работал. С остальным также. А весь новый код уже писал в haml/scss/coffeescript.

Под наш проект невозможно с пустого места сделать весь дизайн. Ибо постоянно все придумывается на ходу сейчас. Нестандартный функционал. Поэтому мне на ходу приходится писать haml/scss/coffeescript без дизайна.

А от дизайн-студий я просто больше не буду брать вёрстку. Зачем мне кривая вёрстка от людей, которые не знают архитектуры нашего проекта?

 

блеаааа ))))  скилл в чем мерять будем? biggrin.png ты считаешь, что это обоснование высокой зарплаты?

обоснование только одно - можешь ты сделать работу или нет,  а то, что какой-то кент хочет зп выше только потому, что он в модных кроссовках к делу не относится )))

p.s. и ладно бы питон привел в пример, мда....

 

1. Холиварить ты первый начал. Получил ответ в таком же стиле. Мб закроем тему?

2. В кроссовках бежать быстрее получится, чем в деревянных ботинках. Только вот надо знать как шнурки завязать. 

3. Питон не нравится. Пробовал и его. Ущербность на каждом шагу. Но питонщика конечно удобнее будет переобучать, чем пхпэшника.

п.с. Спорить дальше не буду. Просто предлагаю больше здесь не холиварить. Мне интересно кто какую технологию считает хорошей или плохой. У меня есть потребность в коллеге-рубисте, либо в том, кто готов перейти на руби. Остальное меня не интересует. Если хочешь - давай сраться в личке.


Сообщение отредактировал _Mr.Cherry_: 10.01.2014, 00:05


#19 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 635 сообщений

Отправлено 14.01.2014, 21:52

Вот, кстати, как решается одна из задач конвертации данных СУБД в Java без ORM: http://samolisov.blo...mework-aop.html


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

#20 Barya

Barya

    Старожил

  • Житель
  • 488 сообщений

Отправлено 14.01.2014, 22:58

Странные бессмысленные обсуждения - человек изъявил желание переобучиться на RoR, а потом вдруг MVC хрень и все в таком роде, ну и понеслось... А вакансия и впрямь неплохая, даже жалею, что когда была возможность, не продолжил рельсами заниматься.







Темы с аналогичным тегами разработчик, программист, требуется, ruby, rails, ruby on rails, ror, веб-программист, веб-девелопер, веб-разработчик

Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 скрытых пользователей