Petja kirjoitti:
En näet jaksa joka kerta mennä keskustelun ohjeisiin.
Sama vika. Hyviä ehdotuksia... kannatan :D
Huomaa kuitenkin, että voit käyttää myös ul li pareja aivan normaalisti hakasulkujen kanssa.
Ehkä tähän voisi rakentaa jonkun tarkistuksen, joka ymmärtää jos tekstistä löytyy paljon koodia muttei kooditageja. Sitten vaan ilmotus ja käyttäjä saa opetella käyttämään niitä.
Teuro kirjoitti:
Huomaa kuitenkin, että voit käyttää myös ul li pareja aivan normaalisti hakasulkujen kanssa.
Jännä, mä oon aina käyttänyt noita ul- ja li-tageja, enkä oo noista lip- ja lik-jutuista kuullutkaan. :D
Kiva kun kerroit tästä, Teuro! Olisin kyllä voinut sitä itsekin kokeilla, jos olisin tajunnut. Siitä huolimatta tähden kirjoittamiseen menee suunnilleen 100 millisekuntia, toisin kuin li:n tai ul:n, joihin tuhlaantuu jopa 1000 ms. Ei sen niin väliä ole, mutta helpompaa ja nopeampaa.
Macrolla oli hyvä idea. Paljon kätevämpi olisi myös jos tunnistettaisiin automaattisesti koodi esim. <?php -alkuosasta. Nykyisten kooditagien käyttö jäisi vain sellaisiin tapauksiin, jolloin koodin syntaksista ei selvästi näe, mikä kieli on kyseessä.
En laittaisi myöskään vastaan, jos esimerkiksi php-koodissa olevat php:n omat funktiot olisivat linkkejä php.netin dokumentaatioon. Ei tarvitsi mennä Googleen jne. CSS:llä muokkaisi värit oikein ja alleviivaukset pois, siten että näyttäisivät siltä miltä nytkin.
Ennen mittavien muutosehdotusten esittämistä voisit laatia kattavat perustelut, joista näkyy, että olet miettinyt sekä hyvät että huonot puolet alusta loppuun. Useimmissa ehdotuksissasi (varsinkin siinä lainaustagijutussa, jonka jo poistit) nimittäin riittää ongelmia.
Petja kirjoitti:
Paljon kätevämpi olisi myös jos tunnistettaisiin automaattisesti koodi esim. <?php -alkuosasta.
Ja mitähän tuollekin viestillesi silloin kävisi?
Petja kirjoitti:
Nykyisten kooditagien käyttö jäisi vain sellaisiin tapauksiin, jolloin koodin syntaksista ei selvästi näe, mikä kieli on kyseessä.
Kielen tunnistaminen koneellisesti on usein mahdotonta, eikä koodin alkua ja loppuakaan ole yleensä helppo havaita, kun monet vielä tunkevat keskustelussa koodeihin kommentteja ilman kommenttimerkkiä ja sisentävät huonosti. Mutta jos koodaat tarpeeksi hyvän systeemin tähän, voin ottaa sen käyttöön.
Petja kirjoitti:
Näitä listoja voisi tehdä MediaWikin tyylisesti asettamalla vain tähden (*) kohdan eteen,
Vaikea sitä on näin pitkän historian jälkeen muuttaa. Sitä paitsi tuollaiset yli-innokkaat automaattimuotoilut aiheuttavat ongelmia sille 95 %:lle käyttäjäkunnasta, jota ei kiinnosta perehtyä muotoiluihin. Tämä on jo nähty lukuisilla netin keskustelupalstoilla.
Petja kirjoitti:
Keskustelun ohjeet voisi tiivistää viestiruudun viereen
Esimerkiksi mitkä osat? Koodi- ja lainaustagit on helppo muistaa, ja muita muotoiluja tarvitsee todella harvoin (yritä nyt itsekin takoa se kalloosi, tällaisia viestejä on vaikea ottaa vakavasti). Ohjeet viestin sisällöstä käsittelevät sellaisia perusasioita, että jos niitä ei osaa luonnostaan noudattaa eikä viitsi käydä ohjesivulta edes kerran lukemassa, tuskin niiden kopiointi viestilaatikon viereenkään paljon auttaa.
Petja kirjoitti:
En laittaisi myöskään vastaan, jos esimerkiksi php-koodissa olevat php:n omat funktiot olisivat linkkejä php.netin dokumentaatioon.
Ai että kirjoittaisi listaan PHP:n 2^samperin_paljon funktiota? Yeah!
No joo onhan toki php:a tietenkin funktio näyttämään mitkä funktiot on käytettävissä, mutta jokaisen sanan käyminen läpi jokaisesta viestistä ennen näyttämistä on mahdollisesti hiukan huono idea?
"Petja kirjoitti:
Ei tarvitsi mennä Googleen jne. CSS:llä muokkaisi värit oikein ja alleviivaukset pois, siten että näyttäisivät siltä miltä nytkin.
Se onkin rankkaa...
Metabolix,
1. Viestini ei kävisi mitenkään. Ei minulla ollut lopetustagia. Voidaan myös sopia, että olin asettanut [eimuotoilua]-tagin <?php-kohdan ympärille.
2. Voin yrittää
3. En ota kantaa
4. En puhunut nyt pelkästään itsestäni, vaan aivan tulokkaista myös. Ei tästä muistamisesta ole kyse, vaan siitä että ne oppii kun tulee. Ne voisi näkyä esimerkiksi ensimmäiset 14 päivää ensimmäisestä kirjautumisesta sekä jos ne omista asetuksista niin kytkee (kun kerta teitä tuntuu tämäkin ehdotus niin haittaavaan). Ps. Tälläisiä viestejä on vaikea ottaa vakavasti.
Teuro,
1. On ne sinne php.netiinkin joku kirjoittanut? Kai?
2. On se. On huomattavasti helpompaa viedä hiiri linkin päälle ja napsauttaa, kuin mennä hakulaatikon päälle, napsauttaa, kirjoittaa joskus pitkäkin hakusana, painaa Enteriä, odottaa sivun latautumista, klikata linkkiä ja odottaa toisen sivun latautumista.
Petja kirjoitti:
Metabolix,
1. Viestini ei kävisi mitenkään. Ei minulla ollut lopetustagia.
Et maininnut mitään lopetustagista. Lopetustagi ei ylipäätään ole PHP:ssä pakollinen, joten ei olisi kovin loogista vaatia sitä viestiin.
Petja kirjoitti:
1. Viestini ei kävisi mitenkään. Ei minulla ollut lopetustagia. Voidaan myös sopia, että olin asettanut [eimuotoilua]-tagin <?php-kohdan ympärille.
Eikö sen [eimuotoilua]-tagin kirjottaminen olisi yhtä hankalaa kuin sen [koodi]-tagin kirjoituskin?
Petja kirjoitti:
Ps. Tälläisiä viestejä on vaikea ottaa vakavasti.
Ainakin asia tuli selväksi ilman mitään turhia alleviivauksia ja lihavointeja.
Petja kirjoitti:
On ne sinne php.netiinkin joku kirjoittanut? Kai?
Joo, mutta ehkä niitä ei kukaan halua kirjoittaa enään uudelleen? Netti on varmasti pullollaan listoja, ja kuten joku jo mainitsikin, PHP:ssä on oma funktio niiden tulostukseen.
Petja kirjoitti:
Ei tarvitsi mennä Googleen jne.
Jopa vissiin IE osaa jo hakea Googlesta kun kirjoitat hakusanasi osoitepalkkiin.
Macro, vastasin jo Teuron viestiin. Lue aiemman viestini loppuosa uudelleen.
Mutta kun "tälläisiä viestejä on vaikea ottaa vakavasti" (jos et ymmärtänyt, niin siteeraasin aikaisempaa viestiäsi).
Aivan sama. Jos uudistuksia ei tehdä, niin sitten ei tehdä. Eipä ne minun juttujani ole, te niistä päätätte.
Tein nyt kuitenkin koodintunnistimen Metabolixin riemuksi:
http://petjatouru.com/foo/kooditunnistin.php
Tunnistaa JS:ää, Javaa, PHP:tä, CSS:ää ja HTML:ää. Perustuu levenshtein-funktioon. Ei tunnista koodia tekstin keskeltä, mutta tietää mikä kieli em. on kyseessä. Juu jos pirunkirjaa rupeette selaamaan löydätte heti jonkun bugin.
Edit: Tunnistaa jotain Javasta. En osaa itse Javaa, mutta joitain rippeitä tuo ymmärtää.
Petja kirjoitti:
Perustuu levenshtein-funktioon.
En ymmärrä, miten koodin tunnistus voisi perustua kahden tekstin välisen eron laskemiseen. Sitä paitsi JS, PHP, CSS ja HTML eivät riitä mihinkään, vaan pitäisi esimerkiksi erottaa C# ja Java.
Petja kirjoitti:
Juu jos pirunkirjaa rupeette selaamaan löydätte heti jonkun bugin.
No en kyllä päässyt testeissä tämän pidemmälle:
Petjan viritelmä kirjoitti:
<?php echo "moi"; ?>Eikös toi oo juu, unohda, toi tuskin edes mitään koodikieltä edes on?
Parannettu. On aika pieni tuo "sanakirja" jonka perusteelta yrittää etsiä kielen. Yritäpä uudelleen.
Se etsii POST-muuttujaa lähimpänä olevan koodipätkän Arraysta ja käyttää switchiä katsomaan mikä sana vastaa Arrayssä, sitten tulostaa kielen tulostaa sen.
<h1>Huippuetevä kooditunnistin</h1> <b>Tiedän <span style="font-size:24px;">0,2%</span> varmuudella</b> mikä kieli on kyseessä kattavan koodivarastoni avulla<br /><br /> <?php $input = $_POST['koodi']; $words = array( "$(\"#obj\").css(\"background-color\",\"#FFFFFF\");", /* JavaScript/jQuery */ "print \"background-color:#FFFFFF;\";", /* PHP */ "#obj{background-color:#FFFFF;}", /* CSS */ "<html><head><style>#obj{background-color:#FFFFF;}</style></head></html>", /* HTML */ "switch($var)\{Case \"esim\":break;\}", /* JS/PHP */ "<html><div id=\"random\"></div></html>", "public static void main (String[] args)\{System.out.println(\"Hello World!\");\}", "<?php echo \"moi\"; ?>", "import java.applet.Applet;import java.awt.*;public class HelloWorld extends Applet \{public void paint (Graphics g)\{g.drawString(\"Hello World!\", 25, 25);\}\}" ); $shortest = -1; foreach ($words as $word) { $lev = levenshtein($input, $word); if ($lev == 0) { $closest = $word; $shortest = 0; break; } if ($lev <= $shortest || $shortest < 0) { $closest = $word; $shortest = $lev;}} switch($closest){ Case $words[0]: $lopputulos="JavaScriptiä"; break; Case $words[1]:Case $words[7]: $lopputulos="PHP:tä"; break; Case $words[2]: $lopputulos="CSS:ää"; break; Case $words[3]:Case $words[5]: $lopputulos="HTML:ää"; break; Case $words[4]: $lopputulos="JS:ää tai PHP:tä"; break; Case $words[6]:Case $words[8]: $lopputulos="Javaa"; break; default: $lopputulos="En tiedä! :-D"; } echo "Antamasi koodi oli:<br /><pre style=\"background-color:#E0E0E0;\">".htmlspecialchars($input)."</pre><br /><br />Eikös toi oo ".$lopputulos."?"; ?> <br /><br /> Liitä koodia:<br /> <form action="" method="post"> <textarea name="koodi" rows="5" cols="50" placeholder="Copy-pastea tai kirjoita tähän jokin koodipätkä, niin yritän arvata mikä kieli mahtaa olla kyseessä"></textarea><br /><br /> <input type="submit" value="Tunnista!" /> </form>
Ei kieltä voi tunnistaa minkään sanakirjan mukaan. En viitsi edes kokeilla, koska tiedän, ettei tuosta tule mitään.
Edit: Aika läppä koodi. :D Et kai kirjoittanut tuota tosissasi? Otahan muuten magic_quotes_gpc pois käytöstä.
Jaa, täältä lähtikin viestit välistä. Noh..
Onnea Putkalle :)
Muokkaus. Koittakaa nyt ihmeessä päättää. :D
Petjan huippuetevä koodintunnistaja kirjoitti:
Warning: levenshtein() [function.levenshtein]: Argument string(s) too long in /var/www/virtual/petjatouru.arkku.net/
petjatouru.com/htdocs/foo/kooditunnistin.php on line 17
:(
Liian pitkä koodi sulla. Lyhennä.
Lisäys:
Metabolix kirjoitti:
Aika läppä koodi. :D Et kai kirjoittanut tuota tosissasi? Otahan muuten magic_quotes_gpc pois käytöstä.
Siis, en, en toki. Ajattelin, että Microsoft ostaa oikeudet multa käyttää tota koodia ja myy sitä kalliilla hinnalla eteenpäin. :D
Voin ehkä ottaakin.
Voithan toki luoda kaikki permutaatiot eri ohjelmointikielten kaikista mahdollista lauseista ja verrata sitä syötteenä tulevaan koodiin. Toimii todella tehokkaasti ja käytännöllisesti :D
#include <iostream>
int main () {
std::cout << "Hello, World!" << std::endl;
return 0;
}"Eikös toi oo Javaa?"
-.-
Petja kirjoitti:
Ensinäkin vie aikaa kirjoittaa nuo lipitykset ja sen lisäksi en koskaan muista kumpi tulee ensin lip vai lik (en näet jaksa joka kerta mennä keskustelun ohjeisiin).
listapuu (lip) ja listakohta (lik)
SL-haasteessa sain muuten seuraavanlaista palautetta:
<b>Fatal error</b>: Allowed memory size of 201326592 bytes exhausted (tried to allocate 71 bytes) in <b>.../sl.php</b> on line <b>378</b><br />
Mistäköhän tämä johtuu?
Ihan ehdotuksena tuohon ilman kooditageja kirjoittamiseen, niin eikös siihen kelpaisi vain jokin varoitus, tyyliin "Oletko varma, ettet ole unohtanut käyttää kooditageja?"? Tunnistukseksi riittäisi, jos löytyy vaikkapa pari kertaa if, for tai while. Käyttäjä saa sitten itse valita oikean kooditagin, jos on unohtanut.
Petja kirjoitti:
SL-haasteessa sain muuten seuraavanlaista palautetta:
<b>Fatal error</b>: Allowed memory size of 201326592 bytes exhausted (tried to allocate 71 bytes) in <b>.../sl.php</b> on line <b>378</b><br />Mistäköhän tämä johtuu?
Mitenkään tuntematta koodiasi / käsittelevää scriptiä sanoisin, että olet luultavimminkin tehnyt ikuisen loopin johonkin. Tai sitten jokin muu varaa muistia aivan tolkuttomasti.
[edit]>Eikun olikin SL-haaste[/edit]
Siis kuinka pitkän lausekkeen oletkaan tehnyt?
{ ja } merkit tunnistukseen, varmaan monia pätkiä voisi tunnistaa
hernih kirjoitti:
{ ja } merkit tunnistukseen, varmaan monia pätkiä voisi tunnistaa
Esimerkiksi tuon viestisi.
Tarkoitin lähinnä, että ei se missään nimessä autom. sitä lisäisi vaan esim. js heittäisi jonkun kooditagi valitsimen tuohon.
if( $das > 0 )
{
while( $fasf > $eas )
{
$fs = "";
$fas = $eas + 4;
if( $fas > 2000 ) {
echo "das;
} else {
echo "saasas";
}
}
Tietystihän se pitäisi varmaan heti ekasta { heittää että "NYT ON KOOOODIA SIELLÄ KAVERILLA"??!
Hennkka kirjoitti:
Ihan ehdotuksena tuohon ilman kooditageja kirjoittamiseen, niin eikös siihen kelpaisi vain jokin varoitus, tyyliin "Oletko varma, ettet ole unohtanut käyttää kooditageja?"? Tunnistukseksi riittäisi, jos löytyy vaikkapa pari kertaa if, for tai while. Käyttäjä saa sitten itse valita oikean kooditagin, jos on unohtanut.
Tehokkaampi tapa on jakaa varoitus jokaisesta väärinkäytöksestä ja laittaa automaattisesti esim. päivän bannit vaikkapa kolmesta varoituksesta. Täysin turhaa alkaa koodata niskureiden kaitsemiseksi softaa, joka kuitenkin joko jäisi täyteen reikiä tai veisi liikaa hyödylliseen kehitykseen tarkoitettua aikaa.
Teuro kirjoitti:
Petja kirjoitti:
En laittaisi myöskään vastaan, jos esimerkiksi php-koodissa olevat php:n omat funktiot olisivat linkkejä php.netin dokumentaatioon.
Ai että kirjoittaisi listaan PHP:n 2^samperin_paljon funktiota? Yeah!
No joo onhan toki php:a tietenkin funktio näyttämään mitkä funktiot on käytettävissä, mutta jokaisen sanan käyminen läpi jokaisesta viestistä ennen näyttämistä on mahdollisesti hiukan huono idea?
Minusta tuo ei ole toimintona ollenkaan huono idea. Toisaalla se on jo käytössä. Ollut itse asiassa jo pitkän aikaa, toimii hyvin ja on kätevä.
Säännöllisellä lausekkeella saisi PHP.netin funktiolistasta kaikki funktiot arrayhyn helposti*. Ongelma olisi tietenkin kunkin funktion syntaksi. Ei kaikki funktiot toimi samalla tavalla toistensa kanssa.
* = En osaa säännöllisiä lausekkeita itse
Nyt PHP-funktioiden linkitys on koekäytössä. Linkkejä tulee kyllä myös vääriin paikkoihin (esim. itse määriteltyihin jäsenfunktioihin), mutta tuskin niistä paljon haittaa on. Näiden tilanteiden tunnistus vaatisi merkittävästi tarkempaa analysointia, eikä eroa välttämättä edes voi nähdä, jos koodi ei ole kokonainen. Lisäksi uudet funktiot ja laajennuksiin liittyvät funktiot jäävät linkittämättä, koska PHP luo funktiolistan itse niistä funktioista, joita tällä palvelimella voi käyttää.
Petja kirjoitti:
Ongelma olisi tietenkin kunkin funktion syntaksi.
PHP:ssä on tietääkseni tasan yksi syntaksi funktioiden kutsumiselle.
Metabolix kirjoitti:
Nyt PHP-funktioiden linkitys on koekäytössä.
Hyvä ominaisuus, kunhan pahemmilta ongelmilta vältytään.
Hei, itse olen tehnyt joskus vastaavan funktioiden linkityksen ja tarkistuksen hyödyntämällä mm. tällaista, jolloin ongelma (esim. itse määriteltyihin jäsenfunktiot) poistuu. En tiedä tarkoititko sitä.
En tarkoittanut tuota, vaan tarkoitin tätä:
class Luokka {
function htmlspecialchars() {
// yllä virheellinen linkki
}
}PHP natiiveja funktioita kutsutaan yleensä ilman "function " - etuliitettä ja ilman { - sulkua.
class Luokka {
function htmlspecialchars() {
// yllä virheellinen linkki, jota ei haeta koska se on kayttäjän esittämä. Ihan sama mikä sen nimi on.
}
}htmlspecialchars(); // Natiivin funktion kutsu, hae manuska
Tuleeko sellaista tilannetta että kutsutaan natiivia funktiota, sen 'etuliitteen' ollessa 'function ' - merkkijono? Silloin se on joko fatal error, tai käyttäjän omassa luokassa.?
Et sitten millään tahdo ymmärrä asiaani: vaikka yksittäisiä tapauksia paikattaisiin, täydellistä tarkistusta ei tule. Paikkasin nyt tuon nimenomaisen käyttötapauksen, mutta eräissä muissa (hankalammin tunnistettavissa) vika vielä ilmenee – löydätköhän?
Metabolix kirjoitti:
Et sitten millään tahdo ymmärrä asiaani: vaikka yksittäisiä tapauksia paikattaisiin, täydellistä tarkistusta ei tule. Paikkasin nyt tuon nimenomaisen käyttötapauksen, mutta eräissä muissa (hankalammin tunnistettavissa) vika vielä ilmenee – löydätköhän?
Minähän ymmärsin asiasi täysin? Tarkoittaako täydellisyyden puute mielestäsi sen että ei kannata paikata kaikki voitava? Tuo paikkaamasi "nimenomaisen käyttötapauksen" hän on aika kattava, eikös vain? Tsurigan esimerkki on aivan yhtä helppo tunnistaa. Miksi olet aina niin hysteerinen.?
qeijo kirjoitti:
Tarkoittaako täydellisyyden puute mielestäsi sen että ei kannata paikata kaikki voitava?
Ei ole kysymys siitä, mitä voi tai ei voi paikata. Kaiken voi paikata. Kyse on työmäärästä: jokainen paikkaus mutkistaa väritystä ja vaatii lisää koodia, jotkin 5 riviä, jotkin 20 riviä, jotkin 100 riviä. Minusta esimerkiksi viimeiseksi mainittuja ei erityisesti kannata paikata, koska saavutettava hyöty on varsin mitätön suhteessa työmäärään. Tietenkin tilanne on toinen sitten, jos ei ole mitään parempaa tekemistä.
qeijo kirjoitti:
Tsurigan esimerkki on aivan yhtä helppo tunnistaa.
Onko? Miten tunnistaisit sen? Kirjoitapa huviksesi koodi, joka tunnistaa sen (myös silloin, kun strlen-funktiota ei määritellä tai se määritellään vasta kutsun jälkeen). Sitä paitsi tässä viimeistään törmätään tilanteeseen, jossa virhe todennäköisesti ei ole vältettävissä millään, koska keskusteluun lähetetyt koodit ovat (onneksi) harvoin kokonaisia tiedostoja eli namespace-rivi tai funktiokutsu voivat puuttua lähetetystä koodista.
Metabolix kirjoitti:
Onko? Miten tunnistaisit sen?
Jos ei löytynyt jatka normaalisti, muuten:
Tuoko on sinusta yhtä helppo kuin se, että yksinkertaisesti ohitetaan function-sanaa seuraava sana? Tilannetta vielä heikentää se, että ratkaisusi ei toimi, jos koodista puuttuu osia. (Koko koodia ei yleensä ole järkevää lähettää sivustolle.) Myöskään monen tiedoston koodeihin ratkaisusi ei auta.
Eli ei, tuota ei lähdetä nyt edes yrittämään. Jos ylimääräiset linkit (joita siis tuskin tulee, koska olisi tyhmää nimetä funktiot noin) aiheuttavat itkua, voidaan kyllä poistaa koko linkkitoiminto kaikista nimiavaruuksia sisältävistä koodeista.
Metabolix voisitko laittaa funktiolinkin avautumaan uuteen ikkunaan?
Olli: voithan avata ne itse uuteen täbiin, jos joku vaikka haluaa avatakin ne samaan ikkunaan.
Itse ainakin tykkään kun tiedän mitä linkkiä painaessa tapahtuu. En siis pidä siitä, että sivun tekijä päättää asian puolestani.
Left click -> Linkki avautuu samaan ikkunaan
Middle click -> Linkki avautuu uuteen tabiin
Shift + Left click -> Linkki avautuu uuteen ikkunaan
Metabolix kirjoitti:
Tuoko on sinusta yhtä helppo kuin se, että yksinkertaisesti ohitetaan function-sanaa seuraava sana?
Ei ole, olet oikeassa sen suhteen että on kohtuuton vaiva hyötyyn nähden.
Jaa,jotenkin tuntuu vain loogisemmalta että sivuston ulkopuoliset linkit avautuvat uudessa ikkunassa. Miten muuten saa pois tuon "Sinulle on yksi viesti, lue!" jos on jo lukenut viestin?
Kas kun eivät ole tuollaista loogisuutta huomanneet esim. Googella, Wikipediassa, Microsoftilla...
Olli kirjoitti:
Miten muuten saa pois tuon "Sinulle on yksi viesti, lue!" jos on jo lukenut viestin?
Napsauta sitä Poista -painiketta.
Kuuluisiko DELETE-komento sql-tageissa korostaa? Entä ABS()
DELETE taulux FROM taulux WHERE ABS(taulux.x) = TIME(0);
EDIT: Näköjään tuon Deleten pistitte toimimaan. Miksi ABS() ei ole lihavoitu, kun muita funktioita on, kuten esim. TIME()?
@ErroR++
Aha sellainenpa löytyi,kiitos!
tkok kirjoitti:
Miksi ABS() ei ole lihavoitu, kun muita funktioita on, kuten esim. TIME()?
Funktioita ei ole lihavoitu eikä ole tarkoituskaan lihavoida. Esimerkiksi TIME on lihavoitu siksi, että se on tietotyyppi. Nyt DATE ja TIME yritetään jättää lihavoimatta, jos perässä on sulku.
Onko olemassa yliviivaustoimintoa?
Ei ole. Toki sellaisen voisi lisätä, mutta niin hauskoja kuin muotoilut ovatkin, minusta on selvempää kirjata poistot tarvittaessa erikseen. Yliviivaus ei ole kovin luonteva osa asiallista tekstiä. (Lisäksi se varmaan aiheuttaa hämmennystä tekstiselaimilla tai ruudunlukijoilla.)
Sellainen tuli mieleen, että onko tuolla kun ava oman profiilin, niin missään linkkiä, josta näkisi kaikki omat aiheet, ja jos ei, niin voisiko sellaista saada? Se olisi mielestäni kätevä, sillä on monesti tullu tarve etsiä omaa aihetta, jossa käsiteltiin jotain tiettyä asiaa, ja on hirveen työlästä lähteä penkomaan sitä kymmenien tai satojen muiden aiheiden seasta itse foorumilta.
dartvaneri: Keskustelun haussa voi laittaa hakuehdoksi myös kirjoittajan eli tuollaista ominaisuutta ei suoranaisesti tarvitse.
sqwiik kirjoitti:
dartvaneri: Keskustelun haussa voi laittaa hakuehdoksi myös kirjoittajan eli tuollaista ominaisuutta ei suoranaisesti tarvitse.
Ominaisuus on jo olemassa, mutta dartvaneri vain halusi linkkiä, jolla kyseisen ominaisuuden voi ottaa helpommin käyttöön.
Ahaa, The Alchemist arvelee, etten tiedä, että ohjelmointiputkassa on hakukin, noh arvele mitä tykkäät. Kuitenkin itse tykkään enemmälti sellaisesta listasta, mutta olkoot, jos näette sen turhaksi. Hakuhan ei tee suoranaisesti listaa käyttäjän luomia aiheista.
Hei,
Olen käynyt läpi Ohjelmointiputkan opas-sarjaa (PHP). Haluaisin tietää miksi malleissa on käytössä tageja kuten <br> eivätkö tällaiset merkinnät ole vanhentuneet.. Missä <br /> ?
Toinen asia, ovatko oppaan esimerkit ajantasalla, koska haluaisin aloittaa koodaamaan mallejen opettamalla tyylillä esim. PDO (tietokantayhteyden avaaminen).. Mukavan simppeli koodinpätkä...
Muuten upeaa settiä, thänks!!
latenleffahylly kirjoitti:
Olen käynyt läpi Ohjelmointiputkan opas-sarjaa (PHP). Haluaisin tietää miksi malleissa on käytössä tageja kuten <br> eivätkö tällaiset merkinnät ole vanhentuneet.. Missä <br /> ?
latenleffahylly: katoppa aina niistä oppaista päivämäärä niin selviää miksi ne "vanhentuneet" tägit on käytössä.
Lebe80, katso itse päivämäärä, opassarjahan vasta uudistettiin. (Edit: keskustelua asiasta.)
<br> ei ole millään tavalla vanhentunut eikä <br/> ole mitenkään sitä korvannut, vaan kyse on kahdesta eri merkintätavasta, joista ensimmäinen on HTML:ää ja jälkimmäinen XHTML:ää eli XML:ää. HTML5 sallii molemmat.
PDO-koodi on periaatteessa ajan tasalla, mutta itse suosittelen globaalin muuttujan sijaan kuitenkin selvempää ja vähemmän ongelmia aiheuttavaa funktioratkaisua.
no niinpä tietenkin. Oletin heti että ne on niitä samoja oppaita mitä on aina ollut.
Kiinnostavaa.. Tuota voiko oppaaseen vaihtaa esimerkin miten tietokantayhteys avataan, nykytavalla??
Haluaisin tehdä asiat oppaan tavalla, olen nyt 3 päivää käynyt läpi, mutta en haluaisi opetella väärien esimerkkien kautta. Jokatapauksessa upeaa jälkeä ja varmasti paljon työtä tehty opas-sarjan eteen.
................
Valitan vain siksi että yhteyden avaaminen äärimmäisen tärkeä kohta PHP koodissa.
No eikö siinä kerrota että nykyään kannattaa käyttää PDOta ja olihan siinä vielä koodiesimerkkikin? Oma PHP-skriptini toimii ihan mainiosti ja suorittaa hienosti kirjautumisen ja uloskirjautumisen.
latenleffahylly kirjoitti:
Kiinnostavaa.. Tuota voiko oppaaseen vaihtaa esimerkin miten tietokantayhteys avataan, nykytavalla??
Asia ei ole niin, että oppaan tapa olisi "vanha tapa" ja Metabolixin tapa olisi "uusi tapa". Molemmat tavat ovat hyviä, ja kumpaa tahansa käyttämällä tulee toimiva koodi.
Miksi sitten on kaksi tapaa? Omasta mielestäni oppaan tapa on parempi (en muuten olisi kirjoittanut sitä niin), ja Metabolixin mielestä hänen tapansa on parempi. Tämä on ihan tavallinen ilmiö ohjelmoinnissa: eri henkilöt ovat eri mieltä siitä, mikä on tyylikästä, helppoa jne.
MySQL:n kehittäjäthän vähän vitsailevat sillä, että PDO on "lähtökohtaisesti rikki" (eng. "broken by design"): http://schlueters.de/presentations/
Ok, kiitos näistä tiedoista, luotan oppaaseen, vaikka olen kyllä huomannut että Ei ole sellaista kysymystä, johon Metabolix ei tietäisi vastausta.
Tässä syystä ajattelin että oppaassa vanhaa tietoa, kuten nuo br jutut.. Eli sekin tuli selväksi miten HTML5 tagit tulkitsee. Yhteenvetona hieno opas, vaikkakin olio-ohjelmointi meni omalla kohdalla liian vaikeaksi. Php opas avaa koodin saloja eli mihin kaikkeen se soveltuu.. Tämä oli hienoa.
Itse käytän wordpressiä, joten esim. Vieraskirjan tekisin lisäosan avulla en koodilla.. Thänks!
latenleffahylly kirjoitti:
...vaikka olen kyllä huomannut että Ei ole sellaista kysymystä, johon Metabolix ei tietäisi vastausta.
Muista, että myös ohjelmoinnissa on paljon kysymyksiä, joita voidaan pitää mielipidekysymyksinä.
dartvaneri kirjoitti:
latenleffahylly kirjoitti:
...vaikka olen kyllä huomannut että Ei ole sellaista kysymystä, johon Metabolix ei tietäisi vastausta.
Muista, että myös ohjelmoinnissa on paljon kysymyksiä, joita voidaan pitää mielipidekysymyksinä.
Jotkut voivat myös osata käyttää Googlea.
latenleffahylly kirjoitti:
Yhteenvetona hieno opas, vaikkakin olio-ohjelmointi meni omalla kohdalla liian vaikeaksi.
Alku voi olla hankalaa.... oikeastaan nuo on aika helppoja. Mutta odotas, kun alat tekemään ohjelmia pelkkiä olioita käyttäen :)
dartvaneri kirjoitti:
latenleffahylly kirjoitti:
...vaikka olen kyllä huomannut että Ei ole sellaista kysymystä, johon Metabolix ei tietäisi vastausta.
Muista, että myös ohjelmoinnissa on paljon kysymyksiä, joita voidaan pitää mielipidekysymyksinä.
Todellakin. Ja, paitsi mielipiteistä, valittava toteutustapa riippuu usein myös siitä mitä ja miten ollaan tekemässä. Pienissä ja lyhyen elinkaaren projekteissa voidaan ehkä oikoa vähän suunnittelussa, mutta isommissa ja pidemmän elinkaaren ohjelmissa on tärkeää kiinnittää huomiota suunnitteluun jo alusta alkaen.
Kannattaa aina suhtautua kriittisesti ja kiinnttää huomiota perusteluihin pelkän "toimivan" koodin kopioimisen sijaan. Metabolixilla on hyviä perusteluja siihen miksi hänen funktioratkaisunsa tietokantayhteyden hallintaan on parempi kuin Antin oppaassa esitetty ja olen niistä samaa mieltä. Silti minusta myös se on huono vaihtoehto mm. seuraavista syistä:
- globaali funktio saastuttaa globaalia nimiavaruutta
- ei mahdollista php:n autoload-tominnallisuuden hyödyntämistä vaan funktio pitää tuoda aina manuaalisesti mukaan sinne missä sitä halutaan käyttää
- singleton ohjaa helposti piilevien ja hankalasti hallittavien riippuvuuksien luomiseen koodiin (Metabolixin ratkaisu on käytännössä singleton)
- hankalasti konfiguroitavissa
- ei mahdollista useamman tietokantayhteyden luomista
Tukki kirjoitti:
- ei mahdollista useamman tietokantayhteyden luomista
Siis mikä ei tuota mahdollista?
Tukki kirjoitti:
Silti minusta myös se [Metabolixin funktioratkaisu] on huono vaihtoehto mm. seuraavista syistä: ...
En ole väittänyt, että ratkaisu olisi ideologisesti täydellinen. Funktioni on tarkoitettu idioottivarmaksi ratkaisuksi aloittelijalle, joka haluaa käyttää sitä webhotellinsa ainokaista tietokantaa muttei osaa selvittää yksinkertaistakaan virhetilannetta itse. En usko, että siihen käyttöön pystyt tarjoamaan mitään parempaa. "Prove me wrong."
Globaali funktio on lähes mahdoton rikkoa: se on heti kaikkialta käytettävissä eikä sitä voi vahingossa poistaa, ylikirjoittaa tai monistaa. Globaalin luokan staattinen metodi on näiltä osin yhtä hyvä ja mahdollistaa lisäksi autoloadin, mutta sen koodi on myös marginaalisesti mutkikkaampi, varsinkin autoloadin kanssa. Globaalin muuttujan taas voi vahingossa ylikirjoittaa tai alustaa moneen kertaan, ja muuttujan käyttö funktiossa vaatii erillisen global-lauseen.
Aloittelija ei tarvitse autoloadia, konfigurointia eikä useaa tietokantayhteyttä, ja on turha odottaa, että hänen koodinsa olisi missään tilanteessa modulaarista ja "riippumatonta" tai että hän välittäisi tippaakaan globaalin nimiavaruuden sisällöstä. Jos tarpeet kasvavat, pitää opetella koodaamaan paremmin, ja jos osaa koodata hyvin, voi sitten tehdä oman, paremman tietokantaratkaisun.
Tukki kirjoitti:
singleton ohjaa helposti piilevien ja hankalasti hallittavien riippuvuuksien luomiseen koodiin
Näkisinpä mielelläni, onko oma koodisi muka aina tai edes yleensä tehty niin, että tietokantayhteys luodaan konfiguraatiotiedoston mukaan paikalliseen muuttujaan ja kuljetetaan kaikkialle parametrina. Kerro myös, onko tästä joskus ollut sinulle käytännön hyötyä tai millaisiin ongelmiin singletonit ovat johtaneet.
Tukki kirjoitti:
globaali funktio saastuttaa globaalia nimiavaruutta
Millä tavalla funktio saastuttaa enemmän kuin globaalissa nimiavaruudessa oleva luokka tai nimiavaruus?
Metabolix kirjoitti:
Tukki kirjoitti:
Silti minusta myös se [Metabolixin funktioratkaisu] on huono vaihtoehto mm. seuraavista syistä: ...
En ole väittänyt, että ratkaisu olisi ideologisesti täydellinen. Funktioni on tarkoitettu idioottivarmaksi ratkaisuksi aloittelijalle, joka haluaa käyttää sitä webhotellinsa ainokaista tietokantaa muttei osaa selvittää yksinkertaistakaan virhetilannetta itse. En usko, että siihen käyttöön pystyt tarjoamaan mitään parempaa. "Prove me wrong."
En sitä epäilekään ettetkö itse tunnistasi esimerkkisi puutteita. Tarkoitus oli lähinnä kritisoida latenleffahyllyn tapaa ottaa se jotenkin yleisestiottaen "oikeana ratkaisuna" ja tuoda esiin että siinäkin on mahdollisia puutteita joissain mahdollisissa konteksteissa sekä sanoa että järkeviä toteutustapoja voi olla useita riippuen mielipiteistä ja tilanteista. Tuohon aloittelijakontekstiin esimerkkisi on varmaan aika optimaalinen. En osaa keksiä muuta helppoa parannusta kuin että käärisi funktion luokan sisään, jolloin sen käyttö olisi aivan yhtä helppoa, muuta lajentaminen (autoload, konfigurointi, namespacet) olisi myöhemmin osaamisen kartuttua helpompaa.
Metabolix kirjoitti:
Globaali funktio on lähes mahdoton rikkoa: se on heti kaikkialta käytettävissä eikä sitä voi vahingossa poistaa, ylikirjoittaa tai monistaa. Globaalin luokan staattinen metodi on näiltä osin yhtä hyvä ja mahdollistaa lisäksi autoloadin, mutta sen koodi on myös marginaalisesti mutkikkaampi, varsinkin autoloadin kanssa. Globaalin muuttujan taas voi vahingossa ylikirjoittaa tai alustaa moneen kertaan, ja muuttujan käyttö funktiossa vaatii erillisen global-lauseen.
Globaali funktio on helppo rikkoa kirjoittamalla itse vahingossa uusi saman niminen tai tuomalla projektiin ulkoinen kirjasto, jossa on määritelty saman niminen funktio. Muuten olen samaa mieltä, niinkun sanoin, esimerkkisi on parempi kuin Antin oppaassa oleva tapa johon se tuo pienellä ja helpolla vaivalla isoja parannuksia.
Metabolix kirjoitti:
Aloittelija ei tarvitse autoloadia, konfigurointia eikä useaa tietokantayhteyttä, ja on turha odottaa, että hänen koodinsa olisi missään tilanteessa modulaarista ja "riippumatonta" tai että hän välittäisi tippaakaan globaalin nimiavaruuden sisällöstä. Jos tarpeet kasvavat, pitää opetella koodaamaan paremmin, ja jos osaa koodata hyvin, voi sitten tehdä oman, paremman tietokantaratkaisun.
Niinpä. Yksi askel oppimiseen on huomata että ei ole olemassa yhtä oikeaa ratkaisua, vaan työkalut ja menetelmät voi valita tilanteen mukaan.
Metabolix kirjoitti:
Tukki kirjoitti:
singleton ohjaa helposti piilevien ja hankalasti hallittavien riippuvuuksien luomiseen koodiin
Näkisinpä mielelläni, onko oma koodisi muka aina tai edes yleensä tehty niin, että tietokantayhteys luodaan konfiguraatiotiedoston mukaan paikalliseen muuttujaan ja kuljetetaan kaikkialle parametrina. Kerro myös, onko tästä joskus ollut sinulle käytännön hyötyä tai millaisiin ongelmiin singletonit ovat johtaneet.
Tämä on hankalampi, vastaan myöhemmin...
Metabolix kirjoitti:
Tukki kirjoitti:
globaali funktio saastuttaa globaalia nimiavaruutta
Millä tavalla funktio saastuttaa enemmän kuin globaalissa nimiavaruudessa oleva luokka tai nimiavaruus?
Sillä tavalla että globaaliin luokkaan saa yhden loogisen prefiksin alle useita funktioita. Toki globaaleja funtioitakin voi keinotekoisesti prefiksata, mutta nimiavaruudet on juuri siksi ettei tarvitse. Nimiavaruuksia järkevästi käyttämällä törmäyksen todennäköisyys on jo melko pieni ja lisäksi ne toimivat hyvin autoloadin kanssa ja luokkien ja funktioiden nimet pysyvät järkevinä.
Ok, olemme siis asioista suunnilleen samaa mieltä. :)
Tukki kirjoitti:
Globaali funktio on helppo rikkoa kirjoittamalla itse vahingossa uusi saman niminen tai tuomalla projektiin ulkoinen kirjasto, jossa on määritelty saman niminen funktio.
Tämä kyllä pätee teknisesti myös luokkiin ja nimiavaruuksiin, esimerkiksi luokka nimeltä DatabaseConnection on yhtä törmäysaltis kuin funktio db. Koko projektin kattavalla nimiavaruudella toki törmäysriskistä tulee olematon, mutta tämä on jälleen ehkä aloittelijalle mahdoton ratkaisu, koska nimiavaruudet eivät ehkä ole monissa halvoissa webhotelleissa vieläkään käytössä eikä niiden käyttöä opeteta monissa oppaissa lainkaan.
Metabolix kirjoitti:
Näkisinpä mielelläni, onko oma koodisi muka aina tai edes yleensä tehty niin, että tietokantayhteys luodaan konfiguraatiotiedoston mukaan paikalliseen muuttujaan ja kuljetetaan kaikkialle parametrina. Kerro myös, onko tästä joskus ollut sinulle käytännön hyötyä tai millaisiin ongelmiin singletonit ovat johtaneet.
Ei toki ole läheskään aina, mutta nykyään yleensä pyrin siihen, jos näen että siitä voi olla hyötyä nyt tai tulevaisuudessa vaikka se onkin usein hankalaa. Tässä muutama mieleentuleva esimerkki, missä singleton voi olla ongelmallinen. Nämä on ehkä 70%:sti todellisia ja 30%:sti keksittyjä.
- Tietokantayhteyden tapauksessa, jos esimerkiksi tehdään migraatio-ohjelmaa, joka lukee dataa yhdestä kannasta ja kirjoittaa toiseen, singleton ei toimi kun se palauttaa aina saman yhteyden. Toki tämä voidaan kiertää tekemällä kaksi eri singleton-toteutusta, jotka palauttavat eri yhteyden, mutta se haiskahtaa vähän purkalta. Monesti tuo voi olla riittävä oikaisu koska migraatio-ohjelmat on usein kertakäyttöisiä.
- Toinen reaalimaailman esimerkki voisi olla vaikka seuraava. Oletetaan että minulla on ohjelma, jonka osana on monitorointi-luokka, joka tutkii onko ohjelma tietyssä tilassa, ja jos on, lähettää tästä tekstiviestin tiettyyn numeroon. Ohjelmaa käyttää asiakkaat A ja B identtisillä mutta erillisillä asennuksilla (sama lähdekoodi). Minulla on myös sopimus SMS-gateway-tarjoajan X kanssa, jonka kautta saan hyvät katteet A:n ja B:n lähettämistä tekstiviesteistä. Tässä tilanteessa monitorointiluokassa voitaisiin käyttää singletonia sanomalla jotain tyyliin SMSSender::getInstance()->send($msg, $number); ja homma toimisi hyvin. Sitten minulle tuleekin mahdollisuus tarjota ohjelmaa palveluna myös asiakkaalle C, mutta he vaativat että saavat käyttää tarjoajan Y SMS-gatewayta koska C:n toimari tuntee Y:n toimarin ja saa sieltä hyvän hinnan. Y:llä voi myös olla tarjolla oma valmis luokka heidän gatewaynsä käyttämiseen, mutta se alustetaan aivan eri tavalla kuin tuo oma SMSSender:ini ja sen käyttöönotto vaatii väistämättä tuon monitorointiluokan refaktorointia enemmän tai vähemmän. Jos taas olisin alusta asti suunnitellut monitorointiluokan niin, että sille annetaan parametrina SMSSenderInterface-rajapinnan toteuttava olio, niin minun ei tarvitsisi koskea siihen tämän muutoksen takia. Voisin laajentaa tuota Y:n tarjoamaa luokkaa omalla luokallani niin että saan sen toteuttamaan tuon tarvittavan rajapinnan ja käyttää tätä luokkaa suoraan monitorointiluokan kanssa C:n asennuksessa. Parhaimmillaan tuo valinta käytettävästä SMS-gatewaysta voitaisiin tehdä asiakaskohtaisessa konfiguraatiossa ja alustettu olio haettaisiin factory-luokalta tai di-containerista, jonka jälkeen sitä käsiteltäisiin vain rajapinnan kautta eikä koodissa edes tarvitsisi tietää minkä gavewayn kautta viestit lähtee. Samoin uusia gatewayta lisättäessa olemassaolevaan koodiin ei tarvitsisi koskea lainkaan.
- Kolmas esimerkki on ehkä tyypillisin. Yksikkötestauksessa singleton-patternia on hankala tai mahdoton korvata mock-olioilla muuttamatta varsinaista koodia. Parametrina annetut oliot taas voi lähes aina korvata vastaavilla mock-toteoutuksilla.
Tukki kirjoitti:
Tietokantayhteyden tapauksessa, jos esimerkiksi tehdään migraatio-ohjelmaa, joka lukee dataa yhdestä kannasta ja kirjoittaa toiseen, singleton ei toimi kun se palauttaa aina saman yhteyden.
Kuten itsekin sanoit, tämä ohjelma on tyypillisesti kertakäyttöinen, joten tyylikkyydellä ei ole väliä ja hieno toteutus tuskin säästää sekuntiakaan. Jos ja kun migraatiossa käytetään vanhan ja uuden järjestelmän natiiveja luokkia ja näissä on törmäys, tilanteen voi yleensä pelastaa yhdellä sed-skriptillä. Toisaalta usein migraatio tehdään myös yhden palvelimen sisällä, jolloin ei välttämättä tarvitakaan kuin yksi yhteys.
Tukki kirjoitti:
Yksikkötestauksessa – –
– – voi käyttää ihan todellista tietokantaa. Tässä toki tarvitaan aiemmin mainittu konfigurointimahdollisuus, jotta testit eivät sotke tuotantokantaa.
Tukki kirjoitti:
SMSSender::getInstance()
Ehkä muotoilin kysymyksen epäselvästi, mutta tarkoitin edelleenkin vain tietokantayhteyksiä. Tietenkin ongelmia tulee, jos siirrytään muihin aihepiireihin. Miten järkevältä kuulostaisi vaikka Käyttäjä::getInstance()?
Näin lähtökohtaisesti singletoneja (globaaleja) tulisi välttää kuin ruttoa. Eräs hauska esimerkki aiheesta sattui kun joku joskus oli käyttänyt juuri tietokantayhteydessään singletonia. No, sitten joskus tuli tarvetta läimäyttää lukeminen ja kirjoittaminen eri paikkoihin, ja singleton luontaisesti iski tilanteessa polveen.
Mielestäni hauskan tästä esimerkistä teki, että kehittäjä ei tuosta lannistunut, vaan päivitti tämän singletoninsa sisältämään uuden getterin - getInstance2() tjms, joten loiko hän nyt sitten kokonaan uuden termin alalle "doubleton" :D
En nyt ota kantaa onko singleton juuri sen ja sen tilanteen käytössä ongelmallinen, mutta joka tapauksessa singleton on pohjimmiltaan "broken by design", ainakin PHP/webbimaailmassa (vaikka se ei kaikissa tapauksissa osoittautuisikaan ongelmalliseksi). Helposti tulee myös kirjoitettua "tightly coupled" koodia singletonien takia, mikä on tapauksessa kuin tapauksessa iso miinus.
Metabolix kirjoitti:
Tukki kirjoitti:
Yksikkötestauksessa – –
– – voi käyttää ihan todellista tietokantaa. Tässä toki tarvitaan aiemmin mainittu konfigurointimahdollisuus, jotta testit eivät sotke tuotantokantaa.
Tästä ei selviä pelkällä tietokantakonfiguraation muutoksella, koska et saa eristettyä koodistasi tätä DB::getInstance() tjms. kohtaa, mikä juuri pitäisi pystyä korvaamaan mockilla (oletin, ja kaikesta päätellen tässä oli juuri kyseessä että koodissa olisi kovakoodattuna DB::getInstance).
Olen timoh:n kanssa täysin samaa mieltä. Singletoneja tulisi lähtökohtaisesti pyrkiä välttämään juuri tuon "tightly coupled"-koodin takia, vaikka kehityshetkellä se tuntuisikin turhalta ylisuunnittelulta.
Tuossa yksikkötestaustapauksessa pelkkä konfiguraation muuttaminen ohjaamaan kyselyt testikantaan ei riitä ellei sitten ole tarkoitus yksikkötestata nimenomaan kantayhteyttä, mutta siitä ei nyt ollut kysymys. Jos tarkoitus on testata jotain funktiota, joka vain hakee kannasta jotain ervoja ja tekee niiden perusteellaa jotain, mockaamalla kantayhteys saadaan siinä mahdollisesti esiintyvät bugit eliminoitua testin ulkopuolelle. Voi myös olla että oikeaa kantayhteyttä ei ole saatavilla, jos vaikka tuotannossa käytetään kallista oracle-kantaa, josta ei ole raskittu hankkia lisenssejä kaikille kehitys- ja testauskoneille.
Tavoitteeni oppaissa on esitellä uudet asiat mahdollisimman yksinkertaisessa mutta toimivassa muodossa. Jos tietokannan avaamisen toteuttaisi funktiona tai luokkana, niin lukijan olisi selvästi vaikeampaa ymmärtää ja soveltaa koodia.
Tietokannan käyttäminen globaalin muuttujan kautta on käytännössä erittäin toimiva ratkaisu. Mielestäni tässä vaiheessa ei kannata huolehtia laajoihin järjestelmiin liittyvästä oliosuunnittelusta. Enhän tarjoa oppaissa myöskään matemaattista analyysia esimerkkien oikeellisuudesta ja aikavaativuuksista.
Parannusehdotuksista puheen ollen, näitä foorumin käyttämiä osoitteita voisi ainakin kaunistella -- jos ei muuten, niin vain inspiraation lähteeksi orastaville web-kehittäjille. Kaikkihan varmasti myöntävät (<- liioittelu), että nämä paljaat GET-parametrit ovat aika ysäriä (<- kärjistys), ja olisihan vaihtoehtoinen esitysmuoto nätimpi (<- mielipiteen esittäminen faktana):
/keskustelu/aihe.php?id=26051&sivu=2
vrt.
/keskustelu/ohjelmointiputka/parannusehdotuksia/
(Keskustelualueen sisällyttäminen osoitteeseen vaihtoehtoista.)
Tässäkin asiassa on toki vähintään ne 2 koulukuntaa, joista toinen ehkä suosisi seuraavaa:
/keskustelu/ohjelmointiputka/parannusehdotuksia-2.html
(Päällekkäisyyksien käsittelystä tuskin tarvitsee tehdä mitään turhan monimutkaista. Jos tällainen hapatus joskus toteutettaisiin, nykyisiä osoitteita ei tulisi rikkoa.)
Ehkäpä joku, jonain päivänä jättää ihan tällaisesta muutoksesta valaistuneena käyttämättä osoitetta weppi.sivu/content.cgi?id=0xAFD kun tarve oli oikeastaan kirjoittaa weppi.sivu/ploki.
Mutta eikös staattisetkin sivut pidä tehdä tottelemaan osoitteita muotoa index.php?sivu=sivu, jotta kaikki näkee, että nyt on koodattu jotain palvelinpäähänkin? ;)
Tai helpoin tapa olisi säilyttää nykyiset yksilöivät numerot, juuri päällekkäisyyksien ehkäisemiseksi:
/keskustelu/26051/parannusehdotuksia/2
eq kirjoitti:
Ehkäpä joku, jonain päivänä jättää ihan tällaisesta muutoksesta valaistuneena käyttämättä osoitetta weppi.sivu/content.cgi?id=0xAFD kun tarve oli oikeastaan kirjoittaa weppi.sivu/ploki.
Älä nyt sotke kahta täysin erilaista asiaa. Tietenkin on hölmöä välittää GET-parametrina sivuston osan nimi, kun olisi yleensä viisaampaa (myös teknisen toteutuksen kannalta) laittaa eri toiminnot eri tiedostoihin. Logiikka on rikki, jos sama kooditiedosto tuottaa eri parametreilla aivan erilaisia sivuja. Sen sijaan on täysin loogista ja järkevää välittää GET-parametrina id, jota käytetään tietokantakyselyssä. Sama koodi tuottaa silloin toiminnallisesti täysin samanlaisia sivuja, ja vain sisältö (teksti) vaihtuu. Tyylistä voi toki kiistellä.
Pelkällä otsikolla ilman id:tä ei voi täällä pelata, koska nytkin keskustelussa on 1479 ei-uniikkia otsikkoa (koko sivustolla 2336, kun lasketaan myös poistoalue, oppaat ja koodivinkit).
Astetta tyylikkäämmät osoitteet ovat nyt kuitenkin testikäytössä ja tulevat sitten aikanaan yleiseen käyttöön, ellei yllättäviä ongelmia ilmene.
Parannusehdoitus:
Mites olisi jos nuo pitkät viestit olisi automaattisesti pituus rajoitettuja, jos ne eivät ole ketjun viimisiä viestejä. Esim kun selaa tuota tämän hetkistä Canvas space invaders, niin siinä joutuu selaamaan aika pitkästi alaspäin kunnes pääsee viimeiseen viestiin.
Tietty jos kaksi viimeistä viestiä on pitkiä niin voi menettää jotain, tai joutuu painamaan näytä koko viesti nappia tms.
Synomi kirjoitti:
Esim kun selaa tuota tämän hetkistä Canvas space invaders, niin siinä joutuu selaamaan aika pitkästi alaspäin kunnes pääsee viimeiseen viestiin.
Paina endiä näppikseltä?
Synomi kirjoitti:
Parannusehdoitus:
Mites olisi jos nuo pitkät viestit olisi automaattisesti pituus rajoitettuja, jos ne eivät ole ketjun viimisiä viestejä. Esim kun selaa tuota tämän hetkistä Canvas space invaders, niin siinä joutuu selaamaan aika pitkästi alaspäin kunnes pääsee viimeiseen viestiin.Tietty jos kaksi viimeistä viestiä on pitkiä niin voi menettää jotain, tai joutuu painamaan näytä koko viesti nappia tms.
Mikäs parannusehdotus tuo on? Sehän vain huonontaa. Jos haluat tuollaisen toiminnon, niin vertaa sitä sähköpostiohjelman toimintaan. Eli pitkiä keskusteluja on erittäin hidas lukea, jos "jokainen viesti on omassa näkymässä".
Nykytekniikan ansiosta ei ole mitään haittaa, että nettisivu on vaikka "äärettömän" pitkä, voit huomata uudistuksen vaikka nykyaikaisilta sivuilta, joiden pituus on nykyään erittäin pitkä. Eli nykyinen viestimäärä/sivu on aivan hyvä.
Onkohan muuten millään foorumilla käytössä esim. Googlen kuvahaun (ja monen muun sivun) tyylistä ratkaisua, jossa sisältöä ladataan sitä mukaa lisää kun käyttäjä skrollaa alas. Ei siis tarvitse tehdä ollenkaan perinteistä sivuihin jakoa.
Samaa näyttää olevan myös esim. Sampo Pankin iPhone-sovelluksessa. Tilitapahtumia ladataan lisää jos käyttäjä skrollaa pidemmälle.
Toki keskustelussa on se haittapuoli, että viestien järjestys täytyisi muuttaa käänteiseksi tai sitten keksiä miten homma toimisi järkevästi selaimessa ylös skrollattaessa.
Lähinnä tarkotin niitä koodi osioita, että ne olis rajoitettu(eli sama ko painaa nyt sitä rajota koodia nappia tms), tuskin niitä moni lukee läpi jos niiden jälkeen on samantapasia monen sivusia koodi pätkiä 5 lisää.
Tietty tuo End-nappi on suhkot vaivaton tapa päästä sivun loppuun juu.
Synomi kirjoitti:
Lähinnä tarkotin niitä koodi osioita, että ne olis rajoitettu
Oletko koskaan harkinnut, että voisit itse laittaa ne asetuksista (tällä hetkellä profiilisivulta) lyhennetyiksi?
Metabolix kirjoitti:
Synomi kirjoitti:
Lähinnä tarkotin niitä koodi osioita, että ne olis rajoitettu
Oletko koskaan harkinnut, että voisit itse laittaa ne asetuksista (tällä hetkellä profiilisivulta) lyhennetyiksi?
No joo olisihan tuo osittain ratkaisu tuohon, tiennyt että edes voi laittaa päälle.
Uudet SEO-ystävälliset urlit ovat melko sekavat.
Voisiko muuttaa näin:
/keskustelu/26051/Parannusehdotuksia
--> /keskustelu/26051-Parannusehdotuksia/2
Oppaissa pitäisi erottaa alaotsikko ja yläotsikko osoitteessa. Koodivinkeissä edelleen normaalit osoitteet?
Metabolix kirjoitti:
Tyylistä voi toki kiistellä.
Tyylistähän tässä juuri "kiistellään".
Metabolix kirjoitti:
Pelkällä otsikolla ilman id:tä ei voi täällä pelata, koska nytkin keskustelussa on 1479 ei-uniikkia otsikkoa (koko sivustolla 2336, kun lasketaan myös poistoalue, oppaat ja koodivinkit).
1479 ei suoraan tarkoita, ettäkö id:ttä pelaaminen olisi mahdotonta, mutta kyllähän siinä käytännöllisyys joutuu kyseenalaiseksi.
Henk.koht. suosikkini formaatiksi (id:n kanssa) olisi /keskustelu/id-otsikko-jossa-välejä/# tai /keskustelu/id/Otsikko, jossa välejä/# (hui). Miksikö? Jaa-a. Melkein kaikilla on varmasti vastaavasti omat suosikkinsa, joten näistä en ala väittelemään ;)
Mielestäni jos jotain uutta osoitteisiin, niin tylliin:
/keskustelu/26051/2, kaikkein selkein, ei mitään tekstejä tonne osoiteriville, kamalan näköistä. Esim:
/keskustelu/26335-jQueryn_show%28%29_ja_hide%28%29_ei_toimi_IE_ss%C3%A4/sivu-1
Kun osoite voisi olla:
/keskustelu/26335/1
Onko ehkä hieman selkeämpää?
Keskustelujen otsikoiden käyttö sellaisenaan on minustakin aika rumaa. Tuo dartvanerin pelkistetty versio olisi ihan ok, mutta eq:n ensimmäinen ehdotus jossa titlestä on tehty slugi on minusta paras. Esim:
/keskustelu/26335-jqueryn-show-ja-hide-ei-toimi-IE-ssa/1
dartvaneri kirjoitti:
Mielestäni jos jotain uutta osoitteisiin, niin tylliin:
/keskustelu/26051/2, kaikkein selkein, ei mitään tekstejä tonne osoiteriville, kamalan näköistä. Esim:
/keskustelu/26335-jQueryn_show%28%29_ja_hide%28%29_ei_toimi_IE_ss%C3%A4/sivu-1
Kun osoite voisi olla:
/keskustelu/26335/1
Onko ehkä hieman selkeämpää?
Ideahan näissä kokeiltavissa osoitteissa on juurikin se, että itse osoitteestakin jo näkisi vihjeitä siitä, mitä se voisi sisältää. Eihän tuo URL minkään edes etäisesti modernin selaimen osoiterivillä ole mahdottoman epäselvä -- rumuudesta voi väitellä -- ja noin ohimennen, samaa URL-escape-sarjojen dekoodausta voisi käyttää myös 'putkan keskustelun linkeissä (parannusehdotus!). Tämä ei tietysti auta muualla, mutta tarvittaessa tuon ID:n jälkeisen osan voi nytkin jättää pois, se on täysin valinnainen (erottavaa väliviivaa myöten), kuten varmaan itsekin huomasit.
Ja nuo otsikot löytyy osoitteesta myös hakukoneoptimoinnin takia.
SEF-urlit on hakukoneiden lisäksi myös ihmisiä varten.
eq, linkkien siistiminen olikin jossain vaiheessa käytössä, mutta ilmeisesti siitä tuli jokin ongelma, koska otin sen pois. Kokeillaan nyt kuitenkin uudestaan muistin virkistämiseksi.
Olli, ehdottamasi muutos linkin tehtiin jo sunnuntaina, joten on turha spammata siitä vielä sähköpostiinkin. Ääkköset kuitenkin aion pitää ääkkösinä, ellei joku esitä hyvää perustelua muutokselle.
Lebe80 kirjoitti:
SEF-urlit on hakukoneiden lisäksi myös ihmisiä varten.
Samaa mieltä. Jos vie hiiren linkin päälle, selkeästä osoitteesta osaa arvata, mitä linkin takana on. Esim. Tästä linkistä ei näe napsautusta nopeammin, mihin se vie, mutta tästä näkee. Aikaa säästyy kokonainen sekunti, jos linkin takan onkin vain roskaa, muussa tapauksessa se hidastaa vain 1 s. ;)
Katsotteko te todellakin osoitteriviltä, mitä sivu sisältää? Väitän, että osoite kertoo usein paljon vähemmän sivun sisällöstä, kuin muutamat ensimmäiset rivit tekstiä.
Ainut missä tapauksessa itse näen ehkä järkeväksi sen, että osoitteesa on toi otsikko, niin on se, että jos heitetään tänne keskusteluun sivun sisäinen linkki, mutta sekin on mielestäni hyvin turhaa.
dartvaneri kirjoitti:
Ainut missä tapauksessa itse näen ehkä järkeväksi sen, että osoitteesa on toi otsikko, niin on se, että jos heitetään tänne keskusteluun sivun sisäinen linkki, mutta sekin on mielestäni hyvin turhaa.
Miksi se on mielestäsi (hyvin) turhaa? Ei sen linkin toiminta ole edes rajattu 'putkaan, yhtä hyvin se säilyttää kaikki etunsa (sisältönsä paljastamisesta) myös muualle laitettuna.
Ideahan on juuri linkkien parantaminen; ei osoiterivin erityinen hyödyntäminen.
(Viittasin aiemmalla viestilläni siihen, että kun enkoodatut osoitteet dekoodataan, osoiterivillä tai muualla, ei uudistettu osoite ole mitenkään ratkaisevalla tavalla epäselvä, ja se sisältää selkeästi enemmän informaatiota kuin mikään sellainen vaihtoehto, jossa näkyy vain ID. Uudistettu algoritmi näyttää nyt poistavan suuremman osan enkoodaamista vaativista merkeistä, poikkeuksena ainakin skandit -- itselläni ei ole preferenssiä asian suhteen.)
dartvaneri kirjoitti:
Katsotteko te todellakin osoitteriviltä, mitä sivu sisältää? Väitän, että osoite kertoo usein paljon vähemmän sivun sisällöstä, kuin muutamat ensimmäiset rivit tekstiä.
Ainut missä tapauksessa itse näen ehkä järkeväksi sen, että osoitteesa on toi otsikko, niin on se, että jos heitetään tänne keskusteluun sivun sisäinen linkki, mutta sekin on mielestäni hyvin turhaa.
Se title / osio yms. urlissa nimenomaan ainut asia millä mitään merkitystä. Vai väitätkö, että esim. osoite /keskustelu/23452/2 on yhtään enemmän informatiivisempi, kuin vaikka keskustelu.php?aihe=23452&sivu=2 jossa jälkimmäisempi kertoo selkeästi enemmän kuin ns. "clean urli".
Pointtina siis; miksi käyttää "clean urleja" jollei se tarjoa mitään (muuta kuin "selkeämmän" ulkoasun).
Titlen yms. perusteella voi kertoo suoraa haluunko avata jonku osotteen (linkattu vaikka ircissä tms.)
tuutti kirjoitti:
dartvaneri kirjoitti:
Katsotteko te todellakin osoitteriviltä, mitä sivu sisältää? Väitän, että osoite kertoo usein paljon vähemmän sivun sisällöstä, kuin muutamat ensimmäiset rivit tekstiä.
Ainut missä tapauksessa itse näen ehkä järkeväksi sen, että osoitteesa on toi otsikko, niin on se, että jos heitetään tänne keskusteluun sivun sisäinen linkki, mutta sekin on mielestäni hyvin turhaa.Se title / osio yms. urlissa nimenomaan ainut asia millä mitään merkitystä. Vai väitätkö, että esim. osoite /keskustelu/23452/2 on yhtään enemmän informatiivisempi, kuin vaikka keskustelu.php?aihe=23452&sivu=2 jossa jälkimmäisempi kertoo selkeästi enemmän kuin ns. "clean urli".
Pointtina siis; miksi käyttää "clean urleja" jollei se tarjoa mitään (muuta kuin "selkeämmän" ulkoasun).
Titlen yms. perusteella voi kertoo suoraa haluunko avata jonku osotteen (linkattu vaikka ircissä tms.)
Hei.
Olet oikeassa että:
www.osoite.fi/keskustelu/26347
ei hirveästi auta, mutta:
www.osoite.fi/keskustelu/rewrite-ongelma
jo ehkä auttaisi.
Käytän erästä sivustoa, jossa keskustelun eri säikeitä vastaavat jutut on numeroitu, mutta niitä lukiessa sivusto generoi niille URLin, jossa on myös juttujen otsikosta johdettu tekstinpätkä, jota ilmeisesti voi sanoa myös slugiksi (uusi termi minulle, oli tuolla linkissä aiemmin).
Sivustolta löytää halutun jutun URLissa olevan numeron avulla, ja se tekstiosa ei vaikuta oikean sivun aukeamiseen mitenkään. Sen voi jättää pois, tai se voi olla melkein mitä vain. Ainoa merkittävä ominaisuus sillä on, että sen saa sivustolta automaattisesti (on siis aina otsikkokentällä, kun jutun avaa sivuston omasta linkistä) ja sitä voi käyttää tai sen voi jättää pois linkatessa sivuston juttuihin.
Qeijon esimerkkiosoitteisiin sovellettuna tämä kävisi siis näin. Jos keskustelu rewrite-ongelmasta olisi saanut numeron 26347, siihen voisi viitata näin:
www.osoite.fi/keskustelut/26347/
tai
www.osoite.fi/keskustelut/26347/rewrite-ongelma (tämä olisi osoitekentässä, kun sivun aukaisee, sekä Putkan automaattisesti generoimissa linkeissä)
tai
www.osoite.fi/keskustelut/26347/mitävain-eiväliä (näin voisi linkata jos haluaisi, mutta se nyt olisi vain tyhmää kikkailua)
Näistä voisi olettaa normaalin käyttäjän käyttävän sitä, minkä palvelin toimittaa selaimen osoiteriville nähtäväksi, josta hän sen kopioi. Se olisi siis tuo keksimmäinen.
Tässä ratkaisussa siis numero olisi se tärkeä osa palvelinohjelman kannalta, ja selkokielinen teksti olisi vain ihmisten iloksi oleva koriste. Se tuntuu tällä yhdellä sivulla toimivan, mutta en tiedä olisiko se helppo tai järkevä toteuttaa Putkaan. Tässä varmaankin kannattaa miettiä, kenen ongelmia ollaan ratkaisemassa, tai onko kellään ylipäätänsä vakavia ongelmia nykyisen järjestelmän kanssa :)
Yhteenveto: Yksi tapa tehdä asiat on laittaa keskusteluiden osoitteisiin numero tietokonetta varten ja vapaaehtoinen automaattisesti generoituva tekstiosa ihmisiä varten. Olen nähnyt sellaisen käytössä.
No eikö hakukoneiden vuoksi se sluggi kannattaisi aina olla mukana, lähinnä, ettei Google pudota esim. foorumiviestejä pois duplikaattien takia.
Uskon, että hakukoneet kuitenkin tarjoavat jokuselle linkin hakemaansa aiheeseen, vaikka moni aktiivikävijä tietääkin foorumin suoran linkin.
edit:
Eli siis vaikka sluggi olisikin vapaaehtoinen (lähinnä, että viestin otsikkoa muutettaessa myös vanha urli pelittäisi), niin sivuston sisällä slug-sisällytettäisiin aina automaattisesti urliin.
Jos kuvaukseni ei ollut ihan selvä, niin kertauksen vuoksi täsmennän.
Jokaisessa toimivassa URLissa on aina pakollinen numero. Kullakin mahdollisella linkin kohteella on oma numero, joten eri URLit ovat aina erillisiä, eivätkä duplikaatit ole mahdollisia.
Jokainen sivulla automaattisesti luotava URL sisältää aina slugin. Sen voi jättää pois linkatessa keskusteluihin ns. käsin, koska mainitsemani sivusto löytää jutun aina sen numero-osan avulla.
Koska tyypillisellä tavalla sivua selatessa slugi päätyy myös tavallisen selaimen otsikkokenttään, sieltä kopioimalla osoite on oletusarvoisesti ns. slugillinen. Pitää siis erikseen nähdä vaivaa, jos sen ottaa pois lykätessään sen URLin jonnekin.
Jos tässä on joku ongelma, se on se, että samaan sivuun voisi linkata useilla eri tavoilla, jotka näyttäisivät tavallisilta osoitteilta. Joka tapauksessa, ei tämä ole tärkeä asia minulle. Ajattelin vain kertoa tavasta X, jonka näin paikassa Y. :)
Jättäisin itse pois invalidin slugin läpi päästämisen.
123-etusivu -> Etusivu 123 -> Etusivu 124-pilasivu -> Pilasivu 124 -> Pilasivu 123-pilasivu -> 404
Osoitteessa 123-pilasivu on selvästi kirjoitusvirhe. Kun siitä tulee 404 ja sivustolle ajetaan rikkinäinen-linkki-snifferi, virhe huomataan.
Huono puoli tuossa tietysti olisi, että jos kirjoittaja tai moderaattori vaihtaa ketjun otsikkoa, niin mahdolliset aiemmin tehdyt linkit lakkaisivat toimimasta.. Ellei sitten myös pidettäisi tallessa lista vanhoista otsikoista.
Pekka Karjalainen kirjoitti:
Yhteenveto: Yksi tapa tehdä asiat on laittaa keskusteluiden osoitteisiin numero tietokonetta varten ja vapaaehtoinen automaattisesti generoituva tekstiosa ihmisiä varten. Olen nähnyt sellaisen käytössä.
Juuri tällainenhan putkan betatestauksessa oleva osoitemuunnos on - sillä erotuksella, että slugi on tehty hieman epäkonventionaalisesti ja slugin ja id:n välissä on väliviiva, ei kauttamerkki - ja siitähän tässä on keskusteltu viimeinen sivullinen.
Ylimääräinen kauttamerkki tavallaan rikkoo polkumuotoisen ajattelun, joten itse en karsasta väliviivaa.
Nyt voi tulla tyhmä kysymys, jos missaan jotain todella yksinkertaista. No, tällä mennään:
Millä perusteella alueiden keskustelut järjestetään? Esimerkkinä /keskustelu/alue/2-C_ja_Cpp/sivu-7 (kirjoitushetkellä listan yläosassa).
C, SFML: Ohjelma ei toimi [25313] Burton 13.08.2011 17:01:52 Burton 15.08.2011 22:36:42 Code::Blocks-ongelma [25941] Tumce 22.04.2010 18:20:01 Metabolix 22.04.2010 18:30:35 Code::Blocks-ongelma [25940] pXhZa 14.07.2009 20:30:32 Metabolix 15.07.2009 09:37:04 C-ohjelmoinnin aloittaminen [22826] erkki4 07.08.2011 12:16:29 Torgo 10.08.2011 14:00:24
Kai tämä putoaa kategoriaan "jotain todella yksinkertaista tai jotain hassua tekeillä". Keskusteluiden ID:tkään (hakasulkeissa) eivät tunnu noudattavan yksinkertaisinta kaavaa, mutta sillä tuskin on käytön kannalta mitään väliä (onko mm. 23xxx-24xxx id:llisiä threadeja olemassakaan?)
Järjestys menee uusimman viestin id:n perusteella. Putkan remontin yhteydessä oppaat ja koodivinkit ja näiden kommentit siirrettiin samoihin tauluihin kuin keskustelut, jolloin näille tietenkin tarvittiin uudet id:t ja keskusteluun tuli tuhansien viestien kolo. Muilta osin tämän ei tietenkään pitäisi vaikuttaa keskustelun toimintaan mitenkään, mutta nämä löytämäsi poikkeusyksilöt onkin siirretty oppaiden kommenteista keskustelun puolelle, jolloin ne id:n perusteella sijoittuvat virheellisesti päivityshetkelle.
Vaihdan nyt järjestysperusteeksi ajan, niin lista menee oikein ja sen lataaminen kestää 10–20 % (noin 0,01 s) pidempään kuin ennen.
Huolestuttavinta tässä tapauksessa kuitenkin on, että joku edes päätyy juhannuksena keskellä yötä Putkan aihelistan 7. sivulle asti. ;)
Metabolix kirjoitti:
Huolestuttavinta tässä tapauksessa kuitenkin on, että joku edes päätyy juhannuksena keskellä yötä Putkan aihelistan 7. sivulle asti. ;)
Miten niin? Juhannuksenahan ei ole töitä eikä koulua, joten mitä muutakaan voisi tehdä kuin lukea putkaa?
Metabolix kirjoitti:
Huolestuttavinta tässä tapauksessa kuitenkin on, että joku edes päätyy juhannuksena keskellä yötä Putkan aihelistan 7. sivulle asti. ;)
Arvelinkin, että tämä voisi nousta mielenkiintoisemmaksi kysymykseksi asiassa ;). Vastataan nyt olemattomaan kysymykseen: en oikeastaan lueskellut aiheita, vaan päädyin syystä tai toisesta katselemaan mitä mielenkiintoista löytyy vanhojen eri thread-id:iden takaa. Tämä puuttuva väli 23xxx-24xxx sitten herätti melko nopeastikin mielenkiinnon (en minä tätä mitenkään kauaa tehnyt, kai, logeistahan sen näkisi ;) ja tarkistin, että onko tuo puuttuva väli todella olemassa ja törmäsin tuohon kysymykseen siinä samalla.
Veikkasin, että tuolla id-gapilla voisi olla jotain tekemistä asian kanssa, mutta sen enempää en minäkään asiaan ajattelua uhrannut (varsinkin kun se täältä käsin jäisi vain arvuuttelun asteelle, joka tapauksessa).
Grez kirjoitti:
Miten niin? Juhannuksenahan ei ole töitä eikä koulua, joten mitä muutakaan voisi tehdä kuin lukea putkaa?
Kun on aikansa jo lomaillut ja "palaillut luontoon" niin kyllähän juhannuspäivän loppu - teknisesti juhannuksen jälkeen - on hyvä aika tehdä ihan kaikenlaista -- ml. lukea 'putkaa, jos täällä vain olisi enemmän oivaltavaa luettavaa, sellainen on aina ilo sielulle :).
(En ole kaksinaismoralisti; ei ole mitään väärää myöskään käyttää tätä aikaa vastatakseen epäoleellisiin kysymyksiin. Eikä tällaisiin vasteaikoihin edes päästäisi muuten ;)
Voisiko viestipainikkeissa "Linkki" painiketta muuttaa siten että se tunnistaisi automaattisesti valitun tekstin. Jos valittu teksti on URL-osoite, linkkikoodin lisäyksessä aktivoituu linkin tekstin kirjoitus. Jos valinnasta ei voi tunnistaa osoitetta, niin aktivoituu url-osoite.
Olli: Hyvä ehdotus, kehittelin.
Muuten ok, mutta jos valitsee osoitteen niin linkin tekstiksi tulee "Linkin osoite". Lisäksi kun valitsee tekstiä, niin mielestäni olisi parempi vain siirtää osoitin suoraan osoitekohtaan, eikä heittää promptia ruudulle.
Olli kirjoitti:
Muuten ok, mutta jos valitsee osoitteen niin linkin tekstiksi tulee "Linkin osoite". Lisäksi kun valitsee tekstiä, niin mielestäni olisi parempi vain siirtää osoitin suoraan osoitekohtaan, eikä heittää promptia ruudulle.
Kannatan Ollin ehdotusta. Prompt blokkaa koko selaimen, jolloin nappia ei kannata painaa ennen osoitteen kopioimista. :(
Milloin muuten oikeasti tarvitaan Linkin osoite-linkkiä? Lue tämä on minustakin parempi. Jos laittaa vaikka pelkän linkin vastaukseksi, voidaan käyttää Ctrl + V, Ctrl + A, Linkki-nappi ja Lähetä-nappi menetelmää. Sehän ei ole kovin paljon enemmän kuin pelkän osoitteen lähettäminen. :)
"Linkin osoite" oli jokin hetkellinen ajatushäiriö. Nyt tekstit ovat oikein ja prompt poissa.
jukkah kirjoitti:
Jos laittaa vaikka pelkän linkin vastaukseksi, ...
On typerää laittaa vastaukseksi linkki, jonka tekstinä on "Lue tämä". Jos ei viitsi laittaa kunnollista tekstiä, esimerkiksi "Lue Antti Laaksosen PHP-opas", kannattaa joko jättää viesti lähettämättä tai edes laittaa pelkkä linkki niin, että lukijalla on edes jokin aavistus, mihin se johtaa.
Metabolix kirjoitti:
jukkah kirjoitti:
Jos laittaa vaikka pelkän linkin vastaukseksi, ...
On typerää laittaa vastaukseksi linkki, jonka tekstinä on "Lue tämä". Jos ei viitsi laittaa kunnollista tekstiä, esimerkiksi "Lue Antti Laaksosen PHP-opas", kannattaa joko jättää viesti lähettämättä tai edes laittaa pelkkä linkki niin, että lukijalla on edes jokin aavistus, mihin se johtaa.
Niin no, mielipiteitä on useita... :)
Kiitoksia Metabolix, nyt toimii hyvin!
Saisiko saman toimimaan myös lainaustageissa?
Tässä PHP:n oppaassa on seuraava bugi:
"This page contains the following errors:
error on line 132 at column 2: Extra content at the end of the document
Below is a rendering of the page up to the first error."
Saan joskus puhelimella keskustelun sivuista vastaavannäköisiä virheitä. En muista mitä se herjaa, mutta indeksisivulla jää silloin alueet näkymättä ja aiheissa ei näy viestejä jos virhe ilmaantuu.
edit. oiskohan ollut jotain ajax failed to load tms.
Laitetaan nyt tänne: PHP-Haasteen teht.php heittää 500 Internal Server Error. <h2>Tehtävänanto</h2> vielä tulostuu, mutta tuon jälkeen nada. Eilen en tuohon törmännyt, joten hmm-mmm.
PHP-haaste toimii mulla ainakin ihan ok nyt. Varmaan joku tilapäinen virhe ollut kyseessä.
Tossa oli ainakin äsken joku huoltokatko, oiskohan sillon korjattu noita juttuja.
Macro kirjoitti:
Saisiko saman toimimaan myös lainaustageissa?
Laitoin, tosin tässä ei ole mitään tunnistusmagiaa, vaan oletetaan, että valittuna on aina lainattava teksti.
Ohcanep kirjoitti:
– – 500 Internal Server Error.
Tämä ynnä muut edellä mainitut korjaantuivat maagisesti jo eilen.
Macro kirjoitti:
Tossa oli ainakin äsken joku huoltokatko, oiskohan sillon korjattu noita juttuja.
Tämän päivän huoltokatko johtui tärkeän tiedoston tuhoamisesta vahingossa.
1. Voisiko käyttäjäprofiiliosoitteissa %20 sijaan käyttää viivaa - kuten esim. ketjujen nimissä on?
Eli
/kayttajat/profiili/Antti%20Laaksonen
olisikin
/kayttajat/profiili/Antti-Laaksonen
2. Voisiko tt-tagille lisätä taustan, jotta teksti erottuisi helpommin? Esimerkiksi
code {
padding: 1px 5px 1px 5px;
background-color: #EEE;
}Tuo koodi on Stackoverflowista.
Olli kirjoitti:
1. Voisiko käyttäjäprofiiliosoitteissa
%20sijaan käyttää viivaa-kuten esim. ketjujen nimissä on?
Mitähän tapahtuu jos joku tekee vaikkapa tunnuksen Antti-Laaksonen ja sitä tarkastellaan? :)
Olli kirjoitti:
1. Voisiko käyttäjäprofiiliosoitteissa %20 sijaan käyttää viivaa - kuten esim. ketjujen nimissä on?
Olenko jotenkin erillainen kun minulla on sekä profiilit että ketjujen linkit id:nä eikä ceo tyyppisesti?
Korjausehdotus: omia tietojani muokatessa kotisivun osoite -kenttään päivittyy koko ajan oma nimimerkkini.
Olli kirjoitti:
Voisiko käyttäjäprofiiliosoitteissa
%20sijaan käyttää viivaa-kuten esim. ketjujen nimissä on?
Tunnuksen pitää olla osoitteessa muodossa, jossa siitä voi yksiselitteisesti päätellä käyttäjän. Siksi muutteleminen ei ole järkevää. Keskusteluissa taas osoite sisältää myös id:n, joten otsikon muuttelulla ei ole merkitystä.
Olli kirjoitti:
Voisiko
tt-tagille lisätä taustan, jotta teksti erottuisi helpommin?
Minusta tälle ei ole mitään tarvetta, ja monissa tapauksissa korostus myös näyttää huonolta.
t0ll0 kirjoitti:
Olenko jotenkin erillainen kun minulla on sekä profiilit että ketjujen linkit id:nä eikä ceo tyyppisesti?
Toiminto on toistaiseksi ollut käytössä vasta kokeiluun ilmoittautuneilla. CEO on muuten firman pomo, ja hakukoneoptimointi on SEO.
The Alchemist kirjoitti:
Korjausehdotus: omia tietojani muokatessa kotisivun osoite -kenttään päivittyy koko ajan oma nimimerkkini.
Joku muukin on joskus väittänyt näin, mutta tämän on oltava käyttäjän tai selaimen vika. Jos olet eri mieltä, lähetä todisteeksi sivun HTML-koodista kohta, jossa tuollainen outo arvo asetetaan.
Oisko mahdotonta saada plantuml pyörähtään. Parikin kertaa käynyt mielessä, että kuva jostain jutusta ois kiva. Ainakin itse pidän ohjelmiston mallinnuksesta tuolla.
Kirjoittaisi alice->bob: Hello! ja laittaisi kooditageiksi ympärille plantuml ja siihen kohtaan tulisi UML-kuva. http://plantuml.sourceforge.net on virityksen osoite. vaatinee vissiin graphvizin ja javan. Kutsu onnistuu PHP:stä
Oppaisiin parannusehdotus:
Nykyisellään, kun johonkin oppaan loppuun kirjoittaa jotain kommenttia tai kysymystä siihen ei saa vastausta moneen kuukauteen, jos silloinkaan. Sinne kirjoitetut kommentit ovat liian näkymättömissä niin, ettei kukaan huomaa, jos joku kirjoittaa sinne jotain.
Siksi ehdottaisin, että keskusteluihin lisättäisiin uusi alue nimeltä "oppaat", jossa olisi jokaisen oppaan jokaisesta sivusta oma keskusteluosionsa. Oppaisiin kirjoitetut kommentit olisi siis linkitetty yhteen tämän alueen kanssa siten, että oppaaseen kirjoitettu viesti näkyisi tämän alueen vastaavassa keskustelussa ja vastaavasti keskusteluun kirjoitettu kommentti näkyy kyseisessä oppaassa. Näin jokainen keskusteluita seuraava käyttäjä näkee heti uudet oppaisiin kirjoitetut kommentit ja voi vastata niihin keskusteluiden kautta.
Tämä vaatisi tietysti sen, että kyseisen "oppaat" alueen keskustelut eivät mene lukkoon, vaikka sinne ei kirjoitettaisi mitään pitkään aikaan. Lisäksi ainoa tapa aloittaa uusi aihe kyseiselle alueelle olisi se, että kirjoittaisi ensimmäisen viestin jonkin oppaan jollekin sivulle. Tällöin keskusteluihin muodostuisi "oppaat" alueelle sen kyseisen oppaan kyseistä sivua vastaava uusi aihe.
AkeMake kirjoitti:
Nykyisellään, kun johonkin oppaan loppuun kirjoittaa jotain kommenttia tai kysymystä siihen ei saa vastausta moneen kuukauteen, jos silloinkaan.
Oppaan kommenttikenttä on väärä paikka esittää kysymyksiä ohjelmoinnista, vaikka kysymys tavallaan liittyisi oppaan aihepiiriin. Yleensä siirrän huomaamani kysymykset keskustelualueelle. Ainoat oppaan kommentteihin sopivat kysymykset ovat sellaiset (yleensä retoriset) kysymykset, jotka kyseenalaistavat oppaan sisällön, esim. miksi oppaassa väitetään jotain virheellistä tai miksi jokin koodi on kirjoitettu huonosti tai miksi jotain asiaa ei käsitellä ollenkaan.
Oppaiden näyttäminen keskustelun Uudet viestit -sivulla olisi kyllä myös mahdollista, mutta katsotaan nyt, onko tälle todellista tarvetta. Seuraan ensin kommentteja itse tarkemmin.
Aihe on jo aika vanha, joten et voi enää vastata siihen.