0 Comments

git-logo_thumb2

In this blog post we will look at how we can merge multiple commits into a single one with the goal of reducing the chatter in a git log. This technique is generally known as squashing.

When to use it

When working on a new feature (User Story) it is best practice to often commit. This gives you the option of always reversing back to a safe spot without loosing a great amount of work. But once you commit the changes to a remote repository it would be nice to get the quintessence of your work within one/a few meaningful commit(s). Often all those small safety hooks no longer are helpful on the server repository and may even harm the flow of reading through the log and getting the big picture.

How is it done

You can either rebase based on the commit count you want to squash or the commit id:

git rebase -i 003ee6c6f34516ad325a72d430e5a269e470b4d3

Alternatively you can set the count of commits you want to rebase:

git rebase -i HEAD~4

Here we are telling git to rebase the last four commits. After executing the command your editor of choice for commit messages will popup:

pick 5629556 Adds second paragraph
pick 56ea060 Adds third paragraph
pick 892c090 Adds final paragraph

# Rebase 003ee6c..892c090 onto 003ee6c
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Simply change the commands to squash i.e. s and your commits will be squashed into one single commit. Note you want to pick the starting point of your squashing:

pick 5629556 Adds second paragraph
squash 56ea060 Adds third paragraph
squash 892c090 Adds final paragraph

# Rebase 003ee6c..892c090 onto 003ee6c
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Which merge your commit messages i.e. lets you edit the message that will be associated with the commit:

Some very meaningful merge commit message comes here.

# This is a combination of 3 commits.
# The first commit's message is:
Adds second paragraph

# This is the 2nd commit message:

Adds third paragraph

# This is the 3rd commit message:

Adds final paragraph

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# rebase in progress; onto 003ee6c
# You are currently editing a commit while rebasing branch 'master' on '003ee6c'.
#
# Changes to be committed:
#    modified:   someFile.txt
#

When to leave your fingers from this technique

Do not rebase commits that exist outside your repository.

With rebase you are changing the history of the git repository. If you do this on a history that you have published and that other people are using.. Let’s just say you will not be rewarded by many friendly words. As you will mangle the history which they are using to work upon leading into a big mess. So only apply rebasing to local repositories which you haven’t published yet. An exception is if you are the only committer to a repository (and do not have any other copies with work lying around..).

Conclusion

Using git rebase enables you to modify the commit history and make it more readable and less clunky. This helps you and your co-committers to have a nice log history with meaningful commits. Further it allows developers while coding to commit often to the local repository and easily go back in time if an approach has proven futile. All without littering the log history of the project and ending up with a ton of non-meaningful log entries.

Do however never rebase on public history as this might lead to tears and intense discussions.

References:

https://help.github.com/articles/about-git-rebase/

http://www.git-scm.com/book/en/v2/Git-Branching-Rebasing

0 Comments

During my day job I’m mainly involved in mobile applications which often (like in always…) have to communicate with a backend that provides data and other services to the mobile app. The backend often needs to be more then a mere database gateway and is often extended with additional features which enables a rich mobile app experience and integration to other systems. These services change over time and when the app is successful are required to offer ever more functionality. Microservices is a new buzzword in town that comes with praises which allow a system to grow without slowing down the development and further allows for better fault tolerance due to it’s distributed nature.

Building Microservices is a book written by Sam Newman which covers the ideas and concepts behind microservices and gives an introduction into the challenges of monolithic systems and how microservices try to solve the demands towards todays services.

A general take

The author assumes that the reader has a general understanding of application and service development. The author goes through great lengths to ensure the reader gets a general understanding of how services can be created and what the ideas are behind their designs. Thereby he highlights what the benefits and downsides are for each system. The reader is led through many different aspects of designing a microservice from communication protocols, datastorage even company culture which boosts the design of microservices are described in the book and introduce the concepts and patterns on which microservices are built on.

While the book contains a lot of conceptual information on microservices and development techniques it does not go into great detail on the topics. However if your interested you will find references to books, libraries, frameworks etc. in the book. So if you are looking for a step-by-step guide on how to create a microservice with language X using framework Y you will not be happy with this book. If however you are looking for an overview and introduction into microservices i.e. on how to leverage microservices in your projects this is the book for you - and if you are looking for a cookbook book, consider reading this book anyway as it will give you some great insight on what to look out for when creating your service Winking smile

The books content

Due to the high level approach the book covers a lot of topics and gives a good insight in what is to be expected, so lets have a glance at what is available in the books 280 pages:

  1. Microservices
    • This chapter gives a basic introduction into the topic and introduces the idea behind microservices. Also explains why microservices are no silver bullet.
  2. The Evolutionary Architect
    • Explains the role of an architect when having a system created of microservices.
  3. How to Model Services
    • Defining boundaries of services and how this effects the data model being passed in between. This chapter takes input from Domain Driven Design and explains how these could be implemented in a service i.e. why they should be considered.
  4. Integration
    • Explains how services can be integrated together. How one use different technology stacks for different tasks at hand without creating an error prone system.
  5. Splitting the Monolith
    • This chapter shows how existing applications can be split up into microservices. The author generally advises to first start out with the monolith and only when the demand for microservices arises should the system be pushed into that direction.
  6. Deployment
    • Having multiple services comes with a larger complexity when it comes down to deployment. In this chapter you see how to automate as much as you can for your services leaning heavily on Continuous Integration and Continuous Deployment methodologies.
  7. Testing
    • This chapter shows how to automatically test your services with tests that go beyond unit tests. It introduces the concept of load tests. Further explains why system wide tests are not as useful as one would hope due to their brittleness and how to replace them with more modular tests.
  8. Monitoring
    • This chapter shows how to effectively monitor multiple services deployed on multiple instances and what are the key metrics you should implement into your services.
  9. Security
    • Perhaps one of the most important chapter shows the challenges faced when developing a service and how to secure the systems. It provides information on what are the current industry standards which you should use and how to manage data. Core take away: do not write your own security software - unless you are a security expert.
  10. Conway’s Law and System Design
    • In this chapter the idea of Conway’s law is applied to microservices and highlights how team organization will impact the design and architecture of your system for better or worse. These are backed up with some real world examples of companies such as Netflix and Amazon which went with the microservice design approach and built their teams/company culture accordingly.
  11. Microservices at Scale
    • This chapter gives you a glance at what it means to have a business running on microservices. Dealing with failing services by degrading functionality, caching, discovering services and scaling (including database scaling) will be looked at in this chapter
  12. Bringing it all together
    • The final chapter goes over the principles of microservices and gives a reminder when to not use microservices.

Generally speaking this book covers a lot of topics within 280 pages and the author does a great job in building up the knowledge of the reader. So much that I every time a new chapter started I found myself wanting to know how this additional puzzle piece fits into the picture. One notices while reading the book that the author has had a lot of real world experience and shares his insights throughout the book and giving hints on where to dig deeper if you ever need or want to do so on a given topic.

Conclusion

Building microservices gives a great introduction into the concept behind microservices and shows why the approach is a great solution to certain problems which just happen to be a lot of apps we are writing these days Smile

This book gives you a conceptual overview and stays clear of diving into technical solutions (though you will find links to notable libraries, frameworks etc. throughout the book) but explaining concepts on how to solve certain problems that occur in highly decoupled and distributed environments. The book therefore is not bound to a certain technology stack or development language.

If you are looking for a book that gives you a general overview of the topic or are looking for a book that gives you an introduction into microservices I can only recommend this book to you and hope you will enjoy reading it as much as I did.

Small Remark: I read this book on my Kindle and the formatting was flawless.

0 Comments

GitToGitHub

I usually end up looking for these steps every time I write a blog post with a code sample that I in the end push up to GitHub. So the steps I do are:

  1. Creating and committing to a local git repository
  2. Create a GitHub repository with License (and readme)
  3. Configure the local repository to push it to GitHub

Step one is usually done by creating a new Solution in Visual Studio which automatically adds the gitignore file according to my C# project which is very helpful to not ending up committing the bin folder and the NuGet package binaries.

After finishing my solution I go to GitHub and create a new repository, in the setup process you can add a License file and a blank readme. You could also add the gitignore at this step but as some of my code gets thrown away as it is of no use I tend to first start locally and then push the solution once I feel it has some value to add.

Now once all is setup on GitHub I use the Git Shell which you get after installing GitHub for Windows . There navigate to the root of your project and add the repository (you find the uri after creating the repo) with the following line:

git remote add origin https://github.com/your-account/the-repository-name

Next verify that your branch has been successfully added as a remote branch:

git remote -v

First we have to get the remote branch to our local repository:

git fetch

Then set the upstream branch:

git branch --set-upstream-to=origin/master master

Pull the license and possible readme (et al):

git pull

Now you can simply push your main branch to GitHub:

git push

And all is good :-)

Technorati Tags: ,,

0 Comments

Ever had the need to correct multiple filenames?

S0501_SomeName
S0502_SomeName
S0503_SomeName
S0504_SomeName

The following command will allow you to replace the substring and insert another string (or just replace it with an empty string) if needed.

for filename in *.m4v; do newname=`echo $filename | sed 's/S05/S04/g'`; mv $filename $newname; done

Which will transform the sample list to:

S0401_SomeName
S0402_SomeName
S0403_SomeName
S0404_SomeName

HTH

0 Comments

surfacepro3

I got a Surface 3 Pro recently and I really love the fact that I can use it as a tablet and as a normal Laptop but am not bound to carrying two devices with me. One problem I received was after installing Visual Studio which installs and activates Hyper-V automatically. Hyper-V disables the connected Stand-By mode on your Surface. No problem there but that connected stand-by is also your sleep mode and living without a sleep mode on your tablet is a real pain point.

The solution

Luckely we can easily change this behaviour by switching Hyper-V off when we do not need it with the following command:

bcdedit /set hypervisorlaunchtype off

And if we do need Hyper-V for development we can enable it again with this line of code:

bcdedit /set hypervisorlaunchtype auto

You will have to run each command in an elevated powershell as admin. Simply open Powershell rightclick on the Taskbar icon and select Run as Administrator.


HTH