Forum: - Szukam programisty... do napisania serwisu foto

Forum: / Fotografia cyfrowa 2008 / Szukam programisty... do napisania serwisu foto

Autor	Wiadomość
4x5	Posted: 19 Lis 2008 10:37:26 Szukam kogoś sensownego, kto napisałby serwis typu plfoto, według mojej specyfikacji. Zależy mi na osobach, które się na tym znają, bo już kilkunastu "fachofcóf" wymiękło... Nie da się tego zrobić na gotowcach, trzeba pisać całość. Czarek
Winetoo	Posted: 19 Lis 2008 10:54:09 Szukam kogoś sensownego, kto napisałby serwis typu plfoto, według mojej specyfikacji. Zależy mi na osobach, które się na tym znają, bo już kilkunastu "fachofcóf" wymiękło... Nie da się tego zrobić na gotowcach, trzeba pisać całość. Za ile i na kiedy? :-))) Dobra żartowałem i tak obecnie nie mam czasu. Nie wiem, jak w Warszawie, ale na śląsku to najłatwiej i najlepiej (a często też najtaniej) szukać na polibudzie wśród studentów informatyki i pokrewnych. Gdy sam studiowałem to bywało trochę podobnych ogłoszeń i wiem, że część kolegów żyła z takich zleceń. Jedynym problemem może być czas. Jeśli potrzebujesz to na szybko i nie chcesz gotowców to chyba tylko firma zatrudniająca więcej osób. Pewnie to wiesz, ale student studentowi nierówny :-) Mamy niż demograficzny i mature giertycha i uczelnie obniżyły wymagania nawet na obleganych kierunkach, więc najpierw zobacz jego portfolio. Pozdrawiam Winetoo
Dizel	Posted: 19 Lis 2008 11:30:32 Szukam kogoś sensownego, kto napisałby serwis typu plfoto, według mojej specyfikacji. Zależy mi na osobach, które się na tym znają, bo już kilkunastu "fachofcóf" wymiękło... Nie da się tego zrobić na gotowcach, trzeba pisać całość. Aha. I ma być co najmniej tak stabilny jak plfoto, skalowalny, z API w REST na XML dostępnym z zewnątrz, front w PHP na kilku serwerach plus backend jako sensownie skalowalny serwer aplikacyjny w J2EE (z DAO Factories, wszystko co się da patternami, projekt oparty na DDD)? Chętnie. Jakieś trzy miesiące, ok. 30-40 tysięcy brutto. Oczywiście dostarczasz projekt graficzny i grafika? :)
ps	Posted: 19 Lis 2008 12:23:45 (..) Chętnie. Jakieś trzy miesiące, ok. 30-40 tysięcy brutto. Oczywiście dostarczasz projekt graficzny i grafika? :) To w sumie niedrogo chcesz. Ale.. i tak za drogo :)
Dizel	Posted: 19 Lis 2008 12:42:15 Chętnie. Jakieś trzy miesiące, ok. 30-40 tysięcy brutto. Oczywiście dostarczasz projekt graficzny i grafika? :) To w sumie niedrogo chcesz. Ale.. i tak za drogo :) Ja to wiem. Ty to wiesz. Czarek nie :o)
Arek (G)	Posted: 19 Lis 2008 12:47:12 Szukam kogoś sensownego, kto napisałby serwis typu plfoto, według mojej specyfikacji. Zależy mi na osobach, które się na tym znają, bo już kilkunastu "fachofcóf" wymiękło... Nie da się tego zrobić na gotowcach, trzeba pisać całość. Aha. I ma być co najmniej tak stabilny jak plfoto, skalowalny, z API w REST na XML dostępnym z zewnątrz, front w PHP na kilku serwerach plus backend jako sensownie skalowalny serwer aplikacyjny w J2EE (z DAO Factories, wszystko co się da patternami, projekt oparty na DDD)? Aleś wodotrysków nasadził:) Chętnie. Jakieś trzy miesiące, ok. 30-40 tysięcy brutto. Oczywiście dostarczasz projekt graficzny i grafika? :) 3 miesiące? Kurde wydajny jesteś jak cholera:) Arek
Dizel	Posted: 19 Lis 2008 13:02:49 Aleś wodotrysków nasadził:) Alternatywą jest PanGąbka :) 3 miesiące? Kurde wydajny jesteś jak cholera:) Eeeno, przecież to wszystko znane patterny są. Samo się pisze :)
Jakub Jewuła	Posted: 19 Lis 2008 12:42:17 Aha. I ma być co najmniej tak stabilny jak plfoto, skalowalny, z API w REST na XML dostępnym z zewnątrz, front w PHP na kilku serwerach plus backend jako sensownie skalowalny serwer aplikacyjny w J2EE (z DAO Factories, wszystko co się da patternami, projekt oparty na DDD)? Chętnie. Jakieś trzy miesiące, ok. 30-40 tysięcy brutto. Oczywiście dostarczasz projekt graficzny i grafika? :) Budzet juz znam, umiejetnosci masz? Powaznie pytam - po nowym roku bede mial robote na pol roku, rok. Duzy serwis cos tak jak piszesz... q
Dizel	Posted: 19 Lis 2008 13:19:01 Budzet juz znam, umiejetnosci masz? Powaznie pytam - po nowym roku bede mial robote na pol roku, rok. Duzy serwis cos tak jak piszesz... - Priv :)
Arek (G)	Posted: 19 Lis 2008 13:21:48 Aleś wodotrysków nasadził:) Alternatywą jest PanGąbka :) Przecież do dużo bardziej banalny serwis, po co tam J2EE? Co do PanaGąbki źle to teraz działa?:) 3 miesiące? Kurde wydajny jesteś jak cholera:) Eeeno, przecież to wszystko znane patterny są. Samo się pisze :) No jasne. A co jeśli coś ma być niestandardowe? Takie składanie z klocków IMHO jest dobre na szybki start. Choć w sumie, i tak nie wiadomo jak to będzie żyło. Arek
Jakub Jewuła	Posted: 19 Lis 2008 13:21:59 Aha. I ma być co najmniej tak stabilny jak plfoto, skalowalny, z API w REST na XML dostępnym z zewnątrz, front w PHP na kilku serwerach plus backend jako sensownie skalowalny serwer aplikacyjny w J2EE (z DAO Factories, wszystko co się da patternami, projekt oparty na DDD)? Chętnie. Jakieś trzy miesiące, ok. 30-40 tysięcy brutto. Oczywiście dostarczasz projekt graficzny i grafika? :) Budzet juz znam, umiejetnosci masz? Powaznie pytam - po nowym roku bede mial robote na pol roku, rok. Duzy serwis cos tak jak piszesz... przy takim projekcie to chyba jakiś stały mastah niezbędny? Oczywiscie. Glowna czesc roboty bedzie trwala < pol roku, potem start systemu i dalsza rozbudowa, a jeszcze pozniej oczywiscie stala kontrola, poprawki etc. Zdaje sobie sprawe z tego, ze ktos na stalej umowie bedzie konieczny. Nawet niekoniecznie jedna osoba. q
Dizel	Posted: 19 Lis 2008 13:40:18 Aleś wodotrysków nasadził:) Alternatywą jest PanGąbka :) Przecież do dużo bardziej banalny serwis, po co tam J2EE? A jak chcesz to skalować jakby co? Wiesz jak by plfoto działało jako np. PHP z zaszytymi query? A jak Czarek chce sklepik? Zarządzanie zdjęciami? Rozszerzyć funkcjonalność potem? Udostępnić API? Zrobić backend z prawdziwego zdarzenia? :) Co do PanaGąbki źle to teraz działa?:) Bo przepisali.. :) 3 miesiące? Kurde wydajny jesteś jak cholera:) Eeeno, przecież to wszystko znane patterny są. Samo się pisze :) No jasne. A co jeśli coś ma być niestandardowe? Przykład? :) Takie składanie z klocków IMHO jest dobre na szybki start. Ejno, czekaj, wiesz co to design patterns? :)
Dizel	Posted: 19 Lis 2008 14:49:16 REST jak i udostępnianie czegoś na zewnątrz uważam w kontekście tego konkretnego problemu jako zbędne wodotryski. Nie potrzebnie zwiększające koszt całości. Cchesz logikę biznesową i dostęp do bazy wsadzić we front? :) Zauważ, że całe ustrojstwo które zaproponowałeś same z siebie sporo waży Niebardzo. Czas odpowiedzi dobrze napisanego serwera aplikacyjnego jest znacznie krótszy, niż zapytania z PHP do bazy. i już na wstępie ma dużo większe wymagania zarówno ze strony sprzętowej jak i administrowania. Że nie wspomnę o większych wymaganiach na developerów. Co innego stawiać serwis w php a co innego w j2ee. Ten drugi napis kosztuje co najmniej dwa razy więcej:) Jeszcze więcej kosztuje gdy sklep klęka bo jest za dużo userów. Albo dodanie backoffice do dodawania towarów wymaga pisania wszystkiego po raz wtóry albo wręcz rozpruwania całości "bo się tabele w bazie zmieniły" ;) Chodzi mi tylko o dobór kalibru armaty do problemu. Dla mnie to ciągle armata na wróble. Niechwytasz. Czarek chciałby dwa tysiące za całość jak go znam :) I aby była jasność zdaje sobie sprawę, że z PHP pewnej granicy się nie przeskoczy ale... ale ta granica wcale nie leży tak nisko. Jeśli się okazuje, że zaczyna być przekraczana to już wiadomo, że serwis załapał więc można włożyć w niego dalsze inwestycje. Robienie tego od razu IMHO nie ma sensu. Może i masz rację - patrzę ze swojej perspektywy, gdzie "mała" aplikacja pracuje na load balancerze i obsługuje naście tysięcy requestów na sekundę. Inna rzecz, że gdy pracowałem w Onecie i napisałem backend mechanizmu suggest (tą "podpowiadaczkę" na inputach), to to było tylko troszkę C, komunikacja po czystych socketach i mimo to działa do teraz :) Nie tak. Nic nie zastąpi glowy - szczególnie przy Domain Driven Development, gdzie większość czasu spędzasz z kartką papieru i Visual Paradigmem :). Patterny są użyreczne przy typowych operacjach, wytstępujących w website, są przetestowane i nie ma sensui ich zmieniać. No właśnie typowych i tu jest jasność. Typowy znaczy na przykład "mechanizm dostępu do bazy danych" czy "mechanizm wątkowania".. ;) Tak wyglądają takie klocki. One nie narzucają żadnych ograniczeń :) Ale to dla mnie - jak stwierdziłem powyżej armata na wróble. Owszem możemy się brandzlować technologiami, pytanie tylko po co?:) Serio oddałbyś poważnemu klientowi projekt z kwerendami do MySQLa zaszytymi we froncie? :)
Arek (G)	Posted: 19 Lis 2008 15:21:10 REST jak i udostępnianie czegoś na zewnątrz uważam w kontekście tego konkretnego problemu jako zbędne wodotryski. Nie potrzebnie zwiększające koszt całości. Cchesz logikę biznesową i dostęp do bazy wsadzić we front? :) A gdzie to napisałem? Zauważ, że całe ustrojstwo które zaproponowałeś same z siebie sporo waży Niebardzo. Czas odpowiedzi dobrze napisanego serwera aplikacyjnego jest znacznie krótszy, niż zapytania z PHP do bazy. No tego nie byłbym taki pewien chyba, że potrafisz to jakoś potwierdzić. Aczkolwiek nie neguje, że w większych rozwiązaniach serwer aplikacyjny daje większe możliwości rozkładania obciążenia. Inna sprawa, że w PHP też się da nawet widziałem przykłady - aczkolwiek to już jest totalny przerost formy nad treścią:) i już na wstępie ma dużo większe wymagania zarówno ze strony sprzętowej jak i administrowania. Że nie wspomnę o większych wymaganiach na developerów. Co innego stawiać serwis w php a co innego w j2ee. Ten drugi napis kosztuje co najmniej dwa razy więcej:) Jeszcze więcej kosztuje gdy sklep klęka bo jest za dużo userów. Albo dodanie backoffice do dodawania towarów wymaga pisania wszystkiego po raz wtóry albo wręcz rozpruwania całości "bo się tabele w bazie zmieniły" ;) Jak sklep zaczyna klękać, znaczy, że czas zacząć myśleć o inwestycjach:) No chyba, że możesz sobie na to pozwolić od razu to jasna sprawa, ale tu nie mamy z tym do czynienia. Natomiast nie rozumiem tego o rozpruwaniu całości. Ja nie rozumiem dlaczego w php nie można zaprojektować sensownej architektury serwisu. Na prawdę bardzo ładnie można sobie tak rozdzielić aby w razie czego podnieniać tylko pewne elementy, które siadają. I aby była jasność zdaje sobie sprawę, że z PHP pewnej granicy się nie przeskoczy ale... ale ta granica wcale nie leży tak nisko. Jeśli się okazuje, że zaczyna być przekraczana to już wiadomo, że serwis załapał więc można włożyć w niego dalsze inwestycje. Robienie tego od razu IMHO nie ma sensu. Może i masz rację - patrzę ze swojej perspektywy, gdzie "mała" aplikacja pracuje na load balancerze i obsługuje naście tysięcy requestów na sekundę. Inna rzecz, że gdy pracowałem w Onecie i napisałem backend mechanizmu suggest (tą "podpowiadaczkę" na inputach), to to było tylko troszkę C, komunikacja po czystych socketach i mimo to działa do teraz :) Aby była jasność, nie dywagujemy co jest lepsze (bo wiadomo, że lepsze jest lepsze). Tylko na co można sobie pozwolić w określonej sytuacji. To tak jak z kupnem samochodu. Możesz sobie gdybać, który fajniejszy, który ma fajniejszy silnik, lepsze bajery i co tam wolisz. Ale jak przyjdzie do zakupu to już inne kryteria będą brane pod uwagę:):) I o to chodzi. No właśnie typowych i tu jest jasność. Typowy znaczy na przykład "mechanizm dostępu do bazy danych" czy "mechanizm wątkowania".. ;) A co za różnica, jedno i drugie maksymalnie typowe:) Tak wyglądają takie klocki. One nie narzucają żadnych ograniczeń :) Ale to dla mnie - jak stwierdziłem powyżej armata na wróble. Owszem możemy się brandzlować technologiami, pytanie tylko po co?:) Serio oddałbyś poważnemu klientowi projekt z kwerendami do MySQLa zaszytymi we froncie? :) Tyle, że ja o niczym takim nie pisałem.:) Pozdrawiam, Arek
Arek (G)	Posted: 19 Lis 2008 15:42:03 Może i masz rację - patrzę ze swojej perspektywy, gdzie "mała" aplikacja pracuje na load balancerze i obsługuje naście tysięcy requestów na sekundę. Inna rzecz, że gdy pracowałem w Onecie i napisałem backend mechanizmu suggest (tą "podpowiadaczkę" na inputach), to to było tylko troszkę C, komunikacja po czystych socketach i mimo to działa do teraz :) a to z tobą tak wdałem się w dyskusję o big sysach :) Chyba nie, bo nie kojarzę. Arek
4x5	Posted: 19 Lis 2008 18:44:58 http://bi.adagp.fr PHP+MySQL. Design z 2001. Ponad ROK pracy kilkuosobowego zespołu, przy stale zmieniających się założeniach projektowych. A i tak nie jest najszybsze.. Dobry przykład. Właśnie nie interesują mnie serwisy, które zgłaszają się takim komunikatem: http://dybowski.pl/all/adagp.jpg Czarek
Dizel	Posted: 19 Lis 2008 19:11:16 http://bi.adagp.fr PHP+MySQL. Design z 2001. Ponad ROK pracy kilkuosobowego zespoĹu, przy stale zmieniajÄcych siÄ zaĹoĹźeniach projektowych. A i tak nie jest najszybsze.. Dobry przykĹad. WĹaĹnie nie interesujÄ mnie serwisy, ktĂłre zgĹaszajÄ siÄ takim komunikatem: http://dybowski.pl/all/adagp.jpg Skoro nie umiesz przeczytaÄ co tam jest napisane, to rzeczywiĹcie masz problem.. PS Ale i tak nie staÄ CiÄ i dorabiasz ideologiÄ. Jak zwykle zresztÄ..
Bronek Kozicki	Posted: 19 Lis 2008 19:39:34 Serio oddałbyś poważnemu klientowi projekt z kwerendami do MySQLa zaszytymi we froncie? :) MVC. Model-View-Controller? Jak każdy design pattern, nie jest uniwersalny. Poza tym - controller we front-end w PHP? Eeee. B.
lrem	Posted: 19 Lis 2008 20:14:44 Dizel nabazgrał: Dobry przykład. Właśnie nie interesują mnie serwisy, które zgłaszają się takim komunikatem: http://dybowski.pl/all/adagp.jpg Skoro nie umiesz przeczytać co tam jest napisane, to rzeczywiście masz problem.. Czemu tekst wygląda jak z translatora? Oryginalnie było tylko fr?
Dizel	Posted: 19 Lis 2008 20:15:56 Dizel nabazgraĹ: Dobry przykĹad. WĹaĹnie nie interesujÄ mnie serwisy, ktĂłre zgĹaszajÄ siÄ takim komunikatem: http://dybowski.pl/all/adagp.jpg Skoro nie umiesz przeczytaÄ co tam jest napisane, to rzeczywiĹcie masz problem.. Czemu tekst wyglÄda jak z translatora? Oryginalnie byĹo tylko fr? Francuzy wpisaĹy. ByĹo fr + pustka na wypeĹnienie ang. To byĹo oddane w 2001 i majÄ pewnie wĹasnego webmastera. Na site sÄ zapewne jeszcze wiÄksze kwiatki po angielskawemu, znajÄc FrancuzĂłw :)
lrem	Posted: 19 Lis 2008 20:13:37 Dizel nabazgrał: Czemu tekst wygląda jak z translatora? Oryginalnie było tylko fr? Francuzy wpisały. Było fr + pustka na wypełnienie ang. To było oddane w 2001 i mają pewnie własnego webmastera. Na site są zapewne jeszcze większe kwiatki po angielskawemu, znając Francuzów :) Tak właśnie myślałem... Ale przy okazji miałem spytać: co sądzisz o .NET? Ostatnio powoli oswajam się z myślą, że jednak kiedyś też będę musiał uciec się do takich źródeł dochodu, ale mam uczulenie drobne na Javę :/
Adam Płaszczyca	Posted: 19 Lis 2008 21:02:03 Dobry przykład. Właśnie nie interesują mnie serwisy, które zgłaszają się takim komunikatem: http://dybowski.pl/all/adagp.jpg Znaczy, chcesz drożej?
Dizel	Posted: 19 Lis 2008 22:05:43 Tak wĹaĹnie myĹlaĹem... Ale przy okazji miaĹem spytaÄ: co sÄdzisz o .NET? Ostatnio powoli oswajam siÄ z myĹlÄ, Ĺźe jednak kiedyĹ teĹź bÄdÄ musiaĹ uciec siÄ do takich ĹşrĂłdeĹ dochodu, ale mam uczulenie drobne na JavÄ :/ C#. IMO najsensowniejszy jÄzyk z.net. Spodoba Ci siÄ - bardziej przemyslany niĹź Java z jej schizofrenicznym mechanizmem exceptions :)
lrem	Posted: 19 Lis 2008 22:15:02 Dizel nabazgrał: Tak właśnie myślałem... Ale przy okazji miałem spytać: co sądzisz o .NET? Ostatnio powoli oswajam się z myślą, że jednak kiedyś też będę musiał uciec się do takich źródeł dochodu, ale mam uczulenie drobne na Javę :/ C#. IMO najsensowniejszy język z.net. Spodoba Ci się - bardziej przemyslany niż Java z jej schizofrenicznym mechanizmem exceptions :) Nie no, język to akurat znam wystarczająco dobrze. Pytam w kontekście tych paskudnie rozlazłych systemów, o których jest dyskusja. W sensie, pod stronę, zamiast J2EE.
Dizel	Posted: 19 Lis 2008 22:33:00 Dizel nabazgraĹ: Tak wĹaĹnie myĹlaĹem... Ale przy okazji miaĹem spytaÄ: co sÄdzisz o .NET? Ostatnio powoli oswajam siÄ z myĹlÄ, Ĺźe jednak kiedyĹ teĹź bÄdÄ musiaĹ uciec siÄ do takich ĹşrĂłdeĹ dochodu, ale mam uczulenie drobne na JavÄ :/ C#. IMO najsensowniejszy jÄzyk z.net. Spodoba Ci siÄ - bardziej przemyslany niĹź Java z jej schizofrenicznym mechanizmem exceptions :) Nie no, jÄzyk to akurat znam wystarczajÄco dobrze. Pytam w kontekĹcie tych paskudnie rozlazĹych systemĂłw, o ktĂłrych jest dyskusja. W sensie, pod stronÄ, zamiast J2EE. Kontaktu duĹźego z .net nie miaĹem, z tego co pamiÄtam to problemy byĹy dwa. Pierwszy, to oczywiĹcie kwestia platformy pod ktĂłrÄ Twoja aplikacja ma dziaĹaÄ. Porty na Linuxa dopiero sie tworzÄ. Drugi to zamkniÄty status podstawowych elementĂłw, takich jak np. WinForms. Z drugiej strony, jeĹli przewidujesz tworzenie aplikacji na serwery Win, to .net moĹźe byÄ rĂłwnie dobrym wyborem, co Java. A znowuĹź, jak masz awersjÄ do javy, a nie chcesz siÄ zamykaÄ w Win32, to moĹźe Python? Python + CherryPy + SQLAlchemy - i masz pozamiatane, a jÄzyk prosty i do pewnego stopnia dobrze siÄ skaluje. Do pewnego stopnia, bo byÄ moĹźe trafisz na problem wielowÄtkowoĹci w Pythonie albo na dziwactwa SQLAlchemy - ale to dopiero przy duĹźych projektach i czÄĹÄ z nich da siÄ obejĹÄ. A Pythona znajdziesz w tej chwili chyba na kaĹźdym serwerze :)
lrem	Posted: 19 Lis 2008 22:38:23 Dizel nabazgrał: A znowuż, jak masz awersję do javy, a nie chcesz się zamykać w Win32, to może Python? Python + CherryPy + SQLAlchemy - i masz pozamiatane, a język prosty i do pewnego stopnia dobrze się skaluje. Do pewnego stopnia, bo być może trafisz na problem wielowątkowości w Pythonie albo na dziwactwa SQLAlchemy - ale to dopiero przy dużych projektach i część z nich da się obejść. A Pythona znajdziesz w tej chwili chyba na każdym serwerze :) To ja już wolę Javę, na nią mam drobną alergię ;)
Dizel	Posted: 19 Lis 2008 22:38:27 A Pythona znajdziesz w tej chwili chyba na kaĹźdym serwerze :) To ja juĹź wolÄ JavÄ, na niÄ mam drobnÄ alergiÄ ;) A, trafiĹeĹ na wÄtki czy CherryPy i wylatujÄce poĹÄczenia z bazÄ? :)
lrem	Posted: 19 Lis 2008 23:00:11 Dizel nabazgrał: A Pythona znajdziesz w tej chwili chyba na każdym serwerze :) To ja już wolę Javę, na nią mam drobną alergię ;) A, trafiłeś na wątki czy CherryPy i wylatujące połączenia z bazą? :) Nie, po prostu Pythona nie lubię bardziej niż Javy. Ja Perlista jestem, tylko Catalyst, choć dość fajny i elastyczny, to skaluje się ponoć jak jakiś Rails. No i ciężko skompletować zespół piszący w tym samym narzeczu ;)


° Forum ° Odpowiedz ° Rejestracja ° Szukaj °