JavaRush /Blog Jawa /Random-JV /Ngopi #31. 9 kesalahan karir sing kudu dihindari saben pa...

Ngopi #31. 9 kesalahan karir sing kudu dihindari saben pangembang. Napa arsitektur REST API entuk popularitas?

Diterbitake ing grup

9 Kesalahan Karir Saben Pangembang Piranti Lunak Kudu Dihindari

Sumber: Infoworld Ngopi #31.  9 kesalahan karir sing kudu dihindari saben pangembang.  Napa arsitektur REST API entuk popularitas?  - 1 Ayo jujur. Sawetara sampeyan miwiti sinau program amarga sampeyan utawa wong tuwa mikir bakal luwih gampang sampeyan entuk dhuwit akeh. Sampeyan dudu komputer ing sekolah, lan sampeyan ora seneng banget karo pangembangan piranti lunak. Yen iki bener, iki tegese sampeyan bakal tansah dadi programmer biasa-biasa wae. Ya, sampeyan bakal entuk dhuwit sing apik amarga industri kita seneng, nanging artikel iki dudu kanggo sampeyan. Nanging yen sampeyan diukum minangka bocah kanggo njupuk loro electronics kanggo tokoh metu carane padha makarya ... Yen ngginakaken setengah wengi ing Internet kanggo sinau carane nggawe video game ... Yen sampeyan nglampahi wektu free larang regane sinau bab apa ora ana sing takon sampeyan ... artikel iki kanggo sampeyan. Sampeyan kudu ngganti persepsi karir. Sampeyan ora nulis kode maneh kanggo seneng-seneng: sampeyan nindakake kanggo dhuwit. Kanggo seneng-seneng, sampeyan bisa ndhukung proyek pribadi. Nanging priksa manawa sampeyan paling ora seneng kerja dina. Yen ora, golek panggonan sing luwih apik yen bisa. Tujuan sampeyan kudu mbukak dana pensiun, nyelehake kabeh dolar sawise pajak, tuku omah, mobil, lan nindakake apa sing dikarepake. Mungkin lelungan. Ing wektu sing padha, sampeyan kudu mikir babagan karir, ora mung proyek sampeyan saiki. Kanggo nindakake iki, sampeyan kudu ngindhari sangang pitfalls, sing saiki bakal dibahas.

Pitfall #1: Aja tetep ing siji teknologi kanggo dangu

Aku ngerti. Apa sampeyan seneng C # utawa Java utawa JavaScript, Python utawa Cobol. Nanging umume teknologi duwe siklus urip adopsi, puncak, outsourcing, niche, lan obsolescence. Maksudku, yen sampeyan ngerti Cobol ing taun 1980-an, mesthi bakal kelangan. Nanging programer Cobol saiki ora entuk akeh dhuwit. Intine, mung ngerti siji basa pamrograman, cepet utawa mengko sampeyan kudu nyuda biaya, pindhah menyang kutha sing luwih murah, amarga sampeyan bakal entuk luwih murah.

Pitfall No.. 2: aja dadi monopoli IT

Sampeyan perlu kanggo hedge investasi. Kayane sampeyan mung kudu dadi ahli ing teknologi sing saiki ndominasi pasar. Nanging banjur sampeyan bakal ngadhepi akèh kompetisi. Kajaba iku, nalika panjaluk spesialisasi sampeyan mudhun, sampeyan kudu duwe rencana metu. Contone, aku dadi geek C ++ nalika Jawa metu. Aku sinau basa Jawa. Sawetara taun kepungkur, kabeh wong wiwit ngomong babagan Ruby minangka bintang anyar ing antarane basa pemrograman. Lan ing sawetara titik katon yen Perl bakal tekan tingkat sing padha karo Jawa. Prediksi masa depan angel, mula hedging taruhan minangka cara paling aman kanggo njamin relevansi ing pasar kerja.

Pitfall # 3: Aja terus kanggo fads

Cepet utawa mengko sihir ilang. Wong ora bakal nyewa pangembang Groovy utawa Ruby. Yen bos sampeyan ngidini sampeyan nggunakake basa warisan ing proyek, mesthine amarga dheweke ora peduli utawa ora ngerti. Kanthi kabeh cara, sinau lan gunakake teknologi paling anyar. Siapke dadi salah siji sing pisanan ngerti babagan lan dadi ahli. Saliyane, uga siyap nggawe owah-owahan drastis yen panjaluk spesialisasi sampeyan nolak. Ana uga teknologi anyar liyane kanggo tresna, dadi basa utawa database.

