Monday, April 11, 2016

Introduction to Git

Step 0: Install git and create a GitHub account 

The first two things you'll want to do are install git and create a free GitHub account.
Follow the instructions here to install git (if it's not already installed). Note that for this tutorial we will be using git on the command line only. While there are some great git GUIs (graphical user interfaces), I think it's easier to learn git using git-specific commands first and then to try out a git GUI once you're more comfortable with the command. 
Once you've done that, create a GitHub account here.  (Accounts are free for public repositories, but there's a charge for private repositories.)

Step 1: Create a local git repository 

When creating a new project on your local machine using git, you'll first create a new repository (or often, 'repo', for short). 
To use git we'll be using the terminal. If you don't have much experience with the terminal and basic commands, check out this tutorial (especially the 'Navigating the Filesystem' and 'Moving Around' sections).
To begin, open up a terminal and move to where you want to place the project on your local machine using the cd (change directory) command. For example, if you have a 'projects' folder on your desktop, you'd do something like:

coder:Desktop coder$ cd ~/Desktop
coder:Desktop coder$ mkdir myproject
coder:Desktop coder$ cd myproject/
view hosted with ❤ by GitHub

To initialize a git repository in the root of the folder, run the git init command:  


Step 2: Add a new file to the repo

Go ahead and add a new file to the project, using any text editor you like or running a touch command.
Once you've added or modified files in a folder containing a git repo, git will notice that changes have been made inside the repo. But, git won't officially keep track of the file (that is, put it in a commit - we'll talk more about commits next) unless you explicitly tell it to.

After creating the new file, you can use the git status command to see which files git knows exist.
What this basically says is, "Hey, we noticed you created a new file called coder.txt, but unless you use the 'git add' command we aren't going to do anything with it."

An interlude: The staging environment, the commit, and you

One of the most confusing parts when you're first learning git is the concept of the staging environment and how it relates to a commit.
commit is a record of what files you have changed since the last time you made a commit. Essentially, you make changes to your repo (for example, adding a file or modifying one) and then tell git to put those files into a commit.
Commits make up the essence of your project and allow you to go back to the state of a project at any point.
So, how do you tell git which files to put into a commit? This is where the staging environment or index come in. As seen in Step 2, when you make changes to your repo, git notices that a file has changed but won't do anything with it (like adding it in a commit).
To add a file to a commit, you first need to add it to the staging environment. To do this, you can use the git add <filename> command (see Step 3 below).
Once you've used the git add command to add all the files you want to the staging environment, you can then tell git to package them into a commit using the git commitcommand. 
Note: The staging environment, also called 'staging', is the new preferred term for this, but you can also see it referred to as the 'index'.

Step 3: Add a file to the staging environment

Add a file to the staging environment using the git add command. 
If you rerun the git status command, you'll see that git has added the file to the staging environment (notice the "Changes to be committed" line).  
 To reiterate, the file has not yet been added to a commit, but it's about to be.

Step 4: Create a commit

It's time to create your first commit!
Run the command git commit -m "Your message about the commit"
The message at the end of the commit should be something related to what the commit contains - maybe it's a new feature, maybe it's a bug fix, maybe it's just fixing a typo. Don't put a message like "asdfadsf" or "foobar". That makes the other people who see your commit sad. Very, very, sad.

Step 5: Create a new branch

Now that you've made a new commit, let's try something a little more advanced.
Say you want to make a new feature but are worried about making changes to the main project while developing the feature. This is where git branches come in. 
Branches allow you to move back and forth between 'states' of a project. For instance, if you want to add a new page to your website you can create a new branch just for that page without affecting the main part of the project. Once you're done with the page, you can merge your changes from your branch into the master branch. When you create a new branch, Git keeps track of which commit your branch 'branched' off of, so it knows the history behind all the files. 
Let's say you are on the master branch and want to create a new branch to develop your web page. Here's what you'll do: Run git checkout -b <my branch name>. This command will automatically create a new branch and then 'check you out' on it, meaning git will move you to that branch, off of the master branch.
After running the above command, you can use the git branch command to confirm that your branch was created:
coder:myproject coder$ git branch
* my-new-branch
view hosted with ❤ by GitHub
The branch name with the asterisk next to it indicates which branch you're pointed to at that given time. 
Now, if you switch back to the master branch and make some more commits, your new branch won't see any of those changes until you merge those changes onto your new branch.

Step 6: Create a new repository on GitHub

If you only want to keep track of your code locally, you don't need to use GitHub. But if you want to work with a team, you can use GitHub to collaboratively modify the project's code.

To create a new repo on GitHub, log in and go to the GitHub home page. You should see a green '+ New repository' button: 

After clicking the button, GitHub will ask you to name your repo and provide a brief description:

When you're done filling out the information, press the 'Create repository' button to make your new repo.
GitHub will ask if you want to create a new repo from scratch or if you want to add a repo you have created locally. In this case, since we've already created a new repo locally, we want to push that onto GitHub so follow the '....or push an existing repository from the command line' section: 

coder:myproject coder$ git remote add origin
coder:myproject coder$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 263 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.
view hosted with ❤ by GitHub

 (You'll want to change the URL in the first command line to what GitHub lists in this section since your GitHub username and repo name are different.)

Step 7: Push a branch to GitHub

Now we'll push the commit in your branch to your new GitHub repo. This allows other people to see the changes you've made. If they're approved by the repository's owner, the changes can then be merged into the master branch.
To push changes onto a new branch on GitHub, you'll want to run git push origin yourbranchname. GitHub will automatically create the branch for you on the remote repository: 
coder:myproject coder$ git push origin my-new-branch
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 313 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
 * [new branch]      my-new-branch -> my-new-branch
 You might be wondering what that "origin" word means in the command above. What happens is that when you clone a remote repository to your local machine, git creates an alias for you. In nearly all cases this alias is called "origin." It's essentially shorthand for the remote repository's URL. So, to push your changes to the remote repository, you could've used either the command: git push yourbranchname or git push origin yourbranchname
(If this is your first time using GitHub locally, it might prompt you to log in with your GitHub username and password.)
If you refresh the GitHub page, you'll see note saying a branch with your name has just been pushed into the repository. You can also click the 'branches' link to see your branch listed there.
Now click the green button in the screenshot above. We're going to make a pull request!

Step 8: Create a Pull Request (PR)

A pull request (or PR) is a way to alert a repo's owners that you want to make some changes to their code. It allows them to review the code and make sure it looks good before putting your changes on the master branch.
This is what the PR page looks like before you've submitted it:

And this is what it looks like once you've submitted the PR request:

You might see a big green button at the bottom that says 'Merge pull request'. Clicking this means you'll merge your changes into the master branch.
Note that this button won't always be green. In some cases it'll be grey, which means you're faced with a merge conflict. This is when there is a change in one file that conflicts with a change in another file and git can't figure out which version to use. You'll have to manually go in and tell git which version to use.
Sometimes you'll be a co-owner or the sole owner of a repo, in which case you may not need to create a PR to merge your changes. However, it's still a good idea to make one so you can keep a more complete history of your updates and to make sure you always create a new branch when making changes.

Step 9: Merge a PR

Go ahead and click the green 'Merge pull request' button. This will merge your changes into the master branch.

When you're done, I recommend deleting your branch (too many branches can become messy), so hit that grey 'Delete branch' button as well.
You can double check that your commits were merged by clicking on the 'Commits' link on the first page of your new repo.

This will show you a list of all the commits in that branch. You can see the one I just merged right up top (Merge pull request #2).
You can also see the hash code of the commit on the right hand side. A hash code is a unique identifier for that specific commit. It's useful for referring to specific commits and when undoing changes (use the git revert <hash code number> command to backtrack).

Step 10: Get changes on GitHub back to your computer

Right now, the repo on GitHub looks a little different than what you have on your local machine. For example, the commit you made in your branch and merged into the master branch doesn't exist in the master branch on your local machine.
In order to get the most recent changes that you or others have merged on GitHub, use the git pull origin master command (when working on the master branch).
coder:myproject coder$ git pull origin master
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
 * branch            master     -> FETCH_HEAD
   b345d9a..5381b7c  master     -> origin/master
Merge made by the 'recursive' strategy.
 coder.txt | 1 +
 1 file changed, 1 insertion(+)
view hosted with ❤ by GitHub
This shows you all the files that have changed and how they've changed.
Now we can use the git log command again to see all new commits.
(You may need to switch branches back to the master branch. You can do that using the git checkout master command.)
coder:myproject coder$ git log
commit 3e270876db0e5ffd3e9bfc5edede89b64b83812c
Merge: 4f1cb17 5381b7c
Author: Coder Insigts <>
Date:   Fri Sep 11 17:48:11 2015 -0400

    Merge branch 'master' of

commit 4f1cb1798b6e6890da797f98383e6337df577c2a
Author: Coder Insigts <>
Date:   Fri Sep 11 17:48:00 2015 -0400

    added a new file

commit 5381b7c53212ca92151c743b4ed7dde07d9be3ce
Merge: b345d9a 1e8dc08
Author: Coder Insigts <>
Date:   Fri Sep 11 17:43:22 2015 -0400

    Merge pull request #2 from cubeton/my-newbranch
    Added some more text to my file

commit 1e8dc0830b4db8c93efd80479ea886264768520c
Author: Coder Insigts <>
Date:   Fri Sep 11 17:06:05 2015 -0400

    Added some more text to my file

commit b345d9a25353037afdeaa9fcaf9f330effd157f1
Author: Coder Insigts <>
Date:   Thu Sep 10 17:42:15 2015 -0400

    This is my first commit!
view hosted with ❤ by GitHub

Step 11: Bask in your git glory

You've successfully made a PR and merged your code to the master branch. Congratulations! If you'd like to dive a little deeper, check out the files in this Git101 folder for even more tips and tricks on using git and GitHub. 
I also recommend finding some time to work with your team on simulating a smaller group project like we did here. Have your team make a new folder with your team name, and add some files with text to it. Then, try pushing those changes to this remote repo. That way, your team can start making changes to files they didn't originally create and practice using the PR feature. And, use the git blame and git history tools on GitHub to get familiar with tracking which changes have been made in a file and who made those changes. 
The more you use git, the more comfortable you'll... git with it. (I couldn't resist.)


Tuesday, April 7, 2015

Using a SOAP service as DLL

By default, when you do an Add Service Reference operation, the WCF runtime will generate the client-side proxy for you.

The simplest way to use it is to instantiate the client proxy with a constructor that takes no parameters, and just grab the info from the app.config:
YourServiceClient proxy = new YourServiceClient();
This requires the config file to have a <client> entry with your service contract - if not, you'll get the error you have.
But the client side proxy class generated by the WCF runtime also has additional constructors - one takes an endpoint address and a binding, for instance:
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.Transport; 
EndpointAddress epa = new EndpointAddress("");
YourServiceClient proxy = new YourServiceClient(binding, epa);
With this setup, no config file at all is needed - you're defining everything in code. Of course, you can also set just about any other properties of your binding and/or endpoint here in code.

NodeJs Quick File Server

$ npm install finalhandler

var finalhandler = require(‘finalhandler’);

var http = require('http');
var finalhandler = require('finalhandler');

var serveStatic = require('serve-static');
var serve = serveStatic("./");
var server = http.createServer(function(req, res){
var done = finalhandler(req, res)
serve(req, res, done)


API Details

Friday, October 5, 2012

MYSQL Incremental Backup

Blogs by Others:

Leading Authority on MYSQL backups:

Different Methods:


Questions on stackoverflow:

Example Implementation:

Cautions and Dangers:


Must Knows:*)*)




Thursday, September 13, 2012

PHP Design Patterns


Friday, September 7, 2012

Database migrations using DbDeploy & Phing

Install Phing

The best way to download and install phing is using PEAR. This can be done on Linux or Windows assuming you have the pear script in your PATH with three shell commands.

shell> pear channel-discover
shell> pear config-set preferred_state beta
shell> pear install [--alldeps] phing/phing

Example Application structure

As an example, we’re going to develop a simple application with the following directory structure.
 |-- db/
 |   `-- deltas/
 |-- deploy/
 |   `-- scripts/  
 |-- library/
 `-- public/
The db directory contains sql files for using and manipulating our database and the deploy directory contains our build scripts that set the migrations in motion. The library directory contains our application code and the public folder will contain scripts and files accessible directly from the web, but will not be the focus of this article.

Build scripts

This section shows you how to develop the build scripts that will run the database migrations. The first file we need to create is a simple configuration file and should be fairly self explanatory. The file is written as key=value, lines beginning with a # are comments. Open your editor and save the following text as deploy/
# Property files contain key/value pairs

# This dir must contain the local application

# Credentials for the database migrations

# paths to programs
The next file we are going to create is the deploy/build.xml file. This is the file that tells Phing what we want it to do. I’m not going to go into too much detail describing each part of the build file, there are some comments, but you should consult the Phing Documentation for further details and enhancements.
<?xml version="1.0" ?>
<project name="PurpleMonkey" basedir="." default="build">

<!-- Sets the DSTAMP, TSTAMP and TODAY properties -->

<!-- Load our configuration -->
<property file="./" />

<!-- create our migration task -->
<target name="migrate" description="Database Migrations">  

<!-- load the dbdeploy task -->
<taskdef name="dbdeploy" classname="phing.tasks.ext.dbdeploy.DbDeployTask"/>

<!-- these two filenames will contain the generated SQL to do the deploy and roll it back-->
<property name="build.dbdeploy.deployfile" value="deploy/scripts/deploy-${DSTAMP}${TSTAMP}.sql" />
<property name="build.dbdeploy.undofile" value="deploy/scripts/undo-${DSTAMP}${TSTAMP}.sql" />

<!-- generate the deployment scripts -->
undooutputfile="${build.dir}/${build.dbdeploy.undofile}" />

<!-- execute the SQL - Use mysql command line to 
avoid trouble with large files or many statements and PDO -->
command="${progs.mysql} -h${} -u${db.user}
-p${db.pass} ${} &lt; ${build.dbdeploy.deployfile}" dir="${build.dir}" checkreturn="true" /> </target> </project>
That’s essentially all the magic we need. Now we just need to create our database.

Writing dbdeploy delta scripts

We haven’t actually created our database, so rather than create it the traditional way, we will actually use the migrations to create the initial schema. We’ve not actually decided what our example application does yet, but seeing as most tutorials make blogs, why don’t we give that a bash. We’ll start simple, one table with three columns called post.
Field Type Comment
title VARCHAR(255) The title of our post
time_created DATETIME The time we created our post
content MEDIUMTEXT The content of our post
Dbdeploy works by creating numbered delta files. Each delta files contains simple SQL to both deploy the change and roll it back. The basic layout of a delta file is like so.

-- //

-- Run SQL to do the changes

-- //@UNDO

-- RUN SQL to undo the changes

We are creating our initial schema, so put the following content in db/deltas/1-create_initial_schema.sql

    `title` VARCHAR(255),
    `time_created` DATETIME,
    `content` MEDIUMTEXT


DROP TABLE `post`;

Note: recent versions of mysql require space between -- and // 

Migrating the database

We are one step away from running our first migration. To keep track of the current version of the database, dbdeploy requires a table in the database. This is the only time we will have to interact with the mysql client directly.
shell> mysql -hlocalhost -uroot -ppassword example
mysql> CREATE TABLE changelog (
  change_number BIGINT NOT NULL,
  delta_set VARCHAR(10) NOT NULL,
  complete_dt TIMESTAMP NULL,
  applied_by VARCHAR(100) NOT NULL,
  description VARCHAR(500) NOT NULL
mysql> ALTER TABLE changelog ADD CONSTRAINT Pkchangelog PRIMARY KEY (change_number,delta_set);
We are now ready to run our first migration and create the initial schema for our application.
shell>cd deploy
shell>phing migrate
All being well, we now have a posts table in our database. But what about an author for our blog posts? We’ll have to add another table and a foreign key from the post table to author table. To do this we create another delta, we call this one db/deltas/2-create_author_and_link_to_post.sql

CREATE TABLE `author` (
    `author_id` INT(10) unsigned auto_increment,
    `name` VARCHAR(255),
    PRIMARY KEY (`author_id`)

ALTER TABLE `post` ADD `author_id` INT(10) unsigned NULL;


ALTER TABLE `post` DROP `author_id`;

DROP TABLE `author`;

shell> cd deploy
shell> phing migrate

Friday, August 31, 2012

Useful Links for the Month

Installing Nginx for PHP, MySQL

Nginx is a high performance HTTP server. It provides very fast speed of delivering web pages, and uses fewer resources at the same time. With Nginx (Pronounced Engine X) A server with low resources will be able to serve many more clients, due to this, many popular websites use this (To conserve their resources, of course). In this blog post, I am going to discuss how to install Nginx, along with PHP, and MYSQL. You will need to follow very close attention to this article, else, one mistake and you may need to restart all over again.

The first thing you will need to do of course is own a VPS/Dedicated server. You will also need to have an SSH Client (Putty), and your username and password. If you have all of this, the first thing you need to do is login to your panel, and rebuild the server with some version of CentOS (it does not matter what version, really). Once you have done so, login to your SSH client, supplying the required information.

Next, we are going to begin the actual procedure. Follow these steps very closely.

1st We will need to install MYSQL. To do so, copy and paste the command below.

“yum install mysql mysql-server” – Without the quotations of course.

Next, we will set the server to start MYSQL whenever the system is rebooted. This will help significantly, else you will need to login to the console every time you need to reboot, and then you will need to type in a command to start MYSQL. To set the server to start MYSQL when the server boots, follow the steps below.

- Type in, copy “chkconfig – levels 235 mysqld on /etc/init.d/mysqld start”

- Once the above command has been entered, enter “netstat -tap | grep mysql”

The screen should then look something like this (The text).
[root@server1 ~]# netstat -tap | grep mysql
tcp 0 0 *:mysql *:* LISTEN 2388/mysqld
[root@server1 ~]#

Once you get that screen, you will want to reboot your MYSQL server, this will append any changes that you have made. To do so, copy this command “/etc/init.d/mysqld restart”.

Now, you need to actually setup MYSQL (Remember, all you just did was actually install the server). To start the install/configuration process, use this command “mysql_secure_installation”. All you will need to do is set your root password. Once you have done this, you are done with the installation of MYSQL. (Yay!).

When MYSQL is installed, it also installs PHP. The next step is to install the actual server (Nginx). This is very much easier then installing MYSQL.

The HTTP engine has not yet been released for final, for centos, though there are repositorys that may be used with it. To install the repositorys, you will need to type in the command as follows.

cd /etc/yum.repos.d/ 

It should then open a file like:[...]
# pkgs in the -Testing repo are not gpg signed
name=CentOS.Karan.Org-EL$releasever - Testing

You will need to set GPGCHECK to 0, and enabled to 1.

Once you have done that, run this command “yum install Nginx”.

Once that is done, we also need to make the server start on boot, to do this type in the following
command.chkconfig --levels 235 nginx on
/etc/init.d/nginx start

Now, reboot the server, and then type in the server IP in your browser. When you do so, you should see just a blank page..if you do everything is working correctly..the page is only blank because you haven’t added any content. If you would like to do so, you should install an FTP server. And set it to “/usr/share/nginx/html/index.html”.

That’s it! Your done!