Rails - Apr 2006 - Applications used in the Rails video?

Hi all,

I just watched the rail video:

http://www.rubyonrails.org/media/video/rails_take2_with_sound.mov

I am just curious. I can tell that the video was done on a Mac, but I 
cannot tell which applications were used for editing the code, and for 
interfacing with MySQL database.

As far as editing source code, I normally use BBEdit (I''ve used it
since
1994), but the editor used in the video looks very nice, anyone knows 
what it is?

I have MySQL installed on my Mac, but the MySQL Administrator does not 
look like the application which was used in the video. again, anyone 
knows which app was used in the video to access the MySQL databasae?

Thanks in advance,

-avi

-- 
Posted via http://www.ruby-forum.com/.

cocoaMySQL-SBG and textmate

-- 
Posted via http://www.ruby-forum.com/.

On Apr 22, 2006, at 5:00 PM, aviram carmi wrote:
> http://www.rubyonrails.org/media/video/rails_take2_with_sound.mov
>
> I am just curious. I can tell that the video was done on a Mac, but I
> cannot tell which applications were used for editing the code, and for
> interfacing with MySQL database.
TextMate for editing and CocoaMySQL for the DB front end.

That said, if he redid the video again, he''s use migrations for the
DB work, so I doubt he''s use CocoaMySQL for more than to create the
DB instance.

-- 
-- Tom Mornini

Tom Mornini wrote:
> That said, if he redid the video again, he''s use migrations for
the
> DB work, so I doubt he''s use CocoaMySQL for more than to create
the
> DB instance.
Thanks,

I''ve searched the forum for "migrations", and from what I can
tell, it
is a framework for interacting with the database, if this is correct, 
why would you want to use that (i.e. write code) over a nice GUI 
application such as CocoaMySQL for making small one time changes to the 
database? (which makes me think that I am wrong about migrations...)


-avi

-- 
Posted via http://www.ruby-forum.com/.

On Sun, 2006-04-23 at 02:43 +0200, aviram carmi wrote:
> Tom Mornini wrote:
> > That said, if he redid the video again, he''s use migrations
for the
> > DB work, so I doubt he''s use CocoaMySQL for more than to
create the
> > DB instance.
> 
> Thanks,
> 
> I''ve searched the forum for "migrations", and from what
I can tell, it
> is a framework for interacting with the database, if this is correct, 
> why would you want to use that (i.e. write code) over a nice GUI 
> application such as CocoaMySQL for making small one time changes to the 
> database? (which makes me think that I am wrong about migrations...)
----
you''ll figure it out soon enough.

when I initially started with rails, it represented a layer of
complexity that I didn''t want to deal with.

when you want to set up testing or production, or start developing on a
home system and deploy to a server, it becomes real obvious.

Craig

On Sun, 23 Apr 2006, aviram carmi wrote:
> I''ve searched the forum for "migrations", and from what
I can tell, it
> is a framework for interacting with the database, if this is correct,
> why would you want to use that (i.e. write code) over a nice GUI
> application such as CocoaMySQL
Because migrations are stepwise pieces that can be checked into a SCM like 
Subversion.  That way you get the benefit of database-agnostic changes 
with all the benefits of version control.

That means that your entire development team, or even just a number of 
computers you might be using (say, desktop, notebook, and server) can all 
have their database schemas up to date.

--Jim

On Apr 23, 2006, at 2:56, Jim Zajkowski wrote:
> On Sun, 23 Apr 2006, aviram carmi wrote:
>
>> I''ve searched the forum for "migrations", and from
what I can
>> tell, it
>> is a framework for interacting with the database, if this is correct,
>> why would you want to use that (i.e. write code) over a nice GUI
>> application such as CocoaMySQL
>
> Because migrations are stepwise pieces that can be checked into a  
> SCM like Subversion.  That way you get the benefit of database- 
> agnostic changes with all the benefits of version control.
>
> That means that your entire development team, or even just a number  
> of computers you might be using (say, desktop, notebook, and  
> server) can all have their database schemas up to date.
I don''t understand that argument. As far as version control is  
concerned, which is the difference with having a single schema.sql  
under version control as usual?

This is a nice article explaining the benefits of migrations:

   The Joy of Migrations
   http://glu.ttono.us/articles/2005/10/27/the-joy-of-migrations

-- fxn