Pitfall # 4: Alergi kanggo aturan

Saben organisasi, ora preduli gedhe utawa cilik, duwe aturan kantor dhewe. Sampeyan kudu sinau lan tindakake. Yen ora, sampeyan bakal dadi pion ing game wong liya utawa bakal terisolasi ing tim kasebut. Yen sampeyan kasengsem ing karir lan hubungan produktif ing karya, sinau kanggo tindakake taktik pertahanan ing aturan kantor.

Pitfall # 5: disinterest ing bisnis

"Aku mung developer, aku ora kasengsem ing bisnis." Iki dalan kanggo ora ono. Sampeyan kudu sinau ngetung. Apa perusahaan sampeyan apik? Apa tujuan bisnis utamane? Apa proyek paling penting dheweke? Kepiye teknologi utawa piranti lunak mbantu entuk? Kepiye perusahaan sampeyan cocog karo industri sakabèhé? Yen sampeyan ora ngerti jawaban kanggo pitakonan kasebut, sampeyan bakal bisa nggarap proyek sing ora penting kanggo wong sing ora penting ing perusahaan sing ora penting kanthi jumlah dhuwit sing ora pati penting.

Pitfall No. 6: mentalitas "solidaritas serikat pekerja"

Nalika aku isih enom, salah sawijining kancaku yaiku wong sing ngrancang meh kabeh nem sasi sadurunge. Dheweke nggawe kesalahan nalika arep liburan, mula aku ngrampungake kabeh proyek sajrone rong minggu, nanging ninggalake dheweke siji-sijine. Aku ngarepake dheweke bakal seneng. Pranyata dheweke ora seneng. Iku kabeh rampung karo dheweke nggunakake saben kesempatan kanggo njaluk kula murub. Iki dadi tujuan utama. Dheweke malah ngeluh babagan aku menyang direktur anyar kita. Mesthi wae aku nindakake kabeh karyaku. Aku dadi inovator. Aku tansah golek cara anyar kanggo nindakake samubarang luwih apik lan luwih cepet lan ngatasi masalah. Dheweke pensiun sakcepete sawise aku lunga menyang proyek liyane. Kaping pirang-pirang aku weruh dheweke ing cafe, lan kita nyamar yen kita ora kenal. Iki ora bakal dadi pungkasan wektu aku nemoni jinis karya iki: "Lakukan alon-alon utawa bakal dadi luwih elek." Saranku: tulis kode sing bener, nanging siyaga kanggo sing ora dikarepke. Yen masalah ora bisa ditanggulangi, ninggalake mbanting lawang: perusahaan sampeyan ora mung siji ing pasar.

Pitfall No.. 7: sampeyan ora ngerti regane

"Aku ora kene kanggo dhuwit." Dadi, njupuk hobi. Aja lunga kerja saben dina mikir babagan gaji sabanjure. Sampeyan uga ora kudu kerja yen entuk 50% luwih murah tinimbang wong liya. Ngerti regane lan aja ngremehake.

Pitfall # 8: Nambani proyek kaya proyek

"Iku mung proyek." Ora, iki minangka langkah ing karir sampeyan. Sampeyan ora bakal ing proyek iki ing salawas-lawase. Dadi apa sing bisa sampeyan sinau ing kene? Apa sing bakal dadi langkah sabanjure? Ing endi sampeyan pungkasane pengin mungkasi? Kepiye karya iki bakal mbantu sampeyan nggayuh tujuan kasebut? Tambah kesadaran babagan lingkungan sampeyan. Iki bakal nglayani sampeyan kanthi apik ing jangka panjang. Iku ora mung proyek, iku lelampahan.

Pitfall No.. 9: Sampeyan mikir iku mung bab dhuwit

Penjual seneng ngomong, "Aku kerja yen sampeyan muter koin." Ya, nanging yen sampeyan ora kerja ing sales, mula ora ana sing kepengin nyambut gawe karo wong sing kerjane mung kanggo dhuwit. Aku ngerti yen aku mung pengin nggarap wong sing tanggung jawab kanggo karyane. Lan sampeyan? Ing sisih liya, ora perlu tanggung jawab sing ora bisa ditindakake. Yen sampeyan pancene kuwatir babagan debat tab utawa kesenjangan sing langgeng, sampeyan bisa uga kudu njupuk obat penenang.

Napa arsitektur REST API entuk popularitas?

Sumber: Komunikasi Instan DZone pancen luar biasa. Kita kabeh wis biasa karo kasunyatan sing bisa langsung komunikasi karo ngendi wae ing donya. Saka komputer desktop utawa piranti seluler, kita bisa tuku, ngirim, masang lan milih apa wae, ing ngendi wae. Kita wis disambungake kanggo saben liyane lan kanggo donya kaya tau sadurunge. Nanging kepiye kedadeyan kasebut? Kepiye data entuk "saka ing kana"? Ngopi #31.  9 kesalahan karir sing kudu dihindari saben pangembang.  Napa arsitektur REST API entuk popularitas?  - 2Piranti lan aplikasi komunikasi karo saben liyane nggunakake antarmuka program aplikasi, utawa API. Iki persis mesin "ing hood". Iku tansah konco sing pemandangan, lan kita kathah kanggo mikir iku minangka soko biasa, nanging API sing nggawe kabeh interaktivitas kita Count ing.

Apa iku API?

Cukup, API minangka utusan sing nampa panjalukan, ngandhani sistem apa sing arep ditindakake, banjur menehi respon marang sampeyan. Kanggo conto visual, mbayangno API minangka pelayan ing restoran. Mbayangno yen sampeyan lagi lungguh ing meja, nyekel menu ing tangan sampeyan, lan pawon minangka bagéan saka sistem sing bakal nyiapake pesenan sampeyan. API minangka link sing bakal ngirim pesenan menyang pawon lan ngirim panganan menyang meja.

Ayo njupuk conto nyata:

Kita kabeh ngerti proses nggoleki penerbangan online lan ngerti manawa kanggo nggawe pesenan penerbangan, kita kudu sesambungan karo situs web maskapai kasebut. Sampeyan ngakses database kanggo ndeleng yen kursi kasedhiya ing tanggal tartamtu lan apa biaya sampeyan bisa nyana adhedhasar syarat pesawat. Nanging kepiye yen sampeyan ora nggunakake situs web maskapai sing duwe akses langsung menyang informasi? Apa yen sampeyan nggunakake layanan pesenan online sing ngumpulake informasi saka maskapai beda? Layanan kasebut sesambungan karo API maskapai, ing ngendi API minangka antarmuka sing, kaya pelayan sing mbiyantu, njaluk informasi saka layanan online babagan reservasi kursi lan pilihan dhaharan utawa bagasi penumpang. API banjur njupuk respon maskapai lan ngirim bali menyang layanan online, kang nuduhake informasi kanggo penumpang. Akeh proses sing padha dumadi ing antarane kabeh aplikasi, data, lan piranti liyane. Kabeh mau duwe API sing ngidini komputer ngontrol, lan iki pungkasane nggawe komunikasi.

Apa jinis API sing ana?

Arsitektur API bisa diimplementasikake kanthi rong cara utama: salah sawijining cara kanggo ngetrapake transfer informasi yaiku SOAP, lan cara utama liyane yaiku REST. Kita wis nemtokake manawa API nyedhiyakake komunikasi antarane rong aplikasi. Saiki kita bakal sinau kepiye SOAP lan REST pas karo arsitektur komunikasi.

API SOAP

SOAP (Simple Object Access Protocol) minangka layanan web sing ngetutake spesifikasi kanthi prinsip komunikasi tartamtu sing ditetepake ing antarane badan tengah sing diarani W3C lan set spesifikasi inti. Set iki kalebu:
  • SABUN
  • WSDL
  • UDDI
SOAP minangka protokol sing nemtokake cara loro aplikasi bakal komunikasi karo saben liyane. Loro aplikasi kudu ngetutake format sing umum nalika sesambungan, lan format umum iki kudu adhedhasar basa XML. XML ing SOAP API kudu cocog karo standar SOAP Message, sing kalebu Envelop, Header, lan Body.

REST API

Iki minangka konsep layanan web sing penting banget nanging asring disalahake, mula ayo ngerteni apa tegese REST utawa RESTful API. REST minangka layanan web sing miwiti komunikasi antarane rong aplikasi nggunakake prinsip arsitektur dhewe. Arsitektur REST minangka gaya arsitektur sing ora ngetutake protokol apa wae, ora ana spesifikasi sing ketat, lan ora ana otoritas pusat sing ngontrol spesifikasi kasebut. Iki ndadekake REST serbaguna kanggo nggunakake utawa nggawe layanan apa wae. Nalika prinsip kasebut ditrapake nalika nggawe layanan web, kita entuk layanan web RESTful. Saiki ayo luwih jero lan ngerteni prinsip sing adhedhasar arsitektur REST.

Antarmuka Manunggal

Ing arsitektur RESTful, kabeh bisa dianggep minangka sumber daya. Contone, yen sampeyan nyoba nggawe aplikasi kanggo sistem manajemen karyawan. Aplikasi iki bisa dikembangake nggunakake basa apa wae, ing platform apa wae lan kanggo platform apa wae. Kajaba iku, database apa wae bisa digunakake kanggo nangani layanan internal. Konsep sumber daya ing REST API nuduhake manawa pangguna bisa nemtokake informasi utawa modul apa wae minangka sumber. Kanthi sistem manajemen karyawan, pangripta bisa nemtokake sumber daya karyawan, departemen, lan modul liyane sing digunakake ing aplikasi kasebut.

Stateless

Ing arsitektur RESTful, kabeh tanggapan lan panjaluk, lan kabeh komunikasi antarane server, ora ana negara. Iki tegese server ora njaga kahanan saiki sistem, klien bisa ngirim panjalukan sing dhewe jangkep. Lan panjaluk iki ora gumantung saka panjaluk sadurunge. Contone, yen sampeyan lagi blanja online lan nambah item menyang cart, server ora bakal njaga status cart, supaya saben pangguna ngirim panjalukan kanggo server, bakal ngemot status cart ing wektu panjalukan digawe. Nalika stateless, ora ana biaya overhead kanggo server kanggo nyimpen utawa njaga sesi kasebut, mula bisa nambah kinerja layanan web.

Kapabilitas cache

Ing protokol pungkasan, kita ngerteni manawa ing arsitektur RESTful server ora nyimpen negara sesi, kabeh caching kedadeyan ing sisih klien. Saben klien ngirim panjalukan menyang server, server ngasilake respon sing ngemot data nyata uga metadata liyane sing ngandhani klien apa kudu nyimpen respon kasebut sacara lokal utawa ora.

Sistem multi-level

Prinsip REST nyatakake yen saben ana komunikasi antarane klien lan server, bisa uga ana pirang-pirang lapisan ing antarane, lan lapisan kasebut bisa digunakake kanggo ngetrapake macem-macem tujuan kayata terjemahan pesen, peningkatan kinerja, caching, lan macem-macem liyane. Saben tingkat komunikasi duwe tugas tartamtu. Kanthi pirang-pirang lapisan komunikasi, sistem kasebut beroperasi kanthi efisien, ningkatake kacepetan lan daya tahan.

Kode ing request

Iki minangka watesan opsional saka layanan web RESTful sing bisa digunakake nalika pangguna ngirim panjaluk kanggo nampa respon. Tanggepan bisa mbukak kode sisih klien. Prinsip iki ngembangake fungsi komunikasi.

Napa REST API digunakake luwih asring?

REST paling gampang digunakake, luwih fleksibel, lan duwe sawetara kaluwihan tinimbang SOAP. Contone, sampeyan ora mbutuhake alat sing larang kanggo sesambungan karo layanan web apa wae. Arsitèktur REST luwih prasaja, bisa gampang disesuaikan, lan ora mbutuhake katrampilan khusus nalika nggawe model komunikasi. Iku efisien kanggo nggunakake amarga bisa nggunakake sisih klien saka server kanggo nyimpen informasi-related klien. REST nggunakake format pesen sing luwih cilik lan nyedhiyakake interaksi sing luwih cepet amarga ora mbutuhake proses sing akeh wektu. REST uga luwih cedhak karo teknologi web liyane nalika nerangake filsafat desain.

SABUN utawa ngaso?

Kanggo syarat aplikasi web sing khas, SOAP asring overkill. REST minangka solusi sing luwih prasaja sing nduweni kabeh sing dibutuhake nalika aplikasi web mbutuhake API. Nanging, ana wektu nalika API kudu rada rumit kanggo ngrampungake tugas. Contone, yen API dibutuhake kanggo panjalukan otomatis, SOAP API bakal dadi pilihan sing luwih apik kanggo skenario kasebut. Cukup, pilih SOAP yen masalah gedhe lan rumit, lan pilih REST yen sampeyan butuh solusi sing prasaja.
Komentar
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION