jurchiks

Man tas pats :D Too much work. Nav nekādu garantiju, ka man patiktu strādāt draugiem.lv, + tas, ka ofiss ir fucking tālu, tā kā es nevaru neko tur motivēt.

Un vispār, tas nosaukums "motivācijas vēstule" ir kaut kāds nepareizs. Vai man jāmotivē darbā ņēmējs, vai? Manuprāt, IT jomā tāda lieta ir lieka, vajag skatīties vispirmām kārtām sausus faktus. Izlasīs pasakainu motivācijas vēstuli, pieņems darbā, izrādīsies, ka tikai muti trīt vien māk.

Tas tāpēc, ka cilvēki mūsdienās vairs nemāk rakstīt vienkāršu kodu.

jurchiks, parasti jau no PHP iet uz Java. Vismaz tāds iespaids bija radies. Jo tur dzīve esot zaļāka, algas milzīgākas (no 60k gadā), kamēr PHP tāda bērnu pasaule vien esot, utt. Kāpēc gāji otrādi? Jeb tāds iespaids par Javas supremacy izveidojies tikai lokāli, par LV?

Java pieredze bija pašmācības ceļā iegūta, par enterprise neko nezināju. Turklāt vēlāk, meetupos, sarunās ar Java programmētājiem uzzināju, ka diezgan tizli Latvijā ar to Java ekosistēmu.

Anyway, enterprise pēc būtības ir baigā birokrātija un diezgan sasietas rokas, bet man patīk izvēles brīvība.

Tāpēc, ka man patīk vienkāršs, lightweight kods.

Es gan teiktu, ka viņa servisa pirmā kļūda bija izmantot SOAP.

Ja tu to tagad man saki, tad palasi, ko FB glabā tajā cookie.

Nu tam Firefox PDF viewerim nevar uzticēties. Daudzi tādus PDF rēķinus vērs vaļā lokāli, nevis caur pārlūku, tāpēc Adobe Reader ir obligāti jāskatās, un ja tas rāda šķībi, tad IR šķībi, vnk Firefox kaut ko tur izskaistina; kārtējo reizi noslēpj problēmu.

> >Catching multiple exception types

>

> pa taisno no Javas ņemts.

 

So? Normāla fīča.

Es vai tad sūdzējos, ka slikta fīča?

Man reāli iekš php pietrūkst ENUM tipi, šobrīd lietoju abstract class myEnum ar klases konstantēm, bet typehintot tā pat nav iespējams. 

 

https://wiki.php.net/rfc/enum

Piekrītu, nākot no Javas, sākotnēji baigi pietrūka. Bet nu kaut kā esmu pielāgojies.

Facebook JS uzseto cookie. Backendā tu izmanto Facebook PHP API, lai darītu kaut ko šādu:

	public static function facebookLogin()
	{
		$fb = new Facebook(
			[
				'app_id'     => Config::get('app.facebook-auth.app-id'),
				'app_secret' => Config::get('app.facebook-auth.secret'),
			]
		);
		$helper = $fb->getJavaScriptHelper();
		$accessToken = $helper->getAccessToken();
		$response = $fb->get('/me?fields=name', $accessToken);
		$user = $response->getGraphUser();
		
		$localUser = Database::get()
			->prepare('SELECT id, name FROM users WHERE facebook_id = ?')
			->execute([$user->getId()])
			->fetchRow();
		
		if (empty($localUser))
		{
			$id = Database::get()
				->prepare('INSERT INTO users (name, facebook_id) VALUES (?, ?)')
				->execute([$user->getName(), $user->getId()])
				->getLastInsertId();
		}
		else
		{
			$id = $localUser['id'];
			// update the name to the latest version whenever the user logs in
			if ($localUser['name'] !== $user->getName())
			{
				Database::get()
					->prepare('UPDATE users SET name = ? WHERE id = ?')
					->execute([$user->getName(), $id]);
			}
		}
		// šis uzseto PHP sesiju
		self::set(
			'user',
			[
				'id'    => $id,
				'fb_id' => $user->getId(),
				'name'  => $user->getName(),
			]
		);
	}

Attiecīgi, ja kaut kas ar to cookie ir šķībi, tad Facebook API metīs exception.

Kas jauns 7.1 būs: https://dotdev.co/upcoming-changes-in-php-7-1-76ebea53b820#.s3hygwi1a

Dažādas sīkas lietas, bet tāpat patīkami, jo sāk vairāk līdzināties jēdzīgai valodai :)

Eh, gribētos scalar type hintu...

>Catching multiple exception types

pa taisno no Javas ņemts.

>Allow specifying keys in list()...

Tur kaut kāds sviests ar to sintaksi darās, reālajā RFC tas izskatās daudz loģiskāk:

https://wiki.php.net/rfc/list_keys

It īpaši feins ir tas __construct(array $attributes) piemērs (trūkst tikai isset() tiem keys).

