Iesakiet kursus Python valodā

[Inspektors Caps]

 

šī minimālistiskā pieeja

Jā, tas ir uzlabojums, bet tur jau tā lieta, ka tā kopējās sistēmas efektivitātes ziņā nav pat tuvu minimālistiskai pieejai. Tas ir tikai viens uzlabojums esošajā superneefektīvajā lielajā sistēmā.

 

 

ieslēgtu GZIP kompresiju, tad tas jau būtu daudz tīkla atslogošanai

Un jau tā liekajai teksta parsēšanai uzliktu VĒL papildus lielāku slodzi uz CPU un RAM!

 

 

Neredzu vajadzību ieviest kaut ko "bināru"

Bināru formātu gadījumā ietaupām pilnīgi visos parametros - datu apjomu, CPU, RAM. Pie tam ietaupījums nav par kaut kādiem procentiem bet vismaz 10 REIZES katrā šajā jomā! Tā rezultātā arī krietni ietaupām elektrību vai krietni palielinām iekārtas autonomo darbības laiku no akumulatora. Papildus bonusā vēl bināri standarti parasti arī pieļauj mazāk neprecizitāšu un PIESPIEŽ taisīt visu korekti. Ja tie nav ieguvumi, tad šī "neredzēšana" ir saucama tikai vienā vārdā - aklums.

[Mezavecis]

Caps, man liekas, ka weba principus neesi līdz galam izpratis. Ja gala kods būtu melnā kaste, tad web lapu skaits būtu n reizes mazāks, turklāt binārs formāts nav elastīgs izmaiņām, bet esoša 15 gadus veca weblapa būs uz pašiem jaunākiem pārlūkiem skatāma tieši tādā izskatā kā toreiz. Vēl arī fragmentāra ielāde nodrošina, ka cilvēks var lasīt daļēji ielādētu lapas saturu. Bināra koda gadījumā rezultāts būtu redzams tikai pilnīgi ielādējoties visam kodam. Interneta traucējumu gadījumā lapa būs tukša vai bezgalīgi lādēsies ar mistisku kļūdu. Es piemēram nevaru iedomāties, kā varētu aizvietot html/xml ar kaut kādu aizvērtu kodu, jo tādā gadījumā dinamiski kaut kādu lapas fragmentu nebūtu iespējams pārģenerēt.

 

Salīdzinājumam C# vai AWT formu izmainīt nozīmētu kaudzi koda sarakstīt, lai iegūtu vēlamo rezultātu vienā statiskā formā. Es arī nerunāju par to, kādi servera resursi būtu nepieciešami bināras platformas darbināšanai. Droši vien kāds atceras, cik ātri bija CGI serveri un cik ātri spēja sagremot vajadzīgo saturu un sūtot pa jaunu saturu klientam. Jāpiezīmē, ka vairumos gadījumu serveri klientam sūta jau kompresētu saturu. Arī slodzes pārnešana no klienta uz serveri ir dārga un neefektīva, jo servera resursi nav bezizmēra un tos daudz grūtāk nodrošināt.  

 

isa šī cepšanās ir par tēmu "būtu tantei riteņi būtu tramvajs", jo triljoniem devaisus neviens nepārtaisīs. Ajax, freimworki, flash, skripti, multimēdiji iet kopsolī ar interneta attīstību, jo diez vai 20 gadus atpakaļ kāds iedomājās par interaktīvu vidi.

 

Arī cepšanās par standartiem ir bezjēdzīga, jo webs nepārtraukti attīstās. Pats pieminēji videostandartus - cik kodeki pa šo laiku ir saražoti un top joprojām? Arī audio looseless jomā ir bardaks, jo nav atskaņotāju, kas spētu visu atskaņot. Domājams, ka neviens negrib webā standartizēt, lai nenonāktu pie apsurda, ka kāda weblapa nestrādā, jo nomainījās windows versija un kāds lapas modulis netiek vairs supportēts. Arī mūsu standartizētie programmētāji nevar aizdomāties 10 gadus uz priekšu un uzražot tādu produktu bez kļūdām un savietojamu it visā, kas teorētiski varētu rasties. 

