Roze

Rakstīšana ar pildspalvu uz papīra (nu vai ar krītu uz tāfeles) ir veids kā novērtēt cilvēka spēju formulēt savas domas kopumā. Īpaši, ja atlasei ir jaunatne, kurai (lielai) daļai mūsdienās ir problēmas ar uzmanības noturību un/vai arī viss līdz šim ir tapis uz "bakstīšanas" principiem. Vai tas konkrēti der un ir vajadzīgs atlasot kodētājus, iespējams, ir cits jautājums, bet sava nozīme tam noteikti ir.

Ja lieto binārās/statiskās packages no https://wkhtmltopdf.org/downloads.html (ne bleeding edge) tad var iztikt bez X-logiem (xvfb - xlogu frame bufera).

Par to šaubu nav - reizē uzjautrina un nedaudz skumdina (proti, ka par to izsakās cilvēks, kam par konkrēto sfēru (IT) nav nekādas sajēgas) nemaz neņemot vērā līdzšinējo bēdīgo pieredzi (kaut vai vid epopeju)) šādi apgalvojumi ( http://www.tvnet.lv/zinas/viedokli/673345-caksa_e_veseliba_par_datu_drosibu_nav_nekadu_bazu_tacu_aktivak_jastrada_ar_merka_grupam ) .. bet tas nav īsti arī tas, ko es jautāju ..

d*.lv ir kas?

Šķiet, ka visur samainīju .. ja kaut kur vēl rādās vai taisni otrādi - vajag tomēr to "balsošanu" - sakiet ..

Ja nu varbūt kaut kas ir mainījies pēdējā gada laika, tad savādāk un apsveicami, bet pirms kāda laika pirmie divi gadījumi attiecās tikai uz valsts informācijas sistēmām ( https://www.visr.eps.gov.lv/ ) .. Ne-valstiskajām (privāt/juridisku personu) IS kamēr nav pierādāms materiālais kaitējums neviens virsū tavam pieteikumam/incidentam īpaši neskatās / labākajā gadījumā CERT atsūta īsu e-pastu ar rekomendācijām tālākai individuālai darbībai . Pēc pieredzes ..

Ir jā, bet .. IPB eksistē vairāki foruma veidi Discussions un Questions pirmais ir tipa parastais / otrais ir kur it kā tēmas uzsācējs uzdod jautājumu, tad kāds atbild un pārējie vēl papildus var vertēt tās atbildes un tad viņas kārtojas pēc tā. Bet nu cik šķiet to var nomainīt tikai foruma settingos un nekādi lietotāja settingi to neoverraido (vismaz neesmu redzējis nekur), kā arī, cik izskatās, nesaglabājas tas, ja manuāli norādā Sort by .. Man personīgi patīk standarta variants bez kaut kādas balsošanas, attiecīgi vislaik jāspaida uz 'Date', kā citiem - nezinu ... Varbūt jauztaisa foruma aptauja, tad paskatīties par ko nobalso vairākums un tad var pārslēgt vai atstāt kā ir.

Tas, ka mācību iestāde meklē mācībspēkus (piesaistot lektorus no uzņēmumiem) arī pastāvēšanas/uzsākšanas laikā nu gan obligāti nenorāda, ka kaut kas ir "skečīgs". Var, protams, apsvērt/diskutēt vai tāda skola var piešķirt kaut kādu atzītu izglītības kvalifikāciju dokumentāli (jo nu gan skolotājam (profesijai), gan mācību programmai ir zināmi noteikumi), bet savā ziņā var pat no vienas puses uzskatīt, ka tas ir ļoti labi, jo nu tāpat var būt arī otra galējība, proti, ja cilvēks mācību iestādē ir bakstījies 30 gadus, ir liela iespēja, ka viņa akadēmiskās zināšanas (īpaši saistībā ar darba tirgus vajadzībām/tendencēm) ir novecojušas attiecībā pret to "figņu", kas mūsdienās darās IT jomā.

Crasho tikai Oracle skripti? Jo nu ir it kā: https://bugs.php.net/bug.php?id=71708 https://bugs.php.net/bug.php?id=71600 Proti tur tā, ka php randomly crasho, ja Oracle atgriež vairāk kā 8 rowus. Tam bugam gan vajadzētu būt safixētam tavā norādītajā versijā ..

Es no konsoles pačekotu 'php -i | grep opcache.enable_cli' vai tiešām ir off. Reizēm distributīvu php packagos web un cli konfigurācijas ir nodalītas (vai includējas no dažādam vietām) un attiecīgi tas kas izspīdinās webā zem <? phpinfo(); ?> atšķiras no tā ko dabū cron lietotājs. Var pamēģināt pamainīt kādu cronu 'php -d opcache.enable_cli=0 izpildamais_fails.php' un paskatīties vai nepalīdz. Jo nu savādāk tā jocīgi ..

7.0 vai 7.1? Tāds vispārīgs ieteikums pačekot vai CLI modei nav eneiblots (noklusēti ir) Opcode cache (proti vai php.ini (php-cli.ini) ir opcache.enable_cli = 0)

Storētās procedūras ir vienkārši papildus "slānis" (layer), kas ļauj izveidot interfeisu/API sistēmām un risinājumiem, kur tas ir nepieciešams (lai nodrošinātos kaut vai pret tiem pašiem programmētājiem) :) Proti, piemēram, lasot komentāru "Kodā noteikti arī vieglāk ir veikt izmaiņas, versionēt, deployot." .. ir skaidrs, ka ik pārdienu ir vēlme (vai nu vienkārši tāds darba/organizācijas stils) mainīt kaut kādus pieprasījumus (SQL), kas reizēm rada ļoti neprognozējamas sekas un citas ķeskas. Ar procedūrām ir iespējams panākt konkrētu API / prognozējuma risinājuma, produkta darbību un un DBA nav jāsatraucas un jānodarbojas ar zinātnisko pētniecību, ja pēkšņi DB serveris deg zilām liesmām tikai tāpēc, ka kaut kur kodā iesprausts pieprasījums, kas neizmanto indeksus, atgriež miljoniem ierakstu vai ko tamlīdzīgu . Arī no drošības viedokļa, pretēji tam lai dotu pilnas piekļuves visiem (izstrādātājiem / aplikācijai), standarta SQL vietā var definēt konkrētas procedūras/funkcijas datu apmaiņai. tāpat iespējams "neuzticēties" aplikācijai ar ievad/izvaddatu apstrādi (izvairīties no SQL "injectiem"). Tīri no tehniska viedokļa - iespējams ietaupīt nedaudz resursus.(cpu/trafiks) proti, pretēji tam lai aplikācija katru reizi sūtītu gigantisku kveriju, kas SQL serverim ir jāsaņem / jāpārsē utt, var veikt procedūras izsaukumu ar parametriem un viss pārējais notiek servera pusē (protams, tas reizē arī ir mīnuss - DB serveri/risinājumi parasti skeilojas sliktāk nekā aplikāciju frontendi).

Nu ja ir vēlme saistīt darbu ar IT, tad kaut kādai iekārtai tomēr pie rokas jābūt, taču nu mūsdienās jau ir visas tehnoloģiskās iespējas (darba dienai pietiekams baterijas laiks, visādi bezvadu tīkla pārklājumi, attālinātas piekļuves (VPN u.c)) lai obligāti cilvēkam nebūtu jāpiesienas pie vienas stacionāras iekārtas t.i. izņemot uzņēmuma un paša nostāju/politiku nekas cits īsti netraucē sēdēt pļavā zem ābeles ar tjapļapu :) Bet nu tā idejiski nākošais solis droši vien ir kaut kāda "vadība" - grupas / projektu / uzņēmuma un, ja vien cilvēks nav totāli antisociāls elements, nedomāju ka tam nepieciešami lieli līdzekļi lai apgūtu komunikāciju prasmes (manuprāt, tās vienkārši veidojas pašas no sevis dažādās situācijās (labās/sliktās) un praktiskās darbošanās rezultātā).

Ja es pareizi saprotu vēlmi, tad tāds pavisam vienkāršs veids kā automātiski scrollēt uz noteiktu vietu lapā ir izmantojot 'anchorus'. Proti konkrētam elementam vajadzīgajā pozīcijā lapā pieliek name="kautkas" atribūtu (vai id) un attiecīgi linku veido "&scat=2#kautkas" ( http://www.rapidtables.com/web/html/link/html-anchor-link.htm ) Ja doma ir par subkategorijas ielādi bez pilna lapas refreša, tad būs jāskatās uz Ajax.

+1

Nē es to biju domājis tā - pretēji tam, lai dotu tiesības uz 'python', kas principā ļauj caur valodu/interpretatoru darbināt jebko citu ar root privilēģijam, to dara apmēram šādi: 1. Uztaisa shell skriptu blabla.sh, kurā ir iekšā 'python tavsvails.py' (faktiski shellskripta vietā var izmantot arī pašu .py failu, ja viņam sākumā norāda caur ko tas jādarbina (piem. #!/usr/bin/python)) 2. Pārliecinās, ka konkrētajam lietotājam nav rakstīšanas tiesības failā (visvienkāršāk, piemēram, ir izveidot (vai nomainīt) ar root lietotāja un uzlikt chmod 700) 3. sudoers failā ieliek tikai šo .sh vai .py skriptu, tādējādi nav īpaši tālāk jādomā vai konkrētais lietotājs tīši vai netīši spēj palaist kaut ko vēl, kas viņam nepienākas .. Šis protams vairāk būtiski kaut kādās vairāklietotāju vidēs, bez tam mūsdienās modernāka pieeja ir darbināt šādas "aplikācijas" virtualizēt izolētos konteineros, piemēram, docker, LXC u.c. kur tu vari mierigi aplikāciju darbināt procesus kaut vai zem root lietotāja īpaši neiespringstot, ka tie var ietekmēt pamatsistēmu (protams, tur atkal iespējamas citas ķeskas ar tiešu piekļuvi hardwarei (šajā gadījumā sensoriem)). Vārdu sakot, tikai pārdomas par tēmu .. p.s. es piekrītu arī šeit izteiktajam viedoklim ka Tavā gadījumā būtu labāk: 1. darbināt to skriptu no tā paša 'pi' lietotāja un izvades datus vienkārši ierakstīt kādā teksta failā - ja pietiek, ka tas updeitojas ne biežāk kā 1x minūtē, tad var caur cron, ja vajag biežāk, tad var palaist fonā (./skripts.sh &) vienkārši bash skriptu ar while loopu un sleep timeoutu, piem.: #!/bin/bash while [ 1 ]; do sudo python /home/pi/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 12 > /var/www/sensor.txt sleep 5 done 2. No php lasīt tikai konkreto teksta failu Tādējādi nebūs nepieciešams ņemties un dot apaches lietotājam kaut kādus sudo utt, kā arī var labāk kontrolēt piekļuvi sensor datiem/atmiņai utt, proti nav iespējams variants ka atver http lapu, uzliek pirkstu uz F5 un Pi nokaras tāpēc, ka dzīvajā palaisti ziljons sudo python skripti, kas visi mēģina bakstīt sensoru.

Šobrīd tu esi atļāvis www-data izpildīt sudo python, kas no drošības viedokla nav diezko labi (protams, ja uz kastes nav citu lietotāju, kā arī nav publiska, tad pofig), bet nu ideja ir apmēram tāda, ka šadi www-data var palaist python, kas savukārt var izpildīt jebko ar root permisijām: sudo python -c 'import os;os.system("ls -la")' (drošības labad, lai kāds nepamēģina, nerakstīju 'rm -rf /') Attiecīgi nedaudz labāk būtu, ja nodzēstu to komatu starpā, bet šo parasti risina vai nu sudoers taisot Cmd_aliasus vai arī piemēram uztaisot .sh skriptu, kas satur konkrēto komandu un kuram ir tikai read/exec bet ne write tiesības konkrētajam lietotājam.

Šāda konfigurācija manuprāt neko nedod (ja vien nav nepilnīgi iekopēta), jo nenorāda komandu(-as), kuras ļauts izpildīt. Varbūt testiem tad var ielikt vienkārši: www-data ALL=(ALL) NOPASSWD: ALL kas ļautu www-data izpildīt caur sudo jebko (nav īpaši labi no drošības viedokļa, bet to var pēc tam mainit brīdī ja vispār kaut kas sāk darboties). Nu varbūt tad jāsāk ar vienkāršākām lietām, piemēram, skatīties vai php var palaist pythonu vispār (jāņem vērā ka www-data var būt noshell lietotājs (var noskaidrot paskatoties /etc/passwd vai nav kaut kāds /sbin/nologin vai /bin/false vai arī no root lietotāja izpildot 'su www-data'), kam nav definēti PATH utt) Piemēram, vai izpildās no weba php ar kaut ko šādu? <?php passthru('python --version'); ?> Ja nē, tad nepieciešams pilns path uz python executabli. Tad var pamēģināt patestēt vienkārši no konsoles vai zem www-data iespējams izpildīt : su www-data -c "python /var/www/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 12" vai sudo -u www-data python /var/www/Adafruit_Python_DHT/examples/AdafruitDHT.py 2302 1 utt

Skan kaut kā jocīgi, ka tā ir tikai vienīgā vieta kur iespējams ielikt python skriptu, bet nu labi .. Bet pa lielam tev tad jāmaina permisijas (proti vai nu /home/pi dot pilnas read/exec tiesības visiem sistēmas lietotājiem (chmod a+rx /home/pi) vai arī jāliek www-data un pi vienā grupā un tad jāmaina grupas permisijas) vai arī teiksim var darbināt apache zem 'pi' lietotāja. Vai arī jāskatās /etc/sudoers un jāļauj www-data lietot sudo komandu. Piemēram var kaut ko šadu: www-data ALL = NOPASSWD: /var/www/html/python.sh attiecīgi ļaujot www-data izpildīt sudo /var/www/html/python.sh bez root pw ievadīšanas ..

Tev tas skripts atrodas /home/pi/Adafruit_Python_DHT/examples/AdafruitDHT.py kas ir 'pi' lietotāja home direktorija .. parasti noklusētās permisijas neļauj citiem lietotājiem (kas šajā gadījumā ir www-data) piekļuvi /home/ direktorijām. Pamēģini pārcelt to Adatafruit_Python_DHT kaut kur ārpuse /home (piem /tmp /opt utt) kur būtu read/exec tiesības www-data (vai arī visiem sistēmas lietotājiem). p.s. no testēšanas viedokļa, manuprat, exec() vietā vienkāršāk ir lietot passthru() ( http://lv.php.net/passthru ), kas uzreiz izgrūž komandas outputu.

Kā jau iepriekš minēts, 126 exit status ir nepietiekamas permisijas .. Zem kāda lietotāja darbojas php (ja tiek vērta lapa caur http/webserveri)? Vai no komandrindas 'php konkretaisfails.php' ar neko neizdod? Proti, parasti noklusēti 'sudo' komanda pieprasa ievadīt root lietotāja paroli, ja vien nav specifiski nokonfigurēts (konfigurācija parasti /etc/sudoers), ka konkrēti sistēmas lietotāji to var izsaukt bez paroles ievades, taču, ja php darbojas zem cita lietotāja, iespējams tam nav šādu permisiju. Kā alternatīvu varētu skatīties vai nav iespējams atjaunināt pašu Raspberry programmatūru (neesmu gan lietojis Pi, attiecīgi nemāku teikt cik grūti/vienkārši tas izdarāms), jo tā fiksi pameklējot webā parādās šāda lieta https://github.com/adafruit/Adafruit_Python_DHT/commit/0db54b0482f004e0091e48cefa9b5f0b310d735b#diff-1da2860702a0965f5f60c13795e0bddf proti iespēja lasīt datus bez root tiesībām.

Cik jauns/vecs php un openssl (būtu jābūt vismaz 1.0.1) ir uz servera? Proti, pirms kāda laika Paypal nogrieza visu izņemot TLS1.2 (SSLv3 noteikti vairs neatbalsta) ( https://devblog.paypal.com/upcoming-security-changes-notice/) attiecīgi uz vecākām serveru OS/php versijām varētu kā reiz nekas vairs neiet. Visvienkāršāk pārbaudīt vai ir atbalsts ir uztaisīt pliku php lapu ar <? phpinfo(); ?> un tad atvērt to pārlūkā un tad pie augšējā tabulā pie 'Registered Stream Socket Transports' paskatīties vai tur ir tlsv1.2 - ja tur ir tikai ssl/tls/tls 1.0, tad pa lielam nekas cits neatliks kā atjaunot programmatūru uz webservera.

Tur tas raksts/intervija tāda jocīga, proti, vienā brīdī runā par (NoSQL produktu) uzņēmumu nespēju veidot biznesu "Because there is so much money poured into some companies and they do not have a way to monetise until [a solution] is proven worthwhile" .. otrā brīdī par pašas tehnoloģijas popularitātes zudumu "“I see more people revert back to doing SQL than NoSQL because it is still trusted to handle mission-critical data.”" .. Interesanti, gan ka viņa paša kompānijas upstream produkts (MySQL) ievieš natīvu atbalstu JSON (ar visām tām saistītām funkcijām https://dev.mysql.com/doc/refman/5.7/en/json.html ) kā arī pašai MariaDB jau krietni pirms tam eksistē nedaudz apdalīts json + dinamisku kolonnu atbalsts, ko nekā citādi kā par NoSQL (nedefinētas datu struktūras aspektā) nosaukt nevar .. Ja jau NoSQL ir tik neperspektīvs un "burbulis plīsīs", tad jēga kaut ko tādu iekļaut savā produktā? :) Man, piemēram, JSON liekas ļoti interesants - ir iespēja veidot ļoti dinamisku datu struktūru (t.i. lai vienam ierakstam pieliktu papildus lauku/vērtību nav vairs jāmaina tabulas struktūra vai jāveido sarežģīti joini, kas lielām tabulām ir resursietilpīgi) tai pat laikā konkrētus json laukus eksportēt un indeksēt (nepalielinot datu apjomu) kā virtuālas kollonas ierastajai SQL apstrādei.

Par ko tieši sasmējies? Par "simple" vai kā? Ja par to, tad ļoti precīzu un fiksētu ciparu ir grūti nosaukt, jo Amazons tarificē pēc N dažādām lietām un faktisko summu tu sāc redzēt tikai pēc pirmā mēneša darbināšanas. Bet pēc tavām prasībām tā ir aptuveni t2.small instance. Mums tik mazas nav, bet nu kā piemēram dažas (US-West): $0.077 per On Demand Linux m3.medium Instance Hour 744 Hrs $57.29 $0.14 per On Demand Linux m4.large Instance Hour 743 Hrs $104.02 EU$0.056 per On Demand Linux t2.medium Instance Hour 744 Hrs $41.66 USD 0.04 hourly fee per Linux/UNIX (Amazon VPC), reserved t2.medium instance 1,488 Hrs $59.52 samērā precīzi atbilst kalkulatora uzrādītājam .. Protams, atkarībā no trafika (piemēram, ja no servera ne-Amazones izejošais trafiks būs 1Tb tad + ~90$), snapshotu apjoma, kā arī no izvēlētā datucentra izmaksas mainās un klāt var nākt papildus ikmēneša rēķinam, bet kopumā t2.small ja ir 100% utilizācija būs ~20$ vai ~14$, ja rezervēta (1 gads, bez priekšapmaksas).

Kā jau Blitz minēja - pamēģini Jira, Redmine, Gitlab (teorētiski arī Github). Pašam jāsaprot kādu rīku izvēlēties, proti, vai tas vairāk ir domāts (vairāk iespēju) tieši programmētājiem (faktiskie uzdevumi / bug reporti / koda repozitorijs / testi utt) vai kā reiz tiem pašiem projektu vadītājiem (sarakste ar klientu / kalendāra ieraksti utt). Manuprāt Mr.Key nedaudz pārspilē projektu (pus)vadītāju lomu. Protams ir ērtāk, ja ar klientu iet runāties cilvēks (inviduāla pieeja galu galā) kuram ir komunikācijas dotības, taču tas nenozīmē, ka arī programmētājam tādas nevar būt un tad nav būtiski, kurš ir fiksējis uzdevumu. Uz šo var skatīties dažādi - kā tad vadība pat par sevi to nodrošina? Vai tas domāts kā garantijas attiecībā pret klientu? Jo nu produkta izstrādi jau tāpat veic programmētājs (u.c. faktiskā darba veicēji). Ja tas ir domāts kā skubināšana (vai ar pātagu), tad savādāk/bēdīgāk.. Šādas sistēmas kā reiz (ja klientam arī ir piekļuve) vienkāršo komunikāciju - vai nu darbs ir pabeigts vai nav .. un nav vajadzības kādam braukt un taisnoties vai solīt, ka rīt no rīta viss nu tiešām noteikti būs (protams, reizēm iedzert (kafiju) ar klientu var būt noderīgi). Pēc būtības jau lielākā daļa atvertā koda (un arī komerciālas) programmatūras strādā ar šādiem rīkiem / principiem, Tikai klients šajā gadījumā lielākoties ir "anonīms" lietotājs, kas piesaka savu "feature requestu" vai "bugu" un tad atkarībā no dažādiem kritērijiem tas tiek vai netiek izpildīts. Neredzu arī iemeslu kāpēc tas nestrādātu attiecībā uz fiksētiem klientiem - klients vai projekta izstrādes puse saraksta visus veicamos darbus un prasības, kurus abas puses apstiprina / tās tiek pieškirtas konkrētiem darba veicējiem / klients un vadītāji vienmēr var kontrolēt kāds ir progress utt. Advancētākas sistēmas kā Jira var veikt arī analīzi par patērēto laiku (ja tas ir būtiski) / salīdzināt to koda versiju kontrolēs sistēmas faktiskajām izmaiņām utt. Liela daļa šo sistēmu nodrošina arī dažādu e-pastu / čatu u.c. integrāciju. Tāpat arī nekas neliedz šādās projekta/koda vadības sistēmās reģistrēt arī lietas, kas tieši neattiecas uz programmēšanu/kodēšanu, proti, sapulces / sarunu transkriptus utt.