The Composite Design Pattern In Fortran

The Composite design pattern is a structural design pattern which is used to group the objects of same type together and create hierarchies of objects. As an example consider a factory where "Manager" is an "Employee" but also has subordinates which are "List<Employee>" and in this way a tree structure for a group of "Employee" is created.

As an example following is an implementation in Fortran:

Github - Fortran implementation of Composite pattern

Fork

Bridge Design Pattern in Fortran

Bridge pattern is used to separate an implementation from its abstraction so that both may vary without any dependancy upon other. Due to this decoupling, the bridge pattern is classified as a structural pattern. All that is needed is to create an interface to act as a bridge to make the functionality of concrete classes independent of interface implementer.

Following is an example in Fortran:

GitHub - Bridge Pattern

Fork

Adapter Pattern Implementation in Fortran

Sometimes the classes that need to work together do not have compatible interfaces. In that case, to make the two classes talk to each other, Adapter pattern is implemented. This pattern is a structural pattern as it combines the capabilities of two different interfaces. Think of it as a dvd player which acts as an adapter between the dvd and the television.

Following is an implementation in Fortran.

Github - Adapter Pattern

Fork

Prototype Design Pattern Implementation in Fortran

Although the modern systems have lots of computing power, there are some operations which still become a bottleneck. Disk I/O and database access being few of them. Prototype design pattern is a creational pattern which is used to duplicate/clone objects keeping performance in mind. For example, a system where disk I/O is expensive can reference the same pointer when creating different objects of the same class.

Following is an implementation of the pattern using Fortran:

Github - Prototype Pattern

Fork

Builder Pattern Implementation in Fortran

Builder pattern is one of the most widely used and useful design pattern. The idea is to separate creation logic from the class so as to provide better encapsulation and make an object immutable for the client. This is a creational pattern because it facilitates the object creation logic.

Following is an implementation of builder in Fortran:

GitHub - Builder Pattern

Fork

Singleton Pattern Implementation in Fortran

In software systems, there is usually a need for class with just one instance. This need arises when there are resources that are globally shared. Singleton design pattern is a creational design pattern facilitating the creation of one and only one instance of a class. It is one of the simplest design patterns yet it is the most famous and as some may claim, most useful.

Following link has an implementation of Singleton pattern using Fortran programming language.

GitHub - Single Pattern using Fortran

Fork

Abstract Factory Design Pattern Implementation Using Fortran

An abstract factory is the factory of factories. It is a class which acts as a kind of super-factory.  The abstract factory can return factories of objects without specifying specific classes. Each factory object can produce objects using the factory pattern.

Following is an implementation of abstract factory pattern using Fortran.

GitHub - Abstract Factory using Fortran

Fork

Design Patterns & Fortran

The advent of Object Oriented Programming (OOP) has brought with it the positives of inheritance, composition, aggregation and reusability. Modern languages like C++, Java and C# have built upon these principles and have made their mark in the community. With the adaptation of OOP, the community has agreed upon some best practices which are classified as Design Patterns.

Fortran 2003 has introduced the constructs which have brought some of the best features of OOP in the language. However, the large code base used by the scientific community is still clustered with Structured Programming. The code is cluttered with variables and methods which make it hard to read and maintain.

FortranPatterns is an open source project aimed at implementing the established Design Patterns using the Fortran 2003 constructs with the aim of introducing to the scientific community the best practices.

GitHub - FortranPatterns

Fork

Factory Design Pattern Implemention Using Fortran

Fortran 2003 opened a new dimension of Object Oriented Programming (OOP) in the world of Fortran. Used widely by scientific community, the usage of Fortran is still limited to the Structured Programming approach. The resulting code is long list of jumbled up uncommented methods and variables which make it very difficult to read. Adapting OOP best practices can change this.

OOP provides better encapsulation, abstraction, composition and reusability for the code. Design Patterns go one step further. These are best practices adapted by the community for solving certain kind of problems. Depending on the task, these patterns can be behavioural, structural or creational. Factory pattern is classified as creational pattern.

Factory pattern provides one of the best ways to create objects which comply with the same interface. In this pattern, the creational logic is not exposed to the client. Rather a singular interface is provided and the client gets the object using this interface by specifying the kind of object it is demanding.

Following is an implementation of Factory pattern in Fortran.

https://github.com/FactoryPattern
Fork

Reuse & enjoy!

Google Drive's Delete Confirmation Dialog

So the real annoyance I am facing is the Google Drive's delete confirmation dialog that keeps on popping up.

So to make it disappear, try the following if you are on Mac:

Remove the item from the login items:

Then go to terminal and type the following to start the application:

/Applications/Google\ Drive.app/Contents/MacOS/Google\ Drive --noshow_confirmation_dialog_on_delete

Viola!

On Windoes go to terminal (cmd.exe) and type the following and press Enter:

C:\Program Files (x86)\Google\Drive\googledrivesync.exe" --noshow_confirmation_dialog_on_delete

Generate an Android project using the amazing Maven Archetypes

So I can't seem to get over the convenience of using Maven Archetype for generating Android project. Does all the work for ya!

mvn archetype:generate \
  -DarchetypeArtifactId=android-quickstart \
  -DarchetypeGroupId=de.akquinet.android.archetypes \
  -DarchetypeVersion=1.0.10 \
  -DgroupId=your.company \
  -DartifactId=my-android-application

For more details and a thorough introduction to the concept of Archetypes:
http://maven.apache.org/guides/introduction/introduction-to-archetypes.html

P.S. Remember, android-maven-plugin version 3.6.0 is your friend! So edit the pom.xml generated and change the version to 3.6.0 (or higher).

Use homebrew to install maven 3.0.5 on OS X

Quite frankly, I have found working with maven 3.1.1 a pain in the a**. This is because of various compatibility issues with preexisting projects. So here is a simple way to install maven 3.0.5:

brew install maven30

For those of you who will still go with 3.1.1:

brew install maven

Enjoy!

Trace Metals in Atmosphere

Trace metals enter the atmosphere through different anthropogenic and natural sources. Some of the emission sources are gasoline, combustion, non-ferrous metal production. Once in the atmosphere, the trace metals do not remain confined to the local region but are carried to other regions and impact on a global level. The enrichment of trace metals has been noted as far as Arctic. This has impacted ecology, economy and quality of life. E.g. the increase in levels of Cd (Cadmium) and Pb (Lead) are known to cause spontaneous abortion in women in the first 3 months of pregnancy.

A global emission inventory can help in modelling the role of trace metals in riverine and atmospheric ecosystem. The changing emission factors, e.g. the use of low leaded gasoline, are indicative of the need for revision of such inventories on a regular bases. Lack of data makes it hard to come up with accurate emission inventories and hence a lot of assumptions are made which introduce uncertainty. Although every industry discharges at least one trace metal to the environment, yet this data is not recorded and hence, a lot of averages need to be estimated in order to create an inventory for use with simulations.

For industrial input, the first study which quantifies the emission of 16 different trace metals in air, soil and water on a global scale was conducted in 1980s and published in 1988. There have been just a few updates to this data and those were done in 1995 and 1996 for the data collected at the beginning of 1990s. There have been several studies done on a local scale on a limited set of trace metals.

Ref: "An assessment of global and regional emissions of trace metals to the atmosphere from anthropogenic sources worldwide" by Pacyna & Pacyna.