Why Ruby? (was: This is happening (again))

26 views
Skip to first unread message

Ian Young

unread,
Sep 24, 2015, 12:45:41 PM9/24/15
to grinnellplan...@googlegroups.com
Hi Saul,
 
In short, Ruby because:
 
1) It's fun,
2) Rails is an extremely solid and capable framework
3) Experience in Rails is pretty valuable to anyone looking to get a web dev job
 
If you want more details on the thought process, I believe it's covered in the meeting minutes from when we started the project several years ago.
 
 
On Thu, Sep 24, 2015, at 01:25 AM, stjohns wrote:
Why Ruby?
 
On Wednesday, September 16, 2015 at 1:45:52 AM UTC-5, Ian Young wrote:
Yes! Despite appearing rather dead, the Rails rewrite has just been resting its eyes for a bit. I am firing this thing back up, with the intention of putting in regular amounts of work throughout the next few months and hopefully pushing this project close to the finish line.
 
Are you interested in helping out? Whether you're a Rails vet looking to do some good for the community, or a newbie looking to gain some experience with the fun and eminently-marketable framework, we can totally use your help. If you are interested but don't know where to start, literally me email me with the words "I want to help with Plans dev" and I will get you set up.
 
I've pushed a whole ton of updates bringing the project up to Rails 4.2, Ruby 2.2, etc. Hopefully no one had outstanding branches, but if you did and they are now ruined, ping me and I can help you straighten them out. I'll be putting most of my substantive commits from now on into Pull Requests. I'll leave them open for at least a day in case anyone would like to review and comment. If you want to look over a pull request before it gets merged, drop me a comment to let me know you're looking at it, and I'll wait a bit longer.
 
Let's do this! I want to push Plans forward into the new era of the web, and getting it onto manageable technological footing is the very important first step.


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 

stjohns

unread,
Sep 25, 2015, 5:10:18 PM9/25/15
to GrinnellPlans Development
Gonna be honest, I didn't read the whole IRC discussion, because a chat log does not a design doc make. Maybe someone who participated wants to write up a summary of what was discussed and the decisions that were made that's accessible to the community at large?

Here's what I'm getting at. A rewrite in Ruby is a cool hack, and the experiential value to the dozen or so involved developers is apparent. But what is the value of this project to the six-thousand-odd end-users who are not developers? What are the risks? Is the balance in the their interest?

What's more, the existing community of Plans developers are necessarily comfortable with PHP. That may not be true of Ruby. Is the potential alienation of existing developers in pursuit of this project justified?

-s

On Thursday, September 24, 2015 at 11:45:41 AM UTC-5, Ian Young wrote:
Hi Saul,
 
In short, Ruby because:
 
1) It's fun,
2) Rails is an extremely solid and capable framework
3) Experience in Rails is pretty valuable to anyone looking to get a web dev job
 
If you want more details on the thought process, I believe it's covered in the meeting minutes from when we started the project several years ago.
 
 
On Thu, Sep 24, 2015, at 01:25 AM, stjohns wrote:
Why Ruby?
 
On Wednesday, September 16, 2015 at 1:45:52 AM UTC-5, Ian Young wrote:
Yes! Despite appearing rather dead, the Rails rewrite has just been resting its eyes for a bit. I am firing this thing back up, with the intention of putting in regular amounts of work throughout the next few months and hopefully pushing this project close to the finish line.
 
Are you interested in helping out? Whether you're a Rails vet looking to do some good for the community, or a newbie looking to gain some experience with the fun and eminently-marketable framework, we can totally use your help. If you are interested but don't know where to start, literally me email me with the words "I want to help with Plans dev" and I will get you set up.
 
I've pushed a whole ton of updates bringing the project up to Rails 4.2, Ruby 2.2, etc. Hopefully no one had outstanding branches, but if you did and they are now ruined, ping me and I can help you straighten them out. I'll be putting most of my substantive commits from now on into Pull Requests. I'll leave them open for at least a day in case anyone would like to review and comment. If you want to look over a pull request before it gets merged, drop me a comment to let me know you're looking at it, and I'll wait a bit longer.
 
Let's do this! I want to push Plans forward into the new era of the web, and getting it onto manageable technological footing is the very important first step.


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 

Ian Young

