RE: [JUG-Indonesia] Transaction Locking

[Adelwin, Adelwin]

Well.. sorry...

Kalo server.. bentuk nya Cuma laptop... that's just silly...

Soal account posting... ini harus dari posisi yang centralized...

Either ada 1 mesin yang proses ini... ato di taro dalem database nya
sendiri...

Database nya apa toh?

Kalo oracle... more than sufficient sih...

Bisa pake oracle scheduler... ato trigger... buat jalanin ini event...

Dan logic nya taro di PL/Sql

Ato pake java stored proc...

 

Tapi sebenernya ada metoda satu lagi yang mayan ribet tapi rapih...

EJB :P

Hahahahha

Bikin server pendamping buat DB nya...

Jadi EJB server...

Semua app client nya bakal call EJB nya.. :p

Dengan gini... semua mechanism nya JEE bisa di pake...

Mau pake worker gitu juga bisa...

Hehehhee

 

 

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 Andre Prasetya
Sent: Friday, July 16, 2010 1:00 PM
To: jug-indonesia@yahoogroups.com
Subject: Re: [JUG-Indonesia] Transaction Locking

 



Terima kasih pak Endy, pak Alpha dan pak Adelwin untuk masukannya,

Selain summary, ada juga proses serupa yang perlu saya buat, jadi
aplikasi nya ada berhubungan dengan akuntansi juga, untuk setiap hutang,
cicilannya kalau sudah jatuh tempo perlu diposting ke akun yang
bersangkutan (asumsi bunga fixed dan tercatat di tabel hutangnya).
Selain
membuat agent yang berjalan di belakang untuk melakukan hal ini, apa ada
solusi lain semisal scope aplikasinya dibatasi hanya di desktop
dan di server hanya ada database saja ?

adapun permintaan untuk di server hanya isi database saja itu karena
aplikasinya akan ada personal edition yang hanya running di 1 laptop
saja
dan ada standard edition yang running multi client - server dan hanya
dibedakan berdasarkan serial number.

2010/7/15 Endy Muhardin 

2010/7/15 Andre Prasetya 
>
>
>

> Kalau yang biasa saya lakukan di CP itu ada agent yang berjalan setiap
malam, membuat summary, dihitung brapa jumlah yang register hari ini,
jumlah member berjalan, jumlah member yang off dan distore jadi 1 record
per hari.
>
> Nah kalau saya melakukan hal yang mirip tapi deployment nya aplikasi
desktop, kl pengguna A tekan tombol summary lalu sblm proses slesai, B
juga menekan khan bisa berakibat double record (apalagi saya pakai Id
AutoGenerate)
>
> Saat ini baru kepikir buat pake 1 tabel lock, jadi fungsi yang krusial
sblm dilakukan, akan dilock dan sesudah slesai akan dilepas lock nya.
Barangkali ada solusi yang lebih pas...
>



Ooo .. memang harus dikasi flag biar gak tumpukan.
Kalo saya biasanya bikin tabel background_process.
Dari UI, cukup nginsert aja ke tabel itu untuk request jalankan summary.
Nanti di server ada background process yang ngecek tabel itu.
Kalo ada record yang statusnya new, ganti jadi running, kemudian
jalankan proses summary.
Setelah selesai, ganti lagi statusnya jadi success/error.

Kalo ada user lain yang klik tombol proses, tinggal dilihat ke tabel,
apa ada proses sejenis yang sedang running atau sudah selesai.
Kalau ada, tinggal popup message, proses sedang berjalan, atau proses
sudah pernah dijalankan.



--
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --






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






-- 
-Andre-
http://rafunkel.blogspot.com









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 n

Re: [JUG-Indonesia] Transaction Locking

[Andre Prasetya]

Terima kasih pak Endy, pak Alpha dan pak Adelwin untuk masukannya,

Selain summary, ada juga proses serupa yang perlu saya buat, jadi aplikasi
nya ada berhubungan dengan akuntansi juga, untuk setiap hutang,
cicilannya kalau sudah jatuh tempo perlu diposting ke akun yang bersangkutan
(asumsi bunga fixed dan tercatat di tabel hutangnya). Selain
membuat agent yang berjalan di belakang untuk melakukan hal ini, apa ada
solusi lain semisal scope aplikasinya dibatasi hanya di desktop
dan di server hanya ada database saja ?

adapun permintaan untuk di server hanya isi database saja itu karena
aplikasinya akan ada personal edition yang hanya running di 1 laptop saja
dan ada standard edition yang running multi client - server dan hanya
dibedakan berdasarkan serial number.

2010/7/15 Endy Muhardin 

