Elevate: Migrasi Rolling Sum Kemajuan Tahun ke Aplikasi Elevate

Saya yang kedua ini, saya suka tren kebugaran tetapi rata-rata bergulir 30 hari sangat berharga!

Saya datang ke sini hanya untuk mengatakan ini! Rata-rata bergulir 30 hari adalah salah satu fitur yang paling berguna untuk membandingkan volume musim. Juga jarak tahun lalu cukup mendalam bagi mereka yang berfokus pada mengumpulkan mil.

Akan sangat membantu untuk menambahkan 30 hari terakhir dan rata-rata jarak/waktu/elevasi tahun lalu jika memungkinkan.

Saya juga ingin mengambil kesempatan ini untuk berterima kasih kepada Thomas atas proyeknya yang tidak dapat dibandingkan

@ashdriver @DCunnama @fjavipm Saya memahami umpan balik ini. Sebenarnya fitur warisan ini telah dikodekan oleh orang lain (dengan permintaan tarik & terima kasih padanya!!). Saya menemukan banyak bug dengan banyak pengguna dan saya tidak dapat mempertahankan fitur dalam kode lama. Itu sebabnya saya pindah (atau dipaksa untuk Anda...) fitur lama ke yang baru.

Saya akan mengembalikan fitur ini dan menandainya mendesak . Sejujurnya saya tidak pernah benar-benar memahami konsep rata - jarak/waktu/ketinggian rata-rata tahun lalu untuk tujuan saya sendiri. Jadi saya bisa membayangkan bahwa banyak pengguna (kecuali Anda) tidak akan dapat menggunakannya dengan benar. Saya ingat bahwa fitur harus dapat diakses oleh semua orang.

Jadi bisakah Anda menjelaskan kembali kepada saya "kebutuhan", "kasus penggunaan", "masalah terpecahkan" di balik rata - jarak/waktu/ketinggian rata-rata tahun lalu ? Jadi saya bisa mengkodekannya kembali dalam perkembangan tahun baru? Pemahaman ini diperlukan untuk saya dan semua pengguna lain juga.

Jika Anda ingin mengembalikan fitur lama, Anda masih dapat mengunduh versi lama di sini: https://thomaschampagne.github.io/elevate/#/builds (dengan filter cabang: master, versi: 6.8.1 )

Hai Tomas,

Terima kasih atas respon dan penjelasannya. Saya akan memberikan kebutuhan dan penggunaan saya sendiri untuk ini, tetapi semoga orang lain dapat menambahkan lebih banyak jika ada:

Membutuhkan:
Sebuah cara untuk membandingkan beban pelatihan terbaru dan diperpanjang (diukur dengan jarak atau ketinggian) dari satu tahun ke tahun berikutnya.

Kasus Penggunaan:
Pengguna dapat memilih untuk menampilkan plot elevasi atau jarak rata-rata 30 hari atau 365 hari (ditampilkan pada sumbu y), dan tanggal pada sumbu x mulai 1 Januari. Setiap tahun dengan data yang tersedia dapat dilapis dalam warna yang berbeda, dan idealnya juga kemampuan untuk memilih/membatalkan pilihan tahun tertentu untuk perbandingan langsung di antara mereka.

Masalah Terpecahkan:
Ini memberikan cara yang cukup efektif untuk membandingkan upaya pelatihan yang diukur dengan jarak dan ketinggian pada waktu tertentu dalam setahun dibandingkan dengan tahun-tahun sebelumnya. Seringkali atlet berlatih untuk acara tahunan tertentu yang jatuh pada tanggal yang kira-kira sama setiap tahun, dan dapat dengan mudah membandingkan rata-rata bergulir 30 hari (dan pada tingkat yang lebih rendah 365 hari) adalah cara yang bagus untuk membandingkan persiapan untuk acara semacam itu.

Permintaan fitur tambahan opsional: Kemampuan untuk menyesuaikan jendela rata-rata bergulir antara/di bawah 30 hari dan 365 hari mungkin juga berguna, meskipun menurut saya 30 hari adalah nilai tetap yang cukup bagus. Menyesuaikan ukuran jendela dapat berguna untuk membandingkan blok latihan yang lebih panjang (atau lebih pendek) dari 30 hari dari tahun ke tahun - misalnya program pelatihan maraton sering ditetapkan selama 3 bulan.

Jadi bisakah Anda menjelaskan kembali kepada saya "kebutuhan", "kasus penggunaan", "masalah terpecahkan" di balik rata - jarak/waktu/ketinggian rata-rata tahun lalu ? Jadi saya bisa mengkodekannya kembali dalam perkembangan tahun baru? Pemahaman ini diperlukan untuk saya dan semua pengguna lain juga.

"30 hari terakhir" berguna untuk memahami variasi volume latihan khususnya menurut cabang olahraga. Dalam olahraga long endurance, volume dan intensitas adalah kunci sukses. Terlepas dari intensitas, yang dapat diperoleh dalam HRSS, volume adalah bagian paling sederhana dari persamaan tetapi seringkali sangat sulit untuk diperbaiki. Misalnya, fitur 30 hari terakhir membantu Anda mendapatkan tingkat peningkatan yang mengarah ke enam hingga delapan minggu terakhir dari acara puncak Anda.

Hanya koreksi kecil - Saya telah berbicara tentang 'rata-rata bergulir' selama 30 dan 365 hari tetapi sebenarnya total akumulasi jarak/elevasi/waktu di atas jendela mungkin lebih berguna dan bagaimana fitur ini diimplementasikan sebelumnya.

Saya juga ingin berpadu dan mengatakan bahwa rata-rata bergulir 30 dan 365 hari sebenarnya telah menjadi alasan nomor satu saya menggunakan plugin Anda, jadi tolong tolong bawa kembali :)

Untuk menjawab pertanyaan kegunaan, rata-rata bergulir adalah cara yang bagus untuk memiliki ukuran "garis" yang lebih masuk akal yang suka dilacak oleh pelari. Misalnya saya tahu bahwa saya memiliki setidaknya 3000 mil rata-rata bergulir di kaki saya selama lebih dari satu tahun sekarang (tepatnya 424 hari seperti yang Anda lihat di bawah). Perhitungan ini saya lakukan pada Google Spreadsheet terpisah tetapi cukup mudah untuk mengonversinya menjadi plot untuk disertakan dalam plugin Anda.

Ambang | Per minggu | Air mani. Mil | Tanggal tercapai | Hari berakhir | Bulan berakhir
-- | -- | -- | -- | -- | --
1000 | 19 | 1006 | 2016/03/29 | 1044 | 34
1500 | 29 | 1516 | 2016/08/19 | 901 | 29
2000 | 38 | 2001 | 2016/10/21 | 838 | 27
2500 | 48 | 2505 | 2017/06/19 | 597 | 19
3000 | 58 | 3005 | 2017/12/09 | 424 | 13

Ini lebih jelas bagi saya dari sekarang ... Saya tinggal menit lama pada perkembangan saya untuk menangkapnya. Saya memiliki vizualisasi fitur yang salah sebelumnya... Itu tidak membantu saya... Tapi mulai sekarang, ini bukan ilmu roket :)

Jadi saya akan memberikan 2 mode ini:

• "Mode Kumulatif Standar" yang saat ini ada di aplikasi
• Dan "Mode Rolling Streak" => Butuh bantuan Anda untuk kata-kata pemasaran yang tepat ;)

"Mode Rolling Streak" akan memiliki nilai hari bergulir yang dapat disesuaikan dari 1 hingga 365 . Apakah kita harus membatasi ini pada nilai tetap? Maksudku 1 minggu , 2 minggu , 1 bulan , 3 bulan ,.. 6 bulan , 1 tahun . Beberapa pengguna mungkin tidak tahu hitungan hari mana yang terbaik menurut saya.

"Mode Rolling Streak" akan berlaku untuk semua jenis kemajuan: jarak , waktu , ketinggian & hitungan .

Saya masih tidak tahu apa yang bisa kita tampilkan di tabel (sebelah kanan)? Delta bergulir antara tahun? Bagaimana dengan target?

Tentu saja hal-hal yang saya tulis di sini tidak disegel. Anda dapat memberikan saran, ide, peringatan, ... ;) Saya akan menautkan beberapa bangunan di sini. Jadi Anda akan dapat menguji fitur tersebut. Saya akan bekerja terutama pada itu sekarang, fitur lain dalam status tertunda.

Terima kasih Thomas, saya juga setuju bahwa ini adalah salah satu bagian favorit saya dari plugin. Saya pribadi berpikir memilikinya default ke 1 bulan, tetapi memungkinkan pengguna untuk mengaturnya secara manual akan sangat bagus.

Saya sering bolak-balik antara 1 bulan, dan 1 tahun untuk dengan mudah membandingkan beban saya dari satu tahun ke tahun berikutnya, dan melihat bagaimana pelatihan saya, sebagian besar untuk acara seperti Marathon dalam berlari, di mana jumlah pelatihan benar-benar baik untuk melihat lebih dari kelelahan dll.

Bersulang!

Saya akan mengatakan nilai tetap bagus untuk kisaran - 1 minggu, 2 minggu, 1 bulan, 3 bulan, 6 bulan, 1 tahun.
Mungkin tambah 2 bulan juga?

Untuk nilai tabel dan ikhtisar saya pikir tetap sama dengan tabel perkembangan yang ada - yaitu delta dengan tahun sebelumnya dan saat ini, seperti yang Anda sarankan.

"Mode Rolling Streak" sepertinya nama yang layak untuk saya sebut - setidaknya saya tidak bisa memikirkan sesuatu yang lebih baik!

Sekali lagi terima kasih atas semua waktu dan keahlian yang Anda curahkan untuk proyek ini - ini sangat kami hargai.

• Dan "Mode Rolling Streak" => Butuh bantuan Anda untuk kata-kata pemasaran yang tepat ;)

Saya menempatkan kata "garis" dalam tanda kutip di posting asli saya karena garis berarti sesuatu yang khusus untuk pelari dan itu adalah hari berturut-turut berlari. Beberapa pelari percaya pada NDO (no-days-off) dan coretan adalah berapa lama Anda bisa pergi tanpa satu hari istirahat. Jadi dalam pengertian itu menyebutnya "Mode Rolling Streak" mungkin membingungkan. Saya akan menyarankan sesuatu seperti "Mode Kumulatif Bergulir" atau "Mode Kumulatif Berjendela" yang menyiratkan jendela waktu di mana akumulasi terjadi.

"Mode Rolling Streak" akan memiliki nilai hari bergulir yang dapat disesuaikan dari 1 hingga 365 . Apakah kita harus membatasi ini pada nilai tetap? Maksudku 1 minggu , 2 minggu , 1 bulan , 3 bulan ,.. 6 bulan , 1 tahun . Beberapa pengguna mungkin tidak tahu hitungan hari mana yang terbaik menurut saya.

Saya akan menyarankan untuk memberikan opsi untuk unit (hari, bulan, tahun) dan nomor. Misalnya saya ingin memiliki akumulasi bergulir 2 tahun saya karena berlari adalah permainan yang panjang. Selain itu, akan lebih baik untuk memberikan opsi untuk melapisi 2-3 parameter yang berbeda, misalnya 30 hari & 1 tahun di atas satu sama lain karena yang terakhir adalah versi yang lebih "halus" dari yang pertama. Tentu saja agar sumbu y masuk akal, seseorang perlu memplot nilai rata-rata bukan total karena totalnya sangat berbeda. Rata-rata dapat ditampilkan per minggu yang dilacak oleh banyak pelari. Jadi di tabel saya di atas 3000mi/tahun sesuai dengan 58/minggu. Jadi jika Anda merencanakan 30 hari & 1 tahun di atas satu sama lain, Anda akan melihat seberapa jauh Anda menyimpang dari target 58 mil/minggu.

"Mode Rolling Streak" akan berlaku untuk semua jenis kemajuan: jarak , waktu , ketinggian & hitungan .

Kedengarannya bagus dan itu masuk akal.

Saya masih tidak tahu apa yang bisa kita tampilkan di tabel (sebelah kanan)? Delta bergulir antara tahun? Bagaimana dengan target?

Saya tidak memasukkan ini pada tabel di atas tetapi saya juga melacak berapa lama waktu yang dibutuhkan untuk mencapai ambang batas atau delta berikutnya seperti yang Anda katakan. Seseorang tidak ingin bergerak dari ambang batas ke ambang terlalu cepat karena ini adalah resep untuk cedera / kelelahan. Apa yang dapat saya tawarkan di sini adalah akan menyenangkan untuk memiliki ambang batas yang dapat diatur pengguna baik secara total (1000, 2000, 3000mi dll) atau per minggu (10, 20, 30mi dll) dan kemudian menampilkan berapa hari atau bulan Anda telah melewati ambang batas yang merupakan sesuatu yang akan meningkat setiap hari.