unread,
Sep 25, 2015, 6:09:11 PM9/25/15
to grinnellplan...@googlegroups.com
Here's why I'm confident that this is a positive move: the current community of Plans developers is effectively 0. Actually, 0.5, because [cohnalex] handles server stuff, does some small patches, reviews code and generally does a bunch of other thankless stuff to keep the existing codebase humming along. But there is no active development happening currently and has been little to none for years. No progress on a real API (and thus on mobile apps), no hashtags, no newlove. The only thing I've done recently is the blocking feature,; other than that exception I am retired from the PHP codebase because doing any major work in it is a tedious uphill slog and I will not spend my free time on things that make me unhappy.
 
So am I willing to sacrifice that for a framework that offers many benefits and generates a fair amount of interest fromother developers every time I bring up the subject up? Yes I am.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
  Ian Young
 
 

Anna Carey

unread,
Sep 25, 2015, 6:31:30 PM9/25/15
to grinnellplan...@googlegroups.com
I'm open to discussion, but first asking a question about why a decision was made and the refusing to read the meeting notes that we collaboratively documented after the meeting is not a good way to start off the discussion.

The primary reason that we were motivated to rewrite plans is that it is/was a big hot mess of code (disclaimer: I haven't looked at the php plans in a while). The web has evolved immensely since the days that plans was started and we would benefit greatly from a framework.  It's been an off-and on hobby project for a few of us, but I think we could knock it out quickly with some dedication.  The starting point of the discussion was that there were a lot of bug reports in google code and no one was willing to address them because the php codebase was too unwieldy.  Looks like that's still the case  https://github.com/grinnellplans/grinnellplans-php/issues.  Picking a framework, any framework makes it easier for people to jump in and help write code.  At the time we picked RoR because there were a number of experienced and enthusiastic people. 

To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 

--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.

[FullmerS]

unread,
Sep 26, 2015, 2:01:56 PM9/26/15
to GrinnellPlans Development
Hi! I just want to throw in my two cents in from from an Android developer perspective.

It would be great if there was a Android app for Plans (iOS too of course, but I cannot easily help with that). However, as the back-end currently stands, creating an Android app would be... unnecessarily difficult. If you guys decided to make some well-documented API end points with Rails, I would love to make an Android app for Plans.


On Thursday, September 24, 2015 at 6:45:41 PM UTC+2, Ian Young wrote:
Hi Saul,
 
In short, Ruby because:
 
1) It's fun,
2) Rails is an extremely solid and capable framework
3) Experience in Rails is pretty valuable to anyone looking to get a web dev job
 
If you want more details on the thought process, I believe it's covered in the meeting minutes from when we started the project several years ago.
 
 
On Thu, Sep 24, 2015, at 01:25 AM, stjohns wrote:
Why Ruby?
 
On Wednesday, September 16, 2015 at 1:45:52 AM UTC-5, Ian Young wrote:
Yes! Despite appearing rather dead, the Rails rewrite has just been resting its eyes for a bit. I am firing this thing back up, with the intention of putting in regular amounts of work throughout the next few months and hopefully pushing this project close to the finish line.
 
Are you interested in helping out? Whether you're a Rails vet looking to do some good for the community, or a newbie looking to gain some experience with the fun and eminently-marketable framework, we can totally use your help. If you are interested but don't know where to start, literally me email me with the words "I want to help with Plans dev" and I will get you set up.
 
I've pushed a whole ton of updates bringing the project up to Rails 4.2, Ruby 2.2, etc. Hopefully no one had outstanding branches, but if you did and they are now ruined, ping me and I can help you straighten them out. I'll be putting most of my substantive commits from now on into Pull Requests. I'll leave them open for at least a day in case anyone would like to review and comment. If you want to look over a pull request before it gets merged, drop me a comment to let me know you're looking at it, and I'll wait a bit longer.
 
Let's do this! I want to push Plans forward into the new era of the web, and getting it onto manageable technological footing is the very important first step.


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 

Ian Young

unread,
Sep 26, 2015, 6:50:38 PM9/26/15
to grinnellplan...@googlegroups.com
[fullmers] - That's great, I'm delighted that you're volunteering for that. It would be wonderful to have an Android app, and you're absolutely right that it would be difficult and unpleasant given the site's current state. A real API is definitely near the top of the wishlist once we move to Rails, but unfortunately we can't start on new stuff until we've finished rewriting the existing things. I will definitely post here once I'm thinking about building an API, so I really hope you're still available and interested when the time comes.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.

Avram Lyon

unread,
Sep 27, 2015, 1:58:17 AM9/27/15
to grinnellplan...@googlegroups.com
Of course another direction of development would be to go API-first and have the actual web interface be nothing more than another API consumer (i.e., something in JS/HTML that uses the API). That might simplify the rest of the story and allow web and native mobile to proceed in parallel.

On Sat, Sep 26, 2015 at 3:50 PM Ian Young <i...@iangreenleaf.com> wrote:
[fullmers] - That's great, I'm delighted that you're volunteering for that. It would be wonderful to have an Android app, and you're absolutely right that it would be difficult and unpleasant given the site's current state. A real API is definitely near the top of the wishlist once we move to Rails, but unfortunately we can't start on new stuff until we've finished rewriting the existing things. I will definitely post here once I'm thinking about building an API, so I really hope you're still available and interested when the time comes.
 
 
On Sat, Sep 26, 2015, at 01:58 AM, [FullmerS] wrote:
Hi! I just want to throw in my two cents in from from an Android developer perspective.
 
It would be great if there was a Android app for Plans (iOS too of course, but I cannot easily help with that). However, as the back-end currently stands, creating an Android app would be... unnecessarily difficult. If you guys decided to make some well-documented API end points with Rails, I would love to make an Android app for Plans.
 
On Thursday, September 24, 2015 at 6:45:41 PM UTC+2, Ian Young wrote:
Hi Saul,
 
In short, Ruby because:
 
1) It's fun,
2) Rails is an extremely solid and capable framework
3) Experience in Rails is pretty valuable to anyone looking to get a web dev job
 
If you want more details on the thought process, I believe it's covered in the meeting minutes from when we started the project several years ago.
 
 
On Thu, Sep 24, 2015, at 01:25 AM, stjohns wrote:
Why Ruby?
 
On Wednesday, September 16, 2015 at 1:45:52 AM UTC-5, Ian Young wrote:
Yes! Despite appearing rather dead, the Rails rewrite has just been resting its eyes for a bit. I am firing this thing back up, with the intention of putting in regular amounts of work throughout the next few months and hopefully pushing this project close to the finish line.
 
Are you interested in helping out? Whether you're a Rails vet looking to do some good for the community, or a newbie looking to gain some experience with the fun and eminently-marketable framework, we can totally use your help. If you are interested but don't know where to start, literally me email me with the words "I want to help with Plans dev" and I will get you set up.
 
I've pushed a whole ton of updates bringing the project up to Rails 4.2, Ruby 2.2, etc. Hopefully no one had outstanding branches, but if you did and they are now ruined, ping me and I can help you straighten them out. I'll be putting most of my substantive commits from now on into Pull Requests. I'll leave them open for at least a day in case anyone would like to review and comment. If you want to look over a pull request before it gets merged, drop me a comment to let me know you're looking at it, and I'll wait a bit longer.
 
Let's do this! I want to push Plans forward into the new era of the web, and getting it onto manageable technological footing is the very important first step.


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jacob Kaufman-Osborn

unread,
Sep 27, 2015, 10:06:52 AM9/27/15
to grinnellplan...@googlegroups.com
+1 to what Avram said.

I don't have any time to help coding on this project, but here's what I would do:
1) Write a proper API on top of the existing storage. Continue to serve the existing PHP plans as-is.
2) Write a new frontend on top of the new API. Serve both the new plans frontend (via the API) and PHP plans off of the same storage.
3) Continue to add features to the new API to convince people to migrate. Add an Android app / iOS app off of the new API.
4) Sunset the PHP plans. Deal with the remaining angry people.
5) Rewrite the storage layer if it needs to be rewritten. Since the API provides an interface we can rewrite the DB implementation however you choose. I don't know if the DB layer actually needs to be rewritten.

FWIW, this is coming from someone who has done migrations where there's a high cost of downtime. With plans, there probably aren't fines for every hour of downtime. :)

stjohns

