codez

Tur, kur pings ir 200ms (vai 500ms, kā te kāds piedāvā), tur arī tāds ir reālais ātrums. Normāli pings ir 10 - 30ms. Paņem šo un saliec kopā ar 10 Mb/s interneta pieslēgumu un tev sanāks tas pats, ka servera pusē ģenerēts variants ir 2-4 reizes lēnāks.

Reālā situācijā nē. Teiksim lietotāja, reālais tīkls ir 0.3 MB/s. Dati raw formā aizņem 60kB, bet HTML formā 300 kB, bet teiksim pliks htmls 30 kB Ja renderē servera pusē, tad ir 100ms html requests + 1000 ms datu pārraide = 1200ms Ja renderē klienta pusē, tad: 1. pieprasījums 100ms html requests + javascript sāk lādēties jau pēc 10ms, jo html tiek pārsēts tik, cik jau ielādēts + 100ms js faila requests + 100ms js faila trafiks + 100ms ajax requests + 200ms ajax trafiks = 610ms taču nākamajā requestā, html ir nokešots, js ir nokešots un ir tikai 100ms ajax requests + 200ms trafiks = 300ms

Ja jau tie footeri un headeri tik statiski, kāpēc viņus ģenerēt backendā, ja viņu tādā gadījumā var uzģenerēt frontendā, bez papildus informācijas.

Man šķiet, ka tieši klienta pusē ģenerēt ir ātrāk, jo galvenais botlenecks ātrumam ir tieši tīkls un raw dati parasti aizņems vairākas reizes mazāk vietas kā šie dati ieģenerēti htmlā.

http://www.jobsite.co.uk/vacancies?search_type=quick&engine=solr&search_referer=internal&title_query=remote&location=&radius=20&daysback=

Neesu gan vācis dziļu statistiku, bet ik pa laikam paskatoties, kas darās Londonas remote piedāvājumu darba tirgū, ir palicis iespaids, ka C#-istiem piedāvā aptuveni tikpat, cik pythonistiem un rūbijiestiem, tas ir ap 200 - 300 GPB / dienā, kamēr Skalai tās summas vairāk tiecas uz 400 - 600 GBP / dienā.

Iesaku pamēģināt backendam Scala + Play!, bet frontendam Reactjs.

Taisiet scalā, nevajadzēs dizainu.

Why an Ex-Google Coder Makes Twice as Much Freelancing

Piemēram, mans projekts biome3d nekādi nestrādātu ar http, pat ar visiem longpolliem, utml., jo ir nepieciešams saņemt informāciju no servera 20x sekundē. Es protams saprotu, ka tā nav ikdienišķa web aplikācija, bet arvien vairāk web aplikācijas sastopas ar nepieciešamību pēc realtime datiem no servera. Tas var būt kāds RT analītikas grafiks, čats, notificationi no servera, utml. Pirms websocketa visi lietoja longpoolus un daudz kur vēl lieto, bet tiem ir vajadzīgs regulārs reconects un liels headeru trafika overheads, ja saņemtie dati ir niecīgi. Ja nemaldos websocketa messidžam ir 6 baitu overheads, pretstatā kādiem 500 - 2000 baitiem http requesta gadījumā. Un, ja jau nepieciešamība pēc websocketiem rodas, tad kāpēc arī visus pārējos datus netransportēt caur websocketiem.

Tieši tā - nedaudz smukāks un kā jau iepriekš minēja nav jau visi tie paši plusi un mīnusi, tieši tās atšķirības viņu padara savādāku un daudzos gadījumos noderīgāku.

Socketu plusi: - socketiem nav jāgaida konekcijas izveidošana, kas pie bremzīga tīkla aiz n-tiem firewāliem aizņem reāli jūtamu laiku, tāpēc aizture ir mazāka. - socketiem var sūtīt datus no servera, negaidot, kad klients tos paprasīs. Tas ir liels bonuss. - sockets var sūtīt binārus datus, kas atkarībā no situācijas, ļauj samazināt datu plūsmu pat līdz 5 reizēm. Tas, ko esmu pamanījis, ka arvien vairāk un vairāk parastas web appas, kuras varētu iztikt bez tā, izvēlas websocketus, jo ir daudz bonusu. Viena kaste var mierīgi turēt 100k - 1M atvērtu konekciju (atkarībā no tehnoloģijas kādu izmanto). Tas ne tuvu nebūs bootlnecks web sistēmai.

