Giter Site home page Giter Site logo

ul-fmf / projekt-tomo Goto Github PK

View Code? Open in Web Editor NEW
14.0 12.0 23.0 6.36 MB

Spletna storitev za poučevanje programiranja

Home Page: https://www.projekt-tomo.si

License: GNU Affero General Public License v3.0

Python 41.66% JavaScript 7.22% HTML 35.32% CSS 2.66% MATLAB 7.49% R 4.62% Dockerfile 0.14% TeX 0.88% Shell 0.02%

projekt-tomo's Introduction

Projekt Tomo

Projekt Tomo je spletna storitev za učenje programiranja. Deluje tako, da učenec na svoj računalnik prenese datoteke z nalogami in jih začne dopolnjevati s svojimi rešitvami, strežnik pa te rešitve brez kakršnega koli dodatnega dela sproti shranjuje, preverja ter učencu nudi takojšen samodejen odziv o njihovi pravilnosti, učitelju pa pregled nad znanjem učencev.

Spletna storitev je napisana v Djangu, ki je razvojno ogrodje za spletne storitve v Pythonu. Če želite prispevati k razvoju Projekta Tomo, si najprej poglejte kaj malega o Djangu in Pythonu, nato pa si po spodnjih navodilih storitev namestite na računalnik. Za navodila glede dodajanja funkcionalnosti in popravljanja napak glejte CONTRIBUTING.md.

Navodila za namestitev

Na začetku klonirajte repozitorij ter ustvarite virtualno okolje:

git clone [email protected]:ul-fmf/projekt-tomo.git
cd projekt-tomo
python3 -m venv venv

Dobiti bi morali sledečo strukturo datotek:

projekt-tomo/
    web/
        attempts/
        courses/
        ...
    manage.py
    ...
    venv/
        ...

Po prvi namestitvi, pa tudi na vsake toliko časa, greste v imenik projekt-tomo/web/ ter s sledečimi ukazi kodo posodobite, aktivirate virtualno okolje, namestite potrebne pakete in posodobite bazo:

git pull
source ../venv/bin/activate
pip install -r requirements/local.txt
python manage.py migrate

Če uporabljate Windowse, je drugi ukaz drugačen

git pull
..\venv\Scripts\activate
pip install -r requirements\local.txt
python manage.py migrate

Strežnik nato poženete z

python manage.py runserver

Teste poženete z

python manage.py test

Ker ima spletna storitev zaradi podpore ArnesAAI specifičen način prijave, morate pred prvo uporabo z ukazom

python manage.py createsuperuser

ustvariti administratorskega uporabnika. Ob prvi in vseh ostalih prijavah pa se morate prijaviti prek administratorskega vmesnika, saj je po taki prijavi mogoče dostopati tudi na običajno stran. V administratorskem vmesniku lahko prav tako ustvarjate dodatne uporabnike in predmete.

Če želite, lahko uporabite tudi bazo z bolj realnimi (anonimiziranimi) podatki. Prenesite datoteko db.sqlite3, ki jo shranite na projekt-tomo/web/web/db.sqlite3. Administratorski uporabnik z uporabniškim imenom admin in geslom admin je že vključen.

Namestitev v Dev Container

Kdor ima nameščen Docker in urejevalnik VS Code, lahko za razvoj uporabi tudi Dev Container. Pred zagonom morate datoteko example.env prekopirati v novo datoteko .env in po potrebi popraviti nastavitve. Nato poženete ukaz Dev Containers: Open in Container (lahko tudi Build and Open ali Rebuild and Reopen). Navodila za zagon so taka kot zgoraj, le da lahko izpustite vse ukaze za delo z virtualnim okoljem venv.

projekt-tomo's People

Contributors

andrejbauer avatar ash-ray avatar bubblebeam11 avatar dimes123 avatar dolencm avatar gregorjerse avatar jaanos avatar jakavel avatar jo-osko avatar jureslak avatar k3ap avatar kraljsamo avatar kriznar4 avatar matijapretnar avatar mrcinv avatar petkomat avatar pg008 avatar schrjako avatar sonjajerse avatar strelec avatar yoyof430 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

projekt-tomo's Issues

Check.input & Check.output

