Here's a link to a blog with a Youtube video link talking about Google's much awaited Android - sorta like a phoneOS...
But the keynote spells out more than that, and Vic Gondotra, one of Google's VPs, does a good job of explaining things... and of where Google's headed with the internet and with world domination!
Now, for geeks like me who don't get to actually be on the scene and get all screamy and excited, the video in the link will have to do... just hope I don't wet my bed tonight!
This week's been a bit slow, so i'm picking up the pace this weekend for all you readers out there. I'm studying an updated version of XP today - i mentioned we needed to do some improvements on our project management methods... so expect more on this next week!
Thursday, May 29, 2008
Wednesday, May 28, 2008
Rails training, anyone?
I got a little lazy (well, a lot really... ) so i decided that i didn't want to study Rails by reading, but by watching a video with a popcorn in hand (really hard to get good popcorn these days)
searching through the web for video tutorials, I came across this set of videos from guys at UC Berkeley RAD Lab... Never been to UCB, but I hear its a beaut... my kudos to the guys at UCB RAD...
the video filesizes are large... I nodded off waiting for it to stream... so you might wanna have a firefox extension do the downloading for you before you view them... here's one. If you're using IE... again, seriously?
anywho, check it out! i think it's RAD! haha! (although i haven't even gotten to the end of one yet, so no guarantees)
we'll post some video tutorials up in the future - when we actually have time to kill... but we will... promise...
searching through the web for video tutorials, I came across this set of videos from guys at UC Berkeley RAD Lab... Never been to UCB, but I hear its a beaut... my kudos to the guys at UCB RAD...
the video filesizes are large... I nodded off waiting for it to stream... so you might wanna have a firefox extension do the downloading for you before you view them... here's one. If you're using IE... again, seriously?
anywho, check it out! i think it's RAD! haha! (although i haven't even gotten to the end of one yet, so no guarantees)
we'll post some video tutorials up in the future - when we actually have time to kill... but we will... promise...
Sunday, May 25, 2008
Sprint Review & Retrospect Meeting
ahh... the good ol meetings... i used to think meetings kinda wanna make you feign sick and take leave... (then go and watch a movie... but that's a different story...)
We just did the Sprint Review and Retrospect meetings for one of our projects. took us about less than 2 hours... we're a pretty small team...
One thing we noticed was that when you keep improving on what you did on the last sprint, you get more - even tho it might be just abit - excited to go work on the next sprint. we realized that its because, doing the same thing for people who don't leave their brains at home when they go to work is just plain boring and disengaging.
improvements bring fresh air... we've got 6 things to improve on the next sprint... and we've still got a long way to go... hang on!
prototype and scriptaculous is gonna have to wait a bit... we're gonna need to tackle the really meaty stuff first... Basic Ruby for the team! oh god...
We just did the Sprint Review and Retrospect meetings for one of our projects. took us about less than 2 hours... we're a pretty small team...
One thing we noticed was that when you keep improving on what you did on the last sprint, you get more - even tho it might be just abit - excited to go work on the next sprint. we realized that its because, doing the same thing for people who don't leave their brains at home when they go to work is just plain boring and disengaging.
improvements bring fresh air... we've got 6 things to improve on the next sprint... and we've still got a long way to go... hang on!
prototype and scriptaculous is gonna have to wait a bit... we're gonna need to tackle the really meaty stuff first... Basic Ruby for the team! oh god...
Thursday, May 22, 2008
Git Cheat Sheet
What's Rails without Git version control right? Here's a cheatsheet on Git by Jan Kruger from http://jan-krueger.net/git
I thought I knew it all already... well... never hurts to learn... that is, until you suffer from CM (yeah, that's cranial meltd-... i know you know it already!)
I thought I knew it all already... well... never hurts to learn... that is, until you suffer from CM (yeah, that's cranial meltd-... i know you know it already!)
to_proc or not to proc
Instead of writing this
I could write this using Rails' Symbol#to_proc
Nice.
Profile.find(:all).collect{ |x| x.email }
I could write this using Rails' Symbol#to_proc
Profile.find(:all).collect(&:email)
Nice.
Wednesday, May 21, 2008
Use filter_parameter_logging for your password
This morning while I was looking at some codes, I've found something interesting. When I login, I looked at the logs and I could see clearly the password that I'd just entered.
Example
Parameters: {"commit"=>"Log in", "action"=>"create", "controller"=>"sessions", "password"=>"password123", "login"=>"foobar"}
I know, this looks like a trivial matter but imagine anyone having access to our server looking at our production logs file. Passwords are left wide open for the whole world to see.
But no worries, just add this one liner in your application.rb
Go back to your login form, fill in your login name and password and then submit.
Check out the logs and see the parameters hash.
Parameters: {"commit"=>"Log in", "action"=>"create", "controller"=>"sessions", "login"=>"foobar", "password"=>"[FILTERED]"}
Notice the hash key 'password'?
Example
Parameters: {"commit"=>"Log in", "action"=>"create", "controller"=>"sessions", "password"=>"password123", "login"=>"foobar"}
I know, this looks like a trivial matter but imagine anyone having access to our server looking at our production logs file. Passwords are left wide open for the whole world to see.
But no worries, just add this one liner in your application.rb
class ApplicationController < ActionController::Base
filter_parameter_logging "password"
end
Go back to your login form, fill in your login name and password and then submit.
Check out the logs and see the parameters hash.
Parameters: {"commit"=>"Log in", "action"=>"create", "controller"=>"sessions", "login"=>"foobar", "password"=>"[FILTERED]"}
Notice the hash key 'password'?
Saturday, May 17, 2008
Incompetent git!! Or is it?
Git used to be, in my vocabulary, a word I use when I'm angry with someone. Now it's a new word I use to keep my codes version controlled and backed up. Interesting how language can run circles around you
If you don't know what git is, here's a detailed explanation on Wikipedia
Here's a brief tutorial on how to use git to store your development codes. At the end of this tutorial we provide a link for you to download a script we created to automate push and pull from our git server. Note that we're running this on an Ubuntu server (gutsy) and using Ubuntu desktop (gutsy/hardy) on our computers. Now, if you're using Microsoft for doing Ruby on Rails – seriously? (git is possible in Microsoft. You can find git tutorials for Microsoft on the web :) )
1. First, install git in your system/server. Open a terminal in your desktop and type the following:
sudo apt-get install git-core
2. Then, create a folder, lets call it myfirstapp
mkdir myfirstapp
3. Enter the directory that you created
cd myfirstapp
4. Initialize the directory created to be git aware
git init
5. Now you have completed initializing your local directory. Test the setup by doing the following:
Create any file in the folder
touch file1
To display the new file created,use this command
git status
It should display something like this
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add..." to include in what will be committed)
#
# file1
nothing added to commit but untracked files present (use "git add" to track)
which means you have succeeded in creating the repository.
6. Commit the file to your local repository.
git add . (Make sure you add the dot in after add)
git commit -m “put your message here”
7. Now, create your remote repository based on your local repository.
git remote
Nothing should display at this stage
git branch -a
Now, it should display something like this
* master
8. Create a remote connection to your centralized server. We use secured shell (ssh) to create a remote connection to our server.
ssh -l foo foo.bar.org
enter the password for foo
9. Create a folder in your home driectory
foo@foobar:~$mkdir myfirstapp.git
Enter the directory created
cd myfirstapp.git
10. Initialize the directory by typing :
git --bare init
Exit from your remote connection:
Exit
11. In case you are not in the repository folder that you have created earlier,change to that directory in your local machine. Add the origin of the remote by typing
git remote add origin ssh://foo@foo.bar.org/home/foo/myfirstapp.git
12. Verify by viewing the the .git/config file
cat .git/config
You should see something like this
[remote "origin"]
url = ssh://foo@foo.bar.org/home/foo/myfirstapp.git
13. Push the changes to the server
git push origin master
14. Edit your .git/config using your favourite editor (our 'engineers' use vi. You can always choose to use nano or gedit )
vi .git/config
Now, add the following line
[branch "master"]
remote = origin
merge = refs/heads/master
15. Quit and Save.
You have now created a repository for your codes in your remote server. Now you need to set up your local directory to automatically link to the remote repository to pull codes. Your team mates will need to do the following too to get a copy of the codes (and git setup!). To get the source from the repository, the first step is to clone the source code. In your projects folder, (parent to myfirstapp, for example), type in the following:
git clone ssh://foo@foo.bar.org/home/foo/myfirstapp.git
This will clone your codes from your remote server to your local machine
The next step would be to set the .gitignore files. This file specifies what files to ignore when pushing to the remote server. You would not want to push your log file and other insignificant files to your remote server, won't you? Use your favourite editor to edit .gitignore. Again, by using vi,
vi .gitignore
Copy and paste the following lines
log/*.log
tmp/**/*
.DS_Store
doc/api
doc/app
These are the file types that you may not want to push to the remote repository. Your requirements may vary, so make sure!. Once you've specified the file types to ignore, save and quit the text editor.
You are now all set to pull and push from your server. The following steps detail how you should ALWAYS pull and push to your server
1. First,use the following commands to add your files to your local repository.
git add . (Again, make sure the dot after “add”)
git commit -m “your message here”
2. Next, pull the codes from repository from the remote server in order to avoid any conflicts with existing codes in the remote server (your team mates might have upload codes before you, so they might be in conflict with changes you made to the codes)
git pull
If something is wrong – a conflict, for example, you and your team mate both modified the same lines of code - fix it first.
3. If there are no problems, then you may proceed with pushing your codes to the remote server
git push
Now, the server is updated with your new codes, and others may pull your codes from the repository.
Now as programmers we know very well that it's easy to overlook one or two of the procedures mentioned above – especially if you're pushing code at around 2-4 am – so we created a script for us to push our codes without having to bother doing all the above. Oh, did I forget to mention that we're also lazy?
If you want to you can download the script from here. Remember to remove the .txt extension before using (Scribd quirk, can't upload if they don't know your file format) Note that we won't be held responsible if anything happens to your data or system (In other words, make sure you know the ins and outs of your system and the script before you use it!)
Here are the steps for you to run our script
1. Save the script to the local repository folder in your machine. In this case it would be the myfirstapp folder.
2. Change the file access to executable file
chmod +x pullpush
3. Run the script from the local repository folder
./pullpush
Follow the instructions provided as the script runs (enter passwords etc). You may terminate the script by using ctrl+c (Hey, it ain't perfect, but it works)
That's it for our brief git tutorial! Learn to do it, and you can avoid becoming an actual git yourself!
If you don't know what git is, here's a detailed explanation on Wikipedia
Here's a brief tutorial on how to use git to store your development codes. At the end of this tutorial we provide a link for you to download a script we created to automate push and pull from our git server. Note that we're running this on an Ubuntu server (gutsy) and using Ubuntu desktop (gutsy/hardy) on our computers. Now, if you're using Microsoft for doing Ruby on Rails – seriously? (git is possible in Microsoft. You can find git tutorials for Microsoft on the web :) )
1. First, install git in your system/server. Open a terminal in your desktop and type the following:
sudo apt-get install git-core
2. Then, create a folder, lets call it myfirstapp
mkdir myfirstapp
3. Enter the directory that you created
cd myfirstapp
4. Initialize the directory created to be git aware
git init
5. Now you have completed initializing your local directory. Test the setup by doing the following:
Create any file in the folder
touch file1
To display the new file created,use this command
git status
It should display something like this
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add
#
# file1
nothing added to commit but untracked files present (use "git add" to track)
which means you have succeeded in creating the repository.
6. Commit the file to your local repository.
git add . (Make sure you add the dot in after add)
git commit -m “put your message here”
7. Now, create your remote repository based on your local repository.
git remote
Nothing should display at this stage
git branch -a
Now, it should display something like this
* master
8. Create a remote connection to your centralized server. We use secured shell (ssh) to create a remote connection to our server.
ssh -l foo foo.bar.org
enter the password for foo
9. Create a folder in your home driectory
foo@foobar:~$mkdir myfirstapp.git
Enter the directory created
cd myfirstapp.git
10. Initialize the directory by typing :
git --bare init
Exit from your remote connection:
Exit
11. In case you are not in the repository folder that you have created earlier,change to that directory in your local machine. Add the origin of the remote by typing
git remote add origin ssh://foo@foo.bar.org/home/foo/myfirstapp.git
12. Verify by viewing the the .git/config file
cat .git/config
You should see something like this
[remote "origin"]
url = ssh://foo@foo.bar.org/home/foo/myfirstapp.git
13. Push the changes to the server
git push origin master
14. Edit your .git/config using your favourite editor (our 'engineers' use vi. You can always choose to use nano or gedit )
vi .git/config
Now, add the following line
[branch "master"]
remote = origin
merge = refs/heads/master
15. Quit and Save.
You have now created a repository for your codes in your remote server. Now you need to set up your local directory to automatically link to the remote repository to pull codes. Your team mates will need to do the following too to get a copy of the codes (and git setup!). To get the source from the repository, the first step is to clone the source code. In your projects folder, (parent to myfirstapp, for example), type in the following:
git clone ssh://foo@foo.bar.org/home/foo/myfirstapp.git
This will clone your codes from your remote server to your local machine
The next step would be to set the .gitignore files. This file specifies what files to ignore when pushing to the remote server. You would not want to push your log file and other insignificant files to your remote server, won't you? Use your favourite editor to edit .gitignore. Again, by using vi,
vi .gitignore
Copy and paste the following lines
log/*.log
tmp/**/*
.DS_Store
doc/api
doc/app
These are the file types that you may not want to push to the remote repository. Your requirements may vary, so make sure!. Once you've specified the file types to ignore, save and quit the text editor.
You are now all set to pull and push from your server. The following steps detail how you should ALWAYS pull and push to your server
1. First,use the following commands to add your files to your local repository.
git add . (Again, make sure the dot after “add”)
git commit -m “your message here”
2. Next, pull the codes from repository from the remote server in order to avoid any conflicts with existing codes in the remote server (your team mates might have upload codes before you, so they might be in conflict with changes you made to the codes)
git pull
If something is wrong – a conflict, for example, you and your team mate both modified the same lines of code - fix it first.
3. If there are no problems, then you may proceed with pushing your codes to the remote server
git push
Now, the server is updated with your new codes, and others may pull your codes from the repository.
Now as programmers we know very well that it's easy to overlook one or two of the procedures mentioned above – especially if you're pushing code at around 2-4 am – so we created a script for us to push our codes without having to bother doing all the above. Oh, did I forget to mention that we're also lazy?
If you want to you can download the script from here. Remember to remove the .txt extension before using (Scribd quirk, can't upload if they don't know your file format) Note that we won't be held responsible if anything happens to your data or system (In other words, make sure you know the ins and outs of your system and the script before you use it!)
Here are the steps for you to run our script
1. Save the script to the local repository folder in your machine. In this case it would be the myfirstapp folder.
2. Change the file access to executable file
chmod +x pullpush
3. Run the script from the local repository folder
./pullpush
Follow the instructions provided as the script runs (enter passwords etc). You may terminate the script by using ctrl+c (Hey, it ain't perfect, but it works)
That's it for our brief git tutorial! Learn to do it, and you can avoid becoming an actual git yourself!
Thursday, May 15, 2008
Prototype and Scriptaculous? OMG!!!
You really know you've got cranial meltdown when you got that really dull throbbing at the back of your head... but peeling your eyes away from the screen is just torture - "Gotta get this thing solved by sundown!!! "&%#$(^%&*@$%$!!" - you don't want to, no... cannot possibly, read another word of tutorials, but you know you have to... so it boils down to: do it, or die...
If you're doing AJAX on Ruby on Rails, trust us, you'll want to know these two words: Prototype and Scriptaculous (we don't - yet). In the coming weeks, we'll be posting stuff on Prototype and Scriptaculous and - if we can actually glue our brains together again - post a quick guide (or cheatsheet, if you want) for all you guys out there who don't think they can suffer like we did today...
If you're doing AJAX on Ruby on Rails, trust us, you'll want to know these two words: Prototype and Scriptaculous (we don't - yet). In the coming weeks, we'll be posting stuff on Prototype and Scriptaculous and - if we can actually glue our brains together again - post a quick guide (or cheatsheet, if you want) for all you guys out there who don't think they can suffer like we did today...
Monday, May 12, 2008
The Wall is up and moving!
The wall is now up and moving!
We skipped some processes in setting this up, cause, well, the development was already on way, but it did clear up some stuff for us...
Can't give you the project topic yet, more on the project itself soon. but you could probably get an idea from the wall... and by the way, it looks a little bare, but that's coz we've got only 1 developer... doing 1 thing at a time...
Unlike the normal 'spit spraying' methodology of meetings, the wall actually helped us see where we're going, focus on the more important issues, and track progress - hey, it's like 3-in-1.... mmmm... hot coffee...
Also, we realized that, at least for this project, we could do away with the Product Backlog and burndowns - its a simple system development. It all depends on the conditions of work, so we'll let that tell us what needs doing for now - at least until we're better at this.
Sunday, May 11, 2008
Ruby Cheatsheet Part Two!
Finally, part 2 of the Ruby Cheatsheet is now complete! Click here to download the file from Scribd, which, by the way, is also an excellent site for lots of stuff... so kudos to the Scribd crew...
Part two gets you acquainted with the built-in stuff ruby provides to make your coding life easier and more fun (or confusing maybe?). Great help for you young apprentices who are looking forward to becoming Jedi Railers... (Nothing like geek speak to lighten up your day)
Now, about that project wall....
UPDATE: The combined version, part 1 and part 2 together, can be found here. I've made some improvements to the file to make it more readable - Acap
Part two gets you acquainted with the built-in stuff ruby provides to make your coding life easier and more fun (or confusing maybe?). Great help for you young apprentices who are looking forward to becoming Jedi Railers... (Nothing like geek speak to lighten up your day)
Now, about that project wall....
UPDATE: The combined version, part 1 and part 2 together, can be found here. I've made some improvements to the file to make it more readable - Acap
Tuesday, May 6, 2008
Ruby Syntax Cheatsheet
For all us Ruby on Rails newbies, it's really important to know Ruby, the language, before jumping into Rails. Learning Rails without knowing Ruby is like doing bike stunts without learning how to ride. Major pain bro...
Save yourselves from major cranial meltdown by learning Ruby syntax first. It shouldn't be too hard if you already know other programming languages. To help us with learning it, we created our own Ruby Syntax Cheatsheet
This is part 1 of the Ruby Syntax Cheatsheet we made to help us code in Ruby. It's based on the Ruby for Rails book by David Black. Highly recommended reading for all of us who aspire to become 'Jedi' Railers.... (hey, you can't make Jedi if you don't know the Force!). Click here to download the file
Save yourselves from major cranial meltdown by learning Ruby syntax first. It shouldn't be too hard if you already know other programming languages. To help us with learning it, we created our own Ruby Syntax Cheatsheet
This is part 1 of the Ruby Syntax Cheatsheet we made to help us code in Ruby. It's based on the Ruby for Rails book by David Black. Highly recommended reading for all of us who aspire to become 'Jedi' Railers.... (hey, you can't make Jedi if you don't know the Force!). Click here to download the file
7 do's and 3 don'ts for creating web products
hey hey...
really slow day today, so went surfing the www... and stumbled upon this:
http://whydoeseverythingsuck.com/2008/05/seven-dos-and-three-donts-for-creating.html
It's good!
no me toos... no me toos... no me toos... ok, got it!
really slow day today, so went surfing the www... and stumbled upon this:
http://whydoeseverythingsuck.com/2008/05/seven-dos-and-three-donts-for-creating.html
It's good!
no me toos... no me toos... no me toos... ok, got it!
Sunday, May 4, 2008
1st half of wall is up!!
Well, here's our first foray into the Project Wall for our projects. Heading out for lunch now.... can't think without food!!
Project Wall
Alright, we just finished a Release Plan meeting - more like hangout than meeting - so I'm gonna start with a Project Wall for this project.
Picture shows the format I'm thinking of using. Comments are welcome this time... just no tomatoes...
Real life pictures just as soon as the wall comes up....
Friday, May 2, 2008
Agile Software Development Process
2 weeks ago, while staring blankly at the screen of my laptop during our company's weekly meeting, I decided to lookup on agile programming methods.
We weren't getting far on our projects, and even if we did, I didn't know it. Man, that sucked.
So after a week's worth of toiling and brain damage (I never knew us fellow programmers can be so 'organized' when presenting stuff online), I came up with a 'framework' ("What?! another one?! $@%@%@%!!") described by the diagram I put up, a snapshot of the process we're going to use for our software development management. booyah!!
Scrum + XP guys... I'm a newbie at this... so no rotten tomatoes ok? not just yet... please...
coming up... the framework... in words... and more.
Subscribe to:
Posts (Atom)