Felix Halim wrote:
> On 5/21/06, m.c. cptrwn <[EMAIL PROTECTED]> wrote:
> > > Biasanya Test Cases yang paling menjebak tidak tergenerate dari Random
> > > Cases :D
>
> Kita nge challenge code orang lain kalau:
> 1. keliatan bug yang jelas
> contohnya, kurang pengecekan untuk kondisi tertentu. Maka kita
> challenge dengan input yang tidak dihandle oleh orang tersebut,
> otomatis programnya pasti outputnya ngaco :D biasanya justru banyak
> sekali kondisi kondisi yang sangat kecil yang terlupakan oleh
> programmer... (karena disepelekan). Disitulah kita bisa cari points,
> challenge coder yang gak baca soal dengan teliti ato emang salah ketik
> :D
>
> 2. orangnya salah make algorithm
> kalo input rangenya misalkan n <= 1000. tapi di coding orang tersebut
> ada begini:
> for i = 1 .. n
> for j = 1.. n
> for k = 1..n
> do abcdef;
> Nah udah pasti gagal tuh algoritma, karena untuk n nya 1000 pasti dia
> berjalan 1000,000,000 kali looping dan karena komputer TopCoder dalam
> 2 detik hanya bisa looping sebanyak 50 jutaan, yah pasti coding orang
> tersebut berjalan lebih dari 2 detik (50 detik tepatnya). Maka,
> challenge aja dengan input sebesar 1000, pasti programnya TimeLimit
> (timelimit itu kalo program berjalan lebih lama dari 2 detik, maka
> dianggap salah).
>
> untuk solve problem yang inputnya n<=1000 harus pake algo yang lebih
> kecil dari O(N^2).
>
> 3. Tricky cases
> kalo kita punya testcase yang tricky abis, kita bisa gambling nge
> challenge orang pake tricky cases kita :D
>
Sip sip ... good sharing ! ada contoh tricky case ?
Btw gantian sharing :)) , kalau di qa cycle pada produk real time ,
tricky case ini bisa merupakan 'combination of events' yang tidak
dihandle oleh systems dan mengakibatkan chain of reactios.
Ada beberapa hal yang harus di-exploit oleh engineer :
1. task prioritization (semaphore)
2. cpu utilization
3. memory (leaks,consumptions,etc).
contoh yang paling sederhana adalah hanya jika menggunakan printf()
untuk logging messages. Dalam sistem apapun jika tidak ada fungsi
kontrol (buffered) untuk memprint log message, dijamin cpu utilisasi
bisa tinggi.
Dan jika cpu utilisasi tinggi, biasanya hanya task tertentu yg
menguasai cpu, sementara task lain yg bertugas untuk mengontrol
system,networks atau forwarding packet terhenti. Walhasil , triple
effects , networks down/router crash.
> > mungkin kalo ada PC di Indonesia, dosenya felix seperti mark p.e.
> > kandidat yg bagus untuk jadi juri :)
>
> saya cuman bisa coding, mana bisa jadi dosen :P
maksud saya jugdnya pak mark p.e. sang dosen binus (mudah2an felix
kenal) :)
>
> > > Menyukai disini dalam arti bisa "meng-appreciate" computer science
> > > stuff, betapa susahnya itu dibuat, tapi belum tentu terjun ke semua
> > > computer science stuffs karena teralu luas. Keliatannya kata
> > > "mengagummi" lebih tepat disini :)
> >
> > he he .. iya saya setuju point ini. point dimana CS sangat dan terlalu
> > luas itu benar sekali , sampai kadang2 saya mikir kenapa gak semua anak
> > sma saja terjun ke CS karena peluangnya limitless.
>
> Terutama kalo udah ngeliat program2 open-source yang canggih canggih..
> pasti ada rasa kagum di hati ini. Tapi bagi yang bukan pencinta
> pemograman mungkin program opensource yang canggih itu terlihat biasa
> saja.
>
Kalau dari pengalaman saya, kadang2 bukan hanya programer senior yang
bikin hasil produk bagus tapi yg terpenting adalah software engineering
management dan teamwork, dalam kasus ini saya merefer ke real time
produk yang punya 5-10 juta codes :)
-mcp
X-Google-Language: INDONESIAN,ASCII-7-bit
Received: by 10.11.53.63 with SMTP id b63mr101835cwa;
Sun, 21 May 2006 07:45:03 -0700 (PDT)
X-Google-Token: HOwNhQwAAADmn9FjNAMJyLk-PJYWLsAR
Received: from 71.135.47.95 by j73g2000cwa.googlegroups.com with HTTP;
Sun, 21 May 2006 14:45:03 +0000 (UTC)
From: "m.c. cptrwn" <[EMAIL PROTECTED]>
To: "teknologia" <teknologia@googlegroups.com>
Subject: Re: Sharing tentang Programming Competition
Date: Sun, 21 May 2006 14:45:03 -0000
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3)
Gecko/20060426 Firefox/1.5.0.3,gzip(gfe),gzip(gfe)
Mime-Version: 1.0
Content-Type: text/plain
Felix Halim wrote:
> On 5/21/06, m.c. cptrwn <[EMAIL PROTECTED]> wrote:
> > > Biasanya Test Cases yang paling menjebak tidak tergenerate dari Random
> > > Cases :D
>
> Kita nge challenge code orang lain kalau:
> 1. keliatan bug yang jelas
> contohnya, kurang pengecekan untuk kondisi tertentu. Maka kita
> challenge dengan input yang tidak dihandle oleh orang tersebut,
> otomatis programnya pasti outputnya ngaco :D biasanya justru banyak
> sekali kondisi kondisi yang sangat kecil yang terlupakan oleh
> programmer... (karena disepelekan). Disitulah kita bisa cari points,
> challenge coder yang gak baca soal dengan teliti ato emang salah ketik
> :D
>
> 2. orangnya salah make algorithm
> kalo input rangenya misalkan n <= 1000. tapi di coding orang tersebut
> ada begini:
> for i = 1 .. n
> for j = 1.. n
> for k = 1..n
> do abcdef;
> Nah udah pasti gagal tuh algoritma, karena untuk n nya 1000 pasti dia
> berjalan 1000,000,000 kali looping dan karena komputer TopCoder dalam
> 2 detik hanya bisa looping sebanyak 50 jutaan, yah pasti coding orang
> tersebut berjalan lebih dari 2 detik (50 detik tepatnya). Maka,
> challenge aja dengan input sebesar 1000, pasti programnya TimeLimit
> (timelimit itu kalo program berjalan lebih lama dari 2 detik, maka
> dianggap salah).
>
> untuk solve problem yang inputnya n<=1000 harus pake algo yang lebih
> kecil dari O(N^2).
>
> 3. Tricky cases
> kalo kita punya testcase yang tricky abis, kita bisa gambling nge
> challenge orang pake tricky cases kita :D
>
Sip sip ... good sharing ! ada contoh tricky case ?
Btw gantian sharing :)) , kalau di qa cycle pada produk real time ,
tricky case ini bisa merupakan 'combination of events' yang tidak
dihandle oleh systems dan mengakibatkan chain of reactios.
Ada beberapa hal yang harus di-exploit oleh engineer :
1. task prioritization (semaphore)
2. cpu utilization
3. memory (leaks,consumptions,etc).
contoh yang paling sederhana adalah hanya jika menggunakan printf()
untuk logging messages. Dalam sistem apapun jika tidak ada fungsi
kontrol (buffered) untuk memprint log message, dijamin cpu utilisasi
bisa tinggi.
Dan jika cpu utilisasi tinggi, biasanya hanya task tertentu yg
menguasai cpu, sementara task lain yg bertugas untuk mengontrol
system,networks atau forwarding packet terhenti. Walhasil , triple
effects , networks down/router crash.
> > mungkin kalo ada PC di Indonesia, dosenya felix seperti mark p.e.
> > kandidat yg bagus untuk jadi juri :)
>
> saya cuman bisa coding, mana bisa jadi dosen :P
maksud saya jugdnya pak mark p.e. sang dosen binus (mudah2an felix
kenal) :)
>
> > > Menyukai disini dalam arti bisa "meng-appreciate" computer science
> > > stuff, betapa susahnya itu dibuat, tapi belum tentu terjun ke semua
> > > computer science stuffs karena teralu luas. Keliatannya kata
> > > "mengagummi" lebih tepat disini :)
> >
> > he he .. iya saya setuju point ini. point dimana CS sangat dan terlalu
> > luas itu benar sekali , sampai kadang2 saya mikir kenapa gak semua anak
> > sma saja terjun ke CS karena peluangnya limitless.
>
> Terutama kalo udah ngeliat program2 open-source yang canggih canggih..
> pasti ada rasa kagum di hati ini. Tapi bagi yang bukan pencinta
> pemograman mungkin program opensource yang canggih itu terlihat biasa
> saja.
>
Kalau dari pengalaman saya, kadang2 bukan hanya programer senior yang
bikin hasil produk bagus tapi yg terpenting adalah software engineering
management dan teamwork, dalam kasus ini saya merefer ke real time
produk yang punya 5-10 juta codes :)
-mcp
--~--~---------~--~----~------------~-------~--~----~
http://teknoblogia.blogspot.com/2005/02/tata-tertib-milis-v15.html
-~----------~----~----~----~------~----~------~--~---
