-
41. Data: 2014-03-25 01:45:31
Temat: Re: Programista iOS - Łódź
Od: Roman W <b...@g...pl>
On Mon, 24 Mar 2014 12:06:58 -0700 (PDT), Wojciech
Muła<w...@g...com> wrote:
> To jest system backoffice, który wspiera bardzo różne procesy
> w bankach (np. obieg dokumentów, sprawy windykacyjne). No i jak
> zweryfikujesz, że nie kłamię?
A do czego ten system potrzebuje równań nieliniowych?
RW
-
42. Data: 2014-03-25 01:52:24
Temat: Re: Programista iOS - Łódź
Od: Roman W <b...@g...pl>
On Mon, 24 Mar 2014 23:52:25 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> Chcesz z gównianym jezyku wynajdywac kwadratowe koła. To jest
własnie
> slabośc PHP: tam *NIC* nie ma. Epoka kolejki łupanej, wszystko
musisz
> sam wydłubać z kamienia jesli masz potrzebę większa niz nastepne
forum o
> hiphopie. I to ma być *profesjonalny* język który bank używa na
codzień?
> Może jednak robi te grafiki sprzątaczek w banku.
Wewnętrzne systemy w bankach bywaja zadziwiająco i żenująco slabe. W
duzym europejskim banku (naprawdę dużym, ponad 100tys. pracowników,
na liście "systemowo waznych") w którym pracowałem wewnętrzny system
HR (urlopy, zwolnienia lekarskie, dane adresowe, itd.) najpierw
zaczął uniemożliwiac edycję pól a potem padł zupełnie i już nigdy nie
wstal - musieliśmy wszystko załatwiać emailami. Zenada.
RW
-
43. Data: 2014-03-25 01:54:23
Temat: Re: Programista iOS - Łódź
Od: Roman W <b...@g...pl>
On Mon, 24 Mar 2014 11:12:08 +0100, bartekltg <b...@g...com>
wrote:
> O PHP rozumiem, ale ogólnie w "technologiach webowych"
> bywa różnie. Znajomy siedzi blisko jquery, pokazywał
> ostatnio, co tam wprowadzają. Aby wspierać asynchroniczność
> i pozbyć się dlugiej listy callbacków wprowadza się
> promise'y i coś na kształt prostych coroutine (jak to się
> po polsku nazywa, wikpediowe "wspolprogramy" chyba mylące).
> Od razu stwierdziłem, że szeregowy klepacz stronek tego
> nie będize zbyt świadomie używał, ale widać zapotrzebowanie
> jest.
W mojej firmie tego używają (w angularJS).
RW
-
44. Data: 2014-03-25 02:04:39
Temat: Re: Programista iOS - Łódź
Od: Roman W <b...@g...pl>
On Mon, 24 Mar 2014 23:52:25 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> PHP to kupa. Nie wierzę że ludzie pracujący w bankach są aż tak
> przeraźliwie głupi aby wybrać go na krytycznej ścieżce
Przypominam ze mówimy o branży w ktorej nadal obraca sie miliardami
dolców za pomocą arkuszy Excela wypełnionych makrami VBA pisanymi
przez ludzi bez żadnego wykształcenia programistycznego (traderzy po
czymkolwiek albo quanci po fizyce/matmie).
Banki maja tendencje do długiego trzymania przy zyciu systemow
zbudowanych dawno temu przy uzyciu antycznych technologii ktore juz
dawno przestały byc uwazane za wskazane dla "critical systems" (np.
COBOL) albo dorobily sie lepszych zastepnikow (np. Excel VBA). Ale
PHP nigdy nie mieścił sie w zadnej z tych dwu kategorii.
RW
-
45. Data: 2014-03-25 08:11:35
Temat: Re: Programista iOS - Łódź
Od: Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl>
W dniu 2014-03-24 19:33, Sebastian Biały pisze:
> On 2014-03-24 08:10, Tomasz Kaczanowski wrote:
>> A co za różnica, w jakim języku napisze się subsystem do obsługi stron
>> www?
>
> A zastanawiałeś się jakoś głębiej dlaczego stron www nie pisze się np. w
> asm? Przeciez to żadna różnica, nie?
Może i żadna, tyle, że to są same widoki, czyli więcej pracy dla grafika
i speca od css-u, logika jest tam zazwyczaj bardzo ograniczona do kilku
funkcji komunikującej się z jakimś serwerem, który da dostęp do
niektórych danych z bazy właściwej + trochę prac nad zabezpieczeniem
logowania itp rzeczami, więc tu nie potrzeba odkrywać czegokolwiek, więc
język nie jest aż tak istotny, bo tam nie ma aż tak skomplikowanych rzeczy.
>
>> On i tak nie ma (przynajmniej jak pracowałem nad takimi systemami,
>> to zaden z nich nie miał) bezpośredniego dostępu do bazy bankowej.
>
> Nawet by mi nie przyszło do glowy że ten PHP w banku ma dostęp do
> jakiejkolwiek bazy danych większej niż dyżury sprzątaczek.
Była to normalna strona dla klientów. Muszę powiedzieć, że na owe czasy
jedna z wygodniejszych jakie testowałem, ale to zasługa osoby, która
nadzorowała projekt i po własnych doświadczeniach w różnych
internetowych bankach powiedziała jak to ma się zachowywać od strony
gui. A czy to byłoby stworzone w PHP, czy w czym innym, to tylko widok...
--
Kaczus
http://kaczus.ppa.pl
-
46. Data: 2014-03-25 08:14:35
Temat: Re: Programista iOS - Łódź
Od: Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl>
W dniu 2014-03-24 15:30, g...@g...com pisze:
> Przyklad: programu napisanego w asemblerze jednej maszyny
> nie uruchomisz na innej maszynie (chyba ze na emulatorze).
> To jest przyklad braku tej elastycznosci. Moglbym wymienic
> kilka innych.
Kwestia definicji co jest emulatorem, a co nim nie jest... W sumie teraz
procesory mają swój microkod, więc można by uznać, że w emulatorze
działa coś z definicji...
--
Kaczus
http://kaczus.ppa.pl
-
47. Data: 2014-03-25 08:42:34
Temat: Re: Programista iOS - Łódź
Od: m...@k...org
On Monday, March 24, 2014 11:36:35 PM UTC+1, g...@g...com wrote:
>
> Haskell ma najlepszy
>
> system typow, jaki widzialem,
A to polecam poczytac chocby o "dependent types", na poczatek:
http://en.wikipedia.org/wiki/Dependent_type
-
48. Data: 2014-03-25 08:49:41
Temat: Re: Programista iOS - Łódź
Od: g...@g...com
W dniu poniedziałek, 24 marca 2014 23:55:49 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
> >> > Mysle ze to akurat kwestia przyzwyczajenia.
> >> > Nie wiem tez co to znaczy, ze "caly swiat juz dawno poszedl dalej".
> >>
> >> Na przykład ma dekoratory (funkcje owijające inne funkcje/metody). Albo
> >> pozwala na manipulację drzewem wyprowadzenia (jak makra w Lispie). Albo
> >> pozwala na wnioskowanie o typach. I parę innych.
> >
> > Makra w lispie istnieja znacznie dluzej, niz PHP, ale pod wzgledem
> > popularnosci PHP zdecydowanie wygrywa.
>
> Owszem, trudno znaleźć język bardziej popularny od PHP. Ale znowu: ile
> się pisze rzeczy *zaawansowanych* w PHP? Mimo jego popularności, prawie
> nic.
Znaj proporcje, mocium panie. PHP powstal jako jezyk do tworzenia
licznikow na stronach domowych, i trzeba mu przyznac, ze zaszedl daleko.
Jednak wspolczesnie fakt, ze rzeczy zaawansowanych nie pisze sie w PHP,
nie wynika juz z semantycznych niedostatkow tego jezyka, tylko z (w pelni
zasluzonej) marnej reputacji PHP. Nawet jego tworcy przeszli od nazwy
"Personal Home Page" do "PHP HTML Preprocessor", nie mierzac zbyt
wysoko.
> A coś, co potrafi podobne rzeczy do lispowych makr (manipulację drzewem
> wyprowadzenia) występuje w całkiem sporej liczbie języków, od Pythona
> zaczynając.
Moglbys powiedziec cos wiecej na ten temat? Ew. rzucic jakims linkiem?
(Jedyny jezyk z nielispowa skladnia, o jakim slyszalem, ze ma lispowe
makra, to ruby-podobny jezyk o nazwie elixir)
> >> > latwosc korzystania z PHPowych tablic i ich uniwersalnosc sa
> >> > naprawde imponujace,
> >>
> >> Głupio pomieszane tablice asocjacyjne ze zwykłymi tablicami. Imponujące
> >> to to może być dla kogoś, kto przychodzi z C albo Javy, gdzie takie
> >> rzeczy są zepchnięte do bibliotek.
> >
> > Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
> > potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.
>
> ...gwarancje czasowe?
Jezeli piszesz "time-critical application", to zgadzam sie, ze PHP
to zly wybor. Podobnie jak wybor wiekszosci innych jezykow dynamicznych
oraz wszystkich jezykow z garbage collectorem.
> A pomieszane głupio, bo nie potrzebuję indeksować tablicy stringami.
> Potrzebuję mieć gwarancję dostępu w czasie O(1). Jak będę potrzebował
> indeksowanie stringami, to sobie użyję hasza i będę wiedział, jakie on
> daje gwarancje na operacje.
Jezeli nie potrzebujesz indeksowac tablicy stringami, to nie musisz
tego robic. Jezeli korzysasz ze spojnych kluczy numerycznych od 0, to
bedziesz mial normalna tablice numeryczna z dostepem w czasie O(1)
> Tablice w PHP to jakby ktoś wymieszał B-drzewa z wyrażeniami
> regularnymi. Można to trzymać razem, ale kto przy zdrowych zmysłach
> potrzebuje takiej konstrukcji?
Nie wiem, jaki jest zwiazek B-drzew z wyrazeniami regularnymi.
Tablice php-owe opieraja sie na spostrzeniu, ze sekwencje rowniez
stanowia forme asocjacji.
-
49. Data: 2014-03-25 10:43:50
Temat: Re: Programista iOS - Łódź
Od: IDKrzych <n...@p...onet.pl>
> ...cach
> Banki maja tendencje do długiego trzymania przy zyciu systemow
> zbudowanych dawno temu przy uzyciu antycznych technologii ktore juz
> dawno przestały byc uwazane za wskazane dla "critical systems" (np.
> COBOL) albo dorobily sie lepszych zastepnikow (np. Excel VBA).
a przepraszam co jest lepszym zastępnikiem dla Excel VBA?
--
IDKrzych
"Jakkolwiek będzie - będzie inaczej, aniżeli sobie wyobrażamy
- ponieważ między Dobrem a Złem znajdujemy się w życiu i w świecie
wielowymiarowym,
w którym dokumentnie pomieszane jest Przypadkowe z Nieuchronnym."
(S. Lem 1999)
-
50. Data: 2014-03-25 17:19:17
Temat: Re: Programista iOS - Łódź
Od: Tomasz Sowa <t...@N...ttmath.org>
Witam, dnia Tue, 25 Mar 2014 00:49:41 -0700 (PDT)
g...@g...com napisał:
> Znaj proporcje, mocium panie. PHP powstal jako jezyk do tworzenia
> licznikow na stronach domowych, i trzeba mu przyznac, ze zaszedl
> daleko. Jednak wspolczesnie fakt, ze rzeczy zaawansowanych nie pisze
> sie w PHP, nie wynika juz z semantycznych niedostatkow tego jezyka,
> tylko z (w pelni zasluzonej) marnej reputacji PHP.[...]
A technologiczne niedostatki już zostały rozwiązane?
1. Mogę już utrzymać stan pomiędzy requestami? Inaczej niż poprzez
session/baze danych/memcecha? (hint: co z obiektami nie
serializowalnymi takimi jak uchwyt do bazy danych, uchwyt do
pliku, socket...)
2. Mogę stworzyć drzewo w jednym requeście i odpytywać go w innych?
(tak abym nie musiał drzewa serializować przy każdym requeście).
3. Mogę już korzystać wydajnie z innych silników bazodanowych niż mysql?
(hint: każde mysql_connect() tworzyło nowy uchwyt, a więc wprowadzono
mysql_pconnect() aby spróbować odnaleźć 'stary' uchwyt jeśli
istnieje i go wykorzystać)
4. Mogę programować współbieżnie inaczej niż uruchamiając skrypt
z crona? Mogę zrobić kolejkę komunikatów np z plikami graficznymi do
wykonania miniaturki i w innym wątku po kolei je obrabiać? Tak aby
były dostępne tak szybko jak się da, ale jeśli już jest coś innego
do zrobienia to żebym nie zajechał procesora wykonując naraz
kilkanaście operacji...
5. Mogę zrobić cokolwiek bardziej sensownego aby nie mieć ograniczeń
wydajnościowych?
- Mogę zrobić statystyki każdej strony tak abym nie musiał przy
każdym requeście ich zapisywać i obciążąć bazy? (tylko zrobić
jeden save co x requestów)
- Mogę w tych statystykach zawrzeć adres ip osoby próbującej zgadnąć
login/hasło do mojego serwisu?
- Mogę to zrobić tak aby na jeden request atakującego nie poruszyć
całej machiny silnika bazodanowego? (hint: dos)
- Mogę zrobić wyszukiwanie pełnotekstowe tak aby nie korzystać z
lucene/sphinxa/bazy danych? Na przykład z fleksją dla języka
polskiego?
- Mogę mieć swój własny plik logów tak aby przy każdym requeście nie
otwierać pliku ponownie? (i beż użycia sysloga)
- Mogę przy starcie aplikacji wczytać plik konfiguracyjny, pliki
szablonów, pliki z tłumaczeniami na inne języki tak aby przy
kolejnych requestach korzystać z tych samych plików siedzących w
pamięci a nie mielić dyskiem ponownie? Tak bez memcecha albo
systemu plików montowanego w ramie da sie?
- Mogę cachować wyjściowy html bez użycia innych aplikacji? (i bez
mielenia dyskiem)
6. Mogę już normalnie robić aplikację tak jak w innych językach czy
dalej w każdym katalogu muszę zostawiać pusty plik index.php aby
ktoś przypadkiem nie podejrzał co jest w katalogu?
7. Mogę już normalnie robić aplikację czy dalej na początku pliku muszę
zostawiać wartownika na wypadek gdyby ktoś wpisał adres url do tego
pliku z palca? (i podejrzał coś co nie powinien)
8. Mogę już normalnie używać przyjaznych urli tak jak to robię
w aplikacji pisanej w C++ czy dalej aby mieć friendly urle to muszę
konfigurować serwer www? (hint: mod_rewrite)
--
Tomek