Keskustelu: Nettisivujen teko: viisi uusinta sivua

Kuinka saisin näytettyä sivulla viisi uusinta sivua? Sivut haetaan eräästä hakusanat.txt tiedostosta, jossa ne on tiedoston ihan lopussa tyyliin

hakusana:hakusanan otsikko:hakusanan tiedot#http://osoite.com

Tuottaako ongelmia viimeisten rivien poimiminen, linkkien muodostaminen vai jokin muu? Mitä linkkien teksteiksi tulee?

Öh? :D

pitäisi siis vain saada näytettyä hakusanat.txt tiedostossa olevat viisi viimeistä (eli uusinta) sivua, ei ole ongelmia paitsi webmasterin kädettömyys (ei osaa PHP:tä) :D

Kyllä mä olen yrittänyt harjoitella, mutta tällä hetkelläkään en osaa kuin sen verran PHP:tä, että osaan lähinnä laittaa tekstiä ruutuun

<?php
echo("tekstiä");
?>

ja osaan hieman lukea koodia ja sen toimintaa, mutta oman koodin tuottaminen on vielä hankalaa.

No eipä sitten muuta kuin harjoittelun iloa :) (valmista koodia ei olisi tarkoitus antaa)

Paljastamatta koko ratkaisua: kokeile näitä asioita: file(), array_reverse() ja sit foreach().

https://www.php.net/manual/en/function.file.php
https://www.php.net/manual/en/function.array-reverse.php
https://www.php.net/manual/en/language.control-structures.php

Tuolla pitäisi jo päästä aika pitkälle. Harjoittelun iloa :-)

En suosittele taulukon kääntämistä nurinperin jollain funktiolla, ellei sille ole pakonomaista tarvetta.

Käyttämällä for-silmukkaa, voit helposti käydä taulukkoa läpi takaperin.

T.M. kirjoitti:

En suosittele taulukon kääntämistä nurinperin jollain funktiolla, ellei sille ole pakonomaista tarvetta.

Käyttämällä for-silmukkaa, voit helposti käydä taulukkoa läpi takaperin.

Parin sekunnin tuhannesosan menetys vs. koodin selkeys ja ymmärrettävyys. Jokainen valitkoot oman tapansa :)

Mjaa... onkohan näin? Käännäppäs tuolla funktiolla miljoona riviä niin huomaat eron.

Ja miksi niitä huonoja tapoja on aivan pakko opetella?

Vielä varottaisin käyttämään noita PHP:n array-funktioita, etenkin array_map() funktiota missään vähänkään suuressa taulukossa.
Syyt: hitaus, muistin kulutus, purkkamenetelmä.

Joidenkin array-funktioiden nopeus on jopa pienempi kuin tavallisella foreach-silmukalla koodattu systeemi.

Sitten kun tekstitiedostosta löytyy miljoona riviä, lienee paikallaan katsoa peiliin. PHP:n valmiit funktiot ovat tehty käytettäviksi, ja ainakin itselleni tuo koodin selkeys on tärkeämpi seikka kuin noiden muutamien tuhannesosien voittaminen. Mutta kuten sanottua, jokainen saa valita oman tapansa.

Sen kyllä huomaa miten typerä on ollut PHP:tä koodatessa, kun siirtyy esimerkiksi C-kieleen :)

T.M. kirjoitti:

Sen kyllä huomaa miten typerä on ollut PHP:tä koodatessa, kun siirtyy esimerkiksi C-kieleen :)

Onneksi itselläni tuo siirtyminen tapahtui juurikin toisinpäin... :)

Ai? No ei kyllä uskois, kun käyttelet tuolla tavalla PHP:n funktioita.
No jokaisella tapansa, kuten sanoit.

Minäkään en varmaan tässä tilanteessa kääntäisi koko taulukkoa, mutta muuten olen kyllä samoilla linjoilla Olgan kanssa. Skriptiä kannattaa optimoida vasta sitten, kun sen ylimääräisen hitauden todella huomaa todellisessa käyttötilanteessa. Ainakin minulle näin käy vain ani harvoin.

Taulukon viiden viimeisen alkion näyttäminen for-silmukan avulla:

<?php

$tiedot = range(1, 10);

for ($i = count($tiedot); $i >= count($tiedot) - 5; $i--) {
    echo "<p>" . $tiedot[$i] . "</p>";
}

?>

T.M. kirjoitti:

Ja miksi niitä huonoja tapoja on aivan pakko opetella?

Toisen huonotapa on toisen käytännöllisyys. Itse ainakin harvoin olen nähnyt PHP skripteissäni minkäänlaista nopeuden vähenemistä, ellen sitten tee mittausta sekunnin sadas- ja tuhannesosissa.

