Category Archives: Uncategorized

Things everyone should know about responsive images and srcset

The aim of responsive images is to deliver the same image in mobile and desktop view without disturbing the viewport size that is the image should look alike in every device .

Therefore this problem of responsive images can be solved by using srcset attribute in image tag or using media queries.

Both are suitable to deal with this situation but prefer to use srcset instead of media queries because media queries will take time to write but srcset does the same thing in small time and space .
The information below will explain all about srcset .

srcset
The srcset attribute is listing different resolutions of the same image from which the browser chooses the best fitting image source before loading it.
Example: srcset="ninja-1000w.jpg 1000w, ninja-500w.jpg 500w, ..."
To calculate this, the browser assumes the image fills up the full viewport width (100vw) by default, which means it uses the full width of the browser.

In short, Srcset is a new attribute which allows you to specify different kind of images for different screen-sizes/orientation/display-types.
The usage is really simple, you just provide a lot of different images separating them with a comma like this:

<img src="image.jpg" alt="image" srcset="<img> <descriptor>, ..., <img_n> <descriptor_n>">.

Here is an example:

srcset="image.jpg 160w, image2.jpg 320w, image3.jpg 2x"

Descriptors are just a way to show what kind of image is coming from the resource. There are various kinds of descriptors:

  1. density descriptor–> srcset=”image.jpg, image-2X.jpg 2x” The display density values—the 1x, 2x, etc. are referred to as display density descriptors. If a display density descriptor isn’t provided, it is assumed to be 1x.
  2. width descriptor –> srcset=”image-240.jpg 240w, image-640.jpg 640w”.
    When using the w-descriptor we have to specify the default explicitly by adding a second srcset image option, with its own w-descriptor, and separating them with a comma.
  3. size descriptor–> It only makes sense if you use width descriptor.
    srcset=”image-160.jpg 160w, image-320.jpg 320w, image-640.jpg 640w, image-1280.jpg 1280w” sizes=”(max-width: 480px) 100vw, (max-width: 900px) 33vw, 254px”>.
    The instructions for the browser would look like this: (max-width: 480px) 100vw — if the viewport is 480 pixels wide or smaller, the image will be 100% of the viewport width.So it is like using media queries in html which looks a lot easier as compared to media queries written in css .

Pros–>
1.much easier than media query
2.saves time

Cons–>
1.Browser should be updated to see the effect
2.Not all browsers support this.
At present, Edge, Safari, and iOS Safari only support a subset of the srcset specification. Firefox, Chrome, Opera, Android Browser, and the forthcoming versions of Safari and iOS Safari fully support it.

Demo can be seen on my github link

pershantgoel.github.io/imgsrcset

Test Driven Development with SpringBoot+Junit

 

Test-driven development(TDD) in the Spring framework.

TDD  helps me speed up my software release cycles, and ensure that I end up with a high-quality product. Spring makes Java enterprise development much easy.  Spring Boot, which we will use in this blog, is a project that does this task with excellence.

Follows are the steps to configure your spring boot framework with the Junit and Maven.

Step-1)Set up Spring boot with J-Unit testing Approach

After Set your maven dependencies , for spring-boot add following dependency for testing Approach.

<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.4</version>
<scope>test</scope>
</dependency>

<dependency>
<groupId>org.springframework.restdocs</groupId>
<artifactId>spring-restdocs-mockmvc</artifactId>
<scope>test</scope>
</dependency>

Step-2)Create test Package and in that ,create DemoApplicationTests Class.

Step-3)Inject controller using @InjectMocks, Inject repository using @Mock Annotations.

Let us take some J-Unit Annotations used in java class :

@Before:@Before annotation are executed before each test.

@After:It executes after each test.

@BeforeClass: It executes common operation before each test,So it executes  only once before running all tests.

@AfterClass: It executes common operation after each test, So it executes only once after running all tests.

@Test:The Test annotation tells JUnit that the public void method to which it is attached can be run as a test case.

In JUnit 5, the tags @BeforeEach and @BeforeAll are the equivalents of @Before and @BeforeClass in JUnit 4.

Configure Java File and Select Run as Junit and Test the file.

 

Congratulations!!!you are done with your TDD approach.

Eclipse not auto-configuring/auto-importing a Git mavenized project

I was trying to setup a maven project in eclipse via GIT. I had hoped, it will auto import the project into eclipse, but for some reason that did not happen.

 

This is what was done as a workaround:

Step:1 Checkout your repository in your system

File->import->Git->Project from Git->Clone URI->Enter Git Repository Details

Select Destination where you wanted to store your Git Repository

Step:2 Import your Project into Eclipse

File->import->maven->install or deploy an artifact to a Maven Repository

Once these steps are done, The project is browsable in eclipse!

Some Helpful Git Commands for the commandline:

git init — Initialize your directory with git.

git add FILE and git checkout — FILE To stage/unstage a file

git commit— To save your changes. This commit will be local

git stash and git stash pop — Stashes are back

git reset HEAD –hard Revert all your local changes

git log— Access all the history in the repository