unread,
Sep 27, 2015, 1:20:53 PM9/27/15
to GrinnellPlans Development
Blocking was implemented in, what, a couple of weeks? Tbh, that doesn't sound like a particularly difficult codebase to work in, plus I'm not sure "Ian Young has sworn off PHP (with limited exceptions)" is really a sufficient reason to rewrite Plans in its entirety.

Maybe the reason so many bugs sit in the queue is because so many of them are unreproducable end-user errors, nitpicky bullshit no one cares about, or pie-in-the-sky feature requests? Tbh, Plans works pretty well as-is, and if something were to go horribly wrong right now, there's no fewer than a dozen individuals experienced with the current code who could be called upon to fix it. 

That's an extremely valuable resource to be risking on something that still sounds a whole lot like an exercise in technological vanity.

Ian Young

unread,
Sep 27, 2015, 4:21:09 PM9/27/15
to grinnellplan...@googlegroups.com
Avram/Jacob,
 
Yes, I've contemplated doing a split between an API-only backend and a single-page-app frontend. Having built several SPAs for clients, I feel like I have a good grasp of the tradeoffs. Here are the reasons I'm not planning to pursue this kind of architecture:
 
  • Plans isn't an application that would benefit very much from the strengths of JS-heavy frontends. Angular/Ember etc are really good when you have a dynamic, highly-interactive app. Plans is pretty static. So I don't think we'd gain very much in terms of user experience, or server load.
  • JS frameworks are not good at things like supporting non-mainstream browsers, accessibility, or supporting browsers without JS. They are working on it, and there are some existing solutions, but this kind of support would be a development burden. I imagine the occasional student still accesses Plans from the MathLAN with Lynx, and I want to support that. AFAIK [stone] is still browsing with JS completely disabled due to security concerns, and since we can support that, I think we should. And I'm sure we have some users accessing Plans from IE7 on their terrible locked-down work computers who are very grateful to have one thing that still works properly.
  • SPAs are slower to develop than Rails. I know they will all claim otherwise, but Rails has such good dev tools and is so stable, and the JS ecosystem is simply not there yet. More JS means more bugs in your code, more bugs in the libraries, worse debugging, more browser problems, etc. I am prioritizing development speed for this project because we are always understaffed.
  • I don't feel as confident about "investing" in a JS framework at this time, both in terms of code investment and in terms of what experience would be most beneficial to people who want to put Plans dev on their resume. Angular has already completely changed their framework once, and my understanding is that Ember is always in a state of serious flux. For something that needs to stay functional with minimal maintenance, and stay relevant for many years, JS land doesn't seem like the best bet.
 
The one area I think Plans could potentially benefit from being a SPA would be the mobile experience, where a SPA could conceivably produce snappier feedback, less network traffic, etc. However, I think that
 
  • Simply serving Rails-Plans with a responsive design will provide a pretty-good experience, insofar as it will be usable and not terribly unpleasant, and
  • To make an outstanding mobile experience (with things like notifications and offline reading), we have little choice but to offer native apps.
 
An SPA would fill in the space between those two options, which doesn't seem like a huge enough win to be worth the downsides.

Jacob Kaufman-Osborn

