Skocz do zawartości

Cała aktywność

Kanał aktualizowany automatycznie     

  1. Wczoraj
  2. Nad czym aktualnie pracujesz?

    Zawsze szanuję robienie rtsów, zawsze chciałem zrobić własny ale nie umiałem. Może kiedyś zbiorę się w sobie i coś takiego wykombinuję
  3. Ostatni tydzień
  4. Nad czym aktualnie pracujesz?

    Jest już nieco poprawiony HUD: I ostatnio zbytnio nic nowego nie dodawałem, w zamian bawiłem się optymalizacją i jak we wstępnej fazie mogłem mieć ciągłe ścinki przy 100 pracownikach, tak teraz nawet na jakimś szrocie udało mi się osiągnąć 500, co prawda prawie ten laptop eksplodował gdy słyszałem jego wiatrak, ale i tak o dziwo ładnie to chodziło
  5. Glorious: Companions

    O! Dawno nie grałem, chętnie przetestuje te nowe rzeczy
  6. Glorious: Companions

    Właśnie wleciał na Steama największy póki co update do gry, wprowadza całkowicie nową grywalną rasę Scarrów. O 19 też zacznie się przecena -50%. Możecie przeczytać więcej info tutaj: https://steamcommunity.com/games/1001040/announcements/detail/3586491361635935246 Albo obejrzeć filmik:
  7. Temat zbiorczy na drobnostki

    Jak piszą w dokumentacji do polecenia buffer_create - "pamiętaj aby usunąć z pamięci", więc tak, siedzi tam ciągle i nie ma garbage collectora. Garbage collector w GMie jest na instancje z niezaznaczonym persistent i tablice.
  8. Zdecydowanie problem leży w twojej konfiguracji sprzętowej-systemowej. Biorąc pod uwagę jak działa GM, ten efekt "mrugania" jest niezależny od tego, w jaki sposób masz zaprogramowane draw. Fakt, że masz pustą listę "Target" oraz inne problemy z samym IDE, świadczy o tym, że jest coś nie tak z instalacją GMS lub uprawnieniami. Debugowanie tego problemu jest praktycznie niemożliwe, dlatego zacząłbym od reinstalacji GMS (ale dokładnie usuń, z %AppData% też). https://help.yoyogames.com/hc/en-us/articles/216753708-How-to-perform-a-fresh-install-of-GM-S-1-4 Poza tym rozważyłbym migrację na 2.0, wiesz z 1.4 będzie już tylko gorzej.
  9. Może musisz ponownie aktywować licencję bo zgubiło.
  10. Nie wiem jak Wam, ale mi to trochę trąca trollingiem, oby to była prawda Jeśli nie, to chyba mamy dobry przykład efektu z wykresu poniżej.
  11. @LolikZabójca2 Dziwię się, że Gnyskowi i spółce chce się z Tobą jeszcze pisać. Po tym co piszesz ewidentnie widać, że masz bardzo małe doświadczenie w ecommerce i mimo tego co Ci piszą rozmówcy, starasz się z nimi dyskutować o rzeczach, o których nie masz pojęcia ze względu na właśnie brak należytego doświadczenia. Nie chcę Cię urazić, no ale nie jesteś partnerem do rozmowy z nimi na takie tematy, skoro i tak wiesz swoje. To ja nie robię w ecommerce (bardziej duże systemy specjalistyczne, niesprzedażowe) a mam większą wiedzę na ten temat od Ciebie i mogę jedynie potwierdzić to co pisze reszta. Nawet nie zdajesz sobie sprawy z tego, że zahaczasz tylko o wierzchołek góry lodowej. Nie znasz realnych case'ów, konsekwencji spieprzenia czegokolwiek w tym zakresie. Śmiesznie się czyta tę całą dyskusję.
  12. Mogę to zrobić, ale pojawił się kolejny, znacznie poważniejszy problem. Przy próbie kompilacji gry, dostaję taki błąd: Wyłączenie i włączenie GM lub komputera nie pomogło, próba odpalenia backupu też, nie działa też żaden z moich innych projektów. Zauważyłem, że pole "Target" jest puste i nie mam żadnych opcji, żeby ustawić na Windows. Wygląda to tak: Nie mam pojęcia, co robić
  13. Temat zbiorczy na drobnostki

    jeśli tworze var x=buffer_create(), a potem go nie usuwam, to on ciągle siedzi w pamięci, do wyłączenia gry?
  14. Wcześniej
  15. Ja myślalem, że ten sklep już powstał, to miało być dwa dni pisania Ale ostatnie zdanie Threefa mówi wszystko w temacie na temat skomplikowania sprawy.
  16. Twoje podejście w tym momencie to: "Jakoś się zrobi", "przecież to tylko podpięcie", "damy radę", "wiem jak". Ale wszystko wskazuje, że nie masz pojęcia jak. Jest to naiwne myśleć, że każdy może siąść i zaplanować, a co więcej napisać sklep internetowy. Samochód też ma 4 koła, drzwi, karoserię, i silnik, który jeździ na paliwo. Paliwo trzeba podawać i działa. Jak ktoś chce to można radyjko zamontować... xD
  17. Ale przepraszam, myślisz, ze kto mi zleca zadania, programista? Pfff. Zadania zleca klient, który zaprogramować, to potrafi najwyżej pralkę. I ja wszystko robię tak, jak on chce i jak wg. jego wizji ma to wyglądać, a nie ja wg. mojej wizji. Jak wrzucam 30 różnych skryptów śledzących, obrazków, google tag managerów, facebook pikseli i chuj wie czego jeszcze, to nie dla tego, że programista uważa, że tak jest lepiej, tylko dla tego, ze przyszedł MARKETINGOWIEC i SPECJALISTA OD SPRZEDAŻY i on takie gówna każe wklejać. Także jest dokładnie na odwrót niż myślisz, bo programiści to są leniwe istoty i robią na skróty, a same formularze i proces sprzedaży upraszczaliby jak się da. Dla mnie wystarczą dwa statusy zamówienia - "oczekujące" i "zrealizowane", ale pan właściciel sklepu potrzebuje 50, a potem sam się w tym gubi. A to okienko tutaj, a to newsletter tam, a to bannerek w tym miejscu, a to pierdoła w tamtym. Każdy sklep ma naprawdę inne wymagania i robienie projektu już pod dwa wymaga, żeby pisać modułowo. I tak się to rozrasta potem. Zapytałeś co musisz wiedzieć przed robieniem sklepu, my, z doświadczeniem mówimy, że na takie coś nie ma się co porywać, bo to jest za duży projekt, i to nie dla tego, że piszemy sklepy na gotowcach, tylko dla tego, że w ogóle mamy doświadczenie w programowaniu (którego Ty w ogóle nie masz, skoro mylisz bezpieczeństwo sklepu z używaniem PDO), albo twierdzisz, że coś da się napisać w godzinę, skoro nawet zrobienie HTMLa i CSSa dla niektórych rzeczy zajmie dłużej, żeby coś się prawidłowo wyświetlało. Owszem, jak chcesz to próbuj, ja jednak nadal będę twierdził, że użycie gotowca jest szybsze, niż pisanie samemu. Ja bym się tego nie podjął, bo żeby zrobić coś uniwersalnego, dla więcej niż jednej osoby wiem, że musiałbym spędzić chyba z kilka lat, żeby to napisać. Jeśli jednak ktoś o sklepach mówi CMS, no to w sumie wszystko mówi na temat poziomu rozmowy i tego, ze nie rozumie faktów które przytaczamy. Żaden z systemów sklepowych, Magento, Presta, Sylius, WooCommerce, OpenCart, ZenCard czy X-Card nie jest CMSem. Część z nich posiada moduł CMS, część z nich działa pod CMSami, ale żaden nie jest. Jedyne z czym się zgodzę, to że prowadzenie sklepu niestety jest drogie i fajnie minimalizować koszty, ale właśnie skorzystanie z gotowca kosztuje w sumie 0zł. I naprawdę sporo da się wyklikać, bez programowania i jestem pewien, że jakbyś powiedział czego potrzebujesz, to większość tych funkcji jest bez wtyczek. Martwisz się też co w momencie, gdy sklep ma aktualizacje. No cóż, to patrzysz co zaktualizowali, jeśli trzeba to poprawiasz kod (chociaż jak poprawka dotyczy jedynie bezpieczeństwa, to jeśli musisz coś poprawić to sam miałeś błąd bezpieczeństwa) i tyle. Nie wrzucasz przecież poprawki na żywca na serwer na pałę. A co do argumentów, że znajomi mają mnóstwo malware itp. - no cóż, jak nie potrafią skonfigurować dobrze serwera, to mają. U mnie klienci nigdy nie mieli z tym problemu, bo zawsze chociażby zmieniamy ścieżkę do panelu admina, blokujemy ją pod konkretne IP, dodajemy htpassword czy nawet wymagamy konkretnego ciasteczka w przeglądarce najpierw. I to są akurat rzeczy do zrobienia w godzinę. Jestem też ciekaw tych faktur. Generujesz fakturę, wtedy wysyłasz ją księgowej i jak będzie zła to poprawisz? Coś chyba tutaj jest nie tak, przecież jak user już pobrał fakturę, to po ptakach. A jak ją sobie wpiszę w KPiR to co, potem mi się skarbówka przywali, bo nie umiałeś dobrze faktury wygenerować? Nie mniej, czekam na pierwsze efekty, na pewno podpowiemy co jest źle i ostrzeżemy przed jakimś fatalnym błędem, zanim pakujesz się w maliny. Pamiętaj tylko, że od początku ostrzegaliśmy, że na maliny w ogóle masz nie iść
  18. Wady pisania własnego sklepu internetowego od zera

    Możemy nawet prosić o kontakt użytkownika z prośbą o edycję danych. Poza tym taki formularz to nie problem. Usunięcie danych to usunięcie(nawet nie wszystkich zgodnie z RODO) danych z bazy. Widzę codziennie problemy kolegów z taką prestą. Widzę co chwilę rzeczy typu "jak usunąć wirusa". Bo ciągle presta ma jakieś backdoory. We własnym sklepie idzie się w tym połapać, w takiej prescie już nikt się nie łapie, bo jest ogromna. Stąd tyle błędów. Po prostu w tym temacie chcę pomocy z przygotowaniem się do pisania takiego sklepu. O tym czy da się te rzeczy zrobić w Presta założę inny. Muszę dokładnie zbadać każdą możliwość. Póki co to widzę więcej gadania "nie da się" niż faktycznych problem. Mocno wyolbrzymiane jest wszystko. Dobre pytanie bo łatwo zweryfikować czy int to int itp. Formularze tego typu to co innego. Jak googlowałem o XSS to tam są informacje o wrzucaniu komuś złośliwego kodu JS, czy PHP i odpalaniu go na różne sposoby. O to pytam. Bo tutaj póki co nie widzę takiej opcji. Ale wiesz o tym, że ja będę miał wszędzie FVAT 23% i w dodatku to idzie potem do księgowej która to sprawdza? Rozumiem, ale meczy mnie takie gadanie trochę. Wiem jaki chce program lojalnościowy i wiem ile się go pisze. Być moze mieli inny. Być może pisali program lojalnościowy pod Prestę albo Magneto wtedy to może trwać latami. I właśnie tego chcę uniknąć. Każdy kto pisał w HTML/CSS/PHP stronę wie, że to kilka operacji na MySQL tylko(o ile piszemy to od zera a nie pod CMS). W tym problem, że podchodzę do tego tak, że chcę uniknąć ryzyka na ile mogę zdobywając najpierw odpowiednią wiedzę. I przykro mi, że zamiast pomocy otrzymuję informacje z cyklu nie rób tego, bo X programistów to nie umie zrobić w Y dni. No ja chcę konkrety, bo to mi nic nie mówi. Zrobię temat o własnym sklepie i zbiorę informację. Potem o tym jak dane rzeczy wdrożyć w Prestę. Na koniec to porównam. Tymczasem ciężej mi zebrać informacje kiedy muszę męczyć się z tłumaczeniem tego, że potrzebuje konkretów, a nie gadania nie bo nie, albo X lat tym się zajmuje i robię na CMS i jest lepiej. Znam też programistów co umieją robić strony tylko na WP i robią to całe życie i NIEKTÓRE strony potrafię szybciej od zera napisać niż oni w WP. I potem sa problemy z edycją czy backdoorami takiego WP plus strona muli przez co spada w Google, a strona w HTML/CSS/PHP potrafi zajmować kilkaset linijek kodu i mieć mniej niż 1mb. Steve Jobs mówił think different - nie torpedujcie jakiegoś pomysłu tylko dlatego, że każdy mówi, że robi się inaczej niż ja proponuje. Pomyślmy o tym w sposób rzeczowy. Zastanówmy się. Właśnie dlatego, że chodzi o dane klientów nie możemy sobie pozwolić na nie konkretne dyskusje. Potrzebuję konkretów. O i to jest właśnie konkrety. To może mi dać jakieś wskazówki. Więc rozważmy to. 1. - nie mam serwisu magazynowego i mieć nie będę. Tylko baza MySQL sklepu. 2 - tego się nie obawiam. A jako, że będę to pisał sam, to będę mógł zrobić promocje czy rabaty tak jak ja chcę. 3 - Numery przesyłek przekopiuje i wkleję bo i tak zamawiam kurierów przez pośredników, a nie bezpośrednio(dla małej firmy wychodzi taniej). Koszty zależne od regionu odpadają(Polska), wagi też. Ceny przesyłek i tak w większości sklepów są stałe. I to są takie rzeczy które np są w prescie a mi nie są potrzebne dlatego pójdzie mi szybciej. No a jakbym potrzebował to co za problem przydzielać każdemu produktowi np. i klasę przesyłki i wybierać w koszyku najdroższą? Można też po KG ale w detalicznym ecommerce takich technik się raczej nie używa. Zasady przesyłki muszą być maksymalnie proste dla klienta. Jeśli się będzie musiał nad tym zastanawiać, pewnie procent zrezygnuje tylko z tego powodu, że nie rozumie skąd dana cena wysyłki i nie ma czasu się nad tym zastanawiać. Dzisiejsi klienci sklepów internetowych oczekują maksymalnej prostoty. 4 - umów nie będzie. Faktury będę generował. Maile wiem jak wysyłać. 5.1 No tu pytanie czy wiem na 100% jak to zrobić czy myślę że wiem. Na pewno PDO żeby nie było MySQL Injection. Na pewno na każdej podstronie weryfikowanie czy nikt się nie "podszywa" pod kogoś kto ma uprawnienia do danej informacji na stronie weryfikując sesję. Coś jeszcze? 5.2 - To wiem, będę pamiętał na pewno. 5.3 - damy radę. 5.4 no to pewnie to co w 5.1 pisaliśmy. Jeśli nie to możecie mi coś dodać od siebie. 6 - no pewnie zależy też od dostawcy bramki. O tym muszę się dowiedzieć jak najwięcej i będę czytał dokumentacje wkrótce. Może nawet jeśli podejmę decyzję że robię od zera to zacznę od napisania obsługi bramek żeby sprawdzić czy podołam. 7. Mógłbyś rozwinąć? No właśnie. Wiedza programistów o ecommerce kończy się na tym, że sprzedaż to dla nich sprzedawca w sklepie, a nie techniki sprzedażowe opracowywane przez specjalistów od sprzedaży. Ciężko programiście uświadomić sobie co na prawdę jest czym. Marketing i sprzedaż to mega skomplikowane sprawy. Ja też pisałbym pod prestę jakiś dodatek dłuuuugo. Dlatego wolę własny silnik gdzie napisanie podstrony to raptem kilkaset linijek, a często kilkadziesiąt, a dodanie jakiegoś widgetu czy formularza to kilkadziesiąt linijek. To zupełnie inny kaliber. Osobie która ma obroty w sklepi 5-10tyś/msc nie są potrzebne programy magazynowe, integracja z systemem dostaw itp. Kuriera zamawia się na jednej stronie, na sklep przekopiowuje numer przesyłki do formularza i gotowe. Z boku możesz dodać przycisk śledź paczkę, a jak bardzo chcesz integrujesz z API jednego z wielu silników który obsługuje śledzenie paczek od wszystkich kurierów i poczt, a nie każdego z osobna. Proste i skuteczne. To ma działać. Dla programisty "dobrze dla klienta" oznacza co innego niż dla gościa od sprzedaży i marketingu. W innych miejscach trzeba doszukiwać się problemu niż w tym, że nie będzie programu magazynowego czy bezpośredniej integracji z systemem wysyłki zamówień. Takie rzeczy się robi jak ma się conajmniej setki przesyłek dziennie. Jeśli sklep zacznie wychodzić poza to powiedzmy 10tyś obrotu miesięcznie to się zainwestuje w rozbudowę. Na początku każdego biznesu jest minimalizowanie kosztów, żeby zbadać rynek i pomysł w praktyce i nie stracić mnóstwa pieniędzy w razie czego. No i żeby nie czekać z próbowaniem swoich sił aż uzbieramy kilkadziesiąt tysięcy złotych tylko zacząć tu i teraz. Można wydawać dużo, a można poświęcić swój CZAS na to by zbadać możliwości jak zaoszczędzić pieniądze. Jasne w sytuacji firmy która z góry wiadomo że będzie miała ponad milion obrotu rocznie robi się odwrotnie. Pompuje się kasę żeby oszczędzić każdą minutę czasu. Zrozumcie też jedno. Nie jest to temat o tym co lepiej wybrać. Dlaczego? Bo ja zbiorę informację jakby to wyglądało. Potem zbiorę jak wyglądałoby przerobienie na preście. Wtedy wypiszę sobie co jakie ma zalety, a jakie wady. I wtedy będzie miejsce na taką dyskusję i rozważania. Podchodzę do tego bardziej poważnie niż może Wam się wydawać. Dlatego zanim podejmę taką decyzję chcę 'zasymulować' jedną i drugą opcję, żeby zobaczyć w takiej 'praktyce' co wyniknie(nie do końca praktyce, bo symulacji tylko, ale to lepsze według mnie niż rozmowa ogólnikami, lepiej mieć sytuację czarno na białym co jakie wady i zalety ma). Tu nie chodzi o to, że ja się uparłem, żeby go pisać od zera na 100%. Chodzi o to, że w tym temacie takie jest moje zadanie, że ja się będę upierał, żeby zrobić wszystko żeby się "udało"(tzn na razie w sensie teoretycznym), a Wy swoimi uwagami pozwolicie mi nie być właśnie olewczym i dostrzec to, czego moje mniejsze doświadczenie w pisaniu sklepów nie pozwala(bo pisałem rożne strony, nawet ruletki internetowe, ale nigdy sklepy). Nie obraźcie się, że się tak upieram przy swoim. Takie moje zadanie w tym temacie. Ale nie chcę tak ciągle gadać o tym, czy ta presta to dobry pomysł czy nie. Chciałbym, żebyśmy na chwilę zapomnieli, że CMSy istnieją. Potem porozmawiamy o tym, jak pewne rzeczy można zrobić w CMSie pokroju Presty. A na sam koniec porównamy co wynikło z jednego i drugiego tematu. To bardzo ważne dla mnie, bo pakuję mnóstwo energii i pieniędzy(względnie, dla mnie to mnóstwo pieniedzy, bo wiadomo, że są tacy co lekką ręką mogą i bańkę wydać na taki sklepik) i muszę wszystko zbadać bardzo dokładnie. Każdą możliwość. Chcę podejmować świadomie każdą decyzję, opierając się na faktach, a nie przeczuciach. Tego nauczyło mnie dotychczasowe doświadczenie jako przedsiębiorcy. Mam nadzieję, że teraz lepiej rozumiecie dlaczego ten temat wygląda tak, a nie inaczej. I dlaczego sprawiam wrażenie takiego któremu się nic nie wytłumaczy. Bo w tym temacie zakładam opcję, że robię od zera i koniec. Chcę sprawdzić co z niego wyniknie. Zakładam tak na potrzeby tego rozważania, a nie że na prawdę jestem 100% pewien, że to super pomysł. Ale mój sposób pracy nie przyjmuje do wiadomości ogólników, bo całe życie spotykam ludzi którzy mówią, że "jak czegoś nie robi się to się nie da, bo ktoś by to już zrobił" i nie jest to bliskie mojemu podejściu do rzeczy. Dzięki wielkie za wkład w temat, bo mimo wszystko parę konkretów padło
  19. 10 lat piszę sklepy internetowe, zrobiłem ich ponad 50, piszę czasem sam bramki do nowych systemów, czy systemy dostaw, a ten mi mówi, ze to kilka linijek... to nie jest tak, ze ja je piszę pod jakiś system, dlatego zajmują mnóstwo kodu, to jest tak, że się nie da krócej, bo ja już znam system i wiem gdzie oszukać i czego nie muszę zrobić, byle to działało. Jak mówię - nie masz nawet pojęcia za co się bierzesz, albo w ogóle nie chcesz 90% funkcjonalności sklepu, które są przydatne MARKETINGOWO i dla SPRZEDAWCY a nie dla programisty. Sporo rzeczy przyspiesza prace, jak da się je zobaczyć w panelu admina (status zamówienia, numery paczek, status płatności) ale rozumiem, wolisz je sprawdzać osobno. I bez odpowiedniego flow dla klienta. Pytanie czy robisz prawdziwy sklep, czy tylko mikro-sklepik na dwóch klientów rocznie.
  20. Czy jesteś w stanie zminimalizowac projekt (oczywiście na kopii) do 1-2 obiektów i podesłać go nam, zebysmy sprawdzili (i upewnić się, ze dalej się psuje)? Inaczej chyba na nic nie wpadnę. Czasem usuwając rzeczy okaże się, ze się magicznie naprawia i znajdziesz problem
  21. integracja stocków z serwisem magazynowym koszyk promocje rabaty potencjalny race condition ze wszystkim, co "daje" jakąś kasę userowi wysyłka integracja z dostawcami, chociaż najdrobniejsza, żeby user znał chociaż numer przesyłki koszty zależne od regionu / wagi przesyłki generowanie maili aktywacyjnych, maili potwierdzających zamówienie pdfów z umowami, fakturami security rejestracja, logowanie nie trzymanie haseł w plainie reset hasła ogólnie cała autoryzacja i autentykacja bramki płatnicze generowanie linków powrót usera case udany/nieudany obsługa callbacków z bramki co jakiś czas zbiorcza odpytka bramki o status wszystkich płatności, jakby callback z jakiegoś powodu nie przeszedł wygasanie płatności ogólnie licz 4 dni robocze na bramkę jeżeli już kiedyś jakąś podpinałeś + 3 dni na rzeczy, które powinny działać, bo są wg. dokumentacji, ale z jakiegoś powodu nie działają (ze 2 miesiące temu podpinałem Soisy, wymieniłem z nimi kilka maili o co chodzi, oczywiście nic mi nie umieli powiedzieć, po czym ich zjebałem że wg dokumentacji callback jest w jsonie, więc raczej nie spodziewasz się nulla w body, a dane tak naprawdę przychodzi w x-www-form-urlencoded - aż dodali to do dokumentacji) GDPR anonimizacja usera tak, żeby było legalnie, ale żeby nie tracić całych serii danych z nim związanych piszesz, że user będzie wprowadzać ilości produktów, mieć konto z danymi i w ogóle - przecież pisałeś, że tylko Ty będziesz wprowadzał treści na stronę? to jak to jest, to będzie podatne na XSS czy nie? "przygotowanie wydruku FVAT, albo ustawienie ilości w magazynie to żaden problem" - to napisz to fakturowanie, skoro na cały projekt zakładasz tydzień to pewnie z tym się wyrobisz w 2h "autorski system programu lojalnosciowego" - have fun, w firmie sporo takich tworzymy i obsługujemy, i to wszystko co piszesz (i co ja pisze) to tylko wierzchołek góry lodowej funkcjonalności programu lojalnościowego, a każdy taki system jest utrzymywany i rozwijany przez minimum 3 programistów 8-16 przyznaj się, chcesz po prostu własny Avon ale nie chcesz bulić jakiejś firmie bańki za kilka podstron edit: to totalnie brzmi jakbym cie zniechęcał, ale nie zrozum mnie źle - to, tak, jak pisze Konrad, bardzo ciekawy i rozwijający projekt, ale podchodzisz do tego wszystkiego zbyt olewczo, i zaprzegasz w to kasę klientów mimo tego, że masz zerową świadomość ryzyka
  22. Dalej nie zrozumiałeś. Siądź sam i przemyśl co ma mieć twój sklep. Mając taką listę możesz wrócić z konkretnymi pytaniami. GDPR widzę że już nie rozumiesz. Nie jest "dane mają być bezpieczne" bezpieczne mają być w każdym serwisie który operuje na danych. GDPR ma pozwalać użytkownikowi na wgląd w swoje dane, możliwość ich edycji oraz usunięcia. I to nie jest zwykłe "usuń z MySQL". Jeżeli chcesz dalej próbować to droga wolna. Ale systemy jak Presta i Magento powstały właśnie po to aby uniknąć 80% tych problemów. Nie łatwo się się je konfiguruje ale też nie robi się tego samemu.
  23. Wady pisania własnego sklepu internetowego od zera

    Sklep nie ma ogarniać podatku w przypadku płatnika zza granicy, bo takiej osobie nic nie sprzedam(koszta wysyłki). Presta też nie ogarnia domyślnie takich rzeczy. Dzisiaj gadaliśmy ze znajomym o problemach które sprawiają, że faktury z Presta zawsze są inne niż po sprawdzeniu przez ksiegową. Na razie nikt nie podał mi konkretnego powodu dlaczego nie. Ja nie potrzebuję wystawiania faktur. Towar będzie in stock kiedy będzie odpowiednia ilość na magazynie. To jeden wpis obok każdego produktu w MySQL. Wygląda mi to trochę jak typowe "nie da się, bo każdy tak mówi". No tak się firm nie prowadzi. Jeśli pomysły rozpatrujemy na te które robią wszyscy i te których się nie da. No póki co każdy mi mówi, że nie bo nie. Tylko sprawdzę jeszcze kwestię bramek płatności bo to jedyny konkret. Ale to nie powinno też sprawiać większych problemów. GDPR czyli RODO - okej ale z tego co wiem to tam nie ma żadnych konkretnych wymagań. Tylko, że dane mają być bezpieczne. Jesteśmy wszyscy programistami, a słyszę, że przygotowanie wydruku FVAT, albo ustawienie ilości w magazynie to problem programistyczny który przezwyciężą tylko nie liczni. Przecież takie rzeczy jak "in stock" to się robi w pierwszym roku nauki programowania.
  24. Nie rozumiesz. Stoisz twardo przy swoim pytając jakie możesz napotkać problemy, podczas gdy jest ich setka. Siądź chwilę i rozpisz sobie co jest ci potrzebne do twojego sklepu. Samo wyświetlanie produktów z bazy to nic. Pomyśl o procedurze sprzedaży. Wystawiania faktur, pilnowaniu czy produkty są "in stock". Procedurach bramek płatnościowych. Przechowywaniu danych usera. GDPR. Rozliczaniu płatników z poza polski. Nie będę wymieniał już. To ty twierdzisz że "programiści gdy projektują takie rzeczy to robią to technicznie, a nie czując potrzeby klienta" więc chyba wiesz czego potrzebuje twój sklep. Jak będziesz miał taką listę to możesz zacząć gdybać ile czasu by ci to zajęło. I to powinien być twój punkt wyjścia. W tym momencie tylko marnujesz siły próbując pytać o szczegóły.
  25. Wady pisania własnego sklepu internetowego od zera

    tzn jestem też programistą. Tylko też marketingowcem i stąd rozumiem dlaczego jest taki problem z komunikacją jednych z drugi. W każdym razie to nie jest istotne takie, po prostu wygodniej mi napisać ręcznie i tyle, nie wchodźmy w szczegóły bo rozmowa marketingowca z programista na takie tematy to jak rozmowa z fanem Linuxa który mówi, że konsola też jest wygodna xd Wiecie, wszystko zależy od punktu siedzenia. Dla programisty presta jest idealna. Dla informatyka Linux. Dla usera Windows, a dla marketingowca Presta to bariera w kreowaniu takiego sklepu, jaki chce. Ależ jestem. Piszę strony internetowe, czy programy. Ale pewnie mniej doświadczonym od Was. Robiłem różne portale posiadające wiele podstron wczytywanych na podstawie MySQL, z panelem admina i edycją treści z jego poziomu. Po prostu chcę się dowiedzieć jakie byłyby utrudnienia w przypadku sklepu bo tu jest wiele newralgicznych danych, Co do bramek płatności rzeczywiście poczytam o tym. Programuję od kilku lat w tym także komercyjnie, ale sklep to po prostu duże ryzyko w razie kary za RODO. W tym cała rzecz Oooo fajny link. To teraz podyskutujmy, bo mnie zaciekawiłeś. MySQL Inject to raczej wiadomo jak ominąć. A czy przepełnienia bufora może spowodować coś więcej niż tylko nie wczytanie strony? Jak to działa w praktyce? Jak unikać zdalnego wykonanie poleceń? Czym jest dokładniej ten opisany background? Manipulacja ceną to raczej mały problem, bo wystarczy po prostu po stronie serwera obliczać ceny produktów a nie clientside. I o czym uprzedził mnie Gnysek sprawdzać czy przedmioty są w odpowiedniej ilości. Jak mam to rozumieć?
  26. Podejrzewam, że Ty nie jesteś programistą, a marketingowcem, z którymi @gnysek ma pewnie masę doświadczenia w pracy ;P Ale nie jesteś programistą, żeby zrozumieć na czym to polega, dlatego ciężko będzie przekazać Ci konkretną wiedzę techniczną (nie da się jej przekazać w jednym zdaniu, żeby napisać stronę ecommerce), skoro nie wiesz jakie to jest skomplikowane - chociażby taka obsługa bramek płatności, jeszcze gorzej, jak będzie trzeba obsłużyć ich kilka, kolejne abstrakcje, kolejne interfejsy które trzeba, niestety, zaprogramować. BTW. To jest prosta i konkretna odpowiedź z doświadczenia a nie z wywyższania się. Albo napisz swoją wtyczkę, w takim np. Presta masz masę gotowych interfejsów w systemie i możesz je obsługiwać jak CI się tylko podoba bez myślenia, jak zaimplementować kolejkowanie zamówień czy obsługę bramek płatności, w tym skonfigurować serwer SMTP i wygenerować oraz wysyłać maile (np. z fakturami) do klientów - a to chyba jest ważne w marketingu? Bo przeważnie nie jest to tak dobry pomysł jakby się wydawało, zwłaszcza, jak nie ma się doświadczenia z programowaniem. Starsi koledzy też pewnie tak myśleli, ja np. napisałem własny sklep dla własnych potrzeb (i kilka innych stron), masa zabawy z tym była... generalnie polecam napisać swój sklep, sporo się nauczysz i zrazisz do takich przekonań Ale tu jest już jakaś funkcja, przez którą będziesz umieszczał dane, dodajmy do tego formularz zgłoszeniowy, że ktoś chce kupić jakiś przedmiot, może nawet bramkę płatności XSS podałem dla przykładu, pierwsza strona Google pod hasłem "common ecommerce website vulnerabilities" - https://lirax.org/6-common-security-vulnerabilities-in-e-commerce-systems/ Jak dla mnie fajny CMS, kilka stron na nim postawiłem i działa naprawdę nieźle - w tym w łatwy sposób można dodawać podstrony bezpośrednio w HTMLu (z wbudowanym silnikiem template'ów). Generowałem w nim PDFy, wysyłałem customizowane maile, zarządzałem użytkownikami (poza adminami/redaktorami ofc.)... Ale nie stawiałem na nim sklepów, tutaj własną wtyczkę musiałbyś dopisać (co jest banalne w October CMS), albo skorzystać z wtyczek z marketu
  27. Wady pisania własnego sklepu internetowego od zera

    Gnysek nie jest marketingowcem i dlatego nie do końca rozumie w czym rzecz. Dlatego proszę ogólnie o konkrety, a nie "nie, bo nie i wybierz prestę". WIdzę jaki problem z nią mają marketingowcy. Albo znajdziesz na coś wtyczkę(najczęściej nie) albo się zgadasz że sklep będzie gorzej sprzedawał. Tu nie chodzi o to, że nie ma wtyczki która robi coś, ale takiej która robi w odpowiedni sposób. Właśnie ciężko opisać programistą różnicę, bo trzeba by podać chociażby podstawowe przykłady z marketingu, ale myślę, że po prostu taka dyskusja jest zbędna. Tutaj nie chodzi mi o przekonanie kogokolwiek do swojej czy czyjejś racji, tylko szukam odpowiedzi technicznych dlaczego to miałby być zły pomysł. Tak dla siebie. Tylko ja bym go używał. XSS - czy ten problem mnie wgl dotyczy skoro nikt poza mną nic nie będzie mógł umieścić na mojej stronie? Właśnie wydaję mi się, że presta jest tak wielka, że zabezpieczenie jest dużo trudniejsze i te łatki to tak na prawdę łatają najczęściej jakieś przeoczenia, a na tak małej stronie która będzie miała maks 10tyś linijek kodu to raczej nie będzie takich problemów. Nie planuję wielkiego CMSa tylko zwykłą stronkę ze sklepem i prostym formularzem dodawania produktów z panelu admina. October_(CMS) - poczytam, dzięki @gnysek xxxxD Nie wiesz nic o programowaniu w takim razie - dobra coś sobie wyjaśnijmy, bo chyba źle się rozumiemy. Ja nie chcę pisać CMSa dla innych. Tylko sklep dla siebie. Robiłem nie sklepy, ale strony o podobnej złożoności. Ile czasu zajmie napisanie strony z listą produktów z sortowaniem itp, podstroną produktu i panelem do dodawania produktów? No to nie jest długo. Robiłem strony o podobnej złożoności od zera. Np. dla muzyka stronę w której miał na stronie głównej widok playlist, w każdą można było wejść i sprawdzić listę utworów z danymi o nich, z informacjami o albumie ogólnie, w każdy utwór jak wszedłeś miałeś linki do różnych platform do odsłuchu itp. Tutaj będzie możliwe, że nawet mniej podstron. Właściwie to trzy podstrony - strona główna, strona kategorii i strona produktu - nie licząć panelu admina. Który nie ma być rozbudowany. Okno tytułu produkt, kategorii, opisu z gotowym silnikiem do obsługi wizualnie HTMLa w inpucie itp. "no ale kto te etapy programuje co? wiesz chociaż jaki jest standard branżowy w e-commerce?" i dlatego my jako marketingowcy się wkurzamy i ja wolałbym napisać to od zera. Bo programiści gdy projektują takie rzeczy to robią to technicznie, a nie czując potrzeby klienta. "przepraszam kto implementuje obsługę bramek płatności? Jak myślisz, ze to działa? Przecież musisz wypuścić ze sklepu klienta do bramki z kwotą i numerem zamówienia, a potem sprawdzić, czy już opłacił. Ja Ci powiem - z doświadczenia, taki kod bramki (gdzie numer karty/przelew robimy po stronie bramki a w sklepie nie pobieramy żadnych danych) to jest kilkadziesiąt plików kodu po kilkaset linijek. I nikt tego nie napisał w tydzień. Paczkomaty czy DHLa też rozumiem w godzinkę rozpykasz, chociaż dużym firmom zajmuje to koło miesiąca." - wybór dostawy to zaznaczenie punktu w formularzu. Nie wiem o czym mówisz. A przekierowanie na stronę płatności i sprawdzenie czy odebrano płatność to dwa pliki. To jest różnica pisania od zera vs presta czy inny wielki CMS gdzie wszystko zajmuje mnóstwo linijek kodu. "Tu znowu śmiechłem. Niedawno odkryliśmy w jednym z systemów, że można ręcznie zedytować ukryty input z ilością sztuk i wpisać 0,1, dzięki czemu kupisz wszystko za 10% ceny. To nie jest SQL injection." no to słuszna uwaga, żeby po prostu w PHP sprawdzać czy nie ma miejsc dziesiętnych. Ale to prosta rzecz. No i dobra załóżmy że kupiłeś 0.1 sztuk. I co wtedy? Przecież ja jako sprzedawca dostanę na zamówieniu 0.1 sztuki i się zorientuję że coś jest nie tak. Ja się bardziej obawiam o jakimś sposobie na wydobycie danych klientów bo kary za RODO są spore. I o tym mówię. 0.1 sztuki to żaden problem bo widać to od razu i nikt nie spakuje 0.1 sztuki do paczki widząc coś takiego, prawda? "Powinno dać Ci do myślenia, dlaczego gotowe sklepy internetowe mają tak dużo plików i są tak wielkie, a nie na 2000 linijek. Serio. Jak chcesz sprzedawać 5 rzeczy, to nie baw się w Presty, tylko wordpresik + woocommerce." - no mają dużo plików bo są bardzo elastyczne, obsługują wtyczki, motywy, szablony itp. Wordpress to ta sama historia. Mi szybciej napisać stronę dla kogoś od zera niż w WP, tym bardziej sklep. No a sam Woo ma wiele wad względem presty i nadaje się na sklepy bardzo małe albo określone. Co do możliwości presty... No właśnie tego programista nie zrozumie. Dla programisty jeśli np. jest formularz zamówienie to jest. A nie wie nawet, ze umieszczenie imienia i nazwiska w jednym polu może wpłynąć na sprzedaż. Nie wie, że czcionka przycisku "zamów" może wpłynąć na zakup. No jest dużo takich szczególików. Po prostu nie chcę rozmawiać o tym, bo to za długi temat i jałowy, bo jakby bez sensu jest ta rozmowa bo ja nie chcę nikogo przekonywać. Mi chodzi o to, że macie większe doświadczenie jako programiści i możecie powiedzieć mi jakie konkretne problemy mogą mnie spotkać podczas pisania takiego sklepu od zera. A nie o tym czy od strony marketingowej to dobry czy zły pomysł. Edytowanie takich szczegółów w presta zajmie mi więcej niż napisanie tego od początku. Tym bardziej że zanim połapię się co jest czym w takim kombajnie to miną wieki. "Próbuj, chętnie zobaczę za tydzień co masz Mogę nawet zrobić review i pokazać wszystkie dziury, bo pewnie bez problemu je znajdę, z zamkniętym jednym okiem." no bardzo chętnie skorzystam z takiej pomocy, bo na pewno będziesz mógł lepiej niż ja ocenić kwestie techniczne. Tylko najpierw wolałbym upewnić się czy warto zanim stracę czas na coś takiego. Może już na tym etapie możecie mnie przed czymś ostrzec. No z tym inputem 0.1 to słuszna uwaga, będę pamiętał, ale pytanie czy nie ma poważniejszych problemów które moglyby doprowadzić do wycieku danych. Dodam, że "silnik" to de facto mój sklep i nie będzie nikomu taki "silnik" udostępniany i nie musi być dostosowany do instalowania szablonów czy coś. Ja będę go edytował w kodzie. Tylko produkty będzie dodawało się przez formularz i jakieś podstawowe ustawienia, resztę bym edytował w kodzie źródłowym. Np. dodanie autorskiego systemu programu lojalnościowego na który nie ma wtyczki w presta zajmie dłużej niż HTML + PHP dla mnie. Chcę też mieć dokładną kontrolę nad każdym pikselem strony od strony designu. Chodzi mi o to, że obsługa CMS wymaga przestudiowania kodu CMS, Własna, prosta strona = prosty kod + znany nam kod. Łatwo go rozwijać nam i dodać jakiś moduł i nie trzeba płacić za wtyczki które i tak prezentują wizję autora wtyczki, a nie moją i musiałbym je przerabiać. Co jak ustaliliśmy jest nie możliwe bo co update musiałbym to robić od nowa, albo zrezygnować z aktualizacji.
  28. Dlatego nikt nie zabiera się za pisanie sklepu od podstaw (pomijając brak wiedzy) tylko od razu uderza się do agencji która zrobi to w krótkim czasie i bez komplikacji. Bazując na doświadczeniu i zaufanym teamie. Chcesz sobie zacząć już to pisać? Zacznij od generowania PDF faktury. Po 2 tygodniach pracy nad tym przemyśl ponownie co chciałeś zrobić. Tylko nie ośmieszaj się, że nie wiesz co ma być na fakturze. Zapytaj specjalisty od sprzedaży. On na 100% będzie wiedział.
  1. Pokaż więcej aktywności
×