PHPdude

I utgangspunktet bør all Installasjon av grafikk-drivere kun skje gjennom menyvalget "System -> Administrasjon -> Håndtering av ufrie drivere"...

Han skrev han hadde 8400. Nå har ikke egentlig jeg peiling på disse modellene, men skulle ikke tro at det kortet ikke er støttet, vi snakker jo om *neste* Ubuntu-versjon og det ville jo vært litt kjedelig om driverne allerede er såpass utdatert...

Compiz skal jo være installert som standard i Gutsy, men det følger vel fortsatt ikke med de proprietære driverne fra Nvidia eller ATI så viss kortet ditt trenger disse driverne vil jeg tro at du først må installere de og deretter aktivere Compiz.

Det finnes en spesialpakke kalt "ubuntu-desktop" som i seg selv ikke inneholder noe, men som avhenger av alle de pakkene som følger med som standard i Ubuntu. Når du fjernet Compiz vil jeg tro at også denne spesielle pakka ble fjernet så ved å hake av for den i Synaptic bør du også få med alle de andre.

Nå har jeg for en gangs skyld ventet med å oppgradere så jeg vet ikke, men har forstått det som at menyvalget "System > Innstillinger > Skrivebordseffekter" hvor en kunne aktivere/deaktivere Compiz i 7.04 har blitt flyttet sammen med andre relaterte ting til "System > Innstillinger > Utseende" eller noe sånt.

Det gjør det også mye lettere å style siden etterpå. Er for eksempel ikke mange CSS-linjene som må til for en perfekt utbrettbar meny viss HTML'n er god.

Kan jo komme med noen eksempler:

Basert på hvilke interfaces objektet implementerer kan man

se hvordan datasettet kan leses.

function outputProducts($data)
{
 if($data instanceof Zend_Db_Statement_Interface {
   while($product = $data->fetch()) {
     echo $product['name'] . "\n";
   }
 } elseif($data instanceof Iterator) {
   foreach($data as $product) {
     echo $product['name'];
   }
 }
}

Mer aktuelt er kanskje å lage en universell måte å loope gjennom mange forskjellige datasett på.

I PHP har vi "Iterator"-interfacen som er innebygd og er enklest i bruk da den er integrert med foreach

function outputData(Iterator $data)
{
 foreach($data as $key => $value) {
   echo "$key => $value\n";
 }
}
$xmlData = new SimpleXMLIterator(new SimpleXMLElement('test.xml'));
$arrayData = new ArrayObject($someArray);
$filesData = new DirectoryIterator(dirname(__FILE__));
$newsData = new ArrayObject($db->fetchPairs('SELECT date, title FROM news'));
/*
* Alle disse data-variablene implementerer "Iterator" og outputData() kan
* forstå og skrive ut innholdet av alle sammen.
*/

Et annet eksempel på hvordan en interface kan skille ut spesifikk funksjonalitet.

// Først oppretter vi en en egen interface med funksjoner
interface Storage
{
 public function __construct($id);
 public function save();
 public function load();
 public funciton getId();
}

// Så lager vi en klasse som implementer interfacen med de påkrevde funksjonene
class Storage_Session implements Storage
{
 protected $_id;
 protected $_data;

 public function __construct($id, &$data)
 {
   $this->_id = $id;
   $this->_data = $data;
 }

 public function save()
 {
   $_SESSION[$this->getId()] = serialize($this->_data);
 }

 public function load()
 {
   if(!isset($_SESSION[$this->getId()])) {
     return null;
   }
   return unserialize($_SESSION[$this->getId()]);
 }
}
// Andre klasser vi kunne ha lagd er f.eks Storage_Db, Storage_File og Storage_Memory

// Så lager vi en klasse som faktisk bruker funksjonaliteten:
class Shoppingcart
{
 protected $_products;
 protected $_storage;

 public function __construct()
 {
   // Oppretter $storage og sjekker om det er lagret data fra tidligere
   $storage = new Storage_Session('shoppingcart', $this->_products);
   $this->setStorage($storage);
   $storedData = $storage->load();
   if($storedData !== null) {
     $this->_products = $storedData;
   }
 }

 public function __destruct()
 {
   $this->_storage->save();
 }

 /**
  * Her kommer vi til et nøkkelpunkt. Det er det samme om $storage er 
  * Storage_Session, Storage_Db, Storage_Memory eller Storage_File 
  * eller noe annet. Det eneste som teller
  * er at den implementerer de funksjonene definert i "Storage", 
  * for så lenge den gjør det vet "Shoppingcart" hvordan
  * lagringen og lastingen skal utføres.
  * Merk at det er unødvendig å foreta noen ekstra sjekk av innholdet 
  * fordi funksjonsdefinisjonen her krever at $storage er et
  * objekt som implementerer "Storage"
  */
 public function setStorage(Storage $storage)
 {
   $this->_storage = $storage;
 }
}

Koden er helt utestet og ikke ment som noe annet enn en skisse.

Objekter som har noe funksjonalitet til felles kan knyttes sammen ved hjelp en interface og når man da skal bruke denne funksjonaliteten trenger man ikke å forholde seg til alle de forskjellige objektene, men kun til interfacen.

Aldri nødvendig å bruke interfaces, men det kan ofte være lurt.

http://no2.php.net/manual/en/ref.spl.php

http://no.php.net/manual/en/language.oop5.php

Må nesten slenge meg med Ernie her.

Om du kan PHP (Da snakker jeg ikke om bare basis) så anbefaler jeg at du skriver ditt eget framwork. Dette tar tid, men er mye lettere.

Viss vi her snakker om et profesjonelt nivå vill jeg påstå at "basisen" har du når du kan PHP-manualen på rams (litt overdrevet), en mye viktigere del av programmering er god kodestruktur og der virker det som om du har såpass langt igjen at du bør være forsiktig med å legge deg ut mot det som er ansett som sunn fornuft innen webprogrammering, MrNeeon

Finnes enkelte "gyldige" grunner til at et eget rammeverk kan forsvares og da kanskje i første rekke:

1. Opplæring. Lengre utviklingstid forsvares ved at å ha bygget noe såpass komplekst helt fra bunn av er en bra erfaring å ta med seg.

2. Man har allerede kunnskapen som skal til for å foreta en nøye vurdering av prosjektets behov og har kommet frem til at et eget rammeverk bygget fra bunn av eller delvis basert på et annet er god langsiktig tidsbruk.

Så for all del - har han lyst til å lage noe fra bunn av er det bare å kjøre på det, men nå var det jo hjelp til ZF han lurte på, og det er nok langt bedre tidsbruk.

Tilbake til trådstarter: ZF er et glimrende rammeverk jeg har stor tro på, men foreløpig synes jeg det lider under at det er såpass nytt og ikke så mye opplærings-materiell tilgjengelig. Den beste ressursen er helt klart manualen som egentlig er ganske bra. Guider har jeg ikke funnet noe særlig av enda, særlig tynt er det når man kommer forbi det mest grunnleggende.

http://zftutorials.com/ har samlet så godt alt som er, så noe som passer bør jo være å finne...

Har nok ikke noe med disken å gjøre. Er nok rett å slett en feil i Wine, husk at vi her snakker om veldig uferdig programvare hvor det mangler mye på enkelte områder, og sånn vil det antakelig alltid være.

Beste håpet tror jeg må være å se i AppDB på winehq.org om det er noen som har hatt samme problemet og funnet en løsning.

Selve __autoload-funksjonen ble vurdert fjernet fra PHP6 til fordel for SPL-metoden som er mer komplett.

Uansett en veldig praktisk mulighet

php.net/spl

Konfigurasjonverdier er da ikke konstante verdier. Til mindre prosjekter kan det sikkert være enkelt og greit, men noen "best practice" kan det ikke kalles.

Ja, det gjør jeg. Er jo bare å ikke endre de, det

Hva om det er et prosjekt med flere programmerere? DB_HOST, DB_USER osv er vel da mer praktisk?

9549708[/snapback]

DB_HOST og DB_USER? Mener du da at de skal inneholde host og brukernavn for en DB-tilkobling? Isåfall er da det misbruk av konstanter.

For å si det slikt... jeg har forlengst sluttet å lage nettsider for IE.. Klart jeg lager de kompatibel, men når jeg sketcher opp en idé til en nettside, så tenker jeg webstandarder, ikke IE restriksjoner...

9548017[/snapback]

Det er klart, men du får allikevel bare brukt det veldig begrensede utvalget av funksjoner som IE støtter (og da snakker jeg ikke om en CSS-property her og der), med mindre du enten dumper 60% av de besøkende eller lager en egen side for dem da det dessverre er umulig å utnytte det fulle spekteret av W3C-standarder som er støttet i Mozilla og Opera og samtidig være "IE-kompatibel".

Sånne automatiske hjelpegreier lar seg veldig dårlig kombinere med manuelle modifikasjoner siden koden de lager er et eneste stort makkverk. Så viss dette er noe du tenker å gjøre noe ordentlig ut av, så kan du like gjerne begynne fra start av. Har en først kunnskapen bør det ikke ta mange minuttene å sette opp et sånt design.

Ellers så kan du bruke "overflow" i CSS for å få til scrollingen.

Du trenger ikke bruke <iframe> for det, det er mange andre mye bedre løsninger, <iframe> og frames generelt er noe hærk.

Ja skjønner at du ikke har kontroll. Vil på det sterkeste anbefale deg å lese guidene på www.htmldog.com, det mest grunnleggende bør være på plass før du begynner, ellers vill du bare rote bort masse tid på dårlige løsninger med et dårlig resultat

http://htmldog.com/

Video og lyd-delen fra HTML5 vil også være på plass i Firefox 3

http://mozillalinks.org/wp/2007/06/firefox...-video-support/

De som ikke har sett den kan jo også være interessert i denne SVG/Video-demoen:

http://mozillalinks.org/wp/2007/08/surface...d-native-video/

Eneste skåret i gleden er at disse mulighetene føyer seg inn i den laaaange rekken av muligheter som Internet Explorer setter en stopper for...

Så lenge det bare er display_errors som er skrudd av kan du vel alltids lage en egen errorhandler også skrive ut info derfra så blir jo resultatet likt.

http://no2.php.net/manual/en/function.set-error-handler.php

Hvorfor <br>? Er da bare tull å slenge inn html-tagger i epost som er ren tekst. Helt vanlig linjeskift er tingen, altså "\n"

PHP sin mail()-funksjon har visst også en sikkerthetssvakhet hvor $subject ikke sjekkes skikkelig så man kan sette inn en ny linje og dermed også en ny header i eposten. Mulig det er fikset i de nyeste versjonene.

Du har grov feil som går igjen med at du ikke bruker " rundt strenger.

Når du utvikler bør du alltid ha følgene kode på toppen, så oppdager man sånne og andre feil med en gang:

error_reporting(E_ALL | E_STRICT);

2. Normalt kjører en webserver på port nr 80, og siden to programmer ikke kan dele samme porten kan du normalt ikke ha to webservere kjørende samtidig, men viss du setter den ene til å kjøre på en annen port går det.

3. Bruker ikke Windows/IIS, men vil tro IIS kjører som en vanlig service og at denne kan startes/stoppes. Tror det ligger under Administrative verktøy i kontrollpanelet (eller kanskje under Programmer -> Tilbehør) og deretter under Services/Tjenester eller noe sånt.

At klassisk ASP er døende er det vel liten tvil om, men er utrolig hvor seigliva sånne kan være i blant...

Har jeg forstått deg rett ser jeg tre løsninger:

1. Viss IIS støtter å ha både PHP og ASP installert kan du jo kjøre PHP gjennom IIS. Ikke ideelt viss du utvikler for Apache, men i praksis er det veldig små forskjeller. Bare vær litt ekstra obs når du leser PHP-manualen.

2. Kjøre begge to samtidig på forskjellige porter. Du kan f.eks sette Apache til å kjøre på port 81, kan jo og redigere hosts fila til at f.eks "apachehost" eller "apache.localhost" skal peke til 127.0.0.1:81.

3. Starte og stoppe Apache/IIS ettersom hvilken du skal bruke.

Uansett hva og når er det vertfall et tegn på at Valve vurderer muligheten for Linux-versjoner, noe som jo definitivt er en start

Mistenker at disse store spillene nå etterhvert opererer med sitt eget API, også omdirigerer de det videre til DirectX/OpenGL ettersom hvilken platform spillet skal kjøre på, er tro tross alt bare Windows og Xbox som bruker DirectX.

Men det er nok mye jobb allikevel.

Edit: Er jo også en mulighet for at jobben kun gjelder server-delen da...

Da ser det ut til at AMD holder ord og offentliggjør specs, foreløpig bare en liten del men det er en start.

Spesifikasjonene er nå tilgjengelig på www.x.org/docs/AMD/

Så gjenstår det bare å se hvordan oppfølgingen blir og hvor god kvaliteten er på innholdet.

Skal kjøpe ny laptop snart, og har hittil skydd alt som har ATI-kort, men nå blir jo situasjonen nesten motsatt

System > Administrasjon > Påloggingsskjerm > Lokal (fane) > Bakgrunnsfarge?

Hvis radeon express kortene er raskere enn intel sine integrerte grafikk løsninger så skal nok nevnte radeon kort klare compiz helt fint, men ikke før i oktober.

9462558[/snapback]

Er da fullt mulig å kjøre skrivebordseffekter med dagens fglrx-drivere også, men det krever at man bruker XGL i tillegg som visstnok har en del svakheter ovenfor AIGLX.

Som jeg har forstått det kommer det denne måneden oppdateringer til fglrx-driveren fra ATI som er VELDIG forbedret i forhold til de gamle (skal ikke så mye til...) og vil by på enorme ytelsesforbedringer samt støtte for AIGLX som brukes i forbindelse med Compiz og dermed vil gjøre det lettere å kjøre 3D-effekter med ATI-kort.

Denne oppdaterte driveren vil støtte alle de samme kortene som dagens fglrx-driver støtter pluss noen av de nyeste ATI-kortene.

I tillegg har de lovet å gi tilgang til maskinvare-spesifikasjoner til R500-serien og nyere hvilket betyr at det i nær fremtid vil komme opensource-drivere til disse kortene.

Snakker vi om eldre kort så har den allerede eksisterende opensource-driveren rimelig god støtte på mange av kortene.

Kort oppsummert så kan du kjøre 3D-effekter nesten uansett bare du har et grafikk-kort fra de siste åra (og som ikke er så nytt at det mangler linux-driver), pr. dags dato så er ATI-kort det dårligste valget, selv om det kan endre i løpet av noen få måneder.

Vet dessverre ikke i hvilken kategori de modellene du nevner ligger.

http://www.phoronix.com/ dekker disse områdene godt.

System > Administrasjon > Håndtering av ufrie drivere