Looking for an engineer to port Merb code to Rails3

[Tony Mann]

Hi all.

[I am not sure if we are trying to avoid job postings in this group. If so, please forgive me. But I need someone with Merb experience, and this seemed like a great place to find someone.]

We have a medium-size Merb project that we have to port to Rails in order to integrate with various company-wide services. If you or anybody you know is interested in some short-term contract work, let me know. The job would take roughly a month to complete. We need this done soon and done well, and we will provide good compensation if you fit the bill.

Just to avoid flames: I love Merb and don't like Rails. But this decision is out of my control.

..tony..

[pedro mg]

Hi,

will you be posting the migration details publicly ? Would be interesting.

Even if we are starting and maintaining Merb projects. Merb and Sinatra are awesome.

Best luck,
pedromg

--
You received this message because you are subscribed to the Google Groups "merb" group.
To post to this group, send email to me...@googlegroups.com.
To unsubscribe from this group, send email to merb+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/merb?hl=en.

[Tony Mann]

I would be happy to share the details.

So far, the biggest struggle has been that some of the cooler Rails plugins, like inherited_resources and Formtastic, don't work with DataMapper. I considered porting them, but they had AR dependencies all over the place. I already had a little Merb Resources class of my own (which I posted about over a year ago), and porting that to Rails went well.

In general it seems like moving from Merb to Rails will be a mechanical process, but I will keep you posted.

..tony..

[Martin Gamsjaeger]

Tony,

Would it be an option to "just" spend some time on making the problematic plugins work with DataMapper? I'd be interested in helping out with that if the company you work for would be up for it. Sounds like a possible win/win for everyone to me; you could be using popular feature rich rails plugins, DM will be more compatible with the rails ecosystem so more people can use it, and I would have paid work for some time ;)

I have to admit that I haven't yet looked at inherited_resources and formtastic, but I think that if they can work with AR, they can also work with DM.

Some background on me:

* I'm a DataMapper core team member: 

* I was a Merb contributor

* I patched rails' active_model to support DM's usecases

* I share my code at http://github.com/snusnu

cheers

Martin

[Gary Yngve]

Here are a few notes I have regarding merb=>rails3 w/ extlib=>AS and 1.8.7=>1.9.2:

Need the gems dm-rails and rspec-rails.

To generate a new project that uses datamapper:
rails new prj_name -m http://datamapper.org/templates/rails.rb

Nothing special needed to use haml.. just add to Gemfile for bundler.

Notable differences

Controllers

application_controller instead of application.

No fancy sugar for params.. e.g., instead of def edit(id), you need def edit; id = params[:id]

URL helpers

Instead of link_to "req", url(:req,req_id), 
it is link_to "req", req_path(req_id)

partials

Instead of partial 'foo', it is render :partial => 'foo'

escaped strings

All strings are auto-escaped, e.g., = '<br/>' in Rails is equivalent to = h '<br/>' in Merb. Use raw() if you don't want it escaped. 
This is a pain in the ass for helpers that generate forms and other html snippets. 

old:

DateTime.now - DateTime.time_to_day_fraction(0, 2, 0)

new:

DateTime.now.ago(120)

(need to use activesupport: require 'active_support/core_ext/date_time/calculations')

activesupport vs extlib:

instead .snakecase, it is .underscore

[ngo...@googlemail.com]

Hi,

On May 7, 2011 10:58pm, Gary Yngve <gary....@gmail.com> wrote:
> activesupport vs extlib:
>
> instead .snakecase, it is .underscore

A small warning there, the AS inflector methods for those conversions are sometimes subtly different from their apparent extlib equivalents, which is mostly an issue when you try to create paths or constant names. In this case, #underscore will also convert "::" to "/", so e.g.:

"Merb::SomeThing".snake_case
#=> "merb::some_thing"

"Merb::SomeThing".underscore
#=> "merb/some_thing"

There are a few other instances where those differences matter, so read the String documentation at http://rubydoc.info/gems/activesupport/3.0.7/String carefully and hope that your specs are covering those corner cases ;-) In 99% of your code though, it will likely be a purely mechanical switch as it has been for merb itself so far.

[Tony Mann]

Hi Martin.

 

I am very familiar with your work, and I admire and appreciate all your accomplishments. My little Resources stack was inspired in part by the "resources controller" work you did a few years ago.

 

At this time, I cannot justify paying you to do these ports for the following reasons:

1. I already ported my Resources stack, and it provides more of what I need than inherited_resources.
2. Since we are porting existing forms with all layout and styles done already, formtastic does not provide much benefit.

It is a shame, because having these ports would be good for the DM community.

 

..tony..

 

[pr]

I undertook a similar project to migrate our open source project
Mostfit (http://github.com/mostfit/mostfit) to Rails 3. I sent this
email to my team after 3 days:

"
Mostfit has taken some baby steps towards rails3.

Learnings so far:
1. Devise is SHIT. It follows the age old methodology of rails aka my-
way-or-highway. Just won't let go of that email property(we do not
have a email login). Moreover, I do not have any idea right now how we
can make sure painless migration aka without forcing users to change
password.

2. Merb is a much better framework *any* day. Merb routing was much
easier to understand and use. For instance, even after so much work on
rails3, they have stylesheet_include_tag not take symbols. I do not
understand why.

3. Rails 3 is damn slow in dev mode. I tried some stupid dev-boost
shit. It just caches everything and doesn't reload anything when
changed. Removing it almost make it impossible to work with Rails
taking upto 20-30 seconds to re-load at times.

I hate rails3 so far!

I have written a script which will make it easy to keep merging
mostfit to mostfit_rails for the time being. My aim is to make a
single command migration from mostfit_merb to mostfit_rails. It works
like 95% right now. Rest 5% will come soon. There are some code
changes I am doing into mostfit to make this easier.
"

I never completed the rest 5% as it was deemed unnecessary. We are
happy to use Merb.

Piyush

[Tony Mann]

Thanks for the notes. Unfortunately we have to integrate with other apps in the company, and thus Rails is required because we need to use certain plugins. Ah well, I will just hold my nose and get it done.

..tony..

[pedro mg]

Hi,

On Thu, May 26, 2011 at 12:59 PM, pr <piyu...@gmail.com> wrote:
> I undertook a similar project to migrate our open source project
> Mostfit (http://github.com/mostfit/mostfit) to Rails 3. I sent this
> email to my team after 3 days:

I recently met someone on a local meeting porting a Merb app to
Rails3. After 2 weeks they dropped the port. The team (of 3) has their
own homebrew fast Merb as they say, and will stick to it for new apps
development. Was nice to ear that.

I'm happy with Merb and Sinatra. And at its core, Ruby is a very
active project, with a great deal of attention. If Ruby gets better
and faster, Merb gets better and faster. We'll need to pay attention
to this Rubygems recent "development".

And, as posted here before:
http://sethgodin.typepad.com/seths_blog/2011/03/bring-me-stuff-thats-dead-please.html

As for Engine Yard, AppCloud has support for Merb apps.

Nicos, thanks for the effort, I see still lots of production apps that
will be thanking all that Merb love ;-)

best regards,
pedro mg

[Tony Mann]

I like Merb. But our app is now part of a suite of apps, and it really needs to be in Rails to "play nice" with the others. So I have no choice.

..tony..

On Mon, May 30, 2011 at 3:33 AM, pedro mg <pedro...@gmail.com> wrote:

Hi,

[pedro mg]

Hi,

On Wed, Jun 1, 2011 at 6:09 AM, Tony Mann <theph...@gmail.com> wrote:
> I like Merb. But our app is now part of a suite of apps, and it really needs
> to be in Rails to "play nice" with the others. So I have no choice.

yes, you mentioned it before. Will you be using/porting js "to" CoffeScript ?

best regards,
pedro mg

[Tony Mann]

For now I will leave the JS as-is. The truth is that I wrote the JS code as I was learning the language, so it needs to be re-written at some point anyway. When I do, I will probably use Coffeescript, since it provides a solution to a few of the more annoying pain points with JS.

..tony..

best regards,
pedro mg

[Jason Lewis]

could you be more explicit about what has to be Rails-ified to "play nice"? Moving DM classes to ActiveRecord shouldn't be that hard. And if there's a common API for which you want to use ActiveResource, that's also just rewriting models (in theory). I wouldn't mind considering this as a freelance project, but some more info would be helpful.

Jason Lewis

Email          jasonl...@gmail.com    
                       
Mobile         414.301.2665

Blog:           http://duckpunching.wordpress.com/

best regards,
pedro mg

[Julian Leviston]

Haha... isn't everything "just rewriting models (in theory)", though? ;-)

Julian.

[Tony Mann]

We are going to stick with DM, at least for now. So the models can stay as-is.

We just need to port the rest of the stack; ie. controllers, views, and helpers. And some of the merb-specific /lib code.

If you need more info, let me know.

If this is starting to bore the list, you can email me directly :-)

..tony..

[pedro mg]

Hi,

On Thu, Jun 2, 2011 at 10:27 PM, Tony Mann <theph...@gmail.com> wrote:
> We are going to stick with DM, at least for now. So the models can stay
> as-is.
> We just need to port the rest of the stack; ie. controllers, views, and
> helpers. And some of the merb-specific /lib code.
> If you need more info, let me know.
> If this is starting to bore the list, you can email me directly :-)

