- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Valaki fejtse ki ezt egy picit, mert nem teljesen világos. Milyen szkriptről beszélünk?
Konkrétan az a bajom, hogy az esetek nagy részében vagy a script egy előre jól meghatározott rendszeren fog futni, olyankor nyilván a rendszerrel azonos paraméterű rendszeren. (Pl. ha egy shell script ami egy linuxon fog futni, akkor egy ahhoz hasonló linuxon). Vagy a script egy platformfüggetlen futtatókörnyezetben fog futni (pl. javascript valamilyen böngészőben), ilyenkor teljesen mindegy milyen rendszeren futtatja az ember, nyilván az elsődlegesen használt fejlesztői rendszerén fogja futtatni.
--
Don't be an Ubuntard!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
+1, a kérdés és válaszok olvasása után a "hehh??" kérdés fogalmazódott meg bennem..
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..." - Douglas Adams
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
azért beklikkoltam a Linuxot. biztos, ami biztos.
- A hozzászóláshoz be kell jelentkezni
+1, ennek igy semmi ertelme, altalaban tudom, milyen feladatra szanom. Az igen ritka, hogy olyan script-et kell irnom ami "cross-platform", foleg ha windows-tol kezdve a MacOSX-ig minden futnia kene, es erdekel is, hogy fusson, ilyen meg nem is volt soha, mint igeny sem.
- A hozzászóláshoz be kell jelentkezni
Ugyvan! +1
- A hozzászóláshoz be kell jelentkezni
nekem csak Linuxon kell scripteket irnom alapbol (mondjuk Windowsom tovabbra sincs, csak Virtualboxban) "sajnos" vagy "halistennek" a mindennapi Desktop hasznalat kenyelmesebbe tetelehez is (egyik fele ket perc alatt osszedobott workaround script (mukodhetne jobban is de megoldom cimszoval a.k.a. Desktop Linux eve), masik fele viszont olyan, amit mas Unix-alapu rendszereken is eloszeretettel hasznalnek)
- A hozzászóláshoz be kell jelentkezni
+1
Ez a szavazas igy eleg ertelmetlen. En a "Linux"-ot valasztottam, mert ha scriptet irok akkor jellemzoen shell scriptet irok, es azt azert mert a jovoben is Linuxon akarom majd hasznalni.
- A hozzászóláshoz be kell jelentkezni
én sem értem pontosan a kérdést, meg a lényegét sem, de mivel linuxon írom, itthon is meg a cégbe is így nyílván linuxon próbálom ki a módosításokat :D
- A hozzászóláshoz be kell jelentkezni
Amire írom, azon.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Bezony. :) Perl és Bash fordul elő nálam shellben, PHP az CSAK weben. :) Illetve a bash one-liner jellegű sed/awk/xargs/grep -es quartet-et is szoktam alkalmazni, mert ágyuval nem szeretek verebet lőni.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Örömmel venném, ha szavazás indítója (pts) kifejtené, hogy mire gondolt a szavazás összeállításakor. Csak a kíváncsiságom kielégítése céljából.
- A hozzászóláshoz be kell jelentkezni
A szavazás kitűzőjeként arról akartam egy körképet kapni, hogy a hup-tagok milyen operációs rendszerre/rendszeren írnak szkripteket. Elsősorban Perl, PHP, Python, Ruby, Lua (és hasonló) nyelvekre gondoltam, de tágabban beleértettem a shellszkripteket, a JavaScriptet, a WSH-t, VBA-t és a PowerShell-szkripteket is. Sok szkriptnyelv több rendszeren is elréhető, például egy szövegfájlokat beolvasó Perl-szkript változtatás nélkül futhat többek között sokféle Unix-szerű rendszeren és Windowson is. Ebben az esetben arra voltam kíváncsi, hogy a fejlesztés során milyen rendszeren futtatja, próbálja ki a hup-tag programozó a szkriptet. Tehát nem az érdekel, hogy milyen rendszeren fut a text editor, amivel megírja a szkriptet, hanem az érdekel, hogy milyen rendszeren fut a szkript először, a fejlesztés során.
Persze egy ember élete során több rendszerre is írhat szkriptet, és az is lehet, hogy ugyanannak a szkriptnek a legújabb verzióit a fejlesztés különböző fázisaiban különböző rendszereken próbálja ki először. Sajnos hup-szavazás keretében ilyen részletességű választ nem lehet kérni, ezért aki sokféle szkriptet fejleszt sokféle rendszerre/rendszeren, az válassza azt a rendszert, amin az utóbbi időben a legtöbbet dolgozott, vagy ha még így sem egyértelmű, akkor ezek közül válasszon egyet véletlenszerűen.
Aki csak böngészőben futó szkripteket ír (pl. JavaScript vagy ActionScript nyelven), az ne szavazzon, mert ezek a nyelvek alapvetően rendszerfüggetlenek.
Aki egy webalkalmazás szerveroldali szoftverét szkriptnyelven írja, az arra a rendszerre szavazzon, amelyen a fejlesztés során használt webszerver fut.
Azért érdekel a szavazás eredménye, mert jelenleg egy szkritnyelv release-én dolgozom, és szeretném tudni, hogy a programozók hány százalékát érem el, ha csak Linuxra adok ki release-t (ami emulációval megy FreeBSD-n is), vagy ha csak Linuxra és Mac OS X-re adok ki release-t. Ha Linuxra, Mac OS X-re és Windowsra is adnék ki release-t, akkor szerintem a programozók 99%-át is elérhetném, viszont a windowsos release karbantartása túl sok munka lenne. Szeretném látni, hogy ez a sok munka hány százalék programozóért folyna.
- A hozzászóláshoz be kell jelentkezni
Most akkor mit is csinalsz?;)
Elsore add ki POSIX-ra (ugy, hogy forduljon linux alatt is, BSD alatt is, meg Mac alatt is), windowsra raersz...
A mai nagy nyelvek (perl, python, php, ruby) kezdetben nem rendelkeztek windows valtozattal, 5-10 ev kulonbseg van az elso release es a windowsos kozt.
- A hozzászóláshoz be kell jelentkezni
ne csinálj windows releaset, mert azzal csak segíted az életbenmaradását
------------------------------------------
Egyetlen vi-parancsot ismerek, a kilépést.
- A hozzászóláshoz be kell jelentkezni
Istenem...
- A hozzászóláshoz be kell jelentkezni
troll detected.
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
"amivel megírja a szkriptet, hanem az érdekel, hogy milyen rendszeren fut a szkript először, a fejlesztés során."
Erről az jut eszembe, amikor phpistuka megírja az ultraeditjében FTP kapcsolattal a PHP scriptet... Léccineeeee...
"Aki egy webalkalmazás szerveroldali szoftverét szkriptnyelven írja, az arra a rendszerre szavazzon, amelyen a fejlesztés során használt webszerver fut."
Természetesen csak és kizárólag azon a gépen amin dolgozok. Az OS meg lényegtelen.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Ezesetben 50-50% Linux és Windows. Melóhelyen Linux van, ott is írok egy rakás scriptet (amit aztán soha senki nem fog Windowson futtatni), itthon Win7 alá pötyögök Python scripteket, és nem viszem őket Linuxra, mert nem használom.
Amúgy miért olyan problémás karbantartani a Windowsos releaset? Tényleg érdekel.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Amennyiben a *nix adminisztrátorok a célcsoportod, jó helyen kérdezed, de itt nincs sok értelme rákérdezni a Windowsra. Végezz hasonló felmérést a PCForum, HWSW, vagy prog.hu közönségének a körében, és akkor meg Windows alatt lesz annyi, mint itt Linux alatt…
int getRandomNumber() { return 4; } // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni
Szia,
Azt mindenkeppen kell latnod, hogy ha egy rendszeruzemelteto leul szkriptet irni, akkor nem azert ir szkriptet, mert eppen jo neki, vagy mert eppen rossz, hanem azert, mert van egy adott rendszer, azon van egy adott feladat amit meg kell oldani.
Ezzel a kerdessel elsosorban azt mered fel, hogy a valaszadok korulbelul milyen rendszereken dolgoznak - amire viszont ott volt a reprezentativabb HOVD szavazas, meg jobb a DistroWatch-on nezelodni.
A kerdes feltevese ott hibas, hogy azt feltetelezed, hogy egy script az csak ugy szuletik, a semmibol, holott ez boven nem igy van. En a kerdest ugy fogalmaznam meg, hogy: "Amikor scriptet írok, általában ezen a rendszeren teszem:"
ez ugyanis sokkal inkabb rautal arra, amit kerdezni szeretnel.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Általában PHP és AJAX scripteket írok és Chromeban próbálom ki :)
- A hozzászóláshoz be kell jelentkezni
mi az az AJAX script? (szerintem javascriptre gondolsz)
Tyrael
- A hozzászóláshoz be kell jelentkezni
PHP az tudtommal a web server kozeleben fut, de semmikeppen nem a bongeszoben :) Szoval csodalkoznek, ha ott probalnak ki. AJAX script meg imho nincs, az max egy technika inkabb, es scripting reszben javascript-et hasznal.
- A hozzászóláshoz be kell jelentkezni
Bauxit főzeléken.
- A hozzászóláshoz be kell jelentkezni
Érdekes kérdés, hisz gondolom sokan nem férnek hozzá "egyéb kereskedelmi Unix" -okhoz...
- A hozzászóláshoz be kell jelentkezni
Általában, mostanában HP-UX-ra írom őket. Volt olyan, (Perl CGI) amit eszközök hiányában ott írtam meg, de Linuxon (VirtualBox) tudtam csak kipróbálni, tesztelni (Apache + mod_perl). Szóval egyéb kereskedelmi UNIX és általában (>=90%) Korn Shell 88 || 93.
--
A gyors gondolat többet ér, mint a gyors mozdulat.
- A hozzászóláshoz be kell jelentkezni
részemről mac-en írom, linuxra töltöm fel, ezért feltételezem, hogy a php-t linuxon próbálom ki, a js meg marad mac-en ugye
*nyomokban mogyorót tartalmazhat*
- A hozzászóláshoz be kell jelentkezni
Szerintem itt a delikvens batch scripting-re gondol, nem arra, hogy a dinamikus nyelveket egyesek 'scriptnyelvnek' becezik.
(Reszemrol foleg linux, hiszek a 'fejlesztoi szerver' kifejezes letjogosultsagaban)
- A hozzászóláshoz be kell jelentkezni
A fenti hozzászólásomban felsoroltam, mely nyelvekre gondolok.
- A hozzászóláshoz be kell jelentkezni
altalaban az osszes interpreteres nylvere gondolnak szerintem amikor script nyelveket emlegetnek. ezzel a "cserevel" en sem ertek egyet.
- A hozzászóláshoz be kell jelentkezni
Fejlesztői szerver az, amikor a fejlesztők kapnak egy vasat tesztelésre, játszadozásra... Aki szerveren fejleszt, sikeres ember nem lehet.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Pedig szeretnem hinni, hogy az vagyok ;)
Nagyon sok problema szokott lenni a harom ember jon 3 os-sel, 4 editorral, meg 5 php-configgal esetbol.
Erre anno az volt a megoldasunk hogy volt egy szerver, amin popecre, elessel megegyezo modon belott config, es mindenkinek 2 virtualhost jatszani, plusz qa virtualhost.
En speciel szeretem, hogy screen -ben fut a vim, lelovom a laptopot, aramszunet vagy barmi van no para, naponta backupolt fejlesztoi env ami nem erzekeny a kliens oldali osszeomlasra.
Ez nem azt jelenti, hogy kozvetlenul az eles rendszert turkalom, csak azt hogy nem tartok fenn mindenkinek kulon envet, mert az - plane a 'windowson fejlesztunk, linuxon hostolunk' esetben - gigamegaszopas n > 1 fejlesztonel.
- A hozzászóláshoz be kell jelentkezni
Valahol ezt csak egyszer kell meglepned es masnap mar be se kell menned dolgozni. Aki a production szerveren fejleszt, teszteli a sajat szar scriptjet az mar jo uzemelteto nem lehet. Erre tartanak kulon dev,test,production kornyeztet ,hogy mielott bar mi elesbe menne elotte tuti le legyen tesztelve.
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
"elessel megegyezo modon belott config" ... "Ez nem azt jelenti, hogy kozvetlenul az eles rendszert turkalom, csak azt hogy nem tartok fenn mindenkinek kulon envet,"
Ez a resze megvolt a hozzaszolasnak? Mert igy mar korrekt
- A hozzászóláshoz be kell jelentkezni
egyes, leulhetsz.
Tyrael
- A hozzászóláshoz be kell jelentkezni
Aha. Lattom azert Te is hozza tudsz szolni a temahoz :).
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
hát, te meg ráharaptál erre az elcseszett témára....
Akinek külön teszt szerver kell, hogy az egysoros bash/sh/ksh/csh/tcsh (shell) scriptjeit kitesztelje, mert képtelen biztonságosan tesztelni, az már jó üzemeltető nem lehet. :)
A dev/test/prod szerver szép dolog, de 15 év szakmai tapasztalata az, hogy még a legnagyobb multicégnél sincs mindig erre lehetőség.
- A hozzászóláshoz be kell jelentkezni
A több évtizedes tapasztalat miatt egyes? wtf?
------------------------------------------
Egyetlen vi-parancsot ismerek, a kilépést.
- A hozzászóláshoz be kell jelentkezni
Erre anno az volt a megoldasunk hogy volt egy szerver, amin popecre, elessel megegyezo modon belott config, es mindenkinek 2 virtualhost jatszani, plusz qa virtualhost
...
Ez nem azt jelenti, hogy kozvetlenul az eles rendszert turkalom
vs.
Valahol ezt csak egyszer kell meglepned es masnap mar be se kell menned dolgozni. Aki a production szerveren fejleszt, teszteli a sajat szar scriptjet az mar jo uzemelteto nem lehet.
remelem igy mar vilagos.
Tyrael
- A hozzászóláshoz be kell jelentkezni
bevallom, nem, úgyhogy kezdjük az elejéről.
1. ha hello world scriptet írok, akkor az természetesen mehet azonnal production környezetbe, de még ekkor is megnézetem valakivel, hátha kiszúr valamit (a legbrutálisabb hibákat pont az nem veszi észre, aki írja - gondolom, neked is volt már ilyen tapasztalatod). időveszteség 3 perc.
2. ha hosszú, vagy kevésbé átláthatóan dependál, akkor jobb a békesség, inkább vesztek 10 percet, de kipróbálom a játszótéren && (elolvastatom valakivel || 1).
------------------------------------------
Egyetlen vi-parancsot ismerek, a kilépést.
- A hozzászóláshoz be kell jelentkezni
1, ebben a szalban senki sem fejleszt direktben eles kornyezeten, es senki nem is irta, hogy ott fejlesztene.
2, detto
az egesz felreertes azon indult, hogy ki mit ert a fejlesztoi szerver fogalma alatt.
az egyik oldalon saxus azt mondta, hogy a fejleszto ne (fejlesztoi) szerveren fejlesszen, ott maximum csak tesztel (gondolom elsosorban teljesitmenyt, de majd megvalaszolja saxus hogy mire gondolt), a masik oldalon Aadaam dobta be, hogy o jobban szereti azt, hogy ha minden fejleszto azonos homogen fejlesztoi kornyezetben dolgozik, amit konyebb betartatni, hogyha ugyanazon a gepen van mindenkinek hozzaferese, ami kornyezet a leheto legnagyobb mertekben hasonlit az elesre, de semmikepp sem azonos vele (es nem is all vele kapcsolatban, es nem tartalmaz eles szenzitiv adatokat).
ezt ertette veletlenul/szandekosan felre o_O es valaszolt ugy, mintha barki is arrol beszelt volna, hogy eles kornyezetben fejlesztene direktben.
szemely szerint en is a tobb kornyezetes(dev, test/qa, staging, live) felallasban hiszek, ahol a fejlesztoknek van ezen felul egy sajat homokozo vmjuk is, de ez mar egyeni preferencia.
megfelelo konfiguracios menedzsmenttel (cfengine, chef, puppet izles szerint) illetve virtualizacioval tok jol tud mukodni szerintem (a staging akkor is fizikai szervereken fusson!).
Tyrael
- A hozzászóláshoz be kell jelentkezni
write-only voltam, mea culpa. így már értem, mi a helyzet.
------------------------------------------
Egyetlen vi-parancsot ismerek, a kilépést.
- A hozzászóláshoz be kell jelentkezni
Nah, akkor kifejtem, mert úgy látom, valóban félreértések vannak:
Alapvetően annak a híve vagyok, hogy játszon mindenki a saját kis homokozójában a saját gépén. Itt adjuk meg a fejlesztőnek a lehető legszabadabb munkakörnyezetet, ami a hatékonyságát segíti (ha pl. Eclipse-helyett NetBeansot akar, akkor használja. Persze, ha az IDE valami ökörséget felel, akkor ő oldja meg, ha nem tud, alkalmazkodik. És nyilvánvalóan logikus keretek között.)
Az adatok replikálása meg szintén nem egy megoldhatatlan feladat, lehet db build scripteket írni nagyon egyszerűen.
Az meg, hogy mi a futtatókörnyezet verziószáma, és hasonlók, szintén egy előre megbeszélhető dolog. Nálunk le van fektetve két környezet, azokra fejlesztünk. (Azért kettő, mert a régebbi mellé bejött egy újabb verzió, de ez nem okoz problémát, hisz projektenként fix, hogy melyik. Az meg ritka, hogy 10 percenként váltogatna valaki a projektek között.) Ha meg valamely komponens patchlevel szintű frissítése romba dönti a fél rendszert... nos, az csak annyit jelent, hogy az a komponens fos. Röviden, tömören.
Viszont ennek a környezetnek a beállítása elsősorban a fejlesztést és a debuggolást segíti elő. Ezért is a rugalmasság. (Meg is őrülnék, ha pl. lenne 2 fix vhostom...)
Ettől függetlenül nyilvánvalóan nekünk is vannak -többnyire- VPS-k fejlesztési célokra, pl. tesztelésre, megrendelőnek kirakni a fejlesztés alatt áló rendszert, stb.), de itt nem szokásunk már össze-vissza taknyolni a kódot. (staging igazából méret/megrendelői igény kérdése - persze, az optimális az, amit írsz.)
Az, meg Windows és Linux és részt vesz a folyamatban... Nos, gyakorlatban ebből nem volt több problémánk, mintha csak Linuxon menne az egész. Legalább annyi problémánk volt abból, ha mondjuk Linux-OSX-FreeBSD között kell a kódot mozgatni, vagy akár -elvben ugyanolyan- Linux-Linux között is vannak néha furcsaságok. Ellenben az nagyon nem rossz dolog, ha valami platformfüggetlen. (Pl. nemrég kaptunk levelet az egyik megrendelőnktől, hogy szereztek szervert és nekik előnyösebb lenne, hogy ha Windows Serveren menne a jövőben az, ami most Linuxon fut. - Az élet nem csak abból áll mindenkinek, hogy a egy gépteremben van egy Linuxos szerver és oda lesz feltúrva minden...)
De C++-ban sem lehetetlen úgy fejleszteni, hogy az egyből portolható legyen Linuxra, csak hozzáállás kérdése. (Ha valakinek kell, mondok konkrét példát is.)
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Eztet en ertem, de ez outsourcing ceg volt, eclipse-netbeansbol mindenki azt hasznal amit akar (van rendes remote filesystem driver mindkettoben), viszont ilyen hogy db buildscript, meg db replikalas, hat ezeket a tobbszaz gigas [meta]adatbazisokkal azert nagyon el kell felejteni, nem veszunk minden munkaallomasba terras vinyot poenbol.
Es ugyanezert van az, hogy 'ja, a komponens szar, igen, ez van, enterspajz outszoszing, ezt kell hasznalni, ez van az ugyfelnek'.
(Mellesleg az egyik esetben ugyfel pure linux rendszereken fejlesztett, szinten devszerverrel, nem is ertette, mi az hogy XY kommersz cucc nem igazan akar windowson jol menni, merthogy nala sose letezett 3-4 (dev, qa, staging, prod) peldanynal tobb belole, mind popecre belove sokeves configolassal, meg a kliensei is linuxok voltak (nfs mount))
En egyebkent valahogy a remote debuggerrel (Xdebug) egyaltalan nem szivtam annyit mint ami az eclipse-be beepitve van localhostra, es azt szepen ugyfel is minden vhostra configolta.
De elotte is remote-oztunk, sajat magunknak, kis cegnel, es soha semmilyen gondot nem kellett forditani / egyeztetni a verziok miatt. Megerte
- A hozzászóláshoz be kell jelentkezni
es egy tengeri bajt az hany foldi bajt? :D (bocs)
- A hozzászóláshoz be kell jelentkezni
Érdekelne, hogy mi volt az a nagyon sok gigamegaszopás, ugyanis nálunk ezek a dolgok működnek. Jól.
Meg vannak határozva a konvenciók és projekt szinten le van fektetve, hogy ez a szoftver ez a verzió, stb.
Másrészt a pöccre megegyező konfig eleve nem opció fejlesztés során (pl. debugger és error reporting PHP esetén éles rendszeren nem igazán van...)
De biztos mi csinálunk valamit rosszul, hogy nekünk működik Linux, Windows, OSX és FreeBSD alatt is.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
+1
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
error_reporting jobb helyeken ugyanugy be van kapcsolva, csak a display_errors nincs bekapcsolva, helyette csak logolod a hibakat.
(php hibakezelese olyan szerencsetlenul van megirva, hogy hiaba nem kezelsz egy hibat, performance szempotbol ugyanugy lassit.)
http://seanmonstar.com/post/909029460/php-error-suppression-performance
Tyrael
- A hozzászóláshoz be kell jelentkezni
Egy nagyobb rendszert fejlesztettunk igy, mert egyes kollegak keptelenek voltak megbirkozni azzal, hogy devszerver. Volt benne master-slave DB, CDN, eAccelerator, mysql (tobb verzio), sphinx, ja es tobb terra adat, aminek a metaadata is tobb gigabajtban volt merheto
Sz.pasok:
- Verziovaltasok rulez, foleg SQL szervert ha fel kellett upgrade-elni, es mashogy ment patchlevelek kozt; kulon orom amikor a tarsasag fele nem upgrade-elte. (Volt hogy a php klienslibet is kellett volna upgrade-elni)
- Szinten nagyon jot tesz egy metaadat valtozas lekerese 5 gepre, meg az, ha a kollega sietett es nem update-elt egy hetig, aztan commitnal nez, hogy miert nem megy a QA gepen
- A PHP modulok nem _mindig_ viselkednek ugyanugy windows es linux alatt, including, but not limited to: eAccelerator, apd (persze egy-ket het mulva jon a peccs)
- A windowsos enterek kulon oromot jelentenek egy-egy rendszeren, csakugy mint az a kepessege, hogy kisbetu-nagybetu nem szamit (mi ugyan nem, de volt olyan lib, ami igen)
- Nem feltetlenul lehet barmilyen nagy rendszert beloni ugyanugy egy szimpla windowsra mint egy vm-farmra.
Szoval en ezt 2x eljatszottam eletemben egy amugy javas cegnel, hogy php fejlesztese 10-20 fos csapattal devszerver nelkul architektkent, azota koszonom szepen, se azokbol a cegekbol nem kerek, akik ezt nem tudjak elkepzelni, se magabol az elmenybol.
Barki nyugodtan sz.rraszophatja magat, ha en fejlesztek, egy env van, sandboxolva mindenkinek, oszt joccakat :)
- A hozzászóláshoz be kell jelentkezni
Kend miről beszél? Bizonyos fajta munkáknál akár igazad is lehet, de soknál meg nincs. Durván kiterjeszted a saját kis világodat.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Ritkán írok szkripteket, most viszont kísérletezek a Haikuval, így elsősorban azon próbálgatom.
- A hozzászóláshoz be kell jelentkezni
* Egyeb operacios rendszeren
Emacson.
--
|8]
- A hozzászóláshoz be kell jelentkezni
attól függ milyen scriptről van szó. egy .ps1 scriptet linuxon nem szoktak próbálgatni:)
- A hozzászóláshoz be kell jelentkezni
Miért nem? http://pash.sourceforge.net/
--
Don't be an Ubuntard!
- A hozzászóláshoz be kell jelentkezni
ez már használható is? ahogy nézem 3 éve sajnos nem nagyon nyúlt hozzá a fejlesztője.
- A hozzászóláshoz be kell jelentkezni
Meg ugy egyaltalan nem is sikerult mukodesre birni. Jo ez a google, csak idonkent hulyesegeket mond.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Elsődlegesen linuxon, Ubuntun, de azért mert PHP-t is itt fejlesztek. Ha lehet legközelebb legyen egyértelműbb a kérdés.
- A hozzászóláshoz be kell jelentkezni
Egyébként tökmindegy, hogy hol teszteli először, ott kell futnia helyesen, ahova szánják. (Pl. általában Windowson vagy OSX-n fejlesztek PHP-t, de a végső helye rendszerint Linux vagy néha FreeBSD. Na most volt már olyan, hogy Windowson nem nagyon teszteltem, szimplán azért, mert meg kellett hívogatni néhány Linuxos binárist is. Igaz, ilyenkor jön a virtualizáció a képbe.)
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
A célrendszerrel megegyező rendszeren vagy magán a célrendszeren. Milyen scriptet?
- A hozzászóláshoz be kell jelentkezni
Az attol fugg. Ha valami konkret problemara kell konkret megoldas, akkor akar a production kornyezeten is, bar akkor a scriptjeim merete nem szokta meghaladni az 5 sort, es ebbol ketto a shebang meg utana az ures sor, 3 pedig a ketszaznyolcvankilencsszer leutott parancs a historybol.
Ha valami komolyabbat kell fejleszteni, van ra kulon gepem, ott addig rugom a kodot, amig nem megy. De mondjuk en eleve ugy fejlesztek nagyobb kodokat, hogy feltonna if-et belerakok...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni