RE: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
Hahaha yess... I have to agree with this... They really are paranoid... So we can assert that not just any random thugs can do this.. :p Adelwin Handoyo | Senior Consultant - Wholesale Bank Standard Chartered Bank 7, Changi Business Park Cresent, Level 3. Singapore (486028) T : (65) 659 61395 | E adelwin.adel...@sc.com -Original Message- From: jug-indonesia@yahoogroups.com [mailto:jug-indone...@yahoogroups.com] On Behalf Of Samuel Franklyn Sent: Friday, July 16, 2010 12:17 PM To: jug-indonesia@yahoogroups.com Subject: Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya. On 7/16/2010 10:49 AM, Endy Muhardin wrote: On Fri, Jul 16, 2010 at 9:13 AM, Adelwin, Adelwin adelwin.adel...@sc.com wrote: Duit gue mah itungan nya receh buat konglomerat gitu... Tapi konglomerat juga nabung disono... Mereka harus protect duit die... and yours along with it... 10% off chance bahwa itu akan gak secure... well they just cant live with that... Banking itu industri trust, yang mana trust itu urusan psikologis dan bukan teknis. Kalo sempat ada image bahwa suatu bank tidak aman, bisa2 bubar urusannya. Makanya seperti kata Adelwin, mereka akan spend all cost untuk mencapai 100% secure. Selain urusan token device ini, banking juga pakai alat yang namanya HSM (Host Security Module). Harganya at least senilai 1 Honda Jazz. Biasanya bank beli at least 2 biji buat failover. Apa sih HSM itu? Tidak lebih dari kalkulator kriptografi dengan sedikit memori untuk menyimpan key. Bisakah kita bikin aplikasi tanpa HSM? Sangat mudah sekali, tinggal donlod bouncycastle, koding 1-2 hari, selesai. Tapi coba tawarin solusi ke bank tanpa HSM. They will show you the door. Bahkan tanya2 di milis jpos aja, begitu ada indikasi kita gak mau pakai HSM, bakalan dicuekin. Mahalnya HSM dikarenakan adanya faktor pengaman fisik di HSM. HSM ini secara fisik dirancang tamper proof. Kalau ada yang mau utak-atik hardwarenya untuk bisa tahu isi algoritma dalam HSM maka langsung tuh isi data dalam HSM hangus. He he he. HSM only for the paranoid. Bank is paranoid institution. Buktikan Anda peduli pendidikan Indonesia. Dukung Kurikulum SMK berJava.. kirimkan surat resmi perusahaan dukungan ke moderator JUG. === Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke jug-indonesia-unsubscr...@yahoogroups.com. Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id Yahoo! Groups Links This email and any attachments are confidential and may also be privileged. If you are not the addressee, do not disclose, copy, circulate or in any other way use or rely on the information contained in this email or any attachments. If received in error, notify the sender immediately and delete this email and any attachments from your system. Emails cannot be guaranteed to be secure or error free as the message and any attachments could be intercepted, corrupted, lost, delayed, incomplete or amended. Standard Chartered PLC and its subsidiaries do not accept liability for damage caused by this email or any attachments and may monitor email traffic. Standard Chartered PLC is incorporated in England with limited liability under company number 966425 and has its registered office at 1 Aldermanbury Square, London, EC2V 7SB. Standard Chartered Bank (SCB) is incorporated in England with limited liability by Royal Charter 1853, under reference ZC18. The Principal Office of SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In the United Kingdom, SCB is authorised and regulated by the Financial Services Authority under FSA register number 114276. If you are receiving this email from SCB outside the UK, please click http://www.standardchartered.com/global/email_disclaimer.html to refer to the information on other jurisdictions.
Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
2010/7/16 Samuel Franklyn sfrank...@gmail.com: Mahalnya HSM dikarenakan adanya faktor pengaman fisik di HSM. HSM ini secara fisik dirancang tamper proof. Kalau ada yang mau utak-atik hardwarenya untuk bisa tahu isi algoritma dalam HSM maka langsung tuh isi data dalam HSM hangus. He he he. HSM only for the paranoid. Bank is paranoid institution. HSM yang beneran, strukturnya udah kayak bom. Ada sensor cahaya di dalamnya, yang kalo dibuka akan menghapus data. Ada sensor gerakan juga, jadi kalo kena guncangan, datanya juga dihapus. Tapi dari sudut pandang programmer, ya tidak lebih dari kalkulator + sedikit memori buat simpan LMK. Waktu development pakai bouncy castle, pas production baru pakai HSM. -- Endy Muhardin http://endy.artivisi.com Y! : endymuhardin -- life learn contribute --
RE: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
setuju ama om adelwin. cmn security jg harus di barengin ama comfort masalahnya :(( lagian gimana caranya sms bisa lebih secure drpd otp ato media encryption lainnya. lagian sekarang serba salah jg. kalo ke bobolan gara2 sms semua pada komplen banknya. kalo terlalu secure jg bilang terlalu ribet. :D --- On Thu, 15/7/10, Adelwin, Adelwin adelwin.adel...@sc.com wrote: From: Adelwin, Adelwin adelwin.adel...@sc.com Subject: RE: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya. To: jug-indonesia@yahoogroups.com Date: Thursday, 15 July, 2010, 19:13 Jadi gw sih gak terlalu liat manfaatnya otp device yg dipersenjatai dengan brightest algorithms.. . Coding cupu dengan random-number + sms ajah dah reasonably unbreakable buat kebanyakan personal banking, yang buat gw seems to be solusi yg lebih logical dari sisi development cost maupun customer's convenience. Well… luckily they don’t think so… Otherwise.. I’d soon be out of job… Hahahhaha Namanya juga di bank… Innovation is waaa down the list… Security is of the utmost importance… Mau dobel2… mau redundant… mau most of the times useless… tetep pasti ada… Buat mereka rule 80-20 ituh gak ngaruh… Die apply 20% of the security that they “could have” placed to serve 80% of their customer… They just don’t work like that… Mereka akan coba push sebisa mungkin… at all cost(I’d know)… supaya bisa sedekat mungkin sama 100%... Bagi lu mungkin aahh gak penting lah ginian… 90% of the time juga pasti secure lah… Lagian sapa mau ambil duit gue… Duit gue mah itungan nya receh buat konglomerat gitu… Tapi konglomerat juga nabung disono… Mereka harus protect duit die… and yours along with it… 10% off chance bahwa itu akan “gak” secure… well they just cant live with that… Don’t be so quick to dismiss things… Ini kerjaan gue inih… Gue cari makan dari sini… Banking… I would know… Adelwin Handoyo | Senior Consultant - Wholesale Bank Standard Chartered Bank 7, Changi Business Park Cresent, Level 3. Singapore (486028) T : (65) 659 61395 | E adelwin.adelwin@ sc.com From: jug-indonesia@ yahoogroups. com [mailto: jug-indonesia@ yahoogroups. com ] On Behalf Of Hendry Luk Sent: Thursday, July 15, 2010 9:11 PM To: jug-indonesia@ yahoogroups. com Subject: Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya. - secure-random sih dah bagian standard library di most programming languages.. - dengan predictably random pun, berapa likely sih buat nebak 5 digit correctly dalam 2 kesempatan? Chancenya dwarfs the risk.. mengingat kebanyakan personal saving accounts by-default cuma dikasih transfer limit $3k per hari. - Kalopun lu bisa nebak tuh 5 digit dengan 100% accuracy (e.g. sniff sms packet), u'll find it hampir mustahil buat exploit tuh account tanpa expose identity lu. IP lu kan ditrack, dan lagian lu bakal transfer tuh duit ke rekening siapa? Makanya biasanya kita kan gak butuh masukin sms code lagi kalo ngirim ke rekening yang dah pernah kita kirim sebelomnya kalo cuma $1k or less. Jadi gak ngerepotin tiap mo transaksi mesti masukin token-code lagi kalo toh rekening tujuannya dah kita kenal (Kalo tuh orang malingin lu, gampang ketangkep). Kalo lu jadi maling sih daripada ngebobol bank account, lebih banyak bigger fish yg bisa lu tangkep dengan significantly less effort. Credit-card hampir gak ada security apapun. Semua call-center agents yang lu bacain nomer credit-card lewat telpon, mereka langsung posses all the required info buat ambil duit lu (gak ada one-time password). Hampir semua IT staff yg kerja most online retail shop bisa dengan gampang baca semua credit-card information di sistem mereka. Tapi tetep ajah gak gampang buat spend tuh duit. Semua online merchant gak memungkinan pelanggannya buat beli apapun tanpa somehow expose identitas pembeli (e.g. delivery address). Jadi gw sih gak terlalu liat manfaatnya otp device yg dipersenjatai dengan brightest algorithms.. . Coding cupu dengan random-number + sms ajah dah reasonably unbreakable buat kebanyakan personal banking, yang buat gw seems to be solusi yg lebih logical dari sisi development cost maupun customer's convenience. Gw gak pernah demen (so called) mobile banking yg mesti nenteng2 otp device kemana2. Keybca gw pernah ngaco, dan rek gw jadi dilock pas gw lagi overseas, dan shockingly, menurut call-centernya, there was absolutely nothing anyone could do about it, not even high-ranking officers mereka! Unbelievable. Untungnya itu bukan pot duit utama gw, otherwise situasi gw bakalan dah 100% f'd up, mesti cari jembatan yg kolongnya hanget. Dan anyway, yg rugi dari security breach toh bukan customers ato merchants, melainkan banknya sendiri.. Most banks kan ngasih 100% garansi against fraud. 2010/7/15 Monang Setyawan mon...@gmail. com I don't believe that any thug can write
Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
Mungkin gw phrased it dengan jelek... Gw gak maksud nge-ditch otp. Maksud gw, sms authentication sebenernya gak as vulnerable as it sounds... Cuma gara2 bca pake otp device jadi ada tendency semua nasabah langsung nganggap semua banking mesti pake otp, alternative laen gak secure. Padahal it probably doesnt matter that much.. sms dah diconsider acceptably secure, dan most banks emang cuma pake itu, gak pake sophisticated device macem2. Otp biasanya cuma nongol di business banking. On Fri, Jul 16, 2010 at 12:13 PM, Adelwin, Adelwin adelwin.adel...@sc.comwrote: Jadi gw sih gak terlalu liat manfaatnya otp device yg dipersenjatai dengan brightest algorithms... Coding cupu dengan random-number + sms ajah dah reasonably unbreakable buat kebanyakan personal banking, yang buat gw seems to be solusi yg lebih logical dari sisi development cost maupun customer's convenience. Well… luckily they don’t think so… Otherwise.. I’d soon be out of job… Hahahhaha Namanya juga di bank… Innovation is waaa down the list… Security is of the utmost importance… Mau dobel2… mau redundant… mau most of the times useless… tetep pasti ada… Buat mereka rule 80-20 ituh gak ngaruh… Die apply 20% of the security that they “could have” placed to serve 80% of their customer… They just don’t work like that… Mereka akan coba push sebisa mungkin… at all cost(I’d know)… supaya bisa sedekat mungkin sama 100%... Bagi lu mungkin aahh gak penting lah ginian… 90% of the time juga pasti secure lah… Lagian sapa mau ambil duit gue… Duit gue mah itungan nya receh buat konglomerat gitu… Tapi konglomerat juga nabung disono… Mereka harus protect duit die… and yours along with it… 10% off chance bahwa itu akan “gak” secure… well they just cant live with that… Don’t be so quick to dismiss things… Ini kerjaan gue inih… Gue cari makan dari sini… Banking… I would know… *Adelwin Handoyo** | Senior Consultant - Wholesale Bank* *Standard Chartered Bank* 7, Changi Business Park Cresent, Level 3. Singapore (486028) *T* : (65) 659 61395 |* **E* adelwin.adel...@sc.com -- *From:* jug-indonesia@yahoogroups.com [mailto: jug-indone...@yahoogroups.com] *On Behalf Of *Hendry Luk *Sent:* Thursday, July 15, 2010 9:11 PM *To:* jug-indonesia@yahoogroups.com *Subject:* Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya. - secure-random sih dah bagian standard library di most programming languages.. - dengan predictably random pun, berapa likely sih buat nebak 5 digit correctly dalam 2 kesempatan? Chancenya dwarfs the risk.. mengingat kebanyakan personal saving accounts by-default cuma dikasih transfer limit $3k per hari. - Kalopun lu bisa nebak tuh 5 digit dengan 100% accuracy (e.g. sniff sms packet), u'll find it hampir mustahil buat exploit tuh account tanpa expose identity lu. IP lu kan ditrack, dan lagian lu bakal transfer tuh duit ke rekening siapa? Makanya biasanya kita kan gak butuh masukin sms code lagi kalo ngirim ke rekening yang dah pernah kita kirim sebelomnya kalo cuma $1k or less. Jadi gak ngerepotin tiap mo transaksi mesti masukin token-code lagi kalo toh rekening tujuannya dah kita kenal (Kalo tuh orang malingin lu, gampang ketangkep). Kalo lu jadi maling sih daripada ngebobol bank account, lebih banyak bigger fish yg bisa lu tangkep dengan significantly less effort. Credit-card hampir gak ada security apapun. Semua call-center agents yang lu bacain nomer credit-card lewat telpon, mereka langsung posses all the required info buat ambil duit lu (gak ada one-time password). Hampir semua IT staff yg kerja most online retail shop bisa dengan gampang baca semua credit-card information di sistem mereka. Tapi tetep ajah gak gampang buat spend tuh duit. Semua online merchant gak memungkinan pelanggannya buat beli apapun tanpa somehow expose identitas pembeli (e.g. delivery address). Jadi gw sih gak terlalu liat manfaatnya otp device yg dipersenjatai dengan brightest algorithms... Coding cupu dengan random-number + sms ajah dah reasonably unbreakable buat kebanyakan personal banking, yang buat gw seems to be solusi yg lebih logical dari sisi development cost maupun customer's convenience. Gw gak pernah demen (so called) mobile banking yg mesti nenteng2 otp device kemana2. Keybca gw pernah ngaco, dan rek gw jadi dilock pas gw lagi overseas, dan shockingly, menurut call-centernya, there was *absolutely nothing* anyone could do about it, not even high-ranking officers mereka! Unbelievable. Untungnya itu bukan pot duit utama gw, otherwise situasi gw bakalan dah 100% f'd up, mesti cari jembatan yg kolongnya hanget. Dan anyway, yg rugi dari security breach toh bukan customers ato merchants, melainkan banknya sendiri.. Most banks kan ngasih 100% garansi against fraud. 2010/7/15 Monang Setyawan mon...@gmail.com I don't believe that any thug can write cryptographically secure PRNG. 2010/7/13
Re: Bls: [JUG-Indonesia] Release From Code to Exe
kenapa gak dijadiin jar saja?? untuk memudahkan user buat aja installer pake advance installer atau izpack, atau di akalin bikin .bat yang manggil jar itu, terus .bat nya di jadiin exe, tapi tetep nanti dia execute jarnya... cmiiw setelah saya baca2, ternyata memang untuk menjadikan code java ke exe, harus dijadiin jar dulu, permasalahan selanjutnya bagaimana cara export jar dengan manifest file (agar libarary external yang digunakan tidak ikut di paketkan, sehingga ukuran jar ga terlalu gede) ada masukan ga? soalnya masih belum begitu ngerti nih
Re: [JUG-Indonesia] Re: RESIZE IMAGE,,HELP URGENT
2010/7/15 Endiaz Ludia Arsanto arsantod...@gmail.com 2010/7/15 dita dita_...@yahoo.de iya textboxnya ga di Canvas tapi di class lain,,,jadi gimana ?hehe lya yg ini ya? --- In jug-indonesia@yahoogroups.com jug-indonesia%40yahoogroups.com, Mirza Akhena mirken...@... wrote: tapi itu bakal ditangkep di canvas ..emang bisa ya?gmana caranya:d ya bisa2 aja. btw, udah bisa nampilin text ke Canvas kan? ada banyak cara. salah satunya yang paling simple, ya simpen aj hasil getString ke temporary variable, setelah Canvas di display-in ambil lagi deh.. :p ato bisa juga ketika di TextBox, saat Command (misalnya) submit ditekan, ya kayak ginilah kira2 manggil Canvasnya //ceritanya ni didalam TextBox Display.getDisplay(themidlet).setCurrent(new MyCanvas(textbox.getString())); tapi ini perlu bikin Constructor di class Canvas yang nerima String lagi. ohya just wanna make sure, udah tahu kan kalo TextBox gak bisa ditampilin dalam Canvas?
Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
Actually... Banking disini sih semua pake token... Cuma di jkt ajah yang aneh kenapa BCA doang yang implement... Adelwin Handoyo - adel...@gmail.com - Sent from my Mac From: Hendry Luk hendrym...@gmail.com Reply-To: JUG-Indonesia jug-indonesia@yahoogroups.com Date: Fri, 16 Jul 2010 14:05:27 +1000 To: JUG-Indonesia jug-indonesia@yahoogroups.com Subject: Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya. Mungkin gw phrased it dengan jelek... Gw gak maksud nge-ditch otp. Maksud gw, sms authentication sebenernya gak as vulnerable as it sounds... Cuma gara2 bca pake otp device jadi ada tendency semua nasabah langsung nganggap semua banking mesti pake otp, alternative laen gak secure. Padahal it probably doesnt matter that much.. sms dah diconsider acceptably secure, dan most banks emang cuma pake itu, gak pake sophisticated device macem2. Otp biasanya cuma nongol di business banking. On Fri, Jul 16, 2010 at 12:13 PM, Adelwin, Adelwin adelwin.adel...@sc.com wrote: Jadi gw sih gak terlalu liat manfaatnya otp device yg dipersenjatai dengan brightest algorithms... Coding cupu dengan random-number + sms ajah dah reasonably unbreakable buat kebanyakan personal banking, yang buat gw seems to be solusi yg lebih logical dari sisi development cost maupun customer's convenience. Well luckily they don¹t think so Otherwise.. I¹d soon be out of job Hahahhaha Namanya juga di bank Innovation is waaa down the list Security is of the utmost importance Mau dobel2 mau redundant mau most of the times useless tetep pasti ada Buat mereka rule 80-20 ituh gak ngaruh Die apply 20% of the security that they ³could have² placed to serve 80% of their customer They just don¹t work like that Mereka akan coba push sebisa mungkin at all cost(I¹d know) supaya bisa sedekat mungkin sama 100%... Bagi lu mungkin aahh gak penting lah ginian 90% of the time juga pasti secure lah Lagian sapa mau ambil duit gue Duit gue mah itungan nya receh buat konglomerat gitu Tapi konglomerat juga nabung disono Mereka harus protect duit die and yours along with it 10% off chance bahwa itu akan ³gak² secure well they just cant live with that Don¹t be so quick to dismiss things Ini kerjaan gue inih Gue cari makan dari sini Banking I would know Adelwin Handoyo | Senior Consultant - Wholesale Bank Standard Chartered Bank 7, Changi Business Park Cresent, Level 3. Singapore (486028) T : (65) 659 61395 | e adelwin.adel...@sc.com From: jug-indonesia@yahoogroups.com [mailto:jug-indone...@yahoogroups.com] On Behalf Of Hendry Luk Sent: Thursday, July 15, 2010 9:11 PM To: jug-indonesia@yahoogroups.com Subject: Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya. - secure-random sih dah bagian standard library di most programming languages.. - dengan predictably random pun, berapa likely sih buat nebak 5 digit correctly dalam 2 kesempatan? Chancenya dwarfs the risk.. mengingat kebanyakan personal saving accounts by-default cuma dikasih transfer limit $3k per hari. - Kalopun lu bisa nebak tuh 5 digit dengan 100% accuracy (e.g. sniff sms packet), u'll find it hampir mustahil buat exploit tuh account tanpa expose identity lu. IP lu kan ditrack, dan lagian lu bakal transfer tuh duit ke rekening siapa? Makanya biasanya kita kan gak butuh masukin sms code lagi kalo ngirim ke rekening yang dah pernah kita kirim sebelomnya kalo cuma $1k or less. Jadi gak ngerepotin tiap mo transaksi mesti masukin token-code lagi kalo toh rekening tujuannya dah kita kenal (Kalo tuh orang malingin lu, gampang ketangkep). Kalo lu jadi maling sih daripada ngebobol bank account, lebih banyak bigger fish yg bisa lu tangkep dengan significantly less effort. Credit-card hampir gak ada security apapun. Semua call-center agents yang lu bacain nomer credit-card lewat telpon, mereka langsung posses all the required info buat ambil duit lu (gak ada one-time password). Hampir semua IT staff yg kerja most online retail shop bisa dengan gampang baca semua credit-card information di sistem mereka. Tapi tetep ajah gak gampang buat spend tuh duit. Semua online merchant gak memungkinan pelanggannya buat beli apapun tanpa somehow expose identitas pembeli (e.g. delivery address). Jadi gw sih gak terlalu liat manfaatnya otp device yg dipersenjatai dengan brightest algorithms... Coding cupu dengan random-number + sms ajah dah reasonably unbreakable buat kebanyakan personal banking, yang buat gw seems to be solusi yg lebih logical dari sisi development cost maupun customer's convenience. Gw gak pernah demen (so called) mobile banking yg mesti nenteng2 otp device kemana2. Keybca gw pernah ngaco, dan rek gw jadi dilock pas gw lagi overseas, dan shockingly, menurut call-centernya, there was absolutely nothing anyone could do about it, not even high-ranking officers mereka! Unbelievable. Untungnya itu bukan pot duit utama gw,
Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
Actually... Banking disini sih semua pake token... Cuma di jkt ajah yang aneh kenapa BCA doang yang implement... Perlu diluruskan nih win, semua banking di jakarta sepertinya pake token, kecuali BRI. -- regards
Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
Mandiri pake ah perasaan... 2010/7/17 Ifnu bima ifnub...@gmail.com Actually... Banking disini sih semua pake token... Cuma di jkt ajah yang aneh kenapa BCA doang yang implement... Perlu diluruskan nih win, semua banking di jakarta sepertinya pake token, kecuali BRI. -- regards -- Petra Novandi Barus, ST Magister Program of Computer Science School of Electrical Engineering and Informatics Institut Teknologi Bandung http://petrabarus.net
[JUG-Indonesia] [ask] manajemen session di spring
sebelumnya saya mau mengembangkan web dengan teknologi spring mvc + satu program di sisi server yang senantiasa membaca database. Alur kerjanya seperti ini. 1. ada program di server yang senantiasa membaca database, jika ada data yang masuk(penambahan data di lakukan lewat web) maka program tersebut akan memproses data tersebut. 2. aplikasi web, yang telah mengirim data senantiasa menunggu response dari server. dimana respone dari server ada 3 secara berturut2, yaitu submit_success, process, result. jika telah mendapatkan response result maka aplikasi web telah selesai menuggunya. yang mau saya tanyakan, gimana caranya agar spring mvc saya dapat menyimpan session, lalu jika tahap process telah selesai di lakukan oleh program server, maka spring tersebut dapat menggunakan kembali session tersebut untuk mengembalikannya ke client. mohon, petunjukkan, jika bisa code simplenya. udah google tapi belom dapat2 juga. Terima kasih dan minta maaf jika ada kata-kata yang kurang sopan.
Re: [JUG-Indonesia] [ask] manajemen session di spring
hendry_agi wrote: sebelumnya saya mau mengembangkan web dengan teknologi spring mvc + satu program di sisi server yang senantiasa membaca database. Alur kerjanya seperti ini. 1. ada program di server yang senantiasa membaca database, jika ada data yang masuk(penambahan data di lakukan lewat web) maka program tersebut akan memproses data tersebut. 2. aplikasi web, yang telah mengirim data senantiasa menunggu response dari server. dimana respone dari server ada 3 secara berturut2, yaitu submit_success, process, result. jika telah mendapatkan response result maka aplikasi web telah selesai menuggunya. yang mau saya tanyakan, gimana caranya agar spring mvc saya dapat menyimpan session, lalu jika tahap process telah selesai di lakukan oleh program server, maka spring tersebut dapat menggunakan kembali session tersebut untuk mengembalikannya ke client. Seingat saya pakai scope di controllernya. -- Salam/Regards, Thomas Edwin Santosa
Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
Terakhir bank niaga blm pake token tuh, entah skrg. Kalau di sini (Aussie), semua bank pakenya sms, gak ada yang pake token. -Kurniady 2010/7/17 Ifnu bima ifnub...@gmail.com Actually... Banking disini sih semua pake token... Cuma di jkt ajah yang aneh kenapa BCA doang yang implement... Perlu diluruskan nih win, semua banking di jakarta sepertinya pake token, kecuali BRI. -- regards
Re: [JUG-Indonesia] Tentang boolean OR operator
Sedikit menambahkan.
Dulu ketika saya belajar tentang operator, ada operator ( || ) dan ada ( |
). Dua-duanya sama2 berarti OR
operator yang pertama ( || ) , cek di kedua kondisi. Misal
If ( *kondisi_1* || *kondisi_2* ) {} -- jika kondisi pertama sudah
diketahui bener, java TETAP mengecek kondisi kedua. Padahal secara logika
sudah tidak perlu.
Beda jika saya menggunakan :
If ( *kondisi_1* |*kondisi_2* ) {} -- Jika kondisi pertama sudah
diketahui bener, java TIDAK perlu ngecek kondisi kedua.
Seingat saya demikian. Maaf kalau nda nyambung.
CMIIW.
2010/7/15 Mirza Akhena mirken...@gmail.com
owh.. kalo dari Java-nya ud jamin bacanya dari kiri ke kanan berarti
problem solve, yang methodKedua juga aman .. :)
_
2010/7/15 Andrian Kurniady andr...@kurniady.net
Java spec menjamin expression dievaluate kiri ke kanan.
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html
Menurut saya sih lebih readable yang kedua, yang pertama bacanya mumet :-P
-Kurniady
2010/7/15 Mirza Akhena mirken...@gmail.com
Saya punya kasus begini,
ada dua method yaitu *methodPertama* dan *methodKedua* yang melakukan
hal yang sama:
public void methodPertama(String property){
if (null != values) {
if (!values.containsKey(property)) {
getData(property);
}
} else {
getData(property);
}
}
public void methodKedua(String property){
if (null == values || !values.containsKey(property)) {
getData(property);
}
}
pertanyaan saya :
*mana yang lebih baik? methodPertama atau methodKedua?*
Saya udah coba kedua2nya dan fine2 saja sih,
hanya saja kalo saya pribadi sih, kayaknya lebih aman methodPertama.
Alasannya pada methodKedua, saya cenderung merasa gak safe karena kita
tahu (a || b) == (b || a)
kalo kita punya x || y saya gak tahu mana duluan yang dieksekusi, x atau
y ? JVM ngaruh gak ya?
values == null || !values.containsKey(property)
samakah dengan
!values.containsKey(property) || values == null
?
ketika kita sampai pada
values == null || !values.containsKey(property)
kalo values memang bernilai null dan values.containsKey(property) duluan
dieksekusi takutnya malah NullPointerException (Bener kah dugaan saya ini ?)
tapi kalo values == null yang duluan dieksekusi DAN kita tahu ada
operator OR disana, maka ya aman2 aja (bener gak ya?)
pendapat temen2 JUG gimana? pernah kepikiran begini juga gak? ato mgk
malah ada solusi yang lebih baik?
Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
berarti jarpul [jarang pulang] :D 2010/7/17 Ifnu bima ifnub...@gmail.com Actually... Banking disini sih semua pake token... Cuma di jkt ajah yang aneh kenapa BCA doang yang implement... Perlu diluruskan nih win, semua banking di jakarta sepertinya pake token, kecuali BRI. -- regards -- http://wempi.nokspi.com
Re: [JUG-Indonesia] [ask] manajemen session di spring
Ini koq kayaknya kamu mau buat RPC dari aplikasi web ke program server via database... arsitekturnya agak aneh. Kenapa nggak dibikin aplikasi webnya panggil RPC ke program server langsung, trus program server yang menulis data ke database sekalian proses datanya? Kalau prosesnya lama, RPCnya dibuat async dan dari aplikasi web ke browser bisa pakai teknik server-to-client-push seperti comet atau websocket. -Kurniady 2010/7/17 hendry_agi hendry_...@yahoo.com sebelumnya saya mau mengembangkan web dengan teknologi spring mvc + satu program di sisi server yang senantiasa membaca database. Alur kerjanya seperti ini. 1. ada program di server yang senantiasa membaca database, jika ada data yang masuk(penambahan data di lakukan lewat web) maka program tersebut akan memproses data tersebut. 2. aplikasi web, yang telah mengirim data senantiasa menunggu response dari server. dimana respone dari server ada 3 secara berturut2, yaitu submit_success, process, result. jika telah mendapatkan response result maka aplikasi web telah selesai menuggunya. yang mau saya tanyakan, gimana caranya agar spring mvc saya dapat menyimpan session, lalu jika tahap process telah selesai di lakukan oleh program server, maka spring tersebut dapat menggunakan kembali session tersebut untuk mengembalikannya ke client. mohon, petunjukkan, jika bisa code simplenya. udah google tapi belom dapat2 juga. Terima kasih dan minta maaf jika ada kata-kata yang kurang sopan.
Re: [JUG-Indonesia] Tentang boolean OR operator
Salah, pernyataan anda terbalik :-D
|| itu OR with short-circuit, kalau kiri true, kanan gak dicek.
| itu OR without short-circuit, kiri kanan tetap dicek.
Sama juga dengan (short-circuit AND) dan (non-short-circuit AND).
-Kurniady
2010/7/17 andhik cahyono andhikb...@gmail.com
Sedikit menambahkan.
Dulu ketika saya belajar tentang operator, ada operator ( || ) dan ada ( |
). Dua-duanya sama2 berarti OR
operator yang pertama ( || ) , cek di kedua kondisi. Misal
If ( *kondisi_1* || *kondisi_2* ) {} -- jika kondisi pertama sudah
diketahui bener, java TETAP mengecek kondisi kedua. Padahal secara logika
sudah tidak perlu.
Beda jika saya menggunakan :
If ( *kondisi_1* |*kondisi_2* ) {} -- Jika kondisi pertama sudah
diketahui bener, java TIDAK perlu ngecek kondisi kedua.
Seingat saya demikian. Maaf kalau nda nyambung.
CMIIW.
2010/7/15 Mirza Akhena mirken...@gmail.com
owh.. kalo dari Java-nya ud jamin bacanya dari kiri ke kanan berarti
problem solve, yang methodKedua juga aman .. :)
_
2010/7/15 Andrian Kurniady andr...@kurniady.net
Java spec menjamin expression dievaluate kiri ke kanan.
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html
Menurut saya sih lebih readable yang kedua, yang pertama bacanya mumet
:-P
-Kurniady
2010/7/15 Mirza Akhena mirken...@gmail.com
Saya punya kasus begini,
ada dua method yaitu *methodPertama* dan *methodKedua* yang melakukan
hal yang sama:
public void methodPertama(String property){
if (null != values) {
if (!values.containsKey(property)) {
getData(property);
}
} else {
getData(property);
}
}
public void methodKedua(String property){
if (null == values || !values.containsKey(property)) {
getData(property);
}
}
pertanyaan saya :
*mana yang lebih baik? methodPertama atau methodKedua?*
Saya udah coba kedua2nya dan fine2 saja sih,
hanya saja kalo saya pribadi sih, kayaknya lebih aman methodPertama.
Alasannya pada methodKedua, saya cenderung merasa gak safe karena kita
tahu (a || b) == (b || a)
kalo kita punya x || y saya gak tahu mana duluan yang dieksekusi, x atau
y ? JVM ngaruh gak ya?
values == null || !values.containsKey(property)
samakah dengan
!values.containsKey(property) || values == null
?
ketika kita sampai pada
values == null || !values.containsKey(property)
kalo values memang bernilai null dan values.containsKey(property)duluan
dieksekusi takutnya malah NullPointerException (Bener kah dugaan saya
ini ?)
tapi kalo values == null yang duluan dieksekusi DAN kita tahu ada
operator OR disana, maka ya aman2 aja (bener gak ya?)
pendapat temen2 JUG gimana? pernah kepikiran begini juga gak? ato mgk
malah ada solusi yang lebih baik?
RE: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....
Hah?? Mandiri segala gitu udah pake yah? Waahh.. g ketinggalan dah :p Adelwin Handoyo | Senior Consultant - Wholesale Bank Standard Chartered Bank 7, Changi Business Park Cresent, Level 3. Singapore (486028) T : (65) 659 61395 | E adelwin.adel...@sc.com From: jug-indonesia@yahoogroups.com [mailto:jug-indone...@yahoogroups.com] On Behalf Of Ifnu bima Sent: Saturday, July 17, 2010 8:00 AM To: jug-indonesia@yahoogroups.com Subject: Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya. Actually... Banking disini sih semua pake token... Cuma di jkt ajah yang aneh kenapa BCA doang yang implement... Perlu diluruskan nih win, semua banking di jakarta sepertinya pake token, kecuali BRI. -- regards This email and any attachments are confidential and may also be privileged. If you are not the addressee, do not disclose, copy, circulate or in any other way use or rely on the information contained in this email or any attachments. If received in error, notify the sender immediately and delete this email and any attachments from your system. Emails cannot be guaranteed to be secure or error free as the message and any attachments could be intercepted, corrupted, lost, delayed, incomplete or amended. Standard Chartered PLC and its subsidiaries do not accept liability for damage caused by this email or any attachments and may monitor email traffic. Standard Chartered PLC is incorporated in England with limited liability under company number 966425 and has its registered office at 1 Aldermanbury Square, London, EC2V 7SB. Standard Chartered Bank (SCB) is incorporated in England with limited liability by Royal Charter 1853, under reference ZC18. The Principal Office of SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In the United Kingdom, SCB is authorised and regulated by the Financial Services Authority under FSA register number 114276. If you are receiving this email from SCB outside the UK, please click http://www.standardchartered.com/global/email_disclaimer.html to refer to the information on other jurisdictions.
