×Закрыть
Web Developer
  • Туториал по развертыванию Rails-приложений на Amazon с помощью Docker. Часть 1

    йошки-матрьошки, класна стаття. Грейт сенкс!

  • Используете ли вы pen mouse, эргономичную клавиатуру/мышь?

    кинув адресу його сайту в приватні повідомлення.
    Коли вибирав в інтернетах трекбольну мишу, то бачив 2 варіанти, той що я обрав дозволяє маніпулювати мишою за допомогою вказівного та середнього пальця. Великий та безіменний використовується для натискання на праву і ліву клавішу миші.
    був також варіант, типу як звичайна миша з клавішами, але шар для маніпуляції був пристосований для керування великим пальцем. Про цей варінта нічого не можу сказати.
    В загальному, не відмічав, що при роботі у мене виникали якісь дискомфорти з великим пальцем.

  • Используете ли вы pen mouse, эргономичную клавиатуру/мышь?

    Будь ласка, завжди радий допомогти.

  • Используете ли вы pen mouse, эргономичную клавиатуру/мышь?

    Після тривалих періодів роботи за пк зявились сильні болі, що починались від лопатки, проходили по шиї потилиці і доходили аж до брови правого ока. Біль, до слова, був дуже сильний. Я почав грішити, що то щось не те з нервом чи щось таке. Але після того як я відвідав лікара-костоправа, він сказав, що це перенапружується м’яз, що знаходиться над лопаткою, від постійних мікрорухів правою рукою, що керує мишкою, і це все діло віддає більовими відчуттями в голову. Лікар мені промасажував спину, шию і головне, (Богу дякувати лікар виявився продвинутим чоловіком :) ) що лікар мені порадив придбати тракбол мишку (в інтернетах я знайшов logitech-івську) і почати маніпулювати мишкою лівою рукою. Що і зробив. На разі біль більше мене не турбує. Спочатку перших кілька днів працювати було не зовсім зручно, але терпимо.. зараз вже абсолютно привик і ніякого дискомфорту в роботі не відчуваю. Як висновок можу сказати, що ті всі штуки ергономічні дурень не придумав і часом воно круто стає в пригоді.
    Зараз планую купити ще таку підставку на стіл (щось типу такого stiystil.com.ua/ua/view/solid-32 ), щоб можна було працювати сидячи і стоячи почергово. Працюю, на разі, сидячи, раніше пробував працювати стоячи. І той і той варіант не дуже добре для здоров’я і продуктивної праці, а от по черзі, думаю буде саме те. Тому товариші та товаришині вдосконалюйте своє робоче місце — це шлях у світле майбутнє :)

    Поддержали: Punk Floyd, Joe Forsyte
  • Коваріантність в PHP

    IPayloadFactory закидаєтся як ключ для dependency injection a PayloadFactory, що реалізує цей інтерфейс, буде значенням в DI...

  • Коваріантність в PHP

    Переконали... :)

  • Коваріантність в PHP

    Тут проблема в тому, що якщо Ти в виконаєш метод make() класу B, який повертає інтерфейс А, то далі згідно контракту, ти зможеш з ним працювати виключно, як з обєктом А, а решту функціоналу — це буде як чорний ящик, і використання методів класу В — це вже порушення контракту, що не фантан...

  • Коваріантність в PHP

    Сіра качка, це є та сама качка, просто ще сірого кольору, вона по суті не може бути гускою..

    Поддержал: Dmitriy Tolstoy
  • Коваріантність в PHP

    якщо ChildPayloadFactory повертає iPayload, то це значить, що по контракту, toArray() нам вже не доступний... можна звичайно цей метод використати, в надії, що ми гіпотетично працюємо з класом, який реалізує мотод toArray(), але як на мене це зовсім не Right Way...

  • Коваріантність в PHP

    interface IPayload {
        public static function create(array $data): self;
    }
    
    interface IPayloadFactory {
        public function create(): IPayload;
    }
    
    Тут на вигляд, якась надлишковість по функціоналу. Не зрозуміло, навіщо у фабриці декларувати метод create, і потім при реалізації цієї фабрики ми просто делегуємо виконання методу з сутності, яка породжується цією фабрикою.. тобто і там, і там у нас, фактично одне і те саме.
    По друге, якщо ми реалізовуємо create метод у класі самої сутності, то що робити, якщо потрібно якось по інакшому створити IPayload і нап потрібна інша фабрика, скажімо дані вигрібаються вже не з бази, а з файлу?? Тоді потрібно розширяти Payload, перевизначати в цьому класі метод create(), і тоді вже в dependecy Injection контейнері, якось переприсвоювати інтерфейсу IPayload нову фабрику, яка поверне розширену сутність, зі зміненим методом create()... як на мене дуже багато не потрібних рухів, якщо ж в нас фабрика окремо від сутності, яку вона породжує, тоді просто потрібно створити нову фабрику і все..
  • Коваріантність в PHP

    поки-що, для себе вибрав такий варіант:

    interface IPayload { 
        public function toArray(): array;
    }
    
    interface IPayloadFactory {
        public function create();
    }
    
    class Payload implements IPayload {
        public function toArray(): array {
            return ['hello' => 'world'];
        }
    }
    
    class ChildPayload extends Payload {
        public function setVar(string $var)  {
            $this->var = $var;
        }
    }
    
    interface IChildPayloadFactory extends IPayloadFactory {
        public function create(): ChildPayload;
    }
    
    class ChildPayloadFactory implements IChildPayloadFactory {
        public function create(): ChildPayload  {
            return new ChildPayload();
        }
    }
    
    $factory = new ChildPAyloadFactory();
    
    var_dump($factory->create());
    
    

    В IPayloadFactory прибрав тип, який повинен повертати метод create(), а в IChildPayloadFactory вже вказую той тип, який потрібно...

  • Коваріантність в PHP

    Тут не питання PHP, тут питання філософії.. якщо мені потрібно повернути качку, то хіба буде погано, якщо я поверну качку з яблуками, скажімо... від того качка меньшою качкою не буде.. хоча так тут я погоджуюсь, тут більше проблема в обмеженнях самого PHP...

  • Коваріантність в PHP

    В цьому випадку, напевне це не є далеким від істини.. :), те що в інших мовах програмування, напр С#, це стандарна практика, в PHP, поки не реалізовано.. а шкода.. дуже спомічна штука була б, і архітектурф кода була б лаконічніша.. Так що момент підступно-коварності тут все ж таки є.. :)

    Поддержал: Maksym Huz
  • Коваріантність в PHP

    Не зовсім погоджуюсь.. ChildPayload я не обмежую, а розширюю інтерфейс IPayload. Відповідно, якщо я повертаю ChaildPayload, я автоматично реалізую повертаю і інтерфейс IPayload... Ваше твердження було б справедливим, якби IPayloadFactory повертав би IChildPayload, a IChildPayloadFactory повертав би IPayload, то в такій ситуації дійсно, IChildPayloadFactory повертав би дійсно інтерфейс, який би обмежував батьківську фабрику, тому-що повертав би інтерфейс, який по своєму функціоналу був би обмеженим по відношенню до ChildPayload. А так, на мою думку, контракт(інтерфейс, на відміну від класа) він, по ідеї, повинен бути контрактом, без привязки до назви класу, в цьому і є суть коваріантності, на скільки я розумію...

  • Коваріантність в PHP

    є rfc по цій темі. Шкода, що поки в драфті, а майбутнє його туманне як альбіон..
    wiki.php.net/...​-contravariant-parameters

    Поддержал: Евгений Козлов
  • Коваріантність в PHP

    Воно так і є.. у мене все описано через інтерйфейси, ту не описував, щоб зробити код компактнішим, бо по суті це нічого не змінить..

  • Коваріантність в PHP

    Такий варіант не підходить, тому-що, childPayload-ів є велика кількість (тобто пайлоадів, які реалізують інтерфейс IPayload), кожен пайлоад це типу як DTO-обєкт з get-ерами та set-ерами і кожен, повинен мати свій унікальний набір гетерів і сеттерів, для класу, який буде використовувати цей пайлоад. Тому GenericPayload розширяти від всіх, пайлоадів трохи не серйозно...