Xavier Noria wrote:
> I don''t understand that argument. As far as version control is  
> concerned, which is the difference with having a single schema.sql  
> under version control as usual?
Often migrations won''t just be schema definitions - they may well also 
include data reformatting.  In a case like that, you definitely can''t 
get away with just a schema.sql, you *need* a code level description of 
the mapping in each direction.

-- 
Alex

On Apr 23, 2006, at 15:27, Alex Young wrote:
> Xavier Noria wrote:
>> I don''t understand that argument. As far as version control is
>> concerned, which is the difference with having a single  
>> schema.sql  under version control as usual?
> Often migrations won''t just be schema definitions - they may well
> also include data reformatting.  In a case like that, you  
> definitely can''t get away with just a schema.sql, you *need* a
code
> level description of the mapping in each direction.
Sure, schema.sql and migrations are different. I loosely used the  
name "schema.sql" because I replied to a message that mentioned a  
database schema. But that was not my point. My remark was about this  
paragraph:
> That means that your entire development team, or even just a number  
> of computers you might be using (say, desktop, notebook, and  
> server) can all have their database schemas up to date.
This is not a feature of migrations themselves, it is a consequence  
of having the database schema under a version control system.

-- fxn

Xavier Noria wrote:
> This is not a feature of migrations themselves, it is a consequence of 
> having the database schema under a version control system.
True, however it does help if you need to run multiple versions of a 
database on multiple machines.  This can and will happen and migrations 
make it a much, much happier prospect than pure SQL files.  I believe 
the original poster was trying to allude to the fact that it''s much 
easier to manage "versions" of your database across multiple boxes
using
migrations *and* version control.

Xavier Noria wrote:
> Sure, schema.sql and migrations are different. I loosely used the  name 
> "schema.sql" because I replied to a message that mentioned a 
database
> schema. But that was not my point. My remark was about this  paragraph:
> 
>> That means that your entire development team, or even just a number  
>> of computers you might be using (say, desktop, notebook, and  server) 
>> can all have their database schemas up to date.
> 
> This is not a feature of migrations themselves, it is a consequence  of 
> having the database schema under a version control system.
The point is that if you only have the schema defined at certain points 
in time, definitions of the schema before and after a change give you no 
information about how to transition from one to another.  Migrations 
give you a very handy way of encapsulating that.

-- 
Alex

On Sun, 23 Apr 2006, Xavier Noria wrote:
> My remark was about this paragraph:
>
>> That means that your entire development team, or even just a number of 
>> computers you might be using (say, desktop, notebook, and server) can
all
>> have their database schemas up to date.
>
> This is not a feature of migrations themselves, it is a consequence of
having
> the database schema under a version control system.
I enjoy selective quoting as much as everyone else, but you should have 
included the paragraph above it:
> Because migrations are stepwise pieces that can be checked into a SCM 
> like Subversion.
Note the word "stepwise."  You do not get update steps with a simply 
checked-in schema.sql file.

But the real point is that I was greatly simplifying why you would want to 
use migrations for someone who wanted to know why he should look into 
them.  I was not posting someone you to come along and pick apart single 
phrases because it wasn''t 100% correct, or correct in all cases.  Your 
argument is like someone complaining that the teacher isn''t using the
full
relativity forumlas when teaching newtonian physics to a bunch of 
highschool students.

--Jim

On Apr 24, 2006, at 16:31, Jim Zajkowski wrote:
> On Sun, 23 Apr 2006, Xavier Noria wrote:
>
>> My remark was about this paragraph:
>>
>>> That means that your entire development team, or even just a  
>>> number of computers you might be using (say, desktop, notebook,  
>>> and server) can all have their database schemas up to date.
>>
>> This is not a feature of migrations themselves, it is a  
>> consequence of having
>> the database schema under a version control system.
>
> I enjoy selective quoting as much as everyone else, but you should  
> have included the paragraph above it:
Yeah, that was a reply to a reply where I tried to be brief, I quoted  
the rest in the real reply.
>> Because migrations are stepwise pieces that can be checked into a  
>> SCM like Subversion.
>
> Note the word "stepwise."  You do not get update steps with a  
> simply checked-in schema.sql file.
You can get that using version control revisions. If you check out  
revision 54 you get back to the schema as it was in 54. And most of  
the times you want to go back in the application as well, because it  
is rare that schema in revision 54 works nicely with an application  
in revision 73 using an schema from revision 70.

Note that *I wasn''t claiming maintenance is comparable*. I claimed  
that the fact that "stepwise" evolution of schemas is easier is  
orthogonal to the fact that the team or several computers can stay in  
sync with that data, we did that before migrations.
> But the real point is that I was greatly simplifying why you would  
> want to use migrations for someone who wanted to know why he should  
> look into them.  I was not posting someone you to come along and  
> pick apart single phrases because it wasn''t 100% correct, or  
> correct in all cases.  Your argument is like someone complaining  
> that the teacher isn''t using the full relativity forumlas when  
> teaching newtonian physics to a bunch of highschool students.
Please don''t take it personally, I am very sorry if you did. That was  
not my intention!

I just wanted to clarify a point in that mail where I thought  
confusion could arise, that''s standard in technical forums. I mean,  
if I write something false, inaccurate, or that needs some additional  
comment (in my view that particular point of that reply falls in the  
last case), I want people to prove me wrong, to correct or improve  
the mail, because the only thing that matters to me is the OP,  
readers, and the archives.

Please excuse me again.

-- fxn

PS: You mentioned physics, I happen to have background in math, where  
truth and correctness is above individuals generally speaking,  
correcting arguments and being corrected is very normal and expected.

Schemas in version control do not encapsulate the logic to preserve 
existing data and alter data to make it conform to the schema changes. 
Migrations do, and  in both directions.

When you revert an application from version 73 to version 54, of course 
you want to roll back to the schema as it existed in version 54. But you 
don''t want to roll the data back. If you have a running app with lots
of
important data, let''s say at rev 61 you replaced a text field with an 
integer field that points to a lookup table.

A migration would not just be where you put the field change and the 
creation of the lookup table schema, but also where you put a snippet 
that initially populates the lookup table and another snippet that reads 
through existing records old entries and sets the lookup field before 
deleting the old text column. The same migration, if done right, would 
contain all the logic to do the reverse in the event the application 
gets rolled back, setting the text field based on the contents of the 
lookup field before deleting the lookup field and lookup table.

A versioned schema doesn''t do that. Simply recreating the database with
the old schema would result in data loss. This is the very sort of 
situation that keeps DBAs busy hitting programmers upside the head and 
storming back to their desks to write a custom SQL script or do a bunch 
of stuff in their fancy ER tools for the sole purpose of gently altering 
the schema in steps and massaging the existing data along the way so 
that the stuff that was stored differently in rev 54 gets converted 
instead of lost on its way down from rev 73.

Xavier Noria wrote:
> On Apr 24, 2006, at 16:31, Jim Zajkowski wrote:
...
>>
>> Note the word "stepwise."  You do not get update steps with a
>> simply checked-in schema.sql file.
> 
> You can get that using version control revisions. If you check out
> revision 54 you get back to the schema as it was in 54. And most of
> the times you want to go back in the application as well, because it
> is rare that schema in revision 54 works nicely with an application
> in revision 73 using an schema from revision 70.
> 
> Note that *I wasn''t claiming maintenance is comparable*. I claimed
> that the fact that "stepwise" evolution of schemas is easier is
> orthogonal to the fact that the team or several computers can stay in
> sync with that data, we did that before migrations.
> 
>> But the real point is that I was greatly simplifying why you would  
>> want to use migrations for someone who wanted to know why he should  
>> look into them.  I was not posting someone you to come along and  
>> pick apart single phrases because it wasn''t 100% correct, or  
>> correct in all cases.  Your argument is like someone complaining  
>> that the teacher isn''t using the full relativity forumlas when
>> teaching newtonian physics to a bunch of highschool students.
> 
> Please don''t take it personally, I am very sorry if you did. That
was
> not my intention!
> 
> I just wanted to clarify a point in that mail where I thought
> confusion could arise, that''s standard in technical forums. I
mean,
> if I write something false, inaccurate, or that needs some additional
> comment (in my view that particular point of that reply falls in the
> last case), I want people to prove me wrong, to correct or improve
> the mail, because the only thing that matters to me is the OP,
> readers, and the archives.
> 
> Please excuse me again.
> 
> -- fxn
> 
> PS: You mentioned physics, I happen to have background in math, where
> truth and correctness is above individuals generally speaking,
> correcting arguments and being corrected is very normal and expected.

-- 
Posted via http://www.ruby-forum.com/.

On Apr 24, 2006, at 9:52 AM, Steve Koppelman wrote:
> Schemas in version control do not encapsulate the logic to preserve
> existing data and alter data to make it conform to the schema changes.
> Migrations do, and in both directions.
Well written, and correct in every sense.

The most important distinction, pointed out by several, is
that migrations migrate structure *and* data! Also, DB
independence is very valuable! No need to setup PostgreSQL
or MySQL on your laptop, just use SQLite!

With migrations, nobody ever needs to ask (or answer) the
question:

   "How do I create the schema and initialize it with data."

Think about it! Joining a Rails development team? No problem:

1) Check out the code
2) rake migrate
3) rake
4) No errors? Great, get busy
5) Errors? Track them down using tools above
6) Realize that if this wasn''t a Rails project,
    you''d still be wondering how to get started.

Very cool.

If a Rails developer isn''t using migrations, it''s not due
to cleverness, but stubbornness.

I''m qualified to comment, because I was a couple of months
late to migrations. :-)

-- 
-- Tom Mornini

On Apr 24, 2006, at 18:52, Steve Koppelman wrote:
> A versioned schema doesn''t do that. Simply recreating the database
> with
> the old schema would result in data loss. This is the very sort of
> situation that keeps DBAs busy hitting programmers upside the head and
> storming back to their desks to write a custom SQL script or do a  
> bunch
> of stuff in their fancy ER tools for the sole purpose of gently  
> altering
> the schema in steps and massaging the existing data along the way so
> that the stuff that was stored differently in rev 54 gets converted
> instead of lost on its way down from rev 73.
I would like to ask how do you separate initial development data from  
initial production data.

Before migrations I had data loaders for development, written in Ruby  
to leverage AR and run with script/runner. A task recreated the  
schema and run the dev loaders, and another created the schema and  
run the prod loaders. Most of those loaders had no sense for  
production, think a product catalog, which in development may be  
filled with fake entries.

If you mix schema creation and data loading in migrations, how do you  
separate those kinds of data so that rake migrate knows what to load?

-- fxn

On Apr 24, 2006, at 11:20 AM, Xavier Noria wrote:
> On Apr 24, 2006, at 18:52, Steve Koppelman wrote:
>
>> A versioned schema doesn''t do that. Simply recreating the
database
>> with
>> the old schema would result in data loss. This is the very sort of
>> situation that keeps DBAs busy hitting programmers upside the head  
>> and
>> storming back to their desks to write a custom SQL script or do a  
>> bunch
>> of stuff in their fancy ER tools for the sole purpose of gently  
>> altering
>> the schema in steps and massaging the existing data along the way so
>> that the stuff that was stored differently in rev 54 gets converted
>> instead of lost on its way down from rev 73.
>
> I would like to ask how do you separate initial development data  
> from initial production data.
>
> Before migrations I had data loaders for development, written in  
> Ruby to leverage AR and run with script/runner. A task recreated  
> the schema and run the dev loaders, and another created the schema  
> and run the prod loaders. Most of those loaders had no sense for  
> production, think a product catalog, which in development may be  
> filled with fake entries.
>
> If you mix schema creation and data loading in migrations, how do  
> you separate those kinds of data so that rake migrate knows what to  
> load?
I use migrations for anything that *belongs to the application*, and  
fixtures for anything that belongs to development and/or testing.

-- 
-- Tom Mornini

On Apr 24, 2006, at 20:32, Tom Mornini wrote:
> I use migrations for anything that *belongs to the application*,  
> and fixtures for anything that belongs to development and/or testing.
I see. Tom, do you have separate sets for dev and testing? Where do  
you put the fixtures and how do you load them?

-- fxn

On Apr 24, 2006, at 11:53 PM, Xavier Noria wrote:
> On Apr 24, 2006, at 20:32, Tom Mornini wrote:
>
>> I use migrations for anything that *belongs to the application*,  
>> and fixtures for anything that belongs to development and/or testing.
>
> I see. Tom, do you have separate sets for dev and testing? Where do  
> you put the fixtures and how do you load them?
I have migrations that load application data, and fixtures that load  
development and test data. I''ve found that it''s not too hard
to
create fixtures that have data applicable to unit tests, functional  
tests, and development.

Fixtures go in test/fixures/

You can load them via:

   rake db:fixtures:load

-- 
-- Tom Mornini