Git repo commands

Making git repository bare...

git config --bool core.bare true

Checkstyle Vs. PMD Vs. FindBugs

There is often some misunderstanding when people talk about coding rules engines. Everyone tries to take position in favor of his preferred tool and does his best to explain what are the weaknesses of the other ones. For instance, a PMD supporter could say :

“Checkstyle is a stupid tool consuming time to search for tab characters when PMD is a smart one that can do the job alone as a good soldier, Findbugs is very good for resource consumption and Macker is … uh, what is Macker ? “

Time to breathe ! There is in fact no need to take such position since those tools are not competing but are complementary and should be used simultaneously as it is the case in Sonar. Each of them is mainly targeting a certain type of coding rules : conventions (Checkstyle), bad practices (PMD) and potential bugs (FindBugs).

GPL based JavaScript

When a user accesses a website with GPL'd JavaScript code, technically the "source code" (in this case a JS file) is "distributed" to the end-user. Does that mean your entire website needs to be GPL'd? There's anentire debate about that, too.

GPL license

It's called the GNU GPL.

And you should clarify which version. There are minor differences in the GNU GPLv2 and GNU GPLv3 in regards to how it applies to uncompiled scripting languages.

That being said, both are distribution licenses only, not EULAs (albeit GPLv3 borders on that). You can use the code without obligations if you do not redistribute it in any way. No paying, no attribution, no publishing required on your part.

The GNU GPL, as it is actually called, does allow usage without accepting the license (clause 5 in GPLv2.1). This usage permission applies to said friend. However, he may not distribute the combined work.

Using it internally (applies to webserver case): yes.

Distributing this mixed code as software package: no.

 Actually, there is a modified version(AGPL) that is specifically designed to force web apps to release the code. If the binaries are running on the server, you don't have any obligation under vanilla GPLv2.

What is a commercial website

Any site that Buys, Sells, or provides a service for a fee.

Mutable Vs. Immutable

Well, there are a couple aspects to this. Number one, mutable objects without reference-identity can cause bugs at odd times. For example, consider a Person bean with an value-based equals method:

Map map = ...
Person p = new Person();
map.put(p, "Hey, there!");

p.setName("Daniel");
map.get(p);       // => null

The Person instance gets "lost" in the map when used as a key because it's hashCode and equality were based upon mutable values. Those values changed outside the map and all of the hashing became obsolete. Theorists like to harp on this point, but in practice I haven't found it to be too much of an issue.

Another aspect is the logical "reasonability" of your code. This is a hard term to define, encompassing everything from readability to flow. Generically, you should be able to look at a piece of code and easily understand what it does. But more important than that, you should be able to convince yourself that it does what it does correctly. When objects can change independently across different code "domains", it sometimes becomes difficult to keep track of what is where and why ("spooky action at a distance"). This is a more difficult concept to exemplify, but it's something that is often faced in larger, more complex architectures.

Finally, mutable objects are killer in concurrent situations. Whenever you access a mutable object from separate threads, you have to deal with locking. This reduces throughput and makes your codedramatically more difficult to maintain. A sufficiently complicated system blows this problem so far out of proportion that it becomes nearly impossible to maintain (even for concurrency experts).

Immutable objects (and more particularly, immutable collections) avoid all of these problems. Once you get your mind around how they work, your code will develop into something which is easier to read, easier to maintain and less likely to fail in odd and unpredictable ways. Immutable objects are even easier to test, due not only to their easy mockability, but also the code patterns they tend to enforce. In short, they're good practice all around!

With that said, I'm hardly a zealot in this matter. Some problems just don't model nicely when everything is immutable. But I do think that you should try to push as much of your code in that direction as possible, assuming of course that you're using a language which makes this a tenable opinion (C/C++ makes this very difficult, as does Java). In short: the advantages depend somewhat on your problem, but I would tend to prefer immutability.

kill JBoss on Mac

kill -9 $(ps -e|grep jboss|awk '{ print $1 }')

Types of DAO

• Table DAO Code

Table DAO code is the most widely used Data Access Object. Each Table DAO represents a single table and contains methods to insert, update, and delete single rows using the following signatures (using an example Customer table):