unread,
Sep 27, 2015, 11:01:45 PM9/27/15
to grinnellplan...@googlegroups.com
Makes sense to me. If Plans were my startup I wouldn't do it that way, but it's not a startup (and its goal isn't to make money). And, as frameworks go, Rails is a pretty damn popular one.

Moreover, as someone who's not actually going to write any code, I can't be too picky...

Eric Tjossem

unread,
Sep 28, 2015, 3:20:40 AM9/28/15
to GrinnellPlans Development
I'm a newcomer to the project, but I have worked professionally with PHP, Rails, and Angular -- and I've seen this before. This debate absolutely echoes what's happening in hundreds of other shops in the web dev world. It's a really common story; a solid codebase that's been built on for years and is in a pretty stable state. It's written in PHP. Suddenly, someone comes along and puts forward a good case for another language (in this case: it's easier to provide a robust API, faster to develop in once you've gotten over the learning curve, and would provide better professional development to the authors).

Everyone's right. You absolutely need a core team of developers from the existing codebase, to keep the site stable and reliable for your users. They care a lot about how existing users will be affected, and whether the improved functionality of the rewrite is even worth it. And you also need a labs team - free of external pressure or requests - that is willing to try new approaches to address long-standing problems. Their experiment might not go anywhere, or it might shape up to look way better than the stable project.

So it's up to some contributors to maintain the user experience and fix bugs in the existing PHP codebase of Plans, while others will naturally gravitate towards working on worthy experiments, like a Rails rewrite.

I agree with the choice of rewrite framework, by the way. Rails will have a far shallower learning curve for PHP devs than the SPA + API architecture you'd end up with if you went for Angular, Ember, or Backbone. I also see we've made significant progress on the Rails-based project already, and we're mainly serving static text-based content. So while I'm normally a huge fan of Angular and often argue for it (combined, say, with a Sinatra API), in my opinion the Rails project is a very appropriate next step for Plans.

- Eric

On Thursday, September 24, 2015 at 9:45:41 AM UTC-7, Ian Young wrote:
Hi Saul,
 
In short, Ruby because:
 
1) It's fun,
2) Rails is an extremely solid and capable framework
3) Experience in Rails is pretty valuable to anyone looking to get a web dev job
 
If you want more details on the thought process, I believe it's covered in the meeting minutes from when we started the project several years ago.
 
 
On Thu, Sep 24, 2015, at 01:25 AM, stjohns wrote:
Why Ruby?
 
On Wednesday, September 16, 2015 at 1:45:52 AM UTC-5, Ian Young wrote:
Yes! Despite appearing rather dead, the Rails rewrite has just been resting its eyes for a bit. I am firing this thing back up, with the intention of putting in regular amounts of work throughout the next few months and hopefully pushing this project close to the finish line.
 
Are you interested in helping out? Whether you're a Rails vet looking to do some good for the community, or a newbie looking to gain some experience with the fun and eminently-marketable framework, we can totally use your help. If you are interested but don't know where to start, literally me email me with the words "I want to help with Plans dev" and I will get you set up.
 
I've pushed a whole ton of updates bringing the project up to Rails 4.2, Ruby 2.2, etc. Hopefully no one had outstanding branches, but if you did and they are now ruined, ping me and I can help you straighten them out. I'll be putting most of my substantive commits from now on into Pull Requests. I'll leave them open for at least a day in case anyone would like to review and comment. If you want to look over a pull request before it gets merged, drop me a comment to let me know you're looking at it, and I'll wait a bit longer.
 
Let's do this! I want to push Plans forward into the new era of the web, and getting it onto manageable technological footing is the very important first step.


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 

Alex Cohn

unread,
Sep 28, 2015, 9:49:57 AM9/28/15
to grinnellplan...@googlegroups.com
Quick operations-side question: I've been buying AWS Reserved Instances to save money, but am looking into switching to Amazon RDS managed MySQL hosting (managing MySQL replication is a pain), which would lock us into using MySQL for about three years (or, rather, make switching an expensive proposition). Have we decided that the backing store for Plans will definitely remain MySQL going forward, or should I pursue options that will give us more flexibility?

Alex

- Eric
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 

--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.

Ian Young

unread,
Sep 28, 2015, 12:35:54 PM9/28/15
to grinnellplan...@googlegroups.com
Alex:
 
It will remain in MySQL during development and the initial launch/switchover phase. It certainly can remain in MySQL after that. Postgres is nicer, but I can't think of any terribly pressing reasons we would have to force a switch. The one Postgres-specific feature we might want at some future date would be full-text search, but there are other solutions available for that (and I haven't used pg search enough to know if it would meet our needs anyhow). And I don't think we will be wanting to switch to a NoSQL store or anything like that.

stjohns

unread,
Sep 29, 2015, 12:52:43 PM9/29/15
to GrinnellPlans Development
I'm open to discussion, but first asking a question about why a decision was made and the refusing to read the meeting notes that we collaboratively documented after the meeting is not a good way to start off the discussion.

Wow, seriously, have you ever read a design document? I have, and that is not what one looks like. Slightly edited meeting minutes might be useful for developers, but other stakeholders deserve succinct and digestible updates such that they can be informed of decisions made and observe progress in accomplishing them (or lack thereof.)

I'm glad you're open to discussion regarding these major technical changes with the users that will be affected by them. I'd suggest that this discussion would have gotten off to a better start had the need for a ground-up reimplementation not been assumed.
 
The primary reason that we were motivated to rewrite plans is that it is/was a big hot mess of code (disclaimer: I haven't looked at the php plans in a while).

You may not have looked at the PHP plans in a while, but the blocking feature was implemented extremely rapidly. That doesn't exactly scream "unmaintainable hot mess of code."
 
The web has evolved immensely since the days that plans was started and we would benefit greatly from a framework. 

That's actually kinda meaningless. The web evolves every day. In what ways would we benefit greatly from a framework?
 
It's been an off-and on hobby project for a few of us, but I think we could knock it out quickly with some dedication. 

That's hardly confidence-inspiring.
 
The starting point of the discussion was that there were a lot of bug reports in google code and no one was willing to address them 
because the php codebase was too unwieldy. 

Or because no one has the time, or the impetus, or thinks they're worthwhile, or...
 
Looks like that's still the case  https://github.com/grinnellplans/grinnellplans-php/issues.  Picking a framework, any framework makes it easier for people to jump in and help write code. 

I'm still not convinced that the lack of people actively developing on Plans at this point in time is actually a problem in need of fixing. I certainly don't think burning down Plans and starting over is a good way to fix it, even if it were a problem.
 
At the time we picked RoR because there were a number of experienced and enthusiastic people. 

If you remember, the README file in the grinnellplans-php codebase lists a large number of people experienced in the existing PHP code-base. I must have missed the part where you consulted the existing authors of this project before decreeing a major architectural overhaul?
 
On Friday, September 25, 2015, stjohns <saul....@gmail.com> wrote:
Gonna be honest, I didn't read the whole IRC discussion, because a chat log does not a design doc make. Maybe someone who participated wants to write up a summary of what was discussed and the decisions that were made that's accessible to the community at large?

Here's what I'm getting at. A rewrite in Ruby is a cool hack, and the experiential value to the dozen or so involved developers is apparent. But what is the value of this project to the six-thousand-odd end-users who are not developers? What are the risks? Is the balance in the their interest?

What's more, the existing community of Plans developers are necessarily comfortable with PHP. That may not be true of Ruby. Is the potential alienation of existing developers in pursuit of this project justified?

-s

On Thursday, September 24, 2015 at 11:45:41 AM UTC-5, Ian Young wrote:
Hi Saul,
 
In short, Ruby because:
 
1) It's fun,
2) Rails is an extremely solid and capable framework
3) Experience in Rails is pretty valuable to anyone looking to get a web dev job
 
If you want more details on the thought process, I believe it's covered in the meeting minutes from when we started the project several years ago.
 
 
On Thu, Sep 24, 2015, at 01:25 AM, stjohns wrote:
Why Ruby?
 
On Wednesday, September 16, 2015 at 1:45:52 AM UTC-5, Ian Young wrote:
Yes! Despite appearing rather dead, the Rails rewrite has just been resting its eyes for a bit. I am firing this thing back up, with the intention of putting in regular amounts of work throughout the next few months and hopefully pushing this project close to the finish line.
 
Are you interested in helping out? Whether you're a Rails vet looking to do some good for the community, or a newbie looking to gain some experience with the fun and eminently-marketable framework, we can totally use your help. If you are interested but don't know where to start, literally me email me with the words "I want to help with Plans dev" and I will get you set up.
 
I've pushed a whole ton of updates bringing the project up to Rails 4.2, Ruby 2.2, etc. Hopefully no one had outstanding branches, but if you did and they are now ruined, ping me and I can help you straighten them out. I'll be putting most of my substantive commits from now on into Pull Requests. I'll leave them open for at least a day in case anyone would like to review and comment. If you want to look over a pull request before it gets merged, drop me a comment to let me know you're looking at it, and I'll wait a bit longer.
 
Let's do this! I want to push Plans forward into the new era of the web, and getting it onto manageable technological footing is the very important first step.


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 

--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplans-development@googlegroups.com.

On Friday, September 25, 2015 at 5:31:30 PM UTC-5, aca...@gmail.com wrote:
I'm open to discussion, but first asking a question about why a decision was made and the refusing to read the meeting notes that we collaboratively documented after the meeting is not a good way to start off the discussion.

