The future of Javascript developers and their projects: Inachekesha ila inaumiza pia

Mi kwanza JavaScript siipendi japo nalazimika kufanya project zangu nyingi kwa JavaScript, nimejaribu typescript sioni utofauti mkubwa na JavaScript, najifunza Dart nione kama itakuwa mbadala wa JavaScript
Hujaona utofauti na Typescript na JavaScript?
Are you for real?

Personally nitaanza Ku recommend Typescript kwa beginners baada ya kuanza kuitumia kwa mda sasa haswa kwenye Mobile Development (with React Native)

Anachozungumzia kali linux hapa ni tatizo la JavaScript developers haswa beginners kutokua na core concepts/skills za JavaScript au hawana full knowledge ya JavaScript

Kwanza naomba niseme kuwa huwezi Ku master language nzima,hakuna anayeweza

Most devs huwa wanatumia Progressive learning, kwa Ku focus na aspects zipi za JavaScript project yako inazihitaji

Pia kabla hatujawalaumu beginners kwa kosa la kutojifunza core concepts za Js,

Lazima tukubaliane kuwa JavaScript yenyewe ina ruhusu hii tabia kwa kuwa "dynamically typed language"
Ni ngumu sana kujua kama codes zina makosa au lah untill run time
 
Kwanza naomba niseme kuwa huwezi Ku master language nzima,hakuna anayeweza
Sijaongelea kumaster language nzima. Ni wazi kuwa hilo jambo haliwezekani. Lakini nimeongelea core concepts ambazo ni simple sana. Kwa maneno mengine nasemea tabia ya javascript, (Especially How js treats values, loops and various data types in JS - na hizo ndizo building blocks za language yoyote ile duniani).

Kosa wanalofanya wengi ni kusoma syntax tu na kujua namna ya kucreate variables then anajiita developer, Hapo sitokuita javascript developer, nitakupa badge ya script Kiddie tu coz hio kitu hata mtoto wa darasa la nne anaweza kufanya. Lakini ule uwezo wa kujua kiundani jinsi codes zako zinavyofanya kazi ndipo unaweza kujiita developer. Kuna advanced concepts za js ambazo kwa dev wa kawaida inawezekana hata asije akazisikia kabisa kwenye maisha yake ila hizo hapo juu sio advance bali ni intermediate tu.

Sikatai kuhusu progressive learning kama unavyosema. Lakini shida inakuja reckless codes za aina hio nazikuta mara kwa mara kwenye apps ambazo zipo tyr deployed, na sio learning project bali ni app kabisa inayosimamia business fln fln. Hapo kweli bado utaniambia developer alikua anajifunza au alikua kazini?

Nimefanya pentesting ya baadhi ya apps na websites na technique mojawapo ninayotumia ni Source-code analysis, so hapa naongelea kitu ambacho nimekiona kwenye production na sio kwenye learning.

We cannot go around this. Kama unataka kuwa developer kweli wa javascript au language yoyote ile basi kasome core concepts kwanza za hio language.
 
Hujaona utofauti na Typescript na JavaScript?
Are you for real?

Personally nitaanza Ku recommend Typescript kwa beginners baada ya kuanza kuitumia kwa mda sasa haswa kwenye Mobile Development (with React Native)

Anachozungumzia kali linux hapa ni tatizo la JavaScript developers haswa beginners kutokua na core concepts/skills za JavaScript au hawana full knowledge ya JavaScript

Kwanza naomba niseme kuwa huwezi Ku master language nzima,hakuna anayeweza

Most devs huwa wanatumia Progressive learning, kwa Ku focus na aspects zipi za JavaScript project yako inazihitaji

Pia kabla hatujawalaumu beginners kwa kosa la kutojifunza core concepts za Js,

Lazima tukubaliane kuwa JavaScript yenyewe ina ruhusu hii tabia kwa kuwa "dynamically typed language"
Ni ngumu sana kujua kama codes zina makosa au lah untill run time

