jurchiks

Tu un kaimiņu Vaņka sanāc kopā un pasludini sevi par ekspertu vistu pārošanā. Pēc tam tu izdod standartu, kā jāpāro vistas. Vistu audzētāji tevi nosauc par dumju un pieklājīgi ignorē. 

Tad jau tev jebkuri standarti pie dirsas? Kā atšķiras citi standarti no šiem?

Nu paskaties dateks lapā, gan filtriem, gan lapai ir savs scroll bar, jo filtri neielien jebkurā gadījumā. Man vienkārši tie scrollbari ir citur - nav filtriem, ir produktiem, lapas scrollbar paliek kā bijis.

Ir tāda pastulba problēma (precīzāk sakot, problēma nav man, bet priekšniekam). Daudzi no jums laikam zina, kā izskatās, piemēram, dateks.lv produktu lapa - ir (ļoti) garš produktu saraksts un blakus filtri, kuri slaido pakaļ, kad skrullē ekrānu.

Tajā lapā, kuru patreiz taisu, ir uztaisīts līdzīgs dizains, tikai filtri ir statiski un produktu bloks resaizojas kopā ar filtru bloku (atkarībā no atvērtajiem/aizvērtajiem filtriem + min-height 1000px). Attiecīgi filtri tā īsti nav jāskrullē, jāskrullē ir vai nu lapa, vai produktu saraksts. Kods daudz vienkāršāks, jo slaidojot to filtru bloku ir jāveic vairāki aprēķini un jāņem vērā resaizošana, ja filtri nesalien ekrānā.

Priekšniekam, protams, nepatīk. "Visi citi" taisa tā, značit mums arī tā vajag, principā tas arī bija vienīgais puslīdz nopietnais arguments, kuru viņš varēja pateikt.

Jautājums: kā jums liekas, kā lietotājiem (vai vismaz jums) būtu ērtāk - ka ir garum gara lapa, kurai filtri slīd pakaļ (piemēram, tajā pašā dateks.lv portatīvo datoru sadaļas document.height ir 122k pikseļu), vai relatīvi īsa lapa, kurā jāskrullē pārsvarā tikai produktu saraksts (manā lapā ar visiem atvērtiem filtriem 6264px)?

Abos gadījumos tāpat ir jāskrullē gan filtri, gan produkti, tāpēc arī neredzu baigo jēgu kaut ko mainīt.

Izlasi topic title...

You got the idea. Turklāt C++ suportē multiple inheritance.

Palasīju tos PSR, 0. un 1. piekrītu, bet 2. ir pāris aizķeršanās:

Code MUST use 4 spaces for indenting, not tabs.

Fuck you.

Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility;static MUST be declared after the visibility.

visibility [static] [final]

or

visibility [abstract|final]

Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.

Baigi gudri, klasēm un funkcijām braces on a new line, šeit nē... Fuck this aswell.

The extends and implements keywords MUST be declared on the same line as the class name. 

šis gan liekās pilnīgi nevajadzīgs noteikums, kāpēc gan neļaut sadalīt extends sarakstu un implements sarakstu katru savā līnijā, piemēram, šādi:

public final class Bar
    extends \Foo
    implements \That, \SomethingElse

Allman forever.

Visādi citādi gandrīz pilnībā pieturos Oracle guidelines: http://www.oracle.com/technetwork/java/codeconv-138413.html (arī PHP kodā tāpat formatēju, rūļi lielā mērā atbilst un readability man ir ļoti svarīgs).

Ir pāris sīkumi, kuros nepieturos, bet tādi bija burtiski pāris un uz sitiena neatceros.

Izvēles iemesls: sāku programmēt, darbojoties ar open-source projektu, kurā praktiski visur tika izmantots Allman stils, bet pārējos rūļus pats izvēlējos, kā man vislabāk patika no Eclipse code style dotajām iespējām. Tikai vēlāk uzzināju, ka mani preferences ļoti atbilst Oracle guidelines.

Visos tajos location blokos? Un vai ir svarīgi - pirms vai pēc expires direktīvas?

Edit: nvm, pieliku pēc, it kā strādā.

Radusies problēma ar nginx un caching. Uz production servera stāv nginx 1.2.3 (zinu, damn old versija, atbildīgajam uztaisīju ticket, lai apdeito, sen tā kā būtu laiks).

Ir projekta root folderis /public/. Šajā folderī ir 3 subfolderi /css/, /js/ un /images/. Nginx configi šiem folderiem:

        location ~ /css/ {
                include enable-gzip.conf;
                expires 2w;
        }
        location ~ /js/ {
                include enable-gzip.conf;
                expires 1M;
        }
        location /images/products/ {
                include enable-gzip.conf;
                expires 2w;
                try_files $uri /images/products/index.php;
        }
        location /images/ {
                expires 2w;
                include enable-gzip.conf;
        } 