Mitä nyt juhazille ehdotin oli vain nopea ratkaisu, enkä ensimmäisenä miettinyt että onko tämä nyt paras tapa. Jos mietitään fiksua koodaamista niin itse en ainaakaan laittaisia tällaista järjestelmää tekstitiedoston varaan vaan laittaisin tämän kaiken tietokantaan ja tekisin kyselyt sql:llä. Parhaimman tuloksen kun käyttää kyselyä joka palauttaa juuri sen mitä halutaan, ettei PHP:tä edes tarvitse käyttää tulosten parsaamiseen vaan ne voi suoraan vain tulostaa.

Antti, koodissasi on virhe.
Tässä korjattu + optimoitu ;)

<?php

$tiedot = range(1, 10);
$max = count($tiedot);

for ($i = $max-1; $i >= $max-5; $i--) {
    echo "<p>" . $tiedot[$i] . "</p>";
}

?>

Niin ja tuosta array_reverse() käytöstä, että sen käytön typeryyden huomaa vasta sitten kun kääntelee sillä isompia filuja. Jos ei tiedä sen hitautta aikaisemmin, voi alkaa ihmetellä minkä takia scripti on niin hidas.

Ja jos on mahdollista kiertää jonkin funktion käyttö, niin miksi pitää olla käyttämättä sitä nopeampaa tapaa? Tuossa tapauksessa koodin selkeys ei huonone.
En ole huomannut tilannetta jossa optimoitu koodini olisi sekavampi kuin optimoimaton. Yleensä siinä käy juuri toisinpäin, kun koodimääräkin vähenee optimoimisen yhteydessä.

Toki matemaattiset laskutoimitukset menettävät selkeytensä, mutta harvemmin PHP:llä väännetään mitään korkeamman matematiikan tehtäviä.

Jos on kyse jostain demoefektistä, niin siinä tapauksessa optimoitu koodi menettää selkeytensä, ja on täten myös vaikeammin muokattavissa.
Mutta kun tehdään PHP:llä jotain raskasta tietojenkäsittelysysteemiä, niin siinä ei pitäisi koodin mennä niin pahasti solmuun jos kiertää muutaman funktion käytön, jollain järkevämmällä rakenteella :)

Toki noita valmiita funktiota on kätevä käyttää joissain pienissä jutuissa, mutta en suosittele ottaa tavakseen käyttää noita funktioita aina.

T.M. kirjoitti:

Jos ei tiedä sen hitautta aikaisemmin, voi alkaa ihmetellä minkä takia scripti on niin hidas.

kun tämä nyt kerran meni optimointikeskusteluksi, niin eikö niitä eri toteutustapoja kannattaisi verrata esim. prosentteina eikä suoraan millisekunteina. Kun yleensä kehitysvaiheessa testiaineisto on pieni, niin eihän siinä silmä juuri erota suoriutuuko joku toiminto kymmenessä vai sadassa millisekunnissa. (eroa 90 ms) Prosentteina (tai yleensäkin suhteessa alkuperäiseen) tuo ero onkin jo aika suuri. Ja sitten kyllä usein käy niin kuin T.M. jo sanoi että myöhemmin sitten ihmetellään että onpas hidasta. Kun muistaa joskus kirjoittaneensa koodin johonkin tehtävään, niin silloin on kyllä taipumusta käyttää juuri sitä pätkää, kuin että kirjoittaisi saman uudestaan. Yleensä vielä copypastella. Siinä vaiheessa sitten sen "bugin" metsästäminen onkin vaikeampaa, kun alkuperäinen idea ei välttämättä ole enää niin selvänä mielessä.

T.M. kirjoitti:

En ole huomannut tilannetta jossa optimoitu koodini olisi sekavampi kuin optimoimaton. Yleensä siinä käy juuri toisinpäin, kun koodimääräkin vähenee optimoimisen yhteydessä.

Yleensä asia on juuri näin. Usein optimoitaessa käy niinkin päin että on kirjoittanut jonkun funktion ja sitten huomaa että on olemassa valmis funktio joka hoitaa saman asian nopeammin.

Kylläpäs tämä nyt paisui.

T.M. kirjoitti:

Niin ja tuosta array_reverse() käytöstä, että sen käytön typeryyden huomaa vasta sitten kun kääntelee sillä isompia filuja. Jos ei tiedä sen hitautta aikaisemmin, voi alkaa ihmetellä minkä takia scripti on niin hidas.

