Search This Blog

Theme images by MichaelJay. Powered by Blogger.

Blog Archive

Wednesday, January 30, 2019

REV.IEW
  • branding
  • web
The outdated brand image of the Finnish company producing water and electricity metering solutions required to give it the character and to make out the basic publishing rules.

The scope included refreshing the logotype, creating the brandbook and designing the whole new, onepage website.
Done at Tonik.



Learn more
Monday, January 28, 2019



di artikel ini, saya ingin menunjukkan kepada Anda bahwa dengan mempelajari tentang batasan teknis & aspek pengembangan, Anda akan dapat menyertakan lapisan tambahan yang berharga untuk pekerjaan desain Anda & untuk berkolaborasi dengan pengembang secara lebih efektif.

Mengapa mempelajari dasar-dasar pengembangan itu penting?
Jika Anda seorang perancang UX (perancang interaksi, perancang produk, perancang layanan, perancang UI - label Anda tidak terlalu penting), kemungkinan besar Anda sedang mengerjakan produk atau layanan digital. Dengan kata lain, Anda membuat produk perangkat lunak.

Menurut pengalaman saya, ini adalah fakta yang sering diabaikan: Anda, sebagai desainer, berkontribusi pada proses pengembangan perangkat lunak. Dan tanpa mengetahui apa yang ada di balik tudung, Anda tidak akan dapat membuat keputusan desain yang terinformasi.

Secara historis pekerjaan desain dilakukan oleh pengembang produk perangkat lunak. Melibatkan desainer secara efektif merupakan tantangan besar. Di satu sisi, sulit untuk sepenuhnya mengintegrasikan kegiatan desain, dan tetap menyelaraskan desain dan pengembangan. Di sisi lain, di sebelah aspek proses pengembangan produk, Anda dapat berpikir tentang integrasi ini di tingkat yang lebih rendah: setiap peserta dari proses pengembangan perangkat lunak harus memahami apa yang mereka bangun. Dan ini adalah salah satu alasan mengapa pertanyaan terkenal "Haruskah desainer belajar kode?" Telah diajukan berkali-kali baru-baru ini.]



Saya percaya bahwa ini bukan pertanyaan yang bagus. Inilah beberapa yang lebih baik:

Haruskah desainer memahami biaya, risiko, trade-off dari keputusan desain?
Haruskah desainer tahu cara kerja pengembang, tantangan apa yang mereka hadapi, apa tugas utama mereka?
Dan jawabannya adalah: ya! Tentu saja memahami dasar-dasar dan kemampuan misalnya Javascript mungkin menjadi nilai tambah dalam beberapa kasus, tetapi itu tidak berarti bahwa Anda harus belajar menulis kode siap produksi.

Baik desainer maupun pengembang memiliki kompetensi dan tanggung jawab inti mereka. Anda bekerja bersama, Anda memiliki tujuan yang sama, Anda berdedikasi untuk proyek yang sama, Anda bekerja sama sebanyak mungkin. Namun, Anda harus saling menghormati pengetahuan dan keahlian.

Desain tidak boleh diubah menjadi desain oleh komite, dan desainer tidak boleh memberikan instruksi kepada pengembang tentang cara menulis kode mereka.

Saya percaya bahwa hal yang paling penting adalah membangun rasa saling percaya: pengembang harus tahu bahwa Anda memahami risiko, biaya, trade-off dari keputusan desain, sehingga Anda tidak akan menanyakan hal-hal yang tidak masuk akal, dan Anda akan merasa bahwa mereka menang ' t mencoba menghindari penyelesaian masalah yang lebih kompleks.

Jadi, alih-alih mempelajari cara membuat kode, Anda harus melakukannya

memahami dasar-dasar pembangunan dan
bekerja sama erat dengan pengembang.
Memahami kendala teknis utama, batasan, dan aspek pengembangan yang paling penting bermanfaat bagi setiap desainer, apakah Anda seorang freelancer atau karyawan yang bekerja di sebuah startup kecil, di agensi atau di organisasi besar.

Mempelajari cara berkolaborasi secara efektif bermanfaat bagi para perancang yang bekerja dalam tim atau dengan profesional lain secara teratur. Dan ini adalah bagaimana kedua tujuan ini berkaitan erat: memahami kendala teknis dan aspek pengembangan akan membantu Anda meningkatkan cara Anda bekerja sama dengan pengembang.

Learn more
Friday, January 25, 2019



Setiap melamar pekerjaan maupun internship sebagai Software Engineer pastilah di fase saringan awal harus menjalani coding test di platform seperti Hackerrank atau Codility sebelum lanjut ke tahap interview HR dan user (kalau lolos).

Nah, coding test disini ada beberapa macam, basic programming test maupun yang bertipe mini project assignment. Ini bisa saja berbeda-beda tergantung perusahaannya, ada yang cuma basic programming test aja, ada yang mini project assignment aja, atau keduanya. Kebetulan saya pernah dapat 2 macam itu sekaligus 😥.

Oke, langsung aja tipsnya.