public void insert(Customer customer) throws CustomerDaoException

public void update(CustomerPk pk, Customer customer) throws CustomerDaoException

public void delete(CustomerPk pk) throws CustomerDaoException

In addition to this, there are also numerous 'finder' methods generated. FireStorm/DAO creates default finders when you first import a schema but these are fully customizable. Some examples of finder methods:

public Customer findByPrimaryKey(CustomerPk pk) throws CustomerDaoException;

public Customer[] findWhereLastNameEquals(String lastName) throws CustomerDaoException;

public Customer[] findByCountry(int countryId) throws CustomerDaoException;

• View DAO Code

The View DAO is generated for each view in the database. This DAO code offers the same finder methods as the Table DAO code but obviously does not provide the insert, update, and delete operations because views are read-only.

• Custom DAO Code

Custom DAO code is used when you have a complex SQL query that goes beyond the simple CRUD (create, update, delete) operations on a single table. Examples would be SQL queries that perform a join between several tables, queries that performs aggregration using the GROUP BY operator, and bulk update or delete queries.

Example queries that the Custom DAO code feature in FireStorm/dAO can support:

SELECT a.*, b.* FROM a, b WHERE a.id = b.id AND b.install_date between ? and ?

DELETE customer WHERE status = ? AND create_date = ?

SELECT product, count(*) FROM product WHERE download_date > ? GROUP BY product

Example of declarative transaction implementation

Example of declarative transaction implementation

Consider the following interface, and its attendant implementation. This example uses Foo and Bar classes as placeholders so that you can concentrate on the transaction usage without focusing on a particular domain model. For the purposes of this example, the fact that the DefaultFooService class throws UnsupportedOperationException instances in the body of each implemented method is good; it allows you to see transactions created and then rolled back in response to the UnsupportedOperationException instance.

// the service interface that we want to make transactional

package x.y.service;

public interface FooService {

  Foo getFoo(String fooName);

  Foo getFoo(String fooName, String barName);

  void insertFoo(Foo foo);

  void updateFoo(Foo foo);

}

// an implementation of the above interface

package x.y.service;

public class DefaultFooService implements FooService {

  public Foo getFoo(String fooName) {
    throw new UnsupportedOperationException();
  }

  public Foo getFoo(String fooName, String barName) {
    throw new UnsupportedOperationException();
  }

  public void insertFoo(Foo foo) {
    throw new UnsupportedOperationException();
  }

  public void updateFoo(Foo foo) {
    throw new UnsupportedOperationException();
  }

}

Assume that the first two methods of the FooService interface, getFoo(String) and getFoo(String, String), must execute in the context of a transaction with read-only semantics, and that the other methods,insertFoo(Foo) and updateFoo(Foo), must execute in the context of a transaction with read-write semantics. The following configuration is explained in detail in the next few paragraphs.

<!-- from the file 'context.xml' -->
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:aop="http://www.springframework.org/schema/aop"
     xmlns:tx="http://www.springframework.org/schema/tx"
     xsi:schemaLocation="
     http://www.springframework.org/schema/beans 
     http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
     http://www.springframework.org/schema/tx
     http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
     http://www.springframework.org/schema/aop 
     http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">
  
  <!-- this is the service object that we want to make transactional -->
  <bean id="fooService" class="x.y.service.DefaultFooService"/>

  <!-- the transactional advice (what 'happens'; see the  bean below) -->
  <tx:advice id="txAdvice" transaction-manager="txManager">
  <!-- the transactional semantics... -->
  <tx:attributes>
    <!-- all methods starting with 'get' are read-only -->
    <tx:method name="get*" read-only="true"/>
    <!-- other methods use the default transaction settings (see below) -->
    <tx:method name="*"/>
  </tx:attributes>
  </tx:advice>
  
  <!-- ensure that the above transactional advice runs for any execution
    of an operation defined by the FooService interface -->
  <aop:config>
  <aop:pointcut id="fooServiceOperation" expression="execution(* x.y.service.FooService.*(..))"/>
  <aop:advisor advice-ref="txAdvice" pointcut-ref="fooServiceOperation"/>
  </aop:config>
  
  <!-- don't forget the DataSource -->
  <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
  <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
  <property name="url" value="jdbc:oracle:thin:@rj-t42:1521:elvis"/>
  <property name="username" value="scott"/>
  <property name="password" value="tiger"/>
  </bean>

  <!-- similarly, don't forget the PlatformTransactionManager -->
  <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="dataSource"/>
  </bean>
  
  <!-- other  definitions here -->

