Hi, Tonight I sat down to play arround with Rails like I have done for the last few days and I realized, being new at all of this framework and OO stuff, that it''d be great to be able to have a personal repository of classes that I could share between different projects. This may sound obvious for most of you but OO is an approach that I''m getting familiar with through Ruby. I know it is possible if I make the effort of creating well designed classes maintaining dependencies to a minimum, etc... but what about the big picture as far as how I use all of this from a practical point of view? How do experienced developpers do it? Do you usually keep a library of classes that you know well available for every project and then mix and match? Is there a way of maybe having a server "serve" these functionality so it can be used by my clients (web services?)? If so, have you seen a setup like this one? I''ve learnt most of what I know about programming because I enjoy it but my background is in design so I don''t know how a "freelance" developper would go about organizing his material. I''d like think I can focus on an approach that will save me from repeating myself and feeling like I have done everything 100 times. For example, as far as Rails goes, say I''ve been using it for some time and have a collection of nice controllers scattered arround in various applications. How can I share these between apps while keeping the code in one place or at least a "master" in one place? I know Needle or Needle-like functionality is being integrated but don''t know if this helps. Imagine having a Rails application with a stucture like this one (this is only for illustration purposses): /appsrv/ /appsrv/cart/create /appsrv/cart/list /appsrv/cart/add_item /appsrv/cart/mod_item /appsrv/cart/... /appsrv/inventory/create /appsrv/inventory/list /appsrv/inventory/locations /appsrv/inventory/add_locations /appsrv/inventory/add_item /appsrv/inventory/mod_item /appsrv/inventory/... /appsrv/catalog/create /appsrv/catalog/add_item /appsrv/catalog/... Then being able to create an application (maybe even on a different server - a client''s server) and "calling" these different controllers (mixing and matching). Maybe a particular client only needs to have inventory functionality so you only use that controller. I realize this has many performance and security complications (and probably more) but I''m dicussing conceptual approaches to structuring a developpers material for re-use and efficiency of development not necessarily propossing this as the right approach. Maybe Railing all of it is not the right approach and having organized folders with classes that I can share petween Rail apps is better. But then how do you consume these services or controllers from other servers? I don''t know.... Do you mind sharing your opinions or recommendations on how one should or could approach development? Thank you, <lgomez>
Hi Luis,
Great question. It is a great idea to get an infrastructure in place-
that will encourage reuse and continued development of code you often
use. Without, you end up repeating yourself a lot or getting lost among
a raft of half finished code on your system. The following is my take,
which, I think, is pretty generic nowadays. The "Pragmatic Starter
Kit", http://www.pragmaticprogrammer.com/starter_kit/index.html, is
good introduction to a number of the topics.
First off, even as a solo developer, a lot of it depends on the tools
you use- version control, test/admin automation, and ide/project tools.
Unit testing is also a good idea- it provides documentation and security
when you revisit something years later. It also encourages continual
development and refactoring, since you aren''t so worried about breaking
things.
I''d recommend looking at things from a source perspective, not a
distributed application perspective. Distributed apps should be avoided
unless it absolutely makes sense due to complexity and performance reasons.
Core considerations are:
1. version control and classification of projects/modules
2. code structure (design, refactoring) and documentation
3. code inclusion techniques to project
4. automation (rake is a great tool for Ruby)
5. evolve your practices to fit your working style- everyone is different
1. Version Control and Classification
===========================First off, I''d recommend source control- cvs
or subversion.
http://www.pragmaticprogrammer.com/starter_kit/vc/index.html (one
of three books in the Pragmattic Starter Kit)
Then, you need to find a place for code. Not too many, or too few projects.
Maybe something like,
rails-utils
-all your simple rails utilities. subfolders are fine, but don''t
over do it. you generally checkin and checkout the entire module.
ruby-utils
-similar to rails_utilities, but for ruby as a whole
ruby-play
-hack-space/sandbox, to not make a mess of your nicely resuable
stuff. When something becomes more interesting, move to one of the
others. I put example code from mailing lists, etc. here for future
reference as well as my learning experiments,
<<projectX>>
-significant work gets it''s own project space. This would akin
to
the various things on rubyforge packaged as gems. In cvs, you could do
this as a subdirectory in a module, or a module by itself.
2. Code Structure and Documentation
===========================Documentation is critical for resuse, even with
yourself. You''ll forget
the purpose and nuances of the code, as well as it''s state, pretty
quickly if you write lots of code. Learn RDoc, and start using in your
codes comments right away.
More importantly, code needs to be written to be reusable, and
reusability can be hard- and even not wanted in certain cases.
From a file structure perspective, consider Rails unique needs. Rails
has certain requirements due to introspection and directory expectation
that need to conformed too (more on code inclusion techniques below).
This makes putting a controller and model in the ruby library path
unlikely to be successful- they need to know where they are in the
context of the rails directory structure.
I think this is fine, because view and controller logic are unlikely to
be very resuable anyhow, and there are many, many cool ruby techniques
for including reusable code into a framework. Generally, I don''t think
I''d want to (or need to) share controller across apps so much as factor
out the code, and share that. Controllers needs to uniquely represent
the application control flow and logic, and it would strange to find
reuse at a controller-level without creating difficult to maintain code.
Helpers are probably closer to resusable since they don''t do
control/flow logic so much.
What then, when resuability starts to make it''s needs known- you have
code in a controller that''s screaming "resuse me! I''m da
bomb!". The
code is talking to you, and you should listen.
Thankfully, Ruby is great for managing code structure (and resulting
file structures). Refactor, and put the code into a helper, or library
that''s included into the view or controller. If the application is
growing, and more resuse is needed, create another module or layer for
your application- have the controller talke to a service that bundles up
the functionality you want to resuse. Rails introduced an actionmailer
module recently. It wasn''t appropriate to put the logic in a
controller,
but rather to reference it. That type of design practice is how you''ll
best achieve reuse in rails- low coupling (minimal dependencies between
modules), high-cohesion (like functionality grouped together, which in
turn helps achieve low coupling and reuse), and DRY (don''t repeat
yourself).
In the case that you have something great that is very controler
specific, you may want to place your shareable controller code into a
module, and include that into a skeleton controller. Or create a
singleton (class << self). Or extend the base rails classes via your
included ruby file. But in most cases, you can aggregate the
functionality without needing to mixin a module, or extend the class
(see actionmailer again).
Needle helps with code reuse by enforcing good practice - high
modularity with good interfaces - and reducing/controlling coupling
between modules. However, good design practices can achieve most of the
same thing, and Needle adds a certain complexity. On the other hand,
having the environment explicitly define modularity and interfaces is
great- it helps push you to continually make the right choices.
Test-first development helps similarly, by continually forcing you to
use the code and refine the interfaces and modularity. There are a few
great artciles on DI with Needle and rails. Dave Thomas made an
interesting point on achieving DI without losing clarity of code ( a
problem with DI where the code now longer tells the whole story). It
sounds like Rails+Needle will be going in this direction. I''m pretty
keen on DI after working on a legacy Java codebase with 7 core
"singletons" creating the most obscure and horrid spagetti-flow
I''ve
ever seen.
Botton line- resuability is a design requirement that when present,
influences how you design and code. Mix-modules, aggregation, etc.
Different types of code have different successful design patterns. MVC,
as rails implements, is a great one. Helper classes, also great.
Aggregation/Composition is generally better for reuse then inheritence
(mix-ins are composition with automatic delegation more then
inheritence, so they don''t suffer from the same issues).
3. Code Inclusion
============Now, you need to include your code in your projects. with the goal
of
not "forking" by cutting and pasting. As mentioned above, certain
application frameworks may complicate this, in which case you need to
look at code structure. But you still need to get the code into the
project you are working on! Start simple (e.g. symlink your work
directory into the ruby library parth), and evolve. Here are some options:
1. use the ruby lib path to include your work directories. This
allows "require ...." into any script on your system. The downside to
this is visibility into your project space if you are continuing to
enhance the code while working on the project. Note that you can do this
via symlinks, environment variables, or in scripts themselves ($:
represents the load path. Add directories to it and you can require
away- though it''s probably not an ideal practice if avoidable).
e.g. $:.push File.dirname(__FILE__) puts the directory of the
current file into the loadpath. I often use it at the top of the main
ruby file for a package I have in my classpath.
You could either modify the lib path, or deploy your code into it.
While this is great for external code that your don''t modify (e.g. all
ruby libraries you download and install), it may not be so good for your
own work in progress where you are modifying your library code as much
as your app code. Then modifying the ruby lib path to include your work
is probably better. Currently I symlink my work directories to
/usr/local/lib/ruby/site_ruby/1.8/.
2. use symbolic links to include directories from your main work
directory (as checked out of cvs) into your project. Note: you may want
deployment directories for your utility code, so that work-in-progress
doesn''t break existing apps.
~/work/ruby_utilities - where you do the development
~/my_libs/ruby/ruby_utilities -where you depoy various
"builds"
to (not used by your work-in-progess, which is pointing to the work
directory)
The benefit of this approach is that you can modify the files
within the project your are working on, and you modify the source files
directly. This way, even if switching about 3 rails projects, the
"rails_utilities.rb" file in the project tree is the same file. This
can
also be done virtually by editors and ideas with project management
tools and browsers- you can include multiply projects into the same
workspace, hiding the fact they are in different directories.
Windows has symbolic links for directories- there are just no
tools included with windows to create them (the are called junctions).
http://www.sysinternals.com/ntw2k/utilities.shtml has a tool called
junction that I use a lot.
3. copy the actual files into the project...I''d only recommend this
if it''s automated nicely from a the actual work or deployment directory
and you don''t modify the copied code (maybe make it read-only). This is
an ugly option, and probably a bad idea without really good automation
for deloying and refreshing code. It also makes it harder to work on the
code at the same time your working on your project in a convenient
manner. However, some frameworks may not give you much of a choice due
to their structure or nature. This seems less likely in Ruby then in
Java. Also, option 2, symbolic links, may be a better option that makes
the framework happy. I''d worry about symlinks at the file level though-
that could be messy to maintain. I''d be more comfortable at the
directory level.
4. what might be cool is to develop a level of automation to package
your own code as gems, and then run your own local gems server, for you
own use. That would be pretty cool, enabling versions and providing a
higher-level deployment architecture (as opposed to the my_libs/ruby
directory mentioned above).
You probably want to start simply- maybe just deploy to the ruby
environment lib directory (/usr/local/lib/ruby/site_ruby/1.8/ in Unix)
on successful tests/builds (using rake). Or symlink your working
directories there (my current strategy) . The you can do "require
"rails_utilities/myutil" from anywhere.
Later, when more is going on, refine to something that fits you and your
code better (e.g. seperation of development and deployment directories).
4. Automation
===============Builds, cvs actions, deployments, rdoc generation, unit
testing...makes
all the best and useful practices automatic
5. Evolve Your Practices
==================The above suits my tastes- everyone is different. Also, the
volume and
nature of the code you write is going to effect practices a lot.
However, I think the core principles above are good ones (Pragmattic
Programmer Starter Kit is a great overview of most of the above), and
while it''s a bit of effort to get it in place initial, there is really
low overhead once that''s done. In fact, it easily pays for itself in
time-savings. For instance, my commiting to cvs, I don''t have to
pollute
my directory with mytest.rb.version1 etc. to save history in case I
break something. And once you have basic automation in place, all
actions are quicker then the manual alternatives, and the collection of
automation scripts provide both a source for the next script, as well as
great documentation and repeatability of your processes.
Oops. My response is longer then expected. Hope it helps. Helped me- I
just cleaned up my code while writing it. I should also note that I work
on 4 different machines in a given week, so cvs is essential.
Regards,
Nick
Luis G. Gómez wrote:
> Hi,
>
> Tonight I sat down to play arround with Rails like I have done for the
> last few days and I realized, being new at all of this framework and
> OO stuff, that it''d be great to be able to have a personal
repository
> of classes that I could share between different projects. This may
> sound obvious for most of you but OO is an approach that I''m
getting
> familiar with through Ruby. I know it is possible if I make the effort
> of creating well designed classes maintaining dependencies to a
> minimum, etc... but what about the big picture as far as how I use all
> of this from a practical point of view?
>
> How do experienced developpers do it? Do you usually keep a library of
> classes that you know well available for every project and then mix
> and match? Is there a way of maybe having a server "serve" these
> functionality so it can be used by my clients (web services?)? If so,
> have you seen a setup like this one?
>
> I''ve learnt most of what I know about programming because I enjoy
it
> but my background is in design so I don''t know how a
"freelance"
> developper would go about organizing his material. I''d like think
I
> can focus on an approach that will save me from repeating myself and
> feeling like I have done everything 100 times.
>
> For example, as far as Rails goes, say I''ve been using it for some
> time and have a collection of nice controllers scattered arround in
> various applications. How can I share these between apps while keeping
> the code in one place or at least a "master" in one place? I know
> Needle or Needle-like functionality is being integrated but don''t
know
> if this helps.
>
> Imagine having a Rails application with a stucture like this one (this
> is only for illustration purposses):
>
> /appsrv/
> /appsrv/cart/create
> /appsrv/cart/list
> /appsrv/cart/add_item
> /appsrv/cart/mod_item
> /appsrv/cart/...
>
> /appsrv/inventory/create
> /appsrv/inventory/list
> /appsrv/inventory/locations
> /appsrv/inventory/add_locations
> /appsrv/inventory/add_item
> /appsrv/inventory/mod_item
> /appsrv/inventory/...
>
> /appsrv/catalog/create
> /appsrv/catalog/add_item
> /appsrv/catalog/...
>
> Then being able to create an application (maybe even on a different
> server - a client''s server) and "calling" these
different controllers
> (mixing and matching). Maybe a particular client only needs to have
> inventory functionality so you only use that controller. I realize
> this has many performance and security complications (and probably
> more) but I''m dicussing conceptual approaches to structuring a
> developpers material for re-use and efficiency of development not
> necessarily propossing this as the right approach.
>
> Maybe Railing all of it is not the right approach and having organized
> folders with classes that I can share petween Rail apps is better. But
> then how do you consume these services or controllers from other
> servers? I don''t know....
>
> Do you mind sharing your opinions or recommendations on how one should
> or could approach development?
>
> Thank you,
>
> <lgomez>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
On Fri, Nov 26, 2004 at 03:49:24PM -0500, Nicholas Van Weerdenburg wrote: <snipage>> 2. use symbolic links to include directories from your main work > directory (as checked out of cvs) into your project. Note: you may want > deployment directories for your utility code, so that work-in-progress > doesn''t break existing apps. > ~/work/ruby_utilities - where you do the development > ~/my_libs/ruby/ruby_utilities -where you depoy various "builds" > to (not used by your work-in-progess, which is pointing to the work > directory) > The benefit of this approach is that you can modify the files > within the project your are working on, and you modify the source files > directly. This way, even if switching about 3 rails projects, the > "rails_utilities.rb" file in the project tree is the same file. This can > also be done virtually by editors and ideas with project management > tools and browsers- you can include multiply projects into the same > workspace, hiding the fact they are in different directories. > Windows has symbolic links for directories- there are just no > tools included with windows to create them (the are called junctions). > http://www.sysinternals.com/ntw2k/utilities.shtml has a tool called > junction that I use a lot. > 3. copy the actual files into the project...I''d only recommend this > if it''s automated nicely from a the actual work or deployment directory > and you don''t modify the copied code (maybe make it read-only). This is > an ugly option, and probably a bad idea without really good automation > for deloying and refreshing code. It also makes it harder to work on the > code at the same time your working on your project in a convenient > manner. However, some frameworks may not give you much of a choice due > to their structure or nature. This seems less likely in Ruby then in > Java. Also, option 2, symbolic links, may be a better option that makes > the framework happy. I''d worry about symlinks at the file level though- > that could be messy to maintain. I''d be more comfortable at the > directory level.<snipage> Great of you to take the time to write this all up and share Nicholas. Just /w/r/t the two suggestions above, I''d like to point out that if one is using subversion, externals definitions (the svn:externals prop) can come in very handy for tasks similar to what you outline above. More information at: http://svnbook.red-bean.com/en/1.1/ch07s03.html marcel -- Marcel Molina Jr. <marcel-WRrfy3IlpWYdnm+yROfE0A@public.gmane.org>
Thanks. Good points, and a good link. I plan to switch to subversion in the near future, once I''m a bit more comfortable with cvs. In a similar vein, I realized after sending I forgot to mention using CVS to synch code by checking out into multiple directories/projects and then doing updates/commits to keep the multiple copies synched (one of my original reasons for mentioning cvs). You can do this manually, by checking out at various levels in your project structure. But better yet, you can do a similar thing as mentioned by that subversion link by defining modules that include other modules (called ampersand modules)- so one checkout grabs everything. e.g. CVSROOT/modules entirerailsproject1 &railsproject1 &rails-utils &ruby-utils entirerailsproject2 &railsproject2 &rails-utils &ruby-utils cvs co entirerailsproject1 cvs co entirerailsproject1 gets the rails project plus the my personal libraries. The libraries are now duplicated, but they are relatively easy to synch via regular update/commits such that it shouldn''t be an issue. Modules can create nice aliases to project subdirectories, e.g. railsprojectdocs -a railsproject1/docs I''ll probably switch to this kind of management structure once I have a bit more ruby code. This is particulary good if working on multiple machines, since it doesn''t require you to update various symbolic links. And if working on a team, you don''t subject your team members to your symbolic link hacks. Thanks, Nick Marcel Molina Jr. wrote:>On Fri, Nov 26, 2004 at 03:49:24PM -0500, Nicholas Van Weerdenburg wrote: ><snipage> > > > >> 2. use symbolic links to include directories from your main work >>directory (as checked out of cvs) into your project. Note: you may want >>deployment directories for your utility code, so that work-in-progress >>doesn''t break existing apps. >> ~/work/ruby_utilities - where you do the development >> ~/my_libs/ruby/ruby_utilities -where you depoy various "builds" >>to (not used by your work-in-progess, which is pointing to the work >>directory) >> The benefit of this approach is that you can modify the files >>within the project your are working on, and you modify the source files >>directly. This way, even if switching about 3 rails projects, the >>"rails_utilities.rb" file in the project tree is the same file. This can >>also be done virtually by editors and ideas with project management >>tools and browsers- you can include multiply projects into the same >>workspace, hiding the fact they are in different directories. >> Windows has symbolic links for directories- there are just no >>tools included with windows to create them (the are called junctions). >>http://www.sysinternals.com/ntw2k/utilities.shtml has a tool called >>junction that I use a lot. >> 3. copy the actual files into the project...I''d only recommend this >>if it''s automated nicely from a the actual work or deployment directory >>and you don''t modify the copied code (maybe make it read-only). This is >>an ugly option, and probably a bad idea without really good automation >>for deloying and refreshing code. It also makes it harder to work on the >>code at the same time your working on your project in a convenient >>manner. However, some frameworks may not give you much of a choice due >>to their structure or nature. This seems less likely in Ruby then in >>Java. Also, option 2, symbolic links, may be a better option that makes >>the framework happy. I''d worry about symlinks at the file level though- >>that could be messy to maintain. I''d be more comfortable at the >>directory level. >> >> > ><snipage> > >Great of you to take the time to write this all up and share >Nicholas. Just /w/r/t the two suggestions above, I''d like to point out >that if one is using subversion, externals definitions (the svn:externals >prop) can come in very handy for tasks similar to what you outline above. > >More information at: >http://svnbook.red-bean.com/en/1.1/ch07s03.html > >marcel > >
Nicholas Van Weerdenburg wrote:> Hi Luis, > > Great question. It is a great idea to get an infrastructure in place- > that will encourage reuse and continued development of code you often > use. Without, you end up repeating yourself a lot or getting lost > among a raft of half finished code on your system. The following is my > take, which, I think, is pretty generic nowadays. The "Pragmatic > Starter Kit", > http://www.pragmaticprogrammer.com/starter_kit/index.html, is good > introduction to a number of the topics.This post was really great. If you have a second, you should put it up on the rails wiki so it can be in a more permanent location. I would do it, but since it is your baby I figured you might be somewhat particular about where and how it was posted. Thanks, Carl
I haven''t replied because I wanted to take some time to read and understand Nicholas'' response. I''ll post this on the wiki between tonight and tomorrow. Thank you. Luis Gómez -------------------------------- 4360 NW 107th Av. Suite 102 Miami, FL 33178 786.395.1490 lgomez-walYqSS8HwPCENZMoErytg@public.gmane.org Carl Youngblood wrote:> Nicholas Van Weerdenburg wrote: > >> Hi Luis, >> >> Great question. It is a great idea to get an infrastructure in place- >> that will encourage reuse and continued development of code you often >> use. Without, you end up repeating yourself a lot or getting lost >> among a raft of half finished code on your system. The following is my >> take, which, I think, is pretty generic nowadays. The "Pragmatic >> Starter Kit", >> http://www.pragmaticprogrammer.com/starter_kit/index.html, is good >> introduction to a number of the topics. > > > This post was really great. If you have a second, you should put it up > on the rails wiki so it can be in a more permanent location. I would do > it, but since it is your baby I figured you might be somewhat particular > about where and how it was posted. > > Thanks, > Carl > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Ok, I''ve posted this thread on rubyobrails.org. I hope none of you mind. If you do, feel free to edit/remove your sections. Nick, thank you very much for that response. Obviously it takes time to try and adopt one or more of these approaches but I have a much clearer idea of how I''d like to proceed. I wouln''t be surprised to find many developpers who would benefit from reading your response. You can find the post here: http://www.rubyonrails.org/show/TheBigPicture I took the liberty of formatting the text to make it aesier to read. Thanks! Luis G. Gómez wrote:> I haven''t replied because I wanted to take some time to read and > understand Nicholas'' response. I''ll post this on the wiki between > tonight and tomorrow. > > Thank you. > > Luis Gómez > -------------------------------- > > Carl Youngblood wrote: > >> Nicholas Van Weerdenburg wrote: >> >>> Hi Luis, >>> >>> Great question. It is a great idea to get an infrastructure in place- >>> that will encourage reuse and continued development of code you often >>> use. Without, you end up repeating yourself a lot or getting lost >>> among a raft of half finished code on your system. The following is >>> my take, which, I think, is pretty generic nowadays. The "Pragmatic >>> Starter Kit", >>> http://www.pragmaticprogrammer.com/starter_kit/index.html, is good >>> introduction to a number of the topics. >> >> >> >> This post was really great. If you have a second, you should put it >> up on the rails wiki so it can be in a more permanent location. I >> would do it, but since it is your baby I figured you might be somewhat >> particular about where and how it was posted. >> >> Thanks, >> Carl >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I''ll find this topic on the rails wiki and add these comments there, but this should probably also be addressed on the list: On Fri, 26 Nov 2004 15:49:24 -0500, Nicholas Van Weerdenburg <nick-mbAR5jBooqeEiqnLjJjuE/C9HSW9iNxf@public.gmane.org> wrote:> 3. copy the actual files into the project...I''d only recommend this > if it''s automated nicely from a the actual work or deployment directory > and you don''t modify the copied code (maybe make it read-only). This is > an ugly option, and probably a bad idea without really good automation > for deloying and refreshing code. It also makes it harder to work on the > code at the same time your working on your project in a convenient > manner. However, some frameworks may not give you much of a choice due > to their structure or nature. This seems less likely in Ruby then in > Java. Also, option 2, symbolic links, may be a better option that makes > the framework happy. I''d worry about symlinks at the file level though- > that could be messy to maintain. I''d be more comfortable at the > directory level.Actually, if you''re using proper source-control techniques (especially with a more modern SCS such as Subversion, since this doesn''t work as easily with CVS) copying the library into your project often _is_ the pefferable way to do things. Do some research on the concept of "vendor branches", and you''ll find that they make life much easier when you have dependencies on other libraries. Not only do they allow you to continually update those other libraries (or upgrade them as they are updated by the vendor), but you can also apply per-project customizations without having to lose the context of the original library code---when that code gets updated, you simply merge the updates with your customized code. -- Regards, John Wilger ----------- Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat. "I don''t know," Alice answered. "Then," said the cat, "it doesn''t matter." - Lewis Carrol, Alice in Wonderland
Thanks. Carl Youngblood wrote:> Nicholas Van Weerdenburg wrote: > >> Hi Luis, >> >> Great question. It is a great idea to get an infrastructure in place- >> that will encourage reuse and continued development of code you often >> use. Without, you end up repeating yourself a lot or getting lost >> among a raft of half finished code on your system. The following is >> my take, which, I think, is pretty generic nowadays. The "Pragmatic >> Starter Kit", >> http://www.pragmaticprogrammer.com/starter_kit/index.html, is good >> introduction to a number of the topics. > > > This post was really great. If you have a second, you should put it > up on the rails wiki so it can be in a more permanent location. I > would do it, but since it is your baby I figured you might be somewhat > particular about where and how it was posted. > > Thanks, > Carl > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Cool. Looks good. In general, it''s probably better to remove the email-thread stuff, and leave the content anonymous/public-domain. That''ll make it more likely for people to feel comfortable refactoring/fixing content. If someone wanted to do that, I have no problems with that- I give my OK for non-attributed use. Or I''ll look into it myself in a week or so. I noticed there is a good info on the wiki under edge rails on using subversion. Look here: http://www.rubyonrails.org/show/EdgeRails This talks about keeping rails up-to-date within your projects. I agree it can take a bit to get up-to-speed on cvs, etc, but it''s worthwhile. Symlinks might be a good starting point before getting into that- it keeps your library code in one place, and helps avoid duplication. It may make sense to go to subversion since rails itself is now in subversion. Thanks, Nick Luis G. Gómez wrote:> Ok, I''ve posted this thread on rubyobrails.org. I hope none of you > mind. If you do, feel free to edit/remove your sections. > > Nick, thank you very much for that response. Obviously it takes time > to try and adopt one or more of these approaches but I have a much > clearer idea of how I''d like to proceed. I wouln''t be surprised to > find many developpers who would benefit from reading your response. > > You can find the post here: http://www.rubyonrails.org/show/TheBigPicture > > I took the liberty of formatting the text to make it aesier to read. > > Thanks! > > Luis G. Gómez wrote: > >> I haven''t replied because I wanted to take some time to read and >> understand Nicholas'' response. I''ll post this on the wiki between >> tonight and tomorrow. >> >> Thank you. >> >> Luis Gómez >> -------------------------------- >> >> Carl Youngblood wrote: >> >>> Nicholas Van Weerdenburg wrote: >>> >>>> Hi Luis, >>>> >>>> Great question. It is a great idea to get an infrastructure in >>>> place- that will encourage reuse and continued development of code >>>> you often use. Without, you end up repeating yourself a lot or >>>> getting lost among a raft of half finished code on your system. The >>>> following is my take, which, I think, is pretty generic nowadays. >>>> The "Pragmatic Starter Kit", >>>> http://www.pragmaticprogrammer.com/starter_kit/index.html, is good >>>> introduction to a number of the topics. >>> >>> >>> >>> >>> This post was really great. If you have a second, you should put it >>> up on the rails wiki so it can be in a more permanent location. I >>> would do it, but since it is your baby I figured you might be >>> somewhat particular about where and how it was posted. >>> >>> Thanks, >>> Carl >>> _______________________________________________ >>> Rails mailing list >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Hi John, Yes, I originally ment to mention that- it was the main reason for mentioning CVS :). I wrote a followup email on that after Marcel mentioned doing that with subversion, and that made it onto the wiki. I didn''t get into vendor branches, Feel free to fix/add comments to the wiki. In my last email to the list, I recommended stripping out attributions to encourage refactoring and additions in traditional wiki-style. Thanks, Nick John Wilger wrote:>I''ll find this topic on the rails wiki and add these comments there, >but this should probably also be addressed on the list: > >On Fri, 26 Nov 2004 15:49:24 -0500, Nicholas Van Weerdenburg ><nick-mbAR5jBooqeEiqnLjJjuE/C9HSW9iNxf@public.gmane.org> wrote: > > >> 3. copy the actual files into the project...I''d only recommend this >>if it''s automated nicely from a the actual work or deployment directory >>and you don''t modify the copied code (maybe make it read-only). This is >>an ugly option, and probably a bad idea without really good automation >>for deloying and refreshing code. It also makes it harder to work on the >>code at the same time your working on your project in a convenient >>manner. However, some frameworks may not give you much of a choice due >>to their structure or nature. This seems less likely in Ruby then in >>Java. Also, option 2, symbolic links, may be a better option that makes >>the framework happy. I''d worry about symlinks at the file level though- >>that could be messy to maintain. I''d be more comfortable at the >>directory level. >> >> > >Actually, if you''re using proper source-control techniques (especially >with a more modern SCS such as Subversion, since this doesn''t work as >easily with CVS) copying the library into your project often _is_ the >pefferable way to do things. Do some research on the concept of >"vendor branches", and you''ll find that they make life much easier >when you have dependencies on other libraries. Not only do they allow >you to continually update those other libraries (or upgrade them as >they are updated by the vendor), but you can also apply per-project >customizations without having to lose the context of the original >library code---when that code gets updated, you simply merge the >updates with your customized code. > > >
On Tue, 30 Nov 2004, John Wilger wrote:> Actually, if you''re using proper source-control techniques (especially > with a more modern SCS such as Subversion, since this doesn''t work > as easily with CVS) copying the library into your project often _is_ > the pefferable way to do things. Do some research on the concept of > "vendor branches"....In fact, vendor branches are a bit more difficult with CVS, but not that hard to deal with once you get the hang of it. I''ve been doing this for years. On my current system, for example, I build several C libraries, apache, php (don''t ask), and various php and ruby libraries (incuding ActiveRecord) from source I keep in CVS with the rest of my project, and I''ve been considering even moving ruby in there. This ensures that I''m testing and deploying my system on the same support code. This, BTW, is a very good reason for keeping available non-gems versions of things like rails. Having stuff available only in another package management system forces me to unpackage it so that I can "re-package" it in my system. cjs -- Curt Sampson <cjs-gHs2Wiolu3leoWH0uzbU5w@public.gmane.org> +81 90 7737 2974 http://www.NetBSD.org Make up enjoying your city life...produced by BIC CAMERA
On Wed, 1 Dec 2004, Nicholas Van Weerdenburg wrote:> Look here: > http://www.rubyonrails.org/show/EdgeRails > This talks about keeping rails up-to-date within your projects.Very interesting. However: Because if you are [using subversion], you will much rather use the power of svn:externals. Using it, you tell subversion that a certain part of your project can be found on another subversion server. Upon doing an svn update, subversion will also automatically bring the Rails components up to their latest revision. This is not typically what people want to do, since the subversion committers are of course not running your project''s test suite before checking in subversion changes, and thus their changes may break your project. It would be nice if someone would add instructions to this page for how to set your external link to a particular version of that external, and how to do the upgrade sequence. It would look something like this: 1. Set the external link to the rails components to the release tag of the version of rails you were previously using. 2. Update your checkout, run the tests, and make sure everything works fine. Fix any problems and commit the changes. 3. Do a temporary change of the external link to, say, the head version of a rails component. Run your test suite. 4. If you can''t fix all your tests, bail at this point, leaving the default version of the component as it was. 5. If there are no problems, or you can fix the problems, do a commit that checks in any changes that you made and at the same time sets the default checkout version of that rails component to whatever you had temporarially checked out. This gives you a system that''s ready for a production release at any time, while letting you easily try out newer versions of rails. The important thing is that in step 3, that change of version you''re pulling in is for your checkout only, and doesn''t affect anyone else, so that your co-worker, who updates his checkout for a release two minutes later is getting the latest tested version, not some untested stuff. cjs -- Curt Sampson <cjs-gHs2Wiolu3leoWH0uzbU5w@public.gmane.org> +81 90 7737 2974 http://www.NetBSD.org Make up enjoying your city life...produced by BIC CAMERA
Good points. I''m just learning subversion this week, and I''ll probably try to integrate to the rails svn next week and see how it all works. Nick Curt Sampson wrote:>On Wed, 1 Dec 2004, Nicholas Van Weerdenburg wrote: > > > >>Look here: >>http://www.rubyonrails.org/show/EdgeRails >>This talks about keeping rails up-to-date within your projects. >> >> > >Very interesting. However: > > Because if you are [using subversion], you will much rather use the > power of svn:externals. Using it, you tell subversion that a certain > part of your project can be found on another subversion server. Upon > doing an svn update, subversion will also automatically bring the > Rails components up to their latest revision. > >This is not typically what people want to do, since the subversion >committers are of course not running your project''s test suite before >checking in subversion changes, and thus their changes may break your >project. > >It would be nice if someone would add instructions to this page for how >to set your external link to a particular version of that external, and >how to do the upgrade sequence. It would look something like this: > > 1. Set the external link to the rails components to the release tag > of the version of rails you were previously using. > > 2. Update your checkout, run the tests, and make sure everything > works fine. Fix any problems and commit the changes. > > 3. Do a temporary change of the external link to, say, the head > version of a rails component. Run your test suite. > > 4. If you can''t fix all your tests, bail at this point, leaving the > default version of the component as it was. > > 5. If there are no problems, or you can fix the problems, do a > commit that checks in any changes that you made and at the same > time sets the default checkout version of that rails component to > whatever you had temporarially checked out. > >This gives you a system that''s ready for a production release at any time, >while letting you easily try out newer versions of rails. > >The important thing is that in step 3, that change of version you''re >pulling in is for your checkout only, and doesn''t affect anyone else, so >that your co-worker, who updates his checkout for a release two minutes >later is getting the latest tested version, not some untested stuff. > >cjs > >