> 2010/7/15 Andre Prasetya 
> >
> >
> >
> > Kalau yang biasa saya lakukan di CP itu ada agent yang berjalan setiap
> malam, membuat summary, dihitung brapa jumlah yang register hari ini, jumlah
> member berjalan, jumlah member yang off dan distore jadi 1 record per hari.
> >
> > Nah kalau saya melakukan hal yang mirip tapi deployment nya aplikasi
> desktop, kl pengguna A tekan tombol summary lalu sblm proses slesai, B juga
> menekan khan bisa berakibat double record (apalagi saya pakai Id
> AutoGenerate)
> >
> > Saat ini baru kepikir buat pake 1 tabel lock, jadi fungsi yang krusial
> sblm dilakukan, akan dilock dan sesudah slesai akan dilepas lock nya.
> Barangkali ada solusi yang lebih pas...
> >
>
>
> Ooo .. memang harus dikasi flag biar gak tumpukan.
> Kalo saya biasanya bikin tabel background_process.
> Dari UI, cukup nginsert aja ke tabel itu untuk request jalankan summary.
> Nanti di server ada background process yang ngecek tabel itu.
> Kalo ada record yang statusnya new, ganti jadi running, kemudian
> jalankan proses summary.
> Setelah selesai, ganti lagi statusnya jadi success/error.
>
> Kalo ada user lain yang klik tombol proses, tinggal dilihat ke tabel,
> apa ada proses sejenis yang sedang running atau sudah selesai.
> Kalau ada, tinggal popup message, proses sedang berjalan, atau proses
> sudah pernah dijalankan.
>
>
> --
> Endy Muhardin
> http://endy.artivisi.com
> Y! : endymuhardin
> -- life learn contribute --
>
>
> 
>
> 
> 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
>
>
>
>


-- 
-Andre-
http://rafunkel.blogspot.com

Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....

[Samuel Franklyn]

On 7/16/2010 10:49 AM, Endy Muhardin wrote:
> On Fri, Jul 16, 2010 at 9:13 AM, Adelwin, Adelwin
>   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

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/jug-indonesia/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/jug-indonesia/join
(Yahoo! ID required)

<*> To change settings via email:
jug-indonesia-dig...@yahoogroups.com 
jug-indonesia-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
jug-indonesia-unsubscr...@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....

[Endy Muhardin]

On Fri, Jul 16, 2010 at 9:13 AM, Adelwin, Adelwin
 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.

Lalu gimana dengan solusi random thugs?
Yah kalo koperasi simpan pinjam mungkin mau.
Tapi kalo bank besar, ya coba aja ditawarin.


--
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --





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

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/jug-indonesia/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/jug-indonesia/join
(Yahoo! ID required)

<*> To change settings via email:
jug-indonesia-dig...@yahoogroups.com 
jug-indonesia-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
jug-indonesia-unsubscr...@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Re: [JUG-Indonesia] [ask]Konsep memonitoring mail server dengan javamail

[Abdul Arfan]

atau bisa juga javamail nya melakukan monitoring dengan cara melakukan test
pengiriman email secara berkala ke mail server. kalo email sampe makan
mail servernya masih ok, dan begitu juga sebaliknya.

2010/7/16 Wiyanto Ngasinur 

>
>
> javamail kaga bisa buat monitor mailserver, kalo mo monitor mailserver mah
> biasanya uda tersedia built-in tool/aplikasi di mailserver itu sendiri.
> javamail itu sendiri cuma nyediain API buat send/receive email di java.
>
> thanks,
> W
>
> 2010/7/16 th3_wanto 
>
>
>>
>> Aplikasi bersifat desktop, Kira2 apa saja yang dibutuhkan untuk
>> memonitoring suatu email server (Dalam hubungannya dengan javamail). Mohon
>> pencerahan dari kaka2 sekalian. Secara konseptual akan sangat membantu.
>> trimakasih
>>
>>
>  
>



-- 
Abdul Arfan
http://arfan86.blogspot.com

RE: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....

[Adelwin, Adelwin]

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 mailto:mon...@gmail.com> >

  

I don't believe that any thug can write cryptographically secure PRNG.

 

2010/7/13 Hendry Luk mailto:hendrym...@gmail.com>
>

  

Boleh tau what the problem is?

2010/7/14 Monang Setyawan mailto:mon...@gmail.com> >

  

Bank mana yang salah satu developer internet bankingnya adalah "thug"
yang "nulis code buat generate 5 digit random number"? Saya pengin kasih
tahu teman/kerabat saya supaya tidak menjadi nasabah bank itu :)

2010/7/13 Hendry Luk mailto:hendrym...@gmail.com>
>

 

  

Ada teknologi baru... umumnya diapplikasikan pada perangkat
telpon genggam, dipopulerkan 2 dekade silam, dinamai
"short-message-service", ato SMS ;P

   

Re: [JUG-Indonesia] Tentang boolean OR operator

[Mirza Akhena]

owh.. kalo dari Java-nya ud jamin bacanya  dari kiri ke kanan berarti
problem solve, yang methodKedua juga aman .. :)

_
2010/7/15 Andrian Kurniady 

>
>
> 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 
>
>
>>
>> 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.....

[Hendry Luk]

- 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 