</beans>

Examine the preceding configuration. You want to make a service object, the fooService bean, transactional. The transaction semantics to apply are encapsulated in the  definition. The definition reads as “... all methods on starting with 'get' are to execute in the context of a read-only transaction, and all other methods are to execute with the default transaction semantics”. The transaction-managerattribute of the  tag is set to the name of the PlatformTransactionManager bean that is going to drive the transactions, in this case, the txManager bean.

Declarative transaction management

Declarative transaction management

	Note
	Most Spring Framework users choose declarative transaction management. This option has the least impact on application code, and hence is most consistent with the ideals of a non-invasivelightweight container.

The Spring Framework's declarative transaction management is made possible with Spring aspect-oriented programming (AOP), although, as the transactional aspects code comes with the Spring Framework distribution and may be used in a boilerplate fashion, AOP concepts do not generally have to be understood to make effective use of this code.
The Spring Framework's declarative transaction management is similar to EJB CMT in that you can specify transaction behavior (or lack of it) down to individual method level. It is possible to make a setRollbackOnly() call within a transaction context if necessary. The differences between the two types of transaction management are:

• Unlike EJB CMT, which is tied to JTA, the Spring Framework's declarative transaction management works in any environment. It can work with JTA transactions or local transactions using JDBC, JPA, Hibernate or JDO by simply adjusting the configuration files.
• You can apply the Spring Framework declarative transaction management to any class, not merely special classes such as EJBs.
• The Spring Framework offers declarative rollback rules, a feature with no EJB equivalent. Both programmatic and declarative support for rollback rules is provided.
• The Spring Framework enables you to customize transactional behavior, by using AOP. For example, you can insert custom behavior in the case of transaction rollback. You can also add arbitrary advice, along with the transactional advice. With EJB CMT, you cannot influence the container's transaction management except with setRollbackOnly().
• The Spring Framework does not support propagation of transaction contexts across remote calls, as do high-end application servers. If you need this feature, we recommend that you use EJB. However, consider carefully before using such a feature, because normally, one does not want transactions to span remote calls.

The concept of rollback rules is important: they enable you to specify which exceptions (and throwables) should cause automatic rollback. You specify this declaratively, in configuration, not in Java code. So, although you can still call setRollbackOnly()on theTransactionStatus object to roll back the current transaction back, most often you can specify a rule that MyApplicationException must always result in rollback. The significant advantage to this option is that business objects do not depend on the transaction infrastructure. For example, they typically do not need to import Spring transaction APIs or other Spring APIs.

Although EJB container default behavior automatically rolls back the transaction on a system exception (usually a runtime exception), EJB CMT does not roll back the transaction automatically on an application exception (that is, a checked exception other thanjava.rmi.RemoteException). While the Spring default behavior for declarative transaction management follows EJB convention (roll back is automatic only on unchecked exceptions), it is often useful to customize this behavior.

Reference:(http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html#transaction-declarative)

C3P0 connection pool configuration

<bean id="oracle.dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"> <property name="driverClass" value="oracle.jdbc.driver.OracleDriver"></property> <property name="jdbcUrl" value="jdbc:oracle:thin:testdb"/> <property name="user" value="sa"/> <property name="password" value=""/> <property name="initialPoolSize" value="5"></property> <property name="minPoolSize" value="5"></property> <property name="maxPoolSize" value="15"/> <property name="checkoutTimeout" value="1000"/> <property name="preferredTestQuery" value="select 1 from dual"/> <property name="maxStatements" value="50"></property> <property name="testConnectionOnCheckin" value="true"></property> <property name="idleConnectionTestPeriod" value="60"></property> </bean>