Kreatīna efekts ir izteiktāks un var sākt ar to. Deva ir ap 3 - 5g / dienā. Taču, sākot lietot kreatīnu, organisms piesātinās pakāpeniski, tāpēc pirmo nedēļu var droši lietot 5 - 20g dienā. Acetil-L-karnatīnu - 1 - 2 grami / dienā. P.S. Par lietotšanu: Kreatīns pārdodas kristāliska pulvera veidā, tāpēc to pirms lietošanas ir jāizšķīdina. Ja neizšķīdina, kristāli kairina (durās) kuņģi. Kreatīna šķīdība ir diezgan vāja, tāpēc to ir grūti izšķīdināt aukstā ūdenī. Labāk izmantot siltu un, ja deva ir vairāk par 5 grami, var nākties arī izmantot vairāk par 200ml ūdens. Ir protams arī kapsulās, bet, ja tajā kapsulā iekšā ir tas pats kristāliskais pulveris, tad labāk tādas nelietot. Karnatīns - pārsvarā kapsulās. Bet, ja pulverī, tad tāpat izšķīdina dzērienā.

Bet, ja pieturās pie oriģinālās tēmas, tad, manuprāt, pašlaik vislabākais veids kā būtiski uzlabot savas kognitīvās spējas ir ar: 1)Kreatīnu, kuru var nopirkt jebkurā sporta pārtikas veikalā. Lai arī lielākoties cilvēki viņu izmanto, lai palielinātu enerģijas piegādi muskuļos, viņš efektīvi to pašu dara arī nervu šūnās. Tāpat pētījumos pierādīts, ka ilglaicīga kreatīna lietošana neatstāj nekādu negatīvu efektu uz veselību. 2)Acetil-L-karnatīnu. Šo pie mums par saprātīgām cenām neesmu atradis, bet var pasūtīt no, piemēram, amazones(Vācijas), vai kāda cita internetveikala. Parastais L-karnatīns nespēj pārvarēt asins-smadzeņu barjeru, tāpēc nav efektīvs. Man personīgi šīs vielas uzlabo produktivitāti vismaz vairāk reizes.

Īsumā - raksts ir rakstīts vienā virzienā un esmu lasījis tur apskatītos pētījumus. Man pašreizējā izpratne par MSG ir šāda: Visa bīstamība ar MSG ir tad, kad tā koncentrācija būtiski pieaug asinīs. Tāpēc arī daudzi eksperimenti ar salīdzinoši mazu devu injekciju, liecināja par nervu sistēmas bojājumiem. Savukārt, cilvēka vielmaiņa, uzņemot nelielas devas MSG, spēj nodrošināt, lai tā koncentrācija asinīs būtiski nepalielinātos un tikai pie lielākām MSG devām īsā laikā, sākas nozīmīga MSG koncentrācijas palielināšanās. Šī robeža pieaugušam cilvēkam ir 2 - 5g MSG vienā ēdienreizē. Savukārt bērniem papildus bīstamības faktors ir tāds, ka to neuroni vēl nav apauguši ar mielīnu un ir ievainojamāki. Tā kā, lai šādus MSG daudzumus uzņemtu, ir īpaši jāpacenšas, tad domājams, ka daudz lielāks MSG kaitīgums sabiedrībā kopumā ir tajā faktā, ka tā radītā garšas un eiforijas sajūtu, veicina to, ka cilvēki apēd ļoti daudz draņķīgas pārtikas.

Kāds ir iemesls izmantot gulpu? Manuprāt, webpack pilnībā pārklāj gulp-a funkcionalitāti. Ja nu vienīgi pierasts un ir labākas zināšanas kā to konfigurēt.

git clone https://github.com/rackt/redux.git cd redux/examples/todos-with-undo npm install npm start un pārbaudi http://localhost:3000

Man no šiem piemēriem todos-with-undo un counter piemērs strādā (pārējos nemēģināju): https://github.com/rackt/redux/tree/master/examples

