Sunday, July 21, 2013

Applying an Android application into any Application Store is not a walk in the park.
One need to prepare, beside the application binaries of course, several supporting documents (marketing, images, reviewer instructions etc.).

The publication process length might vary from store to store.
In Google Play the publication starts immediatly after the binary is being uploaded.
In Samsung Store it take several long days till the binaries are inspected and pass the entire certification process.
Amazon store submission process is very similar to the Samsung store process but the waiting period might be a bit shorter.
However, in all the stores mentioned above there is a lack of certainty about WHEN the process will end.

Therefore I was very surprised when I saw the submission process at the Korean store - T-Store.
In the submission dashboard there is a counter that specifies the deadline of this review (see image below)

T-Store Review Deadline counter


I like this efficiency and the feedback!

In case you wonder - this is NOT effects the inspection quality. In fact their inspection is one of the best quality I seen.






Saturday, June 29, 2013

Geek, Nerd, Dork ?

Some nice venn diagram about what makes a geek, nerd or dork:

http://www.buzzfeed.com/scott/nerd-venn-diagram

Recently a more scientifically approach was taken in a research about the difference between a nerd and a geek.. here are the results:
http://www.makeuseof.com/tag/are-you-a-geek-or-a-nerd-find-out-for-sure/


Saturday, December 8, 2012

PixMix - very cool app recommendation

I would like to recommend a cool mobile app I recently installed called PixMix.

You might have came across it in a Jelastic technological post, in their spotlight corner.
http://blog.jelastic.com/2012/12/07/the-jelastic-spotlight-pixmix/


PixMix app allows one to instantly create photo albums and share it with friends.
So every photo me and my friends  take in a certain album, instantly uploaded into an online space which show all the photos.

What distinguish it apart from other apps is the fact that it has cool feature of animated photo gallery.
This feature is a killer feature for me.
Every new photo, of a certain album, is immediately shown in the live animated gallery.

There is also the right amount of balance between social sharing and private albums. It allows you to share what right (and not instantly takes the whole album public) and for who is right.

I tried it in my daughter 2 years birthday party.
I connected my laptop into my living room TV, opened the album via the PixMix site and displayed the animated live gallery.
I started to take few photos vie PixMix, just to see it works, and to my surprise it was instantly appeared in the animated gallery.
That really took the attention of my family, and before I realized, everyone started taking photos and compete each other to see which photo will appear in the animated gallery...

The nice thing is that at the end of the birthday, I was left with many photos, capturing many moments, I wasn't even part of...

Check it out  :-)

Tuesday, August 14, 2012

DB connection pool - production tips

Every developer knows that DB IO is the bottle neck of most web application.

It is also a common best practice to use an open connection to the DB and manage it in a pool, since opening a DB connection is costly operation.

However, in many DB connection pools tutorials, often the mentioned parameters are the size of the initial pool (min, max size) and how many connection to increment.

I would like to state here additional configuration which is important mainly in production use to efficient pool management -

The following are configuration parameters which are specific to C3P0 pool, however, one can

  1. maxIdleTime - Num of seconds a Connection can remain pooled but unused before being discarded. Zero means idle connections never expire. I would recommend not keeping idle connection much time.
  2. maxIdleTimeExcessConnections - number of seconds that Connections in excess of minPoolSize should be permitted to remain idle in the pool before being culled. Intended for applications that wish to aggressively minimize the number of open Connections.
  3. maxConnectionAge -  A Connection older than maxConnectionAge will be destroyed and purged from the pool. This differs from maxIdleTime in that it refers to absolute age.
  4. unreturnedConnectionTimeout - Will destroy open/active connection if  it wasn't returned to the pool within the specified amount of time. This could potentially prevent memory leaks if exception which prevent connection to close occurred. use it with parameter- debugUnreturnedConnectionStackTraces=true so you could debug the and find the reason for such behavior.
 
 



references - C3P0 configuration

Monday, July 30, 2012

How to change logging level in runtime

Changing the log logging level in runtime is important  mainly in production environment where you might want to have debug logging for limited amount of time.

Well, changing the root logger is very simple - assuming you have an input parameter with the wanted logging level simply get the root logger and set by the input logging level, such as:

Logger root = Logger.getRootLogger();

//setting the logging level according to input
if ("FATAL".equalsIgnoreCase(logLevel)) {
    root.setLevel(Level.FATAL);
}else if ("ERROR".equalsIgnoreCase(logLevel)) {
    root.setLevel(Level.ERROR);
}

However - the common case is that we maintain log instance per class, for example:

class SomeClass{

//class level logger
static Logger logger - Logger.getLogger(SomeClass.class);
}

and setting the root logger is not enough, since the class level logger will not be affected.

The trick is to remember get all the loggers in the system and change their logging level too.
For example:

Logger root = Logger.getRootLogger();
Enumeration allLoggers = root.getLoggerRepository().getCurrentCategories();

//set logging level of root and all logging instances in the system
if ("FATAL".equalsIgnoreCase(logLevel)) {
    root.setLevel(Level.FATAL);
    while (allLoggers.hasMoreElements()){
        Category tmpLogger = (Category) allLoggers.nextElement();
        tmpLogger .setLevel(Level.FATAL);
    }
}else if ("ERROR".equalsIgnoreCase(logLevel)) {
    root.setLevel(Level.ERROR);
    while (allLoggers.hasMoreElements()){
        Category tmpLogger = (Category) allLoggers.nextElement();
        tmpLogger .setLevel(Level.ERROR);
    }
}


So just wrap it up in a service class and call it from your controller, with a dynamic logLevel String parameter which represent the logging level you wish to set your system to.

If any of you need the complete solution, please let me know.

Reference to the basic approach is in this link.

Thursday, July 26, 2012

Build documentation to last - choose the agile way

Lately I wondered what the best way to document a project is?

Taken from lwiki's GalleryMy documentation experience vary among different tools and methodologies.
I would like to share some observation I have and a conclusion about the best way to document a project.


The documentation could be classified to the following categories:

Documentation place:
  • In line code/ version control system (via code commit description)
  • In separate server linked to the code
  • In separate server, decoupled from the code (no direct linkage)
Documentation done by:
  • Developer
  • Product team/ Design team / architects
  • Technical writers
Documentation too:
  • IDE
  • Design documents
  • Modeling tool, Process Flow
  • Wiki
  • version control (e.g. git, svn,..) commits
  • Interface documentation
Not surprisingly there is a direct correlation between the tool used , the person who document the code, the amount of documentation, the "distance" of documentation from the code and the accuracy of that documentation.

Given the categories above it could be organized in the following manner:
  • Developers
    • In line code/ version control system (via code commit description) 
      • IDE/ version control
  • Product team/ Design team / architects
    • In separate server linked to the code 
      •  Design documents, Interface documentation
  • Technical writers
    •  In separate server, decoupled from the code (no direct linkage)
      • Modeling tool, Process Flo, wiki

Developers tend to write short inline documentation using IDE, well interface semantics and complementary  well written code commits.
As long as the person who document the functionality has more distance from the code, the documentation would usually be in places more decoupled from where the code exist and more comprehensive.

From my experience, even good design tend to change a bit and even if the documentation is good but is decoupled from the code, most chances are that it won't catch up with code change.

In real life, when requirements keep coming from the business into development, it sometimes brings with it not only additional code to directly support functionality, but often we see the need for some structural or infra change and refactoring.

The inline code documentation is agile and change with minimum effort along the change in functionality. If the developer submit the code grouped by functionality and provide good explanation about changes that were done it would the most updated and accurate  documentation .

I know that some of you might wonder about heavy duty design or complex functionality documentation.
I would recommend tackle these issues as much as possible inline the code, for example, assuming you read some pattern or some bug solution in the web put a link to that solution near the method/class which implement the solution. Try to model your code by known patterns so it would avoid documentation. Try to use conventions so it would reduce amount of configuration and make your code flow more predictable and discoverable.

This approach is even more important when managing a project in agile methodology.
Usually such methodology would rather direct communication with product/business to understand requirements rather than documented PRDs. This makes it even more important to have the code self explanatory easy for orientation. Moreover, frequent changes in design and business change would cause decoupled documentation soon be obsolete (or will drag hard maintenance)

Although it sounds easier said than done and it is not a silver bullet for every project, writing documentation as close as possible to the code itself should be taken as a guideline / philosophy when developing a project.


Acknowledgment - above image was taken from lwiki's Gallery : https://picasaweb.google.com/lh/photo/ScQcKRBjhY7UvnzJ7vNArdMTjNZETYmyPJy0liipFm0

Wednesday, July 25, 2012

Spring Profile pattern , part 4

Phase 3: using the pattern

As you can recall, in previous steps we defined an interface for configuration data.
Now we will use the interface in a class which needs different data per environment.

Please note that this example is the key differentiator from the example given in  the Spring blog, since now we don't need to create a class for each profile, since in this case we use the same method across profiles and only the data changes.


Step 3.1 - example for using the pattern
@Configuration
@EnableTransactionManagement
//DB connection configuration class 
//(don't tell me you're still using xml... ;-)
public class PersistenceConfig {

 @Autowired
 private SystemStrings systemStrings; //Spring will wire by active profile

 @Bean
 public LocalContainerEntityManagerFactoryBean entityManagerFactoryNg(){
  LocalContainerEntityManagerFactoryBean factoryBean
  = new LocalContainerEntityManagerFactoryBean();
  factoryBean.setDataSource( dataSource() );
  factoryBean.setPersistenceUnitName("my_pu");       
  JpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter(){
   {
    // JPA properties
    this.setDatabase( Database.MYSQL);
this.setDatabasePlatform("org.hibernate.dialect.MySQLDialect");
    this.setShowSql(systemStrings.getShowSqlMngHibernate());//is set per environemnt..           
   
   }
  };       
  factoryBean.setJpaVendorAdapter( vendorAdapter );
  factoryBean.setJpaProperties( additionalProperties() );

  return factoryBean;
 }
//...
@Bean
 public ComboPooledDataSource dataSource(){
  ComboPooledDataSource poolDataSource = new ComboPooledDataSource();
  try {
   poolDataSource.setDriverClass( systemStrings.getDriverClassNameMngHibernate() );
  } catch (PropertyVetoException e) {
   e.printStackTrace();
  }       
                 //is set per environemnt..
  poolDataSource.setJdbcUrl(systemStrings.getJdbcUrl());
  poolDataSource.setUser( systemStrings.getDBUsername() );
  poolDataSource.setPassword( systemStrings.getDBPassword() );
  //.. more properties...       
  return poolDataSource;
 }
}

I would appreciate comments and improvements.
Enjoy!

part 1, part 2 , part 3, part 4