<New Site! />

Hello ,just a short note.I have moved my initial blog from My Thoughts to a new name “Code Kulture”,which better represents what im about as a software developer.

Im moving the blog to facilitate further growth because a blog directly linked to my site was limiting me  in delivering content,as at times i received feedback which was not related to the post but personal,thats why the move from the initial url.

Expect more content and fun times from this new blog.

Until next time …keep coding

My Reading List For 2017

Reading list

That’s not me of course

Every year towards my birthday I review my previous year to check how far I’ve gone with respect to my goals and plans.
I also take time to create reading list for the year ahead.
Today i would share some of the books that i will be devouring in 2017.
The books that interest me usually have to do with computer science,leadership and of course my faith which is Christianity.
I will focus on computer science or programming.

Computer Science/Programming

Algorithms

Introduction to algorithms

1.Introduction to algorithms

This is my all time favourite book,when it comes to the study of algorithms and data structures.
I am a huge fan of algorithms and data structures,for any beginning programmer i will recommend this book anytime as it covers the basics of algorithms and which are very important in programming and distinguish between a good software developer and a great developer

2.Clean Code:A Handbook of Agile Software Craftsmanship

That’s another book i have read a couple of times.It keeps me grounded on how to construct software.
I am a huge fan of Robert C.Martin,i would pick up any book by him.

3.Clean Architecture: A Craftsman’s Guide to Software Structure and Design

Another book by Robert C.Martin,I’m sure it will be a great read.Its due to be released later during the year.

4.Soft Skills: The software developer’s life manual

Every developer needs soft skills,that is one area where most developers struggle.
Somnez covers that aspect of a developer in great detail.
I have been following John’s blog for some time now,so i trust that his book will be a good read.

5.Code Complete: A Practical Handbook of Software Construction

 

That’s my reading list for 2017,if you want me to share my whole list on other categories just leave comments in the comments section.
keep coding!!

Dependency Inversion Principle(DIP)

Dependency Inversion Principle(DIP)

What Is Dependency Inversion Principle(DIP)?

In object-oriented design, the dependency inversion principle(DIP) refers to a specific form of decoupling software modules.
Dependency Inversion Principle or DIP has two key points:
1.Abstractions should not depend upon details;
2.Details should depend upon abstractions.
The principle could be rephrased as use the same level of abstraction at a given level. Interfaces should depend on other interfaces. Don’t add concrete classes to method signatures of an interface. However, use interfaces in your class methods.

Simple Example Of Dependency Inversion Principle

Consider the case of the Button object and the Door object.
The Button object senses the external environment. On receiving the Poll message, the Button object determines whether a user has “pressed” it. It doesn’t matter what the sensing mechanism is.
It could be a button icon on a GUI, a physical button being pressed by a human finger, or even a motion detector in a home security system. The Button object detects that a user has either activated or deactivated it.
The Door object affects the external environment. On receiving a TurnOn message, the Door object opens the door. On receiving a Close message, it closes that door.
How can we design a system such that the Button object controls the Door object?  The Button object receives Poll messages, determines whether the button has been pressed, and then simply sends the Open or Close message to the Door.

Consider the C# code implied by this model (above). Note that the Button class depends directly on the Door class. This dependency implies that Button will be affected by changes to Door. Moreover, it will not be possible to reuse Button to control a Motor object. In this model, Button objects control Door objects and only Door objects.


 public class Button  
  {  
   private Door door;  
   public void Poll()  
   {  
    if (/*some condition*/)  
     door.Open();  
   }  
  }  
The above solution violates DIP.The abstractions have not been separated from the details.Without such a separation, the high-level policy automatically depends on the low-level modules, and the abstractions automatically depend on the details.

Finding the Underlying Abstraction