Saya akan mengawasi utasnya dan sekali lagi terima kasih telah bersedia untuk memperkenalkan kembali fitur yang luar biasa ini!

• "Mode Kumulatif Standar" yang saat ini ada di aplikasi

Saya juga menyarankan dalam mode standar untuk menambahkan opsi untuk opsi bulanan bukan hanya tahunan. Banyak pelari berlomba di balapan yang sama dari tahun ke tahun, jadi akan menyenangkan untuk memiliki "reset" per bulan untuk membandingkan bagaimana akumulasi Januari 2019 ditumpuk dengan akumulasi 2018 jika itu masuk akal. Pada titik ini semua ini adalah fitur creep :) jadi saya akan lebih dari senang jika Anda mengembalikan fungsi sebelumnya :)

Sebenarnya bagaimana dengan "Rolling Sum" yang sederhana ? Modus standar lebih seperti "Jumlah YTD" (Tahun Sampai Saat Ini). Hanya pemikiran saja.

Jadi saya memulai pengembangan 2 hari yang lalu.

Saya menggunakannya saat ini:

export enum ProgressionMode {
    STANDARD_CUMULATIVE,
    ROLLING_CUMULATIVE
}

@mathin "Jumlah Bergulir" & Tahun Sampai Saat Ini" tampaknya memang jauh lebih sederhana. Saya dapat mengaktifkan ini. Apa yang Anda pikirkan orang lain?

Beberapa hasil di sini !! :) Saya selesai mengkode logika arus utama melalui TDD. Dan setelah beberapa bypass di UI, inilah beberapa hasilnya:

"Jumlah Bergulir 30 hari"

"Jumlah Bergulir 3 Bulan" :

"Jumlah Bergulir 1 Tahun" :

" Jumlah

Dan warisan "Jarak 30 hari terakhir" untuk dibandingkan dengan

Itu terlihat sempurna, terima kasih banyak karena telah mengimplementasikan sesuatu dengan sangat cepat!

Anda dapat memvalidasi perilaku saat ini dengan pengujian unit di sini: https://github.com/thomaschampagne/elevate/blob/1f48cd28c5c111c6fe826ae6da6b79d8050c583e/plugin/app/src/app/year-progress/shared/services/year-progress.service.spec .ts#L537

Dan metode di sini: https://github.com/thomaschampagne/elevate/blob/1f48cd28c5c111c6fe826ae6da6b79d8050c583e/plugin/app/src/app/year-progress/shared/services/year-progress.service.ts#L200

Beberapa hasil di sini !! :) Saya selesai mengkode logika arus utama melalui TDD. Dan setelah beberapa bypass di UI, inilah beberapa hasilnya:

Itu benar-benar menakjubkan! Terima kasih banyak, saya tidak sabar untuk mulai menggunakan metrik baru!

Satu pertanyaan/komentar kecil. Ketika saya membandingkan (hanya secara visual tentu saja) warisan "Jarak 30 hari terakhir" dengan "Jumlah Bergulir 30 hari" yang baru, menurut saya "Jumlah Bergulir" lebih "bergerigi" atau sebaliknya bahwa warisan "30 hari terakhir" terlihat sedikit lebih halus. Apakah ini hanya artefak dari fungsi plot atau apakah ada pemulusan data tambahan yang terjadi pada kode lama?

Terima kasih lagi!!!

@mathin Ini hanya mode d3 curveLinear yang saya gunakan: https://github.com/d3/d3-shape#curveLinear

Menggunakan _curveNatural_ memberikan bahwa:

@matin lagi. Tentang permintaan Anda:

Selain itu, akan lebih baik untuk memberikan opsi untuk melapisi 2-3 parameter yang berbeda, misalnya 30 hari & 1 tahun di atas satu sama lain karena yang terakhir adalah versi yang lebih "halus" dari yang pertama. Tentu saja agar sumbu y masuk akal, seseorang perlu memplot nilai rata-rata bukan total karena totalnya sangat berbeda. Rata-rata dapat ditampilkan per minggu yang dilacak oleh banyak pelari.

Tampaknya jauh lebih sulit untuk melakukannya "cepat", mungkin melacaknya di edisi baru untuk dilakukan nanti.

Jadi di tabel saya di atas 3000mi/tahun sesuai dengan 58/minggu. Jadi jika Anda merencanakan 30 hari & 1 tahun di atas satu sama lain, Anda akan melihat seberapa jauh Anda menyimpang dari target 58 mil/minggu.

kamu kehilangan aku :)

Beberapa pembaruan UI dan "6 Weeks Elevation Rolling Sum" :

Ini terlihat sangat bagus dan menjanjikan!
Saya lebih suka jumlah bergulir 4 minggu selama 30 hari/1 bulan, dan 13 minggu selama 3 bulan.
Karena kebanyakan orang biasanya berolahraga pada hari yang sama dalam seminggu.
Menggunakan ritme minggu setiap trip di hari minggu menggantikan trip hari minggu X-back, sehingga garis akan jauh lebih halus dan goyangan berkurang.

Saya lebih suka jumlah bergulir 4 minggu selama 30 hari/1 bulan, dan 13 minggu selama 3 bulan.
Karena kebanyakan orang biasanya berolahraga pada hari yang sama dalam seminggu.

Itu adalah poin yang bagus, saya juga ingin melihat jumlah bergulir 4 minggu, bukan 30 hari. Dan BTW, saya pikir Anda bermaksud menulis 12 minggu bukan 13 kan?

@bkleingoldewijk @matin Anda dapat memilih periode yang Anda inginkan. Kalikan saja dengan angka yang Anda butuhkan.

Bagus sekali!

Bob

dikirim dari iPhone saya

Op 12 feb. 2019 om 18:57 heeft Thomas Champagne < [email protected] [email protected] > het volgende geschreven:

@bkleingoldewijk https://github.com/bkleingoldewijk @mathin https://github.com/mathin Anda dapat memilih periode yang Anda inginkan. Hanya beberapa dengan nomor yang Anda butuhkan.

[gambar] https://user-images.githubusercontent.com/151973/52657012-f395ee80-2ef7-11e9-81c4-5b43b4792c70.png

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/thomaschampagne/elevate/issues/760#issuecomment-462865891 , atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/AtN0S2opo7- OK64kFII6bAM1C2Dc1tzRks5vMwCMgaJpZM4ako11 .

Saya juga penggemar berat dari 30 hari dan 365 hari yang bergulir. Namun saya juga akan mengatakan bahwa 4 minggu dan 52 minggu bergulir akan lebih informatif karena saya cenderung memiliki pola bersepeda yang sama dalam seminggu. Terimakasih banyak.

Ada masalah dengan warna dan kontras. Saat ini 2019 pada grafik saya menggunakan warna yang sangat gelap dengan latar belakang yang sangat gelap. Pemilihan warna perlu lebih hati-hati, atau memiliki opsi untuk memilih dari palet.

@jfhaugh palet "bergulir" didefinisikan di sini: https://github.com/thomaschampagne/elevate/blob/develop/plugin/app/src/app/year-progress/year-progress.component.ts#L43

Anda dapat memberi saya daftar Anda;)?

(harus bekerja juga pada tema ringan)

Mungkin membantu: https://color.adobe.com/create/color-wheel/

Berikut adalah progresi Rolling & Year pertama yang dapat diuji

v6.9.2_stable_2019-02-23-14-06.zip

Catatan: Untuk menghindari sinkronisasi baru, Anda dapat menggunakan cadangan elevasi "resmi" Anda untuk memulihkannya ke build itu.

Tentu saja bantuan Anda sangat diharapkan untuk:

• Temukan bug pada kasus umum dan bengkok
• Berikan saya ide/teks untuk meningkatkan pemahaman fitur (terutama progresi bergulir yang tentu saja rumit bagi sebagian besar pengguna). Misalnya "Di bawah tombol Anda harus menulis ini: ", "Tambahkan tooltip hover * dan tampilkan * *", dll...
• Berikan saya konten dialog pembantu (ditampilkan saat Anda mengklik tombol (?))
• Perbaiki bahasa inggris saya :)

