ИТ фирми и пракси во Скопје

  • Креатор на темата Креатор на темата StaticStupid
  • Време на започнување Време на започнување
Прегледај го приврзокот 291539

на кратко ако кодот не е кеширан на првиот реквест се складира во OPCache ако е веќе кешран од кешот се извршува директно во машински код. Сепак ова ќе се користи пред се при процесирањето на long-running processes кои би се појавиле при machine learning и deep learning. Python we are getting there :)

Само Ц++ мојт да го брка пајтонот во оваа област за големи сетови, ама кога станува збор за тајм ту маркет и брзина на прилагодување на код на одредени измени мислам дека пајтон е неприкосновен. За брзина се држиме со Cython :D
 
Немам воопшто чепнато Котлин затоа те прашав, инаку имам работено Јава. Сакам да почнам Пајтон или нешто Блокчејн и затоа прашав за Котлин дали тоа да терам или претходниве две :D
Nullable types не е толку проблем и Optional си врши работа. Со java records веќе немора да користиш Ломбок и ќе се скрати boilerplate code што се кратеше со Ломбок веќе од јдк 17 ќе има LTS и ќе може да ја кроистиме. First class citizens се слагам дека е недостаток. Ќе се најде начин и другите недостатоци да се надокндат им текна да ја мрднуваат малку работата па еве јдк 17 ќе има доста новини :P
Nullable тип не е исто со Optional.
Пример, ако во Java пишува дека некој метод враќа String, тогаш може да ти врати или String или null. Ако методот ти враќа Optional<String>, може да ти врати Optional што има вредност, Optional што нема вредност или null.
Во Kotlin, метод може да ти врати "String" или "String?". "String?" e еквивалтен на Optional, со тоа што Optional секогаш креира 2 објекти, додека "String?" не креира дополнителен wrapper (Во compile time се додаваат само not null проверки).

Е сега, за да можеш да го имаш истото однесување како во Kotlin, ќе мораш да си поставиш правило/конвенција, дека секој метод што е nullable ќе мора да враќа Optional. Затоа што ништо не те спречува да вратиш null од метод кој што претходно не враќал null.
Ама не е исто да поставиш конвенција и да имаш ограничување директно во јазикот :D
 
Немам воопшто чепнато Котлин затоа те прашав, инаку имам работено Јава. Сакам да почнам Пајтон или нешто Блокчејн и затоа прашав за Котлин дали тоа да терам или претходниве две :D
Nullable types не е толку проблем и Optional си врши работа. Со java records веќе немора да користиш Ломбок и ќе се скрати boilerplate code што се кратеше со Ломбок веќе од јдк 17 ќе има LTS и ќе може да ја кроистиме. First class citizens се слагам дека е недостаток. Ќе се најде начин и другите недостатоци да се надокндат им текна да ја мрднуваат малку работата па еве јдк 17 ќе има доста новини :P

нене, за разлика од обични јава класи, records немаат setters туку само се креираат getters, equals, hashCode и toString методите.
Records ќе служат само како data carriers (датата се става само во конструкторот) најчесто за immutable ствари и во некои случаеви како DTOs. Така да Ломбок ќе си живее уште :D
 
Само Ц++ мојт да го брка пајтонот во оваа област за големи сетови, ама кога станува збор за тајм ту маркет и брзина на прилагодување на код на одредени измени мислам дека пајтон е неприкосновен. За брзина се држиме со Cython :D

Пајтон ко јазик е прилично спор и повикува готови precompiled C/C++ библиотеки. Доколку некој се нафати да ги креира тие готови библиотеки во PECL не гледам која би била разликата од Пајтон и зошто не би можел да го брка пајтонот?
 
Пајтон ко јазик е прилично спор и повикува готови precompiled C/C++ библиотеки. Доколку некој се нафати да ги креира тие готови библиотеки во PECL не гледам која би била разликата од Пајтон и зошто не би можел да го брка пајтонот?
Мислев од аспект на должина на код и едноставност.
 
Поминаа деновите кога PHP беше серен и критикуван дека е премногу спор или во јазикот имаше срања кога на варијабла можеш да и доделиш објект како вредност и со тоа да креираш нов објект. Денес јазикот добива асинхрони особености со помош на библиотеки како Swoole. Со помош на корутини кои всушност претставуваат lightweight threads кои комуницираат меѓу себе и делат state за разлика од stateless NGINX каде секој I/O (реквест) е изолиран и е врзан за еден процес кој го извршува кодот на синхрон начин чекајќи response or in a blocking way. Тоа не е случај со корутините кои го извршуваат кодот на асинхрон начин користејќи помалку ресурси, како и синтакса која е "синхрона" односно без async && await срањата во javascript каде со овие зборчиња означуваш кој дел од кодот да ти се извршува асинхроно. Нема повеќе конфигурирање на сервери во конф фајлови, сега може да се бутира сервер програматично. Се надевам дека во брзо време ова ќе стане нативна особина на јазикот и веќе имаме RFC за PHP Fibers што у превод е еквивалент на корутините од Swoole. Со ова се решаваат два проблема првиот е спајкот на конкурентни реквести кои се процесираат од multiple event loops, вториот е решавањето на проблемот со извршување на кодот на синхрон или blocking начин. А резултатите од тоа се денес PHP е рамо до рамо со Go. Ова се benchmark резултати од споредбата PHP 7.4 (не PHP 8.0 или PHP 8.1) vs Node vs Go