Gulp pēc būtības ir task menidžeris, viņam nav nojausma par projekta struktūru un dependencijiem, visas projekta dependencijas ir jākonfigurē. Gulp nevar viens pats nodrošināt viena moduļa ielādi pēc tā izmaiņām, jo viņam nav nojausma par projekta struktūru. Ja gulp ir task menidžeris, tad webpack ir projekta menidžeris. Topiks vairāk ir par tendencēm forntend izstrādē. Gribi teikt, ka esi agrāk izmantojis workflowu, kurā tu pārlūkā savā app-ā izdari pāris darbības, tās tiek ielogotas, izmaini kāda moduļa kodu, tas tiek automātiski ielādēts un pirms tam izdarītās darbības automātiski tiek izdarītas vēlreiz uz jaunā koda un tu redzi jauno rezultātu, kāds tas izskatās ar iepriekš veiktajām darbībām un redzi visu ceļu kā mainās app-a stāvoklis pēc katras darbības? Kaut vai video parādītais piemērs ar counteri, kurā ir React komponente, kurai ir stāvoklis un funkcija, kas šo stāvokli maina. Tu izmaini šo funkciju, kura maina stāvokli, saglabā un "hot module reloadings" ielādē tev jauno react komponenti, pie tam saglabājot tās iepriekšējo stāvokli un atjaunojot tikai funkciju, kas maina šo stāvokli. Nedomāju, ka tavā aprakstītājā workflof-ā un rīkos kas tāds ir iespējams.

Es piekrītu, ka dažreiz vienkāršākām aplikācijām ir vieglāk stāvokli glabāt vienkārši react komponentēs. Bet, jo aplikācija paliek sarežģītāka un, jo vairāk dažādām komponentēm pārklājas datu kopas, ko tās izmanto, jo viss kļūst par lielāku bardaku un saglabāt kārtību stāvoklī kļūst arvien sarežģītāk, un tas prasa papildus darbu pretstatā, ja dati glabājas vienā kopējā storē. Redux galvenā ideja ir tāda, ka actions tiek definēts kā stores transformācija, tādā veidā var panākt visās tās skaistās fīčas (time travel, undo/redo, action replay), kuras varbūt gala produktam nevajag, bet izstrādes procesu noteikti atvieglo. Es izmēģināju Redux-u un man personīgi viņš nepatika. Actionu definēšana likās pārāk verbose. Reduxam nav atstrādāta paterna kā veidot stori ar Immutable.js Plus esmu pieradis strādāt ar cursor-iem storē, kuri arī nav Reduxā implementēti (plus vēl kombinācijā ar Immutable.js). Bet viss pārējais no tā video pat baigi patika - jau jaunajā projektā iekļāvu Webpacks + es6 moduļu struktūru (ar babel) + hot module reload - beidzot, tas kā tiek organizēts javascript projekts, man patīk. Visi moduļi ir īsi un kodolīgi, ir skaidri redzams, kas no kā ir atkarīgs, viss tiek automātiski sapakots kopā ar 3rd party bibliotēkām, stylšītiem, bildēm, utt. + arī visas obfucēšanas, minificēšnas, utt. Izmaini kādu moduli, tas bez aplikācijas refrešošanas atjaunojas un uzreiz redzi izmaiņas, gan izskatā, gan funkcionalitātē. P.S.: Aptuveni šādi tagad izskatās React komponentes modulis es6 javascriptā: import React, { Component } from 'react' import actions from './actions' import { Link } from './components/Helpers' export default class extends Component { render() { return <div> <button onClick={()=>actions.doSomthing()} /> <Link to="home" /> </div> } }

Varbūt kāds jau izmanto, bet izskatās pēc diezgan laba frontend workflow-a. https://github.com/rackt/redux https://webpack.github.io/ https://github.com/gaearon/react-transform-boilerplate

Zaļums ir pieredze, nevis darbības ilgumu, kurš arī ir jau vairāk kā 4 gadi, tāpēc ņemot vērā to un atrodoties 2. pozīcijā pēc serveru skaita, domāju, ka uzskatīt DO par zaļiem, ir vairāk kā nekompetenti. Pie tam ņemot vērā, ka MPr izvēlētais fastcomet ir dibināts 3 gadus atpakaļ un ir jaunāks par Digital Ocean un nav pat hostinga kompānija, bet ir kaut kāds starpnieks, kurš sēž citā hostinga kompānijā.

Šķiet, ka rakstā pat nebija pieminēts, ko konkrēti projekts dara, tik tas, ka bija ļoti daudz failu pieprasījumu un par bootlnecku kļuva kaut kādi failu sistēmas locki.

http://news.netcraft.com/archives/2015/05/01/digitalocean-becomes-the-second-largest-hosting-company-in-the-world.html

Mhm, tajā rakstā runa bija par miljoniem failu no kuriem tūkstošiem failu tiek izmantoti paralēli.