Dodal bom še funkciji za preverjanje programov, ki niso funkcije, temveč komunicirajo preko input & print. Predlagam Check.input(vhod), ki dane teste izvede ob tem, da na standardni vhod pošlje nize v seznamu vhod, ter Check.output(ukaz, izhod), ki izvede dane ukaze (ponavadi bo to kar Check.current_part['solution']) in pogleda, ali izpisani nizi ustrezajo seznamu izhod. Pri tem je Check.input context manager, tako kot Check.in_file, da lahko Tomo sporoči:

Pri vnešenih nizih ... je prišlo do naslednjih napak...

Uporablja se pa kot:

with Check.input(['Matija', 'Pretnar']):
    Check.output(Check.current_part['solution'], ['Živjo, Matija Pretnar!', 'Kako si?'])

Dve vprašanji:

  1. ali bomo Check.output uporabljali še na čem drugem kot na trenutni rešitvi? Sprašujem zato, ker je Check.current_part['solution'] en velik niz, pri Check.run pa podamo seznam nizov, ki se združijo v en velik niz. Mogoče lahko naredimo tako, da pri obeh preverimo, ali je seznam ali niz, in v prvem primeru združimo vse v en niz, v drugem pa ne?

  2. ali pri Check.output razliko med dejanskim in pričakovanim izpisom prikažemo z dvema seznamoma ali z diffom, tako kot pri Check.out_file?

Kaj menite, @sonjajerse @gregorjerse in @lokarM?

Stran za prijavo

Ko prideš na osnovno stran, se ti prikaže obrazec za prijavo, če nisi prijavljen, in seznam nalog, če si. Če se prijaviš napačno, greš nazaj na obrazec za prijavo z opozorilom.

Značke (tags)

Na kaj vse bomo dali značke, kot npr. "slovarji", "dinamično programiranje", "zaporedja"... Na Problem zagotovo. Na Part verjetno nima smisla. Kaj pa ProblemSet? Ali ima ProblemSet kar unijo značk vseh svojih problemov? Ali se lahko zgodi, da ima še kakšno, ki jo njegovi problemi nimajo?

iOS mobilna aplikacija

Za testiranje iOS mobilne aplikacije potrebujemo Xcode (https://itunes.apple.com/us/app/xcode/id497799835?mt=12) in čim več iNaprav, ker virtualno oklje za testiranje aplikacij ne podpira vseh funkcionalnosti (če to sploh potrebujemo, ker imamo precej osnovno aplikacijo).

Potrebujemo tudi ključ za podpis aplikacije, ki ga dobimo preko Keychain Access apliakcije (navodila na http://docs.build.phonegap.com/en_US/signing_signing-ios.md.html)

Za to je potreben status iOS Developer ( https://developer.apple.com/programs/ios/ ).

Vir in dodatne informacije: http://docs.phonegap.com/en/edge/guide_platforms_ios_index.md.html#iOS%20Platform%20Guide

Pošiljanje URL-ja v metodo za skripte

Metoda, ki sestavi vsebino skripte za oddajanje in urejanje nalog, smiselno spada v models.py, vendar tam nima dostopa do HTTP zahteve, zato ne more dodati polnega URL-ja za strežnik. Trenutno dobi dodaten argument url, ki ga izpolnemo v views.py. Po mojem je najbolje, da se ta URL zapiše kar v settings. @gregorjerse & @sonjajerse mnenje?

Datoteke

Pri določenih nalogah bi potrebovali datoteke, npr. za vzorčno kodo, tekstovne datoteke za analizo ali slike. Ali bi jih pripeli na Problem ali na ProblemSet? Mogoče so bolj vezane na prvega, ampak jih lažje zapakiramo v zip od drugega.

Logo za mobilno aplikacijo

Prilagam dva primera logotipa za mobilno aplikacijo.

Zgledovala sem se po izgledu napisa Tomo v navigacijski vrstici v starem in novem Tomotu.

Meni je lepši črno-beli napis, ker bolj izstopa. Če izberemo tega, predlagam, da ustrezno obarvamo tudi navigacijo v novem Tomotu, da bo izgled "logotov" enak za mobilno in spletno aplikacijo.

logo_sivi

logo_crni

Spisek manjkajoče funkcionalnosti

Tule bi napisal stvari, ki jih stari Tomo ima, novi pa še ne, vendar smo še preveč leni, da bi odprli issue, ali pa moramo razmisliti, ali jih sploh hočemo. Ko bomo vse našteli in za vse odprli issue, lahko tole zapremo.

Za začetek:

  • statistika
  • naprednejši testi v Pythonu
  • podpora za R in infrastruktura za ostale programske jezike
  • prijava na predmete
  • datoteka z zgodovino
  • datoteke za preverjanje na MOSSu
  • datoteke za masovno ocenjevanje (ni besedil nalog, samo vse rešitve, v komentarjih pa javljene napake)
  • kopiranje nalog
  • urejanje in dodajanje nalog preko lastnega uporabniškega vmesnika (ne django admina)
  • pop-up prikaz rešitev
  • anonimni problemi

Testi osnovne funkcionalnosti

Napisati bi bilo treba teste za vsaj vso funkcionalnost, do katere dostopajo študentje, da ne bomo česa ponesreči polomili. Se kdo javi?

Uvodna predstavitev

Ko bo dokumentacija napisana, bi bilo dobro, da bi za tiste, ki jim ne paše toliko brati, naredili par osnovnih filmčkov:

  1. kratka reklama (1-2 minuti) za to, kaj Tomo omogoča
  2. uvodni filmček za študente (5-10 minut), ki gre čez ves potek reševanja
  3. uvodni filmček za učitelje (10 minut), ki gre čez ves potek urejanja in pokaže, kje je dokumentacija.

Filmčke lahko naredim jaz, me pa zanima, kaj si @sonjajerse, @gregorjerse in @lokarM mislite o tem.

Pravice

V modelu Course imamo polje teachers, vendar se nikjer ne uporablja. Zaenkrat preverjamo, ali ima oseba status administratorja. To bo treba popraviti. @gregorjerse & @sonjajerse, to se verjetno preverja v viewu? S čim pa?

Navigacija

Ali lahko damo navigacijo na črno in jo fiksiramo, da bo vedno vidna? Razlogi so razloženi v #26.

Počasno oddajanje rešitev

Na vajah imam občutek, da je oddajanje nalog na strežnik počasnejše kot na starem Tomotu. Lahko da se tudi motim. Ali obstaja način, da bi izmerili, koliko časa trajajo posamezni deli pri oddaji? Nekaj takega kot Django debug toolbar, samo za REST.

Popularizacija

Kot gledam, so vse stvari, ki bi jih morali narediti, bodisi narejene bodisi imajo odprt issue na Githubu. Edina (razmeroma ključna 😃) stvar, ki manjka, je predstavitev storitve uporabnikom. Dobršen del smo (ste) naredili že na SIRIKTu, nekaj bo na ISSEPu in VIVIDu, bi bilo pa dobro pred tem imeti že nekaj uporabnikov, da se bomo tam lahko pohvalili.

Pred tem bo treba vzpostaviti javni strežnik (issue #33, kjer moramo dobiti domeno). @lokarM, mogoče ti najbolj veš, kako naprej? Verjetno bo treba napisati navodila, nato pa uporabiti veze in poznanstva ter poslati vabila potencialnim interesentom?

Vzpostavitev strežnika

Treba bo postaviti strežnik na ARNESovem oblaku. Prav tako bi bilo dobro, da trenutni Tomo za UVP ne bi tekel na dev strežniku, da ne bomo česa ponesreči povozili. Ali bi po vzpostavitvi ARNESovega strežnika UVP prestavili tja, trenutnega pa bi imeli za testiranje?

@gregorjerse?

Podpora za druge jezike

Trenutno so vse naloge narejene iz iste vzorčne datoteke: tiste za Python. Podobno bi seveda lahko naredili tudi za druge jezike, ampak bolj splošno, ne samo, da spreminjamo vzorčno datoteko, kot je bilo na starem Tomotu. Npr. pri C-ju je bolj smiselno za vsako nalogo prenesti zip z .c in .h datoteko, pa verjetno še kakšen makefile, ki se ga zažene. Podobno bi lahko bile Pythonove naloge bodisi zapletene (kot so zdaj, z dostopom do celotne knjižnice) ali enostavne (kjer bi učitelji le napisali, na katerih vrednostih se preveri delovanje funkcije).

Pravne formalnosti

Glede na to, da bo stvar javna, je verjetno treba urediti par pravnih traparij:

  • piškotki EU
  • zavedanje, da

Predlagam, da na vstopni strani nad gumbom za prijavo piše, da se s prijavo strinjamo s pogoji poslovanja, kjer je link na pogoje poslovanja (mogoče kar modalni pogled?), v katerem zgornje piše na najbolj direkten možen način.

@gregorjerse: imaš ti kaj več izkušenj s tem? Z @lokarM in @sonjajerse smo na sestanku ugotovili, da poleg tega, da pravne službe ne bodo preveč koristne, izkušenj nimamo. Jaz se bom pozanimal še pri Alenu in Barbari Paternoster.

Preprečevanje goljufij

Kako se bomo lotili preprečevanja goljufij, torej npr. dnevniki dostopov, beleženje IPjev, primerjava rešitev, …
Po eni strani bi na FMFju to koristili, ampak v splošnem pa nekako ni v duhu storitve. Ali vseeno napišemo stvari, pa naj jih uporablja, kdor jih hoče?

Dokumentacija

Živjo!

Kaj praviš na to, da bi kodo malo bolje podokumentirali? Jaz predlagam, da bi uporabili Sphynx. Je pa res, da je s tem kar nekaj dela.

Nalaganje testnih podatkov

Od kod bi nalagali testne podatke v bazo? Imamo sledeče možnosti

  1. fixture – če prav razumem, je to zastarelo in ga nadomesti:
  2. data migration – ta mi ni všeč, ker ne vem, kako bi dosegli, da bi se migracija pognala le lokalno, na strežniku pa ne
  3. JSON dump – ker že imamo REST API, bi lahko podatke naložili tudi z enim POST requestom. Ker bi bilo to dobro tudi za razne masovne uvoze in izvoze, bi to zagotovo lahko uporabljali za podatke o nalogah. Ne vem pa, ali bi isto uporabljali tudi za podatke o rešitvah.
  4. SQL dump – ta je še najbolj na ziher. Tu je prednost tudi ta, da lahko enostavno vzamemo žive podatke s strežnika. Ko sem delal na starem Tomotu so potem stvari s pravimi podatki vedno pokazale še na kakšen hrošč, ki ga zaradi premajhnosti testnih podatkov nisem videl.

Skratka, predlagam 3 v kombinaciji s 4. Ostali?

Učiteljev uporabniški vmesnik

Pripravil sem kodo za premikanje nalog v sklopu in sklopov v predmetu. Podobno bom naredil tudi skrivanje nalog in rešitev. @sonjajerse, a lahko narediš smiselne gumbke v HTML-ju? Po mojem je najbolje, da se v ustrezni view doda bool show_teacher_controls ali kaj takega, pa potem odvisno od tega pokažeš varianto.

POST za urejanje problemov

Potrebovali bi tudi nekaj, na kar učitelj pošlje podatke za urejanje problema. V stari verziji se pošlje:

  • id problema (že obstoječ - nove probleme narediš preko spletnega vmesnika)
  • naslov problema
  • opis problema
  • preambula (tega zdaj ni več)
  • za vsak del problema pa še:
    • id, če že obstaja. Če ne, se za id nastavi 0 in se tak del naredi na novo
    • opis dela
    • rešitev dela
    • testi dela
    • uraden secret

Prek tega vmesnika lahko dodajaš nove dele, brisati jih pa ne moreš. Nekaj v tem stilu bi rabili tudi sedaj, da bodo učitelji lahko dodajali naloge.

Logotipa MIŠZ in ESS

Povsod je treba označiti financerja projekta, torej ministrstvo in evropske strukturne sklade. Logotipa (prilagam zraven) bi bilo najbolje dodati kar v footer v base.html.

ess
mizs

POST za obstoječi Attempt

Glede na to, da Python skripta, ki bo pošiljala JSON z rešitvijo na strežnik, ne bo vedela, ali je uporabnik že oddal rešitev, bi bilo dobro create v AttemptSerializer (ali kaj drugega, ne vem) spremeniti tako, da bo naredil update v primeru, da za danega uporabnika oddaja že obstaja.

JSON odziv v AttemptViewSet.submit

Strežnik bi Python skripti vrnil seznam popravljenih Attemptov (predvsem popravil valid in še kaj dodal v feedback). Če vrnem samo seznam Attemptov, stvar ne dela, ker jih ne spravi v JSON, zato na roke naredim slovarje, ki gredo skozi. Verjetno se to da narediti avtomatično?

Financer

Je res potrebno tisto famozno besedilo na prav vseh straneh. Ali ne bi bilo le na osnovni strani (+ manjše - in slike in fonti)

Prijava na predmete

Treba je ustvariti vmesnik, v katerem se ureja prijavo v predmete, torej:

  • učenci se lahko prijavijo v predmete
  • učitelji pri svojih predmetih vidijo (in urejajo) učence in učitelje

AttemptSerializer za feedback

Polje feedback v modelu Attempt je seznam nizov. Ali se da AttemptSerializer popraviti tako, da bo sprejel seznam nizov v JSONu in ne niza, ki predstavlja seznam nizov v JSONU?

Poslati torej hočem {"feedback": ["bla", "bla", "bla"], ...} in ne {"feedback": "[\"bla\", \"bla\", \"bla\"]", ...}.

LDAP avtentikacija

To bi moralo že delati, samo mi študentski račun ne dela, zato ne morem poskusiti.

Osnovna dokumentacija

Pripraviti je treba neko osnovno dokumentacijo za uporabnike in učitelje. Materiala imamo dovolj, zdaj pa je vse skupaj treba spraviti v en Markdown, da ga lahko objavimo na strani.

Primerjava z uradno rešitvijo

Tabelica, v katerem lahko vsak del rešitve primerjaš z uradno rešitvijo. Za prve vaje bo dovolj, da se primerjava pokaže, če je tvoja rešitev pravilna.

Uvoz/izvoz nalog

V razpisu smo obljubili:

Poleg tega bomo omogočili izvoz nalog v standardnem tekstovnem odprtem formatu (npr. JSON ali XML), preko katerega bodo učitelji naloge lahko uvozili nazaj v sistem, ali po potrebi predelal z drugimi programi, ki standardni format podpirajo. Pri uvozu bo uporabnik nalogo lahko drugače uvrstil v zbirko nalog in kasneje tudi popravil. Ena izmed možnosti, ki jo tak pristop omogoča, je tudi avtomatično generiranje večje skupine sorodnih nalog.

Torej, treba je dodati gumbe izvozi, ki nalogo/sklop/predmet izvozi v JSON, ter gumbe uvozi, ki naredi obratno.

Jezik

Načeloma mešamo jezike. Tako imamo na istih straneh

"Prenesi datoteke" in "Show progress"
"Copy" in "Izbriši"

Vidnost nalog in rešitev

V modelu ProblemSet sicer imamo polji visible in solution_visibility, vendar se nikjer ne poznata.

Kloni nalog

Po manjšem razmisleku glede klonov (torej nalog, ki se z isto vsebino pojavljajo na več koncih), se mi zdi najboljša rešitev sledeča.

  • Ko narediš kopijo, se naredi v celoti nova naloga, vendar se v obe v polje clones zapiše, da imata identično vsebino.
  • Ko se naloga popravi, se vsem učiteljem klonov nekje pokaže, da je bil eden od klonov spremenjen, in se vpraša, ali bi posodobili tudi svoje naloge. Če ja, se vsebina popravi, če ne, se prekine povezavo.

Na tak način se izognemo temu, da bi kdo po nesreči popravljal našo nalogo, saj lahko vsak posodablja le tiste naloge, za katere ima tako ali tako pravico urejanja. Če imaš pravico urejanja pri več predmetih, lahko hkrati popraviš pri vseh. Če pa je kakšen klon v "lasti" drugega učitelja, pa je to njegova odločitev.

Kako se vam zdi?

Napredna dokumentacija

Poleg osnovne dokumentacije bo treba narediti neko zbirko naprednejših testov (kot smo se pogovarjali na sestanku). @lokarM, ali lahko ti pripraviš Markdown z osnovnimi primeri?

Pregled napredka učencev

Zaenkrat lahko iz starega Tomota skopiramo tisto razpredelnico s pregledom pravilnosti, ampak bi bilo dobro stvar še enkrat premisliti, kaj vse bi radi videli.

Izboljšave Python skripte

Bom uporabil ta issue za zbiranje vseh raznih idej, ki se tičejo Python skripte in morebiti nimajo svojega issueja.

  • test za neskončno zanko (#164)
  • Check.difflines (#256)
  • ast (kot omenjeno spodaj)
  • Check.secret z nizom (z f-nizi je lažje napisati for i in ...: Check.secret(f'moja_funkcija("{i}"))
  • Uporaba f-nizov v kodi
  • Popravi template, da bodo delovali z black
  • premisli, ali se da lokalna okolja nastaviti prek context managerjev (kot omenjeno v diskusiji #287)
  • poskrbi, da bodo testi brez težav videli spremenljivke, definirane nad njimi (v učiteljevi kodi so globalne, v učenčevi lokalne)

Kakšne ideje, kako bi Python skripto naredili še boljšo za študente in učitelje?
Zaenkrat sem za učitelje že naredil to, da je velika večina strašne kode na dnu datoteke, imamo pa še:

  • če se program zacikla pri rekurziji, dobimo strašno dolg trackback z vsemi 500 rekurzivnimi klici. Tega bi lahko malo skrajšali. Zdi se mi, da to tudi zaseda precejšen del baze - bi moral preveriti.
  • med testi bi lahko skrili stdout zaradi tega, ker nekateri za debugging uporabljajo print, pa se potem ti printi izpisujejo tudi takrat, ko funkcijo kličejo naši testi.

Gumb za prenos vseh datotek za urejanje

Tako kot učitelji lahko izberejo, ali naj prenesejo datoteko za reševanje ali izbiranje, bi bilo treba narediti tudi na gumbu za prenos arhiva z vsemi datotekami.

Organizacija nalog

Ugotoviti bo treba, kako bi organizirali naloge. Nekaj idej:

  • Po mojem bi bilo dobro, da bi naloge lahko ustvarjal vsak, saj se nam s tem zna zgoditi, da stvar precej bolj zaživi. Kot je že Gregor rekel, bi bilo dobro (in tudi enostavno), da bi ljudje o nalogah lahko glasovali o kvaliteti in zahtevnosti. S tem bi lahko verjetno tudi ob morebitni poplavi nalog poskrbeli, da bodo dobre vidne.
  • Glede deljenja nalog bi lahko naredili tako: vsaka naloga ima tudi neobvezen ForeignKey za starša in vsakič, ko nalogo od nekod prekopiraš, se ta starš nastavi. Nato vsakič, ko se starša popravi, dobiš obvestilo: "Starš je popravljen, ali želiš posodobiti svojo nalogo?" Potem pa lahko rečeš, "ja" (in se izvede nek merge?), "ne", ali pa "nehaj mi težiti" in naloga postane samostojna. S tem bi dosegli to, da ljudje ne urejajo nalog drugih, hkrati pa ne bi divergirale.
  • Nalogam bi bilo treba dati značke. Ko gledam naloge pri Uvodu v programiranje, vidim, da je nastala cela štala, ker je cel kup nalog s kvizov, kolokvijev, poskusnih izpitov, vse seveda v 4 skupinah, ampak za nobeno nalogo ne veš, ali je z datotekami, nizi…
  • S temi značkami bi lahko načeloma naredili tudi predmete. Da bi res lahko delali predmete, bi bilo dobro narediti še to, da so nekatere značke rezervirane in jih ne more dodati kar vsak, temveč samo posvečeni. Prav tako bi bilo dobro, da ti posvečeni lahko urejajo tudi tuje naloge. Mogoče bi vseeno naredili tako kot zdaj?

@sonjajerse in @gregorjerse, kaj mislita?

Urejanje nalog na domači strani

Tam, kjer je seznam sklopov na domači strani, manjkajo gumbi za urejanje. Ker se tako tu kot pri pregledu predmeta uporablja isti vzorec, sklepam, da ni nastavljena spremenljivka show_teacher_forms.

Izgled sklopov

Za sklope predmeta sem sedaj dodal nek izgled v vejo assembly_progress . Prosim preglejte in podajte komentarje.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.