DEV Community: Alain Mauri

My GIT cookbook

Alain Mauri — Thu, 13 Aug 2020 13:52:52 +0000

A collection of commands I often use

This is a work in progress collection of common and less common GIT command I found useful in my day to day job.

Logging

# compact log and graph
git log --oneline --graph

# log actual changes in a file
git log -p <filename>

# log changes not yet merged to the parent branch
git log --no-merges <parent-branch>..

Branches management

# if you want to rename a branch
git branch -m <oldname> <newname>
# if you want to rename the current branch
git branch -m <newname>
# push and delete the old branch
git push <remote> --delete <old_name>
# or
git push <remote> :<oldname>
# push the new branch and reset the upstream branch
git push <remote> -u <newname>

# Check available local and remote branches
git branch -v -r

# Change the URL of a remote
git remote --set-url <remote URL>

# Remove old remote tracking branches
git remote prune origin

Committing changes

Multi-Line message with commit

To write a multi-line commit without opening the editor, use the -m option using single or double quotes, without closing them. Once you finish typing, close the quotes and you will have your nice message.

git commit -m 'Feature: Add ignore files to rubocop
quote>
quote>
* Added routes.rb to rubocop ignore file'
[branchname 387aa73] Feature: Add ignore files to rubocop
1 file changed, 1 insertion(+)

Commit message using the editor and a template

If you want to use an editor for the commit and prefer to have a template that will be consistent all across your commits you can drop a .gitmessage file in your home folder with something similar in it:

Refactoring/Bugfix/Feature: Title
* Description

An then tell GIT that you want to use that file, passing its absolute path, otherwise it will be interpreted as relative:

git config commit.template /absolute/path/to/.gitmessage

miscellaneous

# fix the last made commit
git commit --amend
# edit the previous n commits
git rebase -i HEAD~n
# undo the last n commits
git reset HEAD~n

General

List Files with conflicts when merging

git diff --name-only --diff-filter=U

Stop tracking files added to .gitignore

Sometimes happens that after adding a file or a folder to .gitignore you're still seeing it in a git status.
What you have to do is removing the files or the folder from the cache using:

git rm --cached <filename>
# or
git rm --cached -r /path/to/folder/**/*

This list will probably increase as soon as I will learn something new, so...

Stay Tuned!

Thoughts on Merge vs Rebase

Alain Mauri — Wed, 08 Jul 2020 07:34:54 +0000

Both merge and rebase offer the same service which is incorporating commits from one branch into another, but how is this done?

Merge

Given the two following branches

      A---B---C Release
     /
D---E---F---G Development

And given that the current branch is Development, when you perform a merge:

git merge Release

The merge will replay all the changes that have been made on Release since it diverged from Development up to commit C, on top of Development, recording the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes

      A---B---C Release
     /         \
D---E---F---G---H Development

An example of a merge commit from some code

commit ca617c46f71507d1bdf44d452e1a7f0a6740c344
Merge: ea47a12b3 e16cbd937
Author: Foo Bar <foo.bar@funnyplace.fu>
Date:   Wed Mar 18 12:42:03 2020 +0000

    Merge pull request #836 in Baz/funny-services from bar/FAB-579 to development

    * commit 'e16cbd937937bd368c28bd7677f211997231a4f1':
      FAB-479 removed breaking dependency

Whats is the downside of merge? If used too liberally, merge commits could clutter your git log, making difficult to understand the flow of the project changes:

git log --oneline --graph --decorate --all

