Find the Wi-Fi Password of your Current Network

Type “cmd” in the Run box, right-click the command prompt icon and choose Run as Administrator


netsh wlan show profile

Now enter the following command and hit enter to see the WiFi password

netsh wlan show profile name=network_name key=clear

WiFi Password on Windows

WiFi Password on Windows


Check Key Content in Sercurity Setting part, you will have the Password.

Starting new project in Java- Coding guidelines.

UI and ApplicationLayer packages contains mainly concrete classes

UI and ApplicationLayer packages contains mainly concrete classes


  • All software to be written needs to be modular. The basic and most important principle to be followed is Separation of concerns. Read the article thoroughly should you not already be profoundly familiar with it.
  • Also follow following principles:
  • Avoid writing spaghetti code at all costs.
  • Consider the  if  statement your enemy. The more  if  statements are scattered around your code, the more difficult it will become to read, understand, maintain and extend, both for you and for other developers. Trying to solve difficult problems with dozens and dozens of nested if statements is brute force
  • Whenever a parameter needs to be checked for null, it should be done right at the beginning of the method as follows.
    …and this is what you should never do:
    if (<parameter> != null) {
    // do something here;
  • Mark all unfinished or problematic locations in your code with a  TODO  tag.
  • String literals and numbers shall always be defined as constants.
  • Use enums if what you need is a set of constants instead of just a single one
  • Type your fields, parameters and local variables as abstract as you can make use of the Java 7 diamond operator:
    List<String> = new ArrayList<>();
    … and not like this:
    ArrayList<String> lastNames = new ArrayList<String>();
  • Use the  final  keyword for arguments, member and local variables wherever applic

Static and Singletons

  • Do not write  static  methods as they are non-overridable and non-injectable. Also they usually make testing very difficult or even impossible.
  • In applications without a dependency injection framework (such as Spring) one notable exception of the above rule is the static  getInstance()  method in singleton Abstract Factories.
  • Use singletons (such as singleton Abstract Factories) as seldom and as carefully as possible as they introduce a global state to the application and hidden dependencies to the modules that use them.
  • Never use static-style abstract factories in container managed applications (such as Spring).

Exception Handling


Unit Testing

  • The scope of unit tests is always a single class (maybe along with its interface(s)) and its methods.  Do not go beyond: don’t test clusters of classes at once.  Unit testing always requires isolation of the test subject.  That said, do NOT mistake unit testing for E2E testing.
  • Perform isolation by mocking collaborators that are not the subject of your test using Mockito or any comparable framework in your team/project.
  • While creating a bugfix use TDD to provide regression tests:
    • write unit-test first to reproduce the bug
    • fix the bug: make the test work without modifying the test but modifying the code that causes the bug.
  • Before starting a refactoring: write tests first so as to ensure to keep current functionality.
  • Always run JUnit tests locally  before  committing/pushing.  (Do not rely on Jenkins server running the tests.)
  • It is highly recommended to use EclEmma (an Eclipse plugin) to check the current test-coverage of the code you wrote or modified.
    • do not  solely rely on the  line coverage  but also keep the  branch coverage  in mind .
    • As Uncle Bob says: “Leave the campground cleaner than the way you found it.”. This also applies to the test-coverage of our code.
  • Write tests using JUnit 4 and its features. Annotate with  @Test @Before @BeforeClass @After  and  @AfterClass  appropriately. Create one test method per use case.
  • Each unit test needs to have at least one assertion-statement.
  • If you need database interaction, set up an in-memory database using HSQLDB or H2. You should, however, usually isolate the code to be tested in a fashion that you don’t need to access any database, except while testing DAO-classes.
  • Make your tests repeatable. Make sure they don’t interfere with each other and they can be run in any order possible.
  • Use white-box tests as a primary approach.
  • It is recommended to write additional black-box tests.
  • As an absolute minimum all public methods (except getters and setters) have to be unit-tested.

Git policy

  • Try to commit as few files together as possible. If many files are clogged together in one commit step, the message will have to describe all changes. This, however is detrimental if later someone is looking into the revision repository history of just one of these files, because it will be difficult to understand which part of the common commit message is meant to describe the changes for that single file.
  • Push early, push often. If your laptop suddenly catches fire still no source code would be lost. Even more importantly, you’re developing under a constant feedback from test and build results coming from Jenkins so that errors can be detected at an early stage. It will also be much easier for you to commit classes related to specific tickets. Make commits atomic so they can be reverted at a later point should there be need to.
  • A new branch is to be created when it makes sense. It usually doesn’t when a single line of code in a single file will be modified and it most probably does if the changes affect dozens and dozens of files and the development takes long. Consult your team if in doubt.
  • Features that take longer than a sprint (take)  shall  always  be   kept  in  feature   branches   until   development   is   finished .
  • Follow the Branching Model aligned with LeanDI.
  • All code written in the scope of any project, be it even as little as an auxiliary tool or utility, absolutely has to be pushed into a central repository for versioning and publishing.  No such non-versioned/unpublished code may stay on any developer computer.

Remember 90% Of Everything You Learn


Learning Pyramid

Learning Pyramid

Books, classroom lectures, videos — non-interactive learning methods that results in 80-95% of information going in one ear and leaking out the other.

The point here is that instead of forcing our brains on how to remember more information with “passive” methods, we should focus our time, energy, and resources on “participatory” methods that have proven to deliver more effective results, in less time.

This means that:

  • If you want to learn how to speak a foreign language, you should focus on speaking with native speakers and gain immediate feedback (instead of mobile apps)
  • If you want to get in shape, you should work with a personal fitness trainer (instead of watching Youtube workout videos)
  • If you want to learn a new instrument, hire a local music teacher in your city


UML introduction

UML is a graphical notation specifically for drawing diagrams of an object-oriented system. A UML describes over a dozen different diagrams, but we’re only interested in a few of the most common, such as the classic class diagram.



Class Diagram

Class Diagram

When drawing diagrams, it’s common to see signs before the attributes or methods, most

– Minus signs in front of the attributes here. This is referred to as controlling visibility, and Minus means these should be private to the class, not directly accessible from other objects.

+ For example getName operation which will be public and marked with a Plus sign.



Identifying inheritance


Inheritates Abstract Class

Inheritates AbstractClass

easiest way of identifying an inheritance situation is with two words, “Is A”. Inheritance describes an “Is A” relationship.


Using aggregation and composition

Aggregation Composition

Aggregation Composition

it’s the unfilled diamond. So, for example, we might have a classroom object that will contain an array of student objects that might be important to diagram that relationship.

Document has a Page or has many pages. But if I were to delete the Document object all the associated Page objects should be deleted too. I would not expect then those page objects to be shared with any other part of the application. On the other hand in a plain aggregation situation as with the Classroom and Student relationship, if I deleted the Classroom object, perhaps the class got canceled, I would not expect all the Student objects to be destroyed, they may be used in different classrooms or just be able to live on their own.

And that’s the difference, Composition implies ownership, Aggregation does not. Now Aggregation is not usually worth showing on a diagram, but Composition often can be. If the lifetime of an object is dependent on another object existing that can be worth showing, even if we are just prompting the idea that when you’re defining the owning class, say here the Document class, you may need to write aconstructor and a destructor that would take care of creating and/or deleting the internal objects.


Using interfaces



Sequence Diagrams

Sequence Diagrams

Class Diagram

Class Diagram


Khi một class có sử dụng một instance của class B như một tham số đầu vào của method trong class A.

public class A {

    public void doSomething(B b) {}

Nhưng giả sử class A có một member với kiểu dữ liệu là class B thì lúc đó ta có mối quan hệ



public class A {

    private B _b;

    public void setB(B b) { _b = b; }

Với ví dụ trên ta có thể thấy mối quan hệ giữa A và B chỉ là Aggreation có nghĩa là nếu như A bị hủy thì chưa chắc B đã được hủy. Do vậy nếu như instance của B được khởi tạo trong A như ví dụ dưới đây ta có mối quan hệ là



public class A {

    private B _b = new B();


public class A {

    private B _b;

    public A() {
        _b = new B();
    } // default constructor

Còn mối quan hệ như Inheritance hay Realization thì sao? Đúng như tên gọi của nó, nếu class B kế thừa từ class A ta có mối quan hệ



public class A {


} // class A

public class B extends A {


} // class B

Mặt khác nếu class B implement từ A thì ta có mối quan hệ (Ví dụ ta hay thấy đó là implement một interface)



public interface A {


} // interface A

public class B implements A {


} // class B

OOP: The Specification Pattern


In this article, we are going to explore the classic specification pattern and implement it in order to compose the LINQ queries, and also non-LINQ queries. This article will also help beginners in understanding the specification pattern and how to implement it in practice. Major benefits of the specification patterns include reusability, maintainability, loose coupling of business rules from the business objects, readability and easy testing.

Specification Pattern

Specification pattern as per the definition from Wikipedia, is a particular software design pattern, wherebybusiness rules can be recombined by chaining the business rules together using boolean logic. To put it simply, business rules are segregated based on the Single responsibility principle (SRP) and chained or composed using boolean operands (AND, OR or NOT) to achieve the desired result. Each segregated business rule is called Specification.

Each specification inherits the abstract CompositeSpecification class which defines one abstractmethod called IsSatisfiedBy. This method is the engine of specification pattern. The responsibility of this method is to apply the business rule (specification) on the object in question and return a boolean result. The primary goal of the specification pattern is to select the subset of objects that satisfy a set of specifications chained together.


More infor:




Using SALV (object oriented model) has many advantages:

  • Simplified design: This Model uses a highly integrated object oriented design which provides the simplicity to programmers to develop the ALV.
  • Unified Object models: This model has only one main class which will get and set the parameters of entire layout.

All Classes has static method FACTORY which will get back the instance of the ALV. Like for the simple table dispaly we must call the method CL_SALV_TABLE=>FACTORY to get the instance of the ALV.

SALV class

SALV class


Simple case to display table:

DATA lo_salv TYPE REF TO cl_salv_table.
r_salv_table = lo_salv
t_table = lt_sflight ).
CATCH cx_salv_msg INTO lx_msg.

lo_salv->display( ).

Add standard PF Status

DATA: lo_functions TYPE REF TO cl_salv_functions_list.
lo_functions = co_salv->get_functions( ).
lo_functions->set_default( abap_true ).


Table vs View vs Materialized View

A table is where data is stored. You always start with tables first, and then your usage pattern dictates whether you need views or materialized views.

A view is like a stored query for future use, if you’re frequently joining or filtering the same tables the same way in multiple places.

A materialized view is like a combination of both: it’s a table that is automatically populated and refreshed via a view. You’d use this if you were using views, and want to pre-join or pre-aggregate the rows to speed up queries.

materialized view

Figure below shows an example of using the Materialized View pattern. Data in the Order, OrderItem, and Customer tables in separate partitions in a Microsoft Azure storage account are combined to generate a view containing the total sales value for each product in the Electronics category, together with a count of the number of customers who made purchases of each item.

materialized view2

Materialised View:Materialized views are schema objects that can be used to summarize, precompute, replicate, and distribute data.It  provides indirect access to table data by storing the results of a query in a separate schema object. Unlike an ordinary view, which does not take up any storage space or contain any data.

Senario:While creating a dataware house we need to go for staging part at that time this is useful.


We have 2 types

1)Read only


An updatable view lets you insert, update, and delete rows in the view and propagate the changes to the target master table.


In order to be updatable, a view cannot contain any of the following constructs:

SET or DISTINCT operators, an aggregate or analytic function, a GROUP BY, ORDER BY, CONNECT BY, or START WITH clause, a subquery (or collection expression) in a SELECT list

or finally (with some exceptions) a JOIN


Views that are not updatable can be modified using an INSTEAD OF trigger.





Visitor pattern

Visitor Design Pattern


  • Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
  • The classic technique for recovering lost type information.
  • Do the right thing based on the type of two objects.
  • Double dispatch


Many distinct and unrelated operations need to be performed on node objects in a heterogeneous aggregate structure. You want to avoid “polluting” the node classes with these operations. And, you don’t want to have to query the type of each node and cast the pointer to the correct type before performing the desired operation.


Visitor’s primary purpose is to abstract functionality that can be applied to an aggregate hierarchy of “element” objects. The approach encourages designing lightweight Element classes – because processing functionality is removed from their list of responsibilities. New functionality can easily be added to the original inheritance hierarchy by creating a new Visitor subclass.

Visitor implements “double dispatch”. OO messages routinely manifest “single dispatch” – the operation that is executed depends on: the name of the request, and the type of the receiver. In “double dispatch”, the operation executed depends on: the name of the request, and the type of TWO receivers (the type of the Visitor and the type of the element it visits).

The implementation proceeds as follows. Create a Visitor class hierarchy that defines a pure virtualvisit() method in the abstract base class for each concrete derived class in the aggregate node hierarchy. Each visit() method accepts a single argument – a pointer or reference to an original Element derived class.

Each operation to be supported is modelled with a concrete derived class of the Visitor hierarchy. Thevisit() methods declared in the Visitor base class are now defined in each derived subclass by allocating the “type query and cast” code in the original implementation to the appropriate overloadedvisit() method.

Add a single pure virtual accept() method to the base class of the Element hierarchy. accept() is defined to receive a single argument – a pointer or reference to the abstract base class of the Visitor hierarchy.

Each concrete derived class of the Element hierarchy implements the accept() method by simply calling the visit() method on the concrete derived instance of the Visitor hierarchy that it was passed, passing its “this” pointer as the sole argument.

Everything for “elements” and “visitors” is now set-up. When the client needs an operation to be performed, (s)he creates an instance of the Vistor object, calls the accept() method on each Element object, and passes the Visitor object.

The accept() method causes flow of control to find the correct Element subclass. Then when thevisit() method is invoked, flow of control is vectored to the correct Visitor subclass. accept()dispatch plus visit() dispatch equals double dispatch.

The Visitor pattern makes adding new operations (or utilities) easy – simply add a new Visitor derived class. But, if the subclasses in the aggregate node hierarchy are not stable, keeping the Visitor subclasses in sync requires a prohibitive amount of effort.

An acknowledged objection to the Visitor pattern is that is represents a regression to functional decomposition – separate the algorithms from the data structures. While this is a legitimate interpretation, perhaps a better perspective/rationale is the goal of promoting non-traditional behavior to full object status.


The Element hierarchy is instrumented with a “universal method adapter”. The implementation ofaccept() in each Element derived class is always the same. But – it cannot be moved to the Element base class and inherited by all derived classes because a reference to this in the Element class always maps to the base type Element.

Visitor scheme

When the polymorphic firstDispatch() method is called on an abstract First object, the concrete type of that object is “recovered”. When the polymorphic secondDispatch() method is called on an abstract Second object, its concrete type is “recovered”. The application functionality appropriate for this pair of types can now be exercised.

Visitor scheme


The Visitor pattern represents an operation to be performed on the elements of an object structure without changing the classes on which it operates. This pattern can be observed in the operation of a taxi company. When a person calls a taxi company (accepting a visitor), the company dispatches a cab to the customer. Upon entering the taxi the customer, or Visitor, is no longer in control of his or her own transportation, the taxi (driver) is.

Visitor example

Check list

  1. Confirm that the current hierarchy (known as the Element hierarchy) will be fairly stable and that the public interface of these classes is sufficient for the access the Visitor classes will require. If these conditions are not met, then the Visitor pattern is not a good match.
  2. Create a Visitor base class with a visit(ElementXxx) method for each Element derived type.
  3. Add an accept(Visitor) method to the Element hierarchy. The implementation in each Element derived class is always the same – accept( Visitor v ) { v.visit( this ); }. Because of cyclic dependencies, the declaration of the Element and Visitor classes will need to be interleaved.
  4. The Element hierarchy is coupled only to the Visitor base class, but the Visitor hierarchy is coupled to each Element derived class. If the stability of the Element hierarchy is low, and the stability of the Visitor hierarchy is high; consider swapping the ‘roles’ of the two hierarchies.
  5. Create a Visitor derived class for each “operation” to be performed on Element objects. visit()implementations will rely on the Element’s public interface.
  6. The client creates Visitor objects and passes each to Element objects by calling accept().

Rules of thumb

  • The abstract syntax tree of Interpreter is a Composite (therefore Iterator and Visitor are also applicable).
  • Iterator can traverse a Composite. Visitor can apply an operation over a Composite.
  • The Visitor pattern is like a more powerful Command pattern because the visitor may initiate whatever is appropriate for the kind of object it encounters.
  • The Visitor pattern is the classic technique for recovering lost type information without resorting to dynamic casts.


The November 2000 issue of JavaPro has an article by James Cooper (author of a Java companion to the GoF) on the Visitor design pattern. He suggests it “turns the tables on our object-oriented model and creates an external class to act on data in other classes … while this may seem unclean … there are good reasons for doing it.”

His primary example. Suppose you have a hierarchy of Employee-Engineer-Boss. They all enjoy a normal vacation day accrual policy, but, Bosses also participate in a “bonus” vacation day program. As a result, the interface of class Boss is different than that of class Engineer. We cannot polymorphically traverse a Composite-like organization and compute a total of the organization’s remaining vacation days. “The Visitor becomes more useful when there are several classes with different interfaces and we want to encapsulate how we get data from these classes.”

His benefits for Visitor include:

  • Add functions to class libraries for which you either do not have the source or cannot change the source
  • Obtain data from a disparate collection of unrelated classes and use it to present the results of a global calculation to the user program
  • Gather related operations into a single class rather than force you to change or derive classes to add these operations
  • Collaborate with the Composite pattern

Visitor is not good for the situation where “visited” classes are not stable. Every time a new Composite hierarchy derived class is added, every Visitor derived class must be amended.

Keyboard Settings in ABAP editor

Shortcut What it does
Ctrl + D Duplicate any line.
Ctrl + U Selected text converted into uppercase..
Ctrl + L Selected text converted into lowercase..
Ctrl + J Selected text will become capitalize.
Ctrl + O Goto a particular line in the program.
Ctrl+Alt+T Swaps current line with the Upper Line.
Ctrl+Shift+L Deletes the whole line

Otherway, we can created a new shortcut for selected command via using Keyboard option as the following picture

KeyBoard Options

KeyBoard Options

If you want to save your keyboard and import into new PC, you can do the following steps.

Checking SAP folder “C:\Users\XXXX\AppData\Roaming\SAP\SAP GUI\ABAP Editor”, you will found a folder named SAP GUI and in this folder, select find keymap.xml this is Keyboard mapping file, you can use this to import when having new computer.

Hope that help!