What is the high-level policy? It is the abstraction that underlies the application, the truths that do not vary when the details are changed. It is the system inside the systemit is the metaphor. In the
Button/Door example, the underlying abstraction is to detect an open/close gesture from a user and relay that gesture to a target object.
What mechanism is used to detect the user gesture? Irrelevant! What is the target object? Irrelevant!
These are details that do not impact the abstraction.
The model in above can be improved by inverting the dependency upon the Lamp object. In model below, we see that the Button now holds an association to something called a ButtonServer,which provides the interfaces that Button can use to turn something on or off. Door implements the ButtonServer interface.
Thus, Door is now doing the depending rather than being depended on.
The design above allows a Button to control any device that is willing to implement the ButtonServer interface. This gives us a great deal of flexibility. It also means that Button objects will be able to control objects that have not yet been invented.
However, this solution also puts a constraint on any object that needs to be controlled by a Button.
Such an object must implement the ButtonServer interface. This is unfortunate, because these objects may also want to be controlled by a Switch object or some kind of object other than a Button.
By inverting the direction of the dependency and making the Door do the depending instead of being depended on, we have made Door depend on a different detail: Button. Or have we?
Door certainly depends on ButtonServer, but ButtonServer does not depend on Button. Any kind of object that knows how to manipulate the ButtonServer interface will be able to control a Door .
Thus,the dependency is in name only. And we can fix that by changing the name of ButtonServer to something a bit more generic, such as SwitchableDevice. We can also ensure that Button and SwitchableDevice are kept in separate libraries, so that the use of SwitchableDevice does not imply the use of Button.
In this case, nobody owns the interface. We have the interesting situation whereby the interface can be used by lots of different clients, and implemented by lots of different servers. Thus, the interface needs to stand alone without belonging to either group. In C#, we would put it in a separate namespace and library.
Further Reading

1.Agile Software Development, Principles, Patterns, and Practices By Robert C.Martin

2. Head First Design Patterns by Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bert, Bates

3.Object Solutions: Managing the Object-Oriented Project by Grady Booch,

Interface Segregation Principle(ISP)

ISP Image

Interface Segregation Principle

The Interface Segregation Principle(ISP) deals with the disadvantages of “fat” interfaces.

The Interface Segregation Principle(ISP) states that no client code object should be forced to depend on methods it does not use. Basically, each code object should only implement what it needs, and not be required to implement anything else.

The ISP was first used and formulated by Robert C. Martin while consulting for Xerox.

I will tackle today’s principle using an example from MSDN

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
 
namespace SOLIDPrinciplesDemo 
{ 
    // Only common generic methods exists for all derived classes. 
    interface IDataProvider 
    { 
        int OpenConnection(); 
        int CloseConnection(); 
    } 
    // Implement methods specific to the respective derived classe 
    interface ISqlDataProvider : IDataProvider 
    { 
        int ExecuteSqlCommand(); 
    } 
    // Implement methods specific to the respective derived classe 
    interface IOracleDataProvider : IDataProvider 
    { 
        int ExecuteOracleCommand(); 
    } 
    // Client 1 
    // Should not force SqlDataProvider client to implement ExecuteOracleCommand, as it wont required that method to be implemented. 
    // So that we will derive ISqlDataProvider not IOracleDataProvider 
    class SqlDataClient : ISqlDataProvider 
    { 
        public int OpenConnection() 
        { 
            Console.WriteLine("\nSql Connection opened successfully"); 
            return 1; 
        } 
        public int CloseConnection() 
        { 
            Console.WriteLine("Sql Connection closed successfully"); 
            return 1; 
        } 
 
        // Implemeting ISqlDataProvider, we are not forcing the client to implement IOracleDataProvider 
        public int ExecuteSqlCommand() 
        { 
            Console.WriteLine("Sql Server specific Command Executed successfully"); 
            return 1; 
        } 
    } 
    // Client 2 
    // Should not force OracleDataProvider client to implement ExecuteSqlCommand, as it wont required that method to be implemented. 
    // So that we will derive IOracleDataProvider not ISqlDataProvider 
    class OracleDataClient : IOracleDataProvider 
    { 
        public int OpenConnection() 
        { 
            Console.WriteLine("\nOracle Connection opened successfully"); 
            return 1; 
        } 
        public int CloseConnection() 
        { 
            Console.WriteLine("Oracle Connection closed successfully"); 
            return 1; 
        } 
        // Implemeting IOracleDataProvider, we are not forcing the client to implement ISqlDataProvider 
        public int ExecuteOracleCommand() 
        { 
            Console.WriteLine("Oracle specific Command Executed successfully"); 
            return 1; 
        } 
    } 
    class InterfaceSegregationPrincipleDemo 
    { 
        public static void ISPDemo() 
        { 
            Console.WriteLine("\n\nInterface Inversion Principle Demo "); 
 
            // Each client will implement their respective methods no base class forces the other client to implement the methods which dont required. 
            // From the above implementation, we are not forcing Sql client to implemnt orcale logic or Oracle client to implement sql logic. 
 
            ISqlDataProvider SqlDataProviderObject = new SqlDataClient(); 
            SqlDataProviderObject.OpenConnection(); 
            SqlDataProviderObject.ExecuteSqlCommand(); 
            SqlDataProviderObject.CloseConnection(); 
 
            IOracleDataProvider OracleDataProviderObject = new OracleDataClient(); 
            OracleDataProviderObject.OpenConnection(); 
            OracleDataProviderObject.ExecuteOracleCommand(); 
            OracleDataProviderObject.CloseConnection(); 
        } 
    } 
}

