D3.js 01 - Introduction

Hi guys, welcome to {FOSS}-4EVER. Today I'm going to start a new article series, it's about D3.js. What it is? & Why it is? here we go.

D3 stands for Data Driven Documents. It's a JavaScript library for data visualization purpose.

 http://d3js.org/ is their official website, you can find official documentation and examples here. D3 helps you to represent your data{even messy data} in a more attractive way. D3.js is using HTML, SVG and CSS to make your data visualization experience. 

Why we call it Data Driven Documents? What are the data? Who is driving here? What are the documents? Data is what we are providing to arrange in a more attractive way. D3 represents data visualizations by editing documents in it's own way, these documents are HTML documents. To represent the visualization D3 connects your data with documents, it's the driving part, D3 is the driver here.

How does D3 works? It loads data to your browser memory. And then it binds data to elements within the document, if needed it creates new elements. Then it transforms these elements by setting it's visual properties.

is D3 a powerful library? Yes it is. But there are several things D3 can do, and can't do. In brief D3 doesn't,

• Generate predefined visualizations. 
• Support very old browsers.
• Handle bitmap map tile. When geo mapping you have to go all-SVG and stick with D3.
• Hide your original data.  If your data can’t be shared, then don’t use D3.

D3 is not perfect if,

• You need a quick start.
• You don't have time to code it from the scratch.
• You need to support old browsers.
• You can't relay on recent technologies like SVG

Then there are several alternatives like Flot, gRaphael.

Before getting started with D3 you should have some basic idea about followings,

• How does the web works,
• HTML
• DOM
• CSS
• JavaScript
• SVG

This is an introduction about D3.js, in the next article I'll discuss about the Fundamentals of D3.js, if you have any ideas or doubts please comment here. See you soon. Bye.

Search Post

Label :

Software design patterns 01

Hi guys, welcome back. After several weeks today I'm going to write something about software design patterns. This is an introduction to software design patterns and also this is the first article of software design patterns article series. Let's move, 

{?} What are the design patterns?

Design patterns are well tested solutions to common problems in software development. 

Is it a package, module or a library? No, you can't download and install a design pattern. And also it's not a finished design that can be directly converted to the code. It's a guide line for how to solve a problem. Think of design patterns is an ultimate reuse in software development. Design patterns are,

• Built from years of software development experience
• Save time, minimize trial and error

If you learnt design patterns you are reusing experience not code. Change is a constant in software design. Say your manager is asking for add a new feature to the running system, or your client asking for a new feature or sometimes you may found a bug in the system. If your code is not flexible to change you may have to restructure it. In so many ways you can change your code. After that your system may powered with new features, or it may optimized or you may invented few bugs.

Lots of problems in software development are related to how flexible those systems are, Can we add a new feature easily? can we change the part of the system without breaking the entire system? can we adapt a new data exchange format in the system? Design patterns are invented to solve these kinds of problems in a effective way. Design patterns are not specific solutions for specific kinds of software.

If you are building a HR management system you may use some design pattern, when you are building a banking system you may use some other design pattern. Design patterns are providing general solutions for common problems in software development. The primary goal of any design pattern is help to structure your code in a flexible way.

Design patterns are originated by Christopher Alexander as an architectural concept in 1977-79. Then in 1987 Kent Beck and Wad Cunningham began experimenting by applying this idea to programming and presented their results to OOPSLA conference in that year. Design patterns gained popularity in Computer Science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 by the so-called "Gang of Four". 

There are 23 design patterns. We can divide them into three categories on their specifications as follows,

• Creational patterns
• Structural patterns
• Behavioral patterns 

Followings are the design patterns which are belong to above categories,

# Creational design patterns

- All about class instantiation.

• Abstract Factory
  - Creates an instance of several families of classes
• Builder
  - Separates object construction from its representation
• Factory Method
  - Creates an instance of several derived classes
• Object Pool
  - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
• Prototype
  - A fully initialized instance to be copied or cloned
• Singleton
  - A class of which only a single instance can exist

# Structural design patterns

- All about Class and Object composition.

• Adapter
  - Match interfaces of different classes
• Bridge
  - Separates an object’s interface from its implementation
• Composite
  - A tree structure of simple and composite objects
• Decorator
  - Add responsibilities to objects dynamically
• Facade
  - A single class that represents an entire subsystem
• Flyweight
  - A fine-grained instance used for efficient sharing
• Private Class Data
  - Restricts accessor/mutator access
• Proxy
  - An object representing another object

# Behavioral design patterns

- All about Class's objects communication.

• Chain of responsibility
  - A way of passing a request between a chain of objects
• Command
  - Encapsulate a command request as an object
• Interpreter
  - A way to include language elements in a program
• Iterator
  - Sequentially access the elements of a collection
• Mediator
  - Defines simplified communication between classes
• Memento
  - Capture and restore an object's internal state
• Null Object
  - Designed to act as a default value of an object
• Observer
  - A way of notifying change to a number of classes
• State
  - Alter an object's behavior when its state changes
• Strategy
  - Encapsulates an algorithm inside a class
• Template method
  - Defer the exact steps of an algorithm to a subclass
• Visitor
  - Defines a new operation to a class without change

Thanks for reading, if you have any ideas, doubts please comment below. In my next design pattern article I'll discuss about above three design pattern categories and more about abstract factory. Thanks, see you again, bye.

Search Post

Label :

Static bindings Vs Dynamic bindings in Java

Hi guys, how are you? hope you all are doing well. Today I would like to write something about Static binding Vs Dynamic bindings in Java. First of all what does mean by binding?

Connecting a method call to the method body is known as method binding...

So, there are two types of bindings,

• Dynamic bindings AKA Late bindings
• Static bindings AKA Early bindings

# Dynamic bindings {Late bindings}

When we call a method in java it'll resolve at run time or compile time. It depends on whether that our method is a virtual method  or a static method. If our method call is resolved at run time, it's a Dynamic binding. How does it happen? Let's take an example.

We know Java supports Polymorphism. So a reference variable of type Parent can hold an object of type Child which extends Parent. In above example, type of human is Human, but it holds object of type Boy. Now if you call a virtual method on this object, the compiler can't identify correct method. Because it can be the defined method in Human{Parent} or it can be the overridden method in Boy{Child}. So this call will resolve at run time. Because at run time actual object will be available. This is the behavior of Dynamic binding.

# Static bindings {Early bindings}

If our method call is resolved at compile time, it's a static binding. Basically all the private, final, static variables and methods will be resolved at compile time. Because they can't be overridden. So compiler can clearly understand who will be called using this reference variable. An example for static binding,


In this example, type of reference variable myDog is Dog and it holds object of Dog. Actually it's like it holds it self. There is no confusion for compiler. But eat method is not a  private, final or a static. But it's qualified to resolve at compile time. Because it's not overridden. This is the behavior of Dynamic binding.

This is my very first technical blog post. Hope this'll help you at least a little bit :) Like to hear from you. If you have any ideas, comments, doubts please comment here. See you soon. Bye Bye...

Search Post

Label :