Port to Ruby ?

[dchelimsky]

I think there might be more developer support in Chicago if this were written in Ruby. What do other contributors (existing and potential) think? Anybody reading this who would like to contribute and would prefer to work in Ruby?

[dchelimsky]

FYI - restructuring aside, there are a little over 5k lines of PHP to convert:

$ cloc .
      89 text files.
      89 unique files.
      46 files ignored.

http://cloc.sourceforge.net v 1.60  T=0.44 s (181.9 files/s, 64086.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
CSS                             10           1885            183          10581
PHP                             52            693            864           5173
Javascript                      16           1067            737           4135
SQL                              1            103           1347           1309
HTML                             1             14              8             92
-------------------------------------------------------------------------------
SUM:                            80           3762           3139          21290
-------------------------------------------------------------------------------

[gregsanders]

I'd be interested to hear the rationale for porting the app from PHP to Ruby. I can make some guesses, but would like to get at exactly what the issue is. Is it a feeling that the Ruby language in itself is superior? Or wanting to have the code structured in a stricter MVC pattern? Or a perception that more developers are working in Rails these days? Definitely interested to drill down into this issue, thanks a lot for raising it.

[dchelimsky]

In fairness, it's been several years since I've worked with PHP, so I'm comparing Ruby in 2013 to PHP in 2005. My first thought was "I'd contribute to this, but not in PHP because I don't want to go back and remember how that works".

That said, yes, it's about language preference, it's about structure enabled by the language (not specifically MVC), and it's about increasing the number of developers who would be inclined to contribute. It's also about testability, which is made easier in Ruby IMO (again, comparing to PHP ca. 2005).

Personally, I'd prefer Clojure ;)

[gregsanders]

Thanks, that's good information. I understand the impulse to port an application to your favorite language. I personally know of 2 people who (separately) re-wrote the Python-based CKAN open data platform for PHP. If it had been written in PHP, no doubt someone would have re-written it for Python or Rails. IMHO that's all part of the fun.

I'm thinking the best approach is to worry less about the language and more about the app structures. What happens if we re-structure the current Metalicious app using a more stringently MVC-based framework (think Laravel or Yii)? MVC is the anchor for Django, Rails and MVC.NET. If we also focus on the Active Record pattern and convention-over-configuration, then it seems to me that anyone wishing to port the app to another MVC-based framework would have a relatively easy time of it.

It's even possible that someone who loves Rails or Django might even be persuaded to get involved, despite the PHP, because it would all be laid out in familiar patterns. Thoughts, anyone?

[dchelimsky]

I'm thinking the best approach is to worry less about the language and more about the app structures.

Seems valuable to me.

What happens if we re-structure the current Metalicious app using a more stringently MVC-based framework (think Laravel or Yii)? MVC is the anchor for Django, Rails and MVC.NET. If we also focus on the Active Record pattern and convention-over-configuration, then it seems to me that anyone wishing to port the app to another MVC-based framework would have a relatively easy time of it.

Yes, MVC is the anchor for those frameworks, but I have yet to see a Rails app that doesn't have a bunch M leaking all over its V and C, and I think that's largely due to ActiveRecord (the pattern, not just the lib). I'd much rather see a pattern that decoupled data from datasource e.g. Repository.

That said, I think moving toward some conventions, and the conversation around that move, would be useful.

[derekeder]

There was an opinionated blog post on the OpenShift blog about this very topic of language/framework selection for government apps: https://www.openshift.com/blogs/hey-civic-hackers-how-about-leaving-the-ninja-skills-at-home-and-building-really-useful

I don't necessarily agree with all of the author's points, but he does raise an interesting issue of picking frameworks that government IT have the skills to support. At the end of the day, they're the ones responsible for keeping the app going, so the choice should be made with that in mind.

That being said, porting a recently launched and working app to another language sounds like yak shaving to me.

[dchelimsky]

Agreed. Closing in the hopes of keeping one more yak warm in this cold Chicago winter.

[derekeder]

:wink:

[derekeder]

years later, I realize that I did not apply the term 'yak shaving' properly in this context. still, it was not a good idea to rewrite an entire codebase.

anyways, RIP metalicious. it was a beautiful dream