Gå til innhold

Nytt hobbyprosjekt, hva bør jeg tenke på?


Anbefalte innlegg

Jeg leker med tanken på å starte med et langsiktig hobbyprosjekt. Mest for moro skyld, men også for å hjelpe meg i studiene (anvendt datateknologi). Det jeg vil få til er å lage et nettsamfunn for hesteinteresserte (jeg er veldig hesteinteressert selv og utnytter derfor det som motivator) basert på SQL-databaser. Jeg har mye øving i html og css, og har database og php/webprogrammering som fag to av tre fag på studiet i skrivende stund. Har ikke erfaring i dette fra før, med unntak av grunnleggende php-kurs i forrige semester.

 

Hva bør jeg tenke på? Hva er viktig å få med fra starten av? Mitt første mål er å bygge "skjelettet" på nettsiden, få en ok struktur på det, samt få implementert sql slik at det blir mulig å lage profil, logge inn, endre opplysninger etc. Jeg vil også at nettsiden skal følge retningslinjene for WCAG nivå AA fra starten av, finnes det en side med en kortfattet sjekkliste for dette noe sted?

 

Allerde fra første linje av det blanke php-dokumentet er jeg usikker. Hva slags DOCTYPE skal jeg bruke? Hva slags include-inndeling bør jeg ha? Vil ha kvalitet fra bunnen av (selv om det bare er fritidsprosjekt kan det jo alltids hende at det blir tatt skikkelig i bruk senere)

Lenke til kommentar
Videoannonse
Annonse

Lenge siden jeg har satt meg inn i doctype-reglene og er kansje ikke oppdatert nok til å svare korrekt på dette: Noen får vel bare rette på meg. Jeg må også beklage mye kode, og lite som er formulert med ord. Sikkert noen som vet å formulere seg med ord som dropper innom :)

 

Skal du kode HTML-delen perfekt, så er vel Doctype HTML-strict (4.x) korrekt. Her eksisterer ikke "deprecated" fuksjoner som <font> eller <center>.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

 

Enda bedre er det å bruke XML/XHTML strict:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Denne er tilsvarende HTML-strict, men krever perfekt XML-syntaks f.eks:

<body>
<h1>Bæææd
</body>

En slik feil (ingen avslutning: </h1>) blir ikke gjenkjent som HTML. Hvor i f.eks doctype HTML-loose, vil dette ofte fungere fint.

 

Doctype for den siste standarden: HTML5, denne er noe kortere :p

<!DOCTYPE html>

 


 

Jeg starter altid med å lage først en core.php-fil denne inneholder hurtigkall, sikkerhetsfunksjoner og annet som vil gjenta seg ofte: EG: BB-koder, "snarvei" til sql-kallinger etc... Fra første stund så er det viktig å tenke på sikkerhet når man skal kommunisere med 3. part, som (My)SQL.

 

Hva slags include-inndeling bør jeg ha?
.. Du inkluderer bare filer du skal/trenger å inkludere (include/require), det er heller ikke helt tilsvarende i php som i java, c/c++, python etc.. Det er ingen "built-in" includes. Alt ligger i din egen mappe, du inkluderer bare filer du har der, om de trengs. Du slipper altså inkludere tilsvarnde "include mysql", eller "include math" for å kunne benytte seg av funksjonen sqrt() eller pow(), eller for å kjøre sql-kall - Slik en gjøre i de fleste andre programmeringspråk.. Alt som trengs er allerede tilgjengelig.

 

Jeg inkluderer var.php (denne inneholder passord til sql-db, og connecter til db) i min core.php

 

Snipp fra en core.php (tilpasser denne altid litt etter sidens innhold):

 

Inkludering av var.php

// Kontakte var.php samt lage BASEDIR fuksjon
$folder_level = "";
while (!file_exists($folder_level."var.php")) { $folder_level .= "../"; }
require_once $folder_level."var.php";
define("BASEDIR", $folder_level);

require_once/require brukes tilsvarnde include_once/include.. De behandler bare feilmeldinger litt forskjellig.

 

//Enkel, liten generell sikkerhetsfuksjon

// Unngå mulige XSS angrep via $_GET.
foreach ($_GET as $check_url) {
if ((eregi("<[^>]*script*\"?[^>]*>", $check_url)) || (eregi("<[^>]*object*\"?[^>]*>", $check_url)) ||
	(eregi("<[^>]*iframe*\"?[^>]*>", $check_url)) || (eregi("<[^>]*applet*\"?[^>]*>", $check_url)) ||
	(eregi("<[^>]*meta*\"?[^>]*>", $check_url)) || (eregi("<[^>]*style*\"?[^>]*>", $check_url)) ||
	(eregi("<[^>]*form*\"?[^>]*>", $check_url)) || (eregi("\([^>]*\"?[^)]*\)", $check_url)) ||
	(eregi("\"", $check_url))) {
die ();
}
}
unset($check_url);

 

// Clean URL Function, prevents entities in server globals
function cleanurl($url) {
$bad_entities = array("&", "\"", "'", '\"', "\'", "<", ">", "(", ")", "*");
$safe_entities = array("&", "", "", "", "", "", "", "", "", "");
$url = str_replace($bad_entities, $safe_entities, $url);
return $url;
}

 

Forkorte lange fuksjoner for å forekle senere kode..:

//mysql_real_escape_string
function mres($data) {
return mysql_real_escape_string($data);
}

// Validere numerisk input - brukerprofil, nyhetsID etc..
function isNum($value) {
return (preg_match("/^[0-9]+$/", $value));
}

// Validere alphanumerisk input
function isAlphaNum($value) {
return (preg_match("/^[a-zA-Z0-9]+$/", $value));
}

 

Jeg forkoerter også databasekall da dette er noe som aktivt skjer når man lager en portal..:

// MySQL database fuksjoner
function dbquery($query) {
$result = @mysql_query($query);
if (!$result) {
	echo mysql_error();
	return false;
} else {
	return $result;
}
}

function dbcount($field,$table,$conditions="") {
$cond = ($conditions ? " WHERE ".$conditions : "");
$result = @mysql_query("SELECT Count".$field." FROM ".DB_PREFIX.$table.$cond);
if (!$result) {
	echo mysql_error();
	return false;
} else {
	$rows = mysql_result($result, 0);
	return $rows;
}
}

function dbarray($query) {
$result = @mysql_fetch_assoc($query);
if (!$result) {
	echo mysql_error();
	return false;
} else {
	return $result;
}
}

//etc...

 

 

Vanligvis ligger core.php-filene mine på 600-1000 linjer..

 

Hver frittstående fil /side som folk skal besøke innholder (etter mitt system) ett par includes i starten nå:

require_once "core.php"
require_once "header.php"

og i bunnen inkluderer jeg da:

require_once "footer.php"

Du kan også lage rammeverk slik at du bare inkluderer disse i en fil.. som da inkluderer hver side.. Bruk php-seksjonen for mer php-relaterte spørsmål.

 


 

WCAG: http://www.w3.org/WAI/intro/wcag.php

Der finner du nok litt om standarden..

Noe alà en "Sjekkeliste": http://www.w3.org/WAI/WCAG20/quickref/ - Men kortfattet er den absolutt ikke.

Endret av warpie
Lenke til kommentar

Vil ha kvalitet fra bunnen av (selv om det bare er fritidsprosjekt kan det jo alltids hende at det blir tatt skikkelig i bruk senere)

Bare et råd å ta med på veien:

 

Å lære seg programmering fungerer sånn at du må gjøre det igjen og igjen og igjen, og etterhvert finne ut hva som fungerer best i ulike situasjoner. Så når du skal starte et nytt prosjekt er det bedre å bare hoppe i det, og ha i bakhodet at du alltid kan endre det du gjør, og kanskje starte helt fra scratch igjen om du ender opp med noe som ikke er så lett å jobbe med.

 

Forsøk ulike strukturer, og vurder underveis hvor enkelt/vanskelig du føler det er hver gang du skal implementere noe ny funksjonalitet. Må du gjøre endringer mange ulike steder, eller kan du utvide løsningen din uten å rote med eksisterende kode? Er det lett å finne frem etterhvert som løsningen vokser? Etc.

 

Det kan hende det er litt for tidlig for deg å tenke på denne måten - i starten kan det være greit med klare og tydelige regler - men etterhvert må du begynne å eksperimentere. Husk at du ikke må ha alle svarene før du kan lage noe. Gjør det heller quick and dirty først, sånn at du får noe opp å kjøre. Da ser du hvordan det virker, og du kan refakturere koden til den blir fin og medgjørlig.

 

Lykke til med hobbyprosjektet!

  • Liker 1
Lenke til kommentar

Dette kan faktisk bli et knallbra prosjekt! Lidenskap for en hobby, databaseferdigheter og dedikasjon er en veldig fin kombinasjon.

 

Det du vil er å lage et nytt og moderne nettsystem for fremtiden, ikke en utdatert 1994-kompatibel hjemmeside. Med moderne, mener jeg både i look n'feel, bruken og teknologien bak. Derfor anbefaler jeg HTML5 og CSS3 all the way. Finnes mange fallback-teknikker for de huleboerne som fremdeles kjører steingamle nettlesere, så det er ikke noen grunn til å anvende gammel og utdatert teknologi istedetfor å kode for fremtiden, som også er mye gøyere. Kort sagt er fordelene med HTML5 at det er fremtidens Doctype, den er enklere enn XHTML1.x (lettere syntax + enklere å få validert) og den har masse nye kule features. Doctypen ser slik ut: <!DOCTYPE html>.

 

Litt idéer: du har en tabell for hesterase med rasenavn og kort info. På nettsiden kan man så bla seg gjennom eller søke etter bestemt hesterase. Når man har funnet ønsket hesterase, kan man klikke seg inn på hesterase-profilsiden og se litt info + starte enkle tråder hvor man kan snakke ut om den hestrasen.

 

Du har en brukertabell hvor folk kan registrere seg med navn, profilbilde og registrere hvilke(n) hesterase(r ) de eier. Når man så går inn på profilen til en bruker, får man bl.a. opp en link til mer info om rasen til den hesten brukeren har. Og omvendt, når man går inn på hesterase-profilsiden, får man opp en liste over alle registrerte brukere som har den rasen.

 

Du har en klubb/stall-tabell hvor du har oversikt over alle rideklubber eller staller i hele landet. Det som gjør din side bedre enn Norges Rytterforbunds nettside, er at din har oversikt over alle klubber, ikke kun de som er med i NRYF. Du kan evt. la registrerte brukere få registrere rideklubber selv. Minimum informasjon du trenger om hver klubb er navn, adresse og info. Senere kan du koble klubbene til GeoNames API og Google Maps API og dermed kan man automatisk få opp på kart hvor klubben ligger, eller hvilke klubber som finnes i ditt fylke ligger eller få en oversikt over nærmeste rideklubber. Også senere kan du importere/eksportere klubben via Google Places API. Også senere kan du importere Atom/RSS feeds fra klubbens eller forbundets nettside og facebookside inn til den aktuelle klubb-profilsiden. Og enda senere igjen, kan du lage en Android/iOS app.

 

Du tar også med alle grener, ikke kun de som finnes innenfor NRYF. Jeg har ikke oversikt over hestegrener selv, men vet det finnes mer enn de åtte grenene som er nevnt på NRYF. Dette blir også egen tabell og kobles feks. sammen med klubb.

 

Du har en hestetabell hvor alle registrerte brukere kan legge inn info og bilde om hesten(e) sin(e). Her blir hestens navn, bilde(r ), rase (kobles til hesterasetabellen) og eier (kobles til brukertabellen) registrert. Du kan evt. legge inn andre egenskaper også så man kan søke etter hest med bestemte egenskaper. Nå aner jeg ikke om hester blir ID-merket, men om de blir det, og det på en måte går an å importere dataen fra ID-brikken, har du også uante muligheter.

 

Anbefaler også at du bruker http://en.wikipedia.org/wiki/Progressive_enhancement -prinsippet. Dvs at du får alt til å fungere med kun bruk av HTML, CSS og PHP og ikke bruker noe javascript/jquery e.l. før det. Har du ok kontroll på PHP anbefaler jeg CodeIgniter, siden da får du praktisert "best practice" når det gjelder oppsett av filstruktur og andre viktige prinsipper (mvc, oop, dry, etc). Men ikke hvis du fremdeles vedkjenner deg som en n00b. Er ellers viktig å tenke på at du gjør brukeren interaktiv og ikke bare passiv. Han må engasjeres mest mulig. Se bare Facebook, Wikipedia og Diskusjon.no feks., mesteparten av innholdet der er brukerstyrt!

 

Si fra når du har gjort alt dette, så skal du få noen flere idéer! :)

Endret av MikkelRev
Lenke til kommentar

Tusen takk for masse flotte innspill og ideer!! Veldig nyttig og motiverende :)

 

Doctypen var ikke verre nei :lol: Er HTML5 og CSS3 vi har lært å forholde oss til, så baserer meg nok på det ja! :) Kan bli moro det her, men gjett om ting kommer til å ta tid...! :ph34r: Men skal huske å kontakte deg om et år Mikkel, kanskje jeg har klart å få til alt det der til da... Kanskje :D

Lenke til kommentar

 

//Enkel, liten generell sikkerhetsfuksjon

// Unngå mulige XSS angrep via $_GET.
foreach ($_GET as $check_url) {
if ((eregi("<[^>]*script*\"?[^>]*>", $check_url)) || (eregi("<[^>]*object*\"?[^>]*>", $check_url)) ||
	(eregi("<[^>]*iframe*\"?[^>]*>", $check_url)) || (eregi("<[^>]*applet*\"?[^>]*>", $check_url)) ||
	(eregi("<[^>]*meta*\"?[^>]*>", $check_url)) || (eregi("<[^>]*style*\"?[^>]*>", $check_url)) ||
	(eregi("<[^>]*form*\"?[^>]*>", $check_url)) || (eregi("\([^>]*\"?[^)]*\)", $check_url)) ||
	(eregi("\"", $check_url))) {
die ();
}
}
unset($check_url);

 

Hva om noen slenger inn en url som dette ?

<IMG SRC='http://localhost/test.jpg' onmouseover='javascript:alert('XSS')'>

Lenke til kommentar

Jeg har ikke tenkt over alt sammen, takker for tips.

 

Vi/noen skulle kansje opprettet en PHP-"sikkerhetstråd", med en samling over funksjoner som kan hjelpe til å holde sikkerhetsstandarden høy. Forhåpentligvis også fått den sticky, da det er et viktig tema for en hver webutvikler.

Endret av warpie
Lenke til kommentar

@MikkelRev: Jeg blir imponert hvis du klarer å holde pusten i ett år.

 

@christinahk: Har du tenkt noe på hvor mange aktive brukere og besøkende siden din kan komme til å ha? Dette er for såvidt et greit spørsmål å stille seg med tanke på valg av database og oppbygning av siden. Hvis du f.eks. har tenkt til å ha søkemulighet på siden din og du har masse informasjon du skal søke gjennom vil en SQL-database være veldig tregt, mens en søkemotor som Solr vil føre til en signifikant hastighetsøkning. Dette er selvfølgelig noe som det er mulig å se an når siden først er oppe.

Når det gjelder oppbygning av siden har jeg ikke mye å komme med, men jeg vil anbefale deg å holde kode og design adskilt så godt som mulig. Dette vil gjøre det mye enklere for deg å vedlikeholde siden senere. Det kan godt hende det finnes noen gode PHP-rammeverk for det.

 

 

Keep up the good work. Du vil sikkert bli nødt til å prøve ut en haug med tilnærminger før du blir fornøyd, men det er tross alt litt av læringsprosessen :) Blir spennende å se hvordan utviklinga går.

 

 

BTW; Artig å se ei jente interessere seg for programmering, det er alt for få jenter som gjør det.

 

 

Lenke til kommentar

Jeg ville ihvertfall laget så mye gjenbrukskode som mulig...

 

Lag innloggingen i egen fil

Lag registreringen i egen fil

Lag menyer i egen fil

etc.

 

Bruk include for å inkludere dem i hoveddokumentet.

 

Ombestemmer du deg og vil lage noe annet kan du bruke det om igjen med små forandringer.

Lenke til kommentar

Hvis prosjektet er først og fremst for å lære underliggende og grunnleggende strukturer for hvordan en nettside med databaser fungerer, så sier jeg kjør på. Bruk PHP og lag databaser, vær veldig nøye med SQL-en, vær konsekvent, skriv hjelpefunksjoner (eller klasser) i stedet for å implementere det samme to ganger, tenk nøye gjennom sikkerhet og les masse på internett underveis.

 

Hvis målet er mer for å enten (a) faktisk bygge et nettsamfunn for hesteinteresserte som skal fungere og vokse, eller (b) lære hvordan man i praksis bør bygge slike ting med mer moderne metoder, så har jeg følgende anbefaling:

 

Bruk et rammeverk. Det aller aller meste (!!!) av det du kommer til å skrive i et slikt prosjekt har noen skrevet før deg. Veldig mye blir å finne opp hjulet på nytt, bare at de som skrev det før deg antagligvis var flinkere enn deg og meg til det. Mange av disse funksjonene kan du få fra et godt rammeverk. Rammeverk kan også hjelpe deg å skrive mye bedre kode, for eksempel via MVC-arkitektur.

 

Personlig ville jeg ha kastet PHP på sjøen og hoppet over på Django (skrevet i Python).

 

Det gir deg en sikrere, antagligvis bedre og mer fleksibel nettside på langt kortere tid, med enklere debugging, langt høyere kodekvalitet og enkle muligheter for å bruke plugins. Lærekurven er muligens noe brattere, men etter min mening får du igjen for det i bøtter og spann.

 

:)

Lenke til kommentar

@MikkelRev: Jeg blir imponert hvis du klarer å holde pusten i ett år.

Jeg blir også imponert om hun har fått alt det på plass innen ett år.

 

Det kan godt hende det finnes noen gode PHP-rammeverk for det.
Ja det gjør det, som f.eks. CodeIgniter. Men jeg anbefaler ikke CI eller andre rammeverk før man har en grei grunnleggende kunnskap i PHP.

 

Det er kjempemye som er kjempeviktig, men er man nybegynner og skriver PHP, så er det ikke sååå nøye om ikke koden er perfekt fra første testeprosjekt. Å ha streng MVC-struktur og konvensjon, riktig bruk av OOP og DRY, tettet igjen hvert eneste sikkerhetshull, valgt riktig rammeverk for både klient og serversiden, SEO, PHPdoc, perfekt optimaliserte spørringer, osv osv er alt vel og bra, men ett sted må man begynne og en ting om gangen! :)

Lenke til kommentar

Takk igjen for gode innspill! Har ikke kommet ordentlig igang ennå, men forelesningene jeg føler jeg har behov for er rett rundt hjørnet tror jeg :) I mellomtiden, er det noen som har forslag til navn? :lol: Det er (nesten) det aller vanskeligste, og strengt talt ikke nødvendig ennå, men synes det er så irriterende å jobbe med noe "navnløst", så om dere har noen gode ideer - SHOOT.

Lenke til kommentar

Du måååå ikke ha et fastsatt navn før du starter, er greit å enten bruke et kodenavn for prosjektet, hvis du føler du trenger å holde hva prosjektet skal handle om litt hemmelig. Ellers er det greit å bare gi det et navn som beskriver litt av hva du skal lage.

Når jeg skulle finne på navn til mitt nåværende prosjekt så brukte jeg nesten en hel dag før jeg ga opp og smalt sammen noen ord som beskrev hva jeg skulle lage xD

 

Du kan alltids prøve å beskrive det som om det var en person... Et stort system som skal inneholde mange muligheter. Første som slår meg da er egentlig "Doris"... men hvem vil vel kalle prosjektet sitt Doris? xD

Lenke til kommentar

http://nodejs.org/ http://expressjs.com/http://www.mongodb.org/ http://jade-lang.com/

 

Jeg begynte med SQL og basic php og html, men beveger meg mot de ovenfornevnte (i form a lenker) teknologiene. Det er mye enklere å få ting til å henge sammen. Ellers finnes det massevis av rammeverk og CMSer som du kan bruke for å forenkle prosessen. Se på http://drupal.org/ - mitt for tiden favorittCMS.

 

Skal du kode det selv i php er det lang vei å gå, men du lærer mye. Pass på sikkerheten knyttet til sesjoner (du kommer til dette senere). Jeg utviklet et eget CMS i et fag på studiet, og det viste seg at det var veldig lett å hacke dette CMSet. Så ikke gå i den fellen. Ellers lykke til :)

Lenke til kommentar
  • 5 måneder senere...

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...