Да да, и јас користам фотосинтеза некогаш во експресијалното изразување за да звучам поинтелигентно :D Читам ова и ми иди сликава од мајмунов во музејов, едино јас сум мајмунот тука. Шала на страна, пошто пишав дека сум за мобиле дев, во двоумица сум за котлинов, али барем месец два нема да изгубам ако учам концептиве за Јава, пошто нели котлинов е базиран на Јава, па да свртам на него после.
 

Attachments

  • 117300680_294291831852113_3860181438481278020_n-3427092875.jpg
    117300680_294291831852113_3860181438481278020_n-3427092875.jpg
    98,8 KB · Прегледи: 21
6. Поминаа деновите кога PHP беше серен и критикуван дека е премногу спор или во јазикот имаше срања кога на варијабла можеш да и доделиш објект како вредност и со тоа да креираш нов објект. Денес јазикот добива асинхрони особености со помош на библиотеки како Swoole. Со помош на корутини кои всушност претставуваат lightweight threads кои комуницираат меѓу себе и делат state за разлика од stateless NGINX каде секој I/O (реквест) е изолиран и е врзан за еден процес кој го извршува кодот на синхрон начин чекајќи response or in a blocking way. Тоа не е случај со корутините кои го извршуваат кодот на асинхрон начин користејќи помалку ресурси, како и синтакса која е "синхрона" односно без async && await срањата во javascript каде со овие зборчиња означуваш кој дел од кодот да ти се извршува асинхроно. Нема повеќе конфигурирање на сервери во конф фајлови, сега може да се бутира сервер програматично. Се надевам дека во брзо време ова ќе стане нативна особина на јазикот и веќе имаме RFC за PHP Fibers што у превод е еквивалент на корутините од Swoole. Со ова се решаваат два проблема првиот е спајкот на конкурентни реквести кои се процесираат од multiple event loops, вториот е решавањето на проблемот со извршување на кодот на синхрон или blocking начин. А резултатите од тоа се денес PHP е рамо до рамо со Go. Ова се benchmark резултати од споредбата PHP 7.4 (не PHP 8.0 или PHP 8.1) vs Node vs Go

Прегледај го приврзокот 291548

  1. Go — 35,509 req/s
  2. PHP Swoole — 34,919 req/s
  3. NodeJS — 21,626 req/s
Максимална искористеност на сите threads на CPU

Прегледај го приврзокот 291550

  1. NodeJS — 20%
  2. PHP Swoole — 49,33%
  3. Go — 50,67%
Помала искористеност на меморија во споредба со Node

Прегледај го приврзокот 291551

статијава е на индиски или така нешто, така да не верувам дека некој ќе се замара да чита

Да те надополнам, еве уште еден benchmark на web frameworks на кој налетав пред некоја недела. Интересни резултати. Баш ме интересира како би котирал новиот Laravel Octane на листава.

 
За почетници, игнорирајте ги дискусииве, тотално се небитни кога сте на почеток на кариера. :D
 
Да те надополнам, еве уште еден benchmark на web frameworks на кој налетав пред некоја недела. Интересни резултати. Баш ме интересира како би котирал новиот Laravel Octane на листава.


Ќе биде побрзо. Тејлор се зафатил со најголемата болка на Ларавел а тоа е бутстрапирањето/иницијализирањето на Ларавел, кое беше споро и беше главната причина да биде критикуван фрејмворкот. Од ова што го прочитав е дека бутстрапот на апликацијата ќе се случува само на првиот реквест и дека регистрирањето на сервис провајдерите и врзувањето на сервисите во контејнерот, како и поминувањето на реквестот низ мидлверите, се тоа ќе биде ставено во Swoole Tables односно in-memory. До сега се тоа се случуваше на секој реквест односно целиот свет беше креиран и уништуван во еден реквест, сега ќе биде state-full и воркерите ќе можат да го споделуваат тој state а секој нов реквест. Друго што видов е нешто во врска со конкурентноста, во Swoole е возможно да креираш process/worker pools па така со елоквент ќе може да се извршуваат паралелни квериња и преку код ќе можеш да контролираш кои квериња да се извршат. За ова Road Runner прв пат слушам искрено.

1618163220459.png

Еве како изгледа кодот со корутини. Ко што кажав корутини се еден вид на linux threads (подединица на процес) кои се врзуваат/мапираат со реквестот/реквестите.

Еве ги резултатите nginx vs swoole


знаејќи со какви се компоненти располага swoole не би ме чудело да видиме и нешто ко laravel pub-sub i laravel scraper.
 
дали некој знае нешто за талент програмата во Seavus?
 
Последно уредено:
По огласиве слабо се наоѓа, дали заради ситуацијава не се примаат толку практиканти, но ако има некој да ми предложи некоја компанија за пракса у областа web development, поточно Spring Boot со React/Angular?
 
По огласиве слабо се наоѓа, дали заради ситуацијава не се примаат толку практиканти, но ако има некој да ми предложи некоја компанија за пракса у областа web development, поточно Spring Boot со React/Angular?
Помина рокот за државни субвенции за практиканти :D Следен бран огласи очекувај периодот септември-октомври.
 
Од Битола е фирмава, ама јак им е огласов :D (требало да стават практикантство, со 3-5 години чистач нема да најдат за овие пари).
Само за возачката 15 треба да му дадат :D
1619039120155.png
 

Kajgana Shop

Back
На врв Bottom