development

Development or developing may refer to: read more at WikiPedia

  • The file web.xml inside the WEB-INF folder is the Web Application Deployment Descriptor for your application. This is an XML file describing the servlets and other components that make up your application. The file below is what I use at work. It contains better settings than the default one, plus all descriptions of parameters.

    <?xml version="1.0" encoding="UTF-8"?>
    <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee   http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
     
    <context-param>
    <description>
    Comma separated list of URIs of (additional) faces             config files. (e.g. /WEB-INF/my-config.xml) See JSF             1.0 PRD2,
    10.3.2 Attention: You do not need to put
    /WEB-INF/faces-config.xml in here.
    </description>
    <param-name>javax.faces.CONFIG_FILES</param-name>
    <param-value>
     /WEB-INF/faces-configs/common-faces-config.xml,
     /WEB-INF/faces-configs/page1-faces-config.xml,
     /WEB-INF/faces-configs/page2-faces-config.xml
    </param-value>
    </context-param>
    Follow Divide and Conquer rule:
    Do not put all your managed beans, navigations rules in one big file. Consider one faces-config per functions or html page.
    <context-param>
    <description>State saving method: "client" or "server"          (= default) See JSF Specification 2.5.3
    </description>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>server</param-value>
    </context-param>
    Server is recommended.
    Ive tried one day client, but HTML pages were 10Mb big!
    <context-param>
    <description>
    Only applicable if state saving method is "server"         (= default) and if
    org.apache.myfaces.SERIALIZE_STATE_IN_SESSION is           true (=default) If true (default) the serialized              state will be compressed before it is written to the session. If false the state will not be compressed.
    </description>
    <param-name>
      org.apache.myfaces.COMPRESS_STATE_IN_SESSION
    </param-name>
    <param-value>true</param-value>
    </context-param>
    You should always balanced cpu/memory usage.
    (Compressing state cost CPU but spare memory...obvious)


    <context-param>
    <description>
    Only applicable if state saving method is "server"             (= default). If true (default) the state will be               serialized to a byte stream before it is written to             the session. If false the state will not be                     serialized to a byte stream.
    </description>
    <param-name>
     org.apache.myfaces.SERIALIZE_STATE_IN_SESSION
    </param-name>
    <param-value>false</param-value>
    </context-param>
    Compressing data save memory bytes on server at the cost of more computational power.
    <context-param>
    <param-name>
    org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
    </param-name>
    <param-value>5</param-value>
    </context-param>
    Number of back button. Default is 20. far too much. reducing this value decrease memory size.
    <context-param>
    <description>
    This parameter tells MyFaces if javascript code               should be allowed in the rendered HTML output. If             javascript is allowed, command_link anchors will have javascript code that submits the corresponding form. If javascript is not allowed, the state saving info and nested parameters will beadded as url parameters. Default: "true"
    </description>
    <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
    <param-value>true</param-value>
    </context-param>
    <context-param>
    <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
    <param-value>false</param-value>
    </context-param>
    Nothing special here. Most of the time, webpage are full of javascript.
    <context-param>
    <description>The buffer size to set on the response         when the  ResponseWriter is generated.
    By default the value is -1, which will not assign             a buffer size on the response.
    </description>
    <param-name>facelets.BUFFER_SIZE</param-name>
    <param-value>8192</param-value>
    </context-param> 
    Try to set the buffer size to the most common page size.
    <context-param>
    <param-name>facelets.SKIP_COMMENTS</param-name>
    <param-value>true</param-value>
    </context-param>
    In production, no need to let comment in rendered code
    <context-param>
    <description>
    If true, rendered HTML code will be formatted, so             that it is "human readable". i.e. additional line             separators and whitespace will be written, that do             not influence the HTML code. Default: "true"
    </description>
    <param-name>org.apache.myfaces.PRETTY_HTML</param-name>
    <param-value>false</param-value>
    </context-param>
    Cpu waste in production.
    Beautify your code in eclipse.
    Consider instead using Firefox source chart plugin which always beautify and color the source source
    <context-param>
    <description>
    If true, a javascript function will be rendered               that is able to restore the former vertical scroll             on every request.
    Convenient feature if you have pages with long                 lists and you do not want the browser page to                 always jump to the top if you trigger a link or               button action that stays on the same
    page. Default: "false"
    </description>
    <param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
    <param-value>true</param-value>
    </context-param>
     
    <context-param>
    <description>
    Validate managed beans, navigation rules and                   ensure that forms are not nested.
    </description>
    <param-name>org.apache.myfaces.VALIDATE</param-name>
    <param-value>true</param-value>
    </context-param>
    Can be turned off in production, if you have a good testing team and many deployment stage This kind of errors should not go un noticed.
    <context-param>
     <param-name>facelets.LIBRARIES</param-name>
    <param-value>
     /WEB-INF/taglib/tomahawk.taglib.xml;
     /WEB-INF/taglib/aa.taglib.xml;
     /WEB-INF/taglib/your.taglib.xml
    </param-value>
    </context-param>
    List here all 3rd party and your own tag library
    <context-param>
    <param-name>facelets.REFRESH_PERIOD</param-name>
    <param-value>2</param-value>
    </context-param>
    <context-param>
    <description>Special Debug Output for Development
    </description>
     <param-name>facelets.DEVELOPMENT</param-name>
     <param-value>false</param-value>
    </context-param>
    <context-param>
     <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
     <param-value>.xhtml</param-value>
    </context-param>
    			Using a 
    			facelets.REFRESH_PERIOD >= 1 
    			means that templates 
    			will be reloaded after 
    			a given period if the
    			file has been modified 
    			on the file-system.
    			

     

     

     

     

    Obvious settings

    <filter>
    <filter-name>extensionsFilter</filter-name>
    <filter-class>
     org.apache.myfaces.webapp.filter.ExtensionsFilter
    </filter-class>
     <init-param>
      <param-name>uploadMaxFileSize</param-name>
      <param-value>100m</param-value>
    </init-param>
    <init-param>
     <param-name>uploadThresholdSize</param-name>
     <param-value>100k</param-value>
    </init-param>
    </filter>   
    Some security settings. Consider settings these values accordingly to your needs.
    <error-page>
     <error-code>404</error-code>
     <location>/error.jsp</location>
    </error-page>
           
    <error-page>
     <error-code>500</error-code>
     <location>/error.jsp</location>
    </error-page>
           
    <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
    </error-page>
    Standard settings not related to JSF. Never reveal any useful informations in error pages!

       
  • Books:

    Softwares:

    Analysis

    Structural Analysis for Java"SA4J is a technology that analyzes structural dependencies of Java applications in order to measure their stability. It detects structural "anti-patterns" (suspicious design elements) and provides dependency web browsing for detailed exploration of anti-patterns in the dependency web. SA4J also enables "what if" analysis in order to assess the impact of change on the functionality of the application; and it offers guidelines for package re-factoring."
      

    Metrics

    Metrics sourceforge
    eclipse plugin
     
  • SableVM is a highly-portable Java virtual machine written in C, and implementing the Java virtual machine specification, second edition.
    I ti s currently able to start and use Eclipse 3.1
    On the JVM side, Java on BeOs is making huge steps
  • 51 minutes of pure joy! Thanks you Sara Bareilles!!! Listening to this on my Grado Sr-325 headphones is pure magic!

    On 9/10/12, Sara Bareilles played an online concert hosted by Stageit.com in order to raise money for an organization called Playing For Change http://playingforchange.org . Link to the organization with be posted below. All song rights and credits goes to Sara Bareilles and her respective label.

    • Playing for Change @ 4:34
    • Bright Lights and Cityscapes @ 9:45
    • Love Song @ 16:55
    • Only Shadows @ 24:40
    • Sittin' on the Dock of the Bay @ 31:56
    • King of Anything @ 37:35
    • Gravity @ 45:29
  • joomlalovexsd

    Full support for Joomla 3.1 has been added to the project “Schema Validation for Joomla Extensions” (GitHub), tested with all 113 manifests of Joomla 3.1.5! (components, modules, plugins and templates)

    Without them, Joomla accept any entry in manifest xml and never complains about

    • Mistyping, like a valid xml but that the Joomla installer do not understand or only partially,
    • Wrong constructs, xml tag child misplaced,
    • Invalid data type, like a path not being a valid path, an expected integer being a text and so on…

    Joomla just silently die during install or install only partially extensions. These days are over and all developers with any decent IDE will be able to

    • Validate while typing,
    • Enjoy auto completion.
    • Have an up to date documentation of all possibilities in Joomla’s manifest.

    What’s new

    see https://github.com/cedricwalter/joomla-xsd/commit/8b315332e8c0fa515da19f15a4c547f446850024

    component / module / plugins

    • add in <menu> support for attribute value img="class:banners">
    • add in <menu> support for attribute value view="anyString"
    • add in <menu> support for attribute value alt="anyString"
    • add to type="cmsVersionType" version 3.1
    • add support for <menu link="option=com_finder">COM_FINDER</menu> (finder.xml)
    • In <extension> attribute valuemethod="" is now optional
    • add new <help key="ANY_STRING" />
    • add in <field> support for attribute value first="anyNumber"
    • add in <field> support for attribute value last="anyNumber"
    • add in <field> support for attribute value step="anyNumber"
    • add in <field> support for attribute value published="" (mod_articles_category.xml)
    • add in <field> support for attribute value format="%Y-%m-%d %H:%M:%S"
    • add in <field> support for attribute value disable="separator" (mod_login.xml)
    • add in <fields> support for attribute value addfieldpath="validPath" (mod_finder.xml)
    • in <field> validate css class names class="btn-group" or class="btn-group btn1 blue" orclass=""
    • Allow empty without fieldset (vote.xml) <fields name="params"> </fields>
    • In <authorEmail> consider N/A as a valid email
    • Attribute &39;label&39; now optional on element &39;field&39;. <field name="spacer3" type="spacer" hr="true" />
    • Support for validate <field> type="url" (sef.xml)
    • in <fieldset> allow Attribute value label="" to appear in element (debug.xml)
    • allow <field> to have type attribute value category (contactcreator.xml)
    • allow <field> to have new attribute extension=com_* (contactcreator.xml)
    • In <media> attribute destination value is now optional
    • In <fieldset> add optionaladdfieldpath="" and validate that it is a valid path
    • In ```<option value="" empty values are now allowed
    • <updateservers> is now available in plugins manifests
    • In <field> type now support type="modal_article" or from enum (using xsd union)

    Plugins only

    • in <file plugin="weblinks">weblinks.php</file>

    Template only

    • In <extension> attribute value method="" is now optionnal
    • In <extension> addattribute value client=""
    • add <languages></languages>

    These files will be hopefully soon merged into Joomla CMS  (GitHub project) and officialy supported by Joomla

  • Joomla! Doc has a great documentation online that explains how to set up your development environment

    This article provides detailed instructions for setting up your workstation for Joomla! development. Note that there are many possible configurations for doing Joomla! development. Any environment that supports Apache, MySql, PHP, and Subversion should work for writing Joomla! code and extensions.

    This document provides step-by-step instructions for setting up and working with the Eclipse IDE. The example used and screen shots are for Windows XP, but the basic steps are the same for Linux.

    The part 1 mainly explains how to install technical components

    The part 2 is even better as it explains how to create patches for Joomla! along with some eclipse tips and tricks.

  • Welcome to Android application development! If you're new to Android app development, this where you should begin.

    Download Android Studio

    Android Studio is a new Android development environment based on IntelliJ IDEA. Similar to Eclipse with the ADT Plugin, Android Studio provides integrated Android developer tools for development and debugging. On top of the capabilities you expect from IntelliJ, Android Studio offers:

    • Gradle-based build support.
    • Android-specific refactoring and quick fixes.
    • Lint tools to catch performance, usability, version compatibility and other problems.
    • ProGuard and app-signing capabilities.
    • Template-based wizards to create common Android designs and components.
    • A rich layout editor that allows you to drag-and-drop UI components, preview layouts on multiple screen configurations, and much more.
    • Built-in support for Google Cloud Platform, making it easy to integrate Google Cloud Messaging and App Engine as server-side components.

    Download http://developer.android.com/sdk/installing/studio.html

    This download includes:

    • Android Studio early access preview
    • All the Android SDK Tools to design, test, debug, and profile your app
    • The latest Android platform to compile your app
    • The latest Android system image to run your app in the emulator

    Now start Android studio

  • git-stitch-repo

    Stitch several git repositories (merging git repository) into a git fast-import stream from Git-FastExport

    Installation

    $ perl -MCPAN -e shell
      
    cpan[6]> i /fastexport/
    	Distribution    BOOK/Git-FastExport-0.107.tar.gz
    	Module  < Git::FastExport        (BOOK/Git-FastExport-0.107.tar.gz)
    	Module  < Git::FastExport::Block (BOOK/Git-FastExport-0.107.tar.gz)
    	Module  < Git::FastExport::Stitch (BOOK/Git-FastExport-0.107.tar.gz)
    	4 items found
    
    cpan[6]> install BOOK/Git-FastExport-0.107.tar.gz
    
    cpan[6]> CTRL-D
    

    Usage

    git-stitch-repo will process the output of git fast-export --all --date-order on the git repositories given on the command-line, and create a stream suitable for git fast-import that will create a new repository containing all the commits in a new commit tree that respects the history of all the source repositories. Typical usage is like this:
    git clone https://github.com/xxxx/A.git
    git clone https://github.com/xxxxx/B.git
    
    $ ls
    A B
    
    mkdir result
    cd result
    git init
    git-stitch-repo ../A:folderA ../B:folderB | git fast-import
    
    # pull both repository in a new branch for examples
    git checkout -b newBranch
    git pull . master-A
    git pull . master-B
    
    # when finished delete unused branches
    git branch -d master-A 
    git branch -d master-B 
    
  • I did upgrade from TeamCity 5.0.1 to TeamCity 5.1.1 In no time, just drop the war in my Tomcat container :-)

    At this address you will always find the latest snaphosts of some (I would need 44 builds to display them all!) of my PHP projects for Joomla!

    http://teamcity.waltercedric.com

    I will also upgrade tomorrow early morning our TeamCity Licensed server at www.Innoveo.com .

    Continuous build for Joomla!

    By the way I have still to deliver (HERE and HERE) what i promised on the Joomla! development group, aka a full solution for developing Joomla! using Maven for PHP and Teamcity/Bamboo/Husdon. You can see the documentation I made in my WIKI (work in progress)

    TeamCity integration in Joomla!

    At the same time, Joomla! users that are using TeamCity, search no more, I will be providing you the first GPL module for Joomla! that let you display in your site the status of all your builds/projects! The code is heavily using the REST API with PHP CURL and a bit of XML parsing. If you have any requirements, it is still time to drop me an email ;-)

  • From www.devsource.com
    "Scripting languages have long been regarded by the programming world as poor country cousins, somehow inferior to the "real" programming languages. Yet, according to Evans Data Corp.'s Fall 2004 North American Development Survey, a lot of "real" programmers are adding scripting to their arsenals of programming tools. The research firm reports that over 41 percent of the 666 developers surveyed use Perl, 32 percent use PHP, and 15.6 percent use Python, with considerable overlap (other scripting languages were not included in the questionnaire)." read more HERE
  • Top 20 Replies by Programmers when their programs don't work
     1. "It works on my machine."  
     2. "Where were you when the program blew up?" 
     3. "Why do you want to do it that way?" 
     4. "You can't use that version on your system." 
     5. "Even though it doesn't work, how does it feel?" 
     6. "Did you check for a virus on your system?" 
     7. "Somebody must have changed my code." 
     8. "It works, but it hasn't been tested." 
     9. "THIS can't be the source of THAT." 
     10. "I can't test everything!" 
     11. "It's just some unlucky coincidence." 
     12. "You must have the wrong version." 
     13. "I haven't touched that module in weeks!" 
     14. "There is something funky in your data." 
     15. "What did you type in wrong to get it to crash?" 
     16. "It must be a hardware problem." 
     17. "How it that possible?" 
     18. "It worked yesterday." 
     19. "It's never done that before..." 
     20. "That's weird...." 

  • Beaucoup de personne me connaissant et qui m'écrivent me demande comment je developpe mes programmes java car je trouve toujours le moyen d'en faire des frameworks...ce qui est par définition plus dur.

    Eh bien j'applique plusieurs petite règles simples...

    1. Un bon tool: je ne travaille qu'avec eclipse (www.eclipse.org) car c'est un IDE de qualité et malgré la quantité de perspectives (j'en ai 16), views (j'en ai 64) et plugins (>20), je m'y sens à   l'aise. Je privilégie la vue hiérarchique "java browsing view" avec une vue supplementaire "hiérarchie" (F4) car cela facilite la navigation et le découpage sémantique losque je dévelope (projets<-> packages<->objets<->hiérarchie<->méthodes<->code)
    2. Un environnement de travail propice: Je travaille avec 2 écrans (un 21'' et un 15'4 LCD) car rien n'est plus ennuyeux de perdre son temps à   bouger/réduire/changer de tâches sans cesse. Cela me permet aussi de travailler en parallèle. C'est déroutant au début mais rien n'est plus malléable que le cerveau humain et vous vous surprendrez au bout de quelques semaines en passant d'un écran à   l'autre sans cesse. C'est simple si demain je trouve une méthode fiables et peu couteuse en temps CPU (pas avec une carte video USB svp) pour avoir un troisième écran, je saute sur l'occasion immédiatement.

    Ces 2 règles ne participent qu'a hauteur de 15% à   un travail de qualité...mais elle réduisent le stress au poste de travail. Le reste est plus standard...

    Quelques techniques de développement modernes, ont bouleversés ma vie (relativement courte) de developpeur:

    1. Les "design patterns" pour appliquer des élements d'architectures éprouvés à   des classes de problèmes.
      Il faut bien sur les comprendre (quand les appliquer et leurs bénéfices/inconvénients) sans pour autant savoir les implémenter. J'en place un maximum sans effort grà ¢ce à   un générateur de pattern (plugin eclipse).
      Je me débrouille pour avoir des hièrarchies la ou c'est évident (mais en général, elles apparaissent toute seule cf. Refactoring), j'ai rarement des super classes non abstraites et sans interface, je crée toujours des interfaces pour augmenter le niveau d'abstraction dans mon code à   chaque niveau (layer) et laisser à   l'utilisateur le droit d'insérer son code dans le mien.
      Rappeler vous: sans interfaces, vous n'avez pas de polymorphisme en java et un typage trop fort (pourquoi encore passer des types concrets à   vos objets alors que l'on peut jouer à   des niveaux plus abstraits avec les interfaces?)
      Les design patterns apportent, à   mon code, la flexibilité (pattern de créations), le dynamisme (pattern de comportements) ou améliore le design (pattern de structures)
      Je n'hésite pas non plus à   créer des objets en quantités et à   leur donner les droits et fonctions minimums qui leurs incombent, car peu m'inporte les pertes de performances: je privilégie le design quitte à   devoir profiler plus tard.
    2. Les "antipatterns" (www.antipatterns.com/) leur contraire, en général lorsque je récupère du code dans un mauvais état. Cela m'aide à   trouver quelle "design patterns" peut arranger la situation (en vue de la correction d'un bug, pour améliorer la maintenance etc...) 
    3. Je programme de plus en plus "par intentions" (lien-> informit), une idée centrale de l'extreme programming (XP voir  www.extremeprogramming.org ). Comment le client voudrait avoir à   utiliser mon code, en fait à   quoi doit ressembler idéalement le code (le nom des types, des méthodes, des mediateurs). Je les écrits (comme un squelette) et bien sur ils n'existent pas encore, (donc compile error). Je force donc eclipse à   les créer (Quick fix ou CTRL-1)  et remplis les blancs, à   savoir l'implémentation, ce qui est forcément une tache moins intéressante.

    4. l'UML (Unified Modelling Language) oui de plus en plus, mais uniquement pour observer l'évolution des dépendances entre les objects (les motifs et les relations) sur mon 2ème écran. Et toujours en reverse engineering: je modifie le code java et observe d'un oeil le diagramme UML. En fait cela rejoint la programmation par intention dans un sens sauf que normalement on part de l'UML par intention pour créer le squellete du code java et non l'inverse. Le sens que j'utilise permet cependant de compléter mon javadoc ou ma documentation efficacement.
    5. Les "metrics" (plugin eclipse metrics) ne me servent que rarement mais surtout pour auditter du code ne m'appartenant pas. J'utilise neanmoins le plugin Code analysys plugin(CAP) ou celui de IBM alphawork: Structural Analysis for Java (SA4j) néanmoins de temps en temps...

    Mais la véritable APOCALYPSE est survenue chez moi il y a trois ans:

    1. Avec le "Refactoring" ' www.refactoring.com ) il m'est impossible de tout prévoir et c'est la que trés rapidement, le refactoring tool de eclipse m'aide car j'itère des changes atomiques (dans le sens: élémentaire et rapide) très rapidement à   travers tout mon code et cela en permanence. Des méthodes bougent ou disparaissent, je renomme en permanence tout: variables, objects, packages (pour éviter des commentaires à   travers mon code). j'introduit aussi des design patterns.
      Je les utilisent tellement que j'ai définit des racourcis clavier dans le workspace de eclipse.
      Le code devient de plus en plus petit (donc moins de bugs/lignes) et fait de plus en plus de chose (par design). Il se bonnifie avec un risque minimum d'instabilité car
    2. J'utilise des "test unitaires" (Junit www.junit.org) qui m'assure aprés chaque gros refactoring que je n'ai pas perdu de fonctionnalitées, cela me sert aussi à   tester mes interfaces: comment mon code va ètre utilisé?, est ce que les signatures sont bien choisies? y a t'il assez de constructors et d'accessors, et sont t'il pertinents? La plupart du temps cela me force repasser par une étape de refactoring dans mon code.

    Est ce la bonne facon de developper? cela dépend des situations, du domaine ou vous travaillez et de vous bien sur.

    Est t'on forcément plus lent? oui et non, cette méthode est déroutante de prime abord mais elle respecte la théorie de l'évolution biologique, génération après génération (refactoring - design - refactoring - unit test) le code devient meilleur.

    Attention: on est pas forcément plus lent, mais cette méthode n'est pas très adaptée au problèmes pointues: on peut se prendre des murs sans cesse (et donc réimplémenter-refactorer) si on ne réflechit pas assez au préalable.

    D'un autre coté, ce qui est certain, c'est que écrire des frameworks est forcément plus long et plus dur que, en caricaturant, faire un main() de 150 lignes (mon dieu, cela se voit encore trop souvent). L'interèt de l'existence d'un framework est dans la réutilisation par d'autres personnes de votre code, et le fait que vous avez deja réalisés pour eux les taches les plus difficiles, mais tout en leur laissant la liberté de spécialiser votre code au besoin.

    Dans les composants java du coté serveur que je réalise pour l'ecommerce d'assurance vie, cela a toujours fonctionné. En tout cas pour moi....

  • Here is a solution to the following problems

    • Deriving Maven artifact version from GIT branch,
    • Update pom version on GIT checkout automatically,
    • Add the ability to use Pull request with Apache Maven.

    You have a workflow requirement that require you to have the artifact version of a module externally defined from the current branch in GIT.

    For example

    You want to start working on a new feature branch “feature-memory-improvement”, so you branch from master a new branch named feature/feature-memory-improvement

    Having unique snapshot is a something you need to share your code using a Maven repository, so you may want to have into the branch all pom.xml version changed to

    <version>FEATURE-MEMORY-IMPROVEMENT-SNAPHOTS</version>

    changing all your pom.xml and doing a technical commit&160; will create merge conflicts when using pull request!

    One solution, while not perfect is to do the following:&160; You can add a separate execution to run a goal which will change the version of the POM automatically in the Maven reactor. This small script will do it¨

  • Since I did not find any clear how to on the internet how to run test cases for 3rd party extensions that use Joomla CMS, here is my version of it.

    Prerequisites

    Having PHPUnit properly install, if you use XAMPP you may want to read this post.

     

    How to use PHPUnit in Joomla

    At the root of your Joomla installation directory, make a checkout of https://github.com/joomla/joomla-cms/tree/master/tests/unit

    You’ll need at least the following file

    • ${joomla_root}\tests\unit\bootstrap.php
    • ${joomla_root}\tests\unit\config.php
    • ${joomla_root}\tests\unit\JoomlaDatabaseTestCase.php
    • ${joomla_root}\tests\unit\JoomlaTestCase.php
    • ${joomla_root}\tests\unit\phpunit.xml
    • ${joomla_root}\tests\unit\readme.txt

    config.php is a custom or a copy of your configuration.php

    For your convenience, I provide a zip file (joomla_phpunit_testing.zip), unpack in your Joomla root and you’re done.

    Note when using PHPUnit 3.6 , Joomla should not need to include/require anything PHPUnit related since (at least) PHPUnit 3.6. This create errors otherwise.

    In PHPStorm

    Set Up PHPUnit

    Go to Settings, using CTRL+ALT+S, under PHPUnit, select the option “Use Bootstrap file” and use as value ${joomla_root}\tests\unit\bootstrap.php

    Set Up PHPUnit Skeleton Generator

    Go to Settings, using CTRL+ALT+S, under “Skeleton Generator”

    • Enter for “Path to phpunit-skelgen” the value is  ${xampp_root}\php, for example C:\xampp\php
    • Enter for “use bootstrap file” the value ${joomla_root}\tests\unit\phpunit.xml

    Your first Joomla test case

    Create a test case from any of your Joomla classes, by hitting CTRL+SHIFT+T, this will let you select the method you want to test and generate a runnable albeit incomplete test classes.

    It is only the beginning of testing your Joomla extensions, there is a lot now to learn

    • Mocking objects in Joomla, Stubbing of Joomla classes
    • Invoking protected method using TestReflection::invoke
    • How to create integration tests using the database
    • How to test the user interface using PHPSelenium
    • and more…

    These links may interest you

     

  •  
    mail from a new OpenComment  Developer James Friesen:
    I found the CVS code. I realized that you have that in there as a  branch of com_akocomment. I was mislead because the project still has the old name. I found the opencomment code but I need to know  what versions are which. I see that you are already working on a version for Joomla 1.5.x but I are you also planning to finish the version for 1.0.x? I don't think I'll be upgrading to 1.5 for a while so I'm interested in making the 1.0.x version work.  I connected to the CVS repository. I see that each regular Joomla  folder as a akocomment and opencomment version underneath it. What's  unclear to me is how to manage the different versions (for 1.0.x and 1.5.x) and how to run the latest version of OpenComment on my test server. If you can offer some tips that would be helpful.

    In fact I have still not found a correct solution to the problem of PHP versionning under PHPEclipse

    • I don't want to version joomla together with a database for each component i develop...otherwise I will have to version 5Mb (joomla) + database (or delta) + my component.
    • PHPEclipse (or eclipse) only make CVS version at the project level...it refuse to check in a directory (a component or module for example) in a project
    I really need to ask some people on Joomla Forge, and find a solution to that issue.

    Code version Joomla 1.0.x or Joomla 1.5.x?

    OpenComment has been develop under Joomla 1.0.8, it was working but was not fully tested...This code has been tagged and closed in a CVS version: v01_00_00
    The CVS HEAD contains the code for the 1.5.x version of Joomla. If You want to continue version 1.0 You'll need to open a CVS BRANCH of the version v01_00_00

    How to  join the development?
    1. You need to install Eclipse 3.1.1 and the plugin PHPEclipse (PHP eclipse do not run under 3.2Mx)
    2. You need to install the latest JDK to run Eclipse,
    3. You need to try to install the PHP debugger.
    4. You need to install MySQL4
    5. You need to install a Joomla 1.0.8 version or Joomla 1.5.X version
    6. You need to be accredited y me to have a commiter access to CVS
    As You see a lot of things to do before ever being able to write code. In order to help You, I have decide to open:

    A new project at Joomla Forge (It must be accepted first by the forge)

    I found another project which aimed at the same result:
    PHP Development Studio 
    Joomla/Mambo PHP Development Studio is a pre-packaged Eclipse version aimed at the PHP /MySQL developer. Includes tools like: PHPEclipse, Clay database modeller, SQL Explorer, QuickRex, Subversion client and FTP&WebDAV client. Serveral licenses apply. 

     I will in the next hour  provide a  full runnable PHPeclipse+Joomla+ Mysql+ PHP+ everything....environment. So You only have to:
    • Download and Install that big zip file.
    • Connect to CVS
    • I will deliver for each component in development (ex opencomment) a SQL script to initialize database. (And this because I develop the installer at the end of development.)
  • The Eclipse Foundation is targeting release of Eclipse 3.1 for late June 2005. There have been seven milestone releases of version 3.1 dating back to August 2004. The Eclipse Requirement Council identified six major themes that the technical community will deliver on:

    • Scaling Up
    • Enterprise Ready
    • Design for Extensibility
    • Rich Client Platform
    • Simple to Use 
    • Appealing to the Broader Community

    As with previous releases, the Eclipse development team is committed to preserving backward compatibility with previous version of Eclipse. Eclipse 3.1 will be compatible with Eclipse 3.0 for API (contract), Binary (plug in), Source and Workspace. Most of the Eclipse SDK is "pure" Java code and has no direct dependence on the underlying operating system. The 3.1 release of the Eclipse Project is written and compiled against version 1.4 of the Java 2 Platform APIs, and targeted to run on version 1.4 of the Java 2 Runtime Environment, Standard Edition.
    Eclipse SDK 3.1 is tested and validated on the following platforms:

    • Microsoft Window XP (Win 32) on Intel x86
    • Red Hat Enterprise Linux WS 3 (GTK) on Intel x86
    • SUSE Linux Enterprise Server 9 (GTK) on Intel x86
    • Sun Solaris 8 (Motif) on SPARC
    • HP-UX 11i (Motif) on hp9000 PA-RISC
    • IBM AIX 5L v5.2 (Motif) on PowerPC
    • Apple Mac OS X 10.3 (Carbon) on PowerPC

    More information about Eclipse 3.1can be found Here

  • apache_maven

     jetty-logo-80x22

    I was getting mad because jetty was refusing to redeploy my static files (xhtml, css) in Eclipse until I find the reason

    The Jetty Web Server provides a HTTP server and Servlet container capable of serving static and dynamic contend either from a standalone or embedded instantiations.

    Jetty buffers static content for webapps such as html files, css files, images etc and uses memory mapped files to do this if the NIO connectors are being used. The problem is that on Windows, memory mapping a file causes the file to be locked, so that the file cannot be updated or replaced. This means that effectively you have to stop Jetty in order to update a file.

    To fix this, add a line with to your maven-jetty-plugin configuration:

    org.mortbay.jetty 
    maven-jetty-plugin 
    6.1.5
       
     ... 
      src/main/resources/webdefault.xml 
     
    

    The default webdefault.xml file is found in the lib/jetty.jar at org/mortbay/jetty/webapp/webdefault.xml. Extract it to a convenient disk location and edit it to change useFileMappedBuffer to false:

     
        useFileMappedBuffer 
         false 
      

    Copy the changed file into src/main/resources/ of your project.

    The problem is explained more in Jetty's documentation.

  • Bug Tracking Tool
    Work in progress

    or Why it is not possible to manage any software development without a bug tracking tool

    A bug tracking system is basically a database linked to  a frontend:
    • The frontend can be a FAT client, understand a windows or application running on your pc and that need to be install by each developer/client, or may be
    • Adhering to a light client server model: HTML frontend which submit queries to a server.

    Provide

    Tracability

    When was the bug open, and closed, what is its status now. Who has reported it (login is required and all system support profile (user, tester, manager, developer, administrator) and/or isolation of project). Did It already existed in a previous version (regression in code), etc...

    Responsability

     Easily dispatch responsability or find quickly who was reponsible for solving it, how  much time was needed to close this bug, some system may send email automatically to developer to inform them... etc...

    Effort

    How difficult will it be to solve this issues, (can be a bugnote add by other developer). Most of the time, technical leader decide of the value of this field together with developers.

    Priorities

    How many bugs are still open at a date "t", how do I determine the order in which I will solve them...etc

    Standardisation of records

    By forcing tester/customer to enter some mandatory fields in a graphical forms. It may avoid You to hear some ridiculous statement like: "the application is not printing, working". It force the user talking a language You have decide together, having agreed on a "bug category" list is a very good and common example.

    Customization

    All modern bug tracking tool let You define and customize some part of the system according to your need.

    Addition of information

    A screenshot is better than thousand word, a file create by the application, a memory dump, anything that will help developer to reproduce the bug.

    Statistics/Reporting

    A lot of very powerful queries can be executed. It is always interesting to know, how many improvement were done in the next/past releases, or if a team has use more power to develop new functionnalities (also changes request which interest the customer the most) or loose time tracking some low level bug priority.
    In case of reporting, Bugzilla support the following:
    • Tabular reports - tables of bug counts in 1, 2 or 3 dimensions, as HTML or CSV.
    • Graphical reports - line graphs, bar and pie charts.

    Al of the above will have a positive result on:
    • communication among the team of developers and customers,
    • It will improve the product quality by several magnitude,
    • Developer will be more productive as the will know what to concentrate on or what is worth to do.
    AND Your customers will be happier!!

    Golden rules

    1. A bug that can be reproduce can be analysed/corrected.
    2. Correcting a bug is not always trivial, a correction may introduce new bugs.
    3. The intrinseque quality of a software is always improved with a tracking tool over time

    Some open source software:


    Bugzilla (http://www.bugzilla.org/) is the more famous, use in a lot of open source application (Mozilla, Apache, and even eclipse) version 2.19.2 (MySQL+PHP, Solaris, Linux, Win32, MacOS X, BSD) 370 companies are currently using it. (Nasa, IBM, Mozilla and others)- Wikipedia has a very brief article on it, Features are listed here

    Mantis. (http://mantisbt.sourceforge.net/) A very simple bug tracking tool with limited search functionnality compared to bugzilla, a strong community but not so much stable release as expected.

    Buggit (http://www.matpie.drw.net/PBSystems/products/buggit/Buggit.html) no new release since 2000 and bounded to MS access, aka running only unde windows. Listed Here because I use to play with it in 2001.