Advantages of Using ISP:

  1. Better Understandability
  2. Better Maintainability
  3. High Cohesion
  4. Low Coupling

Limitations

ISP like any other principle should be used intelligently when necessary otherwise it will result in a code containing lots of interfaces containing one method. So the decision should be taken intelligently.

Additional Resources

1.Agile Software Development, Principles, Patterns, and Practices-Robert C.Martin

2.SOLID Principles of Object Oriented Design– Steve Smith(Pluralsight)

3.Principles Of OOD

That’s it folks for this week,hope you learnt something in today’s topic,Interface Segregation Principle(ISP), the “I” in the S.O.L.I.D acronym,i will be concluding our series in the next post covering the Dependency Inversion Principle.

Liskov Substitution Principle

If you’ve been following my blog,you’ll know that we have been covering the SOLID Principles,in my previous posts i covered The Single Responsibility Principle,the “S” in the SOLID Acronym,then we covered The Open Closed Principle,today  my focus will be on The Liskov Substitution Principle,the “L” in the SOLID Principles acronym.

What is LSP?

This principle is credited to Barbara Liskov,she wrote this principle in 1988 and she said:

“What is wanted here is something like the following substitution property: If for each object o1
of type S there is an object o2 of type T such that for all programs P defined in terms of T, the
behaviour of P is unchanged when o1 is substituted for o2 then S is a sub-type of T.”

In simple terms the above statement means:

“Subtypes must be substitutable for their base types.”

or more simply:

“It means that we must make sure that new derived classes are extending the base classes without changing their behaviour” 

A Simple Example Using C#

We’ll use the classic Rectangle-Square problem to demonstrate this principle. Let’s imagine that we need to find the area of any rectangle.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;


namespace SOLIDPrinciplesDemo
{
  // If any module is using a Base class then the reference to that Base class can be replaced with a Derived class without affecting the functionality of the module.
  // Or
  // While implementing derived classes, one needs to ensure that, derived classes just extend the functionality of base classes without replacing the functionality of base classes.

class Rectangle
{
 protected int mWidth = 0 ;
 protected int mHeight = 0;

public virtual void SetWidth(int width)
{
  mWidth = width;
}

public virtual void SetHeight(int height)
{
  mHeight = height;
}


public virtual int GetArea()
{
  return mWidth * mHeight;
}
}


  // While implementing derived class if one replaces the functionality of base class then,
  // it might result into undesired side effects when such derived classes are used in existing program modules.
class Square : Rectangle
{
  // This class modifies the base class functionality instead of extending the base class functionality
  // Now below methods implementation will impact base class functionality.
public override void SetWidth(int width)
{
  mWidth = width;
  mHeight = width;
}

public override void SetHeight(int height)
{
  mWidth = height;
  mHeight = height;
}

}


class LiskovSubstitutionPrincipleDemo
{

private static Rectangle CreateInstance()
{
  // As per Liskov Substitution Principle "Derived types must be completely substitutable for their base types".
  bool SomeCondition = false;

if (SomeCondition == true)
{
  return new Rectangle();
}
else
{
  return new Square();
}
}

public static void LSPDemo()
{
  Console.WriteLine("\n\nLiskov Substitution Principle Demo ");
  Rectangle RectangleObject = CreateInstance();

  // User assumes that RectangleObject is a rectangle and (s)he is able to set the width and height as for the base class
  RectangleObject.SetWidth(5);
  RectangleObject.SetHeight(10);
  // Now this results into the area 100 (10 * 10 ) instead of 50 (10 * 5).
  Console.WriteLine("Liskov Substitution Principle has been violated and returned wrong result : " + RectangleObject.GetArea());
  // So once again I repeat that sub classes should extend the functionality, sub classes functionality should not impact base class functionality.
}
}
}

I know the example above doesn’t exhaust the LSP principle,but im sure it gave you an idea what the principle stands for.

Benefits

This principle aims to keep functionality intact. The main purpose is to guarantee that objects lower in a relational hierarchy can be treated as though they are objects higher in the hierarchy. Basically, any child class should be able to do anything the parent can do.

Further Reading

1.Data Abstraction and Hierarchy,” Barbara Liskov, SIGPLAN Notices, 23(5) (May 1988)