>
>
> I don't believe that any thug can write cryptographically secure PRNG.
>
>
> 2010/7/13 Hendry Luk 
>
>>
>>
>> Boleh tau what the problem is?
>>
>> 2010/7/14 Monang Setyawan 
>>
>>>
>>>
>>> Bank mana yang salah satu developer internet bankingnya adalah "thug"
>>> yang "nulis code buat generate 5 digit random number"? Saya pengin kasih
>>> tahu teman/kerabat saya supaya tidak menjadi nasabah bank itu :)
>>>
>>> 2010/7/13 Hendry Luk 
>>>
>>>

 Ada teknologi baru... umumnya diapplikasikan pada perangkat telpon
 genggam, dipopulerkan 2 dekade silam, dinamai "short-message-service", ato
 SMS ;P

 In fact, satu2nya bank yg gw pernah liat pake OTP cuma BCA doank. Bank
 laen semuanya plain humble SMS... secure, gak ngerepotin (btw orang2 para
 nenteng keybca kemana2 24 jem ya?), dan practical: any thug bisa nulis code
 buat generate 5 digit random number n kirim ke sms... gak perlu rocket
 scientists buat bikin algorithm super mutakhir that is otp.

 2010/7/13 Endy Muhardin 

>
>
> 2010/7/13 Fredi Tansari 
> 
> >
>
> >
> >
> >
> > hiihihi masih jaman ya pake otp gitu
> > btw gua mau arrange shipment nih utk smart card... ada yang interest
> gak?
>
> Trus kalo gak pakai OTP, apa ada teknologi yang lebih baru?
>
> --
> Endy Muhardin
> http://endy.artivisi.com
> Y! : endymuhardin
> -- life learn contribute --
>


>>>
>>>
>>> --
>>> "Don't worry about what anybody else is going to do. The best way to
>>> predict the future is to invent it." - Alan Kay
>>>
>>
>>
>
>
> --
> "Don't worry about what anybody else is going to do. The best way to
> predict the future is to invent it." - Alan Kay
>  
>

Re: [JUG-Indonesia] Tentang boolean OR operator

[Mirza Akhena]

maksudnya apa ya? saya masih tidak mengerti..
_
On Thu, Jul 15, 2010 at 9:43 PM, Saksomo Herwijaya <
saksomo.herwij...@gmail.com> wrote:

>
>
> >> public void methodPertama(String property){
> >>  if (null != values) {
> >>if (!values.containsKey(property)) {
> >>  getData(property);
> >>}
> >>  } else {
> >>getData(property);
> >>  }
> }
>
>
>  
>

RE: [JUG-Indonesia] Transaction Locking

[Adelwin, Adelwin]

Jadi 1 desktop app... ada di 2 tempat.. connect ke 1 DB...

Gitu kan scenario nye?

G ngerti masalah nya...

Kalo menurut gue...

Bener ituh pake composite key...

1 field nya ituh normal column that "would have been" a primary key
otherwise...

1 field nya lagi y user ID nyaa...

Say "Requestor_ID" gitu misal nya...

Udha pasti composite key nya pasti unique kan?

Tapi seharusnya sih hal ini nih tujuan awal nya oracle sequence kan?

In a way... die ituh enforce somekind of "synchronized" method gituh
supaya at any single given point in time... Cuma 1 yang di respond...
yang laen di queue...

G belom pernah liat case nya oracle sequence bisa fail sih.. :D

 

 

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 Endy Muhardin
Sent: Thursday, July 15, 2010 6:28 PM
To: jug-indonesia@yahoogroups.com
Subject: Re: [JUG-Indonesia] Transaction Locking

 

  

2010/7/15 Andre Prasetya mailto:andre.prasetya%40gmail.com> >
>
>
>
> Kalau yang biasa saya lakukan di CP itu ada agent yang berjalan setiap
malam, membuat summary, dihitung brapa jumlah yang register hari ini,
jumlah member berjalan, jumlah member yang off dan distore jadi 1 record
per hari.
>
> Nah kalau saya melakukan hal yang mirip tapi deployment nya aplikasi
desktop, kl pengguna A tekan tombol summary lalu sblm proses slesai, B
juga menekan khan bisa berakibat double record (apalagi saya pakai Id
AutoGenerate)
>
> Saat ini baru kepikir buat pake 1 tabel lock, jadi fungsi yang krusial
sblm dilakukan, akan dilock dan sesudah slesai akan dilepas lock nya.
Barangkali ada solusi yang lebih pas...
>

Ooo .. memang harus dikasi flag biar gak tumpukan.
Kalo saya biasanya bikin tabel background_process.
Dari UI, cukup nginsert aja ke tabel itu untuk request jalankan summary.
Nanti di server ada background process yang ngecek tabel itu.
Kalo ada record yang statusnya new, ganti jadi running, kemudian
jalankan proses summary.
Setelah selesai, ganti lagi statusnya jadi success/error.

Kalo ada user lain yang klik tombol proses, tinggal dilihat ke tabel,
apa ada proses sejenis yang sedang running atau sudah selesai.
Kalau ada, tinggal popup message, proses sedang berjalan, atau proses
sudah pernah dijalankan.