enable-gzip.conf saturs:

gzip                    on;
gzip_disable            "MSIE [1-6]\.";
gzip_http_version       1.1;
gzip_comp_level         6;
gzip_types              text/plain text/css text/javascript application/x-javascript image/jpeg image/png;
gzip_buffers            16 8k;

Gan CSS, gan JS failiem ir GET parametrs "?mod=unixtime",  /js/jquery... failiem "?mod=static", savukārt attēliem tāda vispār nav.

Diemžēl atverot jebkuru lapu, šie faili netiek kešoti, līdz ar to lapa reāli ielādējas 2 sekundes katru reizi, kad tiek pārlādēta, kaut gan saturs tiek kešots un refreshojās tikai min. 1x stundā.

Visiem failiem HTTP response code ir 200 un Request headeri satur šādas līnijas: "Cache-Control:no-cache", "Pragma:no-cache".

Ir aizdomas, ka /images/ rūlis neuzliekās dziļākiem subfolderiem tajā mapē, tur ir vēl pa kategorijām un preču ID subfolderi, bet tas neattiecas uz css/js, kuros iekšā nav neviena subfoldera.

WTF is this and how do I fix it?

jebāl, nu kur tādu troll projektu var izdomāt...

Zinu, ka JPEG nav transparent, neesmu vakarējais.

Anyway, uzliku, ka neliek transparent background, un ir OK.

Kā jāsaprot "Ar šo tiek atslēgta arī automātiska erroru rakstīšana log failā"? Tas tā nopietni CodeIgniter ir uztaisīts? Kas tas par debīlismu?

Anyway, try/catch ap "$articles = $this->articles_model->get_articles();", ja tev vajag konkrēti tajā situācijā, bet ja nē, tad normālam freimworkam vajadzētu būt globālam try/catch blokam tur, kur tiek izsaukts kontrolieris un action.

+ es kaut kā nesaprotu, nafig vajadzīgs tāds brīnums kā "$this->load->model('articles_model')"; var taču izmantot autoloading un vai nu statiskas metodes vai singleton.

Nezinu, uz production servera visi attēli tiek konvertēti uz jpg, izņemot uploadoto oriģinālu.

Nu paga, bet pirms tiek izsaukts toJpegFile(), nav taču zināms, ka nevajadzēs transparent. Turklāt, kā es jau teicu, uz manas kastes tādu problēmu nav, tikai uz linux bokša.

Backgrounds arī iepriekš tika likts transparent, tajā vietā, visticamāk, problēmas nav, tāpēc arī es domāju, ka unsharp kaut ko sačakarē.

Esmu uzskrējis virsū interesantai problēmai, ko pats nespēju lokāli reproducēt.

Izmantojot šo bibliotēku un šādu kodu:

header('Content-type: image/jpeg');
Image::loadFromFile('http://upload.wikimedia.org/wikipedia/commons/c/ca/Triple-Spiral-4turns_green_transparent.png') // source nav svarīgs, galvenais, ka transparent bg
	->resize(75, 75, true, true) // dimensijas nav svarīgas, arī 600x600 tāda pati problēma
	->unsharp(90, 1, 3)
	->toJpegFile(null, 93);

uzģenerētie .jpg attēli uz production servera ir ar melnu "noise" backgroundā. Problēma ir tikai ar .png failiem, kuri tiek resaizoti un konvertēti uz .jpg, bet uz sava development bokša ar PHP 5.5.0 tādu problēmu nav, lai kādus izmērus norādu.

Kas par huiņu? Man ir aizdomas, ka problēma ir unsharp maskā (moš imagealphablending(true) nepatīk), bet hvz...

Man liekas, ka WM ir tava apsēstība.

Nedzeru un netaisos, tā tik vēl trūka.

Protams, ka tas ir mans laiks (arī, nevis tikai, bet vienalga mans).

Ar termiņiem ceru vairs nekad nesaskarties. Esmu strādājis stresainu darbu, kur dzen uz priekšu un spiež sulu ārā, nahuj tādu vairs nestrādāšu. Patreizējā darbā tādu termiņu nav un to, ko no manis prasa, es uztaisu un uztaisu kvalitatīvi, tā, lai nav pēc pāris dienām jāpārraksta no nulles, jo jāpieliek viena fīča vai kaut kas jāpamaina. Bet priekšniekam gribās, lai es tieši tā arī taisu un kad vajag, lai pārrakstu no nulles, un to es pat netaisos saprast, jo tā ir lieka mana laika un zināšanu tērēšana.

