Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.
ehnmark

ehnmark

Medlem
  • Plats International user
  • Registrerad 2001-07-19
  • Senast aktiv 2009-05-23
  • Antal inlägg 51

Foruminlägg

De senaste inläggen ehnmark har skrivit i forumet.

  • Medlem
  • International user
  • 2001-11-09 16:20

Är det ingen som använder Emacs för programmering..?

Hu nä, vim är det enda rätta Men ta en titt på diskussionsforumet på Sourceforge, där står det kanske.

  • Medlem
  • International user
  • 2002-03-03 03:19

Algoritmer och design är avgörande för prestanda. Språk är enligt min mening sekundärt, men i vissa sällsynta fall kan det vara avgörande.

Stilpoäng! Det i särklass mest insiktsfulla som sagts i denna debatt hittills.

  • Medlem
  • International user
  • 2002-03-03 03:17

Ska du lära dig något språk snabbt för ett projekt så är PERL uteslutet, som är väldigt komplex, plus begränsningarna som jag inte tänker gå in på.
I längden med stora siter så är PERL eller nån annan form av CGI nästan inte ens att tänka på, för datorn måste använda mer CPU för att hantera det.

Låt oss höra vilka begränsningar Perl som språk har gentemot PHP & Co Att gränssnittet CGI har fler begränsnignar är en annan femma, men ingen sund människa använder Perl genom CGI när mod_perl finns.

  • Medlem
  • International user
  • 2001-08-18 19:43

Om du vill slippa Obj-C totalt så blir det Carbon.

Annars verkar Qt kunna bli ett högintressant alternativ, om inte Trolltech larvar sig med licenserna.

  • Medlem
  • International user
  • 2002-01-17 18:27

Tips på fri källkod som kan användas för att komma igång?

Vill du skippa återuppfinna hjulet men ändå ha frihet att designa publiceringssystemet efter eget tycke, rekommenderas Zope + CMF. Rockar skjortan av det mesta.

  • Medlem
  • International user
  • 2001-08-13 13:18

Du kan t ex ladda ned Bash för terminalen, i stället för tcsh.

Tack för tipset, men nu var det terminalemuleringen det gällde, skalprogrammet har inget med saken att göra.

  • Medlem
  • International user
  • 2001-08-12 15:46

Jag antar att jag inte är den enda som tycker att terminalemuleringen i Terminal.app är under all kritik. Finns det någon riktigt bra terminalemulator till OS X? Det borde inte vara alltför svårt att porta en nerstrippad version av KDE-terminalen nu när Qt för OSX finns.

[ 12-08-2001: Meddelandet ändrat av: ehnmark ]

  • Medlem
  • International user
  • 2002-02-13 23:51

Du tappade bort mig totalt i ditt andra stycke Ehnmark, men jag tvivlar inte på att det ligger nåt i det för dom som förstår...

Gå upp på DV-institutionen och skriv in dig på TDBC86 så lovar jag att dimman lättar

Och som sagt, jag använder ADOdb just nu och tycker det fungerar fint, och det har bra stöd för ODBC också.

Det tror jag säkert, men det förutsätter väl ändå att det finns en sk. Driver Manager och en ODBC-driver? Under Windows är det enklare eftersom sådant ingår i OSet, och ytterligare drivrutiner kan hämtas på MySQLs och Postgres hemsidor. Men under Mac OS X är det lite knivigare antar jag, OpenLink har tydligen en Driver manager men frågan är dock om det finns väl fungerande drivrutiner.

  • Medlem
  • International user
  • 2002-02-13 22:42

Men till att börja med räcker ju MySQL bra, ska man bara göra några INSERT och SELECT så spelar det ingen större roll.

Det är sant, men så fort man har någorlunda sofistikerad databasdesign och vill hålla tabellerna konsistenta så vill man definitivt ha constraints, och då är det väldigt smidigt med triggers och transaktionsstöd. Om man kan få det gratis utan att förlora MySQLs enkelhet och php-integration så är det väl bara att tacka och ta emot

Fast i ärlighetens namn är inte alla features i Postgres av godo, det är lätt att man använder sådant som man tror underlättar men som kan orsaka problem senare. Exempelvis lär man sig på grundläggande kurser i databasteknik att det finns något som heter normalformer och som relationer bör uppfylla av olika skäl, men eftersom Postgres har stöd för arrayer och andra icke-atomiska datatyper är det lätt att konstruera en tabell som inte ens uppfyller den mest grundläggaste formen.

Vad gäller ADOdb så läste jag visst lite för snabbt Trodde det var en php-wrapper för just ADO, men det verkar mycket riktigt vara ett plattformsoberoende API som härmar syntaxen i ADO. Det förändrar saken

Men för att återgå till ursprungsfrågan: om ODBC är ett krav så är det kanske varken MySQL eller Postgres du bör kika på utan OpenBase. Även om det säkert går att pussla ihop en fungerande ODBC-uppkoppling till andra databashanterare skulle jag tro att det blir minst krångel med OpenBase eftersom man kan hämta hem en driver manager och tillhörande drivrutin från företagets hemsida.

  • Medlem
  • International user
  • 2002-02-10 19:03

Vet inte riktigt om det finns så många andra alternativ. PostgreSQL kanske, men typ Filemaker lär väl inte funka eller ? Har själv ingen erfarenhet av Filemaker så jag vet inte ... Postgre är vad jag förstår mer lämpad för större installationer, så det kanske blir lite att ta i.

Jag har svårt att förstå fascinationen över MySQL. Nu har jag förvisso inte använt programmet sedan version 3.2-nånting, men då var MySQL ett par generationer efter Postgres. Inga subqueries, inga stored procedures, inget stöd för arv eller annan form av objektorientering, inga transaktioner, överhuvudtaget tämligen begränsad. Postgres däremot är en oerhört kompetent men ändå lättanvänd databashanterare, och fungerar alldeles finfint med PHP. Fast jämfört med Access/Jet är t.o.m. MySQL ett underverk.

En annan grej som kan vara smart är att göra databaskopplingen oberoende av databas, med det menar jag att använda ett databasbibliotek som heter ADOdb för PHP. Fördelen med det är att man då använder samma anrop oberoende av databastyp och så anger man bara vilken databas man använder så sköter ADOdb resten.

En programmerare som är mån om portabilitet skriver naturligtvis ett abstraktionslager för databas-snack i form av en klass eller liknande, ser ingen anledning att begränsa sig till Windows. Fast då vill det till att enbart använder någon sorts gemensam nämnare och håller sig borta från smidiga funktioner som kan vara unika för en viss databashanterare.