--
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --




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] Tentang boolean OR operator

[Adelwin, Adelwin]

Huahauhauhauhauauahuah

Maap.. I was thinking about AND...

Hahaha

Kalo A nya udah TRUE... B nya udah gak perlu di eval lagi...

Jadi tergantung si programmer sendiri gimana cara exploit ini short
circuit nya...

Liat mendingan pake AND ato OR...

Kalo OR bisa lebih besar probability kena short circuit... re-write ajah
expression nya...

Kan bisa di negate kan...

Yaahhh ngerti lah maksudnya...

Maap.. typo

wakakakak

 

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 Reza Lesmana
Sent: Friday, July 16, 2010 7:01 AM
To: jug-indonesia@yahoogroups.com
Subject: Re: [JUG-Indonesia] Tentang boolean OR operator

 

  

Hmmm A OR B ? Klo A false, B-nya harus dicek dong.

 

A OR B itu, klo A true, ga peduli hasil B, hasilnya pasti true.

 

Klo A AND B baru klo A false, gak peduli hasil B, hasilnya pasti false.

2010/7/16 Adelwin Handoyo mailto:adel...@gmail.com>
>

  

Bener ituh java menjamin di execute dari kiri ke kanan..
Bener juga lebih read-able method ke dua.. Dengan if tumpuk2an gituh
Step by step...
Tapi juga musti di perkirakan..
Short-circuit...
Hehehehehe
Coba kalo dita implementasikan ilmu tautology nya..
A OR B
Kalo A nya udah false.. Tanpa perduli nilai B.. Hasil nya pasti false
kan?
Ini dia..
Kalo pake if yang sebaris.. Dan yang suku pertama udah salah.. Die gak
akan coba eval suku kedua nya
Emang gak begitu ngaruh sih.. Tapi yah.. Ada edge nya lah dikit..
Gue sih prefer yang sbaris doang sih..
Udah kebiasaan.. Udah gak ngaruh baca nya..
Sama sama ajah sih kata gua..


Adelwin Handoyo
- adel...@gmail.com   -
Sent from my Mac





From: Mirza Akhena http://mirken...@gmail.com> >
Reply-To: JUG-Indonesia http://jug-indonesia@yahoogroups.com> >
Date: Thu, 15 Jul 2010 20:00:49 +0700
To: JUG-Indonesia http://jug-indonesia@yahoogroups.com> >
Subject: [JUG-Indonesia] Tentang boolean OR operator





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?


  



 




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] [ask]Konsep memonitoring mail server dengan javamail

[Wiyanto Ngasinur]

javamail kaga bisa buat monitor mailserver, kalo mo monitor mailserver mah
biasanya uda tersedia built-in tool/aplikasi di mailserver itu sendiri.
javamail itu sendiri cuma nyediain API buat send/receive email di java.

thanks,
W

2010/7/16 th3_wanto 

>
>
> Aplikasi bersifat desktop, Kira2 apa saja yang dibutuhkan untuk
> memonitoring suatu email server (Dalam hubungannya dengan javamail). Mohon
> pencerahan dari kaka2 sekalian. Secara konseptual akan sangat membantu.
> trimakasih
>
>  
>

Re: [JUG-Indonesia] Tentang boolean OR operator

[Reza Lesmana]

Hmmm A OR B ? Klo A false, B-nya harus dicek dong.

A OR B itu, klo A true, ga peduli hasil B, hasilnya pasti true.

Klo A AND B baru klo A false, gak peduli hasil B, hasilnya pasti false.

2010/7/16 Adelwin Handoyo 

>
>
> Bener ituh java menjamin di execute dari kiri ke kanan..
> Bener juga lebih read-able method ke dua.. Dengan if tumpuk2an gituh
> Step by step...
> Tapi juga musti di perkirakan..
> Short-circuit...
> Hehehehehe
> Coba kalo dita implementasikan ilmu tautology nya..
> A OR B
> Kalo A nya udah false.. Tanpa perduli nilai B.. Hasil nya pasti false kan?
> Ini dia..
> Kalo pake if yang sebaris.. Dan yang suku pertama udah salah.. Die gak akan
> coba eval suku kedua nya
> Emang gak begitu ngaruh sih.. Tapi yah.. Ada edge nya lah dikit..
> Gue sih prefer yang sbaris doang sih..
> Udah kebiasaan.. Udah gak ngaruh baca nya..
> Sama sama ajah sih kata gua..
>
> *
> Adelwin Handoyo
> *- adel...@gmail.com -
> Sent from my Mac
>
>
> --
> *From: *Mirza Akhena 
> *Reply-To: *JUG-Indonesia 
> *Date: *Thu, 15 Jul 2010 20:00:49 +0700
> *To: *JUG-Indonesia 
> *Subject: *[JUG-Indonesia] Tentang boolean OR operator
>
>
>
>
> 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] Tentang boolean OR operator