2.Bertrand Meyer, Object-Oriented Software Construction, 2d. ed., Prentice Hall, 1997

3.Rebecca Wirfs-Brock et al. , Designing Object-Oriented Software, Prentice Hall,
1990.

4.Agile.Principles.Patterns.and Practices.In.C#[Robert.C.Martin]

That’s it for this week,next i will be covering Interface Segregation Principle(ISP),the letter “I” in the SOLID acronym.

****Happy Holidays and be safe****

The Open Closed Principle

Last week I covered the Single Responsibility Principe, which is part of the SOLID Principles, this week I will continue and cover the next principle  which is the Open/Closed Principle.

What is The Open Closed Principle?

Robert “Uncle Bob”  Martín, defines it like this:
The open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”; that is, such an entity can allow its behaviour to be extended without modifying its source code.

Simply stated, this means that we should not have to change our code every time a requirement or a rule changes. Our code should be extensible enough that we can write it once and not have to change it later just because we have new functionality or a change to a requirement.

Imagine what life would be like if every new feature or requirement resulted in changing the source code, that would mean that one has to  test the code again and again, that would be a tedious thing, lest to say boring.

*Code Example

Let me illustrate with a code example

Background

 We were working on a project where we were using Oracle as the prime repository until one fine day our technical lead came up and announced that our application should support SQL Server as another data source.

Now our Data access layer had a DBConnection class with a connect method strongly bound to accept Oracle provider and establish a connection.

I ignored the detailed implementation and tried to keep things simple.

Initial Code

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace SOLID
{
    class DBConnection
    {
        public void Connect(OracleProvider ora)
        {
            Console.WriteLine("Connected to oracle data source");
        }
    }

    class OracleProvider
    {
        string _providername;
    }
}

As we were in a hurry for the delivery, we could only come up with this design for the existing dbConnection class so that it now supports SQL provider too.

After Refactoring

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace SOLID
{
    class DBConnection
    {

        public void Connect(object o)
        {

            if (o is OracleProvider)
            {
                Console.WriteLine("Connected to oracle data source");
            }
            else if (o is SQlProvider)
            {
                Console.WriteLine("Connected to sql data source");
            }
        }
    }

    class OracleProvider
    {
        string _providername;
    }

    class SQlProvider
    {
        string _providername;
    }
}

OMG ! We designed something wrong …

Here if you can see from the above code, we are modifying the class DBConnection rather than extending it by including if else statements, this simply is against OCP.

Reason is simple if tomorrow another provider is introduced, again we have to make changes to the DBconnection class.

Ultimate refactoring …

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace SOLID
{
    interface IDBConnection
    {
        public void Connect();
    }

    class DBConnection
    {
        public void Connect(IDBConnection con)
        {
            con.Connect();
        }
    }

    class OracleProvider :IDBConnection
    {
        string _providername;

        public void Connect()
        {
            Console.WriteLine("Connected to oracle data source");
        }        
    }

    class SQlProvider:IDBConnection
    {
        string _providername;

        public void Connect()
        {
            Console.WriteLine("Connected to sql data source");
        }        
    }
}

Finally the main method ….

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace SOLID
{
    class Program
    {
        static void Main(string[] args)
        {
            //Sql connection 
            IDBConnection conSQl = new SQlProvider();
            conSQl.Connect();

            //oracle connection 
            //IDBConnection conOra = new SQlProvider();
            //conOra.Connect();
        }       
    }
}

The above design we could come up seems to adhere to OCP.
Now tomorrow if we have to support another Data source, we can easily do it by simply extending IDBConnection needless to make any changes to DBConnection.

So the entities are now open for extension and closed for modification.

That’s it for this week, will be looking at the the Liskov Substitution Principle next,which is the letter “L” in the SOLID Principles acronym.

*Code example adapted from an article in code project

Design Principles To Increase Your Productivity As A Developer

Today I will tackle a topic that new to intermediate software developers struggle with, that’s a concept of design principles,if you master the design principles it will greatly improve your productivity as a software developer.

I know in some large organisations I know there is a person responsible for implementing the design principles or enforce them or ensures that they are implemented during software development.

In the following weeks I will be covering a concept called the SOLID principles, covering one or two concept per week.

First let me define what solid principles are. SOLID is actually an acronym for

S-Single Responsibility Principle(SRP)

O-Open/Closed principle(OCP)

L-Liskov Substitution Principle(LSP)

I-Interface Segregation Principle(ISP)

