Wuu

CNC kods nepieciešams uz konsoles, kas darbina CNC. Validācija notiek matemātiski. Prastākam CNC esmu uzstādījis node.js klientu, tur vispār cilvēks neko vairs nedara, imho, viss vajadzīgais ģenerējams automātiski. node.js paskatās, vai datubāzē nav jauns pasūtījums, ja ir, uzģenerē.

400mb toč frontendā nebāzīšu, tas ir ektrēmi, pat 10mb ir diezgan 0.99999% gadījums. Es vienkārši ar piemēru pierādu, ka frontends neatpaliek, pie prastas apstrādes būs ātrāks, par datu nosūtīšanu uz serveri un atpakaļ. Un nekādas problēmas ar atmiņu nav. Man viss fronteds ir React'ā sapakots, pat uz sūda planšetēm, griežas un darbojas 100% ātrāk par standarta "pie katra klikšķa novelc svaigākos failus". Man liekas, ka šis vairāk ir pieraduma faktors. Ja datu apstrāde, tad tikai servera pusē - frontends vairāk par css un html neko nemāk. Mierīgi, klienta pusē ģenerēju CNC programmas un apstrādāju medicīniskos legacy XML'us no rentgena diagnostikas :D

Kavacky, kam tev zem dependencies gulp un laravel-elixir? Tas viss iet zem devDependencies (Klients par to visu nekad neuzzinās), un man reāli pajāt, ja izstrādājot produktu man būs 10GB ar failiem kas paātrina procesu, tas būs to vērts. F3llony... Piemērs ar 120mb CSV faila ielādi un apstrādi (Izvadīt key, un pirmos 8 simbolus) klienta pusē. Viss lielāko laiku aizņem datu izvade! (Neviens normāls cilvēks 52k tabulu rindas vienā lapā nerāda) Ja attēlo normāli lapaspuses, tad ir FileReader ielādes laiks. http://postimg.org/image/s6oyhudjf/full/ 3.5 sekundes. Pārējie var turpināt lipināt POST formas un sūtīt datus turpu šurpu. Man tā ir vieglāk un cilvēkiem darbs raitāk iet uz priekšu. (Pietam man ir Windows serveris ar kaut kādu gatavu mysql,php,apache uzparikti kas darbojas uz malkas, spriežot pēc ātruma, bet es tur neko nevaru mainīt.) 100mb uz viņu sutās apmēram minūti.

Pierādi :> Ikdienā strādājam ar +100mb failiem, no lietotājiem dzirdu tikai pozitīvas atsauksmes par to ka ielādēs formas ar POST ir aizvāktas. Tiko notestēju, 120mb fails klienta pusē ielādējās 2 sekundēs. Un beigās, ko ar to blāķi darīsi? Tāpat vajadzēs piejūgt meklēšanu, kaut vai banālas lapaspuses. Visu darīsi ar serveri? Katru reizi sūtīsi jaunu pieprasījumu un gaidīsi atbildi? Oj, pasmējos, nopietni, izlasi kā javascripts glabā datus atmiņā un tad raksti... dievs pasarg... Runājot par paketēm, jebkurš var jebko piedrazot ja labi grib. Nav atkarīgs no valodas vai veida. Man ir šādi: "dependencies": { "history": "1.17.0", "react": "0.14.0", "react-dom": "0.14.0", "react-router": "1.0.3", "socket.io-client": "1.4.0" } Servera pusē "dependencies": { "mongoose": "4.3.5", "socket.io": "1.3.7", "winston": "2.1.1" }

Pierādi, un tad mētājies ar apgalvojumiem. Neredzu atšķirību starp atmiņas patēriņu CSV datiem, kas uz klienta, vai servera konvertēti un attēlojas klienta pusē.

Tas protams atkarīgs no lapas uzdevuma, bet jāsaprot, ka klienta puse mūsdienās ir ļoti spēcīga un pielietojums var būt plašs. Kādreiz dzenāju CSV failus uz serveri un konvertēju, tagad visu daru klienta pusē. Starp React komponentiem dalos ar base64 failu stringiem. Būtībā, servera puse tiek piesaukta, tikai kad nepieciešams kaut ko konkrēti saglabāt, vai nolasīt. Bet ja darbs notiek ar TEMP klienta failiem, to visu, mierīgi var izdarīt klienta pusē, neaiztiekot serveri.