Labots Aprīlis 3, 2013 - Skrandainais

[Inspektors Caps]

Skrandainais, neapvainojies, bet man pat rokas nolaižas pēc Tava teksta izlasīšanas. Šie ir mūžīgie WEB pasaules cilvēku absolūti nepatiesie apgalvojumi! Faktiski Tu pilnīgi visu vai nu neizproti, vai labākajā gadījumā saproti nepareizi. Mēģināšu izvilkt tikai galveno un iedot arī nopietnus pretpiemērus, jo izskatās, ka bez tādiem liela daļa šeit nopietni padomāt ar savu galvu, izprast un noticēt nespēs...
 

binārs formāts nav elastīgs izmaiņām, bet esoša 15 gadus veca weblapa būs uz pašiem jaunākiem pārlūkiem skatāma tieši tādā izskatā kā toreiz.

Neviens formāts/standarts nav elastīgs izmaiņām, jo tāda ir standarta būtība - nemaināmu specifikāciju komplekts. Un tas nekādi nav atkarīgs no tā vai tas ir teksta vai binārs formāts. Arī HTML Tu nevari nomainīt elementa identifikatoru (tagu) vai kaut kādus pamata principus un gaidīt, ka viss turpinās strādāt. Jaunas izmaiņas formātā ievieš kā papildinājumus, nemainot esošās. Un tieši tāpat to var un arī dara bināros formātos. Piemēri:

AVI: Reāli ir divas AVI versijas, bet tā kā "jaunā" OpenDML versija ir kā papildinājums, tad šo pāreju gandrīz neviens tā īsti pat nejuta un vēl jo vairāk - nemaz nezin par tādu un nezin kādu versiju reāli lieto! Varu pateikt, ka šodien jums gandrīz visi faili ir jaunā formāta, bet gadās pa vidu arī kāds vecais, kuru visi pleijeri atskaņos bez problēmām!

 

"Most AVI files also use the file format extensions developed by the Matrox OpenDML group in February 1996. These files are supported by Microsoft, and are unofficially called "AVI 2.0"."
Interesanta piezīme - radīts 1992. gadā, papildināts 1996. gadā un vēl šodien 2013. gadā nodrošina gandrīz visas audio/video formāta vajadzības.

 

"An AVI file may carry audio/visual data inside the chunks in virtually any compression scheme, including Full Frame (Uncompressed), Intel Real Time (Indeo), Cinepak, Motion JPEG, Editable MPEG, VDOWave, ClearVideo / RealVideo, QPEG, and MPEG-4 Video."
Binārs formāts nav papildināms, lai paliktu savietojams ar vecākas formāta versijas failiem? AVI pats ir tikai viens no RIFF apakšformātiem, bet RIFF ir gandrīz bezgalīgi papildināms, saglabājot savietojamību!

 

"As a derivative of the Resource Interchange File Format (RIFF), AVI files are commonly tagged with metadata in the INFO chunk. In addition, AVI files can embed Extensible Metadata Platform (XMP). By design, any RIFF file can legally include additional chunks of data, each identified by a four-character code; software which does not understand that particular code should skip the chunk. As such, it is theoretically possible to expand any RIFF file format, including AVI, to support almost any conceivable metadata."

MPEG-1/2 Video: MPEG-2 Video ir MPEG-1 Video papildinošs standarts.
"All standards-compliant MPEG-2 Video decoders are fully capable of playing back MPEG-1 Video streams conforming to the Constrained Parameters Bitstream syntax."

 

MPEG-1 Audio: Viens formāts, bet uzreiz 3 savietojamos līmeņos.
"MPEG-1 Audio is divided into 3 layers. Each higher layer is more computationally complex, and generally more efficient at lower bitrates than the previous.[10] The layers are semi backwards compatible as higher layers reuse technologies implemented by the lower layers. A "Full" Layer II decoder can also play Layer I audio, but not Layer III audio, although not all higher level players are "full".[47]"
 
