While working on my project, I created 3 mini-libraries (100-1000 lines). They are quite complete for the their purposes, though of cause they maybe do not suite any relevant use case.
So the question is: what should i conider deciding if i should make a plug-in/gem from it and publish? When it worth and it doesn't to publish a library?
It would be nice if you supported you advice with some of successful or frustrating experience of creating and publishing a gem/plug-in.
Update:
I've finally published a plug-in: active_factory
I'd say you should consider making it a plugin/gem when you think the idea is modular enough to be a drop and use(with some configuration if needed) for other projects. You should publish it if you think others will also find it useful.
I want to note that I said the "idea" is modular enough. Right now your implementation many not be completely modular, however if the idea itself is, then I'd spend some time making the implementation modular.
In terms of what deems a gem 'useful', I would initially just put it out in the public(aka github for example) and see if there is interest. Some of the greatest ideas spawned from just throwing it out there into the public. You can try your hardest to think about what others are thinking, but you never know until your try. And in this case, there really isn't much overhead in putting it out in the public.
Make it a gem when you think you or others might reuse the code, or simply because you want to manage its development (and tests, etc) separately. The cost is trivial.
Related
I have a large ruby on rails 2.3 which was now a disaster because of the slowness and many bugs. I'm the only programmer and every day I've done debugging and tearing my hair off because of this. The users are already using the product but so many bugs and data are scattered.
I was employed without prior knowledge of project development and management. Now I'm suffering of having more overtime and a crisis on my codes to be fixed.
And also I've created this app while learning rails so there are codes there that became stranger to me.
What should I do?
What are your suggestions?
What books do I need to read about more?
Please I need some help.
Thanks.
I would love to recommend you upgrade to Rails 3. Especially since there are many newer features and some things are simplified, and it would ease future maintainability.
However, unfortunately, I am hesitant to (or rather simply cannot) actually recommend that given that you already have much more on your hands.
In this case, the best thing you can do is to start writing tests. If there are so many bugs, I have to assume that either you have no tests or your have an incomplete test suite. Tests will help to give you confidence that you do not break anything when you try to fix something else.
The default rails test framework can be found at the Ruby on Rails Guides. Having said that, many people prefer the RSpec testing framework. There are indeed shortcomings of the default Rails testing framework (notably the fragility of fixtures - try get a factory gem, and other features such as mocks and expectations, and nested contexts).
You should read up on the testing frameworks, and maybe try it a bit. Pick one testing framework early on however, and start testing everything!
Perhaps when you become more confident in your test suite and have fixed the most important bugs, you should think more about a path to upgrading Rails - because all the gems will march on, and gradually drop support for Rails 2.3, which means you will be using increasingly old gems which may no be well supported anymore.
From what I understood, you are asking for project managment tips and tools how to get a rails project under control.
I believe first thing you need to is stabilize the project. To do this, you will need to minimize the bugs and chart the required work.
I see two complementary approaches for this:
use a task/bug tracking tool
start using cucumber for testing
Task/bug tracking
This is very important, because you will need some kind of list that itemizes all bugs.
Sometimes users discover a bug, and suddenly you have to drop everything, because at that moment, that single bug is the most important bug ever, and needs to be solved immediately.
However, if you would ask them outright if this means the bugs you are fixing are more or less important, the answer could be different.
So it is in your advantage if there is a clear way to let the user participate in that decision process. If there is a shared bug-list, users can also follow the current state (what you are working on), they can indicate/choose which bugs are more important for them.
Secondly: having a list of items(work/tasks/outstanding bugs/...) will also help you planning the work.
There are a lot of options to some kind of bug-tracking, but some easy/pragmatic/free suggestions are
checkout trello
use the issues from github
Tracking the bugs/tasks will give you the feeling you gain control of your project, and furthermore: it will make this also more visible to your client.
Cucumber
When fixing bugs there is always the danger to introduce new bugs, definitely in a project that is originally not your own.
In a project where there are next to no tests, I always propose to start with cucumber. Cucumber has a few advantages:
it tests your application/website from the outside in: no need to understand the code fully, you just need to know what the application should do. If I click this link, it should take me to that page.
it is really easy to write tests in cucumber, and you get test-coverage really quickly
as a bonus, your test-code is readable, which you could show your clients/users, and they would actually understand what is covered by the tests (and could correct/improve it).
Upgrading or not?
I personally believe your first step should be stabilizing the project and minimize/remove all bugs. Whilst upgrading to rails 3 would be a huge improvement, it is not a straightforward process. There are good guidelines, but if you do it now, you will have no idea if a bug was introduced during the upgrade, or existed before. First get your code quality in order, and then do the upgrade.
Hope this helps.
Actually the thing you are asking is completely depending on how much refactoring you need to clean up the whole project. If you have enough time in your hand to clean it up completely. I would suggest following steps:
Getting Ready
Get the visualization of the whole project. What is required and what is not required.
Define your resources and relation between them properly.
Use proper RESTful routing.
Decide the test tools and frameworks like cucumber, rspec, factory girl etc.
Plan of Action
Decide (if possible, as a team) that what are the minimum or necessary changes required.
Isolate all the components in different groups so that each group can be refactored individually. Smaller groups are preferred.
Decide test cases.
Break down tasks into as much as small size possible.
Make sure to keep your test coverage more than 90%.
This process will take around 4-5 months for a medium scale project for a team of 4 members.
Let us know if you have any specific confusion.
What to read: http://guides.rubyonrails.org/v2.3.11/ Start with chapters about debugging and performance testing.
Forget about upgrading to Rails 3 for now, at this moment it would only introduce many more bugs and probably lots of problems with legacy gems and plugins. And don't forget that you need ruby 1.9 in order to upgrade to rails 3 - yet another batch of problems.
Adding tests is a good idea, as ronalchn suggested. I'd recommend to start with unit tests. You might have to rewrite code a lot in order for it to be testable. (In other words, instead of trying tests to fit current legacy code, it's usually better to refactor the code to make it testable.)
Unfortunately there is no quick fix in your current solution. If you seriously consider an upgrade, it will take time to fill in the missing tests if you haven't been writing them, pick up the testing frameworks on top of Rails 3, and work out the necessary data migration once you are ready to flip the switch.
The other option is to continue with Rails 2.x, which isn't completely unfathomable although the support avenues will be much more limited. You still need to work in the tests as a first priority and understand the various nuances that are present in the existing application.
For your scenario (one-man racket with little to no prior experience), I feel that sticking with what you have and improving the testability up to the point where you would feel an upgrade is worthwhile, would be the prudent action. No matter which course of action you would take, be prepared to put in quite a bit of work in the short-to-middle term (but such is the case of accumulating technical debt).
I am currently working on a large project. It is already lunched but the problem is users are already using the app and having very erroneous results. They don't complain much but each and every day I am receiving emails on errors and improvements.
I would appreciate some help in deciding weather to debug the app or just create another one. I'm working on a rails 2.5 app with old plugins.
And I'm the only one doing all this. T.T
Its really tempting on a project like you describe to toss out old code and rewrite, but its almost always a mistake (see http://en.wikipedia.org/wiki/Second-system_effect. links at end regarding rewrites are invaluable, especially http://chadfowler.com/2006/12/27/the-big-rewrite).
I'm guessing you don't have any real test suite in place, or it'd be easier to track down problems and you'd probably have a smaller project as well-tested projects tend to be well-factored (though not always). That's going to make it very difficult to reimplement and have any assurances that you've replicated all the functionality and that any dependencies work well with the "new and improved" code.
And if your users are getting erroneous results, I'd venture to say you don't actually know what the problem is, so a rewrite isn't going to fix that.
When I take over a project like this, step one is to write a suite of characterization tests, documenting the way I think the system is supposed to work AT THE PRESENT TIME. Often in doing so you'll uncover a piece of functionality that doesn't make sense or is inconsistent with the rest of the system—that may well be where your problem is. Once we're through that phase, we can start refactoring the ugly parts, cleaning up views, moving logic to someplace it belongs, removing dead code, etc. But those tests are really important to have if you want to keep the system functioning.
Finally, set reasonable expectations for yourself. Projects like this don't turn into messes overnight—you can't fix them overnight either.
Fujisan I am in the exact situation as you are. I think it is best to first debug the current rails app and then think about rebuilding it. If you are rebuilding the rails app it takes more time than expected. I started out like this:
Created a separate database and repository which has the same code and data that pulls from the live website. I use this website to work with the bugs and not on the live site.
First started off knowing what models are present and started with user model. It is best to use the rails console and dbconsole in this step if you havent used them before. It is easy to find the dependencies from the console with ruby.
Just tweaked around the models and found the relations between different models. After the models looked at the controllers. Now once I have an idea of what is happening in the application I started with a sketch of the purpose of each model and what it is doing and how and why the dependencies are made.
FInally went with working on the bugs and suggestions. The major hurdle was with gems. When the website was created by seniors the gems were very active and now they are all orphaned. This makes it hard to get answer to any of the bugs that are persisting because of those gems.
Railscasts are your best friends!
I hope that helped. Good luck!
I am looking to start developing a relatively simple web application that will pull data from various sources and normalizing it. A user can also enter the data directly into the site. I anticipate hitting scale, if successful. Is it worth putting in the time now to use scalable or distributed technologies or just start with a LAMP stack? Framework or not? Any thoughts, suggestions, or comments would help.
Disregard my vague description of the idea, I'd love to share once I get further along.
Later. I can't remember who said it (might have been SO's Jeff Atwood) but it rings true: your first problem is getting other people to care about your work. Worry about scale when they do.
Definitely go with a well structured framework for your own sanity though. Even if it doesn't end up with thousands of users, you'll want to add features as time goes on. Maintaining an expanding codebase without good structure quickly becomes fairly horrible (been there, done that, lost the client).
btw, if you're tempted to write your own framework, be aware that it is a lot of work. My company has an in-house one we're quite proud of, but it's taken 3-4 years to mature.
Is it worth putting in the time now to use scalable or distributed technologies or just start with a LAMP stack?
A LAMP stack is scalable. Apache provides many, many alternatives.
Framework or not?
Always use the highest-powered framework you can find. Write as little code as possible. Get something in front of people as soon as you can.
Focus on what's important: Get something to work.
If you don't have something that works, scalability doesn't matter, does it?
Then read up on optimization. http://c2.com/cgi/wiki?RulesOfOptimization is very helpful.
Rule 1. Don't.
Rule 2. Don't yet.
Rule 3. Profile before Optimizing.
Until you have a working application, you don't know what -- specific -- thing limits your scalability.
Don't assume. Measure.
That means build something that people actually use. Scale comes later.
Absolutely do it later. Scaling pains is a good problem to have, it means people like your project enough to stress the hardware it's running on.
The last company I worked at started fairly small with PHP and the very very first versions of CakePHP that came out (when it was still in beta). Some of the code was dirty, the admin tool was a mess (code-wise), and sure it could have been done better from the start. But do you know what? They got it out the door before their competitors did, and became extremely successful.
When I came on board they were starting to hit the limits of their current potential scalability, and that is when they decided to start looking at CDN's, lighttpd caching techniques, and other ways to clean up the code and make things run smoother when under heavy load. I don't work for them anymore but it was a good experience in growing an architecture beyond what it was originally scoped at.
I can tell you right now if they had tried to do the scalability and optimizations before selling content and getting a website live - they would never have grown to the size they are now. The company is www.beatport.com if you're interested in who I'm talking about (To re-iterate, I'm not trying to advertise them as I am no longer affiliated with them, but it stands as a good case study and it's easier for people to understand what I'm talking about when they see their website).
Personally, after working with Ruby and Rails (and understanding the separation!) for a couple of years, and having experience with PHP at Beatport - I can confidently say that I never want to work with PHP code again =p
Funny to ask "scale now or later?" and label it "ruby on rails".
Actually, Ruby on Rails was created by David Heinemeier Hansson, who has a whole chapter in his book labeled "Scale later" :))
http://gettingreal.37signals.com/ch04_Scale_Later.php
I agree with the earlier respondents -- make it useful, make it work and get people motivated to use it first. I also agree that you should pick off-the shelf components (of which there are many) rather than roll your own, as much as possible. At the same time, make sure that you choose components for your infrastructure that you know to be scalable so that you can go there when you need to, without having to re-write major chunks of your application.
As the Product Manager for Berkeley DB, I've seen countess cases of developers who decided "Oh, we'll just write that to a flat file" or "I can write my own simple B-tree function" or "Database XYZ is 'good enough', I don't have to worry about concurrency or scalability until later". The problem with that approach is that a) you're re-inventing the wheel (and forgoing what others have learned the hard way already) and b) you're ignoring the fact that you'll have to deal with scalability at some point and going with a 'good enough' solution.
Good luck in your implementation.
I have a created a userdriven gallery with Ruby on Rails.The site is using a few plugins to create friendly links, permissions, pageless pagniation etc. The application controllers and views has gotton quite complex and I find it difficult and very time consuming to work with. So I thought about rebuilding the app with hobo, as it includes all the user and permission logics and another template system. However I am affraid that I will be to limited, or maybe not win anything becasue I will loss a lot of time hacking hobo. I am planning to add frinedships and personal messing to my website. Could this be to compelx for hobo? Does hobo use jquery?
Best regards.
Asbjørn Morell.
Hobo is not that complex, however you would need to study documentation which takes some time. But, in the long-run any refactoring such as Hobo could help, if the code is currently getting unmaintainable.
JQuery can be used in any sytsem as it is independent of script frameworks etc. AFAIK,
No one can tell you if Hobo will help your specific program.
That said, I have been using Hobo for a while and I have found it to be very effective. It handles a good part of the standard rails logic every site needs (such as routes). The dryml system has been useful in my work as well, reducing the size and complexity of my views.
If your code is becoming unmaintainable and you feel a refractor is necessary, you could definitely do worse than Hobo.
i have been building a few hobo apps and they work rock solid, problem is dryml is quite peculiar and you must learn and do a lot of test and try, but in the end it allways comes along quite nicely. i recommend you start quickly with hobo and you will end up faster..!!
I have an idea for a large web application, which in my mind would really be a number of reasonably independent application "components" (?), e.g. forum, blog etc.
It seems to me that it would be nice to open source some of the individual components for others, or myself in the future to use.
Now clearly, I could write a basic forum, make the code available, then copy it across into my large app and extend/integrate it. However, this doesn't feel very DRY. In an ideal world I could maintain the code in one place and drop it into my larger application.
Rails seems to include engines, which sound like solve my problem but it would appear that what I want to do is a bad idea!
So should I..
a) Just build one large, coupled app.
b) Create a rails forum app (for example), release it, then merge/copy it into my main app
c) Use engines
d) Other...
Cheers,
Adam
That warning is just the standard Uncle Ben Corollary. Paraphrased from "With great power, also comes great responsibility." to "Just because you can, doesn't mean you should."
However, just because there are a number of uses for engines that are bad ideas, that doesn't mean it is in your case. Blogs and forums are two reasonably independent components that have already been produced as plugins using Engines. You might not even need to make them.
The way I see it, if you're planning on reusing a functional component that you can feasibly segregate from the rest of the app, then that's a good enough reason to make it a plugin, whether or not it relies on engines.
My experience is that these plugins grow from existing application code I've written. It's much easier to conceive, write, and test them as part of an application than on their own. Engines being miniature apps, aren't that much harder to build and test.
In short. Only you can decide which path is best, because you are most familiar with the goals of your app. Before you start have a look at what others have done with engines and plugins. The components you want to build may already exist.
To answer the question, I would probably start by building a single app, and extract out the bits that could be useful in other apps and abstract them into [engine] plugins as they reach maturity.
What you might be looking for Git Submodules. I don't know a ton about them, but you can simply have a git repo within a git repo. And you can update all your inner git repos pretty easily. Here's an article talking about it.