Yleensä kehittäjä minulla on hyvä käsitys siitä mitä tekstitiedostoihini laitan. Kun teen skriptejä, yleensä suunnittelen sen toimimaan tietyissä puitteissa. Tässä tapauksessa tietäisin kuinka paljon dataa olisin mahdollisesti tallentamassa hakusanat.txt -tiedostoon. Jos kyse olisi miljoonista, niin kuin joku ehdotti, tuskin edes avaisin sitä file() funktiolla. Käyttäisin ehkä tiedostokahvoja, tai parempaa, tietokantaa. Jos tiedän että tuskin kyseessä on tuhansista riveistä, käyttäisin ehdotettua for() silmukkaa. Jos tietäisin että kyse on sadoista riveistä, käyttäisin kevyinmielin foreach() silmukkaa. Näin ainakin itse suunnittelen skriptejäni. Koodia kirjoittaessa on vain käytännöllistä ottaa huomioon tarpeet jotka alunperin ajoivat tekemään sitä koodia. So what jos skripti ei ole käytännöllinen jos siihen tallentaa kymmeniätuhansia rivejä tekstiä. En usko että juhazin tarpeet menevät niin pitkälle.

T.M. kirjoitti:

Ja jos on mahdollista kiertää jonkin funktion käyttö, niin miksi pitää olla käyttämättä sitä nopeampaa tapaa?

PHP:n kehityksessä on satsattu aika paljon alemassa olevien algoritmien käyttämiseen nopeimmalla mahdollisella tavalla. Mielestäni on myös yhtä kummallista rakentaa oma viritelmä, jos kerran PHP:llä on oma funktio jonkin asian tekemiseen.

lainaus:

Mielestäni on myös yhtä kummallista rakentaa oma viritelmä, jos kerran PHP:llä on oma funktio jonkin asian tekemiseen.

Jaaha.

Kumpi selkeämpi?

1.

<?php

$filu = file("testi.txt");
$filu = array_slice($filu, -5); // halusimme vain 5 tulosta
$filu = array_reverse($filu);

foreach($filu as $rivi){
    print $rivi."<br>";
}

?>

2.

<?php

$filu = file("testi.txt");
$max = count($filu);

for($u = $max-1; $u >= $max-5; $u--){
    print $filu[$u]."<BR>";
}

?>

Mielestäni tuo alempi koodi näyttää vähemmän omalta viritelmältä

Tuosta toisesta ei niin helposti käy ilmi haluttujen tulosten määrä, kun pitää miettiä, mitä for-lause tekee.

No kun nyt tästä tapellaan, niin kirjoitetaan tuo toinen ehdotus vielä vähän selkeämmin:

<?php
$tiedosto = file("testi.txt");
$viimeinen = count($filu) - 1;

for ($x = $viimeinen; $x > $viimeinen - 5; $x--){
    echo $tiedosto[$x]."<BR />";
}
?>

Eikös tuosta jo näy se -5 aika selkeästi? Ja kun on hetken ohjelmoinut, niin kyllä se for-lauseen toiminta pitäisi ymmärtää, jos se on noin helppo for-lause. Ja printiä ei tueta :)

Itsehän käyttäisin edelleen tapaa yksi, jos vaan muistan nuo kaksi array-funktiota ulkoa, ei tarvitse lähteä miettimään for-lauseen toimintaa ollenkaan. Optimointia sitten jos on tarvetta. <br /> :)

Tomi kirjoitti:

PHP:n kehityksessä on satsattu aika paljon alemassa olevien algoritmien käyttämiseen nopeimmalla mahdollisella tavalla. Mielestäni on myös yhtä kummallista rakentaa oma viritelmä, jos kerran PHP:llä on oma funktio jonkin asian tekemiseen.

tsuriga kirjoitti:

Itsehän käyttäisin edelleen tapaa yksi, jos vaan muistan nuo kaksi array-funktiota ulkoa, ei tarvitse lähteä miettimään for-lauseen toimintaa ollenkaan. Optimointia sitten jos on tarvetta.

Aamen.

Tomi kirjoitti:

PHP:n kehityksessä on satsattu aika paljon alemassa olevien algoritmien käyttämiseen nopeimmalla mahdollisella tavalla.

Enpä nyt noinkaan sanoisi... osa PHP:n funktioista näyttää olevan aika purkasti tehtyjä :p

$color = ($r << 16) | ($g << 8) | $b;
on nopeampi kuin... imagecolorallocate()

$round = (int)($numero+0.5);
on nopeampi kuin... round($numero)

Enpäs nyt muita esimerkkejä jaksa etsiä, joten nuo riittänee.

Ja tästä päästään taas kysymykseen, mitä tarkoittaa purkka. Väittäisin, että php:n funktiot eivät ole purkkaa. Oma käsitykeni purkasta:
"purkka on huonosti toteutettu viritys, jolla paikataan jotain suurempaa virhettä. Koodi venyy ja paukkuu ja selkeys häviää sen sen mukana"

Purkka ei todellakaan tarkoita hidasta koodia.

Ja ihan mielenkiinnosta, mitä hyödytään käyttämällä $round=(int)($numero+0.5) round($numero):n sijasta? 0,0000001s? Ja mitähän merkitystä tällä on koodin toiminnan kannalta? Kyllä selkeys voittaa tuon 0,0000001s ainakin minun koodaustyylissäni.

Aamen myös minun osaltani. Kokemuksesta tiedän, että T.M.:ltä trollaus onnistuu.

ajv kirjoitti:

Ja ihan mielenkiinnosta, mitä hyödytään käyttämällä $round=(int)($numero+0.5) round($numero):n sijasta? 0,0000001s? Ja mitähän merkitystä tällä on koodin toiminnan kannalta? Kyllä selkeys voittaa tuon 0,0000001s ainakin minun koodaustyylissäni.

30% nopeampi tuo esittämäni tapa, ja se on paljon nopeuden kannalta. Mutta tässä tapauksessa pointtini ei ollut se, onko jokin hyödyllistä koodin kannalta, kerroin vain ettei ne PHP:n funktiot ole "huippuunsa optimoituja". Kuten tuossa ylempänä väitettiin.

Eikö keskusteluissa saa korjata toisten väitteitä lainkaan?
Mielestäni jokaisella on oikeus tähän.

lainaus:

Kokemuksesta tiedän, että T.M.:ltä trollaus onnistuu.

Jahas. Haukuppa samalla peeloksi ja [lisää tähän muutama haukkumasana], niin eiköhän se siitä parane.

Aah, tämä on sitä putkaa itseään :) Pieni asia, iso väittely.

juhazia neuvon vaihtamaan monet erottimet yhdeksi erottimeksi, jolloin rivit näyttävät tältä:

hakusana|###|hakusanan otsikko|###|hakusanan tiedot|###|http://osoite.com|###|

Huomaa erotin viimeisen arvon perässä, tämä estää rivinvaihdon mukaanhyppimisen. Koodi taas näyttäisi tältä:

<?php
$file = file("hakusanat.txt");
$max = count($file) -1;

for ($i = $max; $i > $max - 5; $i--) {
  $tieto = explode("|###|", $file[$i]); //nyt linkin tiedot löytyvät tyyliin: $tieto[0] = hakusana, $tieto[1] = hakusanan otsikko...
  echo "<a href=\"{$tieto[3]}\">{$tieto[$0]}</a><br />\n";
}
?>

Ja nyt mukaan väittelyyn. Miksi tein näin? Itse en koodien nopeuksista tiedä piirun vertaa, mutta selkeyteen voin vedota. Lisäksi haluan sanoa, että on naurettavaa olla käyttämättä for-silmukkaa, koska ei ymmärrä sitä. For-silmukka on niin perusasiaa, että on aika suunnata kirjastoon, mikäli sen kanssa on ongelmia.

Viittaan seuraavissa esimerkeissä T.M.:n kirjoittamiin esimerkkeihin.

1. Avaa tiedoston sisältö erottaen jokainen rivi omaksi alkioksi taulukossa. Luo uusi taulukko taulukon viidestä viimeisimmästä alkiosta. Käännä uusi taulukko ylösalaisin. Käy taulukko läpi tulostaen sen alkiot.

2. Avaa tiedoston sisältö erottaen jokainen rivi omaksi alkioksi taulukossa. Lue ja tulosta taulukon viisi viimeistä alkiota aloittaen viimeisimmästä alkiosta.

EDIT: pikku viilausta

Mitä hyötyä on laittaa noin pitkä erotin? Mieluummin vaikka chr(7).

Eihän siitä varmaan mitään hyötyä tule, mutta tuskin haittaakaan. Voihan tuon helposti vaihtaa, mikäli haitaksi syntyy.

Unohtu sanoa: pitkä erotin vie enemmän (turhaa) tilaa.

Kukaan ei varmasti tee täysin puhtaan selkeää ja nopeaa koodia ensimmäisellä kirjoitus kerralla. Optimoida pystyy aina.

Hidasta funktiota ei ole järkevä käyttää edes vähissä datamäärissä, perusteluita tuskin kaivataan.

Tekstitiedoston koko ei tuosta erotinmerkistä tuskin kasva nimeksikään(selkeydestä en sano mitään, paitsi sen, että tuo käy silmään). Ja mitä väliä vaikka kasvaisikin. Kiintolevyn koko tuskin on ongelma ja koodin nopeus on kuitenkin hyvällä mallilla, kun ei niitä hitaita funktioita tms. käytetä.

Voi nyt jo jeesus. Kyseessä on sekunnin tuhannesosat ja niin pieniä ajanjaksoja ei ihmissilmä eikä -mieli edes tajua. Sitten ku ero on jo selvästi huomattavissa ja siitä on haittaa, voi alkaa optimoimaan.

Tyhmä saa olla, muttei liian tyhmä.