Tici man, man arī ļoti patīk kārtot kodu.

@daGrevis - PHP arī var programmēt kārtīgi un izbaudīt procesu, ja tikai ļauj.

t.i. he's right.

Priekš manis tas ir par zemu. Ja kods ir reāli sūdīgs, es tā arī saku un cenšos kaut ko darīt lietas labā, nevis vienkārši "ja jau maksā...", galvenokārt tāpēc, ka nauda man nav galvenais, es vēlos savu darbu izbaudīt.

Tāpēc, ka nav tavā stilā? :D Varbūt tad pašam jāapsver šādas tādas izvēles?

Gribi pateikt, ka tas ir tavā stilā?

neadkevāti daudz gļuko, sarežgīta uzturēšana

Tas jau viss ir. Viss ir hardkodēts, ja vajag, piemēram, izmainīt kaut kādu sīkumu datubāzē (pielikt, noņemt kolonnu), risks nogāzt visu saitu ir diezgan reāls, tāpēc visu jādara BAIGI rūpīgi, un arī tad var nepietikt.

Vari mēģināt priekšniekam iestāstīt par technical debt. Un pirms ej prom, mēģini dabūt algas paaugstinājumu vai citus bonusus un nejiet prom. :)

 

Vēl variants, ja tas programmētājs ir tāds muļķis, publiski pateikt viņa vārdu... lai vismaz netīšām tādu nepaņem komandā (piemēram mēs meklējam programmētaju).

Var jau arī mēģināt, bet zinot priekšnieka attieksmi, neizskatās, ka viņu tas interesēs. Cik zinu, tas programmētājs ar viņu kopā ir strādājis gandrīz no uzņēmuma sākšanas (~9 gadus), viņš vienmēr ir rakstījis visai nekārtīgu kodu un priekšniekam tas nav traucējis (pirms es atnācu, projektam pat nebija centrāla VCS, katram developerim bija sava lokāla VCS un izmaiņas kopēja pa tiešo caur FTP, pie tam konkrēti šis programmētājs, par kuru iet runa, strādā uz production servera, vnk faili /test/ mapītē).

Vārdu "skaļi" gan neteikšu, ja gribi, varu PM aizsūtīt, bet man neliekas, ka viņš tuvākajā laikā meklēs citu darbu, vismaz ne šajos apstākļos, kur es, rakstot 20x vairāk un 5x kvalitatīvāku kodu par viņu (viņš kaut ko uztaisa reizi 2-3 dienās un arī tad tas ir pupu mizas, liela daļa katra kommita ir backticku izņemšana no SQL queries vai atstarpju/newline/punctuation dzēšana/pielikšana kur nekur), dabūju pa mizu par to, ka cenšos ieviest kārtību.

Būtu jau jauki, ja varētu viņu pierunāt kaut ko tādu izmantot.

Es jau kādu laiku apsveru iet prom, nauda ir iekrāta, kādu mēnesi atpūstos un atrastu kaut ko sakarīgu.

Ļoti iespējams, ka tad, kad vasara beigsies, iešu arī.

Ar to formatējumu arī rodas problēmas, kad viņa kodā ir bagi (kuru pēdējā laikā ir arvien vairāk). Kamēr atrod... Nevienam negribās gaidīt, kamēr viņš atnāks uz darbu, ja vispār atnāks, bet nevienam taču tādiem sūdiem grābties cauri negribās. A viņam pofig; atlaist ta viņu nevar, jo viņš ir "pārāk dziļi sistēmā".

Es jau refaktorēju, bet priekšniekam kvalitāte pie kājas (burtiski šodien par to strīdējāmies un viņš tā arī pateica), un tas čalis kopš sākta gala tā programmējis, ar mietu nepietiks. Esmu mēģinājis skaidrot, kāpēc kārtīgs kods ir svarīgi, bet mani neviens neklausās.

@rpr - te viens piemērs tipiskam viņa stilam:

class methods{ private $_ = array();
 public function __construct(){ $this -> _[ 'usr' ] = new _users; }
 public function __call( $name, $params ){ $get = $params[ 0 ]; $post = $params[ 1 ];
  $funcs = array( 'usr' => array( 'inc' => 'usr.php', 'env' => array( 'usr' => $this -> _[ 'usr' ] ) ) );
  if( isset( $funcs[ $name ] ) ){ require_once 'include/global/'. $funcs[ $name ][ 'inc' ];
   if( in_array( $func = $get[ 0 ][ 0 ], $iface ) ) return $func( $funcs[ $name ][ 'env' ], toSys( @$get[ 0 ][ 1 ] ), toSys( $post ) ); }
  return new s( NULL ); } }