Elixir's Ecto Querying DSL: Beyond the Basics
Heroku Alternative: Deploy Apps with Dokku on DigitalOcean
Quick Read: Blockchain's Future after Bitcoin
Understanding Elixir's Ecto Querying DSL: The Basics
Java Serialization: Building a Persistent Phone Book
Serialization is a powerful tool. It's what allows us to store objects on disk and reconstruct them in memory when necessary -- perhaps when the program restarts. For anyone who wants to move beyond the run-and-forget type of programs, serialization is essential. We can serialize objects to create a sense of persistence in our programs so that the information we gather is not lost, or forgotten, when our program ends. Let's take a look at how to implement serialization in Java
The folks over at Oracle define serializable objects like so:
To serialize an object means to convert its state to a byte stream so that the byte stream can be reverted back into a copy of the object.
There may be many reasons for a programmer to serialize an object, but we will focus on the reason of storing it in a file to be accessed later.
In this case, deserialization is then the process of reverting the serialized form of an object into a copy of the object to use as expected. You can serialize any object that is an instance of a class that either implements
java.io.Serializable interface or its subinterface,
java.io.Externalizable itself or is the subclass of a class that does.
We're going to build a simple phone book app in the console. The program will allow a user to add contacts to their phone book, view their contacts, delete contacts, and save their contacts to a file for later. When the user ends the program and relaunches it later, they will be asked for the name of the file they want to load their phone book contacts from. If a file containing the serialized form of the phone book's contacts exists, the phone book will be loaded from disk and made available to the user for manipulation.
The code related to this article can be found here.
An Introduction to Elixir's Ecto Library
The Importance of Code Reviews
Jump Start Git: Branching in Git
The following is a short extract from our book, Jump Start Git, available for free to SitePoint Premium members. Print copies are sold in stores worldwide, or you can order them here. We hope you enjoy this extract and find it useful.
In Chapter 1, I talked about my one-time fear of trying out new things in a project. What if I tried something ambitious and it broke everything that was working earlier? This problem is solved by the use of branches in Git.
Creating a new branch in a project essentially means creating a new copy of that project. You can experiment with this copy without affecting the original. So if the experiment fails, you can just abandon it and return to the original—the
But if the experiment is successful, Git makes it easy to incorporate the experimental elements into the
master. And if, at a later stage, you change your mind, you can easily revert back to the state of the project before this merger.
So a branch in Git is an independent path of development. You can create new commits in a branch while not affecting other branches. This ease of working with branches is one of the best features of Git. (Although other version control options like CVS had this branching option, the experience of merging branches on CVS was a very tedious one. If you've had experience with branches in other version control systems, be assured that working with branches in Git is quite different.)
In Git, you find yourself in the
master branch by default. The name “master” doesn't imply that it's superior in any way. It's just the convention to call it that.
Note: Branch Conventions
Although you're free to use a different branch as your base branch in Git, people usually expect to find the latest, up-to-date code on a particular project in the
You might argue that, with the ability to go back to any commit, there's no need for branches. However, imagine a situation where you need to show your work to your superior, while also working on a new, cool feature which is not a part of your completed work. As branching is used to separate different ideas, it makes the code in your repository easy to understand. Further, branching enables you to keep only the important commits in the
master branch or the main branch.
Yet another use of branches is that they give you the ability to work on multiple things at the same time, without them interfering with each other. Let's say you submit
feature 1 for review, but your supervisor needs some time before reviewing it. Meanwhile, you need to work on
feature 2. In this scenario, branches come into play. If you work on your new idea on a separate branch, you can always switch back to your earlier branch to return the repository to its previous state, which does not contain any code related to your idea.
Let's now start working with branches in Git. To see the list of branches and the current branch you're working on, run the following command:[code language="bash"]git branch [/code]
If you have cloned your repository or set a remote, you can see the remote branches too. Just postfix
-a to the command above:
As shown above, the branches that colored red signify that they are on a remote. In our case, we can see the various branches that are present in the
There are various ways of creating a branch in Git. To create a new branch and stay in your current branch, run the following:[code language="bash"]git branch test_branch [/code]
test_branch is the name of the created branch. However, on running
git branch, it seems that the active branch is still the
master branch. To change the active branch, we can run the
checkout command (shown below):
You can also combine the two commands above and thereby create and checkout to a new branch in a single command by postfixing
-b to the
The branches we've just created are based on the latest commit of the current active branch—which in our case is
master. If you want to create a branch (say
old_commit_branch) based on a certain commit—such as
cafb55d—you can run the following command:
To rename the current branch to
renamed_branch, run the following command:
To delete a branch, run the following command:[code language="bash"]git branch -D new_test_branch [/code] [caption id="attachment_131996" align="alignnone" width="300"] Deleting a branch in Git[/caption]
Note: Don't Delete Branches Unless You Have To
As there's not really any downside to keeping branches, as a precaution I'd suggest not deleting them unless the number of branches in the repository becomes too large to be manageable.
-D option used above deletes a branch even if it hasn't been synchronized with a remote branch. This means that if you have commits in your current branch that have not been pushed yet,
-D will still delete your branch without providing any warning. To ensure you don't lose data, you can postfix
-d as an alternative to
-d only deletes a branch if it has been synchronized with a remote branch. Since our branches haven't been synced yet, let's see what happens if we postfix
-d, shown below:
As you can see, Git gives you a warning and aborts the operation, as the data hasn't been merged with a branch yet.
Now that we've had a chance to experiment with the basics of branching, let's spend a little time discussing how branches work in Git, and also introduce an important concept:
As mentioned above, a branch is just a link between different commits, or a pathway through the commits. An important thing to note is that, while working with branches, the
HEAD of a branch points to the latest commit in the branch. I'll refer to
HEAD a lot in upcoming chapters. In Git, the
HEAD points to the latest commit in a branch. In other words, it refers to the tip of a branch.
A branch is essentially a pointer to a commit, which has a parent commit, a grandparent commit, and so on. This chain of commits forms the pathway I mentioned above. How, then, do you link a branch and
HEAD and the tip of the current branch point to the same commit. Let's look at a diagram to illustrate this idea:
As shown above,
branch_A initially is the active branch and
HEAD points to commit C. Commit A is the base commit and doesn't have any parent commit, so the commits in
branch_A in reverse chronological order (which also forms the pathway I've talked about) are C → B → A. The commits in
branch_B are E → D → B → A. The
HEAD points to the latest commit of the active
branch_A, which is commit C. When we add a commit, it's added to the active branch. After the commit,
branch_A points to F, and the branch follows F → C → B → A, whereas
branch_B remains the same.
HEAD now points to commit F. Similarly, the changes when we add yet another commit are demonstrated in the figure.
As mentioned earlier, one of Git's biggest advantages is that merging branches is especially easy. Let's now look at how it's done.
We'll create two new branches—
another_feature—and add a few dummy commits. Checking the history in each branch shows us that the branch
another_feature is ahead by one commit, as shown below:
This situation can be visualized as shown below. Each circle represents a commit, and the branch name points to its
HEAD (the tip of the branch).
master, run the following (after first making sure the
master branch is active):
The result can be visualized as shown below:[caption id="attachment_132007" align="alignnone" width="1024"] The status of the repository after merging new_feature into master[/caption]
new_feature, just run the following (making sure that the branch
new_feature is active):
The result can be visualized as shown below:[caption id="attachment_132009" align="alignnone" width="1024"] The status of the repository after merging another_feature into new_feature[/caption]
Important: Watch Out for Loops
The diagram above shows that this merge has created a loop in your project history across the two commits, where the workflows diverged and converged, respectively. While working individually or in small teams, such loops might not be an issue. However, in a larger team—where there might have been a lot of commits since the time you diverged from the main branch—such large loops make it difficult to navigate the history and understand the changes. We'll explore a way of merging branches without creating loops using the
rebase command in Chapter 6.
This merge happened without any “conflicts”. The simple reason for that is that no new commits had been added to branch
new_feature as compared to the branch
another_feature. Conflicts in Git happen when the same file has been modified in non-common commits in both branches. Git raises a conflict to make sure you don’t lose any data.
We’ll discuss conflicts in detail in the next chapter. I mentioned earlier that branches can be visualized by just a simple pathway through commits. When we merge branches and there are no conflicts, such as above, only the branch pathway is changed and the
HEAD of the branch is updated. This is called the fast forward type of merge.
The alternate way of merging branches is the no fast forward merge, by postfixing
--no-ff to the
merge command. In this way, a new commit is created on the base branch with the changes from the other branch. You are also asked to specify a commit message:
In the example above, the former (merging
master) was a fast forward merge, whereas the latter was a no fast forward merge with a merge commit.
While the fast forward style of merges is default, it’s generally a good idea to go for the no fast forward method for merges into the master branch. In the long run, a new commit that identifies a new feature merge might be beneficial, as it logically separates the part of the code that is responsible for the new feature into a commit.
In this chapter, we discussed what branches are and how to manage them in Git. We looked at creating, modifying, deleting and merging branches.