Ndio sijaona, maana at the end typescript inakuwa compiled to plain JavaScript, typescript haifanyi kazi pasipo kuwa compiled to JavaScript
 
What You See Is What You Get(WYSIWUG) zimefanya hata vilaza waweze kutengeneza saiti kwa kudrag na kudrop lakini hawajui chochote behind the scene
 
Ndio sijaona, maana at the end typescript inakuwa compiled to plain JavaScript, typescript haifanyi kazi pasipo kuwa compiled to JavaScript
JavaScript ina built in data types kama String, Number,Boolean,Array,Object etc

Lakini hai Ku force u declare aina gani ya data types variable yako ita store

Hii freedom inakufanya kutogundua possible errors mpaka run time

So kwa large applications zenye lot of components kama za Vuejs au Reactjs

Inakua vigumu Ku hakikisha kuwa kila independent component ina pokea "props" sahihi

Kama ina accept boolean, isipokee String na kufanya application I fail

So Typescript imekuja Ku solve hili tatizo kwa Ku add types annotations

Ili iwe rahisi kwa JavaScript devs Ku adapt JavaScript, wali make sure any valid JavaScript codes ni Valid Typescript codes

So hio ndo tofauti ya Ts na Js,
 
What You See Is What You Get(WYSIWUG) zimefanya hata vilaza waweze kutengeneza saiti kwa kudrag na kudrop lakini hawajui chochote behind the scene
Hio inaitwa abstraction
Sio lazima kujua nini kina happen behind the scene unless kuna sababu ya kufanya hivyo

So Kuwaita vilaza sio sahihi

As software developer utajifunza kuishi ndani ya hizo abstractions unless kuna sababu ya kujua what actually going on under the Hood
 
Hio inaitwa abstraction
Sio lazima kujua nini kina happen behind the scene unless kuna sababu ya kufanya hivyo

So Kuwaita vilaza sio sahihi

As software developer utajifunza kuishi ndani ya hizo abstractions unless kuna sababu ya kujua what actually going on under the Hood
Sikubaliana na wewe hata kidogo.Huu ndio msimamo wangu
 
What You See Is What You Get(WYSIWUG) zimefanya hata vilaza waweze kutengeneza saiti kwa kudrag na kudrop lakini hawajui chochote behind the scene
Hii ni sawa na kulalamika kuwa watu sikuhz wanasoma vitabu kwenye simu baadala ya kuingia maktaba na kusoma hard copy. Haijalishi kma ame drag and drop na wewe umecode from scratch. End result ndio ya muhim. Kumuita mtu kilaza kwasabab ametumia simplified tools sio sahihi.

Aliye drag and drop hatakuwa sawa na wewe unaecode sabab scope yako inaenda mbali zaidi lakini na yeye anafanya kazi yake kwa upeo alionao yeye. Kumuita kilaza ni kumkosea heshima.
 
Hii ni sawa na kulalamika kuwa watu sikuhz wanasoma vitabu kwenye simu baadala ya kuingia maktaba na kusoma hard copy. Haijalishi kma ame drag and drop na wewe umecode from scratch. End result ndio ya muhim. Kumuita mtu kilaza kwasabab ametumia simplified tools sio sahihi.

Aliye drag and drop hatakuwa sawa na wewe unaecode sabab scope yako inaenda mbali zaidi lakini na yeye anafanya kazi yake kwa upeo alionao yeye. Kumuita kilaza ni kumkosea heshima.
Ok basi natengua kauli mkuu.Ila na-appreciate sana coding kuliko drag and drop.
 
Ok basi natengua kauli mkuu.Ila na-appreciate sana coding kuliko drag and drop.
Ndio. Ukicode unakua na uwezo wa kutengeneza unachotaka wewe. Utaweza kudebug kiundani tatzo linapotokea. Kumbuka anaecode ndio anaetengeneza hzo drag and drop.