MPEG-2 Audio:
"The MPEG-2 Audio section, defined in Part 3 (ISO/IEC 13818-3) of the standard, enhances MPEG-1's audio by allowing the coding of audio programs with more than two channels, up to 5.1 multichannel. This method is backwards-compatible (also known as MPEG-2 BC[7][8][9][10]), allowing MPEG-1 audio decoders to decode the two main stereo components of the presentation.[11] MPEG-2 part 3 also defined additional bit rates and sample rates for MPEG-1 Audio Layer I, II and III.[12]"

 

PE un ELF: Var saturēt izpildāmo kodu, bildes, tekstu, un vēl visu ko, kā arī ir fleksibli un papildināmi. PE, pie tam, jau pats ir DOS MZ papildinājums. Un izpildāmo programmu faili tā kā būtu arī pietiekoši "interaktīva" formāta piemērs, vai ne?

 

Vēl arī fragmentāra ielāde nodrošina, ka cilvēks var lasīt daļēji ielādētu lapas saturu. Bināra koda gadījumā rezultāts būtu redzams tikai pilnīgi ielādējoties visam kodam. Interneta traucējumu gadījumā lapa būs tukša vai bezgalīgi lādēsies ar mistisku kļūdu.

Atkal tas pats... Neviens formāts/standarts nav attēlojams korekti, ja tajā iztrūkst kādi dati. Un tas nekādi nav atkarīgs no tā vai tas ir teksta vai binārs formāts. Tāpat arī nav nekādu problēmu izstrādāt bināru formātu, kas attēlos izkropļotu datu saņemtās daļas pat vēl labāk un korektāk kā iespējams parsēt izkropļotu HTML. DOM specifikācijā, starp citu, ir pat noteikts, ka to drīkst parsēt tikai pilnībā pabeigtu. Tikai reti kurš to ievēro. Pakāpeniskas ielādes piemērs ir kaut vai JPEG. JPEG standartā ir divas pieejas. Viena ir parastā progresīvā ielāde, kur bilde lādējas pilnā detalizācijā, bet "no augšas uz leju". Otra ir tāda progresīvā, kur bilde uzreiz tiek saņemta visam laukumam, bet mazākajā detalizācijā (pilnīga miglu bilde) un tad tālākie dati bildei tikai ar vien papildina detalizāciju (it kā uzlabojas asums). Šīs divas pieejas pat pārlūkos var saskatīt, ja ir lēns internets vai lieli JPEG attēli.

 

Es piemēram nevaru iedomāties, kā varētu aizvietot html/xml ar kaut kādu aizvērtu kodu, jo tādā gadījumā dinamiski kaut kādu lapas fragmentu nebūtu iespējams pārģenerēt.

Kur ir problēma tieši tāpat dinamiski ģenerēt bināru formātu? Tajā apstāklī, ka, izstrādājot servera puses programmu (kā tagad PHP), nevarētu tam kodam pa vidu iesmērēt arī datus (kā tagad HTML), bet dati visdrīzāk būtu atsevišķā failā un būtu jālieto kaut kādi mainīgie?

 

Es arī nerunāju par to, kādi servera resursi būtu nepieciešami bināras platformas darbināšanai.

Šodien: Teksts => parsēšana (PHP) => dinamiskā salikšana => pārraide => parsēšana (HTML) => attēlošana.
Developeris tikai rada tekstu. PHP teksta parsēšana un dinamiskā salikšana ir uz servera pleciem un prasa daudz CPU, RAM un HDD resursu, jo viss notiek tekstā. Pārraide aizņem daudz baitu un attiecīgi laika, pie tam arī servera konekcijai. Klienta pusē HTML teksta parsēšana atkal prasa daudz resursu.

Iespējams: Teksts => parsēšana (kompilēšana) => dinamiskā salikšana (linkošana) => pārraide => parsēšana (kaut kas binārs) => attēlošana.

