Category: Software

Pitanje iz naslova jedno je od najčešće postavljenih pitanja svršenih diplomaca ili ljudi koji ulaze u svet programiranja. Pitanje nije trivijalno iz jednostavog razloga što dobro odabrana tehnologija znači veće mogućnosti za pronalaženje posla, bolje plaćen posao, … u najkraćem – svetliju budućnost.

Sve do juče na pitanje iz naslova bez mnogo razmišljanja odgovarao bih – PHP. Jednostavno, PHP poslova uvek ima, PHP se relativno brzo nauči, tako da za relativno kratko vreme možete doći do posla. Čak i za one bez ikakvog iskustva, otvorenost Web platforme omogućava početnicima da naprave sopstveni sajt, sajt komšijine prodavnice, prijatelja … whatever … i tako za kratko vreme steknu kakve takve reference i iskustvo – stvar koju tako mnogo tražimo mi koji tragamo za kvalitetnim developerima.

Elem, pre nekoliko dana kolega iz FBM-a zamolio me je da otvorim novu poziciju za iPhone developere, nakon čega sam nažalost jako brzo saznao da se broj iPhone Developera u Srbiji može nabrojati “na prste” jedne ruke.

Međutim situacija u svetu a naročito u USA je dramatično drugačija. Broj downloada iPhone aplikacija na Apple Application Store-u bliži se cifri sa 9 nula, a trenutno na listi najprodavanijih knjiga na Amazonu u kategoriji Računari i Internet možete naći samo nekoliko programerskih knjiga, od kojih su apsolutno sve vezane za iPhone. Ista priča je i kada odete i na kategoriju Programming gde su tri od prvih pet naslova knjige o razvoju iPhone aplikacija!

iPhone Application Develpment Books

Nažalost cene Apple računara i nedostatak zvanične iPhone podrške u Srbiji i dalje je veliki problem u ovoj priči. No, za one za koje taj problem nije nepremostiv, današnji odgovor na pitanje iz naslova definitivno bi bio Objective C. Nisam siguran da ću čak i ja odoleti iskušenju …

Danas sam sticajem okolnosti bio u prilici da nakon duzeg vremena updatujem svoju klasu za detekciju browsera. Radi se o klasi koja omogucava detektovanje tacne verzije Browsera/OS-a na osnovu user agenta browsera.

Npr: Mozilla Firefox 3.0.4 / Mac OS X

Može biti od koristi u slučaju da želite da korisnike određenih browsera redirektujete na posebne strane, kod pravljenja sopstvene statistike korišćenosti browsera itd.

Update sadrži dodatu podršku za Google Chrome, iPhone i Windows Vista OS.

Kompletan kod sa primerima možete downloadovati ovde

Zbog prirode svog posla gotovo svakodnevno se bakćem sa raznoraznim php cli scriptovima. Često su u pitanju programi koji rade jako dugo (satima, neki čak i danima), ponekad praveći veliku količinu outputa, te zbog toga praktikujem da iste startujem unutar screen sesije, kako bih uvek mogao da se ponovo ulogujem u sesiju i bacim pogled kako stoje stvari.

Veoma je dobro logovati kompletan output skripta u fajl, za slučaj da je nešto pošlo naopako, ali nekako sam uvek voleo da onako “live” vidim na ekranu šta se dešava, umesto da mi ceo izlaz stoji u nekom tamo log fajlu. No, zahvaljući unix tee komandi i ovom postu, danas sam naučio da mogu imati obadva.

./script.php | tee out.log

Ovo će kreirati fajl out.log i usmeriti kompletan output scripta u njega, ali će isti biti prikazan i na ekranu (STDOUT). U slučaju da želite samo da dodate (append) output u postojeći log, nema problema:

./script.php | tee -a out.log

Ako ste ikada morali da backup-ujete ili prebacujete podatke iz jedne ili više MySQL tabela, znate da se za to koristi mysqldump utility, pomoću kojeg jednostavno podatke iz MySQL-a “dumpujete” u neki mojetabele.sql fajl, koji zatim možete sačuvati kao backup, prebaciti i importovati na neki drugi MySQL server, itd. Ovu proceduru koristio sam milion puta do sada, i ona se generalno svodi na izvršavanje sledećih komandi u linuxu:

export:

mysqldump -udinke -pmojpass -hhostname.prvog.servera ime_baze tabela1 tabela 2 tabelan > dump_fajl.sql

import:

mysql -udinke -pmojpass -hhostname.drugog.servera ime_baze < dump_fajl.sql

Tu i tamo pojavi se problem kada prebacujete dump sa novije verzije MySQL-a na stariju, i tada je poželjno specifirati i odgovarajući compability flag prilikom izvršavanja mysqldump komande (--compatible=name gde name može biti mysql323, mysql40, postgresql, oracle itd.).

Elem, pre nekoliko dana zbog prebacivanja MySQL servera sa jedne lokacije na drugu, morao sam da odradim dump solidno velikih MySQL tabela (10-tak tabela gde je svaka imala preko 2 miliona slogova). Nakon užasavajuće duge procedure dumpa, gzipovanja i scpovanja na drugi server, konačno sam startovao import. Međutim, nakon 3 sata (tri sata) umesto standardne "no news is a good news" poruke, kada sam bacio pogled na status dočekala me je sledeća poruka ...:

[dinke@um-917 ~/public_html]$ mysql -udinke -p325ewfwt23rasf
keyword_discovery < es_miner_data.sql
ERROR 1582 (23000) at line 163833: Duplicate entry '1167548' for key
'PRIMARY'

WTF? Prebacivao sam podatke sa starije verzije na noviju, što znali da import mora proći glatko! Ovo bi trebalo da znači da je MySQL negde nešto pobrljavio sa indexima, i umesto da čekam još 2 sata da se odradi check & repair, odlučujem se da napravim ponovo dump fajl, ovaj put sa ignore opcijom, kako bi svi inserti u dump fajlu bili "insert ignore" tako da u slučaju ovakve greške ne bi došlo do pucanja. Ne preterano pametno, ali podaci nisu extremno osetljivi i mogu da dozvolim luksuz da izgubim desetak slogova, ali ne i desetak sati za import!

Naravno, novi dump, zip, scp ... to je traajalooo ... toliko dugo da sam posle par sati nakon startovanja importa krenuo da mozgam sa administratorom (kuki) oko alternativnih rešenja. A rešenje je bilo jednostavno ali efikasno. Prekopirali smo sve MySQL data fajlove sa jednog servera na drugi (*.MYI, *.MYD i *.frm fajlove), a zatim odradili myisamchk kako bi sredili pomenute tabele, jer nismo smeli da spuštamo server prilikom backup-a što generalno može da prouzrokuje dosta problema (tipa oštećene tabele) ako se na ovaj način backupuju fajlovi.

Sve u svemu, ova operacija prošla je jako brzo (najduže je trajalo kopiranje fajlova sa jednog hosta na drugi), i za manje od pola sata cela procedura bila je završena.

Zaključak do koga smo došli je da je kod velikih tabela zbog dužine trajanja operacije dumpovanje praktično neprihvatljivo kao backup rešenje, i da se samim tim kao jedino rešenje nameće kopiranje MySQL data fajlova. Kod MyISAM tabela to nije nikakav problem, jer su one "platform safe", tj. binarni fajl kreiran na jednoj platformi (recimo *.MYI fajl na linuxu) radiće bez ikakvih problema na drugoj platformi (recimo isti *.MYI fajl na Windowsu).