Drag and drop site zilitengenezwa ili kuwezesha watu wa kawaida kutengeneza simple website bila kujua kucode.

Anae drag and drop sio sahihi kujiita developer na hatakiwi kulinganishwa na actual web developers.
 
Mkuu hili swala lipo na linawakumba developers wengi wanao chipukia. Huwa wanapitia juu juu documentation za framework na kuanza kazi.

Ila kwa kuongezea hapo kwenye mada kuna matatizo pia kwenye sehemu mbili ambazo mimi nimeziona. Ya kwanza ni documentation na ya pili ni testing.

Nianze na documentation. Developers wengi huwa tunakuwa wavivu kuandika documentation vizuri za project zetu. Hii huwa inaenda hadi kwenye libraries ambazo tunatengeneza ili developers wengine wazitumie kwenye project zao. Sasa kama ukikumbana na library yenye poor documentation unaweza kujikuta na matatizo kama hayo uliotaja, hata kama kwenye zile core basics za language husika upo vizuri.

Mfano unakuta library ya mtu ina method inayorusha (throw) exception na hajaiandikwa kwenye documentation yake. Kama kwenye project yako, ukitumia method ya hiyo library bila taadhari ya ku-catch hiyo exception utapata run time error bila kutegemea.Mimi huwanasita sana kutumia library ambayo ina poor documentation. Maana unajikuta unaanza ku-study code za ile library kwa undani ili ujue nini kinafanyika.

Tuje kwenye testing. Swala la testing ni pana mno na huwa developers wengi tunapuuzia. Kwenye hizi fortune 500 companies zilizojikita kwenye software huwa zina dedicated departments za kufanya testing za products zake. Ukiwa una test, unatakiwa kutest input unayotegemea na input usiyoitegemea kwa user. Wengi tunaishia kwenye input tunayoitegemea na kupuuzia the unexpected input.

Katika huo mfano ulioutaja mkuu, kama huyo developer angetest the unexpected input, angeona tatizo kabla ya kuenda kwenye production. Shida itakuja pale kugundua ni wapi kabisa tatizo lipo kwa sababu ya uelewa wake mdogo wa core basics za language husika. Kikawaida huwa kuna mtu au team ya kufanya testing ya mfumo wako. Huyu anakuwa kama jicho lako la tatu kabla ya ku-roll out to production.
 
Mkuu hili swala lipo na linawakumba developers wengi wanao chipukia. Huwa wanapitia juu juu documentation za framework na kuanza kazi.

Ila kwa kuongezea hapo kwenye mada kuna matatizo pia kwenye sehemu mbili ambazo mimi nimeziona. Ya kwanza ni documentation na ya pili ni testing.

Nianze na documentation. Developers wengi huwa tunakuwa wavivu kuandika documentation vizuri za project zetu. Hii huwa inaenda hadi kwenye libraries ambazo tunatengeneza ili developers wengine wazitumie kwenye project zao. Sasa kama ukikumbana na library yenye poor documentation unaweza kujikuta na matatizo kama hayo uliotaja, hata kama kwenye zile core basics za language husika upo vizuri.

Mfano unakuta library ya mtu ina method inayorusha (throw) exception na hajaiandikwa kwenye documentation yake. Kama kwenye project yako, ukitumia method ya hiyo library bila taadhari ya ku-catch hiyo exception utapata run time error bila kutegemea.Mimi huwanasita sana kutumia library ambayo ina poor documentation. Maana unajikuta unaanza ku-study code za ile library kwa undani ili ujue nini kinafanyika.

Tuje kwenye testing. Swala la testing ni pana mno na huwa developers wengi tunapuuzia. Kwenye hizi fortune 500 companies zilizojikita kwenye software huwa zina dedicated departments za kufanya testing za products zake. Ukiwa una test, unatakiwa kutest input unayotegemea na input usiyoitegemea kwa user. Wengi tunaishia kwenye input tunayoitegemea na kupuuzia the unexpected input.

Katika huo mfano ulioutaja mkuu, kama huyo developer angetest the unexpected input, angeona tatizo kabla ya kuenda kwenye production. Shida itakuja pale kugundua ni wapi kabisa tatizo lipo kwa sababu ya uelewa wake mdogo wa core basics za language husika. Kikawaida huwa kuna mtu au team ya kufanya testing ya mfumo wako. Huyu anakuwa kama jicho lako la tatu kabla ya ku-roll out to production.
Noted👏
 
Mkuu hili swala lipo na linawakumba developers wengi wanao chipukia. Huwa wanapitia juu juu documentation za framework na kuanza kazi.

Ila kwa kuongezea hapo kwenye mada kuna matatizo pia kwenye sehemu mbili ambazo mimi nimeziona. Ya kwanza ni documentation na ya pili ni testing.

Nianze na documentation. Developers wengi huwa tunakuwa wavivu kuandika documentation vizuri za project zetu. Hii huwa inaenda hadi kwenye libraries ambazo tunatengeneza ili developers wengine wazitumie kwenye project zao. Sasa kama ukikumbana na library yenye poor documentation unaweza kujikuta na matatizo kama hayo uliotaja, hata kama kwenye zile core basics za language husika upo vizuri.

Mfano unakuta library ya mtu ina method inayorusha (throw) exception na hajaiandikwa kwenye documentation yake. Kama kwenye project yako, ukitumia method ya hiyo library bila taadhari ya ku-catch hiyo exception utapata run time error bila kutegemea.Mimi huwanasita sana kutumia library ambayo ina poor documentation. Maana unajikuta unaanza ku-study code za ile library kwa undani ili ujue nini kinafanyika.

Tuje kwenye testing. Swala la testing ni pana mno na huwa developers wengi tunapuuzia. Kwenye hizi fortune 500 companies zilizojikita kwenye software huwa zina dedicated departments za kufanya testing za products zake. Ukiwa una test, unatakiwa kutest input unayotegemea na input usiyoitegemea kwa user. Wengi tunaishia kwenye input tunayoitegemea na kupuuzia the unexpected input.

Katika huo mfano ulioutaja mkuu, kama huyo developer angetest the unexpected input, angeona tatizo kabla ya kuenda kwenye production. Shida itakuja pale kugundua ni wapi kabisa tatizo lipo kwa sababu ya uelewa wake mdogo wa core basics za language husika. Kikawaida huwa kuna mtu au team ya kufanya testing ya mfumo wako. Huyu anakuwa kama jicho lako la tatu kabla ya ku-roll out to production.
Daaah ni kweli kabisa unachosema mkuu.

Swala la testing pia naona bado sana kwa wadau wengi.
 
Inategemea ni language ipi, uelewa wako na je unasoma masaa mangap kwasiku. Average kwa language kma python ili kuijua vizuri ni kma miezi 3 hv kama unasoma masaa 24 kwa week.
Masaa 24!

Naipenda sana hii comp. language ya python mkuu, nataka niisome niive kweli kweli! Vipi unaweza nisaidia muongozo mzuri kabisa wa kuanza mayo from the scratch ili isinisumbue huko mbeleni nitakapoanza kuisoma!

Natanguliza shukrani...
 
Masaa 24!

Naipenda sana hii comp. language mkuu, nataka niisome niive kweli kweli! Vipi unaweza nisaidia muongozo mzuri kabisa wa kuanza mayo from the scratch ili isinisumbue huko mbeleni nitakapoanza kuisoma!

Natanguliza shukrani...
Masaa 24 kwa week nzima. Ila inashauriwa usome 12 hrs a week kma una mambo mengine unafanya
 
Masaa 24 kwa week nzima. Ila inashauriwa usome 12 hrs a week kma una mambo mengine unafanya
Nataka soma Python lang mkuu naomba muongozo naona hapo kwenye replay nilisahau kuedit bfr hujani quote hii..
 
Back
Top Bottom