Jump to content
php.lv forumi

Maris-S

Reģistrētie lietotāji
  • Posts

    634
  • Joined

  • Last visited

Everything posted by Maris-S

  1. Gaišs fons ir mazāk nogurdinošs. Uz tumšu skatoties acs zīlīte paplašinās uzņemot vairāk starojuma. Par papīra lapu gan nezinu. Man personīgi mājas lapas ar tumšu fonu ir nogurdinošas acīm, pie tam ļoti jūtami.
  2. Jā, to varētu tā atrisināt, bet tad vēl paliek html dažādu tagu nosaukumu vai identifikatoru pārklāšanās. Piemēram, ir veikals, kuram kaut kur headerī ir login forma, ar input lauku nosaukumiem "email" un "password", tad vēl arī tiek atvērta kaut vai "Forgot password" sadaļa, kurā arī ir lauks input, ar nosaukumu "email". Sanāk kopējā html parādās divi input lauki ar vienādu nosaukumu. Varētu arī sanākt tā ka izsauktajos kontrolieros vairāki elementi pārklājas, ne tikai input lauku nosaukumi, bet arī tagu ID, kam ir jābūt unikāliem, kut vai: <div id="menu"></div> priekš augšējā un sānu menu. Protams šie ir primitīvi piemēri un šeit tam varētu salīdzinoši vienkārši izsekot līdzi. Arī MVC tas viss jāņem vērā, bet HMVC, iekļaujot kontrolierus vienu otrā, varētu sanākt jau ne tik vienkārši to visu atcerēties, īpaši ja lietojumu izstrādā komandā. Vienīgais kas nāk prātā ir izmantot, precīzākus nosaukumus un id, piemēram "top_menu", "left_menu", "login_email", "forgot_password_email" utt. Vai tomēr esmu vēl ko palaidis garām?
  3. Īss un saprotams apraksts par dependency injection, ieskaitot dependency injection container. http://fabien.potencier.org/article/11/what-is-dependency-injection Iespējams kādu ieinteresēs.
  4. Nē, CRUCIAL. :) Pie SMART viņš rāda apmēram to pašu ko jebkurš cietais, bet nebija nekas tāds, kas liecinātu par kādiem defektiem, kas varētu izraisīt tādas problēmas. Tagad nopirku Samsungu, redzēsim cik šis noturēsies. :)
  5. Īstenībā ar SSD var būt dažādi brīnumi, kurus sarežģīti atklāt. Man pašam nesen nocepās SSD. Defekts bija interesants, strādāja kādu pus stundu un tad vienkārši nobruka, linuksis tajā brīdī pārmountēja root failu sistēmu uz read only, tā arī sapratu ka problēma ir ar SSD. Pēc restartēšanas viss ir tā pat, pastrādā kādu laiku un nobrūk. Es mēģināju skatīties SMART informāciju, bet arī tur neko jēdzīgu neuzrādīja. Paskaties sev to SMART, kaut ko iespējams arī varēs uzzināt.
  6. Sveiki! Šajā forumā jau ir runāts ap un par tulkošanu php, izmantojot gettext. Arī pats dažreiz esmu piedalījies šajās diskusijās, bet līdz šim nesanāca atrisināt labi zināmo problēmu, ja primārai valodai viens un tas pats vārds varētu tikt tulkots dažādi. Piemēram angļu "name" varētu tikt tulkots uz latviešu valodu kā "vārds" un kā "nosaukums". Tā kā primārās valodas teksts veido unikālu identifikatoru, tie tiek iztulkoti visur vienādi. Zināmākais risinājums, kas tiek piedāvāts, lai atrisinātu šo problēmu, ir tādu kā mainīgo lietošana primārās valodas vietā. Šis risinājums tiešām atrisina problēmu, lai gan man personīgi viņš nepatīk, jo tiek zaudētas labākās gettext lokalizācijas iespējas. Izmantojot primārajā valodā atbilstošo tekstu, nevis identifikatorus, sistēma izvadīs primārās valodas tekstu, ja tas nebūs iztulkots, taču izmantojot identifikatorus, tiks izvadīts identifikators, kas nebūs tik smuki. Vēl viens trūkums ir ērtība pie tulkošanas. Izmantojot identifikatorus pie primārās valodas būs attēloti identifikatori, kas padarīs tulkošanu neērtu un laikietilpīgu. Izrādās tam ir risinājums, kas nav iekļauts php. Tā ir iespēja izmantot kontekstu, lai norādītu kādā kontekstā ir jātulko vārds. Vienkārši izsakoties tas nozīmē pielikt unikālu identifikatoru tur, kur tas ir nepieciešams, nemainot pašu primāro tekstu. Problēmas risinājumu var apskatīties šeit, pie apraksta konteksta izmantošanai: https://developer.mozilla.org/en-US/docs/gettext Arī php dokumentācijā, lietotāju komentāros: http://php.net/manual/en/book.gettext.php Iespējams kādam noderēs.
  7. Kavacky, paturpinot piemēru, pieņemsim ka mājas lapa kā tāda ir taisīta tā, lai labajā pusē vienmēr ir jaunākās ziņas, gan tad kad ir atvērta kāda preču sadaļa, gan tad kad atvērts lietotāja profils utt. Tagad tiek atvērta parastā sadaļa ar preču sarakstu un tiek izsaukts kontrolieris: ShopController::SowProductsAction(); kas attēlo produktus, preču saraksts tiek nolasīts no datubāzes un piešķirts skata mainīgajam: $this->view->item_list Pašā skatā tas attēlojas, piemēram ar: echo($this->item_list); Tagad pieņemsim ka tiek izmantots HMVC un lai labajā pusē attēlotu jaunākās ziņas tiek izsaukts: Common::ShowNews(); kas neko nezina par ShopController, iegūst jaunākās ziņas un piešķir savam skata mainīgajam: $this->view->item_list un ziņu skatā attēlo to mainīgo: echo($this->item_list); kas ir tāds pats kā preču sarakstam. Kā jau teicu es iespējams kļūdos, jo neesmu pētījis kā īsti HMVC atrisina šo problēmu, iespējams ka tur ir savi risinājumu un iespējams ka tie ir labi risinājumi. To būs jāpapēta nākotnē. Līdzīgas problēmas ir arī MVC, ja vienkārši kontrolierim _init() metodē iekļauj common.php, bet šajā gadījumā tas ir tikai viens fails un vienmēr sākumā, bet ja tiek izmantots HMVC, tad kontrolieri var tikt iekļauti viens otrā jebkādā secībā un jau nav tik vienkārši izsekot visam tam līdzi.
  8. Nu pirmais kas ienāk prātā ir jādomā par mainīgo nosaukumiem, lai tie nepārklātos. Bet es varētu šeit arī kļūdīties, neesmu pētījis kādas ir pieejas, lai to atrisinātu. Nu un arī pieradums. Pašreizējam projektiņam nav laika pētīt un pārtaisīt uz HMVC, bet nākotnē būs jāpaskatās. :)
  9. daGrevi, tieši tā. Runa iet tieši par to ko atgriež kontrolieris, tam ir jābūt kontrolierī, nevis kaut kur citur. Piemēram, datus, kas tiek iegūti no datubāzes un padoti tālāk skatam. Tur arī sanāk ka bieži dažādiem kontrolieriem ir kādi pilnīgi vienādi dati un darbības, piemēram kontrolieriem user, shop, news, utt., visiem ir jādabū no datubāzes kāda pilnīgi vienāda informācija. Piemēram, ir pieprasījums: mana_lapa.lv/lv/news/show/ziņas-virsraksts Te var redzēt ka tiks izsaukts NewsController::ShowAction() un jā, viennozīmīgi viņam ir jāizpilda sava darbība, jāatgriež ziņa "ziņas-virsraksts", bet tā pat izsauktajam kontrolierim ir jādabū no datubāzes papildus informācija: valodas, visi menu, visādi jaunākie produkti kaut kur sānā, vai akciju preces, ja tas ir veikals, vai vēl visāda informācija. Ar tādas informācijas attēlošanu protams nodarbojas skats, bet ar datu, kuri tiek iegūti caur modeli no datubāzes, nosūtīšanu uz skatu nodarbojas kontrolieris un šeit tiek izsaukts tieši NewsController. Protams to varētu atrisināt ar HMVC mazliet savādāk, bet to es negribu izmantot, tur savi trūkumi ir arī.
  10. Simpsons, Tu laikam manis sarakstīto izlasīji neuzmanīgi. :) Domāju diskusiju pēc manis norādītās saites arī neizpētīji. Pie tam populārākais nenozīmē labākais. Es arī nejautāju par popularitāti. Kam Singletons domāts es arī labi zinu un arī lasījis par to esmu. Kā jau teicu vairāk iet runa par kvalitāti un vai ir vērts viņu izmantot. Saitē norādītajā diskusijā var redzēt, ka programmētāju vidū tādas izteikti labas atzinības Singletonam nav un tur ir arī savi pamatojumi tam. Par to arī iet runa, nevis par to, kas tas ir un cik viņš ir populārs. Jebkurā gadījumā paldies par atbildēm. Ērts tas Singleton ir, bet būs laikam pagaidām jāatturas no viņa. Jāpiekrīt arī Codez, ka php varētu izmantot dažus globālos mainīgos, jo tā pat daži jau tur ir.
  11. Paldies par atbildēm! daGrevis, te doma ir ne tikai par vizuālo attēlošanu, tie menu ir tikai piemēri. Būtībā vairāk iet runa par pašiem kontrolieriem un to darbību, tas kā viņi dabū datus, piemēram menu no datubāzes, vai arī ieraksta datubāzē, vai veic kādas vispār ar db nesaistītas darbības. Vēl varētu būt arī darbības kā rezultātam nevajadzētu attēloties skatā, tā uz ātro, kaut vai apmeklējuma counteris.
  12. Sveiki! Pameklēju pa internetu dažādas atsauksmes un diskusijas par Singleton modeli. No vienas puses tas ir ērts, bet no otras puses ir negatīvas atsauksmes. Piemēram šajā diskusijā: http://stackoverflow.com/questions/4595964/who-needs-singletons lielākā piekrišana ir tieši viedoklim, ka Singleton labāk neizmantot (atbilde no Gordon). Tā nav vienīgā diskusija kur tiek izcelti Singleton trūkumi, īpaši uz php un bieži vien tādiem komentāriem ir diezgan liels atbalsts, kas liek secināt ka daudziem programmētājiem viņš nepatīk. Gribēju pajautāt ko Jūs domājat par Singleton un vai bieži izmantojat? Codez, zinu ka Tu izmanto viņus, vai ir sanākušas kādas problēmas darbojoties ar Singleton modeli? Paldies!
  13. Labdien! Gribēju pakonsultēties par labākām pieejām, kā iekļaut kopējo skriptu dažādos kontrolieros? Kopējais skripts varētu izvadīt tādus datus kā dažādus menu, piemēram augšējo un sānu menu, valodas utt. Kā un kur pareizāk un ērtāk būtu iekļaut šo kopējo skriptu? Rakstīt katram kontrolierim, piemēram Controller::_init() metodē to visu būs kopēšana, vēl iespēja būtu iekļaut kādu common.php tai pašā Controller::init() metodē, piemēram: class UserController extends controller { function _init() { require_once('path/to/common.php); } function ProfileAction() { ..... } } Viss tas strādā, bet sanāk ne visai smuki pašā common.php failā, jo ārpus objekta parādās, piemēram: $this->view->languages = $page->get_languages(); $this->view->main_menu = $page->get_menu(); Kādas būtu labākās pieejas, lai visu to savienotu kopā? Paldies!
  14. Nē, pārāk daudz nav, kad izslēdz webmin. :) Vispār minimāli. Rakstīju webminam sourgeforge forumā, bet viņi neatbildēja. Kaut kas vai nu pašam webminam, vai arī python. Tā kā webmin nav bieži vajadzīgs, tad arī var ieslēgt caur ssh kad viņu vajag. Par tām vērtībām es arī īsti nesaprotu, sīku aprakstu tā arī neatradu. Ko tie burtiņi beigās nozīmē tā arī nesapratu, piemēram 700.0m, vai arī 86u, vai arī vērtība vispār bez burta. Neesi kaut kur redzējis aprakstu?
  15. Paldies par valodu salīdzināšanu. Jā, delphi būs mazāk bibliotēku, ko arī pieminēju kā lielāko mīnusu šai valodai. Taču tas man neliek domāt ka tā valoda ir pielīdzināma tikai mācību valodām un nelietojama. Ja viņa būtu nelietojama, tad viņu arī neviens nelietotu. Nu labais, nav nepieciešamība atbrīvot atmiņu! :) Tā ir laba pieeja, saveidojam kaudzi objektu un atstājam atmiņā, ir taču garbage collector! :) Nu nezinu, laikam moderniem programmētājiem ar modernām valodām tas liekās normāli. Pareizi, priekš kam veidot kvalitatīvu programmas darbību, ja var to nedarīt? Tikai kāpēc tad memory leaks vienmēr tiek uzskatīts par bugu, kurus vienmēr labo? Ir taču garbage collectors. Problēma ir tur, ka lielākai daļai programmēšanas valodu nav rīku, lai tādus bugus vismaz mēģinātu izķert izstrādes gaitā, nevis tāpēc ka modernajās valodās to nevajag darīt. Protams ka FastMM varēs atrast memory leaks tikai Tavā programmā. Viņš arī paredzēts, lai tos atrastu delphi kodā. Viss ir ļoti pareizi, FastMM atrod memory leaks un parāda kur kodā tas notiek. Kā Tu iedomājies to izdarīt ar dll, kur nemaz nav programmas izejas kods? Tas kas notiek dll ir dll ražotāja atbildība. Es nesaku ka programmētājam nav nepieciešams pārliecināties par izmantojamo dll kvalitāti, protams tas ir jādara, bet primāri par to kvalitāti ir jārūpējas tam, kas to dll ir programmējis un viņam būtu jārūpējas par tādu kļūdu atrašanu savā programmā, ko ražotājs arī parasti dara. Kā viņi to dara tai pašā C es nezinu, bet parasti jēdzīgi ražotāji labo bugus savos produktos, tai skaitā memory leaks. Vai es tomēr kaut ko ne tā saku? Kā jau teicu lazarus/delphi būtu mana personīgā izvēle, īpaši veidojot lietojumprogrammatūru, nevis to, ka šīs būs vienīgās pareizās valodas.
  16. Codez, kuras tad ir tās labās valodas Tavā skatījumā? Kur tieši ir tā kritikas būtība uz pascal valodām? Vai tiešām tas ko Tu teici: "komponenšu trūkums izsaka visu"? Tad kurā no valodām ir pilnīgi viss? Es tiešām neesmu pētījis visas programmēšanas paradigmas uz delphi, man nebija vajadzības izpētīt pilnīgi visu, bet es nedomāju ka ir kāda valoda kurā būtu viss. Sarežģīta testēšana gan laikam nebūtu par pascal valodu. Es uzskatu ka tai ir viena no lasāmākajām sintaksēm. Arī IDE atkļūdošanas rīki ir pietiekami attīstīti. Arī iespēja atklāt memory leaks izstrādes gaitā nav mazsvarīga pie atkļūdošanas, kas nav izveidota tai pašā C, vismaz man nav zināms par tādu. Pielaist kļūdas var jebkurā programmā, lai arī cik moderna būtu un tāpat var sarakstīt kodu, kas nebūs viegli lasāms un atkļūdojams. Šajā ziņā nesaskatu pascal valodu kā nepilnīgāku par citām.
  17. Kārtējais jautājums. Kā būs ar atbildēm uz manējiem? :) Par ORM, nav ne mazākās nojausmas, jo es viņus neizmantoju, kad vajadzēs, tad meklēšu. Par to kāpēc man nepatīk ORM, vismaz uz php, jau rakstīju kādā no atbilstošajām tēmām šajā forumā. Uz ātro meklējot: http://delphi.wikia.com/wiki/Enterprise_Core_Objects http://delphi.about.com/od/toppicks/tp/orm-object-relational-mapping-delphi.htm Kārli, nevajag taču tā kritizēt bez pamatojuma. Uzdodot kādam jautājumus, atbildi arī uz Tev uzdotiem. Tas, ja nebūtu kāds izveidojis ORM, nenozīmē ka programmēšanas valodai ir mazāk iespēju vai tā ir neefektīva. Arī php nav ideāls un ko man tagad darīt, visu pārprogrammēt, tikai tāpēc ka tur kādas nianses nav, piemēram UTF-8 failu nosaukumu atbalsts (windowā), par ko biju minējis jau iepriekš šajā forumā?
  18. Tieši tā, nekādas jēgas no strīdēšanās par to kura valoda ir labāka nebūs, tāpēc arī neteicu ka paskāls ir vienīgā pareizā un tur var izdarīt visu, bet citās valodās nevar. Vēl vienu jautājumu Tu man uzdevi, bet uz manējo tā arī neatbildēji. Lai nu būtu, par darbu un iespējām. Ja Tu būtu lasījis uzmanīgi ko iepriekš rakstīju, tad būtu sapratis ka tieši Java valodu uzsvēru kā gan perspektīvu, gan labi atalgotu. Ar delphi/lazarus iespējams ir salīdzinoši mazas, pareizāk sakot te jārunā par delphi, neesmu vēl redzējis sludinājumus kur prasītu lazarus, bet ja mācēsi vienu, tad mācēsi arī otru. Delphi programmētājus meklē salīdzinoši maz, bet ja meklē, tad nemaz tik viegli nevar atrast. Nesaprotu kāpēc vispār tāds jautājums, jo nekur neteicu ka delphi vai lazarus būtu perspektīvāks darba iespējās par to pašu java vai C? Es taču skaidri teicu to, ka tā būtu mana personīgā izvēlē, nevis ka tā būtu vienīgā pareizā, arī uzsvēru, ja valoda ļautu sasniegt to ko vajag, protams sasniegt var visu, bet jādomā arī par to cik vienkārši to sasniegt un vai ir jau gatavi risinājumi citās valodās. Par to kāpēc es personīgi izvēlētos lazarus nevis delphi, es arī pateicu, jo tas ir open source un darbojās uz linuks. Vispār tā arī nesaprotu no kurienes ir tāds mīts, ka pascal ir nemoderna, paredzēta tikai mācībām valoda, kas ne visu var paveikt? Neviens nevienā no tādām diskusijām vēl nav pamatoti to argumentējis.
  19. Codez, kā konkrēti Tavs redzējums uz programmēšanas valodas modernismu būtu attiecināms uz pascal, pareizāk sakot kas tieši pašā pascal valodā kā tādā nav atbilstošs mūsdienu programmēšanas paradigmām? Ko Tu gribēji pateikt ar problēmu atrisināšanu bez "caurumiem"? Varbūt tagad vēl mēģināsi iestāstīt ka ar paskālu var programmēt kā grib un vienalga programma būs caurumaina? Ja, piemēram, pascal salīdzina ar to pašu C, tad pascal ir stingrāka un lasāmāka valoda un pielaist neuzmanības kļūdas C ir daudz vienkāršāk. Pielaist dažādas kļūdas ir iespējams visur, taču apgalvot ka programmējot ar pascal kods būs caurumains tikai pašas programmēšanas valodas dēļ ir absolūta muļķība un no programmētāja ar lielu pieredzi kāda tā ir Tev (vismaz pēc foruma tā izskatās) tādu domu gājienu sagaidīju vismazāk. Kas tieši pascal valodā ir tāds, ka tur nevarētu atrisināt problēmas bez "caurumiem"? Kārli, ko tieši? Īpaši ja iet runa par lietojumprogrammatūru, nevis, piemēram, par draiveru programmēšanu, kaut arī tas būtu iespējams, tikai vai to būtu pareizi darīt ar pascal, tas jau ir cits jautājums.
  20. Kavacky, Codez būs sarežģīti kaut ko iestāstīt. :) Bet nu visumā, lazarusā salīdzinoši ar delphi un C būs mazāk komponenšu tas ir pilnīgi saprotams, lai gan katram uzdevumam jāskatās kas ir nepieciešams un kā to risināt un vai var atrisināt. Par to ko Tu jautāji vari palasīt dokumentācijā. Es arī varu izrakt kādu niansi kas nav tai pašā C un bļaustīties ka viss ir nemoderni, piemēram tas pats FastMM analogs cik zinu tā arī nav sataisīts priekš C (nejaukt ar garbage collector), ja tomēr ir sataisījuši, tad piedošanu... Lai gan visā tajā kritikā mani interesē cits, kas Tev ir "diezgan moderna programmēšana"? Kur tieši izpaužas modernums programmēšanā? :)
  21. Lasījis par to esmu, mēģinājis neesmu. Tomēr cik saprotu autors runā tieši par desktop lietojumu, kas var izmantot tos lietotājus, kas ir web lietojumā. Realizācijas jau var būt dažādas, gan informācijas apmaiņa caur http protokolu, gan pieslēgšanās pa tiešo pie datubāzes, kas laikam nebūs labākais apskatot to no drošības viedokļa, gan paša programmēta klienta/servera struktūra. Web lietojumu izstrādāšanu paskālā sen jau gribas papētīt, bet nevaru saņemties. :) Desktop lietojumu programmēšanai lazarus un delphi ir ļoti labi, neviena sakarīga pamatojuma kāpēc pascal būtu nederīgs programmēšanai tā arī neesmu redzējis. Pats dodu priekšroku lazarus, jo ir open source un strādā arī uz linuksa. Trūkums ir ne tik plašs komponenšu klāsts kā gribētos.
  22. Domāju Java būtu laba izvēla, jo cik saprotu, Tu esi gatavs ņemt to kas vēl nav apgūts un mācīties. Java ir gan perspektīva, gan labi atalgota, gan arī atbalsta daudzas platformas. Iemācīties Java būs tikai par labu. QT bāzēta programmatūra arī atbalstāma. Tā arī derēs gan windows, gan linukšiem, nezinu cik viņiem labi ir uz mobilām iekārtām, sākotnēji jau QT toolkitu izstrādāja Nokia, bet ko tieši no mobilajām iekārtām viņi atbalsta gan nezinu. Programmēšanai QT ir ļoti labs IDE - QT Creator. Personīgi es izvēlētos lazarus, īpaši maziem lietojumiem, protams ja viņam pieejamās komponentes ļautu sasniegt to, kas nepieciešams. Palieku uzticīgs Paskālam. :)
  23. Codez, nav tik vienkārši. Protams, tas ko Tu raksti ir pareizi, ja Tev mājas lapā apmeklētājiem ir iespēja iesūtīt attēlus un Tev pie attēliem ir pievienota iespēja sazināties ar administrāciju, lai informētu par autortiesību pārkāpumiem, tad jā. Tomēr, ja Tu taisi, piemēram, mājas lapas dizainu, tad tās īpašnieks ir atbildīgs par to, kas ir dizainā. No jautājuma autora īsti nevar saprast, kā viņš izmantos tos attēlus, bet tā kā te ir pārsvarā web izstrādātāji, tad pieļauju ka tas varētu būt dizains. Attēlus tiešām ir lētāk nopirkt, parasti viņi ir samērā lēti.
  24. Maris-S

    iPhone IMEI nr

    Nu tas tiešām nav saistīts ar IMEI.
×
×
  • Create New...