Developeris rada tekstu un kompilē servera puses PHP analoga programmu. Cilvēks, kurš rediģē saturu, vai tas pats developeris, arī saturu "kompilē" klienta HTML analoga formātā. Tas viss ir atsevišķos failos - kā kompilatoram OBJ faili. Tas, vai viņu izstrādes/rediģēšanas datoriem tas prasa sekundi vai minūti, nevienu nekrata, jo tas tiek darīts tikai vienu reizi. Uz servera pleciem paliek gandrīz tikai dinamiska bināru failu salikšana jeb linkošana, kas CPU, RAM un HDD resursus prasa 10+ reizes mazāk kā ar tekstu. Pārraide aizņem 10+ reizes mazāk kā ar tekstu. Klienta pusē bināra formāta parsēšana atkal prasa 10+ reizes mazāk resursu kā ar tekstu. Win-win-win situācija.

 

Arī slodzes pārnešana no klienta uz serveri ir dārga un neefektīva, jo servera resursi nav bezizmēra un tos daudz grūtāk nodrošināt.

Neko neesi sapratis. 90% gan servera, gan klienta slodzes tiek pārnests uz izstrādātāja datoru un slogots tikai VIENU reizi, nevis uz katru pieprasījumu katram attēlot lapu! Skat. augstāk.

 

cik kodeki pa šo laiku ir saražoti un top joprojām? Arī audio looseless jomā ir bardaks, jo nav atskaņotāju, kas spētu visu atskaņot.

Nekorekts salīdzinājums. Dažādiem kodekiem atbilstošās dažādās tehnoloģijas WEBā ir HTML, Flash, Java, Silverlight u.c., kas arī ir pilnībā nesavietojamas un tām nepieciešami plugini. Tieši tāpat kā audio/video pleijeriem priekš dažādiem formātiem ir nepieciešami plugini. Savukārt par viena kodeka versiju attīstību jau augstāk izstāstīju.

 

webs nepārtraukti attīstās

Tā "nepārtrauktība" ir defekts, kas tāds ir dēļ tā, ka W3C ir nespējnieki. Visi normālie standarti arī attīstās, bet "pārtraukti" - pa precīzi definētām standartu versijām. Kā piemēram augstāk minētie MPEG standarti. Vai piemēram aparatūras jomā kaut vai Ethernet 10/100/1000 Mbps - kopš 1985. gada iznākušas 3 versijas un katra ar 10x ātruma pieaugumu. Bināri, atpakaļsavietojami un precīzi standarti - strādā vienmēr, nevis jāzīlē vai šis RealTek modelis strādās ar šo Intel modeli. Kā pie cilvēkiem!

 

 

Caps, man liekas, ka weba principus neesi līdz galam izpratis.

Rezumē... Biedri, kā jums ar kompetenci dažādās tehnoloģiju jomās? Kādēļ zināt tikai kaut ko vienu, bet citu pat principiāli necenšaties saprast un izzināt? Jāsecina, ka esošo WEB tehnoloģiju aizstāvji paši neizprot savu sludināto principu būtību un argumentē ar pilnīgi falšiem un nepamatotiem apgalvojumiem. Viena lieta ir, ja cilvēks nesaprot, bet grib saprast - tad ir jēga argumentēt tālāk. Bet pavisam savādāk ir, ja nesaprot, bet turpina nedomāt ar savu galvu un akli ticēt "mācītāju" sprediķiem - tad tur nelīdzēs nekādi objektīvi argumenti un acu atvēršana. Esmu runājis!

Labots Aprīlis 4, 2013 - Inspektors Caps

[meeris]

<Sonium> someone speak python here?
<lucky> HHHHHSSSSSHSSS
<lucky> SSSSS
<Sonium> the programming language

[japets]

 

Pie tam ietaupījums nav par kaut kādiem procentiem bet vismaz 10 REIZES katrā šajā jomā!

Vai tas uzlabo, piemēram, gala js programmas algoritmisko sarežģītību?

Var cīnīties pret vairāk vai mazāk iedomātiem pretiniekiem, bet tikai tad, kad izcīnītas īstās kaujas.

[Baigais Janka]

Capam pivons no manis. Gadās šajā forumā arī prātīgas domas palasīt Kā krievi saka - polučil udovoļstvije.

[Mezavecis]