[Adelwin Handoyo]

Bener ituh java menjamin di execute dari kiri ke kanan..
Bener juga lebih read-able method ke dua.. Dengan if tumpuk2an gituh
Step by step...
Tapi juga musti di perkirakan..
Short-circuit...
Hehehehehe
Coba kalo dita implementasikan ilmu tautology nya..
A OR B
Kalo A nya udah false.. Tanpa perduli nilai B.. Hasil nya pasti false kan?
Ini dia..
Kalo pake if yang sebaris.. Dan yang suku pertama udah salah.. Die gak akan
coba eval suku kedua nya
Emang gak begitu ngaruh sih.. Tapi yah.. Ada edge nya lah dikit..
Gue sih prefer yang sbaris doang sih..
Udah kebiasaan.. Udah gak ngaruh baca nya..
Sama sama ajah sih kata gua..


Adelwin Handoyo
- adel...@gmail.com -
Sent from my Mac



From: Mirza Akhena 
Reply-To: JUG-Indonesia 
Date: Thu, 15 Jul 2010 20:00:49 +0700
To: JUG-Indonesia 
Subject: [JUG-Indonesia] Tentang boolean OR operator



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] Tentang boolean OR operator

[Edward Yakop]

Reply inline.

2010/7/16 Mirza Akhena 

> @Edward
>
> >> Initialized values, jadi nggak usah deal dengan null.
> iya sih, tapi kalo initialize nya dengan null ? [duh, ngotot bgt nih
> hehehe..]
>

Well, problem dengan tidak initialize itu di semua tempat dimana values
dipakek, kamu musti check
values != null, codenya jadi ugly.

Kalo musti initialize dengan null, check not null sebelum pakek values itu
udah keharusan.


>
> btw,
> Saya sendiri jadi mumet sama pertanyaan saya sendiri.. :p
> Seharusnya tadi pertanyaannya :
>
> kalo kita punya a || b , Apakah ada jaminan a duluan yang diperiksa
> kemudian (jika a false) baru b ?
>

Yup, dijamin.

Regards,
Edward Yakop

[JUG-Indonesia] [ask]Konsep memonitoring mail server dengan javamail

[th3_wanto]

Aplikasi bersifat desktop, Kira2 apa saja yang dibutuhkan untuk memonitoring 
suatu email server (Dalam hubungannya dengan javamail). Mohon pencerahan dari 
kaka2 sekalian. Secara konseptual akan sangat membantu. trimakasih

Re: [JUG-Indonesia] Tentang boolean OR operator

[Andrian Kurniady]

2010/7/16 Andrian Kurniady :
>
> 2010/7/16 Mirza Akhena 
>>
>>
>>
>> @Saksomo
>>
>> >>fine2 ?? coba cek method pertama, struktur nya sdh bener atau blun
>> maksudnya "strukturnya udah bener atau blum.." itu gimana ya?
>
> Kalau di constructor tulisnya gini
> constructorSaya(HashMap values) {
>   this.values = new HashMap();
>   this.values.addAll(values);

Maksudnya this.values = new HashMap(values);

> }
> maka tidak akan pernah null.

-Kurniady

Re: [JUG-Indonesia] Tentang boolean OR operator

[Andrian Kurniady]

2010/7/16 Mirza Akhena 

>
>
> @Saksomo
>
> >>fine2 ?? coba cek method pertama, struktur nya sdh bener atau blun
> maksudnya "strukturnya udah bener atau blum.." itu gimana ya?
>

Kalau di constructor tulisnya gini

constructorSaya(HashMap values) {
  this.values = new HashMap();
  this.values.addAll(values);
}

maka tidak akan pernah null.


> @Edward
>
> >> Initialized values, jadi nggak usah deal dengan null.
> iya sih, tapi kalo initialize nya dengan null ? [duh, ngotot bgt nih
> hehehe..]
>
> btw,
> Saya sendiri jadi mumet sama pertanyaan saya sendiri.. :p
> Seharusnya tadi pertanyaannya :
>
> kalo kita punya a || b , Apakah ada jaminan a duluan yang diperiksa
> kemudian (jika a false) baru b ?
>

Jadi sudah tau jawabannya? :-P

-Kurniady

Re: [JUG-Indonesia] Tentang boolean OR operator

[Saksomo Herwijaya]

>> public void methodPertama(String property){
>>  if (null != values) {
>>if (!values.containsKey(property)) {
>>  getData(property);
>>}
>>  } else {
>>getData(property);
>>  }
}

Re: [JUG-Indonesia] Tentang boolean OR operator

[Mirza Akhena]

@Saksomo
>>fine2 ?? coba cek method pertama, struktur nya sdh bener atau blun
maksudnya "strukturnya udah bener atau blum.." itu gimana ya?

@Edward
>> Initialized values, jadi nggak usah deal dengan null.
iya sih, tapi kalo initialize nya dengan null ? [duh, ngotot bgt nih
hehehe..]

btw,
Saya sendiri jadi mumet sama pertanyaan saya sendiri.. :p
Seharusnya tadi pertanyaannya :

kalo kita punya a || b , Apakah ada jaminan a duluan yang diperiksa kemudian
(jika a false) baru b ?

_
2010/7/15 Edward Yakop 

>
>
> 2010/7/15 Mirza Akhena 
>
>> pertanyaan saya :
>>
>>
>> *mana yang lebih baik?  methodPertama atau methodKedua?*
>>
> Kedua, tapi bukannya lebih baik buat initialized value field? Jadi nggak
> usah deal dengan null?
>
>
>> 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
>> ?
>>
> Yang kedua bakal throw NPE kalo values = null, jadi check yang dikanan
> values == null nggak ada artinya.
> Dan karena kita deal dengan operator or, kalo yang sebelah kiri udah true,
> nggak bakalan evaluate yang sebelah kanan.
> Ini lain dengan AND operator.
>
> 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 ?)
>>
> Betul.
>
>> tapi kalo values == null yang duluan dieksekusi DAN kita tahu ada
>> operator OR disana, maka ya aman2 aja (bener gak ya?)
>>
> Betul.
>
>
>> pendapat temen2 JUG gimana? pernah kepikiran begini juga gak? ato mgk
>> malah ada solusi yang lebih baik?
>>
> Initialized values, jadi nggak usah deal dengan null.
>
> Regards,
> Edward Yakop
>
>  
>

Re: [JUG-Indonesia] Tentang boolean OR operator

[Edward Yakop]

2010/7/15 Mirza Akhena 

> pertanyaan saya :
>
>
> *mana yang lebih baik?  methodPertama atau methodKedua?*
>
Kedua, tapi bukannya lebih baik buat initialized value field? Jadi nggak
usah deal dengan null?


> 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
> ?
>
Yang kedua bakal throw NPE kalo values = null, jadi check yang dikanan
values == null nggak ada artinya.
Dan karena kita deal dengan operator or, kalo yang sebelah kiri udah true,
nggak bakalan evaluate yang sebelah kanan.
Ini lain dengan AND operator.

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 ?)
>
Betul.

> tapi kalo values == null yang duluan dieksekusi DAN kita tahu ada operator
> OR disana, maka ya aman2 aja (bener gak ya?)
>
Betul.


> pendapat temen2 JUG gimana? pernah kepikiran begini juga gak? ato mgk malah
> ada solusi yang lebih baik?
>
Initialized values, jadi nggak usah deal dengan null.

Regards,
Edward Yakop

Re: [JUG-Indonesia] Tentang boolean OR operator

[Saksomo Herwijaya]

2010/7/15 Mirza Akhena 

>
>
> 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?*
>

maksudnya lebih baik??


>
> Saya udah coba kedua2nya dan fine2 saja sih,
>

fine2 ?? coba cek method pertama, struktur nya sdh bener atau blun


> 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?
>
>
setau saya : ekspresi A || ekspresi B  , jika ekspresi A uda pasti false,
maka ekspresi B tidak akan di cek

CMIIW

Re: [JUG-Indonesia] Tentang boolean OR operator

[Andrian Kurniady]

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 

>
>
> 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?
>
>  
>

[JUG-Indonesia] Tentang boolean OR operator

[Mirza Akhena]

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] Transaction Locking

[Endy Muhardin]

2010/7/15 Andre Prasetya 
>
>
>
> Kalau yang biasa saya lakukan di CP itu ada agent yang berjalan setiap malam, 
> membuat summary, dihitung brapa jumlah yang register hari ini, jumlah member 
> berjalan, jumlah member yang off dan distore jadi 1 record per hari.
>
> Nah kalau saya melakukan hal yang mirip tapi deployment nya aplikasi desktop, 
> kl pengguna A tekan tombol summary lalu sblm proses slesai, B juga menekan 
> khan bisa berakibat double record (apalagi saya pakai Id AutoGenerate)
>
> Saat ini baru kepikir buat pake 1 tabel lock, jadi fungsi yang krusial sblm 
> dilakukan, akan dilock dan sesudah slesai akan dilepas lock nya. Barangkali 
> ada solusi yang lebih pas...
>


Ooo .. memang harus dikasi flag biar gak tumpukan.
Kalo saya biasanya bikin tabel background_process.
Dari UI, cukup nginsert aja ke tabel itu untuk request jalankan summary.
Nanti di server ada background process yang ngecek tabel itu.
Kalo ada record yang statusnya new, ganti jadi running, kemudian
jalankan proses summary.
Setelah selesai, ganti lagi statusnya jadi success/error.

Kalo ada user lain yang klik tombol proses, tinggal dilihat ke tabel,
apa ada proses sejenis yang sedang running atau sudah selesai.
Kalau ada, tinggal popup message, proses sedang berjalan, atau proses
sudah pernah dijalankan.


--
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --

Re: [JUG-Indonesia] Teknologi yg mirip ama klikbca kyknya.....

