Something to view
The future release of java , jvm and jee.
http://www.infoq.com/presentations/To-Java-SE-8-and-Beyond
http://www.infoq.com/presentations/Java-EE-7-8?utm_source=infoq&utm_medium=popular_links_homepage
Google+
Picketlink simple bug resolving
Error: Caused by: java.lang.IllegalStateException: PL00075: File could not be located :policyConfig.xml
at org.picketlink.identity.federation.core.pdp.SOAPSAMLXACMLPDP.getPDP(SOAPSAMLXACMLPDP.java:115)
at org.picketlink.identity.federation.core.pdp.SOAPSAMLXACMLPDP.
Solutions:
although you want to use SAML assertions, picketlink loads a single web service for SAML and XACML authentication, so you have to define the policy files. You can see an example of pdp application at this address:
https://community.jboss.org/wiki/CheatsheetPicketLinkAndJBossAS
Google+Continuouos Integration, Continuouos Delivery – Questi sconosciuti … 0×1
Writing code is fun, but deploying to production is not. Cit Mike McGarr
Noi costruiamo, vendiamo e distribuiamo software. Non c’è nulla di più istantaneo del software, possiamo cambiarlo in pochi giorni e spedirlo in pochi nano-secondi, ma cosa succede quando risaliamo ai primi anelli della catena ? Sono stati scritti numerosi libri su come costruire un buon software, alcuni ormai dedicati alla storia e presi come pilastri della storia informatica di questi giorni. Ma cosa succede quando dobbiamo distribuire il nostro applicativo e per applicativo intendo proprio i manufatti (compilati) che dobbiamo consegnare al cliente ? Qui ci troviamo di fronte a delle vere e proprie sabbiere inconsistenti che permangono nei tempi , vuoi per motivi economici , ma anche per motivi di lentezza al cambiamento. Mi riferisco principalmente al mercato IT italiano ed a come queste metodologie (DevOps e Continuos Integration and Delivery) non sono propriamente usate. Prima di tutto , dobbiamo scordarci i vecchi tool (perchè ? , perchè sono vecchi, il mercato è cambiato in questi 10 anni , figuriamoci quello IT), seconda cosa non è pensabile correre con un macigno sopra la testa. Non è pensabile riuscire ad essere efficienti tramite il solo intervento umano.
Dopo questa breve parentesi di carattere volutamente non tecnico, passiamo all’oggetto del topic, Che cos’è il DevOps ? Bhe … basta cercare su wikipedia ed abbiamo subito una risposta abbastanza esauriente. Il DevOps è un metodo di sviluppo software atto a stressare la comunicazione , collaborazione ed integrazione tra sviluppatori e professioni IT o persone che hanno nel core business l’uso di tecnologie informatiche. Quello che interessa maggiormente a noi è l’uso di metodi di release management ( o per meglio dire release engineering). D’altro canto non è pensabile non proporre cambiamenti al cliente, anche se alcune volte è proprio il cliente a proporre cambiamenti. Per concludere questa parentesi direi che per motivi espressamente personali non mi dilungherò troppo su questa parte, anche perchè ogni azienda ha i propri limiti ed a volte le proprie inossidabili strutture, non mi interessa approfondire questa tematica, ne mi interessa entrare nel merito di alcune scelte. Quello che ogni essere umano con un minimo di intelligenza fa è scegliere con le informazioni che esso ha a disposizione nel momento della scelta, quando queste cambiano, una scelta pregressa può rivelarsi non corretta, ma senz’altro la migliore ( best resoning and deduction approach). Detto questo, è meglio esordire con un sunto molto semplice: “il deployment non può essere fatto manualmente!”
Due strumenti che voglio approfondire in quest’articolo sono jenkis e artifactory, mi soffermerò maggiormente su primo anche se il secondo è il miglior modo ( al momento) per gestire repository di binari, perchè sono proprio questi gli artefatti che interessano al cliente, non i sorgenti anche se il cliente paga per essi. Rimando a delle semplici slide di Mike McGarr per una brevissima partentesi su CI: http://www.slideshare.net/jmcgarr/continuous-delivery-applied-agile-richmond (piccola nota personale, Serena Dimension viene esplicitamente bannato).
- Continuous Integration (CI)
Il continuous integration non è una tecninca binaria, ossia che o viene applicata oppure no, ma ci possono essere varie fasi in cui esso può essere inizialmente applicato. Ognuna di queste fasi possono essere incrementalmente adottate nell’infrastruttura tecnica e , cosa più importante, all’interno delle pratiche e cultura dell’azienda.
- Fase 1 – Nessun build server: Non c’è nessun centrale build server, il software viene costruito manualmente o tramite un tool di building quale ant , msbuild etc. Il codice sorgente potrebbe essere memorizzato all’interno di un tool di versioning, quali svn. In qualche tempo prima della release il “programmatore” integra manualmente i cambiamenti, un processo che generalmente associato a sofferenza e pena ( sembra la descrizione di una malattia psichiatrica, bhe … potrebbe causarne).
- Fase 2 – Build notturni: Il team ha un build server dove automatizzati build sono schedulati nelle ore notturne. Il build compila semplicemente il codice, ma non c’è nessun ripetibile o test automatizzato ( vi dice niente questo ambiente ?
). Invece, se test automatici sono presenti non sono vincolanti per il processo di build e potrebbero non girare correttamente tutti. Comunque gli sviluppatori fanno dei commit regolari sul repository ed in questa fase, se un commit va in conflitto con un’altro commit il build server automaticamente avverte il team via email nella mattina seguente. Nonostante questo, in questa fase il build server viene ancora usato a titolo informativo ( come dire … qualcosa è andato male, bhe… meglio l’abbiamo scoperto in questa fase, ma lo fisseremo al più presto, ma qualcosa può ancora andare male … brrrrrrrrr). I programmatori fissano subito il problema, ma il build potrebbe rimanere ancora corrotto ( aufff… che fatica fare il deployment). - Fase 3 – Build Notturni e test automatici di base: Il team in questa fase prende in considerazione il CI più seriamente ( e finalmente … ). Il build server schedula una nuova compilazione ogni volta che c’è un commit sul nostro sistema di versioning. Inoltre il team ha la possibilità di vedere quali cambiamenti sono stati apportati al codice sorgente , lo stato della compilazione dell’intera applicazione. In questa fase si ha anche “l’obbligo” di fornire dei casi di test automatizzati che saranno lanciati in combinazione con il nuovo build. La cosa fantastica o quanto meno moderna, è la possibilità di notificare per email all’interno team quali sono i test che non sono andati a buon fine o tramite IM. Compilazioni fallite sono spesso intercettate molto rapidamente.
- Fase 4 – Acceptance Test e Deployment Automatico : Questa è la fase dove il nostro prodotto fornisce dei test di accettazione ed il deployment automatico nel primo ambiente di test viene eseguito. Quello che banalmente si fa è prendere in considerazione tutti build stabili (ossia quelli non marchiati come SNAPSHOT per usare un gergo alla maven e trasferirli nell’ambiente di test). Per il DataBase un lancio massivo degli script possono essere eseguiti in modo concorrente (ma questo già lo sappiamo fare, non è vero ? :) ). Maven, Ivy o NuGet ci forniscono un meccanismo per legare logicamente (tramite dipendenze) diverse versioni degli stessi artefatti tra loro. Questo garantisce che un deployment non sarà mai parziale, ma avrà le dipendenze corrette. La domanda potrebbe essere : ma come faccio a capire che funzionalità sto trasportando ? La risposta è semplice: un qualsiasi enterprise binary repository (Artifactory ad esempio) ci permette di inserire dei metadati in aggiunta alla dll che vogliamo inserire nel repository.
Le fasi precedenti sono ripetibili ad ogni rilascio e possono essere in combinazioni con le tecniche di Continuous Deployment che tenterò di descrivere nel seguito di questi articoli.
“E’ necessario gestire le dipendenze a livello di binari e non a livello di sorgenti durante il deployment” questo è banalmente vero. Il customer non ha bisogno di sorgenti, siamo noi che ne abbiamo bisogno per risolvere problemi non intercettabili in nessun altro ambiente, questo è vero in molte occasioni, ma con un repository di pre-compilati versionati possiamo intercettare molto meglio il problema. Inoltre, possiamo sempra aggiungere i sorgenti su un sotto-sistema di debug. Ma il deployment in produzione deve essere semplice, pulito e senza troppi problemi di sorta. Esistono molti modi per rendere il tutto facilmente fruibile e alcuni meccanismi di rilascio devono essere semplice, concordati e temporizzati.
“La maggior parte dei problemi in produzione sono dovuti alle differenze strutturali tra l’ambiente di test e quello di produzione”.
Alla prossima!
Google+
Oracle – take care of ordering settings
What I’ve learnt, today ? I have to take care of session parameters during operations. If you have a linguistic compare operations with
binary_ci ordering, your index doesn’t work with default settings. By default,NLS_COMP is set to BINARY, meaning that string comparisons performed by functions such as LEAST are based on the underlying character code values.
So the following query returns ‘JONATHAN’:
SELECT LEAST('JONATHAN','Jonathan','jon') FROM dual;
if you want to order the results in linguistic way or in lexicographilcal order,you could set this session parameter.
ALTER session SET nls_comp=linguistic; SELECT LEAST('JONATHAN','Jonathan','jon') FROM dual;
The result now is jon, as we want. In this case some previous defined table indexes stop to work. An example in the following:
SQL> SELECT last_name 2 FROM employees 3 WHERE last_name = 'Olson'; LAST_NAME ------------------------- Olson Execution Plan ---------------------------------------------------------- Plan hash VALUE: 3085132068 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| TIME | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 8 | 1 (0)| 00:00:01 | |* 1 | INDEX RANGE SCAN| EMP_NAME_IX | 1 | 8 | 1 (0)| 00:00:01 | -------------------------------------------------------------------------------- Predicate Information (identified BY operation id): --------------------------------------------------- 1 - access("LAST_NAME"='Olson') Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 2 consistent gets 0 physical reads 0 redo size 426 bytes sent via SQL*Net TO client 419 bytes received via SQL*Net FROM client 2 SQL*Net roundtrips TO/FROM client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL> ALTER session SET nls_comp = linguistic; Session altered. SQL> SELECT last_name 2 FROM employees 3 WHERE last_name = 'Olson'; LAST_NAME ------------------------- Olson Execution Plan ---------------------------------------------------------- Plan hash VALUE: 1445457117 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| TIME | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 8 | 3 (0)| 00:00:01 | |* 1 | TABLE ACCESS FULL| EMPLOYEES | 1 | 8 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified BY operation id): --------------------------------------------------- 1 - filter(NLSSORT("LAST_NAME",'nls_sort=''WEST_EUROPEAN''')=HEXTORAW ('5A4B695A5500010202020200') ) Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 7 consistent gets 0 physical reads 0 redo size 426 bytes sent via SQL*Net TO client 419 bytes received via SQL*Net FROM client 2 SQL*Net roundtrips TO/FROM client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL> spool off;
As you can see , if you alter the NLS_COMP session parameter oracle stops using the column’s index and executes a full table scan to retrive the results. If you want to resolve this problem in a simple way, i suggest to create a simple index, with NSL_SORT set to BINARY_CI and set NLS_SORT parameter as follows:
ALTER session SET nls_sort=binary_ci; CREATE INDEX last_name_ci ON employees ( NLSSORT ( last_name, 'NLS_SORT=BINARY_CI') );
In the following the trace of the oracle plan, as you can see the query uses the new index:
SQL> ALTER session SET nls_comp = linguistic; Session altered. SQL> ALTER session SET nls_sort = binary_ci; Session altered. SQL> SELECT last_name 2 FROM employees 3 WHERE last_name = 'Olson'; LAST_NAME ------------------------- Olson Execution Plan ---------------------------------------------------------- Plan hash VALUE: 3250234101 -------------------------------------------------------------------------------- ------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU) | TIME | -------------------------------------------------------------------------------- ------------ | 0 | SELECT STATEMENT | | 1 | 77 | 2 (0) | 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 1 | 77 | 2 (0) | 00:00:01 | |* 2 | INDEX RANGE SCAN | LAST_NAME_CI | 1 | | 1 (0) | 00:00:01 | -------------------------------------------------------------------------------- ------------ Predicate Information (identified BY operation id): --------------------------------------------------- 2 - access(NLSSORT("LAST_NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('6F6C736F6E 00') ) Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 426 bytes sent via SQL*Net TO client 419 bytes received via SQL*Net FROM client 2 SQL*Net roundtrips TO/FROM client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL> spool off;
So, take care of ordering settings in your sessions
!! See you soon !!
Google+