@Mr.Key - tas laravel-dompdf ir tikai wrapperis pašam DOMPDF, un DOMPDF, kā jau teicu, ir sūds. 7. versija tikai pirms 5 dienām iznāca stable, bet kad es viņu pirms nedēļas mēģināju piešķilt, ne 6., ne 7. versijā neizdevās piedabūt img un h1 tagus nostāties vienu otram blakus - ne ar floatiem, ne ieliekot tabulā. 7. versija gan ģenerē diezgan ātri, vismaz 2x ātrāk par 6. versiju, bet tas arī viss.

Nevar jau ieviest, ja katram klientam uz servera sava PHP versija, tai skaitā 5.3.3 (ādažu čipšiem) :@

Jāāā, IDEi tas ir ļoti svarīgi... Reāli izskatās, ka tev vienkārši nebija, pie kā piekasīties, tāpēc izvēlējies fontus (ar kuriem nekas nav nepareizi).

Nē, viņš vienkārši dizaineris, un tam GUI nav "stilīgu, modernu" fontu.

Lol, tagad pat par GUI fontiem strīdēsimies? :D

Piemērs neizdevās. Bez tā trešā punkta vēl būtu kaut cik OK, bet priekš kam kas tāds reāli vajadzīgs... Examples should be relatable.

Nav bijusi vajadzība pēc tāda sviesta, un ja būtu, es stipri apšaubītu tā nepieciešamību.
Un es nešaubos, ka bez termināļa tas IR iespējams. This is programming after all.

Kāds plagins, built-in funkcionalitāte.

Also - so pro, much cli. Except we don't need it. Baigi patīk merdžot konfliktus caur konsoli?

@Kavacky - protams, kompis vainīgs. Kādā sakarā antialiasing un table borderim 1px nobīde?

Man gan nav ne tuvu tik traki, kā Kasspars, bet 1 stūris šajā PDFā - http://webit.lv/test/wkhtml.pdf- katrai otrajai tabulai lien ārā uz zoom=100%.

GIT GUI ir primarily priekš tiem, kas izmanto text editorus, nevis IDEs, tas jau tāpat ir skaidrs.

Nu vai arī varbūt kādu baigi neapmierina IDEs built-in GIT GUI.

Jā, kaut kāds 1 pikselis tur reizēm lien ārā, bet nu cmon. Kasspars vēl ar table design nodarbojas?

IT speciālists klientam pasaka, kas un kā ir jādara, lai konkrēto biznesa problēmu risinātu. Vai ir kāds cits mēŗkis, kāpēc klients pie Jums ir vērsies?

Ja mums būtu tāds IT speciālists... Te ir 2 programmētāji, no kuriem viens esmu es, un ar klientiem pa tiešo mēs nesazināmies. Vairāk no IT te neviena nav. Vienkārši lapas tiek taisītas ar smagu uzsvaru uz frontendu, backenda baigi maz, jo dizaina kompānija.

Paeksperimentē .. 

 

Atkarībā no hostinga reizēm netiek diseiblotas php exec() shell_exec() utt funkcijas .. tad atliek tikai uzlikt (pa ftp) statiski sakompilēto wkhtmltopdf bināriju ( piem no https://github.com/h4cc/wkhtmltopdf-amd64) un tad tikai exec() vai `` vai proc_open() :)

Interesanta štelle, paskatīšos! Bet nu jāmēģina kaut kā dabūt līdz sisadminam, lai ieinstalē normāli, varbūt sanāks.

Tu jau laikam par to, ka visi aizņemti, neizlasīji...

+ te neviens par tādu wkhtmltopdf dzirdējis nav, tā kā tāda prasība izvirzīta nemaz nevarēja būt.

+ ne visi ir tik priviliģēti, ka var klientam izvirzīt baigās prasības; šitais ir mazs kantoris, nesen tikai sākuši.

Tādi, kuriem ir tikai FTP access. Es darbā vairākās vietās, incl. PM, rakstīju, ka vajadzētu uz servera wkhtmltopdf dabūt, lai tos rēķinus varētu normāli ģenerēt, bet klusums. Visi ir līdz matu galiem darbos, jo paņemti 20x vairāk projekti, nekā spēj izpildīt.

Esmu pagātnē lietojis TCPDF, bet tolaik tur kaut ko normālu varēja dabūt gatavu tikai ar table design.

Tagad vairākos projektos izmantojas DOMPDF, bet tas arī ir diezgan pabriesmīgs mēsls.

No tādiem tūļiem, kuri ģenerē tiešām kvalitatīvus rezultātus no normāla, moderna HTML dokumenta, es zinu tikai native softu - wkhtmltopdf (uz klientu serveriem praktiski nav iespējams dabūt), http://www.pdfforge.org/(Windows-only) - un komerciālus risinājumus (http://docraptor.com/ utml).

Vajadzētu kaut ko normālu PHP-only pusē. Ieteikumi?