Latihan
Harusnya sudah self explanatory sih. Tapi ya sudah, saya jelaskan lagi saja. Sebelum menjalani coding test, terutama yang basic programming test di Hackerrank atau Codility maupun whiteboard coding, harus latihan-latihan dulu. Seminggu lah minimal. Test semacam ini biasanya menuntut kita untuk membuat suatu algoritma yang efisien untuk menyelesaikan masalah yang telah ditentukan sebelumnya dan menguji kemampuan problem solving, jadi perlu banyak latihan mengerjakan soal-soal seperti di Hackerrank, SPOJ, atau penyedia online judge lain. Lakukan simulasi whiteboard coding sama teman yang sekiranya jago coding, jika diperlukan dan jika melamar pekerjaan di perusahaan seperti Google, Facebook, dan Traveloka.

Pelajari kembali pelajaran struktur data maupun desain dan analisis algoritma, karena tipe soalnya tidak jauh-jauh dari dua hal tersebut dalam melewati online coding test maupun whiteboard coding.

Khusus yang bertipe mini project assignment, kalau sering coding bikin aplikasi yang bisa dipakai orang, harusnya tidak akan jadi rintangan yang berarti. Pelajari lagi pelajaran tentang design pattern maupun architectural pattern seperti MVC, MVP, MVVM, atau arsitektur yang lain. Sertakan pula unit testnya jika diperlukan dan/atau diwajibkan.

Kerjakan dengan jujur
Di platform seperti Hackerrank atau Codility, jawaban kita direkam. Ketika kita mengetik source code di editor mereka juga direkam. Mereka punya fitur playback yang bisa dipakai ketika perusahaan melakukan review hasil pekerjaan tiap kandidat setelah coding test selesai.

Jadi sudah cukup jelas, dilarang kopas. Kopas dari internet, kopas kerjaan teman maupun kopas dari IDE (walaupun mengerjakan sendiri). Saya telah mengalaminya 2x, karena waktu itu belum tahu kalau jawaban kita direkam, mengerjakan dari IDE, lalu source code dikopi dari IDE ke editor yang telah mereka sediakan. Hasilnya apa? Saya gagal di tahap online test.

Bagi yang sering kopas kerjaan temannya ketika kuliah atau praktikum, harap segera tobat ya.

Tidak meremehkan
Ya walaupun yang diujikan sering kali materi dasar, jangan sekali-kali meremehkan test semacam ini. Kebanyakan yang ada malah gagal karena terlalu pede, dan tidak memahami bahkan cenderung melupakan materi dasar seperti algoritma dan struktur data.

Berpikir positif dan berdoa
Ini juga self explanatory harusnya. Kita harus senantiasa berpikir positif supaya aura positif bisa menyertai kita semua. Hal non teknis semacam ini seringkali berpengaruh terhadap keberhasilan dalam melewati test. Rajin berdoa dan ibadah supaya senantiasa diberikan kemudahan dan hasil yang terbaik.

Jadi itu beberapa poin dari saya untuk dapat menghadapi coding test ketika proses rekrutmen. Semoga bermanfaat bagi yang membutuhkan.

Learn more



Jadi, yang belum tahu Software Engineer itu apa, yaitu seseorang yang menerapkan prinsip dan best practice pada software engineering dalam proses perancangan, pengembangan, pengujian, dan perawatan sebuah perangkat lunak.
Cukup intronya ya.

Awal mengenal programming

Sebenarnya, saya mulai mengenal programming sejak SMP. Jangan bayangkan ketika SMP sudah bisa coding hal yang sophisticated, macam bikin sistem informasi, ataupun aplikasi mobile. Big no. Saya mulai mencoba belajar coding waktu itu menggunakan bahasa Pascal, dengan compiler FPC. Dulu belajarnya di portal milik Tim Olimpiade Komputer Indonesia, lupa linknya tapi.
Berlanjut hingga SMK, pada waktu itu dikirim oleh sekolah untuk ambil bagian dalam OSN tingkat kabupaten bidang komputer. Bayangan awal, ini soalnya tak jauh dari materi umum seputar IT dan programming. Big no. Tetap ada programming, cuman soalnya lebih ke arah debugging, alias baca codingan, dan soal yang berkaitan dengan matematika, macam kombinatorika, aljabar maupun logika matematika.

Jaman kuliah

Setelah lulus SMK, saya pun diterima di BINUS, disaat yang bersamaan saya akhirnya memutuskan mengundurkan diri dari seleksi Taruna Akpol.
Di kuliah pun berlanjut belajar coding juga, bahasanya Java waktu itu. Di saat itu, saya masih belum punya bayangan untuk jadi apa setelah lulus, masih punya mindset mahasiswa pada umumnya, cari nilai bagus. Belajar pas kuliah saja, pernah pula jadi budak proker. Masa kelam hehe.
Saya akhirnya dipertemukan dengan teman-teman yang lebih dulu jago coding, macam Fathony, Imam, Arrizal, Mas Echa, dan banyak lagi. Beruntung saya masih punya rasa malu, mereka sudah jago, masa saya masih segini-gini aja. Saya pun bertekad untuk bisa jago seperti mereka.

Memulai belajar