Es vienmēr apbrīnoju, cik lēni twiiters spēj ielādēt jaunāko saturu uz visām platformām. Lai viņi iet dir** ar saviem ieteikumiem.

Trolis, neizmantoju PHP satura apstrādei/izvadīšanai, ja saturs paredzēts attēlošanai interneta pārlūka grafiskā veidā. Apmierināts?

Ja Javascriptu var pavilkt, node.js + Reactjs. Jo rakstīt visu projektu vienā valodā ir daudz efektīvāk un ērtāk. Nevis pārslēgties starp vairākām valodām vienlaicīgi.

Apmēram, jau gadus divus esmu atteicies no jebkāda PHP klienta pusē, sākumā ar javascript GET'ie pildīju saturu. Tagad, React, React-router un Flux veikali - iepakots ar Webpack. Redzot PHP, kurš apstrādā HTML, man reāli šermuļi metas. Tā ir maģija, kad klienta puse no servera puses ir pilnvērtīgi atdalīta. Reāli, ar abiem vienlaicīgi ir grūtāk un lēnāk strādāt. Pluss, veic izmaiņas klienta pusē, nebaidoties kaut ko sačakarēt servera pusē. Un klients laimīgāks, jo aplikācija strādā ātrāk, imho, kaut vai uz desktopa nomet html failus un viss darbosies tik un tā. Nevis, pie katra klikšķa, lejuplādē vienus un tos pašus failus ar minimālām izmaiņām. Pēdējā puss gadā laika, no PHP arī atteicos, jo node.js ir daudz ērtāks.

Lētāk, bet kas notiek - kad tu pazūdi, atbalsts, jaunas fīčas. Es runāju no klienta puses, pašam nācies bīdīt šādus projektus. Nopietnos uzņēmumos, pie ieviešanas, paprasīs vismaz 3 piedāvājumus, kurus izskatīs. Ja tev nav ilgstoši stāžs un klientu kaudze, grūti šādu piedāvājumu apstiprināt. Bet ražošanas industrijas datu analizēšana konveijeriem, procesa automatizēšana ir laba lietu kur mērķēt. Jo šobrīd tur ir pilnīgs vakums, visas tehnoloģijas atpaliek pa gadiem 10, no normāliem risinājumiem.

I27, intresants darbs :D Es to pašu daru kopš 2013. gada. Kad domāju, ka jQuery ir zelts. Jebkurā gadījuma, pārāk daudz konkurentu šajās jomās, neredzu perspektīvas priekš tevis. Par to pašu konveijeri, http://evocon.com/, 25$ par posmu, paši uzstāda, atbalsta un iesaka. Mēra netikai skaitu, bet metrus, utt... Neteicās, ka nopietns uzņēmums ietu pie tevis un pirktu jebkādus risinājumus. Ieteiktu fokusēties uz vienu produktu un attīstīt to. Tomēr, šā joma ir daudz interesantāka, par blogu, veikalu un lapeļu drukāšanu. Prieks redzēt :)

Izklausās pēc ikdienas PHP problēmām. Bija doma pamēģināt Laravel, vai Symfony, tā sabiedējāt, ka ar ar routēm netiek galā, paldies nē. Papētot Laravel, redzams, ka bez kā tāda uz PHP rakstīt mājaslapas nebūtu iespējams. Savādāk jūstos kā atpalicis un ar skaudību skatītos uz node vai Go. Symfony ir paredzēts hardcore večiem ar bārdu :>

Ieliec pilnu kodu, tā funkcija, nav zinām kā tu viņu lieto. Tanī paša fidlē ar css un html..

Patestēju ilgāku laiku un teikšu ka nekas labs nesanāk. Vienkārši, ja strādā ar gataviem API un pārsvarā tikai ar render() attēlošanu, tad der un ir ērti. Bet būsim reāli, tas ir stipri šaurs pielietošanas veids. Pats paralēli , gan frontendu, gan API rakstu, neiet kopā, beigās sanāk ka F5 biežāk jāspaida, nekā vajag. Un ja javascript kļūda iziet caur kompilatoru, tad grūti saprast kur vaina, citriez ar F5 kļūda pazūd, lieks laiks patērēts. Būs laiks, būs jāpieskrūvē slēdzis, kurš ļauj pārslēgties no hot reload uz pilnu pārlādi un atpakaļ.

