Terrasque Skrevet 29. mai 2012 Del Skrevet 29. mai 2012 (endret) var VELDIG enkelt forklart ja, men de FLESTE Linux distroer kjører på pc da, mens de FLESTE Uni kjører på servere, fornøyd? (Og jo veit at du har Linux for servere, kjører Ubuntu server selv..) Linux brukes ganske ofte som server. (over 60% av verdens servere i følge noen undersøkelser). Og OSX er en sertifisert Unix. Og vil gjette 90% av OSX bokser er desktops, ikke servere. Edit: Litt saksing fra Wikipedia: As of September 2011, OS X is the second most active general-purpose client operating system in use on the World Wide Web, after Microsoft Windows, with an 8.45% usage share according to statistics compiled by W3Counter. It is the most successful Unix-like desktop operating system on the web, estimated at over 5 times the usage of Linux (which has 1.5%). Linux distributions have long been used as server operating systems, and have risen to prominence in that area; Netcraft reported in September 2006 that eight of the ten most reliable internet hosting companies ran Linux distributions on their web servers. Since June 2008, Linux distributions represented five of the top ten, FreeBSD three of ten, and Microsoft two of ten; since February 2010, Linux distributions represented six of the top ten, FreeBSD two of ten, and Microsoft one of ten. Edit 2: Litt mer wikipedia saksing (og hopefully kan man stoppe og diskutere dette) The UNIX-like family is a diverse group of operating systems, with several major sub-categories including System V, BSD, and GNU/Linux. The name "UNIX" is a trademark of The Open Group which licenses it for use with any operating system that has been shown to conform to their definitions. "UNIX-like" is commonly used to refer to the large set of operating systems which resemble the original UNIX. Unix-like systems run on a wide variety of computer architectures. They are used heavily for servers in business, as well as workstations in academic and engineering environments. Free UNIX variants, such as GNU/Linux and BSD, are popular in these areas. Endret 29. mai 2012 av Terrasque Lenke til kommentar
Lycantrophe Skrevet 29. mai 2012 Del Skrevet 29. mai 2012 Tallet er nok høyere enn det og. Lenke til kommentar
Olavxxx Skrevet 30. mai 2012 Del Skrevet 30. mai 2012 ang include/require _once: Det har forsåvidt ikke nødvendigvis noe med å "ha kontroll over includes" å gjøre. I de tilfeller der du vet at du bare får en include, er det like greit å bruke include() (ev. require()). Men om du har en stor funksjonsfil som du vet inkluderes i forskjellige (inkluderte) deler, må du kunne forvente at den samme filen da inkluderes flere ganger. Derfor bruker du da _once (for å forhindre kræsj/feilmeldinger). Du legger ikke opp til å alltid bruke _once :-P (da blir det sloppy code med en gang). Men samtidig lager du gjerne en del globale funksjoner og instillinger (feks.tilkobling til database, funksjoner for datavask, funksjoner for regulære uttrykk (kontroll av brukerinput,m.m.). Lenke til kommentar
Olavxxx Skrevet 30. mai 2012 Del Skrevet 30. mai 2012 Forøvrig er det flere andre "småtips" man kan fortelle,som: Shortcode: <?=$variabel?> er veldig grei om man har mye html og skal ha ut verdi fra en variabel Ellers: alt som har med headers å gjøre, må gjøres før noe "sendes" til nettleseren (toppen av filen). Dette gjelder da sesjonsvariabler, diverse header() ting (redirect, content, m.m.). Videre, om man bruker echo med doublequotes, kan man ha variabler inne mellom quotes. Bruker man med singlequotes, må man dele det opp sånn: Singlequotes echo 'heisann ' . $_GET['navn'] . '!'; doublequotes echo "heisann {$_GET['navn']}!"; shorthand code (må være aktivert i config, men det er som regel det) heisann <?=$_GET['navn']?>! Man finner ut utrolig mye info på php.net,men man bør lese mye om sikring av php-script. (spesielt om du kobler deg til en database!). Det er viktig å ha kontroll på input, vaske data (fjerne tegn med strip_tags, trim,m.m.) Man må også være forsiktig med dynamiske includes (variabelnavn). Om man ikke vet hva man gjør på, kan andre manipulere includes til å inkludere filer du ikke ønsket. Dette kan føre til at de leser filene du ikke vil skal bli lest, eller de kan lage "uendelige løkker". Kjører de opp nok slike uendelige løkker, vil du kanskje få trøbbel med vevhotell-leverandøren din. Om man skal begynne å leke med mysql og php, husk å sikre alt av inputs og burk gjerne den i eksempel 1 her: http://php.net/manual/en/function.mysql-real-escape-string.php Husk også å bruke som sagt strip_tags(), trim(), samt kontroll av input (regulære uttrykk, eller regular expressions). Gjør man ikke leksen sin, kan man risikere at man mister kontroll over dataene sine. (da mener jeg ikke dataene som i datamaskinene, men i selve dataene du har lagret i database neller på filstruktur). Lenke til kommentar
Terrasque Skrevet 30. mai 2012 Del Skrevet 30. mai 2012 (endret) Du legger ikke opp til å alltid bruke _once :-P (da blir det sloppy code med en gang). Men samtidig lager du gjerne en del globale funksjoner og instillinger (feks.tilkobling til database, funksjoner for datavask, funksjoner for regulære uttrykk (kontroll av brukerinput,m.m.). Raskt spørsmål.. Er det noen situasjoner der du trenger å include en fil mer enn en gang? Jeg kan ikke komme på noen, og husker jeg stusset på hvorfor _once ikke var default behavior, men en egen funksjon (som ikke er så fremhevet som standard include). Slik jeg ser det er regelen at du bare vil include en gang, og skjeldent unntak at man faktisk vil include flere ganger (om noen). Slik sett burde vel include tilrettelegge for standard bruken, og alternative funksjonen være for unntakene? Og hvis man planlegger å bare inkludere en gang, så burde man vel bruke include_once .. Ved bare include så sier strengt tatt koden noe annet enn det du mener den skal si (selv om resultatet er det samme.. om du er forsiktig). Uansett... Er blant annet slike ting som gjør at jeg syns språket er rotete. Edit: Gjorde litt googling på det.. Fant http://stackoverflow.com/questions/186338/why-is-require-once-so-bad-to-use Short summary: Ser ut som tidligere PHP versjoner gjorde noen idiotiske ting ved include_once, men det er moot nå (og har vært en stund). En der benchmarket litt, og over 10,000 include_once vs 10,000 include resulterte i exec tid på 10.15 og 9.84 sekunder. AKA en ku-fjert i slaktetida Endret 30. mai 2012 av Terrasque Lenke til kommentar
Olavxxx Skrevet 1. juni 2012 Del Skrevet 1. juni 2012 Edit: Gjorde litt googling på det.. Fant http://stackoverflow...e-so-bad-to-use Short summary: Ser ut som tidligere PHP versjoner gjorde noen idiotiske ting ved include_once, men det er moot nå (og har vært en stund). En der benchmarket litt, og over 10,000 include_once vs 10,000 include resulterte i exec tid på 10.15 og 9.84 sekunder. AKA en ku-fjert i slaktetida Jeg mener at man vil tvinges til å kjenne koden sin bedre, samt kjenne den logiske styringen bedre - om man ikke bruker _once på alt. Da vet man hvordan sidene egentlig henger sammen og man skjønner gjerne mer rundt prosessrekkefølger,m.m. For ytelse har det ikke så mye å si, men jeg mener at man i 99.9%av tilfellene bør ha kontroll over includes. Unntaket er som jeg nevnte ovenfor f.eks. om man bruker samme funksjonsfil i andre typer sider (admin, ajax,o.l.). Da kan det av og til være aktuelt med en _once Men jeg mener altså da at man bør være obs på det og at man da bør implementere det for avvikene, ikke for all kode. Det har sånn sett egentlig mer med å holde seg i tøylene å gjøre. Det er ikke farlig å bruke _once ; men jeg føler at det er litt det samme som å skrive kode uten å kommentere den, eller å indentere den. Lenke til kommentar
jossy Skrevet 4. juni 2012 Del Skrevet 4. juni 2012 Ka theme/color-scheme er brukt i bildet til artikkelen? Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå