Halaman

Jumat, 16 April 2010

[shared] to_xml_params with attributes from hash

sejauh yang saia tau, rails .to_xml dari hash tidak dapat menghasilkan xml tag dengan attribute selain type.
tetapi saia membutuhkan hal tersebut pada project yang saia kerjakan. karena itu saia membuat method to_xml_params untuk mengubah hash menjadi xml string:

def self.to_xml_params(data)
if data.is_a? Hash
data.collect do |key, value|
tag_attr = []
if key.is_a? Array
tag = key.first
key[1..-1].each do |key_attr|
key_attr.each do |k, v|
tag_attr << "#{k}=\"#{v}\""
end
end
else
tag = key
end
tag = tag.to_s.tr('_', '-')
result = "<#{tag}#{" #{tag_attr.join(' ')}" unless tag_attr.empty?}>"
result << to_xml_params(value)
result << "</#{tag}>"
result
end.join('')
elsif data.is_a? Array
data.inject(''){|result, v|
result << to_xml_params(v)
}
else
data.to_s
end
end


contoh penggunaan:


to_xml_params :a => "b"
# -> b
to_xml_params :a => {:b => "c"}
# -> c
to_xml_params [:a,{:x => :y}] => {:b => "c"}
# -> c
to_xml_params [:a,{:x => :y, :z => "w"}] => {[:b, {:p => "q"}] => "c"}
# -> c
to_xml_params :a => {:b => "c", :d => "e"}
# -> ec
to_xml_params :a => [{:b => "c"}, {:d => "e"}]
# -> ce sama dengan diatas

Selasa, 06 April 2010

[shared] "whenever" - cron simplified

karena beberapa waktu lalu saia menyadari kalau rufus-scheduler bermasalah bila digunakan di passenger maka saia beralih kembali menggunakan cron.
namun cron mengharuskan saia untuk meng-update crontab setiap kali saia ingin menambahkan task baru, karenanya saia mencoba mencari alternatif lain yg reliable dan mudah digunakan..

http://github.com/javan/whenever/

sebagai alternatif rufus-scheduler gem ini cukup mudah untuk digunakan, walaupun sedikit lebih "repot".

saia rasa dokumentasi di github sudah cukup jelas jadi saia hanya akan membahas implementasi yg saia gunakan.

yang menyusahkan dari gem ini, saia diharuskan meng-convert schedule.rb ke cron dengan menggunakan

whenever --update-crontab MyApp

setiap kali saia melakukan perubahan di schedule.rb
dokumentasi di github menunjukkan cara integrasi dengan capistrano, tetapi saia tdk mau direpotkan dengan menginstall gem tambahan, jadi yg saia lakukan hanya menambahkan bbrp baris di script untuk deploying pada staging dan production server:

.... svn up, rsync, etc ....

cd /home/rails/myapp && whenever --update-crontab MyApp --set environment=staging
cd /home/rails/myapp/script && chmod 755 runner

baris 1 untuk meng-update crontab. --set environment digunakan untuk merubah environment dari default production
baris 2 untuk memberi ijin execute pada script runner, karena saia menggunakan model method bukan rake untuk task2 nya

contoh schedule.rb yg saia gunakan:

every 30.minutes do
runner "QueuedEmail.deliver_all"
end

every 10.minutes do
runner "Message.destroy_all_expired"
end

every :day do
runner "ReferData.give_rewards!"
runner "SystemMailer.deliver_scheduler_check"
end

How to report bugs effectively

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
artikel yg saia pikir sangat berguna, tidak hanya untuk user, tetapi juga untuk developer.

finding a way to reproduce problem is already a half of the debugging progress ^_^

Selasa, 09 Maret 2010

[shared] Branching using TortoiseSVN part 2

ok, ngelanjutin dari part 1, saia akan menjelaskan soal feature branch.

untuk post ini saia tidak akan menjelaskan prosedur untuk branching dan merging karena saia rasa di part 1 sudah cukup jelas.. jadi saia akan lebih membahas tentang konsep dari feature branch.

so, pertanyaannya: apa itu feature branch?
jawab: feature branch sbenarnya sama seperti staging branch. perbedaannya feature branch biasanya dibuat dari staging branch, bukan dari trunk, jadi branch of branch.
feature branch ini dibuat untuk memenuhi salah satu aturan yg saia tulis di bagian tambahan pada part 1:

"Usahakan agar setiap update yang ditambahkan di staging selesai dalam sesedikit mungkin commit"

jadi bila pada suatu project ada feature yang cukup besar dan rumit, sehingga diperkirakan membutuhkan waktu 2 hari atau lebih, sebaiknya membuat feature branch khusus untuk feature tersebut.

Kelebihan menggunakan feature branch:

misalkan klien meminta implementasi feature A di page X yang cukup besar/rumit. nah saat kita sedang ditengah2 mengerjakan feature A tersebut ternyata di page X terdapat bug vital dan harus segera diperbaiki. Namun yang jadi masalah page X tersebut sudah terdapat beberapa bagian dari feature A yang masi dalam pengerjaan, jadi tidak mungkin untuk di-deploy (dapat menyebabkan bug). hal tersebut dapat dihindari apabila feature A dikerjakan dalam feature branch.

kasus lain (masih nyambung sama yg di atas), karena feature A cukup rumit, maka pengerjaan memakan waktu bbrp hari, smentara sebelum selesai tidak dapat di-commit karena akan menyebabkan staging server menjadi rusak. nah lalu misalkan karena suatu sebab tempat pengerjaan feature A tersebut tidak dapat digunakan, maka pengerjaan feature A akan dipaksa berhenti. dengan feature branch commit kode yang belum selesai tidak akan mempengaruhi staging server jadi bila terjadi kasus tadi, kita dapat check-out ulang dan melanjutkan pengerjaan di tempat lain.

Kekurangannya:

- memperbesar penggunaan disk space
- ada kemungkinan conflict antara feature branch dengan staging (hati2 dalam me-resolve conflict)
- memperlama deploying, untuk deploy feature A ke production (trunk), merge harus dilakukan 2x: merge feature_a_branch ke staging, kemudian merge staging ke trunk. karena merge proses yg memakan waktu, hal ini dapat menyusahkan apabila kita hanya perlu men-deploy perbaikan kecil (1-2 baris) untuk feature A ke production. maka dari itu biasanya perbaikan2 bug tetap saia lakukan di staging.

ok sgitu saja soal branching2an, post ini hanya merupakan pendapat dari saia dan apa yang saia gunakan saat ini, jadi mungkin tidak spenuhnya benar, dan pastinya ada cara lain yang lebih baik.

Kamis, 04 Maret 2010

[shared] jQuery serialize only a part of form

baru2 ini di project yang sedang saia kerjakan, saia menemui suatu masalah, intinya saia ingin men-submit suatu bagian dari form yang cukup besar menggunakan ajax untuk mendapatkan nilai yang akan dipakai oleh bagian lain dari form.

secara sederhana kode nya sebagai berikut:

<form>
<input type="text" name="user_name" />
<div id="part1">
<input type="text" name="user_paid_amount" onchange="ajaxRequestToGetPart2ValueBasedOnPart1();" />
<input type="text" name="user_type" onchange="ajaxRequestToGetPart2ValueBasedOnPart1();"/>
</div>
<div id="part2">
<input type="text" name="price_amount" value="" />
</div>
</form>

intinya ketika ada perubahan pada input2 di part1, part2 akan secara otomatis diisi.

namun yang jadi masalah adalah bagaimana cara mengambil value2 dari part1 untuk dikirimkan sebagai parameter..
jquery menyediakan fungsi serialize untuk mengambil semua element dari suatu form (http://api.jquery.com/serialize/), sayangnya hal tersebut tidak dapat dilakukan untuk container selain form, jadi $('#part1').serialize() tidak dapat digunakan..

Solusi 1 - clone(true)

jQuery Serialize a Fieldset
menggunakan clone untuk meng-copy isi div yang kemudian diletakkan pada form yang disembunyikan. form tersebut lalu di-serialize kemudian di-remove.

namun clone merupakan fungsi yang cukup memakan resource.

Solusi 2 - selector

solusi yang ke-2 dengan menggunakan selector :input. kira2 kodenya sebagai berikut:

function serialize(container){
//container: string selector or element of the container
$(':input', container).serialize();
}
serialize('#part1');

lebih simple dan efektif :)