Pag, viss jāskatās kompleksi, jo teorētiski visi jaunie devaisi spēlē AVI formātu, bet piemēram nesaprot AC3 skaņu. Es tikai saku ka bez tiem maznozīmīgiem pluginiem nebūs ne bilde, ne skaņa un tavs standartizētais AVI formāts būs nekur nederīgs. Tāpat quicktime, shockvave un citi brīnumi neatskaņojas paši par sevi. Nu nav te nekā standartizēta, jo nodefinētas čaulas, bet pārējais aizgājis pašplūsmā. Analoģiski ar html saistītajām lietām. 

 

Nekorekts salīdzinājums. Dažādiem kodekiem atbilstošās dažādās tehnoloģijas WEBā ir HTML, Flash, Java, Silverlight u.c., kas arī ir pilnībā nesavietojamas un tām nepieciešami plugini. Tieši tāpat kā audio/video pleijeriem priekš dažādiem formātiem ir nepieciešami plugini. Savukārt par viena kodeka versiju attīstību jau augstāk izstāstīju.

 

Mans darbības profils ir saistīts ar weba tehnoloģijām. Vienkārši es redzu reālā dzīvē, pie kā noved funkcionalitātes pārnešana no klienta uz servera, kas izpaužās ātrdarbības trūkumā un ierobežotā funkcionalitātē, jo pie katra sīkuma jāpārkompilē risinājums, kas ir tavs piedāvātais html uzlabotais standarts. Un nevajag teikt, ka tev vienīgam ir absolūta taisnība, jo esi kompetents n-tajās tehnoloģijās. Visas lietas jāapskata no visiem skatu punktiem un kādreiz jāizlien no standartu un dokumentu kalna. 

 

Rezumē... Biedri, kā jums ar kompetenci dažādās tehnoloģiju jomās? Kādēļ zināt tikai kaut ko vienu, bet citu pat principiāli necenšaties saprast un izzināt?

Labots Aprīlis 4, 2013 - Skrandainais

[usver]

 

Patiesībā mēģinājumi jau ir: Binary_XML. Pietiktu kaut ko no šī vai analoģisku tikai atbalstīt W3C, sākt lietot Google

 

 

androīda resursus APK failā paskaties un to, kā Spring/GWT pārsūta datus. 2 no 3 nosauktajiem produktiem ir gūgles.

[ChristheK]

Interesānti, kā šajā forumā tiek atbildēts uz postiem par konkrētu tēmu, laikam lielākā daļa lietotāju atbild pēc kaut kāda primārais-parādīt-ko-tu-zini-labāk-par-citiem-nevis-palīdzēt-saistībā-ar-TĒMU principa. Bet nu paldies visiem, kuri vismaz centās dot kādu informāciju saistībā ar uzdoto jautājumu!

Manā gadījumā esmu ''interns'' kādā firmā, kuras kodi ir Python'ā, tāpēc tieši Python ir aktuāls. Biju domājis, ka pie programmētāja (laba) īpašībām pieskaitāma daudzpusība, arī vairāku paņēmienu, program. valodu zināšana un sevis pilnīga necentrēšana uz kādu šauru zināšanu un prasmju spektru. Varbūt kļūdos, nezinu esmu jauns šajā sfērā...

[deriksx]

tu nekļūdies, forums tāds

[tr4nkv]

Kursus neiesaku, kursi, manuprāt, nav vajadzīgi. Iesaku Coursera + MIT edX, tur ir pitons, viens čoms kuram vajadzēja pitonu savām nodarbēm tīri veiksmīgi sāka viņu tur mācīties un kaut ko darīt.

 

 

 

 

Offtopic, bet saistīts ar šo tēmu. Šobrīd esmu nodarbināts IT jomā, bet programmētājs neesmu. Programmēju brīvā laikā, sava prieka pēc. Palasīju lietotāja Inspector Caps domas šajā tēmā, dažām piekrītu, bet ir jautājums - ja jau RTU un LU piedāvā "biznesa līksoftu uzturēšanas un developēšanas" kursus tad kāda tam ir alternatīva? Kur mācīties?

[ChristheK]

tr4nkv +9999 paldies par super nodergajiem atslegasvardiem!