Terima kasih atas bantuan dan pengujian Anda :)

Sudah lama menunggu metrik bergulir — bagus

Tab Kemajuan Tahun

• akan lebih baik lagi jika untuk pilihan "Tahun", seseorang bisa..
  
  
  
  • Pilih Semua
  
  
  • batal pilih semua
  
  
  • pilihan sebaliknya
  
  
  • 5 tahun terakhir (misalnya)
    
    (Catatan: database saya kembali ke tahun 2003, tetapi data menjadi semakin jarang saat saya kembali ke masa lalu. Ini menciptakan banyak gangguan dalam grafik. Juga sulit untuk memilih atau membatalkan pilihan kotak centang selama hampir 20 tahun)
  
  

• Periode bergulir adalah salah satu fitur terbaik dari perangkat lunak ini. Tendangan pantat.
  
  
  
  • jendela waktu geser yang dapat disesuaikan akan sempurna
  
  
  • atau, termasuk 4 minggu atau 30 hari
  
  

Pertahankan kerja bagus!

Saya memperbarui fitur pembantu jika Anda dapat melihat peningkatan teks dan bahasa Inggris

File sumber yang dapat Anda edit dan kirim kembali: https://github.com/thomaschampagne/elevate/blob/9632d6b28a4a7cfe57b1099c031f9856ae8c2855/plugin/app/src/app/year-progress/year-progress-helper-dialog/year-progress- helper-dialog.component.html

@thomaschampagne sekali lagi terima kasih telah merilis fungsi baru yang luar biasa ini!

Saya punya masalah kecil untuk dilaporkan. Suatu hari, saya mengatur interval bergulir menjadi 1 hari dan melihat grafik saya. Saya terkejut melihat nilai 30mi+ yang tampak agak aneh karena saya bukan pria ultra. Saya tidak pernah berlari lebih dari satu maraton (hanya pada hari perlombaan) dan bahkan termasuk pemanasan sebelum perlombaan (maks 1 mil) saya tidak akan pernah melebihi maksimum 27-28 mil dalam satu hari, dan tidak pernah lebih dari 30 mil. Setelah pemeriksaan lebih lanjut, saya menemukan bahwa hari 30 mil terjadi ketika saya telah menjalankan lari panjang 22 mil dan hari sebelumnya lari mudah 8 mil dengan total 30 mil.

Ini membuat saya menyadari bahwa interval bergulir dapat diterapkan setiap jam. Artinya, mungkin lari 22mi dan 8mi terjadi dalam waktu kurang dari 24 jam dari satu sama lain (tetapi pada hari yang berbeda) sehingga mungkin dihitung pada interval bergulir 1 hari yang sama. Prinsip yang sama tampaknya berlaku pada semua interval bergulir mengenai jumlah hari/minggu dll. Ini terdengar seperti fungsi "benar" untuk diterapkan tetapi dalam praktiknya "kuantisasi" interval bergulir mungkin akan lebih bermanfaat.

Satu saran adalah mengkuantisasi interval pada tengah malam sehingga katakanlah interval 2 hari menghitung tengah malam hingga tengah malam alih-alih bergulir dalam sehari. Saya harap itu masuk akal.

Sekali lagi terima kasih dan beri tahu saya tentang pemikiran Anda dan jika saya perlu mengklarifikasi sesuatu.

@matin Anda mungkin benar. Itu bisa berasal dari kurma. Bisakah Anda membuat tiket baru untuk potensi bug ini? Dan tautkan saya id/tanggal cadangan + aktivitas yang lebih tinggi di mana masalahnya bisa terjadi.

@matin Anda mungkin benar. Itu bisa berasal dari kurma. Bisakah Anda membuat tiket baru untuk potensi bug ini? Dan tautkan saya id/tanggal cadangan + aktivitas yang lebih tinggi di mana masalahnya bisa terjadi.

Hai @thomaschampagne . Saya akan melakukan apa yang Anda minta tetapi saya tidak tahu caranya (cadangan+id/tanggal dll). Jika Anda mendapatkan waktu untuk memperbaiki fungsionalitasnya, itu akan bagus, tetapi saya tidak berharap Anda melakukannya karena saya mengerti ini adalah proyek kesayangan Anda. Terima kasih sekali lagi untuk fungsionalitas yang luar biasa!