Ir, vienkārši ieraudzīju "showMatch" funkciju google un uzreiz aizvēru, domāju kārtējā skriptu kaudze. Izrādījās normāls manuālis :D

Tādā gadījuma es pats varu uzrakstīt funkciju, interesē pa tiešo ar RegExp

Kā ar Javascript RegExp sameklēt tālāko rezultātu? Parasti to darīju meklējot simbola atrašanās vietu stringā. Varbūt ir iespēja ar RegExp, pa taisno? Piemēram {DCg{aasss}}}{aaaaa:_aaaaa} {}}[] }Za?} Atrast visu, meklējot pēc "{" - "}"

Protams, bet to visu manā vietā dara socket.io. Man pusē, atkrīt, tam visam sekot līdzi :D Man pēc Http Requestiem, socket.io atgādina maģiju. Atpakaļ mani nekas neiestums. Tas pats ar React, ja kaut kas ir lielisks, gribas nošauties, ja jālieto kas cits.

Skaties, Clienta pusē Vārds, objekts, callback io.emit('transfer', {func: '/user/logout', key: this.data.__session__key}, (data) => { //Daram ar 'data' ko gribam }) Server pusē, callback({ko vēlamies nosūtīt}) Un tas uzreiz izdarās klienta pusē, būtībā nosūtam funkciju. :) Ērti! Tev nevajag clienta pusē taisīt klausītājus. Tāds vienkāršs get, vien sanāk. Un var nosūtīt Javascript objektu/arraju kāds viņš ir, nevis JSON.stringify() un JSON.parse() turpu, šurpu. Nezinu, varbūt ar HTTP tāpat var, neesmu redzējis, ka kād stā darītu, visur piedāvā jsonu konvertēt. Būtībā, no mongo paņem arrayu un pa taisno viņu nosūti, kāds viņš ir. Es kad atskatos, kā es šo daru ar PHP API un Ajax req... #%^&*#@(*#@*!!!#@ socket.on('transfer', (req, res) => { UserSchema.find({}, (err, docs) => { res(docs) //Pa taisno nosūtam uz clientu }) })

Baigi ērti piejūgt pie Flux storēm un pušot atjauninājumus/notifikācijas, un ir daudz ērtāk strādāt, ja clients ir uz Javascripta uzrakstīt. Sūti pa taisno objektus, bez jebkādas konvertācijas JSON un atpakaļ uz objektiem. Cik studēju, atvērts sockets neprasa ēst. Kad pamēģini pastrādāt ar socket.io, galīgi nav vēlmes iet atpakaļ uz akmens laikmetu. Protams milzīgām lapām, tas nav variants. Sākuma ar biju skeptisks, bet tad uzrakstīju JavaScript interneta ātruma mērītāju, kas lieto socket.io. Pirmkārt rāda precīzus mērījumus, otrkārt līdz 120mb/s sūta, un nejūt. Neesmu mēģinājis ar diviem datoriem lokāli, iespējams varētu vairāk izspiest.

Loopback izskatījās ok, līdz gribēju piejūgt socket.io. Nepavilku. Ja vajag prastu REST api, tad gan baigā bomba un ērtība. Sequelize, manuālis drausmīgs, loģikas nekādas, ļoti atgādina PHP :> Pēc Moongose, liekas ka viņi pīpē kaprona zeķes. Arī github'ā, tās lietas, ko atbild autori, liek domāt, ka production not ready 100%. Ar MongoDB ir viena problēma, cilvēki sūdzas, jo lietot nemāk un nesaprot, kāpēc MongoDB neuzvedas kā MySql. Es ar sākuma biju skeptisks, bet katru reizi lasot viņu problēmas, smiekli nāk. Visiem viņiem ceļš uz https://university.mongodb.com/

Kādus lietojam? Ieteicams ilgāk. Standartā, reāli tracina darboties ar MySql uz node.js un šobrīd nav iespējas pāriet uz ko jēdzīgāku. Sequelize nav variants, tad es labāk veltu nedēļu un uzrakstu pats savu, neko lietoju kaut ko tik drausmīgu.

Tā jau ir reliģijas tēma.

Nezinu, pierasts :D Aizvācu.