|/ / /  
* | |   d61503b9e (tag: 1.0.14) Merge pull request #753 in FUN/funny-services from foobaz/TEAM-487-a to development
|\ \ \  
| * | | ea8052a6c (origin/foobaz/TEAM-487-a) TEAM-487 add mongo ssl/auth for progressive
* | | |   534cc7abf Merge pull request #745 in FUN/funny-services from foobaz/TEAM-487-a to development
|\ \ \ \  
| |/ / /  
| * | | 2bc74b0c7 TEAM-487: Customer - some nice stuff
|/ / /  
* | |   721565549 Merge pull request #752 in FUN/funny-services from foo/HEART-93-mongoclient-auth to development
|\ \ \  
| * | | c1ba829fd (origin/foo/HEART-93-mongoclient-auth) HEART-93 lib release versions.
| * | |   9f3d3a443 Merge branch 'development' into foo/HEART-93-mongoclient-auth
| |\ \ \  
| |/ / /  
|/| | |   
* | | |   82e3b898d Merge pull request #751 in FUN/funny-services from baz/TEAM-A-638 to development
|\ \ \ \  
| * | | | f920814a5 (origin/baz/TEAM-A-638) TEAM-A-638 Fixed variable name
| * | | | 688a166d8 TEAM-A-638 Added missing content
* | | | |   271e8d3c8 Merge pull request #744 in FUN/funny-services from baz/TEAM-A-638 to development
|\ \ \ \ \  
| |/ / / /  
| * | | | 1ebb5100a TEAM-A-638 removed useless comments
| * | | | d03467db6 TEAM-A-638 refactored packages and classes
| * | | | 08064700b TEAM-A-638 renamed controller file name
| * | | | 59c93e015 TEAM-A-638 add deactivation control and model + tests
* | | | |   8c3b6b33a Merge pull request #747 in FUN/funny-services from foobaz/TEAM-528 to development
|\ \ \ \ \  
| * | | | | f61fa3a90 (origin/foobaz/TEAM-528) TEAM-528: upload tool to source control.
| |/ / / /  
| | * | | 9a2cc0515 HEART-93 changes to support catch-up.
| | * | |   636f5db20 Merge branch 'development' into foo/HEART-93-mongoclient-auth
| | |\ \ \  
| |_|/ / /  
|/| | | |   
* | | | |   946f4e8d4 Merge pull request #749 in FUN/funny-services from bar/FAB-420-resolve-client-ids to development
|\ \ \ \ \  
| * | | | | 97531eb5a (origin/bar/FAB-420-resolve-client-ids) FAB-420 Fixed missing error message
| * | | | | d54f7c7da FAB-420 Added client id
* | | | | |   fbb71d8e1 Merge pull request #748 in FUN/funny-services from foobaz/TEAM-419-add-back-in to development
|\ \ \ \ \ \  
| |/ / / / /  
|/| | | | |   
| * | | | | caad3ef9a (origin/foobaz/TEAM-419-add-back-in) TEAM-419: Customer - re-adding endpoint for Customer
|/ / / / /  
| | * | |   91588ab17 Merge branch 'development' into foo/HEART-93-mongoclient-auth
| | |\ \ \  
| |_|/ / /  
|/| | | |   
* | | | |   70aa26022 Merge pull request #733 in FUN/funny-services from foobaz/TEAM-503 to development

Rebase

Given the same branches as before:

      A---B---C Release
     /
D---E---F---G Development

suppose that the current branch is Release and that you want to update it, to include all the latest changes that have been merged into Development. This the case where rebase is really helpful:

git rebase Development

D---E---F---G---A'---B'---C' Release

To perform this operation Git goes back in the history until it finds the common ancestor ( commit E ), gets all the diffs introduced by your changes and saves them in temporary files. It then resets the current branch ( Release) to the same commit as the branch you're rebasing onto ( Development commit G) and then finally applies all your changes in turn. You then end up with a clean and linear history.

Keep in mind that, although the applied changes are exactly the same, from Git perspective these are new commits with a new SHA, meaning that you're rewriting the history of your branch.

From Git manual, the main difference between merge and rebase:

Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.

When to use merge and when to use rebase

In summary:

Use merge if you want a set of commits clearly grouped in history
User rebase if you want a linear history and if you're contributing to a bigger projects that you don't control. In this case rebasing your branch means that you solve all the conflicts locally and the project's maintainer does not have to do any integration work.
Do not use rebase on a shared branch - Don't rebase Development/Main onto a working branch.

Enjoy!

Another GIT Introduction part 2

Alain Mauri — Wed, 08 Jul 2020 07:03:48 +0000

I'm posting here a series of introductory articles I wrote on another platform, hoping you will enjoy them

In my previous article, I wrote about the differences between GIT and other versioning systems, some basic terminology, states and working areas, what is the heart of a GIT system and the object it stores.

Starting from the last point, I want to recall what are the objects that GIT stores: Blobs, Trees, Commits and Tags.

But where and how are these objects stored?

At the core of GIT there is a simple key-value data store, that gives you the capability of storing whatever kind of content you want. The system will give you back a key that can be used to retrieve the data at any time.

When you initialise a new repository, GIT creates a .git folder, with some others sub-folders: objects, objects/info, objects/pack as you can see from the following example:

git init plain_git
Initialized empty Git repository in /tmp/plain_git/.git/
cd plain_git
find .git/objects
.git/objects
.git/objects/pack
.git/objects/info

Obviously, at this point there aren't any object in the repository and you need to add one:

touch status.txt
# Now edit and save the file
# check the status of the repository

git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    status.txt

nothing added to commit but untracked files present (use "git add" to track)

# add the file to the staging area 
git add .

# then save it to your repository
git commit -m "first commit"
[master (root-commit) 51dcfd9] first commit
 1 file changed, 1 insertion(+)
 create mode 100644 status.txt

# Now check the objects created

find .git/objects
.git/objects
.git/objects/51
.git/objects/51/e1acfa6ecdb46d6c9d4ad13e82b5cab90d5f3f
.git/objects/51/dcfd9bba09650f50ccad8dde3ad5fe8ba68ad2
.git/objects/pack
.git/objects/info
.git/objects/53
.git/objects/53/8d4c75373bb8ebb9af381c4e8287b6f0819533

What happens when you create a file? When you run the git status command, GIT checks if the file was in the previous snapshot of your repository and, if not, marks it as untracked.

To start tracking it, you need to add it to the staging area using

git add <file-name>

At this point the file is staged and ready to be committed using

git commit -m "first commit"

After committing, using the following command

find .git/objects -type f

we can take a look at what kind of files GIT creates:

find .git/objects -type f
.git/objects/51/e1acfa6ecdb46d6c9d4ad13e82b5cab90d5f3f
.git/objects/51/dcfd9bba09650f50ccad8dde3ad5fe8ba68ad2
.git/objects/53/8d4c75373bb8ebb9af381c4e8287b6f0819533

As you can see, after a commit GIT creates three files under the '51' and '53' sub-folders, but where these names come from?
When you commit a file, GIT calculates a 40-characters checksum hash for your file content plus a header in the following way
First it calculates the header

<type-of-content> + <space> + <content size> +<\0> (null char)
eg: blob 7\000

It then concatenates the header to the content

<header> + <content>

and calculates the SHA-1 checksum of this new content.

The '51' and '53' sub-folder names are directly coming from the first two digits of the checksum, while the filenames are the remaining 38 characters.
Now, let's take a look at the files in detail using the following code:

# Tree object
git cat-file -p 51e1acfa6ecdb46d6c9d4ad13e82b5cab90d5f3f
100644 blob 538d4c75373bb8ebb9af381c4e8287b6f0819533    status.txt

# Commit object: Author info, Committer info and commit message
git cat-file -p 51dcfd9bba09650f50ccad8dde3ad5fe8ba68ad2
tree 51e1acfa6ecdb46d6c9d4ad13e82b5cab90d5f3f
author wildeng <wildeng@myemail.com> 1563483367 +0100
committer wildeng <wildeng@myemail.com> 1563483367 +0100

first commit

# Content of the file
git cat-file -p 538d4c75373bb8ebb9af381c4e8287b6f0819533
This is my first commit

As you could see, I used the command

git cat-file -p <SHA-1>

which is a sort of Swiss army knife for GIT objects. It helps you inspecting any kind of GIT object and the -p option prints in a nice form its content.

If, for example, you apply it to a commit it will first uncompress the file and then it will nicely display it on STDOUT.

As a reference, here is the output of the -h option ( help )

git cat-file -h
usage: git cat-file (-t [ - allow-unknown-type] | -s [ - allow-unknown-type] | -e | -p | <type> | - textconv | - filters) [ - path=<path>] <object>
 or: git cat-file ( - batch | - batch-check) [ - follow-symlinks] [ - textconv | - filters]
<type> can be one of: blob, tree, commit, tag
 -t show object type
 -s show object size
 -e exit with zero when there's no error
 -p pretty-print object's content
 - textconv for blob objects, run textconv on object's content
 - filters for blob objects, run filters on object's content
 - path <blob> use a specific path for - textconv/ - filters
 - allow-unknown-type allow -s and -t to work with broken/corrupt objects
 - buffer buffer - batch output
 - batch[=<format>] show info and content of objects fed from the standard input
 - batch-check[=<format>]
 show info about objects fed from the standard input
 - follow-symlinks follow in-tree symlinks (used with - batch or - batch-check)
 - batch-all-objects show all objects with - batch or - batch-check

As a final step let's add a tag to our repository and see what happens:

# Adding a tag to our commit
git tag -a v0.1 -m "a nice commit"

# looking for the created files we see that one more file
# has been created
find .git/objects -type f
.git/objects/51/e1acfa6ecdb46d6c9d4ad13e82b5cab90d5f3f
.git/objects/51/dcfd9bba09650f50ccad8dde3ad5fe8ba68ad2
.git/objects/53/8d4c75373bb8ebb9af381c4e8287b6f0819533

# new folder and new file created
.git/objects/11/85637c960727f803e5229393839629479c7b8d

# content of the TAG object
git cat-file -p 1185637c960727f803e5229393839629479c7b8d
object 51dcfd9bba09650f50ccad8dde3ad5fe8ba68ad2
type commit
tag v0.1
tagger wildeng <wildeng@myemail.com> 1563610234 +0100

a nice commit

a nice tag

When you add a tag, git creates a new object with its own SHA-1 checksum and creates a sub-folder to store it.
In this object, GIT saves the information about the object type that has been tagged - a commit - , the annotation used - v0.1 - , the author of the tag and the human readable message added to the tag.
Now you should have an understanding of what GIT is doing when you commit a file, what are the objects involved and how GIT stores them.
In the next episode I will talk about what happens in a basic GIT workflow, how you can take a look at the history of the repository and how you can change it.
Enjoy!

References:

GIT - GIT Objects

GIT Pocket Guide

Apple animated logo

Alain Mauri — Sun, 24 May 2020 20:25:02 +0000

It's been a rainy day, so I decided to have some fun while listening to some music :)

Another GIT Introduction - part 1

Alain Mauri — Thu, 16 Apr 2020 07:29:46 +0000

I'm posting here a series of introductory articles I wrote on another platform, hoping you will enjoy them

The main difference from GIT and other control versioning systems -Subversion for example - is the way it thinks about its data. What usually happens with other systems is that they store data as a set of files and the changes made on each file over time, while GIT thinks about its data as a series of snapshots of a mini filesystem.

How a Subversion style system manages changes

This means that every time you commit, it takes a picture of your project at that moment and saves a reference to it and. As a matter of efficiency, if a file has not been changed, it saves only a link to the previous file.

How GIT manages changes

Another important fact about GIT is that almost every operation is local and generally, you do not need to go online because the entire history of your project is stored locally. Because of this, most of the operations seems instantaneous.

GIT states and terminology

GIT workflow is based on three main states:

Committed: data is safely stored in your local database.
Modified: you changed your files but they are not yet added to your local database.
Staged: you marked a file in the current version to go into the next commit.

Following the previous definitions, three main working areas can be identified:

GIT directory: where GIT stores the metadata and the database for your project.
Staging area: this is a simple file, saved in the GIT directory, where GIT stores all the informations on what will go into your next commit.
Working directory: this is a single checkout of one version the project. The files are pulled out of the GIT directory and placed on disk for you to modify.

GIT main areas

From the picture above we can define how a typical GIT workflow looks like:

You modify the files in your working directory.
You stage them, adding a snapshot in the staging area
You perform a commit which takes the snapshot from your staging area and stores it permanently in your GIT directory.

GIT Objects

What is the real heart of a GIT repository and which kind of objects GIT stores?

The object store is the correct answer, a database that holds four kind of items: blobs, trees, commits and tags</>.

Blobs are a string of bytes with no further internal representation, as far as GIT is concerned. This does not mean that its implementation is simple. Every version of a file in GIT is represented with a blob where the entire content of the file is contained. If on one side this means occupying more space on disk, on the other side has the advantage of preventing corruption. If this happens on a blob, future versions of the file are not affected by it.

A Tree represents a portion of the repository content at one point in time, a snapshot of a particular directory all its children included.

A Commit is a snapshot of the entire repository content with additional data like identifying content such as author's name or committer's info, relationship of this state with all the other recorded states, providing an evolution of the repository over time.

Specifically it is composed by:

A pointer to a tree containing the complete state of the repository at one point in time.
Author and committer information plus time and date the changes have been introduced.
A list of zero or more objects, parents of the current commit.

A Tag is basically a commit with a human readable name in a namespace reserved for this purpose.

It consists of:

Name of the person making the tag
A timestamp
A reference to the tagged commit
A free-form text message

Hopefully you will now have appreciate the clever engineering that lies behind GIT curtains and also have a basic understanding of how it works.

In the next posts I will try to explain some other related GIT arguments that I found useful and interesting like rewriting history. I will also share some nice and useful GIT commands I use day by day.

Enjoy!

Dockerfile template for Rails Apps

Alain Mauri — Sun, 12 Jan 2020 17:21:18 +0000

Disclaimer:

This post assumes that you know how Docker works and you know how to build images passing some arguments and that you know how to run a container.
It's not and introduction to Docker.
If you find any kind of error please contact me and I will amend the post.

Update:

I've created a Github repo with some other stuff to support this post.

A Dockerfile template for Rails apps

Problem:

I wanted to find a way to improve the on-boarding process of new developers joining my team and to improve the day to day life of my team's "legacy" developers. At that time, everyone had to manage different Ruby versions for different projects, manage different environment variables and so on. You can imagine how painful could have been such a process for a new developer in the team so, I started looking around for possible solutions.

Solution:

After searching and reading a lot around, I came up with the conclusion that Docker could have been a good solution.
Containers run in isolation, you can replicate a production environment, it runs on different systems and you can easily tweak it to test different features of your app.
So everything seemed easy and pretty much working out of the box so, I came up with this:

FROM ruby:2.5.3

# The qq is for silent output in the console
RUN apt-get update -qq && \
  apt-get install -y build-essential openssl libssl-dev nodejs-legacy less vim libsasl2-dev


# Sets the path where the app is going to be installed
# you can modify this as you wish
ENV WORK_ROOT /var
ENV RAILS_ROOT $WORK_ROOT/www/
ENV LANG C.UTF-8
ENV GEM_HOME $WORK_ROOT/bundle
ENV BUNDLE_BIN $GEM_HOME/gems/bin
ENV PATH $GEM_HOME/bin:$BUNDLE_BIN:$PATH

RUN gem install bundler -v 1.17.3

# Creates the directory and all the parents (if they don't exist)
RUN mkdir -p $RAILS_ROOT

WORKDIR $RAILS_ROOT

# We are copying the Gemfile first, so we can install
# all the dependencies without any issues
# Rails will be installed once you load it from the Gemfile
# This will also ensure that gems are cached and only updated when
# they change.
COPY Gemfile ./

# Installs the Gem File.
RUN bundle install

# We copy all the files from the current directory to our
# application directory
COPY . $RAILS_ROOT

This was working fine for a while until one day... One day I decided that, because of the fact our production environment were Linux based, I wanted to go back to Linux and so, after giving back my Macbook Pro, I asked the company to provide me a Linux based machine.

After setting it up properly, the easiest part should have been checking out the projects, starting up a container and done! Ready to go!

No way!

There was one point that I did not consider at that time. Macbooks are nice and shiny machines, but Docker runs on them in a virtual machine while in a Linux environment it runs as a daemon with root permissions...

So the point is that, after running the container, all my files were "property" of the root user and I had to manually chmod then everytime.

This was annoying and not the purpose of the entire effort. Anyway this problem can be easily overcome by passing some environment variables while building the image and creating a user that has the same gid and uid of the host user:

ARG RUBY_VERSION
FROM ruby:$RUBY_VERSION

ARG BUNDLER_VERSION
ARG uid
ARG gid
# The qq is for silent output in the console
RUN apt-get update -qq && \
  apt-get install -y build-essential openssl libssl-dev nodejs-legacy less vim libsasl2-dev

# To not run the container as root I create a users that shares
# uid and gid with the host user.
# In this way we can avoid having our working folder owned by root
RUN groupadd -g $gid webuser
RUN useradd -ms /bin/bash -u $uid -g $gid webuser

# Sets the path where the app is going to be installed
ENV WORK_ROOT /var
ENV RAILS_ROOT $WORK_ROOT/www/
ENV LANG C.UTF-8
ENV GEM_HOME $WORK_ROOT/bundle
ENV BUNDLE_BIN $GEM_HOME/gems/bin
ENV PATH $GEM_HOME/bin:$BUNDLE_BIN:$PATH

RUN gem install bundler -v $BUNDLER_VERSION

