Use Bash in FreeBSD machine

FreeBSD using C shell for the root user, and the user got sh for their shell by default. And there are so many shell can be used. But why you want to use bash at the first place, in FreeBSD terminal ?

One thing for sure, every Linux distribution by default using Bash as their shell of choice. This will get some compatibility if you create script which not run in Bash. So the options was you use bash or you change your script.

So the option to using bash shell in FreeBSD is open. we can change any type of shell we want to use. So now i will show how to change the default shell in FreeBSD which i had encounter and some tips which not a standard setup for Bash in FreeBSD.

First, install bash shell if not installed. Here are my step to install :

#cd /usr/ports/shell/bash

#make install clean

Then to change the shell as a user :

$ chsh

This will prompt user profile, change the shell to /usr/local/bin/bash

Then you can relogin to get the bash shell.

And in Linux , you can create profile for Bash, so when login the script executed. This was called .bashrc , but not in FreeBSD.

To make the bash start script run when user login, you must put it in .bash_profile .

This happend to me when i want to create a virtualenvwrapper setup in FreeBSD.

That's it. you have your Bash way.

Read More

Git Branching Model for Great Project

I got a development bump when using GIT. Currently i do the master branch only with git and develop all in master branch and log back to the master branch.

Now i start using the git branching for development of new feature, and all the way, i got confuse if i merge back to master, the current running stable version i cannot revert.

I remember the git tag usage, so i can tag the point where the code was stable, the same way when using svn for source code management.

But in git, i think and search a better way and a best proven practice somebody else employ and works in the project very well with single fighter or with many developers.

So i look for it in the web, and i found one. This is very interesting and i would like to share it and blog about it.

I will give the link [1] to the site where i learn a lot. Here are some summary i got :

1. Always have a Master and Develop branch in origin repo.
2. In master use Tag to pin point the stable release of the code. Master branch is the production ready code ready to be deploy.
3. In your own repo or developer repo, you can have feature branch, release branch, hotfix branch. But not in you origin repo.
4. Some rules to be remember :
   For branching out ::
   Feature branch always branching from develop branch.
   Release Branch always branching from a ready develop branch.
   Hotfix branch always branching from Master
   
   For Merging in :
   Feature branch always merge back to Develop branch when ready.
   Develop branch alway merge back to Release branch when ready.
   Hotfix branch always merge back to Master and Develop branch.
5. Always remember the rules and better explanation is with a picture.

For the better understanding of course the picture :

Picture explain a thousand words right. Hope this help. What do you think about this method? are you have any other best method you employ in your GIT work flow with greater success, share it with me.

Source :
[1]  A-successful-git-branching-model , download at  15 May 00:07 +8 GMT

Read More

Django Collectstatic usage

After some project completed and had a common project template layout directory , usually we will want to reuse the previous project template. But there are some static files which not belong to new project anymore. This needs time to fix.

The question is, can we put the static files for an application in their own static folder, not in the project static file it self? so when we use the app in django project, we also no need to copy to project wide static folders, which served by the webserver, usually Nginx or apache.

So come the rescue Collectstatic command in the Django admin. These feature available since Django1.3, but i actually never used it until now i understand how to implement it, and it's smart. So how to use it? I will share the step-by-step to make the collectstatic run without hassle and give speed up in development. This run with Django < 1.6 as i write this.

Step 1 :

in your settings.py :

STATIC_ROOT = '/usr/local/www/1millionproject/collected_static'



Then let say you have an app called ordernow

Step2 :

create a static folder and put any static directory or files in the folder.

ordernow/static/orderstyle.css
ordernow/static/images/produt1.png

So what happend and how to get the static file in the correct path inside project ?

Step 3 :

From your project root directory run the collectstatic command :

$python manage.py collectstatic

Then you will get a prompt and warning if you want to proceed to collect all the static files in your application folder and put it in the STATIC_ROOT location you state in Step 1.

Then make sure you set the STATIC_ROOT accessible from the webserver which will serve the static files.

In your Django code, use it as usuall with {{ STATIC_URL }} in your template files.

So the benefit of using collectstatic command is you won't need the copy command to your initial project files. Also when deploy to the production server, just issue collectstatic command and all the static files will copied from the app folder to your public static folder.

This is one of some nice features Django have. I love it especially you have many reusable app with its own static files. All will be in 1 place in the application specific directory.

How about your way, you can give a comment and share.

Thanks for reading.

Read More