Untuk bisa mengejar ketertinggalan, saya pun harus belajar diluar materi kampus. Pernah waktu itu saya belajar coding Android pada Android Student Club, yang diadakan oleh Google Student. Belum ada Android Kejar waktu itu, sekitar tahun 2015. Pernah pula belajar coding web pakai PHP. Di saat inilah, saya masih bingung mau mendalami yang mana, belajar juga masih moody. Masa kelam juga.

Looking for opportunity

Saya tidak bisa seperti ini terus. Akhirnya, saya pun memberanikan diri cari part time job sebagai programmer. Saya menilai, kerja part time jadi programmer akan ngeboost skill dengan cepat, karena pressure kerja yang mungkin saja besar.
Pernah suatu waktu, saya ikut seleksi dengan AdIns. Hingga 3 kali ikut seleksi, gagal. Bingung juga, gagalnya dimana, test paper coding bisa jawab, interview lancar. Ya sudah, mungkin belum rejeki.
Akhirnya terbesit keinginan, untuk belajar coding iOS, terlihat menjanjikan untuk masa depan. Ya sudah, hutang ke emak 8 juta, buat beli MacBook bekas. Dari sini pun saya mulai belajar coding iOS.
Setelah belajar hal-hal basic, macam belajar Swift, layouting pakai Auto layout, penyakit di masa kelam kambuh lagi. Belajar setengah-setengah dan moody. Saatnya harus cari tantangan dan pressure.

Journey begins

Ketemu dengan Hilmi, waktu itu dia sudah part time di Gumcode sebagai Android Engineer, iseng lah tanya, ada lowongan iOS tak? Langsung dah di rekomin dan akhirnya perjalanan karir sebagai software engineer dimulai. Sekitar Q3-Q4 tahun 2016 alias kuliah semester 4.
Projek pertama saya waktu itu mengerjakan aplikasi ojek online MangJek, dengan target pasar di Palembang (sayangnya, sekarang sudah defunct). Awal mengerjakan, bingung setengah mati masalah layouting, initiate network request nya bagaimana, mengatur flownya bagaimana, dan lain-lain. Lebih dari 6 bulan berjalan, aplikasi akhirnya rollout ke production. Milestone besar pertama saya, bisa mengatasi segala kendala waktu development dan publish aplikasi iOS di App Store, walau pakai akun klien.

Looking for opportunity, again

Setelah projek selesai, saya pun akhirnya menganggur. Saya tidak bisa menganggur terlalu lama, karena bikin skill tumpul. Akhirnya, saya coba apply sebagai iOS developer di DOT Indonesia, dengan harapan dapat tantangan baru, dan benefit yang lebih baik.
Hasilnya, saya belum diterima menjadi bagian dari DOT, mungkin belum rejeki lagi.

Sederet kegagalan

Saya bisa mencapai titik ini bukan tanpa halangan. Setidaknya, saya pernah gagal sebanyak 10 kali dalam perjuangan membangun karir sebagai software engineer. Diantaranya adalah:
  • 3 kali gagal AdIns
  • 1 kali gagal DOT
  • 1 kali gagal Tokopedia (no feedback after online test)
  • 1 kali gagal Technobit Indonesia (no feedback)
  • 2 kali gagal Blibli, campus hiring & future program (kalau tak salah ingat, gagal setelah online test & psychotest)
  • 1 kali gagal SE Intern Traveloka (no feedback after online test)
  • 1 kali gagal GO-JEK (no feedback after apply via LinkedIn)
  • 1 kali gagal Bukalapak Scholarship 2017 (failed at final test)
Kegagalan yang saya alami ada yang memang kurang beruntung saja, ada pula yang memang saya kurang maksimal pada waktu tes (seperti yang saya alami waktu seleksi beasiswa BL, kurang bisa mengelola waktu dengan baik ketika mengerjakan).
Dan akhirnya, sederet kegagalan ini saya jadikan pelajaran untuk tidak mengulangi kesalahan yang sama, dan sebagai pemacu untuk terus banyak belajar dan mempersiapkan diri dengan maksimal sebelum proses seleksi.

Akhirnya menjadi Nakama Tokopedia

Saya pernah gagal test di Tokopedia, mungkin gara-gara test onlinenya jelek, makanya tidak ada feedback setelahnya. Pada waktu skripsi 50–60%, saya akhirnya apply via LinkedIn, juga apply ke GO-JEK yang akhirnya cuma dikacangi (mungkin requirement nya kurang masuk).
Akhirnya setelah apply, dapat lah link test Codility untuk dikerjakan. Setelah test Codility, diberitahu seminggu kemudian untuk interview user. Interview user ini yang dibahas seputar technical. Setelah interview, akhirnya menunggu agak lama hingga mengantongi offering letter.
TMT 26 Februari 2018 saya akhirnya mulai join, dan menjalani probation selama 3 bulan, dan Alhamdulillah lulus probation, dan lanjut hingga sekarang. Banyak yang saya pelajari dan mendapat banyak pengalaman dari sini, mulai bagaimana caranya coding dengan benar, mengimplementasikan berbagai design pattern & arsitektur yang ada, collaboration workflow, mengelola task dengan maksimal supaya tidak lewat timeline, kolaborasi dengan Product Owner, Test Engineer, UI/UX, dan sesama engineers, bergabung ke tim interviewer user, hingga menjadi mentor kelas iOS development untuk iOS Test Engineer Team.

