Selasa, 09 September 2014

JsonCollectionRenderer Bug can not set excludes from RenderContext

Kemarin saya mencoba implemetasi Rendering Partial RESTful Responses ternyata untuk index tidak bekerja dengan baik pada grails versi 2.3.11. Hal ini disebabkan karena terjadi bug pada grails.rest.render.json.JsonCollectionRenderer#renderJson(JSON converter, RenderContext context) Bisa dilihat source code versi 2.3.11 sebagai berikut
 package grails.rest.render.json

import grails.converters.JSON
import grails.rest.render.ContainerRenderer
import grails.rest.render.RenderContext
import groovy.transform.CompileStatic

import org.codehaus.groovy.grails.web.mime.MimeType

/**
 * ....
 */
@CompileStatic
class JsonCollectionRenderer extends JsonRenderer implements ContainerRenderer {
    final Class componentType
    ...
    @Override
    protected void renderJson(JSON converter, RenderContext context) {
        converter.setExcludes(componentType, excludes != null ? excludes : context.excludes)
        converter.setIncludes(componentType, includes != null ? includes : context.includes)
        converter.render(context.getWriter())
    }
}
Dengan melihat kode diatas nilai context.excludes tidak akan bisa di set pada converter karena field excludes tidak pernah null. Seharusnya kode nya adalah sebagai berikut..
 package grails.rest.render.json

import grails.converters.JSON
import grails.rest.render.ContainerRenderer
import grails.rest.render.RenderContext
import groovy.transform.CompileStatic

import org.codehaus.groovy.grails.web.mime.MimeType

/**
 * ....
 */
@CompileStatic
class JsonCollectionRenderer extends JsonRenderer implements ContainerRenderer {
    final Class componentType
    ...
    @Override
    protected void renderJson(JSON converter, RenderContext context) {
        converter.setExcludes(componentType, (excludes || context.excludes==null)? excludes : context.excludes)
        converter.setIncludes(componentType, includes != null ? includes : context.includes)
        converter.render(context.getWriter())
    }
}

Jumat, 07 Juni 2013

Implementasi WSI UsernameToken pada grails cxf

Saya ini saya ingin mencoba implementasi Security WSI. Pada proyek ini kita memerlukan domain UserWebservice sebagai penyimpan data username dan password.
 package org.grails.cxf.samplewssecurity1 
class UserWebservice {

    String username
    String password

    static constraints = {
    }
}

Setelah itu kita buat ServerPasswordCallbackHandlerService. Service ini berguna untuk lookup pasangan username dan password
 package org.grails.cxf.samplewssecurity1 
 import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
import org.apache.ws.security.WSPasswordCallback
import org.springframework.beans.factory.InitializingBean

class ServerPasswordCallbackHandlerService implements CallbackHandler,InitializingBean{

    @Override
    void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException{
        for (pc in callbacks){
            if(log.debugEnabled){
                log.debug pc.identifier
                log.debug pc.password
            }
            def password= UserWebservice.findByUsername(pc.identifier)?.password 
            if(password) {
                pc.password = password
            }
        }
    }

    @Override
    void afterPropertiesSet() {
    }
}

Kita mempunyai service yang akan proteksi dengan password yang bernama AnnotatedSecureService Seperti dibawah ini.
 package org.grails.cxf.samplewssecurity1 
import org.grails.cxf.utils.EndpointType
import org.grails.cxf.utils.GrailsCxfEndpoint
import org.grails.cxf.utils.GrailsCxfEndpointProperty

import javax.jws.WebMethod
import javax.jws.WebParam
import javax.jws.WebResult

@GrailsCxfEndpoint(expose = EndpointType.JAX_WS,properties = [@GrailsCxfEndpointProperty(name = "ws-security.enable.nonce.cache", value = "false"), @GrailsCxfEndpointProperty(name = "ws-security.enable.timestamp.cache", value = "false")])
class AnnotatedSecureService {

