#programista15k

  •  

    Mirki i Mirabelki mam pytanie. Zamierzam po godzinach rozwijać się w kierunku PHP (programować jako tako potrafię, radzę sobie z prostymi rzeczami, miałem do czynienia z tym w technikum i na studiach), bo chcę wrócić do IT i kiedyś pracować zdalnie (to nie są widzi misie, po prostu jestem bardziej produktywny gdy wiem co mam do zrobienia, a godziny pracy mogę dopasować pod siebie i nie obciąża mnie dojeżdżanie do biura).

    PHP samo w sobie wystarczy i w końcu będę musiał sięgnąć po framework. Od razu mówię, że interesuje mnie 100% backend, ewentualnie minimalnie front, ale bez grzebania we frontowych frameworkach (js i bootstrap mi wystarczy( ͡° ͜ʖ ͡°)).

    Rozważam Symfony / Laravel lub Magento i nie wiem na co się nastawiać w przyszłości. Pomijam kwestię opłacalności, bo zarówno w jednym jak i w drugim są mniej lub bardziej płatne oferty. Bardziej mi chodzi o to, w którym frameworku idzie bardziej się połapać i jest że tak powiem "przyjemniejszy" w pisaniu.
    Za Symfony przemawia fakt, że na studiach tworzyłem proste aplikacje użytkowe, więc pewnie szybciej bym się odnalazł. Z kolei za Magento przemawiają... obecne trendy i przenoszenie się handlu w coraz większej ilości do sieci.
    Chcę wybrać jeden z nich i w nim stworzyć portfolio, które pomoże mi znaleźć robotę. Może ktoś pomoże mnie nieco ukierunkować ( ͡° ͜ʖ ͡°)

    #php #programowanie
    pokaż całość

    •  

      @MiroslavWalikonsky: Przesyt taki sam, jak w każdym innym popularnym języku. Tj. dużo klepaczy kodu i niedosyt kompetentnych ludzi.
      Oczywiście da się robić stricte backend. Jest tak, jak mówisz - ewentualnie minimalna ilość frontu na zasadzie wyplucia jakiegoś HTML z backendu, żeby front-dev miał z czym pracować. A jak projekt działa na zasadzie SPA (lub czegoś podobnego) + API, to w ogóle frontu nie ruszasz.

      Ruby niewiele jest w Polsce. Ponoć lepiej sytuacja wygląda w niektórych innych krajach na zachodzie.
      pokaż całość

    •  

      mniejszej januszerki, bo nikt pierwszy lepszy w tym nie będzie klepał projektów.

      @MiroslavWalikonsky: Oczywiście, że będzie. Ruby to taki trochę dziadek Pythona. Kiedyś robiło się w tym trochę stronek, ale nie za dużo więcej. To nie COBOL, żeby liczyć na to, że będziesz niezastąpiony i dobrze opłacany za utrzymywanie dużych, ważnych systemów.

      Chcesz mniej januszerki, a przy okazji ciekawą technologię i dobre zarobki, to prędzej C#. Używany zarówno w mniejszych firmach, jak i korpo. Wizytówek nikt w tym pisać nie będzie. Z drugiej strony mniejsza konkurencja, niż w np. Javie.

      Aczkolwiek tak ogólnie to dość "ciekawy" punkt widzenia, żeby celowo szukać zanikającej technologii licząc na brak konkurencji i "ciepły stołek". ( ͡° ͜ʖ ͡°)
      pokaż całość

    • więcej komentarzy (17)

  •  

    Pehapowcy, próbowaliście może swoich sił w Javie albo Kotlinie? Programuje w PHP zawodowo, ale chciałbym pobawić się w adnroid dev. Teraz pytanie co wybrać, Javę czy Kotlin? Przerobiłem kilka prostych tutoriali i jak na razie Java wydaje mi się bardziej podobna do PHP. Kotlin piszą, że jest łatwiejszy, ale na pierwszy rzut oka, lepiej rozumiem kod Javy ( ͡º ͜ʖ͡º)

    Co radzicie?

    #php

  •  

    Mirki, kolejne pytanie o #apiplatform i #symfony

    Mam endpoint z produktami
    /api/products

    Chcę stworzyć endpoint POST /orders to składania zamówień.
    Encja Order (wiem, mysql bedzie krzyczal o nazwe zastrzezona). W niej pewnie dodatkowa encja jak OrderProduct. Payload miałby wygladać mniej więcej tak:

    {
    orderProducts: [
    'api/products/1',
    'api/products/2',
    ]
    }
    Chcę jednak by nie była tam zapisywana relacja do produktów (bo przecież produkt może zniknąć, zostać usunięty lub zostanie zmieniona cena) ale żeby była zapisywana np. nazwa oraz cena po jakiej został sprzedany. Jak to rozwiązać?

    #php
    pokaż całość

    •  

      @mirunek: abstrahując od samego APIPlatform, to dobre spostrzeżenie w kwestii domeny. Element zamówienia i produkt to dwie różne rzeczy. Także przy tworzeniu zamówienia, element na zamówieniu tworzysz na podstawie produktu kopiując potrzebne dane oraz dodając dodatkowe jak ilość, jakieś rabaty itp.

      Cechy produktu, jak cena, nie tylko mogą się zmieniać, ale również np ktoś może mieć rabat na produkt, więc również cena zakupu, a cena produktu to różne rzeczy.

      Jakbyś robił fakturowanie, to pozycja na fakturze to jeszcze co innego niż element zamówienia i produkt więc znów trzeba kopiować niektóre dane.

      Ogólnie mówiąc - słusznie zauważyłeś, że niektóre dane często będą TAKIE same, ale logicznie, to nie są TE same.

      Zwracam uwagę jednak że lepiej nie usuwać produktów, a jedynie je wyłączać z oferty. Lepiej mieć zawsze powiązanie sprzedaży do produktu, bo inaczej potem np trudno zrobić jakiś raport sprzedaży.
      pokaż całość

...to tylko najnowsze aktywności użytkownika zakopiak

Zobacz wszystkie dodane znaleziska, komentarze i wpisy korzystając z menu powyżej.

Popularne tagi zakopiak

Osiągnięcia (4)