codehighriga

Tādi lietotāji arī nespēj savu jautājumu uzrakstīt botam saprotamā formā. Supports potenciāli tiks atslogots tādā formā, ka lietotājs, nesaprot kā nonākt līdz īstam supportam, atmetīs visam ar roku un aizies no lapas/produkta pavisam prom.

Neesmu redzējis vēl nevienu čatbotu, kas būtu tiešām noderīgs gala lietotājam. Bots spēj tikai nokaitināt gala lietotāju, pirms tas tiek līdz čatošanai ar īstu cilvēku supportā.

Chrome Remote Desktop - https://remotedesktop.google.com/ - ļauj piekļūt tavām personīgajām ierīcēm, kas ir tavā google kontā

Nu no otras puses @moonshine jau arī nav nekāds saulstariņš. :) Cik saprotu lielais cepiens joprojām ir tikai par to, ka bez WP pieredzes nepaņēma darbā WP-centriskā uzņēmumā. + tika iztērēts mazliet laiks testa uzdevumam. Vai tas tiešām ir tas briesmīgākais, kas var darba meklējumos atgadīties?

Tas jau it kā būtu saprotams, galu galā atverot mājaslapu ar lieliem burtiem ir rakstīts "We are building the best Wordpress tools". Nav gluži rakstīts "We are building the best Laravel packages".

https://blog.newrelic.com/engineering/distributed-monolith-vs-microservices/ Justin Etheredge writes that a distributed monolith is "the worst of all worlds". You’ve taken the relative simplicity of a single monolithic codebase, and you’ve traded it in for a deeply intertwined distributed system.

Šitas viss parasti izklausās labi tikai hipsterīgos bloga rakstos un IT konferencēs. Realitātē nav ne skaisti, ne vienkārši. Galvenā problēma visticamāk būs monolīta datubāze. Tu uzrakstīsi savu jauno fīču uz kāda jauna FW, bet tik un tā slēgsies klāt tai pašai vecajai datubāzei, jo vajadzēs pieeju kādam svarīgam resursam, piemēram, vecajai "users" vai "orders" tabulai. Ja tavs jaunais mikroserviss ar veco DB darbojas tikai read-only režīmā, tad vēl varbūt tur kaut kas var sanākt, bet ja vairāk servisi sāks veikt write darbības, tas agri vai vēlu novedīs pie sačakarētiem DB datiem. Es par īstu mikroservisu uzskatu tādu, kas ar pārējo sistēmu komunicē tikai ar HTTP, bet biežāk par mikroservisu nosauc kaut kādu composer package, kas tiek ievilkta projektā. Piemēram, grib būt DRY un ievelk kaut kādu "company/core" paku. Tas variants ir galīgi garām, jo rodas tight coupling un tiek pazaudēta iespēja brīvi izvēlēties tehnoloģijas. Visi mikroservisi ir spiesti palikt pie tās pašas valodas/FW, kas ir izmantota "company/core" pakā. Tad nu tur rodas tāda putra, ka varbūt vajadzēja vien palikt pie vecā legacy monolīta?

Derētu precizēt, kas priekš tevis ir "senas/vecas tehnoloģijas" un kāpēc gribi precīzi Symfony frameworku ar precīzi PHP 8. Arī PHP 7 joprojām ir ļoti labs un arī citi frameworki joprojām ir ļoti labi. Var mierīgi iet strādāt arī tādā uzņēmumā, kam ir projekts ar Laravel 7 un PHP 7, nekas briesmīgas nenotiks. Red flag ir tikai tad, ja projekts ir uz Laravel 5 un PHP 5.x

Servera ziņā es nevienam projektam nelieku mazāk par 8GB RAM. Neliekas ticami, ka redis/mysql labi funkcionēs ar 1-2GB RAM. Arī ar 4GB diez vai. Otrkārt, atverot sākumlapu un attaisot Developer Tools -> Network, ir redzams, ka priekš pilnas sākotnējās ielādes tiek iekačāti 40MB datu. Četrdesmit! Iesaku papētīt, ko par lapu rāda Google PageSpeed Insights: https://developers.google.com/speed/pagespeed/insights/?hl=lv&url=https%3A%2F%2Fwww.branchess.com%2F Izskatās, ka iesaka samazināt attēlu izmēru utt. Daudzas bildes tur ir 1-3MB lielas.

Ar to ir jābūt ļoti uzmanīgiem, jo tāds hash lielā mērā sabojās visu privātuma un kriptēšanas būtību. Ja uzbrucējam ir kādi konkrēti e-pasti, ko gribas sameklēt datubāzes dumpā, tad varēs pielietot dictionary metodi. Ja neinteresē konkrēts e-pasts, nu tad varbūt tāda metode ir pieļaujama.

https://security.stackexchange.com/questions/184519/how-to-handle-emails-as-usernames-under-gdpr Sliecos piekrist šim viedoklim ^ Tomēr ir arī kompānijas, kas kriptēšanu veic vienīgi dēļ šī iemesla - "To give a feeling of security by sprinkling some crypto all over the place" - tas izskaidrots šeit: https://security.stackexchange.com/questions/101163/what-fields-should-i-encrypt-in-a-database-containing-user-information

Pirmais ieteikums, vēl pirms visas tehniskās puses, ir rakstīt gramatiski pareizā latviešu valodā ar visām mīkstinājuma zīmēm. Citādi, ja cilvēks neprot konstruktīvi izteikties cilvēkiem domātā valodā, tad rodas jautājumi, vai tādas pašas kļūdas un overall messy stils būs arī programmēšanas valodās? Katrā ziņā saņemot tāda stila motivācijas vēstuli es nebrīnos, ka uzņēmums nesniegs nekādu atbildi. Ja veic nelielu izpēti un paklausās apkārt, tad ir vairākas vietas, kas ņem juniorus ar mazu pieredzi. Šīm vietām nepieciešamās zināšanas var labi un salīdzinoši ātri apgūt dažādos online kursos (youtube, udemy, stackoverflow learning, vue mastery, laracasts utt). Iekļūšanu nodrošinās galvenokārt laba motivācijas vēstule, kurā var iekļaut visus apskatītos kursus, grāmatas, tēmas, tehnoloģijas. Ar IT nesaistītas lietas droši vien nebūs vērts iekļaut. Cik ilgs laiks nepieciešams kopš mācību uzsākšanas līdz pirmajai darba vietai - tas ir ļoti individuāli. Atkarīgs no ieguldīto stundu skaita, motivācijas, prasmes navigēt lielā informācijas plūsmā utt. Varētu mierīgi paiet 1 gads. Kādam mazāk, kādam vairāk.

Problēma varētu būt tā, ka docker-compose.yml trūkst "expose". Zem expose ir jābūt portiem 80 un 443. Ja Dockerfile ir bāzēts uz oficiālo nginx image bez izmaiņām, tad pēc noklusējuma expose ir tikai ports 80. Tā kā tu ļepini kopā SSL, tad tev vajag expose arī 443.

Digitalocean tu vari izvēlēties, kurā datucentrā būs serveris. Eiropā ir vismaz divi - Nīderlandē un Vācijā. Personīgi nekad nav nācies sazināties ar supportu, bet pieņemu, ka rakstiski visu var atrisināt vēl labāk kā pa telefonu.

Nu jā, tas pats digitalocean kvalificējas visām prasībām. Man jau liekas, ka 2020. gadā ar hostinga meklēšanu nemaz nav diez kā jānodarbojas - paņem kādu starptautiski atpazīstamu kompāniju un viss darbosies, būs līmenī. Daudz uzticamāk kā čakarēties ar kaut kādiem vietējiem Latvijā/Lietuvā bāzētiem kantorīšiem.