Forum: Ruby on Rails Applications used in the Rails video?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
(unknown) (Guest)
on 2006-04-23 02:00
Hi all,

I just watched the rail video:

http://www.rubyonrails.org/media/video/rails_take2...

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
65c7c3dd95869e1430a260b049eabd51?d=identicon&s=25 Damian Legassick (dlg)
on 2006-04-23 02:06
cocoaMySQL-SBG and textmate
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-23 02:10
(Received via mailing list)
On Apr 22, 2006, at 5:00 PM, aviram carmi wrote:

> http://www.rubyonrails.org/media/video/rails_take2...
>
> 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
(unknown) (Guest)
on 2006-04-23 02:43
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
C1e5a9e9344b6d31b9df7303e6dc378a?d=identicon&s=25 Craig White (Guest)
on 2006-04-23 02:53
(Received via mailing list)
On Sun, 2006-04-23 at 02:43 +0200, aviram carmi wrote:
> 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
0004e098c1882b1245ab74822fb7b725?d=identicon&s=25 Jim Zajkowski (Guest)
on 2006-04-23 02:56
(Received via mailing list)
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
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2006-04-23 10:40
(Received via mailing list)
On Apr 23, 2006, at 2:56, Jim Zajkowski wrote:

> 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...

-- fxn
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-04-23 15:27
(Received via mailing list)
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.
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2006-04-23 20:06
(Received via mailing list)
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
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-04-23 20:22
(Received via mailing list)
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.
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-04-24 08:04
(Received via mailing list)
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.
0004e098c1882b1245ab74822fb7b725?d=identicon&s=25 Jim Zajkowski (Guest)
on 2006-04-24 16:35
(Received via mailing list)
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
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2006-04-24 17:43
(Received via mailing list)
On Apr 24, 2006, at 16:31, Jim Zajkowski wrote:

>> 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.
34f5b045aec62235c17458650ea75353?d=identicon&s=25 Steve Koppelman (hatless)
on 2006-04-24 18:52
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.
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-24 19:04
(Received via mailing list)
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
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2006-04-24 20:22
(Received via mailing list)
On Apr 24, 2006, at 18:52, Steve Koppelman wrote:

> 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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-24 20:34
(Received via mailing list)
On Apr 24, 2006, at 11:20 AM, Xavier Noria wrote:

>> altering
> 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
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2006-04-25 08:56
(Received via mailing list)
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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-25 10:04
(Received via mailing list)
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
This topic is locked and can not be replied to.