‘+’, ‘>’ and ‘~’ symbols in CSS Selector

‘>’  – Targets elements which are DIRECT children of a particular element.

div #container > p {
  border: 1pxsolidblack;






‘+’ – It is Adjacent sibling combinator. It combines two sequences of simple selectors having the same parent and the second one must come IMMEDIATELY after the first.

div + p { 
   color: green
‘~’  – It is general sibling combinator and similar to Adjacent sibling combinator. the difference is that the second selector does NOT have to immediately follow the first one means It will select all elements that is preceded by the former selector
div ~ p{

Allowed Memory Size Exhausted

This error happen because your memory is not enough to execute the php code (uploading large image, delete lot of products, send mass mails etc). Increasing the memory allocated for PHP will solve the issue.

Error variant:
  • Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 47200 bytes) in /path/public_html/system/library/image.php on line 34
  • Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 13069817 bytes) in /path/public_html/system/library/mail.php on line 144
  • Fatal error: Out of memory (allocated 33554432) (tried to allocate 14024 bytes) in /path/public_html/library/image.php on line 34
Apply one of solutions bellow to increasing the limit to 64MB, 128MB, 256MB or 512MB -depends on your host.
  1. Edit php.ini
    memory_limit = 128M;
  2. Or put code below to .htaccess
    php_value memory_limit 128M
  3. If you oftenly get this error and solution above isn’t work, contact your host. In most shared hosting, there is maximum memory_limit. You can’t set memory-limit to 64Mb if you get max 32Mb.


Source: http://www.opencartnews.com/tutorials/common-opencart-errors-and-how-to-solve-them/

Dependency Injection in Spring

Dependency Lookup

The Dependency Lookup is an approach where we get the resource after demand. There can be various ways to get the resource for example:

  1. A obj = new AImpl();

In such way, we get the resource(instance of A class) directly by new keyword. Another way is factory method:

  1. A obj = A.getA();

This way, we get the resource (instance of A class) by calling the static factory method getA().

Alternatively, we can get the resource by JNDI (Java Naming Directory Interface) as:

  1. Context ctx = new InitialContext();
  2. Context environmentCtx = (Context) ctx.lookup(“java:comp/env”);
  3. A obj = (A)environmentCtx.lookup(“A”);

There can be various ways to get the resource to obtain the resource. Let’s see the problem in this approach.

Dependency Injection

The Dependency Injection is a design pattern that removes the dependency of the programs. In such case we provide the information from the external source such as XML file. It makes our code loosely coupled and easier for testing. In such case we write the code as:

  1. class Employee{
  2. Address address;
  3. Employee(Address address){
  4. this.address=address;
  5. }
  6. public void setAddress(Address address){
  7. this.address=address;
  8. }
  9. }

In such case, instance of Address class is provided by external souce such as XML file either by constructor or setter method.

Two ways to perform Dependency Injection in Spring framework

Spring framework provides two ways to inject dependency

  • By Constructor
  • By Setter method

Courtesy: http://www.javatpoint.com/dependency-injection-in-spring

Stored Procedure Proxy in Spring Java Framework

The org.springframework.jdbc.object package contains the StoredProcedure class. By extending this class, Spring enables a stored procedure to be proxied by a Java class with a single business method. If you like, you can even define an interface that the stored procedure implements, meaning that you can free your application code from depending on the use of a stored procedure at all.

For example, if there were a stored procedure called “AllTitles” in a movie database to get all of the titles currently available, we would create a StoredProcedure subclass that implements an application-specific interface for use by clients.

 public class AllTitleSproc extends StoredProcedure implements AllTitleLister { private static final String STORED_PROCEDURE_NAME = "AllTitles"; private static final String RESULT_SET_NAME = "titles"; public AllTitleSproc(DataSource dataSource) { setDataSource(dataSource); setSql(STORED_PROCEDURE_NAME); declareParameter( new SqlReturnResultSet( RESULT_SET_NAME, new TitleMapper())); compile(); } public List<Title> listAllTitles() { Map result = execute(new HashMap()); // no input params return (List<Title>) result.get(RESULT_SET_NAME); } private static class TitleMapper implements ParameterizedRowMapper<Title> { public Title mapRow(ResultSet resultSet, int i) throws SQLException { Title t = new Title(resultSet.getLong(1)); t.setName(resultSet.getString(2)); return t; } } }

Notice first that we can achieve portability with stored procedures across databases; all that is required is that the stored procedure name be the same (although we could make this configurable if we wanted in order to further increase portability). Second, notice that the class AllTitleSproc implements an application-specific interface, AllTitleLister:

 public interface AllTitleLister { List<Title> listAllTitles(); }

This allows code that uses this functionality to be completely independent of how movie titles are obtained:

 public class AllTitleListerClient { private AllTitleLister allTitleLister; public void setAllTitleLister(AllTitleLister allTitleLister) { this.allTitleLister = allTitleLister; } public void useLister() { List<Title> titles = allTitleLister.listAllTitles(); for (Title t : titles) { System.out.println(t.getId() + ":" + t.getName()); } }

Since the allTitleLister property is provided via dependency injection, this client code only depends upon the interface and none of its implementation details.

Courtesy: http://www.stevideter.com/2008/03/08/processing-stored-procedure-result-sets-in-spring/


JTAG Debugger

Serial Communication (IEEE 1149.1 standard) initially developed to test the printed circuit boards, but now become a defacto standard for debugging low level firmware to different operating system applications.

1. TDI (Test Data In)
2. TDO (Test Data Out)
3. TCK (Test Clock)
4. TMS (Test Mode Select)
5. TRST (Test Reset)

IEEE 1149.1 Daisy Chain


IEEE 1149.7 (Reduced Pin Count) Daisy Chain



Supported TCK is 10 – 100 MHZ