Target kedepannya

Saya ingin belajar banyak diluar iOS development, seperti belajar backend, distributed computing, microservice, hingga scalability. Tak menutup kemungkinan pula untuk belajar untuk bisa menjadi servant leader suatu saat nanti.
Semoga bisa mencapai level yang lebih tinggi lagi di suatu saat nanti, seiring meningkatnya jam terbang, pengalaman maupun skill.

Penutup

Meminjam motto Kopaska TNI AL, yang berbunyi Tan Hana Wighna Tan Sirna.
Dalam perjuangan dalam menggapai impian dan cita-cita, pasti ada rintangan, dengan tekad dan keyakinan yang kuat, rintangan yang ada dapat diatasi.
Kegagalan yang bisa terjadi ketika berproses merupakan sebuah pembelajaran yang berharga, agar tidak terjatuh di kesalahan yang sama dan sebagai pelecut untuk lebih baik lagi dari sebelumnya.
Selagi punya impian dan cita-cita, tugas kita adalah berjuang supaya impian dan cita-cita bisa tercapai, dan berdoa kepada Tuhan supaya diberikan jalan dan hasil yang terbaik.
Man jadda wajada.

Learn more
Monday, January 21, 2019



Kembali ke Q3 / Q4 2016, ketika saya masih menjadi siswa tahun ketiga, saya memiliki kesempatan untuk mulai membentuk karier saya sebagai pengembang perangkat lunak, terutama untuk pengembangan iOS. Pada waktu itu, sebelum saya merujuk oleh teman baik saya dan juga ahli Android, saya tidak pernah melakukan pemrograman di lingkungan Apple, saya tidak pernah mengkode aplikasi iOS sebelumnya, baru mulai mempelajari permukaan pengembangan iOS, dan berhenti karena beberapa kegiatan di perguruan tinggi .

Dan, saya ditunjuk untuk menangani pengembangan aplikasi online ojek mereka untuk perangkat iOS (tetapi sampai sekarang, aplikasi itu tidak berfungsi), dan itu sangat melelahkan bagi saya, untuk pertama kalinya mengerjakan proyek besar tanpa pengalaman sebelumnya dalam pengembangan iOS . Dillema, saya bisa menyelesaikan proyek itu atau tidak pernah, karena kemampuan saya yang terbatas saat itu.

Hal pertama yang membuat saya kewalahan di dunia pengembangan iOS saat itu adalah Auto Layout. FYI, tata letak otomatis adalah sistem tata letak berdasarkan kendala yang diterapkan pada komponen UI pada tampilan Anda, yang membuat kami membuat tata letak tetap konsisten & responsif pada berbagai ukuran layar perangkat, misalnya, tombol Masuk harus diletakkan di bagian bawah bidang teks kata sandi dengan offset 20 poin, dengan tinggi 45 poin, dan inset kiri kanan diatur ke 45 poin untuk superview. Itu seperti, wtf, mengapa membuat tata letak tidak ringkas dan mudah, dibandingkan dengan tata letak berbasis Android XML. Setelah saya berjuang untuk mempelajari tata letak Otomatis, disertai dengan berbagai bahan bacaan di Apple docs, raywenderlich.com, dan banyak solusi Stack overflow, maka saya memiliki pemahaman yang lebih baik tentang hal itu. Oh, itu tidak sesulit yang dibayangkan sebelumnya, dan sekarang saya menikmatinya.

Tata Letak Otomatis dipelajari bersama dengan belajar cara membuat tata letak UI untuk aplikasi iOS, menggunakan Storyboard, XIB, atau kode. Saat itu, saya menggunakan storyboard untuk menyelesaikan proyek. Sangat menarik dan menyenangkan, membuat UI di storyboard, menentukan navigasi, tapi saya tidak suka lagi sekarang. Sampai sekarang, saya lebih suka membuat tata letak UI baik dalam XIB atau kode lengkap. Selain belajar cara membuat tata letak UI, maka saya belajar tentang View Controller yang mengelola tampilan, menangani interaksi pengguna, menyajikan tampilan, dan juga memahami siklus hidup mereka.

Setelah saya mempelajari beberapa hal tata letak UI, saya mulai belajar, bagaimana membuat panggilan jaringan. Apple telah menyediakan URLSession untuk melakukan panggilan jaringan, tetapi bagi saya, itu terlalu rumit dan sulit dimengerti, dan pilihan saya adalah, Alamofire. Itu adalah perpustakaan yang bagus untuk membuat panggilan jaringan, mudah digunakan, dan ringkas. Saat itu di tahun 2016, saya sering menggunakan SwiftyJSON untuk memetakan data respons ke kamus (pada waktu itu, saya tidak tahu bagaimana memetakan respons ke struct, lol). Waktu berlalu, kemudian Codable muncul, dengan Swift 4.

Jangan lupa untuk mempelajari Grand Central Dispatch untuk menangani konkurensi, mengirim antrian, dan juga untuk tujuan multithreading.

Pada saat itu, kembali ke ketika saya pertama kali memulai pengembangan iOS, saya tidak pernah mempertimbangkan tentang kualitas kode, testability, dan juga pemisahan perhatian. Semuanya dimasukkan ke View Controller, lol.

Setelah itu, saya mulai belajar hal baru. MVVM dan RxSwift. Saya menggunakan arsitektur itu dan pustaka reaktif itu pada proyek & tujuan pembelajaran kedua saya. Kesan pertama? Wah, bagus.

Sebagai contoh, ketika saya membuat UITableView, untuk memberi makan tampilan tabel dengan data kami, kami biasanya membuat objek terpisah (atau VC itu sendiri) menjadi delegasi tampilan tabel dan sumber data, sehingga tampilan tabel dapat meminta delegasikan dan sumber data untuk mengelola aksi tampilan tabel atau mengumpankan data. Dengan RxSwift, saya hanya menggunakan kode berikut untuk memberi makan data, dan mengembalikan sel masing-masing


Tetapi, penggunaan RxSwift tidak hanya untuk memberi makan tampilan tabel secara reaktif, itu lebih dari itu, misalnya digunakan untuk aliran data antara satu lapisan ke lapisan lain, atau mengemudi UI.

Oke, MVVM dan RxSwift sudah selesai, jadi apa yang saya pelajari selanjutnya?

Mempelajari konsep arsitektur bersih, pengujian unit, menerapkan prinsip-prinsip SOLID, dan juga tertarik untuk bereksperimen dengan arsitektur VIPER, sepertinya menarik, bukan?

Ringkasan
Jadi, saya mulai belajar pengembangan iOS dengan hal-hal ini:


  • beli mac
  • belajar membuat tata letak UI
  • tata letak otomatis
  • mengikat tata letak UI di XIB / Storyboard ke kode
  • lebih banyak komponen UIKit
  • pengiriman grand central
  • panggilan jaringan
  • arsitektur selain MVC
  • RxSwift
  • pengujian unit

dan banyak hal ...: D
Jadi, jika Anda ingin mempelajari pengembangan iOS, pastikan Anda memiliki Mac terlebih dahulu, lalu baca dokumentasi resmi Apple, baca tutorial dan konsep lain, dan mulailah kode. Ciao

Learn more
Tuesday, January 8, 2019

Setiap kali saya mulai membaca kisah sukses, saya akan segera mencari untuk menemukan latar belakang penulis, berharap itu akan cocok dengan saya. Saya tidak pernah menemukan seseorang yang memiliki latar belakang yang sama dengan saya, dan kemungkinan besar saya tidak akan sama persis dengan Anda.

Meskipun demikian, saya berharap cerita saya menginspirasi orang lain dan bertindak sebagai titik data berharga yang dapat ditambahkan ke dataset kisah sukses Anda.

Pengungkapan penuh
Saya mengambil kursus Visual Basic for Applications (VBA) di sekolah menengah (sembilan tahun yang lalu). Dalam kursus teknik mahasiswa baru saya (tujuh tahun lalu), saya belajar beberapa C, Python, Matlab, dan Labview. Saya lulus dari universitas yang bagus dengan gelar teknik kimia dan IPK yang baik (tiga tahun lalu). Saya belum melakukan pemrograman apa pun di luar sekolah, di sekolah menengah atau perguruan tinggi, sampai saya memutuskan ingin belajar tahun lalu.

Setelah lulus, saya mendapat pekerjaan sebagai Engineer Proses di sebuah kilang. Saya bekerja di sana sampai saya mengubah karier menjadi Rekayasa Perangkat Lunak.

Mengapa saya ingin berganti karier

Saya menikmati pemecahan masalah teknis, tetapi saya tahu saya ingin masuk ke dunia bisnis / startup di beberapa titik. Saya selalu mengingat gelar MBA di benak saya, tetapi setiap kali saya melihat label harga sekolah-sekolah top, minat saya berkurang.

Pada tanggal 27 Mei 2017 saya menemukan diri saya googling tentang MBA lagi, dan entah bagaimana saya menemukan rekayasa perangkat lunak. Sepertinya sangat cocok.

Insinyur perangkat lunak dalam permintaan yang meningkat, gaji yang besar, dan itu adalah industri yang sempurna untuk masuk ke dunia startup tanpa perlu satu ton modal awal. Yang Anda butuhkan hanyalah komputer, dan peluang Anda tidak terbatas (semacam).

Dalam disiplin ilmu teknik lain, Anda tidak dapat memiliki ide, mulai membangunnya, menunjukkannya kepada pengguna, dan beralih dengan modal kecil dan hambatan masuk yang rendah. Dalam teknik kimia, Anda pada dasarnya membutuhkan pabrik berjalan atau banyak uang untuk merancang pabrik jika Anda memiliki ide untuk produk baru.

Saya telah mendengar tentang orang-orang yang berhenti dari pekerjaan mereka dan menghadiri bootcamp, tetapi semakin saya membaca tentang itu secara online, semakin saya menyadari bahwa Anda benar-benar dapat mempelajarinya sendiri jika Anda berkomitmen dan fokus.



THE GOAL

Anda harus memiliki tujuan. Terutama jika Anda mencoba belajar sambil bekerja penuh waktu. Sangat mudah untuk membiarkan pembelajaran Anda terus berlanjut jika Anda tidak memiliki tekanan dari luar yang mendorong Anda. Jadi, Anda perlu menciptakan tekanan internal. Tujuan Anda harus sederhana dan kuantitatif. Anda harus melakukan riset yang cukup untuk menghasilkan tujuan yang masuk akal. Milik saya adalah sebagai berikut:

Dapatkan pekerjaan rekayasa perangkat lunak dalam satu tahun dengan gaji yang sama atau lebih baik dari yang saya hasilkan saat ini.

THE PLAN




Setelah Anda memiliki tujuan, Anda perlu rencana untuk membantu Anda sampai di sana. Di sinilah Anda mengkonsumsi kisah sukses sebanyak yang Anda bisa. Tidak satu pun dari mereka akan cocok dengan situasi Anda yang sebenarnya, tetapi Anda dapat mengambil beberapa saran dari masing-masing. Saya mengembangkan (dan mengulangi) rencana saya menggunakan sumber daya seperti subreddit learningprogramming, forum FreeCodeCamp, dan Medium.

Pada 27 Mei 2017 saya memutuskan untuk membuat kode terjun, dan saya terjun terlebih dahulu. Hari itu saya memutuskan untuk mulai memasukkan tidak lebih dari 40 jam per minggu di pekerjaan saya, sehingga saya punya waktu untuk kode setelah bekerja dan pada akhir pekan. Beruntung bagi Anda, saya melakukan pekerjaan yang cukup baik untuk mendokumentasikan kemajuan saya.






Learn more

Hai! Ini adalah Magda dan Maciek. Bersama-sama kami mengelola tim Desain Produk di agensi digital K2. Salah satu tanggung jawab utama kami adalah merekrut desainer baru. Kami telah melakukannya selama lebih dari 10 tahun, jadi kami memiliki banyak pengalaman di bidang ini.

Di sini kami ingin berbagi beberapa saran untuk orang yang mencari pekerjaan baru sebagai Desainer Produk / UX. Tentu tidak perlu di K2. Seharusnya bermanfaat jika Anda melamar pekerjaan di semua jenis organisasi. Kami berhubungan dengan banyak manajer tim desain di berbagai perusahaan dan kebanyakan dari mereka memberi tahu kami bahwa mereka memperhatikan hal-hal serupa.

Artikel ini sebagian didasarkan pada pembicaraan kami dari konferensi UX Poland 2018 di Warsawa. (Anda dapat memeriksa slide kami dari acara ini di tautan berikut, tetapi semuanya dalam bahasa Polandia: https://www.slideshare.net/macieklipiec/jak-zjednac-sobie-ludzi-i-zdobyc-prace-jako-ux -designer.) Pada artikel ini kami ingin menjawab:

Bagaimana proses perekrutan biasanya?
Apa hal paling penting yang dicari manajer perekrutan?
Keterampilan apa yang Anda butuhkan sebagai Desainer Produk / UX?
Bagaimana mempersiapkan CV / resume dan portofolio Anda untuk diundang ke wawancara? (Pikirkan ini sebagai "optimisasi konversi").
Bagaimana cara mendekati wawancara dan tantangan desain akhirnya?
Bagaimana cara memilih perusahaan yang tepat untuk diterapkan? (Kami belum membicarakan hal ini di UX Polandia, karena ini dari sudut pandang kandidat, jadi ini adalah materi bonus.)
1. Seperti apa proses perekrutan?
Di sebagian besar perusahaan prosesnya terlihat hampir sama dengan sedikit variasi. Begini tampilannya di Google:


  • Penyaringan telepon.
  • Ulasan portofolio.
  • Tantangan desain.
  • Rapat di tempat.
  • Pencocokan tim.
  • Menawarkan.

Tentu saja Google adalah perusahaan yang sangat besar dengan banyak kantor di seluruh dunia. Dalam kasus kami lebih sederhana, tetapi semua langkah penting adalah sama. Kami meninjau CV dan portofolio Anda untuk memutuskan apakah kami ingin mengundang Anda untuk rapat di kantor kami atau tidak. Jika kami tidak yakin tentang Anda setelah pertemuan, tetapi kami pikir Anda berpotensi menjadi kandidat yang hebat, kami dapat memberi Anda tantangan desain untuk dipecahkan. Setelah itu kami akan berterima kasih atau mengirimkan penawaran kami kepada Anda. Anda akan menerimanya atau kami akan bernegosiasi.

Di beberapa perusahaan pada tahap awal proses Anda hanya akan berurusan dengan orang-orang SDM, bukan manajer desain, jadi Anda perlu mempertimbangkannya. Dalam kasus kami, kami secara langsung bertanggung jawab atas proses perekrutan dan kontak dengan para kandidat.

2. Apa hal paling penting yang dicari manajer perekrutan?
Itu selalu merupakan jawaban untuk satu pertanyaan mendasar: apakah kandidat cocok dengan budaya, tim, dan proyek perusahaan? Perekrutan adalah semua tentang menemukan kandidat yang paling cocok untuk sebuah perusahaan.

Perusahaan tidak benar-benar mencari "yang terbaik", mereka mencari "yang paling cocok". Anda mungkin perancang yang paling luar biasa, tetapi jika keterampilan, pengalaman, pemikiran, atau kepribadian Anda tidak sesuai dengan kebutuhan perusahaan, maka Anda tidak akan dipekerjakan. Dan dari sudut pandang bisnis murni: perusahaan harus yakin bahwa Anda dapat memberikan nilai lebih daripada biaya.

Kami menghabiskan hampir setengah dari waktu seumur hidup kami di tempat kerja, jadi penting bagi kami untuk berpikir sama dan kami saling menyukai di tempat kerja. Ini benar-benar demi kepentingan kedua belah pihak, perusahaan dan kandidat, untuk mengetahui apakah mereka cocok.

Dan tolong jangan menerima penolakan secara pribadi: sering kali mempekerjakan manajer mungkin berpikir bahwa Anda adalah orang yang sangat keren, tetapi pada saat yang sama tidak perlu cocok dengan perusahaan saat ini. Itu saja.

3. Keterampilan Desainer UX / Produk
Anehnya kami merasa bahwa merekrut UXers sekarang jauh lebih sulit daripada hanya beberapa tahun yang lalu. Mengapa? Karena Pengalaman Pengguna sekarang menjadi topik hangat, banyak orang menyebut diri mereka Desainer UX, terlepas dari keterampilan atau pengalaman mereka.

Apa yang kita miliki saat ini adalah apa yang kita sebut distribusi tidak normal di pasar kerja:

Ada banyak Desainer UI / UX - mantan desainer grafis, yang melamar pekerjaan UX dengan portofolio mereka di Dribbble. Tolong jangan lakukan itu. Tidak ada yang namanya "desain UI / UX". Mereka adalah disiplin ilmu yang jauh berbeda dengan keahlian yang berbeda, dan kami belum pernah bertemu seseorang, yang benar-benar hebat dalam keduanya. Belum lagi, untuk melakukan segalanya pada proyek-proyek serius, Anda harus bekerja setidaknya 16 jam sehari! Di tahun 60-an, Bill Bernbach di DDB memulai sebuah revolusi di industri iklan yang mempekerjakan tim-tim kreatif dari Direktur Seni dan Copywriter. Dia mengakui kedua cara berpikir yang berbeda dan bekerja bersama yang dapat membuat keseluruhan yang lebih baik. Kami merasakan hal yang sama tentang desainer UX dan UI. Di K2 kami memiliki tawaran pekerjaan terpisah untuk UX / Desainer Produk dan UI / Desainer Grafis. Beberapa orang melamar keduanya, yang bagi kami merupakan sinyal bahwa mereka tidak benar-benar tahu siapa mereka, mereka tidak peduli, atau benar-benar putus asa ...
Ada cukup banyak Pemikir Desain atau Desainer Layanan - orang-orang yang berspesialisasi dalam melakukan lokakarya atau penelitian desain, tetapi tidak benar-benar berpengalaman dalam merancang sesuatu secara detail (dan terutama digital). Nothi

Learn more



Fungsi di Kotlin berbeda dari yang ada di Java dengan cara berikut:

Dalam fungsi Kotlin tidak perlu menjadi bagian dari kelas, seperti di Java jika kita ingin mendefinisikan fungsi kita harus memiliki kelas yang didefinisikan dalam file .java. Tetapi di Kotlin kita dapat mendefinisikan fungsi seperti ini:

Dalam fungsi Kotlin dapat memiliki parameter default seperti ini:


Output: pengujian2

Dalam snapshot di atas, fungsi log memiliki parameter "nilai" default yang ditetapkan dengan nilai sama dengan "2". Jadi, jika kita memanggilnya dari main, kita tidak perlu meneruskan "parameter" nilai ke fungsi log.

Tetapi jika kita tidak menetapkan "nilai" nilai parameter sama dengan "2", kita akan mendapatkan kesalahan waktu kompilasi di utama.


Jadi, manfaat memiliki parameter default adalah bahwa kita tidak perlu meneruskan nilai ke fungsi panggilan dan itu tidak memerlukan perubahan dalam kode di mana-mana jika kita ingin mengubah nilai hanya melakukan perubahan pada single tempat.

Dalam fungsi Kotlin dapat memiliki parameter bernama seperti ini:

fun main(args: Array<String>){
    
    named(count=1,str="Sachin")
    named(str="Kumar",count=2)
}
fun named(str: String,count: Int) {
   
    println(str+count)
}

Jadi, kita dapat dengan mudah memahami manfaat menggunakan parameter bernama saat memanggil fungsi bernama, kita dapat memanggilnya dengan mengirimkan parameter dalam urutan apa pun yang kita inginkan.

Kotlin dapat memiliki fungsi Ekstensi seperti ini:

fun main(args: Array<String>){
   
   println("Sachin Kumar".removeSpace())

   var returnedVal = -23.absoluteValue()

   println("returned Int val: $returnedVal")
}
// extension function.
fun String.removeSpace() : String{
    return this.replace(" ","")
}
// extension function.
fun Int.absoluteValue(): Int{
    return -this
}

Dalam cuplikan kode di atas, "ini" adalah penerima yang merupakan nilai string yang kami lewati sebagai utilitas. Jadi, tidak perlu membuat kelas terpisah untuk manipulasi string dan integer di atas.

Karenanya, manfaat menggunakan fungsi ekstensi adalah mengurangi penggunaan kelas utilitas seperti di Jawa dan membuat kode kita lebih mudah dibaca.

Kotlin dapat memiliki fungsi infiks seperti ini:
Output:
SachinKumar
returned Int val: 23


Jadi, dengan infix, kita dapat melakukan overloading operator di Kotlin dan pada saat yang sama, kita dapat memanggil fungsi secara langsung melalui nama fungsi tanpa perlu operator titik.

Kotlin juga mendukung fungsi rekursif ekor jika kita menggunakan panggilan rekursif mendalam seperti ini:
fun main(args: Array<String>) {

    var h1 = Header("H1")
    var h2 = Header("H2")
    // with inflix keyword can use simply fun name.
    var h3 = h1 plus h2

    println(h3.name)
    /* operator overloading, have to use operator keyword with 
       infix function. */
    var h31 = h1 + h2

    println(h31.name)

}
class Header(var name:String){

}
//infix function.
infix operator fun Header.plus(other: Header) : Header {

    return Header(this.name+other.name)

}



Kode di atas akan mengarah ke pengecualian Stackoverflow. Jadi, kita akan menggunakan kata kunci "tailrec" dengan fungsi fibonacci:
import java.math.BigInteger

fun main(args: Array<String>) {

    println(fibonacci(100000, BigInteger("1"),BigInteger("12")))
}

fun fibonacci(length:Int, a: BigInteger, b: BigInteger): BigInteger {
    return if (length==0) b else fibonacci(length-1,a+b,a)
}

Ini adalah beberapa dasar penting dari fungsi di Kotlin yang harus disadari ketika melakukan pengkodean di Kotlin. Ini memiliki manfaat besar dibandingkan dengan kode di Jawa, hal utama adalah ini sangat mudah digunakan.

Saya harap Anda telah menemukan itu berguna, silakan suka artikel ini dan berbagi dengan sesama coders Anda :).





