TextMate and the Mac Dashboard
As you get more proficient with rails, the keyboard shortcuts in TextMate really start to help out. The challenge is memorizing all of them. I did not want to print a cheatsheet and keep it by my desk. I wanted something quick that would come up and then go away. Then the Mac dashboard came to mind.
Wouldn't it be nice to hit F12 and the cheatsheet comes up, hit it again and it goes away? So I did just that. And so that you do not have to do this yourself, I have inluded them for you to download.
Terminal and AppleScript
I mentioned that I like to have four terminal windows going while I code in Rails. script/console, mongrel console, breakpointer, tail of development.log.
So how do you get all these windows going every time you get started on Rails. It is a pain having to start a new windows for these. I could write a shell script I guess, but being a Mac, you have AppleScript.
I wrote a script that prompts for the rails app root folder and from there Textmate starts with that folder, Terminal starts and the four Terminal windows mentioned earlier, show up all running the appropriate processes. I even color coded the windows so that I can quickly orient myself.
I am enclosing the AppleScript source here. It is in source not a finished applescript because you might need to change the script to tweak it for your environment.
Anyway, hope you find these helpful.
Download
Dashboard Cheat Sheet Widget and Terminal AppleScript source.
Monday, December 18, 2006
Sunday, December 17, 2006
The development environment
Get a Mac
I started working on the first apps with a Windows machine. It was OK, I could get going, but none of the tools suited me. I rationalized that if I was going to go on this Rails trip, getting there would be half the fun at least. So I was going to ride in style. I got a 15" Mac Book Pro, a 24" LCD and I was ready to rock.
Software
Next comes the software to use. I started with Locomotive and TextMate, but Locomotive pretty soon starts making you look too newbie. I was getting ready for downloading the source and installing. At first I was aprehensive because I am all about focus, and the thought of spending valuable time in sys admin setup instead of Rails learning was dangerously derailing me. So I stuck it out with Locomotive until I got an app going. And I did.
Lesson learned
But given what I know now, I would have been served best by downloading the source and compiling it. I would have started with the setup I have today. And that is:
- Ruby 1.8.5
- Rails 1.1.6 (or edge rails if I feel like playing around)
- Mongrel
- MySQL
- Terminal (mulitple windows -- more on this later)
- TextMate
TextMate is nice in that you have nice syntax coloring and other items. I do not like the slow search, but I am getting to the point where I do not need to constantly search across files -- less code refactoring :).
Terminal
Given that there is really no IDE environment for Rails yet (not one that suits me anyway), you end up having to rely on the Terminal window quite a bit. Whenever I am coding I have four windows up:
- script/console
- web server console (mongrel)
- breakpointer
- development.log tail -f
The script/console is huge for newbies. And I continue to use. Basically, you get the Rails environment in a console and can test things out to see what is returned, etc. A big one for newbies is the object.methods method. Also object.class. Between those two methods you stop pulling your hair out as to why something does not work. Maybe you have the wrong object, maybe that object does not support the method you wanted.
Anyway, I can not say enough about the script/console. Have it running always.
web server console is nice to have. I would not run mongrel in hidden mode. Warnings, some mailers, and other activity shows up. The warnings are good as they help you quickly see something that you might want to clean up in your code.
breakpointer
When everything else breaks :) use breakpoint() in your code, hit the web page URL and watch for irb to kick in in the breakpointer window. There again you can evaluate variables by typing them (no IDE remember), or you can put several breakpoint()s in your code and press control-D to move to the next breakpoint. Then you can evaluate more variables as you move through the code. By evaluate, I mean, type the variable or object.method on the irb screen and see what comes back. Even the object.class, or object.methods gives you an indication if you used the wrong object to begin with.
development.log
by tailing the development log, you get to see what is actually being sent to the SQL server. It is interesting to watch how Rails translates the stuff you enter into SQL. Sometimes, you pass conditions that you think are OK, but forgot the previous filters you might have put on the object. Anyway, it is another debugging tool and another way for you to learn what is happening behind the scenes.
That is it for the development environment. You need a good dev environment and a whole library of books. I am not kidding when I said I bought them all. I even found a couple of books on Amazon that are not yet out but I ordered anyway. Nothing like reading Ruby and Rails from different authors' perspectives. But books review and opinions will be my next topic.
I started working on the first apps with a Windows machine. It was OK, I could get going, but none of the tools suited me. I rationalized that if I was going to go on this Rails trip, getting there would be half the fun at least. So I was going to ride in style. I got a 15" Mac Book Pro, a 24" LCD and I was ready to rock.
Software
Next comes the software to use. I started with Locomotive and TextMate, but Locomotive pretty soon starts making you look too newbie. I was getting ready for downloading the source and installing. At first I was aprehensive because I am all about focus, and the thought of spending valuable time in sys admin setup instead of Rails learning was dangerously derailing me. So I stuck it out with Locomotive until I got an app going. And I did.
Lesson learned
But given what I know now, I would have been served best by downloading the source and compiling it. I would have started with the setup I have today. And that is:
- Ruby 1.8.5
- Rails 1.1.6 (or edge rails if I feel like playing around)
- Mongrel
- MySQL
- Terminal (mulitple windows -- more on this later)
- TextMate
TextMate is nice in that you have nice syntax coloring and other items. I do not like the slow search, but I am getting to the point where I do not need to constantly search across files -- less code refactoring :).
Terminal
Given that there is really no IDE environment for Rails yet (not one that suits me anyway), you end up having to rely on the Terminal window quite a bit. Whenever I am coding I have four windows up:
- script/console
- web server console (mongrel)
- breakpointer
- development.log tail -f
The script/console is huge for newbies. And I continue to use. Basically, you get the Rails environment in a console and can test things out to see what is returned, etc. A big one for newbies is the object.methods method. Also object.class. Between those two methods you stop pulling your hair out as to why something does not work. Maybe you have the wrong object, maybe that object does not support the method you wanted.
Anyway, I can not say enough about the script/console. Have it running always.
web server console is nice to have. I would not run mongrel in hidden mode. Warnings, some mailers, and other activity shows up. The warnings are good as they help you quickly see something that you might want to clean up in your code.
breakpointer
When everything else breaks :) use breakpoint() in your code, hit the web page URL and watch for irb to kick in in the breakpointer window. There again you can evaluate variables by typing them (no IDE remember), or you can put several breakpoint()s in your code and press control-D to move to the next breakpoint. Then you can evaluate more variables as you move through the code. By evaluate, I mean, type the variable or object.method on the irb screen and see what comes back. Even the object.class, or object.methods gives you an indication if you used the wrong object to begin with.
development.log
by tailing the development log, you get to see what is actually being sent to the SQL server. It is interesting to watch how Rails translates the stuff you enter into SQL. Sometimes, you pass conditions that you think are OK, but forgot the previous filters you might have put on the object. Anyway, it is another debugging tool and another way for you to learn what is happening behind the scenes.
That is it for the development environment. You need a good dev environment and a whole library of books. I am not kidding when I said I bought them all. I even found a couple of books on Amazon that are not yet out but I ordered anyway. Nothing like reading Ruby and Rails from different authors' perspectives. But books review and opinions will be my next topic.
Starting to see the light
This is my third month with my immersion in Rails. Things are starting to make sense to some degree. Enough for me to try to start explaining some of the struggles and tools I have come around to using.
Over the next posts I will try to explain, while things are fresh in my newbie mind, several of the aha! moments that have gone through. I am not sure they will make sense to newbies, but at least hopefully they can recognize some of their struggles and continue trying to understand.
So anyway, let's get started ...
Over the next posts I will try to explain, while things are fresh in my newbie mind, several of the aha! moments that have gone through. I am not sure they will make sense to newbies, but at least hopefully they can recognize some of their struggles and continue trying to understand.
So anyway, let's get started ...
Rails late nights
It was time to reread the Agile book from last year and go at it again. I went through the Depot Application, had it working, every step seemed very simple to follow and I could get the Depot running fairly easily. It took me the better part of a weekend, but it was running. The problem was, I did not get how some of the stuff worked.
I mean, it made sense in writing, but when I typed the code I did not know if I was typing a string variable, a method, or whatever. Everything looks the same pretty much. And I had never used hashes and arrays so much. Finally I realized that I just had to get used to the idea that all this nesting in hashes is the Rails way and Ruby way and I had to get used to follow it.
Then I picked up the Ruby for Rails book, and the Pickaxe Book and tried to read them cover to cover. That took a while. I would find myself dosing off at times (all this BTW happens late into the night, which is the only time I have found to devote to this).
After those two books, it was time to write my own application. It was a lot harder to get going. Don't get me wrong, I can write web applications, I have just used 4D which is a procedural language and Dreamweaver. Writing stuff in an MVC setup, with a language you hardly know and a framework that you know even less, it was slow going.
Not that I could not get the tables, the screens, the CRUD stuff. All that worked OK. But my apps need roles and rights, authentication, mailers, redirection, cron job processing, and all the view stuff needed (how do you get a popup with list values from a table in the database? for example).
But I kept going slowly making sense of what to use when. It had been a while since I had been so challenged with a language. And everyone out there keeps saying that this stuff is super easy. Do not be fooled. Sure complexity is masked and relegated far away from the app development, but sooner or later, you need to know where to look if something is not working. That was the part I struggled with, where would I go to see how things happened.
Anyway, the point of this post is to encourage all newbies out there to stick it out. It is not easy getting going with Rails, IF you want to build real, complex apps. You need to know Ruby, you need to understand Rails, and the way Rails wants you to do things.
I mean, it made sense in writing, but when I typed the code I did not know if I was typing a string variable, a method, or whatever. Everything looks the same pretty much. And I had never used hashes and arrays so much. Finally I realized that I just had to get used to the idea that all this nesting in hashes is the Rails way and Ruby way and I had to get used to follow it.
Then I picked up the Ruby for Rails book, and the Pickaxe Book and tried to read them cover to cover. That took a while. I would find myself dosing off at times (all this BTW happens late into the night, which is the only time I have found to devote to this).
After those two books, it was time to write my own application. It was a lot harder to get going. Don't get me wrong, I can write web applications, I have just used 4D which is a procedural language and Dreamweaver. Writing stuff in an MVC setup, with a language you hardly know and a framework that you know even less, it was slow going.
Not that I could not get the tables, the screens, the CRUD stuff. All that worked OK. But my apps need roles and rights, authentication, mailers, redirection, cron job processing, and all the view stuff needed (how do you get a popup with list values from a table in the database? for example).
But I kept going slowly making sense of what to use when. It had been a while since I had been so challenged with a language. And everyone out there keeps saying that this stuff is super easy. Do not be fooled. Sure complexity is masked and relegated far away from the app development, but sooner or later, you need to know where to look if something is not working. That was the part I struggled with, where would I go to see how things happened.
Anyway, the point of this post is to encourage all newbies out there to stick it out. It is not easy getting going with Rails, IF you want to build real, complex apps. You need to know Ruby, you need to understand Rails, and the way Rails wants you to do things.
October 2006 - Barnes and Noble browsing - The realization
Weekend afternoons, when I am in between errands with the family, I find myself looking for a break spot while the other browsers in the family are still at their own stores. Barnes and Noble fits the bill nicely.
Invariably, no matter how hard I try to do to expand my browsing scope, I gravitate slowly to the Technology section.
What caught my eye this time was the shelf space Rails was getting. It was not just one book, there were several! The Agile book, a Recipes Book, the Pickaxe book, The Ruby Way, Up and Running with Ruby on Rails, Ruby for Rails, the list went on.
This was not going to implode, it was an explosion, and now the books were there to back this up. Obviously the conscensus is that there is an audience for all these books.
I got home and did some more browsing, and wow! Rails was everywhere. There were blogs, to do's, plenty of code. This reminded me of Java in 1997. This was unreal.
There had to be more than hype. It was time to get serious with Rails.
I ordered everybook there was on Rails and setup a schedule to teach myself Rails by year's end. I had to get a handle on what the hype was all about.
This blog, will detail my journey as I continue to immerse myself in this technology.
Invariably, no matter how hard I try to do to expand my browsing scope, I gravitate slowly to the Technology section.
What caught my eye this time was the shelf space Rails was getting. It was not just one book, there were several! The Agile book, a Recipes Book, the Pickaxe book, The Ruby Way, Up and Running with Ruby on Rails, Ruby for Rails, the list went on.
This was not going to implode, it was an explosion, and now the books were there to back this up. Obviously the conscensus is that there is an audience for all these books.
I got home and did some more browsing, and wow! Rails was everywhere. There were blogs, to do's, plenty of code. This reminded me of Java in 1997. This was unreal.
There had to be more than hype. It was time to get serious with Rails.
I ordered everybook there was on Rails and setup a schedule to teach myself Rails by year's end. I had to get a handle on what the hype was all about.
This blog, will detail my journey as I continue to immerse myself in this technology.
Spring 2006
In the Spring of 2006 I had a chance again to look at the whole Rails philosophy. This time though, it was more with a strategy slant, looking at the Getting Real book.
It had several insights that I could easily relate to. I have always been for agile development and we have strived for that.
The key point though, with Rails methodology to design, was the concept of Opionated Software. You basically have to set some constraints around your beliefs of how an application should run.
And Rails takes this philosophy into the application development arena.
So at the time, I just took these points more as strategic thinking exercises. I had this nagging feeling that this technology fad might just implode.
My exposure with Rails would be delayed even more.
It had several insights that I could easily relate to. I have always been for agile development and we have strived for that.
The key point though, with Rails methodology to design, was the concept of Opionated Software. You basically have to set some constraints around your beliefs of how an application should run.
And Rails takes this philosophy into the application development arena.
So at the time, I just took these points more as strategic thinking exercises. I had this nagging feeling that this technology fad might just implode.
My exposure with Rails would be delayed even more.
Rails caught my eye around this time last year
It was about this time last year when going through my reading material, I see Ruby on Rails mentioned in Business Weeek. What the heck? If the folks at Business Week were already on top of a _new_ web development environment, why did I not hear about this? This is my trade, I oversee quite a bit of web development, what the heck?
Like most busy people, I was probably too preoccupied with my own stuff, my own technology, my own projects.
Seeing Ruby on Rails mentioned in Business Week (or was it Information Week?) was a wake up call. I had to do more research on happening Web 2.0 stuff. If Google gave these guys the Hacker of the Year Award in 2005, this had to be promising technology.
First things first ... who is behind this? Sun pushes Java, Microsoft pushes .NET, who is pushing Rails? Where is the Big money? Who the heck is 37signals anyway?
As far as I could tell, this was a grass roots effort. It just did not make sense. Why would everyone be so gaga about an MVC Framework written by what seems to be a young kid from Denmark. Needed to dig more.
Rails was written in Ruby. Ruby? I had heard of Python, heck we use Python quite a bit, PHP (we never really used it, but that is another story altogether). Ruby was developed in Japan and did not have an English reference book until 2000? And for the four years before Rails, it survived mainly as a novelty scripting language for hobbyist developers. Why would anyone pick Ruby to develop a web framework? This was getting interesting...
Ruby turned out to be a scripting language on steroids. Heavily Object Oriented, extremely flexible almost to the point that I did not understand how anything would run in Ruby (parenthesis - optional, end of line markers - optional, override any class, single inheritance - phew ... read more ... not so, you can circumvent and get single inheritance and mixins, what the heck?).
So I download the e-book AgileWebDevelopment and go at it. Install the stuff on my Windows machine (heck I had left the Mac a couple of years ago to feel the pain others in my company feel - as the head IT guy, I had to feel the pain). So now used to the Windows machine install MySQL, Notepad++ and Ruby. No biggie, I am running and trying to follow along.
Rails turned out to be a lot more complex than I anticipated. Sure you can type some commands and you get a CRUD, but we write full blown apps, so we are used to the easy examples and bypass them to go to the real stuff. I found myself stuck in first gear. I just could not get the hang of it.
Then I got busy again ... that was December 2005... and my Rails first encounter came and went.
Like most busy people, I was probably too preoccupied with my own stuff, my own technology, my own projects.
Seeing Ruby on Rails mentioned in Business Week (or was it Information Week?) was a wake up call. I had to do more research on happening Web 2.0 stuff. If Google gave these guys the Hacker of the Year Award in 2005, this had to be promising technology.
First things first ... who is behind this? Sun pushes Java, Microsoft pushes .NET, who is pushing Rails? Where is the Big money? Who the heck is 37signals anyway?
As far as I could tell, this was a grass roots effort. It just did not make sense. Why would everyone be so gaga about an MVC Framework written by what seems to be a young kid from Denmark. Needed to dig more.
Rails was written in Ruby. Ruby? I had heard of Python, heck we use Python quite a bit, PHP (we never really used it, but that is another story altogether). Ruby was developed in Japan and did not have an English reference book until 2000? And for the four years before Rails, it survived mainly as a novelty scripting language for hobbyist developers. Why would anyone pick Ruby to develop a web framework? This was getting interesting...
Ruby turned out to be a scripting language on steroids. Heavily Object Oriented, extremely flexible almost to the point that I did not understand how anything would run in Ruby (parenthesis - optional, end of line markers - optional, override any class, single inheritance - phew ... read more ... not so, you can circumvent and get single inheritance and mixins, what the heck?).
So I download the e-book AgileWebDevelopment and go at it. Install the stuff on my Windows machine (heck I had left the Mac a couple of years ago to feel the pain others in my company feel - as the head IT guy, I had to feel the pain). So now used to the Windows machine install MySQL, Notepad++ and Ruby. No biggie, I am running and trying to follow along.
Rails turned out to be a lot more complex than I anticipated. Sure you can type some commands and you get a CRUD, but we write full blown apps, so we are used to the easy examples and bypass them to go to the real stuff. I found myself stuck in first gear. I just could not get the hang of it.
Then I got busy again ... that was December 2005... and my Rails first encounter came and went.
Subscribe to:
Posts (Atom)