[Andrian Kurniady]

But they can just use available ones, like:

http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/security/SecureRandom.html

-Kurniady

2010/7/15 Monang Setyawan 

>
>
> I don't believe that any thug can write cryptographically secure PRNG.
>
>
> 2010/7/13 Hendry Luk 
>
>>
>>
>> Boleh tau what the problem is?
>>
>> 2010/7/14 Monang Setyawan 
>>
>>>
>>>
>>> Bank mana yang salah satu developer internet bankingnya adalah "thug"
>>> yang "nulis code buat generate 5 digit random number"? Saya pengin kasih
>>> tahu teman/kerabat saya supaya tidak menjadi nasabah bank itu :)
>>>
>>> 2010/7/13 Hendry Luk 
>>>
>>>

 Ada teknologi baru... umumnya diapplikasikan pada perangkat telpon
 genggam, dipopulerkan 2 dekade silam, dinamai "short-message-service", ato
 SMS ;P

 In fact, satu2nya bank yg gw pernah liat pake OTP cuma BCA doank. Bank
 laen semuanya plain humble SMS... secure, gak ngerepotin (btw orang2 para
 nenteng keybca kemana2 24 jem ya?), dan practical: any thug bisa nulis code
 buat generate 5 digit random number n kirim ke sms... gak perlu rocket
 scientists buat bikin algorithm super mutakhir that is otp.

 2010/7/13 Endy Muhardin 

>
>
> 2010/7/13 Fredi Tansari 
> 
> >
>
> >
> >
> >
> > hiihihi masih jaman ya pake otp gitu
> > btw gua mau arrange shipment nih utk smart card... ada yang interest
> gak?
>
> Trus kalo gak pakai OTP, apa ada teknologi yang lebih baru?
>
> --
> Endy Muhardin
> http://endy.artivisi.com
> Y! : endymuhardin
> -- life learn contribute --
>


>>>
>>>
>>> --
>>> "Don't worry about what anybody else is going to do. The best way to
>>> predict the future is to invent it." - Alan Kay
>>>
>>
>>
>
>
> --
> "Don't worry about what anybody else is going to do. The best way to
> predict the future is to invent it." - Alan Kay
>
>  
>

Re: [JUG-Indonesia] Transaction Locking

[Alpha Bagus Sunggono]

betul,
keynya jangan di set autoincrement,
mengingat biyasana yang diberi auto increment dengan tujuan mencapai unique
id - merupakan artifisial key.
Jadi gunakan kandidat key lain.

atau bila itu memang haru id satu satunya,
berarti kita assign.

Pada jaman dahulu kala,
dibuatlah satu tabel berisi global parameter,
namun hanya berisi 1 baris (banyak kolom, sebanyak parameter id yang akan di
increment).
semua Node akan mengecek ke tabel satu ini,
untuk mendapatkan nilai increment.

REsikonya 2 orang tersebut mendapatkan id yang sama,
sehingga salah satu berhasil, yang lain akan gagal.

Pada 15 Juli 2010 17:10, Andre Prasetya  menulis:

>
>
> Dgn kata lain primary id nya nggak boleh auto increment tapi assignable ?
>
> 2010/7/15 Alpha Bagus Sunggono 
>
>
>>
>> Kalau 2 orang itu mempunyai key composite yang sama,
>> maka tidak akan dobel,
>> namuan salah satu berhasil,
>> yang lain akan gagal.
>>
>
> --
> -Andre-
> http://rafunkel.blogspot.com
>
>  
>

Re: [JUG-Indonesia] Transaction Locking

[Andre Prasetya]

Kalau yang biasa saya lakukan di CP itu ada agent yang berjalan setiap
malam, membuat summary, dihitung brapa jumlah yang register hari ini, jumlah
member berjalan, jumlah member yang off dan distore jadi 1 record per hari.

Nah kalau saya melakukan hal yang mirip tapi deployment nya aplikasi
desktop, kl pengguna A tekan tombol summary lalu sblm proses slesai, B juga
menekan khan bisa berakibat double record (apalagi saya pakai Id
AutoGenerate)

Saat ini baru kepikir buat pake 1 tabel lock, jadi fungsi yang krusial sblm
dilakukan, akan dilock dan sesudah slesai akan dilepas lock nya. Barangkali
ada solusi yang lebih pas...


2010/7/15 Endy Muhardin 

> 2010/7/15 Andre Prasetya 
> >
> >
> >
> > Saya sedang buat aplikasi desktop menggunakan JPA
> >
> > Ada salah satu mekanismenya itu membuat summary, dan tahu2 terpikir kalau
> ada 2 orang bersamaan click bikin summary atau sebelum summary slesai dibuat
> tahu2 ada orang kedua yang click tombol untuk membuat summary yang hasilnya
> jadi dobel (Summary nya diwrite ke temporary table).
> >
> > Kalau aplikasi web khan tinggal bikin agent dan agentnya yang lakuin,
> kalau desktop gimana ? ada masukan ?
>
> Bisa dijelaskan apa yang dimaksud dengan 'bikin summary' ?
>
> --
> Endy Muhardin
> http://endy.artivisi.com
> Y! : endymuhardin
> -- life learn contribute --
>
>
-- 
-Andre-
http://rafunkel.blogspot.com

