Bemærk. overs.: Denne artikel, som blev et hit på Medium, er en oversigt over centrale (2010-2019) ændringer i programmeringssprogenes verden og det tilhørende teknologiøkosystem (med særligt fokus på Docker og Kubernetes). Dens oprindelige forfatter er Cindy Sridharan, som har specialiseret sig i udviklerværktøjer og distribuerede systemer - især hun skrev bogen "Distributed Systems Observability" - og er ret populær på internetområdet blandt it-specialister, især interesseret i emnet cloud native.
Da 2019 nærmer sig enden, ville jeg dele mine tanker om nogle af de vigtigste teknologiske fremskridt og innovationer i det seneste årti. Derudover vil jeg forsøge at se lidt ind i fremtiden og skitsere de vigtigste problemer og muligheder i det kommende årti.
Jeg vil gerne gøre det klart, at jeg i denne artikel ikke dækker ændringer inden for områder som datavidenskab (datavidenskab), kunstig intelligens, frontend engineering osv., da jeg personligt ikke har tilstrækkelig erfaring med dem.
Typifikation slår tilbage
En af de mest positive tendenser i 2010'erne var genoplivningen af statisk maskinskrevne sprog. Sådanne sprog forsvandt dog aldrig (C++ og Java er efterspurgte i dag; de dominerede for ti år siden), men dynamisk typesprog (dynamik) oplevede en betydelig stigning i popularitet efter fremkomsten af Ruby on Rails-bevægelsen i 2005 . Denne vækst toppede i 2009 med open source af Node.js, som gjorde Javascript-på-serveren til en realitet.
Over tid har dynamiske sprog mistet noget af deres tiltrækningskraft inden for skabelse af serversoftware. Go-sproget, der blev populært under containerrevolutionen, virkede bedre egnet til at skabe højtydende, ressourceeffektive servere med parallel behandling (hvormed skaberen af Node.js selv).
Rust, der blev introduceret i 2010, omfattede fremskridt i i et forsøg på at blive et sikkert og maskinskrevet sprog. I den første halvdel af årtiet var industriens modtagelse af Rust ret lunken, men dens popularitet steg markant i anden halvdel. Bemærkelsesværdige anvendelsestilfælde for Rust omfatter dets brug til , (vi talte om det i - ca. oversættelse), en tidlig WebAssembly-compiler fra Fastly (nu en del af bytecodealliance) osv. Med Microsoft overvejer muligheden for at omskrive nogle dele af Windows OS i Rust, er det sikkert at sige, at dette sprog har en lys fremtid i 2020'erne.
Selv dynamiske sprog fik nye funktioner som (valgfri typer). De blev først implementeret i TypeScript, et sprog, der giver dig mulighed for at oprette maskinskrevet kode og kompilere den til JavaScript. PHP, Ruby og Python har deres egne valgfri skrivesystemer (, ), som med succes bruges i .
Returnerer SQL til NoSQL
NoSQL er en anden teknologi, der var meget mere populær i begyndelsen af årtiet end i slutningen. Jeg tror, der er to grunde til dette.
For det første viste NoSQL-modellen sig, med dens mangel på skema, transaktioner og svagere konsistensgarantier, at være sværere at implementere end SQL-modellen. I med titlen "Hvorfor du bør foretrække stærk konsistens, når det er muligt" (Hvorfor du bør vælge stærk konsistens, når det er muligt) Google skriver:
En af de ting, vi har lært hos Google, er, at applikationskoden er enklere, og udviklingstiden er kortere, når ingeniører kan stole på eksisterende lager til at håndtere komplekse transaktioner og holde data i orden. For at citere den originale Spanner-dokumentation, "Vi mener, at det er bedre for programmører at håndtere applikationsydelsesproblemer på grund af transaktionsmisbrug, når der opstår flaskehalse, i stedet for konstant at have fraværet af transaktioner i tankerne."
Den anden grund skyldes stigningen af "udskalering" distribuerede SQL-databaser (som f.eks и ) i det offentlige skyrum, såvel som Open Source-alternativer som CockroachDB (vi taler også om hende - ca. oversættelse), som løser mange af de tekniske problemer, der fik traditionelle SQL-databaser til at "ikke skaleres." Selv MongoDB, engang indbegrebet af NoSQL-bevægelsen, er nu distribuerede transaktioner.
I situationer, der kræver atomlæsning og skrivning på tværs af flere dokumenter (på tværs af en eller flere samlinger), understøtter MongoDB multi-dokument transaktioner. I tilfælde af distribuerede transaktioner kan transaktioner bruges på tværs af flere operationer, samlinger, databaser, dokumenter og shards.
Total streaming
Apache Kafka er uden tvivl en af de vigtigste opfindelser i det seneste årti. Dens kildekode blev åbnet i januar 2011, og gennem årene har Kafka revolutioneret måden, virksomheder arbejder med data på. Kafka er blevet brugt i alle virksomheder, jeg har arbejdet for, lige fra startups til store virksomheder. De garantier og use cases, det giver (pub-sub, streams, begivenhedsdrevne arkitekturer) bruges i en række forskellige opgaver, fra datalagring til overvågning og streaminganalyse, efterspurgt inden for mange områder såsom finans, sundhedspleje, offentlig sektor, detailhandel mv.
Kontinuerlig integration (og i mindre grad Kontinuerlig Deployment)
Kontinuerlig integration dukkede ikke op i de sidste 10 år, men i løbet af det sidste årti har spredt sig i den grad, som blev en del af standard workflowet (kør test på alle pull-anmodninger). Etablering af GitHub som en platform til udvikling og lagring af kode og, endnu vigtigere, udvikling af en arbejdsgang baseret på betyder, at det er at køre test før accept af en pull-anmodning til master kun arbejdsgang i udvikling, velkendt for ingeniører, der startede deres karriere inden for de sidste ti år.
Kontinuerlig implementering (implementering af hver commit, når og når den rammer master) er ikke så udbredt som kontinuerlig integration. Men med overfloden af forskellige cloud-API'er til implementering, den voksende popularitet af platforme som Kubernetes (som giver en standardiseret API til implementeringer) og fremkomsten af multi-platform, multi-cloud værktøjer som Spinnaker (bygget oven på de standardiserede API'er), er implementeringsprocesser blevet mere automatiserede, strømlinede og generelt mere sikre.
Containere
Containere er måske den mest hypede, diskuterede, annoncerede og misforståede teknologi i 2010'erne. På den anden side er det en af de vigtigste nyskabelser i det foregående årti. En del af årsagen til al denne kakofoni ligger i de blandede signaler, vi modtog fra næsten overalt. Nu hvor hypen er stilnet lidt, er der kommet skarpere fokus på nogle ting.
Containere er blevet populære, ikke fordi de er den bedste måde at køre en applikation på, der opfylder behovene i det globale udviklerfællesskab. Containere blev populære, fordi de med succes passede ind i en markedsføringsanmodning om et bestemt værktøj, der løser et helt andet problem. Docker viste sig at være fantastisk et udviklingsværktøj, der løser det presserende kompatibilitetsproblem ("virker på min maskine").
Mere præcist blev revolutionen lavet Docker billede, fordi det løste problemet med paritet mellem miljøer og gav ægte portabilitet ikke kun af applikationsfilen, men også af alle dens software- og driftsafhængigheder. Det faktum, at dette værktøj på en eller anden måde ansporede populariteten af "containere", som i det væsentlige er en implementeringsdetalje på meget lavt niveau, forbliver for mig måske hovedmysteriet i det sidste årti.
Serverless
Jeg vil vædde på, at fremkomsten af "serverløs" computing er endnu vigtigere end containere, fordi det virkelig gør drømmen om on-demand computing til virkelighed (On-demand). I løbet af de sidste fem år har jeg set den serverløse tilgang gradvist udvides i omfang ved at tilføje understøttelse af nye sprog og kørselstider. Fremkomsten af produkter som Azure Durable Functions ser ud til at være det rigtige skridt hen imod implementeringen af stateful-funktioner (samtidigt en afgørende relateret til FaaS-begrænsninger). Jeg vil med interesse se, hvordan dette nye paradigme udvikler sig i de kommende år.
Automation
Den måske største fordel ved denne tendens er driftsingeniørsamfundet, da det har gjort det muligt for koncepter som infrastruktur som kode (IaC) at blive en realitet. Derudover er passionen for automatisering faldet sammen med fremkomsten af "SRE-kulturen", som har til formål at tage en mere software-centreret tilgang til driften.
Universal API-fikation
Et andet interessant træk i det sidste årti har været API-fikation af forskellige udviklingsopgaver. Gode, fleksible API'er giver udvikleren mulighed for at skabe innovative arbejdsgange og værktøjer, som igen hjælper med vedligeholdelse og forbedrer brugeroplevelsen.
Derudover er API-ficering det første skridt mod SaaS-ficering af en eller anden funktionalitet eller værktøj. Denne tendens faldt også sammen med stigningen i popularitet af mikrotjenester: SaaS er blevet blot endnu en tjeneste, der kan tilgås via API. Der er nu mange SaaS- og FOSS-værktøjer tilgængelige inden for områder som overvågning, betalinger, belastningsbalancering, kontinuerlig integration, advarsler, funktionsskift (funktionsmarkering), CDN, trafikteknik (f.eks. DNS) osv., som har blomstret i det seneste årti.
observerbarhed
Det er værd at bemærke, at vi i dag har adgang til meget mere avanceret værktøjer til at overvåge og diagnosticere applikationsadfærd end nogensinde før. Prometheus-overvågningssystemet, som fik Open Source-status i 2015, kan måske kaldes det bedste overvågningssystem fra dem, som jeg har arbejdet med. Det er ikke perfekt, men et betydeligt antal ting er implementeret på den helt rigtige måde (f.eks. støtte til målinger [dimensionalitet] i tilfælde af metrikker).
Distribueret sporing var en anden teknologi, der trådte ind i mainstream i 2010'erne, takket være initiativer som OpenTracing (og dets efterfølger OpenTelemetry). Selvom sporing stadig er ret vanskelig at anvende, giver nogle af de seneste udviklinger håb om, at vi vil frigøre dets sande potentiale i 2020'erne. (Bemærk: Læs også i vores blog oversættelsen af artiklen ""af samme forfatter.)
Ser på fremtiden
Desværre er der mange smertepunkter, der afventer løsning i det kommende årti. Her er mine tanker om dem og nogle potentielle ideer til, hvordan man kan slippe af med dem.
Løsning af Moores lov-problemet
Slutningen af Dennards skaleringslov og halten bag Moores lov kræver nye innovationer. John Hennessy ind forklarer hvorfor problemafhængige (domænespecifik) Arkitekturer som TPU kan være en af løsningerne på problemet med at halte bagefter Moores lov. Værktøjssæt som fra Google ser allerede ud til at være et godt skridt fremad i denne retning:
Compilere skal understøtte nye applikationer, nemt kunne porteres til ny hardware, forbinde flere lag af abstraktion lige fra dynamiske, administrerede sprog til vektoracceleratorer og software-kontrollerede lagerenheder, samtidig med at de leverer switches på højt niveau til auto-tuning, hvilket giver lige- i funktionalitet -tid, diagnostik og distribution af fejlfindingsinformation om systemernes funktion og ydeevne i hele stakken, mens det i de fleste tilfælde giver en ydeevne, der er rimelig tæt på håndskrevet assembler. Vi har til hensigt at dele vores vision, fremskridt og planer for udvikling og offentlig tilgængelighed af en sådan kompileringsinfrastruktur.
CI / CD
Mens fremkomsten af CI er blevet en af de største trends i 2010'erne, er Jenkins stadig guldstandarden for CI.
Dette rum har et stærkt behov for innovation på følgende områder:
- brugergrænseflade (DSL til kodning af testspecifikationer);
- implementeringsdetaljer, der vil gøre det virkelig skalerbart og hurtigt;
- integration med forskellige miljøer (iscenesættelse, prod, osv.) for at implementere mere avancerede former for test;
- løbende test og implementering.
Udvikler værktøjer
Som branche er vi begyndt at skabe mere og mere kompleks og imponerende software. Men når det kommer til vores egne værktøjer, kunne situationen være meget bedre.
Samarbejde og fjernredigering (via ssh) vandt en vis popularitet, men blev aldrig den nye standard måde at udvikle på. Hvis du, ligesom jeg, afviser selve ideen om nødvendigt en permanent forbindelse til internettet bare for at kunne programmere, så vil arbejde via ssh på en ekstern maskine næppe passe dig.
Lokale udviklingsmiljøer, især for ingeniører, der arbejder med store serviceorienterede arkitekturer, er stadig en udfordring. Nogle projekter forsøger at løse dette, og jeg ville være interesseret i at vide, hvordan den mest ergonomiske UX ville se ud for en given use case.
Det ville også være interessant at udvide begrebet "bærbare miljøer" til andre udviklingsområder såsom fejlreproduktion (eller ), der forekommer under visse forhold eller indstillinger.
Jeg vil også gerne se mere innovation inden for områder som semantisk og kontekstafhængig kodesøgning, værktøjer til at korrelere produktionshændelser med specifikke dele af kodebasen osv.
Computing (fremtiden for PaaS)
Efter hypen omkring containere og serverløse i 2010'erne er udbuddet af løsninger i det offentlige cloud-rum udvidet markant i de sidste par år.
Dette rejser flere interessante spørgsmål. Først og fremmest vokser listen over tilgængelige muligheder i den offentlige sky konstant. Cloud-tjenesteudbydere har personalet og ressourcerne til nemt at følge med i den seneste udvikling i Open Source-verdenen og frigive produkter som "serverløse pods" (jeg formoder blot ved at gøre deres egne FaaS runtime OCI-kompatible) eller andre lignende smarte ting.
Man kan kun misunde dem, der bruger disse cloud-løsninger. I teorien leverer Kubernetes cloud-tilbud (GKE, EKS, EKS på Fargate osv.) cloududbyder-uafhængige API'er til at køre arbejdsbelastninger. Hvis du bruger lignende produkter (ECS, Fargate, Google Cloud Run osv.), får du sandsynligvis allerede mest ud af de mest interessante funktioner, som tilbydes af tjenesteudbyderen. Derudover, efterhånden som nye produkter eller computerparadigmer dukker op, vil migration sandsynligvis være enkel og stressfri.
I betragtning af hvor hurtigt rækken af sådanne løsninger udvikler sig (jeg vil blive meget overrasket, hvis et par nye muligheder ikke dukker op i den nærmeste fremtid), små "platform"-teams (teams tilknyttet infrastruktur og ansvarlige for at skabe on-premise platforme for at køre arbejdsbyrder virksomheder) vil være utroligt vanskelige at konkurrere med hensyn til funktionalitet, brugervenlighed og generel pålidelighed. 2010'erne har set Kubernetes som et værktøj til at bygge PaaS (platform-as-a-service), så det forekommer mig fuldstændig meningsløst at bygge en intern platform oven på Kubernetes, der tilbyder det samme valg, enkelhed og frihed tilgængelig i offentligheden skyrum. At indramme containerbaseret PaaS som en "Kubernetes-strategi" er ensbetydende med bevidst at undgå skyens mest innovative muligheder.
Hvis man ser på de tilgængelige i dag computeregenskaber, bliver det indlysende, at oprettelse af din egen PaaS udelukkende baseret på Kubernetes er ensbetydende med at male dig selv ind i et hjørne (ikke en meget fremadskuende tilgang, hva?). Selv hvis nogen beslutter sig for at bygge en containeriseret PaaS på Kubernetes i dag, vil den om et par år se forældet ud sammenlignet med cloud-funktioner. Selvom Kubernetes startede som et open source-projekt, er dets forfader og inspiration et internt Google-værktøj. Det blev dog oprindeligt udviklet i begyndelsen/midten af 2000'erne, da computerlandskabet var helt anderledes.
Også i en meget bred forstand behøver virksomheder ikke at blive eksperter i at drive en Kubernetes-klynge, og de bygger og vedligeholder heller ikke deres egne datacentre. At levere et pålideligt computergrundlag er en kerneudfordring udbydere af cloud-tjenester.
Endelig føler jeg, at vi er gået lidt tilbage som branche mht interaktionsoplevelse (). Heroku blev lanceret i 2007 og er stadig en af de mest let at bruge platforme. Der kan ikke benægtes, at Kubernetes er meget mere kraftfuld, udvidelsesbar og programmerbar, men jeg savner, hvor nemt det er at komme i gang og implementere til Heroku. For at bruge denne platform behøver du kun at kende Git.
Alt dette fører mig til følgende konklusion: vi har brug for bedre abstraktioner på højere niveau for at fungere (dette gælder især for abstraktioner på højeste niveau).
Den rigtige API på højeste niveau
Docker er et godt eksempel på behovet for bedre adskillelse af bekymringer på samme tid korrekt implementering af API på højeste niveau.
Problemet med Docker er, at projektet (i det mindste) oprindeligt havde for brede mål: alt sammen for at løse kompatibilitetsproblemet ("virker på min maskine") ved hjælp af containerteknologi. Docker var et billedformat, en runtime med sit eget virtuelle netværk, et CLI-værktøj, en dæmon, der kørte som root og meget mere. Under alle omstændigheder var udvekslingen af beskeder mere forvirrende, for ikke at nævne "lette VM'er", cgroups, navnerum, adskillige sikkerhedsproblemer og funktioner blandet med marketingopfordringen om at "bygge, levere, køre enhver applikation hvor som helst".
Som med alle gode abstraktioner tager det tid (og erfaring og smerte) at nedbryde forskellige problemer i logiske lag, der kan kombineres med hinanden. Desværre, før Docker kunne nå lignende modenhed, gik Kubernetes ind i kampen. Det monopoliserede hype-cyklussen så meget, at alle nu forsøgte at følge med ændringer i Kubernetes-økosystemet, og containerøkosystemet fik en sekundær status.
Kubernetes deler mange af de samme problemer som Docker. For al snakken om cool og sammensat abstraktion, opdele forskellige opgaver i lag ikke særlig godt indkapslet. I sin kerne er det en containerorkestrator, der kører containere på en klynge af forskellige maskiner. Dette er en opgave på ret lavt niveau, der kun gælder for ingeniører, der betjener klyngen. På den anden side er Kubernetes også abstraktion på højeste niveau, et CLI-værktøj, som brugere interagerer med via YAML.
Docker var (og er stadig) fedt nok udviklingsværktøj på trods af alle dets mangler. I et forsøg på at holde trit med alle "harer" på én gang, lykkedes det dets udviklere at implementere korrekt abstraktion på højeste niveau. Med abstraktion på højeste niveau mener jeg delmængde funktionalitet, som målgruppen (i dette tilfælde udviklere, der brugte det meste af deres tid i deres lokale udviklingsmiljøer) virkelig var interesseret i, og som fungerede godt ud af boksen.
Dockerfile og CLI-værktøj docker skal være et eksempel på, hvordan man opbygger en god "brugeroplevelse på højeste niveau". En almindelig udvikler kan begynde at arbejde med Docker uden at vide noget om forviklingerne implementeringer, der bidrager til driftserfaringsåsom navnerum, cgroups, hukommelse og CPU-grænser osv. I sidste ende er det ikke meget anderledes at skrive en Dockerfile fra at skrive et shell-script.
Kubernetes er beregnet til forskellige målgrupper:
- klyngeadministratorer;
- softwareingeniører, der arbejder med infrastrukturproblemer, udvider Kubernetes' muligheder og skaber platforme baseret på det;
- slutbrugere, der interagerer med Kubernetes via
kubectl.
Kubernetes' "one API fits all"-tilgang præsenterer et utilstrækkeligt indkapslet "bjerg af kompleksitet" uden nogen vejledning i, hvordan det skaleres. Alt dette fører til en uberettiget langvarig læringsbane. Hvordan Adam Jacob, “Docker bragte en transformativ brugeroplevelse, som aldrig er blevet overgået. Spørg alle, der bruger en K8s, om de ønsker, at den fungerede som deres første docker run. Svaret vil være ja":
Jeg vil påstå, at det meste af infrastrukturteknologien i dag er for lavt niveau (og derfor betragtes som "for kompleks"). Kubernetes er implementeret på et ret lavt niveau. Distribueret sporing i sin (mange spænd, der er syet sammen for at danne en traceview) er også implementeret på et for lavt niveau. Udviklerværktøjer, der implementerer "abstraktioner på højeste niveau", har tendens til at være de mest succesrige. Denne konklusion gælder i et overraskende antal tilfælde (hvis teknologien er for kompleks eller svær at bruge, så er "API/UI på højeste niveau" for den teknologi endnu ikke blevet opdaget).
Lige nu er det cloud-native økosystem forvirrende på grund af dets lave fokus. Som industri skal vi innovere, eksperimentere og uddanne os om, hvordan det rigtige niveau af "maksimal, højeste abstraktion" ser ud.
Detailhandel
I 2010'erne forblev den digitale detailoplevelse stort set uændret. På den ene side burde letheden ved at handle på nettet have ramt de traditionelle detailbutikker, på den anden side har nethandel grundlæggende været næsten uændret i et årti.
Selvom jeg ikke har nogen specifikke tanker om, hvordan denne industri vil udvikle sig i løbet af det næste årti, ville jeg være meget skuffet, hvis vi handler i 2030 på samme måde, som vi gør i 2020.
Journalistik
Jeg bliver mere og mere desillusioneret over den globale journalistiks tilstand. Det bliver stadig sværere at finde upartiske nyhedskilder, der rapporterer objektivt og minutiøst. Meget ofte er grænsen mellem selve nyheden og meninger om den sløret. Som regel præsenteres information på en forudindtaget måde. Dette gælder især i nogle lande, hvor der historisk ikke har været nogen adskillelse mellem nyheder og meninger. I en nylig artikel offentliggjort efter det sidste britiske parlamentsvalg, Alan Rusbridger, tidligere redaktør af The Guardian, :
Hovedpointen er, at jeg i mange år kiggede på amerikanske aviser og havde ondt af mine kolleger der, som var eneansvarlige for nyhederne, og overlod kommentarerne til helt andre mennesker. Men med tiden blev medlidenhed til misundelse. Jeg mener nu, at alle britiske nationale aviser bør adskille deres ansvar for nyheder fra deres ansvar for kommentarer. Desværre er det for svært for den gennemsnitlige læser – især online-læsere – at se forskellen.
I betragtning af Silicon Valleys ret tvivlsomme ry, når det kommer til etik, ville jeg aldrig stole på, at teknologien ville "revolutionere" journalistikken. Når det er sagt, ville jeg (og mange af mine venner) blive glad, hvis der var en upartisk, uinteresseret og troværdig nyhedskilde. Selvom jeg ikke aner, hvordan sådan en platform kan se ud, er jeg overbevist om, at i en æra, hvor sandheden bliver stadig sværere at gennemskue, er behovet for ærlig journalistik større end nogensinde.
Sociale netværk
Sociale medier og samfundsnyhedsplatforme er den primære kilde til information for mange mennesker rundt om i verden, og nogle platformes manglende nøjagtighed og modvilje mod at foretage selv grundlæggende faktatjek har ført til katastrofale konsekvenser såsom folkedrab, valgindblanding og mere .
Sociale medier er også det mest kraftfulde medieværktøj, der nogensinde har eksisteret. De ændrede radikalt politisk praksis. De ændrede reklamen. De ændrede popkulturen (for eksempel hovedbidraget til udviklingen af den såkaldte annulleringskultur [udstødelseskulturer - ca. oversættelse] sociale netværk bidrager). Kritikere hævder, at sociale medier har vist sig at være grobund for hurtige og lunefulde ændringer i moralske værdier, men det har også givet medlemmer af marginaliserede grupper mulighed for at organisere sig på måder, de aldrig har haft før. I det væsentlige har sociale medier ændret den måde, folk kommunikerer og udtrykker sig på i det 21. århundrede.
Jeg mener dog også, at de sociale medier bringer de værste menneskelige impulser frem. Hensyn og betænksomhed negligeres ofte til fordel for popularitet, og det bliver næsten umuligt at udtrykke begrundet uenighed med bestemte meninger og holdninger. Polarisering kommer ofte ud af kontrol, hvilket resulterer i, at offentligheden simpelthen ikke hører individuelle meninger, mens absolutister kontrollerer spørgsmål om online etikette og accept.
Jeg spekulerer på, om det er muligt at skabe en "bedre" platform, der fremmer diskussioner af bedre kvalitet? Det er trods alt det, der driver "engagement", der ofte bringer hovedfortjenesten til disse platforme. Hvordan Kara Swisher i New York Times:
Det er muligt at udvikle digitale interaktioner uden at fremprovokere had og intolerance. Grunden til, at de fleste sociale mediesider virker så giftige, er fordi de blev bygget til hastighed, viralitet og opmærksomhed snarere end indhold og nøjagtighed.
Det ville være virkelig uheldigt, hvis den eneste arv fra sociale medier om et par årtier var udhulingen af nuancer og passende i den offentlige diskurs.
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com