Jeśli podobają Ci się moje filmy, to zostaw łapkę w górę i za subskrybuj mój kanał. Zapraszam Cię także do zapoznania się z moimi kursami i warsztatami: 🟢 Kurs Hibernate i JPA - kursy.nullpointerexception.pl/hibernate/ 🟠 Warsztat Architektura Heksagonalna - kursy.nullpointerexception.pl/product/warsztat-architektura-heksagonalna/ 🟢 Kurs Testy Jednostkowe - kursy.nullpointerexception.pl/testy-jednostkowe/ 🟠 Warsztat Architektura Warstwowa - kursy.nullpointerexception.pl/product/warsztat-architektura-warstwowa/
Chłopie, ale ja Cię szanuję za to, że naprawdę dotrzymujesz słowa. Wiele ludzi zachowuje się nieopacznie, rzucając luźno "..., link damy w opisie" i potem gówno w tym opisie jest, tylko link do jakiegoś ich instagrama albo sklepu. Tak, jakby wcale nie oglądali swojego materiału przed wrzuceniem. A u Ciebie na serio zawsze jak wspominasz, że dasz odnośnik do jakiegoś swojego filmu czy artykułu czy czegokolwiek, to faktycznie on tam się znajduje. Super
50% tego o co prosisz już masz na kanale, pytanie czy drugie 50% to aby na pewno domena która interesuje Mateusza. Osobiście nie widzę sensu tworzenia materiałów specjalnie traktujących o połączeniu tych dwóch elementów.
Fajnie jakbyś zrobił film o połączeniu spring rest z jakimś frontem (react/angular) wraz z autoryzacją i uwierzytelnieniem poprzez np JWToken albo BasicAuth
Osobiście nie widzę czemu miałoby to służyć. Backend robisz jak dotychczas np. wystawiasz restowe api, front to już kompletnie inna bajka o której jest masa materiałów i sprowadza się to finalnie do wysłania odpowiednio przygotowanego requestu na odpowiedni endpoint. Połączenia tych dwóch rzeczy w ramach np. jednego projektu niczym się nie różni od materiałów osobno traktujących o wystawianiu api w javie czy o budowaniu aplikacji z wykorzystaniem jakiegoś js'owego frameworka a tego jest pełno.
Dzięki!. Bardzo dobry materiał (jak zwykle:)). Odczuwam niedosyt bo filmy pojawiają się dość rzadko, jednak wolę żeby były publikowane rzadko ale z wysoką jakością :)
Dzięki za komentarz ;) Już niedługo powinno być trochę więcej i bardziej regularnie ;) Mam ostatnio dużo pracy i niestety inaczej się nie da. Przede mną dwa krytycznie tygodnie, jak wszystko pójdzie dobrze, to będzie przynajmniej jeden film w tygodniu.
@@matdabskiJa nie narzekam :) Zdaję sobie sprawę że każdy ma swoje obowiązki. Podoba mi się wyskoa jakość merytoryczna materiałów i cieszę się że trafilem na Twój kanał. Powodzenia!
18:35 "Teraz spring nam tutaj już wstrzyknie" żeby mi wstrzyknęło, muszę dodać @ComponentScan(basePackages = "pakiet_z_webclientem"). Podobnie musiałem zrobić w Controllerze - dodać component scan i podać pakiet do klasy z Serwisem, żeby mi wstrzyknęło ten serwis. Czemu tak jest? Czemu mi nie zaciąga tak samo automatycznie jak Tobie? Korzystam z Javy 17 jakby co i intellij wersji 2023.1.2 Ultimate, ale pewnie to nie ma akurat znaczenia. No i korzystam z Mavena, a nie gradle, może to jest przyczyna?
Zwykle nie trzeba tego dodawać w aplikacji Spring bootowej, bo adnotacja @SpringBootApplication zawiera adnotację @ConponentScan, więc prawdopodobnie zrobiłeś coś niestandardowego i dlatego tak masz.
W jaki sposób są ustawiane pola w obiektach OpenWeatherMainDto, OpenWeatherWeatherDto, OpenWeatherWindDto skoro są prywatne, nie ma setterów, nie ma buildera i nie ma konstruktora, który przyjmowałby odpowiednie argumenty?
Jak dla mnie dzieje się to przy pomocy RestTemplate. Używany jest w metodzie która pobiera dane z zewnętrznego API. Jako argument podajesz tam klasę na którą ma zostać zamieniona odpowiedź. Jeżeli nazwy pól w dto są takie same jak w odpowiedzi json to wtedy rest sam to zmienia w obiekt dto. Mogę się mylić, ale w części o przemapowaniu widać właśnie to co się dzieje.
Wtedy wszystkie twoje komponenty będą powiązane z tym komponentem, który zawiera właśnie tę metodę. Jeśli będziesz w taki sposób rozwiązywał wszystkie swoje problemy z zależnościami (po prostu zmieniał modyfikator dostępu w jakiejś metodzie i używał jej wszędzie), to wszystkie komponenty będą powiązane między sobą, co jest fatalnym rozwiązaniem i drastycznie utrudnia jakikolwiek refaktoring i sprawia, że każda zmiana będzie bardzo czasochłonna. To, co ja proponuję, osobna klasa "klient" i trzymanie tam tej metody, to nic innego jak kompozycja, dzięki której można w elastyczny sposób rozbudowywać swoją aplikację.
Film konkretny i czytelny jak zawsze. Ale mam pytanie. Pracuje z API z GitHub-a, dopóki nie zaimplementowałem return-a poprzez .builder() i gettery pół, endpoint działał prawidłowo. Teraz rzuca mi Exception : "Can not deserialize instance of java.util.ArrayList from Object value (token `JsonToken.START_OBJECT`)" Czy może to być związane z typem zwracanym ? Problem z konwersją na JSON ??
Dto dla OpenWeather to imho trochę przekombinowana koncepcja. Jeszcze ładniej by to wyglądało z użyciem JsonSlurper dostępnego w Groovy. Z odpowiedzi API w json bezpośrednio tworzysz obiekt bez mapowania na dto dla OpenWeather i mapujesz tej obiekt na generyczny dla aplikacji dto. Jeszcze łatwiej by się utrzymywało taki kod w przypadku zarówno konieczności zmiany logiki biznesowej jak i wybrania nowego providera. Chyba, że w kodzie chciałbyś zaimplementować logikę tylko dla danego providera, to wtedy dto dla niego jest jak najbardziej przydatne.
Proponujesz dokładnie to samo co zrobiłem ja z DTO, tylko chcesz do tego użyć innych "dodatkowych" narzędzi. Chcesz zamienić jsona na obiekt przy użyciu JsonSlurper. Dokładnie to samo jest tutaj robione za pomocą RestTemplate w Javie - zmieniam jsona na obiekt. Nie ma tu żadnego przekombinowania, to jest dokładnie to samo.
@@matdabski W zasadzie tak, ale jest pewna drobna różnica, bo jednak z JsonSupplerem nie trzeba deklarować klas DTO dla OpenWeather. Tylko stworzyć bezpośrednio obiekt z odpowiedzi http i go bezpośrednio mapować na DTO, które zwraca kontroler. Ona według mnie minimalnie poprawia czytelność kodu dzięki braku klas DTO dla providerów.
Oczywiście, że jest różnica. Jedno to Groovy, a drugie to Java. Chcesz używać JsonSlurper w Javie? Czy chcesz to zrobić w Groovym, bo nie do końca rozumiem? Jeśli chcesz w Groovym to ok, bo ja też bym to zrobił inaczej w Groovym, bo to inny język i daje inne możliwości. A jeśli chcesz używać JsonSlurper w Javie, to trochę bez sensu, bo z metody parse() dostajesz anonimowy obiekt, więc i tak albo musisz go jakoś zmapować na dto, albo możesz go rzutować co najwyżej na mapę. Ja tutaj pokazuję jak zrobić to w Javie i RestTemplate, i tak się to po prostu robi w tych narzędziach.
@@matdabski Miałem na myśli zrobienie tego w Groovym z JsonSlurperem. Może nieprecyzyjnie się wyraziłem, bo w sumie zastanawiam się czy da się podobnie to zrobić w Javie tak jak w Groovym, czyli aby nie tworzyć dto dla providera i, żeby równocześnie kod był czysty.
W Javie nie da się tego tak zrobić, co najwyżej możesz jsona zamieniać na mapę i wtedy będziesz mógł odwoływać się do pól poprzez mapa.get("nazwa_pola"), ale to jest strasznie niewygodne i tak się nie robi, lepiej jest stworzyć DTO. Tak to po prostu robi się w Javie. Groovy to język skryptowy dynamicznie typowany (chociaż też ma wbudowane statyczne typowanie). Java jest statycznie typowana, dlatego pewne konstrukcje w niej nie są możliwe, a za to w Groovym i innych językach skryptowych dynamiczne typowanych są. Oba podejścia (dynamiczne i statyczne typowanie) mają swoje wady i zalety. W skrócie to wygląda tak, że w dużych skomplikowanych aplikacjach wolę mieć statyczne typowanie, bo mam zapewnioną ochronę w czasie kompilacji (chociaż Grooviewgo też można kompilować:)). A zwykle jak coś robię na szybko, to często wolę to zrobić w języku dynamicznie typowanym (też często skryptowym), bez podawania typów, bo tak jest po prostu szybciej. Kiedyś programowałem w języku dynamicznie typowanym i myślałem, że to cudowny wynalazek, dopóki nie zacząłem programować w Javie i wtedy zrozumiałem, że jednak statyczne typowanie rozwiązuje naprawdę bardzo wiele problemów i dzisiaj świadomie nie chciałbym rezygnować ze statycznego typowania.
To może oznaczać, że dostajesz jakąś nieprawidłową odpowiedź z usługi. Np. taką, w której nie ma elementu main. Wtedy metoda openWeatherWeatherDto.getMain() zwraca null, więc wywołanie kolejnej metody .getTemp() na nullu daje NullPointerException. Kolejna sprawa to zmienna openWeatherWeatherDto teoretycznie też może być nullowa, ale jak wszystko zrobiłeś dobrze, to nie powinno mieć miejsca. Najlepiej spróbować to z debugować i zobaczyć co w tym miejscu jest nullem Oczywiście przyczyn tego może być wiele.
@@matdabski Udało mi się znaleźć. Pola w klasie 'OpenWeatherWeatherDto' miały u mnie nazwy openWeatherMainDto i openWeatherWindDto. Poprawiłem na main i wind i śmiga ;)
Kurde, napisałem drugi komentarz o tym że aplikacja nie widziała beana. Chciałem coś dopisać do tego komentarza, ale zniknął stąd... wtf? Czemu by mógł zostać usunięty? Nie przypuszczam, żebyś Ty go usunął, więc wtf? A dodał się raczej, bo był widoczny po dodaniu... ech
Jeśli podobają Ci się moje filmy, to zostaw łapkę w górę i za subskrybuj mój kanał. Zapraszam Cię także do zapoznania się z moimi kursami i warsztatami:
🟢 Kurs Hibernate i JPA - kursy.nullpointerexception.pl/hibernate/
🟠 Warsztat Architektura Heksagonalna - kursy.nullpointerexception.pl/product/warsztat-architektura-heksagonalna/
🟢 Kurs Testy Jednostkowe - kursy.nullpointerexception.pl/testy-jednostkowe/
🟠 Warsztat Architektura Warstwowa - kursy.nullpointerexception.pl/product/warsztat-architektura-warstwowa/
jeden z lepszych tutoriali jakie widziałem. Dziękuję
Dzięki Wojtek ;)
Fajnie przedsawione: jasno i klarownie. Trzeba zrobić małą przerwę od głównego projektu i pobawić się API :)
Dzięki ;)
Dzięki za ten oraz inne Twoje tutoriale. Sporo pomagają w nauce. Jak się odrobię to na pewno wrócę do Twoich kursów :)
Rewelacja! Takie filmy ogląda się z przyjemnością! Proszę o więcej :)
Dzięki ;)
Po tym wideo wszystko, co do tej pory sie nauczyłem zostało połączone w całość! Super Panie Mateuszu dziękuje za materiał - czekam na więcej!
Dzięki ;)
Chłopie, ale ja Cię szanuję za to, że naprawdę dotrzymujesz słowa. Wiele ludzi zachowuje się nieopacznie, rzucając luźno "..., link damy w opisie" i potem gówno w tym opisie jest, tylko link do jakiegoś ich instagrama albo sklepu. Tak, jakby wcale nie oglądali swojego materiału przed wrzuceniem.
A u Ciebie na serio zawsze jak wspominasz, że dasz odnośnik do jakiegoś swojego filmu czy artykułu czy czegokolwiek, to faktycznie on tam się znajduje. Super
Dzięki ;)
Super filmik!
Czekam na jakiś filmik aplikacji Spring Boot + Angular :D
Dzięki, nie wiem kiedy, ale będzie ;)
50% tego o co prosisz już masz na kanale, pytanie czy drugie 50% to aby na pewno domena która interesuje Mateusza. Osobiście nie widzę sensu tworzenia materiałów specjalnie traktujących o połączeniu tych dwóch elementów.
Złoto i absolutna perełka - materiał !
Dzięki ;)
Jak zwykle świetny materiał, z bardzo dobrym, zrozumiałym wytłumaczeniem. Oby jak najwięcej takich! :)
Dzięki ;)
Fajnie jakbyś zrobił film o połączeniu spring rest z jakimś frontem (react/angular) wraz z autoryzacją i uwierzytelnieniem poprzez np JWToken albo BasicAuth
Mam w planach taki temat, nie wiem kiedy, ale na pewno będzie ;)
@@matdabski Popieram przedmówcę, a najlepiej z Vue ;)
Osobiście nie widzę czemu miałoby to służyć.
Backend robisz jak dotychczas np. wystawiasz restowe api, front to już kompletnie inna bajka o której jest masa materiałów i sprowadza się to finalnie do wysłania odpowiednio przygotowanego requestu na odpowiedni endpoint. Połączenia tych dwóch rzeczy w ramach np. jednego projektu niczym się nie różni od materiałów osobno traktujących o wystawianiu api w javie czy o budowaniu aplikacji z wykorzystaniem jakiegoś js'owego frameworka a tego jest pełno.
Bardzo konkretny odcinek. Wleciał subik
Dzięki ;)
Dzięki!. Bardzo dobry materiał (jak zwykle:)). Odczuwam niedosyt bo filmy pojawiają się dość rzadko, jednak wolę żeby były publikowane rzadko ale z wysoką jakością :)
Dzięki za komentarz ;) Już niedługo powinno być trochę więcej i bardziej regularnie ;) Mam ostatnio dużo pracy i niestety inaczej się nie da. Przede mną dwa krytycznie tygodnie, jak wszystko pójdzie dobrze, to będzie przynajmniej jeden film w tygodniu.
@@matdabskiJa nie narzekam :) Zdaję sobie sprawę że każdy ma swoje obowiązki. Podoba mi się wyskoa jakość merytoryczna materiałów i cieszę się że trafilem na Twój kanał. Powodzenia!
A ja się nie tłumaczę ;) Mówię jak jest ;) Też chciałbym, żeby tu było więcej ciekawych materiałów ;) Dzięki ;)
Świetny odcinek, wielkie dzięki. Przydałby się teraz kolejny o reaktywnym WebCliencie :)
Super robota, fajnie to wytłumaczyłeś
Dzięki ;)
Akurat się tego uczę, dzięki!
Dzięki za komentarz ;)
Fajny odcinek, dobra robota 👍
Dzięki Paweł 😉
Łapka w górę i oglądamy!
Dzięki ;)
Bardzo dobry odcinek :) mogłeś jako wisienkę na torcie dać jeszcze asynchroniczne wywołania.
18:35 "Teraz spring nam tutaj już wstrzyknie" żeby mi wstrzyknęło, muszę dodać @ComponentScan(basePackages = "pakiet_z_webclientem"). Podobnie musiałem zrobić w Controllerze - dodać component scan i podać pakiet do klasy z Serwisem, żeby mi wstrzyknęło ten serwis. Czemu tak jest? Czemu mi nie zaciąga tak samo automatycznie jak Tobie?
Korzystam z Javy 17 jakby co i intellij wersji 2023.1.2 Ultimate, ale pewnie to nie ma akurat znaczenia. No i korzystam z Mavena, a nie gradle, może to jest przyczyna?
Zwykle nie trzeba tego dodawać w aplikacji Spring bootowej, bo adnotacja @SpringBootApplication zawiera adnotację @ConponentScan, więc prawdopodobnie zrobiłeś coś niestandardowego i dlatego tak masz.
Super materiał.
Dzięki Robert ;)
super
W jaki sposób są ustawiane pola w obiektach OpenWeatherMainDto, OpenWeatherWeatherDto, OpenWeatherWindDto skoro są prywatne, nie ma setterów, nie ma buildera i nie ma konstruktora, który przyjmowałby odpowiednie argumenty?
Jak dla mnie dzieje się to przy pomocy RestTemplate. Używany jest w metodzie która pobiera dane z zewnętrznego API. Jako argument podajesz tam klasę na którą ma zostać zamieniona odpowiedź. Jeżeli nazwy pól w dto są takie same jak w odpowiedzi json to wtedy rest sam to zmienia w obiekt dto. Mogę się mylić, ale w części o przemapowaniu widać właśnie to co się dzieje.
Cześć, jak testować API, tak żeby test nam się nie wywalił przy braku dostępu do internetu ?? Będę wdzięczny za odpowiedź :)
14:30 "i co zrobić w takiej sytuacji?" hmmm... zmienić modyfikator dostępu do tej metody na "public" i używać jej wszędzie? :D
Wtedy wszystkie twoje komponenty będą powiązane z tym komponentem, który zawiera właśnie tę metodę. Jeśli będziesz w taki sposób rozwiązywał wszystkie swoje problemy z zależnościami (po prostu zmieniał modyfikator dostępu w jakiejś metodzie i używał jej wszędzie), to wszystkie komponenty będą powiązane między sobą, co jest fatalnym rozwiązaniem i drastycznie utrudnia jakikolwiek refaktoring i sprawia, że każda zmiana będzie bardzo czasochłonna. To, co ja proponuję, osobna klasa "klient" i trzymanie tam tej metody, to nic innego jak kompozycja, dzięki której można w elastyczny sposób rozbudowywać swoją aplikację.
Film konkretny i czytelny jak zawsze. Ale mam pytanie.
Pracuje z API z GitHub-a, dopóki nie zaimplementowałem return-a poprzez .builder() i gettery pół, endpoint działał prawidłowo.
Teraz rzuca mi Exception : "Can not deserialize instance of java.util.ArrayList from Object value (token `JsonToken.START_OBJECT`)"
Czy może to być związane z typem zwracanym ? Problem z konwersją na JSON ??
Tak, typ zwracany to obiekt (jakiś), a ty próbujesz z tego zrobić tablicę ;)
Pierwszy :) Fajny temat poruszyłeś
Dzięki, daj znać, czy się podobało jak już obejrzysz ;)
Witam! Czy dane pobrane z api serwisu internetowego mogę bezpośrednio wyświetlić w mojej apce desktopowej czy wymagany jest do tego spring?
Możesz wyświetlać gdzie chcesz. Albo inaczej patrząc, możesz pobierać w dowolnej aplikacji i w niej wyświetlać potrzebujesz tylko klienta http do tego
@@matdabski Oki dzięki! Pogrzebie i może wykombinuje
Dto dla OpenWeather to imho trochę przekombinowana koncepcja. Jeszcze ładniej by to wyglądało z użyciem JsonSlurper dostępnego w Groovy. Z odpowiedzi API w json bezpośrednio tworzysz obiekt bez mapowania na dto dla OpenWeather i mapujesz tej obiekt na generyczny dla aplikacji dto. Jeszcze łatwiej by się utrzymywało taki kod w przypadku zarówno konieczności zmiany logiki biznesowej jak i wybrania nowego providera. Chyba, że w kodzie chciałbyś zaimplementować logikę tylko dla danego providera, to wtedy dto dla niego jest jak najbardziej przydatne.
Proponujesz dokładnie to samo co zrobiłem ja z DTO, tylko chcesz do tego użyć innych "dodatkowych" narzędzi. Chcesz zamienić jsona na obiekt przy użyciu JsonSlurper. Dokładnie to samo jest tutaj robione za pomocą RestTemplate w Javie - zmieniam jsona na obiekt. Nie ma tu żadnego przekombinowania, to jest dokładnie to samo.
@@matdabski W zasadzie tak, ale jest pewna drobna różnica, bo jednak z JsonSupplerem nie trzeba deklarować klas DTO dla OpenWeather. Tylko stworzyć bezpośrednio obiekt z odpowiedzi http i go bezpośrednio mapować na DTO, które zwraca kontroler. Ona według mnie minimalnie poprawia czytelność kodu dzięki braku klas DTO dla providerów.
Oczywiście, że jest różnica. Jedno to Groovy, a drugie to Java. Chcesz używać JsonSlurper w Javie? Czy chcesz to zrobić w Groovym, bo nie do końca rozumiem? Jeśli chcesz w Groovym to ok, bo ja też bym to zrobił inaczej w Groovym, bo to inny język i daje inne możliwości. A jeśli chcesz używać JsonSlurper w Javie, to trochę bez sensu, bo z metody parse() dostajesz anonimowy obiekt, więc i tak albo musisz go jakoś zmapować na dto, albo możesz go rzutować co najwyżej na mapę. Ja tutaj pokazuję jak zrobić to w Javie i RestTemplate, i tak się to po prostu robi w tych narzędziach.
@@matdabski Miałem na myśli zrobienie tego w Groovym z JsonSlurperem. Może nieprecyzyjnie się wyraziłem, bo w sumie zastanawiam się czy da się podobnie to zrobić w Javie tak jak w Groovym, czyli aby nie tworzyć dto dla providera i, żeby równocześnie kod był czysty.
W Javie nie da się tego tak zrobić, co najwyżej możesz jsona zamieniać na mapę i wtedy będziesz mógł odwoływać się do pól poprzez mapa.get("nazwa_pola"), ale to jest strasznie niewygodne i tak się nie robi, lepiej jest stworzyć DTO. Tak to po prostu robi się w Javie.
Groovy to język skryptowy dynamicznie typowany (chociaż też ma wbudowane statyczne typowanie). Java jest statycznie typowana, dlatego pewne konstrukcje w niej nie są możliwe, a za to w Groovym i innych językach skryptowych dynamiczne typowanych są. Oba podejścia (dynamiczne i statyczne typowanie) mają swoje wady i zalety. W skrócie to wygląda tak, że w dużych skomplikowanych aplikacjach wolę mieć statyczne typowanie, bo mam zapewnioną ochronę w czasie kompilacji (chociaż Grooviewgo też można kompilować:)). A zwykle jak coś robię na szybko, to często wolę to zrobić w języku dynamicznie typowanym (też często skryptowym), bez podawania typów, bo tak jest po prostu szybciej. Kiedyś programowałem w języku dynamicznie typowanym i myślałem, że to cudowny wynalazek, dopóki nie zacząłem programować w Javie i wtedy zrozumiałem, że jednak statyczne typowanie rozwiązuje naprawdę bardzo wiele problemów i dzisiaj świadomie nie chciałbym rezygnować ze statycznego typowania.
Mi w klasie WeatherClient w linii 20 rzuca nullpointera. Już nie mam pomysłu co jest nie tak. Ktoś ma pomysł może?
To może oznaczać, że dostajesz jakąś nieprawidłową odpowiedź z usługi. Np. taką, w której nie ma elementu main. Wtedy metoda openWeatherWeatherDto.getMain() zwraca null, więc wywołanie kolejnej metody .getTemp() na nullu daje NullPointerException.
Kolejna sprawa to zmienna openWeatherWeatherDto teoretycznie też może być nullowa, ale jak wszystko zrobiłeś dobrze, to nie powinno mieć miejsca.
Najlepiej spróbować to z debugować i zobaczyć co w tym miejscu jest nullem
Oczywiście przyczyn tego może być wiele.
@@matdabski Dziękuję za odpowiedź. Będę szukac:)!
@@matdabski Udało mi się znaleźć. Pola w klasie 'OpenWeatherWeatherDto' miały u mnie nazwy openWeatherMainDto i openWeatherWindDto. Poprawiłem na main i wind i śmiga ;)
Fajnie gdybyś zrobił jakiś mniejszy projekt w oparciu o techniki TDD i DDD.
To chyba musiałby być jakiś spory kurs ;) Nie wiem, czy znajdę tyle czasu, żeby coś takiego przygotować. Zobaczymy
Kurde, napisałem drugi komentarz o tym że aplikacja nie widziała beana. Chciałem coś dopisać do tego komentarza, ale zniknął stąd... wtf? Czemu by mógł zostać usunięty? Nie przypuszczam, żebyś Ty go usunął, więc wtf? A dodał się raczej, bo był widoczny po dodaniu... ech
TH-cam czasem gubi komentarze ;) chociaż nie wiem, czy tak się stało w tym przypadku, bo widzę kilka twoich komentarzy.
No masz łeb chłopie
WEATHER_URL ;)