Hi, I’m working on an application with a friend, and while he’s technical, I think it will be me doing most of the development work (he’s handling more the business dev side).
What’s a good workflow for solo development in Rails?
Right now I’m thinking that I’ll do all the back-end work and not do any front-end work until the app is meeting all our functional requirements. Then I would begin front-end work.
However, I can see merit in just completing a feature both back and front-end wise one at a time. Maybe in designing UI, I might come across issues in the application that I would not see otherwise.
I don’t think there’s a set answer here, but how do you all do this?
Also can someone recommend a lightweight authentication/authorization solution? I don’t want to use Devise, I find it hard to work with. I saw Monban used in the intermediate Rails workshop, but not an authorization solution (I’m not done with the workshop yet), can anyone recommend something?
You should follow the same git workflow (atomic commits, good comments, branches for features) that you’d use with a team later. As someone who sometimes picks up projects begun by other devs, your future coworkers/subordinates will appreciate being able to follow the evolution of your application.
As for authentication and authorization, I have found that clearance, a thoughtbot gem, does a great job is you want a fairly lightweight solution. I end up having to extend it almost every time I use it in a production app, but it lays down a solid, readable foundation. I would rather build up my own changes on top of Clearance than wrap my head around Devise. (If you have very sophisticated needs, it is probably the way to go, however.)
@roneesh, I would strongly recommend that you build an entire feature at a time rather than pieces of several features. Use user stories to drive your workflow:
As a user, I can comment on an blog post so that the author can get my feedback
Then implement the right amount of front/back end code to fulfill the needs of this story. Typically, I will convert a user story into a high-level integration test using rspec and capybara that will then drive my development.
I strongly suggest that you check out our playbook where we go over the workflow and best practices we use at thoughtbot when working on a project. There is a lot of good info there.
As @geoffharcourt mentioned, Clearance is a good solution if you are looking for lightweight authentication. For authorization, CanCan is probably the most popular solution out there.
@roneesh, I’m a sole developer working on my first production app for a music school.
At the start I was doing the front-end and UI work too, but now I’ve got a great designer onboard who’s taken all that off my hands.
He’s very capable but isn’t technical enough to discuss the development side, so sometimes it can get frustrating working through issues alone.
I also miss having someone to do code reviews. I used to work in a team (albeit small) and the ability to casually wheel your chair over to a colleague and ask for a quick code review seems priceless to me right now
I’m still working out the best way to get some third-party input without breaking the budget.
@weavermedia, when you’re the only developer on a project, it is really hard not having someone to review your work. I’m alone at my company right now, so I do the following things:
Sometimes I test more than my instincts say is appropriate
I use static analysis tools like CodeClimate, flog, reek, and rubocop to catch things that might slip from a discipline perspective
I rely on “hallway usability testing”, which is having my non-technical co-founder drive code on dev or staging before deploying
I often sleep on significant PRs for a night and review in the morning with a fresh set of eyes when deployment isn’t time sensitive
None of these things are anywhere close to the value that a fellow developer reviewing provides, but when you’re alone it’s at least a little bit of pressure to keep your code in good shape.
For auth: I highly highly recommend Sorcery. I personally despise Devise. Clearance from Thoughtbot is also good, however I haven’t spent much time with it. I hate Devise for one main reason – it tries to be too much. I don’t need Devise to build my views, I hate having to override Devise functionality – it’s just a sledgehammer against a fly. If you’re interested in Sorcery, there’s a great Railscast on it. Of course the Thoughtbot boyz can speak more about Clearance. You can also make your own system but I’ve found that when I do that, it pretty much ends up looking like Sorcery. So I don’t bother anymore.
As @joelq said, the User story approach is absolutely the way to go.
Personally what I do is write the story, write the test, get the test to pass, then after that, I’ll write more cards to do the "front-end-beautification’ That way, I have functioning features first, then beautiful functioning features eventually. I’m not great at front-end so if I were to do the styling simultaneously, I would likely never finish anything. I probably would recommend a hybrid approach – get the basic UX built as you work, but don’t stress the details of color scheme, exact layout until later. Because, I’ve found that the road to hell is paved with “good” design – meaning, what you think is good design, might actually change as you start to add new functionality. So I don’t want to burn a bunch of hours making a page “perfect” until I start to have a cohesive feature set. That way I can evaluate the UX holistically and THEN get into the details.
But please write tests! This way if/when you get a “front-ender” on board, you have tests to ensure that nothing gets broken when you start adding more design. It’s also a lot more fun to code that way because you aren’t chasing random bugs around the yard – the tests let you know what’s up.
I’m not a Thoughtbotter though, so I can’t vouch for my way being the “best” – but it works for me. Personally, I’m a form follows function person, so I like to get the function first and then figure out the best form later.
one prob with CanCan is that the Rails 4 support is a bit questionable since Ryan Bates apparently is backpacking through Nepal or something… I’m using Authorize and Rollify for my latest project and they seem to be working well.
I tend to work solo on projects; if you’re writing tests as you go, it’s useful to know what you’re going to expose in the views — I tend to find I’ve either missed something or added too much when I try and do one without the other, essentially the same problem TDD solves on the ‘backend’ side of your code.
Equally you don’t have to style it up, just getting something showing up, enough to use the application, gives your front-end guy has somewhere to start and/or you something to show them progress wise.
Clearance is good — it’s been mentioned a few times, fairly simple, a bit opinionated… I really like the simplify of what it provides (sign, sign up, sign out, forgotten password) and that it’s up to me to actually enforce authentication in the controllers, I find it makes the application easier to reason about than when I shunt that logic off elsewhere (routes.rb for example).
Roll your own — I’ve done this a few times (Railscasts has most of what you’d need), I tend to find though, similar to @briandear, that I end up rewriting what I’m familiar with (for me it’s Clearance rather than Sorcery)