# Creates the directory and all the parents (if they don't exist)
RUN mkdir -p $RAILS_ROOT

RUN chown -R webuser:webuser $GEM_HOME
RUN bundle config --path=$GEM_HOME

WORKDIR $RAILS_ROOT

# We are copying the Gemfile first, so we can install
# all the dependencies without any issues
# Rails will be installed once you load it from the Gemfile
# This will also ensure that gems are cached and only updated when
# they change.
COPY Gemfile ./
COPY Gemfile.lock ./

RUN chown -R webuser:webuser $RAILS_ROOT

USER webuser
# Installs the Gem File.
RUN bundle install

# We copy all the files from the current directory to our
# application directory
COPY . $RAILS_ROOT

after doing it, I came up with a Dockerfile working on both Linux and MacOS machines (sorry Windows users I don't know if this works on your system).

I also added some other environment variables like Ruby version, Bundler version that can be passed to Docker while building the image.

You could think we're at the end, not at all. The company I'm working for uses LDAP so, uids and gids are big numbers and this carries a problem while creating the user in Docker I wasn't aware of. Basically if you add a user without --no-log-init option, Docker will try to create lastlog as a massive sparse file that could easily eating your disk space.
(more here and here)

So I ended up with this:

ARG RUBY_VERSION
FROM ruby:$RUBY_VERSION

ARG BUNDLER_VERSION
ARG uid
ARG gid
# The qq is for silent output in the console
RUN apt-get update -qq && \
  apt-get install -y build-essential openssl libssl-dev nodejs-legacy less vim libsasl2-dev

# To not run the container as root I create a users that shares
# uid and gid with the host user.
# In this way we can avoid having our working folder owned by root
RUN groupadd -g $gid webuser
RUN useradd --no-log-init -ms /bin/bash -u $uid -g $gid webuser

# Sets the path where the app is going to be installed
ENV WORK_ROOT /var
ENV RAILS_ROOT $WORK_ROOT/www/
ENV LANG C.UTF-8
ENV GEM_HOME $WORK_ROOT/bundle
ENV BUNDLE_BIN $GEM_HOME/gems/bin
ENV PATH $GEM_HOME/bin:$BUNDLE_BIN:$PATH

RUN gem install bundler -v $BUNDLER_VERSION

# Creates the directory and all the parents (if they don't exist)
RUN mkdir -p $RAILS_ROOT

RUN chown -R webuser:webuser $GEM_HOME
RUN bundle config --path=$GEM_HOME

WORKDIR $RAILS_ROOT

# We are copying the Gemfile first, so we can install
# all the dependencies without any issues
# Rails will be installed once you load it from the Gemfile
# This will also ensure that gems are cached and only updated when
# they change.
COPY Gemfile ./
COPY Gemfile.lock ./

RUN chown -R webuser:webuser $RAILS_ROOT

USER webuser
# Installs the Gem File.
RUN bundle install

# We copy all the files from the current directory to our
# application directory
COPY . $RAILS_ROOT

Which is what I'm currently using.

Enjoy!

Find files between two dates

Alain Mauri — Wed, 08 Jan 2020 21:20:58 +0000

Find files between two dates

I’d like to share a simple way I’ve learned to find how many files have been created between two dates, using Linux command line. The method involves find command.

Problem

Working on a project that involved the creation of a lot of KOS objects (nothing difficult, just another DICOM object), I needed a quick and easy way to find out how many files my class method created.

Solution

I knew that find command could help, so I started digging into its manual and at the end I found the right option:

 -newerXY reference
Succeeds if timestamp X of the file being considered is newer than timestamp Y of the file reference. The letters X and Y can be any of the following letters:

              a   The access time of the file reference
              B   The birth time of the file reference
              c   The inode status change time of reference
              m   The modification time of the file reference
              t   reference is interpreted directly as a time

after many trials I ended up with newermt which is newer with sub-options X=m for modification date and Y=t for literal time.

At this point my “command” was taking shape:

find -type f -name "*.dcm" -newermt 2016-04-08 ! -newermt 2016-04-09

Last thing I needed to know, was the number of files that have been created in the desired date interval and this was the easiest part of the command:

wc -l

the command used prints the newline count.

Finally:

find -type f -name "*.dcm" -newermt 2016-04-08 ! -newermt 2016-04-09 | wc

Enjoy!