    @WebMethod(operationName = "simpleMethod")
    @WebResult(name = "simpleResult")
    String simpleMethod(@WebParam(name = "param") String param) {
        return param.toString()
    }
}
Kita akan tambahkan di class BootStrap sebagai berikut.
 package org.grails.cxf.samplewssecurity1  
import org.apache.cxf.frontend.ServerFactoryBean
import org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
import org.apache.ws.security.WSConstants
import org.apache.ws.security.handler.WSHandlerConstants
import org.grails.cxf.samplewssecurity1.UserWebservice

class BootStrap {
    ServerFactoryBean annotatedSecureServiceFactory
    def serverPasswordCallbackHandlerService
    def init = { servletContext ->
        // add user
        UserWebservice.findByUsername('agus') ?: new UserWebservice(
                username: 'agus',
                password: 'ramdan').save(failOnError: true)

        //Register some wss4j security
        Map inProps = [:]
        inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
        // uncomment when need particular PASSWORD_TYPE
        //inProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_DIGEST);
        inProps.put WSHandlerConstants.PW_CALLBACK_REF, serverPasswordCallbackHandlerService

        annotatedSecureServiceFactory.getInInterceptors().add(new WSS4JInInterceptor(inProps))

        //These can be added here or taken care of in the @GrailsCxfEndpoint annotation
        //annotatedSecureServiceFactory.getProperties(true).put("ws-security.enable.nonce.cache","false")
        //annotatedSecureServiceFactory.getProperties(true).put("ws-security.enable.timestamp.cache","false")
    }
    def destroy = {
    }
}
Program selengkapnya bisa clone di git://git.cloudbees.com/agusramdan/SampleWSSecurity2.git

Minggu, 02 Juni 2013

Definition of Done Product Development RDV


Sebuah Product Development yang mengharapkan Continues Release haruslah mempunyai sebuah Definition of Done. Tanpa DoD akan meyebabkan kalimat template seperti dibawah ini akan muncul:

"Seharusnya melakukan ...... sebelum release"

Kalimat diatas adalah sebuah templet di mana titik-titik bisa di isi oleh aktifitas apa saja yang tidak dilakukan pada saat development.

Oleh karena itu untuk Product Development RDV ini mempunai DOD sebagai berikut

Definition of Done Team RDV

Semua UserStory harus:
- Unit telah di test dengan minimal Coverage 80% (Unit Tested)
- Source Code telah di commit pada Source Repository
- Integrasi telah di test dengan minimal Coverage 20% (Integration Tested)
- Dokumetasi deployment telah di tambahkan
- Secenario Acceptance Test telah telah selesai dibuat.

- Secenario Stress Test telah telah selesai dibuat.

Dengan mempunyai DoD yang jelas maka kita bisa menyatakan dengan percayadiri bahwa sebuah UserStory telah selesai.   DoD ini akan berkembang sesuai dengan waktu. Untuk saat ini di rasa DoD cukup menantang untuk dilaksanakan oleh team.

Senin, 13 Mei 2013

Couldfoudary

Akhir-akhir ini saya sangat tertarik dengan aplikasi yang di deploy pada cloud.  Setelah cari penyedia cloud yang gratis akhirnya saya menemukan cloudfoundry . Setelah di cobahternyata cukup nyaman juga. 

Setelah merenung beberapa malam akhirnya saya putuskan untuk membuat sebuah project open source mengunakan grails.  Project ini didedikasikan untuk developer team atau testing team agar mereka lebih terstruktur dalam pengerjaan project.

Project ini diberinama RDV singkatan dari "Requirement Development Verification".  Aplikasi ini harus dapat dijalankan di cloud.  Pada versi awal saya akan menggunakan Grails sebagai framework.  Semoga project ini bisa menjadi hiburan untuk perjalanan sebagai software developer.

Rabu, 03 Oktober 2012

Test Last VS Test First

Dalam sebuah tim Project Development saya sering melihat hahwa terjadi permushan antara kubu Programmer dan Tester.  Tester merasa banga bila menemukan bug dan Programmer merasa terhina bila hal tersebut terjadi.  Bila ditelaah lebih lanjut dan dilihat dari Software Development Life Cycle (SDLC) yang menggunakan waterfall.  Bila dilihat dari tahapan waterfall adalah sebagai berikut:


  1. Requirements specification
  2. Design
  3. Construction
  4. Validation (Testing and debugging)
  5. Maintenance

Dan bila kita melihat project plant bisanya seperti berikut.


Dengan menggunakan cara diatas maka bila terjadi fail pada saat verfiikasi akan menyebabkan project terlambat karena harus memperbaiki Bug.  Perbaikan bug ini bisanya cukup mejebalkan karena.  Programmer akan lebih stress bila mengerjakan perbaikan bug daripade coding baru hal inilah yang mengikatakan kemungkian lembur pada saat Validation. Untuk mengurahi efek stress bagi tim kami  coba menerapkan sedikit modifikasi dari project plan diatas menjadi sebagai berikut.


Pada strukur project plan yang baru aktifitas berhubungan dengan testing dialakukan beriringan dengan prosess task  yang dilakukan programmer. Yang menarik ada aktifias Test Script Construction. Aktifitas ini melakkan konversi dari scrip yang manual hasil dari Test Design menjadi Automatic Test, Computer Executed Manual Test. Computer Executed Manual Test adalah sebuah script yang di jalankan oleh aplikasi tertentu atau robot tapi yang mentukan bahwa test tesebut fail atau success adalah manusia. Model ini untuk menguragi labor work pada saat validation. Sehingga bisa lebih cepat dalam melakukan exekusi.

Automatic Test dan Computer Executed Manual Test script dapat digunakan oleh programmer untuk melakukan validasi atas pekerjanya pada fase konstruksi. Hal ini cukup menguntukan karena programmer dapat lebih awal mengetahui kesalahan programm sebelum benar-benar dilakukan fase berikutnya.  Gaya ini sedikit banyak dipengaruhi oleh Test-First dibandingkan Test-Last.

Keuntungan dari cara ini adalah Tester tidak akan bangga bila mekea menemukan bug pada saat verifikasi.  Hal tesebut dikarenakan Tester mepunyai andil terhadap hal tersebut. Dengan cara ini Tester dan Programmer dapat lebih solid karena mereka saling medukung untuk menghidari verifikasi yang gagal. Walaupun demikian labor work pada saat validation masih diperlukan karena ada beberapa hal.





Minggu, 30 September 2012

Nilai dari anggota tim

Sebuah diskusi singkat dalam ruang pengasapan kemarin sampai saat ini masih menjadi pemikiran saya.  Diskusi tersebut adalah bagaimana caranya agar kita dapat menilai anggota tim dengan fair. Dalam tim kami terbentuk menjadi dua kelopok sub tim yaitu Programmer dan Tester.
Saat itu saya ditantang untuk membuat sebuah sekema penilaian agar kedua kelopok ini dapat berkerja bersama agar men-deliver project yang dapat diterima oleh pengguna. Menurut opini saya skema tersebut haruslah menpunyai karakterisitik seperti berikut.
1. Mondorong untuk meningkatkan pencapaian pribadi.
2. Memberikan kontribusi maksimum pada tim.
3. Menghidari efek menjatuhkan panter (karana umunya Programmer dan Tester bermusuhan).
4. Menghidari untuk mencari kambing hitam (pointing finger).
5. Menjadi pembelajaran untuk fase project berikutnya.
Sampai tulisan ini di turunkan skema tersebut masih samar-samar.  Karena ada beberapa sekenario yang harus di uji sehingga dapat diterima dalam 5 buah karateristik diatas.

Selasa, 26 Juni 2012

Pengen koding di blog

Tadi siang saya lihat sebuah blog (http://codeformatter.blogspot.com/) yang dapat melakukan format koding. Akhirnya saya mencoba sedikit  programm Hello World.  Dan luar biasa ternyata bagus juga.

 package helloword;  
 public class HelloWord {  
   public static void main(String [] str) {  
     System.out.println("Hello World !!!");  
   }  
 }  

Setelah tau hal ini saya jadi lebih semangat untuk coding di blog.