D-Dependency Inversion Principle(DIP)

5 TOOLS AND TECHNOLOGIES EVERY DEVELOPER SHOULD MASTER

THE SINGLE RESPONSIBLE PRINCIPLE

singleresponsibilityprinciple

Single responsible principle

Robert “Uncle Bob” Martin in his book: Agile Principles Patterns and Principles in C# states:

“A class should have only one reason to change “

Like life if you focus on so many things you will fail, in the same way If a class has more than one responsibility, the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’s ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

Like in the image above,the pocket knife is a super knife it can do almost everything,but in the process of adding all the components that make it a super knife it has lost its real purpose that is being a pocket knife.

In the same way you can overload a class with a lot of functionality to a point that it loses its identity

Let me illustrate with a C# code example

The following C# example shows a class named “RectangleShape” that implements two methods, one that calculates its rectangle area and one that draws the rectangle. When the area calculation changes for some reason or the drawing method has to change, for example, another fill color is used, then the whole class is under change. Also if the properties are altered, it influences both methods. After a code change, the class must be tested as a whole again. There is clearly more than one reason to change this class.

Problem

/// <summary>
/// Class calculates the area and can also draw it on a windows form object.
/// </summary>

    public class RectangleShape
    {
        public int Height{ get; set; }
        public int Width { get; set; }
 
        public int Area()
        {
            return Width * Height;
        }
 
        public void Draw(Form form)
        {
            SolidBrush myBrush = new SolidBrush(System.Drawing.Color.Red);
            Graphics formGraphics = form.CreateGraphics();
            formGraphics.FillRectangle(myBrush, new Rectangle(0, 0, Width, Height);
        }
    }

Typically, the above class is used by consuming client classes like these:

/// <summary>
/// Consumes the RectangleShape */
/// </summary>
    public class GeometricsCalculator
    {
        public void CalculateArea(RectangleShape rectangleShape)
        {
            int area = rectangleShape.Area();
        }
    }   


/// <summary>
//// Consumes the RectangleShape */
/// </summary>
    public class GraphicsManager
    {
        public Form form {get;set;}

        public void DrawOnScreen(RectangleShape rectangleShape)
        {
            rectangleShape.Draw(form);
        }
    }

Solution

The next classes show how to separate the different responsibilities. Basic coding is used not taking other SOLID principles into account. It only just shows how to deal with the SRP principle. The RectangleDraw class consumes now a RectangleShape instance and a Form object.

/// <summary>
/// Class calculates the rectangle's area.
/// </summary>
    public class RectangleShape
    {
        public int Height { get; set; }
        public int Width { get; set; }

        public int Area()
        {
            return Width * Height;
        }
    }

/// <summary>
/// Class draws a rectangle on a windows form object.
/// </summary>
    public class RectangleDraw
    {
        public void Draw(Form form, RectangleShape rectangleShape)
        {
            SolidBrush myBrush = new SolidBrush(System.Drawing.Color.Red);
            Graphics formGraphics = form.CreateGraphics();
            formGraphics.FillRectangle(myBrush, 
            new Rectangle(0, 0, rectangleShape.Width,rectangleShape.Height));
        }
    }

The following code shows how to consume both classes:

/// <summary>
/// Consumes the RectangleShape */
/// </summary>
    public class GeometricsCalculator
    {
        public void CalculateArea(RectangleShape rectangleShape)
        {
            int area = rectangleShape.Area();
        }
    }

/// <summary>
/// Consumes the RectangleDraw and RectangleShape */
/// </summary>
    public class GraphicsManager
    {
        public Form form { get; set; }
        
        public void DrawOnScreen(RectangleDraw rectangleDraw, RectangleShape rectangleShape)
        {
            rectangleDraw.Draw(form, rectangleShape);
        }
    }

Before i wrap up for today let me point out the advantages:

Major benefits of this pattern are

  • Code complexity is reduced by being more explicit and straightforward

  • Loose coupling

  • Improved readability

 

5 Tools And Technologies Every Developer Should Master

browser-maintenance-512

I believe that in any trade or culture,field or an endeavor,to be called a master or guru you should have mastered certain skills or practices.

The same goes for software development to be called a great developer you  should have mastered certain skillsets that enable you to be more productive and add value to your organization or team.

Today i will touch on a few of the things that i feel are very important to know or master as a software developer.

This post is aimed at specially new developers who feel overwhelmed with the amount of things they have to tackle or learn to be productive or effective as a software developer.

Today i will tackle five things i feel are very important to master as a software developer.

data-structures

1.Data Structures

Google defines a data structure as a specialised format for organising and storing data.

In layman’s terms, a data structure is simply a data container.

Examples of data structures include arrays,linked lists,dictionary,record or struct,a class…etc

I think every developer should have extensive knowledge of data structures because data structures impact the performance of an application.

This is one area where most self-taught programmers fall short,but that’s one area big companies like Microsoft and Google put emphasis on when interviewing with them.

Here are few advantages of data structures:

1.Allows easier processing of data.

2.Are necessary for design of efficient algorithms.

3.Provide means for management of large dataset such as databases or internet indexing services.

algorithms

2.Algorithms

Algorithms are usually covered together with the data structures,personally i think that way of mixing the two downplays the importance of algorithms.

An algorithm  is a self-contained step-by-step set of operations to be performed. Algorithms perform calculation, data processing, and/or automated reasoning tasks.

In simpler terms an algorithm is a recipe one follows to solve a computational problem.

Just like data structures algorithms impact the performance of an application.

I won’t dwell much on this as it is a broad topic,if  you need more information check out sites like cousera.org or Khan academy and also Pluralsight they have great resources on algorithms

git

3.Source Control

Git is “the” thing nowadays,every developer talks about it.

It is one of the many source control technologies out there,so as a developer there is no running away from it,you have to master it one way or another.

So what is  source control software?

It is A component of software configuration management, version control, also known as revision control or source control, is the management of changes to documents, computer programs, large web sites.

Examples of source control software include Git,Mercurial,Bazaar,Monotone and others.

Advantages of using version control include:

1.Automatic backups: If you accidentally delete some file (or part of a file) you can undelete it. If you change something and want to undo      it, the VCS can do so.

2.Sharing on multiple computers: VCSes are designed to help multiple people collaboratively edit text files. This makes sharing between    multiple computers (say your desktop and laptop) particularly easy. You do not need to bother if you always copied the newest version;  the VCS will do that for you. Even if you are offline and change files on both computers, the VCS will merge the changes intelligently once  you are online.

3.Version control and branching: Say you published some class notes as a pdf and want to fix some typos in them while simultaneously    working on the notes for next year. No problem. And you only need to fix the typos once, the VCS will merge them to the other versions.

ide

4.Integrated Development Environment(IDE)/Code Editor

I believe a serious developer has to learn and master at least one IDE to improve his productivity.

What is an IDE?

An integrated development environment (IDE) is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of a source code editor, build automation tools and a debugger.

The reasons i recommend learning an IDE are:

1. Less time and effort: The entire purpose of an IDE is to make developing faster and
easier. Its tools and features are supposed to help you organize resources, prevent
mistakes, and provide shortcuts.

2. Enforce project or company standards: Simply by working in the same
development environment, a group of programmers will adhere to a standard way of
doing things. Standards can be further enforced if the IDE offers predefined
templates, or if code libraries are shared between different team members/teams
working on the same project.

3. Project management: This can be twofold. First, many IDEs have documentation
tools that either automate the entry of developer comments, or may actually force
developers to write comments in different areas. Second, simply by having a visual
presentation of resources, it should be a lot easier to know how an application is laid
out as opposed to traversing the file system for arcane files in the file system.

framework

5.A Framework

A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions.

In simple terms a framework is acts as the skeletal support to build an application.

Every developer has to master a framework which is directly related to his line of work.I encourage developers to master a framework for the following reasons:

  1. The biggest advantage of the software framework is that it reduces the time and energy in developing any software.

  2. Frameworks provides a standard working system through which user can develop the desired module of application or complete application instead of developing lower level details.

  3. Using frameworks, the developers can devote more time in developing the software requirement, not in preparing the environment and tools of application development.

  4. Framework follow design pattern, so when you use these frameworks you’ve to follow their coding convention which makes your code clean and extensible for future purpose.

  5. Framework separates business logic from user interface making the code cleaner and extensible.

  6. Frameworks help you to develop the project rapidly, if you know one framework well then you’ll never worry about the project deadline.

That’s it for this week folks,i know the list could be extended but tried to make it short as it was going to be a long post but please feel free to add to my list.

and don’t forget to leave your comments below.

Thami signing out!!!

 

Welcome

The is my first post on my blog which will profile some of the things that i experience everyday as a software developer.

I will share my knowledge with other developers on topics that i feel are very important to master as developers especially new developers.

I hope some seasoned developers will help me in my efforts to develop the developer community in a very small way i’m capable.

Thank you will see you next week!