The primary reason that we were motivated to rewrite plans is that it is/was a big hot mess of code (disclaimer: I haven't looked at the php plans in a while). The web has evolved immensely since the days that plans was started and we would benefit greatly from a framework.  It's been an off-and on hobby project for a few of us, but I think we could knock it out quickly with some dedication.  The starting point of the discussion was that there were a lot of bug reports in google code and no one was willing to address them because the php codebase was too unwieldy.  Looks like that's still the case  https://github.com/grinnellplans/grinnellplans-php/issues.  Picking a framework, any framework makes it easier for people to jump in and help write code.  At the time we picked RoR because there were a number of experienced and enthusiastic people. 


On Friday, September 25, 2015, stjohns <saul....@gmail.com> wrote:
Gonna be honest, I didn't read the whole IRC discussion, because a chat log does not a design doc make. Maybe someone who participated wants to write up a summary of what was discussed and the decisions that were made that's accessible to the community at large?

Here's what I'm getting at. A rewrite in Ruby is a cool hack, and the experiential value to the dozen or so involved developers is apparent. But what is the value of this project to the six-thousand-odd end-users who are not developers? What are the risks? Is the balance in the their interest?

What's more, the existing community of Plans developers are necessarily comfortable with PHP. That may not be true of Ruby. Is the potential alienation of existing developers in pursuit of this project justified?

-s

On Thursday, September 24, 2015 at 11:45:41 AM UTC-5, Ian Young wrote:
Hi Saul,
 
In short, Ruby because:
 
1) It's fun,
2) Rails is an extremely solid and capable framework
3) Experience in Rails is pretty valuable to anyone looking to get a web dev job
 
If you want more details on the thought process, I believe it's covered in the meeting minutes from when we started the project several years ago.
 
 
On Thu, Sep 24, 2015, at 01:25 AM, stjohns wrote:
Why Ruby?
 
On Wednesday, September 16, 2015 at 1:45:52 AM UTC-5, Ian Young wrote:
Yes! Despite appearing rather dead, the Rails rewrite has just been resting its eyes for a bit. I am firing this thing back up, with the intention of putting in regular amounts of work throughout the next few months and hopefully pushing this project close to the finish line.
 
Are you interested in helping out? Whether you're a Rails vet looking to do some good for the community, or a newbie looking to gain some experience with the fun and eminently-marketable framework, we can totally use your help. If you are interested but don't know where to start, literally me email me with the words "I want to help with Plans dev" and I will get you set up.
 
I've pushed a whole ton of updates bringing the project up to Rails 4.2, Ruby 2.2, etc. Hopefully no one had outstanding branches, but if you did and they are now ruined, ping me and I can help you straighten them out. I'll be putting most of my substantive commits from now on into Pull Requests. I'll leave them open for at least a day in case anyone would like to review and comment. If you want to look over a pull request before it gets merged, drop me a comment to let me know you're looking at it, and I'll wait a bit longer.
 
Let's do this! I want to push Plans forward into the new era of the web, and getting it onto manageable technological footing is the very important first step.


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 

--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplans-development@googlegroups.com.

stjohns

unread,
Sep 29, 2015, 12:59:39 PM9/29/15
to GrinnellPlans Development
+1 to everything Avram and Jacob said.

I'd also add that there's existing Android and iPhone application consumers of the v1 API, and at least a couple of Chrome/Firefox/Greasemonkey extensions that scrape and parse rendered views. Any sort of architectural overhaul needs to remain compatible with these clients, or else encompass their update.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
 
--
  Ian Young
 


--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.
To post to this group, send email to grinnellplan...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.

To post to this group, send email to grinnellplan...@googlegroups.com.
Visit this group at http://groups.google.com/group/grinnellplans-development.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-development+unsub...@googlegroups.com.

Ian Young

unread,
Sep 29, 2015, 1:03:22 PM9/29/15
to grinnellplan...@googlegroups.com
Saul, if you can't keep a civil and constructive tone I will remove you from this list. We are all very busy people, and no one has time to deal with you picking fights. Please stick to useful suggestions or actual contributions of effort.
--
You received this message because you are subscribed to the Google Groups "GrinnellPlans Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grinnellplans-deve...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages