Applications used in the Rails video?

Rails
1

Hi all,

I just watched the rail video:

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

2

cocoaMySQL-SBG and textmate

3

On Apr 22, 2006, at 5:00 PM, aviram carmi wrote:

Ruby on Rails — A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.

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

4

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

5

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

6

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

7

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

8

On Apr 23, 2006, at 15:27, Alex Y. wrote:

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

9

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

10

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

11

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

– fxn

12

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.

13

On Sun, 23 Apr 2006, Xavier N. 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

14

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

15

On Apr 24, 2006, at 18:52, Steve K. 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

16

On Apr 24, 2006, at 9:52 AM, Steve K. 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. :slight_smile:

–
– Tom M.

17

On Apr 24, 2006, at 20:32, Tom M. 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

18

On Apr 24, 2006, at 11:20 AM, Xavier N. 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 M.

19

On Apr 24, 2006, at 11:53 PM, Xavier N. wrote:

On Apr 24, 2006, at 20:32, Tom M. 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 M.