Ohjelmointiputkan uusi PHP-opassarja on tulossa pilkkuhiljaa valmiiksi.
Uutta opassarjaa pääsee lukemaan tästä:
https://www.ohjelmointiputka.net/oppaat/opas.
Toivoisin teiltä palautetta opassarjasta ennen sen lopullista julkaisua. Palautetta saa mielellään antaa sekä asiasisällöstä että kieliasusta.
Ainaki käytettävyyteen liittyen kunkin osion jälkeen olisi hyvä lopussa olla linkki seuraavaan. Itsellä ainaki ensi katsauksella jäi oikeella ylhäällä oleva menu huomaamatta.
<!DOCTYPE html>
<html>
<head>
<title>Ensimmäinen PHP-sivu</title>
</head>
<body>
<p>Vuorokaudessa on <?php echo 24 * 60 * 60; ?> sekuntia.</p>
<p>Tänään on <?php echo date("j.n.Y"); ?>.</p>
<?php
echo "<ul>";
for ($i = 1; $i <= 10; $i++) {
echo "<li>" . $i;
}
echo "</ul>";
?>
</body>
</html>Vaikka HTML5:kin taitaa sallia tällaisen tagisopan keittämisen, niin minusta voitaisiin pitäytyä käytännössä tuottaa "loogisesti validia" merkkausta. Se helpottaa rakenteen hahmottamista varsinkin, jos PHP:lle uusi ihminen ei HTML:stäkään ymmärrä paljoakaan. Viittaan siis li-tagien sulkematta jättämiseen.
Sitä paitsi on vain koherenttia käytöstä sulkea myös li-tagit, kun p-tagienkin kanssa niin tehdään.
Synomi kirjoitti:
Ainaki käytettävyyteen liittyen kunkin osion jälkeen olisi hyvä lopussa olla linkki seuraavaan.
Nyt kaikkien oppaiden lopussa on linkit seuraavaan ja edelliseen oppaaseen.
The Alchemist kirjoitti:
Vaikka HTML5:kin taitaa sallia tällaisen tagisopan keittämisen, niin minusta voitaisiin pitäytyä käytännössä tuottaa "loogisesti validia" merkkausta.
Minusta </li>-tageista ja muista vapaaehtoisista lopputageista olisi opassarjassa enemmän haittaa kuin hyötyä. Esimerkiksi listan kohdan merkitseminen ilman lopputagia on yleinen tapa, jonka ei pitäisi hämmentää ketään HTML:ää tuntevaa. Enemmänkin voisi hämmentää </li>-tagi, jota ei ole tottunut näkemään. Käytännön ongelmana lopputageissa olisi, että ne mutkistaisivat ja pidentäisivät koodeja.
Pidentävät ehkä esimerkkitulostetta, mikä voi olla ongelma, jos sitä ei siistitä ollenkaan. Eivät ne itse koodia pidennä yhtään. Sitä paitsi suurin osa ihmisistä on aina väärässä tai tietämättömiä; siksi näitä oppaitakin tehdään.
Saisiko opassarjan kirjoitus- tai julkaisupäivämäärän näkyville.
Nopealla vilkaisulla aloittelija saattaa jäädä kaipaamaan oppaasta mistä PHP:n versiosta asti oppaassa kaikki käsitellyt kohdat toimivat ja esimerkkiä, kuinka saada omalta palvelimelta PHP:n versio katsottua.
Sisältöpuolelta hienoa, että PHP-oppaassakin on nyt lyhyehkö selostus luokista ja MVC-mallista, mutta namespaceja jäin vielä kaipaamaan.
Othnos kirjoitti:
Nopealla vilkaisulla aloittelija saattaa jäädä kaipaamaan oppaasta mistä PHP:n versiosta asti oppaassa kaikki käsitellyt kohdat toimivat ja esimerkkiä, kuinka saada omalta palvelimelta PHP:n versio katsottua.
Joo. Pikainen opastus phpinfo() käyttöön ja sen tuottaman tulosteen tulkitsemiseen voisi olla paikallaan.
Putkassa oli ainakin jossain välissä koekäytössä sivu, jossa pystyi ajamaan tietyin rajoituksin omaa php-koodia. Olisiko tämä sivu mahdollista yhdistää jotenkin oppaaseen? Jokaisen osion jälkeen voisi olla vaikkapa harjoitustehtäviä aiheesta, joita voi tehdä kyseisen sivun kautta.
En kyllä katsonut opasta kuin hyvin pintapuolisesti ja nopeasti, mutta aika hyvältä tuo muuten vaikuttaa.
EDIT.
Keskusteluissa tuhanteen kertaan toistuva virheilmoitusten päällelaittaminen ja muut php-debuggauksen alkeet olisi hyvä tuoda myös jollain tapaa oppaassa esille. En uudellakaan pikasilmäyksellä löytänyt mitään siihen viittaavaa.
Lisäsin oppaaseen maininnan PHP:n versiosta 5 sekä PHP:n version tulostuksen ensimmäiseen esimerkkiin.
Nimiavaruudet ovat uusi ja kiistelty ominaisuus PHP:ssä, eikä niitä kannata minusta vielä esitellä oppaassa.
Luontevin väline PHP:n harjoitteluun on PHP-haaste, johon oppaassa on linkki. Kieltämättä oppaan ja harjoittelun voisi yhdistää vielä paremmin.
Virheilmoituksista voisi tosiaan olla aihetta kertoa, mietin asiaa. Kuitenkin esimerkiksi XAMPP-paketissa virheet näkyvät automaattisesti ja toisaalta webhotelleissa niiden ei ole tarkoituskaan näkyä.
Pari juttua, joita ihmettelen.
Esimerkkikoodi nimen pituuden laskemisesta laskee ääkköset kahdeksi. Mitäköhän ihmettä?
Ehtolauseosassa Ehdot-kohdassa on erikoinen ja ihmettelyä aiheuttava muotoilu.
lainaus:
A == B: Aon sama kuinB
Tuosta voisi ymmärtää, että loppuosa ": A" kuuluisi vielä lausekkeeseen, vaikka tätä tuskin tarkoitetaan?
Macro kirjoitti:
Pari juttua, joita ihmettelen.
Esimerkkikoodi nimen pituuden laskemisesta laskee ääkköset kahdeksi. Mitäköhän ihmettä?
PHP ei ole kovinkaan unicode-yhteensopiva. Unicodea varten PHP:ssä on liuta mb-etuliitteisiä funktioita. Strlenin vastine on mb_strlen().
Unicodessa siis erikoismerkit, myös ääkköset, koostuvat useammasta kuin yhdestä tavusta, joten vanhanaikaiset funktiot eivät ymmärrä niitä oikein.
Opassarjassa on kokonainen osa merkistöistä, joten turha sitä on tuossa pysähtyä ihmettelemään. Pieni mainita ja linkki voisivat kuitenkin olla paikallaan.
Ongelmana on siis, että PHP:n funktio strlen palauttaa merkkijonon pituuden tavuina ja UTF-8-koodauksessa ääkköset vievät tilaa kaksi tavua. Tuohon kohtaan opasta tarvitaan selvästi viittaus merkistöistä kertovaan osaan 17.
Selvennän myös ehdoista kertovaa osuutta.
Ok! En lukenut koko opassarjaa ennen kommentointia, niin en huomannut merkistöasioita. Hyvä jos korjaatte virheet!
Muuten tuolla osassa 15 on 'tiedoston tyyppi' -kohdassa 'kokeile koodia' -linkki rikki.
Tosiaan tiedosto puuttui, korjasin nyt asian.
Ensimmäinen osa:
printf, sprintf ja vprintf, ts. voitaisiin sanoa ehkäpä "Kaksi yleisintä tulostuskomentoa PHP:ssä ovat". Tuossa kappaleessa voitaisiin mainita, että echo on komentorakenne kun taas printf on funktio (jolla on siis paluuarvo). Toki sen tarkemmin niiden eroihin heti ensimmäisessä osassa menemättä, jotta lukijan fokus säilyy. Ero on kuitenkin merkittävä, koska se tarkoittaa myös syntaktisia/toiminnallisia eroavaisuuksia.Tietoturva:
hash-funktiota SHA-512- (tai mitä tahansa SHA-2 perheen variaatiota) tai Whirlpool-algoritmilla. Tämä toimii aina PHP 5.1.2:sta lähtien (hitaasti päivittyvä hotellinikin on päivittänyt jo 5.1.6:een), on itse oppaassakkin jo heikoksi haukuttua md5:ttä paljon turvallisempi vaihtoehto, eikä tämä ole ohjelmoijalle käytännössä yhtään hankalampi. Myös suolauksen osuutta tulisi korostaa. Jos oikein muistan niin iterointi saattoi "heikentää tiivistettä" jonkun algoritmin kanssa (ei liene tässä kuitenkaan merkittävä seikka, lähinnä kryptografinen kuriositeetti).Muut:
Hyvä opassarja; hienoa, että tätä jaksettiin päivittää.
Antti Laaksonen kirjoitti:
Esimerkiksi listan kohdan merkitseminen ilman lopputagia on yleinen tapa, jonka ei pitäisi hämmentää ketään HTML:ää tuntevaa. Enemmänkin voisi hämmentää </li>-tagi, jota ei ole tottunut näkemään.
Heh, itse ajattelen juuri toisin päin. Toisaalta en normaalisti lue muiden kirjoittamaa HTML:ää raakana, ja Chromen inspektori lisää aina sulkutägit.
Merkistöoppaassa voisi mainita, mistä lyhenne mbstring tulee. Lisäksi rimpsun
<meta http-equiv="Content-Type" content="text/html; charset=X">
voi HTML5:ssä korvata tällä paljon siistimmällä:
<meta charset="X">
En osaa ulkomuistista sanoa toimiiko tuo ihan kaikissa selaimissa, mutta ainakin sitä käytettiin tuotantokoodissa joten eiköhän se ole ok. :)
Kiitos kommenteista, tsuriga ja jlaire. Harkitsen ehdottamianne asioita.
Osassa yksi sanotaan: "käytössä ovat mm. laskutoimitukset +, -, * ja /". Minusta on hämäävää puhua laskutoimituksesta jakolaskun yhteydessä, sillä nollalla ei voi jakaa, 0/x=0 kun x ei ole nolla mutta jakolasku on laskutoimitus joukossa R\{0}.
Tuossahan on kontekstina selvästi aritmetiikka eikä algebra. Aritmetiikassa jakolasku on ihan normaali laskutoimitus, vaikka toki sielläkin jako nollalla aiheuttaa virheen. Tietokonekielissähän virheitä voi tulla vaikka yhteenlaskussa (liian suuri tulos tms).
Tätä pilkkua on viilattu putkassa ennenkin. En kertakaikkiaan pysty uskomaan, että yksikään oppaan lukija (ehkä Jaskaa lukuunottamatta) hämääntyy siitä, että jakolaskua sanotaan laskutoimitukseksi.
Uudesta oppaasta puuttuu kokonaan switch valintarakenne. Onko se jäänyt pois inhimillisistä syistä vai tarkoituksella? Jos on ihan tarkoituksella jätetty pois, niin miksi?
Ohjelmoinnin tärkein asia, eli goto, jäi käsittelemättä :)
Muutama asia oli mielessä, jotka olisi voinut myös mainita siellä sun täällä, mutta siten olisi taas voinut mainita pari lisää, ja pari lisää, jne..
Näin sivumäärällisesti suppeaan oppaaseen ei millään voi ihan kaikkea laittaa. Tuossa oli minusta hyvä perussetti selkeässä muodossa. Joten hyvältä näytti.
Hienoa kun joku jaksaa näitä tehdä, on varmasti paljon apua monelle henkilölle.
Opassarjasta puuttuu tarkoituksella switch-rakenne, koska sen toteutus PHP:ssä ja muissa C-sukuisissa kielissä on kömpelö enkä halua rohkaista ketään käyttämään sitä.
Nykyään switch-rakenne merkitään PHP:ssä näin:
switch ($paiva) { case 1: case 2: case 3: case 4: case 5: echo "arkipäivä"; break; case 6: echo "lauantai"; break; case 7: echo "sunnuntai"; break; }
Järkevämpi merkintätapa olisi esimerkiksi seuraava:
Pienin rajoituksin seuraava koodi tosin ajaa asian.
Pienet rajoitukset ovat kuitenkin oleellisia, eli pitäisi varmistaa, että lukualue pysyy oikeissa rajoissa.
Lisäksi tuohon koodiin vaaditaan break-komennot, jotta se toimii kunnolla.
En minä tuota switchiä siksi maininnut etten olisi osannut käyttää sitä. Satuin vain huomaamaan sen puuttumisen, kun lähdin netistä etsimään, että mikä sen nimi taas olikaan ja ensimmäisenä yritin etsiä sitä täältä. :) Itse käytän yleensä Antin ensimmäisen esimerkin mukaista rakennetta + default loppuun, jotta sieltä varmasti jotain valitaan.
Joo, en toki epäillyt, ettet tuntisi switch-rakennetta, vaan halusin vain perustella, miksi se on mielestäni kömpelö.
PHP:n switch kyllä sallii emuloida lukuvälejä.
Tuo on kieltämättä hieno viritelmä. Tosin jos päivä on 0, niin kyseessä on koodin mukaan arkipäivä.
Noh joo, PHP bugaa sen nollan kanssa tässäkin tapauksessa.
Vaikka varta vasten käsketään hyväksymään nollaa suuremat arvot?
The Alchemist kirjoitti:
case $paiva > 0 && $paiva <= 5:
PHP ei suinkaan bugaa, vaan olet kirjoittanut virheellisen koodin. Koodisi vastaa tätä:
if ($paiva == ($paiva > 0 && $paiva <= 5))
Ei taida olla kovin järkevä tarkistus? Tulos on tuurilla oikea silloin, kun $paiva sattuu booleaniksi muutettuna olemaan true.
Lisäksi samalla menetetään switch-rakenteen varsinainen etu if-lauseisiin nähden: yhden lausekkeen tarkastelu nimeä toistamatta.
Kyllä tuo ehtolause on ihan oikein, se vain on bugi. Tarkastellaan vaikka seuraavaa esimerkkiä.
<?php
function foo($i) {
printf('%s: ', $i);
switch ($i) {
case 'a':
print 'a';
break;
case $i > 3 && $i < 6:
print 'First';
break;
case $i > 7 && $i < 10:
print 'Second';
break;
case 'b':
print 'Third';
break;
default:
print 'Neither';
}
print PHP_EOL;
}
foo('a');
foo(5);
foo(8);
foo('b');
foo('5');
foo(0);
foo('0');
?>Kokonaisluku-nollalla suoritetaan switchin ensimmäinen ehto. Mielenkiintoista on se, että string-nollalla suoritetaankin tuo ensimmäisen lukualueen ehto.
Millä perusteella se on bugi? Siksikö, että haluaisit sen toimivan toisin? Kyseessä ei ole mikään erityisesti tietyn muuttujan tarkasteluun tarkoitettu kikka, vaan PHP vain sallii casessa minkä tahansa lausekkeen ja vertaa tulosta switchin alussa annettuun. Yhtä hyvin voi tehdä tällaisen vertailun:
switch (true) { case $a == 1: echo "a = 1."; break; case $b == 2: echo "b = 2."; break; case $a < $b: echo "a < b."; break; default: echo "jotain muuta."; break; }
The Alchemist kirjoitti:
Mielenkiintoista on se, että string-nollalla suoritetaankin tuo ensimmäisen lukualueen ehto.
Jos nyt miettisit asiaa hetken ihan rauhassa, siinä ei ehkä olisi mitään mielenkiintoista. On tunnettu tosiasia, että 0 == "a", koska (int) "a" == 0. Vastaavasti on selvää, että "0" != "a". Sen sijaan "0" == ("0" > 3 && "0" < 6) (eli "0" == false), joten toinen kohta toteutuu.
Turso kirjoitti:
Saisiko opassarjan kirjoitus- tai julkaisupäivämäärän näkyville.
Onko tämä ihan mahdoton ajatus? Mielestäni etenkin kenties vuosien kuluttua luettaessa ihan hyödyllinen tieto.
Lueskelin oppaan osan 17 (Merkistöt) ja hämmästyin, kun en löytänyt yhtään virhettä.
Euron merkki on kuitenkin hiukan huono esimerkki ongelmasta, johon UTF-8 tuo ratkaisun. Se nimittäin ratkeaa myös windows-1252:lla, joka toisaalta on se, mitä ISO-8859-1 webissä käytännössä tarkoittaa. Periaatteessa on tietysti hyvä ilmoittaa koodaukseksi window-1252, jos sitä käyttää.
Lisäksi ongelma tietysti ratkeaa useimmiten myös merkinnällä €.
Painavaa tarvetta UTF-8:n käytölle alkaa olla vasta sitten, kun sisällössä on runsaasti sellaisia merkkejä, jotka eivät kuulu windows-1252:een, esim. kun sisältö on ihan hepreaa tai fysiikan kaavoja. Silloin koodista tulisi hankalannäköistä ja vaikeasti ylläpidettävää, jos ne kaikki esitettäisiin &-merkinnöillä.
Ratkeaahan se vaikka kynalla ja paperilla, tai vaihtoehtoista merkintaa (EUR) kayttamalla. Mutta miksi windows-1252 on parempi ratkaisu kuin UTF-8?
Web-käytössä oletusmerkistö (windows-1252) sisältää euromerkin. Eli euromerkin osalta ei ole mitään ongelmaa, joka jäisi UTF-8:lle ratkaistavaksi.
Periaatteessa jos mitään yli Windows-1252 -merkistön meneviä merkkejä ei tarvita, mutta tarvitaan kuitenkin yli 7-bittisen asciin meneviä merkkejä, niin Windows-1252 vie vähemmän tilaa kuin UTF-8. Itse pitäisin tätä eroa kuitenkin käytännössä merkityksettömänä.
Yucca kirjoitti:
Painavaa tarvetta UTF-8:n käytölle alkaa olla vasta sitten, kun sisällössä on runsaasti sellaisia merkkejä, jotka eivät kuulu windows-1252:een, esim. kun sisältö on ihan hepreaa tai fysiikan kaavoja. Silloin koodista tulisi hankalannäköistä ja vaikeasti ylläpidettävää, jos ne kaikki esitettäisiin &-merkinnöillä.
Jos ei ole painavaa tarvetta niin ainakin on suositeltavaa käyttää UTF-8 merkistöä.
Turso kirjoitti:
Turso kirjoitti:
Saisiko opassarjan kirjoitus- tai julkaisupäivämäärän näkyville.
Onko tämä ihan mahdoton ajatus? Mielestäni etenkin kenties vuosien kuluttua luettaessa ihan hyödyllinen tieto.
Miksi päivämäärä olisi hyödyllinen tieto? Useimmat oppaan asiat pätevät varmasti vielä kymmenenkin vuoden kuluttua, ja ne harvat, jotka muuttuvat, voidaan päivittää myös oppaaseen.
Metabolix kirjoitti:
Miksi päivämäärä olisi hyödyllinen tieto?
Haluaisitko lukea tietämättäsi opasta, joka on kirjotettu sillon ku PHP4 oli uusin versio? No sitä minäkin. Tosin, kirjoituspäivää hyödyllisempi päivämäärä vois olla viimeisimmän päivityksen ajankohta.
jcd3nton kirjoitti:
Mutta miksi windows-1252 on parempi ratkaisu kuin UTF-8?
Se on kahdeksanbittinen, joten siinä ei ole niitä UTF-8:n ongelmia, joita oppaan osassa 17 käsitellään.
Blaze kirjoitti:
Haluaisitko lukea tietämättäsi opasta, joka on kirjotettu sillon ku PHP4 oli uusin versio? No sitä minäkin.
Kuinka moni oppaan lukijoista tietää, mikä PHP:n versio on käytössä, milloin se on julkaistu ja mitkä asiat siinä ovat mahdollisesti muuttuneet oppaaseen nähden? Osaatko itse suoralta kädeltä sanoa, mitä versiota käsittelee vaikkapa vuonna 2006 kirjoitettu opas ja mitkä asiat sen jälkeen ovat muuttuneet?
Nykyäänhän Putkassa on lähtökohtana, että vanhentuneet oppaat ovat arkistossa ja opasalueen etusivu edustaa nykyaikaa. Yksi ratkaisu olisi ilmoittaa tämän perusteella automaattisesti jokaisen oppaan alussa, onko tieto vielä ajan tasalla.
Yucca kirjoitti:
[Windows-1252] on kahdeksanbittinen, joten siinä ei ole niitä UTF-8:n ongelmia, joita oppaan osassa 17 käsitellään.
Käytännössä en muista kohdanneeni PHP:ssä tilannetta, jossa UTF-8 olisi aiheuttanut todellisia ongelmia tavumääränsä vuoksi. Tekstiä käsitellään aika harvoin merkki kerrallaan, eli mahdollisia ongelmatilanteita ei ole kovin paljon. Yleensä "ongelmat" johtuvat siitä, että käsitellään virheellisesti tavuja eikä merkkejä. PHP:ssä asia on helppo korjata käyttämällä mbstring-funktioita. Laiska voi jopa laittaa UTF-8-yhteensopivat funktiot automaattisesti perinteisten funktioiden päälle, mutta tällöin tietenkin binaaridatan käsittely vastaavasti vaikeutuu.
Euromerkki on tosiaan huono esimerkki UTF-8:n hyödystä. Muutan sen tilalle paremman esimerkin jossain vaiheessa.
UTF-8-merkkijonojen vaihteleva merkin tavumäärä aiheuttaa ongelmia käytännön tilanteissa. Esimerkiksi substr on aivan arkipäiväinen funktio, joka ei toimi oikein UTF-8-merkkijonojen kanssa. Korjaus ei toki ole vaikea, mutta asiasta on hyvä olla tietoinen.
Metabolix kirjoitti:
Turso kirjoitti:
Turso kirjoitti:
Saisiko opassarjan kirjoitus- tai julkaisupäivämäärän näkyville.
Onko tämä ihan mahdoton ajatus? Mielestäni etenkin kenties vuosien kuluttua luettaessa ihan hyödyllinen tieto.
Miksi päivämäärä olisi hyödyllinen tieto? Useimmat oppaan asiat pätevät varmasti vielä kymmenenkin vuoden kuluttua, ja ne harvat, jotka muuttuvat, voidaan päivittää myös oppaaseen.
Oh, tämä onkin tiukassa. Opassarja löytyy varsin monessa hakutuloksessa. Kas "intternetistä" löytyy valtavasti tietoa - osa on vanhentunut. Itse pyrin aina ensi silmäyksellä hahmottamaan, mikä tieto on vielä ajankohtaista, tähän kysytty päivämäärä antaa yllättävän näppärästi vastauksen, eikö totta?
Olet oikeassa. Vaikka Ohjelmointiputkan opas olisi ajan tasalla, lukijan on vaikeaa tietää tätä ilman päiväystä. Asiaan tulee korjaus.
Missä nykyään on tavallisimmat funktiot luettelo? ennen se oli ../hak
Aihe on jo aika vanha, joten et voi enää vastata siihen.