git rebase –You can squash all the commits! (one should be carefull with this one)

git branch –You can create local branches,But keep the history linear

Hope this workaround and the commands are useful to a new user.

New Active members!

In the coming few weeks you might be seeing lots of activity on the blog!

Credit to : Margi(margi_train) and Pershant(pershant_foodie)!

(Please give them a warm welcome!)

Look forward to their contributions on various technology topics!

Talking to mysql on Bitnami google-cloud Tomcat instance

The Java deployment world is plagued with infra issues! Things we need to take care of:

  • Apache
  • Tomcat
  • RDBMS
  • Firewall/Ports
  • Shell accesses
  • Security/Encryption/Keys
  • File System Storage
  • Indexes corrupting and the list goes on…

So after my failed attempt to understand/decipher CORS issues on the AWS platform, I fortunately stumbled on google-cloud! And it is one hell of a bouquet of services for us petty and dev-ops-complaining Java folks!

So churn out a bitnami tomcat instance and you get the feel of the aws thing. For over a month now my google cloud app was(still is) talking to the mysql instance on aws, before that starts to drain my mini wallet, time to configure a mysql instance on google-cloud. And here are the steps:

  1. Have access to the SSH into your google cloud instance working
  2. Create following script (/home/bitnami/mysql-init):
  3.  UPDATE mysql.user SET Password=PASSWORD('NEW_PASSWORD') WHERE User='root';
     FLUSH PRIVILEGES;
    
  4. sudo /opt/bitnami/ctlscript.sh stop mysql
    
  5. sudo /opt/bitnami/mysql/bin/mysqld_safe --defaults-file=/opt/bitnami/mysql/my.cnf --pid-file=/opt/bitnami/mysql/data/mysqld.pid --init-file=/home/bitnami/mysql-init 2> /dev/null &
    
  6. sudo /opt/bitnami/ctlscript.sh restart mysql
  7. Remove the script in step 2.

So it turns out to get mysql talking on your bitnami instance you only need to reset the password.

Further to enable remote access do this in

/opt/bitnami/mysql/my.cnf:

  •  #bind-address=127.0.0.1
    

Next to enable remote mysql access via workbench you need to enable firewall ports to allow connections for tcp 3306 for a specific ip on your google cloud instance.

And there you go, you have a lot powerful config, much like aws ready to be used, backed by google!!

 

 

android:

Gang! Welcome to the world of Mobility ~ here also we’ve something great called ‘JAVA’ so let’s get started with basics of Android platform for cell phones…….! So :P, First thing to be ask for ? What is Android ?

Android is a software stack for mobile devices….. that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.

FYI: We’ll have posts on Android SDK and ENV. setup later…!

And now what is the …..? Android Application Fundamentals :

Android applications are written in the Java programming language. The Android SDK tools compile the code—along with any data and resource files—into an Android package, an archive file with an .apk suffix. All the code in a single .apk file is considered to be one application and is the file that Android-powered devices use to install the application.

Once installed on a device, each Android application lives in its own security sandbox:

  • The Android operating system is a multi-user Linux system in which each application is a different user.
  • By default, the system assigns each application a unique Linux user ID (the ID is used only by the system and is unknown to the application). The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.
  • Each process has its own virtual machine (VM), so an application’s code runs in isolation from other applications.
  • By default, every application runs in its own Linux process. Android starts the process when any of the application’s components need to be executed, then shuts down the process when it’s no longer needed or when the system must recover memory for other applications.

IoC vs. DI

How do you exactly define IoC (Inversion of Control) vis a vis DI (Dependency Injection)?

Well, as my first attempt at defining IoC and DI, I made the following statement.

IoC is the concept and DI is the way of implementing that. Pretty neat, huh? But how do I go explaining this to anybody in greater depth?

Now, it seems I do have an answer, according to the book Spring In Action:

“IoC aims to offer a simpler mechanism for provisioning component dependencies (often referred to as an object’s collaborators) and managing these dependencies throughout their lifecycles.”

It further states that “IoC can be decomposed into two subtypes: Dependency Injection and Dependency Lookup.”

Now drilling down further, DL (Dependency Lookup) allows acquisition of a reference to a dependency, whereas in DI, the IoC container itself is injecting or providing those dependencies. One can draw an inference that the former scenario is allowing you to control how and when to acquire the dependency and in the second case the container is having the control over the dependency lifecycle.

So, the statement I made above is validated upto a certain extent.

Any further thoughts/comments on this would be certainly welcome.

Some Maven gyaan

Maven is a project management and comprehension tool and as such provides a way to help with managing:
• Builds
• Documentation
• Reporting
• Dependencies
• SCMs
• Releases
• Distribution
Buzzwords
1) POM (Project Object Model) – The POM is the basic unit of work in Maven. POM essentials:
• project This is the top-level element in all Maven pom.xml files.
• modelVersion This element indicates what version of the object model this POM is using. The version of the model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when the Maven developers deem it necessary to change the model. By default, the model version is set to 4.0.0.
• groupId This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plug-ins.
• artifactId This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form . (for example, myapp-1.0.jar).
• packaging This element indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). This not only means if the artifact produced is JAR, WAR, or EAR but can also indicate a specific lifecycle to use as part of the build process. The default value for the packaging element is JAR so you do not have to specify this for most projects.
• version This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development. We will discuss the use of snapshots and how they work further on in this guide.
• name This element indicates the display name used for the project. This is often used in Maven’s generated documentation.
• url This element indicates where the project’s site can be found. This is often used in Maven’s generated documentation.
• description This element provides a basic description of your project. This is often used in Maven’s generated documentation.
More information about POM files can be found in POM reference and POM Introduction.
2) Archetype – Archetype is a Maven project templating toolkit. It provides a standard way to enable creation of sample projects which can be used as a starting point.

• To create a maven project based on archetype, you need to give the following command:
mvn archetype:generate

• Following archetypes are provided by maven:

Archetype ArtifactIds Description
maven-archetype-archetype An archetype which contains a sample archetype.
maven-archetype-j2ee-simple An archetype which contains a simplifed sample J2EE application.
maven-archetype-mojo An archetype which contains a sample a sample Maven plugin.
maven-archetype-plugin An archetype which contains a sample Maven plugin.
maven-archetype-plugin-site An archetype which contains a sample Maven plugin site.
maven-archetype-portlet An archetype which contains a sample JSR-268 Portlet.
maven-archetype-quickstart An archetype which contains a sample Maven project.
maven-archetype-simple An archetype which contains a simple Maven project.
maven-archetype-site An archetype which contains a sample Maven site which demonstrates some of the supported document types like APT, XDoc, and FML and demonstrates how to i18n your site.
maven-archetype-site-simple An archetype which contains a sample Maven site.
maven-archetype-webapp An archetype which contains a sample Maven Webapp project.

• Archetypes are packaged up in a JAR and they consist of the archetype metadata which describes the contents of archetype and a set of velocity templates which make up the prototype project. Archetype contents are as follows:
a) an archetype descriptor (archetype.xml in directory: src/main/resources/META-INF/maven/). It lists all the files that will be contained in the archetype and categorizes them so they can be processed correctly by the archetype generation mechanism.
b) the prototype files that are copied by the archetype plugin (directory: src/main/resources/archetype-resources/)
c) the prototype pom (pom.xml in: src/main/resources/archetype-resources)
d) a pom for the archetype (pom.xml in the archetype’s root directory).
See guide for creating archetype descriptors here for more information.
3) Build Lifecycle & Build Phases – Maven is based on concept of build lifecycle. This allows one to have a clearly defined process for building and distributing a particular artifact.

• There are three build lifecycles- default, clean and site. Default lifecycle is for handling project deployment, clean handles project cleanup and site handles the creation of project’s site documentation.
• Each of these lifecycles is made up of build phases. The build phase represents a stage in the lifecycle. eg. the default lifecycle is made up of following phases:

a) validate – validate the project is correct and all necessary information is available
b) compile – compile the source code of the project
c) test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
d) package – take the compiled code and package it in its distributable format, such as a JAR.
e) integration-test – process and deploy the package if necessary into an environment where integration tests can be run
f) verify – run any checks to verify the package is valid and meets quality criteria
g) install – install the package into the local repository, for use as a dependency in other projects locally
h) deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
These phases (and other phases in clean and site phases) would be run sequentially. For example, if the following maven command is issued:
mvn compile
maven would do every build phase prior to compile before compile it (namely validate).
• A build phase is further made up of goals. Even though it may be responsible for a specific step in the build lifecycle, the manner in which it carries those responsibilities varies. This is achieved by declaring the goals bound to these build phases. A goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.

Overloading in C…..? ..Its possible…..

hi everyone..

since we started studying C language, we have been taught that method overloading is not possible in C..like everyone, even I believed that..
But yesterday I learnt that it is possible..by including a header file named STDARG.H.

This header file lets you create variadic functions.i.e. functions with variable arguments.
To perform method overloading, you just have to include this header file and declare a function which you intent to “overload” or provide variable inputs.

syntax:-
return type function-name( datatype1 arg1, datatype2 arg2,…);

Note:- the last 3 dots in the list(…), this is the one which tells the compiler that it would be taking variable arguments. It is mandatory to include these 3 dots(…) else your function would not accept variable inputs.

You can make a function which accepts same typed arguments or different.

The procedure to be followed is as follows:
1. you need to declare a variable “va_list” for iterating through the variable list.
2. then use macros like “va_start” – to start iterating through the variable list va_list.This macro takes two arguments. First the variable with type va_list and second is the name of the last argument given in the list. In the syntax given above , it would be arg2.
3. va_arg- to retrieve an argument from the list. In this macro you need to provide two arguments. First bariable of type va_list and second is the datatype of the next argument to be fetched.
4. finally, va_end macro- to find the end to the variable list.

Its really fun to work with this feature of C and perform a function which was said not to be possible in C.

This was just a jist about the header file and its macros.

Happy C Programming..!!!