let it flow, this is a good topic and this list needs this kind of activity ;-)

pedro

[Tony Mann]

A thought, based on the "we gave up on our Rails 3 port" postings:

• Rails3 derived some benefits from having merb team work with them, but ultimately Rails 3 does not appeal to merb developers.

So to me, the integration of merb into Rails 3 was ultimately failure, since the developer community was not well-served by it. This gives us three choices:

1. Make Rails 3 more appealing for merb developers. I see no path for this.
2. Get merb back up and running. I don't see enough community support for this, since the rug was pulled out from under it. People incorrectly see Rails 3 as having "solved" the problems merb originally solved.
3. Take advantage of Sinatra's momentum. Put our energy into a lightweight framework on top of it. Padrino comes to mind.

..tony..

--

[Roy Wright]

Personally I've switched to Ramaze for an easy to understand, light weight framework.  I much prefer having to specify what I want versus discover the magic recipes necessary to disable what I don't want.

[pedro mg]

Hi,

On Fri, Jun 3, 2011 at 6:17 PM, Roy Wright <r...@wright.org> wrote:
> Personally I've switched to Ramaze for an easy to understand, light weight
> framework.  I much prefer having to specify what I want versus discover the
> magic recipes necessary to disable what I don't want.
>
> On Jun 3, 2011, at 11:48 AM, Tony Mann wrote:
>
> A thought, based on the "we gave up on our Rails 3 port" postings:
>
> Rails3 derived some benefits from having merb team work with them, but
> ultimately Rails 3 does not appeal to merb developers.
>
> So to me, the integration of merb into Rails 3 was ultimately failure, since
> the developer community was not well-served by it. This gives us three
> choices:
>
> Make Rails 3 more appealing for merb developers. I see no path for this.
> Get merb back up and running. I don't see enough community support for this,

I'd love to see numbers on merb apps in production. Merb was growing
steadily until the core developers had that "call for action" to work
on a messed Rails. That was a breaking point in Merb timeline and
teared its community apart. I still find Merb a smart project and
pretty interesting framework. Because of its value we can't say "its
dead". It isn't. Nicos is working on it, digging its source and
working on interesting future solutions.

It would be interesting to have a Merb::Conf (conference) to revamp
its image as a working and smart ruby framework.

> since the rug was pulled out from under it. People incorrectly see Rails 3
> as having "solved" the problems merb originally solved.
> Take advantage of Sinatra's momentum. Put our energy into a lightweight
> framework on top of it. Padrino comes to mind.

Sinatra is interesting for its pure simplicity. I'm using it as a
read-only "model" (API) for a Merb app.

What makes you want to redirect efforts in developing Merb to Padrino
? The community ? For now, I'll stick to Merb.

I will try to contact Ezra and Wycats and other commiters like SnuSnu
to ask them how they see Merb right now, and how they see Merb related
to other Ruby frameworks technically.

best regards,
@pedro_mg

[Tony Mann]

What makes you want to redirect efforts in developing Merb to Padrino
? The community ? For now, I'll stick to Merb.

I was just pondering whether we could leverage Sinatra's momentum. I imagine that Padrino needs help, and Sinatra provides a great foundation. Maybe we could take our learnings from Merb and use them to make something like Padrino be a pack leader, as a genuine alternative to Rails.

..tony.. 

--

[Chris Scott]

Sinatra pretty much serves my needs.  I use DM with it.  I've dabbled in Padrino a bit.

However, one's app *can* outgrow Sinatra, I've found.

--
Chris Scott

Transistor Software

[pedro mg]

Hi,

On Jun 24, 2011 7:17 PM, "Tony Mann" <theph...@gmail.com> wrote:
>>
>> What makes you want to redirect efforts in developing Merb to Padrino
>> ? The community ? For now, I'll stick to Merb.
>
>
> I was just pondering whether we could leverage Sinatra's momentum. I imagine that Padrino needs help, and Sinatra provides a great foundation. Maybe we could take our learnings from Merb and use them to make something like Padrino be a pack leader, as a genuine alternative to Rails.
>

I see your point, and makes sense of course. Yet we can easily fork
the debate in several situations here :-)
- project contribution and hacking;
- production web apps;
- time spent learning a framework;

Its not easy nor free (time) to port production apps to another
framework. I dont even know if its easier to port on a smaller company
with fewer resources (as contradictory as may seem history tells us it
is) than in a big company.

Merb has an excellent basis to be worked on. Comes to mind a recent
example, related to the run_later() method for small tasks. Is it
implemented on Rails3 ? Some Rails friends went "oh cool!!".

Love and use Sinatra. Merb+Datamapper+jQuery makes my day ;)

@pedro_mg