Re: [JUG-Indonesia] Transaction Locking

[Endy Muhardin]

2010/7/15 Andre Prasetya 
>
>
>
> Saya sedang buat aplikasi desktop menggunakan JPA
>
> Ada salah satu mekanismenya itu membuat summary, dan tahu2 terpikir kalau ada 
> 2 orang bersamaan click bikin summary atau sebelum summary slesai dibuat 
> tahu2 ada orang kedua yang click tombol untuk membuat summary yang hasilnya 
> jadi dobel (Summary nya diwrite ke temporary table).
>
> Kalau aplikasi web khan tinggal bikin agent dan agentnya yang lakuin, kalau 
> desktop gimana ? ada masukan ?

Bisa dijelaskan apa yang dimaksud dengan 'bikin summary' ?

--
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --

Re: [JUG-Indonesia] Transaction Locking

[Andre Prasetya]

Dgn kata lain primary id nya nggak boleh auto increment tapi assignable ?

2010/7/15 Alpha Bagus Sunggono 

>
>
> Kalau 2 orang itu mempunyai key composite yang sama,
> maka tidak akan dobel,
> namuan salah satu berhasil,
> yang lain akan gagal.
>

-- 
-Andre-
http://rafunkel.blogspot.com

Re: [JUG-Indonesia] Transaction Locking

[Alpha Bagus Sunggono]

Kalau 2 orang itu mempunyai key composite yang sama,
maka tidak akan dobel,
namuan salah satu berhasil,
yang lain akan gagal.

Pada 15 Juli 2010 15:19, Andre Prasetya  menulis:

>
>
> Saya sedang buat aplikasi desktop menggunakan JPA
>
> Ada salah satu mekanismenya itu membuat summary, dan tahu2 terpikir kalau
> ada 2 orang bersamaan click bikin summary atau sebelum summary slesai dibuat
> tahu2 ada orang kedua yang click tombol untuk membuat summary yang hasilnya
> jadi dobel (Summary nya diwrite ke temporary table).
>
> Kalau aplikasi web khan tinggal bikin agent dan agentnya yang lakuin, kalau
> desktop gimana ? ada masukan ?
>
> --
> -Andre-
> http://rafunkel.blogspot.com
>
>  
>
> ,___
>

[JUG-Indonesia] Transaction Locking

[Andre Prasetya]

Saya sedang buat aplikasi desktop menggunakan JPA

Ada salah satu mekanismenya itu membuat summary, dan tahu2 terpikir kalau
ada 2 orang bersamaan click bikin summary atau sebelum summary slesai dibuat
tahu2 ada orang kedua yang click tombol untuk membuat summary yang hasilnya
jadi dobel (Summary nya diwrite ke temporary table).

Kalau aplikasi web khan tinggal bikin agent dan agentnya yang lakuin, kalau
desktop gimana ? ada masukan ?

-- 
-Andre-
http://rafunkel.blogspot.com

Re: [JUG-Indonesia] Re: minta saran cara utk running suatu program java

[Mirza Akhena]

wanna try to help.

ini mgk masalah teknisnya eclipse.

*btw, ini library ato aplikasi ya..??*


kalo aplikasi:

Masukkin projectnya coba pake import :

   - File -> import -> General -> Existing Projects into workspace
   - Select root Directory [browse sampe root dari project yang mau dicoba]
   -> Finish
   - Coba Ctrl+B utk *Build*
   - Dan Ctrl+F11 utk *Run*



kalo library:

Masukin library dengan Build path :

   - Bikin project dulu, trus klik kanan projectnya,
   - Build Path -> Add External Archives -> pilih library-nya -> Open.




_
2010/7/15 Yakob 

>
>
> yup thanks,ternyata setelah aq mencoba nya aq berhasil masukin project
> folder ini ke eclipse dan bisa utk running. tapi masalahnya lg adalah
> pas running muncul error seperti ini.
>
> "the project cannot be build until path errors are resolved"
>
> bisa ada yg jelaskan ini error dikarenakan kenapa ya? padahal aq udah
> bisa running helloworld di eclipse.kok bisa build path nya salah?
> mohon bantuannya lg.
>
> thanks
>
>
> On 7/14/10, mimi_tan1985 >
> wrote:
> > Kalo ada file build.xml, berarti bisa build pake ant.
> >
> > --- In jug-indonesia@yahoogroups.com ,
> "P. Adhi Nugroho" 
> > wrote:
> >>
> >> klik kanan project..pilih build project. klo ndak muncul, pilih Project
> di
> >> toolbar lalu uncheck Build Automatically
> >>
> >
> >
> >
>
> --
> http://jacobian.web.id
>  
>