Learn more


Pengantar
Setiap kali bermain dengan UITableView atau UICollectionView yang diletakkan pada UIViewController pasti akan bertemu dengan sintaks seperti ini…

self.tableView.delegate = mandiri
Untuk bisa terlibat dengan tableView tadi, misalkan melakukan aksi tertentu kompilasi salah satu baris pada tableView telah dipilih akan dihapuskan, maka kita sering kali menggunakan delegasi pada tableView dapat melakukan aksi tersebut, tanpa disadari.

Mendiskusikanasan
Secara bahasa, delegasi atau pendelegasian adalah penyerahan tugas kepada pihak lain. Dalam konteks pemrograman iOS baik menggunakan Swift maupun Objective-C, pendelegasian di sini adalah tugas dari objek tertentu, misalkan untuk melakukan suatu tindakan terhadap data yang dituntut di UITableView, maka kita perlu UIViewController sebagai delegasi dari UITableView untuk mencari aksi Khusus, misalkan memilih salah satu item pada UITableView. Seperti itu.

Gambaran / contoh paling mudah dalam pendelegasian delegasi pada Swift, misalkan menyumbangkan hubungan antara Bos dan Sekretaris dalam pendelegasian untuk jadwal jadwal rapat, di mana Bos terlalu sibuk sehingga tidak memerlukan jadwal meetingnya sendiri 😛

Agar si Sekretaris bisa mengadakan pertemuan, maka kita tentukan dulu gimana si Sekretaris bekerja

protokol SekretarisDelegate {
 func aturJadwalMeeting ()
}
Lalu, kita menerapkan protokol agar agar Sekretaris dapat dijadwalkan jadwal pertemuan ...

sekretaris kelas: SekretarisDelegate {
 func aturJadwalMeeting () {
  print ("Wah, jadwal bosnya nih 😛")
 }
}
Klas Bos ditentukan sebagai berikut, karena dia punya delegasi buat pertemuan, maka dia punya atribut delegasi misalkan.

kelas Bos {
 // bos bisa ngapain aja sama punya apa dideklarasikan di sini
 // karena si Bos sibuk gak sempat atur rapat, punya delegasi deh
 var delegate: SekretarisDelegate?
}
Sekarang, kita coba buat Sekretaris dan Bosnya.

biarkan mario = Bos ()
let tina = Sekretaris ()
Lalu, si Mario menyuruh si Tina diminta bisa mengatur jadwal meetingnya, dan si Mario pun bisa mengatur jadwal meetingnya dengan bantuan Tina.

mario.delegate = tina
mario.delegate? .aturJadwalMeeting ()
// output: Whoa, aku dijadwalkan jadwal pertemuannya bos nih 😛
Rekap
Kira-kira begitu gambaran sederhana tentang proses delegasi. UITableView, UICollectionView, atau yang lain pasti memiliki delegasi yang cara mirip seperti simulasi sederhana diatas. Semoga Bermanfaat 😄

Learn more

Contact Us


WE ARE ACCEPTING NEW PROJECTS.

DIAZ IRANIAN
Unicorn indonesia
Startup Indonesia, diaziranian@gmail.com
WA/087784985885
012 5234567